Transit Gatewayでインターネットの出口を集約した際の思わぬ弊害とその対応（Blackholeルート）

ちゃだいん（@chazuke4649）です。

Transit Gatewayのルートテーブル設計にて意図しない点でハマったので、解決方法を添えて紹介します。

前提

構成図は以下となります。

概要

• Transit Gateway　をハブとしたマルチアカウントのネットワーク構成
• 登場するAWSアカウント
  • ネットワークアカウント： Transit Gateway をホストする。アウトバウンドのインターネット経路のためのVPCを配置する。
  • 共有サービスアカウント： 複数のワークロードのアプリケーションにて利用する共有サービスをホストする。
  • ワークロード本番/ステージ/開発アカウント: 業務アプリケーションや自社ウェブサービスをホストする。各環境単位でアカウントを分ける。

要件

• インターネットの出口は1つのVPCに集約したい
• 共有サービスには全てのワークロードアカウントがアクセスできるようにしたい
• ワークロードアカウントにて、各環境間の通信（例えば、開発<->本番など）はできないようにしたい

参考資料

ちょうどBlack Beltに登場する「Transit Gatewayで通信制限するRoute Domain」と「インターネットに抜けるOutbound Route Domain」を掛け合わせたような構成にしました。

Transit Gatewayで通信制限するRoute Domain

インターネットに抜けるOutbound Route Domain

画像引用元：[AWS Black Belt Online Seminar] AWS Transit Gateway

想定していたこと

上記Black Beltを読んでいただくとよりわかりやすいかと思いますが、今回要件の「ワークロードアカウントにて、各環境間の通信（例えば、開発<->本番など）はできないようにしたい」を実現するために、各環境アカウント単位で、TransitGateway(以降TGW)ルートテーブルを作成し、それらにおいて、通信させたくないルートを記載しないことによって通信できない状態を目指しました。例えば、ワークロード本番アカウントのTGWルートテーブルには、ステージや開発のルートは書きません。

ハマったこと

上記を構築し、検証として本番VPCにEC2インスタンスを立てて、そこからステージVPCに立てたEC2インスタンスにPingした時に、トラフィックが到達できないことを試してみました。

すると、不本意にもPingは通ってしまい、両者は互いに疎通可能な状態であることがわかりました。

原因

調査してみたところ、以下のような経路で到達可能であることが判明しました。

どうやら、一度ネットワークアカウントのパブリックサブネットに行ってから、そこで折り返すことで、ステージVPCに到達可能できる状態だったのです。

テストしてみないとわからないことだらけですね。こんな経路パターンいけるのかと驚きました。

解決方法

今回の構成の場合、TGWルートテーブルにBlackholeルートを追加することで、意図しないプライベートネットワーク宛の通信をドロップさせることができます。

TGWルートテーブルにて、ロンゲストマッチ（より具体的なルートが優先）によって、0.0.0.0/0よりも10.0.0.0/8 が優先され、結果ドロップするという形になります。

ルートに一致するトラフィックを破棄するトランジットゲートウェイルートテーブルでは、ブラックホールルートを作成できます。

トランジットゲートウェイの動作 - Amazon Virtual Private Cloud

終わりに

Blackholeルートをまともに活用したことありませんでしたが、今回役に立ちました。ルートテーブルにもBlackholeルートのように、ブラックリスト的条件が追加できるのはありがたいですね。同様の事象に悩まされた人の参考になれば幸いです。

それではこの辺で。ちゃだいん（@chazuke4649）でした。