こんにちは！クラウドの海原へ漕ぎ出したばかりのインフラ・ネットワーク初心者のみなさん、日々格闘お疲れ様です。「AWSやGCPを触り始めたけれど、サブネットやNATゲートウェイという言葉が出てくると、途端に頭がモヤモヤする……」そんな風に感じていませんか？
大丈夫です、一歩ずつ理解していきましょう！
今回は、クラウドインフラの裏方としてめちゃくちゃ重要な働きをしている「NATゲートウェイとElastic IP（EIP）の秘密」を、身近な世界に例えながら分かりやすく解き明かしていきます。実務でそのまま使える設定のコツや、思わぬ落とし穴を避けるためのダウンタイム最小化テクニックまで、現場のリアルな視点でお届けしますね。
—
1. パブリックとプライベート、そしてNATゲートウェイって何者？
まずは、クラウドのネットワーク（VPC）という大きなお城の構造を整理してみましょう。
- パブリックサブネット（城の正面玄関）：
インターネットという「外の世界」と直接つながっているエリアです。ここにいるサーバー（EC2など）には、外の世界から手紙が届く「グローバルIPアドレス」を持たせることができます。
- プライベートサブネット（城の奥深くにある金庫室）：
セキュリティをガチガチに固めるため、外の世界から直接見えないように遮断されたエリアです。ここにいるサーバーは安全ですが、そのままではインターネット上のアップデートサーバーなどへ外出しすることができません。
「でも、プライベートなサーバーからも、ときどき外のパッケージやデータをダウンロードしたいよね？」
そんなときに登場するのが、今回主役の「NATゲートウェイ（通称：NAT Gateway）」です。
郵便配達に例えてみよう
プライベートサブネットにいるサーバーを「外の世界を知らない内勤のスタッフ」だと想像してください。このスタッフが、インターネット（外の世界）にある通販サイトから荷物を取り寄せたいとします。
しかし、内勤スタッフは外に出ていくことができません。そこで、「代わりに外に行って、荷物を受け取ってきてくれるおつかい係（＝NATゲートウェイ）」を玄関口に配置します。
内勤スタッフが「これ買ってきて！」とNATゲートウェイに頼むと、NATゲートウェイは自分の顔（パブリックIPアドレス）を使って外の世界へ買いに行き、戻ってきたら中身をスタッフに渡してくれます。外の世界からは、すべてNATゲートウェイが買い物をしているように見えるわけですね。これが、NATゲートウェイの基本的なお仕事です。
—
2. Elastic IP（EIP）のバインド仕様と自動割り当ての罠
さて、このおつかい係（NATゲートウェイ）をクラウド上で作るとき、必ずセットで必要になるのが「Elastic IP（EIP）」という固定のパブリックIPアドレスです。
ここで初心者の私たちがやりがちな疑問が、「あれ？ NATゲートウェイを作るボタンを押したら、勝手にIPアドレスを割り当ててくれる機能はないの？」という点です。
EIPは「名札」のようなもの
AWSなどのクラウドでNATゲートウェイを作成する際、実はあらかじめ自分で「Elastic IP」という固定のパブリックIPアドレスを取得（確保）しておき、それをNATゲートウェイにくっつける（バインドする）という手順が必要になります。
これを現実の例えで言うと、おつかい係（NATゲートウェイ）に「今日からお前はこの背番号（IPアドレス）を背負って仕事してくれよ」と固有の名札を渡す作業にそっくりです。
- 自動割り当てで気をつけるべきこと：
もし仮に、システムが勝手に適当なIPアドレスをその場で割り当ててしまうと、NATゲートウェイを作り直したときにIPアドレスがガラリと変わってしまいます。
- 固定IPがなぜ必要か：
接続先の外部APIサーバーなどが「このIPアドレスからのアクセス以外はセキュリティ上ブロックする！」と厳しく制限している場合、NATゲートウェイのIPアドレスが勝手に変わると、外部と通信できなくなってパニックになってしまいますよね。だからこそ、あらかじめ自分で取得した不変のEIPをバインドさせる必要があるのです。
—
3. 実践！Terraformで学ぶNATゲートウェイとEIPの構築
言葉だけだとイメージしにくいので、実際のインフラコード（Terraform）を見てみましょう。実務ではこのようにコードで定義するのが現代のスタンダードです。
# 1. おつかい係（NATゲートウェイ）に背負わせるための固定IP（Elastic IP）を確保します
aws_eip "nat_gw_eip" {
domain = "vpc"
tags = {
Name = "production-nat-gateway-eip"
Note = "外部API通信用の固定パブリックIPアドレス"
}
}
# 2. パブリックサブネットにNATゲートウェイを配置し、先ほど確保したEIPをバインドします
aws_nat_gateway "main_nat" {
# EIPの割り当てIDを指定
allocation_id = aws_eip.nat_gw_eip.id
# NATゲートウェイを配置するパブリックサブネットのIDを指定
subnet_id = aws_subnet.public_a.id
tags = {
Name = "production-nat-gateway"
}
# 依存関係を明示的に記述し、インターネットゲートウェイの作成完了後に動くようにする
depends_on = [aws_internet_gateway.gw]
}このコードを実行すると、「固定のEIPを確保」し、「それをアソシエーション（紐付け）したNATゲートウェイがパブリックサブネットに誕生する」という一連の流れが綺麗に自動化されます。
—
4. 現場の落とし穴：EIPの変更時におけるダウンタイム最小化とアソシエーション解除
さて、ここからが現場のSREとしての腕の見せ所、ちょっとディープで大切な話です。
運用を長く続けていると、「セキュリティポリシーの変更に伴い、NATゲートウェイに割り当てているEIPを別のものに変更したい」というシチュエーションに出くわします。
ここでやってはいけないNG行動が、「既存のNATゲートウェイに紐づいている古いEIPをいきなり外して、新しいEIPをくっつける」という荒業です。
アソシエーション解除のリアルな挙動
EIPとNATゲートウェイの紐付け（アソシエーション）を解除したり、NATゲートウェイ自体を削除して作り直したりすると、その瞬間に何が起きるでしょうか？
パケットの視点から見てみましょう。
プライベートサブネットのサーバーから外の世界へ向かっていたTCPコネクション（通信のパイプ）は、すべてその瞬間にプツリと切断されます。もし顧客のクレジットカード決済データや、長時間のファイルアップロードがその瞬間に走っていたら……？ そう、通信エラー（タイムアウト）を引き起こし、ビジネスに直結する深刻なインシデント（ダウンタイム）になってしまいます。
ダウンタイムを最小限にする「ブルーグリーン」的アプローチ
安全にEIPを変更（あるいはNATゲートウェイを再作成）するためには、一気に切り替えるのではなく、「新旧の並行稼働（ブルーグリーン・デプロイメント）」の考え方を持ち込みます。
1. 新しいEIPと新しいNATゲートウェイを別の場所に用意する：
今の通信を邪魔しないように、まずは新しいEIPを取得し、空いている別のパブリックサブネット（または一時的な場所）に新しいNATゲートウェイをもう一つ組み立てます。
2. ルートテーブル（道案内）を静かに切り替える：
プライベートサブネットの道案内図である「ルートテーブル」の行き先（0.0.0.0/0の宛先）を、古いNATゲートウェイから新しいNATゲートウェイへ、一瞬で書き換えます。
3. 古い方を優しくお片付けする：
新しいNATゲートウェイへトラフィックが安全に流れていることを確認してから、古いNATゲートウェイを削除し、古いEIPを解放します。
この手順を踏むことで、ユーザーの通信断を数秒（あるいはミリ秒単位）に抑えるか、あるいは無停止で移行を完了させることができます。
—
まとめ：インフラの裏側を想像しながら手を動かそう
いかがでしたでしょうか？
今回は、NATゲートウェイのパブリックIP自動割り当てとEIPのバインド仕様、そして現場で役立つ移行のコツについてお話しました。
- NATゲートウェイは、プライベートなサーバーの代わりに外へおつかいに行ってくれる頼れる存在。
- IPアドレスが変わるトラブルを防ぐため、固定の「Elastic IP」を明示的にバインドしてあげる必要がある。
- 変更や移行の際は、パケットの流れとコネクションの切断に配慮し、ダウンタイムを最小限にする工夫がプロの技。
最初は横文字や設定項目が多くて難しく感じるかもしれませんが、「今、パケットという名の郵便配達員がどこを走っているんだろう？」と頭の中でイメージできるようになると、クラウドネットワークの触り方が何倍も楽しく、そして確実なものになっていきます。
それでは、次回のクラウド＆コンテナネットワークの探求もお楽しみに！現場からは以上です！
コメント