AWS VPC

VPCとは

VPC（Virtual Private Cloud）は、AWS上に作成する仮想的なプライベートネットワーク。AWSクラウドの中に「自分だけのネットワーク空間」を構築するサービス。

自社のデータセンターに例える

VPCは「AWSの中に自社のデータセンターを建てる」ようなもの。

AWSアカウントを作成すると、各リージョンにデフォルトVPCが自動的に作成されている。しかし本番環境では、自分で設計したカスタムVPCを使うのがベストプラクティス。

なぜVPCが必要か

セキュリティ

VPCがなければ、AWSの全てのリソースが同じネットワーク上に存在することになる。これは、マンションで全ての部屋の鍵がかかっていない状態と同じ。VPCを使えば、リソースごとにネットワークを分離し、必要な通信だけを許可できる。

ネットワーク分離

ネットワーク基礎

VPCを理解するには、ネットワークの基礎知識が必要。ここで重要な概念を押さえておく。

IPアドレスとは

IPアドレスは、ネットワーク上のコンピュータを識別するための番号。住所のようなもの。

IPv4アドレスは4つの数字をピリオドで区切って表す。各数字は0〜255の範囲。

例: 192.168.1.100
     │   │   │ │
     │   │   │ └── ホスト部（コンピュータの番号）
     │   │   └──── ネットワーク部（ネットワークの番号）
     │   └──────── （境界はサブネットマスクで決まる）
     └────────────

プライベートIPアドレスとパブリックIPアドレス

VPCではプライベートIPアドレスを使用する。インターネットに公開するリソースにはパブリックIPも割り当てる。

CIDR表記

CIDR（Classless Inter-Domain Routing、サイダーと読む）は、IPアドレスの範囲を表す表記方法。

10.0.0.0/16
│        │
│        └── プレフィックス長（ネットワーク部のビット数）
└──────────── ネットワークアドレス

/16は、32ビットのIPアドレスのうち最初の16ビットがネットワーク部であることを意味する。残りの16ビットがホスト部で、2^16 = 65,536個のIPアドレスが使える。

CIDR早見表

サブネットマスク

サブネットマスクは、IPアドレスのどこまでがネットワーク部で、どこからがホスト部かを示す値。CIDRの/数字と対応する。

AWSでは各サブネットの最初の4つと最後の1つのIPアドレスが予約されている。例えば /24 サブネットでは256個のうち5個が予約され、実際に使えるのは251個。

VPCの構成要素

VPCは複数のコンポーネントで構成されている。それぞれの役割を理解する。

全体像

┌─────────────────────────────────────────────────────────┐
│  VPC (10.0.0.0/16)                                       │
│                                                           │
│  ┌─────────────────────┐  ┌─────────────────────┐       │
│  │ パブリックサブネット    │  │ パブリックサブネット    │       │
│  │ (10.0.1.0/24)        │  │ (10.0.2.0/24)        │       │
│  │ AZ: ap-northeast-1a  │  │ AZ: ap-northeast-1c  │       │
│  │                       │  │                       │       │
│  │  ┌─────┐ ┌─────┐    │  │  ┌─────┐             │       │
│  │  │ EC2 │ │ NAT │    │  │  │ EC2 │             │       │
│  │  └─────┘ └─────┘    │  │  └─────┘             │       │
│  └──────────┬───────────┘  └──────────┬───────────┘       │
│             │                          │                    │
│  ┌──────────┴───────────┐  ┌──────────┴───────────┐       │
│  │ プライベートサブネット  │  │ プライベートサブネット  │       │
│  │ (10.0.3.0/24)        │  │ (10.0.4.0/24)        │       │
│  │ AZ: ap-northeast-1a  │  │ AZ: ap-northeast-1c  │       │
│  │                       │  │                       │       │
│  │  ┌─────┐ ┌─────┐    │  │  ┌─────┐ ┌─────┐    │       │
│  │  │ EC2 │ │ RDS │    │  │  │ EC2 │ │ RDS │    │       │
│  │  └─────┘ └─────┘    │  │  └─────┘ └─────┘    │       │
│  └──────────────────────┘  └──────────────────────┘       │
│                                                           │
└────────────────────────────┬──────────────────────────────┘
                             │
                    ┌────────┴────────┐
                    │ インターネット     │
                    │ ゲートウェイ       │
                    └────────┬────────┘
                             │
                        インターネット

各コンポーネントの説明

パブリックサブネット vs プライベートサブネット

サブネットは、VPC内のIPアドレス範囲を分割したもの。パブリックとプライベートの2種類がある。

違い

使い分けの考え方

「インターネットから直接アクセスされる必要があるか？」

Yes → パブリックサブネット
  例: Webサーバー（Nginx）、ロードバランサー（ALB）

No → プライベートサブネット
  例: データベース（RDS）、アプリケーションサーバー、バッチサーバー

重要な原則として、データベースは必ずプライベートサブネットに配置する。インターネットから直接データベースにアクセスできる状態は、セキュリティ上極めて危険。

VPC作成手順

コンソールでの作成

ステップ1: VPCの作成

1. VPCダッシュボード → 「VPCを作成」
2. 設定:
   - VPCの設定: VPCのみ
   - 名前タグ: my-vpc
   - IPv4 CIDRブロック: 10.0.0.0/16
   - IPv6 CIDRブロック: なし
   - テナンシー: デフォルト
3. 「VPCを作成」をクリック

CIDR設計のベストプラクティス

VPC全体: 10.0.0.0/16（65,536 IP）

パブリックサブネット:
  AZ-a: 10.0.1.0/24（256 IP）
  AZ-c: 10.0.2.0/24（256 IP）

プライベートサブネット（アプリ層）:
  AZ-a: 10.0.11.0/24（256 IP）
  AZ-c: 10.0.12.0/24（256 IP）

プライベートサブネット（データ層）:
  AZ-a: 10.0.21.0/24（256 IP）
  AZ-c: 10.0.22.0/24（256 IP）

このように番号付けのルールを決めておくと、後から見てもどのサブネットがどの用途かわかりやすい。

ステップ2: サブネットの作成

1. VPCダッシュボード → サブネット → 「サブネットを作成」
2. VPCを選択: my-vpc
3. サブネットの設定:
   - サブネット名: public-subnet-1a
   - アベイラビリティゾーン: ap-northeast-1a
   - IPv4 CIDRブロック: 10.0.1.0/24
4. 「サブネットを追加」で他のサブネットも作成
5. 「サブネットを作成」をクリック

ステップ3: インターネットゲートウェイの作成と紐付け

1. VPCダッシュボード → インターネットゲートウェイ → 「インターネットゲートウェイの作成」
2. 名前: my-igw
3. 作成後、「アクション」→「VPCにアタッチ」→ my-vpcを選択

ステップ4: ルートテーブルの設定

パブリックサブネット用のルートテーブルを作成し、インターネットゲートウェイへのルートを追加する。

1. VPCダッシュボード → ルートテーブル → 「ルートテーブルを作成」
2. 名前: public-route-table
3. VPC: my-vpc
4. ルートの編集:
   送信先: 0.0.0.0/0 → ターゲット: my-igw
5. サブネットの関連付け:
   public-subnet-1a, public-subnet-1c を関連付け

インターネットゲートウェイ（IGW）

インターネットゲートウェイは、VPCとインターネットを接続するための入口。

特徴

• VPC1つにつき、IGWは1つだけアタッチできる
• 水平スケーリングにより冗長性と高可用性が確保されている
• 帯域幅の制限はない
• 追加料金は発生しない

IGWが必要な通信の流れ

インターネット
    │
    ▼
インターネットゲートウェイ（IGW）
    │
    ▼
ルートテーブル（0.0.0.0/0 → igw-xxxxx）
    │
    ▼
パブリックサブネット
    │
    ▼
セキュリティグループ（ポート80/443を許可）
    │
    ▼
EC2インスタンス（パブリックIP付き）

パブリックサブネットに配置したEC2がインターネットと通信するには:

1. IGWがVPCにアタッチされている
2. ルートテーブルにIGWへのルートがある
3. EC2にパブリックIPが割り当てられている
4. セキュリティグループで通信が許可されている

この4つの条件が全て揃う必要がある。

NATゲートウェイ

NATゲートウェイは、プライベートサブネット内のリソースがインターネットにアクセスするための仕組み。NAT（Network Address Translation）は、プライベートIPアドレスをパブリックIPアドレスに変換する技術。

なぜNATゲートウェイが必要か

プライベートサブネットのEC2は、セキュリティのためにインターネットから直接アクセスできない。しかし、OSのアップデートやパッケージのインストールなど、EC2からインターネットに出ていく必要がある場面は多い。NATゲートウェイはこの一方通行の通信を実現する。

通信の流れ

プライベートサブネットのEC2
    │ （送信元: 10.0.3.100）
    ▼
ルートテーブル（0.0.0.0/0 → nat-xxxxx）
    │
    ▼
NATゲートウェイ（パブリックサブネットに配置）
    │ （送信元をNATのパブリックIPに変換）
    ▼
インターネットゲートウェイ
    │
    ▼
インターネット

外部からの応答は、NATゲートウェイが元のプライベートIPに変換して返す。しかし、外部から新規の接続は受け付けない（一方通行）。

NATゲートウェイの注意点

NATゲートウェイは比較的高額なので、開発環境ではNATインスタンス（EC2でNATを構築）を使ってコストを抑えることもある。

NATゲートウェイの作成手順

1. VPCダッシュボード → NATゲートウェイ → 「NATゲートウェイを作成」
2. 設定:
   - 名前: my-nat-gw
   - サブネット: パブリックサブネットを選択（重要）
   - 接続タイプ: パブリック
   - Elastic IPの割り当てID: 「Elastic IPを割り当て」で新規作成
3. 「NATゲートウェイを作成」をクリック
4. プライベートサブネットのルートテーブルに以下を追加:
   送信先: 0.0.0.0/0 → ターゲット: nat-xxxxx

ルートテーブル

ルートテーブルは、ネットワークトラフィックの経路を定義するもの。「この宛先のトラフィックは、ここに送る」というルールの一覧。

パブリックサブネットのルートテーブル

プライベートサブネットのルートテーブル

ルーティングの仕組み

ルートテーブルは、最も具体的な（プレフィックスが長い）ルートが優先される。これを「最長プレフィックスマッチ」と呼ぶ。

例: 宛先が 10.0.3.50 のパケット

ルートテーブル:
  10.0.0.0/16 → local      ← マッチ（/16）
  0.0.0.0/0   → igw-xxxxx  ← マッチ（/0）

→ /16の方が具体的なので、localが選ばれる（VPC内部通信）

セキュリティグループ vs ネットワークACL

VPCには2つのファイアウォール機能がある。それぞれの違いを理解することが重要。

比較表

ステートフル vs ステートレスとは

ステートフル（セキュリティグループ）: 通信の「状態」を記憶する。インバウンドで許可した通信の戻りのアウトバウンドは自動的に許可される。

外部 → [インバウンド: ポート80許可] → EC2
外部 ← [アウトバウンド: 自動許可] ← EC2  ← 戻りの通信は自動OK

ステートレス（NACL）: 通信の状態を記憶しない。インバウンドとアウトバウンドの両方にルールが必要。

外部 → [インバウンド: ポート80許可] → サブネット
外部 ← [アウトバウンド: エフェメラルポート許可が必要] ← サブネット

エフェメラルポート（一時ポート、1024-65535）の許可を忘れると、通信が成立しない。

実務での使い分け

ほとんどの場合、セキュリティグループだけで十分なセキュリティを確保できる。NACLは以下のような場合に使う:

• 特定のIPアドレスをサブネットレベルでブロックしたい
• セキュリティの多層防御（Defense in Depth）を実現したい
• コンプライアンス要件でサブネットレベルのフィルタリングが必要

典型的なVPC構成（3層アーキテクチャ）

本番環境でよく使われる3層アーキテクチャの構成を解説する。

構成図

┌────────────────────────────────────────────────────────────────┐
│  VPC (10.0.0.0/16)                                              │
│                                                                  │
│  ┌── AZ: ap-northeast-1a ──┐  ┌── AZ: ap-northeast-1c ──┐     │
│  │                          │  │                          │     │
│  │  [Web層] パブリック       │  │  [Web層] パブリック       │     │
│  │  10.0.1.0/24             │  │  10.0.2.0/24             │     │
│  │  ┌─────┐  ┌─────┐      │  │  ┌─────┐                │     │
│  │  │ ALB │  │ NAT │      │  │  │ ALB │                │     │
│  │  └─────┘  └─────┘      │  │  └─────┘                │     │
│  │                          │  │                          │     │
│  │  [App層] プライベート     │  │  [App層] プライベート     │     │
│  │  10.0.11.0/24            │  │  10.0.12.0/24            │     │
│  │  ┌─────┐  ┌─────┐      │  │  ┌─────┐  ┌─────┐      │     │
│  │  │ EC2 │  │ EC2 │      │  │  │ EC2 │  │ EC2 │      │     │
│  │  └─────┘  └─────┘      │  │  └─────┘  └─────┘      │     │
│  │                          │  │                          │     │
│  │  [DB層] プライベート      │  │  [DB層] プライベート      │     │
│  │  10.0.21.0/24            │  │  10.0.22.0/24            │     │
│  │  ┌──────────┐           │  │  ┌──────────┐           │     │
│  │  │ RDS      │           │  │  │ RDS      │           │     │
│  │  │ (Primary)│           │  │  │ (Standby)│           │     │
│  │  └──────────┘           │  │  └──────────┘           │     │
│  │                          │  │                          │     │
│  └──────────────────────────┘  └──────────────────────────┘     │
│                                                                  │
└──────────────────────────────┬───────────────────────────────────┘
                               │
                      ┌────────┴────────┐
                      │      IGW        │
                      └────────┬────────┘
                               │
                          インターネット

各層の役割

セキュリティグループの連鎖

セキュリティグループは、別のセキュリティグループをソースとして指定できる。これにより、IPアドレスに依存しない柔軟なルール設定が可能。

ALBのセキュリティグループ（sg-alb）:
  インバウンド: 0.0.0.0/0 → ポート 80, 443

EC2のセキュリティグループ（sg-app）:
  インバウンド: sg-alb → ポート 3000（ALBからのみ許可）

RDSのセキュリティグループ（sg-db）:
  インバウンド: sg-app → ポート 5432（EC2からのみ許可）

この設定により、外部からは ALB → EC2 → RDS という経路でしかアクセスできない。RDSに直接アクセスすることは不可能。

VPCピアリングとTransit Gateway

VPCピアリング

VPCピアリングは、2つのVPC間をプライベートに接続する機能。異なるVPC内のリソースが、プライベートIPアドレスで通信できるようになる。

┌──────────┐     VPCピアリング     ┌──────────┐
│ VPC-A    │ ←───────────────────→ │ VPC-B    │
│ 本番環境  │                       │ 開発環境  │
│ 10.0.0.0 │                       │ 10.1.0.0 │
└──────────┘                       └──────────┘

注意点:

• 2つのVPCのCIDRが重複していると接続できない
• 推移的ピアリングはできない（A-B、B-Cがピアリングしても、A-Cは直接通信できない）

Transit Gateway

Transit Gatewayは、多数のVPCやオンプレミスネットワークを中央集権的に接続するハブ。VPCピアリングはVPC間で1対1の接続だが、Transit Gatewayは多対多の接続を効率的に管理できる。

         ┌────────────┐
         │ Transit GW │
         └──────┬─────┘
        ┌───────┼───────┐
        │       │       │
   ┌────┴──┐ ┌─┴────┐ ┌┴──────┐
   │VPC-A  │ │VPC-B │ │VPC-C  │
   │本番   │ │開発  │ │ステージ│
   └───────┘ └──────┘ └───────┘

VPCが3つ以上になる場合は、Transit Gatewayの方が管理しやすい。

VPCエンドポイント

VPCエンドポイントは、VPC内のリソースからS3やDynamoDBなどのAWSサービスに、インターネットを経由せずにプライベートに接続する機能。

なぜ必要か

通常、プライベートサブネットからS3にアクセスするには、NATゲートウェイ → IGW → インターネット → S3という経路を通る。これは:

• NATゲートウェイの料金がかかる
• インターネットを経由するのでセキュリティリスクがある
• レイテンシが増加する

VPCエンドポイントを使えば、AWS内部のネットワークだけで通信が完結する。

エンドポイントの種類

S3とDynamoDBのゲートウェイエンドポイントは無料なので、プライベートサブネットからこれらのサービスにアクセスする場合は必ず設定すること。NATゲートウェイの料金を節約できる。

DNS（Route 53との連携）

VPC内でのDNS解決は、AmazonのDNSサーバー（VPCのCIDRの2番目のIP、例: 10.0.0.2）が自動的に提供される。

VPC内のDNS設定

Route 53のプライベートホストゾーンをVPCに関連付けると、VPC内部でカスタムドメイン名を使用できる。

例: db.internal.example.com → 10.0.21.100（RDSのプライベートIP）

フローログ

VPCフローログは、VPC内のネットワークインターフェースを通過するIPトラフィックの情報をキャプチャする機能。ネットワークのトラブルシューティングやセキュリティ分析に使用する。

フローログの記録例

2 123456789012 eni-abc123de 10.0.1.5 54.239.28.85 49875 443 6 25 20000 1620140661 1620140721 ACCEPT OK

フローログの出力先はCloudWatch LogsまたはS3バケットを選択できる。

実践例: EC2 + RDS構成のVPC設計

実際のWebアプリケーション環境を構築するVPC設計の例を示す。

要件

• WebアプリケーションはEC2上のNode.jsで動作
• データベースはRDS（PostgreSQL）を使用
• ドメインはRoute 53で管理
• HTTPS対応

ネットワーク設計

VPC: 10.0.0.0/16

パブリックサブネット:
  10.0.1.0/24 (ap-northeast-1a) - ALB, NAT Gateway
  10.0.2.0/24 (ap-northeast-1c) - ALB

プライベートサブネット（アプリ層）:
  10.0.11.0/24 (ap-northeast-1a) - EC2
  10.0.12.0/24 (ap-northeast-1c) - EC2

プライベートサブネット（DB層）:
  10.0.21.0/24 (ap-northeast-1a) - RDS Primary
  10.0.22.0/24 (ap-northeast-1c) - RDS Standby

セキュリティグループ設計

ALB用（sg-alb）:

EC2用（sg-app）:

RDS用（sg-db）:

構築手順の概要

1. VPCを作成（10.0.0.0/16）
2. サブネットを6つ作成（パブリック2、プライベートアプリ2、プライベートDB2）
3. インターネットゲートウェイを作成してVPCにアタッチ
4. NATゲートウェイをパブリックサブネットに作成
5. ルートテーブルを作成して適切に設定
6. セキュリティグループを作成
7. ALBをパブリックサブネットに配置
8. EC2をプライベートサブネット（アプリ層）に配置
9. RDSをプライベートサブネット（DB層）に配置
10. VPCエンドポイント（S3）を作成

実践演習

演習1: VPCの基本構築

1. カスタムVPC（10.0.0.0/16）を作成する
2. パブリックサブネットとプライベートサブネットを作成する
3. インターネットゲートウェイを作成してアタッチする
4. ルートテーブルを設定する
5. パブリックサブネットにEC2を起動してSSH接続する

演習2: 3層アーキテクチャの構築

1. 演習1のVPCにアプリ層とDB層のプライベートサブネットを追加する
2. NATゲートウェイを作成する
3. セキュリティグループを設計して作成する
4. プライベートサブネットにEC2を配置し、NATゲートウェイ経由でインターネットにアクセスできることを確認する

演習3: VPCフローログの分析

1. VPCフローログを有効にする
2. トラフィックを発生させる
3. CloudWatch Logsでフローログを確認する
4. 拒否されたトラフィックの原因を特定する

参考リンク

• AWS VPC 公式ドキュメント
• VPC 料金
• VPC セキュリティベストプラクティス
• VPC ピアリング
• VPC エンドポイント
• AWS Transit Gateway
• VPC フローログ
• CIDR計算ツール