Amazon VPC

このページで押さえる論点

• ネットワークの分け方（パブリック／プライベートサブネット）と IP アドレス設計（CIDR の範囲 /16〜/28、サブネットごとに予約される 5 つの IP）
• ルーティング（ルートテーブル、local ルート、最も細かく一致する経路の優先）
• インターネットとの出入口（IGW、NAT ゲートウェイの AZ ごとの配置とコスト、IPv6 用の Egress-Only IGW）
• NAT インスタンスと NAT ゲートウェイの違い
• 通信の許可・拒否（セキュリティグループとネットワーク ACL、ポート・エフェメラルポート）
• 踏み台サーバーの代わりに使う Session Manager
• VPC フローログ（通信の記録）
• AWS サービスエンドポイントと外部ネットワークとの接続（VPN・Direct Connect の入口）

IP アドレス設計とサブネット

VPC はリージョン（AWS の地域単位）ごとに作り、使う IP アドレスの範囲を CIDR ブロック（例: 10.0.0.0/16。「/16」は先頭 16 ビットが固定という意味で、数字が大きいほど範囲は狭くなる）で決めます。VPC の中を、AZ（アベイラビリティゾーン: リージョン内の独立したデータセンター群）ごとのサブネットに区切って、EC2 やデータベースを配置します。

予約される 5 つの IP は、10.0.0.0/24 のサブネットなら次のとおりです。10.0.0.0（ネットワークアドレス）、10.0.0.1（VPC ルーター用）、10.0.0.2（DNS サーバー用）、10.0.0.3（将来の利用のため予約）、10.0.0.255（ブロードキャストアドレス。VPC はブロードキャストに対応していないため予約）。したがって /24（256 個）で使えるのは 251 個、最小の /28（16 個）では 11 個です。「サブネットに必要な台数が入るか」を問う問題では、この 5 つを引いて計算します。

サブネットは、インターネットに公開するものを置くパブリックサブネットと、公開しないものを置くプライベートサブネットに分けます。Web サーバーやロードバランサーはパブリック、アプリケーションサーバーやデータベースはプライベートに置くのが基本です（ネットワークのセグメンテーション: 役割ごとに区画を分けて、攻撃を受けうる範囲を狭くする考え方）。可用性のために、同じ役割のサブネットを複数の AZ に 1 つずつ作ります。

VPC ピアリングなどで別の VPC やオンプレミス（自社データセンター）とつなぐ予定があるなら、CIDR が重ならないように最初から設計しておきます。CIDR が重なる VPC 同士はピアリングできません。

ルートテーブルとルーティング

ルートテーブルは「宛先（送り先のアドレス範囲）」と「ターゲット（次に渡す相手）」の対応表です。各サブネットは、一度に 1 つのルートテーブルに関連付けられます。明示的に関連付けていないサブネットは、VPC 作成時にできるメインルートテーブルを使います。

複数のルートが当てはまるときは、最も細かく一致するルート（最長プレフィックス一致: /0 より /16、/16 より /24 のように範囲が狭いもの）が使われます。そのため「0.0.0.0/0 → NAT ゲートウェイ」があっても、S3 のアドレス範囲に一致するエンドポイントへのルートが優先されます。

つまり、サブネットが「パブリック」か「プライベート」かは、置いた場所ではなく、関連付けたルートテーブルに IGW へのルートがあるかどうかで決まります。

インターネットとの出入口: IGW・NAT ゲートウェイ・Egress-Only IGW

インターネットゲートウェイ（IGW）は VPC とインターネットをつなぐ玄関口です。VPC に一度にアタッチできる IGW は 1 つだけです。IGW は冗長化されて水平にスケールするため、可用性や帯域の心配はいりません。IGW 自体には料金がかからず、データ転送料金だけがかかります。EC2 が IGW 経由でインターネットと通信するには、ルートテーブルのルートに加えて、パブリック IP アドレスか Elastic IP アドレス（固定のパブリック IP）が必要です。

NAT ゲートウェイは、プライベートサブネットの EC2 が外へ出る通信だけを通す仕組みです。送信元のアドレスを NAT ゲートウェイの Elastic IP に付け替えて送ります（NAT: アドレス変換）。外から始まる通信は受け付けません。パブリックサブネットに置き、プライベートサブネットのルートテーブルから「0.0.0.0/0 → NAT ゲートウェイ」で参照します。

図では省いた、NAT ゲートウェイの配置と料金のポイントです。

• AZ ごとに置く: NAT ゲートウェイは作成した AZ の中でだけ冗長化されています。1 つを全 AZ で共有すると、その AZ が落ちたときに他の AZ のサブネットも外へ出られなくなります。AZ に依存しない構成にするには、AZ ごとに NAT ゲートウェイを作り、各 AZ のルートテーブルから同じ AZ のものを参照します。
• 料金: 使用可能な時間 1 時間ごとと、処理したデータ 1 GB ごとに課金されます。AZ をまたいで大量のトラフィックを送受信する場合は、リソースと同じ AZ の NAT ゲートウェイを使う（AZ ごとに作る）ことが推奨されています。
• AWS サービス宛ての通信: S3 や DynamoDB など VPC エンドポイントに対応したサービス宛ての通信が多いなら、エンドポイントを作ると NAT ゲートウェイのデータ処理料金を減らせます（VPC の接続で解説）。
• 帯域: 5 Gbps から始まり、100 Gbps まで自動で拡張されます。

IPv6 では事情が違います。IPv6 アドレスはすべてグローバルに一意で、既定でパブリックなアドレスです。「外へは出られるが、外から通信を始められない」ようにするには、NAT ではなく Egress-Only インターネットゲートウェイを使います。IPv6 専用・ステートフル（出た通信の応答は戻れる）で、ゲートウェイ自体に料金はかかりません。IPv4 の外向き専用通信には、これまでどおり NAT ゲートウェイを使います。

NAT ゲートウェイと NAT インスタンスの違い

NAT の役割は、NAT 用に設定した EC2 インスタンス（NAT インスタンス）でも担えます。試験では「運用負荷」「可用性」「コスト」の観点で比べる問題が出ます。

NAT インスタンスは、自分宛てでない通信を中継するため、EC2 の「送信元/送信先チェック」（自分が送信元か宛先の通信だけを扱う既定の動作）を無効にする必要があります。また、NAT インスタンス用の AMI（NAT AMI）はサポートが終了しており、AWS は NAT ゲートウェイへの移行を推奨しています。試験で「運用負荷を最小に」「高可用性」と書かれていれば NAT ゲートウェイを選びます。

セキュリティグループとネットワーク ACL

VPC には通信を絞る仕組みが 2 段階あります。サブネットの出入口でチェックするネットワーク ACLと、EC2 などのネットワークインターフェースごとにチェックするセキュリティグループです。

ステートレスの NACL で注意したいのが「戻りの通信」です。Web サーバーへの行きは 443 番ポート宛てですが、戻りはクライアント側が一時的に使うポート（エフェメラルポート）宛てになります。範囲は OS などで異なり（多くの Linux は 32768〜61000、Windows Server 2008 以降は 49152〜65535、ELB・NAT ゲートウェイ・Lambda は 1024〜65535）、さまざまなクライアントを受け付けるなら 1024〜65535 を許可します。NACL のアウトバウンドでこの範囲を許可しないと、行きは届いても応答が返りません。

図では省いた送信元の指定について補足します。SG のルールでは送信元に別のセキュリティグループを指定できます。たとえば DB の SG で「App サーバーの SG からの 3306 番だけ許可」とすれば、App サーバーが Auto Scaling で増減して IP アドレスが変わっても、ルールを直す必要がありません。一方、「特定の IP アドレスからの通信を遮断したい」ときは、拒否ルールを書ける NACL を使い、拒否ルールを許可ルールより小さい番号にします。

踏み台サーバーの代わりに Session Manager

プライベートサブネットの EC2 にログインするには、従来はパブリックサブネットに踏み台サーバー（外から SSH で入り、そこから内側へ入り直すための EC2）を置いていました。しかし、踏み台には SSH ポートの公開、SSH キーの管理、踏み台自体のパッチ適用という手間とリスクがあります。

AWS Systems Manager の Session Manager を使うと、次のようにしてインスタンスを操作できます。

• インバウンドのポートを開けず、踏み台サーバーも SSH キーも不要
• 誰が接続できるかを IAM ポリシーで一元管理
• 操作ログを S3 や CloudWatch Logs に保存でき、API の呼び出しは CloudTrail に記録される
• Systems Manager 用の VPC エンドポイント（PrivateLink）を作れば、パブリック IP を持たずインターネットに出られないインスタンスにも接続できる

「SSH ポートを開けずに」「踏み台を管理せずに」「操作を監査したい」という要件なら Session Manager を選びます。

VPC フローログ

VPC フローログは、ネットワークインターフェースを出入りする IP 通信の情報（送信元・宛先・ポート、許可されたか拒否されたか など）を記録する機能です。「通信が届かない原因を調べたい」「どこからアクセスがあったか記録したい」という場面で使います。

SG や NACL で拒否された通信は REJECT として記録されるため、「どちらで弾かれているか」の切り分けに使えます。API の操作履歴を記録する CloudTrail とは記録する対象が違う点に注意します。

AWS サービスや外部ネットワークとの接続

VPC の外とつなぐ方法は、相手によって選びます。詳しくは VPC の接続 で解説します。

• S3 や DynamoDB などの AWS サービス: VPC エンドポイントを使うと、インターネットや NAT ゲートウェイを通らずにアクセスできる
• 別の VPC: 1 対 1 なら VPC ピアリング（推移的なルーティング不可）、多数なら Transit Gateway
• オンプレミス: インターネット上の暗号化トンネルの Site-to-Site VPN（すぐ使える・安い）か、専用線の Direct Connect（帯域と遅延が安定・開通に時間がかかる）

問題文のキーワード → 選ぶべき答え

引っかけポイント

• 「セキュリティグループに拒否ルールを追加してブロックする」→ ✕。SG は許可ルールのみ。拒否は NACL で書く
• 「NAT ゲートウェイをプライベートサブネットに作成する」→ ✕。NAT ゲートウェイはパブリックサブネットに置き、プライベートサブネットのルートテーブルから参照する
• 「NAT ゲートウェイを 1 つ作れば AZ 障害にも耐えられる」→ ✕。冗長なのはその AZ の中だけ。AZ ごとに作る
• 「NAT ゲートウェイにセキュリティグループを付けて通信を絞る」→ ✕。NAT ゲートウェイには SG を関連付けできない。サブネットの NACL か、背後の EC2 の SG で制御する
• 「/24 のサブネットには 256 台の EC2 を置ける」→ ✕。5 つの IP が予約されるので使えるのは 251 個
• 「NACL で 443 番のインバウンドを許可すれば応答も返る」→ ✕（自分で作った NACL の場合）。ステートレスなのでアウトバウンドでエフェメラルポートの許可も必要
• 「IPv6 の外向き専用通信に NAT ゲートウェイを使う」→ ✕。IPv6 の外向き専用には Egress-Only IGW。NAT ゲートウェイは IPv4 用
• 「通信の許可・拒否の記録を CloudTrail で調べる」→ ✕。CloudTrail は API 操作の記録。IP 通信の記録は VPC フローログ

まとめ: SAA 試験で押さえるポイント

• パブリックサブネット = ルートテーブルに「0.0.0.0/0 → IGW」がある。EC2 がインターネットと通信するにはパブリック IP（または Elastic IP）も必要
• VPC・サブネットの CIDR は /16〜/28。各サブネットで 5 つの IP が予約される。ピアリングの予定があれば CIDR を重ねない
• プライベートサブネットから外へ出るだけなら NAT ゲートウェイ（パブリックサブネットに置く）。外から始まる通信は受け付けない。IPv6 なら Egress-Only IGW
• NAT ゲートウェイは 1 つの AZ の中で冗長化されている。AZ 障害に備えるなら AZ ごとに NAT ゲートウェイを置き、各 AZ のルートテーブルから同じ AZ の NAT GW を指す
• NAT インスタンスは自前管理（パッチ・フェイルオーバー・送信元/送信先チェックの無効化）。運用負荷と可用性では NAT ゲートウェイが有利
• セキュリティグループ（SG）はステートフル・許可ルールのみ・インスタンス単位。ネットワーク ACL（NACL）はステートレス・許可と拒否・番号順評価・サブネット単位
• 「特定の IP アドレスをブロックしたい」→ 拒否ルールを書ける NACL。SG には拒否ルールがない
• SG のルールでは、送信元に別の SG を指定できる（例: DB の SG は「Web の SG からの 3306 番だけ許可」）
• 踏み台サーバーの代わりは Session Manager。通信の記録は VPC フローログ
• S3 や DynamoDB へインターネットを通らずにアクセスするには VPC エンドポイント（ゲートウェイ型）を使う