VPCとは？サブネットとルートテーブルから通信の通り道を読む（AWS）

「VPC とは何か」を調べると、「クラウド上の仮想ネットワーク」という一文と、部品の名前の一覧が出てきます。ただ、実際に困るのは「この EC2 からなぜ外に出られないのか」「ALB に届いたリクエストがどこで止まっているのか」といった、パケットがどこを通るのかが読めない場面です。

この記事では、VPC の意味を短く押さえたあと、典型的な構成を1枚の図にして、ルートテーブルとセキュリティグループ・ネットワークACLを順にたどります。最後に、VPC やサブネットを分ける判断と、アドレス範囲の決め方を整理します。AWS の挙動・既定値・上限は、2026年10月3日時点の AWS 公式ドキュメントで確認したものです。

VPCとは：AWSの中に区切る、自分専用のネットワーク

VPC（Virtual Private Cloud、仮想プライベートクラウド）は、AWS の中に作る、論理的に隔離された仮想ネットワークです。AWS の公式ドキュメントは、自社のデータセンターで運用する従来のネットワークによく似たもの、と説明しています。EC2 や RDS、ALB などは、この VPC の中に置かれます。

VPC は1つのリージョンの中に作り、その中をサブネットという区画に分けます。サブネットは必ず1つのAvailability Zone（AZ）に収まり、AZ をまたげません。そのため、AZ の障害に備えるなら、同じ役割のサブネットを AZ ごとに用意します。

VPC の中の部品は、役割で分けると次の6つです。

典型的な構成を1枚で見る（2つのAZ・パブリックとプライベート）

実務でよく見るのは、2つの AZ にそれぞれパブリックとプライベートのサブネットを置く形です。インターネットからの入口（ALB）と NAT Gateway をパブリックに、アプリの EC2 やデータベースをプライベートに置きます。

この図で押さえたいのは、サブネットの性格を決めているのは下の2つのルートテーブルだということです。パブリック用の表は2つのパブリックサブネットに関連付け、プライベート用の表は AZ ごとに1つずつ作って、それぞれ同じ AZ の NAT Gateway を向けます。

NAT Gateway を AZ ごとに置くのは、AWS の公式ドキュメントが勧めている形です。1つの NAT Gateway を複数の AZ で共有すると、その AZ が止まったときに、ほかの AZ のリソースも外へ出られなくなります。

パケットの行き先はルートテーブルで決まる

ルートテーブルは「宛先（Destination）」と「次の行き先（Target）」の組の一覧です。サブネットから出るパケットは、宛先のIPアドレスに合う行を探し、その行のターゲットへ送られます。

読み方の決まりは3つです。

たとえば、プライベートのサブネットから 10.0.1.25（同じ VPC の ALB）へ送るパケットは 10.0.0.0/16 → local に当てはまり、VPC の中で届きます。198.51.100.10（外部の API）へ送るパケットは local に当てはまらないので、0.0.0.0/0 の行に従って NAT Gateway へ行きます。

パブリックかプライベートかは、名前ではなく経路で決まる

AWS の公式ドキュメントは、Internet Gateway への直接の経路があるサブネットをパブリック、無いサブネットをプライベートと定義しています。サブネットの名前に「public」と付けても、関連付いたルートテーブルに Internet Gateway への行が無ければプライベートです。逆に、メインのルートテーブルに Internet Gateway への行を足すと、明示的に関連付けていないサブネットがすべてパブリックになります。

サブネットがどのルートテーブルを使っているかは、AWS CLI で確かめられます。ここでつまずきやすいのは、明示的な関連付けが無いサブネットは、1つ目のコマンドで何も返らないことです。その場合はメインのルートテーブルを見ます。

# サブネットに明示的に関連付いたルートテーブルの経路を見る
aws ec2 describe-route-tables \
  --filters Name=association.subnet-id,Values=subnet-0123456789abcdef0 \
  --query "RouteTables[].Routes[].[DestinationCidrBlock,GatewayId,NatGatewayId]" \
  --output table

# 何も返らなければ、その VPC のメインのルートテーブルが使われている
aws ec2 describe-route-tables \
  --filters Name=vpc-id,Values=vpc-0123456789abcdef0 Name=association.main,Values=true \
  --query "RouteTables[].Routes[].[DestinationCidrBlock,GatewayId,NatGatewayId]" \
  --output table

GatewayId が igw- で始まる行が 0.0.0.0/0 にあればパブリック、NatGatewayId に nat- が入っていれば NAT Gateway 経由で外へ出るプライベートです。

セキュリティグループとネットワークACL：2つの関所

経路があっても、それだけでは通信は通りません。VPC には関所が2種類あり、どちらかで止まると届きません。公式ドキュメントの比較を、実務で効く順に並べ直すと次のとおりです。

AWS の公式ドキュメントも、通信の制御はセキュリティグループを主に使い、ネットワークACLは必要なときに粗い制御として足すという考え方を示しています。

セキュリティグループは「誰から」をグループで書ける

新しく作ったセキュリティグループは、受信のルールが空（何も受け付けない）で、送信はすべて許可されています。受信を開けるときに便利なのが、送信元にほかのセキュリティグループを指定する書き方です。上の図なら、アプリの EC2 のセキュリティグループに「送信元：ALB のセキュリティグループ、ポート：アプリのポート」と書けば、ALB からの通信だけを受け付けます。ALB の台数や IP が変わっても書き換えは要りません。

ネットワークACLは「戻り」と「順番」でつまずく

デフォルトのネットワークACLはすべて許可なので、触らなければ問題になりません。問題が起きるのは、自分で作ったネットワークACLを関連付けたときです。新しいネットワークACLは、最後の * のルール（すべて拒否）しか無い状態から始まります。

1024-65535 の行が要るのは、相手が返事を送ってくる先が、こちらの OS が一時的に選んだポート（エフェメラルポート）だからです。公式ドキュメントによると、範囲は送信元によって違い、多くの Linux カーネルは 32768-61000、Windows Server 2008 以降は 49152-65535、NAT Gateway と Elastic Load Balancing は 1024-65535 を使います。ネットワークACLはステートレスなので、この戻りの範囲を開けないと「行きは通るのに返事が来ない」状態になります。順番で判定する仕組みと戻りの通信は、ネットワーク機器の ACL と同じ考え方です。手を動かして確かめた記録はネットワーク機器のACLとは？にあります。

経路を追ってみる①：プライベートのEC2が外部APIを呼ぶ

ここからは、上の図の構成で実際にパケットの通り道を追います。1つ目は、AZ-a のプライベートサブネットにあるアプリの EC2（10.0.11.20）が、外部の API（203.0.113.50 の 443番）を呼ぶ場面です。

返事は逆の順番で戻ります。外部の API から NAT Gateway の Elastic IP に返ってきたパケットは、Internet Gateway → パブリックサブネット → NAT Gateway → プライベートサブネット → EC2 と進みます。

• セキュリティグループ：EC2 から出た通信の戻りなので、受信のルールが空でも自動で通ります
• ネットワークACL：戻りも判定されます。パブリックサブネットの受信では、NAT Gateway が使う 1024-65535 への通信を、プライベートサブネットの受信では EC2 の OS が使うエフェメラルポートへの通信を、許可しておく必要があります
• 外部 API 側から見た送信元：NAT Gateway の Elastic IP です。API 側で接続元の IP を登録する必要があるときは、この Elastic IP を伝えます

外部 API ではなく S3 や DynamoDB へ大量に通信する場合は、NAT Gateway を通さない VPC エンドポイントを使う方法があります。どちらを選ぶかはNAT Gatewayの記事で整理しています。

経路を追ってみる②：ALBがインターネットからのリクエストを受ける

2つ目は、利用者のブラウザ（198.51.100.7）から、パブリックサブネットの ALB を経由して、プライベートサブネットのアプリへリクエストが届く場面です。

この流れから分かるのは、プライベートサブネットのアプリにパブリックIPは要らないということです。インターネットとやり取りするのは ALB で、ALB とアプリの間は VPC の中の通信です。ALB はサブネットを2つ以上の AZ から選ぶ必要があり、公式ドキュメントでは各サブネットを /27 以上にして、空きアドレスを8個以上残すよう求めています。ALB の振り分けの考え方はALBとは？を見てください。

つながらないときに確認する順番

「つながらない」と言われたら、上の2つの追い方と同じ順番で、外側から1か所ずつ確かめます。勘でセキュリティグループを広げるより早く、余計な穴も開けずに済みます。

設定から経路を自動で判定する道具も2つあります。Reachability Analyzer は、送信元と宛先を指定すると、設定を解析して途中の経路を1つずつ示し、届かない場合は止めている部品（セキュリティグループ、ネットワークACL、ルートテーブルなど）を示します。パケットは流さず設定だけを見るもので、分析1回ごとに料金がかかります。VPC Flow Logs は、ネットワークインターフェースを出入りした通信を記録し、許可（ACCEPT）か拒否（REJECT）かも残ります。記録の取得は通信の経路の外で行われるので、通信の速さには影響しません。ログの保存先（CloudWatch Logs、S3 など）の料金はかかります。

VPCやサブネットを分けるメリットと判断基準

「VPC を分けるべきか」「サブネットはいくつに分けるか」は、何を切り離したいかで決まります。AWS の公式ドキュメントは、ワークロードや組織ごとに VPC を分け、アプリの層（Web・アプリ・データベース）はサブネットで分けるという考え方を示しています。

分けるメリットは、まとめると「影響範囲を小さくできる」ことです。開発環境の設定ミスや、検証のために開けたポートが、本番のサーバーに届かなくなります。一方で、分けた単位の間で通信が必要になると、そのたびに経路を足す作業が発生します。VPC を分けても IAM の権限は分かれないので、本番を誤操作から守りたいならアカウントを分けるほうが確実です。アカウントを分けずに運用を続けたときに困ることはAWSを1アカウントで運用し続けると何がつらいのかにまとめています。

アドレス範囲（CIDR）は最初に割り当て表を作る

VPC を分けるなら、どの VPC にどのアドレス範囲を使うかを最初に決めます。あとで変えにくい決まりが多く、重なっていると、つなげたくなったときにつなげないからです。

公式ドキュメントで確認した、設計のときに効く決まりは次のとおりです。

VPC peering は1対1の接続で、A と B、A と C をつないでも、B から A を経由して C には届きません。VPC が増えてきたら、複数の VPC やオンプレミスをまとめてつなぐ Transit Gateway を検討します。どちらを使う場合も、範囲が重ならないことが前提です。社内とつなぐ専用線の話はAWS Direct Connect とは？、CIDR の読み方はCIDR表記とは、プライベートアドレスの範囲はグローバルIPとプライベートIPの違いを見てください。

VPCに関するよくある質問

Q. VPC は無料で使えますか

VPC を作ること自体に追加料金はかかりません。サブネット、ルートテーブル、Internet Gateway、セキュリティグループ、ネットワークACLにも料金はかかりません。一方、NAT Gateway、IP Address Manager、Reachability Analyzer などの部品と、パブリックIPv4アドレスは有料です。金額は変わることがあるので、Amazon VPC の料金ページで確認してください。

Q. VPC と VPN は何が違いますか

名前は似ていますが、別のものです。VPC（仮想プライベートクラウド）はクラウドの中に区切ったネットワークそのもので、VPN（仮想プライベートネットワーク）は離れたネットワーク同士を暗号化した通信路でつなぐ仕組みです。社内のネットワークと VPC を VPN でつなぐ、というように組み合わせて使います。

Q. デフォルトVPC をそのまま本番に使ってもよいですか

すぐ動かせるのは利点ですが、デフォルトのサブネットはすべてパブリックで、起動したインスタンスにパブリックIPが自動で付きます。アドレス範囲も全リージョンで 172.31.0.0/16 に固定なので、ほかの VPC や社内とつなぐ計画と重なりやすくなります。本番では、この記事の図のようにパブリックとプライベートを分けた VPC を作るほうが、経路と公開範囲を管理しやすくなります。

Q. サブネットはどのくらいの大きさにすればよいですか

置くものの数より余裕を持たせます。各サブネットで5つのアドレスが予約されるうえ、ALB は各サブネットに /27 以上と空きアドレス8個以上を求めます。コンテナのようにタスクごとにアドレスを使うものを置くなら、さらに大きめに取ります。サブネットの CIDR はあとから変えられないので、迷ったら /24 程度から考えるのが無難です。

Q. セキュリティグループだけで十分ですか、ネットワークACLも設定すべきですか

多くの場合はセキュリティグループで足ります。AWS の公式ドキュメントも、セキュリティグループを主に使い、ネットワークACLは特定の通信をまとめて拒否したいときや、サブネット全体の追加の守りとして使う位置づけにしています。ネットワークACLを自分で作るときは、戻りの通信のエフェメラルポートを必ず許可してください。

まとめ

• VPC は AWS の中に区切った自分専用のネットワーク。サブネットは1つの AZ に収まり、AZ ごとに同じ役割のサブネットを用意する
• パケットの行き先は、サブネットに関連付いたルートテーブルで決まる。local は VPC 内、いちばん細かい行が勝ち、0.0.0.0/0 は受け皿
• パブリックかプライベートかは、Internet Gateway への経路があるかどうかで決まる。インターネットと直接やり取りするにはパブリックIPも要る
• セキュリティグループはリソース単位で、戻りは自動で通る。ネットワークACLはサブネット単位で、番号順に判定し、戻りも許可が要る
• つながらないときは、サブネット → ルートテーブル → パブリックIP → ネットワークACL → セキュリティグループ → OS の順に確かめる。Reachability Analyzer と VPC Flow Logs も使える
• VPC やサブネットを分けると影響範囲を小さくできるが、つなぐための経路が増える。アドレス範囲は重ならないように最初に割り当て表を作る

参考リンク

• AWS：What is Amazon VPC?（VPC の定義・料金の考え方）
• AWS：Default VPC components（デフォルトVPCの構成）
• AWS：Work with your default VPC and default subnets（デフォルトVPCの作り直し）
• AWS：Subnets for your VPC（サブネットの種類と AZ）
• AWS：Subnet CIDR blocks（予約される5つのアドレス）
• AWS：CreateSubnet（作成後にサブネットの CIDR は変えられない）
• AWS：VPC CIDR blocks（VPC の大きさと追加の CIDR）
• AWS：Route table concepts（メイン・カスタム・local）
• AWS：How route priority works（最長一致）
• AWS：Enable internet access for a VPC using an internet gateway
• AWS：NAT gateway basics（AZ ごとの配置）
• AWS：Regional NAT gateways for automatic multi-AZ expansion
• AWS：Infrastructure security in Amazon VPC（セキュリティグループとネットワークACLの比較）
• AWS：Security group rules（既定のルールとグループの参照）
• AWS：Control subnet traffic with network access control lists
• AWS：Custom network ACLs for your VPC（エフェメラルポート）
• AWS：Application Load Balancers（サブネットの要件）
• AWS：How VPC peering connections work（重なり・経由の制限）
• AWS：How AWS Transit Gateway works
• AWS：Amazon VPC quotas（VPC 数・ルール数などの上限）
• AWS：What is Reachability Analyzer?
• AWS：Logging IP traffic using VPC Flow Logs
• AWS：Amazon VPC の料金