共有された Transit Gateway: AWS RAM でルートを所有するのは誰か

Transit Gateway を Resource Access Manager で共有すると、所有していないリソースに対して定義された一連のアタッチメント API を別のアカウントが呼び出せるようになるだけです。ゲートウェイ、そのルートテーブル、トラフィックの転送方法を決める権利は移りません。アタッチメントが受信側のコンソールに現れ、すぐに機能するため、所有権を得たように感じる人がいます。その下にある仕組みは共有リソースに対する許可の付与であり、子オブジェクトはすべて所有者のアカウント境界の内側に残ります。この分離が、共有トランジットに関するアクセス拒否チケットの大半を説明します。

共有が実際に委任するもの

リソース共有は、リソース、プリンシパル、管理された許可を指定します。許可はそのプリンシパルが実行できるアクションを列挙し、Transit Gateway の場合、その一覧は共有リソースに対するアタッチメント操作を対象にします。

一覧の外にあるものはコンソールではなく API で失敗するため、スクリプトを初めて実行したときにエラーが現れることがよくあります。

ルートテーブル、関連付け、伝播は所有者のもとに残る

転送は三つの子オブジェクト、つまりアタッチメントがどのルートテーブルに関連付けられているか、どのテーブルに伝播するか、それらのテーブルがどのルートを持つかで決まります。AWS の共有に関するドキュメントは、受信者が共有を通じてトランジットゲートウェイのルートテーブルやその関連付け、伝播を作成、変更、削除できないと述べています。それらの呼び出しは所有者アカウントに属します。新しい関連付けを必要とする受信者は、有効化を忘れた許可を行使しているのではなく、管理的な変更を求めています。

以下の表は、担当者が変わっても生き残るから、私が設計文書に載せている分担です。

中央の行を注意深く読んで、VPC の所有者はサブネットのルートを制御し、ゲートウェイの所有者は中央の転送判断を制御し、機能する経路には両方が必要だと確認してください。どちらのアカウントも単独では完了できません。

一つの経路、二つのアカウント

スポーク VPC からオンプレミスのプレフィックスまでパケットを追跡します。スポークのサブネットルートテーブルは、そのプレフィックスをトランジットゲートウェイのアタッチメントに送る必要があり、これは VPC の所有者が変更できます。次にゲートウェイは、アタッチメントの関連するテーブルに、VPN アタッチメントを指すルートを持つ必要があり、これは所有者だけが変更できます。戻りトラフィックには両方の鏡像が必要です。どちらかの側を外すと、半分だけ設定され、ファイアウォールの問題に見える経路になります。

両方の変更を二人の担当者付きの一つのチケットに書かないと、別々の週に完了します。

配置が重要なときはアベイラビリティゾーン ID を使う

ゾーン名はアカウント固有の別名です。あるアカウントの us-east-1a が、別のアカウントの us-east-1a と同じ物理ゾーンである保証はありません。設計で同じゾーンにアタッチメントとワークロードが必要な場合は、AZ ID を比較して記録してください。

名前を比較すると、正しく見える図と、正しくないレイテンシプロファイルが得られます。誰かが差を測定した後ではなく、図を描いている間に確認してください。

共有の解除はデータ経路を切断しない

共有を外すのは取り消しのように感じますが、即座のトラフィック停止ではありません。AWS は、ゲートウェイの共有が解除されてもアタッチメントが機能し続けると文書化しています。リソースを管理する許可は消えますが、既存のアタッチメントは誰かが削除または無効化するまで転送を続けます。共有を外し、次にアタッチメントを外し、二番目は所有者が行う二段階で取り消しを計画してください。

共有が唯一の制御なら、制御はありません。

共有の記録とルーティングの記録を一緒に保つ

二つの成果物は二つの異なる問いに答えます。共有の記録は、誰がリソースを扱えるかを示します。ルートテーブルは、どのネットワークが実際に通信できるかを示します。同じ所有者一覧と一緒に保存しないと、次のインシデントは決して問題ではなかった許可を証明することから始まります。

次に各方向のフローを一つずつ、到達できないままであるべきプレフィックスを一つテストしてください。