Multi-Zone Ingress with Layer-4 NLB and DNS Failover
A ticketing platform serves 15,000 requests per second at peak from two Exoscale zones, CH-GVA-2 and CH-DK-2. Each zone runs 12 application instances behind a single Elastic IP and DNS round-robin with a 300-second TTL. Users in southern Germany report 180 ms p95 latency, and during a zone failover last month checkout errors lasted six minutes because DNS caches kept sending traffic to the failed zone. The business wants active-active ingress, health-checked failover under 60 seconds, TLS termination, and session stickiness for checkout. The application is HTTP/1.1 and stores sessions in Redis. Exoscale Network Load Balancer is layer 4 and does not terminate TLS. The team can deploy Nginx or HAProxy on the application instances. Security requires that only the load balancer can reach application ports, and that management SSH is not exposed publicly. The budget covers one NLB per zone and a small reverse-proxy fleet.
1. Design the ingress path from client to application, including TLS and health checks.
Read the worked answer
Deploy one Exoscale Network Load Balancer per zone with a public IP. Each NLB forwards TCP 443 to a small reverse-proxy fleet in the same zone. The reverse proxies terminate TLS, perform HTTP health checks against the application's /health endpoint, and forward to application instances over the private network. The NLB's own health check should target TCP 443 on the reverse proxies; the reverse proxy does the application-aware check. This separates layer-4 availability from layer-7 health.
Do not terminate TLS on the application instances unless you accept certificate sprawl. Keep the reverse-proxy fleet small but at least two instances per zone with anti-affinity. The application security group should allow only the reverse-proxy security group on the application port. The reverse-proxy security group should allow only the NLB traffic. Remove public Elastic IPs from application instances.
For checkout stickiness, use cookie-based session affinity at the reverse proxy. However, because sessions are already in Redis, prefer fixing Redis replication over relying on stickiness; stickiness alone will not survive a zone failover. The NLB is not a TLS terminator and should not be treated as one.
2. How do you achieve sub-60-second failover and avoid the previous DNS problem?
Read the worked answer
The six-minute outage was caused by a 300-second DNS TTL, not by the load balancer. Reduce the TTL to 30 seconds and use health-checked DNS records that withdraw the failed zone's NLB IP. With a 30-second TTL plus a 10-second health-check interval, the worst-case client failover is around 40 seconds, within the 60-second objective. Do not rely on round-robin without health checks.
Run both zones active-active so the surviving NLB already has capacity. Pre-warm the reverse proxies and application pool for the extra load; a failover that causes overload is not a failover. Configure clients with retries for idempotent requests and short connect timeouts. For checkout, make the operation idempotent with a client-generated key so a retry after failover does not double-charge.
DNS is still a weak dependency. If the business requires stricter guarantees, use a global traffic manager with health checks or anycast, but that is outside the stated budget. Document that 60 seconds is achievable only if client resolvers honor the 30-second TTL; some resolvers may not.
3. What security-group and private-network rules do you configure?
Read the worked answer
Attach application instances and reverse proxies to a private network per zone. The application security group should allow inbound only from the reverse-proxy security group on the application port, and allow no public inbound. The reverse-proxy security group should allow inbound 443 only from the NLB's IP addresses or the NLB security group if supported, plus health-check traffic. Do not allow SSH from 0.0.0.0/0; use a bastion host or VPN on the private network, with a separate security group and key-based authentication.
Redis should also be on the private network and accept connections only from the application security group. If Redis is zonal, replicate or use a cross-zone session strategy; otherwise a zone failover will lose sessions even if HTTP traffic fails over correctly. The NLB itself should not expose management ports. Egress from application instances should be restricted to required destinations, such as package mirrors and the Redis endpoint. Review rules for stale Elastic IP allowlists after the migration.