Two Cloud Outages in 24 Hours: A Practical Resilience Plan for Founders

01Executive summary

• Azure and AWS experienced separate regional connectivity incidents within roughly 16 hours, showing how local failures can reach many customer-facing products.
• Buying services from multiple clouds is not the same as making one product capable of failing over between them.
• Founders should set recovery targets from business loss, then fund the cheapest architecture that can meet them.
• The most valuable work is often not active-active infrastructure. It is removing hidden dependencies, creating a useful degraded mode, and rehearsing recovery.
• Reliability is a product decision: customers experience checkout, login, and support—not regions, zones, or service credits.

02What happened

On July 23, 2026, traffic entering and leaving Microsoft's West US region was disrupted between 14:44 and 19:41 UTC. Network World reported that an automated maintenance process isolated more network devices than the initial safety check covered, removing critical routes. Workloads communicating entirely inside the region could continue, but traffic crossing its boundary could not.

On July 24, AWS acknowledged connectivity problems in its Oregon region at 4:40 a.m. PDT. The affected list grew to seven services, including Direct Connect, Global Accelerator, API Gateway, EC2, and ECS. AWS said the issue was resolved shortly after 9 a.m. ET, with no indication of data loss or a global infrastructure failure. TMC Insight connected user reports to services including Apple Pay, DoorDash, Reddit, and Hulu.

The incidents had different causes and impact. Together they expose the same strategic gap: provider recovery and customer recovery are not the same plan.

03Why businesses should care

Cloud availability promises describe provider infrastructure. Your revenue depends on a complete customer journey: DNS, login, application code, data, payments, notifications, and support. One concentrated dependency can stop the journey even when every other component is healthy.

For a marketplace, two unavailable hours can mean abandoned orders and sellers missing fulfillment windows. For a healthcare workflow, it can mean staff returning to phone calls and paper. For an internal operations tool, it can halt dispatch or invoicing. The technical incident ends when connectivity returns. The business incident ends after backlogs, refunds, and customer confidence recover.

Service credits rarely cover that loss. Founders therefore need a business continuity decision, not a promise that engineering will "make it highly available."

04Buy recovery by customer impact

Start with two plain-language targets. Recovery Time Objective (RTO) is how long a customer journey may be unavailable. Recovery Point Objective (RPO) is how much recent data the business can afford to lose. Set both for each critical journey—not once for the whole company.

1. Restore later. Backups and reproducible infrastructure fit low-frequency admin tools where hours of downtime are acceptable.
2. Degrade gracefully. Keep browsing available while queueing checkout, or preserve order capture while delaying recommendations and reports.
3. Keep a warm standby. Run a smaller copy in a second region that can scale when the primary fails. This costs more but recovers faster.
4. Serve from multiple regions. Active-active systems can approach zero downtime, but data conflicts, operations, and testing make them the most expensive choice.

AWS describes these strategies as a progression in cost and complexity, from backup and restore to multi-region active-active. Its reliability guidance says the choice should follow recovery objectives. That is more useful than copying a reference architecture built for a different risk profile.

05Risks that make failover fail

• Paper redundancy. A second region exists, but identity, secrets, DNS, deployment tools, or observability still depend on the first.
• Untested recovery. Replicas are not a recovery plan until a team has routed real test traffic through them and measured the result.
• Replicated mistakes. Multi-region replication can copy corrupt data or accidental deletion. Point-in-time backups still matter.
• Failover without capacity. The backup works during a demo but cannot absorb production traffic, connection volume, or support demand.
• Overengineering everything. Giving an internal reporting page the same recovery design as checkout creates cost and operational complexity without protecting equivalent value.

Microsoft's mission-critical guidance recommends active-active multi-region deployment for the highest availability needs. It also acknowledges the extra demands of data synchronization, regional capability, and measurable service targets. Redundancy is a trade, not a checkbox.

06A practical 30-day resilience review

1. List the three customer journeys whose interruption causes the fastest financial, safety, or trust damage.
2. Give each journey an owner, RTO, RPO, and cost-per-hour range. Let leadership approve the tradeoff.
3. Draw every required dependency, including identity, DNS, payments, third-party APIs, staff access, and deployment controls.
4. Choose a recovery tier for each journey. Design a degraded mode before paying for full duplication.
5. Run a tabletop exercise, then a controlled failover. Time detection, decision, traffic movement, data checks, and customer communication.
6. Turn failures into funded backlog items with owners and test dates. Rehearse quarterly and after major architecture changes.

A useful test is specific: "West-region traffic cannot reach our application. Can customers still place an order within 15 minutes, and can we reconcile every accepted payment?" A vague test—"Does disaster recovery work?"—will produce a vague answer.