HA Across Two AWS Availability Zones for a Retailer

The on-premises pattern relies on a secondary IP address that moves between devices, with gratuitous ARP telling the adjacent switch where the address now lives. AWS does not deliver traffic that way: the VPC routes to an elastic network interface, not to a MAC address, and there is no gratuitous ARP propagation to update the fabric. The standby can hold the address configured and still never receive a packet.

Alternative 1 - Cloud Failover Extension. The VEs use AWS APIs to move an Elastic IP and update route tables on failover. Advantage: the VE still owns the public address, so client IP is preserved and the on-premises mental model is close. Disadvantage: failover depends on API calls and IAM permissions, and takes tens of seconds; the IAM role becomes part of the availability story.

Alternative 2 - Network Load Balancer in front of VE targets. The NLB health-checks the VEs and sends traffic only to healthy targets. Advantage: fast, managed failover. Disadvantage: an extra hop, per-AZ cross-zone costs, and the VE no longer sees the client IP unless Proxy Protocol v2 is enabled. Pick based on whether client IP matters to the WAF and logs - for a storefront, it usually does.

You still need a global decision layer; the question is whether it is BIG-IP DNS or F5 Distributed Cloud DNS.

Keep BIG-IP DNS (as VE) if the team already operates it, needs the same DNS express and iRules investment, and wants consistent policy between on-premises and cloud during the transition. Run a VE pair per region, with health monitors against the regional service address, and use topology or latency-based distribution with a short TTL.

Move to Distributed Cloud DNS if the priority is removing the operational burden of running another VE pair in each region - it gives global anycast resolution and health-checked failover without you patching DNS appliances.

For a 30-minute RTO, DNS is sufficient: a 60-second TTL plus a health check that fires within a few monitor cycles lands well inside the objective. The important design point is that DNS failover and in-region failover are separate layers. DNS moves users between regions; the NLB or the failover extension moves them between VEs. Both must be tested independently, with the active instance deliberately stopped, before go-live.

Client IP is a functional requirement here, not a nicety: the WAF's rate limiting, the bot defences, the fraud rules, and the access logs all key on source address. Lose it and every request appears to come from the load balancer, which silently degrades the security controls the customer is paying for.

With the NLB path: enable Proxy Protocol v2 on the NLB target group and configure the VE to accept it. Verify that the WAF and the logs see the original address, not the NLB address. Note that Proxy Protocol must be enabled on both ends or the connection breaks.

With the failover-extension path: the Elastic IP is attached to the active VE's interface, so the client IP is preserved naturally; confirm that source NAT and the return path are symmetric.

In both cases: check that the application receives X-Forwarded-For correctly, that log retention meets the retailer's requirements, and that a test with a known source address is run end-to-end before launch. Document the expected header chain so the application team can troubleshoot without escalating.