Network high availability options on AWS

The network layer is where availability designs most often have a single point of failure that nobody has noticed, because the failing component is one somebody else operates.

Multi-AZ subnet design

A VPC spans a Region; a subnet lives in exactly one Availability Zone. Multi-AZ presence is therefore something you create by placing subnets, not something a VPC has by default.

• Create subnets in each Availability Zone you intend to use — three where the Region offers three.
• Place every tier across all of them, and keep the configuration identical between zones so a failover does not land traffic on a differently configured stack.
• Size subnets with growth in mind. Resizing a subnet is not possible; you add a new one, and addressing plans that assumed the original size then need revisiting.
• Give each Availability Zone its own route table where the zone-local resources differ — which they do as soon as you have a NAT gateway per zone.

Corporate connectivity

A single Direct Connect connection is not highly available. It is one circuit, terminating on one device, in one facility. Making the connection resilient means adding a second path, and the second path is only useful to the extent that it does not share fate with the first:

• A second Direct Connect connection, ideally at a different location and through a different provider.
• Or a Site-to-Site VPN over the internet as a backup path, which is cheaper and slower but fails independently.

With BGP running over both, the routing converges automatically: when the Direct Connect link drops, BGP withdraws its routes and traffic follows the VPN. That behaviour is a property of the routing configuration, not something AWS does on your behalf, so it needs to be configured and then tested.

Where a VPN is the primary path, run at least two tunnels to the Virtual Private Gateway and terminate them on separate customer gateway devices, so that the on-premises end is redundant too.

Route 53

Route 53 offers a 100% availability service level agreement for its authoritative DNS service — the only AWS service with that commitment — which makes it a safe place to put failover logic.

Health checks monitor an endpoint and remove it from responses when it fails. This works for endpoints outside AWS as well as inside, so an on-premises web farm can be the primary record with an AWS environment as the failover target. Recovery time is the health-check interval plus the record TTL, so keep TTLs short on records that participate in failover.

Elastic IP addresses

An Elastic IP is a static address you own and can move between resources. Remapping it to a replacement instance or a different network interface restores service without waiting for DNS to propagate anywhere, which makes it useful for fast failover and for third parties who have allow-listed a specific address.

The default quota is 5 Elastic IPs per Region, adjustable through Service Quotas. That is lower than most people assume — a Network Load Balancer with one address per Availability Zone consumes three of them in a three-zone Region — so plan a quota increase before deploying more than one such service in a Region.

NAT gateways

A NAT gateway is a zonal resource. A single gateway serving private subnets in three Availability Zones is a single point of failure, and it also means cross-zone data transfer charges on every outbound byte from the other two zones.

• Deploy one NAT gateway per Availability Zone, in that zone’s public subnet.
• Give each private subnet a route table whose default route points at the gateway in its own zone.
• Monitor ErrorPortAllocation and the gateway’s connection count; port exhaustion on a busy gateway presents as intermittent connection failures rather than an outage.

A worked failover statement

For a design combining these pieces, the following are all true and are worth stating explicitly in a recovery plan, because each is a different mechanism:

• BGP withdraws the Direct Connect routes when that link fails, and traffic to AWS follows the backup VPN connection.
• Route 53 health-checks the on-premises web endpoint and stops returning it once it fails, so clients resolve to the AWS environment instead.
• An Aurora cluster fails over to a replica in another Availability Zone automatically, without a DNS change on the application’s part, because the cluster endpoint follows the writer.

Cost

Redundancy at the network layer is mostly a standing cost: a second Direct Connect port, a NAT gateway per Availability Zone, Elastic IPs, and health checks. Review it against the availability requirement periodically — NAT gateway hours and per-GB processing in particular tend to grow quietly, and VPC endpoints for high-volume AWS destinations remove traffic from them entirely.