Resilient Cloud Solutions

This domain is where the AWS Certified DevOps Engineer – Professional exam stops asking "can you automate a pipeline?" and starts asking "when a data center catches fire, does your architecture even notice?" At 15% of the exam it's tied for the third-largest domain, and it tests a different muscle than the automation domains around it: not how do I ship a change, but how do I design a system that keeps serving traffic when AWS's own infrastructure fails underneath it. This page covers multi-AZ and multi-region architecture, Auto Scaling policies, ELB health checks, Route 53 failover routing, and the four disaster-recovery patterns — backup-restore, pilot light, warm standby, and multi-site — with the RTO/RPO tradeoffs that separate them.

Why this is its own domain: the Well-Architected Reliability pillar

☺ Like you're 10: There's no single lesson elsewhere in this course that "is" this domain — it's a whole way of thinking AWS calls the Reliability pillar, and this page is where you learn it from scratch.

Unlike most of this exam blueprint, Resilient Cloud Solutions doesn't map cleanly onto one lesson you've already read — it's assembled from AWS's Well-Architected Framework, Reliability pillar, which the exam draws on directly. Five design principles from that pillar show up, in one disguise or another, in almost every question this domain asks:

• Automatically recover from failure. Monitor for the specific signals that predict or mark a failure and trigger automated recovery — that's the entire reason ELB health checks and Auto Scaling health checks exist.
• Test recovery procedures. A DR plan nobody has failed over is not a DR plan, it's a hypothesis. See Chaos Engineering & Game Days for how teams actually validate this.
• Scale horizontally to increase aggregate availability. Replace one large, precious resource with many small, disposable ones so any single failure is a rounding error, not an outage.
• Stop guessing capacity. Auto Scaling and on-demand infrastructure remove the old failure mode of under-provisioning for a peak nobody predicted correctly.
• Manage change through automation. Infrastructure changes applied by pipelines, not by hand — see this blueprint's own Configuration Management & IaC domain.

Hold onto that list. Every section below is one or two of these principles wearing a specific AWS service's name.

Multi-AZ and multi-region architecture

☺ Like you're 10: An Availability Zone is a separate building; a Region is a separate city. Spreading across buildings protects you from a fire in one; spreading across cities protects you from a flood that takes out the whole city.

An Availability Zone (AZ) is one or more discrete data centers with independent power, cooling, and physical security, connected to other AZs in the same Region by high-bandwidth, low-latency private links. A Region is a fully independent geographic area — typically three or more AZs — with its own power grid, its own network, and (critically) its own blast radius: a regional service disruption in us-east-1 does not touch eu-west-1. AWS guarantees the physical isolation; it is entirely on you to architect a workload that actually uses more than one AZ, because a single-AZ deployment gets none of that guarantee's benefit.

The default resilience baseline the exam expects you to reach for is multi-AZ, single-Region: an Application Load Balancer spanning at least two AZs, an Auto Scaling group with instances distributed across those same AZs, and a Multi-AZ RDS deployment (or Aurora, which is multi-AZ by design) with a synchronously-replicated standby. This defends against the AZ-level failures that are, in practice, far more common than a whole-Region event. Multi-Region is the next tier up — full or partial infrastructure duplicated into a second Region — reserved for workloads where a regional outage, data-sovereignty law, or global latency requirement makes single-Region insufficient. It costs more in every dimension: cross-Region data transfer, replication lag to reason about, and doubled operational surface area, so the exam expects you to justify it, not default to it.

Auto Scaling policies

☺ Like you're 10: Auto Scaling is the "stop guessing capacity" principle made real — instead of predicting how many servers you'll need, you tell AWS the rule and let it add or remove servers as reality unfolds.

An Auto Scaling group (ASG) is defined by a launch template, a minimum/maximum/desired capacity, and the set of subnets — normally one per AZ — it's allowed to place instances in. Distributing an ASG across AZs is, by itself, half of the multi-AZ story above; the other half is making sure it scales for the right reasons. The exam expects you to match a scenario to the correct policy type:

Two settings decide how gracefully an ASG treats replacement instances: the health check grace period gives a freshly-launched instance time to boot and warm up before Auto Scaling starts judging its health (skip this and a slow-booting app gets terminated in a loop before it ever gets healthy), and cooldown pauses further scaling activity after a simple-scaling action so the fleet has time to actually reflect the last change before the next decision is made. A JSON target-tracking policy, applied via the CLI, looks like this:

{
  "PolicyName": "cpu-target-tracking",
  "PolicyType": "TargetTrackingScaling",
  "TargetTrackingConfiguration": {
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ASGAverageCPUUtilization"
    },
    "TargetValue": 50.0,
    "DisableScaleIn": false
  }
}

aws autoscaling put-scaling-policy --auto-scaling-group-name web-asg --policy-name cpu-target-tracking --policy-type TargetTrackingScaling --target-tracking-configuration file://policy.json registers it. For the golden-image side of fast, predictable scale-out, see Immutable Infrastructure & Golden Images — a pre-baked AMI turns "launch a new instance" from a multi-minute configuration run into a near-instant boot, which matters enormously once you get to warm standby below.

ELB health checks

☺ Like you're 10: The load balancer is constantly knocking on every server's door asking "you okay in there?" — and it only sends customers to doors that answer.

A health check is how an Elastic Load Balancer decides which targets are allowed to receive traffic. For an Application Load Balancer, you configure a protocol (HTTP/HTTPS), a path (commonly a dedicated /health endpoint that checks the app's real dependencies, not just "is the process running"), a port, an interval, a timeout, and two threshold counts: how many consecutive successes mark a target Healthy, and how many consecutive failures mark it Unhealthy. A target that fails enough checks stops receiving new connections; in-flight requests are given a grace period — the deregistration delay (default 300 seconds) — to finish before the connection is forcibly closed, so a scale-in or a failed health check doesn't just amputate live requests.

The trap the exam sets here is the difference between an EC2 status check and an ELB health check as far as Auto Scaling is concerned. By default, an ASG's health check type is EC2 — it only replaces an instance if the underlying EC2 instance itself reports impaired. That misses the far more common failure: the instance is up, the OS is fine, but the application inside it has hung, deadlocked, or lost its database connection. Setting the ASG's health check type to ELB makes it trust the load balancer's judgment instead — if the ALB marks a target unhealthy, the ASG terminates and replaces it, closing that gap. This single setting is one of the most exam-tested details in the whole domain.

Route 53 failover and health-check routing

☺ Like you're 10: Route 53 is the phone operator who normally connects you to the main office, but automatically redirects your call to the backup office the moment the main one stops picking up.

Route 53 supports several routing policies — simple, weighted, latency-based, geolocation, geoproximity, multivalue answer — but the one this domain centers on is failover routing: a primary record and a secondary record, where the primary is tied to a health check. While the primary's health check passes, Route 53 answers DNS queries with the primary's endpoint. The moment it fails, Route 53 starts answering with the secondary — an active/passive pattern implemented entirely at the DNS layer, with no application-level redirect involved.

Route 53 health checks come in three flavors, and the exam expects you to pick the right one for the situation: an endpoint health check polls a public IP or domain over HTTP/HTTPS/TCP from a global fleet of checkers; a calculated health check combines other health checks with AND/OR/NOT logic (useful when "healthy" means several dependencies are all up); and a CloudWatch alarm health check reflects a CloudWatch alarm's state instead of polling anything directly — the only option that works for a private or otherwise unreachable resource, since it doesn't need network access to the endpoint at all.

{
  "Comment": "primary record, tied to a health check",
  "Changes": [{
    "Action": "UPSERT",
    "ResourceRecordSet": {
      "Name": "app.example.com",
      "Type": "A",
      "SetIdentifier": "primary",
      "Failover": "PRIMARY",
      "HealthCheckId": "abcd1234-health-check-id",
      "AliasTarget": {
        "HostedZoneId": "Z35SXDOTRQ7X7K",
        "DNSName": "primary-alb-1234.us-east-1.elb.amazonaws.com",
        "EvaluateTargetHealth": true
      }
    }
  }]
}

The secondary record is identical except "Failover": "SECONDARY", no health check requirement, and an AliasTarget pointing at the DR Region's load balancer. One detail the exam likes to probe: lowering DNS TTL does not guarantee an instantly fast failover. Route 53 will start answering differently the moment it observes a failure, but resolvers and clients that cached the old answer honor that cache until it expires — so a low TTL (60 seconds or less, set well before the incident, not during it) shrinks the failover window, but nothing shrinks it to zero. For coordinated, tested, one-action failover across multiple resources at once, AWS also offers Route 53 Application Recovery Controller (ARC) — worth recognizing by name, though check the current exam guide for how deeply it's covered.

Disaster-recovery patterns: trading cost for RTO and RPO

☺ Like you're 10: RTO is "how long until we're back," RPO is "how much data can we afford to lose" — and the four DR patterns are just four different amounts of money you can spend to shrink both numbers.

Two acronyms anchor every DR conversation, and the exam will test whether you can tell them apart under pressure: RTO (Recovery Time Objective) is the maximum acceptable downtime — how long until the workload is serving traffic again. RPO (Recovery Point Objective) is the maximum acceptable data loss, measured backward in time from the failure — if your last backup was 4 hours old when disaster struck, your RPO for that plan is 4 hours, no matter how fast you restore it. A simple way to keep them straight: RTO is about the clock going forward from the incident; RPO is about the clock going backward from the incident to your last good copy of the data.

AWS's whitepaper on disaster recovery names four canonical patterns, arranged along one continuous spectrum of cost versus speed:

Notice the diagram earlier on this page shows warm standby specifically — Region B is up and reachable, just scaled down. Drop it to pilot light and Region B's ALB and instances wouldn't be running at all, only the database replica; drop it to backup and restore and there'd be nothing in Region B but backups waiting to be restored onto infrastructure that doesn't exist yet. AWS Elastic Disaster Recovery (DRS) is the managed service purpose-built for pilot-light and warm-standby patterns — continuous block-level replication into a low-cost staging area that launches full instances only when you actually fail over.

Common exam traps in this domain

☺ Like you're 10: These are the specific ways this domain tries to trick you — memorize the trap, not just the fact.

• RDS Multi-AZ is not a read-scaling feature. The standby exists purely for synchronous failover and cannot serve read traffic directly; if the question is about scaling reads, the answer is a read replica, not Multi-AZ.
• ASG health check type defaults to EC2, not ELB. If a scenario describes an app hanging while the instance itself looks healthy, and Auto Scaling isn't replacing it, this default is almost always the reason.
• NLB cross-zone load balancing defaults to off; ALB's is always on. A scenario with an unbalanced NLB target group is testing this exact asymmetry.
• Low DNS TTL shrinks Route 53 failover time — it does not make it instant. Resolver and client-side caching still apply.
• RTO ≠ RPO, and the direction each one measures matters. RTO counts forward from the incident (how long to recover); RPO counts backward from the incident (how much data is lost since the last good copy).
• Pick the cheapest DR pattern that satisfies the stated RTO/RPO — see the callout above. "More resilient" is not automatically "more correct" if the requirement doesn't call for it.

Auto Scaling and ELB health checks decide who's allowed to serve traffic right now; the next domain is about proving, continuously, that the decision was correct — see Monitoring & Logging for the CloudWatch metrics, alarms, and log pipelines that feed every health check on this page, and Incident & Event Response for what happens the moment a failover actually fires. For provisioning a DR Region as code rather than by hand, see Configuration Management & IaC and the Terraform tool page; for the database replication mechanics behind pilot light and warm standby, see Database Change Management. And no DR plan earns any trust until it's actually been triggered on purpose — that's Chaos Engineering & Game Days.