AWS Network Vol3｜Cloud WAN×VPC Lattice×IPAM×Endpoint

§1 なぜ Network Vol3 か — Network階層 + 三部作完成 + 52記事化 + ナビ

AWS Network本番運用シリーズは、ここまで Vol1 (VPC基礎) と Vol2 (Hybrid接続) の2巻で
「単一 VPC 内のネットワーク設計」「オンプレ <-> AWS 接続」の本番運用知見を体系化してきた。

しかし、エンタープライズ規模のクラウド利用が進むにつれ、Network 層の課題は
「単一 VPC + Hybrid 接続」の枠を超えて以下の4つの新領域へと拡張してきた。

• Global Network 統一管理 — 数十〜数百 VPC を横断する Network Policy / Segment 設計 (Cloud WAN)
• Service Mesh / Service-to-Service 通信 — マイクロサービス間の Auth + Routing + Observability (VPC Lattice)
• IP アドレス空間の組織横断管理 — Multi-account / Multi-region での IP 重複防止 + 監査 (IPAM advanced)
• PrivateLink advanced + Endpoint コスト最適化 — Interface / Gateway / GatewayLB / Endpoint Service (VPC Endpoint deep dive)

本記事 Network本番運用 Vol3 は、これら4領域を1本に統合し、本番運用視点で体系化する。
– Cloud WAN — Core Network + Network Policy Document による Global Network 統一管理
– VPC Lattice — Service Network + Service による Cross-VPC Service Mesh 構築
– IPAM advanced — Pool 階層 + Cross-account allocation + BYOIP による IP 管理
– VPC Endpoint deep dive — Gateway / Interface / GatewayLB / Endpoint Service の本番設計

Network三部作の完成

本記事の公開により、AWS Network本番運用シリーズは3巻構成で完成する。

Vol1 で「単一 VPC を正しく作る」、Vol2 で「VPC をオンプレ・他 VPC と繋ぐ」、
Vol3 で「組織全体のネットワーク・サービス・IP を統一管理する」という3層構造で
AWS Network 本番運用の全体像を提供する。

各 Vol の主要サービスと習得内容は以下の通りである。

Network本番運用 Vol1 (VPC基礎) — 単一 VPC 層
Subnet 設計 (Public / Private / Isolated の3層構造) / Route Table (最長一致ルール / ブラックホール) /
NACL (ステートレス / インバウンド+アウトバウンド) / Security Group (ステートフル / ref参照) /
VPC Flow Logs (S3 / CloudWatch / Athena 分析) の5サービスを本番運用視点で体系化した。

Network本番運用 Vol2 (Hybrid 接続) — VPC 間 / オンプレ接続層
Transit Gateway (Route Table / Peering / ECMP) / Direct Connect (専用線 / VGW / Private VIF) /
PrivateLink (NLB × Endpoint Service) / VPC Peering (Cross-account / Cross-region) /
VPN (Site-to-Site / Client VPN / Accelerated VPN) の5サービスを本番運用視点で体系化した。

Network本番運用 Vol3 本記事 (Global + Service Mesh + IP管理) — 組織横断層
Cloud WAN (§2) / VPC Lattice (§3) / IPAM advanced (§4) / VPC Endpoint deep dive (§5) の
4サービスグループを本番運用視点で体系化する。3巻合計で14サービスが対象となる。

AWS Network 階層モデル (6層)

AWS の Network サービスを階層化すると以下の6層に整理できる。
各層に典型的なコスト目安と適用規模を合わせて示す。

本 Vol3 は L0 (Endpoint) / L3 (IP管理) / L4 (Service Mesh) / L5 (Global) の4層を横断的に扱う。
Vol1 (L1) / Vol2 (L2) と組み合わせることで Network 全6層を網羅する。

想定読者

本記事は以下の5タイプの読者を想定している。

Type A: Multi-Region Network エンジニア (Cloud WAN 採用検討中)
数十〜数百 VPC が複数 AWS リージョンにまたがり、TGW の手動 Route Table 管理に限界を感じている。
拠点間の通信ポリシーを JSON 宣言型 (Network Policy Document) で一元管理し、
Segment 分離 (Production / Staging / Shared) を自動化したい。
現行の TGW Inter-Region Peering × 手動 Route Table 管理から脱却し、
宣言型 Network 設計 (Policy Document = Infrastructure as Code) を実現したいエンジニアに最適。

Type B: SRE / Platform Engineer (VPC Lattice 採用検討中)
マイクロサービスが複数 VPC に分散しており、Service Discovery + L7 ロードバランシング + IAM 認証を
まとめて解決したい。現行の ALB + Route 53 構成では Cross-VPC Auth 設計が複雑になっており、
サービス間の認証・認可を IAM Policy 1枚で宣言できる VPC Lattice の採用を検討している。
EKS (Container Vol3) と合わせて読むことでマイクロサービスの全層 Networking が完成する。

Type C: Cloud Architect (IPAM advanced 必要)
AWS Organizations で数十 Account を管理しており、各 Account が独自に VPC CIDR を採番している。
IP 重複・重複検知漏れ・オンプレ IP との衝突が発生し、IP 管理の一元化が急務となっている。
IPAM の Pool 階層 (Top-level → Region → Account) による動的 Cross-account Allocation と
BYOIP (オンプレ IP の AWS への持ち込み) で IP 管理の一元化を実現したい Cloud Architect が対象。

Type D: FinOps / 運用担当 (VPC Endpoint コスト爆発への対処)
Interface Endpoint を各 VPC × 各 AZ × 各サービスに展開した結果、月額数万〜数十万円の
Endpoint 費用が発生している。S3 / DynamoDB は Gateway Endpoint (無料) に切り替え、
共通 Interface Endpoint を Endpoint Service で集約することでコスト最適化を図りたい担当者に最適。

Type E: Vol1 / Vol2 既存読者 (Network 三部作を完成させたい)
Vol1 で VPC 基礎を習得し、Vol2 で TGW × Direct Connect × PrivateLink を習得した読者が、
Network の最終層 (Global / Service Mesh / IP管理 / Endpoint deep dive) を習得して
「VPC内 → VPC間 → 組織全体横断」の Network 設計力を完成させる本記事が特に有用。
Vol2 の TGW / PrivateLink 知識は本 Vol3 でも直接活用される (Cloud WAN TGW Peering / VPC Lattice)。

逆に「単一 VPC + 数台 EC2 のみ」の小規模利用者は本記事の対象外であり、
Vol1 (VPC基礎) から読み始めることを推奨する。

Vol1 / Vol2 既存読者向け移行導線

Vol1 / Vol2 を読了した読者は、本 Vol3 を通じて以下の移行を達成できる。

Vol1 → Vol2 移行 (習得済)
「単一 VPC 設計 (Subnet / NACL / SG)」→「VPC 間 / オンプレ接続 (TGW / Direct Connect / PrivateLink)」

Vol2 → Vol3 移行 (本記事の範囲)
「VPC 間 / オンプレ接続 (TGW手動管理)」→「Global Network 統一管理 (Cloud WAN Policy Document)」
「個別 ALB + Service Discovery」→「VPC Lattice Service Mesh (Cross-VPC Auth + L7 Routing)」
「手動 IP 採番 + Spreadsheet 管理」→「IPAM Pool 階層 + 動的 Cross-account Allocation」
「Interface Endpoint 個別展開」→「Gateway Endpoint 活用 + Endpoint Service 集約 + コスト最適化」

Vol2 の TGW / PrivateLink 知識は本 Vol3 でも活用される。
Cloud WAN では TGW Peering Attachment により既存 TGW 資産を Cloud WAN に取り込める。
VPC Lattice の Endpoint Service は PrivateLink の発展形であり、Vol2 の PrivateLink 知識が直結する。

本記事の構成

§2 で Cloud WAN (Global) の本番運用を扱い、§3 で VPC Lattice (Service Mesh)、
§4 で IPAM advanced (IP管理)、§5 で VPC Endpoint deep dive (PrivateLink advanced) を扱う。
§6 で4領域の詰まりポイント7選を判断ツリー化し、§7 で5つのアンチパターン → 正解パターン
変換演習を行う。§8 で Network 三部作完成宣言 + 52記事化達成告知 + 全軸クロスリンクで締めくくる。

§2 Cloud WAN 本番運用 — Core Network × Network Policy Document × Attachment × Segment × Route Table Group × Global Manager ★山場1

AWS Cloud WAN は、複数リージョン・複数 VPC にまたがる Wide Area Network を
単一の Network Policy Document (JSON) で宣言的に管理するサービスである。
Transit Gateway (TGW) が「リージョン内 VPC 間接続」を担うのに対し、
Cloud WAN は「組織全体のグローバルネットワーク統一管理」を担う上位抽象として位置付けられる。

TGW の課題として顕在化するのは、リージョン数が3以上・VPC 数が数十を超えたあたりだ。
TGW Inter-Region Peering を手動で張り、リージョンごとに Route Table を個別管理し、
Segment (Production / Staging / Shared) の分離ポリシーを各 TGW で設定する手間は
運用スケールの限界に直結する。Cloud WAN はこれを Policy Document 1枚で宣言的に解決する。

Cloud WAN の基本構造

Cloud WAN は以下の階層構造で成り立つ。

Global Network (組織の論理 WAN 全体)
  └─ Core Network (Policy 管理の基本単位)
 ├─ Network Policy Document (JSON — segments / attachments / routes)
 ├─ Segment (論理ネットワーク分離単位)
 │ ├─ Production Segment
 │ ├─ Staging Segment
 │ ├─ Development Segment
 │ └─ Shared Segment
 ├─ Attachment (物理接続点)
 │ ├─ VPC Attachment
 │ ├─ VPN Attachment
 │ ├─ Connect Attachment (SD-WAN)
 │ └─ TGW Peering Attachment
 └─ Route Table Group (Segment 単位のルーティング)

Global Network は組織 (AWS Account / Organization) に紐付く論理 WAN の最上位単位であり、
1つの Global Network に複数の Core Network を含めることができる。

Core Network は Cloud WAN の管理基本単位で、1つの Network Policy Document を持つ。
Policy Document を apply することで Segment / Attachment / Route の状態が宣言的に収束する。

Network Policy Document の構造

Network Policy Document は JSON 形式で記述する宣言型設定ファイルであり、
Cloud WAN の「Infrastructure as Code」の中核をなす。

主要セクションは以下の構造で構成される。

{
  "version": "2021.12",
  "core-network-configuration": {
 "vpn-ecmp-support": true,
 "asn-ranges": ["64512-65534"],
 "edge-locations": [
{ "location": "ap-northeast-1" },
{ "location": "us-east-1" },
{ "location": "eu-west-1" }
 ]
  },
  "segments": [
 {
"name": "production",
"require-attachment-acceptance": false,
"isolate-attachments": false
 },
 {
"name": "staging",
"require-attachment-acceptance": true,
"isolate-attachments": true
 },
 {
"name": "shared",
"require-attachment-acceptance": false,
"isolate-attachments": false
 }
  ],
  "segment-actions": [
 {
"action": "share",
"mode": "attachment-route",
"segment": "shared",
"share-with": ["production", "staging"]
 }
  ],
  "attachment-policies": [
 {
"rule-number": 100,
"condition-logic": "and",
"conditions": [
  { "type": "tag-value", "operator": "equals", "key": "env", "value": "prod" }
],
"action": { "association-method": "constant", "segment": "production" }
 },
 {
"rule-number": 200,
"conditions": [
  { "type": "tag-value", "operator": "equals", "key": "env", "value": "staging" }
],
"action": { "association-method": "constant", "segment": "staging" }
 },
 {
"rule-number": 300,
"conditions": [
  { "type": "tag-value", "operator": "equals", "key": "shared", "value": "true" }
],
"action": { "association-method": "constant", "segment": "shared" }
 }
  ]
}

core-network-configuration では edge-locations (Cloud WAN を展開するリージョン) と
asn-ranges (BGP ASN 範囲) を宣言する。vpn-ecmp-support を有効化すると
複数 VPN Attachment 間の ECMP (等コストマルチパス) ルーティングが有効になる。

segments で論理ネットワーク分離単位を定義する。require-attachment-acceptance: true の
Segment は、Attachment 追加時に Core Network Owner の明示的承認が必要になる。
isolate-attachments: true を設定した Segment 内の Attachment 同士は、
同一 Segment 内であっても直接通信不可になり、Shared Segment 経由の制御が強制される。

attachment-policies で VPC が持つタグ (env: prod 等) に基づいて
どの Segment に自動割り当てするかを Rule 番号順に評価する。
Rule 100 の条件に合致すれば production Segment に、合致しなければ Rule 200 へと順次評価する。

segment-actions で Segment 間のルート共有を宣言する。上記例では
shared Segment のルートを production / staging と双方向共有している。

Network Policy Document のバージョン管理と Apply フロー

Policy Document は Change Set 方式でバージョン管理される。

# Policy Document をファイルから作成 (新バージョン作成)
aws networkmanager put-core-network-policy \
  --core-network-id core-network-0123456789abcdef0 \
  --policy-document file://network-policy.json \
  --description "Add staging segment and attachment-policies"

# Change Set 確認 (差分確認)
aws networkmanager get-core-network-change-set \
  --core-network-id core-network-0123456789abcdef0 \
  --policy-version-id 2

# Change Set を Apply (実際の変更実行)
aws networkmanager execute-core-network-change-set \
  --core-network-id core-network-0123456789abcdef0 \
  --policy-version-id 2

Apply 前に get-core-network-change-set で差分を必ず確認する。
変更内容によっては既存ルート削除 / Segment 再編成が発生する場合があるため、
本番環境の Policy 変更は必ずステージング Core Network で先行 Apply してから実施する。

Attachment の種類と設定

Cloud WAN への接続点 (Attachment) は4種類ある。

VPC Attachment — VPC を Core Network に接続する最も基本的な Attachment。
VPC Attachment を作成すると、指定したサブネット (各 AZ) に Cloud WAN 用の ENI が作成される。
Attachment に付与するタグが attachment-policies のマッチ条件になる。

# VPC Attachment 作成
aws networkmanager create-vpc-attachment \
  --core-network-id core-network-0123456789abcdef0 \
  --vpc-arn arn:aws:ec2:ap-northeast-1:123456789012:vpc/vpc-0abc123 \
  --subnet-arns arn:aws:ec2:ap-northeast-1:123456789012:subnet/subnet-0abc123 \
  --tags Key=env,Value=prod

VPN Attachment — オンプレミスや拠点への IPsec VPN 接続。
Cloud WAN は複数 VPN Attachment の ECMP ルーティングをサポートし、
TGW VPN と比較してリージョンをまたいだ VPN トポロジ管理が容易になる。

Connect Attachment — SD-WAN 機器 (Cisco / VMware Velocloud 等) との GRE/BGP 接続。
既存の VPC Attachment を「Transport Attachment」として使い、その上に Connect Attachment を構築する。
GRE トンネルにより SD-WAN オーバーレイネットワークを Cloud WAN に統合できる。

TGW Peering Attachment — 既存 TGW を Cloud WAN に接続する。
TGW 上の既存 VPC / VPN を Cloud WAN に段階的に移行する際の橋渡し役として機能する。
全面移行前の過渡期に TGW 資産を維持したまま Cloud WAN を導入できる。

Segment の設計パターン

本番環境では以下の Segment 設計が多く採用される。

isolate-attachments: true の Segment では、
segment-actions の share で明示的に許可したルートのみが伝達される。
これにより Dev VPC が誤って Prod VPC に通信できる構成を Policy レベルで防止できる。

Shared Segment は DNS サーバ VPC / Egress Proxy VPC / Monitoring VPC など
全 Segment から到達が必要な共有サービスを収容し、
segment-actions の share-with で Production / Staging / Development と双方向共有する。

Route Table Group と Static / Blackhole Route

Route Table Group は Segment 単位で Route を管理する仕組みである。

Policy Document の segment-actions に create-route を追加することで
Static Route と Blackhole Route を宣言できる。

{
  "segment-actions": [
 {
"action": "create-route",
"destination-cidr-blocks": ["10.100.0.0/16"],
"segment": "production",
"destination": "attachment-0abc123456"
 },
 {
"action": "create-route",
"destination-cidr-blocks": ["192.168.0.0/16"],
"segment": "production",
"destination": "blackhole"
 }
  ]
}

destination: "blackhole" を使うことで特定 CIDR へのトラフィックを明示的に破棄できる。
オンプレ側の旧 CIDR や廃止済みサービスへの誤ルーティングを Policy で禁止するユースケースに有効。

Global Manager と Cloud WAN Telemetry

AWS Network Manager の Global Manager コンソールは、
Cloud WAN の全体状態を集中可視化するダッシュボードである。

Global Manager で確認できる主要情報:

Global Manager を活用することで、数十〜数百 VPC × 複数 Region にわたる
ネットワーク状態を一画面で確認でき、インシデント発生時の切り分けが高速化される。

Terraform による Cloud WAN 管理

Cloud WAN を Terraform で管理する場合は aws_networkmanager_* リソースを使用する。

resource "aws_networkmanager_global_network" "main" {
  description = "Global WAN for production"
  tags  = { Name = "main-global-network" }
}

resource "aws_networkmanager_core_network" "main" {
  global_network_id = aws_networkmanager_global_network.main.id
  description = "Core Network - production"

  policy_document = jsonencode({
 version = "2021.12"
 core-network-configuration = {
vpn-ecmp-support = true
asn-ranges = ["64512-65534"]
edge-locations = [
  { location = "ap-northeast-1" },
  { location = "us-east-1" }
]
 }
 segments = [
{
  name  = "production"
  require-attachment-acceptance = false
  isolate-attachments  = false
},
{
  name  = "shared"
  require-attachment-acceptance = false
  isolate-attachments  = false
}
 ]
 segment-actions = [
{
  action  = "share"
  mode = "attachment-route"
  segment = "shared"
  share-with = ["production"]
}
 ]
 attachment-policies = [
{
  rule-number  = 100
  condition-logic = "and"
  conditions = [
 { type = "tag-value", operator = "equals", key = "env", value = "prod" }
  ]
  action = { association-method = "constant", segment = "production" }
}
 ]
  })

  tags = { Name = "main-core-network" }
}

resource "aws_networkmanager_vpc_attachment" "prod_vpc" {
  core_network_id = aws_networkmanager_core_network.main.id
  vpc_arn= aws_vpc.prod.arn
  subnet_arns  = [aws_subnet.prod_a.arn, aws_subnet.prod_c.arn]

  tags = { env = "prod" }
}

policy_document を jsonencode() で渡すことで、
HCL 内で JSON を管理でき、Terraform Plan で差分確認が可能になる。
Policy 変更も terraform apply 時に Change Set が自動 Apply される。

TGW vs Cloud WAN 選択基準

§3 VPC Lattice 深掘り本番運用 — Service Network × Service × Listener × Target Group × Auth Policy × Custom Domain × Weighted Routing

VPC Lattice とは — Cross-VPC Service Mesh の全体像

VPC Lattice は ALB・Service Discovery・IAM Auth Policy を単一マネージドプレーンに統合したサービスメッシュ基盤である。異なる VPC 間でマイクロサービスが通信するには従来 VPC Peering / TGW が必要だったが、VPC Lattice は Service Network を中間レイヤーに置き、VPC・Account の境界を越えた L7 ルーティング + 認証 + オブザーバビリティを提供する。

主な特徴は以下の通り。

• TGW / VPC Peering 不要 — Service Network に VPC を関連付けるだけで Cross-VPC 通信を実現
• L7 ルーティング — パス / ヘッダ / HTTP メソッド 条件によるルーティングルール
• IAM Auth Policy — sigv4 署名ベースのサービス間認証。Principal / Condition を JSON で宣言
• Cross-account 対応 — RAM で Service Network を他 Account と共有可能
• マネージド TLS — ACM 証明書を Listener に自動関連付け、証明書管理レス

VPC Lattice を採用することで「誰が誰にアクセスできるか」をネットワーク設定ではなく IAM Policy で宣言的に管理できる。これにより Security Group ルールの肥大化問題を根本的に解消できる。

Service Network — 複数 VPC を1つの論理 Service Mesh に統合

Service Network は VPC Lattice の最上位リソースである。1つの Service Network に複数の VPC と複数の Service を関連付けることで、それらを1つの論理 Service Mesh として扱う。

VPC Association: VPC を Service Network に関連付けることで、その VPC 内の任意リソースが Service Network に登録された Service に到達できる。ENI は不要でルーティングはマネージドプレーンが処理する。

Service Association: Service を Service Network に紐付ける操作。1つの Service は複数の Service Network に関連付け可能で、Production / Staging 環境への対応が容易になる。

Cross-account 共有 (RAM): Service Network を RAM で Org / OU / 個別 Account と共有することで、消費側 Account の VPC からも透過的にアクセスできる。プロバイダ側が Service Network + Service を管理し、コンシューマ側は VPC Association のみ行うモデルが標準的な大規模設計となる。

resource "aws_vpclattice_service_network" "main" {
  name= "prod-service-network"
  auth_type = "AWS_IAM"

  tags = { Environment = "production" }
}

resource "aws_vpclattice_service_network_vpc_association" "app_vpc" {
  vpc_identifier = aws_vpc.app.id
  service_network_identifier = aws_vpclattice_service_network.main.id
  security_group_ids= [aws_security_group.vpclattice_sg.id]
}

resource "aws_vpclattice_service_network_vpc_association" "data_vpc" {
  vpc_identifier = aws_vpc.data.id
  service_network_identifier = aws_vpclattice_service_network.main.id
  security_group_ids= [aws_security_group.vpclattice_sg.id]
}

resource "aws_ram_resource_share" "lattice_share" {
  name = "prod-lattice-network-share"
  allow_external_principals = false
}

resource "aws_ram_resource_association" "lattice_network" {
  resource_arn = aws_vpclattice_service_network.main.arn
  resource_share_arn = aws_ram_resource_share.lattice_share.arn
}

resource "aws_ram_principal_association" "org" {
  principal = "arn:aws:organizations::ACCOUNT_ID:organization/o-XXXXX"
  resource_share_arn = aws_ram_resource_share.lattice_share.arn
}

Service — 個別マイクロサービスの論理表現

VPC Lattice の Service は「1つのマイクロサービス」を表す論理リソースである。作成後に自動生成される <service-id>.vpc-lattice.io という形式の DNS 名で到達できる。Custom domain を設定すれば独自ドメインにマッピング可能。

Service Association: Service を Service Network に紐付けることで、VPC Association 済みの VPC 内リソースから Service に到達できるようになる。

aws vpc-lattice create-service \
  --name "order-service" \
  --auth-type "AWS_IAM" \
  --custom-domain-name "order.internal.example.com" \
  --certificate-arn "arn:aws:acm:ap-northeast-1:ACCOUNT_ID:certificate/CERT_ID"

aws vpc-lattice create-service-network-service-association \
  --service-identifier "svc-XXXXX" \
  --service-network-identifier "sn-XXXXX"

Listener — HTTP/HTTPS トラフィックの受口設計

Listener は Service への入口 (ポート + プロトコル) を定義する。1つの Service に複数の Listener を作成できる。

• protocol: HTTP または HTTPS。HTTPS 選択時は ACM 証明書が必須
• port: 受信ポート番号 (標準は HTTP=80, HTTPS=443)
• default_action: Listener のデフォルト動作 (forward / fixed-response / redirect)
• rules: パス / ヘッダ / メソッド 条件によるルーティングルール (priority 昇順に評価)

ルールは priority 値 (1〜100) の昇順で評価される。fallback のデフォルトアクションを fixed_response (404) にすることで未定義パスへの不正アクセスを拒否できる。

resource "aws_vpclattice_listener" "https" {
  name= "order-https"
  protocol  = "HTTPS"
  port= 443
  service_identifier = aws_vpclattice_service.order.id

  default_action {
 fixed_response {
status_code = 404
 }
  }
}

resource "aws_vpclattice_listener_rule" "api_v2" {
  name = "api-v2-route"
  listener_identifier = aws_vpclattice_listener.https.listener_id
  service_identifier  = aws_vpclattice_service.order.id
  priority= 10

  match {
 http_match {
path_match {
  match { prefix = "/api/v2/" }
}
 }
  }

  action {
 forward {
target_groups {
  target_group_identifier = aws_vpclattice_target_group.orders_v2.id
  weight= 100
}
 }
  }
}

Target Group — 4種の Target Type と Health Check

Target Group は Service へのリクエストを実際に処理するバックエンドを定義する。VPC Lattice では4種の target type をサポートする。

Health Check は Target Group 単位で設定する。interval / timeout / threshold / path / matcher を指定する。LAMBDA type は Lambda 自体が応答するため外部 health check エンドポイントを用意しなくてよい。

Target Group の Terraform 定義例を以下に示す。IP type は ECS Fargate / Pod (K8s) のように動的 IP が変わるバックエンドに適しており、LAMBDA type は Lambda ARN を直接指定してサーバーレスバックエンドに使用する。

resource "aws_vpclattice_target_group" "orders_v2" {
  name = "orders-v2"
  type = "IP"

  config {
 port = 8080
 protocol= "HTTP"
 vpc_identifier= aws_vpc.app.id
 ip_address_type  = "IPV4"

 health_check {
enabled = true
protocol= "HTTP"
path = "/health"
port = 8080
interval_seconds = 30
timeout_seconds  = 5
healthy_threshold= 2
unhealthy_threshold = 3

matcher {
  value = "200"
}
 }
  }
}

resource "aws_vpclattice_target_group" "order_lambda" {
  name = "order-lambda"
  type = "LAMBDA"

  config {
 lambda_event_structure_version = "V2"
  }
}

resource "aws_vpclattice_target_group_attachment" "order_lambda_target" {
  target_group_identifier = aws_vpclattice_target_group.order_lambda.id

  target {
 id = aws_lambda_function.order_handler.arn
  }
}

Auth Policy — IAM ベースのサービス間認証

Auth Policy は VPC Lattice 最大の特長である。IAM Policy 形式の JSON で「誰が (Principal) どのサービスに (Resource) アクセスできるか」を宣言する。Auth Policy は Service Network 単位 と Service 単位 の2層で設定でき、前者は全 Service への横断ポリシー、後者は個別サービスの精細制御に使う。

auth_type = "AWS_IAM" の Service に送信するリクエストは sigv4 署名が必須となる。署名なしリクエストは 403 Forbidden で拒否される。

主な条件キー:

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Effect": "Allow",
"Principal": { "AWS": "*" },
"Action": "vpc-lattice-svcs:Invoke",
"Resource": "arn:aws:vpc-lattice:ap-northeast-1:ACCOUNT_ID:service/svc-XXXXX/*",
"Condition": {
  "StringEquals": {
 "aws:PrincipalAccount": ["111111111111", "222222222222"],
 "vpc-lattice-svcs:RequestMethod": ["GET", "POST"]
  },
  "ArnLike": {
 "aws:PrincipalArn": "arn:aws:iam::*:role/microservice-*"
  }
}
 }
  ]
}

aws vpc-lattice put-auth-policy \
  --resource-identifier "svc-XXXXX" \
  --policy file://auth-policy.json

Custom Domain — ACM × CNAME 連携

VPC Lattice Service には自動生成の DNS 名 (<svc-id>.vpc-lattice.io) に加え、独自ドメインを設定できる。

設定手順:
1. ACM で証明書を発行 (order.internal.example.com または *.internal.example.com のワイルドカード証明書)
2. Service の custom_domain_name に FQDN を設定
3. Route 53 Private Hosted Zone に CNAME レコードを作成し、自動生成 DNS 名を指定
4. VPC に Route 53 Resolver Rule を関連付けて名前解決を有効化

ワイルドカード証明書 (*.internal.example.com) を使えば複数サービスで1枚の証明書を共有でき、証明書発行・管理コストを削減できる。設計時はドメイン命名規則 ({service}.{team}.internal.example.com) を定めておくことで Service Network 内の名前衝突を防げる。

Route 53 Private Hosted Zone での CNAME 設定例 (Terraform):

resource "aws_route53_zone" "internal" {
  name = "internal.example.com"

  vpc {
 vpc_id = aws_vpc.app.id
  }
}

resource "aws_route53_record" "order_service" {
  zone_id = aws_route53_zone.internal.zone_id
  name = "order.internal.example.com"
  type = "CNAME"
  ttl  = 60
  records = [aws_vpclattice_service.order.dns_entry[0].domain_name]
}

Weighted Routing — Canary / Blue-Green Deployment

Listener Rule の forward アクションで同一ルールに複数 Target Group を指定し、各 Target Group に重み (weight) を設定できる。これにより宣言的な Canary / Blue-Green デプロイが可能になる。

resource "aws_vpclattice_listener_rule" "canary" {
  name = "canary-route"
  listener_identifier = aws_vpclattice_listener.https.listener_id
  service_identifier  = aws_vpclattice_service.order.id
  priority= 20

  match {
 http_match {
path_match {
  match { prefix = "/api/v1/orders" }
}
 }
  }

  action {
 forward {
target_groups {
  target_group_identifier = aws_vpclattice_target_group.orders_v1.id
  weight= 90
}
target_groups {
  target_group_identifier = aws_vpclattice_target_group.orders_v2.id
  weight= 10
}
 }
  }
}

weight の合計は自動正規化されるため、90:10 は「v1 に 90%、v2 に 10%」を意味する。Canary 検証完了後は weight を 0:100 に変更するだけで完全切り替えになる。ALB Target Group の登録変更や Route 53 フェイルオーバー設定は不要で、Terraform apply のみで制御できる。

§4 IPAM Advanced 本番運用 — Pool階層 × Allocation × Cross-Account × Reuse × Compliance × BYOIP

IPAM advanced とは — Multi-account / Multi-region IP管理の全体像

Amazon VPC IPAM (IP Address Manager) は、複数の AWS Account / Region を横断した IP アドレス空間を一元管理するサービスである。

Account 数が数十〜数百になると以下の問題が顕在化する。
– CIDR 重複: 異なる Account が同じ CIDR (例: 10.0.0.0/16) を使用し、TGW や VPN 接続時にルーティング競合が発生
– IP アドレス枯渇: 全社 IP 空間の俯瞰ができず、大 CIDR を重複割当して枯渇
– 監査非対応: どの Account がどの IP を使用しているか証跡がなく、コンプライアンス監査で指摘される

IPAM は以下の3要素でこれらを根治する。

Pool 階層設計 — 3段階 CIDR 分割戦略

IPAM の Pool は親子関係で階層を構成する。本番運用では 3段階階層 が標準設計となる。

Top-level Pool: 10.0.0.0/8  (全社 IP 空間)
  ├── Region Pool: 10.0.0.0/12(ap-northeast-1 用)
  │  ├── Account Pool A: 10.0.0.0/16  (prod-account-A 用)
  │  ├── Account Pool B: 10.16.0.0/16 (prod-account-B 用)
  │  └── Account Pool C: 10.32.0.0/16 (dev-account 用)
  └── Region Pool: 10.64.0.0/12  (us-east-1 用)
  ├── Account Pool D: 10.64.0.0/16
  └── Account Pool E: 10.80.0.0/16

設計原則:
– Top-level Pool は Organizations の管理 Account で管理し、子 Pool の CIDR 委任のみを担当する
– Region Pool は 1 Region あたり /12 を割当し、数十〜数百 VPC を収容できる CIDR 帯域を確保する
– Account Pool は 1 Account あたり /16 (65536 アドレス) を基準とし、規模に応じて調整する

resource "aws_vpc_ipam" "main" {
  operating_regions {
 region_name = "ap-northeast-1"
  }
  operating_regions {
 region_name = "us-east-1"
  }
}

resource "aws_vpc_ipam_pool" "top" {
  address_family = "ipv4"
  ipam_scope_id  = aws_vpc_ipam.main.private_default_scope_id
  locale= "ap-northeast-1"
  description = "Top-level pool — 10.0.0.0/8"
}

resource "aws_vpc_ipam_pool_cidr" "top" {
  ipam_pool_id = aws_vpc_ipam_pool.top.id
  cidr= "10.0.0.0/8"
}

resource "aws_vpc_ipam_pool" "region_tyo" {
  address_family  = "ipv4"
  ipam_scope_id= aws_vpc_ipam.main.private_default_scope_id
  locale = "ap-northeast-1"
  source_ipam_pool_id= aws_vpc_ipam_pool.top.id
  description  = "Region Pool — ap-northeast-1 — 10.0.0.0/12"
  allocation_default_netmask_length = 16
  allocation_min_netmask_length  = 16
  allocation_max_netmask_length  = 24
}

resource "aws_vpc_ipam_pool_cidr" "region_tyo" {
  ipam_pool_id = aws_vpc_ipam_pool.region_tyo.id
  cidr= "10.0.0.0/12"
}

resource "aws_vpc_ipam_pool" "account_a" {
  address_family  = "ipv4"
  ipam_scope_id= aws_vpc_ipam.main.private_default_scope_id
  locale = "ap-northeast-1"
  source_ipam_pool_id= aws_vpc_ipam_pool.region_tyo.id
  description  = "Account Pool — prod-account-A"
  allocation_default_netmask_length = 20
  allocation_min_netmask_length  = 20
  allocation_max_netmask_length  = 24
}

resource "aws_vpc_ipam_pool_cidr" "account_a" {
  ipam_pool_id = aws_vpc_ipam_pool.account_a.id
  cidr= "10.0.0.0/16"
}

Allocation — 動的・手動割当の使い分け

IPAM の Allocation には 動的 allocation と 手動 allocation の2種類がある。

動的 allocation は VPC 作成時に ipv4_ipam_pool_id を指定することで自動的に CIDR が割り当てられる。Pool の allocation_default_netmask_length で割当 CIDR のデフォルトサイズを制御する。

aws ec2 create-vpc \
  --ipv4-ipam-pool-id "ipam-pool-XXXXX" \
  --ipv4-netmask-length 20 \
  --tag-specifications "ResourceType=vpc,Tags=[{Key=Name,Value=prod-app-vpc}]"

手動 allocation は予約済み CIDR (オンプレ接続済みの固定 IP 等) を IPAM Pool に登録して管理下に置く場合に使用する。aws ec2 allocate-ipam-pool-cidr で明示的な CIDR を指定して割当できる。Pool の空き CIDR を消費するため、手動 allocation した CIDR は Pool の使用率として計上される点に注意する。

Cross-account — RAM 経由の Pool 共有

IPAM Pool を他 Account と共有するには RAM (Resource Access Manager) を使用する。共有の方向は「Pool 提供側 (管理 Account) → Pool 消費側 (子 Account)」が基本モデルとなる。

aws ec2 create-ipam-pool \
  --ipam-scope-id "ipam-scope-XXXXX" \
  --address-family ipv4 \
  --locale ap-northeast-1 \
  --source-ipam-pool-id "ipam-pool-PARENT" \
  --description "child-account-B-pool"

aws ram create-resource-share \
  --name "ipam-pool-share-account-b" \
  --resource-arns "arn:aws:ec2::MGMT_ACCOUNT_ID:ipam-pool/ipam-pool-CHILD" \
  --principals "TARGET_ACCOUNT_ID" \
  --no-allow-external-principals

Pool Permissions: RAM 共有を受けた子 Account では Pool から VPC CIDR を自律的に割当できる。ただし Pool の CIDR 範囲外の割当は拒否される。allocation_min_netmask_length / allocation_max_netmask_length でさらに制約を加え、子 Account が不必要に大きな CIDR を取得できないよう制御する。

Org / OU 単位共有: RAM の principal に Organization ARN または OU ARN を指定することで、全 Account または特定 OU 以下の全 Account に一括共有できる。Account が新規追加された場合も自動的に Pool が共有されるため、Account オンボーディング手順を簡素化できる。

Reuse — 削除後の再割当ガード

VPC を削除すると、その VPC に割り当てられていた CIDR は Pool に即時返却される。オンプレ側の BGP ルーティングや Firewall ルールが削除済み VPC の CIDR を参照している場合、別 VPC に同一 CIDR が再割当されると通信が意図しない VPC に吸い込まれるリスクがある。

Pool に auto_import = false を設定することで、IPAM 管理外の CIDR が Pool のアドレス空間と重複していても自動取り込みされず、明示的な承認フローを強制できる。VPC 削除前後の CIDR 状態は aws ec2 get-ipam-pool-allocations で確認し、解放を確認してから次の割当を行う運用ルールを設ける。

Reuse ガードの具体的な運用手順:

# 1. 削除前: 現在の allocation 確認
aws ec2 get-ipam-pool-allocations \
  --ipam-pool-id "ipam-pool-XXXXX" \
  --query 'IpamPoolAllocations[?ResourceId==`vpc-XXXXXXXX`]' \
  --output table

# 2. VPC 削除後: CIDR が返却されたことを確認
aws ec2 get-ipam-pool-allocations \
  --ipam-pool-id "ipam-pool-XXXXX" \
  --filters "Name=resource-id,Values=vpc-XXXXXXXX" \
  --query 'IpamPoolAllocations[*].[Cidr,ResourceId,ResourceType]' \
  --output text

# 3. 返却確認後のみ次の VPC CIDR を割当
aws ec2 create-vpc \
  --ipv4-ipam-pool-id "ipam-pool-XXXXX" \
  --ipv4-netmask-length 20

Soft delete (手動 deallocation) によるガード: 特定の CIDR を一定期間使用不可にするには、IPAM Pool に対して手動 deallocation を実行し、その CIDR を「予約済み」状態にしておく方法がある。Pool の publicly_advertisable = false に設定した状態で手動 allocation し、実際の VPC には割当しないことで事実上の使用禁止 CIDR として管理できる。

Compliance — 重複検知とタグ強制

重複検知 (Auto-detect overlap): IPAM は Pool 内の Allocation 間でアドレス重複を自動検知する。Console の Scope ビューで重複を可視化でき、aws ec2 get-ipam-pool-allocations で CLI 確認できる。

Tag 強制 (allocation_resource_tags): Pool に allocation_resource_tags を設定すると、その Pool から CIDR を取得した VPC には指定タグが強制付与される。本番用 Pool から取得した VPC が Dev / Staging 環境として誤用されることを防ぐ監査証跡として有効である。

{
  "allocationResourceTags": [
 { "key": "Environment", "value": "production" },
 { "key": "ManagedBy","value": "IPAM" }
  ]
}

重複 CIDR の検出 CLI 例:

# IPAM Scope 全体での重複チェック
aws ec2 get-ipam-resource-cidrs \
  --ipam-scope-id "ipam-scope-XXXXX" \
  --filters "Name=overlapping-cidrs,Values=true" \
  --query 'IpamResourceCidrs[*].[ResourceId,Cidr,OverlappingCidrs]' \
  --output table

# Pool 内の全 Allocation 一覧 (使用率確認)
aws ec2 get-ipam-pool-allocations \
  --ipam-pool-id "ipam-pool-XXXXX" \
  --query 'sort_by(IpamPoolAllocations, &Cidr)[*].[Cidr,ResourceId,ResourceType,ResourceOwner]' \
  --output table

Config Rule 連携: AWS Config カスタムルールを使って「IPAM Pool 外の CIDR を持つ VPC」を自動検知し、非準拠 VPC を Config ダッシュボードに集約できる。IPAM の auto_import で既存 VPC を検出し、未管理 CIDR の存在を可視化するだけでなく、Config Rule で継続的な準拠監視を実施する体制が本番運用で求められる。

BYOIP — オンプレ IP を AWS に移行

BYOIP (Bring Your Own IP) は、組織が所有するパブリック IP アドレス空間を AWS に持ち込む機能である。オンプレ→AWS 移行時に既存の IP ブロックをそのまま AWS で使用したい場合や、自社所有の IP を AWS 環境で継続利用したい場合に使用する。

移行手順:
1. ROA (Route Origin Authorization) の作成 — 地域 Internet Registry (ARIN / RIPE / APNIC) で ROA を作成し、AS番号 16509 (AWS) を Origin AS として指定する
2. X.509 証明書の作成と AWS への提出 — IP アドレスの所有権を証明する証明書を自己署名で作成し、aws ec2 provision-byoip-cidr でアドレスブロックを登録する
3. IPAM への取り込み — BYOIP で登録したアドレスブロックを IPAM Public Pool に追加し、Elastic IP / ELB / CloudFront に割当する

aws ec2 provision-byoip-cidr \
  --cidr "203.0.113.0/24" \
  --cidr-authorization-context \
 Message="MESSAGE",\
 Signature="BASE64_ENCODED_SIGNATURE"

aws ec2 advertise-byoip-cidr --cidr "203.0.113.0/24"

IPv6 BYOIP: IPv6 アドレスブロック (/48 以上) も同様の手順で対応できる。IPv6 BYOIP は VPC に直接割当し、EC2 インスタンスにパブリック IPv6 アドレスを付与する用途に適している。

ROA 有効期限管理: ROA は発行後 90日〜1年の有効期限が多い。有効期限が切れると BGP 経路の正当性が失われ、AWS から IP が広報されなくなる。定期的な ROA 更新手続きをカレンダーに登録し、期限切れによる IP 広報停止を防ぐ。

IPAM 使用率モニタリング — CloudWatch メトリクスと通知

IPAM は Pool ごとに CloudWatch メトリクス を自動発行する。本番運用では Pool の使用率を継続的に監視し、枯渇前にアラートを発報する仕組みを整備する。

主なメトリクス:

CloudWatch Alarm と SNS Topic を組み合わせて枯渇警告を通知する Terraform 例:

resource "aws_cloudwatch_metric_alarm" "ipam_pool_usage_warning" {
  alarm_name = "ipam-pool-usage-warning"
  comparison_operator = "GreaterThanOrEqualToThreshold"
  evaluation_periods  = 2
  metric_name= "IPAddressUsagePercentage"
  namespace  = "AWS/IPAM"
  period  = 300
  statistic  = "Average"
  threshold  = 70

  dimensions = {
 IpamPoolId = aws_vpc_ipam_pool.region_tyo.id
  }

  alarm_description = "IPAM Pool 使用率が70%を超えました。Pool 拡張を検討してください。"
  alarm_actions  = [aws_sns_topic.ipam_alert.arn]
  ok_actions  = [aws_sns_topic.ipam_alert.arn]
}

IPAM Console の Resource Discovery 機能を有効化すると、Organizations 配下の全 Account × 全 Region の VPC CIDR を自動収集してスコープビューに集約できる。手動での IP 管理台帳との突き合わせ作業が不要になり、監査対応コストを大幅に削減できる。

§5 VPC Endpoint Deep Dive 本番運用 — Gateway × Interface × GatewayLB × Endpoint Service × PrivateLink Advanced × Cost最適化 ★山場2

VPC Endpoint は、VPC 内のリソースが AWS サービス / サードパーティサービスへ
インターネットを経由せずにアクセスするための機構である。
NAT Gateway や Internet Gateway を使わずにプライベート通信を確立できるため、
セキュリティ強化 + トラフィックコスト削減の両面で本番環境に不可欠な技術となっている。

しかし VPC Endpoint には4種類が存在し、それぞれ適用ユースケース・コスト構造・
設計上の制約が大きく異なる。誤った種類を選ぶと「無料になるはずの S3 アクセスに
Interface Endpoint を使って月数万円のコストが発生」「AZ 障害時に Endpoint が切れる」
といった本番インシデントに直結する。

§5.1 VPC Endpoint 4種比較

VPC Endpoint は以下の4種類に分類される。

┌─────────────────────────────────────────────────────────────────────────┐
│ VPC Endpoint 4種比較表│
├───────────────────┬──────────────────┬────────────────┬─────────────────┤
│種類│  対象サービス  │ コスト│通信方式│
├───────────────────┼──────────────────┼────────────────┼─────────────────┤
│ Gateway Endpoint  │ S3 / DynamoDB のみ│  無料 │ Route Table  │
│ ││ │ (prefix-list)│
├───────────────────┼──────────────────┼────────────────┼─────────────────┤
│ Interface Endpoint│ ほぼ全 AWS サービス│ $0.014/h × AZ │ ENI (PrivateLink)│
│ ││ + $0.01/GB  │ Private DNS  │
├───────────────────┼──────────────────┼────────────────┼─────────────────┤
│ GatewayLB Endpoint│ 3rd party firewall│ GLB 料金に含む │ Geneve トンネル │
│ │ / IDS/IPS  │ + $0.01/GB  │ (透過型)  │
├───────────────────┼──────────────────┼────────────────┼─────────────────┤
│ Endpoint Service  │ 自社サービス提供  │ NLB/GWLB 料金  │ PrivateLink  │
│ │ (Service Provider)│ + Endpoint 料金│ (承認制)  │
└───────────────────┴──────────────────┴────────────────┴─────────────────┘

§5.2 Gateway Endpoint — S3 / DynamoDB の無料本番設計

Gateway Endpoint は S3 と DynamoDB にのみ対応する Endpoint で、
完全無料かつデータ転送量無制限という特性を持つ。

動作原理は Route Table への prefix-list エントリ追加である。
VPC 内の EC2 / Lambda / Container が s3.amazonaws.com 宛にパケットを送ると、
Route Table の prefix-list エントリが該当し、AWS バックボーン経由で S3 に
ルーティングされる。インターネット経由のトラフィックが発生しないため
NAT Gateway 料金 ($0.045/h + $0.045/GB) も不要となる。

# Gateway Endpoint (S3) — Terraform
resource "aws_vpc_endpoint" "s3" {
  vpc_id= aws_vpc.main.id
  service_name= "com.amazonaws.${var.region}.s3"
  vpc_endpoint_type = "Gateway"
  route_table_ids= [
 aws_route_table.private.id,
 aws_route_table.isolated.id,
  ]

  policy = jsonencode({
 Version = "2012-10-17"
 Statement = [{
Effect = "Allow"
Principal = "*"
Action = ["s3:GetObject", "s3:PutObject", "s3:ListBucket"]
Resource  = [
  "arn:aws:s3:::${var.allowed_bucket_prefix}-*",
  "arn:aws:s3:::${var.allowed_bucket_prefix}-*/*",
]
 }]
  })

  tags = { Name = "${var.env}-s3-gateway-endpoint" }
}

# DynamoDB Gateway Endpoint (同一 Route Table に追加)
resource "aws_vpc_endpoint" "dynamodb" {
  vpc_id= aws_vpc.main.id
  service_name= "com.amazonaws.${var.region}.dynamodb"
  vpc_endpoint_type = "Gateway"
  route_table_ids= [aws_route_table.private.id]

  tags = { Name = "${var.env}-dynamodb-gateway-endpoint" }
}

Endpoint Policy は VPC Endpoint レベルの IAM 制限で、
バケット単位・アクション単位でアクセスを絞り込める。
例えば「この VPC からは自社バケットのみ GET/PUT 可 / 他社バケットへのアクセス禁止」
という制限を Endpoint Policy で実現できる。これによりデータ流出防止 (DLP) の追加ラインとして機能する。

Route Table には AWS 管理の prefix-list ID (pl-xxxxxxxx) が自動追加される。
このエントリは Endpoint 削除時に自動削除されるため、手動管理は不要。

§5.3 Interface Endpoint (PrivateLink) — ENI per AZ 本番設計

Interface Endpoint は PrivateLink を使って各 AZ のサブネット内に ENI (Elastic Network Interface)
を作成し、その ENI 経由で AWS サービスに接続する。

ほぼ全ての AWS サービス (ECR, STS, KMS, SNS, SQS, Secrets Manager, Systems Manager,
CloudWatch, Kinesis, CodeArtifact 等) が対応しており、Interface Endpoint を経由することで
VPC 内からインターネット経由なしに各サービス API を呼び出せる。

Private DNS hostname (デフォルト有効) が重要な機能で、
ecr.us-east-1.amazonaws.com のような標準の AWS サービスエンドポイント URL を
VPC 内で解決すると自動的に Interface Endpoint の ENI IP アドレスに向く。
アプリケーションのコード変更なしにプライベート接続に切り替えられる。

# Interface Endpoint (ECR) — Terraform 本番パターン (3AZ)
resource "aws_vpc_endpoint" "ecr_api" {
  vpc_id  = aws_vpc.main.id
  service_name  = "com.amazonaws.${var.region}.ecr.api"
  vpc_endpoint_type= "Interface"
  private_dns_enabled = true

  subnet_ids = [
 aws_subnet.private_az1.id,
 aws_subnet.private_az2.id,
 aws_subnet.private_az3.id,
  ]

  security_group_ids = [aws_security_group.endpoint.id]
  tags = { Name = "${var.env}-ecr-api-endpoint" }
}

resource "aws_vpc_endpoint" "ecr_dkr" {
  vpc_id  = aws_vpc.main.id
  service_name  = "com.amazonaws.${var.region}.ecr.dkr"
  vpc_endpoint_type= "Interface"
  private_dns_enabled = true

  subnet_ids = [
 aws_subnet.private_az1.id,
 aws_subnet.private_az2.id,
 aws_subnet.private_az3.id,
  ]

  security_group_ids = [aws_security_group.endpoint.id]
  tags = { Name = "${var.env}-ecr-dkr-endpoint" }
}

# Endpoint 専用 Security Group (VPC CIDR からの HTTPS のみ許可)
resource "aws_security_group" "endpoint" {
  name= "${var.env}-vpc-endpoint-sg"
  vpc_id = aws_vpc.main.id

  ingress {
 from_port= 443
 to_port  = 443
 protocol = "tcp"
 cidr_blocks = [var.vpc_cidr]
  }
  egress {
 from_port= 0
 to_port  = 0
 protocol = "-1"
 cidr_blocks = ["0.0.0.0/0"]
  }
}

§5.4 Gateway Load Balancer Endpoint — Inspection 透過挿入

Gateway Load Balancer (GWLB) Endpoint は、3rd party ファイアウォール / IDS/IPS アプライアンスを
VPC のトラフィックパスに透過的に挿入するための Endpoint 種別である。

通信フローは以下の通り:
1. クライアント VPC の Route Table に GWLB Endpoint をターゲットとするルートを設定
2. トラフィックが GWLB Endpoint → Geneve トンネル (UDP 6081) 経由でアプライアンス VPC へ転送
3. アプライアンス (Palo Alto / Fortinet / Check Point 等) で Inspection 実施
4. 許可トラフィックを GWLB 経由で返送 → 元の宛先に到達

Geneve トンネルにより元のパケットのフロー情報 (送信元/宛先 IP) を保持したまま
Inspection できるため、アプリケーションの IP アドレスを変更せずにセキュリティ検査を実現できる。
North-South トラフィック (Internet → VPC) だけでなく East-West トラフィック
(VPC 間 / Subnet 間) にも適用可能。

§5.5 Endpoint Service — PrivateLink 自前提供 (Service Provider 側)

Endpoint Service は「自社サービスを PrivateLink 経由で他の VPC / AWS Account に提供する」
Service Provider 側の仕組みである。

主要ユースケース:
– SaaS プロバイダーが顧客 VPC に PrivateLink でサービスを提供 (Datadog / Snowflake 等)
– 社内共有サービス (Vault / Jenkins / Artifactory) を他部門の VPC に提供
– マルチテナント SaaS の顧客ごとのネットワーク分離

動作原理:
Service Provider 側で NLB (Network Load Balancer) または GWLB を前段に置き、
その前に Endpoint Service を作成する。Service Consumer 側が Interface Endpoint を
作成して Service Provider の Endpoint Service に接続を要求すると、
Service Provider 側の承認 (Acceptance required) または自動承認によって
PrivateLink 接続が確立する。

# Endpoint Service (NLB前段) — Terraform 本番パターン
resource "aws_vpc_endpoint_service" "internal_api" {
  acceptance_required  = true
  network_load_balancer_arns = [aws_lb.internal_api.arn]

  tags = { Name = "${var.env}-internal-api-endpoint-service" }
}

# Service Consumer の Allow list (Principal ARN で制限)
resource "aws_vpc_endpoint_service_allowed_principal" "consumer_account" {
  vpc_endpoint_service_id = aws_vpc_endpoint_service.internal_api.id
  principal_arn  = "arn:aws:iam::${var.consumer_account_id}:root"
}

# Consumer 側 — Interface Endpoint で接続要求
resource "aws_vpc_endpoint" "internal_api_consumer" {
  vpc_id  = aws_vpc.consumer.id
  service_name  = aws_vpc_endpoint_service.internal_api.service_name
  vpc_endpoint_type= "Interface"
  private_dns_enabled = false

  subnet_ids= [aws_subnet.consumer_private.id]
  security_group_ids = [aws_security_group.consumer_endpoint.id]
}

承認フロー管理: acceptance_required = true の場合、
Consumer からの接続要求を Provider が明示的に承認するまで接続は確立しない。
大規模展開では Lambda + EventBridge で自動承認ロジックを実装するパターンが一般的。

Provider 側は aws ec2 describe-vpc-endpoint-connections で接続要求一覧を確認し、
aws ec2 accept-vpc-endpoint-connections で承認を実施する。

§5.6 PrivateLink Advanced — Cross-Region × VPC Peering 制約 × Consumer 制限

Cross-Region PrivateLink

PrivateLink は本来 Same-Region 内の通信を前提とするが、
Cross-Region PrivateLink は Inter-Region VPC Peering を経由することで
異なるリージョン間でも PrivateLink 接続を確立できる。

通信フロー:
1. Consumer VPC (us-east-1) と Proxy VPC (us-west-2) の間に Inter-Region VPC Peering を確立
2. Consumer VPC からのトラフィックを Peering 経由で Proxy VPC の Interface Endpoint に向ける
3. Proxy VPC の Interface Endpoint が Provider の Endpoint Service に接続

制約: VPC Peering 経由の PrivateLink アクセスは Same-Region では動作しない点に注意。
同一リージョン内の VPC Peering 越しには PrivateLink が届かないため、
同リージョン内の複数 VPC からアクセスさせたい場合は
各 VPC に個別に Interface Endpoint を作成するか、TGW 経由でセントラル Endpoint を設計する。

VPC Endpoint Policy による IAM 制限

Interface Endpoint にも Gateway Endpoint と同様に Endpoint Policy を設定できる。
Endpoint Policy は「この Endpoint を経由するリクエストに対する IAM 制限」として機能し、
Principal (呼び出し元) / Action / Resource の3軸で絞り込める。

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Effect": "Allow",
"Principal": {
  "AWS": "arn:aws:iam::123456789012:role/app-role"
},
"Action": [
  "secretsmanager:GetSecretValue",
  "secretsmanager:DescribeSecret"
],
"Resource": "arn:aws:secretsmanager:us-east-1:123456789012:secret:prod/*"
 }
  ]
}

aws ec2 コマンドによる Endpoint 管理

# 利用可能な VPC Endpoint サービス一覧を確認
aws ec2 describe-vpc-endpoint-services \
  --region us-east-1 \
  --query 'ServiceDetails[].{Name:ServiceName,Type:ServiceType}' \
  --output table

# 作成済み VPC Endpoint の一覧確認
aws ec2 describe-vpc-endpoints \
  --region us-east-1 \
  --filters "Name=vpc-id,Values=vpc-xxxxxxxxxxxxxxxxx" \
  --query 'VpcEndpoints[].{Id:VpcEndpointId,Service:ServiceName,State:State,Type:VpcEndpointType}' \
  --output table

# Interface Endpoint を CLI で作成 (S3 Interface Endpoint の例)
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-xxxxxxxxxxxxxxxxx \
  --service-name com.amazonaws.us-east-1.s3 \
  --vpc-endpoint-type Interface \
  --subnet-ids subnet-aaa subnet-bbb subnet-ccc \
  --security-group-ids sg-xxxxxxxxxxxxxxxxx \
  --private-dns-enabled \
  --region us-east-1

# VPC Endpoint Policy の更新 (Endpoint Policy 変更)
aws ec2 modify-vpc-endpoint \
  --vpc-endpoint-id vpce-xxxxxxxxxxxxxxxxx \
  --policy-document file://endpoint-policy.json \
  --region us-east-1

# Endpoint Service への接続要求を承認 (Provider 側作業)
aws ec2 accept-vpc-endpoint-connections \
  --service-id vpce-svc-xxxxxxxxxxxxxxxxx \
  --vpc-endpoint-ids vpce-yyyyyyyyyyyyyyyyy \
  --region us-east-1

§5.7 Cost最適化 — Interface Endpoint × AZ × サービス数の3軸コスト爆発

Interface Endpoint のコスト構造は以下の3軸で決まる。

月額試算:
  $0.014/h × AZ数 × サービス数 × 730h/月 + $0.01/GB × データ転送量

例1 (標準構成 3AZ × 10サービス):
  $0.014 × 3 × 10 × 730 = $3,066/月 (転送料別)

例2 (フルスタック 3AZ × 20サービス):
  $0.014 × 3 × 20 × 730 = $6,132/月 (転送料別)

例3 (NAT Gateway との比較):
  NAT GW: $0.045/h × 3AZ × 730h = $98.55/月 + データ転送 $0.045/GB
  Interface Endpoint 10サービス: $3,066/月 + $0.01/GB
  → Interface Endpoint 追加の純増コスト: $3,066 - $98.55 = 約$2,967/月増

コスト最適化3戦略:

戦略1 — Gateway Endpoint 優先 (最重要):
S3 / DynamoDB は無条件で Gateway Endpoint に切り替える。
大量 S3 転送 (データレイク / ログ蓄積) では NAT Gateway の $0.045/GB が消えるため ROI は即日。
既存 Interface Endpoint が S3 / DynamoDB 向けに存在する場合は即時削除を検討。

戦略2 — AZ 数最小化:
開発 / テスト環境は 1 AZ のみで Interface Endpoint を作成する。
本番は 3 AZ で可用性を確保するが、ステージングを 1 AZ にするだけでコストが 1/3 になる。
例: 10 サービス × 1 AZ × $0.014 × 730 = $1,022/月 (3 AZ 比で $2,044 削減)。

戦略3 — NAT Gateway + Public Endpoint 比較:
一部サービスはあえて NAT Gateway 経由の Public Endpoint を使い続ける方がコスト優位になる。
特に「呼び出し頻度が低い / データ転送量が少ない」サービスは
Interface Endpoint (固定 $0.014/h = $10.22/月/AZ) より NAT Gateway (従量課金) の方が安い。
計算式: Interface Endpoint 月額 > NAT Gateway 月額 + データ転送料 の場合は NAT Gateway が優位。

§6 詰まりポイント7選 図解 (Mermaid01 判断ツリー)

Cloud WAN / VPC Lattice / IPAM / VPC Endpoint の4領域で発生しやすい
詰まりポイントを7パターンに体系化した。まず Mermaid01 で全体の判断ツリーを確認し、
各パターンの詳細と対処法を整理する。

Mermaid01: 詰まり7選 判断ツリー (4軸)

graph TD
 A[詰まり発生] --> B{どの領域?}
 B --> C[Cloud WAN]
 B --> D[VPC Lattice]
 B --> E[IPAM]
 B --> F[VPC Endpoint]
 C --> C1{Policy Document エラー?}
 C1 -->|ConflictException| C2[Pattern 1: Policy Document debug]
 C1 -->|TGW vs CloudWAN迷い| C3[Pattern 7: 選択基準ガイドライン]
 D --> D1{HTTP 401 / Auth エラー?}
 D1 -->|401返却| D2[Pattern 2: Auth Policy debug]
 D1 -->|命名・削除問題| D3[Pattern 6: 命名規則統一]
 E --> E1{子 Pool 作成失敗?}
 E1 -->|CidrNotWithinParent| E2[Pattern 3: Pool 階層設計]
 E1 -->|Cross-account失敗| E3[Pattern 5: RAM 共有設定]
 F --> F1{コスト爆発?}
 F1 -->|Interface Endpoint過多| F2[Pattern 4: コスト最適化]

Pattern 1: Cloud WAN Policy Document debug

症状: put-core-network-policy 実行後の Apply フェーズで ConflictException が発生し、
Network Policy の適用が失敗する。変更内容がロールバックされる。

原因の特定:

1. JSON 構文ミス — Policy Document の JSON が不正な場合、Apply フェーズまで検出されない
2. Segment 重複 — 同一名の Segment が複数定義されている
3. Attachment-policy 矛盾 — Attachment が存在しない Segment を参照している
4. Change set の競合 — 前回の Change set が完了前に次の変更を適用しようとした

対処法:

# Step1: Policy Document の事前検証
aws networkmanager validate-core-network-policy \
  --core-network-id cn-XXXXXXXXXXXX \
  --policy-document file://policy.json

# Step2: Change set 状態確認 (前回 Change set 完了を確認)
aws networkmanager get-core-network-change-set \
  --core-network-id cn-XXXXXXXXXXXX \
  --policy-version-id 1

# Step3: 適用前に現在の Policy を確認
aws networkmanager get-core-network-policy \
  --core-network-id cn-XXXXXXXXXXXX \
  --alias LATEST

validate-core-network-policy は Apply 前に JSON 構文エラー・Segment 定義の矛盾・
Attachment 参照の整合性を検証する。本番環境への Apply 前に必ず実行すること。
Change set は前回分が完了状態であることを確認してから次の Policy 変更を投入する。

Pattern 2: VPC Lattice Auth Policy 401

症状: VPC Lattice Service を呼び出すと HTTP 401 が返却される。
サービス自体は起動しており、直接アクセスでは正常動作する。

原因の特定:

1. sigv4 署名が付与されていない — SDK / curl から署名なしで呼び出している
2. IAM Policy の Principal 設定ミス — aws:PrincipalAccount 条件が正しくない
3. Auth Policy の Action 不足 — vpc-lattice-svcs:Invoke が許可されていない
4. Service Network の Auth type 設定 — NONE と AWS_IAM が Service / Service Network 間で混在

対処法:

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Effect": "Allow",
"Principal": {
  "AWS": "arn:aws:iam::123456789012:role/ServiceCallerRole"
},
"Action": "vpc-lattice-svcs:Invoke",
"Resource": "*",
"Condition": {
  "StringEquals": {
 "aws:PrincipalAccount": "123456789012"
  }
}
 }
  ]
}

Auth Policy の設定は Service レベルと Service Network レベルの2箇所で管理される。
Service Network 側が AWS_IAM に設定されている場合、Service 側も AWS_IAM に統一が必要。
vpc-lattice-svcs:Invoke が Action として明示されていない Policy は即座に 401 となる。

Pattern 3: IPAM Pool 階層設計失敗

症状: 子 Pool 作成時に Cidr is not within parent pool エラー。
または後から Account / Region 追加時に割当可能な CIDR が枯渇する。

原因の特定:

1. 親 Pool の CIDR が小さすぎる — 将来のアカウント追加を見込んでいない
2. Region Pool 数の見積もり不足 — 新 Region 追加時に親 Pool の分割数が不足
3. Account Pool の最小サイズ制限 — VPC あたり複数サブネットを必要とする場合に空間が不足

対処法:

# Top-level Pool: 組織全体 (10.0.0.0/8 = 約1677万アドレス)
resource "aws_vpc_ipam_pool" "top" {
  address_family = "ipv4"
  description = "Org Top-level Pool"
}
resource "aws_vpc_ipam_pool_cidr" "top" {
  ipam_pool_id = aws_vpc_ipam_pool.top.id
  cidr= "10.0.0.0/8"
}

# Region Pool: ap-northeast-1 (10.0.0.0/12 = 最大16個の /16 割当を収容)
resource "aws_vpc_ipam_pool" "region_apne1" {
  address_family= "ipv4"
  locale  = "ap-northeast-1"
  source_ipam_pool_id = aws_vpc_ipam_pool.top.id
  description= "ap-northeast-1 Region Pool"
}
resource "aws_vpc_ipam_pool_cidr" "region_apne1" {
  ipam_pool_id = aws_vpc_ipam_pool.region_apne1.id
  cidr= "10.0.0.0/12"
}

# Account Pool: 各 Account に /20 を動的割当 (VPC 16本 × /24 を収容可能)
resource "aws_vpc_ipam_pool" "account_prod" {
  address_family= "ipv4"
  locale  = "ap-northeast-1"
  source_ipam_pool_id = aws_vpc_ipam_pool.region_apne1.id
  description= "Production Account Pool"
}

初期設計時に「5年後の VPC 数 × Account 数 × Region 数」で CIDR 分割数を見積もり、
Top-level Pool は /8 程度の大きな空間を確保することを推奨する。
後から Top-level Pool を拡張するには削除・再作成が必要なため、初期設計が最重要。

Pattern 4: VPC Endpoint コスト爆発

症状: 月額請求が数百〜数千ドルに膨らみ、調査すると VPC Interface Endpoint の費用が大部分を占める。

原因の特定:

Interface Endpoint の費用構造: $0.014/h × AZ 数 × サービス数 × 730h/月

コスト試算例:
  AZ=3 × サービス=20 の場合:
 $0.014 × 3 × 20 × 730 = $613/月 (データ転送費除く)

  S3 / DynamoDB を Interface Endpoint で構成している場合の無駄:
 S3 1本:  $0.014 × 3AZ × 730h = $30.66/月 → Gateway Endpoint (無料) に変更で即時ゼロ
 DDB 1本: $0.014 × 3AZ × 730h = $30.66/月 → 同上

  最適化後試算 (S3/DDB を Gateway に変更 + AZ=2 に削減 + サービス=14 に絞り込み):
 $0.014 × 2 × 14 × 730 = $286/月 (53%削減)

Pattern 5: Cross-account IPAM Allocation 失敗

症状: 別 Account から VPC 作成時に No allocation found in pool エラー。
IPAM Pool は存在するが、他 Account からの参照ができない。

原因の特定:

1. RAM (Resource Access Manager) でのリソース共有が未設定
2. AWS Organizations の Trusted Access が未有効化
3. Consumer Account の Pool への Allocation 権限が不足

対処法:

# Step1: AWS Organizations での IPAM Trusted Access 有効化 (管理 Account)
aws organizations enable-aws-service-access \
  --service-principal ipam.amazonaws.com

# Step2: RAM でリソース共有を作成 (IPAM 管理 Account)
aws ram create-resource-share \
  --name "IPAM-Pool-Share" \
  --resource-arns \
 "arn:aws:ec2:ap-northeast-1:MGMT_ACCOUNT:ipam-pool/ipam-pool-XXXX" \
  --principals \
 "arn:aws:organizations::MGMT_ACCOUNT:ou/o-XXXX/ou-XXXX-XXXX"

# Step3: Consumer Account での Pool Allocation 確認
aws ec2 describe-ipam-pool-allocations \
  --ipam-pool-id ipam-pool-XXXX

Pattern 6: VPC Lattice Service Network 命名衝突

症状: 同名の Service Network を再作成しようとするとエラー。削除直後に同名で再作成しようとしても
エラーが発生するか、削除がしばらく完了しない。

原因の特定:

• Service Network の名前は Account 内でグローバルに一意制約がある
• 削除後も Soft delete retention 期間中は名前が予約されている
• リブランディング目的での名称変更は新規作成 + Attachment 移行が必要

対処法:

推奨命名規則: {account_alias}-{region_code}-{purpose}-{env}

良い例:
  mycompany-apne1-payment-prod
  mycompany-apne1-payment-dev
  mycompany-use1-auth-prod

禁止パターン:
  ❌ payment  (Purpose のみ — Account/Region 識別不可)
  ❌ prod  (環境のみ — 複数サービスが将来競合)
  ❌ lattice-svc (汎用名 — 移行時に再利用不可)
  ❌ service-mesh-1 (連番 — 削除・再作成時に番号管理が発生)

Pattern 7: TGW vs Cloud WAN 選択判断ミス

症状: TGW で構築後に運用負荷が増大し Cloud WAN への移行を検討。
または Cloud WAN を導入したが機能過剰でコスト超過。

原因の特定:

• 規模・運用負荷・コストの3軸でのトレードオフ評価が不足
• TGW は Single-Region 向けに最適化されており Multi-Region では Route Table 管理が複雑化
• Cloud WAN は Network Policy Document による宣言型管理が強みだが Core Network の固定費が高い

対処法:

選択ガイドライン:

VPC 数 〜10本 / Single-Region:
  → TGW (シンプル / 基本料金 $0.05/h + attachment $0.05/h)

VPC 数 11〜30本 / 2 Region 以上:
  → TGW Multi-Region (Region 間 TGW Peering) または Cloud WAN 移行検討開始

VPC 数 30本超 / Multi-Region / Multi-Account / 数百 VPC 規模:
  → Cloud WAN (Network Policy Document / Global Manager / Segment 自動管理)

コスト比較 (参考):
  TGW: $0.05/h (本体) + $0.05/h × attachment 数 + データ転送料
  Cloud WAN: Core Network $0.10/h + attachment $0.05/h + データ転送料
  → Cloud WAN 固定費 Core Network $73/月 が追加で発生するが
 Route Table 手動管理コスト削減効果が大きい規模になると逆転する

運用負荷比較:
  TGW: Route Table を手動管理 → VPC 増加で管理コストが線形以上に増大
  Cloud WAN: Policy Document で宣言型 → VPC 増加でも管理コストはほぼ一定

§7 アンチパターン → 正解パターン変換演習 (5問)

4領域の本番設計でよく見られるアンチパターンを5問の演習形式で整理する。
❌ アンチパターン (設計の問題点) → ✅ 正解パターン (本番設計) の変換を通じて、
各設計判断の根拠を身につける。

Q1: TGW 手動メッシュ → Cloud WAN Network Policy Document

❌ アンチパターン: 数十 VPC を TGW Route Table で手動管理

# ❌ TGW Route Table を手動でメッシュ接続 (VPC 増加で管理が破綻)
resource "aws_ec2_transit_gateway_route" "prod_to_shared" {
  destination_cidr_block= "10.1.0.0/16"
  transit_gateway_attachment_id  = aws_ec2_transit_gateway_vpc_attachment.shared.id
  transit_gateway_route_table_id = aws_ec2_transit_gateway_route_table.prod.id
}
resource "aws_ec2_transit_gateway_route" "prod_to_dev" {
  destination_cidr_block= "10.2.0.0/16"
  transit_gateway_attachment_id  = aws_ec2_transit_gateway_vpc_attachment.dev.id
  transit_gateway_route_table_id = aws_ec2_transit_gateway_route_table.prod.id
}
# VPC が増えるたびに Route を手動追加 → VPC数30本超で Route Table 管理が破綻

✅ 正解パターン: Cloud WAN Policy Document で Segment 宣言 + 自動 Apply

# ✅ Cloud WAN Network Policy Document (JSON宣言型)
resource "aws_networkmanager_core_network_policy_attachment" "main" {
  core_network_id = aws_networkmanager_core_network.main.id
  policy_document = jsonencode({
 "version" : "2021.12",
 "core-network-configuration" : {
"vpn-ecmp-support" : false,
"asn-ranges" : ["64512-64555"],
"edge-locations" : [
  { "location" : "ap-northeast-1" },
  { "location" : "us-east-1" }
]
 },
 "segments" : [
{ "name" : "production", "isolate-attachments" : false },
{ "name" : "development", "isolate-attachments" : true },
{ "name" : "shared", "isolate-attachments" : false }
 ],
 "attachment-policies" : [
{
  "rule-number" : 100,
  "conditions" : [{ "type" : "tag-value", "operator" : "equals", "key" : "env", "value" : "prod" }],
  "action" : { "association-method" : "constant", "segment" : "production" }
}
 ],
 "segment-actions" : [
{
  "action" : "share",
  "mode" : "attachment-route",
  "segment" : "shared",
  "share-with" : ["production", "development"]
}
 ]
  })
}
# VPC が増えても Tag を付与するだけで自動的に Segment に配置 → 管理コストはほぼ一定

解説: TGW の手動 Route Table 管理は VPC 数が増えると管理コストが増大する。
Cloud WAN の Policy Document は宣言型で Segment 設計と Tag ベースの自動配置により
VPC 数が増えても管理コストはほぼ一定に保たれる。30 VPC を超える Multi-Region 環境では
Cloud WAN への移行を強く推奨する。

Q2: 静的 IP 割当 (Spreadsheet 管理) → IPAM Pool 階層 + 動的 Allocation

❌ アンチパターン: Excel で IP アドレスを手動管理

❌ Spreadsheet で IP 管理 (Account 数増加で重複チェックが困難)

アカウント名 | CIDR | 用途  | 管理者
prod-001  | 10.0.0.0/24| 本番Web  | 田中
prod-002  | 10.0.1.0/24| 本番DB| 鈴木
dev-001| 10.0.0.0/24| 開発Web  | 佐藤  ← prod-001 と重複！

問題点:
  - Account 数増加で重複チェックが困難
  - 退職者の管理 Spreadsheet が行方不明になるリスク
  - Multi-Region 対応で複数 Sheet に分散 → 整合性維持不可
  - VPC Peering / TGW 接続時に重複 CIDR でルーティング障害

✅ 正解パターン: IPAM Pool 階層 + VPC 作成時の自動 Allocation

# ✅ IPAM Pool から VPC 作成時に自動割当 (重複ゼロ / 監査証跡自動記録)
resource "aws_vpc" "main" {
  ipv4_ipam_pool_id= var.account_ipam_pool_id
  ipv4_netmask_length = 24
  # CIDR は IPAM が自動決定 → 重複なし・割当履歴は IPAM コンソールで追跡可能
}

解説: IPAM を使うと VPC 作成時に CIDR が自動割当されるため、IP 重複が構造的に発生しない。
割当履歴は IPAM コンソールで追跡可能で、Compliance チェックも自動化できる。
Spreadsheet 管理は Account 数が10を超えた時点で IPAM へ移行することを推奨する。

Q3: Service Discovery 単独 (Cloud Map のみ) → VPC Lattice Service Network + Auth Policy

❌ アンチパターン: Cloud Map + 自前 IAM 検証でサービス間認証を実装

❌ 各サービスに認証ロジックを個別実装

問題点:
  - サービスAがサービスBを呼ぶたびに sigv4 署名検証コードが各サービスに重複
  - 認証ポリシーの変更が全サービスのコード変更を要求
  - Cloud Map での Service Discovery は名前解決のみ (認証は各サービスが独自実装)
  - マイクロサービス数が増えるほど認証コードの管理コストが増大

✅ 正解パターン: VPC Lattice Service Network + Auth Policy で認証を一元化

# ✅ VPC Lattice Service Network (認証ロジックを Infrastructure 層で一元管理)
resource "aws_vpclattice_service_network" "main" {
  name= "mycompany-apne1-mesh-prod"
  auth_type = "AWS_IAM"
}

resource "aws_vpclattice_auth_policy" "service_b" {
  resource_identifier = aws_vpclattice_service.service_b.arn
  policy = jsonencode({
 "Version" : "2012-10-17",
 "Statement" : [{
"Effect" : "Allow",
"Principal" : { "AWS" : "arn:aws:iam::123456789012:role/ServiceARole" },
"Action" : "vpc-lattice-svcs:Invoke",
"Resource" : "*"
 }]
  })
}
# 認証ロジックは VPC Lattice が担当 → 各サービスは SDK の sigv4 自動署名のみでよい

解説: VPC Lattice の Auth Policy を使うと、サービス間認証の制御を Infrastructure 層で一元管理できる。
各サービスは SDK の sigv4 自動署名を使うだけでよく、認証ロジックの重複実装を排除できる。
マイクロサービス数が増えるほど、この一元化の効果が大きくなる。

Q4: NAT GW 全リージョン → Interface Endpoint 最適化 + Gateway Endpoint 併用

❌ アンチパターン: 全 AWS API を NAT GW 経由でアクセス

❌ NAT GW 経由で全 AWS API にアクセス

コスト構造:
  NAT GW 基本料金: $0.045/h × 2 AZ = $65.70/月
  データ処理料金:$0.045/GB (S3, DynamoDB へのアクセスも含む全通信)

問題: S3 / DynamoDB は Gateway Endpoint (無料) で代替可能なのに
  NAT GW 経由でデータ転送料が発生し続ける

✅ 正解パターン: S3/DDB は Gateway Endpoint (無料) + その他は Interface Endpoint 厳選

# ✅ Gateway Endpoint (S3 / DynamoDB = 無料)
resource "aws_vpc_endpoint" "s3" {
  vpc_id= aws_vpc.main.id
  service_name= "com.amazonaws.ap-northeast-1.s3"
  vpc_endpoint_type = "Gateway"
  route_table_ids= [aws_route_table.private.id]
}
resource "aws_vpc_endpoint" "dynamodb" {
  vpc_id= aws_vpc.main.id
  service_name= "com.amazonaws.ap-northeast-1.dynamodb"
  vpc_endpoint_type = "Gateway"
  route_table_ids= [aws_route_table.private.id]
}

# Interface Endpoint は本当に必要なサービスのみ (ECR / Secrets Manager 等)
resource "aws_vpc_endpoint" "ecr_api" {
  vpc_id  = aws_vpc.main.id
  service_name  = "com.amazonaws.ap-northeast-1.ecr.api"
  vpc_endpoint_type= "Interface"
  subnet_ids = [aws_subnet.private_a.id, aws_subnet.private_b.id]
  security_group_ids  = [aws_security_group.endpoint.id]
  private_dns_enabled = true
}

解説: S3 と DynamoDB は Gateway Endpoint を使うことで無料かつ Route Table 経由でアクセスできる。
Interface Endpoint は必要なサービスのみに絞り、AZ 数も最低限 (2AZ) に設定することで
コストを大幅に削減できる。

Q5: 1 VPC Endpoint 多 AZ 配置 → Endpoint Service 分散 + AZ 別 Endpoint

❌ アンチパターン: 単一 VPC Endpoint に全 AZ ENI を配置

❌ 全 AZ に ENI を配置した単一 Endpoint

問題点:
  - ENI 制限 (Account あたりの ENI 上限) に早期到達
  - AZ × サービス数の乗算コスト:
 $0.014 × 6 AZ × 20 サービス = $1,214/月
  - Endpoint 障害時に全 AZ が影響を受ける可能性
  - Multi-account 環境では各 Account が重複して Endpoint を作成

✅ 正解パターン: Endpoint Service で Service Provider 化 + Consumer 側で AZ 別 Endpoint

# ✅ Endpoint Service (Provider 側: 1本の NLB でサービス化)
resource "aws_vpc_endpoint_service" "my_service" {
  acceptance_required  = false
  network_load_balancer_arns = [aws_lb.internal_nlb.arn]
  allowed_principals= ["arn:aws:iam::CONSUMER_ACCOUNT:root"]
  tags = { Name = "my-internal-service" }
}

# Consumer 側: 必要な AZ のみに Endpoint を作成 (ENI 数を最小化)
resource "aws_vpc_endpoint" "consumer" {
  vpc_id  = aws_vpc.consumer.id
  service_name  = aws_vpc_endpoint_service.my_service.service_name
  vpc_endpoint_type= "Interface"
  subnet_ids = [aws_subnet.consumer_a.id]
  private_dns_enabled = true
}

解説: Endpoint Service (PrivateLink) を使うと、自前サービスを AWS 上で「共有サービス化」できる。
Consumer 側は必要な AZ にのみ Endpoint を作成するため、ENI 数とコストを最適化できる。
Multi-Account 環境では Provider Account 1個の Endpoint Service を複数 Consumer が参照する構造が
最もコスト効率が高い。

§8 まとめ + Network三部作完成 + 52記事化達成 + 全軸クロスリンク (Mermaid02)

§8-1 本番運用4領域 まとめ

本記事では Cloud WAN / VPC Lattice / IPAM advanced / VPC Endpoint deep dive の4領域を
体系的に解説した。各領域の本番運用ポイントをまとめる。

Cloud WAN 本番運用ポイント

Cloud WAN の本質は「Network Policy Document による宣言型 Global Network 管理」にある。
単一の JSON ファイルで Core Network の全構成を定義し、Segment 設計と Attachment Policy により
VPC をタグベースで自動的に論理ネットワークに配置できる。

本番運用で抑えるべき3原則:

• Policy Document First: Network 設計変更は必ず Policy Document に反映し、
  手動 Route Table 操作は行わない。Change set の状態確認 + validate-core-network-policy を
  Apply 前の必須フローとして定着させる。
• Segment-first 設計: Production / Development / Shared の最低3 Segment を初期設計時に定義し、
  後からの Segment 追加による既存 Attachment への影響を事前に評価する。
• Global Manager 活用: Network Manager コンソールで全 Region の Route / Attachment / Policy を
  一元的に監視し、Change set の適用前後で状態を確認する。

VPC Lattice 本番運用ポイント

VPC Lattice は「Service Network を中心とした L7 Service Mesh」を実現する。
個別サービスの sigv4 署名を前提に、Auth Policy で Service-to-Service 認証を
Infrastructure 層で一元管理できる点が最大の強みである。

本番運用で抑えるべき3原則:

• Auth Policy の一元管理: サービス間認証ロジックをアプリケーションコードから分離し、
  IAM ベースの Auth Policy で宣言型管理する。Service Network と Service の Auth type を統一する。
• Custom Domain + Weighted Routing: Canary デプロイは VPC Lattice の Weighted Routing を
  活用し、コード変更不要でトラフィックを段階的に切り替える。
• Service Network 命名規則: Account-Region-Purpose-Env 形式で統一し、
  削除・再作成時の命名衝突を事前に回避する。

IPAM Advanced 本番運用ポイント

IPAM は「IP アドレス空間の Single Source of Truth」として機能する。
Top-level → Region → Account の3段階 Pool 階層で、組織全体の IP 管理を構造化する。

本番運用で抑えるべき3原則:

• 5年先の CIDR 分割設計: 初期設計時に将来の Account / Region 数を見積もり、
  Top-level Pool は /8 以上の空間を確保する。後から拡張するには削除・再作成が必要。
• Cross-account の RAM 設定: Organizations の Trusted Access + RAM での Pool 共有を
  初期構築時に設定し、新規 Account 追加のオンボーディングを自動化する。
• BYOIP のコンプライアンス活用: オンプレ IP を AWS に持ち込む際は BYOIP + IPAM で
  統合管理し、オンプレ → クラウドの IP 移行を段階的に進める。

VPC Endpoint Deep Dive 本番運用ポイント

VPC Endpoint は「コスト最適化」と「セキュリティ」の両面で重要な設計要素である。
S3 / DynamoDB の Gateway Endpoint (無料) を最初に設定し、その後 Interface Endpoint を
本当に必要なサービスのみに絞ることがコスト最適化の基本戦略である。

本番運用で抑えるべき3原則:

• Gateway Endpoint 優先: S3 / DynamoDB は必ず Gateway Endpoint (無料) を使用し、
  Interface Endpoint でのデータ転送費を排除する。
• Interface Endpoint × AZ × サービス数の3軸コスト管理: 月額コストは
  $0.014 × AZ数 × サービス数 × 730h で計算し、定期的に不要 Endpoint を棚卸しする。
• Endpoint Service による集約: Multi-account 環境では自前サービスを Endpoint Service で
  「共有 PrivateLink サービス」として提供し、Consumer 側の Endpoint 数を最小化する。

4領域横断の本番運用原則

1. Network as Code: Cloud WAN Policy Document / IPAM Terraform / VPC Lattice Auth Policy をすべてコードで管理し手動操作を排除することで構成ドリフトを防止する。
2. Segment-first 設計: Cloud WAN の Segment は後から変更するとコストが高い。初期設計時に Production / Shared / Dev / Security の最低4 Segment を定義する。
3. Cost 可視化と定期棚卸し: Interface Endpoint / Cloud WAN Attachment のコストは隔月で Cost Explorer でレビューし不要リソースを早期に廃止する。
4. Cross-account 共有設計: IPAM Pool / Endpoint Service / VPC Lattice Service Network を Organizations 単位でデザインし Account 単位での重複リソース作成を構造的に排除する。

§8-4 Mermaid02: Network三部作マップ + 全軸接続図

graph LR
 Vol1[Network Vol1<br/>VPC基礎層<br/>Subnet/Route/NACL/SG]
 Vol2[Network Vol2<br/>Hybrid接続層<br/>TGW/DirectConnect/VPN]
 Vol3[Network Vol3<br/>Global/ServiceMesh/IP管理<br/>CloudWAN/VPCLattice/IPAM/Endpoint]
 Vol1 --> Vol2 --> Vol3
 Container[Container Vol3<br/>EKS本番運用]
 MultiAccount[Multi-Account<br/>Organizations/LandingZone]
 Security[Security Vol3<br/>IAM/WAF]
 Edge[Edge<br/>CloudFront/Route53]
 Serverless[Serverless Vol1-2<br/>Lambda/APIGateway]
 Observability[Observability Vol3<br/>AppSignals/SLO]
 Container -->|EKS x VPC Lattice Service Mesh| Vol3
 MultiAccount -->|Cross-account IPAM allocation| Vol3
 Security -->|VPC Lattice Auth Policy x IAM| Vol3
 Edge -->|CloudFront x VPC Endpoint Private Origin| Vol3
 Serverless -->|Lambda x VPC Endpoint x PrivateLink| Vol3
 Observability -->|VPC Flow Logs x CloudWAN telemetry| Vol3

§8-5 関連記事・読者 CTA

数百 VPC × Multi-Region 規模の運用事例をお待ちしています

本記事は理論・設計・実装の観点から Cloud WAN / VPC Lattice / IPAM / VPC Endpoint を体系化したが、現場での実際の運用事例 (成功例・失敗例・ハマりポイント) は記事が提供できる情報を超えた価値を持つ。

以下の観点でのフィードバックを特にお待ちしています:

• 実際に Cloud WAN を本番導入した際の Network Policy Document 設計で詰まった点
• VPC Lattice の Auth Policy 実装で遭遇したエッジケース
• IPAM Pool 階層設計で後から「こうすべきだった」と感じた判断
• VPC Endpoint コスト最適化で実際に発見したコスト削減の数字

Network Vol4 で深掘りすべきテーマ投票 (5選択肢)

Vol4 の執筆テーマを検討中。以下の5つから最も需要の高いテーマをコメント欄または SNS でご意見ください:

1. Direct Connect SiteLink + AWS Transit Hub: Multi-Region Direct Connect 冗長化と SiteLink を使った拠点間通信最適化
2. IPv6 完全対応設計: Dual-stack VPC / IPAM IPv6 Pool / VPC Lattice IPv6 対応
3. VPC Lattice Advanced: Resource Gateway / Resource Configuration / Lattice + EKS 深掘り
4. Cloud WAN Multi-Region 深掘り: Multi-Region Core Network の実装例 / Segment 間の細粒度ルーティング設計
5. Network Firewall × Cloud WAN 統合: インライン検査 / Gateway Load Balancer Endpoint + Firewall 統合設計

フィードバックチャネル

記事下のコメント欄、または各 SNS でシェアいただけると励みになります。「規模 (VPC 数 / Account 数 / Region 数) × 詰まりパターン」を添えていただけると記事改善に直接反映します。

Network 三部作完成後も、AWS 本番運用シリーズは継続して新軸・新 Vol を追加予定。次軸・次 Vol のリリース通知を希望される方は RSS フィードまたは SNS でのフォローを推奨します。

読者の運用規模別 学習ステップ推奨

• 〜10 VPC / 1 Account: Vol1 → Vol2 通読で十分。本Vol3は「Cloud WAN は不要 / VPC Endpoint コスト最適化のみ参考」が適切ガイダンス。
• 数十 VPC / 数〜十数 Account: Vol1+Vol2+Vol3 通読推奨。Cloud WAN 採用検討 + IPAM 階層設計が現実的課題。
• 数百 VPC / 数十〜百 Account: Vol3 を基盤に Vol4 候補テーマを並行検討。Cloud WAN + VPC Lattice + IPAM + Endpoint Service の4本柱を本番設計に組み込む。

本記事が読者の AWS Network 本番設計の意思決定を支える総合的な情報源となることを願っている。引き続き Vol4 / Vol5 を含めた継続的なシリーズ拡充にご期待いただきたい。

Network 三部作 通読ロードマップ (再掲)

Vol1 (VPC基礎層) → Vol2 (Hybrid接続層) → Vol3 (Global / Service Mesh / IP管理層) の順で通読することで、AWS Network 設計の「単一VPC内 → VPC間 → 横断統一管理」という階層的理解が獲得できる。逆方向 (Vol3 → Vol2 → Vol1) では用語の前提知識不足で読みにくくなるため、Vol1 から順に積み上げることを強く推奨する。

最後に

Cloud WAN / VPC Lattice / IPAM advanced / VPC Endpoint deep dive の4本柱は、それぞれ単独で1記事構成できるほど深いトピック群である。本Vol3 では各サービスの本番運用に必要な核心ポイントを4本まとめて凝縮したが、Vol4 以降では読者のフィードバックに基づき特定のトピックを単独深掘りする計画である。AWS Network 本番運用シリーズ三部作の完成記事として、本記事が読者の実務に長く参照される一冊となることを願う。

コミュニティへの貢献のお願い

本シリーズは読者の本番運用知見を取り込んでアップデートしていく方針である。皆様の運用現場で得た成功・失敗事例を共有いただけることが、シリーズ全体の品質向上の最大の原動力となる。コメント欄・SNS・問い合わせフォームのいずれの経路でも歓迎するので、気軽にフィードバックを寄せていただきたい。

AWS の最新サービス情報も日々更新されているため、本記事の内容について「より新しい情報あり」「実装方法が変わった」等の指摘もありがたく受け取る。AWS Network 本番運用の集合知が、皆様のご協力で更に強固なものとなるよう、引き続きシリーズを成長させていく所存である。

それでは、AWS Network 本番運用三部作 完結巻の最後まで読了いただき誠にありがとうございました。次の Vol4 / 新軸でまた皆様にお会いできることを楽しみにしている。