Multi-Region, DR, Migration & Cheat Sheet

Table of Contents#

1. Why This Is the Capstone Part of the Series
2. AWS and the Four Classic DR Strategies, Revisited
3. Backup and Restore on AWS
4. Pilot Light on AWS
5. Warm Standby on AWS
6. Multi-Site Active-Active on AWS
7. AWS Backup — Centralized Backup Management
8. AWS Elastic Disaster Recovery (DRS)
9. Choosing a DR Strategy — The AWS-Specific Decision Framework
10. Multi-Region Architecture Patterns, Consolidated
11. Cost Optimization / FinOps on AWS
12. The AWS Well-Architected Tool, Revisited
13. Migration Strategies — The 6 R's
14. AWS Migration Hub and the Migration Toolkit
15. A Full Worked Example: A Complete Migration Plan
16. The Complete AWS Service Cheat Sheet
17. Cross-Series Concept Map
18. AWS Fault Injection Service — Chaos Engineering on AWS
19. Common Mistakes
20. Worked Practice Problems
21. Series Summary — The Complete AWS Cloud Architecture Picture

---

Why This Is the Capstone Part of the Series#

Every part of this series has built toward this one. Networking (Part 4), compute (Parts 3, 7), storage (Part 5), databases (Part 6), and traffic routing (Part 8) are the building blocks; security (Part 9) and observability (Part 10) keep them safe and visible; CI/CD (Part 11) deploys changes to them. This final part answers the question every one of those parts has been implicitly building toward: what happens when an entire region fails, and how do you get workloads INTO AWS in the first place? It's also where this series closes the loop with the Disaster Recovery & Business Continuity series, translating every strategy covered there into concrete AWS services and CLI commands.

---

AWS and the Four Classic DR Strategies, Revisited#

The Disaster Recovery series (Part 1) established four strategies along a cost/RTO/RPO spectrum — worth a fast recap before mapping each one to specific AWS services.

Diagram

---

Backup and Restore on AWS#

The cheapest, simplest strategy — regular backups to a SEPARATE region, restored only when disaster actually strikes.

Copy
# Cross-region S3 replication (Part 5) as the backup transport
aws s3api put-bucket-replication --bucket prod-data --replication-configuration file://cross-region-replication.json

# RDS automated backups can be copied cross-region
aws rds copy-db-snapshot \
  --source-db-snapshot-identifier arn:aws:rds:us-east-1:123456789012:snapshot:prod-snapshot \
  --target-db-snapshot-identifier prod-snapshot-dr-copy \
  --region eu-west-1

RTO/RPO reality check, worth stating precisely, directly reusing the Disaster Recovery series' cost curve: RTO here is measured in HOURS (spinning up fresh infrastructure from IaC templates, Part 11, and restoring data from backups takes real time) — the cheapest strategy on the spectrum, appropriate specifically for workloads where that RTO is genuinely acceptable.

---

Pilot Light on AWS#

A minimal, always-on core (typically just the database, kept continuously replicated) with everything else provisioned only during an actual failover.

Diagram

Copy
# Aurora Global Database (Part 6) as the continuously-replicated
# "pilot light" core
aws rds create-global-cluster --global-cluster-identifier prod-global --source-db-cluster-identifier prod-primary

# During an actual failover: launch compute FROM already-tested
# CloudFormation/CDK templates (Part 11) — this is precisely
# why those templates should be tested regularly, not just
# written once and forgotten
aws cloudformation create-stack --stack-name dr-failover --template-body file://app-stack.yaml --region eu-west-1

RTO/RPO reality check: RPO is very low (near-continuous database replication via Aurora Global Database), but RTO is measured in TENS OF MINUTES — the time to actually launch and configure compute from IaC templates, directly the same tradeoff already covered generically in the Disaster Recovery series.

---

Warm Standby on AWS#

A scaled-down, but ALREADY RUNNING, full copy of the stack in the DR region.

Copy
# An ASG (Part 3) already running in the DR region, at
# MINIMAL capacity, ready to scale up FAST (not from zero)
aws autoscaling update-auto-scaling-group \
  --auto-scaling-group-name app-asg-dr --min-size 2 --desired-capacity 2 --max-size 20 \
  --region eu-west-1

# During failover: scale UP fast, and shift Route 53 (Part 8)
# traffic
aws autoscaling set-desired-capacity --auto-scaling-group-name app-asg-dr --desired-capacity 20 --region eu-west-1
aws route53 change-resource-record-sets --hosted-zone-id Z1ABC2DEF3GHI --change-batch file://failover-to-dr.json

RTO/RPO reality check: RTO drops to MINUTES, since the stack is already running and just needs to scale up and receive traffic — directly using the Capacity Reservations already covered in Part 3 to GUARANTEE that scale-up capacity is actually available when needed, not just hoped for.

---

Multi-Site Active-Active on AWS#

Already fully worked in Part 8 — both regions running at full production capacity, continuously, both actively serving real traffic.

Diagram

RTO/RPO reality check: RTO approaches ZERO (Route 53 health checks simply stop routing to the failed region — no infrastructure needs to be started at all) and RPO is near-continuous — the most expensive strategy on the spectrum, since it means paying for TWO full production environments simultaneously, permanently, not just during a disaster.

---

AWS Backup — Centralized Backup Management#

Rather than manually configuring backup schedules per-service (RDS snapshots, EBS snapshots via Data Lifecycle Manager already covered in Part 5, DynamoDB backups), AWS Backup centralizes backup policy across nearly every AWS data service.

Copy
aws backup create-backup-plan --backup-plan '{
  "BackupPlanName": "org-wide-daily",
  "Rules": [{"RuleName": "daily-backups", "TargetBackupVaultName": "default", "ScheduleExpression": "cron(0 3 * * ? *)", "Lifecycle": {"DeleteAfterDays": 90}}]
}'

aws backup create-backup-selection \
  --backup-plan-id abc123 \
  --backup-selection '{"SelectionName": "tag-based-selection", "IamRoleArn": "arn:aws:iam::123456789012:role/AWSBackupRole", "ListOfTags": [{"ConditionType": "STRINGEQUALS", "ConditionKey": "Backup", "ConditionValue": "true"}]}'

Why tag-based backup selection is worth stating as a genuinely strong pattern, directly reusing the tagging discipline from Part 1: instead of manually enumerating every resource needing backup, a backup plan can automatically apply to EVERY resource carrying a specific tag (e.g. Backup=true) — meaning a new RDS instance or EBS volume created with that tag is automatically covered, with zero additional configuration, the exact same "governance by construction through tagging" pattern already seen for cost allocation and Tag Policies.

---

AWS Elastic Disaster Recovery (DRS)#

Worth knowing by name for completeness: DRS provides continuous, block-level replication of ENTIRE servers (including on-premises or other-cloud servers, not just AWS-native resources) into a low-cost staging area in AWS, ready to launch as full EC2 instances during an actual failover.

Copy
aws drs initialize-service

When to reach for it, worth stating precisely: DRS is genuinely the right tool for lift-and-shift-style DR of existing servers (on-premises or otherwise) that weren't built AWS-native from the start — for AWS-native workloads already using the Pilot Light/Warm Standby patterns above, DRS is generally unnecessary, since those patterns already provide equivalent or better protection using AWS-native services directly.

---

Choosing a DR Strategy — The AWS-Specific Decision Framework#

Directly the AWS-concrete version of the Disaster Recovery series' own decision framework.

Diagram

Worth stating explicitly, directly reusing the Disaster Recovery series' core honest framing: there is no universally "correct" strategy — the right choice is whichever strategy's RTO/RPO genuinely matches the business's actual, stated tolerance for downtime and data loss, at a cost the business is genuinely willing to pay. A strategy more expensive than the business actually needs is just as much a real mistake as one that's too cheap for the actual requirement.

---

Multi-Region Architecture Patterns, Consolidated#

A dense summary pulling together every multi-region-relevant service already covered across this entire series.

---

Cost Optimization / FinOps on AWS#

Referenced throughout this series — worth the dedicated, consolidated treatment here, since it's genuinely a distinct discipline in its own right.

Copy
# Cost Explorer — understand WHERE spend is actually going
aws ce get-cost-and-usage \
  --time-period Start=2026-07-01,End=2026-08-01 \
  --granularity MONTHLY --metrics "UnblendedCost" \
  --group-by Type=DIMENSION,Key=SERVICE

# Budgets — proactive alerting BEFORE a cost overrun, not
# after the bill arrives
aws budgets create-budget --account-id 123456789012 --budget '{
  "BudgetName": "monthly-production-budget",
  "BudgetLimit": {"Amount": "50000", "Unit": "USD"},
  "TimeUnit": "MONTHLY", "BudgetType": "COST"
}' --notifications-with-subscribers '[{"Notification":{"NotificationType":"ACTUAL","ComparisonOperator":"GREATER_THAN","Threshold":80},"Subscribers":[{"SubscriptionType":"EMAIL","Address":"finance@example.com"}]}]'

A consolidated FinOps checklist, pulling together every cost lever already mentioned across this series:

• Rightsizing: Compute Optimizer (Part 3) for EC2; similar analysis for RDS/ElastiCache instance sizing (Part 6).
• Purchasing model: Reserved Instances/Savings Plans for stable baseline load; Spot (Part 3) for interruptible workloads.
• Storage lifecycle: S3 Lifecycle policies (Part 5) automatically aging data to cheaper storage classes.
• Idle resource cleanup: Trusted Advisor (Part 1) flags unattached EBS volumes, idle load balancers.
• Serverless where traffic is spiky: Lambda/Fargate (Part 7) avoid paying for idle standing capacity.
• Tagging discipline (Part 1): the foundational input every cost-allocation report depends on.

---

The AWS Well-Architected Tool, Revisited#

Already introduced in Part 1 — worth revisiting here as the capstone, since a Well-Architected Review is genuinely the standard, structured way to evaluate a workload against everything this series has covered.

Copy
aws wellarchitected create-workload --workload-name "production-app" --review-owner "platform-team@example.com" \
  --lenses "wellarchitected" --environment PRODUCTION

# The tool asks structured questions per pillar (Part 1) and
# generates a prioritized list of "High Risk Issues" —
# genuinely worth running periodically, not just once
aws wellarchitected list-answers --workload-id abc123 --lens-alias wellarchitected

---

Migration Strategies — The 6 R's#

Worth knowing precisely by name — a genuinely common, real interview framework for "how do you move a workload TO AWS."

Why "Retire" is worth stating as a genuinely common, real, valuable outcome of migration PLANNING itself, worth stating explicitly: a thorough migration assessment routinely discovers systems with zero actual users or business value still running — identifying and retiring them is a real, immediate cost win that requires no migration effort at all, and is worth actively looking for during planning, not treating as a rare edge case.

---

AWS Migration Hub and the Migration Toolkit#

Copy
# Application Discovery Service — inventories on-premises
# servers and their dependencies BEFORE planning a migration,
# so the migration plan is based on actual data, not guesswork
aws discovery start-data-collection-by-agent-ids --agent-ids agent-123

# Migration Hub — tracks migration progress across MULTIPLE
# migration tools (DMS from Part 6, DRS, Application
# Migration Service) in one consolidated view
aws migrationhub-config create-home-region-control --home-region us-east-1 --target '{"Type":"ACCOUNT","Id":"123456789012"}'

Why starting with Application Discovery Service (not guessing at an inventory from memory or outdated documentation) matters, worth stating explicitly, directly connecting to the "measure before you optimize" principle from the Capacity Planning series: migration plans based on incomplete or outdated inventories routinely miss critical dependencies, discovering them mid-migration instead — automated discovery surfaces the REAL dependency graph up front, when it's still cheap to plan around.

---

A Full Worked Example: A Complete Migration Plan#

Bringing this final part together into one concrete, realistic migration scenario.

Scenario: an on-premises, monolithic e-commerce application with a self-hosted MySQL database, moving to AWS.

Diagram

Walking through the explicit reasoning: discovery happens FIRST, before any migration decision is made, avoiding the guesswork this part already flagged as a common mistake; each component gets its OWN 6R strategy rather than a single blanket approach for the whole application — the database replatforms to a managed service (capturing real operational benefit with moderate effort), the monolith rehosts first to reduce migration risk and timeline (with refactoring deliberately deferred to AFTER the move, once the team has stabilized on AWS), and the legacy tool retires entirely, a genuine, real cost win requiring zero migration work.

---

The Complete AWS Service Cheat Sheet#

A dense, consolidated recall table spanning every part of this series — genuinely worth reviewing as a whole before an interview.

---

Cross-Series Concept Map#

The single most valuable table in this entire series — every AWS-specific mechanism, mapped back to the general concept it implements, exactly as promised in Part 1's opening section.

---

AWS Fault Injection Service — Chaos Engineering on AWS#

Worth a fuller, dedicated treatment beyond the concept-map row above, directly the AWS-native implementation of the chaos engineering principles already covered in exhaustive depth in the Incident Management series (Part 3).

Copy
aws fis create-experiment-template --experiment-template '{
  "description": "Terminate a random instance in the ASG",
  "targets": {"instances": {"resourceType": "aws:ec2:instance", "resourceTags": {"Environment": "staging"}, "selectionMode": "COUNT(1)"}},
  "actions": {"terminate": {"actionId": "aws:ec2:terminate-instances", "targets": {"Instances": "instances"}}},
  "stopConditions": [{"source": "aws:cloudwatch:alarm", "value": "arn:aws:cloudwatch:us-east-1:123456789012:alarm:error-rate-too-high"}],
  "roleArn": "arn:aws:iam::123456789012:role/FISExperimentRole"
}'

Why stopConditions deserves its own explicit callout, worth stating precisely, directly connecting to the "start small, in staging first" principle already covered generically in the Incident Management series' chaos engineering discussion: a stop condition tied to a real CloudWatch alarm (Part 10) automatically HALTS the experiment if it starts causing genuine, unacceptable customer impact — turning chaos engineering from "we hope this doesn't go too far" into a structurally bounded, safety-net-equipped practice, directly the same disciplined approach already established generically in that series.

---

Common Mistakes#

---

Worked Practice Problems#

Problem 1: A company's leadership mandates Multi-Site Active-Active DR for every production workload, "to be maximally safe," without reviewing each workload's actual business requirements individually. A platform team pushes back on this blanket policy. What's the platform team's likely reasoning, and what would you recommend instead?

Answer: Multi-Site Active-Active is the most expensive strategy on the DR spectrum, requiring genuinely paying for two full, continuously-running production environments — applying it universally, regardless of each workload's actual RTO/RPO requirements, means many workloads end up paying for a guarantee they don't actually need (a low-traffic internal tool with a genuinely acceptable multi-hour RTO gains little from near-zero RTO Active-Active, at real, ongoing cost). The recommendation is assessing each workload's ACTUAL business-driven RTO/RPO requirement individually — directly the Disaster Recovery series' core framework — and selecting the cheapest strategy that genuinely satisfies each one, reserving Multi-Site Active-Active specifically for the workloads whose real business impact from downtime justifies its cost.

Problem 2: A migration team plans to move an on-premises application to AWS using a single "rehost everything as-is" strategy for speed, planning to revisit architecture improvements later. Midway through discovery, they find the application's admin reporting tool has had zero logins in the past 18 months, and its self-hosted MySQL database is running on hardware nearing end-of-life. How should these two findings change the migration plan?

Answer: Both findings argue for deviating from a single blanket strategy, applying the 6 R's per-component instead of uniformly. The admin reporting tool with zero logins in 18 months is a strong candidate for RETIRE — decommissioning it entirely requires no migration effort at all and is a genuine, immediate cost and complexity win, exactly the kind of finding migration discovery is meant to surface. The MySQL database, given its aging hardware, is a reasonable candidate for REPLATFORM rather than pure rehost — migrating it to RDS or Aurora (Part 6) via DMS (Part 6) captures real operational benefit (managed backups, Multi-AZ failover) for only moderate additional migration effort compared to simply rehosting a database that will need to be dealt with again soon anyway. The core lesson: even a genuinely fast, low-risk migration benefits from per-component assessment rather than one uniform strategy applied blindly.

Problem 3: Six months after migrating to AWS, a company's monthly bill has grown 40% faster than their actual user/traffic growth would suggest, and no one on the team can clearly explain where the extra spend is coming from. What AWS tools and practices, drawn from across this entire series, would you use to diagnose and address this?

Answer: Start with Cost Explorer, broken down by service and by tag (Part 1's tagging discipline, assuming it was actually enforced — if not, that gap itself is likely part of the problem, since untagged spend can't be attributed to a specific team or workload for investigation). Cross-reference with Trusted Advisor (Part 1) for straightforward, common waste — unattached EBS volumes (Part 5), idle load balancers (Part 8), oversized instances Compute Optimizer (Part 3) would flag. Check S3 Lifecycle policies (Part 5) are actually in place and correctly transitioning aging data to cheaper storage classes. Review whether Reserved Instances/Savings Plans coverage matches actual steady-state usage, and whether genuinely spiky workloads have been moved to Spot (Part 3) or serverless (Lambda/Fargate, Part 7) where appropriate. Going forward, set up Budgets alerts (this part) so a similar drift is caught proactively next time, rather than discovered reactively six months later during a routine bill review.

---

Series Summary — The Complete AWS Cloud Architecture Picture#

This series set out, in Part 1, to treat AWS not as trivia to memorize but as the concrete, vendor-specific implementation of principles already covered in exhaustive depth across the rest of this course — and every part since has tried to make that connection explicit, not implicit.

• Fundamentals & Identity (Parts 1-2): the account/organization structure and IAM permission model governing everything else.
• Compute & Networking (Parts 3-4): EC2/Auto Scaling and the VPC networking fabric they run inside — Part 4 went the deepest, matching how heavily networking is tested in real interviews.
• Storage & Databases (Parts 5-6): S3/EBS/EFS and the managed database layer (RDS, Aurora, DynamoDB, ElastiCache, Redshift) built on top of them.
• Containers, Serverless & Traffic (Parts 7-8): ECS/Fargate/Lambda as compute options beyond raw EC2, and how traffic actually reaches them (ALB/NLB, CloudFront, Route 53).
• Security & Observability (Parts 9-10): the defense-in-depth security stack (Part 9 went equally deep, given how heavily security is tested) and CloudWatch/X-Ray's native implementation of the Three Pillars.
• CI/CD, IaC & Messaging (Part 11): AWS-native deployment tooling and the messaging services that decouple event-driven architectures.
• Multi-Region, DR & Migration (Part 12): this final part, tying the whole series together into disaster recovery strategy, cost discipline, and how workloads actually get onto AWS in the first place.

This completes the AWS Cloud Architecture series. See questions.md in this folder for the full interview question bank covering all twelve parts.