Overlapping Address Space and Asymmetric Egress Inspection
Three business units run in one region behind a transit gateway. An acquisition brought a VPC that uses 10.0.0.0/16, which overlaps the existing shared-services VPC. On-premises connects over a Direct Connect advertising 10.0.0.0/8, and policy requires all internet egress to pass through a central inspection VPC running a firewall appliance. Since a second appliance was added in a second availability zone, users report intermittent timeouts to SaaS APIs, and flow logs show return traffic leaving through the wrong appliance. A newly onboarded team also needs to call a partner API over the internet from a source IP the partner can allowlist.
1. What are the realistic options for the overlapping /16, and how do you choose?
Read the worked answer
The overlap is not just an internal inconvenience: because on-premises advertises 10.0.0.0/8, the acquired VPC's addresses are indistinguishable from existing on-premises space, so it cannot be routed to or from on-premises at all without translation.
Options, in ascending order of cost:
- Restrict its connectivity to what it actually needs. If the acquired workload only consumes a handful of services, publish those behind endpoints or a load balancer in non-overlapping space and let it initiate only. No routing of the /16 anywhere. Fastest and usually sufficient.
- NAT that VPC at the transit layer, translating to a unique range. Preserves general connectivity, costs operational complexity, and breaks anything that embeds IP addresses in application logic or certificates.
- Re-IP the VPC. Cleanest long-term, expensive and risky for a newly acquired business, and requires application-level changes.
The decision should be driven by a requirement question first: does the acquired business need bidirectional reach to on-premises, or only to a few services? Teams often re-IP before discovering that one-way access to three endpoints was enough.
2. Why did adding a second firewall appliance in a second AZ cause intermittent timeouts, and how would you fix it?
Read the worked answer
This is the classic stateful-inspection asymmetry. A flow arrives through appliance A in AZ-1, but the transit gateway routes the return packet independently and it exits via appliance B in AZ-2. Appliance B has no session state for that flow, so it drops the packet. Whether a given connection fails depends on the hash of the flow, which is exactly why the symptom is intermittent rather than total - and why it started when the second AZ was added.
Fixes, in order:
- Enable appliance mode on the transit gateway attachment for the inspection VPC. This keeps both directions of a flow pinned to the same appliance in the same AZ.
- Verify symmetric routing across the whole path, including the spoke attachments and any return-path static routes. Appliance mode does not help if routing sends return traffic elsewhere.
- If appliances must be shared across AZs, they need session synchronisation or flow stickiness at the load balancer.
- Scale per AZ, not across AZs - an inspection design where one AZ hosts two appliances and the other hosts none has a hidden single point of failure as well as an asymmetry problem.
3. How would you deliver a stable source IP for the partner allowlist without breaking availability?
Read the worked answer
Give egress a deliberate, owned address plane rather than letting instances use whatever the default path provides.
The design: a dedicated egress VPC (or a clearly scoped egress subnet in the inspection VPC) with NAT gateways holding elastic IPs, and all partner-bound traffic routed there by policy.
The tension to surface to the team is this: a NAT gateway is zonal, so an HA design means one elastic IP per AZ - typically two or three addresses, not one. That has two consequences:
- The partner must allowlist all of them, and the list must be maintained when AZs are added. Ask the partner explicitly; a single-IP allowlist will fail over on the first AZ event.
- Buying "one IP" by using a single-AZ NAT trades availability for allowlist simplicity. That may be an acceptable documented decision for a non-critical integration, but it must be stated, not discovered during an outage.
Also check the inspection path does not silently bypass the firewall for this traffic - a route added for the partner call that skips the inspection VPC would pass traffic and fail policy.