Exam objective 2.3 of the ANS-C01 certification demands that you architect networks that never go down, even when components fail. This chapter explains how to build an internet-facing application that stays online during a server crash, a data centre power outage, or a whole-region disaster. You will learn the patterns — load balancers, health checks, multi-region architectures — that turn a fragile, single-point-of-failure network into a resilient, always-on system.
Jump to a section
A simple way to picture Network Services Optimization and High Availability
A hot dog cart on a busy city street is a single point of vulnerability. If the cart breaks a wheel, the propane runs out, or the vendor gets sick, every customer in that queue goes hungry. The entire lunchtime revenue stream collapses because there is only one way to cook and serve hot dogs.
To fix this, the city council licenses a permanent hot dog stand across the street, connected by a reinforced tunnel so both locations share the same underground gas line and the same refrigerated storage for sausages and buns. Now if the cart breaks down, the stand instantly takes over — customers walk across the street, and the business keeps selling. This is active-passive failover: one system runs, the other waits.
But a smarter operator builds two identical mobile carts, each with its own propane tank and separate cooler, parked on opposite corners. A radio dispatcher monitors the queues. If Cart A gets a long line, the dispatcher signals Cart B to start serving the overflow. If Cart A’s propane runs out, Cart B handles every customer alone. This is active-active load balancing: both systems work simultaneously, sharing the workload and covering for each other. The key insight is that the dispatcher (the load balancer) never cooks — it only directs customers to whichever cart can serve them fastest. The business stays open even if one cart catches fire, because the other cart runs on an entirely independent gas supply from a different city main. That independence is Availability Zone separation in the cloud.
Network services optimisation and high availability is the practice of designing your cloud infrastructure so that applications remain accessible and performant even when hardware, software, or network components fail. The goal is to eliminate any single point of failure — one server, one router, one data centre — that could take down your entire service.
At the heart of high availability is redundancy. Redundancy means having backup components ready to take over the moment a primary component fails. In the cloud, this starts with placing your application across multiple Availability Zones. An Availability Zone is a physically separate data centre within an AWS region, with its own power, cooling, and network connectivity. By running identical copies of your application in two or more Availability Zones, you ensure that a fire, flood, or power cut in one zone does not affect the other.
The component that makes this seamless is the load balancer. A load balancer sits in front of your servers and distributes incoming traffic across them. It does not process the application data itself — it just decides which server gets each request. AWS offers three types: the Classic Load Balancer (CLB, older and rarely used), the Network Load Balancer (NLB, for high-throughput TCP traffic), and the Application Load Balancer (ALB, for HTTP and HTTPS traffic). For the ANS-C01 exam, you must understand the ALB and NLB in detail.
Every load balancer performs health checks. A health check is a periodic test — a ping to a specific URL or port — that confirms a server is alive and responding. If a server fails three consecutive health checks, the load balancer marks it as unhealthy and stops sending traffic to it. Traffic is redirected only to healthy servers. This happens automatically, usually within seconds.
Now scale this idea to an entire region. A Region is a geographic area containing multiple Availability Zones. If an entire AWS Region goes offline — say, a massive earthquake strikes — applications running only in that region become unreachable. To protect against this, you deploy your application in two or more Regions and route traffic between them using Amazon Route 53, AWS’s Domain Name System (DNS) service. Route 53 can be configured with a routing policy such as failover routing or latency-based routing. With failover routing, you designate one Region as primary and another as secondary. Route 53 health checks monitor the primary Region’s load balancer endpoint. If that endpoint becomes unhealthy, DNS automatically resolves the application’s domain name to the secondary Region’s IP addresses.
This introduces the concept of a multi-region architecture. In a multi-region architecture, each Region runs its own set of resources — compute, storage, databases — independently. Keeping data synchronised across Regions is the hard part. For databases, you can use services like Amazon Aurora Global Database, which handles replication across Regions with minimal latency. For static assets (images, videos, HTML), you use Amazon CloudFront, a content delivery network that caches copies of your files at edge locations around the world.
Optimisation goes hand in hand with availability. If your system is available but slow, users will abandon it. Optimisation means reducing latency — the time it takes for a request to travel from the user to your server and back. Techniques include using the nearest available server (latency routing in Route 53), compressing responses, and caching frequently accessed data with ElastiCache or CloudFront.
Finally, you must plan for failure in layers. At the application level, you design stateless applications — applications that do not store session data on the server. Any server can handle any request, so if one server dies, another picks up immediately. At the network level, you use multiple internet connections from different providers. At the data level, you take automated backups and use cross-region replication. The sum of these layers is an architecture that has no single point of failure and can withstand the loss of an entire AWS Region without losing data or availability.
Identify Single Points of Failure
List every component in your network — compute, storage, database, load balancer, internet gateway — and ask: if this component fails, does the entire application go down? If yes, that component is a single point of failure and needs redundancy.
Deploy Across Multiple Availability Zones
Launch identical copies of your application servers and database in a second Availability Zone. Use an Application Load Balancer to distribute traffic across both zones. This ensures that a failure in one data centre does not bring down the entire application.
Configure Health Checks on the Load Balancer
Define a health check path, interval (e.g., 10 seconds), and unhealthy threshold (e.g., 3 failures). The load balancer will stop sending traffic to any server that fails the health checks. This automates failover without human intervention.
Set Up Route 53 Failover Routing for Multi-Region Architecture
Create two Route 53 record sets — one for the primary Region and one for the secondary. Associate a health check with the primary record. If the health check fails, Route 53 automatically resolves your domain to the secondary Region’s IP addresses.
Implement Caching and Edge Optimisation
Use Amazon CloudFront to cache static assets (images, CSS, JavaScript) at edge locations close to users. For dynamic or non-HTTP traffic, use AWS Global Accelerator to route users over the AWS global network to the nearest healthy Region endpoint. This reduces latency and offloads traffic from your origin servers.
Test and Monitor the Failover Process
Regularly simulate failures by terminating an EC2 instance or shutting down a load balancer. Verify that health checks trigger automatic failover and that Route 53 DNS record changes propagate correctly. Monitor everything with CloudWatch alarms and dashboards.
Imagine you work for a global e-commerce company that sells luxury watches. The company’s website runs on AWS and serves customers in North America, Europe, and Asia. The current setup is a single AWS Region in Virginia (us-east-1) with one web server, one database server, and one load balancer. The system works fine 99% of the time, but every month there is a five-minute outage when the database is patched. Customers complain, and the CEO demands 99.99% uptime.
You begin by auditing the existing architecture. You spot the obvious single points of failure: there is only one web server, one database, and one Availability Zone. Your first step is to launch identical web servers in a second Availability Zone in the same region. You place both servers behind an Application Load Balancer that performs health checks every ten seconds. Now if one server crashes, the ALB automatically sends all traffic to the remaining healthy server. The outage caused by a server failure drops from hours (manual replacement) to under thirty seconds (automatic failover).
Next, you tackle the database. You replace the single Amazon RDS instance with a Multi-AZ deployment. In a Multi-AZ deployment, RDS automatically provisions and maintains a standby replica in a different Availability Zone. If the primary database fails, RDS automatically fails over to the standby, typically in under sixty seconds. Your application’s connection string remains the same — the failover is transparent to the code.
The company then launches a marketing campaign in Japan. Customers in Tokyo report page load times of four seconds. You implement Amazon CloudFront to cache product images and CSS files at edge locations in Tokyo, Singapore, and Hong Kong. Load times drop to under one second. You also switch Route 53 from simple routing to latency-based routing: customers are automatically directed to the AWS Region (Virginia or, after expansion, a new Region in Tokyo) that responds fastest from their location.
Finally, you design the disaster recovery plan. You replicate the entire environment — EC2 instances, ALB, database — to a second region in Oregon (us-west-2) using AWS CloudFormation templates. You configure Route 53 failover routing with health checks against the Virginia ALB. If the Virginia Region becomes unreachable, DNS automatically points the company’s domain name to the Oregon environment. The failover takes a few minutes because DNS propagation is not instantaneous, but it meets the company’s recovery time objective of fifteen minutes.
Day to day, you monitor the system using Amazon CloudWatch dashboards. You set alarms for elevated error rates on the ALB and for health check failures. When a developer accidentally deploys buggy code that crashes half the web servers, you see the alarm trigger, roll back the deployment, and verify that the remaining healthy servers handled the load without customer impact. Your manager recognises this resilience as a direct result of the architecture you built.
The ANS-C01 exam tests high availability and optimisation in the context of designing network architectures that meet specific service-level agreements (SLAs). You will be given a scenario — a company with a certain budget, latency requirement, and uptime target — and asked to select the correct combination of AWS services and configurations.
The most heavily tested concepts are:
Health check tuning: Exam questions will ask you to set the correct health check interval, threshold, and timeout values. The trap is over-engineering: setting the health check interval too short causes false positives from transient network blips; setting it too long delays failover and violates the SLA. The correct answer usually uses an interval of ten to fifteen seconds with three consecutive failures before marking a target unhealthy.
Route 53 routing policies: You must memorise the differences between simple, weighted, latency, geolocation, geoproximity, and failover routing policies. A common trap question presents a scenario with users in multiple countries and asks which policy minimises latency. The answer is latency-based routing, not geolocation routing. Geolocation routes based on the user’s physical location, not the fastest server.
Load balancer types: The exam will give you a scenario requiring TCP passthrough or UDP traffic. The correct answer is always a Network Load Balancer, not an Application Load Balancer. ALB only works with HTTP and HTTPS. NLB works with any TCP or UDP protocol.
Cross-zone load balancing: When you have EC2 instances in multiple Availability Zones but they are not evenly sized, you must enable cross-zone load balancing on the ALB or NLB. The trap question gives you an uneven distribution of instances and expects you to know that without cross-zone balancing, traffic is split equally across zones, not across instances, which overloads smaller zones.
Multi-region failover with Route 53: The exam loves testing the difference between active-passive (failover routing) and active-active (weighted or latency routing). A typical question describes two Regions serving the same workload and asks which Route 53 configuration provides automatic failover when one Region degrades. The answer is failover routing with health checks on the primary.
Elastic IP and NAT Gateway high availability: You will be asked how to ensure that outbound internet traffic from a VPC remains available if one NAT Gateway fails. The correct pattern is to deploy one NAT Gateway per Availability Zone and configure the route tables to use the gateway in the same zone as the subnet. Do not share a single NAT Gateway across zones.
Global Accelerator: This is a service that uses the AWS global network to route user traffic to the nearest healthy endpoint. The exam compares it to CloudFront. The key difference: Global Accelerator works with TCP and UDP and does not cache content; CloudFront caches content at edge locations and only works with HTTP/HTTPS. A question about reducing latency for a gaming application using non-HTTP protocol will point to Global Accelerator, not CloudFront.
A single Availability Zone is a single point of failure; deploy across at least two zones to survive a data centre outage.
A load balancer does not cache or transform data — it only distributes incoming traffic to healthy targets based on health checks.
Health checks are only as reliable as the endpoint you configure; always use a dedicated health check endpoint that validates the entire application stack.
Route 53 failover routing uses DNS to redirect traffic from an unhealthy Region to a healthy one, but DNS propagation can take minutes.
For non-HTTP protocols such as gaming or VoIP, use a Network Load Balancer or AWS Global Accelerator, not an Application Load Balancer.
Cross-zone load balancing must be enabled explicitly to distribute traffic evenly across instances in different Availability Zones.
These come up on the exam all the time. Here's how to tell them apart.
Application Load Balancer (ALB)
Operates at Layer 7 (HTTP/HTTPS): can inspect headers, cookies, and paths to make routing decisions.
Supports path-based routing: you can send /api traffic to one server group and /images to another.
Automatically integrates with AWS WAF for web application firewall rules.
Network Load Balancer (NLB)
Operates at Layer 4 (TCP/UDP): does not inspect application content, just forwards packets.
Does not support path-based or host-based routing; routes based purely on IP and port.
Capable of handling millions of requests per second with extremely low latency (sub-millisecond).
Active-Passive Failover (Route 53 Failover Routing)
One Region serves all traffic; the other Region is idle until a failure is detected.
Health check on the primary triggers DNS switch to secondary when primary fails.
Simple to manage but the secondary Region may not be fully validated under load.
Active-Active Failover (Route 53 Weighted or Latency Routing)
Both Regions serve traffic simultaneously; does not require a health check to redirect.
If one Region degrades, the other automatically handles more traffic because latency routing sends users to the faster endpoint.
Requires both Regions to be fully active and properly scaled at all times, increasing cost.
CloudFront
Caches static and dynamic content at edge locations to reduce load on origin servers.
Only supports HTTP and HTTPS protocols.
Can integrate with AWS Lambda@Edge for custom logic at the edge.
Global Accelerator
Does not cache content; it uses AWS’s global network to route traffic faster to the application.
Supports TCP and UDP protocols, making it suitable for non-HTTP applications (gaming, VoIP).
Provides a static IP address that acts as a fixed entry point, which is useful for whitelisting.
Mistake
High availability means you never have downtime at all.
Correct
High availability means you meet a specific uptime percentage, like 99.99%, which allows for about 52 minutes of downtime per year. It does not guarantee zero downtime.
Beginners hear 'high availability' and think it means perfect, uninterrupted service. In reality, it is a probability and a cost trade-off. The exam tests your ability to design for a given SLA, not for absolute perfection.
Mistake
A load balancer makes your application faster by processing the data itself.
Correct
A load balancer does not process or cache data; it only directs traffic. It can reduce latency only by choosing the quickest server, but it adds a small amount of network overhead because every request passes through it.
The word 'balancer' suggests it does something to the data to make it lighter or faster. Beginners confuse load balancing with caching. The exam distinguishes between load balancers (traffic distribution) and content delivery networks (data caching).
Mistake
If you have two Availability Zones, you are automatically protected if one whole AWS Region goes down.
Correct
Availability Zones are within a single Region. If the entire Region fails, all Availability Zones in that Region fail. To protect against Region failure, you must deploy in two separate Regions.
The terms 'Zone' and 'Region' sound similar. Beginners assume that multiple Zones imply geographic separation. The exam tests this distinction directly: a multi-AZ architecture survives a data centre outage but not a Region outage.
Mistake
Health checks from the load balancer guarantee that only perfectly healthy servers receive traffic.
Correct
Health checks only test a single endpoint (like /health). If the actual application logic fails but the health check endpoint returns 200 OK, the load balancer still sends traffic to that server. Health checks are only as good as the endpoint you configure.
Beginners treat health checks as a magic bullet. They write a health check that pings the web server root, not the authentication or database layer. The exam expects you to know that you must implement deep health checks that verify the full application stack.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
High availability keeps your application running when a component fails, using redundancy and automatic failover within the same Region. Disaster recovery prepares for a catastrophic failure of an entire Region by replicating your infrastructure to a second Region and providing a process to switch over manually or automatically.
At least two. With two Availability Zones, you can survive the failure of one data centre. Three zones provide even better resilience but cost more. The exam typically expects two zones as the minimum for a production workload.
Yes, a load balancer can fail. AWS load balancers are highly available by design within a region (they run across multiple Availability Zones), but if you need to survive a load balancer failure, you must use Route 53 to direct traffic to a second load balancer in another Region. This is called a multi-region active-passive setup.
Both ALB and NLB are highly available within a region and support health checks and automatic failover to healthy targets. The main difference is protocol: ALB supports HTTP and HTTPS only, while NLB supports TCP, UDP, and TLS. For high availability with non-HTTP traffic, you must use NLB.
Route 53 failover is based on DNS, and DNS records are cached by internet service providers and clients. The Time to Live (TTL) on the DNS record determines how quickly the change propagates. With a TTL of 60 seconds, most clients will switch within a few minutes. You cannot force an instant failover across the entire internet.
Yes. If you share one NAT Gateway across multiple Availability Zones, a failure of the NAT Gateway’s zone will cause the other zones to lose internet connectivity. The recommended pattern is one NAT Gateway per Availability Zone with route tables configured to use the local gateway.
You've finished Network Services Optimization and High Availability. Continue through the ANS-C01 study guide to build a complete picture of the exam.
Done with this chapter?