Skip to content
VenerableNetworks
SpecialtyProTransit Gateway

Lab 17: The Appliance Mode That Was Enabled And Ignored

Appliance mode is enabled. Route propagation is enabled on the right route table. Every check AWS documents passes. Half of same-zone traffic is still handed to the appliance in the wrong Availability Zone, and the bill shows it before anything else does.

Debugging time
~40 min
Reading time
12 min
Reported by
Cloud Platform
Tier
Specialty
INC-1738SEV-3InvestigatingOpened 2026-09-27 11:40 UTC

Cross-zone data transfer on the inspection VPC is roughly half of all inspected traffic

Reported by Cloud Platform

Finance flagged cross-zone transfer on the inspection VPC. It is running at close to half the total inspected volume, which should be near zero — the workloads that talk to each other are deliberately co-located in the same Availability Zone precisely so inspection stays in-zone.

We enabled appliance mode when we built this, exactly for this reason. I have checked it: the attachment reports ApplianceModeSupport: enable.

I also checked the prerequisite in the documentation, which says route propagation must be enabled on the transit gateway route table associated with the appliance-mode attachment. It is enabled. Both spoke attachments show enabled in get-transit-gateway-route-table-propagations.

So both requirements are met and the behaviour is wrong. There is no error anywhere, nothing has alarmed, and the only reason we know is the invoice.

What you are working with

One Transit Gateway, three VPCs, two Availability Zones.

Starting state — both spokes in the first zone, inspection spanning two
VPC spoke-a 10.180.0.0/16 AZ a contains spoke-a 10.180.1.0/24, default route 10.181.0.0/16 → tgw, holding Client. VPC inspection 10.182.0.0/16 AZ a contains appliance-a 10.182.1.0/24, default route spoke prefixes → eni, holding Appliance A. AZ b contains appliance-b 10.182.2.0/24, default route spoke prefixes → eni, holding Appliance B. VPC spoke-b 10.181.0.0/16 AZ a contains spoke-b 10.181.1.0/24, default route 10.180.0.0/16 → tgw, holding Target.transitgatewayappliance modetransitgatewayappliance modeVPC spoke-a 10.180.0.0/16AZ aspoke-apublic10.180.1.0/2410.181.0.0/16 → tgwClient10.180.1.50VPC inspection 10.182.0.0/16AZ aappliance-apublic10.182.1.0/24spoke prefixes → eniAppliance Acaptures, does not forwardAZ bappliance-bpublic10.182.2.0/24spoke prefixes → eniAppliance Bcaptures, does not forwardVPC spoke-b 10.181.0.0/16AZ aspoke-bpublic10.181.1.0/2410.180.0.0/16 → tgwTarget10.181.1.50

One transit gateway, drawn on each path it carries. Client and target are both pinned into the first Availability Zone, which is the condition under which appliance mode is documented to keep a flow on one appliance. The inspection VPC's attachment spans both zones, so the transit gateway has an interface in each to choose between — and the count of flows landing on each appliance is the measurement this lab takes.

ResourceConfiguration
ClientSpoke A, 10.180.1.50, first AZ
TargetSpoke B, 10.181.1.50, first AZ
Appliance AInspection VPC, first AZ
Appliance BInspection VPC, second AZ
Appliance attachmentApplianceModeSupport: enable, subnets in both zones
Spoke route tableBoth spoke prefixes → appliance attachment
Appliance route table propagationsBoth spoke attachments, enabled
Appliance route table routesBoth spoke prefixes, present

Source and destination are in the same Availability Zone. Per AWS's documented Scenario 1, appliance mode should hold that zone for the whole flow, so every flow should reach appliance A.

  1. EC2

    Client, first AZ

    10.180.1.50 → 10.181.1.50

  2. GW

    Transit gateway

    spoke route table sends the prefix to the appliance attachment

  3. RTB

    Availability Zone selection

    appliance mode enabled, propagation enabled

    Dropped — The route actually in use for the destination prefix is static, and a static route carries no Availability Zone information. With nothing to reason over, the transit gateway hashes the flow and picks a zone.

  4. VPCE

    Appliance A, first AZ

    receives roughly half the flows

  5. VPCE

    Appliance B, second AZ

    receives roughly half the flows, and should receive none

Nothing fails. Each flow is inspected, consistently, by one appliance. Half of them cross a zone boundary to get there.

Scope and constraints

  • In scope: why zone affinity is not happening when both documented requirements are met.
  • Out of scope: appliance mode itself, the propagation configuration, the attachment subnets, and the spoke route table. All correct.
  • The reporter is right on both counts. Appliance mode is enabled and propagation is enabled. Verify both yourself early so you stop re-checking them.
  • Nothing is broken. No connection fails and no alarm fires. This is a cost and blast-radius finding.
  • The fix removes configuration rather than adding it.

Deploy the broken state

cd lab-17-appliance-mode-static-shadow
terraform init
terraform apply

The Transit Gateway takes a few minutes and the attachments a few more — budget about eight minutes before anything is testable.