Transit Gateway Attachment が関連付くサブネットを変更するときは通信断が発生するので注意しよう

Transit Gateway Attachment が関連付くサブネットを変えたいなぁ

こんにちは、のんピ(@non____97)です。

皆さんは「Transit Gateway Attachment が関連付くサブネットを変えたいなぁ」という現象に遭遇したことはありますか? 私はあります。

自称Transit Gatewayおじさんでも、ついうっかり配置先のサブネットを間違えることもあります。

今回はTransit Gateway Attachment が関連付くサブネットを変更したときの挙動や、変更時に通信断が発生するのかを確認します。

いきなりまとめ

• Transit Gateway Attachment が関連付くサブネットを変更するときは通信断が発生する
  • 通信断が発生するタイミングは2回
  • それぞれ20〜30秒程度通信が停止する
• サブネットを変更する際は、一時的に変更後のサブネットにENIが追加され、その後変更前のサブネットからENIが削除される挙動をする
• サブネットの変更完了がするまで2分程度かかる

検証の環境

今回の検証の構成図は以下の通りです。

上述の構成図のTransit Gateway ENIを以下のようにPrivate subnetからTransit Gateway subnetに変更します。

ちなみに構成図では省略していますが、VPC AのEC2インスタンスにSSMセッションマネージャーで接続するために、VPC AのPrivate subnet上に以下VPCエンドポイントを作成しています。

• com.amazonaws.us-east-1.ssm
• com.amazonaws.us-east-1.ssmmessages
• com.amazonaws.us-east-1.ec2messages

Transit Gateway Attachment が関連付くサブネットを変えてみた

変更作業前の環境確認

まず、変更作業前の環境確認をします。

VPC AのTransit Gateway Attachmentを確認すると、以下のサブネットに関連づいていることが確認できます。

• subnet-03bcb1259971596fb
• subnet-0c59af569c2816e87

こちらのサブネット IDを検索すると以下のように、VPC AのPrivate subnetのIDであることが分かります。

次に、VPC AのEC2インスタンスからVPC BのEC2インスタンスのIPアドレス(10.0.1.69)に対してpingを打ってみます。

結果を確認すると、全てのICMPパケットがVPC BのEC2インスタンスに到達したことを確認できます。

$ ping -D -c 10 -i 0.2 10.0.1.69
PING 10.0.1.69 (10.0.1.69) 56(84) bytes of data.
[1635572106.680196] 64 bytes from 10.0.1.69: icmp_seq=1 ttl=254 time=1.43 ms
[1635572106.880053] 64 bytes from 10.0.1.69: icmp_seq=2 ttl=254 time=0.561 ms
[1635572107.081939] 64 bytes from 10.0.1.69: icmp_seq=3 ttl=254 time=0.589 ms
[1635572107.285874] 64 bytes from 10.0.1.69: icmp_seq=4 ttl=254 time=0.535 ms
[1635572107.489894] 64 bytes from 10.0.1.69: icmp_seq=5 ttl=254 time=0.548 ms
[1635572107.693900] 64 bytes from 10.0.1.69: icmp_seq=6 ttl=254 time=0.552 ms
[1635572107.897876] 64 bytes from 10.0.1.69: icmp_seq=7 ttl=254 time=0.556 ms
[1635572108.102022] 64 bytes from 10.0.1.69: icmp_seq=8 ttl=254 time=0.607 ms
[1635572108.305894] 64 bytes from 10.0.1.69: icmp_seq=9 ttl=254 time=0.554 ms
[1635572108.509921] 64 bytes from 10.0.1.69: icmp_seq=10 ttl=254 time=0.574 ms

--- 10.0.1.69 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 1830ms
rtt min/avg/max/mdev = 0.535/0.650/1.433/0.263 ms

Transit Gateway Attachment が関連付くサブネットの変更

VPC AのEC2インスタンスと、VPC BのEC2インスタンスの疎通確認ができたため、Transit Gateway Attachment が関連付くサブネットの変更作業をしていきます。

方法としては、pingを200ms間隔で打ち続けている間に、Transit Gateway Attachment が関連付くサブネットを変えてみます。

コマンドは以下の通りです。UNIX時間ですがタイムスタンプを表示して、200ms間隔で、VPC BのEC2インスタンスのIPアドレス(10.0.1.69)に対してpingを打ち続けます。

$ ping -D -i 0.2 10.0.1.69
PING 10.0.1.69 (10.0.1.69) 56(84) bytes of data.
[1635572280.087174] 64 bytes from 10.0.1.69: icmp_seq=1 ttl=254 time=1.16 ms
[1635572280.287039] 64 bytes from 10.0.1.69: icmp_seq=2 ttl=254 time=0.586 ms
[1635572280.489990] 64 bytes from 10.0.1.69: icmp_seq=3 ttl=254 time=0.610 ms

pingを打ち続けている状態で、Transit Gateway Attachmentが関連付くサブネットを変更します。

VPC AのTransit Gateway Attachmentを選択して、アクション - Transit Gateway アタッチメントを変更をクリックします。

サブネット IDでAZ毎に変更先のサブネットを指定して、Transit Gateway アタッチメントを変更をクリックします。

変更後のTransit Gateway Attachmentのサブネット IDを確認すると、変更前は2つだったサブネットが4つのサブネットになっていることが確認できます。どうやらサブネットを変更する際は、一時的に変更後のサブネットにENIが追加され、その後変更前のサブネットからENIが削除されるような挙動になりそうですね。

変更直後のpingの様子はというと、通信断や遅延は発生していませんでした。しかし、サブネットを変更してから約30秒後に20秒程度の通信断が発生しました。

[1635572311.901858] 64 bytes from 10.0.1.69: icmp_seq=157 ttl=254 time=0.504 ms
[1635572312.105913] 64 bytes from 10.0.1.69: icmp_seq=158 ttl=254 time=0.558 ms
[1635572312.309924] 64 bytes from 10.0.1.69: icmp_seq=159 ttl=254 time=0.524 ms
[1635572312.513855] 64 bytes from 10.0.1.69: icmp_seq=160 ttl=254 time=0.541 ms
[1635572333.322698] 64 bytes from 10.0.1.69: icmp_seq=262 ttl=254 time=1.33 ms
[1635572333.522375] 64 bytes from 10.0.1.69: icmp_seq=263 ttl=254 time=0.409 ms
[1635572333.725799] 64 bytes from 10.0.1.69: icmp_seq=264 ttl=254 time=0.426 ms
[1635572333.929803] 64 bytes from 10.0.1.69: icmp_seq=265 ttl=254 time=0.461 ms

この時のVPC AのTransit Gateway Attachmentのサブネット IDを確認しましたが、変更直後と変わらず4つのサブネット IDが表示されていました。

変更してから2分程度経過すると、再度30秒ほどの通信断が発生しました。

[1635572364.317761] 64 bytes from 10.0.1.69: icmp_seq=414 ttl=254 time=0.424 ms
[1635572364.521728] 64 bytes from 10.0.1.69: icmp_seq=415 ttl=254 time=0.428 ms
[1635572364.725767] 64 bytes from 10.0.1.69: icmp_seq=416 ttl=254 time=0.428 ms
[1635572364.929782] 64 bytes from 10.0.1.69: icmp_seq=417 ttl=254 time=0.448 ms
[1635572393.897912] 64 bytes from 10.0.1.69: icmp_seq=559 ttl=254 time=0.588 ms
[1635572394.101751] 64 bytes from 10.0.1.69: icmp_seq=560 ttl=254 time=0.400 ms
[1635572394.305713] 64 bytes from 10.0.1.69: icmp_seq=561 ttl=254 time=0.367 ms
[1635572394.509816] 64 bytes from 10.0.1.69: icmp_seq=562 ttl=254 time=0.459 ms

この時のVPC AのTransit Gateway Attachmentのサブネット IDを確認すると、2つのサブネット IDが表示されていました。

こちらのサブネット IDを検索すると以下のように、VPC AのTransit Gateway subnetのIDであることが分かります。

無事、Transit Gateway Attachment が関連付くサブネット変更作業は完了ですね。

最後にpingをCtrl + Cで終了して統計情報を確認すると、約2分で40%ほどパケットロスしたことが分かります。

[1635572401.037823] 64 bytes from 10.0.1.69: icmp_seq=594 ttl=254 time=0.485 ms
[1635572401.241726] 64 bytes from 10.0.1.69: icmp_seq=595 ttl=254 time=0.378 ms
[1635572401.445749] 64 bytes from 10.0.1.69: icmp_seq=596 ttl=254 time=0.384 ms
[1635572401.649773] 64 bytes from 10.0.1.69: icmp_seq=597 ttl=254 time=0.408 ms
^C
--- 10.0.1.69 ping statistics ---
597 packets transmitted, 355 received, 40% packet loss, time 121563ms
rtt min/avg/max/mdev = 0.353/0.497/1.338/0.113 ms

Transit Gateway Attachment を関連付けるサブネットを間違えたら、ダウンタイムを考慮して変更作業をしよう

Transit Gateway Attachment が関連付くサブネットを変更するときは通信断が発生することを確認しました。

サブネット変更中のダウンタイムは1回目と2回目を合わせて50秒程度の通信断だったので、変更作業のインパクトはそれなりに大きいと考えます。変更作業をする際は、必ずダウンタイムを考慮して関係者に連絡をしてから作業をしましょう。

この記事が誰かの助けになれば幸いです。

以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!