こんにちは！クラウドの海を渡り歩くSREの視点から、今日は皆さんと一緒に「プライベートサブネットからのインターネット接続」という、避けては通れない重要テーマを紐解いていきたいと思います。
インフラエンジニアの第一歩として、必ずぶつかるのが「インターネットから隔離されたサーバーを、どうやって安全に外の世界へ繋ぐか？」という課題です。パッチを当てたり、ライブラリをインストールしたり……。そんな時、私たちの強い味方になるのが「NAT（Network Address Translation）」という仕組みです。
さあ、肩の力を抜いて、郵便配達のストーリーから始めてみましょう。
—
郵便配達でイメージする「NAT」の仕組み
皆さんが住んでいるマンション（プライベートサブネット）には、外からの訪問者は入れません。でも、マンションの住人である皆さんは、外の世界へ手紙（パケット）を出したいですよね。
しかし、マンションの各部屋には「部屋番号（プライベートIPアドレス）」しかありません。この住所をそのまま外の世界に晒すと、外の人から返事が書けなかったり、セキュリティ上のリスクになったりします。
そこで登場するのが「マンションの受付係（NATゲートウェイ）」です。
1. 送信： 住人（プライベートサブネットのサーバー）からの手紙を受け取る。
2. 変換： 受付係は、自分の名前（グローバルIPアドレス）で外に手紙を出し直す。
3. 返信： 外からの返事が戻ってきたら、誰宛の手紙だったかを確認して、正しい部屋の住人に渡す。
これがNATの正体です。では、この「受付係」をどう用意するか、2つの選択肢を見ていきましょう。
—
選択肢1：マネージド型の「NATゲートウェイ」
AWSで言えば NAT Gateway、GCPなら Cloud NAT がこれにあたります。
メリット：
- 手間いらず： クラウド事業者が勝手に面倒を見てくれます。スケーリング（忙しくなっても自動で対応）も勝手にしてくれるので、エンジニアは何もする必要がありません。
- 高可用性： 複数のサーバーが裏側で動いているので、壊れにくいです。
デメリット：
- コスト： 毎月の固定費と、通信量に応じた従量課金がかかります。
—
選択肢2：インスタンス型の「NATインスタンス」
自分でEC2などのサーバーを立てて、OSレベルでパケットを転送する設定（iptablesなど）を施す方法です。
メリット：
- コストが安い： 小さなインスタンスを使えば、マネージド型より安く済むことがあります。
- 柔軟性： 自分でコントロールできるため、特殊なルーティングが必要な場合には便利です。
デメリット：
- 管理が大変： OSのパッチ適用、監視、冗長化……すべて自分でやらなければなりません。
- 限界がある： 1台のサーバーには処理できるパケットの限界があり、通信量が増えるとボトルネックになります。
—
実践：冗長化（壊れない仕組み）を考える
「NATが壊れたら、インターネットに出られない！」という事態は、システムを止める致命傷になりかねません。
マネージド型の場合
マネージド型は、基本的にはそのままでも高い信頼性を持っています。冗長化したい場合は、各アベイラビリティゾーン（AZ）ごとにNATゲートウェイを配置するのが定石です。
# 例えば、AWS CLIでサブネットIDを指定してNATゲートウェイを作成するイメージ
aws ec2 create-nat-gateway \
--subnet-id subnet-0123456789abcdef0 \ # パブリックサブネットを指定
--allocation-id eipalloc-0123456789abcdef0 # 固定のグローバルIPを指定インスタンス型の場合（泥臭い戦い）
NATインスタンスを冗長化する場合、2台のインスタンスを立てて、片方が死んだらもう片方に切り替える「ヘルスチェック＋ルートテーブル書き換え」という仕組みを自分で組む必要があります。
現場での泥臭いTips：
- Keepalivedを使う： 仮想IP（VIP）を使って、メインが死んだらバックアップが即座に引き継ぐ構成です。
- CloudWatch Alarmと連携： NATインスタンスのCPU負荷やネットワークトラフィックを監視し、異常があればSNS経由でアラートを飛ばす、あるいはLambdaを動かして「ルートテーブルの向き先」を自動で書き換えるスクリプトを組むこともあります。
—
結局、どっちを選べばいいの？
結論から言うと、「特別な理由がない限り、マネージド型のNATゲートウェイを使うべき」です。
理由はシンプル。SREの格言に「管理コストは技術的負債である」という言葉があります。自分でNATインスタンスを構築・運用すると、OSの脆弱性対応や監視に膨大な時間を使います。その時間で、もっとビジネス価値のある機能開発をしたほうが、結果的に会社のためにも、自分自身のスキルアップのためにもなります。
ただし、大規模トラフィックでNATゲートウェイのコストが膨大になる場合や、ネットワークの特殊なプロトコルを通す必要がある場合は、NATインスタンスの出番です。
—
まとめ：一歩ずつ理解を深めよう
今回お伝えしたかったのは、以下の3点です。
1. NATは「インターネットとの仲介役」であること。
2. マネージド型は「安心をお金で買う」選択であり、現代のインフラ構築の標準であること。
3. インスタンス型は「運用努力が必要なDIY」であること。
ネットワークは目に見えないので最初は難しく感じるかもしれません。でも、パケットという名の「手紙」がどう運ばれているのかを想像するだけで、トラブルシューティングの景色は全く変わってきます。
何か問題が起きたときは、「パケットが今、どの通り道で迷子になっているのか？」を追いかけてみてくださいね。応援しています！
コメント