Hacker News new | past | comments | ask | show | jobs | submit login

For those in London wondering where is best for UK based customers, it seems, for London at least, this could be an improvement over Dublin (where Frankfurt is slower), as Paris is roughly 70 miles closer. Of course, depending on where / when [1] a UK-based data centre is released, I'd imagine that would be faster still.

Currently Ireland vs. Frankfurt is (more data needed of course)[2]:

  Europe (Ireland): 25 ms   27 ms   24 ms
  Europe (Frankfurt): 39 ms   39 ms   42 ms
And Frankfurt is about 100 miles further than Dublin.

But for a quick test, this looks like a good tool: http://www.cloudping.info/

Will be interested to test this once released to see UK / Paris vs. Dublin.

[1] Article states UK region "due in coming months". No location announced?

[2] Hitting ec2.eu-west-1.amazonaws.com vs. ec2.eu-central-1.amazonaws.com.




AWS in London is coming within months, so if latency to London is your concern, that's not an issue anymore.

https://aws.amazon.com/blogs/aws/coming-in-2017-new-aws-regi...


For anyone using Virgin Media as their ISP, the Dublin DC will perform more predictably, if not faster, because of VM's "give preference to data originating inside the UK/Ireland and don't give two shits about anything else" attitude.

If you run a data heavy service, PoP inside the UK or Ireland is a must if you want to avoid throttling and heavy-handed traffic shapping.


From London: (To Frankfurt) --- dynamodb.eu-central-1.amazonaws.com ping statistics --- 100 packets transmitted, 100 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 20.431/26.779/80.987/8.822 ms

(To Ireland) --- dynamodb.eu-west-1.amazonaws.com ping statistics --- 100 packets transmitted, 100 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 15.306/22.425/63.455/9.655 ms

To Softlayer Paris: --- speedtest.par01.softlayer.com ping statistics --- 100 packets transmitted, 100 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 12.082/16.196/54.741/7.652 ms


I've found latency in the UK can be about a third lower than Ireland. I used Bytemark for testing in my recent book but Azure have UK regions now [0] and DO have had a London DC for a couple of years [1]. AWS UK is currently just "coming soon" [2] but Werner has said "end of 2016 (or early 2017)" [3].

[0] https://unop.uk/azure-eu-regions-naming-confusion

[1] https://www.digitalocean.com/company/blog/introducing-our-lo...

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

[3] http://www.allthingsdistributed.com/2015/11/aws-announces-uk...


> [0] https://unop.uk/azure-eu-regions-naming-confusion

I expect Microsoft are using the UN region names for Europe, where Britain are Ireland are part of Northern Europe.

https://en.wikipedia.org/wiki/United_Nations_geoscheme_for_E...


Nice find! That probably explains it.

The UK names still aren't great, even if they sound reasonable in isolation (Cardiff - West, London - South). They have fixed the map though.


> Article states UK region "due in coming months". No location announced?

At the bottom of the English section it says it's London

The new European region, coupled with the existing AWS Regions in Dublin and Frankfurt, and a future one in London,


It's hardly surprising. Everything on the UK internet goes through London anyway. If you have a DC in Manchester and an end-user in Liverpool, the link normally goes Manchester - London - Liverpool.

It's not a great situation, having everything so centralised on London, but it's a small enough country that it doesn't have a huge effect on latency. It would make no sense for AWS to locate in a non-London region when everything would then have to be backhauled to London.


A 10 year old PDF map [1] shows plenty of other fibre connections. Does everything really go through London?

Locating outside London would be a lot cheaper, for labour, land and power.

[1] http://www.globalcrossing.com/docs/fn/tanet-uk-map.pdf


There is fibre outside London, but most of the main end-user ISPs have just the one POP and it's normally in Docklands. Everything ends up going through there one way or another.


Not every decision is about cost minimisation. There's a resiliency motivation to place DCs in separate flood plains and separate power grids if possible. Whether AWS is following that, I cannot say.


We (I am part of the AWS team) pay a lot of attention to that; our "Overview of Security Practices" paper[1] says:

"Each availability zone is designed as an independent failure zone. This means that availability zones are physically separated within a typical metropolitan region and are located in lower risk flood plains (specific flood zone categorization varies by Region). In addition to discrete uninterruptable power supply (UPS) and onsite backup generation facilities, they are each fed via different grids from independent utilities to further reduce single points of failure. Availability zones are all redundantly connected to multiple tier-1 transit providers."

[1] https://d0.awsstatic.com/whitepapers/aws-security-whitepaper...


London does have food risk back in the 80's when I worked for British Telecom we moved our central London DC(next to London bridge station) out to Add to crickelwood for that reason.

Of course later on the IRA bombed the building next door to us - we survived ok the modems just rest them selves


I've always assumed that availability zones would not necessarily be in the same building or even site in a given region, but something I've wondered is what does the network look like between zones?

Does inter-AZ traffic traverse only fiber that you wholly own? Does AWS send traffic over some shared links in some cases? If only some cases, which cases?


James Hamilton gives a good talk that goes over networking (and more). This is it from reinvent 2014.

https://m.youtube.com/watch?v=JIQETrFC_SQ


I would assume they wouldn't put any DC on a flood plain.


People like to live near water and where it rains.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: