Day 5 - Week 10 Comprehensive Review: Backup, DR, HA as One Picture

Week 10 's throughline was one question: "When original disappears, where do we restart?" And answer split two axes—how much we can lose (RPO) and how fast we recover (RTO). Backup is RPO reduction game; availability/DR is RTO reduction game. All tools this week were choices on these two axes, at what cost reaching what point.

This review doesn't list concepts; rather reweaves why tools diverge. Then new scenarios in exams become solvable by asking "RPO or RTO problem? Same region or cross-region? Data or workload?"—tool reverse-engineered.

Week 10 at a Glance

RPO and RTO—Two Axes Through Week 10

All recovery design reduces to two numbers. RPO (Recovery Point Objective) is "how much past data can we lose"—gap between last backup/replication and disaster moment. RTO (Recovery Time Objective) is "how long can disaster-to-recovery-complete take." Smaller numbers, steeper cost curves. RPO 0 (zero data loss) demands sync replication (Multi-AZ); minute-level RTO demands immediately-bootable copies (DRS, Aurora Global); both burn money always.

This table solves 90% of exam scenarios. "No data loss" → RPO 0 → Multi-AZ. "Region failure, 1-min recovery" → Aurora Global DB. "Min offline cost + minute recovery" → DRS. Read RPO/RTO requirements and cost constraints; tools nearly auto-decide.

Pattern 1: DLM vs AWS Backup—Lightness vs Integration Fork

Same "auto backup" but boundaries clear. DLM is EBS volume/AMI-only lightweight scheduler, tag-based snapshot creation, retention/Cross-Region replication automation, policy itself free. AWS Backup is multi-service unified platform covering RDS, DynamoDB, EFS, FSx, S3, with Backup Audit Manager compliance validation too. EBS-only? DLM. Multiple services + audit? AWS Backup.

Pattern 2: Three WORM Locks—Same Model, Different Resources

Week 10 saw "issuer can't unlock" immutable storage thrice. All same WORM model (1990s finance regulation's physical WORM optical disc ancestry) applied to different resources.

Key commonality: Compliance mode neither root nor AWS can unlock. "Admin can't delete" means "attacker can't delete"—ransomware defense and regulatory WORM essence. Governance is mistake-prevention guardrail (authorized can unlock).

🔍 Deeper Dive: Why all three Locks mandate Versioning or equivalent immutable version tracking: immutability means "lock specific version," not "lock key." Same-key overwrites break "unchangeable" promise; each write needs unique version ID (version-ID) and individual lock for WORM. S3 Object Lock requiring Versioning, EBS Snapshot inherently version-immutable, Backup recovery points with unique IDs—all same reason. Regulatory audit proving "post-creation unchanged" requires not just unchangeable flag but "each version uniquely identified·locked"—immutable version chain proves no tampering.

📚 Case Study: That Compliance modes consistently demand "after cooling-off even issuer can't" seems overkill but defines pass/fail in real regulatory audits. Finance/medical auditors ask "can admin delete if deciding to?" Possible (Governance) means changeable, WORM-unqualified. Compliance mode third-party (Cohasset Associates) validates SEC 17a-4/FINRA/CFTC compliance, providing legal audit submission grounds. "Inconveniently undeletable" is regulation trust price; three Locks' shared design lets you choose convenience (Governance) or regulation (Compliance) per resource.

Pattern 3: Multi-AZ vs Read Replica—Sync/Async Determines All

Week's most-asked and most-wrong point. Similar surfaces, opposite underneath.

Wrong patterns: Read Replica for "availability," Multi-AZ for "read distribution." Multi-AZ Standby can't even read; Read Replica async means not RPO 0. Need both? Use together.

Pattern 4: Same Region vs Cross-Region—DR Boundary Line

Most-asked trap: Multi-AZ isn't DR. Survives single-AZ failure within region but helpless region-wide (sync can't cross regions). Region DR needs separate tools.

Same Region (AZ failure prep)         Cross-Region (region failure prep = DR)
─────────────────────────            ───────────────────────────────────
RDS Multi-AZ (sync)                   Cross-Region Read Replica (RDS)
Multi-AZ DB Cluster                   Aurora Global Database (RPO<1s)
S3 (auto multi-AZ)                    S3 Cross-Region Replication
EBS Snapshot                          DLM/Backup Cross-Region Copy
                                      DRS (workload failover)

Pattern 5: Data vs Workload—What Recovers

S3 Replication, DLM, AWS Backup replicate/preserve data. Separate work rebuilds servers from that data. DRS entire workload (OS/apps/data) bootable elsewhere within minutes. "Datacenter to AWS failover, minimize offline cost" is DRS. "S3 objects to another region" is CRR. "Keep on-prem app, S3 backend only" is Storage Gateway.

💡 Related Theory: Week 10's meta-pattern: "separate state(state) and change(change), time becomes controllable." EBS incremental snapshots (base + change blocks), PITR (base + transaction logs), Aurora Backtrack (log rewind), S3 Versioning (version chain) all manage data as "basis + post-changes," not "copy entire state each time." This separation enables arbitrary-point restoration, block sharing, fast rewind. Functional persistent data structures, Git, event sourcing use identical principle—immutable snapshots for state, append-only logs for change lets past reconstruction freely.

📝 Practice Questions

Click a choice to reveal the answer and explanation.

Question 1

Operator deregistered dozens unused golden AMIs but storage costs barely dropped. Cause and fix?

• AAMI deletion is async, background cleanup takes days, snapshots auto-reclaimed later
• BAMI deregister removes boot recipe only, EBS snapshots stay, must delete separately or use DLM
• CAMI itself has no storage charge; snapshot costs are standard-rate, won't drop
• DTerminating EC2 instances launched from AMI auto-cleans related snapshots

Question 2

Company wants unified backup for RDS/EBS/DynamoDB/EFS, auto-verify "all prod resources backed up," generate compliance reports. Appropriate config?

• ASeparate DLM policy per resource type, tag-based snapshots, auto Cross-Region replication
• BAWS Backup Backup Plan + Backup Audit Manager Framework
• CEventBridge schedule Lambda calling each service snapshot API, results to DynamoDB
• DManual periodic snapshots, track in spreadsheet

Question 3

Ransomware attacker steals operations account admin, deletes backups. Regulation mandates issuer-undeletable backups. Strongest structure?

• ADeny DeleteObject in operations account IAM, SCP organization-level API block
• BCross-Account separate central vault with Compliance Vault Lock
• CHourly backup frequency so recent recovery point survives, RPO tiny
• DAll users forced MFA, MFA Delete on deletions

Question 4

Wrong DELETE at 2:30 PM, must restore RDS before then. Yesterday dawn snapshot only loses day's data. Needed feature?

• ARestore yesterday snapshot, manually re-input post-snapshot changes from app logs
• BPoint-in-Time Recovery (PITR)—base snapshot + transaction log replay, new instance arbitrary second
• CMulti-AZ failover, promote Standby to pre-DELETE state
• DPromote Read Replica with replication lag still not reflecting DELETE, independent instance

Question 5

"Single AZ failure, no data loss, automatic recovery" goal. Exact RDS feature?

• ARead Replica in different AZ, promote on failure
• BMulti-AZ—sync to Standby in different AZ, RPO 0, auto failover
• CShort-interval auto snapshots, restore from latest on AZ failure
• DCross-Region Read Replica, switch to other-region copy on failure

Question 6

DB read load (analytics/reports) surges mid-operation. Cost-effectively distribute reads?

• AVertically scale DB to bigger instance type, throughput increases together
• BAdd Read Replica, separate endpoint distributes reads
• CEnable Multi-AZ, distribute analytics/reports to Standby
• DHigher-frequency auto snapshots, restore separate instance for analysis

Question 7

Global users need fast reads from nearby regions + region DR (RPO of seconds). Most fit?

• ARDS Multi-AZ different-AZ Standby, HA+fast failover
• BAurora Global Database—up to 10 Secondary regions, storage-layer replication RPO seconds/RTO minutes
• CMultiple Read Replicas single region, Route 53 latency routing nearest
• DDynamoDB Multi-AZ, global read+region DR

Question 8

Lambda connection surge to RDS exceeds max-connections limit. Root fix?

• AUpsize DB instance, lift max_connections ceiling
• BRDS Proxy—connection pool, multiplexing few real connections
• CEnable Multi-AZ, distribute connections to Standby
• DAdd Read Replica, spread connections to replicas

Question 9

Company auto-replicates S3 data to another region's DR. Required prerequisite?

• ARun DataSync task periodically, sync objects to other-region bucket
• BS3 Cross-Region Replication + both-side Versioning + IAM Role
• CStorage Gateway File Gateway caches/uploads to other-region bucket
• DLifecycle Policy transitions objects to other-region Glacier tier

Question 10

Datacenter to AWS DR failover possible, minimize offline cost, minute-level recovery RTO. Which tool?

• AS3 Replication to other-region, rebuild servers from that data on disaster
• BAWS Elastic Disaster Recovery (DRS)—block-level CDP, Staging small offline, real-size launch on failover
• CStorage Gateway backup on-prem volumes, restore to EC2
• DDataSync periodically transfer on-prem files, use for recovery

Question 11

Regulation mandates S3 objects 5-year unchangeable/undeletable. Which feature and prerequisite?

• ABucket/IAM policy deny DeleteObject/PutObject to all
• BS3 Object Lock Compliance + 5yr retention, Versioning required
• CCross-Region Replication, preserve if one side changes
• DGlacier Deep Archive, cold tier 5-year storage discourages modify

Question 12

DR failover new volume from big EBS snapshot, first IO slow, recovery delayed. Cost-aware fix?

• ARe-create snapshot, fill all blocks in new fully-hydrated snapshot, rebuild volume
• BFast Snapshot Restore (FSR) failover-target AZ only, pre-hydrate
• CChange volume type gp2→gp3, lift baseline IOPS/throughput
• DBigger instance type, higher EBS bandwidth absorbs initial IO

🔮 Week 11 Preview

Week 11 is Performance·Cost Optimization—operators' daily work. Compute Optimizer right-sizing, Trusted Advisor's 5 check categories, Cost Explorer/Budgets/Cost Allocation Tags for visibility, Savings Plans/Reserved Instances/Spot for cost cuts. Week 10 was stability—"lose nothing, recover fast"; Week 11 is efficiency—"same stability, cheaper."