[アップデート]  AWS Transit Gateway を経由する通信の送信元をセキュリティグループIDで制御できるようになりました

[アップデート] AWS Transit Gateway を経由する通信の送信元をセキュリティグループIDで制御できるようになりました

取り合えず有効にしておきたいレベル
Clock Icon2024.10.01

Transit Gatewayを介した通信の許可にセキュリティグループIDを使いたい

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

皆さんはTransit Gatewayを介した通信の許可にセキュリティグループIDを使いたいなと思ったことはありますか? 私はあります。

以下記事のとおり、以前はTransit Gatewayを使用する場合、セキュリティグループにて通信の対向のセキュリティグループIDを用いたルールを用意しても、意図したとおり通信ができませんでした。

https://dev.classmethod.jp/articles/communication-cannot-be-controlled-by-security-group-id-when-connecting-between-vpcs-using-aws-transit-gateway/

そのため、もし使用している場合は、セキュリティグループIDではなく、CIDRブロックやプレフィックスリストを使って制御する必要がありました。

CIDRブロックが細かく分割されていると設定するルールの数が膨大になりそうです。

また、Auto ScalingのようにリソースのIPアドレスが動的に変動したり、固定化することができない場合は非常に苦労します。

Auto Scalingの場合、プライマリIPアドレスは指定したサブネットからランダムに選択されます。「サブネットの中の指定したCIDRから採番する」ということはできません。無理矢理IPアドレスの固定化に苦労している様子は以下記事をご覧ください。

https://dev.classmethod.jp/articles/autoscaling-ec2-instance-mapping-private-ip-address/

そのため、同じサブネット上に許可したいAuto Scalingするリソースと、そうでないリソースが混在しているような場合は、運用負荷を考えるとどうしても許可する必要がないリソースに対しても許可をせざるを得ません。

今回、アップデートによりTransit Gatewayを介した通信の許可にセキュリティグループIDを使えるようになりました。

https://aws.amazon.com/jp/about-aws/whats-new/2024/09/general-availability-security-group-referencing-aws-transit-gateway/

AWS Blogsにも投稿されています。

https://aws.amazon.com/jp/blogs/networking-and-content-delivery/introducing-security-group-referencing-for-aws-transit-gateway/

セキュリティグループIDを用いて制御できるようになることで、CIDRよりきめ細かい制御を行うことが可能になります。「役割ごとにセキュリティグループを付与して、送信先のセキュリティグループのインバウンドルールで制御する」ということもできるでしょう。

やったぁ。

実際に確認してみました。

いきなりまとめ

  • AWS Transit Gateway を経由する通信の送信元をセキュリティグループIDで制御するのはインバウンドルールでのみ対応可能
  • Transit Gatewayを経由する通信において、対向VPC上のセキュリティグループIDでインバウンドルールを制御するためには以下全てでセキュリティグループの参照が有効である必要がある
    • Transit Gateway
    • 送信元VPCのTransit Gateway attachment
    • 送信先VPCのTransit Gateway attachment
  • 設定するためにはTransit GatewayもしくはVPCのTransit Gateway attachment単位でセキュリティグループ参照を有効化する必要がある
    • オプションの有効無効はリソース作成後も可能
  • 追加料金は不要
  • クロスアカウントでも動作する
  • 2024/10/1時点での注意点は以下
    • アウトバウンドルールでの参照は不可
    • Transit Gatewayレベルでセキュリティグループ参照を無効にすると、すべてのVPCのTransit Gateway attachmentで無効になる
    • ローカルゾーンはすべてのローカルゾーンではなく、一部ローカルゾーンのみサポートされる
    • 別のAWSリージョンのセキュリティグループを参照することはできない
    • サードパーティのミドルボックスまたは BITM (Bump In The Wire) アプライアンス間では機能しない
    • Transit Gateway 上のマルチキャストではサポートされていない

やってみた

検証環境

検証環境は以下のとおりです。

[アップデート]  AWS Transit Gateway を経由する通信の送信元をセキュリティグループIDで制御できるようになりました検証環境構成図.png

VPCやEC2インスタンスは既に作成済みです。

Transit Gatewayの作成

まず、Transit Gatewayを作成します。

1.Transit Gatewayの作成.png

セキュリティグループ参照サポートというオプションが追加されていますね。

ここでセキュリティグループ参照サポートに関して説明しているAWS公式ドキュメントを眺めてみましょう。

Security group referencing

You can use this feature to simplify security group management and control of instance-to-instance traffic across VPCs that are attached to the same transit gateway. You can cross-reference security groups in inbound rules only. Outbound security rules do not support security group referencing. There are no additional costs associated with enabling or using security group referencing.

Security group referencing support can be configured for both transit gateways and transit gateway VPC attachments. Security group referencing will only work if it has been enabled for both a transit gateway and its VPC attachments.

Amazon VPC attachments in Amazon VPC Transit Gateways - Amazon VPC

こちらが今回のアップデートの「Transit Gatewayを介した通信の許可にセキュリティグループIDを使用する」に必要なオプションなようですね。

こちらの機能を使うためにはTransit Gatewayだけでなく、Transit Gateway attachmentでもこのオプションを有効にする必要があるようです。

有効化して作成します。

2.作成したTransit Gatewayの確認.png

Transit Gateway作成後のセキュリティグループ参照をの有効化/無効化

せっかくなのでリソース作成後にセキュリティグループ参照を無効化できるかも確認しましょう。

チェックがついているので無効化します。

3.既存のTransit Gatewayで変更することも可能.png

問題なく無効化できました。(スクリーンショットは割愛)

また、再度有効化することもできました。

セキュリティグループ参照を無効化する際は30秒程度、有効化する際は30秒ほどかかりました。

Transit Gateway attachmentの作成

Transit Gateway attachmentの作成を行います。

作成する際にセキュリティグループ参照を有効化するように設定しておきます。

4.Transit Gatewayアタッチメントの作成.png

作成後の状態を確認します。

5.Transit Gatewayアタッチメントの確認.png

有効になっていますね。

もう片方VPCのTransit Gateway attachmentも同様に作成します。

セキュリティグループ参照が有効な状態でEC2インスタンス間の通信

動作確認をします。

Transit Gateway route tableのルートは以下のとおりです。

6.Transit Gateway route table.png

また、セキュリティグループで互いのEC2インスタンスにアタッチされているセキュリティグループのIDを指定します。

test-1-ec2のセキュリティグループ

7.test-1-sg.png

test-2-ec2のセキュリティグループ

8.test-2-sg.png

現在、VPCピアリングまたはTransit Gatewayによって接続している対向のVPCから参照されているセキュリティグループを確認します。

$ aws ec2 describe-security-group-references --group-id sg-0eed6618f56d0626e
{
    "SecurityGroupReferenceSet": [
        {
            "GroupId": "sg-0eed6618f56d0626e",
            "ReferencingVpcId": "vpc-0db7fc1f6527ba933",
            "TransitGatewayId": "tgw-047704bdee529740c"
        }
    ]
}

$ aws ec2 describe-security-group-references --group-id sg-0d1b080a1f01a4828
{
    "SecurityGroupReferenceSet": [
        {
            "GroupId": "sg-0d1b080a1f01a4828",
            "ReferencingVpcId": "vpc-0b1c269d0bbf5d59d",
            "TransitGatewayId": "tgw-047704bdee529740c"
        }
    ]
}

Transit Gatewayを介して参照していることが分かりますね。これは期待大です。

それでは、お互いにpingを打ち合います。

test-1-ec2からtest-2-ec2へのping
$ ping -c 4 10.20.12.167
PING 10.20.12.167 (10.20.12.167) 56(84) bytes of data.
64 bytes from 10.20.12.167: icmp_seq=1 ttl=126 time=1.31 ms
64 bytes from 10.20.12.167: icmp_seq=2 ttl=126 time=0.573 ms
64 bytes from 10.20.12.167: icmp_seq=3 ttl=126 time=0.556 ms
64 bytes from 10.20.12.167: icmp_seq=4 ttl=126 time=0.552 ms

--- 10.20.12.167 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3062ms
rtt min/avg/max/mdev = 0.552/0.748/1.313/0.326 ms
test-2-ec2からtest-1-ec2へのping
$ ping -c 4 10.10.4.63
PING 10.10.4.63 (10.10.4.63) 56(84) bytes of data.
64 bytes from 10.10.4.63: icmp_seq=1 ttl=126 time=0.850 ms
64 bytes from 10.10.4.63: icmp_seq=2 ttl=126 time=0.478 ms
64 bytes from 10.10.4.63: icmp_seq=3 ttl=126 time=0.617 ms
64 bytes from 10.10.4.63: icmp_seq=4 ttl=126 time=0.489 ms

--- 10.10.4.63 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3119ms
rtt min/avg/max/mdev = 0.478/0.608/0.850/0.149 ms

どちらも通信できますね。感動です。

片方のTransit Gateway attachmentでセキュリティグループ参照を無効にした場合の挙動

片方のTransit Gateway attachmentでセキュリティグループ参照を無効にした場合の挙動も確認します。

test-2-vpcのTransit Gateway attachmentでセキュリティグループ参照を無効にしました。

9.Transit Gateway attachment2でセキュリティグループ参照を無効.png

この状態で互いにpingを打ち合います。

test-1-ec2からtest-2-ec2へのping
$ ping -c 4 10.20.12.167
PING 10.20.12.167 (10.20.12.167) 56(84) bytes of data.

--- 10.20.12.167 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3091ms
test-2-ec2からtest-1-ec2へのping
$ ping -c 4 10.10.4.63
PING 10.10.4.63 (10.10.4.63) 56(84) bytes of data.

--- 10.10.4.63 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3139ms

通信できなくなりましたね。

ec2 describe-security-group-referencesを叩いてみると、セキュリティグループの参照が解除されていました。

$ aws ec2 describe-security-group-references --group-id sg-0eed6618f56d0626e
{
    "SecurityGroupReferenceSet": []
}

$ aws ec2 describe-security-group-references --group-id sg-0d1b080a1f01a4828
{
    "SecurityGroupReferenceSet": []
}

どうやら、Transit Gatewayを経由する通信において、対向VPC上のセキュリティグループIDでインバウンドルールを制御するためには以下全てでセキュリティグループの参照が有効である必要があるようです。

  • Transit Gateway
  • 送信元VPCのTransit Gateway attachment
  • 送信先VPCのTransit Gateway attachment

セキュリティグループ参照が有効な状態でクロスアカウント通信

構成図

セキュリティグループ参照が有効な状態でクロスアカウント通信はできるのでしょうか。

最近では機能や環境、役割ごとにVPC、AWSアカウントを分割することが多いでしょう。そして、そのVPC間を繋げるのがTransit Gatewayの役割です。

もし、クロスアカウントでもセキュリティグループIDで制御できるのであれば大変ありがたいです。テンション爆発します。

実際に検証してみましょう。

構成図は以下のとおりです。

クロスアカウントの場合の構成図.png

Transit Gatewayの共有

Transit Gatewayを共有します。

共有はRAMを用いて行います。

設定内容は以下のとおりです。

10.Transit Gatewayの共有1.png
11.Transit Gatewayの共有2.png

対向のAWSアカウントでTransit Gatewayのリソース共有を承認します。

12.リソース共有を承認.png

承認されると、以下のような画面になります。

13.招待を承諾しました。共有リソースへのアクセスが可能になりました。.png

Transit Gateway attachmentの作成

tet-3-vpcのTransit Gateway attachmentを作成します。セキュリティグループ参照サポートは有効にします。

14.追加のTransit Gatewayアタッチメントの作成.png

作成後は以下のようになります。

15.追加のTransit Gatewayアタッチメントの作成が完了したことを確認.png

Transit Gatewayデフォルトルートテーブルへの関連付けおよびPropagationを有効にしているので、test-3-vpcへのルートも追加されています。

18.Transit Gateway route table.png

お互いのセキュリティグループのインバウンドルールでセキュリティグループIDを用いたルールを追加します。

test-1-ec2のセキュリティグループ

16.test-1-sg.png

test-3-ec2のセキュリティグループ

20.test-3-sg.png

参考までに各EC2インスタンスが存在しているサブネットのルートテーブルは以下のとおりです。

test-1-ec2のサブネットに紐づくルートテーブル

17.test-1-public.png

test-3-ec2のサブネットに紐づくルートテーブル

19.test-3-public.png

ec2 describe-security-group-referencesを叩いてみると、セキュリティグループの参照が設定されていました。これはできそうです。

AWSアカウントa
# test-1-ec2のセキュリティグループを参照している対向のVPC
$ aws ec2 describe-security-group-references --group-id sg-0eed6618f56d0626e
{
    "SecurityGroupReferenceSet": [
        {
            "GroupId": "sg-0eed6618f56d0626e",
            "ReferencingVpcId": "vpc-0e0d7974",
            "TransitGatewayId": "tgw-047704bdee529740c"
        }
    ]
}

# test-2-ec2のセキュリティグループを参照している対向のVPC
$ aws ec2 describe-security-group-references --group-id sg-0d1b080a1f01a4828
{
    "SecurityGroupReferenceSet": []
}
AWSアカウントb
# test-3-ec2のセキュリティグループを参照している対向のVPC
$  aws ec2 describe-security-group-references --group-id sg-6089c43d
{
    "SecurityGroupReferenceSet": [
        {
            "GroupId": "sg-6089c43d",
            "ReferencingVpcId": "vpc-0b1c269d0bbf5d59d",
            "TransitGatewayId": "tgw-047704bdee529740c"
        }
    ]
}

動作確認

それでは動作確認です。

お互いにpingを打ち合います。

test-3-ec2からtest-1-ec2へのping
$ hostname -i
172.31.3.35

$ ping -c 4 10.10.4.63
PING 10.10.4.63 (10.10.4.63) 56(84) bytes of data.
64 bytes from 10.10.4.63: icmp_seq=1 ttl=126 time=1.17 ms
64 bytes from 10.10.4.63: icmp_seq=2 ttl=126 time=1.27 ms
64 bytes from 10.10.4.63: icmp_seq=3 ttl=126 time=1.06 ms
64 bytes from 10.10.4.63: icmp_seq=4 ttl=126 time=0.924 ms

--- 10.10.4.63 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 0.924/1.104/1.269/0.128 ms
test-1-ec2からtest-3-ec2へのping
$ hostname -i
10.10.4.63

$ ping -c 4 172.31.3.35
PING 172.31.3.35 (172.31.3.35) 56(84) bytes of data.
64 bytes from 172.31.3.35: icmp_seq=1 ttl=126 time=1.16 ms
64 bytes from 172.31.3.35: icmp_seq=2 ttl=126 time=0.908 ms
64 bytes from 172.31.3.35: icmp_seq=3 ttl=126 time=0.919 ms
64 bytes from 172.31.3.35: icmp_seq=4 ttl=126 time=0.926 ms

--- 172.31.3.35 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3107ms
rtt min/avg/max/mdev = 0.908/0.978/1.162/0.105 ms

クロスアカウントでも問題なくできました。最高です。

取り合えず有効にしておきたいレベル

AWS Transit Gateway を経由する通信の送信元をセキュリティグループIDで制御できるようになったアップデートを紹介しました。

個人的にはTransit Gatewayを使用する際はとりあえず有効にしておきたいでレベルです。

対抗のセキュリティグループIDがわかっている必要がありますが、非常に柔軟にインバウンド通信を制御することができそうです。特にVPCピアリングを使っている環境からTransit Gatewayに切り替える時に大活躍しそうですね。

ただし、CIDRでの制御で十分な場合もあると思うので、規模や運用負荷を加味して、どちらが自分の環境に適しているか勘案すると良いでしょう。

設定するにあたってはいくつか注意点はあるので気をつけましょう。最も注意すべきなのはクロスリージョンには対応していないことでしょうか。

  1. As of this writing security group referencing isn’t supported with Outposts and some types of Local Zones. You must keep security group referencing flag disabled for VPCs extended in some types of Local Zones and Outposts to avoid service interruptions. Refer to the documentation for more information.
  2. As of this writing, you can’t reference security groups in a different AWS Region. To connect two VPCs, both VPCs must be attached to the same transit gateway and reside in the same Region.
  3. Security group referencing doesn’t work across third-party middle-box or bump-in-the-wire (BITM) appliances. Instance-to-instance traffic across a third-party middle-box or BITM appliance can’t be allowed using security group references.
  4. As of this writing security group referencing isn’t supported by multicast on Transit Gateway.
  5. As of this writing security group referencing isn’t supported for outbound security groups.

Introducing security group referencing for AWS Transit Gateway | Networking & Content Delivery

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

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

この記事をシェアする

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.