• Skip to primary navigation
  • Skip to main content
Last Week in AWS Logo
Master your cloud costs
  • About
    • Community
    • Contact
  • Blog
  • Newsletter
  • Podcasts
    • Last Week in AWS Podcast
    • Screaming in the Cloud
    • Nominate a Guest
  • Merch
  • Resources
    • AWS Network Map
burning dumpster
10.02.2018

Disaster Recovery Considerations in AWS

By Corey Quinn
A few thoughts on Disaster Recovery planning in AWS environments that most people apparently gloss right over.
FacebookXLinkedInReddit
Home Blog Disaster Recovery Considerations in AWS
Prev
Next

Yesterday we observed what appear to be unrelated incidents in us-west-2 (Oregon) and eu-central-1 (Frankfurt) that gave a number of AWS customers a run for their money as provisioning times of several core services rose to unacceptable levels. It occurred to me that an element of “common wisdom” may not be nearly as common as some of us believe. A cursory check of the internet didn’t show much along these lines, so I figured I’d write down my thoughts and see what the community thought.

Things you should know about Disaster Recovery in AWS

  • AWS regions have separate control planes, which generally serve to isolate faults to particular regions. That’s why we don’t see global outages of DynamoDB, but rather region-specific outages of particular services. That said, if us-west-2 has an issue, and your plan is to fail over to us-east-1, you should probably be aware that more or less everyone has similar plans. You’ll be in very good, very plentiful company. That said, some services still appear to have control planes homed through us-east-1. For instance, during last year’s S3 outage in the US east region, other regions worked fine–but you couldn’t provision new buckets until the issue had passed.
  • AWS regions can take sudden inrush of new traffic very well; they learned these lessons back in the 2012 era. That said, you can expect provisioning times to be delayed significantly. If your recovery plan includes spinning up EC2 instances, you can expect that part of your build to take the better part of an hour in some cases.
  • While a number of naive cost-cutting tools will suggest turning off idle instances, if you’re going to need to sustain a sudden influx of traffic in a new region you’re going to want those instances spun up and waiting; any DR strategy that depends upon the ability to rapidly provision new instances (including as part of autoscaling groups) is likely to end up causing you grief in the event of an actual outage.

None of these are immediately obvious– and they aren’t at all apparent during your standard DR tests. These issues only crop up amid outages that have everyone exercising their DR plans simultaneously.

Disasters are hard; plan accordingly.

Corey Quinn Headshot
by Corey Quinn

Corey is the Chief Cloud Economist at Duckbill, where he specializes in helping companies improve their AWS bills by making them smaller and less horrifying. He also hosts the "Screaming in the Cloud" and "AWS Morning Brief" podcasts; and curates "Last Week in AWS," a weekly newsletter summarizing the latest in AWS news, blogs, and tools, sprinkled with snark and thoughtful analysis in roughly equal measure.

More Posts from Corey

Back to the Blog

Infinidash: AWS’s New Observability Play Has Great Bones and a Terrible Bedside Manner

By Corey Quinn

Infinidash: AWS’s New Observability Play Has Great Bones and a Terrible Bedside Manner AWS has just released something fascinating in the form of CloudWatch Omni. I want to be upfront before I dive further: “CloudWatch Omni” is a wretched name that I will not be using, so for the rest of this article and the […]

Read Moreabout Infinidash: AWS’s New Observability Play Has Great Bones and a Terrible Bedside Manner

Reading Observability Tools? That’s a Robot’s Job

By Corey Quinn

Last Thursday Honeycomb was kind enough to hand me the closing keynote slot at O11yCon, a conference whose entire premise is that observability matters and the people in the room are the ones who would know. I used that slot to argue that the primary reader of your telemetry is no longer a human, and […]

Read Moreabout Reading Observability Tools? That’s a Robot’s Job

S3 Is Not a Filesystem (But Now There’s One In Front of It)

By Corey Quinn

I’ve been saying “S3 is not a filesystem” for over a decade. I’ve said it on stages, in newsletters, on podcasts, and directly to the faces of large company employees who were too polite to tell me to shut up before they went back to their FUSE monstrosities. It was one of those reliable truths […]

Read Moreabout S3 Is Not a Filesystem (But Now There’s One In Front of It)
Billie Holding Mail Email Subscribe Icon

Get the newsletter!

Stay up to date on the latest AWS news, opinions, and tools, all lovingly sprinkled with a bit of snark.

You’re faced with tough questions about cloud costs. You should have confident answers.
Get in touch.
  • Newsletter
  • Podcasts
  • Blog
  • Merch
  • About
  • Contact
  • Disclosures
Billie Footer
footprint-orange
© 2026 L9 Labs, Inc. All Rights Reserved.
Terms of Service Privacy Policy Cookie Policy