CloudWatch エージェント
× VPC エンドポイント
完全ガイド
インターネットを使わずに、プライベートネットワーク内から安全に CloudWatch へログ・メトリクスを送信する方法を「社内メール便」のたとえで図解解説
🎯 最初に押さえる 4 つの結論
CW エージェントは 2 つの送信先を持つ
ログ用(logs.*)とメトリクス用(monitoring.*)の 2 つの AWS エンドポイントに通信する
VPC エンドポイントで通信を閉域化
Interface VPC Endpoint を作成すると、インターネットを経由せずにプライベートネットワーク内で通信できる
プライベート DNS が名前解決の鍵
VPC の enableDnsSupport と enableDnsHostnames を両方有効にすることが必須条件
SG で HTTPS(443)を許可する
VPC エンドポイントのセキュリティグループで、VPC CIDR からの TCP/443 インバウンドを許可する必要がある
🏢 たとえ話:「社内メール便」で理解する全体像
CloudWatch エージェントと VPC エンドポイントの関係を、オフィスビルの社内メール便にたとえて説明します。
💡 イメージ:各部署(EC2)の事務員(CW エージェント)が業務報告書(ログ・メトリクス)を本社(CloudWatch)に届ける。通常は公道の郵便(インターネット)を使うが、機密保持のため社内専用通路(VPC エンドポイント)を使う方法がある。
| AWS の概念 | 社内メール便のたとえ | 役割 |
|---|---|---|
| CloudWatch エージェント | 各部署の事務員 | ログやメトリクスを収集して送信する |
| EC2 インスタンス | 各部署のオフィス | エージェントが動作するサーバー |
| CloudWatch(Logs / Metrics) | 本社の受付窓口 | データを受け取る AWS サービス |
| Internet Gateway | ビルの正面玄関 → 公道 | インターネット経由の通信経路 |
| VPC エンドポイント | 社内専用通路(地下通路) | AWS 内部ネットワーク経由の専用接続 |
| プライベート DNS | 社内電話帳 | サービス名を専用通路の入口に変換 |
| セキュリティグループ | 専用通路の入口にいる警備員 | 通れる人(通信)をチェックする |
| VPC エンドポイントポリシー | 通路の利用ルール掲示板 | どの操作を許可するか制御する |
📡 CloudWatch エージェントの基本と通信先
CloudWatch エージェント(統合エージェント)は、EC2 やオンプレミスサーバーからログとメトリクスの両方を CloudWatch に送信するソフトウェアです。以下の 2 つの AWS エンドポイントと HTTPS(TCP/443)で通信します。
CloudWatch Logs エンドポイント
logs.{region}.amazonaws.com
ログデータの送信先。アプリログ、OS ログ、カスタムログなどを収集して送る。
たとえ:日報・議事録を受け取る窓口
CloudWatch Metrics エンドポイント
monitoring.{region}.amazonaws.com
メトリクスデータの送信先。CPU 使用率、メモリ使用量などのカスタムメトリクスを送る。
たとえ:売上数値・KPI を受け取る窓口
ℹ️ 重要:CloudWatch Logs と CloudWatch Metrics は別のエンドポイントを使います。VPC エンドポイント経由にする場合、2 つとも作成する必要があります。片方だけ作成した場合、もう片方の通信はインターネット経由(または到達不能)になります。
🏗️ アーキテクチャ図:通常経路 vs VPC エンドポイント経路
パターン A:インターネット経由(通常経路)
IGW → インターネット → AWS サービスエンドポイント という経路。パブリックサブネットの EC2 や NAT Gateway 経由で通信する。
図1: 通常経路ではインターネットを経由して CloudWatch へデータを送信する
パターン B:VPC エンドポイント経由(推奨)
VPC 内に Interface Endpoint を作成し、AWS PrivateLink を使って AWS 内部ネットワーク経由で通信する。インターネットへの露出がゼロになる。
図2: VPC エンドポイントにより全通信が AWS 内部ネットワーク経由となる
🔗 VPC エンドポイントの仕組みと設定
Interface VPC Endpoint(AWS PrivateLink ベース)を使うと、VPC 内にプライベート IP を持つ ENI(Elastic Network Interface)が作成され、AWS サービスへの通信がそのENI経由で行われます。
必要な VPC エンドポイント(2つ)
com.amazonaws.{region}.logs
用途:CloudWatch Logs へのログデータ送信
たとえ:日報・議事録を届ける専用通路 A
タイプ:Interface
com.amazonaws.{region}.monitoring
用途:CloudWatch Metrics へのメトリクス送信
たとえ:売上数値を届ける専用通路 B
タイプ:Interface
⚠️ 注意:両方のエンドポイントを作成しないと、CW エージェントはエラーを出します。Logs だけ作って Metrics を忘れる(またはその逆)のはよくあるミスです。
Interface Endpoint の内部動作
図3: プライベート DNS が有効な場合、名前解決から通信まですべてがプライベート経路になる
🔍 プライベート DNS と VPC の DNS 設定
VPC エンドポイントのプライベート DNS 機能を使うと、通常の AWS エンドポイント名(例:logs.us-west-2.amazonaws.com)がそのまま VPC エンドポイントのプライベート IP に解決されます。つまり、エージェント側の設定変更が不要です。
必須の VPC DNS 設定(2つとも true にする)
enableDnsSupport = true
たとえ:社内電話帳サービスを「有効」にする設定
VPC 内の Amazon 提供 DNS サーバー(AmazonProvidedDNS)を使った名前解決を有効にする。これが false だとそもそも DNS クエリが動かない。
enableDnsHostnames = true
たとえ:各部署のオフィスに「名札」を貼る設定
VPC 内のインスタンスにパブリック DNS ホスト名を割り当てる。プライベート DNS 機能はこの設定も有効であることを前提とする。
図4: DNS 設定が正しくないと VPC エンドポイントが機能しない
ℹ️ たとえで理解:社内電話帳が無効(enableDnsSupport=false)だと、事務員は本社の番号がわからず公道経由で行くしかない。電話帳があっても名札がない(enableDnsHostnames=false)と、専用通路が正しく案内されない。両方揃って初めて「社内専用通路」が使える。
🛡️ セキュリティグループの設定
VPC エンドポイントの ENI にはセキュリティグループ(SG)を関連付けます。これは「専用通路の入口にいる警備員」で、許可された人(通信)だけを通します。
VPC Endpoint 用セキュリティグループの設定例
| 方向 | プロトコル | ポート | ソース / 宛先 | 説明 |
|---|---|---|---|---|
| インバウンド | TCP | 443 | VPC CIDR(例: 10.0.0.0/16) | VPC 内からの HTTPS 通信を許可 |
| アウトバウンド | 全トラフィック | 全て | 0.0.0.0/0 | デフォルトで全送信許可 |
図5: セキュリティグループは VPC Endpoint の ENI に関連付けて通信を制御
💡 ポイント:SG のソースに VPC の CIDR を指定するのが一般的ですが、よりセキュアにしたい場合は EC2 の SG ID をソースとして指定することもできます(SG 参照)。
📋 構築手順(ステップバイステップ)
以下の手順で、プライベートサブネットの EC2 から VPC エンドポイント経由で CloudWatch にログ・メトリクスを送信できるようになります。
VPC の DNS 設定を確認・有効化
enableDnsSupport と enableDnsHostnames が両方 true であることを確認。AWS コンソールで VPC → 「DNS 設定の編集」から変更可能。
VPC Endpoint 用セキュリティグループを作成
インバウンドに TCP/443(ソース: VPC CIDR)を許可する SG を作成。
Interface VPC Endpoint を 2 つ作成
com.amazonaws.{region}.logs と com.amazonaws.{region}.monitoring を作成。プライベート DNS を有効にし、作成した SG を関連付ける。
EC2 に CW エージェントをインストール・設定
SSM パラメータストアや設定ファイルで収集対象を定義。エンドポイント URL の変更は不要(プライベート DNS が自動解決)。
動作確認
EC2 から nslookup logs.{region}.amazonaws.com でプライベート IP が返ることを確認。CW エージェントのログでエラーが出ないことを確認。
💻 設定例
VPC エンドポイントの作成
# 1. VPC Endpoint 用 SG を作成 aws ec2 create-security-group \ --group-name "vpce-cw-sg" \ --description "SG for CW VPC Endpoints" \ --vpc-id vpc-0123456789abcdef0 # 2. SG にインバウンドルール追加(TCP 443) aws ec2 authorize-security-group-ingress \ --group-id sg-xxxxxxxxxx \ --protocol tcp \ --port 443 \ --cidr 10.0.0.0/16 # 3. Logs 用 VPC Endpoint を作成 aws ec2 create-vpc-endpoint \ --vpc-id vpc-0123456789abcdef0 \ --service-name com.amazonaws.ap-northeast-1.logs \ --vpc-endpoint-type Interface \ --subnet-ids subnet-aaa subnet-bbb \ --security-group-ids sg-xxxxxxxxxx \ --private-dns-enabled # 4. Monitoring 用 VPC Endpoint を作成 aws ec2 create-vpc-endpoint \ --vpc-id vpc-0123456789abcdef0 \ --service-name com.amazonaws.ap-northeast-1.monitoring \ --vpc-endpoint-type Interface \ --subnet-ids subnet-aaa subnet-bbb \ --security-group-ids sg-xxxxxxxxxx \ --private-dns-enabled
AWSTemplateFormatVersion: "2010-09-09" Resources: # VPC Endpoint 用セキュリティグループ VPCEndpointSG: Type: AWS::EC2::SecurityGroup Properties: GroupDescription: SG for CW VPC Endpoints VpcId: !Ref VPC SecurityGroupIngress: - IpProtocol: tcp FromPort: 443 ToPort: 443 CidrIp: 10.0.0.0/16 # CloudWatch Logs 用 VPC Endpoint LogsEndpoint: Type: AWS::EC2::VPCEndpoint Properties: VpcId: !Ref VPC ServiceName: !Sub com.amazonaws.${AWS::Region}.logs VpcEndpointType: Interface SubnetIds: - !Ref PrivateSubnetA - !Ref PrivateSubnetB SecurityGroupIds: - !Ref VPCEndpointSG PrivateDnsEnabled: true # CloudWatch Metrics 用 VPC Endpoint MonitoringEndpoint: Type: AWS::EC2::VPCEndpoint Properties: VpcId: !Ref VPC ServiceName: !Sub com.amazonaws.${AWS::Region}.monitoring VpcEndpointType: Interface SubnetIds: - !Ref PrivateSubnetA - !Ref PrivateSubnetB SecurityGroupIds: - !Ref VPCEndpointSG PrivateDnsEnabled: true
# VPC Endpoint 用セキュリティグループ resource "aws_security_group" "vpce_cw" { name = "vpce-cw-sg" description = "SG for CW VPC Endpoints" vpc_id = aws_vpc.main.id ingress { from_port = 443 to_port = 443 protocol = "tcp" cidr_blocks = ["10.0.0.0/16"] } } # CloudWatch Logs 用 VPC Endpoint resource "aws_vpc_endpoint" "cw_logs" { vpc_id = aws_vpc.main.id service_name = "com.amazonaws.ap-northeast-1.logs" vpc_endpoint_type = "Interface" subnet_ids = [ aws_subnet.private_a.id, aws_subnet.private_b.id ] security_group_ids = [aws_security_group.vpce_cw.id] private_dns_enabled = true } # CloudWatch Metrics 用 VPC Endpoint resource "aws_vpc_endpoint" "cw_monitoring" { vpc_id = aws_vpc.main.id service_name = "com.amazonaws.ap-northeast-1.monitoring" vpc_endpoint_type = "Interface" subnet_ids = [ aws_subnet.private_a.id, aws_subnet.private_b.id ] security_group_ids = [aws_security_group.vpce_cw.id] private_dns_enabled = true }
DNS 解決の確認コマンド
# プライベート IP が返ればOK nslookup logs.ap-northeast-1.amazonaws.com # 期待結果: 10.0.x.x のようなプライベート IP nslookup monitoring.ap-northeast-1.amazonaws.com # 期待結果: 10.0.x.x のようなプライベート IP
dig logs.ap-northeast-1.amazonaws.com +short # 期待結果: 10.0.1.55 など VPC 内のプライベート IP dig monitoring.ap-northeast-1.amazonaws.com +short # 期待結果: 10.0.2.88 など VPC 内のプライベート IP
✅ ベストプラクティス vs ❌ アンチパターン
✅ ベストプラクティス
- Logs と Monitoring の 両方の VPC Endpoint を作成する
- プライベート DNS を有効にして設定変更を最小化する
- SG のソースに VPC CIDR または EC2 の SG ID を指定する
- 複数 AZ にサブネットを指定して高可用性を確保する
- VPC Endpoint ポリシーで必要最小限のアクションのみ許可する
- CloudTrail で VPC Endpoint 経由のアクセスを記録する
❌ アンチパターン
- Logs だけ作って Monitoring を忘れる(またはその逆)
- SG のインバウンドに 0.0.0.0/0 を指定する(広すぎる)
- enableDnsSupport / enableDnsHostnames を無効のまま放置する
- 単一 AZ のサブネットだけに Endpoint を配置する
- Endpoint ポリシーを設定せずフルアクセスのまま運用する
- NAT Gateway と VPC Endpoint を併用して二重コストを発生させる
🔧 トラブルシューティング
⚠️ CW エージェントが「RequestError: send request failed」を出す
原因:VPC Endpoint が作成されていない、または SG の TCP/443 が許可されていない
✅ 対策:logs / monitoring 両方の Endpoint 存在確認、SG のインバウンド 443 ルールを確認
⚠️ nslookup でパブリック IP が返る
原因:enableDnsSupport / enableDnsHostnames が false、またはプライベート DNS が無効
✅ 対策:VPC の DNS 設定を両方 true にし、Endpoint の「プライベート DNS 名を有効にする」を ON にする
⚠️ メトリクスは送れるがログが送れない(またはその逆)
原因:片方の VPC Endpoint しか作成していない
✅ 対策:com.amazonaws.{region}.logs と com.amazonaws.{region}.monitoring の両方が存在するか確認
⚠️ Endpoint 作成時に「PrivateDnsOnlyForInboundResolverEndpoint」エラー
原因:VPC の enableDnsHostnames が false のとき、プライベート DNS を有効にできない
✅ 対策:先に VPC の enableDnsHostnames を true にしてから Endpoint を作成する
📝 試験対策(ANS-C01 / SAP-C02)
🎯 出題パターン 1:プライベートサブネットから CloudWatch にログを送信したい
「インターネットアクセスなしで CW にデータ送信」→ Interface VPC Endpoint が正解。Gateway Endpoint(S3/DynamoDB 用)とは異なるタイプであることに注意。
🎯 出題パターン 2:VPC Endpoint を作成したのに通信できない
DNS 設定の確認がポイント。enableDnsSupport と enableDnsHostnames の両方が true でないとプライベート DNS が機能しない。また SG の TCP/443 許可忘れもよく出る。
🎯 出題パターン 3:コスト最適化
NAT Gateway($0.045/GB + 時間課金)vs VPC Endpoint(時間課金 + $0.01/GB)のコスト比較。大量のログ転送がある場合、VPC Endpoint のほうがコスト効率が良い場合がある。
🎯 出題パターン 4:Interface vs Gateway Endpoint
CloudWatch Logs / Metrics は Interface Endpoint(PrivateLink ベース)。Gateway Endpoint は S3 と DynamoDB のみ。この違いは頻出。
❓ FAQ(よくある質問)
いいえ、プライベート DNS を有効にしている場合は不要です。エージェントは通常の AWS エンドポイント名(logs.region.amazonaws.com)を使い、DNS が自動的に VPC Endpoint のプライベート IP を返します。
はい。Interface VPC Endpoint は、指定した各サブネット(各 AZ)ごとに ENI が作成され、ENI ごとに時間課金が発生します。コストと可用性のバランスを考慮してサブネット数を決めてください。
はい、Direct Connect または VPN で VPC に接続し、VPC Endpoint のプライベート IP にルーティングすることで可能です。ただし、オンプレミスの DNS をプライベート DNS に向ける設定(Route 53 Resolver Inbound Endpoint など)が追加で必要になります。
Gateway Endpoint はルートテーブルにエントリを追加する方式で、S3 と DynamoDB のみ対応。無料です。Interface Endpoint は ENI を作成して PrivateLink を使う方式で、CloudWatch を含む多数のサービスに対応しますが、時間課金とデータ処理料が発生します。
はい。SSM を使う場合は com.amazonaws.{region}.ssm、com.amazonaws.{region}.ssmmessages、com.amazonaws.{region}.ec2messages の VPC Endpoint も必要です。さらに S3 への Gateway Endpoint も推奨されます。
📋 チートシート
📌 必要な VPC Endpoint
com.amazonaws.{region}.logs
com.amazonaws.{region}.monitoring
📌 VPC DNS 設定
enableDnsSupport: true
enableDnsHostnames: true
📌 SG インバウンド
TCP 443 from VPC CIDR
📌 エンドポイントタイプ
Interface(PrivateLink ベース)
※ Gateway ではない
📌 確認コマンド
nslookup logs.{region}.amazonaws.com
→ プライベート IP が返れば OK
📌 エージェント設定
プライベート DNS 有効時は変更不要
通常の FQDN がそのまま使える
📖 用語集
- CloudWatch エージェント
- EC2 やオンプレミスからログ・メトリクスを CloudWatch に送信するソフトウェア
- Interface VPC Endpoint
- VPC 内に ENI を作成して AWS サービスにプライベート接続する仕組み(PrivateLink ベース)
- AWS PrivateLink
- AWS 内部ネットワークを経由してサービスに接続する技術。インターネットを使わない
- ENI(Elastic Network Interface)
- VPC 内の仮想ネットワークカード。VPC Endpoint はこれを使ってプライベート IP を持つ
- プライベート DNS
- VPC 内で AWS サービスの標準 FQDN を VPC Endpoint のプライベート IP に解決する機能
- enableDnsSupport
- VPC で Amazon 提供 DNS(AmazonProvidedDNS)を使った名前解決を有効にする設定
- enableDnsHostnames
- VPC 内のインスタンスにパブリック DNS ホスト名を割り当てる設定
- Gateway Endpoint
- ルートテーブルにエントリを追加する方式の VPC Endpoint。S3 と DynamoDB のみ対応(無料)