東京リージョンに起動中の EC2 インスタンスを、Transit Gateway (ピアリング) を用いて異なるリージョンの NAT Gateway を経由してマネージドノードにしてみた
2025.07.03はじめに
テクニカルサポートの 片方 です。
今回は、東京リージョンに起動中の EC2 インスタンスを、異なるリージョンの NAT Gateway を経由 (アウトバウンド経路) してマネージドノードにしてみました。
クロスリージョンでの接続を実現するにあたり、Transit Gateway (ピアリング) を利用します。
やってみた
検証では、東京リージョンとバージニア北部リージョンを利用します。
マネージドノードとして登録させたい EC2 インスタンスは東京リージョンの VPC に起動させます。
東京リージョン側の設定 1
インターネットへのアウトバウンド経路が存在しない VPC と 2 つのサブネットを作成します。
IPv4 CIDR (10.10.0.0/26)
- private1
- private2 (EC2 インスタンス起動)
東京リージョン側で Transit Gateway を作成します。
ここでは、Amazon 側の自律システム番号 (ASN)のみ、64512-65534 または 4200000000-4294967294 の範囲でプライベート ASN を指定します。
その他の設定はデフォルトで作成します。
作成された Transit Gateway の ID はピアリング接続に必要なため、メモします。
続いて、Transit Gateway アタッチメントを作成します。
先ほど作成した Transit Gateway ID を選択し、アタッチメントタイプを "VPC" にします。
対象の VPC ID を選択後、Transit Gateway VPC アタッチメントを作成するサブネットを選択します。
EC2 インスタンスが起動しないサブネット (private1) を選択します。
その他設定はデフォルトで作成します。
バージニア北部側の設定 1
バージニア北部リージョンでは、東京リージョンに存在する VPC の CIDR が重複しないように、
パブリックサブネット 1 つと NAT Gateway を持つ プライベートサブネットを 1 つ作成します。
IPv4 CIDR (10.30.0.0/26)
- public1
- private1
Transit Gateway を作成します。
ここでは、Amazon 側の自律システム番号 (ASN)のみ、64512-65534 または 4200000000-4294967294 の範囲でプライベート ASN を指定しますが、東京リージョンで異なる番号を付与します。
その他の設定はデフォルトで作成します。
Transit Gateway アタッチメントを作成します。
先ほど作成した Transit Gateway ID を選択し、アタッチメントタイプを "VPC" にします。
対象の VPC ID を選択後、Transit Gateway VPC アタッチメントを作成するサブネット (private1) を選択します。
その他設定はデフォルトで作成します。
続いて、ピアリング接続用のアタッチメントを作成します。
先ほど作成した Transit Gateway ID を選択し、アタッチメントタイプを "Peering Connection" にします。
マイアカウントを選択し、東京リージョンにある Transit Gateway の ID を記載してから作成します。
作成が完了したら、続いては各リージョンでルートテーブルを設定します。
東京リージョン側の設定 2
EC2 インスタンスが起動中の private2 サブネットのルートテーブルのみ、以下のように編集します。
| 送信先 | ターゲット |
|---|---|
| 0.0.0.0/0 | tgw-xxxxxxxxxxxxxxx |
| 10.10.0.0/26 | local |
続いて Transit Gateway ルートテーブルで、静的ルートを作成します。
CIDR は 0.0.0.0/0 にして、タイプはアクティブを選択します。
アタッチメント選択では、Peering （ピアリングアタッチメント）を選択し、静的ルートを作成します。
最終的に以下が想定されます。
| CIDR | リソースタイプ | ルートタイプ |
|---|---|---|
| 10.10.0.0/26 | VPC | 伝達済み |
| 0.0.0.0/0 | Peering | 静的 |
バージニア北部側の設定 2
インターネットゲートウェイが存在する public1 サブネットのみ、以下のように編集します。
| 送信先 | ターゲット |
|---|---|
| 0.0.0.0/0 | igw-xxxxxxxxxxxxxxxx |
| 10.10.0.0/26 | tgw-xxxxxxxxxxxxx |
| 10.30.0.0/26 | local |
続いて Transit Gateway ルートテーブルで、静的ルートを作成します。
東京リージョン側での設定と異なる点に留意して、作成してください。
| CIDR | リソースタイプ | ルートタイプ |
|---|---|---|
| 10.30.0.0/26 | VPC | 伝達済み |
| 0.0.0.0/0 | VPC | 静的 |
| 10.10.0.0/26 | Peering | 静的 |
これで準備は完了です。こちらより東京リージョンの EC2 インスタンスから送信された Systems Manager サービス宛てのトラフィックが、バージニア北部の NAT ゲートウェイを含む VPC 宛てにルーティングされることが期待されます。
お疲れ様でした！
検証してみた
東京リージョンの private2 サブネットに SSM エージェントインストール済みであり、AmazonSSMManagedInstanceCore ロールをアタッチした EC2 インスタンスを起動させます。
検証で起動されたインスタンス ID は i-0edfea047cd74f8c6 です。
それでは、フリートマネージャーのマネジメントコンソール画面よりマネージドノードとして登録されているか確認します。
成功です！
もし、使用している EC2 インスタンスが、Systems Manager でマネージドインスタンスとして表示されない場合、以下をご参考ください。
まとめ
特定リージョンでのインターネット接続の集約なども含め、本ブログが誰かの参考になれば幸いです。
参考資料
- Amazon VPC Transit Gateway の Transit Gateway ピアリングアタッチメント - Amazon VPC
- Amazon VPC Transit Gateway を使用して Transit Gateway ルートテーブルにルートを追加する - Amazon VPC
- Amazon EC2 インスタンスが Systems Manager でマネージドインスタンスとして表示されない理由について | AWS re:Post
アノテーション株式会社について
アノテーション株式会社は、クラスメソッド社のグループ企業として「オペレーション・エクセレンス」を担える企業を目指してチャレンジを続けています。「らしく働く、らしく生きる」のスローガンを掲げ、様々な背景をもつ多様なメンバーが自由度の高い働き方を通してお客様へサービスを提供し続けてきました。現在当社では一緒に会社を盛り上げていただけるメンバーを募集中です。少しでもご興味あれば、アノテーション株式会社WEBサイトをご覧ください。
![[アップデート] Amazon QuickSight で SPICE データセットのサイズ制限がアップし 20 億行までサポートされるようになりました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-19e77b9a51519e08b94d0f688c125729/4f439c75e1ee56c70e315fa46fa45f81/amazon-quicksight)
