この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
ちゃだいん（@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）でした。
4
