こんにちは！クラウドの世界へようこそ。第一線でインフラを守るSREの視点から、今日は皆さんと一緒に「クラウドの迷宮」の一つ、ネットワークの通り道（ルーティング）について探検していきたいと思います。
「パブリックサブネット？NATゲートウェイ？ルートテーブル？言葉が難しくて、もうお腹いっぱい……」と感じている方も安心してください。今日は難しい専門用語をいったん横に置いて、私たちの身近な「郵便配達」の仕組みに例えながら、一歩ずつ丁寧に紐解いていきましょう。
実は、AWSなどのクラウド上で「安全で止まらないシステム」を作るためには、このネットワークの仕組みを理解することが一番の近道なんです。
—
1. そもそも「プライベートサブネット」と「NATゲートウェイ」って何？
まずは基本のキから。クラウドの中に自分たちの「町」を作ると想像してみてください。
インターネットから隠れた「奥座敷」
クラウドの中には、誰でもアクセスできる「表通り（パブリックサブネット）」と、限られた人しか入れない「奥座敷（プライベートサブネット）」があります。
大事なデータが入っているサーバーは、泥棒（ハッカー）に見つからないよう、この「奥座敷」に配置します。しかし、困ったことがあります。奥座敷のサーバーも、時には「最新のソフトをダウンロードしたい！」と外の世界（インターネット）に連絡を取りたい時があるのです。
外の世界への一方通行の窓口「NATゲートウェイ」
そこで登場するのがNATゲートウェイです。これは、いわば「町の郵便局の発送窓口」のようなもの。
- 外へは出せる： 奥座敷のサーバーからの荷物（リクエスト）を預かって、外の世界へ届けてくれます。
- 外からは入れない： 外の人が勝手にこの窓口を通って奥座敷に入ることはできません。
この仕組みのおかげで、セキュリティを守りつつ、インターネットの恩恵を受けることができるんですね。
—
2. 「ルートテーブル」は道案内をする看板
荷物がどうやって郵便局（NATゲートウェイ）に届くのか。それを決めているのがルートテーブルです。
これは道端に立っている「看板」だと思ってください。
「インターネット（0.0.0.0/0）に行きたい荷物は、あっちの郵便局（nat-xxxx）へ行け！」
という指示が書かれています。
ここに大きな落とし穴が！
ここで皆さんに知っておいてほしい「現場のリアル」があります。
実は、この看板（ルートテーブル）は、郵便局が火事で燃えていても、自動では書き換わらないのです。
AWSには「アベイラビリティゾーン（AZ）」という、物理的に離れたデータセンターの区画があります。もし、ある区画の郵便局が故障してしまったら……。看板は相変わらず「壊れた郵便局へ行け」と指し示し続け、荷物はどこにも届かず迷子になってしまいます。これが「AZ障害時の通信断」の正体です。
—
3. 障害に備える！複数NATゲートウェイの分散と限界
「じゃあ、複数の区画（AZ）に郵便局を立てればいいじゃないか！」
その通りです。それがベストプラクティスです。
通常、私たちはAZ-AとAZ-Cといった複数の場所に、それぞれ専用のNATゲートウェイを設置します。
- AZ-Aの看板： AZ-Aの郵便局へ行け。
- AZ-Cの看板： AZ-Cの郵便局へ行け。
こうすれば、片方の区画がダメになっても、もう片方は生き残ります。
しかし、自動で助け合うことはしない
ここが初学者が一番驚くポイントです。
「AZ-Aの郵便局が壊れたから、自動で隣のAZ-Cの郵便局を使おう！」という気の利いた機能は、標準のルートテーブルには備わっていません。
看板はあくまで固定。AZ-Aが全滅したら、AZ-Aにいるサーバーたちは外との通信が完全に途絶えてしまいます。これが「ルートテーブル自動切り替えの限界」です。
—
4. 解決策：AWS Lambdaを使った「自動書き換え」の魔法
「看板が自動で変わらないなら、誰かが書き換えればいいじゃない！」
その「誰か」の役割を果たすのが、AWS Lambda（ラムダ）というプログラムです。
郵便局（NATゲートウェイ）の健康状態を常にチェックし、もし「あ、ここの郵便局は動いていない！」と気づいたら、サッと看板を書き換えて、隣の町の郵便局を指すようにします。
実際の切り替えイメージ（Pythonコード例）
現場のエンジニアが使うような、ルートテーブルを書き換えるための簡単なプログラムのイメージを見てみましょう。
import boto3
# AWSのネットワーク機能を操作するための道具(クライアント)を準備
ec2 = boto3.client('ec2')
def lambda_handler(event, context):
# 1. 壊れてしまったルートテーブルのID
target_route_table_id = 'rtb-0123456789abcdef0'
# 2. 新しく使いたい（隣の町にある）正常なNATゲートウェイのID
backup_nat_gateway_id = 'nat-0987654321fedcba0'
try:
# 3. 看板（ルートテーブル）の情報を書き換える！
# 「外の世界(0.0.0.0/0)への道は、バックアップの方へ行け」と指示
ec2.replace_route(
RouteTableId=target_route_table_id,
DestinationCidrBlock='0.0.0.0/0',
NatGatewayId=backup_nat_gateway_id
)
print(f"成功：ルートテーブル {target_route_table_id} の行き先を {backup_nat_gateway_id} に変更しました！")
except Exception as e:
print(f"エラー：書き換えに失敗しました。理由は {e} です。")
raise eこの仕組みを動かすためのステップ
1. 監視： CloudWatchアラームなどで、NATゲートウェイの異常を検知します。
2. 発動： 異常を検知したら、上のLambdaを自動で実行します。
3. 復旧： Lambdaが看板（ルートテーブル）を書き換え、通信が隣のAZ経由で復活します。
—
5. まとめ：一歩ずつ「止まらないインフラ」へ
いかがでしたでしょうか？
- NATゲートウェイは、内から外への一方通行の郵便局。
- ルートテーブルは、行き先を指し示す看板。
- 標準機能では、障害時に看板は勝手に書き換わらない。
- Lambdaを使えば、ピンチの時に看板を書き換える「守護神」を作れる。
最初は難しく感じるかもしれませんが、パケットの一つひとつを「大切な荷物」だと思って追いかけていくと、ネットワークの仕組みがスッと頭に入ってくるはずです。
「自動でやってくれないなら、自分で仕組みを作る」。これがクラウドエンジニアの腕の見せ所であり、一番面白いところでもあります。
皆さんの構築するシステムが、どんな嵐（障害）にも負けず、荷物を届け続けられるようになることを応援しています！一歩ずつ、楽しみながら学んでいきましょうね。
コメント