AWS のネットワーク設計で後から直しにくいのは、VPC の CIDR（アドレス範囲）と、サブネットの分け方の2つです。最初に「他のネットワークと重ならない十分な広さの CIDR を取る」「複数の AZ にまたがって、外部公開・内部・データベースの層ごとにサブネットを分ける」と決めておけば、その後のセキュリティグループや NAT、VPC エンドポイントの設計は素直に積み上げられます。この記事では、VPC を作る前に決めておきたい設計の原則を、WordPress のような Web サイトの構成を例に説明します。
VPC の作成手順そのものではなく、設計の判断に絞った記事です。AWS のネットワーク関連のサービスは機能追加や料金体系の変更が続いているため（2026年10月現在）、個々の仕様は AWS の公式ドキュメントで確かめてください。
原則1：CIDR は重ならない範囲で、余裕を持って取る
VPC の CIDR には、プライベートアドレスの範囲（10.0.0.0/8、172.16.0.0/12、192.168.0.0/16）から切り出したブロックを使います。決めるときのポイントは次の3つです。
- 他のネットワークと重ねない：将来 VPC ピアリングや Transit Gateway で別の VPC とつないだり、社内ネットワークと VPN でつないだりするとき、アドレスが重なっていると経路を設定できません。すべての VPC に 10.0.0.0/16 を使う、という運用は避け、組織の中でアドレスの割り当て表を作っておきます。
- 広めに取る：VPC は /16 から /28 の範囲で作れます。小さく作ると、後からサブネットや AZ を増やしたいときに足りなくなります。追加の CIDR を VPC に関連付けることもできますが、最初の範囲を広めにしておく方が管理は簡単です。
- 予約アドレスを見込む：各サブネットでは、先頭の4つと最後の1つのアドレスを AWS が予約しています。/28 のような小さなサブネットでは、使えるアドレスが思ったより少なくなります。
例として、10.20.0.0/16 を VPC に割り当て、/20 単位でサブネットを切る計画を立てると、1つのサブネットに約4,000個のアドレスを確保しながら、16個のサブネットを作れます。
原則2：サブネットは「層 × AZ」で分ける
サブネットは役割ごとの層に分け、それぞれを2つ以上の AZ に作ります。
| 層 | 置くもの | インターネットとの経路 |
|---|---|---|
| パブリック | ALB、NAT ゲートウェイ | インターネットゲートウェイと直接やり取りする |
| プライベート（アプリ） | EC2、ECS のタスク | 外向きのみ NAT ゲートウェイ経由 |
| プライベート（データ） | RDS、ElastiCache、EFS のマウントターゲット | 原則として持たせない |
Web サーバーをパブリックサブネットに置いて公開 IP を付けるのが最も簡単ですが、サーバーが直接インターネットにさらされます。ALB だけを公開し、EC2 はプライベートサブネットに置く構成にすると、外から届く通信を ALB 経由の HTTP/HTTPS だけに限定できます。
AZ を2つ以上にするのは、1つの AZ で障害が起きたときにサービスを続けるためです。RDS のマルチ AZ 配置や ALB も、複数の AZ のサブネットを指定する前提で作られています。
サブネットの「パブリック」「プライベート」は、ルートテーブルで決まります。インターネットゲートウェイへの経路（0.0.0.0/0 → IGW）があるサブネットがパブリックです。サブネットの名前ではなくルートテーブルの中身で判断する、と覚えておくと、設定ミスに気づきやすくなります。
原則3：外向き通信は NAT ゲートウェイ、AWS サービスへは VPC エンドポイント
プライベートサブネットの EC2 も、OS の更新や外部 API の呼び出しでインターネットに出る必要があります。そのための出口が NAT ゲートウェイです。
- NAT ゲートウェイは AZ ごとに置く：1つの AZ にだけ置くと、その AZ の障害で全 AZ のサーバーが外に出られなくなります。また、別 AZ の NAT を通る通信には AZ 間の転送料金もかかります。可用性を優先するなら AZ ごとに置き、それぞれのプライベートサブネットのルートテーブルを同じ AZ の NAT に向けます。検証環境などで費用を抑えたい場合は1つにまとめる判断もあり得ますが、その場合は単一障害点になることを理解したうえで選びます。
- S3 と DynamoDB にはゲートウェイ型の VPC エンドポイント：ルートテーブルに経路を追加するだけで、NAT を通らずに S3 や DynamoDB へアクセスできます。バックアップやメディアファイルで S3 との通信量が多い構成では、NAT の処理量を減らせます。
- その他のサービスにはインターフェイス型の VPC エンドポイント：Systems Manager、Secrets Manager、CloudWatch Logs などに、VPC 内のプライベート IP から接続できます。インターフェイス型には時間とデータ量に応じた料金がかかるため、必要なサービスを選んで作ります。
料金の具体的な金額はここでは挙げませんが、NAT ゲートウェイとインターフェイス型エンドポイントは、置いておくだけで時間単位の費用がかかります。設計の段階で料金ページを確認し、構成図と一緒に見積もっておきます。
なお、公開 IPv4 アドレスは使用中のものにも料金がかかる体系になっています（2024年2月から）。公開 IP を付けるリソースは必要なものに絞り、IPv6 の利用も選択肢として検討します。
原則4：アクセス制御はセキュリティグループを主に使う
VPC のアクセス制御には、セキュリティグループとネットワーク ACL（NACL）の2つがあります。
- セキュリティグループ：インスタンスやロードバランサーなどのネットワークインターフェイスに付けます。ステートフルなので、許可した通信の戻りは自動で通ります。許可ルールだけを書く方式です。
- ネットワーク ACL：サブネットの単位で適用します。ステートレスなので、戻りの通信（エフェメラルポート）も明示的に許可する必要があります。許可と拒否の両方を番号順に評価します。
日常の制御はセキュリティグループで行い、NACL は「特定のアドレス範囲をサブネットごと拒否したい」といった補助的な用途にとどめるのが扱いやすい方法です。NACL を細かく絞り込むと、戻りの通信を許可し忘れて原因の分かりにくい通信障害を起こしがちです。
セキュリティグループでは、送信元を IP アドレスではなく他のセキュリティグループで指定するのが基本です。
- ALB のセキュリティグループ：0.0.0.0/0 から 443（と 80）を許可
- EC2 のセキュリティグループ：送信元 = ALB のセキュリティグループ、ポート 80
- RDS のセキュリティグループ：送信元 = EC2 のセキュリティグループ、ポート 3306
こうしておくと、Auto Scaling で EC2 の台数や IP が変わってもルールを書き換える必要がありません。
SSH のポートを開けない
管理のために SSH（22番）を 0.0.0.0/0 に開けるのは避けます。AWS Systems Manager の Session Manager を使えば、インバウンドのポートを開けずに、IAM の権限で EC2 にログインでき、操作の記録も残せます。プライベートサブネットで使う場合は、NAT 経由か、Systems Manager 用のインターフェイス型エンドポイント経由で通信できる必要があります。
原則5：通信を見えるようにしておく
設計どおりに通信が流れているかを確かめる手段を、最初から用意しておきます。
- VPC フローログ：VPC やサブネット、ネットワークインターフェイスを通った通信の記録を、CloudWatch Logs や S3 に保存します。拒否された通信を調べるときや、不審な通信の調査に使います。
aws ec2 create-flow-logs \
--resource-type VPC \
--resource-ids vpc-0123456789abcdef0 \
--traffic-type ALL \
--log-destination-type s3 \
--log-destination arn:aws:s3:::example-flow-logs-bucket- Reachability Analyzer：2つのリソースの間で通信が届くかを、設定の上で解析するツールです。「EC2 から RDS につながらない」ときに、どのセキュリティグループやルートテーブルで止まっているかを確認できます。
原則6：環境と規模の広がりを見込む
本番、ステージング、開発の環境は、VPC を分けるか、AWS アカウントそのものを分けるのが一般的です。アカウントを分けると、権限や費用の管理を環境ごとに切り分けられます。VPC の数が増えて相互の接続が必要になったら、1対1でつなぐ VPC ピアリングを増やしていくより、Transit Gateway を中心に置く構成の方が経路の管理が楽になります。そのためにも、原則1のアドレス計画が効いてきます。
設計を見直すときは、AWS Well-Architected フレームワークの信頼性とセキュリティの柱が、確認項目の一覧として役立ちます。
まとめ
- VPC の CIDR は他のネットワークと重ならない範囲で広めに取り、組織で割り当て表を管理します。
- サブネットはパブリック・アプリ・データの層ごとに分け、それぞれを2つ以上の AZ に作ります。パブリックかどうかはルートテーブルで決まります。
- 外向き通信は AZ ごとの NAT ゲートウェイ、S3 と DynamoDB へはゲートウェイ型エンドポイントを使います。費用のかかる部品は設計段階で見積もります。
- アクセス制御はセキュリティグループを中心にし、送信元をセキュリティグループで指定します。SSH は開けず Session Manager を使います。
- VPC フローログと Reachability Analyzer で、通信を確認できる状態にしておきます。