One Region, Multiple Availability Zones: What Can Still Go Wrong?
Deploying an application across multiple AWS Availability Zones improves resilience, but it does not guarantee zero downtime. Explore common failure scenarios involving EC2 capacity, database failover, load balancers, shared dependencies, configuration errors, and regional outages. Learn practical AWS architecture best practices to improve fault tolerance, test recovery strategies, and build more reliable cloud applications.
One Region, Multiple Availability Zones: What Can Still Go Wrong?
Introduction
One of the biggest advantages of cloud computing is the ability to build applications that remain available even when part of the infrastructure fails. Amazon Web Services (AWS) supports this through Availability Zones (AZs), which are separate locations within an AWS Region with independent infrastructure.
Deploying an application across multiple Availability Zones improves reliability, but it does not automatically make the entire application failure-proof.
A database might remain unavailable, a load balancer might have no healthy targets, or a configuration mistake might affect every zone at once. These situations demonstrate an important cloud engineering principle: redundancy helps only when the complete application is designed to use it effectively.
This article explores what can still go wrong in a multi-AZ architecture and how developers can prepare for these failures.
Understanding AWS Regions and Availability Zones
An AWS Region is a geographical area containing multiple Availability Zones. Each Availability Zone consists of one or more data centers with independent power, networking, and other infrastructure.
Availability Zones within a Region are connected through low-latency, high-throughput networking. Their physical separation helps limit the impact of certain infrastructure failures.
For example, if an EC2 instance in one Availability Zone becomes unavailable because of a localized infrastructure problem, instances running in another Availability Zone may continue operating.
However, AWS does not automatically distribute every application resource across multiple Availability Zones. Developers must configure their compute resources, databases, networking, and other components according to their availability requirements.
What Does a Multi-AZ Architecture Look Like?
Consider an online shopping application deployed across two Availability Zones.
The architecture includes:
- An Application Load Balancer to distribute incoming requests.
- EC2 instances running the application in separate Availability Zones.
- An Amazon RDS database configured for Multi-AZ availability.
- Monitoring and health checks to identify failures.
Under normal conditions, the load balancer distributes requests across healthy application instances.
If one Availability Zone becomes impaired, traffic can be directed to healthy resources in the remaining zone, provided those resources have sufficient capacity and the required dependencies remain available.
The objective is to reduce downtime and avoid relying on a single infrastructure location.
What Can Still Go Wrong?
1. Insufficient Capacity in the Remaining Zone
Imagine an application running four EC2 instances, with two instances in each of two Availability Zones.
If one zone becomes unavailable, only two instances remain.
If those instances cannot handle the full volume of incoming requests, the application may become slow or start returning errors even though part of its infrastructure is still working.
This problem can occur when developers design an application for normal traffic rather than planning for a zone failure.
How to reduce the risk:
- Estimate the capacity required during a zone failure.
- Configure Amazon EC2 Auto Scaling across multiple Availability Zones.
- Monitor CPU utilization, request latency, and application errors.
- Test whether the remaining instances can handle increased traffic.
High availability requires enough surviving capacity, not just multiple copies of a resource.
2. The Database Becomes a Single Point of Failure
An application may run across multiple Availability Zones while relying on a database that is deployed in only one zone without a suitable failover configuration.
If that database becomes unavailable, the application servers may continue running but cannot complete operations that require database access.
Amazon RDS Multi-AZ deployments provide a way to improve database availability. Depending on the deployment type, AWS can automatically fail over to a standby database or use a Multi-AZ database cluster configuration.
However, failover can still cause a temporary interruption. Applications must also handle reconnections, retry failed operations appropriately, and tolerate brief periods of database unavailability.
How to reduce the risk:
- Select a database configuration that meets the application's availability requirements.
- Understand the failover behavior of the chosen database service.
- Configure connection handling and suitable retry logic.
- Test application recovery after a database failover.
Multiple application servers cannot compensate for a database dependency that remains unavailable.
3. Configuration Errors Affect Every Availability Zone
Not every failure is caused by physical infrastructure.
Suppose a developer changes a security group, route table, or application configuration and accidentally prevents all application instances from communicating with the database.
Even if the application is deployed across three Availability Zones, the same configuration error may affect all three.
This is a shared failure caused by a common dependency or change rather than a problem isolated to one zone.
How to reduce the risk:
- Review infrastructure changes before applying them.
- Use AWS CloudFormation or other infrastructure-as-code tools to manage configurations consistently.
- Test important changes in a non-production environment.
- Maintain a rollback plan for configuration changes.
- Avoid introducing unnecessary shared dependencies.
Redundancy protects against certain failures, but it cannot automatically protect against every mistake replicated across the entire application.
4. The Load Balancer Has No Healthy Targets
An Application Load Balancer can distribute requests across healthy registered targets in multiple Availability Zones.
However, what happens if every registered application instance fails its health checks?
The load balancer may have no healthy target to receive requests. Users can experience errors even if the load balancer itself is operational.
Health checks can also be misleading if they check only whether a server is running instead of whether the application can perform its essential functions.
How to reduce the risk:
- Configure meaningful health checks.
- Monitor target health and application response times.
- Keep sufficient healthy application instances available.
- Ensure that application startup and recovery procedures work correctly.
A healthy load balancer does not guarantee that the application behind it is healthy.
5. Shared Dependencies Cause Wider Failures
An application may use several services, including a database, authentication provider, caching layer, and external API.
Even when the application servers are distributed across Availability Zones, one shared dependency may affect all of them.
For example, if an application depends on an external API that becomes unavailable, requests that require that API may fail regardless of where the application servers are running.
Similarly, a poorly designed shared caching layer or a centralized component can become a bottleneck.
How to reduce the risk:
- Identify dependencies that every request requires.
- Monitor the health of critical services.
- Use appropriate timeouts and retry limits.
- Provide fallback behavior when optional dependencies fail.
- Design the application to isolate failures where possible.
Reliable cloud architecture requires examining the entire dependency chain rather than checking only the locations of EC2 instances.
6. Data Replication Does Not Always Mean Immediate Recovery
Some AWS services replicate data across Availability Zones automatically, while other services require users to enable or manage replication.
Even when replication is configured, recovery behavior depends on the service and its architecture.
For example, a database failover may require the application to reconnect. Self-managed data stored on individual EC2 instances may require separate replication and recovery procedures.
A backup is also not the same as a highly available live replica. Backups help recover data, but restoring them may take time.
How to reduce the risk:
- Understand the data durability and replication behavior of each service.
- Use appropriate Multi-AZ database configurations.
- Maintain backups and define recovery objectives.
- Test restoration and failover procedures.
- Account for possible data loss when selecting a recovery strategy.
A multi-AZ design should consider both whether data survives a failure and how quickly the application can resume normal operation.
7. A Regional Failure Affects More Than One Zone
Availability Zones are designed to isolate many infrastructure failures, but multiple zones within a Region still belong to the same broader geographical area.
A disruption affecting a wider area or a Regional service can affect components in multiple Availability Zones.
For workloads with strict disaster recovery requirements, a second AWS Region may provide an additional layer of protection.
However, multi-Region architecture introduces additional complexity involving data replication, traffic routing, deployment consistency, and recovery testing.
For many applications, a properly designed multi-AZ architecture is sufficient. Multi-Region deployment should be based on actual business and recovery requirements.
How to Test Multi-AZ Reliability
Developers should not assume that an architecture will recover correctly simply because it uses multiple Availability Zones.
A practical reliability-testing process includes:
- Review the architecture: Verify that compute, databases, and other critical components use appropriate multi-AZ configurations.
- Check capacity: Determine whether the surviving resources can handle expected traffic during a zone impairment.
- Test health checks: Confirm that unhealthy application instances are detected and removed from traffic.
- Validate database recovery: Test supported failover procedures in a controlled environment.
- Review monitoring: Ensure that alerts identify application errors, latency increases, and dependency failures.
- Practice recovery: Document recovery procedures and test them periodically.
Testing should be performed in an appropriate test environment with safeguards to avoid disrupting production services.
Best Practices for Building a More Resilient AWS Architecture
The following practices help improve reliability:
- Deploy production compute resources across multiple Availability Zones.
- Use load balancing to route traffic to healthy targets.
- Configure Auto Scaling with suitable minimum, desired, and maximum capacities.
- Choose database configurations that support the required availability and recovery behavior.
- Monitor critical application dependencies.
- Automate recovery where supported.
- Maintain backups and test restoration procedures.
- Use infrastructure as code to reduce configuration inconsistencies.
- Define recovery time and recovery point objectives based on business requirements.
- Consider multi-Region disaster recovery when the risks and requirements justify it.
These practices work together. No single service can guarantee that every part of an application will recover automatically.
Conclusion
Deploying an application across multiple Availability Zones is an important step toward building reliable cloud infrastructure. It helps isolate failures and allows applications to continue operating when a single zone becomes impaired.
However, multi-AZ deployment is not a complete solution on its own. Insufficient capacity, database interruptions, shared dependencies, configuration mistakes, and regional disruptions can still affect application availability.
The most reliable architectures combine redundancy with health monitoring, automated recovery, sufficient capacity, resilient application design, and regular testing.
For AWS beginners, the key lesson is simple: high availability is not achieved by placing resources in multiple locations alone. It comes from designing, testing, and maintaining the entire application so that it can handle failures gracefully.
Further Reading
- AWS Well-Architected Framework — Deploy the workload to multiple locations: https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_fault_isolation_multiaz_region_system.html
- Amazon EC2 Resilience: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/disaster-recovery-resiliency.html
- AWS Well-Architected Framework — Fail over to healthy resources: https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_withstand_component_failures_failover2good.html
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article