Cloud Computing Architecture Guide

Pressure-Testing Risk, Operations, Cost, and Change

Goal

Challenge a promising design outside its happy path and turn findings into owned decisions.

Follow Critical Journeys

Do not review every box equally. Select critical user and operator journeys, then apply probes:

  • What happens under overload, dependency delay, zone or region loss?

  • What happens after credential compromise, corrupt data, or abusive traffic?

  • How is a failed release stopped, and can state changes be reversed?

  • Who detects the problem, obtains access, decides, communicates, and recovers?

  • Which quotas and cost dimensions grow fastest?

  • Which manual step is both powerful and fragile?

Managed services change responsibility; they do not remove customer decisions about configuration, access, data, application recovery, observability, and rehearsed procedures.

Turn Concerns into Risk Work

Write risks as cause, event, and impact: "Because regional promotion has never been rehearsed, a primary-region loss may exceed the recovery objective and extend checkout outage." Record likelihood, impact, current controls, residual risk, owner, and action.

Choose an action: mitigate now, test to gain evidence, transfer, avoid, or explicitly accept. Technical teams can describe residual risk; the accountable business owner accepts business impact.

Example: Multi-Region Public API

The API uses a second region, but data movement is the strongest cost driver and failover has never been rehearsed. Follow request admission, authentication, writes, asynchronous work, telemetry, and operator access through region loss.

The review finds that traffic can switch before data promotion is safe, queue consumers may process in both regions, and dashboards depend on the failed region. Instead of debating the diagram, run a bounded recovery exercise. Add a promotion guard, define consumer fencing, place essential evidence outside the failure boundary, measure cross-region cost, and assign failback ownership.

Common Mistakes

  • Reviewing components instead of critical journeys.

  • Treating a managed service as removal of recovery responsibility.

  • Recording a risk without owner or next action.

  • Adding controls without checking operator usability.

  • Discussing a testable failure for weeks instead of running a safe experiment.

If Someone Asks You

How would you review this design before approving it?

"I follow critical journeys through load, abuse, dependency failure, release, regional loss, and recovery. I verify ownership, evidence, access, capacity, and cost, then turn gaps into owned mitigations, experiments, or explicit residual-risk decisions."

What You Should Remember

Follow critical journeys through stress, failure, change, and recovery; then assign the remaining risk.

Questions to Check Your Understanding

  1. Which pressure test should be run rather than debated?

  2. What operational evidence is missing from the failure boundary?

  3. Who can accept residual business risk?

Further Study