【入門編】 AWS Direct ConnectとNATゲートウェイの併用時におけるルーティング仕様 – クラウド＆コンテナネットワーク実践ガイド

はい、承知いたしました！AWS Direct ConnectとNATゲートウェイの併用時におけるルーティング仕様について、パケットが駆け巡るリアルな挙動を、郵便配達に例えながら、インフラやネットワークに初めて触れるエンジニアの皆さんにも分かりやすく解説するブログ記事を執筆します。難解な専門用語は極力避け、親しみやすいトーンで、現場で役立つ実践的な内容をお届けできるよう努めますね。

—

オンプレミスからAWSへ！Direct ConnectとNATゲートウェイでインターネットに繋ぐ、ちょっとした冒険（ルーティングの秘密を解き明かす！）

皆さん、こんにちは！AWSやGCPといったメガクラウド、そしてKubernetesのネットワークの世界を日々探求しているSRE/クラウドアーキテクトです。今回は、クラウドネットワークのちょっとした「なるほど！」を、皆さんと一緒に発見していきたいと思います。

「AWS Direct Connect」と「NATゲートウェイ」、この二つを組み合わせたときに、一体どんなことが起こるのか？特に、オンプレミスからDirect ConnectでAWSのプライベートサブネットに接続して、そこからNATゲートウェイ経由でインターネットへアクセスしたい！そんな時に、どうやってルーティングを設計すれば良いのか、そして「非対称ルーティング」なんていう、ちょっと怖い名前の落とし穴にハマらないためにはどうすればいいのか、じっくり紐解いていきましょう。

インフラやネットワークの世界に足を踏み入れたばかりの皆さん、大船に乗ったつもりで、このパケットの冒険に一緒に旅立ちましょう！

そもそも、Direct ConnectとNATゲートウェイって何者？

まずは、今回の主役である二つの技術を、身近なものに例えて、その役割を理解することから始めましょう。

AWS Direct Connect：あなた専用の「高速道路」

Imagine your on-premises data center is your home, and AWS is a big city with lots of important places (services). Normally, you’d send your mail (data) through the public internet, which is like using the regular roads. Sometimes, these roads get crowded, and your mail might take a while or get lost.

AWS Direct Connect is like building your own private, high-speed highway directly from your home to a specific spot in that big city. It bypasses the public internet, offering a more consistent, faster, and predictable connection. Think of it as a dedicated fiber optic cable running from your office to an AWS Direct Connect location. This is crucial for large data transfers or applications that demand low latency.

メリット:
高速・安定: インターネットの混雑に左右されず、いつも快適な通信速度を保てます。
低遅延: データが届くまでの時間が短く、リアルタイム性が求められるアプリケーションに最適です。
セキュリティ: 公衆インターネットを通らないため、より安全にデータをやり取りできます。

NATゲートウェイ：あなたの「秘密基地」への玄関

次に、NATゲートウェイです。これは、AWSのVPC（Virtual Private Cloud）という、あなたのプライベートなネットワーク空間の中に設置される、言わば「賢い門番」のようなものです。

皆さんがAWS上に構築するサーバー（EC2インスタンスなど）は、通常、インターネットから直接アクセスできない「プライベートサブネット」という、さらに内側にある安全な場所に配置されます。これは、自宅の「秘密基地」にいるようなイメージですね。

この秘密基地から、どうしても外の世界（インターネット）の情報を仕入れたい、あるいは外部のサービスと連携したい、という時があります。その時に活躍するのがNATゲートウェイです。

NATゲートウェイは、プライベートサブネットにいるサーバーの代わりに、インターネットと通信をしてくれる役割を担います。インターネットから見ると、通信の発信元は「NATゲートウェイ」という一つの窓口に見えるため、プライベートサブネットにいるサーバーのIPアドレスが直接インターネットに公開されることはありません。これは、秘密基地から外に連絡する際に、基地の住所ではなく、あらかじめ決めておいた「連絡用の電話番号」を使うようなイメージです。

メリット:
IPアドレスの節約: プライベートIPアドレスを持つインスタンスが、グローバルIPアドレスを直接持たなくてもインターネットにアクセスできるようになります。
セキュリティ向上: プライベートサブネット内のインスタンスが直接インターネットに公開されないため、セキュリティを高められます。
管理の容易さ: 多数のインスタンスのインターネット接続設定を、NATゲートウェイ一つで集約できます。

Direct ConnectとNATゲートウェイの組み合わせ：専用道路から秘密基地へ、そしてインターネットへ！

さて、この二つを組み合わせるとどうなるでしょう？

オンプレミス（あなたの会社や自宅のネットワーク）から、Direct Connectという専用道路を通って、AWSのVPCに到着します。そして、そのVPCの中にいる「プライベートサブネット」に、あなたのサーバー（EC2インスタンスなど）がひっそりと配置されています。

ここまでは、まるで「専用道路で街の入り口まで行き、そこから秘密基地へ向かう」ようなイメージです。

問題は、この秘密基地にいるサーバーが、インターネット上の情報を取得したい、あるいは外部のサービスと連携したい、という時です。Direct Connectは、あくまでオンプレミスとAWS VPC間の「入り口」までを高速化するものなので、VPCの中からインターネットへ直接出るための道は、別途考える必要があります。

そこで登場するのが、先ほど説明したNATゲートウェイです。プライベートサブネットにいるサーバーは、インターネットへのアクセスをNATゲートウェイに「お任せ」するのです。

しかし、ここでちょっとした「ルーティング」のパズルが出てきます。

ルーティングのパズル：パケットはどこへ行く？

パケット（データのかたまり）が、オンプレミスからAWSへ、そしてインターネットへと旅をするためには、各地点で「次にどこへ行けばいいか」という指示、つまり「ルーティング」が正しく設定されている必要があります。

1. オンプレミスからAWSプライベートサブネットへ（Direct Connect経由）

パケットの流れ: オンプレミス → Direct Connect → AWS VPC（Direct Connect接続ポイント） → プライベートサブネット内のEC2インスタンス
必要な設定:
オンプレミス側: Direct Connect経由でAWS VPCのCIDRブロック（IPアドレスの範囲）へのルートを、Direct Connectへ向ける設定。
AWS側（VPCルートテーブル）: Direct Connect接続ポイント（Direct Connect GatewayやVirtual Private Gateway）を宛先とするルート。

2. AWSプライベートサブネット内のEC2インスタンスからインターネットへ（NATゲートウェイ経由）

パケットの流れ: EC2インスタンス → プライベートサブネットのルートテーブル → NATゲートウェイ → インターネット
必要な設定:
AWS側（プライベートサブネットのルートテーブル）:
インターネット宛ての通信 (0.0.0.0/0) をNATゲートウェイに向けるルート。

ここまで聞くと、シンプルで分かりやすいですよね！でも、この「インターネット宛ての通信 (0.0.0.0/0) をNATゲートウェイに向ける」という設定が、実はちょっとした落とし穴を生むことがあります。

非対称ルーティングの恐怖：パケットが迷子になる！？

「非対称ルーティング」という言葉を聞くと、なんだか怖いですよね。でも、大丈夫、一つずつ見ていきましょう。

非対称ルーティングとは、簡単に言うと、「行きのパケットと帰りのパケットが、異なる経路を通ってしまうこと」です。

郵便配達に例えてみましょう。

1. 行き: あなたが友達に手紙を出すとします。郵便局（ルーター）は、その手紙を「Aのルート」で友達の家に届けました。
2. 帰り: 友達があなたに返事を書きました。しかし、友達の家の郵便局（ルーター）は、その返事を「Bのルート」であなたの家に送ってしまいました。

もし、「Aのルート」と「Bのルート」が全く違う道だったり、途中で「Bのルート」ではあなたの家まで届かないような場所を通ったりしたら、どうなるでしょうか？返信はあなたの元に届きませんよね。

ネットワークの世界でも、これと同じことが起こり得ます。

Direct Connect + NATゲートウェイで起こりうる非対称ルーティング

今回のケースで、非対称ルーティングが発生する典型的なシナリオは、以下のような場合です。

1. オンプレミスからAWSのEC2インスタンスへ通信する場合:

行き: オンプレミス → Direct Connect → AWS VPC → EC2インスタンス
帰り: EC2インスタンス → NATゲートウェイ → インターネット → （どこか別の経路） → Direct Connect → オンプレミス

あれ？おかしいですよね。EC2インスタンスからの「帰り」の通信が、本来Direct Connectでオンプレミスに帰ってくるのではなく、一旦インターネットに出て、そこからどこか別の経路でオンプレミスに戻ろうとしてしまっています。

なぜこんなことが起こるかというと、EC2インスタンスがインターネットにアクセスするために、プライベートサブネットのルートテーブルで 0.0.0.0/0 をNATゲートウェイに設定しているからです。この設定は、EC2インスタンスにとって「インターネットへの道はNATゲートウェイだけ」という認識になります。

そのため、オンプレミスからの通信に対する「返信」も、インターネット経由で返すのが「正しい」と判断してしまうのです。しかし、オンプレミス側で、AWS VPCへの通信をDirect Connectにルーティングしている場合、その返信はDirect Connectを通ってAWS VPCに戻ってこなければなりません。

この「行き」と「帰り」で、パケットが通る道が一致しない状態が、非対称ルーティングです。結果として、通信が確立できなかったり、不安定になったりする原因となります。

非対称ルーティングを回避する！正しいルーティング設計

では、この厄介な非対称ルーティングをどうやって避ければ良いのでしょうか？鍵となるのは、「VPCルートテーブル」と「オンプレミス側のルート設定」、そして「Direct Connectのルーティング属性」を、パケットの行き帰りが一致するように、きちんと設計することです。

基本的な考え方：パケットの「行き」と「帰り」を揃える

オンプレミス → AWS VPC → EC2インスタンス: これはDirect Connect経由で実現します。
EC2インスタンス → オンプレミス: これもDirect Connect経由で実現する必要があります。

NATゲートウェイは、あくまで「EC2インスタンスがインターネットへアクセスするため」にのみ使用し、オンプレミスへの返信経路には使わないようにします。

具体的な設定例（VPCルートテーブル）

プライベートサブネットのルートテーブルに、以下のような設定を考えます。

インターネット宛ての通信 (0.0.0.0/0): NATゲートウェイに向けます。これは、EC2インスタンスがインターネット上の情報を取得するために必要です。
オンプレミス側のCIDRブロック宛ての通信: Direct Connect Gateway (または Virtual Private Gateway) へ向けます。

VPCルートテーブルの設定例 (AWS CLI)

# NATゲートウェイへのルート設定
aws ec2 create-route \
    --route-table-id rt-xxxxxxxxxxxxxxxxx \ # ここにプライベートサブネットのルートテーブルIDを指定
    --destination-cidr-block 0.0.0.0/0 \
    --nat-gateway-id nat-gw-yyyyyyyyyyyyyyyyy # ここにNATゲートウェイIDを指定

# オンプレミスへのルート設定 (Direct Connect Gatewayを使用する場合)
aws ec2 create-route \
    --route-table-id rt-xxxxxxxxxxxxxxxxx \ # ここにプライベートサブネットのルートテーブルIDを指定
    --destination-cidr-block 192.168.0.0/16 \ # ここにオンプレミス側のCIDRブロックを指定
    --transit-gateway-id tgw-zzzzzzzzzzzzzzzzz # Transit Gatewayを使用する場合
    # または
    # --virtual-private-gateway-id vgw-aaaaaaaaaaaaaaaaa # Virtual Private Gatewayを使用する場合

【ポイント】

rt-xxxxxxxxxxxxxxxxx: あなたのVPCにある、プライベートサブネットに関連付けられたルートテーブルのIDに置き換えてください。
nat-gw-yyyyyyyyyyyyyyyyy: 作成したNATゲートウェイのIDに置き換えてください。
192.168.0.0/16: あなたのオンプレミスネットワークのCIDRブロックに合わせてください。
tgw-zzzzzzzzzzzzzzzzz または vgw-aaaaaaaaaaaaaaaaa: Direct Connect接続に使用しているTransit GatewayまたはVirtual Private GatewayのIDに置き換えてください。

オンプレミス側のルーティング設定例（概念）

オンプレミス側のルーターやファイアウォールでは、以下のような設定が必要です。

AWS VPCのCIDRブロックへの通信は、Direct Connectインターフェース（またはBGPピアリングされたルーター）へ向ける。

# 例: Cisco IOS風の設定
ip route <AWS VPC CIDRブロック> <サブネットマスク> <Direct ConnectインターフェースまたはネクストホップIP>

Direct Connect Gateway と Transit Gateway の活用

Direct Connect を利用する際、多くの場合、Transit Gateway を介してVPCと接続します。Transit Gateway を使うことで、複数のVPCやオンプレミスネットワークとの接続を、より柔軟かつ効率的に管理できるようになります。

Direct Connect Gateway: Direct Connect接続を、Transit Gatewayのようなハブに接続するためのリソースです。
Transit Gateway: 複数のVPCやオンプレミスネットワークを接続する、クラウドベースのルーターのようなものです。

この構成の場合、VPCルートテーブルでインターネット (0.0.0.0/0) をNATゲートウェイに向ける設定はそのままに、オンプレミスへの通信は、Direct Connect Gateway (または Transit Gateway) に向ける設定が重要になります。

まとめ：パケットの旅路を想像して、確実な設計を！

今日の冒険はいかがでしたでしょうか？

Direct ConnectでオンプレミスとAWSを繋ぎ、NATゲートウェイでプライベートサブネットのサーバーをインターネットに接続する。一見シンプルに見えますが、パケットがどこを通って、どこへ帰ってくるのかを正確に理解することが、非対称ルーティングという落とし穴を避けるための鍵となります。

インターネットへのアクセスは、NATゲートウェイに任せましょう。
オンプレミスへの返信は、Direct Connect経由で確実に返しましょう。

この二つを意識して、VPCルートテーブルとオンプレミス側のルーティング設定を、パケットの「行き」と「帰り」が一致するように設計することが大切です。

初めてのネットワーク設計は、まるで地図を片手に未知の土地を旅するようなものかもしれません。しかし、一つ一つの設定の意味を理解し、パケットの旅路を想像しながら進めば、必ず目的地にたどり着けます。

この記事が、皆さんのクラウドネットワーク構築の一助となれば幸いです。もし分からないことがあれば、いつでも立ち止まって、もう一度この旅路を思い出してみてくださいね！

それでは、また次の冒険でお会いしましょう！