Amazon VPCエンドポイント設計入門｜Interface Endpoint vs Gateway Endpoint・PrivateLink・エンドポイントポリシーを現場で使い分ける実践ガイド

EC2からS3にアクセスするたびにNAT Gateway経由でインターネットを通っている——そんな設定のままクラウドを運用しているケースは少なくありません。セキュリティ審査でNGが出たり、データ転送コストが想定より高くなったりして、はじめてVPCエンドポイントの存在に気づく、という流れはよくあります。

VPCエンドポイントを使えば、インターネットを経由せずにAWSのマネージドサービスとプライベートに通信できます。ただし「Gateway Endpoint」と「Interface Endpoint（AWS PrivateLinkベース）」の2種類があり、仕組みも料金も対応サービスも大きく違います。

この記事では、VPCエンドポイントの2種類の違いから、エンドポイントポリシーの設計パターン、AZ間通信コストの落とし穴まで、オンプレからクラウド移行を進めるインフラエンジニア向けに実践的に解説します。

VPCエンドポイントとは何か？NAT Gatewayと何が違うのか

デフォルトのVPC設定では、プライベートサブネットのEC2インスタンスがS3やSystems ManagerなどのAWSサービスにアクセスするには、NAT Gatewayを経由してインターネットに出てから戻ってくる必要があります。

Amazon VPC入門でも触れているとおり、VPCはプライベートな仮想ネットワーク空間です。AWSサービスのエンドポイントは基本的にパブリックIPを持っており、プライベートサブネットからはNATなしに直接到達できません。

VPCエンドポイントはこの問題を解消する仕組みで、AWSの内部ネットワーク（バックボーン）上にプライベートな接続経路を確立します。オンプレで言えば、インターネットを使わず専用回線でSaaSベンダーのデータセンターに直結するイメージに近いです。

主なメリットは次のとおりです。

・セキュリティ: トラフィックがインターネットに出ないため、外部露出のリスクが減る
・コスト: NAT Gatewayのデータ転送料（$0.062/GB・東京リージョン、2026年10月時点）を節約できる
・レイテンシ: AWSバックボーン経由のため、インターネット経由より安定した遅延が期待できる

Gateway EndpointとInterface Endpointの違い

VPCエンドポイントには2つのタイプがあり、根本的な仕組みが異なります。

1. Gateway Endpoint：S3とDynamoDB専用の無料エンドポイント

Gateway Endpointはルートテーブルに「S3向けのプレフィックスリスト（pl-xxxxxx）への通信はエンドポイント経由で転送」というルートを追加することで機能します。ENIは作成されないため、セキュリティグループの設定も不要です。

S3とDynamoDBという頻繁に使われる2サービスを無料でカバーできるため、プライベートサブネットを使う構成では必ず設定しておくべきエンドポイントです。

AWS NAT Gatewayのコスト削減の観点でも、S3向けのトラフィックをGateway Endpoint経由に切り替えるだけで月額の転送コストを大幅に下げられます。

2. Interface Endpoint（AWS PrivateLink）：100以上のサービスに対応

Interface EndpointはAWS PrivateLinkという技術をベースにしており、指定したサブネット内にElastic Network Interface（ENI）が作成されます。このENIにプライベートIPが割り当てられ、サービスとの通信はそのIPを経由します。

プライベートDNSを有効化すると、サービスの既存DNSホスト名（例：ssm.ap-northeast-1.amazonaws.com）がENIのプライベートIPに解決されるようになります。アプリケーションコードの変更なしに、既存の設定のまま使えるのが大きな利点です。

Interface Endpointが必要になる主なサービスを挙げると次のとおりです。

・AWS Systems Manager（SSM）: Session Managerでの踏み台なし接続
・Amazon ECR: コンテナイメージのプル・プッシュ
・AWS KMS: 暗号化キーの利用
・Amazon CloudWatch Logs: ログ送信
・AWS Secrets Manager: シークレットの取得
・AWS STS: 一時的な認証情報の取得

料金の仕組みと実際のコスト感覚（2026年10月時点）

Gateway Endpoint：完全無料

S3およびDynamoDBへのGateway Endpointは作成・利用ともに無料です。ルートテーブルへのエントリ追加で動作するためENIも消費しません。迷わず設定しておきましょう。

Interface Endpoint：エンドポイント時間料金＋データ転送料

東京リージョン（ap-northeast-1）での料金は次のとおりです（2026年10月時点）。

・エンドポイント時間料金: $0.01/時間/AZ（1か月730時間として約$7.3/AZ/エンドポイント）
・データ処理料金: $0.01/GB

「AZあたりの課金」という点が重要で、3つのAZにInterface Endpointを配置するとエンドポイント1つあたり月約$21.9（時間分のみ）かかります。SSM用に3本（ssm・ec2messages・ssmmessages）作ると約$65.7/月になります。

（想定例）Systems Managerの3エンドポイントを東京リージョンの3AZに展開し、月100GBのデータ処理が発生した場合、時間料金$65.7 + データ処理$1.0 = 約$66.7/月の試算になります。

Interface Endpointの料金は作成するサービスと展開するAZ数に比例して増えます。不要なエンドポイントの棚卸しは定期的に行い、使っていないものは削除しましょう。

実装手順

1. Gateway Endpoint（S3）の作成

マネジメントコンソールでの操作手順は次のとおりです。

・VPCダッシュボード → 左メニュー「エンドポイント」→「エンドポイントを作成」をクリック
・「サービスカテゴリ」で「AWSサービス」を選択
・サービス名から「com.amazonaws.ap-northeast-1.s3」（Gatewayタイプ）を選択
・対象VPCとルートテーブルを選択（プライベートサブネット用のルートテーブルを選ぶ）
・エンドポイントポリシーを設定（初期値は全許可）

AWS CLIで作成する場合は次のコマンドです。

# S3 Gateway Endpoint の作成（東京リージョン）
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-xxxxxxxx \
  --service-name com.amazonaws.ap-northeast-1.s3 \
  --route-table-ids rtb-xxxxxxxx \
  --vpc-endpoint-type Gateway \
  --region ap-northeast-1

作成後、指定したルートテーブルに「pl-xxxxxxxx（S3のプレフィックスリスト）→ vpce-xxxxxxxx」というルートが自動追加されていることをコンソールで確認してください。

2. Interface Endpoint（Systems Manager）の作成

EC2インスタンスをSystems Manager Session Managerで管理する場合、次の3つのInterface Endpointが必要です。

・com.amazonaws.ap-northeast-1.ssm
・com.amazonaws.ap-northeast-1.ec2messages
・com.amazonaws.ap-northeast-1.ssmmessages

各エンドポイントを作成する際は、「プライベートDNSを有効化」にチェックを入れ、セキュリティグループでEC2インスタンスからHTTPS（443番ポート）のインバウンドを許可します。

AWS CLIでの作成例（ssm）は次のとおりです。

# Systems Manager Interface Endpoint の作成（3AZ分）
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-xxxxxxxx \
  --service-name com.amazonaws.ap-northeast-1.ssm \
  --subnet-ids subnet-aaaaaaaa subnet-bbbbbbbb subnet-cccccccc \
  --security-group-ids sg-xxxxxxxx \
  --vpc-endpoint-type Interface \
  --private-dns-enabled \
  --region ap-northeast-1

AWS Systems Manager Session Managerの活用には、このInterface Endpointの設定が前提になります。パブリックIPなし・踏み台サーバーなしでプライベートEC2に接続できる構成の要です。

エンドポイントポリシーの設計パターン

VPCエンドポイントにはエンドポイントポリシーを設定できます。デフォルトは全アクセス許可ですが、最小権限の原則に従って絞り込むことでセキュリティを高められます。IAMポリシーとは独立して評価される追加のガードレールとして機能します。

1. 特定バケットのみ許可するS3 Gateway Endpointポリシー（想定例）

自社管理のS3バケットへのアクセスのみを許可し、他バケットへの通信をブロックする設計の想定例です。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowSpecificBucketOnly",
      "Effect": "Allow",
      "Principal": "*",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::your-bucket-name",
        "arn:aws:s3:::your-bucket-name/*"
      ]
    }
  ]
}

このポリシーを設定すると、エンドポイント経由ではyour-bucket-name以外のS3バケットへのアクセスが拒否されます。誤って別のAWSアカウントのバケットにデータを書き込む事故を防ぐ効果もあります。

2. 自社アカウントのみ許可するInterface Endpointポリシー（想定例）

Interface Endpointにもポリシーを適用できます。自社AWSアカウントへのアクセスのみを許可する例です。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "ssm:*",
      "Resource": "arn:aws:ssm:ap-northeast-1:123456789012:*"
    }
  ]
}

エンドポイントポリシーはIAMポリシーとAND条件で評価されます。IAMで許可されていても、エンドポイントポリシーで拒否されればアクセスできません。

AWS IAM Access Analyzerを活用すると、エンドポイントポリシーの意図しない外部公開リスクも検出できます。エンドポイントポリシーの設計後は、Access Analyzerで想定外のアクセスパスがないか確認することを推奨します。

マルチAZ設計とAZ間通信コストの落とし穴

Interface Endpointはサブネット（AZ）ごとに作成する必要があります。1つのAZにしかEndpointを置かなかった場合、別AZのEC2インスタンスがそのEndpointを使うとAZ間通信料が発生します。

AZ間通信料は$0.01/GB（東京リージョン、2026年10月時点）で、大量のトラフィックがあると無視できない額になります。高可用性を確保しつつAZ間コストを避けるには、利用するAZすべてにInterface Endpointを作成するのが基本です。

ただし、エンドポイント数が増えると時間課金も増えるトレードオフがあります。一般的には次の方針で設計します。

・本番環境: 全AZ（通常3つ）にInterface Endpointを配置
・開発・検証環境: 1 AZのみに絞ってコスト削減（不要時は削除も検討）

また、AWS Transit Gatewayを使ったハブ&スポーク設計の場合、共有VPCにInterface Endpointを集約する「Centralized Endpoint」パターンも採れます。ただしトラフィックのルーティング設計が複雑になるため、小規模環境では各VPCにEndpointを配置するシンプルな構成の方が運用しやすいケースが多いです。

VPC CIDRブロック設計と合わせて、マルチアカウント・マルチVPC環境でのEndpoint配置方針も事前に決めておくと、後から設計変更する手間が省けます。

よくあるつまずきと対処法

【つまずき1】Interface Endpointを作ったのにサービスに接続できない

最も多い原因はセキュリティグループの設定漏れです。Interface EndpointのENIにアタッチするセキュリティグループは、EC2インスタンスからHTTPS（443番ポート）のインバウンドを許可する必要があります。EC2側のセキュリティグループのIDをソースとして指定すると、より絞り込んだ設定になります。

【つまずき2】プライベートDNSを有効化したのにパブリックDNSに解決される

VPCの設定で「DNS解決を有効化」（enableDnsResolution）と「DNSホスト名を有効化」（enableDnsHostnames）の両方がオンになっていないとプライベートDNSが機能しません。マネジメントコンソールでVPCの設定を確認してください。

【つまずき3】Gateway EndpointでS3にアクセスできない

Gateway Endpointはルートテーブルベースです。プライベートサブネットにアタッチされているルートテーブルにGateway Endpointのルートが追加されているか確認してください。サブネットによってアタッチされているルートテーブルが異なる場合は、すべての対象ルートテーブルにエンドポイントを関連付けます。

VPC Flow Logsを有効化しておくと、実際のトラフィックがどの経路を通っているか可視化でき、疎通確認にも役立ちます。

【つまずき4】エンドポイントポリシーを変更したのに反映されない

エンドポイントポリシーの変更は即時反映されますが、既存の接続セッションには影響しない場合があります。設定変更後にアプリケーションの再起動や再接続を試みると、意図どおりに動作するケースがあります。

本記事のまとめ

VPCエンドポイントは、クラウドのネットワーク設計において「インターネットを経由しない安全な通信経路」を確保するための重要な仕組みです。

まず手を付けるべきはS3とDynamoDBのGateway Endpointです。無料で設定でき、NAT Gatewayのコスト削減にもなります。そのうえで、SSMやECRなどInterface Endpointが必要なサービスを洗い出し、AZ設計を含めて計画的に追加していくのが現実的です。

エンドポイントポリシーで最小権限を設定することも忘れずに。デフォルトの「全許可」のまま本番運用するのは、ガードレールのない高速道路を走るようなものです。AWSエグレス制御の全体設計の中でVPCエンドポイントを位置づけると、データ流出対策としてもより効果的に機能します。