AWSでシステムを構築するとき、最初に設計するのがVPC（Virtual Private Cloud）です。ここを雑に作ると後から修正が効かず、運用で苦しむことになります。この記事では、実務で何度もVPC設計をしてきた経験から、失敗しにくい設計パターンを紹介します。
なぜVPC設計が重要なのか
VPCはAWSにおけるネットワークの土台です。EC2、RDS、ECS、Lambda（VPC内実行）など、ほぼすべてのリソースがVPC上に配置されます。CIDR（IPアドレスの範囲）を後から変更するのは困難で、サブネットの構成ミスはセキュリティホールに直結します。
特に本番環境では「最初から正しく設計する」ことが非常に重要です。
推奨するVPC設計パターン
CIDRブロックの決め方
VPCのCIDRは /16（65,536 IPアドレス）を推奨します。小規模だからと /24 にすると、サービスの成長に伴いIPアドレスが枯渇する可能性があります。
# 推奨するCIDR例
本番VPC: 10.0.0.0/16
検証VPC: 10.1.0.0/16
開発VPC: 10.2.0.0/16VPC Peering や Transit Gateway で接続することを見据えて、各VPCのCIDRが重複しないように設計します。
サブネット構成: 3層 × 3AZ パターン
最もバランスがよく実績のある構成は、パブリック・プライベート・データベースの3層をマルチAZで配置するパターンです。
# サブネット構成例（東京リージョン: ap-northeast-1）
パブリックサブネット（ALB, NAT Gateway）
- public-1a: 10.0.1.0/24 (ap-northeast-1a)
- public-1c: 10.0.2.0/24 (ap-northeast-1c)
- public-1d: 10.0.3.0/24 (ap-northeast-1d)
プライベートサブネット（EC2, ECS, Lambda）
- private-1a: 10.0.11.0/24 (ap-northeast-1a)
- private-1c: 10.0.12.0/24 (ap-northeast-1c)
- private-1d: 10.0.13.0/24 (ap-northeast-1d)
データベースサブネット（RDS, ElastiCache）
- db-1a: 10.0.21.0/24 (ap-northeast-1a)
- db-1c: 10.0.22.0/24 (ap-northeast-1c)
- db-1d: 10.0.23.0/24 (ap-northeast-1d)NATゲートウェイのコスト最適化
NATゲートウェイは各AZに配置するのが可用性の面では理想ですが、コストが月額約$33/台 + データ転送料がかかります。
開発・検証環境では1台に集約し、本番環境のみマルチAZ配置とするのが現実的です。さらにコストを抑えたい場合は、NAT インスタンス（t4g.nano）を使う選択肢もあります。
Terraformでの実装例
resource "aws_vpc" "main" {
cidr_block = "10.0.0.0/16"
enable_dns_support = true
enable_dns_hostnames = true
tags = {
Name = "production-vpc"
Environment = "production"
}
}
resource "aws_subnet" "public" {
count = 3
vpc_id = aws_vpc.main.id
cidr_block = cidrsubnet(aws_vpc.main.cidr_block, 8, count.index + 1)
availability_zone = data.aws_availability_zones.available.names[count.index]
map_public_ip_on_launch = true
tags = {
Name = "public-${data.aws_availability_zones.available.names[count.index]}"
Tier = "public"
}
}
resource "aws_subnet" "private" {
count = 3
vpc_id = aws_vpc.main.id
cidr_block = cidrsubnet(aws_vpc.main.cidr_block, 8, count.index + 11)
availability_zone = data.aws_availability_zones.available.names[count.index]
tags = {
Name = "private-${data.aws_availability_zones.available.names[count.index]}"
Tier = "private"
}
}よくある失敗パターン
CIDRを小さくしすぎる — /24 で始めて、ECSタスクやLambda ENI でIPが足りなくなるケースが多いです。特にECSはタスク数だけENIを消費するので注意が必要です。
AZを1つしか使わない — 可用性を確保するため、最低2AZ、できれば3AZで構成します。RDSのMulti-AZやALBの要件もあるため、最初からマルチAZで設計しましょう。
セキュリティグループに0.0.0.0/0を許可 — 開発中の「とりあえず全開放」が本番にそのまま残るパターン。必ず最小権限の原則を守りましょう。
まとめ
VPC設計は「最初にしっかり考えて、後から変えなくていい」状態を目指すのが鍵です。本記事で紹介した 3層×3AZ パターンをベースに、プロジェクトの要件に合わせてカスタマイズしていくのがおすすめです。次回はこのVPC上にECS Fargateを構築する手順を解説します。
コメント