ストーリー

VPC ピアリング

概要

VPC ピアリングは、2つの VPC 間をプライベートネットワークで接続する機能です。インターネットを経由せず、AWS のバックボーンネットワークを通じて安全に通信します。

VPC ピアリング接続

┌──── VPC-A (本番) ────┐     ┌──── VPC-B (開発) ────┐
│  10.0.0.0/16          │     │  10.1.0.0/16          │
│                        │     │                        │
│  ┌──────────┐         │     │         ┌──────────┐  │
│  │  EC2-A    │─────────│─────│─────────│  EC2-B    │  │
│  │10.0.1.10 │ ピアリング│     │         │10.1.1.10 │  │
│  └──────────┘  接続    │     │         └──────────┘  │
│                        │     │                        │
└────────────────────────┘     └────────────────────────┘

※ CIDR が重複する VPC 間ではピアリング不可

VPC ピアリングの作成

# ピアリング接続のリクエスト
PEERING_ID=$(aws ec2 create-vpc-peering-connection \
  --vpc-id vpc-prod-123 \
  --peer-vpc-id vpc-dev-456 \
  --tag-specifications 'ResourceType=vpc-peering-connection,Tags=[{Key=Name,Value=prod-to-dev}]' \
  --query 'VpcPeeringConnection.VpcPeeringConnectionId' \
  --output text)

# ピアリング接続の承認（ピア側で実行）
aws ec2 accept-vpc-peering-connection \
  --vpc-peering-connection-id $PEERING_ID

# 本番VPCのルートテーブルにルート追加
aws ec2 create-route \
  --route-table-id rtb-prod-xxx \
  --destination-cidr-block 10.1.0.0/16 \
  --vpc-peering-connection-id $PEERING_ID

# 開発VPCのルートテーブルにルート追加
aws ec2 create-route \
  --route-table-id rtb-dev-xxx \
  --destination-cidr-block 10.0.0.0/16 \
  --vpc-peering-connection-id $PEERING_ID

VPC ピアリングの制約

VPC エンドポイント

VPC エンドポイントは、VPC 内から AWS サービスにプライベート接続するための機能です。インターネットや NAT ゲートウェイを経由せずに通信できます。

2種類のエンドポイント

ゲートウェイ型エンドポイント（S3）

# S3 用ゲートウェイエンドポイントの作成
aws ec2 create-vpc-endpoint \
  --vpc-id $VPC_ID \
  --service-name com.amazonaws.ap-northeast-1.s3 \
  --route-table-ids $PRIV_RT \
  --tag-specifications 'ResourceType=vpc-endpoint,Tags=[{Key=Name,Value=nakamura-s3-endpoint}]'

ゲートウェイエンドポイント使用前:
  EC2 (Private) → NAT GW → IGW → インターネット → S3
  ※ NAT GW のデータ転送料金が発生

ゲートウェイエンドポイント使用後:
  EC2 (Private) → VPC Endpoint → S3
  ※ 無料、かつプライベート接続

エンドポイントポリシー

エンドポイント経由でアクセスできるリソースを制限できます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowSpecificBucket",
      "Effect": "Allow",
      "Principal": "*",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": [
        "arn:aws:s3:::nakamura-*/*"
      ]
    }
  ]
}

インターフェース型エンドポイント（PrivateLink）

# CloudWatch Logs 用インターフェースエンドポイント
aws ec2 create-vpc-endpoint \
  --vpc-id $VPC_ID \
  --service-name com.amazonaws.ap-northeast-1.logs \
  --vpc-endpoint-type Interface \
  --subnet-ids $PRIV_SUBNET_A $PRIV_SUBNET_C \
  --security-group-ids $ENDPOINT_SG \
  --private-dns-enabled \
  --tag-specifications 'ResourceType=vpc-endpoint,Tags=[{Key=Name,Value=nakamura-logs-endpoint}]'

インターフェースエンドポイントの構成:

┌──── プライベートサブネット ─────────┐
│                                      │
│  [EC2] → [ENI (VPC Endpoint)] → CloudWatch Logs
│           10.0.11.100               │
│           (プライベートDNS有効)       │
│                                      │
│  ※ アプリケーションのコード変更不要    │
│  ※ DNS が自動的にエンドポイントに解決 │
└──────────────────────────────────────┘

Transit Gateway

複数の VPC やオンプレミスネットワークを中央で接続するハブ型のサービスです。VPC ピアリングの拡張版と考えられます。

VPC ピアリング（多対多はメッシュになる）:
  VPC-A ─── VPC-B
   │  ╲      │
   │   ╲     │
   │    ╲    │
  VPC-C ─── VPC-D

Transit Gateway（ハブ&スポーク型）:
  VPC-A ─┐
  VPC-B ─┤
  VPC-C ─┼── Transit Gateway
  VPC-D ─┤
  On-Prem─┘

VPC が3つ以上の場合は Transit Gateway の方が管理しやすくなります。

まとめ

チェックリスト

• VPC ピアリングの概念と設定方法を理解した
• ゲートウェイ型とインターフェース型エンドポイントの違いを説明できる
• S3 用ゲートウェイエンドポイントの設定方法を把握した
• エンドポイントポリシーによるアクセス制御を理解した
• Transit Gateway の用途を把握した

次のステップへ

次のセクションでは、これまで学んだ VPC の知識を総動員して、本番環境レベルの VPC を設計する演習に挑戦します。

推定読了時間: 30分