I recently read an article AWS: The good, the bad and ugly, which mentioned that they've moved off of all EBS backed AWS features. What features are explicity (EBS backed EC2 instances) or implicitly (AWS web console) backed by EBS?

  • 4
    For those voting to close, Not Constructive, a feature is either EBS backed or not, so... no debate there. Too Localized, I guess a lot of people don't use AWS??? Dec 19, 2012 at 0:14
  • Also, I couldn't find this information gathered in a single place anywhere online. Dec 19, 2012 at 0:16
  • 1
    Agreed, this is invaluable knowledge to any AWS backed organisation, I'd be very interested to see exactly what sit where within the Amazon cloud. This is especially important given the proven instability of EBS.
    – JonVD
    Dec 19, 2012 at 0:29
  • errr - how is EBS proven to be unstable? Number of volumes running for how long with what downtime? Dec 19, 2012 at 3:21
  • 3
    @PeterH. - because failures in the EBS system have been at the root of nearly every large-scale AWS outage since its inception.
    – EEAA
    Dec 19, 2012 at 3:28

2 Answers 2


EBS is used instead of what Amazon calls ephemeral or instance store because random access IO is apparently better. Sequential IO can be faster on an instance store volume.

EBS Backed

  • EC2 If you select an EBS backed AMI
  • ELB You must select an EBS backed AMI for EC2 host
  • RDS
  • Elastic Beanstalk
  • Elastic MapReduce

Not EBS Backed

  • Route53
  • S3
  • CloudFront
  • Glacier
  • DynamoDB

I am almost positive that SES, SNS, SQS and SWF do not use EBS.

I do not think ElastiCache, CloudFormation, CloudWatch, IAM, or CloudSearch use EBS.

  • 2
    This is pure speculation as Amazon has never publically answered this question. I happen to know that some of the information in this answer is incorrect.
    – jamieb
    Jan 4, 2013 at 15:43
  • please correct it then :/ Jan 5, 2013 at 21:39
  • 1
    @JakeMcGraw: I'm not being obtuse, but I can't provide any more information on this topic. Sorry.
    – jamieb
    Jan 9, 2013 at 5:30
  • The ones listed as EBS backed have either had Amazon say that they are, or use lower-level services that are (Elastic Beanstalk). The ones listed as not EBS backed either live outside of the regions, so they can't be EBS backed because those are region-level services, or use local SSDs for speed (DynamoDB). The two sentences at the end are speculative. Jan 9, 2013 at 21:49

I commented on that blog article which was subsequently deleted by the author. You may wish to consider that level of professionalism as you read his post. What I wrote:

AWS has never had a region-wide failure. If the blog author had taken the time to read the two incident reports that he linked to, he would have learned that. A properly designed AWS deployment always uses multiple availability zones. The worst impact that I've experienced through both events was slightly degraded performance or intermittent API access; neither of which were a slow stopper.

What I didn't add to my original comment:

99% of the flak thrown at AWS is by people who don't understand how to properly use it. They treat it as just another VPS or just another co-lo server. You have to build your application with a cloud-based deployment in mind. It must tolerate random node failures, use stateless application servers, and seamlessly work across multiple instances and subnets behind one or more load balancers. You should be using loosely-coupled components and communicating between tiers using message queues.

In short, this blog post was just another long-winded rant by someone who doesn't understand how to use the tools they've chosen.

  • 1
    You are right, but didn't answer the question...
    – iwiznia
    Dec 20, 2012 at 3:16
  • 1
    @iwiznia It was too long to post as a comment. But the question won't be able to be answered in a public forum. Amazon is deliberately tight-lipped about their underlying infrastructure.
    – jamieb
    Dec 20, 2012 at 5:18
  • 3
    "AWS has never had a region-wide failure." This isn't true. aws.amazon.com/message/65648 "The load caused a brown out of the EBS control plane and again affected EBS APIs across the Region."
    – ceejayoz
    Dec 20, 2012 at 17:25
  • @ceejayoz: Read my comment: "The worst impact that I've experienced through both events was slightly degraded performance or intermittent API access; neither of which were a slow stopper.". The applications that I've managed through both events continued to work as designed.
    – jamieb
    Dec 20, 2012 at 19:25
  • 2
    It's a show-stopper if your instances fail because of EBS and you can't launch replacements in another zone. It's also a problem because ELBs and RDS run on EBS, and have historically had problems failing out of the failed AZ because of these dependencies. See their most recent post-mortem, which acknowledges this and says they'll reengineer ELB to avoid EBS dependencies as a result.
    – ceejayoz
    Dec 20, 2012 at 20:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .