Amazon VPC (Virtual Private Cloud)

は、AWS 上に論理的に分離された仮想ネットワークを作るサービスです。、、、、 Gateway、、ネットワークなどを組み合わせて、AWS リソースの通信経路を設計します。

SAA では、VPC はほぼすべてのネットワーク設計問題の土台です。特に、との違い、インターネットへのアウトバウンド通信、障害時の影響範囲、VPC や NAT Gateway の使い分けがよく問われます。

Point

VPC = Virtual Private Cloud の略です。
Virtual は「仮想の」、Private は「専用・非公開の」、Cloud は「クラウド」という意味です。
試験では「AWS 内に作る自分専用のネットワーク範囲」と考えると理解しやすいです。
和訳
- Virtual: 仮想の
- Private: 私的な、専用の
- Weblio英和辞書「private」

概要

では、まずアドレス範囲をで決め、その中にを作ります。サブネットは 1 つのに属するため、複数 AZ にアプリケーションを分散したい場合は、AZ ごとにサブネットを作ります。

サブネットがパブリックかプライベートかは、名前ではなくで決まります。への直接ルートがあるサブネットは、直接ルートがないサブネットはとして扱います。

試験では、をどのサブネットに置くか、外部からのインバウンドを許すか、外部へのアウトバウンドだけを許すか、AWS サービスへプライベートに到達したいかを読み分けます。

主要技術

①CIDR、サブネット、AZ

はやのアドレス範囲を表します。VPC の CIDR を大きく取り、その中を用途やごとにサブネットへ分割します。サブネットは 1 つの AZ の中にだけ存在し、複数 AZ をまたぐことはできません。

設計要素	役割	SAA での判断ポイント
VPC CIDR	VPC 全体の IP アドレス範囲	や他 VPC と重複しないように設計します。
サブネット CIDR	AZ 内のリソース配置範囲	パブリック、プライベート、用途別に分割します。
AZ	障害分離の単位	可用性を高めるには複数 AZ に分散します。
	サブネットの送信先を決める表	サブネット種別や外向き通信の可否を決めます。

⚠️ 頻出: サブネットは全体ではなく 1 つの AZ に属します。複数 AZ 構成では、各 AZ に必要なサブネットを作る前提で考えます。

サブネットの IPv4 CIDR は /16〜/28 の範囲で指定します。各サブネットの先頭 4 つと末尾 1 つの IP アドレスは AWS が予約するため、リソースには割り当てられません。たとえば /28（16 個）で使えるのは 11 個、/27（32 個）では 27 個です。

作成済みの VPC やサブネットの CIDR は拡大も縮小もできません。アドレスが足りなくなったら、VPC にセカンダリ IPv4 CIDR ブロックを追加し、その範囲に新しいサブネットを作ります。追加した CIDR への local の経路はルートテーブルへ自動で入ります。VPC を作成したときのプライマリ CIDR は削除できません。

②パブリックサブネットとプライベートサブネット

は、にへのルートを持つです。外部から直接アクセスさせる、踏み台、 Gateway などを配置します。

は、インターネットゲートウェイへの直接ルートを持たないサブネットです。アプリケーションサーバーやデータベースなど、外部から直接到達させたくないリソースを配置します。

サブネット種別	代表的な配置先	インターネットとの関係
パブリックサブネット	、NAT Gateway、踏み台など	IGW へのルートを持ち、必要に応じてパブリックを使います。
プライベートサブネット	アプリケーション、、内部サービス	IGW へ直接出さず、NAT Gateway やを使います。
isolated サブネット	外部通信を避ける DB や内部処理	VPC 外へのルートを持たせません。

パブリック IP を持つだけでは十分ではなく、ルートテーブル、インターネットゲートウェイ、、ネットワークがそろって通信できます。逆に、プライベートサブネットの EC2 は、パブリック IP を持たせず、必要な外向き通信だけを別の経路で許可する設計がよく出ます。

③インターネットゲートウェイと NAT Gateway

は、とインターネットを接続するための VPC コンポーネントです。ので 0.0.0.0/0 をインターネットゲートウェイへ向けると、インターネット向け IPv4 通信の経路になります。

Gateway は、内のリソースがインターネットへアウトバウンド通信するために使います。外部からプライベートサブネット内のへ直接開始される通信は許しません。パッチ取得、外部呼び出し、パッケージ更新などでよく使います。

パブリック NAT Gateway は、インターネットゲートウェイへの経路を持つパブリックサブネットに作成します。NAT Gateway をプライベートサブネットに作ると、NAT Gateway 自身がインターネットへ出られないため、そこへ 0.0.0.0/0 を向けたインスタンスも外へ出られません。

Point

NAT = Network Address Translation の略です。
プライベート IP アドレスの通信を、外部へ出るときに別のアドレスへ変換する考え方です。
NAT Gateway は、プライベートサブネットから外へ出る通信を助けます。
和訳
- Network: ネットワーク
- Address: アドレス
- Translation: 変換
- Weblio英和辞書「translation」

要件	選ぶ構成	理由
パブリックサブネットの EC2 を直接インターネットに出したい	Internet Gateway	パブリックと IGW へのルートで通信します。
プライベートサブネットの EC2 から IPv4 インターネットへ出たい	Public NAT Gateway	インバウンドを直接許さずアウトバウンドできます。
IPv6 のアウトバウンドだけ許可したい	Egress-only Internet Gateway	IPv6 向けのアウトバウンド専用ゲートウェイです。
AWS サービスへインターネットを通らず接続したい	VPC Endpoint	NAT や IGW を使わずプライベート接続できます。

⚠️ 頻出: IPv4 のプライベートサブネットからインターネットへ出る要件では NAT Gateway を考えます。Egress-only Internet Gateway は IPv6 のアウトバウンド専用なので、IPv4 の 0.0.0.0/0 には使いません。

④NAT Gateway の高可用設計

Gateway は特定のに作成され、その AZ 内で冗長化されます。ただし、複数 AZ のが 1 つの AZ にある NAT Gateway を共有すると、その NAT Gateway の AZ に障害が起きたとき、他 AZ のリソースもインターネットへ出られなくなる可能性があります。

複数 AZ で可用性を保ちたい場合は、各 AZ のに NAT Gateway を 1 つずつ作成し、各 AZ のプライベートサブネットので、同じ AZ の NAT Gateway へ 0.0.0.0/0 を向けます。こうすると、AZ 障害の影響をその AZ に閉じやすくなります。

構成	可用性	注意点
1 つの NAT Gateway を全 AZ で共有	NAT Gateway の AZ 障害が他 AZ に波及しやすい	コストは抑えられますが、SAA の高可用要件では選びにくいです。
各 AZ に NAT Gateway を配置	AZ 障害の影響を閉じやすい	NAT Gateway の時間料金とデータ処理料金は増えます。
NAT インスタンスを自前運用	柔軟な設定が可能	可用性、パッチ、スケーリングを自分で管理する必要があります。

NAT Gateway には、上の AZ ごとに作る方式 (ゾーン型) のほかに、2025 年 11 月に追加された型の可用性モードがあります。リージョン型の NAT Gateway はに 1 つ作るだけで、ワークロードがある AZ へ自動的に広がり、ワークロードがなくなった AZ からは縮退します。パブリックサブネットは不要で、全 AZ のプライベートサブネットのルートを同じ NAT Gateway ID へ向けられるため、AZ を増やすたびに NAT Gateway とルートを追加する作業がなくなります。ただし新しい AZ への拡張には最大 60 分かかることがあり、その間の通信は既存の AZ を経由します。などへのプライベート NAT には対応しないため、その用途ではゾーン型を使います。

⚠️ 頻出: 「各 AZ のプライベートサブネットから IPv4 インターネットへアウトバウンドしたい」「AZ 障害時に他 AZ へ影響させたくない」という要件では、各 AZ のパブリックサブネットに NAT Gateway を配置し、同じ AZ のプライベートサブネットから対応する NAT Gateway へルートします。

⑤Transit Gateway とマルチアカウント VPC 接続

は、複数のやネットワークを集約して接続するためのハブです。多数の VPC を相互接続する場合、をメッシュ状に増やすと接続数とルート管理が複雑になります。 Transit Gateway を使うと、各 VPC をアタッチメントとして接続し、Transit Gateway ので経路を集中管理できます。

接続方式	向いている場面	注意点
VPC Peering	少数 VPC 間の直接接続	推移的ルーティングはできず、多数 VPC ではメッシュ管理が複雑になります。
Transit Gateway	多数 VPC、複数アカウント、オンプレミス接続の集約	アタッチメントとルートテーブルで経路を集中管理します。
	オンプレミスと AWS の接続	VPC 同士を大規模に相互接続する主目的ではありません。
Internet Gateway	インターネット接続	プライベートな VPC 間通信や一元ルーティングには使いません。

配下の複数アカウントでネットワークを分離している場合は、ネットワーク管理アカウントで Transit Gateway を作成し、で各アカウントに共有する設計がよく使われます。各アカウントは共有された Transit Gateway に自分の VPC をアタッチし、経路は Transit Gateway route table と各 VPC の route table で制御します。これにより、各 VPC 間に個別のピアリングを張るより、運用負荷を抑えて一元的にルーティングを管理できます。

⚠️ 頻出: 「数十のアカウント」「多数の VPC」「全 VPC 間通信」「一元的にルーティング管理」は Transit Gateway + AWS RAM 共有を考えます。VPC Peering のメッシュ構成は小規模なら使えますが、大規模環境では管理負荷が増えやすいです。

⑥セキュリティグループ、ネットワーク ACL、VPC Flow Logs

の通信制御では、とネットワークを切り分けます。セキュリティグループはに紐づくな制御、ネットワーク ACL は単位のな制御です。

機能	制御単位	特徴
Security Group	ENI / インスタンス	ステートフルで、許可ルールを中心に管理します。
Network ACL	サブネット	ステートレスで、許可と拒否のルールを番号順に評価します。
VPC Flow Logs	VPC、サブネット、ENI	通信の許可・拒否や送信元・送信先を分析できます。

ネットワーク ACL はステートレスなので、戻りの通信にも許可ルールが要ります。クライアントは応答をエフェメラルポート（1024〜65535 の範囲など）で受けるため、Web サーバーのサブネットの NACL でインバウンドの 443 だけを許可しても、アウトバウンドでエフェメラルポート宛てを許可しなければ応答が返りません。セキュリティグループは送信元に別のセキュリティグループを指定できるため、「のセキュリティグループからの 443 だけを受ける」のように、アドレスではなく層の関係で許可を書けます。

接続できない問題では、、セキュリティグループ、ネットワーク ACL、パブリック IP、ゲートウェイ、を順番に確認します。通信調査や監査では VPC Flow Logs が候補になります。

⑦VPC Endpoint とプライベート接続

Endpoint は、VPC から AWS サービスへプライベートに接続するための機能です。やには Gateway Endpoint、、 Logs、など多くのサービスには Interface Endpoint を使います。

種別	主な対象	判断ポイント
Gateway Endpoint	S3、DynamoDB	に経路を追加して使います。
Interface Endpoint	Systems Manager、KMS、CloudWatch Logs など	とを使い、で制御します。

から AWS サービスへアクセスしたいだけなら、 Gateway より VPC Endpoint が適切な場合があります。インターネット経由を避けたい、NAT Gateway のコストを抑えたい、セキュリティ要件が強い、という条件でよく出ます。

Gateway Endpoint は ENI を作らず、ルートテーブルに追加された経路で働きます。経路はルートテーブル単位で有効になるため、対象のリソースが置かれたが関連付けているルートテーブルすべてに、エンドポイントへの経路を追加します。ルートテーブルがごとや用途ごとに分かれている構成では、1 つだけ追加して残りを忘れると、そのサブネットの通信は NAT Gateway 経由のまま残ります。

Gateway Endpoint には時間料金もデータ処理料金もかかりません。エンドポイントポリシーで到達できるを自社のものに絞ると、VPC 内のインスタンスから他社のバケットへデータを持ち出す経路を塞げます。反対に、バケットポリシーで aws:SourceVpce 条件を使うと、バケット側から特定のエンドポイント経由のアクセスだけを許可できます。

ENI で通信するリソースも同じ扱いです。awsvpc ネットワークモードのタスクやタスクは、サブネット内の ENI から通信するため、経路はタスク側の設定ではなくサブネットのルートテーブルで決まります。

⚠️ 頻出: 「S3 への通信をインターネットに出さず、ネットワークコストを最小にする」は S3 の Gateway Endpoint と、対象サブネットの全ルートテーブルへの経路追加を選びます。

⑧ネットワークの料金の仕組み

ネットワークのコストは、「置いているリソースの時間料金」と「どこからどこへ何 GB 流したかの料金」の組み合わせで決まります。SAA では単価を覚えるより、どの経路の何に課金されるかで構成を選びます。

対象	課金されるもの	判断ポイント
Gateway	作成している時間と、通過したデータ量（GB ごとのデータ処理料金）	宛先が同じのでもデータ処理料金がかかります。別の NAT Gateway を使うと AZ 間の転送料金も加わります。リージョン NAT Gateway は展開している AZ ごとに時間料金がかかります。
Gateway Endpoint（S3、）	時間料金もデータ処理料金もかかりません	S3 と DynamoDB への大量通信を NAT から外す第一候補です。
Interface Endpoint	AZ ごとの時間料金と、処理したデータ量	NAT を通さずに済みますが、自体の料金がかかります。
同じ AZ 内のプライベート通信	転送料金はかかりません	経由でも、同じ AZ 内なら無料です。
AZ 間の通信	送信側と受信側の両方向の転送料金	VPC ピアリング経由でも、AZ をまたげば課金されます。
同じリージョン内のパブリック IP 宛ての通信	リージョン内の転送料金	同じ AZ でもパブリック IP や宛てにすると無料になりません。
リージョン間の通信	送信元リージョンからの転送（アウト）	受信側のリージョンへの転送（イン）には料金がかかりません。
インターネットとの通信	AWS からインターネットへの転送（アウト）	インターネットから AWS への転送（イン）は無料です。
パブリック IPv4 アドレス	使用中か未使用かを問わず、アドレスごとの時間料金	関連付けていない Elastic IP も課金されます。BYOIP で持ち込んだアドレスと IPv6 アドレスには、このアドレス料金はかかりません。
VPC ピアリング	接続の時間料金はなく、データ転送料金だけ	のアタッチメントの時間料金やデータ処理料金がありません。

パブリック IPv4 アドレスの使い方は、 IP Address Manager（IPAM）の Public IP Insights で、組織のアカウントとリージョンをまたいで無料で確認できます。の背後にあるからはパブリック IPv4 の自動割り当てを外し、使っていない Elastic IP は解放します。

⚠️ 頻出: 「同じリージョンの S3 への転送は無料なのに請求が高い」は NAT Gateway のデータ処理料金を疑い、Gateway Endpoint で経路を外します。「AZ 間の転送料金を下げたい」は、通信相手を同じ AZ に寄せるか、同じ AZ の NAT Gateway を使わせます。

試験対策

の問題では、まず「外部から入る通信」なのか「内部から外へ出る通信」なのかを分けます。次に、通信先がインターネットなのか AWS サービスなのか、IPv4 なのか IPv6 なのか、障害時の影響範囲をどうしたいのかを確認します。

問題文のキーワード	優先して考える機能	理由
からインターネットへ直接通信	Internet Gateway	へのルートとパブリックが必要です。
から IPv4 インターネットへアウトバウンド	Gateway	外部からの直接インバウンドを避けながら外へ出られます。
複数 AZ で NAT の AZ 障害影響を避けたい	各 AZ に NAT Gateway	同じ AZ のプライベートサブネットから同じ AZ の NAT Gateway へルートします。
IPv6 のアウトバウンドだけ許可	Egress-only Internet Gateway	IPv6 では NAT Gateway ではなく専用ゲートウェイを考えます。
へ private に接続	Gateway VPC Endpoint	インターネットや NAT を通らずに接続できます。
やへ private に接続	Interface VPC Endpoint	経由でサービスに接続できます。
多数アカウントの VPC 間通信を一元管理	+	ネットワーク管理アカウントの Transit Gateway を共有し、アタッチメントとで集中管理できます。
少数 VPC 間を直接接続	VPC Peering	小規模なら単純ですが、多数 VPC ではメッシュ化して運用負荷が増えます。
接続できない原因調査	Route table、SG、NACL、Flow Logs	経路、許可ルール、ログを切り分けます。

よくある誤答は、1 つの NAT Gateway をすべての AZ で共有する構成です。コストを抑える目的なら成立する場合もありますが、問題文に「AZ 障害時にも他 AZ のインスタンスへ影響させたくない」とある場合は、各 AZ に NAT Gateway を置く構成が自然です。

NAT インスタンスはで自前運用するため、可用性、スケーリング、パッチ、障害復旧を自分で設計する必要があります。SAA では、マネージドで高可用なアウトバウンド通信を求める問題では NAT Gateway が選ばれやすいです。

⚠️ 頻出: プライベートサブネットの EC2 がパッチ取得などで IPv4 インターネットへ出るだけなら NAT Gateway です。さらに複数 AZ で可用性を求めるなら、各 AZ の NAT Gateway と同一 AZ ルーティングをセットで考えます。