Appliance mode has a prerequisite that silently undoes it

Appliance mode exists because Transit Gateway's default behaviour breaks stateful inspection. Without it, the two directions of a flow can be handed to appliances in different Availability Zones, and a firewall that only sees half a conversation drops it.

So you enable appliance_mode_support on the inspection VPC's attachment and move on. There is a prerequisite, and missing it puts you back where you started while the console still says appliance mode is enabled.

From the Transit Gateway VPC attachment documentation:

Route propagation must be enabled for the transit gateway route table associated with the appliance-mode VPC attachment. Without propagation, the transit gateway cannot determine the source and destination Availability Zones. All traffic — including the same-Availability-Zone flows — falls back to flow-hash-based Availability Zone selection. This means traffic within the same Availability Zone might be routed to a different Availability Zone in the appliance VPC, breaking Availability Zone isolation.

Why propagation is load-bearing here#

Appliance mode is not just flow stickiness. It is Availability-Zone-aware routing, and the Transit Gateway needs to know which zone the source and destination are in to do it.

That information comes from propagated routes. Propagation is how the Transit Gateway learns the CIDRs behind an attachment and, with them, the zone structure. Strip propagation from the route table associated with the appliance attachment and the Transit Gateway loses the input it reasons over, so it does the only thing left: hashes the flow and picks a zone.

The flow is still consistent for its lifetime — that part of appliance mode survives — but the zone chosen has nothing to do with where the traffic came from or is going.

The four documented cases#

Worth knowing individually, because only one of them is the case people test:

Same-zone source and destination. With propagation, the Transit Gateway picks the appliance ENI in that zone and holds it for the flow. This is the scenario everybody tests, and it is the one that silently changes when propagation is missing.

Cross-zone source and destination. A flow hash picks one of the appliance zones and sticks with it. Expected behaviour, propagation or not.

Destination with no zone information, such as internet-bound traffic. The Transit Gateway uses the source's zone.

Appliance in zones distinct from both source and destination. Flow hash again, consistently for the flow.

So with propagation missing, cases one and three degrade into case two. Nothing errors. Traffic keeps flowing. What you lose is the zone isolation you built the architecture around.

Why it is hard to notice#

The attachment reports appliance mode enabled, because it is. The setting is real and it is doing what it can with the information available.

Nothing alarms. Inspection still works — packets reach an appliance and both directions of a flow reach the same appliance, so a stateful firewall does not break. What breaks is the assumption that same-zone traffic stays in-zone.

The consequences are cost and blast radius rather than errors. Cross-zone data transfer charges appear where you did not expect them. And a zone failure now affects flows that should have been unaffected, which is the kind of thing you discover during the zone failure.

Two other things worth knowing about appliance mode#

It only works on VPC attachments. The documentation is explicit. The flows themselves can originate from any attachment type — VPC, VPN, or Connect — and can cross Regions, but the attachment you enable the setting on has to be a VPC attachment. Teams occasionally try to enable it on a VPN attachment and find the argument does not exist.

Enabling it later rebalances existing flows. From the same page: flows can be rebalanced across Availability Zones if you enable appliance mode after the fact rather than at attachment creation. So turning it on is not a no-op on a live path — existing connections may move, and a stateful appliance will drop the ones that land somewhere new. Enable it during a window, or accept the reset.

What to check#

Two API calls. First, is appliance mode actually on:

aws ec2 describe-transit-gateway-vpc-attachments \
  --query 'TransitGatewayVpcAttachments[].[TransitGatewayAttachmentId,Options.ApplianceModeSupport]' \
  --output table

Then, for the appliance attachment, find its associated route table and confirm that table has propagations:

RTB=$(aws ec2 describe-transit-gateway-vpc-attachments \
  --transit-gateway-attachment-ids "$ATTACH" \
  --query 'TransitGatewayVpcAttachments[0].Association.TransitGatewayRouteTableId' --output text)
 
aws ec2 get-transit-gateway-route-table-propagations \
  --transit-gateway-route-table-id "$RTB" \
  --query 'TransitGatewayRouteTablePropagations[].[TransitGatewayAttachmentId,State]' --output table

An empty result there means appliance mode is nominally enabled and functionally degraded.

That combination is worth an explicit assertion in whatever checks your network configuration, because it is a state that looks correct from every angle except the one that matters.

The broader pattern#

This is the third distinct place where a Transit Gateway feature depends on propagation rather than association, and the general shape is worth carrying: association decides which table governs an attachment's outbound traffic; propagation is how the Transit Gateway learns about a network at all. Features that need to reason about topology need propagation, not just a route.

The Transit Gateway routing guide covers appliance mode alongside the association and propagation model, and the propagation gap lab is the same distinction producing a plain outage instead of a silent degradation.