外部APIの「IP制限」を突破せよ！NATゲートウェイで送信元を固定するスマートな戦い方
こんにちは！SREの現場で日々ネットワークのトラブルと格闘しているエンジニアです。
皆さんはクラウド環境で開発していて、こんな壁にぶつかったことはありませんか？
「外部のSaaSや決済APIを使いたいけれど、向こうのセキュリティ要件が厳しくて『登録されたIPアドレスからしかアクセスを受け付けないよ』と言われてしまった……」
クラウドのサーバーは、オートスケーリングで増えたり減ったりするのが当たり前。そのたびにIPアドレスが変わってしまうと、外部サービス側では「誰だかわからないからお断り！」となってしまいますよね。
今回は、そんな困った事態を解決するヒーロー、「NATゲートウェイ」を使った「送信元IP固定」のアーキテクチャについて、身近な例えを交えながら解説していきます。
—
なぜクラウドのサーバーは「自分」を証明できないのか？
まず、クラウドのネットワーク事情を少し覗いてみましょう。
皆さんがAWSやGCPで立てたサーバー（インスタンス）は、通常「プライベートサブネット」という、インターネットからは直接見えない、ちょっと隠れた場所に住んでいます。
これ、例えるなら「高セキュリティなオフィスビルの奥にある個室」です。個室から外（インターネット）に手紙を出そうとしても、個室からは直接外のポストには行けませんよね。
そこで登場するのが「NATゲートウェイ」です。これは「オフィスの受付窓口」だと思ってください。
1. 社員（サーバー）が外に出したい手紙を、受付（NATゲートウェイ）に預ける。
2. 受付は、社員の代わりに宛先へ手紙を出す。
3. この時、外から見ると、手紙の差出人は「社員個人」ではなく「会社の代表アドレス（NATゲートウェイのパブリックIP）」として届く。
これがNATゲートウェイの仕組みです。これを使えば、どれだけ中のサーバーが増減しようが、外部からは「あの会社の受付窓口から来たんだな」と認識してもらえるわけです。
—
実際にどう設計するの？（AWSでの構成例）
NATゲートウェイを使った設計は、とてもシンプルです。
- プライベートサブネット: サーバーを配置する場所。ここにはパブリックIPを付けない（安全第一！）。
- パブリックサブネット: NATゲートウェイを配置する場所。ここには「Elastic IP（固定IP）」を割り当てる。
- ルートテーブルの設定: プライベートサブネットから「外への通信（
0.0.0.0/0）」が来たら、NATゲートウェイに転送するよう指示を出す。
これで、あなたのサーバーがどれだけ頑張ってアクセスしても、外部APIからは「いつも同じパブリックIP」として認識されるようになります。
—
実践！NATゲートウェイの構築ヒント
もしAWS CLIを使って構築するなら、このような流れで設定を行います（簡易的なイメージです）。
# 1. 弾力性のある固定IP（Elastic IP）を確保する
aws ec2 allocate-address --domain vpc
# 2. パブリックサブネットにNATゲートウェイを設置する
# (allocation-idには先ほど取得したIDを入れます)
aws ec2 create-nat-gateway --subnet-id subnet-xxxxxx --allocation-id eipalloc-xxxxxxxx
# 3. プライベートサブネットのルートテーブルを更新して、通信をNATへ流す
aws ec2 create-route --route-table-id rtb-xxxxxx --destination-cidr-block 0.0.0.0/0 --gateway-id nat-xxxxxxこの設定が終われば、サーバーからは curl コマンドなどでAPIを叩くだけ。向こう側のサーバーのログには、あなたが固定した Elastic IP がしっかりと記録されているはずです。
—
運用上の「ちょっとしたコツ」
ここで、現場のSREとして一つだけ大切なアドバイスを。
NATゲートウェイは「非常に便利な窓口」ですが、同時に「混雑する窓口」でもあります。
- コストに注意: NATゲートウェイは1時間単位で料金が発生します。また、データ処理量（GB単位）でも課金されるため、大量の通信を外部APIとやり取りする場合はコスト計算を忘れないようにしましょう。
- 可用性を考える: 大規模なシステムであれば、各AZ（アベイラビリティゾーン）ごとにNATゲートウェイを配置するのが鉄則です。一箇所が壊れても通信が止まらないようにするためですね。
—
まとめ：ネットワークは「整理整頓」が9割
パケットがどう飛ぶか、IPアドレスがどう変換されるか……最初は難しく感じるかもしれませんが、「内側のサーバーは隠しておき、外との接点は信頼できる窓口（NATゲートウェイ）に一本化する」という基本原則さえ押さえておけば、どんなに複雑なシステムでも怖くありません。
もし皆さんの現場で「IP制限で困った！」という声が聞こえたら、ぜひ自信を持って「NATゲートウェイで出口を固定しましょう」と提案してみてください。
ネットワークの仕組みを理解すると、インフラ構築がまるでパズルのように楽しくなってきますよ。それでは、また次回の記事でお会いしましょう！
コメント