- 概要
- Transit Gateway を作成する AWS アカウント での作業 (AWS アカウント A)
- Transit Gateway の共有を受ける AWS アカウント での作業 (AWS アカウント B)
- セキュリティグループ参照を試す
- 終わりに
- 余談
2024/10/9 記事を読み易いように全体的に文言や文章を改善しました。
概要
2024 年 9 月 25 日のアップデートで、Transit Gateway のセキュリティグループ参照が可能になりました。
公式ドキュメントは以下にあるようです。
詳細はこちらもお読みください。
以下は公式の紹介ブログです。
この記事では、次のことを確認します。
- AWSアカウントA: Transit Gatewayを作成するアカウント
- AWSアカウントB: Transit Gatewayの共有を受けるアカウント
これらの2つのアカウント間で、VPC 間の通信ができるかを検証します。
構成図
- シナリオ:
- AWS アカウント A にある EC2 インスタンスと、AWS アカウント B にある EC2 インスタンスが通信することを考えます。
- セキュリティグループの設定:
- AWS アカウント A の EC2 インスタンスのセキュリティグループのインバウンドルールに、AWS アカウント B の EC2 インスタンスのセキュリティグループ ID を指定できるようになっています。
- VPC Peering と Transit Gateway の違い:
- このようなセキュリティグループの ID 指定による通信は、以前は VPC Peering で可能でした。
- しかし、Transit Gateway ではこれができなかったという背景があります。
今回のアップデートで、異なるアカウント間での通信制御に関する柔軟性が向上しています。
要点
- 設定場所:
- 「セキュリティグループ参照サポート」は、Transit Gatewayとアタッチメントの両方で設定できます。
- 設定の優先順位:
- Transit Gatewayでこのサポートが無効になっていると、アタッチメントで有効に設定しても無効として扱われ、機能しません。
- アタッチメント間の通信:
- アタッチメント間で通信する場合、双方のアタッチメントでこのサポートを有効にする必要があります。
- ルールの対応:
- この機能はインバウンドルールにのみ対応しており、アウトバウンドルールでは使えません。
- リージョン間の通信制限:
- 異なるリージョン間の通信ではこの機能を使用できません。
- AWSマネジメントコンソールでの注意:
- セキュリティグループのIDを入力しても自動的に候補が表示されないため、IDは事前にメモしておく必要があります。
- セキュリティグループ削除時の注意:
- セキュリティグループを削除しても、そのグループを参照しているルールは自動で削除されないので、手動で削除する必要があります。
- 無効なセキュリティグループのルールを確認するために、CloudShellで以下のコマンドを実行し、削除対象を確認できます。
aws ec2 describe-stale-security-groups --vpc-id vpc-xxxx
- 設定の変更:
- この機能の有効・無効は、アタッチメント作成後にもいつでも変更可能です。
Transit Gateway を作成する AWS アカウント での作業 (AWS アカウント A)
Transit Gateway 作成 (AWS アカウント A)
Transit Gateway の作成時に「セキュリティグループ参照サポート」にチェックを入れるようになっています。
チェックを入れてみます。
作成後の画面です。
アタッチメント作成 (AWS アカウント A)
- VPCの作成:
- IPアドレスの範囲として「10.0.0.0/24」を割り当てました。
アタッチメントを作成します。この際にも「セキュリティグループ参照サポート」にチェックを入れる部分があります。
作成後の画面です。
また、「セキュリティグループ参照サポート」は、あとからいつでも有効または無効に変更できます。
EC2 作成 (AWS アカウント A)
VPC に EC2 を作成し、セキュリティグループを割り当てました。
sg-0d4400ac4ffc5319c (account-A-EC2)
EC2 は IP アドレス：10.0.0.6 になりました。
Transit Gateway の共有を受ける AWS アカウント での作業 (AWS アカウント B)
アタッチメント作成 (AWS アカウント B)
- VPCの作成:
- VPCを作成し、「192.168.1.0/24」のIPアドレス範囲を設定しました。
- Transit Gatewayの利用:
- Transit Gatewayを共有して、ネットワークをつなぐためのアタッチメントを作成しました。（具体的な手順は省略）
- 「セキュリティグループ参照サポート」の設定:
- アタッチメントを作成するときに、「セキュリティグループ参照サポート」を有効にするか選べます。
- 通常はこのオプションを有効にしますが、今回はAWSアカウントBであえて無効にしました。
- 無効にした理由:
- 「アタッチメント間で通信するには、両方のアタッチメントでこのサポートを有効にする必要がある」という情報を確かめるためです。
- 無効に設定して、通信がどう影響を受けるかを試してみたかったのです。
- ルートテーブルの設定:
- アカウントAでTransit Gatewayのルートテーブルを作成し、AとBのVPCが通信できるようにしました。（詳細は省略）
実験的に設定を無効にすることで、ネットワーク通信への影響を確認したかったということですね。
EC2 作成 (AWS アカウント B)
この VPC に EC2 を作成し、セキュリティグループを割り当てました。
sg-0a606c1a4b487cc04 (account-B)
EC2 は IP アドレス：192.168.1.10 になりました。
セキュリティグループ参照を試す
エラー系 1：Transit Gateway を作成した AWS アカウント A の EC2
- 目的: セキュリティグループでアカウント B の EC2 からアカウント A の EC2 への通信を許可した状態にして、通信を試験する。
手順:
- アカウント A の EC2 にセキュリティグループを設定します。
- そのセキュリティグループのルールで、アカウント B の EC2 からの全ての通信を許可します。
- 具体的には、アカウントBのEC2が所属するセキュリティグループ（ID:
sg-0a606c1a4b487cc04）からの通信を、アカウントAのEC2に対して許可する設定を行います。
- 具体的には、アカウントBのEC2が所属するセキュリティグループ（ID:
アカウントBで、アタッチメントの「セキュリティグループ参照サポート」を無効にしている状態で設定を試みたところ、エラーが発生しました。
一時的に、アカウントBのアタッチメントで「セキュリティグループ参照サポート」を有効にしました。この設定変更により、セキュリティグループを正常に保存できました。
その後、再びアタッチメントの「セキュリティグループ参照サポート」を「無効」に戻しました。このとき、セキュリティグループのルールに変化はありませんでした。
アカウントBのEC2からアカウントAのEC2へのpingは成功しませんでした。
考察:
- セキュリティグループのルールで許可をしていても、アカウントBのアタッチメントで「セキュリティグループ参照サポート」を無効にしていることが、通信が成功しない原因と考えられます。
エラー系 2 ：Transit Gateway の共有を受けた AWS アカウント B の EC2
- 目的: アカウント A の EC2 からアカウント B の EC2 への通信を許可すること。
手順:
- アカウント B の EC2 にセキュリティグループを設定します。
- そのセキュリティグループのルールで、アカウント A の EC2 からの全ての通信を許可します。
具体的には、アカウント A の EC2 が所属しているセキュリティグループ（ID:
sg-0d4400ac4ffc5319c）からの通信を、アカウント B の EC2 に対して許可する設定を行います。
セキュリティグループの設定時に、IDを直接入力する際の注意点です。
- セキュリティグループのID（例: sg-で始まるID）を入力する際に、自動補完（サジェスト）機能は働きません。
- そのため、設定を行う前に、必要なセキュリティグループのIDを事前にメモしておく必要があります。
アカウントBで、アタッチメントの「セキュリティグループ参照サポート」を無効にしている状態で設定を試みたところ、エラーが発生しました。
一時的に、アカウントBのアタッチメントで「セキュリティグループ参照サポート」を有効にしました。この設定変更により、セキュリティグループを正常に保存できました。
その後、再びアタッチメントの「セキュリティグループ参照サポート」を「無効」に戻しました。このとき、セキュリティグループのルールに変化はありませんでした。
アカウントBのEC2からアカウントAのEC2へのpingは成功しませんでした。
考察:
- セキュリティグループのルールで許可をしていても、アカウントBのアタッチメントで「セキュリティグループ参照サポート」を無効にしていることが、通信が成功しない原因と考えられます。
正常系
アカウント B で、アタッチメントの「セキュリティグループ参照サポート」を有効にしましょう。
アカウント A の EC2 から、アカウント B の EC2 への ping が通りました。
アカウント B の EC2 から、アカウント A の EC2 への ping が通りました。
「アタッチメント間で通信する場合、双方のアタッチメントでこのサポートを有効にする必要があります。」という部分は本当でした。
Transit Gateway で、「セキュリティグループ参照サポート」を無効にする。
アタッチメントではなくTransit Gateway で、「セキュリティグループ参照サポート」を無効にします。
設定した直後には ping も traceroute も通らなくなりました。
参照先のセキュリティグループを削除してみる
まず、アカウントAのセキュリティグループを削除しました。
しかし、アカウントAのセキュリティグループを参照しているアカウントBのセキュリティグループのルールは、削除後もそのまま残っています。
次に、アカウントBのCloudShellで以下のコマンドを実行して、削除されたセキュリティグループを参照しているルールを確認してみます。--vpc-idにはアカウントBのVPC IDを入力します。
aws ec2 describe-stale-security-groups --vpc-id <アカウント B の VPC ID>
このコマンドを実行することで、アカウントAのセキュリティグループが削除されていることが確認できました。
その後、対象のルールを削除しました。
ルールを削除した後に再度コマンドを実行すると、結果は空になりました。
ルールは残した状態で、「セキュリティグループ参照サポート」を無効にしてみる
「セキュリティグループ参照サポート」を無効にした状態で、ルールをそのままにしておきました。この状態は、以前に実施したエラーケース1、2 と同じです。 このとき、セキュリティグループを参照するルールはそのまま残っていました。
先ほどの aws ec2 describe-stale-security-groupsコマンドを使うと、参照しているセキュリティグループが削除された場合と同様に、古いルールとして検知されました。
終わりに
Transit Gatewayでも、セキュリティグループのルールにセキュリティグループのIDを指定できるようになりました。これは、同じセキュリティグループを共有する複数のノードがあり、それらが通信の送信元になる場合に特に便利です。ノードの数やIPアドレスが変わる場合には、この機能が非常に役立ちます。 Transit Gatewayがこの機能に対応したことで、VPC Peeringからの移行が進むケースもあるでしょう。ただし、アウトバウンドルールや異なるリージョンでは対応していないことに注意が必要です。また、サジェスト機能が働かない場合や、参照しているセキュリティグループを削除したときにルールが消えないことも、運用上の注意点です。
構成図を再掲します。
※ 執筆の都合上 ID を公開したものがあり、それらのリソースは削除しています。
Terraform
5.69.0 以降のバージョンで対応しています。
aws_ec2_transit_gateway リソースに、security_group_referencing_support 属性がありそうです。
aws_ec2_transit_gateway_vpc_attachment リソースに、security_group_referencing_support 属性がありそうです。
余談
おかげさまで多忙なので、土日だけで、南アルプスの仙塩尾根を歩いて（ほぼ走って）きました。
日帰りでも行けなくはないものの、塩見小屋で友人が働いていて、一泊しました。
１日目行程が、地蔵尾根で仙丈ヶ岳 (3033m) に登り、三峰岳 (2999m)、塩見岳 (3052m) と、3000m級の山を３つ超えるというものでした。
昼過ぎに小屋につき、行程について友人に話すと「信じられない・・」と少し引いていました。
登山でも、スピード感と安全・安心を両立させていこうと思います。
三峰岳 (2999m)からの景色がとても印象的で、久々に綺麗な景色を見て、生きた気持ちになれました。
南アルプスは最高です。
