Transit Gateway で伝播ルートと同じ宛先にブラックホールの静的ルートを作り、通信を確認してみた
はじめに
テクニカルサポートの 片方 です。
Transit Gateway のルートテーブルには、VPC アタッチメントの CIDR が伝播ルートとして入ります。同じ宛先に静的ルートを作ると、静的ルートが優先され、伝播ルートはルートテーブルに含まれなくなります。今回は、この静的ルートを「ブラックホールルート」にしたときの動きを確かめます。
ブラックホールルートとは
ブラックホールルートは、宛先に一致した通信を、どこにも送らずに捨てるルートです。Transit Gateway のルートテーブルでは、静的ルートを作るときに「ブラックホール」を選ぶと作れます。
ルートに一致するトラフィックを破棄する Transit Gateway ルートテーブルでは、ブラックホールルートを作成できます。
捨てられた通信は、送った側に「届かなかった」とは返りません。送った側から見ると、相手が応答しないまま時間切れになります。アタッチメントやセキュリティグループに手を入れずに、ルートを 1 つ足すだけで特定の宛先への通信を止められるので、一時的に通信を止めたいときや、通ってはいけない経路を塞ぎたいときに使えます。
確かめたこと
伝播ルートと同じ宛先にブラックホールの静的ルートを作ると、伝播ルートは AWS CLI でどう見えるのか。通信は何秒で止まり、静的ルートを削除すると何秒で戻るのか。Reachability Analyzer の結果には何が出るのか。これを確かめるため、2 つの VPC を Transit Gateway でつなぎ、片方の VPC から相手の VPC へ 2 秒ごとに HTTP でアクセスし続けながら、相手の CIDR へのブラックホールの静的ルートを作って削除しました。
構成
東京リージョンに、次のリソースを AWS CLI で作りました。送信元と宛先は、Amazon ECS のタスク（AWS Fargate）です。アクセスの結果は Amazon CloudWatch Logs に出します。
| リソース | 内容 |
|---|---|
| VPC app-vpc（10.10.0.0/16）、data-vpc（10.20.0.0/16） | 各 1 サブネット（ap-northeast-1a）、インターネットゲートウェイ（コンテナイメージの取得用） |
| Transit Gateway shared-hub-tgw | デフォルトルートテーブルへの関連付けと伝播を有効。VPC アタッチメントは app-vpc-attachment と data-vpc-attachment |
| VPC のルートテーブル | app-vpc に 10.20.0.0/16 → Transit Gateway、data-vpc に 10.10.0.0/16 → Transit Gateway |
| タスク data-http（data-vpc） | python -m http.server 8080 で HTTP サーバーを起動。セキュリティグループで 10.10.0.0/16 からの TCP 8080 を許可 |
| タスク app-probe（app-vpc） | data-http のプライベート IP に 2 秒ごとに HTTP でアクセスし、結果（ok か fail）を CloudWatch Logs に出す（タイムアウト 2 秒） |
| Reachability Analyzer のパス app-to-data-path | 送信元は app-probe のネットワークインターフェイス（ENI）、送信先は data-http の ENI、TCP 8080 |
app-probe のコンテナで実行したコードは次のとおりです。再試行はせず、1 回ずつの結果を記録します。
import time, urllib.request, datetime
url = 'http://10.20.1.174:8080/'
while True:
t = datetime.datetime.now(datetime.timezone.utc).strftime('%H:%M:%S')
try:
urllib.request.urlopen(url, timeout=2)
print(t, 'ok')
except Exception as e:
print(t, 'fail', type(e).__name__)
time.sleep(2)
先に結論から
- ブラックホールの静的ルート
10.20.0.0/16を作ると、search-transit-gateway-routesの結果から伝播ルートの10.20.0.0/16が消え、静的ルート（blackhole）だけになりました。静的ルートを削除すると、伝播ルートが再び表示されました。 - 2 秒ごとの HTTP アクセスは、ブラックホールルートの作成から 15〜17 秒後に止まり、削除から 12〜16 秒後に戻りました。
- Reachability Analyzer の結果は到達不可で、説明コードは
TGW_RTB_NO_ROUTE_TO_TGW_ATTACHMENTでした。ブラックホールであることは、結果には出ません。 - メトリクス
PacketDropCountBlackholeは合計 68 で、失敗したアクセス 34 回のちょうど 2 倍でした。
やってみた
今回は、次の流れで進めました。
- 伝播ルートだけの状態で、ルートテーブルと通信を確かめる
- 相手の VPC の CIDR に、ブラックホールの静的ルートを作る
- 通信が止まるまでの時間を測る
- Reachability Analyzer で分析する
- 静的ルートを削除して、通信が戻るまでの時間を測る
1. 伝播ルートだけの状態を確かめる
Transit Gateway のデフォルトルートテーブルには、2 つの VPC の CIDR が伝播ルートとして入っています。
| 宛先 | 種類 | 状態 | アタッチメントのリソース |
|---|---|---|---|
| 10.10.0.0/16 | propagated | active | app-vpc |
| 10.20.0.0/16 | propagated | active | data-vpc |
app-probe のログは 2 秒ごとに ok で、Reachability Analyzer の分析は到達可能（NetworkPathFound が true）でした。
2. ブラックホールの静的ルートを作る
10.20.0.0/16 に、ブラックホールの静的ルートを作りました。コンソールでは、「静的ルートの作成」で「ブラックホール」を選ぶ操作にあたります。
aws ec2 create-transit-gateway-route --transit-gateway-route-table-id tgw-rtb-0a92c98f910b0eadc --destination-cidr-block 10.20.0.0/16 --blackhole --query 'Route.[DestinationCidrBlock,Type,State]' --output text
通信が止まったことを確かめてから、search-transit-gateway-routes で、種類が static と propagated のルートを検索しました。伝播ルートの 10.20.0.0/16 は返らず、静的ルートだけになりました。
| 宛先 | 種類 | 状態 | アタッチメントのリソース |
|---|---|---|---|
| 10.10.0.0/16 | propagated | active | app-vpc |
| 10.20.0.0/16 | static | blackhole | なし |
静的ルートと伝播ルートの宛先が同じ場合は、静的ルートが優先され、伝播ルートはルートテーブルに含まれません（ドキュメントでは「伝達ルート」と表記されています）。
静的ルートと伝達ルートが同じ送信先を持つ場合、静的ルートの優先度が高くなるため、伝達されたルートはルートテーブルに含まれません。静的ルートを削除すると、重複する伝達ルートがルートテーブルに含まれます。
コンソールの Transit Gateway ルートテーブルでの表示は、今回は確かめていません。
3. 通信が止まるまでの時間を測る
次の画像は app-probe のログの要約です。各行の時刻を、ブラックホールルートの作成・削除からの経過秒数に置き換えています。作成から 15 秒後の ok を最後に、17 秒後から fail（URLError、2 秒のタイムアウト）になりました。通信が止まったのは、作成から 15〜17 秒後です。
4. Reachability Analyzer で分析する
ブラックホールルートがある状態で分析すると、到達不可でした。説明コードは TGW_RTB_NO_ROUTE_TO_TGW_ATTACHMENT で、対象は Transit Gateway ルートテーブルです。
この説明コードは、ルートテーブルにアタッチメントへのルートが無いことを示します。
This transit gateway route table has no route to this transit gateway attachment.
同じページには、宛先へのルートの状態が悪いことを示す TGW_RTB_BAD_STATE_ROUTE という説明コードもあります。ただ、今回の分析で出たのは TGW_RTB_NO_ROUTE_TO_TGW_ATTACHMENT の 1 つだけでした。
5. 静的ルートを削除して、戻るまでの時間を測る
静的ルートを削除すると、削除から 12 秒後に始めたアクセスの fail（2 秒後にタイムアウト）を最後に、16 秒後から ok に戻りました。止まるまでの時間と同じく、アクセスを始めた時刻で区切ると、通信が戻ったのは削除から 12〜16 秒後です。search-transit-gateway-routes の結果も、2 つの伝播ルートに戻りました。
| 宛先 | 種類 | 状態 | アタッチメントのリソース |
|---|---|---|---|
| 10.10.0.0/16 | propagated | active | app-vpc |
| 10.20.0.0/16 | propagated | active | data-vpc |
確認してみた
PacketDropCountBlackhole のメトリクス
Transit Gateway のメトリクス PacketDropCountBlackhole（1 分ごとの合計）は、ブラックホールルートの作成から通信が戻るまでの 4 分だけ増え、合計 68 でした。
失敗したアクセスは、タイムアウトの 2 秒と待ちの 2 秒で 4 秒ごとなので、1 分に 15 回です。これに対して、カウントは 1 分に 30 でした。失敗したアクセスは全部で 34 回で、合計の 68 はその 2 倍です。失敗 1 回あたり 2 になる理由は確かめていません（パケットは取っていません）。
止まるまで・戻るまでの時間について
15〜17 秒と 12〜16 秒は、2 秒ごとのアクセスを始めた時刻で区切った値で、試験は 1 回だけです。起点にした作成と削除の時刻は、API の応答の時刻ではなく、コマンドを実行した時刻です。ルートの変更が通信に反映されるまでの時間は、ドキュメントでは見つけられませんでした。
まとめ
伝播ルートと同じ宛先にブラックホールの静的ルートを入れると、CLI の検索結果から伝播ルートが消えました。とはいえ、伝播が外れたわけではなく、静的ルートが優先されているだけです。静的ルートを消せば、伝播ルートは何もしなくても戻ってきました。通信も、ルートを入れてから 15〜17 秒ほどで止まり、消してから 12〜16 秒ほどで戻っています。
少し注意したいのが、Reachability Analyzer の結果です。ブラックホールで止めているのに、説明コードは「ルートテーブルにアタッチメントへのルートが無い」という意味の TGW_RTB_NO_ROUTE_TO_TGW_ATTACHMENT でした。この説明コードだけを見ると、ルートの書き忘れや伝播の設定漏れを疑いたくなります。通信が届かない原因を切り分けるときは、伝播の設定と一緒に、ルートテーブルに同じ宛先のブラックホールの静的ルートが残っていないかも見ておくと、遠回りせずに済みます。
なお、ブラックホールではない静的ルート（別のアタッチメント向け）と、プレフィックスリスト参照ルートの場合は、今回は試していません。
本ブログが誰かの参考になれば幸いです。
参考資料
- AWS Transit Gateway の仕組み - Amazon VPC
- AWS Transit Gateway で静的ルートを作成する - Amazon VPC
- How Reachability Analyzer works - Amazon Virtual Private Cloud
- Reachability Analyzer explanation codes - Amazon Virtual Private Cloud
クラスメソッドオペレーションズ株式会社について
クラスメソッドグループのオペレーション企業です。
運用・保守開発・サポート・情シス・バックオフィスの専門チームが、IT・AIをフル活用した「しくみ」を通じて、お客様の業務代行から課題解決や高付加価値サービスまでを提供するエキスパート集団です。
当社は様々な職種でメンバーを募集しています。
「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、クラスメソッドオペレーションズ株式会社 コーポレートサイト をぜひご覧ください。※2026年1月 アノテーション㈱から社名変更しました
