VPC エンドポイント

VPC エンドポイントとは

VPC エンドポイントは、VPC 内のリソース (Lambda, EC2, ECS) から AWS サービス (S3, DynamoDB, SQS) にインターネットを経由せずにプライベートにアクセスする仕組みである。トラフィックが AWS ネットワークから外へ出ないため到達先を絞り込みやすく、NAT ゲートウェイに GB 単位でかかるデータ処理料金も避けられる。

補足しておくと、プライベートサブネットから NAT ゲートウェイ経由で同一リージョンの S3 へ送るトラフィックも、インターネットゲートウェイを通過はするが AWS ネットワークの外へは出ない。VPC エンドポイントの価値は公衆網に出さないこと自体よりも、経路をエンドポイント単位で制御できる点と課金の違いにある。

2 つの種類

どちらを使うかは好みで選ぶものではなく、対象サービスで決まる。S3 と DynamoDB だけがゲートウェイ型に対応し、それ以外は PrivateLink を使うインターフェース型になる。課金の形も違い、ゲートウェイ型は追加料金なし、インターフェース型は AZ ごとの時間料金とデータ処理料金がかかる (料金は東京リージョン・2026 年 8 月時点)。

種類	対象サービス	コスト	仕組み
ゲートウェイ型	S3, DynamoDB のみ	追加料金なし	ルートテーブルにルートを追加
インターフェース型	その他の AWS サービス	$0.014/時間 (AZ ごと) + データ処理 $0.01/GB	ENI をサブネットに作成 (PrivateLink)

ゲートウェイ型には追加料金がかからないため、S3 や DynamoDB にアクセスする VPC 内のリソースには基本的に設定しておきたい。設定しなかった場合に発生するのはデータ転送料金ではなく、NAT ゲートウェイのデータ処理料金である (東京リージョン・2026 年 8 月時点で $0.062/GB)。同一リージョンの S3 宛てならデータ転送料金そのものは発生しないため、ゲートウェイエンドポイントで削れるのはこのデータ処理料金の分だと理解しておくと見積もりを外さない。

NAT ゲートウェイとのコスト比較

Lambda を VPC 内に配置して S3 にアクセスする場合:

方式	月額コスト (100 GB 処理・東京リージョン・2026 年 8 月時点)
NAT ゲートウェイ (1 AZ)	~$51 (時間料金 $45 + データ処理 $6)
S3 ゲートウェイエンドポイント	$0 (追加料金なし)
S3 インターフェースエンドポイント (1 AZ)	~$11 (時間料金 $10 + データ処理 $1)

見落としやすいのは、時間料金が消えるのは NAT ゲートウェイ自体を削除できた場合だけだという点である。外部 API の呼び出しなど NAT ゲートウェイを残す理由が他にあるなら、ゲートウェイエンドポイントで減るのは S3 宛て分のデータ処理料金 (この例では約 $6) にとどまる。逆に S3 や DynamoDB へのアクセスだけが NAT ゲートウェイを置いている理由なら、そちらへ寄せて NAT ゲートウェイを消せば月額のほぼ全体が消える。転送量が増えるほど差は開くので、まず S3 と DynamoDB をゲートウェイ型へ寄せるのが定石だ。なお NAT ゲートウェイの時間料金も AZ ごとにかかるため、2 AZ 構成なら上表の時間料金は 2 倍になる。

Lambda + VPC でのアクセス経路

Lambda を VPC 内に置くと、それまで意識せず使えていた AWS SDK の呼び出しがすべて VPC のルーティングに従うようになる。宛先ごとに経路を用意しておかないと、デプロイ後のタイムアウトで初めて気づくことになる。

Lambda (VPC 内)
  → S3:        ゲートウェイエンドポイント (無料)
  → DynamoDB:  ゲートウェイエンドポイント (無料)
  → SQS/SNS:   インターフェースエンドポイント (有料) or NAT GW
  → Bedrock:   インターフェースエンドポイント (有料) or NAT GW
  → 外部 API:  NAT ゲートウェイ (相手が PrivateLink で公開していればインターフェース型も可)

エンドポイントポリシー

ゲートウェイ型・インターフェース型のどちらにもエンドポイントポリシーを設定でき、そのエンドポイントを通せるリクエストをリソース単位・アクション単位で絞り込める。ここで押さえておきたいのは、エンドポイントポリシーは IAM の ID ベースポリシーを上書きも代替もしないという点である。両方が許可して初めてリクエストが通るため、絞りすぎると原因の分かりにくい AccessDenied を生む。また、作成時に付く既定のポリシーはすべてのアクセスを許可する内容なので、絞り込みたいなら明示的に置き換える必要がある。

エンドポイントポリシーはリソースベースのポリシーなので Principal 要素が必須である。ゲートウェイ型では Principal に個別の ARN を書けないため、"Principal": "*" と条件キー aws:PrincipalArn の組み合わせで呼び出し元を限定する。

{
  "Statement": [{
    "Effect": "Allow",
    "Principal": "*",
    "Action": ["s3:GetObject", "s3:PutObject"],
    "Resource": "arn:aws:s3:::my-app-bucket/*",
    "Condition": {
      "ArnEquals": {
        "aws:PrincipalArn": "arn:aws:iam::123456789012:role/my-app-lambda-role"
      }
    }
  }]
}

よくある落とし穴

ゲートウェイ型のルートテーブル設定漏れ

ゲートウェイエンドポイントを作成しても、Lambda が使うサブネットのルートテーブルに関連付けないと機能しない。プライベートサブネットのルートテーブルを確認する。

インターフェース型のセキュリティグループ

インターフェースエンドポイントの ENI にはセキュリティグループが必要だ。Lambda のセキュリティグループからエンドポイントの 443 ポートへのアウトバウンドを許可する。

インターフェース型のプライベート DNS が効いていない

インターフェースエンドポイントを作っても、エンドポイント側でプライベート DNS を有効にし、かつ VPC の DNS ホスト名と DNS 解決の両方が有効になっていないと、公開エンドポイント名 (sqs.ap-northeast-1.amazonaws.com 等) はエンドポイントの ENI に解決されない。SDK は既定で公開エンドポイント名を使うため、この条件が揃わないとコードを変えていないのに NAT ゲートウェイ経路のまま課金され続けたり、NAT ゲートウェイが無い構成ではタイムアウトしたりする。エンドポイント固有の DNS 名を SDK に直接指定する回避策もあるが、設定が散らばるのでプライベート DNS を有効にするほうが素直だ。

インターフェース型を 1 AZ にしか作らない

インターフェースエンドポイントは AZ ごとに ENI を作る構成で、時間料金も AZ 単位でかかる。1 AZ だけに作れば料金は抑えられるが、その AZ が損なわれると他の AZ のリソースまで対象サービスへ到達できなくなる。本番では 2 AZ 以上に ENI を置き、リージョン DNS 名 (公開エンドポイント名) でアクセスする構成が AWS の推奨である。

導入の判断基準

S3 と DynamoDB へアクセスするなら、追加料金のかからないゲートウェイ型を先に入れる。外す理由がほとんどない。
インターフェース型は宛先ごとに時間料金がかかるため、宛先の数と転送量で損得が変わる。東京リージョンでは NAT ゲートウェイ 1 台の時間料金が月 ~$45、インターフェースエンドポイントが 1 サービス 1 AZ で月 ~$10 なので、同じ AZ 数で比べると宛先が 5 種類前後を超えたあたりで時間料金の合計が逆転する。ただしデータ処理料金は $0.062/GB 対 $0.01/GB と差があるので、転送量が大きい構成ではエンドポイント側が有利になる。
料金より「プライベートサブネットからインターネットへの経路を無くしたい」という要件が主目的なら、比較の軸は到達範囲の制御になる。この場合はエンドポイントポリシーと合わせて設計する。

サイト情報