AWS 認定資格 ラボ
SAA（Solutions Architect Associate）攻略 ・

SAA VPC 設計問題の頻出パターン10選｜サブネット・SG/NACL・エンドポイント・TGW を要件文で即断する

AWS SAA-C03 で VPC は最頻出のネットワークテーマ。本記事は VPC 設計問題を「パブリック／プライベートのサブネット分割／NAT Gateway の配置とマルチAZ／Security Group と Network ACL の使い分け／VPC エンドポイント（Gateway 型・Interface 型）／VPC Peering と Transit Gateway／Direct Connect と Site-to-Site VPN／ルートテーブル設計／VPC Flow Logs／IGW と Elastic IP／マルチAZ 高可用性」の頻出10パターンに分解する。各パターンで「要件文のどのキーワードが正解を一意に決めるか」を示し、本番のシナリオでそのまま選択肢を絞れる粒度まで落とす。結論は「VPC 問題はサービス名の暗記ではなく、通信の向き・境界・経路・冗長という4つの評価軸で解く」こと。

#AWS #SAA #SAA-C03 #Solutions Architect #VPC #サブネット #セキュリティグループ #Transit Gateway #試験対策 #AWS認定資格

VPC の設計問題を「どのサービスを使うか」で解こうとすると、SG・NACL・エンドポイント・ピアリングの細かな違いに溺れる。 SAA-C03 で Amazon VPC は、単一テーマとしては最も出題頻度が高いネットワーク領域だ。だが出題は「VPC の仕様暗記」ではなく、通信の向き・境界の粒度・接続の経路・冗長性という4つの評価軸のどれが要件文で問われているかを読み取れるかを試してくる。攻略の鍵は、頻出テーマを「サブネット設計」「境界防御（SG/NACL）」「プライベート接続（エンドポイント）」「VPC 間・オンプレ接続」「可観測性・可用性」の5系統×10パターンに畳み、要件文のキーワードから正解を一意に引く反射を作ること。本記事では、SAA 本番でそのまま選択肢を絞れる粒度で、VPC 設計問題の頻出10パターンを分解する。読み終えれば、「最もセキュアで可用性が高く、要件を満たす構成はどれか」という問いに、迷わず正解を当てられるようになる。

※ 本記事はアフィリエイト広告（Amazon アソシエイト等）を含みます

📑 目次

  1. 結論：VPC 問題は「サービス名」ではなく「4つの評価軸」で解く
  2. パターン1〜3：サブネット分割・NAT・境界防御
  3. パターン4〜5：プライベート接続と VPC エンドポイント
  4. パターン6〜7：VPC 間接続とオンプレ接続
  5. パターン8〜10：ルーティング・可観測性・可用性
  6. 頻出ひっかけパターンと打ち手の整理
  7. 次のアクション チェックリスト
  8. 関連記事
  9. 関連サイト

1. 結論：VPC 問題は「サービス名」ではなく「4つの評価軸」で解く

SAA-C03 の VPC 問題を最短で解く骨格は、**「要件文が4つの評価軸——通信の向き・境界の粒度・接続の経路・冗長性——のどれを問うているかを特定し、その軸で選択肢を振るう」**ことだ。これが本記事の結論である。

理由は明快で、VPC の構成要素はどれも「ある評価軸を制御するための道具」だからだ。ルートテーブルは「通信の経路（どこへ出るか）」を、Security Group と Network ACL は「境界の粒度（インスタンス単位か、サブネット単位か）」を、VPC エンドポイントは「経路をインターネットから隔離するか」を、NAT Gateway のマルチAZ 配置は「冗長性」を担う。つまり要件文のキーワードが軸を指し示し、軸が正解の機能を一意に決める構造になっている。

具体例で見よう。「プライベートサブネットの EC2 からインターネットへアウトバウンドだけ許可したい」——これは通信の向き（外向き）の軸だから NAT Gateway が正解だ。「特定 IP からのアクセスを明示的に拒否したい」——境界で deny が要る軸だから Network ACL（SG は deny を書けない）。「VPC 内の EC2 から S3 にインターネットを経由せずアクセス」——経路を隔離する軸だから Gateway 型 VPC エンドポイント。ここで「どのサービスが高機能か」と機能の優劣で考えると誤答する。軸で解く——この一点が VPC 問題の攻略法だ。

2. パターン1〜3：サブネット分割・NAT ゲートウェイ・境界防御

最も出題頻度が高いのが、この3パターンだ。ここは VPC 問題の“主砲”であり、確実に得点したい。

パターン1：パブリック／プライベートサブネットの分割

VPC 設計の基本は、サブネットを「インターネットゲートウェイ（IGW）へのルートを持つか」で二分することだ。パブリックサブネットは IGW へのルートを持ち、Web サーバーやロードバランサーを配置する。プライベートサブネットは IGW へのルートを持たず、アプリケーションサーバーや RDS などのデータベースを隔離する。SAA の三層アーキテクチャ問題では、**「DB は必ずプライベートサブネット」「公開が必要なものだけパブリック」**が鉄則になる。

パターン2：NAT ゲートウェイの配置とマルチAZ 冗長化

「プライベートサブネットの EC2 から、インターネットへアウトバウンド通信だけさせたい（インバウンドは受けない）」——これは NAT Gateway が正解だ。ここで押さえるべき2つの罠がある。

  • NAT Gateway は必ずパブリックサブネットに置く：プライベートサブネットに置く選択肢はひっかけ。NAT 自身が IGW 経由で外に出る必要があるためだ。
  • マルチAZ では AZ ごとに NAT Gateway を置く：1つの AZ にだけ NAT を置くと、その AZ 障害時に他 AZ のプライベートサブネットが外に出られなくなる。可用性要件があれば 各 AZ に NAT Gateway ＋各 AZ のルートテーブルを自 AZ の NAT に向ける構成が正解になる。

パターン3：Security Group と Network ACL の使い分け

VPC の境界防御は、**「粒度」と「deny の要否」**で SG と NACL を切り分ける。ここは SAA で最も頻繁に問われる VPC トピックだ。

Security Group vs Network ACL（要件キーワード → 正解）
評価項目
Security Group 推奨
Network ACL
適用単位 インスタンス（ENI）単位 サブネット単位
ステート ステートフル（戻りは自動許可） ステートレス（戻りも明示）
ルール 許可（allow）のみ 許可＋拒否（deny）
評価 全ルールを評価 番号順に最初に一致したルール
キーワード 「インスタンスごとに制御」「戻り通信も通したい」 「特定 IP を明示的にブロック」「サブネット全体で遮断」
迷ったら『インスタンス単位・許可だけ＝SG』『サブネット単位・特定 IP を拒否したい＝NACL』の2点で振るう。

3. パターン4〜5：プライベート接続と VPC エンドポイント

「インターネットに出さずに AWS サービスへ接続したい」——セキュア設計ドメインの主役がこの2パターンだ。

パターン4：Gateway 型 VPC エンドポイント（S3・DynamoDB）

「VPC 内の EC2 から、インターネットを経由せず同一リージョンの S3 にアクセスしたい」——これは Gateway 型 VPC エンドポイントが正解だ。ルートテーブルにエンドポイント宛のルートが追加され、通信が AWS 内部で完結する。NAT Gateway 経由のインターネット通信を避けられる上に、NAT の転送料金も不要になる（コスト面でも有利）。ここで押さえる区別が **「Gateway 型は S3 と DynamoDB の2つだけ」**という点。他のサービスは次のパターン5（Interface 型）になる。

S3・DynamoDB 以外の AWS サービス（例：SSM、KMS、CloudWatch、ECR など）へプライベート接続したい場合は、**Interface 型 VPC エンドポイント（PrivateLink）**を使う。サブネット内に ENI（プライベート IP）が作られ、そこ経由でサービスに到達する。自社サービスを他 VPC・他アカウントへプライベート公開する場合も PrivateLink だ。

4. パターン6〜7：VPC 間接続とオンプレ接続

パターン6：VPC Peering と Transit Gateway の使い分け

複数 VPC をつなぐとき、**「VPC の数」と「推移的ルーティングの要否」**で道具が変わる。

VPC Peering vs Transit Gateway（要件キーワード → 正解）
評価項目
VPC Peering
Transit Gateway 推奨
接続形態 1対1（フルメッシュ） ハブ&スポーク（中央集約）
推移的ルーティング 不可（A-B-C で A→C 不可） 可能（ハブ経由で全 VPC 疎通）
スケール N 個で N(N-1)/2 本の接続 N 個で N アタッチメント
SG 参照 ピア VPC の SG を参照可 CIDR ベースのみ
キーワード 「2〜数個の VPC」「低コスト」 「多数の VPC を集約」「オンプレも含めハブ化」
迷ったら『少数の VPC を直結＝Peering』『多数の VPC＋オンプレを中央集約＝Transit Gateway』で振るう。

パターン7：オンプレ接続（Direct Connect と Site-to-Site VPN）

オンプレミスと VPC をつなぐ問題は、**「帯域の安定性・専有性」と「コスト・構築スピード」**のトレードオフで解く。

  • 一貫した低レイテンシ・大帯域・専有線が必要 → Direct Connect：物理専用線。安定性が高いが構築に時間とコストがかかる。「安定したパフォーマンス」「大量データ転送」「一貫した帯域」がキーワード。
  • 短期・低コスト・すぐ繋ぎたい → Site-to-Site VPN：インターネット経由の暗号化トンネル。すぐ構築でき安いが、インターネット品質に依存。
  • 両者の組み合わせ：Direct Connect を主、VPN をバックアップにする冗長構成が「高可用性かつ安定帯域」の要件で正解になる。

5. パターン8〜10：ルーティング・可観測性・可用性

パターン8：ルートテーブル設計

VPC の通信経路は ルートテーブルが決める。「サブネットがパブリックかプライベートか」は、ルートテーブルに 0.0.0.0/0 → IGW があるかどうかで決まる。よくある設計問題は「あるサブネットの EC2 が外に出られない」というトラブルで、原因は多くが「ルートテーブルに IGW（またはプライベートなら NAT）へのデフォルトルートがない」こと。最長プレフィックス一致（より具体的な CIDR が優先）のルールも、VPC Peering やエンドポイント併用時の経路判定で問われる。

パターン9：VPC Flow Logs による可観測性

「VPC 内の通信が SG／NACL のどこで拒否されているか調べたい」「不審なトラフィックを監視・監査したい」——これは VPC Flow Logs が正解だ。ENI 単位・サブネット単位・VPC 単位で送受信の IP／ポート／許可・拒否（ACCEPT/REJECT）を記録し、CloudWatch Logs や S3 に出力する。**「接続性トラブルの切り分け」「セキュリティ監査」「通信の可視化」**がキーワード。Flow Logs は通信のメタデータ（ヘッダ情報）を記録するもので、パケットの中身は取らない点も押さえておこう。

パターン10：マルチAZ を前提とした高可用性 VPC 設計

VPC 設計の総仕上げが可用性だ。単一障害点（SPOF）を作らないのが原則で、①各 AZ にサブネットを用意し、②ロードバランサーを複数 AZ にまたがせ、③Auto Scaling で複数 AZ に EC2 を分散し、④NAT Gateway も AZ ごとに冗長化する。高可用性設計パターンの Web 三層黄金構成は、この VPC 設計の上に成り立つ。「単一 AZ 障害でもサービス継続」が要件なら、上記4点がすべて複数 AZ になっている選択肢を選ぶ。

6. 頻出ひっかけパターンと打ち手の整理

VPC 問題は、正しい打ち手と“やりがちな誤答”が明確に対になっている。表で押さえれば本番で機械的に振るえる。

7. 次のアクション チェックリスト

VPC 設計パターンを、今日からの学習に落とし込むための具体アクションをまとめる。

8. 関連記事

9. 関連サイト

AWS 公式