ネットワーク要件から接続アーキテクチャを選択する

1. アーキテクチャ選択の進め方

SAP-C02で重要なのは、個別サービス名を先に決めるのではなく、問題文に出てくる要件を分解し、候補を比較してアーキテクチャを選ぶことです。

要件
↓
制約
↓
決定要因
↓
候補比較
↓
アーキテクチャ
↓
理由

この流れで、技術的に可能な構成の中から要件を満たし、過剰設計にならない構成を選びます。

2. サービス名より先に要件を読む

最初から「VPCが多いからTGW」「プライベートだからPrivateLink」と決めません。次の順に要件を読みます。

誰と誰が通信？
↓
ネットワーク全体 / サービス単位？
↓
マルチVPC？
↓
マルチリージョン？
↓
ハイブリッド？
↓
レイテンシー / ジッター？
↓
帯域幅？
↓
冗長性？
↓
コスト / 運用負荷？
↓
既存構成を再利用できる？

3. 最初の決定打は通信範囲

ネットワーク全体を接続するのか、特定サービスだけを公開するのかは、候補を大きく絞る決定打です。

4. マルチVPC：VPC数だけで判断しない

少数VPCで、CIDR非重複、推移的ルーティング不要、中央管理不要ならVPC ピアリングが単純です。一方、VPC数が少なくても、共有サービス、ハイブリッド接続、集中ルーティング、環境分離などが必要ならTransit Gatewayが適する場合があります。

判断軸
= VPC数
+ 通信パターン
+ 推移性
+ 集中管理
+ 将来スケール

5. サービス単位ならPrivateLink

別アカウントの内部APIだけをプライベート公開し、提供側 VPC全体へのルーティングは許可したくない場合はAWS PrivateLinkが有力です。CIDRが重複していてもサービス単位の接続として設計できます。

ネットワーク間
→ ピアリング / TGW

利用側からサービス
→ PrivateLink

6. マルチリージョン：直接接続かリージョンハブか

少数VPCだけをリージョン間で直接接続するならリージョン間 VPC ピアリングを評価します。各リージョンですでに多数VPCをTransit Gatewayへ集約しているなら、リージョンハブ同士をTransit Gateway ピアリングで接続する方が自然です。

Transit Gateway ピアリングアタッチメント向けのルートは静的に設定します。

7. ハイブリッド：導入速度とネットワークパフォーマンスを分ける

「VPNは遅い」「DXは速い」という単純化ではなく、導入時間・帯域幅・性能の一貫性・コストを合わせて判断します。

8. レイテンシー要件：回線より先に距離を見る

ユーザーから遠いリージョンに対話型アプリケーションを置いている場合、接続方式を変える前にワークロードをユーザーへ近いリージョンへ配置できないかを評価します。

高レイテンシー
↓
まず物理距離 / リージョン配置を確認
↓
その上でネットワーク経路を最適化

9. 帯域幅要件：平均値だけで設計しない

平均300 Mbpsでもピークが4 Gbpsなら、接続方式・回線数・キャパシティはピークを無視できません。データ転送量、継続時間、バースト特性も合わせて判断します。

平均
だけでは不足

ピーク + 継続時間 + 成長
まで確認

10. 冗長性要件：本数ではなく障害ドメイン

接続が2本あっても、同じ機器・通信事業者・場所へ依存していれば共通障害が残ります。

接続数
↓
機器分離？
↓
通信事業者分離？
↓
ロケーション分離？
↓
バックアップ経路はプライマリと独立？

Direct Connect回線そのものの障害にも耐える必要があるなら、独立したインターネット経路のSite-to-Site VPNなど、異なる障害ドメインを持つバックアップを評価します。

11. コストと運用負荷もアーキテクチャ要件

技術的に実現可能でも、VPC数が少ないのに大規模なハブを導入したり、すべてのVPCへ同じエンドポイントを重複配置したりすると、必要以上にコストと運用対象が増えることがあります。

逆にコストだけを理由に中央集約すると、障害影響範囲やポリシー共有が大きくなる場合があります。

技術的実現性
+
コスト
+
運用負荷
+
影響範囲
↓
アーキテクチャを決定

12. 最小限変更：既存構成を使えるか

SAP-C02では、要件を満たすために既存アーキテクチャを全面置換する必要がない場合があります。

既存
オンプレミス
↓
Direct Connect
↓
Transit Gateway
↓
40 VPC

追加要件
DX障害時のバックアップ
↓
既存TGWへVPNを追加

「最も少ない運用負荷」「最小の変更」が問われる場合は、既存構成を再利用できるかを確認します。

13. 接続方式以外の要件も最後に確認する

ネットワーク接続性を決めただけではアーキテクチャは完成しません。必要に応じてDNS、サービスへのプライベートアクセス、可視化・トラブルシューティングも追加します。

ネットワーク接続を決定
↓
DNS
プライベートサービスアクセス
可視性 / トラブルシューティング
↓
必要な補助設計を追加

14. アーキテクチャ選択マトリクス

15. SAP-C02判断フロー

要件
  │
  ▼
誰と誰を接続？
  │
  ▼
ネットワーク全体 / サービス単位？
  │
  ├─ 少数VPC直接
  │    → VPC ピアリング
  │
  ├─ 多数VPC / 中央化
  │    → Transit Gateway
  │
  ├─ サービス単位
  │    → AWS PrivateLink
  │
  └─ ハイブリッド
       → VPN / Direct Connect

マルチリージョン？
→ ピアリング / TGW ピアリング

レイテンシー？
→ リージョン配置から確認

帯域幅？
→ ピーク / 成長を確認

冗長性？
→ 障害ドメインを分離

コスト / 運用負荷？
→ 過剰設計を避ける

既存構成を再利用？
→ 最小限の変更

最後に
→ 要件をすべて満たすアーキテクチャを選択

16. 代表シナリオ

17. 混同ポイント

• VPCが複数 = 必ずTGW：少数・単純ならピアリングが有力です。
• VPCが2つ = 必ずピアリング：集中管理やハイブリッド接続が決定打ならTGWも候補です。
• プライベート接続 = PrivateLink：ネットワーク全体かサービス単位かを確認します。
• 1 Gbps超 = 必ずDX：帯域幅だけでなく接続先や要件を確認します。
• DXが2本 = 完全冗長：場所などの障害ドメインを確認します。
• マルチAZ = リージョン障害対策：リージョン障害への耐性はマルチリージョン設計です。
• TGW ピアリング = ルート自動伝達：ピアリングアタッチメント向けルートは固定です。
• 技術的に可能 = 最適：コスト、運用負荷、変更量まで比較します。

18. まとめ

要件
↓
通信範囲
↓
マルチVPC / マルチリージョン / ハイブリッド
↓
レイテンシー / 帯域幅
↓
冗長性 / 障害ドメイン
↓
コスト / 運用負荷
↓
最小限の変更
↓
アーキテクチャ選択

最重要ポイント：サービス名から逆算せず、要件を分解して決定打を見つけ、必要なAWSネットワークサービスだけを組み合わせます。

19. 主要AWS公式資料

• SAP-C02 ドメイン 1 タスク1.1
• VPC ピアリング
• AWS Transit Gateway
• Transit Gateway ピアリング
• AWS Site-to-Site VPN
• AWS Direct Connect
• AWS PrivateLink