Transit Gatewayの共有とは

Resource Access Manager（RAM）を使用して、アカウント全体、またはAWS Organizationsの組織全体でVPCアタッチメントのTransit Gateway（TGW）を共有できます。RAMを有効にし、リソースを組織と共有する必要があります。

目的・やりたいこと

背景

  • 既にOrganizationsが有効化されており、アカウント移管に伴い、旧管理アカウント配下で既に有効化または統合されているサービスに影響がないかを調査したい
  • TGWが2つ、RAMの共有リソースとして共有プリンシパルを「組織」に指定して共有していることが判明
  • 管理アカウント切替え前に共有プリンシパルを「組織」から「アカウント」に変更することでアカウント移管に伴うサービス影響を抑える方法を検証したい

目的

管理アカウント変更時の影響を最小限に抑えつつ、リソース共有を安定的に運用するための設定変更を検証すること。具体的には以下を確認したい。

  • 同一のTGWにおいて、「アカウント」タイプ共有リソースと「組織」タイプ共有リソースが存在する場合でも正常に機能すること
  • 上記の状態から「組織」タイプの共有リソースを削除しても通信に影響がないこと

検証依頼内容

  • パターン1
  1. RAMにて共有プリンシパルを「組織」にしたTGWの共有リソースを作成
  2. 1.の共有リソースの設定変更で共有プリンシパルを「アカウント」に変更が可能か、また可能な場合に設定変更に伴って通信断が発生するか
  • パターン2
  1. RAMにて共有プリンシパルを「アカウント」にしたTGWの共有リソースを作成
  2. 1.とパターン1の共有リソースが共存する場合でもTGWが機能するか確認
  3. パターン1の共有リソースを削除した際に通信が継続していることを確認

対象者・ ユースケース

AWS Organizationsの管理アカウントを移行・切り替えたい場合

対象となる技術

  • Transit Gateway
  • Resource Access Manager

条件（導入にあたっての前提事項）

  • アカウント01でVPC、IGW、サブネット（10.0.0.0/24）、EC2、TGWとそのアタッチメント作成済み
  • アカウント02でVPC、サブネット（10.0.1.0/24）、EC2（10.0.1.9）作成済み
  • 両アカウント共にAWS Organizationsに所属

参考URL

Amazon VPC Transit Gateway を使用して Transit Gateway を操作する – Amazon VPC

概要図


図の上部のAWSアカウントをアカウント01、下部のAWSアカウントをアカウント02とします。
アカウント01のEC2からアカウント02のEC2にpingを打ち続けて通信断が発生するかどうかを見ます。

作業の流れ

事前作業

（アカウント01側での作業）
1．組織IDの確認
AWS Organizations > ダッシュボードで組織IDをメモ

2. リソース共有の作成
作成したTGWを選択した状態で[共有]タブ > リソース共有を作成

3. TGWの共有
以下のように設定

4. プリンシパルとして組織を設定
1.でメモした組織IDを貼り付け


このプリンシパルを[追加]してあとはデフォルトのまま設定し、TGWの共有は完了です。

5. サブネットにルートを追加
アカウント02サブネット（10.0.1.0/24）と通信できるよう、アカウント01のサブネットのルートに、TGWをネクストゲートウェイにしたルートを追加

（アカウント02側での作業）

1．TGWアタッチメントを作成
アカウント02でもTGWアタッチメントを作成。その際、TGW IDはアカウント01で共有してもらったTGWのIDを指定して関連付け

2．サブネットにルートを追加
アカウント02側でもアカウント01サブネット（10.0.0.0/24）と通信できるよう、アカウント02のサブネットのルートに、TGWをネクストゲートウェイにしたルートを追加

（アカウント01側での確認）

1．TGWアタッチメントの確認
アカウント01でTGWアタッチメントを表示すると、先ほどアカウント02で作成したTGWアタッチメントが表示（上の方）されているのがわかります。

TGWの[関連付け]タブでも確認

[ルート]タブでもアカウント02サブネット（10.0.1.0/24）へのルートが自動生成されています。

2. ping確認
アカウント01のEC2（10.0.0.12）にSSHログインし、この時点でアカウント02のEC2（10.0.1.9）にping疎通ができることを確認。このまま放置します。

[ec2-user@ip-10-0-0-12 ~]$ ping 10.0.1.9
PING 10.0.1.9 (10.0.1.9) 56(84) bytes of data.
64 bytes from 10.0.1.9: icmp_seq=1 ttl=126 time=5.33 ms
64 bytes from 10.0.1.9: icmp_seq=2 ttl=126 time=1.71 ms
64 bytes from 10.0.1.9: icmp_seq=3 ttl=126 time=1.27 ms
64 bytes from 10.0.1.9: icmp_seq=4 ttl=126 time=0.968 ms

検証手順

組織⇨アカウントへの切り替え

まずはTGWの共有プリンシパルを組織からアカウントに切り替える際に、アカウント01からアカウント02へのpingが瞬断するかどうかを検証します。

1. TGWの[共有]タブから、リソース共有ARNのリンクをクリック

2. [変更]

3. プリンシパルの変更
プリンシパルタイプをAWSアカウントにして、アカウント02のAWSアカウントIDを指定して[追加]

追加されたことを確認

4. AWSアカウント単位に切り替えたいので、組織の方を[選択解除]

最後に[リソース共有を更新]
ご覧のように組織の方のステータスは関連付けが解除されていることがわかります。

5. ping確認
（アカウント01側での確認）2.で行ったpingは、瞬断されることなく継続していました。

64 bytes from 10.0.1.9: icmp_seq=38 ttl=126 time=1.23 ms
64 bytes from 10.0.1.9: icmp_seq=39 ttl=126 time=1.19 ms
64 bytes from 10.0.1.9: icmp_seq=40 ttl=126 time=2.05 ms
64 bytes from 10.0.1.9: icmp_seq=41 ttl=126 time=1.09 ms
64 bytes from 10.0.1.9: icmp_seq=42 ttl=126 time=1.54 ms

これで組織⇨アカウントに切り替えても通信に影響しないことが確認できました！

アカウント⇨組織への切り替え

今度は逆に組織を追加してアカウントの方を選択解除します。

こちらもping継続でした！

追加検証

現状、顧客の環境には共有プリンシパルが「アカウント」のTGW共有リソースがないので、 設定変更ではなく、「組織」と「アカウント」両方のタイプのTGW共有リソースを共存させ、システム影響がないことが確認できたら、「組織」タイプの選択を解除する流れが安全かも？

ということで、一旦共存状態を作った後に、組織を選択解除する方法も検証してみました。

1. この共存状態で一旦[リソース共有を更新]します。

pingは相変わらず継続

2. 次に組織を選択解除

3. AWSアカウントだけになっていることを確認

これでも瞬断は発生しません。

64 bytes from 10.0.1.9: icmp_seq=65 ttl=126 time=1.19 ms
64 bytes from 10.0.1.9: icmp_seq=66 ttl=126 time=0.930 ms
64 bytes from 10.0.1.9: icmp_seq=67 ttl=126 time=1.01 ms
64 bytes from 10.0.1.9: icmp_seq=68 ttl=126 time=1.16 ms

オマケ（というか重大なオチ）

では最後に残ったこのアカウントプリンシパルも削除してしまえば、さすがにpingは遮断されるんじゃ？と思い、念のためそちらも確認してみました。
このようにプリンシパルには何もありません。

この状態で[リソース共有を更新]し、ping疎通画面を見ると・・！？

64 bytes from 10.0.1.9: icmp_seq=351 ttl=126 time=1.52 ms
64 bytes from 10.0.1.9: icmp_seq=352 ttl=126 time=1.34 ms
64 bytes from 10.0.1.9: icmp_seq=353 ttl=126 time=1.60 ms
64 bytes from 10.0.1.9: icmp_seq=354 ttl=126 time=1.43 ms

・・・通信できてしまっています！！？？
それもそのはず、（アカウント02側での作業）1. TGWアタッチメントを作成した時点で、TGWには以下の関連付けが自動生成されます。

  • アカウント02のTGWアタッチメント
  • アカウント02のVPC
  • アカウント02サブネットへのルート

そしてその後に仮にプリンシパルの関連付けを解除したとしても、上記の関連付けは自動では解除されないため、そのまま通信ができてしまうというわけです。完全に元に戻すには、上記の関連付けを手動で削除する必要があります。

 

実際にAWSドキュメントトランジットゲートウェイの共有解除にも、以下の記載があります。

共有所有者がトランジットゲートウェイの共有を解除する場合、次のルールが適用されます。

  • トランジットゲートウェイアタッチメントは、機能し続けます。
  • 共有アカウントでトランジットゲートウェイを示すことはできません。
  • トランジットゲートウェイの所有者および共有所有者は、トランジットゲートウェイアタッチメントを削除できます。

トランジットゲートウェイが別の AWS アカウントと共有されていない場合、またはトランジットゲートウェイが共有されている AWS アカウントが組織から削除された場合、トランジットゲートウェイ自体は影響を受けません。

「トランジットゲートウェイが別の AWS アカウントと共有されていない場合、トランジットゲートウェイ自体は影響を受けません。」とありますね！
つまり、今回のようにOrganizationsの管理アカウントをAからBに移行したいというような場合には、プリンシパル「組織A」を削除後にプリンシパル「組織B」を追加すればいいように思います。
ただお客さんからしてみれば半ば信じ難いことだと思うので、AWSアカウント数が少ないのであれば、保険のために一旦AWSアカウントをプリンシパルに追加するというワンクッションを置いてあげると安心できるように思います。
ただ、AWSアカウント数が多い場合は、全部のアカウントを追加するのは大変なので、このワンクッションは非現実的に思います。

所要時間

2時間

まとめ

  • TGWの共有プリンシパルを組織⇨アカウントに切り替えても通信断は起きない
  • 逆にTGWの共有プリンシパルをアカウント⇨組織に切り替えても通信断は起きない
  • そもそもTGWを共有した時点で生成されるアタッチメントやルート等の関連付けはそのまま残るため、共有プリンシパルが無くても通信断は起きない