NATを使わずに、プライベートサブネットからS3へ届ける

手順に迷ったときや、用語の意味を確かめたいときに開きましょう。

※ リンク切れの場合は、ページタイトルで検索してください。

同じ EC2・同じプライベートサブネットのまま、ルートテーブルにS3用のゲートウェイエンドポイントを追加する前後で、S3への到達性がどう変わるかを比較します。

※ インターネットゲートウェイやNATゲートウェイは、どちらの状態でも使いません。

以下の要件を満たし、「届かない」→「エンドポイント追加」→「届く」という変化を確認してください。

「届かない状態を確認する」→「エンドポイントを追加する」→「届くようになることを確認する」という順番で進めます。

1. フェーズ1 — プライベートサブネットとEC2を用意する

2. マネジメントコンソールにサインインし、リージョンを合わせる

   ブラウザで AWS マネジメントコンソールにサインインし、画面右上のリージョンが「アジアパシフィック（東京）ap-northeast-1」になっていることを確認します。

3. プライベートサブネットを用意する

   VPC コンソールで、インターネットゲートウェイへのルートも、NATゲートウェイへのルートも持たないサブネットを1つ用意します（既存のVPCに新しいサブネットを追加するか、新しいVPCを作成して進めます）。

4. Systems Manager 用の IAM ロールを作成する

   IAM コンソールで、EC2 用の信頼関係を持つロールを作成し、管理ポリシーAmazonSSMManagedInstanceCoreをアタッチします。

5. Session Manager 用のインターフェースエンドポイントを3つ作成する

   VPC コンソールの「エンドポイント」から、com.amazonaws.ap-northeast-1.ssm、ssmmessages、ec2messages の3つを、タイプ「インターフェース」でプライベートサブネットに作成します。セキュリティグループは、VPC内からのHTTPS（443）を許可するものを指定します。

   Session Manager接続用の準備

   この3つのエンドポイントは、プライベートサブネットのEC2にSession Manager経由で接続するための準備です。S3への到達性とは別の目的なので、混同しないようにしましょう。

6. EC2 インスタンスを起動する

   EC2 コンソールで、名前に s3-endpoint-demo、AMI に Amazon Linux 2023、インスタンスタイプに無料利用枠の対象（例：t3.micro）を選び、手順2のプライベートサブネットに、手順3のIAMロールをアタッチして起動します。パブリックIPは割り当てません。

7. フェーズ2 — 「届かない」状態を確認する

8. テスト用のS3バケットを作成する

   S3 コンソールで、バケットを1つ作成します（名前は一意に、例：endpoint-demo-yourname）。設定はデフォルトのままで構いません。

9. Session Manager で EC2 に接続する

   ローカルの PowerShell から、インスタンスIDを指定して接続します。

   PowerShell

   aws ssm start-session --target <インスタンスID>

10. S3への到達性がない状態を確認する

    接続したシェルの中で、S3バケットの一覧を取得しようとします。

    EC2 インスタンス内（Session Manager経由）

    # タイムアウトして失敗するはず
    aws s3 ls

    しばらく応答がなければ想定どおり

    コマンドが固まったまま応答がない、または一定時間後にタイムアウトエラーになれば、これが「届かない」状態です。インターネットへの経路もS3への経路も持たないため、この結果は想定どおりです。Ctrl + C で中断して構いません。

11. フェーズ3 — ゲートウェイエンドポイントを追加する

12. S3用のゲートウェイエンドポイントを作成する

    VPC コンソールの「エンドポイント」で「エンドポイントを作成」を選び、サービスカテゴリに「AWSサービス」、サービス名に com.amazonaws.ap-northeast-1.s3（タイプがGatewayのもの）を選びます。VPCを選び、ルートテーブルの一覧から、プライベートサブネットに関連付けられているルートテーブルにチェックを入れて作成します。

    同じ「s3」でも2種類ある

    サービス名の一覧に、タイプが「Gateway」のものと「Interface」のものが両方表示される場合があります。今回使うのはGatewayタイプのほうです。ルートテーブルへの追加が必要なのはGatewayタイプの特徴です。

13. フェーズ4 — 「届く」ようになったことを確認する

14. もう一度 aws s3 ls を実行する

    Session Manager のシェルに戻り（切れていた場合は再接続し）、同じコマンドをもう一度実行します。

    EC2 インスタンス内（Session Manager経由）

    # 今度はバケット一覧が表示されるはず
    aws s3 ls
    
    # 作成したバケットの中身も見てみる
    aws s3 ls s3://<作成したバケット名>

    これがゴール

    さきほど失敗した同じコマンドが、今度はバケットの一覧を返す——この変化を確認できたら、このハンズオンの目的は達成です。

初学者がよく引っかかる箇所を先回りでまとめました。答えそのものは載せていませんが、「どこを見直せばよいか」の手がかりとして使ってください。

要件の再確認ではなく、画面・コマンドのどこを見れば達成を確認できるかをまとめました。次を順に確かめましょう。

• VPCコンソールの「エンドポイント」一覧に、タイプGatewayのS3用エンドポイントが「使用可能」な状態で表示されている。
• プライベートサブネットのルートテーブルに、S3向けのプレフィックスリストを宛先とするルートが追加されている。
• エンドポイント追加前は aws s3 ls が失敗（タイムアウト）し、追加後はバケット一覧が表示される。
• aws s3 ls s3://<バケット名> で、バケットの中身が確認できる。

手を動かすことに加えて、次の問いに自分の言葉で答えられるようにしておくと、理解がより深まります。

1. NATゲートウェイ経由でS3にアクセスする方法と、ゲートウェイ型エンドポイントを使う方法では、データの流れる経路にどんな違いがあるでしょうか。
   ヒント

   NATゲートウェイを経由する場合、データは一度インターネットゲートウェイの方向に向かいます。ゲートウェイエンドポイントの場合、AWSのネットワークの中だけで完結します。この違いが、料金や安全性にどう影響しそうか考えてみましょう。
2. S3用のゲートウェイエンドポイントがあれば、他のサービス（例えばインターネット上の外部API）へのアクセスも不要になるのでしょうか。
   ヒント

   ゲートウェイエンドポイントは、対応している特定のサービス（S3やDynamoDBなど）専用の経路です。S3以外の汎用的なインターネットアクセスが必要な場面では、別の手段が必要になる、という観点で考えてみましょう。
3. 本番運用で、プライベートサブネットのEC2が複数のAWSサービスにアクセスする必要がある場合、NATゲートウェイとゲートウェイ・インターフェースエンドポイントをどのように組み合わせるとよさそうでしょうか。
   ヒント

   使う頻度が高く、対応するエンドポイントがあるサービス（S3など）はエンドポイント経由にし、それ以外の汎用的な通信のためにNATゲートウェイを残す、という分担の考え方がヒントです。

作成したリソースを順番に削除します。

1. S3バケットを空にして削除する：バケットの中のオブジェクトをすべて削除してから、バケット本体を削除します。
2. EC2インスタンスを終了する：EC2コンソールで s3-endpoint-demo を選び、終了します。
3. VPCエンドポイントを削除する：S3用のゲートウェイエンドポイント、および Session Manager 用の3つのインターフェースエンドポイントをすべて削除します。
4. IAMロールを削除する：作成したロールを削除します。