Every machine fails sooner or later. A disk dies, an entire availability zone of a data center loses power, a cable gets cut. The question that defines a good cloud architect isn't "how do I prevent anything from breaking?" — it's "how do I make sure that when something breaks, the user doesn't even notice?". Designing for failure is the essence of high availability, and understanding the cost of downtime is what justifies the effort.
Region vs availability zone
Every cloud organizes its data centers at two scales, and mixing them up is a classic interview mistake. A region is a geographic area (e.g. São Paulo). Within each region there are several availability zones (AZs) — physically separate data centers with independent power and networking, but connected by fast links. AZs isolate local failures; regions isolate geographic disasters.
| Concept | Scale | Protects against |
|---|---|---|
| Zone (AZ) | Data center | Local power/hardware failure |
| Region | Geography | Regional disaster (flood, earthquake) |
Single point of failure
A single point of failure (SPOF) is any component that, on its own, takes down the entire system if it breaks. A single database server, a single load balancer, a single AZ. Good architecture is, in large part, the exercise of hunting down and eliminating SPOFs through redundancy.
If the answer to "what happens if this machine dies?" is "the system goes down", you've found a single point of failure. The architecture work is making the answer always be "another one takes over".
Redundancy and multi-AZ
The basic defense is having copies in different zones. Spreading your replicas across multiple AZs means the loss of an entire data center doesn't take the service down — traffic simply goes to the zones that are still standing. Orchestrators like Kubernetes make this easier by distributing replicas across zones.
Load Balancer (multi-AZ)
/ \
AZ-a AZ-b
[app][app] [app][app]
[réplica DB] ←sync→ [réplica DB]
Se AZ-a cai, AZ-b atende sozinhaRTO and RPO
To talk about disaster recovery precisely, two numbers matter:
- RTO (Recovery Time Objective) — how long you can be offline. How fast do you need to be back?
- RPO (Recovery Point Objective) — how much data you can lose. Backups from when?
An RTO/RPO of minutes is expensive; of hours, cheap. The business decides what it's worth.
The reliability vs cost trade-off
High availability isn't free. Each additional nine of uptime (from 99.9% to 99.99%) costs exponentially more in redundancy and complexity. The senior architect's role is to size this to the business value: a payment system justifies multi-region; an internal blog doesn't. Calculating the cost of downtime (revenue lost per minute) is what anchors this decision.
Managed services
Whenever possible, prefer managed services (databases, queues, load balancers that the cloud operates for you). They come with multi-AZ redundancy, backups and automatic failover built in — you buy proven reliability instead of reinventing it, and you also reduce the team's operational load.
Conclusion
Architecting for the cloud means assuming failure will happen and designing the system to survive it. Spread across AZs, eliminate single points of failure, define RTO/RPO according to the business and consciously balance reliability against cost. Combined with infrastructure as code and observability, this way of thinking is what's expected of a senior DevOps engineer.