サブネット・ルートテーブル・ゲートウェイ

導入

VPCという敷地ができても、そのままでは何も動きません。敷地の中を区画に分け、どこがインターネットに面していて、どこが面していないかを決める必要があります。

説明

VPCの内部は、サブネットという単位でさらに区切って使います。

パブリックサブネット … インターネットゲートウェイ経由でインターネットと直接通信できるサブネット。Webサーバーなど、外部からアクセスされる必要があるリソースを置く。
プライベートサブネット … インターネットから直接アクセスできないサブネット。データベースなど、外部に直接さらしたくないリソースを置く。

通信の出入り口となるのが次の2つのゲートウェイです。

インターネットゲートウェイ（IGW） … VPCとインターネットの間の双方向の出入り口。パブリックサブネットのリソースが外部と通信するために使う。
NATゲートウェイ … プライベートサブネットのリソースが、外部からは直接アクセスされずに、自分からインターネット側へ出ていく（例：ソフトウェアの更新を取りに行く）ための一方向の出口。

そして、どの通信をどこへ送るかを決めるのがルートテーブルです。サブネットごとに関連付けられ、「この宛先の通信はこのゲートウェイへ」という経路（ルート）の一覧を持ちます。

flowchart TB
    Internet(("インターネット"))
    subgraph VPC["VPC"]
        IGW["インターネット\nゲートウェイ"]
        subgraph Public["パブリックサブネット"]
            Web["Webサーバー（EC2）"]
        end
        subgraph Private["プライベートサブネット"]
            DB["データベース（RDS）"]
            Nat["NATゲートウェイ"]
        end
    end
    Internet <--> IGW
    IGW <--> Web
    Private -->|外へ出るときだけ| Nat
    Nat --> IGW

Webサーバーはパブリックサブネットに置いて外部からのアクセスを受け付け、データベースはプライベートサブネットに置いて外部から直接アクセスできないようにする——この組み合わせが、Webアプリケーションの定番の構成です。

具体例

先ほどの 10.0.0.0/16 の敷地に、ネットショップを配置してみましょう。

Webサーバー（EC2）→ パブリックサブネット … お客さんがブラウザでアクセスする必要があるので、インターネットゲートウェイ経由で外と通信できる区画に置く。
データベース（RDS）→ プライベートサブネット … 顧客情報やクレジット情報を持つので、インターネットから直接は絶対に触れない区画に隔離する。Webサーバーからだけアクセスできる。

ここで困りごとが1つ。プライベートのDBサーバーも、OSのセキュリティ更新は取りに行きたい。でも外からは触られたくない。この「自分から出るのはOK、外から入られるのはNG」を実現するのがNATゲートウェイです。DBは更新を取りに行くときだけNAT経由で外へ出ていき、外部からの侵入口にはなりません。

「外に開くWebは表通り（パブリック）、守りたいDBは奥の部屋（プライベート）、奥からの買い出しは勝手口（NAT）」——この間取りが定番構成です。

読んでみよう

「IGWは双方向の玄関、NATゲートウェイはプライベート側から外へ出るための一方通行の勝手口」という違いは頻出ポイントです。