6 ms·
Now Open – AWS US East (Ohio) Region
- vinny2020 10y agoSo Ohio is a new center but still in the US Region?
- dirtae 10y agoThe 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).
- wmf 10y agoIf 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?
- bdcravens 10y agoIs 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?
- cperciva 10y agoFor people from outside of North America, "us-east-2" is far more informative than "Ohio".
- cbsmith 10y agoJust in time for the election... You don't think?...
- oxguy3 10y agoAnyone 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/amazon-has-big-plans-in-ohio.html http://www.dispatch.com/content/stories/business/2015/05/29/...
- niftich 10y agoFor 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
- reustle 10y agoClickable - https://www.google.com/maps/search/40.103706,%20-83.199873 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.061121,%20-83.134998 - https://www.google.com/maps/search/40.094640,%20-82.751469 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.061121,-83.134998/40.094640,+-82.751469/@40.0832531,-83.1160276,11z/data=!3m1!4b1!4m11!4m10!1m3!2m2!1d-83.199873!2d40.103706!1m0!1m3!2m2!1d-82.751469!2d40.09464!3e0 https://www.google.com/maps/dir/40.103706,+-83.199873/40.061...
- femto113 10y agoZooming 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?
- niftich 10y agoAccording 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-efficiency-uses-data-center-daylighting-save-energy http://www.ase.org/resources/model-commercial-building-effic...
- jsingleton 10y agoI 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-confusion-part-1/ https://unop.uk/on-aws-vs-azure-vendor-lock-in-and-pricing-c... [1]: https://aws.amazon.com/about-aws/global-infrastructure/ https://aws.amazon.com/about-aws/global-infrastructure/
- inopinatus 10y agoLondon 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.
- jsingleton 10y agoInteresting. I made the required EU quip in this post :) - https://unop.uk/azure-eu-regions-naming-confusion/ 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-confusion-part-1/ 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-confusion-part-2/ https://unop.uk/on-aws-vs-azure-vendor-lock-in-and-pricing-c...
- inopinatus 10y agoCan 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.
- jd007 10y agoI wonder how far off the Canadian region is, which they teased in Jan to be coming this year.
- hoodoof 10y agoI 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.
- inopinatus 10y agoIt's in the SDKs. e.g. https://github.com/aws/aws-sdk-ruby/blob/master/aws-sdk-core/endpoints.json 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.
- hoodoof 10y agoMaybe in the Ruby SDK, not in the JavaScript SDK. http://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/EC2.html#describeRegions-property 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.
- QUFB 10y agoSeems 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
- 10y ago
- Rezo 10y agoInteresting 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.
- RyanGWU82 10y agoIt'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.
- AtticusTheGreat 10y agoAs 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)
- toomuchtodo 10y agoThey'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).
- andrioni 10y agoWell, 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.
- helper 10y agoYES. 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/ https://aws.amazon.com/message/67457/ [2]: http://www.agilesysadmin.net/ec2-outage-lessons http://www.agilesysadmin.net/ec2-outage-lessons [3]: https://www.joyent.com/blog/on-cascading-failures-and-amazons-elastic-block-store https://www.joyent.com/blog/on-cascading-failures-and-amazon...
- cperciva 10y agoI just finished copying FreeBSD AMIs into the Ohio region: FreeBSD 10.3-RELEASE ami-780a501d FreeBSD 11.0-RELEASE ami-88154fed
- nodesocket 10y agoAnybody done a ping between EC2 instances in us-east-1 (N. Virginia) and us-east-2 (Ohio)? Curious to see what the latency is.
- virtuallynathan 10y agoThe latencies to various locations are listed in the blog post -- us-east-1 to us-east-2 is < 12ms.
- tedmiston 10y agoIt's interesting that they categorize Ohio under "East" instead of "Midwest".
- theandrewbailey 10y agoI 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.