VPC・ネットワーキング
Amazon VPC（Virtual Private Cloud）は、AWS上に論理的に分離されたプライベートネットワークを構築するサービスです。VPCはAWSリソースのネットワーク基盤であり、セキュアなクラウドアーキテクチャを設計するための最も重要な概念の一つです。
所要時間
約50分
学べること
- VPCの基本概念とネットワーク設計
- パブリック/プライベートサブネットの使い分け
- セキュリティグループとネットワークACLによるアクセス制御
- VPCピアリング・Transit Gatewayによるネットワーク間接続
- VPCエンドポイントとPrivateLinkによるプライベート通信
前提知識
- TCP/IPネットワーキングの基礎（IPアドレス、サブネット、ポート）
- CIDRブロックの表記法（例: 10.0.0.0/16）
- AWSの基本概念（リージョン、アベイラビリティゾーン）
目次
- VPCの概要
- サブネット設計
- インターネットゲートウェイとNATゲートウェイ
- セキュリティグループ
- ネットワークACL
- VPCピアリングとTransit Gateway
- VPN接続とDirect Connect
- VPCエンドポイントとPrivateLink
- IDサービスでの活用
- まとめ
1. VPCの概要
VPC（Virtual Private Cloud）は、AWS上に作成する仮想的なプライベートネットワーク空間です。オンプレミスのデータセンターにおけるネットワークと同様に、IPアドレス範囲の定義、サブネットの作成、ルートテーブルやゲートウェイの設定を行います。
VPCの主な特徴
| 特徴 | 説明 |
|---|---|
| 論理的分離 | 他のAWSアカウントのネットワークと完全に分離 |
| CIDRブロック | IPv4/IPv6のアドレス範囲を自由に指定 |
| リージョン単位 | 1つのVPCは1つのリージョンに属する |
| AZ横断 | VPC内のサブネットは複数のAZに分散可能 |
| デフォルトVPC | 各リージョンにデフォルトVPCが自動作成される |
VPCの構成要素
VPC (10.0.0.0/16)
├── サブネット（パブリック/プライベート）
├── ルートテーブル
├── インターネットゲートウェイ
├── NATゲートウェイ
├── セキュリティグループ
├── ネットワークACL
└── VPCエンドポイント
CIDRブロックの設計指針
VPC作成時に指定するCIDRブロックは後から変更できないため、慎重に設計する必要があります。
| CIDRブロック | IPアドレス数 | 用途例 |
|---|---|---|
| /16 | 65,536 | 大規模本番環境 |
| /20 | 4,096 | 中規模環境 |
| /24 | 256 | 小規模/開発環境 |
推奨されるプライベートIPアドレス範囲は以下の通りです。
10.0.0.0/8- 大規模ネットワーク向け172.16.0.0/12- 中規模ネットワーク向け192.168.0.0/16- 小規模ネットワーク向け
2. サブネット設計
サブネットは、VPC内のIPアドレス範囲を分割したネットワークセグメントです。各サブネットは1つのアベイラビリティゾーン（AZ）に属します。
パブリックサブネットとプライベートサブネット
| 種類 | インターネット接続 | 用途 |
|---|---|---|
| パブリックサブネット | インターネットゲートウェイ経由で直接通信 | ALB、Bastion Host、NAT Gateway |
| プライベートサブネット | NAT Gateway経由でのみ外向き通信 | アプリケーションサーバー、データベース |
典型的なVPC構成
┌─────────────────────────────────────────────────────────────────┐
│ VPC: 10.0.0.0/16 │
│ │
│ ┌──────────── AZ-a ────────────┐ ┌──────────── AZ-c ──────────┐│
│ │ │ │ ││
│ │ ┌─ Public 10.0.1.0/24 ───┐ │ │ ┌─ Public 10.0.2.0/24 ───┐││
│ │ │ [ALB] [NAT GW] │ │ │ │ [ALB] [NAT GW] │││
│ │ └────────────────────────┘ │ │ └────────────────────────┘ ││
│ │ │ │ ││
│ │ ┌─ Private 10.0.11.0/24 ─┐ │ │ ┌─ Private 10.0.12.0/24 ─┐││
│ │ │ [ECS Tasks] │ │ │ │ [ECS Tasks] │ ││
│ │ │ (idp-server) │ │ │ │ (idp-server) │ ││
│ │ └────────────────────────┘ │ │ └────────────────────────┘ ││
│ │ │ │ ││
│ │ ┌─ Private 10.0.21.0/24 ─┐ │ │ ┌─ Private 10.0.22.0/24 ─┐││
│ │ │ [RDS Primary] │ │ │ │ [RDS Standby] │ ││
│ │ └────────────────────────┘ │ │ └────────────────────────┘ ││
│ └──────────────────────────────┘ └──────────────────────────────┘│
│ │
│ [Internet Gateway] │
└────────────────────────────────────────────────────────────────────┘
│
[Internet]
サブ ネットのCIDR設計例
VPC: 10.0.0.0/16 (65,536 IPs)
AZ-a パブリック: 10.0.1.0/24 (256 IPs) - ALB, NAT GW
AZ-c パブリック: 10.0.2.0/24 (256 IPs) - ALB, NAT GW
AZ-a App層: 10.0.11.0/24 (256 IPs) - ECS Tasks
AZ-c App層: 10.0.12.0/24 (256 IPs) - ECS Tasks
AZ-a DB層: 10.0.21.0/24 (256 IPs) - RDS
AZ-c DB層: 10.0.22.0/24 (256 IPs) - RDS
各サブネットでは、AWSが5つのIPアドレスを予約します（ネットワークアドレス、VPCルーター、DNS、将来使用、ブロードキャスト）。
3. インターネットゲートウェイとNATゲートウェイ
インターネットゲートウェイ（IGW）
インターネットゲートウェイは、VPCとインターネット間の通信を可能にするコンポーネントです。
[Internet] ←→ [IGW] ←→ [パブリックサブネット]
│
ルートテーブル:
0.0.0.0/0 → IGW
パブリックサブネットのルートテーブルにIGWへのルートを追加することで、インターネットとの双方向通信が可能になります。
NATゲートウェイ
NATゲートウェイは、プライベートサブネットのリソースからインターネットへの外向き通信のみを可能にします。外部からの着信は遮断されます。
[Internet] ← [IGW] ← [NAT GW (パブリック)] ← [プライベートサブネット]
│
ルートテーブル:
0.0.0.0/0 → NAT GW
通信フローの比較
パブリックサブネット → Internet:
[EC2] → [ルートテーブル: 0.0.0.0/0→IGW] → [IGW] → [Internet]
プライベートサブネット → Internet:
[ECS] → [ルートテーブル: 0.0.0.0/0→NAT] → [NAT GW] → [IGW] → [Internet]
Internet → パブリックサブネット:
[Internet] → [IGW] → [EC2 (パブリックIP)] ← 可能
Internet → プライベートサブネット:
[Internet] → [IGW] → ??? ← 不可能（NATは外向きのみ）
NATゲートウェイのコスト最適化
NATゲートウェイは時間課金とデータ転送量課金があり、コストが高くなりやすいサービスです。
| 方式 | 構成 | 可用性 | コスト |
|---|---|---|---|
| AZごとにNAT GW | 各AZに1台 | 高い | 高い |
| 共有NAT GW | 1つのAZに集約 | AZ障害で影響 | 低い |
本番環境では各AZにNATゲートウェイを配置し、開発環境では1つに集約するのが一般的です。
4. セキュリティグループ
セキュリティグループは、EC2インスタンスやECSタスクなどのリソースに対するステートフルなファイアウォールです。
ステートフルの意味
インバウンドで許可した通信のレスポンスは、アウトバウンドルールに関係なく自動的に許可されます。
[クライアント] ---(リクエスト)--→ [EC2] ← インバウンドルールで評価
[クライアント] ←--(レスポンス)--- [EC2] ← 自動許可（ステートフル）
セキュリティグループのルール設定例
ALB用セキュリティグループ:
| 方向 | プロトコル | ポート | ソース | 説明 |
|---|---|---|---|---|
| インバウンド | HTTPS | 443 | 0.0.0.0/0 | 外部からのHTTPS |
| インバウンド | HTTP | 80 | 0.0.0.0/0 | HTTP（リダイレクト用） |
アプリケーション用セキュリティグループ:
| 方向 | プロトコル | ポート | ソース | 説明 |
|---|---|---|---|---|
| インバウンド | TCP | 8080 | sg-alb | ALBからのみ許可 |
データベース用セキュリティグループ:
| 方向 | プロトコル | ポート | ソース | 説明 |
|---|---|---|---|---|
| インバウンド | TCP | 5432 | sg-app | アプリからのみ許可 |
セキュリティグループの重要な特徴
- デフォルト拒否: 明示的に許可されていない通信はすべて拒否
- 許可ルールのみ: 拒否ルールは設定できない
- SG参照: ソースにIPアドレスではなく他のセキュリティグループを指定可能
- 複数アタッチ: 1つのリソースに複数のセキュリティグループを関連付け可能
5. ネットワークACL
ネットワークACL（NACL）は、サブネット単位で適用されるステートレスなファイアウォールです。
セキュリティグループとネットワークACLの比較
| 項目 | セキュリティグループ | ネットワークACL |
|---|---|---|
| 適用レベル | インスタンス/ENI | サブネット |
| ステート | ステートフル | ステートレス |
| ルール | 許可のみ | 許可と拒否 |
| ルール評価 | すべてのルールを評価 | 番号順に評価（最初の一致で決定） |
| デフォルト | すべて拒否 | すべて許可（デフォルトNACL） |
| 戻りトラフィック | 自動許可 | 明示的に許可が必要 |
ネットワークACLのルール例
インバウンドルール:
ルール# | タイプ | ポート範囲 | ソ ース | 許可/拒否
100 | HTTPS | 443 | 0.0.0.0/0 | 許可
110 | HTTP | 80 | 0.0.0.0/0 | 許可
120 | TCP | 1024-65535 | 0.0.0.0/0 | 許可 (エフェメラルポート)
* | すべて | すべて | 0.0.0.0/0 | 拒否
アウトバウンドルール:
ルール# | タイプ | ポート範囲 | 宛先 | 許可/拒否
100 | HTTPS | 443 | 0.0.0.0/0 | 許可
110 | TCP | 1024-65535 | 0.0.0.0/0 | 許可 (エフェメラルポート)
* | すべて | すべて | 0.0.0.0/0 | 拒否
ステートレスであるため、アウトバウンドルールでエフェメラルポート（1024-65535）を明示的に許可する必要があります。
使い分けの指針
通常のアクセス制御にはセキュリティグループを使い、ネットワークACLは特定のIPアドレスをサブネットレベルでブロックする場合など、追加の防御層として使用します。
6. VPCピアリングとTransit Gateway
VPCピアリング
VPCピアリングは、2つのVPC間をプライベートIPアドレスで直接接続する機能です。
┌───────────┐ ┌───────────┐
│ VPC-A │◄────────►│ VPC-B │
│ 10.0.0.0 │ ピアリング │ 10.1.0.0 │
│ /16 │ 接続 │ /16 │
└───────────┘ └───────────┘
制約事項:
- CIDRブロックが重複するVPC間ではピアリング不可
- 推移的ルーティング不可（A-B、B-Cのピアリングがあっても、AからCへは通信不可）
- 1対1の接続のため、VPC数が増えると管理が複雑化
Transit Gateway
Transit Gatewayは、複数のVPCやオンプレミスネットワークを中央のハブで接続するサービスです。
┌─────────────────┐
│ Transit Gateway │
└────────┬────────┘
┌──────────────┼──────────────┐
│ │ │
┌─────┴─────┐ ┌─────┴─────┐ ┌─────┴─────┐
│ VPC-Prod │ │ VPC-Dev │ │ VPC-Shared│
│ 10.0.0.0 │ │ 10.1.0.0 │ │ 10.2.0.0 │
│ /16 │ │ /16 │ │ /16 │
└────────────┘ └───────────┘ └───────────┘
VPCピアリング vs Transit Gateway
| 項目 | VPCピアリング | Transit Gateway |
|---|---|---|
| 接続トポロジ | 1対1 | ハブ＆スポーク |
| 推移的ルーティング | 不可 | 可能 |
| 帯域幅 | 制限なし | 最大50 Gbps/AZ |
| コスト | データ転送のみ | 時間課金＋データ転送 |
| 管理の複雑さ | VPC数が多いと煩雑 | 中央管理で簡潔 |
| 適用場面 | VPC数が少ない場合 | 大規模マルチVPC環境 |
7. VPN接続とDirect Connect
Site-to-Site VPN
オンプレミスのネットワークとVPCをインターネット経由のIPsec VPNで接続します。
[オンプレミス] ←──IPsec VPN──→ [Virtual Private Gateway] ←→ [VPC]
(カスタマーGW) (暗号化) (AWS側のGW)
| 項目 | 説明 |
|---|---|
| 暗号化 | IPsecによる暗号化 |
| 帯域幅 | 最大1.25 Gbps/トンネル |
| 冗長性 | 2本のトンネルで冗長化 |
| 導入期間 | 数分で設定可能 |
| コスト | 比較的低コスト |
Direct Connect
専用線でオンプレミスとAWSを接続 するサービスです。
[オンプレミス] ←──専用線──→ [Direct Connect] ←→ [Virtual Private Gateway] ←→ [VPC]
(物理接続) ロケーション
| 項目 | 説明 |
|---|---|
| 帯域幅 | 1 Gbps, 10 Gbps, 100 Gbps |
| レイテンシ | 安定した低レイテンシ |
| 導入期間 | 数週間〜数ヶ月 |
| コスト | ポート時間課金＋データ転送 |
| 暗号化 | デフォルトでは暗号化なし（VPNと組合せ可能） |
VPN vs Direct Connect
| 項目 | Site-to-Site VPN | Direct Connect |
|---|---|---|
| 接続経路 | インターネット | 専用線 |
| 帯域幅 | 最大1.25 Gbps | 最大100 Gbps |
| レイテンシ | 変動あり | 安定 |
| 導入時間 | 数分 | 数週間〜数ヶ月 |
| 暗号化 | IPsec標準 | オプション |
| コスト | 低い | 高い |
| 適用場面 | 即時接続、バックアップ | 高帯域・低レイテンシ要件 |
8. VPCエンドポイントとPrivateLink
VPCエンドポイントは、VPC内のリソースからAWSサービスへの通信をAWSネットワーク内で完結させる機能です。インターネットやNATゲートウェイを経由する必要がなくなります。
Gatewayエンドポイント
S3とDynamoDBでのみ利用可能です。ルートテーブルにエントリを追加する方式で、追加コストはかかりません。
[プライベートサブネット] → [ルートテーブル: S3プレフィックス→VPCE] → [S3]
(AWSネットワーク内で完結)
Interfaceエンドポイント（AWS PrivateLink）
ENI（Elastic Network Interface）をサブネット内に作成し、プライベートIPアドレスで各種AWSサービスにアクセスします。
[プライベートサブネット] → [ENI (プライベートIP)] → [AWSサービス]
(PrivateLink経由)
Gatewayエンドポイント vs Interfaceエンドポイント
| 項目 | Gatewayエンドポイント | Interfaceエンドポイント |
|---|---|---|
| 対応サービス | S3, DynamoDB | ほぼすべてのAWSサービス |
| 仕組み | ルートテーブル | ENI（プライベートIP） |
| コスト | 無料 | 時間課金＋データ転送 |
| AZ配置 | 不要 | サブネットごとに配置 |
| セキュリティグループ | 不可 | 適用可能 |
PrivateLinkのユースケース
PrivateLinkは自社サービスやサードパーティサービスをプライベートに公開するためにも使用できます。
┌──── サービス提供側VPC ────┐ ┌──── サービス利用側VPC ────┐
│ │ │ │
│ [NLB] → [アプリ] │←───→│ [Interface Endpoint] │
│ │ │ (プライベートIP) │
│ エンドポイントサービス │ │ │
└───────────────────────────┘ └───────────────────────────┘
(PrivateLink接続)
9. IDサービスでの活用
idp-serverをAWSにデプロイする場合の典型的なVPC設計を示します。
idp-serverのVPC構成
┌──────────────────────────────────────────────────────────────────┐
│ VPC: 10.0.0.0/16 (idp-platform) │
│ │
│ ┌─────────── AZ-a ─────────────┐ ┌─────────── AZ-c ───────────┐│
│ │ ┌─ Public 10.0.1.0/24 ────┐ │ │ ┌─ Public 10.0.2.0/24 ──┐ ││
│ │ │ [ALB] │ │ │ │ [ALB] │ ││
│ │ │ [NAT Gateway] │ │ │ │ [NAT Gateway] │ ││
│ │ └─────────────────────────┘ │ │ └─────────────────────────┘ ││
│ │ │ │ ││
│ │ ┌─ Private 10.0.11.0/24 ──┐ │ │ ┌─ Private 10.0.12.0/24 ─┐││
│ │ │ [ECS Fargate] │ │ │ │ [ECS Fargate] │││
│ │ │ idp-server:8080 │ │ │ │ idp-server:8080 │││
│ │ └─────────────────────────┘ │ │ └───────────────────────── ┘ ││
│ │ │ │ ││
│ │ ┌─ Private 10.0.21.0/24 ──┐ │ │ ┌─ Private 10.0.22.0/24 ─┐││
│ │ │ [RDS PostgreSQL] │ │ │ │ [RDS PostgreSQL] │││
│ │ │ (Primary) │ │ │ │ (Standby) │││
│ │ └─────────────────────────┘ │ │ └─────────────────────────┘ ││
│ └───────────────────────────────┘ └──────────────────────────────┘│
│ │
│ VPCエンドポイント: │
│ - S3 (Gateway) ← ログ保存、設定ファイル │
│ - ECR (Interface) ← Dockerイメージ取得 │
│ - CloudWatch Logs (Interface) ← ログ送信 │
│ - Secrets Manager (Interface) ← クレデンシャル取得 │
└────────────────────────────────────────────────────────────────────┘
セキュリティグループの設計
IDサービスでは、認証情報や個人データを扱うため、セキュリティグループの設計が特に重要です。
sg-alb (ALB用):
インバウンド: HTTPS/443 ← 0.0.0.0/0
アウトバウンド: TCP/8080 → sg-app
sg-app (ECS Fargate用):
インバウンド: TCP/8080 ← sg-alb
アウトバウンド: TCP/5432 → sg-db
アウトバウンド: HTTPS/443 → VPCエンドポイント
sg-db (RDS用):
インバウンド: TCP/5432 ← sg-app
アウトバウンド: なし
ネットワーク設計のポイント
- ALBはパブリックサブネット: クライアントからのHTTPSリクエストを受信
- ECSタスクはプライベートサブネット: 直接インターネットに公開しない
- RDSはプライベートサブネット: データベースへのアクセスはアプリケーション層からのみ
- VPCエンドポイント: ECR、CloudWatch、Secrets Managerへの通信はNATゲートウェイを経由せずPrivateLink経由で通信
- Multi-AZ構成: idp-serverは認証基盤のため、単一AZ障害でもサービスを継続可能にする
10. まとめ
- VPCはAWS上の仮想プライベートネットワークであり、すべてのリソースのネットワーク基盤
- サブネットをパブリック/プライベートに分離し、セキュリティ境界を明確にする
- セキュリティグループ（ステートフル）とネットワークACL（ステートレス）で多層防御を実現する
- NATゲートウェイにより、プライベートリソースから外部へのアウトバウンド通信のみを許可する
- VPCエンドポイントでAWSサービスへの通信をプライベートに保つ
- Transit Gatewayで大規模なマルチVPC環境を効率的に管理する
次のステップ
- EC2・コンピューティング - VPC内で動作する仮想サーバーについて学ぶ