How Do You Do Disaster Recovery for ECS Fargate Across Accounts?
Your auditor wants a DR plan with an RTO. But ECS Fargate has no server to snapshot — the cluster is stateless. So what are you actually recovering? This maps AWS's four disaster-recovery strategies onto a stateless Fargate service, with the cross-account wiring that every single-region tutorial skips.
- ·There's no cluster to back up. Fargate DR = your IaC + your data + your container images + cross-account trust.
- ·AWS defines four strategies: backup/restore (RTO hours), pilot light (tens of min), warm standby (minutes), active/active (near-zero) — pick by RTO/RPO and budget.
- ·Images: ECR cross-account replication. It's NOT retroactive — configure it before you need it, or your DR region has no image to run.
- ·Cluster: redeploy from IaC. CloudFormation StackSets pushes the same stack to N accounts and regions in one operation.
- ·Fail over on the DATA plane (Route 53 ARC), never the control plane — control planes have lower availability goals and fail first.
// 1. SOURCE account — registry replication rule (Terraform aws_ecr_replication_configuration)
{
"replicationConfiguration": {
"rules": [
{
"destinations": [
{ "region": "us-west-2", "registryId": "222233334444" }
],
"repositoryFilters": [
{ "filter": "prod/", "filterType": "PREFIX_MATCH" }
]
}
]
}
}Then, in the destination account (222233334444), grant the source permission to replicate:
// 2. DESTINATION account — registry permissions policy
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowCrossAccountReplication",
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::111122223333:root" },
"Action": [ "ecr:ReplicateImage", "ecr:CreateRepository" ],
"Resource": "*"
}
]
}Only images pushed after this is applied replicate — existing images do not. Configure it before you need it.
What are you actually recovering? (there's no cluster to snapshot)
A Fargate service is stateless — there's no server to back up. DR recovers four things: your IaC, your data stores, your container images, and cross-account trust.
Most DR guides are EC2-shaped: snapshot the instance, copy the AMI, restore it in the other region. That instinct fails on Fargate, because there is no instance and no cluster state to snapshot. A Fargate "cluster" is a logical grouping; a service is a desired-count plus a task definition. Kill the region and none of that was a thing you could have backed up — it was configuration.
So reframe DR around the four things that are actually recoverable. Your IaC is the cluster — Terraform or CloudFormation re-creates it. Your data (RDS, DynamoDB, S3, EFS) is the only genuinely stateful part. Your images live in ECR and must exist in the DR region before you can run anything. And your cross-account trust — the roles that let the DR account pull images and assume permissions — has to be wired ahead of time. Get those four right and "recovering the cluster" is just a deploy.
Your IaC repository is your cluster backup. That's liberating and dangerous. Liberating because a green pipeline can rebuild your whole compute layer in a new region in minutes. Dangerous because if your Terraform doesn't actually deploy cleanly from scratch — hidden manual changes, click-ops drift, a hard-coded region — you'll discover it during the disaster, which is the worst possible time.
The four AWS DR strategies, mapped onto Fargate
AWS defines backup/restore, pilot light, warm standby, and multi-site active/active. On Fargate they differ by what runs in the DR region: nothing, data-only, scaled-down tasks, or full.
| Strategy | What runs in DR | RTO | RPO | Cost |
|---|---|---|---|---|
| Backup & restore | Nothing running — data + IaC only | Hours | Since last backup | $ |
| Pilot light | Data replicating, tasks switched off | Tens of min | Near-continuous | $$ |
| Warm standby | Scaled-down tasks always running | Minutes | Near-continuous | $$$ |
| Active/active | Full capacity, serving traffic | Near-zero | Near-zero | $$$$ |
The AWS whitepaper states these as an ordering, not as fixed SLAs — recovery time gets shorter and cost gets higher as you move down the table. On Fargate the mapping is clean. Backup/restore keeps only data and IaC in the DR region; you redeploy the service at failover. Pilot light keeps the data replicating live but the ECS service at desired-count zero. Warm standby runs the service at a reduced desired-count so it can take traffic immediately, then scales up. Active/active runs full capacity in both regions behind a global router.
Most production services don't need active/active. It doubles your compute bill and adds write-conflict complexity you didn't have before. Pilot light or warm standby covers most real RTO requirements — a second always-on full copy is not a line item you add lightly.
Images: ECR cross-account replication (and its traps)
ECR replicates images cross-account and cross-region, but only content pushed AFTER you configure it — never retroactive. The destination account owns the permission policy, not the source.
A Fargate task can't start if it can't pull its image, so image replication is the first thing to wire — and it has two traps that bite in exactly the wrong moment. First: ECR replication is not retroactive. Only images pushed after you turn on the replication rule are copied; everything already in the registry stays put. If you enable replication and assume your DR region is covered, your existing prod image tag isn't there — the next deploy is, but not the one currently running.
Second, the cross-account policy lives on the destination, not the source. The destination account must grant a registry permissions policy with ecr:ReplicateImage and ecr:CreateRepository — the Ready-to-use block above. Miss ecr:CreateRepository and you have to pre-create every repo by hand in the DR account. This is the same central-ECR machinery covered in managing ECS Fargate across multiple AWS accounts — DR just points it at a second region as well as a second account.
"Only repository content pushed or restored to a repository after replication is configured is replicated. Any preexisting content in a repository isn't replicated."
— AWS ECR documentation, verified July 2026
A few more limits worth knowing before you design around it: most images replicate in under 30 minutes, you get up to 25 destinations across 10 rules, and replication does not cross AWS partitions — a us-west-2 image can't replicate to a China (cn-north-1) region.
The cluster: redeploy from IaC with StackSets
Your cluster is Terraform or CloudFormation, not a snapshot. CloudFormation StackSets deploys the same stack across accounts and regions in one operation — that's your cluster "restore."
Because the cluster is code, "restoring" it means running that code in the DR region. The question is only how you keep the DR region's stack in lockstep with primary. CloudFormation StackSets exists exactly for this: create, update, or delete the same stack across multiple accounts and regions in a single operation, so your DR-region cluster definition never drifts from prod. If you're Terraform-native, the equivalent is a workspace or a module invoked per region with a different provider alias — the discipline is identical: one definition, deployed to N targets.
The reason this matters more on Fargate than EC2 is that the cluster genuinely has nothing else. There's no golden AMI to drift, no instance config to reconcile — just the task definition, service, networking, and IAM, all of which are declarative. Getting the Terraform for ECS Fargate structured so it deploys cleanly from an empty account is the DR investment that pays back most, because that same clean deploy is your recovery.
The data: cross-account backup and replication
Data is the only stateful part. Use AWS Backup cross-account copy for point-in-time, and continuous replication (Aurora global DB, DynamoDB tables) for low RPO — Aurora promotes in under a minute.
Everything above is stateless; the database is where your RPO actually comes from. Two layers, and you usually want both. For point-in-time protection against corruption or a bad deploy, AWS Backup copies backups across accounts and regions — the cross-account copy specifically guards against insider threat or a compromised account, because the DR copy lives where the blast radius doesn't reach.
For a low RPO you add continuous replication on top. Aurora global database replicates to a secondary region with typical sub-second latency and can promote a secondary to read/write in under a minute, even in a full regional outage. DynamoDB global tables give multi-region read/write with last-writer-wins. The trap: continuous replication faithfully replicates corruption too, so it is not a substitute for point-in-time backups — it's a complement.
Failover: use the data plane, not the control plane
Route traffic with Route 53 Application Recovery Controller — health checks as manual on/off switches on the data plane. Never depend on the control plane to fail over; it fails first.
AWS splits every service into a data plane (serves real-time traffic) and a control plane (configures the environment), and the data plane has a higher availability design goal. The DR implication is direct: your failover mechanism must run on the data plane, because the control plane is exactly what's likely to be impaired during a regional event. Toggling a weighted DNS record or updating an ECS service's desired count are control-plane operations — great on a normal day, unreliable in the middle of the outage you're failing over from.
The clean answer is Route 53 Application Recovery Controller: it gives you health checks that don't actually check health but act as manual on/off switches you flip via a highly-available data-plane API. Your failover becomes a scripted toggle — send traffic to DR, away from primary — that keeps working even when the control plane doesn't. Automating the toggle is fine; auto-triggering it on health checks is where teams get burned, because a false alarm fails you over for nothing. Most mature setups keep the decision manual and the execution scripted.
Picking a strategy by RTO, RPO, and budget
Match the strategy to the requirement, not the fear. Backup/restore for internal tools, pilot light for most prod, warm standby for revenue systems, active/active only for near-zero RTO.
The mistake is picking a strategy by anxiety instead of by requirement. Start from the number the business actually needs: what RTO did the auditor or the BCP document write down, and what RPO can the product tolerate? An internal admin tool with a same-day RTO is backup/restore — anything more is wasted spend. A customer-facing prod service with a one-hour RTO is comfortably pilot light or warm standby. Reserve active/active for the handful of revenue-critical systems where minutes of downtime cost more than a permanent second copy.
DR posture is a fleet property, not a per-service one. At 10+ services across several accounts, the real failure mode isn't picking the wrong strategy — it's that half the fleet quietly has no strategy. The service someone stood up last quarter has no ECR replication rule and no DR-region stack, and nobody knows until the region blinks. Knowing which services are actually covered is the hard part at scale.
Testing: a DR plan you haven't run is a hypothesis
An untested DR plan fails when you need it. Run game days: kill the primary region in a test account, time the real failover, and fix what breaks before the auditor — or the outage — finds it.
Every DR plan looks complete on paper and reveals its gaps the first time you actually run it — a missing IAM role in the DR account, a Terraform module that hard-codes the primary region, an image tag that never replicated. The only way to find those before a real disaster is a game day: in a test account, simulate the regional failure, execute the real failover runbook, and measure the actual RTO against the one you promised.
Testing also produces the artifact auditors want — evidence the plan was exercised and met its target, not just documented. Capture who executed the failover and when, the same way you'd trace any prod change in CloudTrail. A DR plan that has survived a game day is a capability; one that hasn't is a hope.
If you read this, you might also want to know
Do I need a separate AWS account per DR region, or just a separate region?
A separate region is the minimum for regional DR. A separate account on top adds isolation against the disaster class that's an account compromise or insider action — AWS explicitly recommends a different account per region for the highest resource and security isolation. For most teams: same-org, separate account, separate region.
How do I keep task definitions in sync across the DR region?
Don't sync them — generate them from the same IaC. Register the task definition in both regions from one Terraform/CloudFormation definition so there's a single source of truth. Syncing rendered task-def JSON between regions guarantees drift; deploying the same code to both does not.
What's the cheapest DR strategy that still meets a 1-hour RTO?
Pilot light. Keep the data replicating continuously and the ECS service at desired-count zero with everything else deployed. At failover you set the desired count and flip Route 53 — well inside an hour, without paying for always-running compute. Warm standby buys you minutes instead of tens of minutes, for the cost of the always-on tasks.
Frequently asked questions
Which of your services actually have DR wired?
At 10+ services across several accounts, the hard part isn't the strategy — it's knowing which services have ECR replication and a DR-region stack, and which quietly don't. Fortem shows your whole ECS fleet, every account and region, on one screen. Book a 20-minute call and we'll walk yours.
Book a 20-min call