AWS Network本番運用Vol2｜TGW×PrivateLink×DX×Peering×VPN

目次

AWS Network本番運用Vol2 マルチアカウント網編｜TGW × PrivateLink × Direct Connect × VPC Peering × Site-to-Site VPN 完全ガイド

マルチアカウント網全体アーキテクチャ｜TGW Hub × PrivateLink × Direct Connect × VPC Peering × Site-to-Site VPN

AWS本番運用 Network本番運用シリーズ Vol2 マルチアカウント網編 — VPC基礎+Hybrid専門編からの拡張
本記事は VPC基礎 (Transit Gateway / VPC Lattice / PrivateLink 統合実装入門) と Hybrid Connectivity 専門編 (Direct Connect × VPN × TGW 運用) を完遂した中堅エンジニア向けの本番マルチアカウント網実装ガイドです。Transit Gateway × PrivateLink × Direct Connect × VPC Peering × Site-to-Site VPN の 5本柱統合で、20-100アカウント規模のマルチアカウント網を本番品質で運用する設計力を確立します。

既存Network記事との住み分け

  • VPC基礎 (Vol1相当 / TGW × VPC Lattice × PrivateLink 統合実装入門): 単体VPC/小規模TGW設計入門
  • Hybrid Connectivity 専門編 (DX × VPN × TGW): オンプレ ↔ AWS 接続専門・ハイブリッド焦点
  • 本Vol2 マルチアカウント網編 = 5本柱統合本番運用: Multi-Account網設計 × 大規模TGW運用 × クロスアカウントPrivateLink × 本番Resilient DX × Peering vs VPN選定

選定基準: 20アカウント以上 / Multi-Region本番網 / オンプレ常時接続必須 / DX物理冗長化必須 → 本Vol2推奨。

1. なぜNetwork本番運用 Vol2 マルチアカウント網編か — VPC基礎+Hybrid編からの架橋 + 5本柱選定の現実解

TODO: 本セクションでは以下を解説する。
– VPC基礎+Hybrid専門編完遂後にチームが直面する5つの壁 (マルチアカウント網設計破綻 / TGW Route Table暴走 / クロスアカウントPrivateLink複雑性 / DX物理冗長化要件 / Peering vs VPN選定の混乱)
– 5本柱選定の現実解 (TGW=ハブ / PrivateLink=サービス公開 / DX=オンプレ高帯域 / Peering=低レイテンシ少数間 / Site-to-Site VPN=DXバックアップ)
– VPC基礎との連続性 (基礎=単体VPC設計入門 / 本Vol2=Multi-Account網統合運用)
– Hybrid専門編との補完性 (Hybrid=DX/VPN詳細運用 / 本Vol2=5本柱選定+本番マルチアカウント網設計)
– 本Vol2で得られる5成果 (TGW Multi-Account網設計 / クロスアカウントPrivateLink / DX Resilient構成 / VPC Peering選定基準 / Site-to-Site VPN BGP本番運用)
– Network本番運用5原則 (Hub-and-Spokeトポロジ標準化 / Route Table分離による blast radius局所化 / クロスアカウント明示的許可 / 物理冗長化必須 / 観測性Network Manager統合)

痛点5選: VPC基礎+Hybrid編完遂者がマルチアカウント網本番運用で直面する地雷

  • 痛点1: TGW Route Table単一化で全アカウント全VPC相互接続→ blast radius全社拡散
  • 痛点2: クロスアカウントPrivateLink Endpoint Service許可リスト管理破綻 (100アカウント手動許可)
  • 痛点3: Direct Connect単一回線 (Resilient未構成) で物理障害時のオンプレ全停止
  • 痛点4: VPC Peering 100ペアでMesh構造化 → Route Table管理不能
  • 痛点5: Site-to-Site VPN Static Route運用で経路変更時に手作業数十件

VPC基礎 — TGW×VPC Lattice×PrivateLink 統合実装入門

2. Transit Gateway本番運用 — Route Table分離 × Attachment × Cross-Region Peering × Network Manager

Transit Gateway マルチアカウント Route Table 分離設計

TODO: 本セクションでは以下を解説する。
– Transit Gateway 4要素 (TGW本体 / Attachment / Route Table / Propagation) の役割
– Route Table分離設計 (Prod/Stg/Dev/Shared/Egress 5パターン分離 / blast radius局所化)
– Attachment種別 (VPC / DX Gateway / VPN / TGW Peering / Connect: SD-WAN) の使い分け
– Cross-Region TGW Peering (Multi-Region Hub-and-Spoke 構築 / 経路広告制御)
– Network Manager 統合監視 (Global Network / Topology可視化 / Event監視)
– RAM (Resource Access Manager) でクロスアカウントTGW共有設計
– 本番Quota管理 (Attachment上限 5,000 / Route上限 10,000 / Hard Limit緩和申請)
– mermaid01: TGW Route Table分離フロー (Prod VPC → Prod RT → Egress VPC のみ許可)

Transit Gateway 本番運用5原則

  • 原則1: Route Tableを最低5本 (Prod/Stg/Dev/Shared/Egress) 分離し blast radiusを局所化
  • 原則2: クロスアカウントTGW共有はRAMで明示的・最小権限設計
  • 原則3: Multi-Region網は TGW Peering + Cross-Region Route 制御 で広告経路を厳格管理
  • 原則4: Network Manager Global Network で TGW + DX + VPN を統合可視化
  • 原則5: Quota (Attachment 5000 / Route 10000) を Hard Limit到達前に緩和申請
TGW Route Table分離パターン

  • Prod RT: Production VPC群のみ相互接続 / Egress VPCへの経路のみ
  • Stg RT: Staging VPC群のみ / Prod RTとは隔離
  • Dev RT: Development VPC群のみ / 自由度高
  • Shared RT: 共通サービス (DNS / ログ集約 / 監査基盤) を全環境から接続
  • Egress RT: NAT/Internet Gateway経由のアウトバウンド集約

3. PrivateLink本番運用 — Interface vs Gateway × Endpoint Service × クロスアカウント × Private DNS

TODO: 本セクションでは以下を解説する。
– VPC Endpoint種別 (Interface Endpoint / Gateway Endpoint / GatewayLoad Balancer Endpoint) の役割
– Interface Endpoint本番運用 (1ENI/AZ あたりコスト / VPC内DNS解決 / SG設計)
– Gateway Endpoint本番運用 (S3/DynamoDB 専用 / Route Table追記方式 / 無料)
– Endpoint Service (PrivateLink Service Provider) でクロスアカウントサービス公開設計
– 許可リスト管理 (Acceptance Required / Allowed Principals / 大規模アカウント運用パターン)
– Private DNS統合 (Endpoint Service Private DNS / Route 53 Resolver連携 / DNS-based Service Discovery)
– AWS Service Endpoint運用 (主要サービスでの設定パターン / S3 Interface vs Gateway選定)
– 本番Quota (Endpoint数 / Interface接続数 / 帯域 10Gbps/AZ)

PrivateLink 本番運用5原則

  • 原則1: S3/DynamoDBはGateway Endpoint (無料) を第一選択 / 他はInterface Endpoint
  • 原則2: Endpoint Service許可リストは Organizations OU単位で管理 (手動許可禁止)
  • 原則3: Private DNS統合で内部DNS解決 (FQDN変更なしでサービス利用)
  • 原則4: クロスリージョンサービス公開は VPC Lattice or DX Gateway 経由で構成
  • 原則5: Interface Endpoint帯域 (10Gbps/AZ) 監視必須・上限到達時はScale Out
アンチパターン: クロスアカウントPrivateLink許可リスト 100アカウント手動管理
TODO: 詳細解説 — Acceptance Required運用で個別アカウント手動許可を続けると、新規アカウント追加毎に手作業発生・許可漏れ事故温床。Organizations OU連携 + Tag-based Access Control (Allowed Principals に OU ARN指定) で自動化が正解。

4. Direct Connect本番運用 — Dedicated vs Hosted × VIF × LAG × DX Gateway × SiteLink × Resilient構成

Direct Connect Resilient構成 + DX Gateway + SiteLink

TODO: 本セクションでは以下を解説する。
– Direct Connect 種別 (Dedicated 1G/10G/100G / Hosted 50M〜10G) の選定マトリクス
– VIF種別 (Private VIF: VPC接続 / Public VIF: AWS Public IP / Transit VIF: TGW接続) の使い分け
– LAG (Link Aggregation Group) で複数回線束ねて冗長化+帯域拡張
– DX Gateway運用 (Multi-Region VPC接続 / Multi-Account共有 / Allowed Prefixes制御)
– SiteLink (DX間トラフィック AWS Backbone転送 / オンプレ拠点間バックホール削減)
– Resilient構成パターン (Single Location 1回線=NG / Single Location 2回線 / Multi-Location 2回線=本番推奨)
– BGP本番運用 (LOCAL_PREF / AS_PATH Prepending / MED / Community Tagging で経路制御)
– 本番障害対応 (CloudWatch BGP Status監視 / VPN自動Failover / SNS通知)

Direct Connect 本番運用5原則

  • 原則1: 本番はMulti-Location 2回線 Resilient構成必須 (Single Location は冗長化不十分)
  • 原則2: DX Gateway経由でMulti-Region/Multi-Account共有 (Allowed Prefixesで経路統制)
  • 原則3: SiteLinkで拠点間バックホール削減 (専用線コスト最適化)
  • 原則4: BGP Community Tagging で本番/開発トラフィック分離
  • 原則5: DX障害時のVPN自動Failoverを必ず設計 (Active-Standby構成)
Resilient構成 選定マトリクス

  • Single Location 1回線: 検証/開発のみ / SLAなし / 本番禁止
  • Single Location 2回線 (Resiliency): ロケーション内冗長 / 99.9% SLA / 小規模本番
  • Multi-Location 2回線 (High Resiliency): 物理ロケーション冗長 / 99.99% SLA / 本番推奨
  • Multi-Location 4回線 (Maximum Resiliency): 完全冗長 / 99.999% SLA / 金融/Mission Critical

5. VPC Peering vs Site-to-Site VPN — Peering特性 × VPN BGP vs Static × Accelerated VPN × 選定基準

VPC Peering vs Site-to-Site VPN 選定フローチャート

TODO: 本セクションでは以下を解説する。
– VPC Peering の本質 (1:1直接接続 / Transitive Routing不可 / 低レイテンシ / 同/Cross-Account/Cross-Region対応)
– Peering制約 (Mesh構造で N(N-1)/2 ペア必要 / Route Table肥大 / SG参照Cross-Region不可)
– Site-to-Site VPN種別 (Customer Gateway / Transit Gateway VPN Attachment / Cloud WAN VPN)
– BGP vs Static Route (BGP=動的経路 / Static=10経路上限 / 障害時自動Failover条件)
– Accelerated Site-to-Site VPN (Global Acceleratorで AWS Backboneに最短入線 / Latency改善)
– VPN Performance最適化 (ECMP / Multi-Tunnel / Active-Active構成)
– Customer Gateway 高可用化 (オンプレ側2台冗長 / 異なるISP回線推奨)
– 本番監視 (CloudWatch VPN Tunnel状態 / IPSec Phase1/2 / BGP Session監視)
– mermaid02: Peering vs VPN vs TGW 選定判断フロー (アカウント数・接続要件で分岐)

VPC Peering vs Site-to-Site VPN 本番運用5原則

  • 原則1: VPC Peeringは「特定2VPC間の低レイテンシ通信」のみ採用 (Mesh構造化禁止)
  • 原則2: 3VPC以上の相互接続はTransit Gateway一択 (Peering Meshはアンチパターン)
  • 原則3: Site-to-Site VPNはBGP動的経路必須 (Static Routeは10経路上限+運用負荷大)
  • 原則4: 重要拠点はAccelerated VPN+Customer Gateway冗長化 (Active-Active)
  • 原則5: VPN Tunnel状態+BGP Session+IPSec Phase状態を統合監視 (PagerDuty連携)
アンチパターン: 10VPC全相互接続を VPC Peeringで Mesh構造化
TODO: 詳細解説 — 10VPC Mesh = 45 Peering Connection が必要。Route Table追加・SG参照管理が爆発的に複雑化。Transit Gateway Hub-and-Spokeで 10 Attachment + 1 Route Table に縮約が正解。VPC数増加に対し O(N) で線形拡張。

6. 詰まりポイント7選 — マルチアカウント網本番運用の地雷とフィックス

TODO: 本セクションでは以下を解説する。

詰まりポイント7選

  1. TGW Route Table単一化で blast radius全社拡散: Prod/Stg/Dev/Shared/Egress 5本分離+Propagation制御で局所化。
  2. クロスアカウントPrivateLink許可リスト破綻: Acceptance Required + Allowed Principals (OU ARN) でOrganizations連携自動化。
  3. DX Single Location冗長化不足で物理障害時オンプレ全停止: Multi-Location 2回線 Resilient構成必須+VPN自動Failover設計。
  4. VPC Peering Mesh構造で Route Table肥大: 3VPC以上はTransit Gateway一択+Route Table分離。
  5. Site-to-Site VPN Static Route 10経路上限到達: BGP動的経路移行 (BGP Community Tagging で本番/開発分離)。
  6. TGW Quota (Attachment 5000) 到達でnew VPC接続不可: 早期 Quota監視+Hard Limit緩和申請ワークフロー設計。
  7. Network Manager未活用でマルチアカウント網可視化困難: Global Network設定 + Event Stream → 統合Topology監視。
頻発トラブル即対応シート

  • TGW Route伝播失敗 → Propagation設定確認 + Static Route追記 → CloudWatch Metric監視
  • PrivateLink許可拒否 → Acceptance Required解除 or Allowed Principals OU追加
  • DX BGP Session Down → CloudWatch Alarm → VPN自動Failover発火 → ISP連絡フロー
  • VPN Tunnel片肺 → IPSec Phase1/2再ネゴ → Customer Gateway切替試験

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

TODO: 本セクションでは以下を解説する。

アンチパターン→正解変換演習5問

  • 演習1: TGW Route Table単一化 (全VPC全相互接続) → 5本分離 (Prod/Stg/Dev/Shared/Egress) + Propagation制御
  • 演習2: VPC Peering Mesh構造 (10VPC=45ペア) → Transit Gateway Hub-and-Spoke (10 Attachment)
  • 演習3: DX Single Location 1回線 → Multi-Location 2回線 Resilient構成+VPN自動Failover
  • 演習4: PrivateLink Acceptance Required手動許可 → Allowed Principals (OU ARN) Organizations自動連携
  • 演習5: Site-to-Site VPN Static Route運用 → BGP動的経路+Community Tagging本番/開発分離

各演習で「現状の問題点」「正解への移行手順 (Terraform例)」「Trade-off」を解説する。

8. まとめ + Network Vol1↔Vol2双方向リンク + 落とし穴10選 + 全クロスリンク

TODO: 本セクションでは以下を解説する。
– Vol2で習得した5本柱統合本番運用パターンの総括 (TGW + PrivateLink + DX + Peering + VPN)
– 落とし穴10選 (VPC基礎+Hybrid編+本番マルチアカウント網横断のチェックリスト)
– Network Vol1↔Vol2 連続性 (Vol1=単体VPC基礎 / 本Vol2=Multi-Account網本番運用)
– Hybrid専門編との補完性 (Hybrid=DX/VPN詳細 / 本Vol2=5本柱選定+本番設計)
– Vol3予告: Service Mesh (VPC Lattice深掘り) / Cloud WAN / Multi-Region Active-Active網
– Network本番運用シリーズ完成度宣言: VPC基礎 + Hybrid専門編 + 本Vol2 で AWS Network運用三本柱を網羅

Vol2完遂で得られる Network本番運用設計力

  • Transit Gateway Route Table分離+Cross-Region Peering+Network Managerでマルチアカウント網を本番設計
  • PrivateLink Interface/Gateway/Endpoint ServiceでクロスアカウントAWS Native接続
  • Direct Connect Multi-Location Resilient+DX Gateway+SiteLinkで物理冗長+コスト最適化
  • VPC Peering vs Site-to-Site VPN 選定基準で接続パターンを的確判断
  • BGP本番運用+Community Tagging+Accelerated VPNで動的経路+性能最適化
AWS本番運用 全シリーズ クロスリンクナビ

VPC基礎 — TGW×VPC Lattice×PrivateLink 統合実装入門

【配置軸の発展】AWS ハイブリッド&エッジ本番運用 Vol1 — Outposts/Local Zones/Wavelength でリージョン外への物理配置拡張を解説します。

AWSの最新記事8件