Transit GatewayのアプライアンスモードはインスペクションVPCでのみ有効にするべき

Transit GatewayのアプライアンスモードはインスペクションVPCでのみ有効にするべき

取りあえずアプライアンスモードを有効化する といった運用は控えましょう
#AWS Transit Gateway
#Amazon VPC
#AWS
のんピ

のんピ

facebook logohatena logotwitter logo
Clock Icon2024.01.19

インスペクションVPC以外のTransit Gateway attachmentでアプライアンスモードを有効にした時の影響が気になる

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

皆さんはインスペクションVPC以外のTransit Gateway attachmentでアプライアンスモードを有効にした時の影響が気になったことはありますか? 私はあります。

Transit Gateway attachmentでアプライアンスモードを有効にすることで、リクエストとレスポンスの通信のルーティングを対照的にすることが可能になります。

https://dev.classmethod.jp/articles/enable-appliance-mode-when-using-transit-gatewayto-aggregate-communication-to-vpc-for-inspection/

便利ですね。

では、アプライアンスモードは全てのTransit Gateway attachmentで有効化しても良いものでしょうか。

答えは「No」です。インスペクションVPCのようにトラフィックを中継するVPCのTransit Gateway attachmentでのみ有効化するべきです。

以降、その理由について説明します。

いきなりまとめ

  • インスペクションVPCではないTransit Gateway attachmentでアプライアンスモードを有効化するべきではない
  • アプライアンスモードを有効化したTransit Gateway attachmentへ通信が流れる際は、送信元のAZとは関係なく、いずれかのAZのENIにルーティングされる
  • インスペクションVPCではないTransit Gateway attachmentでアプライアンスモードで有効化することによる懸念点は以下のとおり
    • AZを跨ぐことによる無駄なコストやレイテンシーが発生する

アプライアンスモードを有効にした場合の影響

ドキュメントを読んでみる

ドキュメントには以下のような記載があります。

アプライアンスモードが有効な場合、トランジットゲートウェイは、フローハッシュアルゴリズムを使用して、アプライアンス VPC 内の 1 つのネットワークインターフェイスを選択し、フローの有効期間中トラフィックを送信します。トランジットゲートウェイは、リターントラフィックに同じネットワークインターフェイスを使用します。これにより、双方向トラフィックは対称的にルーティングされます。つまり、フローの有効期間中、VPC アタッチメント内の同じアベイラビリティーゾーンを経由してルーティングされます。アーキテクチャ内に複数のトランジットゲートウェイがある場合、各トランジットゲートウェイは独自のセッションアフィニティを維持し、各トランジットゲートウェイは異なるネットワークインターフェイスを選択できます。

.
.
(中略)
.
.

アプライアンスモードが有効になっていない場合、トランジットゲートウェイは、送信元のアベイラビリティーゾーン内の VPC アタッチメント間でルーティングされたトラフィックが送信先に到達するまで維持しようとします。トラフィックは、アベイラビリティーゾーンに障害が発生した場合、またはそのアベイラビリティーゾーン内で VPC アタッチメントに関連付けられたサブネットがない場合にのみ、アタッチメント間でアベイラビリティーゾーンを通過します。

例: 共有サービス VPC のアプライアンス - Amazon VPC

アプライアンスモードを有効にすることでアプライアンスVPC(インスペクションVPCと同義)内のいずれかのAZのENIにルーティングされることが分かります。

また、以下のような記載もあります。インスペクションVPCに関わらない通信である場合の挙動については怪しいですね。

アプライアンスモードでのフロー維持が保証されるのは、インスペクション VPC に対する送信元トラフィックと宛先トラフィックのみです。

例: 共有サービス VPC のアプライアンス - Amazon VPC

動作確認

動作確認をしてみます。

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

Transit GatewayのアプライアンスモードはインスペクションVPCでのみ有効にするべき検証環境構成図

NAT Gatewayが存在するVPC BのTransit Gateway attachmentでアプライアンスモードを有効化します。

この状態でVPC AのEC2インスタンスからcheckip.amazonaws.comに対してアクセスして返ってきたIPアドレスを確認します。

検証環境はAWS CDKでデプロイしました。使用したリポジトリは以下です。

https://github.com/non-97/tgw-appliance-mode-nat-gateway

デプロイ後のNAT GatewayのAZ、EC2インスタンスのAZを確認します。

$ aws ec2 describe-nat-gateways \
  --query 'NatGateways[].{NatGatewayPublicIp : NatGatewayAddresses[].PublicIp, SubnetId : SubnetId}'
[
    {
        "NatGatewayPublicIp": [
            "3.231.80.221"
        ],
        "SubnetId": "subnet-0868b4b0b40794353"
    },
    {
        "NatGatewayPublicIp": [
            "18.210.168.215"
        ],
        "SubnetId": "subnet-0e1c483daade8d130"
    }
]

$ aws ec2 describe-subnets \
  --subnet-ids subnet-0868b4b0b40794353 subnet-0e1c483daade8d130 \
  --query 'Subnets[].{AvailabilityZone : AvailabilityZone, SubnetId : SubnetId}'
[
    {
        "AvailabilityZone": "us-east-1a",
        "SubnetId": "subnet-0868b4b0b40794353"
    },
    {
        "AvailabilityZone": "us-east-1b",
        "SubnetId": "subnet-0e1c483daade8d130"
    }
]

$ aws ec2 describe-instances \
  --instance-ids i-08fd74c7d70abe0f2 i-08b52b0d3707e1565 \
  --query 'Reservations[].Instances[].{InstanceId : InstanceId, AvailabilityZone : Placement.AvailabilityZone}'
[
    {
        "InstanceId": "i-08fd74c7d70abe0f2",
        "AvailabilityZone": "us-east-1a"
    },
    {
        "InstanceId": "i-08b52b0d3707e1565",
        "AvailabilityZone": "us-east-1b"
    }
]

まとめると以下のとおりです。

  • IPアドレス3.231.80.221 : us-east-1a
  • IPアドレス18.210.168.215 : us-east-1b
  • EC2 Instance A(i-08fd74c7d70abe0f2) : us-east-1a
  • EC2 Instance B(i-08b52b0d3707e1565) : us-east-1b

EC2 Instance AにSSMセッションマネージャーで接続して16回checkip.amazonaws.comにリクエストします。

$ for i in {0..15}; do
  curl http://checkip.amazonaws.com/
done
18.210.168.215
18.210.168.215
18.210.168.215
18.210.168.215
18.210.168.215
3.231.80.221
3.231.80.221
18.210.168.215
3.231.80.221
3.231.80.221
3.231.80.221
3.231.80.221
3.231.80.221
18.210.168.215
3.231.80.221
18.210.168.215

EC2 Instance Aと同じAZのNAT GatewayのグローバルIPアドレスは3.231.80.221です。しかし、実行結果から異なるAZである18.210.168.215のNAT Gatewayも通っていることが分かります。

EC2 Instance Bでも同様に16回checkip.amazonaws.comにリクエストします。

$ for i in {0..15}; do
  curl http://checkip.amazonaws.com/
done
18.210.168.215
18.210.168.215
18.210.168.215
3.231.80.221
18.210.168.215
18.210.168.215
3.231.80.221
18.210.168.215
3.231.80.221
18.210.168.215
3.231.80.221
18.210.168.215
18.210.168.215
3.231.80.221
3.231.80.221
3.231.80.221

こちらでも同様ですね。

確かにアプライアンスモードを有効化したTransit Gateway attachmentへ通信が流れる際は、送信元のAZとは関係なく、いずれかのAZのENIにルーティングされることが分かりました。

同じAZのNAT Gatewayにルーティングされれば発生しないAZを跨ぐコストやレイテンシーがかかってしまいますね。

Transit Gateway Flow Logsの確認

せっかくなので以下記事を参考にAthenaでTransit Gateway Flow Logsで出力したログを確認します。

https://dev.classmethod.jp/articles/cloudformation-supports-transit-gateway-flow-logs/

以下DDLでテーブルを定義します。

CREATE EXTERNAL TABLE `transit_gateway_flow_logs_partition_projection`(
  `version` int, 
  `resource_type` string, 
  `account_id` string, 
  `tgw_id` string, 
  `tgw_attachment_id` string, 
  `tgw_src_vpc_account_id` string, 
  `tgw_dst_vpc_account_id` string, 
  `tgw_src_vpc_id` string, 
  `tgw_dst_vpc_id` string, 
  `tgw_src_subnet_id` string, 
  `tgw_dst_subnet_id` string, 
  `tgw_src_eni` string, 
  `tgw_dst_eni` string, 
  `tgw_src_az_id` string, 
  `tgw_dst_az_id` string, 
  `tgw_pair_attachment_id` string, 
  `srcaddr` string, 
  `dstaddr` string, 
  `srcport` int, 
  `dstport` int, 
  `protocol` bigint, 
  `packets` bigint, 
  `bytes` bigint, 
  `start` bigint, 
  `end` bigint, 
  `log_status` string, 
  `type` string, 
  `packets_lost_no_route` bigint, 
  `packets_lost_blackhole` bigint, 
  `packets_lost_mtu_exceeded` bigint, 
  `packets_lost_ttl_expired` bigint, 
  `tcp_flags` int, 
  `region` string, 
  `flow_direction` string, 
  `pkt_src_aws_service` string, 
  `pkt_dst_aws_service` string
)
PARTITIONED BY (
  `aws_account_id` string,
  `aws_region` string,
  `datehour` string
)
ROW FORMAT DELIMITED
FIELDS TERMINATED BY ' '
LOCATION
  's3://<S3バケット名>/AWSLogs/'
TBLPROPERTIES (
  'projection.enabled'='true', 
  'has_encrypted_data'='true', 
  "skip.header.line.count"="1",
  'projection.aws_account_id.type'='enum', 
  'projection.aws_account_id.values'='<AWSアカウントID>', 
  'projection.aws_region.type'='enum', 
  'projection.aws_region.values'='us-east-1', 
  'projection.datehour.type'='date', 
  'projection.datehour.interval'='1',
  'projection.datehour.interval.unit'='HOURS',
  'projection.datehour.range'='NOW-1YEARS,NOW',
  'projection.datehour.format'='yyyy/MM/dd/HH', 
  'storage.location.template'='s3://<S3バケット名>/AWSLogs/${aws_account_id}/vpcflowlogs/${aws_region}/${datehour}'
)

テーブル定義後、送信元AZと送信先AZが異なる通信を確認します。

SELECT *
FROM 
  transit_gateway_flow_logs_partition_projection
WHERE
  aws_account_id='<AWSアカウントID>' and
  aws_region='us-east-1' and
  datehour='2024/01/16/02' and
  tgw_src_az_id <> tgw_dst_az_id
LIMIT 10

実行結果は以下のとおりです。

#	version	resource_type	account_id	tgw_id	tgw_attachment_id	tgw_src_vpc_account_id	tgw_dst_vpc_account_id	tgw_src_vpc_id	tgw_dst_vpc_id	tgw_src_subnet_id	tgw_dst_subnet_id	tgw_src_eni	tgw_dst_eni	tgw_src_az_id	tgw_dst_az_id	tgw_pair_attachment_id	srcaddr	dstaddr	srcport	dstport	protocol	packets	bytes	start	end	log_status	type	packets_lost_no_route	packets_lost_blackhole	packets_lost_mtu_exceeded	packets_lost_ttl_expired	tcp_flags	region	flow_direction	pkt_src_aws_service	pkt_dst_aws_service	aws_account_id	aws_region	datehour
1	6	TransitGateway	<AWSアカウントID>	tgw-0925eb88277e1762d	tgw-attach-0ddcc90bec74551b8	<AWSアカウントID>	<AWSアカウントID>	vpc-02f1c02c61a493dc3	vpc-0ddf513a02ddd7695	subnet-0fdb72baa777b74a7	subnet-0a2630b31c7ff62b3	eni-084ba370c45e3de77	eni-048b91cafedc00257	use1-az1	use1-az6	tgw-attach-066289c8fbd1beac6	10.1.1.46	52.46.143.242	50900	443	6	19	5527	1705373739	1705373759	OK	IPv4	0	0	0	0	27	us-east-1	egress	-	AMAZON	<AWSアカウントID>	us-east-1	2024/01/16/02
2	6	TransitGateway	<AWSアカウントID>	tgw-0925eb88277e1762d	tgw-attach-066289c8fbd1beac6	<AWSアカウントID>	<AWSアカウントID>	vpc-02f1c02c61a493dc3	vpc-0ddf513a02ddd7695	subnet-0fdb72baa777b74a7	subnet-0a2630b31c7ff62b3	eni-084ba370c45e3de77	eni-048b91cafedc00257	use1-az1	use1-az6	tgw-attach-0ddcc90bec74551b8	10.1.1.46	52.46.143.242	50900	443	6	19	5527	1705373739	1705373759	OK	IPv4	0	0	0	0	27	us-east-1	ingress	-	AMAZON	<AWSアカウントID>	us-east-1	2024/01/16/02
3	6	TransitGateway	<AWSアカウントID>	tgw-0925eb88277e1762d	tgw-attach-0ddcc90bec74551b8	<AWSアカウントID>	<AWSアカウントID>	vpc-02f1c02c61a493dc3	vpc-0ddf513a02ddd7695	subnet-0fdb72baa777b74a7	subnet-0a2630b31c7ff62b3	eni-084ba370c45e3de77	eni-048b91cafedc00257	use1-az1	use1-az6	tgw-attach-066289c8fbd1beac6	10.1.1.46	52.46.143.242	57890	443	6	22	5647	1705373708	1705373754	OK	IPv4	0	0	0	0	31	us-east-1	egress	-	AMAZON	<AWSアカウントID>	us-east-1	2024/01/16/02
4	6	TransitGateway	<AWSアカウントID>	tgw-0925eb88277e1762d	tgw-attach-0ddcc90bec74551b8	<AWSアカウントID>	<AWSアカウントID>	vpc-02f1c02c61a493dc3	vpc-0ddf513a02ddd7695	subnet-0fdb72baa777b74a7	subnet-0a2630b31c7ff62b3	eni-084ba370c45e3de77	eni-048b91cafedc00257	use1-az1	use1-az6	tgw-attach-066289c8fbd1beac6	10.1.1.27	209.54.183.5	47150	443	6	4	160	1705373708	1705373754	OK	IPv4	0	0	0	0	16	us-east-1	egress	-	AMAZON	<AWSアカウントID>	us-east-1	2024/01/16/02
5	6	TransitGateway	<AWSアカウントID>	tgw-0925eb88277e1762d	tgw-attach-066289c8fbd1beac6	<AWSアカウントID>	<AWSアカウントID>	vpc-02f1c02c61a493dc3	vpc-0ddf513a02ddd7695	subnet-0fdb72baa777b74a7	subnet-0a2630b31c7ff62b3	eni-084ba370c45e3de77	eni-048b91cafedc00257	use1-az1	use1-az6	tgw-attach-0ddcc90bec74551b8	10.1.1.46	52.46.143.242	57890	443	6	22	5647	1705373719	1705373739	OK	IPv4	0	0	0	0	31	us-east-1	ingress	-	AMAZON	<AWSアカウントID>	us-east-1	2024/01/16/02
6	6	TransitGateway	<AWSアカウントID>	tgw-0925eb88277e1762d	tgw-attach-066289c8fbd1beac6	<AWSアカウントID>	<AWSアカウントID>	vpc-02f1c02c61a493dc3	vpc-0ddf513a02ddd7695	subnet-0310d28db41359933	subnet-05f342c2940f01c3a	eni-01d1b0de3c4cac5e0	eni-0c29cd62b9559b7db	use1-az6	use1-az1	tgw-attach-0ddcc90bec74551b8	10.1.1.27	52.46.139.110	60284	443	6	8	351	1705373712	1705373717	OK	IPv4	0	0	0	0	29	us-east-1	ingress	-	AMAZON	<AWSアカウントID>	us-east-1	2024/01/16/02
7	6	TransitGateway	<AWSアカウントID>	tgw-0925eb88277e1762d	tgw-attach-0ddcc90bec74551b8	<AWSアカウントID>	<AWSアカウントID>	vpc-02f1c02c61a493dc3	vpc-0ddf513a02ddd7695	subnet-0310d28db41359933	subnet-05f342c2940f01c3a	eni-01d1b0de3c4cac5e0	eni-0c29cd62b9559b7db	use1-az6	use1-az1	tgw-attach-066289c8fbd1beac6	10.1.1.27	209.54.182.32	37502	443	6	16	5376	1705373757	1705373757	OK	IPv4	0	0	0	0	26	us-east-1	egress	-	AMAZON	<AWSアカウントID>	us-east-1	2024/01/16/02
8	6	TransitGateway	<AWSアカウントID>	tgw-0925eb88277e1762d	tgw-attach-0ddcc90bec74551b8	<AWSアカウントID>	<AWSアカウントID>	vpc-02f1c02c61a493dc3	vpc-0ddf513a02ddd7695	subnet-0310d28db41359933	subnet-05f342c2940f01c3a	eni-01d1b0de3c4cac5e0	eni-0c29cd62b9559b7db	use1-az6	use1-az1	tgw-attach-066289c8fbd1beac6	10.1.1.27	52.46.139.110	60284	443	6	8	351	1705373712	1705373717	OK	IPv4	0	0	0	0	29	us-east-1	egress	-	AMAZON	<AWSアカウントID>	us-east-1	2024/01/16/02
9	6	TransitGateway	<AWSアカウントID>	tgw-0925eb88277e1762d	tgw-attach-0ddcc90bec74551b8	<AWSアカウントID>	<AWSアカウントID>	vpc-02f1c02c61a493dc3	vpc-0ddf513a02ddd7695	subnet-0fdb72baa777b74a7	subnet-0a2630b31c7ff62b3	eni-084ba370c45e3de77	eni-048b91cafedc00257	use1-az1	use1-az6	tgw-attach-066289c8fbd1beac6	10.1.1.46	52.46.143.242	50900	443	6	4	160	1705373760	1705373760	OK	IPv4	0	0	0	0	4	us-east-1	egress	-	AMAZON	<AWSアカウントID>	us-east-1	2024/01/16/02
10	6	TransitGateway	<AWSアカウントID>	tgw-0925eb88277e1762d	tgw-attach-066289c8fbd1beac6	<AWSアカウントID>	<AWSアカウントID>	vpc-02f1c02c61a493dc3	vpc-0ddf513a02ddd7695	subnet-0310d28db41359933	subnet-05f342c2940f01c3a	eni-01d1b0de3c4cac5e0	eni-0c29cd62b9559b7db	use1-az6	use1-az1	tgw-attach-0ddcc90bec74551b8	10.1.1.27	209.54.182.32	37502	443	6	7	311	1705373773	1705373777	OK	IPv4	0	0	0	0	29	us-east-1	ingress	-	AMAZON	<AWSアカウントID>	us-east-1	2024/01/16/02

カラムが流石に多いのでもう少し絞ります。

送信元AZと送信先AZが異なる通信のうち、送信元/送信先のIPアドレス、AZ、VPC IDと通信の方向が一意のものを抽出します。

SELECT
  DISTINCT 
    srcaddr,
    dstaddr,
    tgw_src_vpc_id,
    tgw_dst_vpc_id,
    tgw_src_az_id,
    tgw_dst_az_id
    flow_direction
FROM 
  transit_gateway_flow_logs_partition_projection
WHERE
  aws_account_id='<AWSアカウントID>' and
  aws_region='us-east-1' and
  datehour='2024/01/16/02' and
  tgw_src_az_id <> tgw_dst_az_id

実行結果は以下のとおりです。

#	srcaddr	dstaddr	tgw_src_vpc_id	tgw_dst_vpc_id	tgw_src_az_id	flow_direction
1	10.1.1.27	67.220.244.190	vpc-02f1c02c61a493dc3	vpc-0ddf513a02ddd7695	use1-az6	use1-az1
2	10.1.1.46	209.54.182.32	vpc-02f1c02c61a493dc3	vpc-0ddf513a02ddd7695	use1-az6	use1-az1
3	10.1.1.46	52.119.198.234	vpc-02f1c02c61a493dc3	vpc-0ddf513a02ddd7695	use1-az1	use1-az6
4	10.1.1.27	67.220.242.45	vpc-02f1c02c61a493dc3	vpc-0ddf513a02ddd7695	use1-az6	use1-az1
5	10.1.1.46	67.220.242.22	vpc-02f1c02c61a493dc3	vpc-0ddf513a02ddd7695	use1-az1	use1-az6
.
.
(中略)
.
.
130	10.1.1.27	52.46.145.233	vpc-02f1c02c61a493dc3	vpc-0ddf513a02ddd7695	use1-az6	use1-az1
131	10.1.1.46	67.220.247.162	vpc-02f1c02c61a493dc3	vpc-0ddf513a02ddd7695	use1-az1	use1-az6
132	10.1.1.46	52.46.138.63	vpc-02f1c02c61a493dc3	vpc-0ddf513a02ddd7695	use1-az1	use1-az6
133	10.1.1.27	54.239.25.99	vpc-02f1c02c61a493dc3	vpc-0ddf513a02ddd7695	use1-az6	use1-az1
134	10.1.1.27	67.220.242.48	vpc-02f1c02c61a493dc3	vpc-0ddf513a02ddd7695	use1-az1	use1-az6

134件とそれなりにありました。

結果を確認してみると、送信元VPCはVPC Aと送信先VPCはVPC Bと常に同じ値でした。

逆になっているものを確認してみます。


SELECT
  DISTINCT 
    srcaddr,
    dstaddr,
    tgw_src_vpc_id,
    tgw_dst_vpc_id,
    tgw_src_az_id,
    tgw_dst_az_id
    flow_direction
FROM 
  transit_gateway_flow_logs_partition_projection
WHERE
  aws_account_id='<AWSアカウントID>' and
  aws_region='us-east-1' and
  datehour='2024/01/16/02' and
  tgw_src_az_id <> tgw_dst_az_id and
  tgw_dst_vpc_id <> 'vpc-0ddf513a02ddd7695'

結果は0件でした。

ここからも「アプライアンスモードを有効化したTransit Gateway attachmentが宛先となる場合は送信元AZと同じAZになるとは限らない」ことが分かります。

試しにVPC AのTransit Gateway attachmentでもアプライアンスモードを有効化します。

有効化後EC2 Instance AにSSMセッションマネージャーで接続して通信できることを確認します。

$ for i in {0..15}; do
  curl http://checkip.amazonaws.com/
done
18.210.168.215
18.210.168.215
18.210.168.215
3.231.80.221
18.210.168.215
18.210.168.215
18.210.168.215
18.210.168.215
3.231.80.221
18.210.168.215
18.210.168.215
18.210.168.215
3.231.80.221
3.231.80.221
18.210.168.215
18.210.168.215

そしてAthenaで先ほど0件だった以下クエリを実行します。

SELECT
  DISTINCT 
    srcaddr,
    dstaddr,
    tgw_src_vpc_id,
    tgw_dst_vpc_id,
    tgw_src_az_id,
    tgw_dst_az_id
    flow_direction
FROM 
  transit_gateway_flow_logs_partition_projection
WHERE
  aws_account_id='<AWSアカウントID>' and
  aws_region='us-east-1' and
  datehour='2024/01/16/03' and
  tgw_src_az_id <> tgw_dst_az_id and
  tgw_dst_vpc_id <> 'vpc-0ddf513a02ddd7695'

実行結果は以下のとおりです。

#	srcaddr	dstaddr	tgw_src_vpc_id	tgw_dst_vpc_id	tgw_src_az_id	flow_direction
1	54.161.254.100	10.1.1.27	vpc-0ddf513a02ddd7695	vpc-02f1c02c61a493dc3	use1-az6	use1-az1
2	52.46.139.110	10.1.1.27	vpc-0ddf513a02ddd7695	vpc-02f1c02c61a493dc3	use1-az6	use1-az1
3	52.46.132.109	10.1.1.27	vpc-0ddf513a02ddd7695	vpc-02f1c02c61a493dc3	use1-az1	use1-az6
4	52.217.87.128	10.1.1.27	vpc-0ddf513a02ddd7695	vpc-02f1c02c61a493dc3	use1-az6	use1-az1
5	67.220.245.207	10.1.1.27	vpc-0ddf513a02ddd7695	vpc-02f1c02c61a493dc3	use1-az6	use1-az1
6	35.171.239.133	10.1.1.27	vpc-0ddf513a02ddd7695	vpc-02f1c02c61a493dc3	use1-az1	use1-az6
7	52.44.100.172	10.1.1.27	vpc-0ddf513a02ddd7695	vpc-02f1c02c61a493dc3	use1-az1	use1-az6
8	67.220.242.23	10.1.1.46	vpc-0ddf513a02ddd7695	vpc-02f1c02c61a493dc3	use1-az1	use1-az6
9	54.81.127.33	10.1.1.27	vpc-0ddf513a02ddd7695	vpc-02f1c02c61a493dc3	use1-az1	use1-az6
10	54.161.254.100	10.1.1.27	vpc-0ddf513a02ddd7695	vpc-02f1c02c61a493dc3	use1-az1	use1-az6
11	67.220.245.207	10.1.1.27	vpc-0ddf513a02ddd7695	vpc-02f1c02c61a493dc3	use1-az1	use1-az6
12	52.119.199.68	10.1.1.27	vpc-0ddf513a02ddd7695	vpc-02f1c02c61a493dc3	use1-az6	use1-az1
13	35.170.8.216	10.1.1.27	vpc-0ddf513a02ddd7695	vpc-02f1c02c61a493dc3	use1-az1	use1-az6
14	52.46.145.233	10.1.1.27	vpc-0ddf513a02ddd7695	vpc-02f1c02c61a493dc3	use1-az1	use1-az6
15	3.94.91.31	10.1.1.27	vpc-0ddf513a02ddd7695	vpc-02f1c02c61a493dc3	use1-az1	use1-az6
16	52.46.132.109	10.1.1.27	vpc-0ddf513a02ddd7695	vpc-02f1c02c61a493dc3	use1-az6	use1-az1
17	52.207.222.50	10.1.1.27	vpc-0ddf513a02ddd7695	vpc-02f1c02c61a493dc3	use1-az6	use1-az1
18	52.203.58.41	10.1.1.27	vpc-0ddf513a02ddd7695	vpc-02f1c02c61a493dc3	use1-az1	use1-az6
19	52.6.186.111	10.1.1.27	vpc-0ddf513a02ddd7695	vpc-02f1c02c61a493dc3	use1-az1	use1-az6
20	34.239.40.95	10.1.1.27	vpc-0ddf513a02ddd7695	vpc-02f1c02c61a493dc3	use1-az1	use1-az6
21	209.54.182.68	10.1.1.27	vpc-0ddf513a02ddd7695	vpc-02f1c02c61a493dc3	use1-az1	use1-az6
22	52.203.58.41	10.1.1.27	vpc-0ddf513a02ddd7695	vpc-02f1c02c61a493dc3	use1-az6	use1-az1
23	54.81.127.33	10.1.1.27	vpc-0ddf513a02ddd7695	vpc-02f1c02c61a493dc3	use1-az6	use1-az1
24	52.54.130.153	10.1.1.27	vpc-0ddf513a02ddd7695	vpc-02f1c02c61a493dc3	use1-az1	use1-az6

24件出力されました。

アプライアンスモードはルーティング先のVPCについてにのみ影響を与えることが分かります。

アプライアンスモードを有効化することによって通信できない場面はあるのか

先の検証で「アプライアンスモードを有効化したTransit Gateway attachmentへ通信が流れる際は、送信元のAZとは関係なく、いずれかのAZのENIにルーティングされる」ことを確認しました。

そして、そのデメリットとしてAZ間通信分のコストやレイテンシーが発生してしまうことも紹介しました。

アプライアンスモードを有効化することによって通信できない場面はあるのでしょうか。

私としては基本的に無い想定です。

先ほどの検証で送信元、送信先どちらのVPCのTransit Gateway attachmentでもアプライアンスモードを有効化していましたが、NAT Gatewayを介してインターネットに抜けることができています。

また、以下のようにNetwork Firewallが送信先VPC上にある場合についても通信可能と考えます。

Transit GatewayのアプライアンスモードはインスペクションVPCでのみ有効にするべき検証環境構成図

VPC BのTransit Gateway attachmentでアプライアンスモードを有効化しています。

こちらの環境でEC2 Instance AからProxy Instance Aに対しての通信をする場合を考えます。アプライアンスモードを有効にしたことによる影響で送信元であるEC2 Instance Aと同じAZでなくても、VPCのルートテーブルに従ってリクエスト/レスポンスは問題なくできると認識しています。

NetworkFirewallが送信先VPC上にある構成でアプライアンスモードを有効化していても通信はできる

取りあえずアプライアンスモードを有効化する といった運用は控えましょう

Transit GatewayのアプライアンスモードはインスペクションVPCでのみ有効にするべきというお話をしました。

「取りあえずアプライアンスモードを有効化する」といった運用は控えましょう。

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

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

Share this article

facebook logohatena logotwitter logo

関連記事

[レポート] セキュリティとネットワークの GameDay に参加してきました #GHJ303 #AWSreInvent

[レポート] セキュリティとネットワークの GameDay に参加してきました #GHJ303 #AWSreInvent

[登壇レポート] VPC間の接続方法を整理してみた #自治体クラウド勉強会

[登壇レポート] VPC間の接続方法を整理してみた #自治体クラウド勉強会

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

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

User avatar
のんピ
2024.10.01
[登壇レポート]「オンプレミスネットワークとVPCとを接続する際に考慮すべきポイントを考えてみた」というタイトルで登壇しました #自治体クラウド勉強会

[登壇レポート]「オンプレミスネットワークとVPCとを接続する際に考慮すべきポイントを考えてみた」というタイトルで登壇しました #自治体クラウド勉強会

User avatar
のんピ
2024.05.29
Classmethod's white logo
Facebook's logo
X's logo
YouTube's logo

© Classmethod, Inc. All rights reserved.