The US is not a region. US East (Northern Virginia) is one region, and US East (Ohio) is another region. There are also other US regions, like US West (Oregon) and US West (Northern California).
Is that really an issue? Sometimes I get the number suffixes confused (like us-west-1 and us-west-2). Additionally, would you refer to the Sydney region or the New South Wales region?
I don't know... elections might involve needing an elastic supply of network services accessible over low latency links to certain battleground states...
Zooming in with satellite view shows that all three sites seem to not only have identically sized/shaped buildings, but they're also oriented the same way (long axis running east/west). Any theories on why? Something to do with cooling perhaps?
Yep, suburbs and surrounding cities of my hometown, Columbus, OH. I've been hearing rumors of this here and there for a year now. Glad to see it happening.
I 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.
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.
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.
I really wish there was an API that allowed me to just get a list of all available regions including their descriptive names.
As it stands, when AWS adds a region I have to make manual updates to update my systems.
AWS has APIs for everything else, why not a comprehensive API for regions and their descriptive names?
EDIT: for the downvoters - please specify exactly the REST API call that I make to get regions and their abbreviated and descriptive names. I'd be happy even to see the API in the JavaScript SDK. It doesn't exist.
And anyway, this is not something that should be in the SDK, it's a core part of the AWS system and thus the data should come from a core API not an SDK which requires updating.
$ aws ec2 describe-regions
REGIONS ec2.ap-south-1.amazonaws.com ap-south-1
REGIONS ec2.eu-west-1.amazonaws.com eu-west-1
REGIONS ec2.ap-northeast-2.amazonaws.com ap-northeast-2
REGIONS ec2.ap-northeast-1.amazonaws.com ap-northeast-1
REGIONS ec2.sa-east-1.amazonaws.com sa-east-1
REGIONS ec2.ap-southeast-1.amazonaws.com ap-southeast-1
REGIONS ec2.ap-southeast-2.amazonaws.com ap-southeast-2
REGIONS ec2.eu-central-1.amazonaws.com eu-central-1
REGIONS ec2.us-east-1.amazonaws.com us-east-1
REGIONS ec2.us-east-2.amazonaws.com us-east-2
REGIONS ec2.us-west-1.amazonaws.com us-west-1
REGIONS ec2.us-west-2.amazonaws.com us-west-2
Interesting tidbit in the announcement: Data between the US-East-1 and US-East-2 regions is priced at the lower inter-AZ rate ($0.01 per GB, or half price). That's pretty great if you're looking to add a layer of regional redundancy.
It's actually cheaper than data transfer across AZs. Within a region, AWS charges 1 cent per GB in each direction. You pay a cent to send data from one instance and another cent to receive data on another instance. But between Virginia and Ohio, they charge 1 cent to send data (in either direction) but receiving data is free. In the end, it's actually cheaper to balance your servers across one AZ in Virginia and one AZ in Ohio, rather than 2 AZs in the same region.
But it's only a penny, right? How much could it matter? It actually matters a lot. At both my previous and current employers, a surprisingly large portion of our hill comes from data transfer across AZs. All the microservices, all the memcache hits, and all the database replication add up quickly.
As 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 obviously trying to get rid of it as an option. The only reason I can think of is the excessive amount of money they can charge for EBS instances (especially PIOPS)
They're getting rid of instance stores because all of the bare metal can be diskless then except for the hypervisor boot media (they could even PXE bootstrap that if they wanted and run entirely ephemeral on the physical node). Think of the cost savings on the AWS compute hardware.
Anyway! Provisioned IOPS are sufficient for most workloads; if they're not for yours, you might consider a ramdisk (expensive) or going bare metal on physical servers (cheap).
Well, they still have the instance types where instance storage matters most, IMO: d2 and i2 (which are great for running things like Cassandra and HDFS).
Also, complementing toomuchtodo's comment, there's also now EBS types focused on almost all kinds of workloads: sc1 for cold data/archiving, st1 for workloads optimized for sequential scans (a Confluent benchmark even reported that Kafka ran better with st1 EBS than instance storage), io1/PIOPS for databases and gp2 for everything else.
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.
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.
> 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.
41 comments
[ 3.4 ms ] story [ 132 ms ] threadEDIT: Apparently the facilities are in a couple townships around Columbus (which is in the dead center of the state). Neat. http://www.dispatch.com/content/stories/business/2015/05/29/...
40.103706, -83.199873 in Dublin
40.061121, -83.134998 (originally rumored to be at a different, nearby site at 40.053217, -83.127493) in Hilliard
40.094640, -82.751469 in New Albany
- https://www.google.com/maps/search/40.103706,%20-83.199873
- https://www.google.com/maps/search/40.061121,%20-83.134998
- https://www.google.com/maps/search/40.094640,%20-82.751469
All 3 points: https://www.google.com/maps/dir/40.103706,+-83.199873/40.061...
[1] http://www.ase.org/resources/model-commercial-building-effic...
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/global-infrastructure/
Obligatory jest: they'll have to rename it post-Brexit.
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...
"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.
As it stands, when AWS adds a region I have to make manual updates to update my systems.
AWS has APIs for everything else, why not a comprehensive API for regions and their descriptive names?
EDIT: for the downvoters - please specify exactly the REST API call that I make to get regions and their abbreviated and descriptive names. I'd be happy even to see the API in the JavaScript SDK. It doesn't exist.
Icky and totally unsupported alternative: scrape the console. Look for meta name="awsc-mezz-data" in the response.
http://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/EC2.h...
And anyway, this is not something that should be in the SDK, it's a core part of the AWS system and thus the data should come from a core API not an SDK which requires updating.
But it's only a penny, right? How much could it matter? It actually matters a lot. At both my previous and current employers, a surprisingly large portion of our hill comes from data transfer across AZs. All the microservices, all the memcache hits, and all the database replication add up quickly.
Anyway! Provisioned IOPS are sufficient for most workloads; if they're not for yours, you might consider a ramdisk (expensive) or going bare metal on physical servers (cheap).
Also, complementing toomuchtodo's comment, there's also now EBS types focused on almost all kinds of workloads: sc1 for cold data/archiving, st1 for workloads optimized for sequential scans (a Confluent benchmark even reported that Kafka ran better with st1 EBS than instance storage), io1/PIOPS for databases and gp2 for everything else.
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...
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.
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.
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.
FreeBSD 10.3-RELEASE ami-780a501d
FreeBSD 11.0-RELEASE ami-88154fed