LEARN. PRACTICE. GROW.Concept and mechanism
Availability, read scaling, and data recovery are different capabilities. An RDS Multi-AZ DB instance with a single standby uses it for availability without offering it as a read target. Asynchronous read replicas can lag; reads needing fresh state require a compatible path. In an Auto Scaling group, EC2 health does not replace ALB application health. ELB health-check integration must be configured when that state should drive replacement. Scaling also respects limits: reaching the group maximum prevents further growth without review even if a policy keeps requesting capacity.
Guided application
RDS point-in-time restore creates another instance. Plan configuration, endpoint, access, and validation before redirecting consumers. Recovery timing should include a usable service rather than merely a created resource. In a rehearsal, unavailability at 10:00 and validation at 10:35 gives 35 minutes; recovering data through 09:50 leaves a ten-minute gap. With RTO 45 and RPO 5, only RTO is met. AWS Backup rehearsals need validation and controlled cleanup. In S3, distinguish a delete marker from deleting a version: when earlier versions exist, identify the correct copy and recover with authorization while preserving retention requirements.
A DR report should distinguish outage start, infrastructure readiness, service validation, and recovered data point, with functional-check results.
Common pitfalls
Backup treated as restore proof; standby treated as read replica; ALB unhealthy treated as automatic replacement without integration; RTO confused with RPO.
Related topics: Stacks, images, and deployments · Controlled operational automation
Demonstrate service outcome and data state against agreed objectives.
Reference: AWS Backup restore testing · SOA-C03; exam guide 1.1