はい、承知いたしました！メガクラウドとKubernetesネットワークに精通したSRE/クラウドアーキテクトとして、パケットがネットワークを駆け巡るリアルな挙動と、現場での泥臭いトラブルシューティングの経験に基づき、親しみやすく、かつ深い知見を盛り込んだ技術ブログ記事を執筆します。
以下に、ご提示いただいたテーマに沿ったブログ記事を作成しました。
—
郵便屋さんの大冒険！複数VPCを跨ぐインターネット接続の秘密 – NATゲートウェイ共有設計パターンを紐解く
皆さん、こんにちは！インフラの冒険へようこそ。今回は、クラウドの世界、特にAWS VPC（Virtual Private Cloud）のネットワーク設計における、ちょっとした「賢い工夫」についてお話しします。
「VPC Peering（ピーリング）って聞いたことあるけど、実際どう使うの？」「プライベートなリソースからどうやってインターネットに繋げるの？」そんな疑問をお持ちの、インフラやネットワークの扉を叩いたばかりのエンジニアの皆さん！安心してください。今日は、難しい専門用語に惑わされず、身近な例え話を交えながら、パケットたちがどうやって旅をするのか、一緒に学んでいきましょう！
そもそも、VPCって何？プライベートサブネットって？
まず、基本の「き」からおさらいしましょう。
VPC (Virtual Private Cloud) は、AWS上に構築される、あなただけの独立した仮想ネットワーク空間のこと。まるで、自分専用の「インターネット空間」を持っているようなイメージです。このVPCの中に、さらに小さなネットワークの区画を作るのが「サブネット」です。
- パブリックサブネット: インターネットと直接通信できる、いわば「表通り」に面した区画。
- プライベートサブネット: インターネットからは直接アクセスできない、セキュリティの高い「裏通り」や「隠れ家」のような区画。ここに、データベースやアプリケーションのサーバーなど、外部から直接触られたくない大切なリソースを置きます。
でも、ここで一つ疑問が生まれますよね？「プライベートサブネットにあるリソースは、インターネットにアクセスできないの？」
プライベートサブネットからインターネットへ、どうやって行くの？
確かに、プライベートサブネットは外部から直接アクセスできません。でも、例えば、サーバーのアップデートや、外部のAPIを利用するために、インターネットへの通信が必要になる場面はたくさんあります。
そんな時に活躍するのが NATゲートウェイ (Network Address Translation Gateway) です！
NATゲートウェイは、プライベートサブネットからインターネットへの通信を「仲介」してくれる、いわば「郵便局」のような存在です。
郵便配達員さんの大活躍！NATゲートウェイの役割
皆さんの身近な「郵便配達」に例えてみましょう。
1. プライベートサブネットの住人（サーバー）: あなたは、自宅（プライベートサブネット）から、友達に手紙（インターネットへの通信）を送りたいとします。
2. 自宅の住所（プライベートIPアドレス）: 自宅には「〇〇市△△町1-2-3」のような、内部でしか通用しない住所（プライベートIPアドレス）があります。
3. 郵便局（NATゲートウェイ）: このままでは、外部の人があなたの住所（プライベートIPアドレス）を知って、直接自宅に届けることはできません。そこで、手紙を「郵便局」（NATゲートウェイ）に持って行きます。
4. 郵便局の窓口（パブリックIPアドレス）: 郵便局は、あなたの自宅の住所（プライベートIPアドレス）を、郵便局自身の「〇〇県 県庁前郵便局」のような、外に通用する住所（パブリックIPアドレス）に書き換えてくれます。
5. インターネットへ出発！: 郵便局から、書き換えられた住所（パブリックIPアドレス）で、友達（インターネット上の宛先）に手紙が届けられます。
6. 返信も安心！: 友達からの返信も、一旦郵便局（NATゲートウェイ）に届きます。郵便局は、どの自宅（プライベートIPアドレス）からの手紙だったかを覚えてくれているので、ちゃんとあなた（プライベートサブネットのサーバー）に届けてくれるのです。
このように、NATゲートウェイは、プライベートIPアドレスをパブリックIPアドレスに変換（Network Address Translation）することで、プライベートなリソースが安全にインターネットと通信できるようにしてくれる、とっても重要な役割を担っています。
複数の「お城」をつなぐ、賢いネットワーク設計
さて、ここからが本題です。現代のクラウド環境では、一つのVPCだけではなく、複数のVPCを連携させて利用することが一般的になってきました。例えば、開発環境用VPC、本番環境用VPC、共有サービス用VPCなど、目的別にVPCを分けて、それぞれを VPC Peering で接続する「トランジットVPC」や「セントラルネットワーキングモデル」といった設計パターンがよく採用されます。
- VPC Peering: 異なるVPC同士を、あたかも同じネットワーク内にあるかのように直接通信できるようにする仕組みです。まるで、お城と別のお城の間を、秘密のトンネルで繋ぐようなイメージですね。
ここで、また新しい課題が浮上します。
「複数のVPCにあるプライベートサブネットのリソースから、インターネットに通信したいんだけど、それぞれのVPCにNATゲートウェイを置くのは、コストもかかるし、管理も大変そう…」
そこで登場するのが、今回ご紹介する 「複数VPC間ピーリング環境におけるNATゲートウェイの共有設計パターン」 です！
共有NATゲートウェイ：コストと管理を賢く最適化！
この設計パターンは、名前の通り、単一のVPCに設置したNATゲートウェイを、VPC Peeringで接続された他のVPCからも共有して利用するというものです。
まるで、大きな街（トランジットVPC）に一つだけ立派な郵便局（NATゲートウェイ）を建てて、そこから細い道（VPC Peering）を通って、周りの小さな村々（他のVPC）からも郵便が出せるようにするイメージです。
具体的な仕組みを見てみましょう
1. ハブとなるVPC（トランジットVPC）: ネットワークの中央に位置し、NATゲートウェイが配置されるVPCです。このVPCは、インターネットへの接続を持つように設定します。
2. スポークとなるVPC: 他のVPCで、インターネット通信が必要なプライベートサブネットを持つVPCです。
3. VPC Peering: ハブVPCとスポークVPC間は、VPC Peeringで接続されます。
4. ルーティング制御（ここがキモ！）: スポークVPCからインターネットへの通信は、ルーティングテーブルの設定によって、VPC Peering経由でハブVPCに送られ、そこでNATゲートウェイを経由してインターネットへ出ていきます。
どんなメリットがあるの？
- コスト削減: NATゲートウェイは、配置するだけで費用が発生するため、複数VPCにそれぞれ配置するよりも、単一のNATゲートウェイを共有する方がコストを抑えられます。
- 管理の簡素化: NATゲートウェイの設定や監視、アップデートなどを一元管理できるため、運用負荷が軽減されます。
- セキュリティの向上: インターネットとの接点を集約することで、セキュリティポリシーの適用や監視がしやすくなります。
設定のポイント：ルーティングテーブルを制する者がネットワークを制す！
この共有設計パターンを実現する上で、最も重要なのが ルーティングテーブルの設定 です。
ルーティングテーブルは、パケットが「次にどこへ向かえばいいか」を決定する、ネットワークの「案内板」のようなものです。
スポークVPCでは、「インターネット宛て（0.0.0.0/0）の通信は、VPC Peeringで接続されたハブVPCのネットワークインターフェース（ENI）へ送ってください」というルールを設定する必要があります。
設定例：AWS CLIを使ってみよう！
ここでは、AWS CLI（Command Line Interface）を使った設定例をいくつかご紹介します。もちろん、AWSマネジメントコンソールからでも設定できますが、CLIは自動化や再現性の観点から非常に便利です。
まず、ハブVPCとスポークVPC、そしてVPC Peeringが既に作成されていると仮定します。
1. ハブVPCのNATゲートウェイに、パブリックIPアドレスを関連付ける
# NATゲートウェイのIDを確認しておきます（例: nat-xxxxxxxxxxxxxxxxx）
aws ec2 describe-nat-gateways --region ap-northeast-1 --vpc-id vpc-xxxxxxxxxxxxxxxxx
# NATゲートウェイにElastic IPアドレスを関連付ける（もし未実施の場合）
# まずEIPを確保
aws ec2 allocate-address --domain vpc --region ap-northeast-1
# 取得したAllocationIdを使ってNATGWに関連付ける
aws ec2 associate-nat-gateway-address \
--nat-gateway-id nat-xxxxxxxxxxxxxxxxx \
--allocation-id eipalloc-yyyyyyyyyyyyyyyyy \
--region ap-northeast-1--nat-gateway-id: 共有したいNATゲートウェイのIDを指定します。--allocation-id: NATゲートウェイに紐付けるElastic IPアドレスのIDを指定します。
2. スポークVPCのルーティングテーブルを設定する
スポークVPC内の「プライベートサブネット」が紐づいているルーティングテーブルに、インターネット宛ての通信をハブVPCのVPC Peering接続へ向けるルートを追加します。
# スポークVPCのルーティングテーブルIDを確認します（例: rtb-zzzzzzzzzzzzzzzzz）
aws ec2 describe-route-tables --region ap-northeast-1 --filters "Name=vpc-id,Values=vpc-aaaaaaaaaaaaaaaaa"
# インターネット宛て (0.0.0.0/0) のルートを追加
# ターゲットは、VPC Peering接続のID（pcx-aaaaaaaaaaaaaaaaa）を指定します
aws ec2 create-route \
--route-table-id rtb-zzzzzzzzzzzzzzzzz \
--destination-cidr-block 0.0.0.0/0 \
--vpc-peering-connection-id pcx-aaaaaaaaaaaaaaaaa \
--region ap-northeast-1--route-table-id: インターネット通信を行うプライベートサブネットが属するルーティングテーブルのIDを指定します。--destination-cidr-block 0.0.0.0/0: 全てのインターネット宛ての通信を指します。--vpc-peering-connection-id: スポークVPCとハブVPCを接続しているVPC Peering接続のIDを指定します。
3. ハブVPCのルーティングテーブルも確認（通常はインターネットゲートウェイへ向いています）
ハブVPCには、インターネットゲートウェイ（IGW）がアタッチされているはずです。ハブVPCのメインルーティングテーブル（または、NATゲートウェイが配置されているパブリックサブネットが紐づくルーティングテーブル）には、インターネット宛ての通信がインターネットゲートウェイへ向かうルートが設定されていることを確認してください。
# ハブVPCのルーティングテーブルIDを確認します（例: rtb-wwwwwwwwwwwwwwwww）
aws ec2 describe-route-tables --region ap-northeast-1 --filters "Name=vpc-id,Values=vpc-xxxxxxxxxxxxxxxxx"
# インターネットゲートウェイへのルートが存在することを確認
aws ec2 describe-route-tables \
--route-table-id rtb-wwwwwwwwwwwwwwwww \
--region ap-northeast-1 \
--query "RouteTables[].Routes[]"このコマンドで、DestinationCidrBlock: "0.0.0.0/0" の Target が internet-gateway/igw-xxxxxxxxxxxxxxxxx のようになっていることを確認できればOKです。
注意点：意外とハマる？「ルート伝搬」と「セキュリティグループ」
- ルート伝搬 (Route Propagation): VPC Peeringでは、デフォルトではルート伝搬は有効になっていません。上記のように、手動でルートを追加する必要があります。ただし、VPC Peering接続自体でルート伝搬を有効にすると、ハブVPCのインターネットゲートウェイへのルートがスポークVPCのルーティングテーブルに自動で追加されるようになります。この機能を使うかどうかは、ネットワーク設計の方針によります。今回は手動で追加する例を挙げましたが、ルート伝搬の活用も検討してみてください。
- セキュリティグループとNACL: NATゲートウェイ自体もセキュリティグループやネットワークACL（NACL）の影響を受けます。通信がうまくいかない場合は、これらの設定も確認が必要です。特に、スポークVPCのプライベートサブネットからハブVPCのNATゲートウェイへ、そしてインターネットへ通信するためのアウトバウンドルールが許可されているかを確認しましょう。
まとめ：賢い設計で、クラウドをもっと便利に！
いかがでしたでしょうか？
今回は、複数VPC環境におけるNATゲートウェイの共有設計パターンについて、郵便配達員さんの冒険に例えながら、その仕組みと設定のポイントを解説しました。
この設計パターンを理解し、適切に設定することで、
- コストを抑えながら
- 管理の手間を減らし
- 安全に
複数のVPCにあるプライベートリソースからインターネット通信を実現できます。
クラウドネットワークの設計は、まさに「パケットの気持ちになる」こと。一つ一つの設定が、パケットの旅路をどう変えるのかを想像しながら進めることが、トラブルシューティングにも、より良い設計にも繋がります。
今日学んだ知識が、皆さんのインフラ構築の一助となれば幸いです。
もし「ここがもっと知りたい！」「こんなパターンもあるの？」といったご要望があれば、ぜひコメントで教えてくださいね！
それでは、また次回のインフラ探検でお会いしましょう！
—
コメント