Now Open – AWS US East (Ohio) Region | Hacker News Reader

Now Open – AWS US East (Ohio) Region

aws.amazon.com

98 pointsjeffbarr41 comments

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.

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.

It's in the SDKs. e.g. https://github.com/aws/aws-sdk-ruby/blob/master/aws-sdk-core...

Icky and totally unsupported alternative: scrape the console. Look for meta name="awsc-mezz-data" in the response.

Maybe in the Ruby SDK, not in the JavaScript SDK.

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.

Seems to be one:

  $ 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

I think the OP wants the mapping of "us-east-1": "US East (N. Virginia)" &c.

I'd be happy to serve this as a read only endpoint if you'd like.

can i have write access too?

Anyone know what part of the state the datacenters are located in? Or are they just all over the place?

EDIT: 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/...

For map nerds!

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

Clickable

- 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...

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?

According to the Alliance to Save Energy, an east-west orientation "maximizes daylight, while minimizing unwanted heat losses and gains" [1]

[1] http://www.ase.org/resources/model-commercial-building-effic...

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.

Ooh, you're good at this. Where are the rest of them? I like to keep my DC map accurate, but AWS is hard to find.

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.

[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...

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.

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.

I just finished copying FreeBSD AMIs into the Ohio region:

FreeBSD 10.3-RELEASE ami-780a501d

FreeBSD 11.0-RELEASE ami-88154fed

I wonder how far off the Canadian region is, which they teased in Jan to be coming this year.

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.

[0]: https://unop.uk/on-aws-vs-azure-vendor-lock-in-and-pricing-c...

[1]: https://aws.amazon.com/about-aws/global-infrastructure/

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.

Anybody done a ping between EC2 instances in us-east-1 (N. Virginia) and us-east-2 (Ohio)? Curious to see what the latency is.

The latencies to various locations are listed in the blog post -- us-east-1 to us-east-2 is < 12ms.

It'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.

So Ohio is a new center but still in the US Region?

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).

If there's confusion about the concept of regions, it seems to be coming from Amazon themselves. They couldn't just call it the Ohio region?

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?

For people from outside of North America, "us-east-2" is far more informative than "Ohio".

Just in time for the election... You don't think?...

What has the election got to do with AWS launching a new region?

I don't know... elections might involve needing an elastic supply of network services accessible over low latency links to certain battleground states...

Reply on news.ycombinator.com