18

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?

Jake McGraw
  • 900
  • 1
  • 8
  • 17
  • 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??? – Jake McGraw Dec 19 '12 at 00:14
  • Also, I couldn't find this information gathered in a single place anywhere online. – Jake McGraw Dec 19 '12 at 00: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 '12 at 00:29
  • errr - how is EBS proven to be unstable? Number of volumes running for how long with what downtime? – Pete - MSFT Dec 19 '12 at 03: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 '12 at 03:28
  • @EEAA - how many failures? How many volumes? Proven instability is a big call - I did a little bit of research - http://aws.amazon.com/message/67457/ or http://techcrunch.com/2012/10/27/amazon-web-services-outage-caused-by-memory-leak-and-failure-in-monitoring-alarm/ or http://aws.amazon.com/message/67457/ - I'm not a fan of throwing the baby out with the bathwater. I can't find anything that suggests it has "proven instability" – Pete - MSFT Dec 21 '12 at 03:24

2 Answers2

7

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.

jamieb
  • 3,387
  • 4
  • 24
  • 36
  • 1
    You are right, but didn't answer the question... – iwiznia Dec 20 '12 at 03: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 '12 at 05:18
  • 3
    "AWS has never had a region-wide failure." This isn't true. http://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 '12 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 '12 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 '12 at 20:26
  • @ceejayoz - can you provide a link to that post mortem please? I've been looking for it and can't find it... – Pete - MSFT Dec 21 '12 at 03:27
  • @ceejayoz - nevermind - found it. https://aws.amazon.com/message/680342/ (As always - five minutes after asking for it) – Pete - MSFT Dec 21 '12 at 03:32
5

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.

Jake McGraw
  • 900
  • 1
  • 8
  • 17
Charles Engelke
  • 166
  • 1
  • 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 04 '13 at 15:43
  • please correct it then :/ – Jake McGraw Jan 05 '13 at 21:39
  • 1
    @JakeMcGraw: I'm not being obtuse, but I can't provide any more information on this topic. Sorry. – jamieb Jan 09 '13 at 05: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. – Charles Engelke Jan 09 '13 at 21:49