Zenn
🎉

AWS Cloud Quest Security 学習記録 Day5: VPC Peering Connections

に公開
AWS
Security
VPC
AWS 認定試験
idea

はじめに

AWS Security Specialty取得を目指すAWS Cloud Quest学習の5日目として、複数のVPC間でのセキュアな接続を実現するVPC Peering Connectionsについて学習しました。VPC Peeringは、異なるVPC間でプライベートネットワーク通信を可能にし、マルチVPC環境でのセキュアなアーキテクチャ設計において重要な役割を果たします。

本日学習した内容：

  • VPC Peering Connectionsの概要と基本概念
  • Peering接続の確立プロセス
  • サポートされる構成と制限事項
  • セキュリティ設計における活用方法

VPC Peering Connections 概要

基本概念

VPC Peering Connectionは、2つのVPC間のネットワーク接続であり、以下の特徴を持ちます：

  • プライベートIPv4アドレスまたはプライベートIPv6アドレスを使用してVPC間でトラフィックをルーティング
  • 両方のVPCのインスタンスが同一ネットワーク上にあるかのように相互通信可能
  • 単一のAWSアカウント内および異なるAWSアカウント間での接続をサポート
  • 異なるリージョン間での接続も可能（Inter-Region VPC Peering Connection）

VPC Peeringの主要メリット

1. Simple and Cost-Effective（シンプルで費用対効果が高い）

  • リージョン間やアカウント間でのリソース共有の簡単で費用対効果の高い方法
  • 複雑なネットワーク構成を避けて、直接的な接続を実現
  • 追加のハードウェアやソフトウェアコンポーネントが不要

2. Data Transfer Facilitation（データ転送の促進）

多様なユースケースに対応：

  • データ冗長性のためのレプリケーション：バックアップとディザスタリカバリ
  • 組織内コミュニケーション：部門間でのファイル共有ネットワーク
  • マルチティア アプリケーション：開発・テスト・本番環境間の接続

3. Infrastructure Efficiency（インフラストラクチャの効率性）

  • 既存のVPCインフラストラクチャを活用
  • ゲートウェイやVPN接続ではない
  • 独立した物理ハードウェアに依存しない

4. High Availability and Performance（高可用性とパフォーマンス）

単一障害点とボトルネックの回避：

  • 通信の**単一障害点（Single Point of Failure）**を防止
  • 帯域幅のボトルネックを回避
  • AWS バックボーンの活用による高性能通信

5. Enhanced Security（強化されたセキュリティ）

  • トラフィックは常にグローバルAWSバックボーン上を通行
  • パブリックインターネットを経由しない
  • 一般的なエクスプロイトやDDoS攻撃などの脅威を効果的に軽減

VPC Peering Connection の確立プロセス

ピアリング関係の定義

Requester VPC（リクエスタVPC）

  • Peering接続のリクエストを送信するVPC
  • 接続の開始者として機能

Acceptor VPC（アクセプタVPC）

  • Peering接続のリクエストを受信するVPC
  • 接続の承認者として機能

4ステップの確立プロセス

Step 1: Peering Connection Request（ピアリング接続リクエスト）

リクエスタVPCの所有者がアクセプタVPCの所有者にVPC peering connectionの作成リクエストを送信

重要な制約：
VPC Peeringはすべての構成をサポートしているわけではない

サポートされない構成の例：

  • 重複するCIDRブロック：アクセプタVPCがリクエスタVPCと重複するCIDRブロックを持つ場合
例：サポートされない構成
Requester VPC: 10.0.0.0/16
Acceptor VPC:  10.0.0.0/24  ← 重複するため接続不可

サポートされる構成の例：

例：サポートされる構成
Requester VPC: 10.0.0.0/16
Acceptor VPC:  172.31.0.0/16  ← 重複しないため接続可能

Step 2: Accept Peering Request（ピアリングリクエストの承認）

アクセプタVPCの所有者（自分自身または他のAWSアカウント）がVPC peering connectionリクエストを承認

  • リクエストの承認によりVPC peering connectionがアクティブ化
  • VPCは正式にピアリングされた状態になる

Step 3: Route Table Configuration（ルートテーブル設定）

VPC間のトラフィックフローを有効にするため、ピアリング接続の各VPCの所有者が、希望するVPCルートテーブルに手動でルートを追加

必要なルート設定：

  • 他のピアVPCのIPアドレス範囲を指すルートを追加
  • 双方向の通信を確保するため、両方のVPCでルート設定が必要

ルート設定例：

Requester VPC (10.0.0.0/16) のルートテーブル：

Destination         Target
10.0.0.0/16        local
172.31.0.0/16      pcx-xxxxxxxxx (Peering Connection)

Acceptor VPC (172.31.0.0/16) のルートテーブル：

Destination         Target
172.31.0.0/16      local
10.0.0.0/16        pcx-xxxxxxxxx (Peering Connection)

Step 4: Security Group Rules Update（セキュリティグループルールの更新）

必要に応じて、インスタンスに関連付けられたセキュリティグループルールを更新

目的：

  • ピアVPCとの間のトラフィックが制限されないことを確保
  • 適切なポートとプロトコルでの通信を許可

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

Web Server Security Group (Requester VPC)：

Inbound Rules:
- Type: HTTP
- Protocol: TCP
- Port: 80
- Source: 172.31.0.0/16 (Acceptor VPC CIDR)

Database Security Group (Acceptor VPC)：

Inbound Rules:
- Type: MySQL/Aurora
- Protocol: TCP
- Port: 3306
- Source: 10.0.0.0/16 (Requester VPC CIDR)

VPC Peering の制限事項と考慮事項

1. Transitive Properties Not Supported（推移的特性はサポートされない）

基本的な制限

VPC peering connectionsは推移的特性をサポートしない

推移的特性とは：
VPC A ↔ VPC B、VPC B ↔ VPC Cの接続があっても、VPC A ↔ VPC Cの直接通信はできない

実装時の考慮事項

必要な接続パターン：
すべてのピアVPCは互いに直接ピアリングされる必要がある

例：3つのVPCを完全に接続する場合
VPC A ↔ VPC B  (Peering Connection 1)
VPC B ↔ VPC C  (Peering Connection 2)  
VPC A ↔ VPC C  (Peering Connection 3)  ← この接続も必要

複数VPCピアリングの管理：

  • VPCの数が増加すると、必要なピアリング接続数は指数的に増加
  • n個のVPCを完全に接続するには n(n-1)/2 個のピアリング接続が必要

2. Edge-to-Edge Routing Not Supported（エッジ間ルーティングはサポートされない）

制限内容

VPC peering connectionsは、直接アクセスできないリソースにアクセスするためのエッジ間ルーティングを使用できない

アクセスできないリソースの例：

  • Amazon S3バケット（VPCエンドポイント経由でのアクセス）
  • インターネットゲートウェイ
  • VPN接続
  • AWS Direct Connect

実装上の注意点

S3アクセスの例：

VPC A → VPC B → S3 (VPC Endpoint)
↑ この経路でのS3アクセスは不可能

正しいアプローチ：

VPC A → S3 (VPC A専用のVPC Endpoint)
VPC B → S3 (VPC B専用のVPC Endpoint)

3. CIDR Block Overlap Restrictions（CIDRブロック重複制限）

基本ルール

ピアリング接続を確立する2つのVPCのCIDRブロックは重複してはならない

サポートされない構成例：

VPC A: 10.0.0.0/16
VPC B: 10.0.10.0/24  ← VPC Aと重複

サポートされる構成例：

VPC A: 10.0.0.0/16
VPC B: 172.16.0.0/16  ← 重複なし
VPC C: 192.168.0.0/16  ← 重複なし

CIDR設計の重要性

  • 事前のCIDR計画が重要
  • 将来のピアリング要件を考慮した設計
  • RFC 1918プライベートアドレス空間の効率的な分割

セキュリティ設計における VPC Peering の活用

1. セキュリティアーキテクチャパターン

Hub-and-Spoke モデル

中央集権的なセキュリティ管理

        Security VPC (Hub)
              ↕
    ┌─────────┼─────────┐
    ↕         ↕         ↕
 Dev VPC   Test VPC   Prod VPC
(Spoke)   (Spoke)    (Spoke)

利点：

  • 集中的なセキュリティ管理
  • 共有セキュリティサービス（監視、ログ、セキュリティツール）
  • 一貫したセキュリティポリシーの適用

Multi-Tier Isolation（多層分離）

機能別VPC分離

DMZ VPC ↔ Application VPC ↔ Database VPC

利点：

  • 機能層ごとの分離
  • セキュリティ境界の明確化
  • 侵害時の影響範囲限定

2. Cross-Account セキュリティ

Account Separation Strategy

アカウント別VPC管理

Security Account  ↔  Production Account
     ↕                    ↕
Monitoring VPC       Production VPC
     ↕                    ↕
Logging VPC         Application VPC

セキュリティ利点：

  • 権限の分離：アカウント間での役割分担
  • コンプライアンス：規制要件への対応
  • 監査証跡：クロスアカウントアクセスの記録

3. ネットワークセキュリティ強化

Traffic Flow Control

VPC Peering + Security Groupsの組み合わせ

Web VPC (10.0.0.0/16)
    ↓ Port 443 only
App VPC (172.16.0.0/16)  
    ↓ Port 3306 only
DB VPC (192.168.0.0/16)

実装例：

Web VPC Security Group：

Outbound Rules:
- Type: HTTPS
- Protocol: TCP
- Port: 443
- Destination: 172.16.0.0/16

App VPC Security Group：

Inbound Rules:
- Type: HTTPS
- Protocol: TCP
- Port: 443
- Source: 10.0.0.0/16

Outbound Rules:
- Type: MySQL/Aurora
- Protocol: TCP
- Port: 3306
- Destination: 192.168.0.0/16

Data Classification Based Access

データ分類に基づくアクセス制御

Public Data VPC    ↔    Shared Services VPC
Internal Data VPC  ↔    Shared Services VPC
Confidential Data VPC (Isolated)

Inter-Region VPC Peeringのセクションを続けて完成させます：

Inter-Region VPC Peering

概要と利点

Global Architecture Support

リージョン間でのセキュアな接続

US East (N. Virginia)  ↔  EU West (Ireland)
Production VPC            DR/Backup VPC

ユースケース：

  • 災害復旧（DR）：地理的に分離されたバックアップ
  • データレプリケーション：コンプライアンスやパフォーマンス向上のための地域分散
  • グローバルアプリケーション：世界規模での統合されたサービス展開
  • レイテンシー最適化：ユーザーに近いリージョンでのサービス提供

技術的特徴

AWSバックボーンの活用：

  • 専用のAWSネットワークインフラストラクチャを使用
  • パブリックインターネットを経由しないセキュアな通信
  • 高帯域幅・低レイテンシーの実現

暗号化とセキュリティ：

  • すべてのリージョン間トラフィックが自動暗号化
  • AWS管理のセキュリティインフラストラクチャ
  • DDoS攻撃や一般的なエクスプロイトからの保護

Inter-Region Peering の制限事項

同一リージョン内Peeringとの違い

共通の制限：

  • 推移的特性のサポートなし
  • エッジ間ルーティングのサポートなし
  • CIDRブロックの重複禁止

Inter-Region固有の考慮事項：

  • レイテンシーの影響：地理的距離によるネットワーク遅延
  • データ転送コスト：リージョン間のデータ転送料金
  • 法的・コンプライアンス要件：データの地理的配置に関する規制

VPC Peering の運用ベストプラクティス

1. CIDR設計戦略

事前計画の重要性

将来の拡張を考慮したCIDR設計：

Production Account:
├── US-East-1: 10.0.0.0/8
│   ├── Prod VPC: 10.0.0.0/16
│   ├── Test VPC: 10.1.0.0/16  
│   └── Dev VPC: 10.2.0.0/16
│
└── EU-West-1: 10.100.0.0/8
    ├── Prod VPC: 10.100.0.0/16
    ├── Test VPC: 10.101.0.0/16
    └── Dev VPC: 10.102.0.0/16

CIDR管理のガイドライン：

  • RFC 1918準拠：10.0.0.0/8、172.16.0.0/12、192.168.0.0/16の使用
  • 階層的なアドレス体系：リージョン・環境・用途別の体系的な割り当て
  • 将来の拡張余地：十分なアドレス空間の確保

2. セキュリティグループ管理

Cross-VPC セキュリティグループルール

CIDR参照による制御：

Web Tier Security Group (VPC A):
Inbound Rules:
- Type: HTTPS
- Port: 443  
- Source: 172.16.0.0/16 (VPC B CIDR)

セキュリティグループ参照：
リージョン内のピアリングでは、セキュリティグループIDを直接参照可能：

Database Security Group:
Inbound Rules:
- Type: MySQL/Aurora
- Port: 3306
- Source: sg-xxxxxxxxx (App Tier SG)

最小権限の原則

  • 必要最小限のポート・プロトコルのみ許可
  • 送信元の厳格な制限
  • 定期的なルールの監査

3. 監視とログ記録

VPC Flow Logs

クロスVPCトラフィックの監視：

VPC Flow Logs 設定:
├── Requester VPC Flow Logs
├── Acceptor VPC Flow Logs  
└── Peering Connection Flow Logs

監視対象メトリクス：

  • トラフィック量：送受信データ量の監視
  • 接続頻度：VPC間の通信パターン分析
  • 異常なトラフィック：セキュリティインシデントの検出

CloudTrail 統合

VPC Peering操作の監査：

  • Peering接続の作成・削除
  • ルートテーブルの変更
  • セキュリティグループの更新

4. コスト最適化

データ転送コストの管理

同一リージョン内：

  • VPC Peering接続でのデータ転送は無料
  • Availability Zone間のデータ転送のみ課金

リージョン間：

  • リージョン間データ転送料金が適用
  • 送信リージョンでの課金（受信は無料）

コスト最適化戦略：

  • 必要なデータ転送のみ実行
  • データ圧縮の活用
  • 定期的なトラフィック分析

トラブルシューティング

1. 接続確立時の問題

よくある問題と解決方法

Peering接続が確立できない：

原因: CIDRブロックの重複
解決策: 
1. 両VPCのCIDRブロックを確認
2. 重複がある場合は、新しいVPCを別のCIDRで作成
3. 必要に応じてワークロードを移行

ルート設定の問題：

症状: Peering接続は成功したが通信できない
確認事項:
1. 両VPCのルートテーブルにピア向けルートが存在するか
2. ルートのDestinationが正しいCIDRブロックを指しているか  
3. Targetが正しいPeering Connection IDを指しているか

2. セキュリティグループの問題

通信許可の確認手順

段階的なトラブルシューティング：

1. Network ACLsの確認
   - インバウンド・アウトバウンド両方向の許可

2. セキュリティグループの確認  
   - 送信元セキュリティグループのアウトバウンドルール
   - 宛先セキュリティグループのインバウンドルール

3. ルートテーブルの再確認
   - 適切なルートが設定されているか

4. VPC Flow Logsの分析
   - ACCEPT/REJECT の状況確認

3. パフォーマンスの問題

ネットワークパフォーマンス最適化

レイテンシーの最小化：

  • 同一リージョン内でのピアリングを優先
  • Enhanced Networkingの有効化
  • 適切なインスタンスタイプの選択

帯域幅の最適化：

  • 複数の接続による負荷分散
  • データ転送の最適化
  • ネットワーク集約的ワークロードの配置検討

まとめ

学習した主要ポイント

  1. VPC Peering Connectionsは、2つのVPC間でプライベートな通信を実現する重要な機能
  2. 4ステップの確立プロセスにより、セキュアで制御されたVPC間接続を構築
  3. 推移的特性とエッジ間ルーティングの制限により、設計時の慎重な検討が必要
  4. Inter-Region Peeringにより、グローバルなアーキテクチャとDR戦略を実現
  5. 適切なCIDR設計とセキュリティ設定により、セキュアなマルチVPC環境を構築

AWS Security Specialty取得に向けて

VPC Peeringは、AWS Security Specialtyにおいて以下の観点から重要です：

  • ネットワーク分離とセグメンテーション：セキュリティ境界の適切な設計
  • クロスアカウント・クロスリージョン通信：エンタープライズ環境でのセキュアな接続
  • 最小権限アクセス：ネットワークレベルでの細かいアクセス制御
  • 監視と監査：ネットワークトラフィックの可視化と追跡

Discussion