Start with recovery objectives and known failure modes. Isolate critical paths, automate recovery, test backups and make degraded operation an intentional product state.
Availability begins with business tolerance
Highly available does not mean ‘uses multiple Availability Zones’. It means the system can continue delivering an agreed service when specific components fail. Define recovery time and recovery point objectives for each critical journey before choosing architecture.
A checkout, reporting screen and internal admin tool may deserve different targets. Uniform maximum availability adds cost and complexity without necessarily protecting what matters most.
Design around failure domains
Run stateless compute across Availability Zones and keep load balancing health checks independent of application process checks. Understand the behaviour of databases, queues, caches, DNS and identity dependencies during an AZ or regional impairment.
Remove shared single points that diagrams hide: one NAT gateway, a manual secret rotation step or a deployment pipeline tied to the failed region can prevent recovery even when compute is redundant.
Make degradation intentional
Not every dependency must be available for the product to remain useful. Queue non-critical work, serve cached data, disable expensive recommendations or switch important screens to read-only mode. Product teams should design and test these states rather than leaving them to emerge during an incident.
Use timeouts, bounded retries and circuit breakers carefully. Uncontrolled retries can multiply load and turn a partial failure into a wider outage.
Prove recovery
Backups are not a recovery strategy until a restore has succeeded within the objective. Automate infrastructure and application recovery steps, keep runbooks close to operational tooling and practise them with realistic data volumes.
Track recovery evidence: restore duration, failover behaviour, data loss and manual decisions. Architecture reviews should use those results, not only provider service guarantees.
Frequently asked questions
Does Multi-AZ make an AWS application highly available?
It protects against some infrastructure failures, but the application, data layer, network path, deployment process and dependencies must also tolerate failure.
When is multi-region architecture justified?
When business recovery objectives, regulatory needs or regional dependency risks cannot be met within one region—and the team can operate and test the added complexity.
Further reading
Explore official documentation for the tools and architecture patterns discussed in this guide.