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の基本概念（リージョン、アベイラビリティゾーン）

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は自社サービスやサードパーティサービスをプライベートに公開するためにも使用できます。別 AWS アカウント間でのサービス公開に特に有用です。

┌──── サービス提供側 AWS アカウント ────┐  ┌──── サービス利用側 AWS アカウント ────┐
│  提供側 VPC                           │  │  利用側 VPC                           │
│                                       │  │                                       │
│  [NLB] → [ALB] → [アプリ]            │  │  [Interface Endpoint]                 │
│     ↑                                 │  │  (ENI, プライベートIP)                │
│  エンドポイントサービス                │←──│     ↑                                 │
│  (com.amazonaws.vpce.ap-northeast-1.  │  │  アプリ (RP) がこの ENI に接続        │
│   vpce-svc-xxx)                       │  │                                       │
└───────────────────────────────────────┘  └───────────────────────────────────────┘
                        PrivateLink（AWS バックボーンネットワーク内で完結）

PrivateLink の接続パターン

PrivateLink 経由でサービスを公開する場合、「mTLS が必要かどうか」と「どこで TLS を終端するか」によって構成が変わります。

全パターン比較

	パターン 1	パターン 2	パターン 3	パターン 4
経路	NLB→ALB→ECS	NLB→ECS	API GW(Private)→VPC Link→NLB→ECS	NLB→ALB(mTLS)→ECS
TLS 終端	ALB	NLB or アプリ	API Gateway	ALB
mTLS	なし	なし	不可（後述）	あり
Blue-Green	ALB TG 重み変更	NLB TG 入れ替え	Canary / ステージ変更	ALB TG 重み変更
トラフィック制御	1〜100% 段階的	基本 all-or-nothing	0〜100% 段階的	1〜100% 段階的
コスト	NLB + ALB	NLB のみ	API GW リクエスト課金	NLB + ALB
利用側の変更	なし	なし	なし	なし

mTLS 不要のパターン

パターン 1: NLB → ALB → ECS

利用側 VPC                    提供側 VPC
┌────────────────┐        ┌────────────────────────────────┐
│                │        │                                │
│ VPC Endpoint ─────────────▶ NLB (TCP:443)                 │
│                │  PL    │    │                            │
└────────────────┘        │    ▼                            │
                          │  ALB (HTTPS:443)                │
                          │  ├── Blue TG (重み X)           │
                          │  └── Green TG (重み Y)          │
                          │         │                       │
                          │         ▼                       │
                          │       ECS Tasks                 │
                          └────────────────────────────────┘

特徴:
  ・ALB の L7 機能（パスベースルーティング、ホストベース等）が使える
  ・ALB の重み付き TG で段階的 Blue-Green が可能
  ・NLB は ALB タイプのターゲットグループで ALB に直接接続
  ・mTLS は不要だが、将来追加する場合は ALB に Trust Store を設定するだけ

パターン 2: NLB → ECS

利用側 VPC                    提供側 VPC
┌────────────────┐        ┌────────────────────────────────┐
│                │        │                                │
│ VPC Endpoint ─────────────▶ NLB (TLS:443 or TCP:443)      │
│                │  PL    │    │                            │
└────────────────┘        │    ▼                            │
                          │  ECS Tasks (idp-server)         │
                          └────────────────────────────────┘

特徴:
  ・最もシンプルな構成、ALB 不要でコスト低
  ・NLB が TLS 終端する場合は ACM 証明書を使用
  ・NLB が TCP パススルーする場合はアプリが TLS 終端
  ・Blue-Green は NLB の TG 入れ替え（CodeDeploy 等）
  ・L7 ルーティング機能は使えない

パターン 3: API Gateway (Private) → VPC Link → NLB → ECS

利用側 VPC                    提供側 AWS アカウント
┌────────────────┐        ┌────────────────────────────────────┐
│                │        │                                    │
│ VPC Endpoint ───────────────▶ API Gateway (Private)           │
│ (execute-api)  │  PL    │    ├── リソースポリシー（アクセス制御）│
└────────────────┘        │    ├── WAF 統合                     │
                          │    ├── スロットリング / API キー     │
                          │    ├── Canary デプロイ              │
                          │    └── VPC Link                    │
                          │         │                          │
                          │         ▼                          │
                          │  提供側 VPC                         │
                          │  ┌──────────────────────────┐     │
                          │  │ NLB → ECS Tasks          │     │
                          │  └──────────────────────────┘     │
                          └────────────────────────────────────┘

特徴:
  ・API Gateway の機能（WAF, スロットリング, API キー, Canary）が使える
  ・リソースポリシーでアカウント / VPC / VPC Endpoint 単位のアクセス制御
  ・Canary デプロイが組み込み（% 指定で段階的切り替え）
  ・ステージ変数でバックエンド（VPC Link 先）を切り替え可能
  ・利用側は execute-api 用の VPC Endpoint を作成

制約:
  ・リクエストタイムアウト: デフォルト 29 秒
    （Regional/Private REST API はクォータ申請で延長可能）
  ・ペイロードサイズ: 最大 10 MB
  ・リクエスト課金（$3.50/100 万リクエスト〜、リージョンにより異なる）

注意: API Gateway (Private) では mTLS は使えない。 AWS ドキュメントに「Mutual TLS isn't supported for private APIs.」と明記されている。 API Gateway の mTLS はリージョナルカスタムドメイン名（パブリックエンドポイント）でのみ利用可能。

mTLS が必要なパターン

FAPI（Financial-grade API）等でクライアント証明書による認証が必要な場合。API Gateway (Private) では mTLS が使えないため、ALB またはアプリケーションで終端する。

パターン 4: NLB → ALB（mTLS 終端）→ ECS

利用側 VPC                    提供側 VPC
┌────────────────┐        ┌────────────────────────────────┐
│                │        │                                │
│ VPC Endpoint ─────────────▶ NLB (TCP:443, TLS 終端しない) │
│                │  PL    │    │                            │
└────────────────┘        │    ▼                            │
                          │  ALB (HTTPS:443, mTLS Verify)   │
                          │  ├── Trust Store (CA 証明書)     │
                          │  ├── Blue TG (重み X)           │
                          │  └── Green TG (重み Y)          │
                          │         │                       │
                          │         ▼                       │
                          │       ECS Tasks                 │
                          └────────────────────────────────┘

特徴:
  ・ALB が mTLS を処理（Verify モード / Passthrough モード）
  ・アプリは HTTP ヘッダーで証明書情報を受け取る
  ・ALB の重み付き TG で 1% 単位の段階的 Blue-Green が可能
  ・NLB は TCP リスナー必須（TLS リスナーでは ALB タイプ TG に転送不可）
  ・NLB は ALB タイプのターゲットグループで ALB に直接接続

ALB が転送するヘッダー:
  Passthrough モード:
    ・X-Amzn-Mtls-Clientcert（証明書チェーン全体、URL エンコード PEM）

  Verify モード:
    ・X-Amzn-Mtls-Clientcert-Leaf（リーフ証明書、URL エンコード PEM）
    ・X-Amzn-Mtls-Clientcert-Serial-Number（16進数）
    ・X-Amzn-Mtls-Clientcert-Issuer（RFC2253 形式の DN）
    ・X-Amzn-Mtls-Clientcert-Subject（RFC2253 形式の DN）
    ・X-Amzn-Mtls-Clientcert-Validity（ISO8601 形式の NotBefore/NotAfter）

パターン 4 の変形: NLB → ECS（アプリで mTLS 終端）

利用側 VPC                    提供側 VPC
┌────────────────┐        ┌────────────────────────────────┐
│                │        │                                │
│ VPC Endpoint ─────────────▶ NLB (TCP:443, TLS 終端しない) │
│                │  PL    │    │                            │
└────────────────┘        │    ▼                            │
                          │  ECS Tasks                      │
                          │  ├── Envoy / Nginx サイドカー   │
                          │  │   └── mTLS 終端 + 検証       │
                          │  └── idp-server                 │
                          └────────────────────────────────┘

特徴:
  ・アプリ（またはサイドカー）が TLS 終端とクライアント証明書検証を実行
  ・ALB が不要なのでコスト低、レイテンシも 1 ホップ少ない
  ・証明書バインドトークン（cnf クレーム）のカスタム検証が必要な場合に有用

注意:
  ・Blue-Green は NLB の TG 入れ替え（CodeDeploy の Linear/Canary で段階的切替は可能）
  ・Trust Store の更新はタスク再デプロイが必要（ALB なら設定変更のみ）
  ・Blue/Green 両方で TLS 設定が完全一致していないと障害になる

IDサービスでの推奨

mTLS が必要な場合（FAPI）:
  → パターン 4（NLB → ALB mTLS → ECS）を推奨
    ・mTLS 処理がマネージド（Trust Store 更新が設定変更のみ）
    ・ALB の重み付き TG で細かい Blue-Green 制御が可能
    ・リクエスト課金なし（ALB は LCU ベース）
    ・FAPI の証明書バインドトークンは ALB のヘッダーから thumbprint を取得

mTLS が不要な場合:
  → パターン 1（NLB → ALB → ECS）を推奨
    ・L7 ルーティング、ヘルスチェック、将来の mTLS 追加が容易

  → API Gateway (Private) が適するケース:
    ・WAF / スロットリング / API キーによるアクセス制御が必要
    ・Canary デプロイを API Gateway の機能で行いたい
    ・ただし 29 秒タイムアウト制限に注意

PrivateLink によるクロスアカウントサービス公開

金融機関間連携や FAPI 対応 IdP サービスなど、別 AWS アカウントにいるクライアントにプライベートにサービスを公開する場合の構成。

サービス提供側（IdP 運用者）の設定

Step 1: NLB を作成
  ・リスナー: TCP 443（TLS を終端しない）
  ・ターゲット: ALB の IP アドレス
    → ALB タイプのターゲットグループを使用
  ・AZ: 利用側がアクセスする可能性のある AZ すべてに配置

  aws elbv2 create-load-balancer \
    --name idp-privatelink-nlb \
    --type network \
    --subnets subnet-aaa subnet-bbb

Step 2: ALB タイプのターゲットグループで NLB → ALB を接続
  ・ターゲットタイプ: alb
  ・プロトコル: TCP
  ・ポート: 443

  aws elbv2 create-target-group \
    --name idp-alb-target \
    --target-type alb \
    --protocol TCP \
    --port 443 \
    --vpc-id vpc-xxx

  aws elbv2 register-targets \
    --target-group-arn arn:aws:...targetgroup/idp-alb-target/xxx \
    --targets Id=arn:aws:...loadbalancer/app/idp-alb/yyy

Step 3: VPC Endpoint Service を作成
  ・NLB を指定
  ・承認が必要（acceptance_required: true 推奨）

  aws ec2 create-vpc-endpoint-service-configuration \
    --network-load-balancer-arns arn:aws:...loadbalancer/net/idp-privatelink-nlb/xxx \
    --acceptance-required

  → サービス名が発行される:
    com.amazonaws.vpce.ap-northeast-1.vpce-svc-0123456789abcdef0

Step 4: 利用側の AWS アカウントを許可
  aws ec2 modify-vpc-endpoint-service-permissions \
    --service-id vpce-svc-xxx \
    --add-allowed-principals arn:aws:iam::111122223333:root

Step 5: プライベート DNS 名を設定（オプション、推奨）
  ・カスタムドメイン名を設定: api.idp.example.com
  ・ドメイン所有権の検証（TXT レコード）が必要
  ・利用側は通常のドメイン名で接続可能になる

  aws ec2 modify-vpc-endpoint-service-configuration \
    --service-id vpce-svc-xxx \
    --private-dns-name api.idp.example.com

サービス利用側（金融機関等）の設定

Step 1: VPC Endpoint（Interface 型）を作成
  ・提供側から共有されたサービス名を指定
  ・アプリケーションがあるサブネットに配置

  aws ec2 create-vpc-endpoint \
    --vpc-id vpc-yyy \
    --service-name com.amazonaws.vpce.ap-northeast-1.vpce-svc-0123456789abcdef0 \
    --vpc-endpoint-type Interface \
    --subnet-ids subnet-ccc subnet-ddd \
    --security-group-ids sg-zzz

Step 2: Security Group の設定
  ・アウトバウンド: HTTPS/443 → VPC Endpoint の ENI
  ・VPC Endpoint の SG: インバウンド HTTPS/443 ← アプリの SG

Step 3: DNS の確認
  ・プライベート DNS が有効なら、通常のドメイン名でアクセス可能
  ・プライベート DNS が無効なら、VPC Endpoint 固有の DNS 名を使用:
    vpce-0123456789abcdef0-xxx.vpce-svc-xxx.ap-northeast-1.vpce.amazonaws.com

Step 4: 接続テスト
  curl https://api.idp.example.com/.well-known/openid-configuration
  → プライベートネットワーク内で IdP に到達

提供側・利用側の責任分界

項目	提供側（IdP）	利用側（金融機関等）
NLB の構築・運用	✅	-
ALB の構築・運用（mTLS 含む）	✅	-
Endpoint Service の作成	✅	-
アカウント許可の追加	✅	-
サービス名の共有	✅（通知する）	✅（受け取る）
VPC Endpoint の作成	-	✅
Security Group の設定	提供側 VPC 内	利用側 VPC 内
DNS 設定	プライベート DNS 名	必要に応じて Route 53
クライアント証明書の発行	CA 証明書を Trust Store に登録	証明書を取得・管理
Blue-Green デプロイ時の対応	ALB TG 重み変更	なし（変更不要）

Blue-Green デプロイ時のフロー

通常のサービス提供時:
  利用側 VPC Endpoint → NLB → ALB → Blue TG (v1) [重み 100]
                                   → Green TG (v2) [重み 0]

Blue-Green 切り替え:
  提供側が ALB の重みを変更するだけ:
    Blue TG: 100 → 0
    Green TG: 0 → 100

  利用側:
    ・VPC Endpoint: 変更なし
    ・ENI / プライベート IP: 変更なし
    ・DNS: 変更なし
    ・Security Group: 変更なし
    ・アプリケーション設定: 変更なし
    ・事前通知: 不要（ダウンタイムなし）

  → 利用側は Blue-Green が起きたことすら認識しない

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内で動作する仮想サーバーについて学ぶ

所要時間​

学べること​

前提知識​

目次​

1. VPCの概要​

VPCの主な特徴​

VPCの構成要素​

CIDRブロックの設計指針​

2. サブネット設計​

パブリックサブネットとプライベートサブネット​

典型的なVPC構成​

サブネットのCIDR設計例​

3. インターネットゲートウェイとNATゲートウェイ​

インターネットゲートウェイ（IGW）​

NATゲートウェイ​

通信フローの比較​

NATゲートウェイのコスト最適化​

4. セキュリティグループ​

ステートフルの意味​

セキュリティグループのルール設定例​

セキュリティグループの重要な特徴​

5. ネットワークACL​

セキュリティグループとネットワークACLの比較​

ネットワークACLのルール例​

使い分けの指針​

6. VPCピアリングとTransit Gateway​

VPCピアリング​

Transit Gateway​

VPCピアリング vs Transit Gateway​

7. VPN接続とDirect Connect​

Site-to-Site VPN​

Direct Connect​

VPN vs Direct Connect​

8. VPCエンドポイントとPrivateLink​

Gatewayエンドポイント​

Interfaceエンドポイント（AWS PrivateLink）​

Gatewayエンドポイント vs Interfaceエンドポイント​

PrivateLinkのユースケース​

PrivateLink の接続パターン​

全パターン比較​

mTLS 不要のパターン​

パターン 1: NLB → ALB → ECS​

パターン 2: NLB → ECS​

パターン 3: API Gateway (Private) → VPC Link → NLB → ECS​

mTLS が必要なパターン​

パターン 4: NLB → ALB（mTLS 終端）→ ECS​

パターン 4 の変形: NLB → ECS（アプリで mTLS 終端）​

IDサービスでの推奨​

PrivateLink によるクロスアカウントサービス公開​

サービス提供側（IdP 運用者）の設定​

サービス利用側（金融機関等）の設定​

提供側・利用側の責任分界​

Blue-Green デプロイ時のフロー​

9. IDサービスでの活用​

idp-serverのVPC構成​

セキュリティグループの設計​

ネットワーク設計のポイント​

10. まとめ​

次のステップ​

参考リソース​