Independent cloud architecture reference

The AWS decisions that are hard to reverse

Subnet layout, account boundaries, connectivity and recovery posture cost almost nothing to get right on a whiteboard and a great deal to change once production depends on them. A practitioner’s reference to the trade-offs, and which one to take when.

Browse the reference Try the subnet planner

Independent publication. AWS Networks is not affiliated with, sponsored by, or endorsed by Amazon Web Services, Inc. or Amazon.com, Inc. Nothing here is official AWS documentation. Read the full independence statement

Requests spread across AZ-A, AZ-B and AZ-C. The primary database in AZ-B replicates synchronously to a standby in AZ-A.

  1. 01Steady state
  2. 02Zone impaired
  3. 03Traffic shifts
  4. 04Standby promoted
  5. 05Recovered
Illustration of a general multi-AZ pattern — not a deployed customer environment. Conceptual sequence, no timings implied. It shows Availability Zones within one Region; DNS is a name lookup beside the request path, not a hop on it. The Multi-AZ database uses two of the three zones.

Recovery posture · across Regions

What is already running decides how much is left to do

AWS describes four disaster-recovery strategies for losing a whole Region. They sit on one axis: the more of the recovery Region you keep running before a disaster, the less you have to build during one — and the more it costs you every month. Which rung is right depends on recovery objectives only you can defend.

Work out which rung your objectives imply →

The primary Region is healthy. Each rung shows what its recovery Region already has running.

1

Backup and restore

  1. Serving trafficNo
  2. Application serversNot provisioned
  3. Network and core servicesNot provisioned
  4. DataBackup copies

At disaster time: restore data from backups and provision the infrastructure from templates.

2

Pilot light

  1. Serving trafficNo
  2. Application serversDeployed, switched off
  3. Network and core servicesRunning
  4. DataContinuously replicated

At disaster time: start the application servers and scale up; the data is already there.

3

Warm standby

  1. Serving trafficNo production traffic yet; can take reduced load immediately
  2. Application serversRunning, reduced capacity
  3. Network and core servicesRunning
  4. DataContinuously replicated

At disaster time: redirect traffic to the already-running stack, which can take reduced load at once, then scale it up to full capacity.

4

Active/active

  1. Serving trafficYes, both Regions
  2. Application serversRunning, full capacity
  3. Network and core servicesRunning
  4. DataReplicated between Regions

At disaster time: route traffic away from the failed Region; the other is already serving.

  • Running
  • Running, reduced
  • Stored or switched off
  • Absent

Illustration of the general pattern, drawn from AWS’s published disaster-recovery guidance — not a deployed customer environment. The drill shows how much recovery work each strategy still has to do, not how long it takes; no recovery times or prices are implied. This ladder compares Regions; the animation above compares Availability Zones inside one Region.

The reference

All resources

Planning tools

Work the problem, not the article

These run entirely in your browser. Nothing you type is sent anywhere, stored, or logged.

VPC and subnet planner

Divide a VPC CIDR across availability zones and tiers, with the five addresses AWS reserves in every subnet accounted for rather than ignored.

Recovery strategy selector

Enter the recovery objectives you can actually defend and see which of the four recovery patterns they imply — and what each one commits you to.

Migration readiness check

A structured pre-migration review across landing zone, networking, identity, data and operations, scored by section so the gaps are visible.

Method

Why this reads differently

Most AWS writing is either certification material or a vendor’s pitch wearing a technical costume. Both optimise for something other than your decision. This reference states the trade-off, names the condition under which each option is right, and says plainly where the answer depends on facts only you have.

Where a figure would change the recommendation — a price, a service limit, a failover time — it is cited against current AWS documentation or left out entirely, because a stale number in a reference is worse than no number. Nothing here is sponsored, and no service is recommended because of a commercial relationship.

Editorial standards · About this site