📡 Networking × Monitoring

CloudWatch エージェント
× VPC エンドポイント
完全ガイド

インターネットを使わずに、プライベートネットワーク内から安全に CloudWatch へログ・メトリクスを送信する方法を「社内メール便」のたとえで図解解説

🎯 最初に押さえる 4 つの結論

1

CW エージェントは 2 つの送信先を持つ

ログ用(logs.*)とメトリクス用(monitoring.*)の 2 つの AWS エンドポイントに通信する

2

VPC エンドポイントで通信を閉域化

Interface VPC Endpoint を作成すると、インターネットを経由せずにプライベートネットワーク内で通信できる

3

プライベート DNS が名前解決の鍵

VPC の enableDnsSupportenableDnsHostnames を両方有効にすることが必須条件

4

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 経由で通信する。

パターン A:インターネット経由(公道で郵便を送る) VPC(オフィスビル) プライベートサブネット EC2 インスタンス 🔧 CW エージェント (事務員が報告書を持つ) Internet Gateway (正面玄関) 🌐 インターネット (公道) CloudWatch Logs logs.region.amazonaws.com CloudWatch Metrics monitoring.region.amazonaws.com HTTPS HTTPS 443 443 ⚠️ インターネット経由 — パブリック IP または NAT GW が必要

図1: 通常経路ではインターネットを経由して CloudWatch へデータを送信する

パターン B:VPC エンドポイント経由(推奨)

VPC 内に Interface Endpoint を作成し、AWS PrivateLink を使って AWS 内部ネットワーク経由で通信する。インターネットへの露出がゼロになる。

パターン B:VPC エンドポイント経由(社内専用通路) VPC(オフィスビル) 🔍 プライベート DNS(社内電話帳) プライベートサブネット EC2 インスタンス 🔧 CW エージェント (事務員が報告書を持つ) logs.region.amazonaws.com → VPC EP のプライベート IP に解決 VPC Endpoint (Logs) ENI + プライベート IP (専用通路の入口 A) 🛡️ VPC Endpoint (Metrics) ENI + プライベート IP (専用通路の入口 B) 🛡️ AWS 内部ネットワーク(PrivateLink) ☁️ CloudWatch Logs logs.region.amazonaws.com 📊 CloudWatch Metrics monitoring.region.amazonaws.com 443 443 PrivateLink 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 の内部動作

Interface Endpoint の名前解決と通信フロー 1 DNS クエリ EC2 + CW エージェント logs.ap-northeast-1 .amazonaws.com を問い合わせ DNS Route 53 Resolver (社内電話帳の受付係) → プライベート IP を返す 2 プライベート IP 返却 10.0.1.x ENI(専用通路入口) プライベート IP: 10.0.1.x SG でアクセス制御 3 PrivateLink 経由で通信 HTTPS/443 ☁️ CloudWatch Logs / Metrics (本社の受付窓口) 🔑 ポイント:エージェントの設定変更は不要。DNS が自動的に VPC EP の IP を返すため、 アプリケーションは通常と同じ FQDN で通信でき、経路だけがプライベートに変わる

図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 機能はこの設定も有効であることを前提とする。

DNS 設定による名前解決先の違い ✅ 両方 true(推奨) logs.ap-northeast-1.amazonaws.com → 10.0.1.55(VPC EP のプライベート IP) 通信経路:EC2 → ENI → PrivateLink → CloudWatch 🎉 インターネット不要。完全プライベート通信! ❌ どちらか false logs.ap-northeast-1.amazonaws.com → 52.xx.xx.xx(パブリック IP) 通信経路:EC2 → IGW → インターネット → CloudWatch ⚠️ VPC EP が存在しても使われない!

図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 デフォルトで全送信許可
SG によるアクセス制御(警備員のチェック) EC2 (10.0.1.10) CW エージェント 🛡️ SG (警備員) ✅ TCP 443 from 10.0.0.0/16 ❌ TCP 22 ❌ その他 VPC Endpoint ENI (10.0.1.55) CloudWatch Logs / Metrics HTTPS 許可

図5: セキュリティグループは VPC Endpoint の ENI に関連付けて通信を制御

💡 ポイント:SG のソースに VPC の CIDR を指定するのが一般的ですが、よりセキュアにしたい場合は EC2 の SG ID をソースとして指定することもできます(SG 参照)。

📋 構築手順(ステップバイステップ)

以下の手順で、プライベートサブネットの EC2 から VPC エンドポイント経由で CloudWatch にログ・メトリクスを送信できるようになります。

1

VPC の DNS 設定を確認・有効化

enableDnsSupportenableDnsHostnames が両方 true であることを確認。AWS コンソールで VPC → 「DNS 設定の編集」から変更可能。

2

VPC Endpoint 用セキュリティグループを作成

インバウンドに TCP/443(ソース: VPC CIDR)を許可する SG を作成。

3

Interface VPC Endpoint を 2 つ作成

com.amazonaws.{region}.logscom.amazonaws.{region}.monitoring を作成。プライベート DNS を有効にし、作成した SG を関連付ける。

4

EC2 に CW エージェントをインストール・設定

SSM パラメータストアや設定ファイルで収集対象を定義。エンドポイント URL の変更は不要(プライベート DNS が自動解決)。

5

動作確認

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}.logscom.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 設定の確認がポイント。enableDnsSupportenableDnsHostnames の両方が 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 は S3DynamoDB のみ。この違いは頻出。

❓ 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}.ssmcom.amazonaws.{region}.ssmmessagescom.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 のみ対応(無料)

Created by SSuzuki1063

AWS SAP Learning Resources