What is high availability?
High availability (HA) means your application is designed to keep running even when individual components fail. Instead of a single server that, if it goes down, takes your whole product with it, an HA setup distributes load across multiple instances and automatically routes traffic away from anything that fails.
The standard measure is uptime SLA. 99.9% uptime allows ~8.7 hours of downtime per year. 99.99% allows ~52 minutes. Achieving anything beyond 99.9% typically requires redundant infrastructure — multiple app servers, a replicated database, a CDN for static assets, and automated health checks that trigger failover within seconds.
This is not the default. Most applications start on a single server or a single-region PaaS. HA is something you build when uptime becomes a hard business requirement.
When does your app need it?
- You have a signed SLA committing to uptime targets (government, enterprise, financial services)
- Downtime has a direct, measurable cost — every minute offline means lost revenue or legal liability
- You're operating in healthcare, payments, or critical infrastructure where availability is regulated
- You're serving users across multiple timezones and a maintenance window doesn't exist
- Your current single-region setup has already experienced outages that cost you customers
- You're preparing for a significant traffic event (launch, product hunt, media coverage) that could overwhelm a single instance
How much does it cost?
Adding high availability and multi-region deployment typically adds 8–16 hours of development — roughly $1,000–$4,000 AUD.
Lower end: Horizontal scaling on a single PaaS (Railway, Render, Fly.io) with auto-scaling rules, health checks, and a managed PostgreSQL database with daily backups. This gets most apps to ~99.9% uptime without significant operational complexity.
Higher end: Multi-AZ or multi-region AWS deployment with an Application Load Balancer, ECS or EKS container orchestration, RDS Multi-AZ with automated failover, read replicas for query distribution, a CDN (CloudFront) for static assets, and automated runbooks for incident response. This is genuinely complex infrastructure work.
How it's typically built
On AWS, the standard HA stack uses an Application Load Balancer distributing traffic across multiple ECS tasks in different Availability Zones. The database is RDS PostgreSQL with Multi-AZ enabled — AWS automatically maintains a standby replica and promotes it within ~60 seconds of a primary failure.
For teams on simpler platforms, Railway and Render offer built-in horizontal scaling and managed databases with replication. This covers the majority of HA needs without requiring deep AWS expertise.
Read replicas offload reporting and analytics queries from the primary database, improving both performance and resilience. A CDN handles static assets and can continue serving cached content even during backend outages.
Health checks — HTTP endpoints your load balancer polls every 30 seconds — are the mechanism that triggers automatic instance replacement when something stops responding.
Questions to ask your developer
- What uptime SLA are you actually committing to? The answer determines how much HA investment is justified.
- Is Multi-AZ enough, or do you need multi-region? Multi-region is dramatically more complex and expensive — most apps don't need it.
- What's the recovery time objective (RTO)? Knowing how fast you need to recover helps size the solution correctly.
- What's the database failover strategy? Automatic failover (RDS Multi-AZ) vs manual recovery are very different operational postures.
- How will you test that failover works? HA that hasn't been tested hasn't been validated — ask about chaos/fault injection testing.
See also: Security audit and pen test · Background jobs · App cost calculator