> ## Documentation Index > Fetch the complete documentation index at: https://docs.aviatrix.com/llms.txt > Use this file to discover all available pages before exploring further. # AZ Affinity and Symmetric Routing Architecture > How Aviatrix combines AZ-aware nexthop selection with per-spoke symmetric routing to cut cross-AZ costs and enable east-west inspection in AWS. ## Overview In an Aviatrix ActiveMesh fabric, every healthy gateway instance in a spoke or transit gateway group is an equally eligible next hop, regardless of which Availability Zone (AZ) it runs in. In AWS, that design has two costs: AWS bills for every crossing of an AZ boundary, and each crossing adds latency that compounds across a multi-hop inspection path such as spoke-transit-firewall-spoke. It also blocks east-west Layer 7 inspection features, which require the forward and return leg of a flow to traverse the same gateway pair. AZ affinity and per-spoke-group symmetric routing solve both problems together: AZ affinity biases next-hop selection toward the local AZ to reduce cross-AZ charges and latency, and symmetric routing pins a spoke subnet's forward and return traffic to a single spoke gateway instance so that a stateful inspection function running on that spoke gateway sees a complete view of every flow. Use this architecture when you run Aviatrix spokes and transits in AWS across multiple Availability Zones and need to control cross-AZ cost or latency, or to enable east-west inspection. In Controller 10.1, AZ affinity and symmetric routing are supported for AWS only, and are not supported on spokes or transits attached to FireNet. ## Architecture Diagram The diagram below shows the topology this architecture assumes: one spoke gateway instance and one transit gateway instance per Availability Zone, with AZ affinity biasing the spoke-to-transit and transit-to-spoke paths toward the local AZ, and symmetric routing pinning a spoke subnet's traffic to a single owning gateway instance for both directions. Spoke and transit gateway instances deployed across two Availability Zones, showing the same-AZ next hop preferred between each spoke and transit instance and the cross-AZ next hop used only as a fallback Each spoke subnet is "owned" by exactly one gateway instance for both outbound and inbound traffic. Traffic from a spoke instance to the transit group prefers the transit instance in the same AZ; traffic back from the transit group to the spoke prefers the owning instance's AZ. Either direction falls back to a healthy instance in the other AZ when no same-AZ instance is available. AZ affinity never reduces availability: it only changes which healthy instance is preferred. ## Design Principles ### AZ-Local Preference, Not AZ-Only Enforcement AZ affinity biases next-hop selection toward the same-AZ gateway instance rather than restricting traffic to that AZ. When the local-AZ instance is unavailable, routing falls back to a healthy instance in another AZ, so the cost and latency optimization never comes at the expense of high availability. ### Deterministic Flow Symmetry Over Load Distribution Per-spoke-group symmetric routing assigns each subnet's outbound and inbound traffic to a single, consistent gateway instance instead of distributing it across the whole gateway group. This sacrifices some load-spreading in exchange for the connection-state guarantee that stateful east-west inspection depends on. ### Cloud-Native Enforcement The architecture uses the standard AWS per-subnet route table association and gateway route-metric mechanisms already available in the platform. It does not introduce new infrastructure, so enabling it does not require new components or a different deployment topology. ### Attachment-Scoped, Opt-In Control AZ affinity is enabled independently on each spoke-to-transit or transit-to-transit attachment rather than globally. You can adopt it selectively on the attachments where cost, latency, or inspection consistency matters most, and leave others on default ActiveMesh behavior. ## Components This architecture combines the following Aviatrix components: * ActiveMesh : the next-hop selection and packet-forwarding engine that AZ affinity extends with an AZ-local preference tier. * Spoke and Transit Gateways : the gateway instances between which AZ affinity and symmetric routing operate. The toggle is configured on the spoke-transit or transit-transit attachment. * WebGroups : a Distributed Cloud Firewall policy construct whose east-west enforcement depends on symmetric routing for a consistent, bidirectional view of each flow. * East-West IDS/IPS : intrusion detection and prevention for east-west traffic. Like WebGroups enforcement, it requires symmetric routing to track connection state correctly. ## Traffic Flows ### Spoke to Transit (Outbound) A workload in a spoke subnet sends traffic toward the transit gateway group. The spoke gateway instance handling that subnet prefers a transit gateway instance in its own Availability Zone. If no healthy instance is available in the same AZ, it falls back to a healthy instance in another AZ. ### Transit to Spoke (Return) Return traffic from the transit group back to the spoke prefers the spoke gateway instance that owns the destination subnet, in the same Availability Zone as that instance. If no same-AZ transit instance is available, traffic is load-balanced across the remaining healthy instances. ### Transit to Transit (Peered Domains) When two transit gateway groups are peered (for example, across regions or Aviatrix domains), AZ affinity applies the same same-AZ preference to traffic crossing that peering. This applies independently of whether AZ affinity is also enabled on the spoke attachments behind either transit. ### Symmetric Routing Pins the Subnet's Owner Independently of AZ affinity, per-spoke-group symmetric routing associates each spoke subnet's route table with a single gateway instance. That instance handles both the outbound leg and the inbound leg of every flow originating from or destined to that subnet, so a stateful inspection function on the spoke gateway always sees both directions of the flow. ## Variants and Trade-offs | Decision | Option A | Option B | When to choose B | | ---------------------------- | ------------------------------------------------- | ----------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | AZ affinity on an attachment | Disabled (default ActiveMesh behavior) | Enabled | Traffic on that attachment crosses AZ boundaries often enough that transfer cost or latency matters, or the attachment carries traffic that requires east-west inspection | | Scope of enablement | Enable on every attachment | Enable per attachment selectively | Only some attachments (for example, the ones carrying inspected traffic) need the cost, latency, or symmetry benefit | | Gateway topology | One gateway instance per AZ per group (supported) | More than one gateway instance per AZ per group | Not applicable: this topology is not supported by AZ affinity or symmetric routing in Controller 10.1 | Enabling AZ affinity limits Equal-Cost Multi-Path (ECMP) load-sharing across all gateway instances in the group, because traffic is biased toward a single same-AZ instance instead of being spread across every healthy instance. This can reduce aggregate bandwidth across the group. Weigh this against the cross-AZ cost and latency reduction before enabling AZ affinity on a high-throughput attachment. ## Sizing and Scale Considerations AZ affinity and symmetric routing do not introduce scale limits beyond the existing per-attachment and per-route-table limits of the underlying platform. The one structural constraint is topological, not numeric: the model supports at most one gateway instance per Availability Zone in a given spoke or transit gateway group. Deployments using one gateway instance per Availability Zone do not need to resize or restructure their gateway groups to adopt AZ affinity or symmetric routing. CoPilot includes built-in capability audits for both AZ affinity and symmetric routing. Each audit checks whether a spoke's VPC route tables and subnets are structured correctly for the corresponding feature, and reports any configuration gaps before you enable it in production. ## Security Considerations Symmetric routing is a prerequisite for any east-west Layer 7 inspection feature that depends on connection state, including east-west IDS/IPS and WebGroups-based policies. It guarantees flow-level symmetry at the spoke gateway only: the same spoke gateway instance always sees both the forward and return leg of a given flow. It does not guarantee that the same transit gateway instance is used in both directions. If symmetric routing is not enabled on a spoke's transit attachment, ActiveMesh can resolve the forward and return legs of the same flow to different spoke gateway instances. When that happens, neither instance sees the complete flow, and a stateful inspection function running on the spoke gateway loses visibility into part of the connection. Traffic that is expected to be inspected can pass with incomplete coverage. AZ affinity itself is a routing cost and latency optimization and has no direct security property. Because it changes which gateway instance a flow's traffic is likely to traverse, review any per-gateway logging, monitoring, or compliance controls to confirm they account for AZ-local traffic patterns once AZ affinity is enabled. ## Limitations * AWS only. AZ affinity and symmetric routing are supported for AWS spokes and transits in Controller 10.1. AZ affinity is primarily an AWS cost optimization; symmetric routing's underlying design is cloud-agnostic, but only AWS is supported in this release. Other cloud providers are not covered by this architecture. * High Performance Encryption required. Both gateways in the attachment or peering must have High Performance Encryption enabled to use AZ affinity. * Not supported with FireNet. AZ affinity and symmetric routing are not supported on spokes or transits attached to FireNet in Controller 10.1. * One gateway instance per AZ per group. The model assumes exactly one gateway instance per Availability Zone in a spoke or transit gateway group. Topologies with more than one instance per AZ per group are not supported. ## Related Resources * Spoke and Transit Gateways : configure the AZ affinity toggle on a spoke-transit or transit-transit attachment. * East-West IDS/IPS : configuration guide for the inspection feature that requires symmetric routing.