マネージドサービス部 佐竹です。
本ブログでは AWS Transit Gateway (TGW) を用いて複数 VPC の NAT Gateway を集約しているフルメッシュ*1の環境下において、「仲間外れ」の VPC の作成、つまり TGW による経路制御を実装する方法について詳細に記載します。
- はじめに
- 仲間外れの VPC を Transit Gateway Route Table で実装する方法
- 動作確認1
- Transit Gateway で Blackhole Route を記載する
- 動作確認2
- 動作確認3 Reachability Analyzer ではどうなるか
- まとめ
はじめに
前提は、NAT Gateway を集約した状態
先日、以下のブログで AWS Transit Gateway を用いた NAT Gateway の集約方法についてご紹介しました。
この時、「VPC A」「VPC B」「VPC C」を作成し、「VPC B」の NAT Gateway に全 VPC の IGW への経路を集約しました。
構成図では上図の通りです。この設計においては「VPC A」「VPC B」「VPC C」間はそれぞれフルメッシュでの交互接続を可能としました。
- 「VPC A」⇔「VPC B」同士の接続が可能
- 「VPC A」⇔「VPC C」同士の接続が可能
- 「VPC B」⇔「VPC C」同士の接続が可能
フルメッシュ状態の接続は TGW ルートテーブルの設定によって可能になっています。「VPC A」「VPC B」「VPC C」それぞれにアタッチされた TGW アタッチメントは全て同ルートテーブル「Route Table No.1」を参照しているためです。
ユーザ様からのご要望
このフルメッシュ状態の環境において「VPC C」だけセキュリティの観点から「仲間外れにしたい」という要件があったとします。つまり、以下の状態にしたいことになります。
- 「VPC A」⇔「VPC B」同士の接続が可能
- 「VPC A」⇔「VPC C」同士の接続は不可能
- 「VPC B」⇔「VPC C」同士の接続は不可能
しかしこの要件をそのまま実装すると、せっかく先に集約した NAT Gateway を「VPC C」にも単独で作る必要が出てしまいます。このため、以下の要件となりました。
- 「VPC A」⇔「VPC B」同士の接続が可能
- 「VPC A」⇔「VPC C」同士の接続は不可能
- 「VPC B」⇔「VPC C」同士の接続は不可能、ただし「VPC C」から「VPC B」の NAT Gateway へは接続が可能であること
今回はこの要件に合う Transit Gateway の設計例をご紹介したいと思います。
仲間外れの VPC を Transit Gateway Route Table で実装する方法
改めて要件です。上図の通り、「VPC C」だけを仲間外れにします。しかし「VPC B」にある NAT Gateway だけは利用可能である必要があります。
TGW Route Table を新規に作成する
現在、全ての TGW アタッチメント (Type VPC) に付与されている TGW Route Table は3つ全てで共通としてデフォルトのルートテーブルが設定されています。構成図では「Route Table No.1」となっているものです。
今回「VPC C」だけはこのルートを変更するため、TGW Route Table を新規に作成します。
「Transit gateway route tables」から「Create transit gateway route table」を押下すると上画面が表示されます。今回、新規の TGW Route Table の名前は「2. TGW Route VPC C」としました。TGW は共通で現在「VPC C」が接続されているものを選びます。
参考までに、「1. TGW Route Default」が現在利用しているデフォルトのものです。
また補足となりますが、手動で別途作成する TGW Route Table は以下の設定がどちらも「No」になっています。
- Default association route table :
No - Default propagation route table :
No
TGW Route Table のルートを追加する
NAT Gateway への行きの経路
先にご紹介したブログの通りですが、行きの経路で関係する箇所は4か所です。そのうち、TGW Route Table に関係があるのは上図の「②」の箇所で、TGW のルートテーブルに「0.0.0.0/0」を追加する必要があります。
ということでマネジメントコンソールにて「Create static route」を押下し、先ほど作成した TGW Route Table「2. TGW Route VPC C」へ Static route を追加していきます。
CIDR は 0.0.0.0/0 で、Type は Active とします。経路の向き先となる TGW アタッチメントは「VPC B」のアタッチメントを選択します。
上画像の通り、まずはデフォゲの追加が完了しました。
NAT Gateway からの戻りの経路
戻りの経路で関係する箇所は3か所です。そのうち、TGW Route Table に関係があるのは同様に上図の「②」の箇所です。これは既に「Route Table No.1」に記載されており、このまま利用できるため作業は不要となります。
ここまでの作業を構成図に反映すると「Route Table No.2」が追加された状態です。ただし現在この「Route Table No.2」はどのアタッチメントにも紐づいておらず、浮いている状態です。
作成した TGW Route Table を「VPC C」のアタッチメントに関連付ける
TGW Route Table を関連付ける機能が「Association」です。ただし1つのアタッチメントには1つの TGW Route Table のみが関連付け可能です。
もし複数のアタッチメントを関連付けしようとした場合は以下のエラーが発生します。
There was an error creating your transit gateway route table association.
Transit Gateway Attachment tgw-attach-00085832c8e94543f is already associated to a route table.
そのため、まずは「1. TGW Route Default」と「VPC C」のアタッチメントとの Association を削除します。
「1. TGW Route Default」 での Delete association
ここで関連付けを削除する対象を誤らないよう、VPC の ID で検索しておきます。今回「VPC C」は vpc-0e754f783fad5edff です。アタッチメントを選択した後に「Delete association」を押下します。
「Delete association?」の確認画面が出るので「Delete association」を押下して確定します。
Association の削除が完了すると、アタッチメントが消えて2つになります。
念のため、Route から「VPC C」の CIDR である「10.10.30.0/23」が消えていないか確認しておきます。この経路が消えてしまうと、「VPC B」の NAT Gateway から「VPC C」に「戻る」時の経路がなくなるためです。
「2. TGW Route VPC C」での Create association
次は「2. TGW Route VPC C」を選択した後「Associations」のタブから「Create association」を押下します。
「VPC C」のアタッチメントを選択した後「Create association」を押下して完了します。
ステータスが「Associated」になれば Association は完了です。
ここまでの作業を構成図に反映しました。先の図からは極わずかな変化ですが「VPC C」の TGW Route Table が No.2 になりました。
一旦、実装作業をここで完了とします。
現時点での TGW Route Table の解説
この状態の TGW Route Table を紐解いてみます。
「VPC A」⇔「VPC B」同士の接続が可能
「VPC A」⇔「VPC B」間はルートテーブルが「①」のままで、今回設定を変更していないため影響がありません。
「VPC A」⇔「VPC C」同士の接続は不可能
「VPC A」⇔「VPC C」間は、「VPC A」→「VPC C」は可能です。しかし「VPC C」にアタッチされた TGW Route Table が「VPC A」の戻りの経路を知らないため「VPC A」←「VPC C」が戻れず接続は失敗します。
「VPC B」⇔「VPC C」同士の接続は不可能、ただし「VPC C」から「VPC B」の NAT Gateway へは接続が可能であること
「VPC B」⇔「VPC C」間は、先ほどと同様に「VPC B」→「VPC C」は可能ですが、「VPC B」←「VPC C」が戻れず接続は失敗します。
肝心なインターネットへの接続ですが、NAT Gateway への経路は「VPC C」→「VPC B」の方向で行われます（※1）。
この場合、Route Table No.2の「0.0.0.0/0」とRoute Table No.1の「10.10.30.0/23」がそれぞれインターネットへの「行き」と「戻り」を確保してくれます。
ということで、このように経路を書くことで表題の件は実現できました。
動作確認1
上図の通りに EC2 インスタンスを構築し、動作確認を行います。
- 「VPC C」の EC2 インスタンスからインターネットへの Ping が可能なこと
- 「VPC A」の EC2 インスタンスから「VPC C」の EC2 インスタンスに Ping が到達しないこと
- 「VPC C」の EC2 インスタンスから「VPC A」の EC2 インスタンスに Ping が到達しないこと（逆方向）
以下、念のためリソースを一覧化しておきます。
| VPC | EC2 Instance Name | IP Address | Instance ID |
|---|---|---|---|
| VPC A | VPC A 1a Instance | 10.10.11.4 | i-0cb321d9cf05dd734 |
| VPC C | VPC C 1a Instance | 10.10.31.8 | i-0b0e851f42993c063 |
「VPC C」の EC2 インスタンスからインターネットへの Ping が可能なこと
「VPC C 1a Instance」から ping google.com は到達可能です。
「VPC A」の EC2 インスタンスから「VPC C」の EC2 インスタンスに Ping が到達しないこと
「VPC A 1a Instance」から ping 10.10.31.8 は到達不可能です。
「VPC C」の EC2 インスタンスから「VPC A」の EC2 インスタンスに Ping が到達しないこと（逆方向）
ここで予想外の挙動が発生します。予想に反して「VPC C 1a Instance」から ping 10.10.11.4 は到達可能でした。何故でしょうか？
これには Route Table No.2の「0.0.0.0/0」が影響しています。整理してみましょう。
| From | To | 行きの参照 | 戻りの参照 | Ping | Ping 到達可否の理由 |
|---|---|---|---|---|---|
| VPC A | VPC C | Route Table No.1 | Route Table No.2 | 到達不可能 | 戻りの経路が Route Table No.2 に記載されていない |
| VPC C | VPC A | Route Table No.2 | Route Table No.1 | 到達可能 | 行きも戻りも経路が存在しているため |
再掲ですが、以下の経路拡大図も合わせてご覧ください。
Route Table No.2の「0.0.0.0/0」が「VPC C」をも内包しているために、「VPC A」には戻れないものの、「VPC C」から出る場合には疎通が可能となってしまっています。先ほど「※1」と記載した箇所で考慮漏れがあったのです。
さて、困りました。この場合にどのように制御を行えばいいでしょうか？
というわけで、あまりにも長い前置きが終わり、やっと「本題」です。
Transit Gateway で Blackhole Route を記載する
Blackhole Route とは何か
Transit Gateway の静的ルートはデフォルトで「Active」ですが、上画像の通り「Blackhole」というもう1つのタイプが存在します。
マネジメントコンソールにおける Blackhole ルートの説明は「Blackhole routes indicate whether traffic matching the route is to be dropped.」となっている通りですが、ルートに一致するトラフィックを「ドロップ」してくれます。
ようは、TGW Route Table において Blackhole ルートを記載することで、特定のルートを落としてしまうことができます。ということで、今回の要件にマッチする機能となっています。
「Route Table No.2」に Blackhole Route を追加する
今回の要件がクリアできていないのは「Route Table No.2」の設定が正しくないためです。
このため、「Route Table No.2」に Blackhole Route を追加することで適切に要件に合うように改善します。
「Create static route」を押下し、先ほどと同様に Static Route を追加するのですが、ここで以下のことを鑑みて設計を行います。
「将来的に VPC がさらに TGW へ追加された場合の運用を加味し、可能な限り設定の変更がなく保守できること」です。
VPC 群にはクラス A のみが利用されることが事前にわかっているため、今回「10.0.0.0/8」を全て Blackhole と設定することとしました。「CIDR」にその通り記載を行い、「Blackhole」を選択し「Create static route」を押下します。
正しく経路が追加されました。
これを構成図に追記すると上画像の通りです。この状態で、再度以下3パターンの TGW Route Table の状態を解説します。
「VPC A」⇔「VPC B」同士の接続が可能
「VPC A」⇔「VPC B」間はルートテーブルが「①」のままで、今回設定を変更していないため影響がありません。
「VPC A」⇔「VPC C」同士の接続は不可能
「VPC A」⇔「VPC C」間は、From「VPC A」→「VPC C」は可能です。しかし「VPC C」にアタッチされた TGW Route Table で「VPC A」の戻りのトラフィックが Blackhole によってドロップされるため「VPC A」←「VPC C」が戻れず接続は失敗します。これは From 「VPC C」→「VPC A」でも同様です。
「VPC B」⇔「VPC C」同士の接続は不可能、ただし「VPC C」から「VPC B」の NAT Gateway へは接続が可能であること
「VPC B」⇔「VPC C」間は、同様にFrom「VPC B」→「VPC C」は可能ですが、「VPC B」←「VPC C」が Blackhole によってドロップされるため戻れず接続は失敗します。先ほどまでは From「VPC C」→「VPC B」が接続可能になっていましたが、 Blackhole によってドロップされるため行きの接続が失敗します。
NAT Gateway への経路は「VPC C」→「VPC B」の方向で行われますが、Blackhole によってドロップされる「10.0.0.0/8」以外の「0.0.0.0/0」にマッチする経路は問題なく疎通が可能となります。
合わせて先ほどのテーブルをアップデートしました。
| From | To | 行きの参照 | 戻りの参照 | Ping | Ping 到達可否の理由 |
|---|---|---|---|---|---|
| VPC A | VPC C | Route Table No.1 | Route Table No.2 | 到達不可能 | 戻りのトラフィックが Blackhole によってドロップされるため |
| VPC C | VPC A | Route Table No.2 | Route Table No.1 | 到達不可能 | 行きのトラフィックが Blackhole によってドロップされるため |
経路の拡大図も合わせてご覧ください。
動作確認2
改めて動作確認を行います。
先ほど利用した EC2インスタンスで改めて動作確認を行います。
- 「VPC C」の EC2 インスタンスからインターネットへの Ping が可能なこと
- 「VPC A」の EC2 インスタンスから「VPC C」の EC2 インスタンスに Ping が到達しないこと
- 「VPC C」の EC2 インスタンスから「VPC A」の EC2 インスタンスに Ping が到達しないこと（逆方向）
念のためリソースの一覧を再掲します。
| VPC | EC2 Instance Name | IP Address | Instance ID |
|---|---|---|---|
| VPC A | VPC A 1a Instance | 10.10.11.4 | i-0cb321d9cf05dd734 |
| VPC C | VPC C 1a Instance | 10.10.31.8 | i-0b0e851f42993c063 |
「VPC C」の EC2 インスタンスからインターネットへの Ping が可能なこと
「VPC C 1a Instance」から ping google.com は到達可能です。
「VPC A」の EC2 インスタンスから「VPC C」の EC2 インスタンスに Ping が到達しないこと
「VPC A 1a Instance」から ping 10.10.31.8 は到達不可能です。
「VPC C」の EC2 インスタンスから「VPC A」の EC2 インスタンスに Ping が到達しないこと（逆方向）
「VPC C 1a Instance」から ping 10.10.11.4 も到達不可能です。やっと要件通りの設定を完了することができました。
動作確認3 Reachability Analyzer ではどうなるか
最初にご紹介しましたブログ「AWS Transit Gateway を用いて NAT Gateway を集約し、コストを最適化するための経路設計」において、「Reachability Analyzer は"行き"の経路の論理的な到達可能性を表示する」という話をしました。
この仕様のため、今回の設定、つまり以下の状態であれば・・・
| From | To | 行きの参照 | 戻りの参照 | Ping | Ping 到達可否の理由 |
|---|---|---|---|---|---|
| VPC A | VPC C | Route Table No.1 | Route Table No.2 | 到達不可能 | 戻りのトラフィックが Blackhole によってドロップされるため |
| VPC C | VPC A | Route Table No.2 | Route Table No.1 | 到達不可能 | 行きのトラフィックが Blackhole によってドロップされるため |
行きが到達して戻りがドロップされる「VPC A」→「VPC C」は Reachability Analyzer では「Reachable」になるでしょう。
反対に、行きが到達しない「VPC C」→「VPC A」は「Not reachable」となるでしょう。これも確認しておきます。
「VPC A」の EC2 インスタンスから「VPC C」の EC2 インスタンス
上画像の設定通りに実施します。
結果は、想定の通り「Reachable」になりました。
「VPC C」の EC2 インスタンスから「VPC A」の EC2 インスタンス
こちらの結果も、想定の通り「Not reachable」になりました。
ということで、TGW を経由する場合に「行き」しか見てくれない Reachability Analyzer での動作確認は心許ないものがあります。
まとめ
本ブログでは、AWS Transit Gateway を用いて複数 VPC の NAT Gateway を集約しているフルメッシュの環境下において、「仲間外れ」の VPC を作成、つまり TGW Route Table による経路制御を Blackhole Route を用いて実装する方法について詳細に記載しました。
かなり長文となってしまいましたが、Transit Gateway で Blackhole Route を利用する必要のある具体的な例をご提示できたのではと思います。
本ブログが Blackhole Route の具体的な利用例や書き方をお探しの方に何か参考になれば幸いです。
関連するブログのご紹介
本ブログのさらなる続編で、ネットワーク集約設計ブログ第3弾となります。合わせてご覧ください。
では、またお会いしましょう。
*1:全ての VPC がお互いに疎通が可能な状態を言います
佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ
マネージドサービス部所属。AWS資格全冠。2010年1月からAWSを利用してきています。2021-2022 AWS Ambassadors/2023-2024 Japan AWS Top Engineers/2020-2024 All Certifications Engineers。AWSのコスト削減、最適化を得意としています。
