Skip to content

CONCEPT Cited by 1 source

TGW Appliance Mode

Appliance Mode is a property of an AWS Transit Gateway attachment that pins a flow to a specific Availability Zone's endpoint over the lifetime of the flow, so that both directions of a stateful connection consistently land on the same appliance instance. Without it, TGW's normal load-balancing hashes the two directions of a flow independently and can send them to different AZs — which is fine for stateless destinations but breaks any stateful middlebox sitting behind the attachment (firewalls, IDS/IPS, transparent proxies, NAT appliances).

The asymmetric-routing problem it solves

A stateful inspection device tracks connection state (TCP session table, NAT translations, deep-packet-inspection context) per instance. Packets in the same flow must reach the same instance for that state to remain coherent. When TGW fronts a multi-AZ appliance fleet:

  • Forward path: source VPC → TGW → chooses AZ-A → appliance in AZ-A → destination.
  • Return path: destination VPC → TGW → hashes independently → chooses AZ-B → appliance in AZ-B.

Appliance in AZ-B has no state for this flow; at best it drops, at worst it emits a RST / reject that tears down the connection. This is a classic cause of "SYNs go out, nothing comes back" black-hole failures in centralised-inspection topologies.

Appliance Mode fixes this by making TGW record the AZ choice on the first packet of a flow and honour it for both directions until the flow ages out.

When it's required

Required for any TGW attachment fronting a stateful device:

  • Centralised firewall / IDS/IPS — including AWS Network Firewall when attached to TGW; a canonical instance is the 2025-11-26 post's EVS + Network Firewall topology.
  • Self-managed NVAs — third-party firewalls, SD-WAN concentrators, or custom appliances behind a TGW attachment.
  • Transparent proxies doing TLS termination or DPI.

Not required for stateless paths (plain routing between VPCs with no middlebox in between).

Automatic enablement with Network Firewall native TGW attachment

Historically Appliance Mode had to be set explicitly on an attachment — and forgetting to set it was a common production failure mode for centralised-inspection builds. The 2025-11-26 post describes the native TGW ↔ Network Firewall integration (GA July 2025) as closing this gap:

"With the Transit Gateway native integration enabled, a Transit Gateway attachment is automatically created for the AWS Network Firewall, with the resource type shown as Network Function. In addition, the Appliance Mode is automatically enabled for the firewall attachment to make sure the Transit Gateway continues to use the same Availability Zone (AZ) for the attachment over the lifetime of a flow." (Source: sources/2025-11-26-aws-secure-amazon-evs-with-aws-network-firewall)

With native attachment, Appliance Mode is no longer a thing the operator can forget — the service sets it at attachment-creation time.

Caveats

  • Flow-level pinning, not AZ affinity for the destination. Appliance Mode pins which firewall AZ sees the flow; it does not affect where the ultimate destination VPC sits. A flow whose destination is in AZ-C can still have its firewall hop in AZ-A.
  • Cross-AZ charges. Pinning can send the forward + return paths across AZs if the source and destination are in different AZs — stateful correctness over AZ-locality efficiency.
  • Does not fix asymmetry outside TGW. If the return traffic bypasses TGW entirely (e.g. a VPC with a local route that shortcuts), Appliance Mode can't help — the return never reaches TGW to be pinned.

Seen in

Last updated · 200 distilled / 1,178 read