こんにちは！クラウドインフラの世界へようこそ。SREとして日々コンテナやネットワークと格闘している私ですが、初めてAWSのVPCやコンテナ（ECS/EKS）に触れたとき、「プライベートサブネットにあるはずのコンテナが、どうやって外のインターネット（外部API）と通信できているんだ…？」と頭を悩ませた記憶があります。
教科書を開くと「NATゲートウェイ」「ENI」「ルーティングテーブル」といった難しそうな用語が並んでいて、それだけでお腹いっぱいになってしまいますよね。
でも、大丈夫です！一歩ずつ理解していきましょう。今回は、コンテナ（AWS FargateやAmazon EKS）が、セキュリティの守られたプライベートな空間から、外の世界へお出かけする仕組みを、身近な「郵便配達」に例えて優しく紐解いていきますよ。
—
1. そもそも「プライベートサブネット」ってどんな場所？
まずは、私たちのコンテナたちが暮らす「お家」の場所を確認しましょう。
AWSの世界では、VPC（仮想的なプライベートクラウド）という大きな土地の中に、「サブネット」という区画を作ります。ここには大きく分けて2つのタイプがあります。
- パブリックサブネット（表通り）: インターネットと直接つながっている場所。郵便ポストが目の前にあり、外の世界と直接手紙のやり取りができます。
- プライベートサブネット（要塞の奥深く）: インターネットから直接は見えない、セキュリティでガチガチに守られた安全な場所。ここに、私たちの大切なECSタスクやEKSのポッド（コンテナ）が住んでいます。
「外と直接つながっていないなら、コンテナは外部のAPI（例えば、決済サービスや外部の天気予報APIなど）を呼び出せないのでは？」と思いますよね。その通り、何もしなければ外の世界とは断絶されています。
ここで登場するのが、今回の主役である「NATゲートウェイ（Network Address Translation Gateway）」です。
—
2. 例え話でスッキリ！「NATゲートウェイ」は敏腕の総務部
プライベートサブネットに住むコンテナくんが、外のインターネットにある外部APIへ「お肉の注文書（リクエスト）」を送りたいと想像してください。
でも、コンテナくんはパスポートを持っていません（パブリックIPアドレスを持っていないため、外の世界に出ていけないのです）。
そこで登場するのが、パブリックサブネットに陣取っている「NATゲートウェイ」です。会社組織に例えるなら、「海外とやり取りする敏腕の総務部（または私書箱の管理人）」のような存在です。
1. コンテナくんの願い: 「総務部さん、この注文書を外部のAPIサーバーに届けてきて！」
2. 総務部（NATゲートウェイ）の仕事:
- コンテナくんの代わりに、自分の名前（NATゲートウェイが持っているパブリックIPアドレス）を封筒の差出人に書き換えます。
- 「誰から預かったものか」を自分のメモ帳にしっかり記録しておきます（これをつなぎ目の管理、プロフェッショナルな言葉で「ポートフォワーディング」や「コネクション追跡」と呼びます）。
3. 外の世界へ: 封筒はインターネットの海を渡り、外部APIに届きます。
4. お返事が帰ってきたら: 外部APIは「NATゲートウェイさんから手紙が来たぞ」と返事を送ります。総務部（NATゲートウェイ）は、自分のメモ帳を見て、「あ、これはさっきのコンテナくん宛てだな」と気づき、中身をコンテナくんに渡してあげるのです。
この仕組みのおかげで、コンテナくん自身はパスポート（パブリックIP）を持たずに、安全な部屋から一歩も出ることなく、安全に外の世界と通信できるというわけです。
—
3. パケットが駆け抜けるリアルなフロー
では、もう少し技術寄りの目線で、このパケットがVPC内をどう駆け巡っているのかを覗いてみましょう。ECSやEKS（AWS VPC CNI）の環境では、次のようなバトンタッチが行われています。
1. コンテナの発信:
プライベートサブネット上のポッド（例: 10.0.1.50）が、外部API（例: 203.0.113.10）へ向けた通信（パケット）を発生させます。
2. ルーティングテーブルの案内役:
ポッドが属するサブネットのルーティングテーブルには、次のようなルールが書かれています。
- 「宛先が外の世界（
0.0.0.0/0）だったら、パブリックサブネットにあるnat-xxxxxxxx（NATゲートウェイ）へ投げること！」
3. NATゲートウェイでのアドレス変換（SNAT）:
パケットを受け取ったNATゲートウェイは、送信元IPアドレスを自分のパブリックIPアドレスに書き換えて、インターネットへ送り出します。
この一連の流れがあるからこそ、EKSのポッドやFargateのタスクは、Dockerイメージを外部のコンテナレジストリ（Docker HubやAmazon ECRなど）から安全に引っ張ってこられるのです。
—
4. 実務で役立つ設定とコード例
ここからは、実際にAWS上でこの環境を構築・確認するための設定例を見ていきましょう。インフラエンジニアとして現場で直面する設定のポイントをギュッと凝縮しました。
A. Terraformでのネットワーク構築スニペット
インフラをコードで管理するTerraformにおいて、プライベートサブネットからNATゲートウェイへルートを向ける設定は、AWSインフラの基本中の基本です。
# 1. パブリックサブネットにNATゲートウェイを配置するためのElastic IP（固定IP）
aws_eip "nat_gw_eip" {
domain = "vpc"
tags = {
Name = "my-nat-gateway-eip"
Note = "外部API通信のための固定パブリックIP"
}
}
# 2. NATゲートウェイ本体の作成（必ずパブリックサブネットに置きます！）
resource "aws_nat_gateway" "main" {
allocation_id = aws_eip.nat_gw_eip.id
subnet_id = aws_subnet.public_subnet.id # パブリックサブネットを指定
tags = {
Name = "my-app-nat-gateway"
}
}
# 3. プライベートサブネット用のルーティングテーブル
resource "aws_route_table" "private" {
vpc_id = aws_vpc.main.id
# 「外の世界（0.0.0.0/0）への通信は、すべてNATゲートウェイに任せる！」という設定
route {
cidr_block = "0.0.0.0/0"
nat_gateway_id = aws_nat_gateway.main.id
}
tags = {
Name = "my-private-route-table"
}
}
# 4. プライベートサブネットとルーティングテーブルの紐付け
resource "aws_route_table_association" "private_assoc" {
subnet_id = aws_subnet.private_subnet.id
route_id = aws_route_table.private.id
}B. トラブルシューティング：コンテナから外に出られないときの確認コマンド
「あれ？FargateやEKSのポッドから外部APIに繋がらない……」というインフラトラブルは現場でよく起きます。そんなとき、SREが最初に行う現実的なアプローチをPythonの簡単なスクリプトやcurlで確認してみましょう。
もしデバッグ用のコンテナを一時的にプライベートサブネット上で起動できるなら、次のようなコマンドで外への疎通を確認します。
# 外部のHTTPサーバーに対して、NATゲートウェイ経由で正しく通信できるかテストする
curl -v https://api.ipify.org?format=jsonもしこのコマンドを実行して、返ってきたIPアドレスが「NATゲートウェイに割り当てられたElastic IP」になっていれば、パケットは狙い通りにNATゲートウェイ経由で外の世界に飛び出している証拠です！逆にタイムアウトする場合は、前述の「ルーティングテーブルの設定漏れ」や「セキュリティグループのブロック」が疑われます。
—
まとめ
今回は、コンテナ環境（ECS/EKS）におけるプライベートサブネットとNATゲートウェイの役割について、郵便配達の例えを交えながら解説しました。
- プライベートサブネット: コンテナたちが安全に暮らす要塞の奥部屋。
- NATゲートウェイ: 外の世界と手紙をやり取りする、頼れる敏腕総務部。
- ルーティングテーブル: 「外に行くときは総務部を通ってね」という道案内。
この仕組みを頭の片隅に置いておくだけで、クラウドのネットワーク図を見たときの「難しそう……」という壁がスッと消えていくはずです。現場でのアーキテクチャ設計やトラブルシューティングに、ぜひこの知識を生かしてみてくださいね。
それでは、また次回のインフラ解説でお会いしましょう！
コメント