【入門編】ゲートウェイ型VPCエンドポイント(Amazon S3/DynamoDB)のルーティングとポリシー制御 – クラウドインフラと仮想化ネットワーク実践ガイド

こんにちは！SREとして日々クラウドのインフラやネットワークの海を泳いでいる私ですが、AWSを触り始めた頃は「パブリック？プライベート？え、じゃあプライベートなサブネットからどうやってS3に安全にアクセスするの？」と頭を悩ませたものです。

インターネットに出るためのゲートウェイ（IGW）を通らないのに、AWSのストレージであるAmazon S3やNoSQLデータベースのDynamoDBにアクセスできる……。なんだか魔法のようですよね。

今回は、この「ゲートウェイ型VPCエンドポイント」の仕組みについて、現実世界の郵便配達にたとえながら、一歩ずつ優しく紐解いていきましょう！

—

1. そもそも「プライベートサブネットからのS3アクセス」ってどういうこと？

私たちがAWS上でシステムを作るとき、セキュリティを高めるために「プライベートサブネット」という、直接インターネットから見えない安全な領域にサーバー（EC2など）を配置することがよくあります。

ここで、よくあるこんな疑問が浮かびますよね。
「このプライベートなサーバーから、画像ファイルを保存するためにAmazon S3へアクセスしたい！でも、パブリックIPアドレスは持たせていないし、インターネットゲートウェイ（IGW）も繋ぎたくない……どうすればいいの？」

ここで登場するのが、ゲートウェイ型VPCエンドポイントです。

現実世界でたとえてみよう：社内専用の「秘密の地下通路」

想像してみてください。あなたの会社（VPCのプライベートサブネット）から、巨大な倉庫（Amazon S3）へ荷物を送りたいとします。

通常のルート（インターネット経由）：

会社からいったん一般道（パブリックインターネット）に出て、赤信号をいくつも通り、不特定多数の人がいる大通りを通って倉庫へ向かいます。これではセキュリティ上、少し不安ですよね。

ゲートウェイ型VPCエンドポイントのルート：

会社から倉庫へ向けて、「AWSの敷地内だけを通る、社内専用の秘密の地下通路」をぽっかりと開通させます。一般道に出る必要がないので、安全で、しかも渋滞知らずです！

この「秘密の地下通路」こそが、ゲートウェイ型VPCエンドポイントの正体なんです。

—

2. 郵便配達の仕組みで理解する「ルートテーブル」と「プレフィックスリスト」

では、この秘密の地下通路を通るには、どうやって道を教えればいいのでしょうか？ここでカギになるのが、ルートテーブルとプレフィックスリストです。

宛先リスト（プレフィックスリスト）の正体

AWSのS3やDynamoDBには、世界中に数多くのサーバーが存在し、そのIPアドレスも刻一刻と変化しています。「このIPアドレス宛の荷物はこの道へ」と一つずつ手動で書くのは不可能です。

そこでAWSは、S3宛ての荷物が通るべきIPアドレスのまとまりをプレフィックスリスト（例：pl-xxxxxxxx のようなIDで表されるもの）という「宛先リスト」として提供してくれています。

ルートテーブルの魔法

プライベートサブネットの「ルートテーブル（地図のようなもの）」に、次のような設定を書き込みます。

> 「もし pl-xxxxxxxx（S3の宛先リスト）宛ての荷物を見つけたら、インターネットゲートウェイではなく、VPCエンドポイント（秘密の地下通路）へ投げなさい！」

この設定をしておくだけで、サーバーが意識することなく、自動的に安全な地下通路へと荷物がルーティングされる仕組みになっています。しかも、このゲートウェイ型エンドポイントの利用料金は無料（データ転送量もVPC内扱いなので追加のコストがかからないことが多い）という、インフラエンジニアにとって涙が出るほど嬉しい特徴があります。

—

3. 実践！AWS CLIでゲートウェイ型VPCエンドポイントを作ってみよう

百聞は一見にしかず。実際にTerraformやAWS CLIを使って、このエンドポイントを構築するイメージを持ってみましょう。今回は手軽に確認できるAWS CLIのコマンドを例に見ていきます。

実務でそのまま参考にできるよう、丁寧なコメントを添えておきますね。

# =================================================================
ニッチだけど非常に重要なポイント：
VPCエンドポイントを作成する際は、「どのVPCに」「どのサービスに」「どのルートテーブルを紐付けるか」を正確に指定する必要があります。
=================================================================

# 1. ゲートウェイ型VPCエンドポイントをAmazon S3向けに作成する
aws ec2 create-vpc-endpoint \
    --vpc-id vpc-0123456789abcdef0 \
    --service-name com.amazonaws.ap-northeast-1.s3 \
    --route-table-ids rtb-0123456789abcdef0 \
    --tag-specifications 'ResourceType=vpc-endpoint,Tags=[{Key=Name,Value=s3-gateway-endpoint}]'

これだけで、指定したルートテーブル（rtb-0123456789abcdef0）に、S3宛てのトラフィックをエンドポイントへ向けるルールが自動的に追加されます！

—

4. エンドポイントポリシーで「誰が・どこまでアクセスできるか」を制御する

「地下通路を作ったはいいけれど、社内の誰でもかれでもが勝手に倉庫の奥まで自由に出入りできたら困るよね？」
そんなときに使うのが、エンドポイントポリシーです。

VPCエンドポイントには、IAMポリシーに似たJSON形式のアクセスコルセットを設定できます。これによって、「特定のS3バケット以外へのアクセスは一切禁止する！」といった強力なガードレールを設けることができます。

エンドポイントポリシーの設定例（JSON）

以下のサンプルは、「特定のバケット（my-secure-company-bucket）に対する読み書き（s3:GetObject, s3:PutObjectなど）だけを許可し、それ以外の操作や他のバケットへのアクセスをすべて遮断する」という実用的な設定です。

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

このようにポリシーを適用しておけば、万が一プライベートサブネット内のサーバーが意図しない外部スクリプトに汚染されたとしても、このエンドポイントを経由して社外の不正なS3バケットへデータを持ち出すような「データexfiltration（データ持ち出し）」を防ぐことができます。セキュリティの要として、非常に強力ですね！

—

5. まとめと現場からのアドバイス

今回は、クラウドインフラの基本でありながら非常に重要な「ゲートウェイ型VPCエンドポイント」について解説しました。

ポイントのおさらい

1. インターネットゲートウェイを通らずにS3やDynamoDBに安全にアクセスできる「秘密の地下通路」。
2. ルートテーブルとプレフィックスリストの組み合わせで、パケットが自動的に専用ルートへ導かれる。
3. 追加料金がかからず、エンドポイントポリシーでアクセス先を厳格に制限できるため、セキュリティ面でも必須の機能。

初学者のうちは「ルーティング？エンドポイント？名前が難しそう……」と感じてしまうかもしれませんが、身の回りの郵便配達や専用道路に置き換えて考えると、すんなり頭に入ってきますよね。

実際の現場でも、プライベートサブネットからS3を安全に利用する設計では「まずゲートウェイ型VPCエンドポイントを置く」のがデファクトスタンダード（事実上の標準）です。ぜひ今回の仕組みを頭に置いて、ご自身のAWS環境でもハンズオンで試してみてくださいね。

それでは、また次回のインフラ解説でお会いしましょう！SREチームの主筆ライターより、愛を込めて。