概要
プライベートサブネットの EC2 インスタンスは、インターネットから直接アクセスされない代わりに、そのままではインターネットにも出られません。OS のパッチやパッケージを取りに行くには、NAT ゲートウェイを経由させるのが定番です。
ところが、複数の AZ にプライベートサブネットがあるのに NAT ゲートウェイを 1 つの AZ にだけ置いて共用していると、その AZ に障害が起きたときに、他の AZ のインスタンスまでインターネットに出られなくなります。Web サーバーや DB を複数 AZ に広げても、外へ出る出口が 1 つの AZ に寄っていれば、そこが弱点として残ります。
この記事では、プライベートサブネットから外へ出る方法（NAT ゲートウェイ・NAT インスタンス・インターネットゲートウェイと Elastic IP・VPC エンドポイント）を比べたうえで、NAT ゲートウェイを AZ 障害に強くする 2 つの方法を整理します。1 つは AZ ごとに NAT ゲートウェイを置いてルートを分ける従来の方法、もう 1 つは 2025 年 11 月に提供が始まった、1 つで複数の AZ にまたがる リージョン NAT ゲートウェイ です。実践では、1 つの NAT ゲートウェイを共用している状態から両方の形に組み替え、各 AZ のインスタンスがどの出口を通っているかを確かめます。
クラウドおさる猿山の出入り口が東の山にしかないと、東の山で崖崩れが起きた日には、西の山の猿まで外へバナナを取りに行けなくなるでござる。今日は、出口を山ごとに用意する方法を確かめるでござるよ。
この記事のメリット
- プライベートサブネットから外へ出る方法を比べ、要件に合うものを選べるようになる
- インターネットゲートウェイへのルートや Elastic IP では「直接アクセスさせない」要件を満たせない理由を説明できるようになる
- NAT ゲートウェイを 1 つの AZ で共用したときの弱点と、AZ ごとに置くときのルートの分け方が分かる
- ゾーン NAT ゲートウェイとリージョン NAT ゲートウェイの違いと使い分けが分かる
- NAT ゲートウェイと NAT インスタンスの違い（可用性・管理・送信元/送信先チェック）を説明できるようになる
執筆者とキャラクター紹介
執筆者：土肥（とひ）
株式会社ジェニュインの代表であり元エンジニア。これまでオンプレミスと AWS 環境のインフラ業務を担当。AWS 認定資格の学習で得た知識を、ハンズオンとともに解説するのが得意。直近では新人の教育も行っており、これから技術を学ぶ方が納得できる解説を心がけています。基礎編・Cloud Practitioner の記事では、解説役としても登場します。
クラウドおさる
クラウドおさるはじめましてでござる。弊猿はクラウドおさる。IT インフラが異常に発達した猿山から、雲に乗って地上の AWS を学びに降りてきたのでござる。
クラウドおさる基礎編や Cloud Practitioner の記事では、とひさんに素朴な疑問をぶつける役でござるな。Security - Specialty などの記事では、要所でワンポイントや注意点をひとこと添えるでござる。
クラウドおさる猿山にもデータセンターや監視当番があって、地上で起きることはだいたい猿山にも同じ仕組みがあるのでござる。例え話がつい猿山に寄るのは、弊猿の癖でござる。
技術解説
プライベートサブネットから外へ出る方法
「インターネットからは直接アクセスさせないが、インスタンスからはインターネットに出たい」という要件に対して、よく比べられる方法は次のとおりです。
| 方法 | 外へ出られるか | インターネットから直接アクセスされないか | 説明 |
|---|---|---|---|
| パブリックサブネットの NAT ゲートウェイ + プライベートサブネットのルート | 出られる | されない | NAT ゲートウェイは、外からの接続の開始を受け付けない |
| パブリックサブネットの NAT インスタンス + プライベートサブネットのルート | 出られる | されない | 自分で EC2 を管理する。可用性・パッチ当ては利用者の責任 |
| プライベートサブネットのルートをインターネットゲートウェイに向ける | パブリック IP があれば出られる | される | ルートがインターネットゲートウェイを向いた時点で、そのサブネットはパブリックサブネットになる |
| インスタンスに Elastic IP を付ける | サブネットにインターネットゲートウェイへのルートがあれば出られる | される | インスタンス自身がパブリック IP で外から到達できるようになる。インターネットゲートウェイへのルートが無いプライベートサブネットのままでは、Elastic IP を付けても外へ出られない |
| VPC エンドポイント | AWS のサービスにだけ出られる | されない | S3 や DynamoDB などへの通信だけなら、NAT を通さずに済む |
インターネットゲートウェイへのルートとパブリック IP（Elastic IP）の組み合わせは、外へ出られるようにはなりますが、インスタンスがインターネットから見える状態になります。「直接アクセスさせない」という要件を満たすのは、NAT を経由させる方法です。
NAT ゲートウェイの置き場所にも注意が必要です。パブリック NAT ゲートウェイはパブリックサブネットに作成し、作成時に Elastic IP アドレスを関連付けます。プライベートサブネット側では、ルートテーブルの 0.0.0.0/0 のターゲットを NAT ゲートウェイにします。NAT インスタンスも同じで、インターネットゲートウェイへのルートがあるパブリックサブネットに置かなければ外へ出られません。
NAT ゲートウェイと NAT インスタンス
| 項目 | NAT ゲートウェイ | NAT インスタンス |
|---|---|---|
| 可用性 | AZ の中では冗長化されている。AZ ごとに作ると AZ に依存しない構成にできる | インスタンス間のフェイルオーバーをスクリプトなどで自分で作る |
| 帯域幅 | 5 Gbps から始まり、100 Gbps まで自動で拡張する | インスタンスタイプの帯域幅に依存する |
| メンテナンス | AWS が管理する | OS のパッチ当てなどを利用者が行う |
| セキュリティグループ | 関連付けられない（背後のインスタンス側で制御する） | 関連付けられる |
| 送信元/送信先チェック | 気にしなくてよい | 無効にする必要がある（自分宛てでない通信を中継するため） |
| 踏み台・ポート転送 | 使えない | 使える |
いまから作るなら、管理の手間と可用性の面で NAT ゲートウェイを選ぶのが基本です。
クラウドおさるNAT インスタンスは、門番の猿を自分で雇って、病気になったら代わりを探すのも自分でござる。NAT ゲートウェイなら門番の世話は AWS に任せられるのでござるな。
1 つの NAT ゲートウェイを共用したときの弱点
NAT ゲートウェイ（ゾーン NAT ゲートウェイ）は、特定の AZ に作成され、その AZ の中では冗長化されています。裏を返すと、AZ そのものが止まれば、その AZ の NAT ゲートウェイも使えなくなります。
複数の AZ のリソースが 1 つの NAT ゲートウェイを共用していると、その NAT ゲートウェイがある AZ がダウンしたときに、他の AZ のリソースもインターネットにアクセスできなくなります。耐障害性を高めるには、次のようにします。
- AZ ごとにパブリックサブネットへ NAT ゲートウェイを作る
- プライベートサブネットのルートテーブルを AZ ごとに分ける
- 各ルートテーブルの
0.0.0.0/0を、同じ AZ の NAT ゲートウェイに向ける
同じ AZ の NAT ゲートウェイを使うようにしておくと、AZ をまたぐ通信が減り、AZ 間のデータ転送料金も抑えられます。
リージョン NAT ゲートウェイ
2025 年 11 月から、NAT ゲートウェイの「アベイラビリティーモード」で リージョン を選べるようになりました（コンソールの表示は「リージョナル – 新規」。従来のゾーン NAT ゲートウェイは「ゾーナル」と表示されます）。リージョン NAT ゲートウェイは、1 つの NAT ゲートウェイがワークロードのある AZ に合わせて自動で広がったり縮んだりします。
| 項目 | ゾーン NAT ゲートウェイ（従来） | リージョン NAT ゲートウェイ |
|---|---|---|
| 作る単位 | AZ ごと（パブリックサブネットを指定して作る） | VPC ごと（サブネットを指定しない） |
| パブリックサブネット | 必要 | 不要 |
| プライベートサブネットのルート | AZ ごとに、同じ AZ の NAT ゲートウェイへ向ける | どの AZ からも、同じ 1 つの NAT ゲートウェイ ID へ向けられる |
| 新しい AZ への対応 | NAT ゲートウェイとルートを自分で追加する | 自動で広がる。ただし新しい AZ への拡張に最大 60 分かかることがあり、その間は既存の AZ の NAT ゲートウェイが処理する |
| IP アドレス | NAT ゲートウェイあたり最大 8 個 | AZ あたり最大 32 個。自動モードでは AWS が管理する（手動モードもある） |
| プライベート NAT | 使える | 使えない（ゾーン NAT ゲートウェイを使う） |
| 料金 | NAT ゲートウェイごとの時間料金 + 処理したデータ量 | 時間料金 + 処理したデータ量（課金の単位は Amazon VPC の料金ページで確認する） |
リージョン NAT ゲートウェイを作ると、AWS がその NAT ゲートウェイ用のルートテーブルを自動で作り、インターネットゲートウェイへのルートもあらかじめ入ります。
AZ ごとに NAT ゲートウェイとルートを管理する手間をなくせるのが利点です。一方、プライベート NAT が要る場合や、AZ ごとに出口を細かく制御したい場合は、従来のゾーン NAT ゲートウェイを選びます。
クラウドおさる出口を山ごとに自分で建てるのがゾーン、猿が住み着いた山に出口が勝手に伸びていくのがリージョンでござる。どちらも「1 つの山に寄せない」ための道具なのでござるな。
実践
2 つの AZ のプライベートサブネットが、ap-northeast-1a の NAT ゲートウェイ 1 つを共用している状態から始めます。まず ap-northeast-1c にも NAT ゲートウェイを作ってルートを分け、各 AZ のインスタンスが自分の AZ の出口を通ることを確かめます。続けて、リージョン NAT ゲートウェイに切り替えます。
前提条件
- リージョン:
ap-northeast-1（東京） - VPC・EC2・Systems Manager の操作権限を持つ IAM ユーザーまたはロールでコンソールにログイン済みであること
以下のリソースが作成済みであることを前提とします。プライベートサブネットの EC2 には、Session Manager で接続できる IAM ロールが付いています。
まだ用意していない場合は、「作り方の参考」の記事の手順で作れます。リソース名は、この記事の名前に読み替えてください。
| リソース種別 | リソース名 | 内容 | 作り方の参考 |
|---|---|---|---|
| VPC | nat-ha-vpc | CIDR 10.0.0.0/16 | Amazon VPC で仮想ネットワークを構築しサブネットを設定する ※AZ を 2 つにする |
| パブリックサブネット | nat-ha-public-1a / nat-ha-public-1c | 10.0.1.0/24（1a）/ 10.0.2.0/24（1c）。インターネットゲートウェイ nat-ha-igw へのルートあり | 同上 |
| プライベートサブネット | nat-ha-private-1a / nat-ha-private-1c | 10.0.11.0/24（1a）/ 10.0.12.0/24（1c） | 同上 |
| NAT ゲートウェイ | nat-ha-nat-1a | nat-ha-public-1a に配置。Elastic IP 付き | NAT ゲートウェイでプライベートサブネットからの外部通信を実現する |
| ルートテーブル | nat-ha-private-rt-1a / nat-ha-private-rt-1c | それぞれのプライベートサブネットに関連付け。どちらも 0.0.0.0/0 → nat-ha-nat-1a | VPC のルートテーブルでトラフィックの流れを制御する |
| EC2 インスタンス | nat-ha-app-1a / nat-ha-app-1c | それぞれのプライベートサブネットに 1 台ずつ。パブリック IP なし。Session Manager で接続できる | NAT ゲートウェイでプライベートサブネットからの外部通信を実現する |
このハンズオンで作成するリソースは以下のとおりです。
| リソース種別 | リソース名 | 用途 |
|---|---|---|
| NAT ゲートウェイ（ゾーン） | nat-ha-nat-1c | ap-northeast-1c 用の出口 |
| NAT ゲートウェイ（リージョン） | nat-ha-regional | 両方の AZ をまとめて受け持つ出口 |
NAT ゲートウェイは、作成している間ずっと時間単位で課金されます。Elastic IP も課金対象です。検証が終わったら必ず削除し、Elastic IP を解放してください。
手順 1: 両方の AZ が同じ NAT ゲートウェイを通っていることを確かめる
AWS マネジメントコンソールにログインし、リージョンが ap-northeast-1（東京）であることを確認します。
上部の検索バーに VPC と入力し、「VPC」を選択します。左側ナビゲーションの「NAT ゲートウェイ」を選択し、nat-ha-nat-1a の「プライマリパブリック IPv4 アドレス」を控えておきます。
左側ナビゲーションの「ルートテーブル」を選択し、検索ボックスに nat-ha-private と入力して絞り込みます。nat-ha-private-rt-1c を選択し、下部の「ルート」タブで 0.0.0.0/0 のターゲットが nat-ha-nat-1a の ID（nat- で始まる）になっていることを確認します。ap-northeast-1c のサブネットなのに、ap-northeast-1a の NAT ゲートウェイを通っている状態です。
上部の検索バーに EC2 と入力し、「EC2」を選択します。「インスタンス」で nat-ha-app-1c を選択し、「接続」をクリックします。「Session Manager」タブで「接続」をクリックし、表示されたターミナルで次のコマンドを実行します。
curl -s https://checkip.amazonaws.com表示された IP アドレスが、控えておいた nat-ha-nat-1a のパブリック IP アドレスと同じであることを確認します。nat-ha-app-1a でも同じコマンドを実行し、同じ IP アドレスになることを確認します。
手順 2: ap-northeast-1c に NAT ゲートウェイを作る
VPC コンソールの左側ナビゲーションで「NAT ゲートウェイ」を選択し、「NAT ゲートウェイを作成」をクリックします。以下を設定します。
- 名前:
nat-ha-nat-1c - アベイラビリティーモード:
ゾーナル（初期表示は「リージョナル – 新規」なので切り替えます。ゾーナルにすると、サブネット・接続タイプ・Elastic IP の欄が表示されます） - サブネット:
nat-ha-public-1c - 接続タイプ:
パブリック - Elastic IP 割り当て ID: 「Elastic IP を割り当て」をクリックして新しく割り当てる（割り当てた ID が欄に自動で入ります）
その他の項目はデフォルトのままにして、「NAT ゲートウェイを作成」をクリックします。
状態が Available になるまで数分待ちます。nat-ha-nat-1c のパブリック IP アドレスを控えておきます。
手順 3: ap-northeast-1c のルートを同じ AZ の NAT ゲートウェイに向ける
左側ナビゲーションの「ルートテーブル」から nat-ha-private-rt-1c を選択し、「ルート」タブの「ルートを編集」をクリックします。0.0.0.0/0 のターゲットを「NAT ゲートウェイ」に変え、その下の入力欄に nat- と入力して、候補に表示された nat-…（nat-ha-nat-1c） を選択します。「変更を保存」をクリックします。
nat-ha-private-rt-1a は nat-ha-nat-1a に向けたままにします。これで、各 AZ のプライベートサブネットが同じ AZ の NAT ゲートウェイを通るようになりました。
手順 4: 各 AZ のインスタンスが自分の AZ の出口を通ることを確かめる
nat-ha-app-1c の Session Manager で、もう一度次のコマンドを実行します。
curl -s https://checkip.amazonaws.com表示される IP アドレスが nat-ha-nat-1c のパブリック IP アドレスに変わったことを確認します。nat-ha-app-1a では、引き続き nat-ha-nat-1a の IP アドレスが表示されます。
この状態なら、ap-northeast-1a に障害が起きても、ap-northeast-1c のインスタンスは自分の AZ の NAT ゲートウェイで外へ出られます。
クラウドおさる出口を山ごとに建てたら、道案内（ルートテーブル）も山ごとに分けて、自分の山の出口を指すようにするのが肝でござる。出口だけ増やしても、道案内が東の山を指したままでは意味がないのでござるな。
手順 5: リージョン NAT ゲートウェイに切り替える
左側ナビゲーションの「NAT ゲートウェイ」で「NAT ゲートウェイを作成」をクリックし、以下を設定します。
- 名前:
nat-ha-regional - アベイラビリティーモード:
リージョナル - 新規 - VPC:
nat-ha-vpc - Elastic IP (EIP) 割り当て方法:
自動
サブネットを指定する欄はありません。その他の項目はデフォルトのままにして、「NAT ゲートウェイを作成」をクリックします。
状態が Available になったら（今回は 2〜3 分でした）、nat-ha-regional の詳細画面を開きます。アベイラビリティーモードが Regional になっていること、「IP アドレス」タブに、インスタンスのある ap-northeast-1a と ap-northeast-1c のそれぞれに IP アドレスが自動で割り当てられていることを確認します。
続けて、nat-ha-private-rt-1a と nat-ha-private-rt-1c の両方で「ルートを編集」をクリックし、0.0.0.0/0 のターゲットを nat-ha-regional に変えて保存します。2 つの AZ のルートが、同じ 1 つの NAT ゲートウェイ ID を指すようになります。
各インスタンスの Session Manager で curl -s https://checkip.amazonaws.com を実行し、どちらのインスタンスからも外へ出られることを確認します。表示される IP アドレスは、リージョン NAT ゲートウェイがそれぞれの AZ に割り当てた IP アドレスに変わります。ルートが指す NAT ゲートウェイ ID は 1 つでも、出口は AZ ごとに分かれていることが分かります。なお、ワークロードが新しい AZ に増えた場合、その AZ へ広がるまでに最大 60 分かかることがあり、その間は既存の AZ の NAT ゲートウェイが通信を処理します。
クラウドおさる「直接アクセスさせずに外へ出す」ならパブリックサブネットの NAT、そして AZ 障害まで考えるなら「出口が 1 つの AZ に寄っていないか」でござる。インターネットゲートウェイへのルートとパブリック IP は、外へ出られても丸見えになるので取り違えないことでござるな。
まとめ
| 要件 | 選ぶもの |
|---|---|
| プライベートサブネットから外へ出たいが、直接アクセスはさせない | パブリックサブネットの NAT ゲートウェイ + プライベートサブネットのルート |
| AWS のサービス（S3・DynamoDB など）にだけ出られればよい | VPC エンドポイント |
| 複数 AZ で、AZ ごとに出口を細かく管理したい・プライベート NAT が要る | AZ ごとのゾーン NAT ゲートウェイ + AZ ごとのルートテーブル |
| 複数 AZ の出口をまとめて管理したい | リージョン NAT ゲートウェイ |
- インターネットゲートウェイへのルートとパブリック IP（Elastic IP）で外へ出すと、インスタンスがインターネットから見えるようになる。プライベートサブネットのままでは、Elastic IP を付けても外へ出られない
- NAT ゲートウェイ（ゾーン）は特定の AZ に作られる。1 つを複数 AZ で共用すると、その AZ の障害で他の AZ も外へ出られなくなる
- AZ ごとに NAT ゲートウェイを置き、各 AZ のルートテーブルを同じ AZ の NAT ゲートウェイに向けると、AZ に依存しない構成になる
- リージョン NAT ゲートウェイはパブリックサブネットが要らず、ワークロードのある AZ へ自動で広がる。新しい AZ への拡張には最大 60 分かかることがあり、プライベート NAT には使えない
- NAT インスタンスはパブリックサブネットに置き、送信元/送信先チェックを無効にする必要がある。可用性とメンテナンスは利用者の責任
参照先
- NAT ゲートウェイ – Amazon Virtual Private Cloud
- NAT ゲートウェイの基本 – Amazon Virtual Private Cloud
- 自動マルチ AZ 拡張用のリージョン NAT ゲートウェイ – Amazon Virtual Private Cloud
- NAT ゲートウェイと NAT インスタンスの比較 – Amazon Virtual Private Cloud
- プライベートリソースが VPC の外側で通信できるようにする – Amazon Virtual Private Cloud
- インターネットゲートウェイを使用して VPC のインターネットアクセスを有効にする – Amazon Virtual Private Cloud
