VPCの設計 ― CIDRとサブネット

導入

AWS上のあらゆるリソースは、まず「どのネットワークに置くか」から設計が始まります。その土台となるのが VPC（Virtual Private Cloud） です。

説明

VPC は、AWSアカウント内に作る論理的に隔離された仮想ネットワークです。VPCを作成する際、最初に決めるのが CIDRブロック（IPアドレスの範囲）です。例えば 10.0.0.0/16 を割り当てると、そのVPC内で約6万5千個のIPアドレスを使えます。

VPCの中は サブネット に分割して使います。サブネットは必ず1つのAZに属し、役割によって公開範囲を分けます。

ルートテーブル は、サブネットごとの通信の行き先を決める設定です。「どのサブネットが、どこ（インターネット・他のVPC・オンプレミス）へ通信できるか」は、ルートテーブルで制御します。

flowchart TD
    subgraph VPC["VPC 10.0.0.0/16"]
      subgraph AZa["AZ-a"]
        Pub1["パブリックサブネット<br/>10.0.1.0/24"]
        Priv1["プライベートサブネット<br/>10.0.11.0/24"]
      end
      subgraph AZc["AZ-c"]
        Pub2["パブリックサブネット<br/>10.0.2.0/24"]
        Priv2["プライベートサブネット<br/>10.0.12.0/24"]
      end
    end

設計の鉄則：可用性のため、パブリック・プライベートともに複数のAZにまたがってサブネットを作成します（第1章のMulti-AZの原則がここでも適用されます）。

具体例

典型的な3層Webアプリを、VPC 10.0.0.0/16 の中に配置してみましょう。「どの層をどのサブネットに置くか」がそのまま設計になります。

• ロードバランサー（ALB）→ パブリックサブネット … インターネットからのアクセスを受ける必要があるので公開側。AZ-aとAZ-cに1つずつ（例 10.0.1.0/24、10.0.2.0/24）。
• アプリサーバー（EC2）→ プライベートサブネット … 直接インターネットに晒す必要はなく、ALB経由でのみ受ける。AZ-aとAZ-cに（10.0.11.0/24、10.0.12.0/24）。
• データベース（RDS）→ プライベートサブネット … 最も守りたい層。外部から直接触れない奥に隔離し、アプリ層からのみアクセス。

ここで2つの鉄則が効きます。①インターネットから直接アクセスされるものだけパブリック（ここではALBだけ）、それ以外は全部プライベート。②各層を必ず複数AZにまたがって配置し、片方のAZが落ちても継続。SAAは「このリソースはパブリックか、プライベートか」を繰り返し問います。DBがパブリックにいる選択肢は、まず不正解です。

読んでみよう

SAAでは「このリソースはパブリックサブネットに置くべきか、プライベートサブネットに置くべきか」を問う設問が頻出です。インターネットから直接アクセスされる必要があるものだけパブリック、それ以外（特にDB）は必ずプライベートに置く、が基本方針です。