High Availability Versus Budget Scenario

Goal

Apply the chapter's reliability and cost model to a workload that wants near-zero downtime without unlimited spend.

The Short Version

When business ambition exceeds budget, the architect's job is not to repeat "it depends." The job is to translate the desired outcome into recovery targets, reject patterns that are not financially believable, and recommend the strongest posture the team can truly operate.

The durable idea is:

Reliability architecture earns trust when it states both what the design protects and what it intentionally does not buy.

The Scenario Frame

A company runs a public digital platform that drives revenue all day. Leadership asks for near-zero downtime, but the budget does not support full active-active operation across two Regions.

The architecture team should slow the conversation down and ask four questions:

1. What outage duration becomes unacceptable for the business?

2. How much recent data loss is acceptable?

3. Is the main concern an Availability Zone failure, a full regional issue, or both?

4. What level of recurring spend is actually approved, not just desired?

Once those answers are on the table, the design can become specific.

Recommended Architecture Posture

For this scenario, a credible recommendation is usually stronger than "single Region only" but lighter than "two fully active Regions."

Primary Region
  - Multi-AZ application tier
  - Load balancer across healthy targets
  - Multi-AZ managed data services where appropriate
  - Auto Scaling for burst absorption

Secondary Region
  - Replicated data and baseline infrastructure
  - Warm standby or pilot-light posture
  - Route 53 failover path and tested recovery runbooks

This design says:

• Common failures inside one Region should be handled automatically through Multi-AZ design.

• Larger regional disruption should trigger recovery into a secondary Region, but that secondary Region does not need to run at full production scale all the time.

• The business pays for meaningful recovery capability without funding the highest possible architecture permanently.

Why Not Full Active-Active?

Full active-active multi-region could absolutely be more resilient, but it may be the wrong answer here for three reasons:

• The ongoing cost may exceed what the workload value can support.

• Cross-region data and traffic coordination may introduce application complexity the team is not ready to run well.

• A poorly operated active-active design can be weaker in practice than a well-tested warm-standby design.

This is an important architecture lesson: the best design is not the design with the longest feature list. It is the design with the strongest match between business value, failure scope, technical maturity, and budget.

A Clear Recommendation

A concise recommendation to leadership might sound like this:

We should design the workload to survive normal infrastructure failures automatically within one Region by using Multi-AZ deployment, load balancing, and Multi-AZ data services. For broader disaster recovery, we should maintain a secondary Region in a warm standby or pilot-light posture, with replicated data, tested failover, and enough baseline infrastructure to recover within the agreed target. Full active-active multi-region is possible, but it is not justified by the current budget or operating maturity.

That answer is credible because it includes both the protection and the limit.

Trade-Offs

Common Mistakes

• Accepting "near-zero downtime" without clarifying targets. This hides the real cost conversation.

• Presenting only the most resilient option. Architecture leadership includes narrowing the choices, not overwhelming the audience.

• Talking about trade-offs as weakness. Budget-aware reliability is not compromise in a negative sense. It is deliberate design.

If Someone Asks You

If someone asks, "How would you design for near-zero downtime when the budget is limited?" a clear answer is:

I would separate common failure handling from disaster recovery. First, I would make the primary Region strong with Multi-AZ design and automatic failover for localized issues. Then I would add a lighter secondary-Region recovery posture that meets the agreed RTO and RPO without paying for full active-active capacity all the time.

What You Should Remember

Architects earn confidence when they can say both yes and no clearly: yes to the protection the design delivers, and no to the expensive promises it does not pretend to buy.

The most important idea is this:

A mixed resilience posture is often stronger than an unaffordable ideal because it is more likely to stay implemented, tested, and trusted.

Questions to Check Your Understanding

1. Why can a mixed resilience posture be stronger than an unaffordable ideal?

2. How do recovery targets justify or reject multi-region investment?

3. What makes a budget-aware resilience recommendation credible?

Further Study

• Disaster recovery options in the cloud - Use this for AWS disaster recovery pattern guidance when weighing budget against recovery speed.

• REL10-BP01 Deploy the workload to multiple locations - Use this for AWS guidance on when Multi-AZ or multi-region deployment is appropriate.