Amazon VPC徹底解説：GCP VPC・Azure VNetとの実務比較で“壊れないネットワーク設計”を身につける

はじめに（要点サマリー）

本記事はAmazon VPC（Virtual Private Cloud）を中心に、GCP VPCとAzure Virtual Network（VNet）を用語対応・設計思想・安全なインターネット到達・ハイブリッド接続・観測性・コストの観点で比較する実務者向けの長編ガイドです。
先に結論：“最初の一週間で決めるべきこと”は、①アドレス計画（IPv4/IPv6）、②ルーティング（ハブ＆スポーク）、③境界（Egress/Ingress）、④IDベースの許可（SG/IAM）、⑤**監査（Flow Logs/Traffic Mirroring/CloudTrail）**の5点。ここが固まると、アプリは“ただ乗せるだけ”で安定します。
AWSはNAT Gateway・PrivateLink・Interface/Gatewayエンドポイント・Network Firewall・Transit Gatewayなど部品の選択肢が広く、自由度が高いのが長所。GCPは**“一つのグローバルVPC”の考え方が明快で、Cloud NAT・Private Service Connectがシンプル。AzureはVNet/サブネット/NSG/Route Tableの一体感とPrivate Endpoint/Firewall/Virtual WAN**の企業統合が得意です。
すぐ使えるCIDR設計テンプレ、最小セキュア構成、ルート表の雛形、セキュリティグループ/NSGの対訳、ハブ＆スポークの3パターン図解（文章化）、インシデントRunbook、Terraformの概念サンプルを収録。
読者像：情報システム部門のネットワーク/クラウド移行担当、SRE/プラットフォームエンジニア、アプリ開発者、セキュリティ/ガバナンス担当。オンプレからの段階移行、マルチアカウント/マルチクラウドの“つながる設計”を一気に整理したい方向けです。

1. VPCの基本思想と3クラウド対応の言い換え

VPCは「自分専用の仮想ネットワーク」をクラウド内に作る機能です。**CIDR（アドレス範囲）**を決め、サブネットを切り、ルート表で経路を制御し、**セキュリティグループ（SG）/ネットワークACL（NACL）**で到達性を絞ります。

AWS：リージョン内にVPCを作り、AZごとにサブネットを配置し、IGW/NAT GW/Endpoints/TGWなどで内外と接続。
GCP：VPCはグローバル。サブネットはリージョン単位。Cloud Router/Cloud NAT/PSC/VPN/Interconnectで接続。
Azure：VNetはリージョン単位。サブネットはVNet内。NAT Gateway/Private Endpoint/Firewall/ExpressRoute/VPNで接続。

覚え方：

セキュリティの主役は“ID（SG/NSG/権限）”、経路は“ルート表”、境界は“NAT/Firewall/Endpoint”。
物理の“内外”という感覚ではなく、**“どのIDがどの宛先へ、どの経路・暗号・監査で行けるか”**を言語化します。

2. アドレス計画（CIDR）と命名規則：最初に決めて、二度と変えない

2.1 CIDR基本戦略

重複させない：将来のハイブリッド接続/マルチクラウド/組織統合を見据え、RFC1918の使い方を計画的に。
成長余地：/16（65,536IP）をVPCに割り、/19〜/24単位でサブネット切り出しが王道（数値は目安）。
役割分離：App/DB/Shared/Ingress/Egress/管理など用途ごとにサブネットを固定化。

2.2 命名規則（例）

VPC：{org}-{env}-{region}-vpc（例：acme-prod-apne1-vpc）
Subnets：{vpc}-{az}-{purpose}（例：acme-prod-apne1a-app）
RouteTable/NACL/SG：{env}-{layer}-{purpose}で**“用途”が目に入る名前**を。

2.3 サンプルCIDR配分（文章図）

VPC：10.64.0.0/16
- Public（Ingress/Egress）：10.64.0.0/20（a/c/eの3AZへ均等分割）
- App（プライベート）：10.64.16.0/19
- Data（プライベート）：10.64.48.0/20
- Shared/管理：10.64.64.0/20
  将来のオンプレ/他クラウドとの重複を避けるため、組織で“予約帳”を運用します。

3. ルーティングと境界：ハブ＆スポークを迷わず選ぶ

3.1 3つの標準パターン

最小構成（小規模/単一VPC）
- Publicサブネット：IGWでインターネット到達、ALBやNLBを配置。
- Privateサブネット：NAT GWで外向き通信、インバウンドはALB/NLB経由のみ。
ハブ＆スポーク（中〜大規模）
- ネットワーク専用VPC（ハブ）にNAT GW/Firewall/監査を集約。
- 業務VPC（スポーク）はTransit Gateway（AWS）/VPC Peeringでハブに接続。
マルチクラウド/ハイブリッド
- ハブにVPN/専用線（DX/Interconnect/ExpressRoute）を集約し、ルート集約と監査を一本化。

3.2 経路表（Route Table）の雛形（例：スポークVPC/Private）

Destination      Target
10.64.0.0/16     local
0.0.0.0/0        tgw-xxxxxxxx   # ハブ（NAT/Firewall）へ委譲
::/0             tgw-xxxxxxxx   # IPv6時
10.20.0.0/16     tgw-xxxxxxxx   # オンプレ/他クラウドへのルート

考え方：スポークの外向きはハブへ、ハブでEgress制御。インターネットへ直出しさせないことで、監査と制御点が一箇所になります。

3.3 3クラウド対比（境界）

Egress（NAT）：AWS NAT Gateway／GCP Cloud NAT／Azure NAT Gateway
Privateサービス到達：AWS Interface/Gateway Endpoint・PrivateLink／GCP Private Service Connect／Azure Private Endpoint
中央集約：AWS Transit Gateway／GCP VPC Network Peering＋Cloud Router／Azure Virtual WAN/Hub
L7の公開：ALB/Cloud Load Balancing/Application Gatewayを使い、VM/関数を直接公開しないのが基本線。

4. セキュリティモデル：SG/NACL/Firewallの役割分担

4.1 セキュリティグループ（SG）

インスタンス/ENIに紐づく“状態あり（stateful）”フィルタ。
ルールはホワイトリストで、**ID（SG→SG参照）**での許可が要。
アプリの論理境界（Web→App→DBの段階）をSGで表現すると、運用が簡潔になります。

4.2 ネットワークACL（NACL）

サブネット境界の“ステートレス”フィルタ。
明示的Deny/Allowを順番で評価。特殊用途（例：一時的な遮断・外部連携の最小化）で使います。
日常の許可はSG中心、NACLは追加の保険という位置づけが楽です。

4.3 ネットワークファイアウォール/IDPS

AWS Network Firewall / Azure Firewall / Cloud Armor/Cloud IDSなどをハブに置き、東西/南北トラフィックのL3〜L7制御や脅威対策を集中させます。
Gateway Load Balancer（AWS）はファイアウォールアプライアンスのインライン化に便利。

4.4 3クラウド対比（言い換え）

SG ↔ NSG（Azure）／GCP firewall rules
NACL ↔ Azureに近似なし（NSGで代替）／GCP firewallはVPCレベル
Network Firewall ↔ Azure Firewall／GCP Cloud Firewall/IDS

5. インターネット公開は“CDN＆L7 LB経由”が基本

S3/静的配信：CloudFront（GCPはCloud CDN、AzureはFront Door/Azure CDN）でTLS・WAF・キャッシュを前段に。
API/アプリ：ALB（GCP：HTTP(S) LB、Azure：App Gateway）でTLS終端・ルーティング、WAFはLB/CDN側で。
NLB/GLB：L4用途（gRPC/超高スループット/固定IP）。AWS GWLBでセキュリティアプライアンスを挟みやすい。
“直接パブリックIPで実機公開”は避ける：メンテ/ガバナンス/観測が分散し、事故時の切り分けが難しくなります。

6. Private接続の極意：Endpoints/PrivateLinkの使いどころ

Gateway Endpoint（S3/DynamoDB）：NATを通さずにS3/DynamoDBへ到達。データ流出リスク/転送料の抑制に有効。
Interface Endpoint（Powered by PrivateLink）：各種AWSサービス/自社サービスをプライベートIPで呼び出し。Zero Trustの実装に効きます。
GCPはPrivate Service Connect、AzureはPrivate Endpointが相当。**“SaaS含む外部サービスを私設到達”**にする流れは3クラウド共通です。

7. ハイブリッド接続：VPN/専用線/名前解決

Site-to-Site VPN：短期・可用性要件が緩い用途。冗長トンネルで安定性を確保。
専用線（AWS Direct Connect / Google Interconnect / Azure ExpressRoute）：帯域・遅延・SLAが必要な基幹向け。
名前解決：Private Hosted Zone（Route 53）/Cloud DNS/Private DNSで**“どの名前をどこへ”**を明確に。
Split-horizon DNSで同一FQDNの内外切替を扱う場合は、キャッシュ/TTLと境界の監査を忘れずに。

8. IPv6・Egress・ゼロトラスト：2025年の実務ガイド

IPv6：アドレス枯渇回避だけでなく、一方向NATを減らすことでトラブルシュートを簡潔に。ただしEgress制御はより大切に。
Egress制御：宛先FQDN/タグでの許可（PrivateLink/Endpoint/WAF）を組み合わせ、“どこへ出てよいか”を宣言。
ゼロトラスト：IDベース許可（SG/NSG/Firewall）＋mTLS/OIDCで**“誰がどこへ”**を毎回検証。**踏み台レス（SSM/IAP/Bastion JIT）**を前提に。

9. 観測性：Flow Logsと“見える化の4点セット”

VPC Flow Logs：送信元/宛先/ポート/許可/拒否を収集。異常なEgress/ポートスキャンを検知。
Traffic Mirroring：パケットレベルの深掘り。インシデント時の原因究明に有効。
CloudWatch/Cloud Logging/Azure Monitor：ダッシュボードで接続数・拒否数・帯域・遅延を可視化。
CloudTrail/Audit Logs/Activity Log：誰がネットワーク設定を変えたかを追える状態に。
ログ保管は別アカウント/別プロジェクトに集約すると、改ざん耐性が上がります。

10. コスト最適化：Egress/NAT/監査を“賢く”

NAT Gatewayの数と経路：スポーク側に置かず、ハブに集約して経路最短×数最小を狙う。
Endpointsの活用：S3/DynamoDBはGateway EndpointでNAT課金/転送料を削減。
ログの粒度と保持：Flow Logs/Trafficは必要な粒度/保持期間に。集計→要約保管で費用を平準化。
CDNキャッシュ：外向き帯域/オリジン負荷を軽減し、Egress費を抑える。
構成の“型化”：IaC（Terraform/CloudFormation/Bicep/DM）で再現可能な最小構成に固定すると、無駄な部品が増えません。

11. 3クラウド対比（要点表現の言い換え）

仮想ネットワーク：VPC（AWS）／VPC（GCP：グローバル）／VNet（Azure）
セキュリティグループ：SG（AWS）／Firewall rule（GCP）／NSG（Azure）
Privateサービス接続：Interface/Gateway Endpoint・PrivateLink／Private Service Connect／Private Endpoint
NAT/Egress：NAT Gateway／Cloud NAT／NAT Gateway
中央接続：Transit Gateway／VPC Peering＋Cloud Router／Virtual WAN（Hub & Spoke）
ファイアウォール：Network Firewall／Cloud Firewall/IDS／Azure Firewall
ログ：VPC Flow Logs／VPC Flow Logs（GCP）／NSG Flow Logs/NSG Diagnostics

12. 最小セキュア構成（文章図解）

スポークVPC（App/Data）はPrivateサブネットのみ。
ALB/NLBはハブVPCのPublicサブネットに配置。
App→外部はTGW→ハブNAT GW経由。
S3/DynamoDBはGateway Endpoint、他のAWSサービス/社内SaaSはInterface Endpoint/PrivateLink。
SGはALB→App、App→DBの2段で最小許可。
Flow Logsオン＋CloudTrail集約、Network Firewallはハブに。

13. サンプル設定

13.1 セキュリティグループ（最小・ALB経由のみ）

# アプリSG：ALBのSGからの80/443のみ許可、DBへは別SGで
APP_SG=$(aws ec2 create-security-group --group-name app-sg --description "app" --vpc-id vpc-xxx --query GroupId --output text)
ALB_SG=$(aws ec2 create-security-group --group-name alb-sg --description "alb" --vpc-id vpc-xxx --query GroupId --output text)

aws ec2 authorize-security-group-ingress --group-id $APP_SG --protocol tcp --port 80  --source-group $ALB_SG
aws ec2 authorize-security-group-ingress --group-id $APP_SG --protocol tcp --port 443 --source-group $ALB_SG

13.2 ルート表（スポークPrivate→ハブ）

aws ec2 create-route --route-table-id rtb-xxxx --destination-cidr-block 0.0.0.0/0 --transit-gateway-id tgw-xxxx
aws ec2 create-route --route-table-id rtb-xxxx --destination-ipv6-cidr-block ::/0 --transit-gateway-id tgw-xxxx

13.3 Flow Logs（CloudWatch Logs宛て）

aws ec2 create-flow-logs \
  --resource-type VPC --resource-ids vpc-xxxx \
  --traffic-type ALL \
  --log-destination-type cloud-watch-logs \
  --deliver-logs-permission-arn arn:aws:iam::123456789012:role/vpc-flow-logs-role \
  --log-group-name /vpc/flow/prod

14. Terraform概念サンプル（ハブ＆スポークの要点）

# VPC（スポーク）
resource "aws_vpc" "spoke" {
  cidr_block           = "10.64.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true
  tags = { Name = "acme-prod-apne1-spoke" }
}

# Private Subnet（例）
resource "aws_subnet" "spoke_app_a" {
  vpc_id                  = aws_vpc.spoke.id
  cidr_block              = "10.64.16.0/20"
  availability_zone       = "ap-northeast-1a"
  map_public_ip_on_launch = false
  tags = { Name = "app-a" }
}

# Transit Gateway Attachment（ハブ接続）
resource "aws_ec2_transit_gateway_vpc_attachment" "spoke_attach" {
  subnet_ids         = [aws_subnet.spoke_app_a.id]
  transit_gateway_id = aws_ec2_transit_gateway.hub.id
  vpc_id             = aws_vpc.spoke.id
}

15. よくある落とし穴と回避策

CIDR重複：後戻りが難しい失敗。**設計初日に“全社予約表”**を作り、申請フローを整えます。
パブリック直公開：VM/DBを直接晒すと運用が複雑化。ALB/CloudFront/PrivateLinkを前提に。
NAT乱立：各VPCにNATを置きすぎてコスト増。ハブに集約し、Endpointsを活用。
SGとNACLの混同：SG中心で設計し、NACLは補助。**“IDで許可”**を徹底。
ログ未整備：トラブル時に見えない。Flow Logs/CloudTrailを標準装備に。
名前解決の無計画：Private DNS/Hosted Zoneと各環境の命名規約を最初に定義。

16. ケーススタディ（3パターン）

16.1 企業ポータル（インターネット公開＋社内API連携）

構成：ハブVPC（ALB/Firewall/NAT）＋スポークVPC（App/Data）。外部はCloudFront→ALB、内部はPrivateLinkで社内APIへ。
ポイント：Egress集約で監査簡潔、WAFはCDN/L7に集約。Flow Logsは別アカウントに保管。
GCP/Azure：Cloud CDN→HTTP(S) LB／Front Door→App Gateway、PSC/Private Endpointが同発想。

16.2 SaaS基盤（マルチテナント＋ゼロトラスト）

構成：テナント毎にスポークVPCを分離、中央IdP＋mTLS、Interface Endpointで内部SaaSに到達。
ポイント：SGのID参照でテナント間の到達ゼロを担保。監査ログを一箇所に。
GCP/Azure：VPC Peering＋Firewall rules／VNet Peering＋NSG。Private Service Connect/Endpointを活用。

16.3 ハイブリッド（工場/拠点×クラウド）

構成：オンプレはデュアルVPN→将来専用線へ。ルート集約はハブ、工場からのクラウド行きは必要最小経路のみ。
ポイント：Split-horizon DNSと帯域監視、ローカルブレイクアウトの基準を文書化。
GCP/Azure：Cloud Router＋HA VPN／Virtual WAN＋VPN Gatewayで対称構成。

17. 設計チェックリスト（初週で固める10項目）

CIDR/命名規則：全社共有の予約帳と申請フロー。
ハブ＆スポーク方針：どのVPCがハブか、Egress/Firewall/監査の集約先は。
サブネット役割：Public/Private/管理の分離、AZ分散。
経路：0.0.0.0/0はハブ/TGWへ。オンプレ/他クラウドのプレフィックス管理。
SG/NACL：SG中心。NACLは補助。SG→SG参照を標準に。
Endpoints：S3/DynamoDBのGateway、他はInterface/PrivateLink。
DNS：Private Hosted Zone/Private DNSの分割、命名規約、TTL。
観測：Flow Logs/CloudTrail/Traffic Mirroringの運用。保管先は別アカウント。
ゼロトラスト：踏み台レス（SSM/IAP/Bastion JIT）、mTLS/OIDC、最小到達性。
コスト：NAT/Endpoints/ログ保持の見直しサイクル。

18. 運用Runbook（ネットワーク障害の初動）

検知：アプリ経路のp95遅延/特定宛先到達不可/拒否増加をアラートで把握。
切り分け：DNS→SG→ルート表→NAT/Firewall→相手先の順でトレース。Flow Logsで拒否/許可を確認。
一時緩和：**代替経路（予備NAT/別AZ）**を有効化、LBのヘルスチェック閾値を調整。
原因特定：直近のIaC差分/CloudTrailで変更箇所を特定。Traffic Mirroringで深掘り。
恒久策：ルート収束の設計見直し、DNS TTL最適化、SGのID参照の徹底。
ふりかえり：ダッシュボード/Runbook更新、変更審査に“経路影響レビュー”を追加。

19. 想定読者と到達ゴール（具体的に）

情報システム部門（オンプレ統合/拠点多数）
CIDR予約帳・ハブ＆スポーク・Private Endpointの三点で、全社ネットワークの衝突/抜け道を排除。監査ログ集約で審査対応が軽くなります。
SRE/プラットフォームエンジニア
最小セキュア構成の“型”（ALB前段/SG中心/Endpoints）をIaC化し、新規プロダクトを同じ型で即日展開できます。
アプリ開発者
“L7はLB、到達はSG、外へはハブ”の原則で、ネットワーク設計を意識せずとも安全なデプロイが可能に。
セキュリティ/ガバナンス担当
踏み台レス・最小到達性・ゼロトラストを標準化し、人に依存しない監査と変更追跡が整います。
スタートアップCTO/技術リード
小さく始めつつ、ハブ集約とCIDR余裕で成長に合わせた拡張ができます。NAT/ログのコスト管理も仕組み化できます。

20. Q&A（よくある質問）

Q：SGとNACL、どちらを主に使うべきですか？
A：SG中心で設計します。IDベースで許可でき、状態管理（stateful）も自動です。NACLは補助的な境界に留めます。
Q：NAT Gatewayはどこに置くのが良い？
A：ハブに集約してEgressを一本化します。Endpointsの併用でNAT経由を最小化します。
Q：IPv6を使うべき？
A：はい。アドレス余裕・NAT削減のメリットが大きいです。Egress制御と監査を同時に強化してください。
Q：Transit GatewayとVPC Peeringの使い分けは？
A：スケールと運用一元化が必要ならTGW、点と点の単純接続ならPeering。将来の拡張が見えているなら最初からハブ設計が無難です。

21. 付録A：CIDR予約帳テンプレ（抜粋）

環境：dev / stg / prod
VPC：10.64.0.0/16（prod）／10.65.0.0/16（stg）／10.66.0.0/16（dev）
サブネット用途：public-ingress / private-app / private-data / shared-admin
予約ルール：/16単位は重複不可、/19以上の空き確保、申請はチケットで記録。

22. 付録B：ネーミング＆タグ標準（例）

Tags：env=prod、owner=platform、data-classification=internal、egress=hub、zone=apne1
SG名：prod-app-web-in（ALB→App）、prod-app-db-in（App→DB）
RouteTable名：prod-spoke-private-rt（0/0→tgw）

23. 付録C：今日できる3ステップ

VPCのCIDR/サブネット役割/命名規則をドキュメント化し、**“予約帳”**を整備。
Flow Logs/CloudTrailを全VPCで有効化し、別アカウントに集約。
**Endpoints（S3/DynamoDB）**を追加して、NAT経由のEgressとリスクを即日削減。

まとめ：IDで許可し、経路は集約し、監査で“見える”にする

Amazon VPCの設計は、CIDR計画→ハブ＆スポーク→SG中心→Endpoints→観測という順に“型化”すると、安全・拡張・コストのバランスが取れます。
GCP VPCでもAzure VNetでも、Private接続の徹底とEgressの一本化、ログ集約の原則は同じ。アプリはL7に集約し、到達はIDで許可。この筋道さえ外さなければ、チームの規模やクラウドが変わっても壊れないネットワークが育ちます。
次回はAmazon CloudFrontを取り上げ、Cloud CDN（GCP）／Azure Front Doorとの違いを踏まえながら、WAF/オリジン設計/キャッシュ/コストまで“フロントの最適解”を丁寧に深掘りします。どうぞお楽しみに。