architecting-networks

ネットワークアーキテクチャ

AWS、GCP、Azure における実績あるパターンを活用して、安全でスケーラブルなクラウドネットワークアーキテクチャを設計します。このスキルでは、VPC 設計、サブネット戦略、ゼロトラストの実装、ハイブリッド接続に関する意思決定の枠組みを提供します。

このスキルを使用する場面

次のような場合にこのスキルを呼び出します。

• 新しいクラウド環境の VPC/VNet トポロジーを設計する
• ネットワークのセグメンテーションとセキュリティ制御を実装する
• 複数の VPC 間、またはマルチクラウドの接続を計画する
• ハイブリッドクラウド接続（オンプレミスからクラウド）を確立する
• フラットなネットワークから高度なアーキテクチャへ移行する
• ゼロトラストのネットワーク原則を実装する
• ネットワークのコストとパフォーマンスを最適化する

主なネットワークアーキテクチャパターン

パターン 1：フラット（単一 VPC）アーキテクチャ

使用する場面： 小規模なアプリケーション、単一環境、シンプルなセキュリティ要件、エンジニアが 10 人未満

特徴：

• すべてのリソースを 1 つの VPC に配置し、サブネットレベルでセグメント化する
• パブリック、プライベート、データベースの各サブネット階層
• 最も理解しやすく、管理しやすい
• VPC 間のルーティングが複雑にならない

トレードオフ：

• ✓ コストが最も低く、最も迅速にセットアップできる
• ✗ 分離が不十分で、スケーリングが難しく、VPC 全体が影響範囲になる

パターン 2：マルチ VPC（分離型）アーキテクチャ

使用する場面： 複数の環境（dev/staging/prod）、強い分離要件、コンプライアンス上の分離義務がある場合

特徴：

• 環境またはワークロードごとに VPC を分離する
• 明示的な設定なしでは直接接続されない
• 個別の CIDR 範囲を使用する

トレードオフ：

• ✓ 影響範囲を強く制限でき、セキュリティ境界が明確
• ✗ 管理負荷が増え、インフラストラクチャが重複し、コストが高くなる

パターン 3：ハブアンドスポーク（Transit Gateway）アーキテクチャ

使用する場面： 5 つ以上の VPC 間で通信が必要、セキュリティ検査の一元化が必要、ハイブリッド接続、マルチアカウント構成

特徴：

• 中央のハブ VPC/Transit Gateway
• スポーク VPC をハブに接続する
• すべての VPC 間トラフィックをハブ経由でルーティングする

トレードオフ：

• ✓ ルーティングを簡素化でき、セキュリティを一元化でき、容易にスケールできる（100 以上の VPC）
• ✗ Transit Gateway のコスト（約 $0.05/時間 + $0.02/GB）がかかり、遅延が増加する（ハブを経由）

パターン 4：フルメッシュ（VPC ピアリング）アーキテクチャ

使用する場面： VPC の数が少ない（5 未満）、低遅延が重要、一元的な検査が不要

特徴：

• すべての VPC をピアリングで直接接続する
• VPC 間で直接通信する

トレードオフ：

• ✓ 遅延が最も低く、Transit Gateway のコストがかからない
• ✗ 管理の複雑さが O(n²) で増加し、VPC が約 10 個を超えるとスケールしない

パターン 5：ハイブリッド（複数パターン）アーキテクチャ

使用する場面： 要件が多様な大規模企業、コスト／パフォーマンス／セキュリティのバランスを取る場合

特徴：

• ほとんどの VPC にはハブアンドスポークを使用し、遅延に敏感な VPC の組み合わせは直接ピアリングする
• ワークロード要件に応じて組み合わせる

トレードオフ：

• ✓ 特定のニーズに合わせて最適化できる
• ✗ 設計と管理がより複雑になる

パターン選択の枠組み

Number of VPCs?
│
├─► 1 VPC → Flat (Single VPC)
├─► 2-4 VPCs + No inter-VPC communication → Multi-VPC (Isolated)
├─► 2-5 VPCs + Low latency critical → Full Mesh (VPC Peering)
├─► 5+ VPCs + Centralized inspection → Hub-and-Spoke (Transit Gateway)
└─► 10+ VPCs + Mixed requirements → Hybrid (Multi-Pattern)

Additional Considerations:
├─► Hybrid connectivity required? → Hub-and-Spoke preferred
├─► Centralized egress/inspection? → Hub-and-Spoke with Inspection VPC
├─► Multi-account environment? → Hub-and-Spoke with AWS RAM sharing
└─► Cost optimization priority? → Flat or Multi-VPC (avoid TGW fees)

サブネット戦略

標準的な 3 層設計

パブリックサブネット：

• Internet Gateway へのルートを設定する
• ロードバランサー、踏み台ホスト、NAT Gateway に使用する
• CIDR：/24～/27（256～32 IP）

プライベートサブネット：

• アウトバウンド通信用に NAT Gateway へのルートを設定する
• アプリケーションサーバー、コンテナ、コンピューティングワークロードに使用する
• CIDR：/20～/22（4,096～1,024 IP）

データベースサブネット：

• インターネットへの直接ルートを設定しない
• RDS、ElastiCache、マネージドデータベースに使用する
• CIDR：/24～/26（256～64 IP）

マルチ AZ への分散

本番環境： 各階層を最低 3 つの Availability Zone に分散します
開発／テスト環境： コスト削減のため、1～2 AZ でも問題ありません

CIDR ブロックの計画

VPC のサイズ：

• /16（65,536 IP）- 大規模な本番環境
• /20（4,096 IP）- 中規模環境
• /24（256 IP）- 小規模／開発環境

重要なルール：

• VPC 間で CIDR 範囲が重複しないようにする
• ハイブリッド接続に向けてオンプレミスネットワークチームと調整する
• 将来の拡張用にアドレス空間を確保する

サブネット計画の詳細については、references/subnet-strategy.md を参照してください。

NAT Gateway 戦略

判断フレームワーク

Cost vs Resilience?
│
├─► Cost Priority (Dev/Test)
│   └─► Single NAT Gateway (~$32/month)
│       └─► Risk: Single point of failure
│
├─► Balanced (Most Production)
│   └─► One NAT Gateway per AZ (~$96/month for 3 AZs)
│       └─► Resilience: AZ failure doesn't break connectivity
│
└─► Maximum Resilience
    └─► Multiple NAT Gateways per AZ + monitoring
        └─► Critical workloads, SLA-dependent

Alternative: Centralized Egress Pattern
└─► Hub-and-Spoke: Single egress VPC with NAT
    └─► Reduces NAT Gateway count, centralized logging

外部インターネットへの接続が不要な場合

• NAT Gateway を完全に省略します（コスト削減）
• AWS サービスへのアクセスには VPC Endpoints を使用します

セキュリティ制御

セキュリティグループ（推奨）

特徴：

• ステートフル（戻りの通信は自動的に許可されます）
• インスタンスレベルの制御
• 許可ルールのみ（暗黙的に拒否されます）
• 他のセキュリティグループを参照できます

用途：

• サービス間通信
• インスタンスレベルのセキュリティ
• 最も一般的なユースケース

ベストプラクティス：

• 内容が分かる名前を使用します（app-alb-sg、app-backend-sg）
• CIDR ブロックではなく、他のセキュリティグループを参照します
• ルールは最小限かつ具体的にします

ネットワーク ACL（任意）

特徴：

• ステートレス（リクエストとレスポンスの両方を許可する必要があります）
• サブネットレベルの制御
• 許可ルールと拒否ルール
• ルールを順番に処理します（最小の番号から）

用途：

• 明示的な拒否ルール（特定の IP をブロック）
• コンプライアンス要件（多層防御）
• セキュリティグループに加える追加のレイヤー

ベストプラクティス：

• 使用は必要最小限にします（管理が複雑なため）
• エフェメラルポート（1024-65535）を許可することを忘れないでください
• 十分にテストします（ステートレスな性質により問題が発生するため）

セキュリティグループのアーキテクチャパターンについては、references/security-controls.md を参照してください

ゼロトラストの原則

基本原則

1. 決して信頼せず、常に検証する

   • 送信元にかかわらず、すべてのリクエストを認証します
   • ネットワーク上の場所に基づく暗黙の信頼を排除します

2. 最小権限アクセス

   • 必要最小限の権限を付与します
   • 期限付きアクセス（ジャストインタイム）

3. 侵害を前提とする

   • ネットワークを積極的にセグメント化します
   • すべてのトラフィックを監視します
   • 迅速に検知し、対応します

実装パターン

マイクロセグメンテーション：

• きめ細かなセキュリティグループルールで、すべてのワークロードを分離します
• サービス間通信は、特定のサービス間のみに限定します
• 影響範囲を縮小します

アイデンティティベースのアクセス：

• 認可には IP アドレスではなく IAM ロールを使用します
• IAM ポリシーを適用した VPC Endpoints
• サービス間のアイデンティティ検証

継続的な検証：

• トラフィック分析には VPC Flow Logs を使用します
• 拒否された接続を監視します
• 異常を検知したらアラートを送信します

ゼロトラストアーキテクチャのパターンについては、references/zero-trust-networking.md を参照してください

ハイブリッド接続

VPN（仮想プライベートネットワーク）

使用する場面： 開発／テスト環境、バックアップ接続、一時的な接続

特徴：

• 公共インターネットを経由する暗号化トンネル
• スループット：約1.25 Gbps／トンネル
• レイテンシ：変動あり（インターネット環境に依存）
• コスト：低（約$0.05／時間＋データ転送）
• 設定：迅速（契約不要）

Direct Connect／ExpressRoute／Cloud Interconnect

使用する場面： 本番ワークロード、大容量データ転送、リアルタイムアプリケーション

特徴：

• 専用ネットワーク接続（公共インターネットを経由しません）
• スループット：最大100 Gbps
• レイテンシ：低く安定
• コスト：高め（ポート料金＋データ転送）
• 設定：時間がかかる（契約、調整が必要）

Transit Gateway ＋ Direct Connect

使用する場面： 複数の VPC からオンプレミスへの接続が必要な場合

メリット：

• 1つの Direct Connect 接続 → Transit Gateway → 複数の VPC
• コスト効率が高く、拡張性に優れています
• ハイブリッド接続を一元管理できます

ハイブリッド接続のパターンと例については、references/hybrid-connectivity.md を参照してください

マルチクラウドネットワーキング

プロバイダー間で共通する概念

概念	AWS	GCP	Azure
仮想ネットワーク	VPC	VPC	Virtual Network (VNet)
サブネット	Subnets (AZ-scoped)	Subnets (Regional)	Subnets
NAT	NAT Gateway	Cloud NAT	NAT Gateway
ピアリング	VPC Peering	VPC Peering	VNet Peering
ハブアンドスポーク	Transit Gateway	Cloud Router	Virtual WAN
プライベートエンドポイント	PrivateLink	Private Service Connect	Private Link
ハイブリッド VPN	VPN	Cloud VPN	VPN Gateway
ハイブリッド専用接続	Direct Connect	Cloud Interconnect	ExpressRoute

プロバイダー固有のベストプラクティス

AWS：

• 本番環境ではマルチ AZ を基本とします
• VPC が 5 つ以上の場合は、Transit Gateway を優先します
• NAT の料金を避けるため、VPC エンドポイントを使用します

GCP：

• カスタムモードの VPC を使用します（自動モードではありません）
• 単一の VPC から始め、複数プロジェクトでは Shared VPC を使用します
• サブネットレベルでネットワークユーザーロールを付与します

Azure：

• ハブアンドスポーク型のネットワークトポロジーを標準とします
• 小規模な VNet を多数作るより、大規模な VNet を少数作成します
• Azure サービスにはプライベートエンドポイントを使用します

マルチクラウドの実装については、references/multi-cloud-networking.md を参照してください

ネットワークの可観測性

VPC フローログ

以下の場合にフローログを有効にします：

• トラフィック分析とトラブルシューティング
• セキュリティ監視（不正アクセスの検出）
• ネットワーク経路別のコスト配賦
• コンプライアンス要件への対応

設定：

• トラフィックタイプ：ALL（許可されたトラフィックと拒否されたトラフィックを記録）
• 集約間隔：1～10 分
• 保存先：CloudWatch Logs または S3

監視パターン

監視対象：

• 拒否された接続（セキュリティ上の異常）
• トラフィック量の急増
• VPC 間の通信パターン
• NAT Gateway の使用率

以下の場合にアラートを設定します：

• 拒否された接続の急増
• 通常とは異なるトラフィックパターン
• 高額なデータ転送料金
• ネットワークエラー

可観測性パターンとフローログ分析については、references/network-observability.md を参照してください

コスト最適化

一般的なコスト要因

1. NAT Gateway： $0.045/時間 + 処理データ 1 GB あたり $0.045
2. Transit Gateway： $0.05/時間/アタッチメント + $0.02/GB
3. データ転送： 送信先によって料金が異なります
4. VPN/Direct Connect： ポート料金 + データ転送料金

最適化戦略

NAT Gateway のコストを削減する：

• AWS サービス（S3、DynamoDB）には VPC エンドポイントを使用します
• 集中型の送信 VPC パターンを採用します
• 開発／テスト環境では NAT Gateway を 1 つにします（可用性リスクを許容）

データ転送コストを削減する：

• トラフィックを同一リージョン内にとどめます
• パブリックインターネットの代わりに VPC エンドポイントを使用します
• 大容量転送にはプライベート接続を使用します

Transit Gateway のコストを回避する：

• VPC が少数（5 未満）の場合は、VPC ピアリングを使用します
• 低レイテンシーが求められるペアには、直接ピアリングを使用します

詳細なコスト最適化戦略については、references/cost-optimization.md を参照してください

実装ワークフロー

ステップ 1：要件を分析する

• 必要な VPC／環境の数は？
• ハイブリッド接続が必要か？
• レイテンシーの要件は？
• セキュリティ／コンプライアンス要件は？
• 予算の制約は？

ステップ 2：パターンを選択する

上記のパターン選択フレームワークを使用して、以下から選択します：

• フラット、マルチ VPC、ハブアンドスポーク、メッシュ、またはハイブリッド

ステップ 3：サブネットを設計する

• CIDR ブロックを計算します（重複しないようにします）
• マルチ AZ の分散を計画します
• パブリック／プライベート／データベースの各ティアを決定します

ステップ 4：セキュリティを設定する

• セキュリティグループのアーキテクチャを設計します
• マイクロセグメンテーションを計画します
• 必要に応じて Network ACL を設定します

ステップ 5：IaC で実装する

infrastructure-as-code スキルを使用して、Terraform/Pulumi で実装します

ステップ 6：可観測性を有効にする

• VPC フローログを設定します
• 監視とアラートを設定します
• コストを追跡します

クイックリファレンス

VPC パターンの選択

要件	推奨パターン
単一環境	フラット（単一 VPC）
複数の分離された環境	マルチ VPC（分離型）
VPC が 2～5 個、低レイテンシー	フルメッシュ（ピアリング）
VPC が 5 個以上、集中型セキュリティ	ハブアンドスポーク（TGW）
ハイブリッド接続	ハブアンドスポーク（TGW）
コスト最適化	フラットまたはマルチ VPC

NAT Gateway の設定

シナリオ	設定	月額料金（3 AZ）
開発／テスト	NAT 1 つ	~$32
本番環境	AZ ごとに NAT	~$96
集中型の送信	ハブ VPC の NAT	~$32-96

ハイブリッド接続

要件	ソリューション	スループット	レイテンシー
開発／テスト	VPN	~1.25 Gbps	変動
本番環境	Direct Connect	最大 100 Gbps	低く安定
バックアップ	VPN（DX のバックアップ）	~1.25 Gbps	変動

リファレンスドキュメント

詳細ガイド：

• references/vpc-design-patterns.md - 図を含む包括的なパターンの説明
• references/subnet-strategy.md - CIDR 計画、IPAM、複数 AZ のベストプラクティス
• references/zero-trust-networking.md - マイクロセグメンテーション、IAM 統合、継続的な検証
• references/hybrid-connectivity.md - VPN、Direct Connect、Transit Gateway のパターン
• references/multi-cloud-networking.md - AWS、GCP、Azure の実装
• references/security-controls.md - セキュリティグループ、NACL、ファイアウォールのパターン
• references/private-networking.md - VPC Endpoints、PrivateLink、Private Service Connect
• references/multi-region-networking.md - リージョン間ピアリング、グローバル負荷分散
• references/network-observability.md - フローログ、モニタリング、トラブルシューティング
• references/cost-optimization.md - エグレスの削減、NAT 戦略

コード例：

• examples/aws/ - AWS VPC のパターン（フラット、ハブアンドスポーク、ピアリング、VPN、Direct Connect）
• examples/gcp/ - GCP VPC のパターン（カスタム VPC、共有 VPC、Cloud Interconnect）
• examples/azure/ - Azure VNet のパターン（ハブアンドスポーク、ピアリング、ExpressRoute）
• examples/multi-cloud/ - クラウド間接続の例

ユーティリティスクリプト：

• scripts/cidr-calculator.py - CIDR ブロックを計算し、IP アドレス指定を計画します
• scripts/cost-estimator.sh - ネットワークインフラストラクチャのコストを見積もります
• scripts/validate-sg-rules.py - セキュリティグループのルール設定を検証します
• scripts/flow-log-analyzer.py - セキュリティとコストの観点から VPC フローログを分析します

他のスキルとの連携

infrastructure-as-code スキルを使用して、以下を行います：

• Terraform/Pulumi でネットワークアーキテクチャを実装します
• ネットワーク設定をバージョン管理します
• ネットワークのプロビジョニングを自動化します

kubernetes-operations スキルを使用して、以下を行います：

• VPC 設計の上に Kubernetes ネットワーキング（CNI）を設定します
• Pod ネットワーキングとサービスメッシュを実装します

security-hardening スキルを使用して、以下を行います：

• ファイアウォールルールと WAF 設定を実装します
• ネットワークレベルの DDoS 保護を設定します
• 侵入検知システムをセットアップします

observability スキルを使用して、以下を行います：

• 包括的なネットワークモニタリングを実装します
• ネットワーク境界を越えた分散トレーシングを設定します
• パフォーマンスダッシュボードを設定します

disaster-recovery スキルを使用して、以下を行います：

• マルチリージョンのフェイルオーバーネットワーキングを設計します
• リージョン間のバックアップ接続を実装します
• ネットワーク復旧手順を計画します