It's interesting that they categorize Ohio under "East" instead of "Midwest".
Now Open – AWS US East (Ohio) Region
31–40 of 42 posts
Re: Now Open – AWS US East (Ohio) Region
#32As someone who works with a fairly large EC2 infrastructure, I find the move towards EBS-only instance types somewhat alarming. For me, the main draw of EBS is to ensure data is retained in the case of instance failure, but it comes with significantly lower performance than instance-store SSDs and is more expensive. I've resisted EBS for the most part, and all of my servers are treated as disposable, but AWS is obvio…
YES. We have a strict no-EBS policy. Our main concern is that historically EBS has been a big single point of failure that can take down an entire AZ or worse a whole region. There were a number of outages in 2010-2012 that really bad for EBS instances[1][2]. The rate of outages has certainly gone down since then, but its hard to trust a system that has burned you badly multiple times in the past.
There was a good post by Bryan Cantrill after one of those really bad outages[3]. While this post is from an AWS competitor, the arguments about the reliability of network storage are sound.
While the trend by AWS has been to move away from ephemeral storage, it doesn't seem like they are working to completely kill it off. d2 and i2 fill a lot of our storage node needs. For our compute nodes I could see us moving to a model of booting off ebs and then pivot rooting into a ramdisk root fs so nothing would touch ebs after boot.
[1]: https://aws.amazon.com/message/67457/ [2]: http://www.agilesysadmin.net/ec2-outage-lessons [3]: https://www.joyent.com/blog/on-cascading-failures-and-amazon...
Re: Now Open – AWS US East (Ohio) Region
#33As someone who works with a fairly large EC2 infrastructure, I find the move towards EBS-only instance types somewhat alarming. For me, the main draw of EBS is to ensure data is retained in the case of instance failure, but it comes with significantly lower performance than instance-store SSDs and is more expensive. I've resisted EBS for the most part, and all of my servers are treated as disposable, but AWS is obvio…
It's probably a lot easier for them to manage EBS than per-host storage. And also probably a lot more efficient as most of that ephemeral storage is wasted, but EBS is elastic and you can just provision what you need. For most workloads, EBS is fine, and if you don't need lots of space, it's cheaper to get c4 instances with a small EBS volume than a slower comparable c3 instance with local storage. So the savings _is_ passed along.
All that said, I expect the next generation will have at least one type with a mid-range local SSD available if only because there is real demand for it. But it's not going to be cheaper than using EBS, unless you use most of the disk.
Re: Now Open – AWS US East (Ohio) Region
#34Just in time for the election... You don't think?...
What has the election got to do with AWS launching a new region?
Re: Now Open – AWS US East (Ohio) Region
#35As someone who works with a fairly large EC2 infrastructure, I find the move towards EBS-only instance types somewhat alarming. For me, the main draw of EBS is to ensure data is retained in the case of instance failure, but it comes with significantly lower performance than instance-store SSDs and is more expensive. I've resisted EBS for the most part, and all of my servers are treated as disposable, but AWS is obvio…
> The only reason I can think of is the excessive amount of money they can charge for EBS instances (especially PIOPS)
The main driver is that they don't need to have instance storage - that is, they can uncouple the storage from their compute nodes entirely and keep it on SAN somewhere.
Re: Now Open – AWS US East (Ohio) Region
#36As someone who works with a fairly large EC2 infrastructure, I find the move towards EBS-only instance types somewhat alarming. For me, the main draw of EBS is to ensure data is retained in the case of instance failure, but it comes with significantly lower performance than instance-store SSDs and is more expensive. I've resisted EBS for the most part, and all of my servers are treated as disposable, but AWS is obvio…
YES. We have a strict no-EBS policy. Our main concern is that historically EBS has been a big single point of failure that can take down an entire AZ or worse a whole region. There were a number of outages in 2010-2012 that really bad for EBS instances[1][2]. The rate of outages has certainly gone down since then, but its hard to trust a system that has burned you badly multiple times in the past. There was a good po…
AWS user since the start. Was firmly in the no-EBS camp. Still prefer it aesthetically. No parts is better than good parts.
But they do seem to have figured it out, hasn't been the SPOF it used to be in half a decade now.
// Knock wood, etc.
Re: Now Open – AWS US East (Ohio) Region
#37I wondered how soon "Coming soon" would be. Now I have to update my recent blog post [0] before the final two parts are even out :) - part two is out tomorrow BTW. There seems to be a bit of an arms race with Azure right now. The current map [1] has four more regions "Coming soon". Looking forward to London. [0]: https://unop.uk/on-aws-vs-azure-vendor-lock-in-and-pricing-c... [1]: https://aws.amazon.com/about-aws/glo…
London might be RSN, the EC2 API endpoint for what I'm guessing is London (eu-west-2) is resolvable, reachable and happily 401'ing requests as of a few days ago. Obligatory jest: they'll have to rename it post-Brexit.
Interesting.
I made the required EU quip in this post :) - https://unop.uk/azure-eu-regions-naming-confusion/
I've updated part one to include the new region, will probably have to update for London again soon - https://unop.uk/on-aws-vs-azure-vendor-lock-in-and-pricing-c...
Part two is also now out, part three next week - https://unop.uk/on-aws-vs-azure-vendor-lock-in-and-pricing-c...
Re: Now Open – AWS US East (Ohio) Region
#38Re: Now Open – AWS US East (Ohio) Region
#39It's interesting that they categorize Ohio under "East" instead of "Midwest".
I don't blame them. It is in the Eastern time zone. I grew up there, and describing Ohio as anything west in the US always struck me as stupid.
Re: Now Open – AWS US East (Ohio) Region
#40Earlier quoted context omitted.
London might be RSN, the EC2 API endpoint for what I'm guessing is London (eu-west-2) is resolvable, reachable and happily 401'ing requests as of a few days ago. Obligatory jest: they'll have to rename it post-Brexit.
Interesting. I made the required EU quip in this post :) - https://unop.uk/azure-eu-regions-naming-confusion/ I've updated part one to include the new region, will probably have to update for London again soon - https://unop.uk/on-aws-vs-azure-vendor-lock-in-and-pricing-c... Part two is also now out, part three next week - https://unop.uk/on-aws-vs-azure-vendor-lock-in-and-pricing-c...
Can I suggest you update it to revise this spectacularly misleading statement:
"If you have a global presence then getting your content close to users if very important for performance. Azure currently serves more regions than AWS."
Azure regions and AWS regions are not cardinally comparable. Their functions and availability properties are not isomorphic. AWS would prefer that you compare AWS AZs to Azure regions, and then they get to claim the larger number. But I don't suggest that either, and the matter of content delivery is another comparison again. The distinctions between the two platforms are significant and well documented, so on reading this my trust in this source declined rapidly.
I also flatly disagree with this article about the evils of lock-in. Exploiting a rich platform is a recipe for high productivity and opportunities. Re-hosting an application is rare, fraught with pitfalls, and doesn't create any value. So why optimise for it? In my experience, it's better to choose the platform best oriented to your organisation's culture and principles, and adopt it wholeheartedly.