Amazon VPC 完全ガイド 2026

初心者から実務者向けの包括的解説

Amazon VPC（Virtual Private Cloud） は、AWS クラウド内に論理的に分離されたプライベートネットワーク空間を定義するサービスです。すべての AWS リソースの配置基盤となり、IP アドレス範囲・サブネット・ルートテーブル・セキュリティグループ・ゲートウェイをフルコントロールできます。本ドキュメントは、VPC の概念・設計・実装・運用を体系的に解説する包括的ガイドです。

ドキュメントの目的

本ガイドは以下を対象としています。

初心者向け： VPC とは何か、なぜ必要かを学びたい方
開発者向け： ネットワーク設計・サブネット構成・セキュリティグループを設定したい方
インフラ向け： マルチ VPC・Transit Gateway・ハイブリッド接続を構築したい方
セキュリティ向け： NACL・Security Group・Flow Logs・GuardDuty でセキュリティを実装したい方
意思決定者向け： VPC 設計のベストプラクティス・コスト最適化・リスク評価

2026 年の VPC エコシステム

VPC Lattice GA：サービス間通信の標準化、API Gateway の代替
AWS Cloud WAN：マルチ VPC・オンプレミス接続の統一管理
IPv6 普及促進：デュアルスタック（IPv4+IPv6）の推奨化
Local Zones 拡大：低遅延エッジコンピュート
AWS Outposts：オンプレミス VPC 拡張
Network Firewall 成熟：ネイティブなステートフル検査
AI 統合：Bedrock・SageMaker 通信の最適化

定義

Amazon VPC 公式定義：

“Amazon Virtual Private Cloud (Amazon VPC) enables you to launch AWS resources in a logically isolated virtual network that you’ve defined.”

全 AWS リソース（EC2・RDS・Lambda・ECS 等）はこの VPC 内のサブネットに配置され、ネットワーク分離・セキュリティ・接続性の中心となります。

概要
VPC が解決する課題
主な特徴
アーキテクチャ
CIDR 設計と IP アドレス管理
サブネット種別
主要ユースケース
ルーティング
セキュリティ
VPC Endpoint
NAT
ELB との関係
DNS
VPN・Direct Connect・Transit Gateway
VPC Lattice
Cross-region 接続パターン
他の類似ツールとの比較
クライアントとエコシステム
ベストプラクティス
トラブルシューティング
2025-2026 最新動向
学習リソース
実装例・活用シーン
導入ロードマップ
実装チェックリスト
まとめ
参考文献

概要

初心者向けメモ： VPC は「自分専用のプライベートネットワーク」です。AWS クラウド内に独立した通信空間を作り、リソース（EC2・RDS など）をその中に配置します。パブリック IP は自分で割り当てるか AWS が割り当てるか選べます。

VPC は AWS 全体の基盤です。VPC がなければ、以下は実現できません：

✅ ネットワーク分離による多層セキュリティ
✅ パブリック/プライベートサブネットの設計
✅ セキュリティグループによるインスタンスレベル制御
✅ NACL によるサブネットレベル制御
✅ オンプレミスとの安全な接続
✅ マルチ VPC・マルチリージョン構成
✅ コスト最適化（Endpoint による無駄な NAT 削減）

VPC が存在しない場合の課題

❌ AWS リソースを配置する場所がない ❌ ネットワークセキュリティを制御できない ❌ プライベート IP アドレス範囲を決められない ❌ オンプレミスと安全に接続できない

VPC が解決する課題

課題	非 VPC 環境	VPC 環境
ネットワーク分離	すべてのリソースが同じネットワーク	パブリック/プライベート/VPN 専用をゾーニング
セキュリティグループ	❌ 使用不可	✅ インスタンスレベルステートフルファイアウォール
NACL	❌ 使用不可	✅ サブネットレベルステートレスフィルタリング
プライベートサブネット	❌ 実現不可	✅ インターネット非接続リソース配置可能
VPC Endpoint	❌ 使用不可	✅ 無料（Gateway）で NAT コスト削減
オンプレミス接続	❌ 実現不可	✅ VPN・Direct Connect で安全接続
マルチ VPC 運用	❌ スケールアウト不可	✅ Transit Gateway で集約接続

主な特徴

特徴	説明
ネットワーク分離	IP アドレス範囲を CIDR で定義、複数 AZ・複数リージョン展開
マルチレイヤセキュリティ	Security Group（ステートフル）+ NACL（ステートレス）の 2 層防御
サブネット設計	Public/Private/Isolated/Local Zone/Outpost/Wavelength
ルーティング柔軟性	Route Table で複雑なルーティング、Transit Gateway で大規模接続
VPC Endpoint	Gateway（S3/DynamoDB）と Interface（100+ サービス）で NAT 削減
Flow Logs	ネットワークトラフィック記録、セキュリティ監査・トラブルシューティング
Hybrid Connectivity	VPN・Direct Connect・VPC Peering でシームレス接続
完全制御	IP アドレス・ルーティング・ゲートウェイをフルコントロール可能
スケーラビリティ	Cloud WAN・VPC Lattice で大規模ネットワーク管理
コスト最適化	Gateway Endpoint 無料化で NAT コスト削減

アーキテクチャ

初心者向けメモ： VPC は 3 層構造です。Region（地域）内に VPC があり、VPC 内に複数の AZ（可用性ゾーン）があり、各 AZ に複数のサブネットがあります。どの AZ がダウンしても動作するよう、各 AZ に NAT Gateway・ALB を配置するのが基本です。

【図1】VPC の基本的なマルチ AZ アーキテクチャ：

graph TB
    subgraph Region["AWS Region"]
        subgraph AZ_A["Availability Zone A"]
            PublicSub_A["Public Subnet<br/>10.0.1.0/24"]
            PrivateSub_A["Private Subnet<br/>10.0.2.0/24"]
            IGW_A["IGW"]
            NAT_A["NAT Gateway<br/>+ EIP"]
            ALB_A["ALB"]
            EC2_A["EC2 Instance"]
            RDS_A[("RDS Replica")]
        end
        subgraph AZ_B["Availability Zone B"]
            PublicSub_B["Public Subnet<br/>10.0.11.0/24"]
            PrivateSub_B["Private Subnet<br/>10.0.12.0/24"]
            IGW_B["IGW"]
            NAT_B["NAT Gateway<br/>+ EIP"]
            ALB_B["ALB"]
            EC2_B["EC2 Instance"]
            RDS_B[("RDS Primary")]
        end
    end

    Internet["Internet"]
    OnPrem["On-Premises"]

    Internet -->|Port 443| IGW_A
    Internet -->|Port 443| IGW_B
    
    IGW_A <--> PublicSub_A
    IGW_B <--> PublicSub_B
    
    PublicSub_A --> NAT_A
    PublicSub_B --> NAT_B
    
    NAT_A --> PrivateSub_A
    NAT_B --> PrivateSub_B
    
    PrivateSub_A --> EC2_A
    PrivateSub_B --> EC2_B
    
    EC2_A -.-> RDS_A
    EC2_B -.-> RDS_B
    
    OnPrem -->|VPN/Direct Connect| PublicSub_B

    style IGW_A fill:#ffcccc
    style IGW_B fill:#ffcccc
    style NAT_A fill:#ccffcc
    style NAT_B fill:#ccffcc
    style RDS_A fill:#ccccff
    style RDS_B fill:#ccccff

構成要素：

Region：地理的位置（us-east-1 など）
Availability Zone（AZ）：Region 内の物理的に独立したデータセンター
VPC：CIDR ブロック（例：10.0.0.0/16）で定義されたプライベートネットワーク
Subnet：AZ 内のサブネットワーク（例：10.0.1.0/24）
Route Table：トラフィックのルーティング規則
Internet Gateway（IGW）：インターネット接続
NAT Gateway：プライベートサブネットのアウトバウンド
VPN Gateway：オンプレミス接続

CIDR 設計と IP アドレス管理

初心者向けメモ： VPC を作るときに、最初に IP アドレス範囲を決めます。この範囲は後から変更できないため、十分に広い範囲を確保します。通常 /16（65,000 アドレス）以上を推奨します。

CIDR 記法

10.0.0.0/16 → 10.0.0.0 ～ 10.255.255.255（65,536 アドレス）
10.0.0.0/24 → 10.0.0.0 ～ 10.0.0.255（256 アドレス）
172.16.0.0/12 → 172.16.0.0 ～ 172.31.255.255（1,048,576 アドレス）

VPC CIDR 選定ガイドライン

規模	推奨 CIDR	リソース数目安
スモール	/24 ～ /22	～100 インスタンス
ミディアム	/20 ～ /18	～1000 インスタンス
ラージ	/16 以上	1000+ インスタンス

設計の原則：

✅ /16 以上の予約：後のスケール・追加 VPC との接続を考慮 ✅ RFC1918 範囲の使用：10.0.0.0/8・172.16.0.0/12・192.168.0.0/16 ✅ サブネット予約：VPC サイズの 1/4 ～ 1/2 を予備に確保 ✅ 重複回避：VPC Peering・Direct Connect で他 VPC・オンプレとの重複を確認

AWS IPAM（IP Address Manager）

2023 年以降、AWS が提供する IPAM で複数 VPC の IP 管理を一元化：

graph LR
    IPAM["AWS IPAM<br/>Central IP管理"]
    VPC1["VPC 1<br/>10.0.0.0/16"]
    VPC2["VPC 2<br/>10.1.0.0/16"]
    VPC3["VPC 3<br/>10.2.0.0/16"]
    
    IPAM -->|自動割当| VPC1
    IPAM -->|自動割当| VPC2
    IPAM -->|自動割当| VPC3

IPAM の利点：

✅ マルチ VPC・マルチアカウントの IP 統一管理
✅ 自動 CIDR 割当
✅ 重複検出
✅ 監査ログ

サブネット種別

初心者向けメモ： サブネットは AZ ごとに異なります。「同じサブネットを複数 AZ に広げる」ことはできません。高可用性を実現するには、各 AZ に別々のサブネットを作ります。

標準的なサブネット

タイプ	ルート	特徴	配置リソース
Public	0.0.0.0/0 → IGW	インターネット接続	ALB, NAT GW, Bastion
Private	0.0.0.0/0 → NAT GW	アウトバウンドのみ	EC2, RDS, Lambda VPC
Isolated	local のみ	外部通信なし	DynamoDB, ElastiCache

拡張サブネット

タイプ	説明	ユースケース
Local Zones	Region の極近い延長、超低遅延	ML/Media/IoT（遅延シビア）
Outposts	オンプレミス内 AWS ハードウェア	ハイブリッド・規制要件
Wavelength Zones	5G キャリア内エッジ	5G アプリ・超低遅延

主要ユースケース

初心者向けメモ： VPC 設計は本当に多様です。Web アプリ、ハイブリッド、マイクロサービス、データレイク、CI/CD、機械学習など、ほぼすべての AWS ワークロードが VPC を必要とします。ここでは代表的なパターン 15 個を整理します。

1. 3 層 Web アプリケーション（最も典型）

構成：

Internet → ALB（パブリック） → EC2/ECS（プライベート） → RDS（分離）

VPC 設計：

Web 層：パブリックサブネット（ALB）
App 層：プライベートサブネット（EC2/ECS）
DB 層：分離サブネット（RDS - マルチ AZ）

Security Group 設定：

ALB SG：インバウンド 443 from 0.0.0.0/0
App SG：インバウンド 8080 from ALB SG
DB SG：インバウンド 5432 from App SG

2. ハイブリッド接続（企業向け）

構成：

On-Premises ← Direct Connect（推奨） → VPC
または VPN

用途：

オンプレミス DB ↔ AWS 分析環境
段階的なクラウド移行
ディザスタリカバリー

3. マイクロサービス（大規模）

構成：

VPC Lattice による Service-to-Service 通信
マルチ VPC + Transit Gateway

利点：

サービス間通信を API Gateway なしで実現
自動スケーリング
組み込みロードバランシング

4. データレイク（分析）

構成：

IoT/ログ → S3（プライベートアクセス） → Athena/Glue → QuickSight
VPC Endpoint Gateway でインターネット経由排除

コスト最適化：

✅ S3 Gateway Endpoint で NAT コスト削減（月 20～100+）
✅ DynamoDB Gateway Endpoint で無料化

5. CI/CD パイプライン

構成：

CodePipeline → CodeBuild（VPC 内） → ECR → ECS/EKS

セキュリティ：

ビルド環境をプライベートサブネット内で実行
GitHub/GitLab との通信は VPC Endpoint 経由

6. Bastion/Jump Host パターン

構成：

Internet → Bastion（パブリック） → Private EC2

用途：

プライベートサブネット内 EC2 への管理アクセス
Session Manager（IAM ベース）の代替

7. SaaS マルチテナント（顧客隔離）

構成：

各テナント用専用 VPC → Transit Gateway → 共有 VPC（認証・ログ）

メリット：

顧客ごとに IP アドレス空間を分離
セキュリティ・コンプライアンス強化

8. 機械学習・SageMaker

構成：

SageMaker → Private Subnet → S3（Gateway Endpoint） → DynamoDB

セキュリティ：

✅ Training は VPC 内で実行
✅ Endpoint は VPC 内配置
✅ Inference トラフィックを完全に制御

9. IoT・センサーデータ集約

構成：

IoT → IoT Core → Kinesis → Lambda（VPC） → RDS/DynamoDB

10. ディザスタリカバリー（DR）

構成：

Primary Region（VPC A） ← Route 53 → Secondary Region（VPC B）

フェイルオーバー：

Route 53 ヘルスチェック + DNS フェイルオーバー
VPC Peering で Cross-Region 接続

11. Kubernetes（EKS）

構成：

EKS Control Plane（AWS 管理） → Worker Nodes（プライベートサブネット）

VPC 要件：

各 Worker は最低 /24 サブネット
Security Group で Pod ↔ Pod 通信許可

12. ゼロトラスト・セキュリティ

構成：

Flow Logs → CloudWatch Logs → Lambda（異常検知）
GuardDuty + Security Hub 統合
Network Firewall で DPI・IDS/IPS

13. VPC Peering によるマルチ VPC（レガシー）

構成：

VPC A ↔ VPC B（推移的ルーティング不可）

制限：

推移的ルーティング不可（A-B・B-C でも A-C 接続不可）
Transit Gateway を推奨

14. マルチリージョン・アクティブアクティブ

構成：

Region A（VPC） ← Direct Connect → Region B（VPC）

Route 53 ゲオロケーション：

最寄りリージョンへルーティング
低遅延・冗長性

15. コンテナレジストリ（ECR）とのプライベート連携

構成：

ECS → ECR（VPC Endpoint Interface） → コンテナイメージ取得

NAT Gateway 削減：

NAT なしで ECR イメージをプル（コスト $0.00）

ルーティング

初心者向けメモ： Route Table はサブネットの「交通整理」です。「このアドレスへのトラフィックはこっちのゲートウェイへ」という指示を書きます。VPC の中の通信（local）は自動的に許可されます。

Route Table の基本

Destination         | Target           | 説明
--------------------|------------------|-----
10.0.0.0/16（local）| local            | VPC 内通信（変更不可）
0.0.0.0/0           | igw-xxxxx        | インターネット(Public Subnet)
0.0.0.0/0           | nat-xxxxx        | NAT(Private Subnet)
172.16.0.0/16       | pcx-xxxxx        | Peering
192.168.0.0/16      | vgw-xxxxx        | VPN/Direct Connect

複雑なルーティング：Transit Gateway

【図2】Transit Gateway による複数 VPC・オンプレ接続：

graph TB
    subgraph Region["AWS Region"]
        VPC1["VPC A<br/>10.0.0.0/16"]
        VPC2["VPC B<br/>10.1.0.0/16"]
        VPC3["VPC C<br/>10.2.0.0/16"]
        TGW["Transit Gateway<br/>（中央ハブ）"]
    end
    OnPrem["On-Premises<br/>192.168.0.0/16"]
    VPN["VPN Connection"]

    VPC1 <-->|TGW Attachment| TGW
    VPC2 <-->|TGW Attachment| TGW
    VPC3 <-->|TGW Attachment| TGW
    TGW <-->|VPN Attachment| VPN
    VPN <-->|Site-to-Site| OnPrem

    style TGW fill:#ffcccc
    style OnPrem fill:#ccffcc

Transit Gateway の利点：

✅ N 個 VPC を 1 つのハブで接続（O(N) ではなく O(1)）
✅ ルーティング TABLE で通信制御
✅ オンプレミス接続も統一管理
✅ マルチアカウント対応

VPC Peering（レガシー）

制約：

❌ 推移的ルーティング不可
❌ CIDR 重複不可

使用シーン：

VPC 数が少ない（2～3 個）
Transit Gateway は高額な場合

セキュリティ

初心者向けメモ： VPC セキュリティは 2 層構造です。下層（インスタンス）を Security Group で、上層（サブネット）を NACL で制御します。ステートフル（SG）とステートレス（NACL）の違いに注意。

Security Group（SG）

特性	説明
スコープ	ENI（ネットワークインターフェース）単位
ステート	ステートフル（往路許可 → 復路も自動許可）
デフォルト	インバウンド全拒否、アウトバウンド全許可
参照	他の SG を参照可能（セグメンテーション）
評価順序	ルール間に優先度なし（全マッチで許可）

代表的な SG ルール例：

Web Tier SG:
  Inbound: TCP 443 from 0.0.0.0/0（外部ユーザー）
  Inbound: TCP 22 from 203.0.113.0/24（Admin）
  Outbound: TCP 8080 to App Tier SG（App 層へ）

App Tier SG:
  Inbound: TCP 8080 from Web Tier SG
  Outbound: TCP 5432 to DB Tier SG（DB へ）

DB Tier SG:
  Inbound: TCP 5432 from App Tier SG
  Outbound: ❌ すべて拒否（Egress 不要）

Network ACL（NACL）

特性	説明
スコープ	サブネット単位
ステート	ステートレス（往路・復路を独立して定義）
ルール番号	100, 200, 300…の昇順で評価（最初にマッチで決定）
デフォルト	すべて許可（カスタム NACL はすべて拒否）

NACL 設計ガイドライン：

Inbound Rules:
  100: TCP 443 from 0.0.0.0/0
  110: TCP 1024-65535 from 0.0.0.0/0（エフェメラルポート）
  120: TCP 22 from 203.0.113.0/24（Admin）
  *: すべて拒否（Default）

Outbound Rules:
  100: TCP 443 to 0.0.0.0/0
  110: TCP 1024-65535 to 0.0.0.0/0（エフェメラルポート）
  *: すべて拒否（Default）

SG と NACL の使い分け：

シーン	SG	NACL
インスタンス間通信制御	✅	△（冗長）
サブネット境界防御	△	✅
DDoS 軽減	△	△
複雑なルール	✅（参照ベース）	△（ルール番号）

VPC Flow Logs

【機能】

ENI のトラフィック → CloudWatch Logs / S3 / Kinesis Firehose

記録形式：

version account-id interface-id srcaddr dstaddr srcport dstport 
protocol packets bytes start end action log-status

例：
2 123456789012 eni-1234567 10.0.1.2 10.0.2.3 60000 5432 6 100 8000 
1620000000 1620000060 ACCEPT OK

用途：

✅ セキュリティ調査（疎通確認、ブロック検証）
✅ ネットワークトラブルシューティング
✅ コンプライアンス監査
✅ 異常検知（高トラフィック、DDoS）

AWS GuardDuty（ネットワーク脅威検知）

Flow Logs + DNS Logs + API Calls → 機械学習 → 脅威検知

検知例：

Cryptomining
Bot 感染
異常な API 呼び出し

AWS Network Firewall

VPC → Network Firewall → IGW/NAT

機能：

✅ ステートフル検査（Stateful）
✅ IDS/IPS（侵入検知・防止）
✅ DPI（Deep Packet Inspection）
✅ URL フィルタリング

VPC Endpoint

初心者向けメモ： VPC Endpoint を使うと、NAT Gateway を経由せずに AWS サービスにアクセスできます。特に S3 は 1 ヶ月で数万円のデータ転送料金が削減できるので重要です。

ゲートウェイエンドポイント（Gateway Endpoint）

対応サービス：

S3
DynamoDB

構成：

VPC（Private Subnet） → Gateway Endpoint → S3 / DynamoDB
（インターネット経由なし、NAT Gateway 不要）

実装方法：

Route Table に以下のエントリを追加：

Destination: s3.ap-northeast-1.amazonaws.com
Target: vpce-xxxxxx（Gateway Endpoint）

S3 バケットポリシーで VPC Endpoint の使用を強制（推奨）：

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Deny",
    "Principal": "*",
    "Action": "s3:*",
    "Resource": ["arn:aws:s3:::my-bucket/*"],
    "Condition": {
      "StringNotEquals": {
        "aws:SourceVpce": "vpce-xxxxxx"
      }
    }
  }]
}

コスト削減効果：

NAT Gateway：$0.045/GB（データ転送）
Gateway Endpoint：無料
月 100GB S3 アクセス = $45 削減

インターフェースエンドポイント（Interface Endpoint）

対応サービス：

100+ AWS サービス（EC2, SQS, SNS, Secrets Manager, Systems Manager, RDS, Glue, Lambda など）

構成：

VPC → Interface Endpoint（ENI） → AWS Service

【図3】Interface Endpoint の詳細構成：

graph LR
    VPC["VPC<br/>10.0.0.0/16"]
    Subnet["Private Subnet<br/>10.0.2.0/24"]
    ENI["Interface Endpoint<br/>（ENI - プライベート IP）"]
    EC2["EC2 Instance<br/>10.0.2.10"]
    Service["AWS Service<br/>（EC2, RDS など）"]
    
    VPC -->|contains| Subnet
    Subnet -->|contains| ENI
    Subnet -->|contains| EC2
    EC2 -->|calls via DNS| ENI
    ENI -->|connects to| Service
    
    style ENI fill:#ffcccc
    style Service fill:#ccccff

料金：

時間料金：$0.01/時間
データ処理料金：$0.01/GB

設定例（Secrets Manager）：

# Interface Endpoint 作成
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-xxxxx \
  --service-name com.amazonaws.ap-northeast-1.secretsmanager \
  --vpc-endpoint-type Interface \
  --subnet-ids subnet-xxxxx subnet-yyyyy

PrivateLink

Gateway Endpoint と Interface Endpoint は AWS 内部用です。カスタムサービス（自社アプリ）を VPC 経由で提供するには AWS PrivateLink を使用：

Provider VPC → NLB → PrivateLink → Consumer VPC

NAT

初心者向けメモ： NAT（Network Address Translation）は、プライベートサブネットのリソースがインターネットに出るための「出口」です。戻ってきた応答も NAT が処理します。

NAT Gateway

特徴：

AWS 管理サービス（スケーリング自動）
マネージドで信頼性高い
時間料金 + データ転送料金

配置パターン：

High-Availability（推奨）:
  AZ-A: Private Subnet → NAT GW（EIP in Public） → IGW
  AZ-B: Private Subnet → NAT GW（EIP in Public） → IGW
  
Cost-Optimized（非本番）:
  AZ-A: Private Subnet → NAT GW in AZ-B（クロス AZ 通信料発生）

価格例（ap-northeast-1）：

NAT Gateway 時間料金：0.03/時間 × 24 × 30 ≈ 21.60/月
データ処理：$0.045/GB（最初の 100GB まで）
2 つ NAT GW = 月 $50+

NAT Instance

特徴：

EC2 インスタンス（自分で管理）
コスト安い（EC2 料金のみ）
スケーリング・HA は自分で実装

非推奨な理由：

AWS が NAT Gateway を推奨
トラブルシューティング困難
パフォーマンス制限

アウトバウンド IP の固定

シーン：

API が呼び出し元 IP をホワイトリスト登録している場合

実装：

NAT Gateway → Elastic IP（固定 IP）

Elastic IP は NAT Gateway に割り当てることで、アウトバウンド送信元を固定化できます。

ELB との関係

初心者向けメモ： ロードバランサーはサブネットに配置され、VPC に密接に関連しています。ALB・NLB・GLB それぞれ異なるユースケースがあります。

ALB（Application Load Balancer）

配置：

パブリックサブネット（ALB） → プライベートサブネット（EC2/ECS）

特徴：

Layer 7（HTTP/HTTPS）
ホスト・パス・クエリベースのルーティング
最も一般的

VPC 設定：

ALB Subnet: Public（10.0.1.0/24, 10.0.11.0/24）
Target Subnet: Private（10.0.2.0/24, 10.0.12.0/24）
SG: ALB ← 0.0.0.0/0:443, Targets ← ALB SG:8080

NLB（Network Load Balancer）

配置：

TCP/UDP 高スループット用（Gaming, Real-time, DNS等）

特徴：

Layer 4（TCP/UDP）
極低遅延・高スループット
Million RPS 対応

用途：

ゲーム（マルチプレイヤー）
リアルタイム通信
DNS・RADIUS 等

GLB（Gateway Load Balancer）

配置：

VPC トラフィック → GLB → Third-party 仮想アプライアンス

用途：

ファイアウォール検査
侵入検知
ロードバランシング

DNS

初心者向けメモ： VPC 内の EC2 は、DNS で自動的に Private IP でアクセスできます。例：ip-10-0-2-5.ap-northeast-1.compute.internal

DNS 機能

機能	説明
DNS Hostnames	VPC 内インスタンスにプライベート DNS 名を自動割り当て
DNS Resolution	Route 53 Resolver が VPC 内 DNS クエリを処理
Private Hosted Zone	VPC 専用の内部 DNS 名前解決（Route 53）
Resolver Endpoints	オンプレミス ↔ VPC 間 DNS クエリ転送

Resolver Endpoints（ハイブリッド）

用途：

オンプレミス DNS サーバーから VPC リソースへの名前解決
VPC からオンプレ DNS サーバーへの照会
On-Premises DNS → VPC Resolver Endpoint Inbound → VPC リソース
VPC リソース → VPC Resolver Endpoint Outbound → On-Premises DNS

VPN・Direct Connect・Transit Gateway

初心者向けメモ： ハイブリッド接続には 3 つの方法があります。VPN は安い・遅い、Direct Connect は高い・速い、Transit Gateway は大規模向け。

Site-to-Site VPN

特徴：

インターネット経由の暗号化接続
セットアップ簡単、コスト安い
レイテンシ高い（100+ ms）

構成：

On-Premises VPN Device ← Tunnel ← VPC（VPN Gateway）

料金：

VPN Connection：0.05/時間 × 24 × 30 ≈ 36/月
データ転送は通常料金

AWS Direct Connect

特徴：

専用線（インターネット非経由）
低遅延（1～10ms）
セットアップ 1 ～ 3 ヶ月、コスト高い

料金：

ポート時間料金：$0.30/時間（1Gbps）
月 $216+

用途：

金融機関・大規模企業
低遅延・高スループット必須

AWS Cloud WAN（新しい統一管理）

Global Network（AWS管理） ← VPC ← Cloud WAN Core Network
← On-Premises
← Branch Office

利点：

✅ マルチ VPC・マルチリージョンを統一管理
✅ VPN・Direct Connect 統合
✅ セキュリティポリシー一元化

VPC Lattice

初心者向けメモ： VPC Lattice は最新機能で、マイクロサービス間の通信を簡単にします。API Gateway の代替になる可能性があります。

特徴：

Service A → VPC Lattice → Service B
（内部通信、External NLB不要）

メリット：

✅ API Gateway なしでサービス間通信
✅ 自動スケーリング
✅ 組み込みロードバランシング
✅ マルチ VPC・マルチアカウント対応

【図4】VPC Lattice によるマイクロサービス通信：

graph TB
    subgraph VPC1["VPC A"]
        Service_A["Service A<br/>（ECS）"]
    end
    subgraph VPC2["VPC B"]
        Service_B["Service B<br/>（ECS）"]
    end
    subgraph VPC3["VPC C"]
        Service_C["Service C<br/>（Lambda）"]
    end
    
    Lattice["VPC Lattice<br/>Service Network"]
    
    Service_A -->|Register| Lattice
    Service_B -->|Register| Lattice
    Service_C -->|Register| Lattice
    
    Service_A -->|Call Service B| Lattice
    Service_A -->|Call Service C| Lattice
    Service_B -->|Call Service A| Lattice
    
    style Lattice fill:#ffcccc

Cross-Region 接続パターン

パターン	構成	用途	コスト
Route 53（ルーティング）	DNS フェイルオーバー	DR、低遅延エンドユーザー	$0.50/100万 Query
VPC Peering	Region A ↔ Region B	小規模・限定的	データ転送料金
Transit Gateway Peering	TGW-A ↔ TGW-B	マルチ VPC・マルチ Region	Route 53 + TGW
Direct Connect Virtual Interface	専用線で複数 VPC	大規模・高スループット	Direct Connect 基本料

他の類似ツールとの比較

項目	AWS VPC	Azure VNet	GCP VPC
IP アドレス範囲	CIDR 自由	CIDR 自由	CIDR 自由
ルーティング	Route Table	Route Table	Cloud Router
ファイアウォール	SG + NACL	NSG（単一）	Firewall Rules
Endpoint	Gateway/Interface	Service Endpoint	Private Service Connection
マルチ VPC 接続	Transit Gateway	Virtual Network Peering	VPC Peering（制限）
ハイブリッド接続	VPN / DX	VPN / ExpressRoute	Cloud Interconnect
プライベート DNS	Route 53 PZ	Private DNS Zone	Cloud DNS

結論：

AWS VPC：最も柔軟・スケーラブル（Transit Gateway）
Azure VNet：クラウドネイティブ・統合管理
GCP VPC：シンプル・学習コスト低い

クライアントとエコシステム

AWS Management Console

Web UI で VPC・Subnet・SG を管理。

AWS CLI

# VPC 作成
aws ec2 create-vpc --cidr-block 10.0.0.0/16

# Subnet 作成
aws ec2 create-subnet \
  --vpc-id vpc-xxxxx \
  --cidr-block 10.0.1.0/24 \
  --availability-zone ap-northeast-1a

# Route Table 設定
aws ec2 create-route \
  --route-table-id rtb-xxxxx \
  --destination-cidr-block 0.0.0.0/0 \
  --gateway-id igw-xxxxx

Terraform（Infrastructure as Code）

# VPC
resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
  tags = { Name = "main-vpc" }
}

# Public Subnet
resource "aws_subnet" "public" {
  vpc_id                  = aws_vpc.main.id
  cidr_block              = "10.0.1.0/24"
  availability_zone       = "ap-northeast-1a"
  map_public_ip_on_launch = true
}

# Internet Gateway
resource "aws_internet_gateway" "main" {
  vpc_id = aws_vpc.main.id
}

# Route Table
resource "aws_route_table" "public" {
  vpc_id = aws_vpc.main.id
  
  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.main.id
  }
}

AWS CDK（TypeScript/Python）

import * as ec2 from 'aws-ec2';

const vpc = new ec2.Vpc(this, 'MyVpc', {
  cidr: '10.0.0.0/16',
  maxAzs: 2,
  natGateways: 1,
});

const publicSubnet = new ec2.PublicSubnet(this, 'PublicSubnet', {
  vpcId: vpc.vpcId,
  cidrBlock: '10.0.1.0/24',
});

Reachability Analyzer

EC2 A → EC2 B への疎通確認
（実際のトラフィック送信なしで検証可能）

用途：

✅ 設定後の検証
✅ トラブルシューティング
✅ セキュリティ監査

AWS Network Manager

マルチ VPC・オンプレミス・ブランチオフィスの統一ネットワーク可視化。

ベストプラクティス

1. CIDR 設計（最初が肝心）

✅ 十分に広い範囲を予約： /16 以上推奨 ✅ RFC1918 使用： 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 ✅ 重複確認： VPC Peering・Direct Connect 前に他 VPC・オンプレとの重複を確認 ✅ IPAM 活用： マルチ VPC・マルチアカウント管理

❌ 後から CIDR 変更：できません（VPC 再作成必須）

2. マルチ AZ 構成（高可用性）

✅ 各 AZ に NAT Gateway： AZ 障害時のアウトバウンド確保 ✅ 各 AZ に Subnet： リソースを複数 AZ に分散 ✅ ゾーン冗長 RDS： Multi-AZ デプロイ推奨

3. セキュリティグループの最小権限

✅ 必要最小限のみ許可： “すべて許可” は禁止 ✅ SG を参照： IP アドレスより参照が柔軟（動的スケーリング対応） ✅ 説明を記載： 「何のために許可か」を明記

❌ Bad:
  Inbound: TCP 0-65535 from 0.0.0.0/0（全ポート許可）

✅ Good:
  Inbound: TCP 443 from 0.0.0.0/0（HTTPS のみ）
  Inbound: TCP 8080 from web-sg（App Tier から）

4. Flow Logs の有効化

✅ CloudWatch Logs に記録： セキュリティ監査・トラブルシューティング ✅ S3 に保存： 長期保存・コンプライアンス（Athena で分析可）

# VPC Flow Logs 有効化
aws ec2 create-flow-logs \
  --resource-type VPC \
  --resource-ids vpc-xxxxx \
  --traffic-type ALL \
  --log-destination-type cloud-watch-logs

5. VPC Endpoint の活用（コスト最適化）

✅ S3 Gateway Endpoint： NAT Gateway の S3 通信を削減（月 20～100+） ✅ DynamoDB Gateway Endpoint： NAT Gateway 無駄排除

6. Transit Gateway の使用（マルチ VPC）

✅ VPC 数が 3 以上： Transit Gateway は必須（VPC Peering の複雑性回避） ✅ オンプレ接続： Transit Gateway で VPN・Direct Connect 統一管理

❌ VPC Peering の過度使用： N VPC で N*(N-1)/2 個の接続が必要（運用困難）

7. ハイブリッド接続（段階的採用）

✅ VPN から開始： 低コスト、セットアップ簡単（実装 1 日） ✅ Direct Connect に移行： 低遅延・高スループット必須時（実装 1～3 ヶ月）

8. Cloud WAN（新規構築）

✅ 新規マルチ VPC・マルチ Region： Cloud WAN で統一管理 ✅ 中央セキュリティポリシー： Network Firewall 統合

9. DNS 設計

✅ Private Hosted Zone： VPC 専用の内部 DNS（Route 53） ✅ Resolver Endpoints： ハイブリッド環境での DNS 統合

10. セキュリティのレイヤー化

Layer 1: Security Group（インスタンス）
         ↓
Layer 2: NACL（サブネット）
         ↓
Layer 3: Network Firewall（VPC）
         ↓
Layer 4: GuardDuty（脅威検知）

✅ すべてのレイヤーを活用して多層防御を実装

トラブルシューティング

EC2 → RDS の疎通失敗

原因の調査順：

Security Group 確認：

# RDS SG にアプリ層 SG からのアクセスを許可？
# ポート（MySQL:3306, PostgreSQL:5432）開放？

NACL 確認：

# RDS が配置されたサブネットの NACL で許可？
# エフェメラルポート（1024-65535）の復路許可？

Route Table 確認：

# RDS サブネット・Routing が適切？

Reachability Analyzer で検証：

aws ec2 describe-network-interfaces \
  --filters "Name=vpc-id,Values=vpc-xxxxx"

# EC2 → RDS への到達性確認

Flow Logs 確認：

# CloudWatch Logs で REJECT を確認
# どの層（SG/NACL）で拒否されているか特定

インターネット到達性がない

確認項目：

✅ Public Subnet に IGW のルート？
✅ EC2 が Elastic IP または Public IP をもつ？
✅ EC2 の SG でアウトバウンド許可？
✅ NACL でアウトバウンド許可？
✅ Instance Metadata Service v2（IMDSv2）が原因でない？

VPN 接続が不安定

確認項目：

✅ Tunnel Up/Down をチェック（CloudWatch Metrics）
✅ BGP ネイバーシップ確立？（DX 場合）
✅ ルート伝播設定？
✅ オンプレミス VPN デバイスのログ確認

2025-2026 最新動向

VPC Lattice のGA化

マイクロサービス間の通信を簡素化、API Gateway の代替として注目。

Before: ALB → VPC → ALB（複雑）
After: VPC Lattice Service Network（シンプル）

Cloud WAN の拡大

マルチ VPC・オンプレ・ブランチオフィスを統一管理。

IPv6 普及加速

デュアルスタック（IPv4+IPv6）の推奨化、IPv4 アドレス枯渇対応。

Local Zones 拡大

低遅延エッジコンピュート（ML・Media・Real-time）対応地域拡大。

AI との統合

Bedrock・SageMaker 通信の VPC 最適化、Trainium・Inferentia チップ向け VPC 設計。

Outposts の成熟

オンプレミス内 AWS ハードウェア、VPC を物理的に拡張。

Network Firewall 成熟

DPI（Deep Packet Inspection）・IDS/IPS 機能強化、ENI レベル検査。

学習リソース

公式ドキュメント

Hands-on Learning

AWS Skill Builder：VPC 基礎コース
CloudAcademy：VPC 設計パターン
Linux Academy：Transit Gateway 実装

認定資格

AWS Certified Solutions Architect（SA）：VPC が出題必須
AWS Certified SysOps Administrator（SOA）：VPC 運用・トラブルシューティング

実装例・活用シーン

シーン 1：WordPress（3 層 Web）

Internet → ALB（Public） → EC2（Private）→ RDS（Isolated）

VPC 設計：

VPC：10.0.0.0/16
Public Subnet：10.0.1.0/24, 10.0.11.0/24（各 AZ）
Private Subnet：10.0.2.0/24, 10.0.12.0/24（EC2）
Isolated Subnet：10.0.3.0/24, 10.0.13.0/24（RDS）

シーン 2：Kubernetes（EKS）

Internet → ALB（Public）→ EKS Workers（Private）→ Services

VPC 要件：

Node per /24 subnet（CNI プラグイン）
VPC CNI（Container Network Interface）で Pod に IP 割り当て
Security Group で Pod ↔ Pod 通信制御

シーン 3：ハイブリッド（金融）

On-Premises（192.168.0.0/16）←─ Direct Connect ─→ AWS VPC（10.0.0.0/16）

実装：

Direct Connect Virtual Interface（プライベート）
VPN（バックアップ）
Route 53 Resolver Endpoints

導入ロードマップ

フェーズ	タスク	期間
1. 設計	CIDR 計画、セキュリティ要件定義、図面作成	1～2 週
2. 構築	VPC・Subnet・SG・NLB 作成	1～2 週
3. 接続	IGW・NAT Gateway・VPN 設定	1 週
4. 検証	Reachability Analyzer、Flow Logs 確認	1 週
5. 運用	Flow Logs・GuardDuty 監視、アラート設定	継続

実装チェックリスト

VPC 設計

☑️ CIDR ブロック決定（/16 以上）
☑️ Subnet CIDR 設計（Public/Private/Isolated）
☑️ 重複確認（他 VPC・オンプレ）
☑️ マルチ AZ 計画

セキュリティ

☑️ Security Group 定義（最小権限）
☑️ NACL 設定（不要な場合スキップ可）
☑️ Flow Logs 有効化
☑️ GuardDuty 有効化
☑️ Network Firewall（必要に応じて）

接続性

☑️ Internet Gateway アタッチ
☑️ NAT Gateway 配置（各 AZ）
☑️ VPC Endpoint（S3/DynamoDB）設定
☑️ VPN/Direct Connect（ハイブリッド）設定

運用

☑️ CloudWatch アラーム設定
☑️ Flow Logs 分析設定
☑️ Tagging 戦略実装
☑️ 災害復旧計画作成

まとめ

VPC は 「AWS 上の全リソードの配置基盤となるネットワーク層」 です。以下を基本原則として設計・運用します：

十分な CIDR 予約：後からの変更不可、最初が肝心
マルチ AZ 冗長性：各 AZ に NAT・ALB を配置
セキュリティの多層化：SG + NACL + Flow Logs + GuardDuty
VPC Endpoint で無駄排除：Gateway Endpoint で NAT コスト削減
大規模ならTransit Gateway：VPC Peering の複雑性回避
ハイブリッドは計画的に：VPN → Direct Connect への段階採用
Cloud WAN で統一管理：新規マルチ VPC はWAN導入

これらを実装することで、セキュアでスケーラブル・高可用性のネットワーク基盤が実現できます。

目次

Amazon VPC 完全ガイド 2026

初心者から実務者向けの包括的解説

ドキュメントの目的

2026 年の VPC エコシステム

定義

目次

概要

VPC が存在しない場合の課題

VPC が解決する課題

主な特徴

アーキテクチャ

CIDR 設計と IP アドレス管理

CIDR 記法

VPC CIDR 選定ガイドライン

AWS IPAM（IP Address Manager）

サブネット種別

標準的なサブネット

拡張サブネット

主要ユースケース

1. 3 層 Web アプリケーション（最も典型）

2. ハイブリッド接続（企業向け）

3. マイクロサービス（大規模）

4. データレイク（分析）

5. CI/CD パイプライン

6. Bastion/Jump Host パターン

7. SaaS マルチテナント（顧客隔離）

8. 機械学習・SageMaker

9. IoT・センサーデータ集約

10. ディザスタリカバリー（DR）

11. Kubernetes（EKS）

12. ゼロトラスト・セキュリティ

13. VPC Peering によるマルチ VPC（レガシー）

14. マルチリージョン・アクティブアクティブ

15. コンテナレジストリ（ECR）とのプライベート連携

ルーティング

Route Table の基本

複雑なルーティング：Transit Gateway

VPC Peering（レガシー）

セキュリティ

Security Group（SG）

Network ACL（NACL）

VPC Flow Logs

AWS GuardDuty（ネットワーク脅威検知）

AWS Network Firewall

VPC Endpoint

ゲートウェイエンドポイント（Gateway Endpoint）

インターフェースエンドポイント（Interface Endpoint）

PrivateLink

NAT

NAT Gateway

NAT Instance

アウトバウンド IP の固定

ELB との関係

ALB（Application Load Balancer）

NLB（Network Load Balancer）

GLB（Gateway Load Balancer）

DNS

DNS 機能

Resolver Endpoints（ハイブリッド）

VPN・Direct Connect・Transit Gateway

Site-to-Site VPN

AWS Direct Connect

AWS Cloud WAN（新しい統一管理）

VPC Lattice

Cross-Region 接続パターン

他の類似ツールとの比較

クライアントとエコシステム

AWS Management Console

AWS CLI

Terraform（Infrastructure as Code）

AWS CDK（TypeScript/Python）

Reachability Analyzer

AWS Network Manager

ベストプラクティス

1. CIDR 設計（最初が肝心）

2. マルチ AZ 構成（高可用性）

3. セキュリティグループの最小権限

4. Flow Logs の有効化

5. VPC Endpoint の活用（コスト最適化）