The new Amazon Web Services data center opens up in Stockholm region and brings the Amazon’s cloud services closer to us both physically and mentally. This gives us a great opportunity to discuss what it means in practice.
Over a year ago, in April 2017, AWS announced it will expand to the nordics with the new Stockholm region. Darren Mowry, CEO of AWS Nordic, stated that this investment will mean creating a new Nordic hub to support the customers in Norway, Denmark, and Finland. In addition, he mentioned a possibility for a data center in Finland some day.
During 2018 we saw no progress reports of the data center in the media. There was only an estimation from 2017 that the AWS data center will be ready sometime during 2018. Hence, the launch announcement of the Stockholm region in 12th of December was a very pleasant surprise!
Location in Stockholm reduces latencies
Before Stockholm, Finland’s nearest AWS data center was located in Frankfurt, Germany. When the geographical distance grows along with the amount of intermediary network devices, the latency increases. That’s why the location in Stockholm may well reduce the experienced latencies in Finland – especially when more than one round-trips to the cloud are required.
The term latency can refer to either network latency or the total processing lag of the software. It’s often also referred to as the ping, which stands for the round-trip network latency. For clarity I’ll use the term network latency when referring to network delays in general, and ping only to refer to the round-trip network latency.
Hybrid cloud solutions increase latencies
Cloud-adopting enterprises often leave some of their software to private data centers and set up a so-called hybrid cloud system. This allows applications in the cloud to communicate with the applications still located in the private data center. Unfortunately the network latency doubles when a user in Finland sends a request to an application in the cloud, and the cloud application requests data from the private data center in Finland.
Of course it’s quite normal for the data to travel around, especially when using microservices. Yet if network latency is introduced, and there are many rounds between AWS and Finland, the service becomes slow.
But we’re still only talking about tens of milliseconds per round-trip between Finland and a European AWS data center. The ping from Finland to Europe’s biggest AWS data center in Ireland is 44 milliseconds. Sounds like it shouldn’t be a big deal?
When the network latency doubles in a hybrid cloud system, the time adds up to 88 milliseconds. If one request causes multiple rounds between Ireland and Finland, each round will add 44 milliseconds to the latency.
The network latency also gets a hit from the SSL/TLS handshake protocol, which is required to initiate a secure point-to-point connection. At minimum the handshake adds two extra rounds between Finland and Ireland when opening up the connection. In hybrid cloud setups the TLS handshake might also impact the latencies between AWS and the private data center, unless this can be mitigated with TLS keepalive.
Adding up, the result might be something like six round-trips. With 44ms ping it means 264ms of total network latency – that’s ¼ of a second. The figure still doesn’t include the time spent in processing and behind-the-scenes calls to other systems.
At the end of the day, even a fourth of a second doesn’t sound much – not even when doubled up to half a second with some processing time and hidden delays. But this exceeds the magical 250 millisecond limit. At that time an average person has noticed that nothing happened and is possibly preparing to push the button again.
For public web services I would aim to minimize the latency to improve the user experience. For background services and in-house software it shouldn’t matter as much. On the other hand, some of the background services do end up being called by the public facing web services.
Other ways to decrease latencies
Before moving your AWS resources from Ireland to Stockholm, you should measure the latencies and figure out how much of it is something else than network latency. In addition to hard measurements, you should also measure the experienced latencies for your users. Now that you have a setup for measuring latencies, you can first try to reduce them by other means than switching the AWS region.
First, I would recommend to decrease the amount of round-trips, and taking advantage of the TLS keepalive settings to prevent the handshake from happening on every request. This is something we are currently doing with my team. After giving it a try, we will consider moving the operations from Ireland closer to Finland.
The ping to AWS Stockholm from Finland is 14 milliseconds, which would turn the 264 ms of the presented hybrid could example into 84 ms. The ping to AWS Frankfurt is 26 milliseconds, which would make the same amount of round-trips cause a network latency of 156 ms.
Yet, it is important to remember that for a single round-trip the difference between 14, 26 and 44 milliseconds network latency is rather meaningless. Unless you are building a background service for the Fortnite game.
The proximity of the data center has a soothing effect
In addition to latencies, some companies are interested in the geographical location of their data. Security breaches (though usually not cloud related) are constantly in the headlines, and cause fears for the safety of data. It’s also unclear what the changes in the political climate, like the Brexit, mean for the regional data centers. Worries of storing information on NSA’s area of impact also sometimes pops up in the cloud discussions.
Now, thanks to the new AWS Stockholm region, Finnish customers can choose to store their data in Sweden – this way the data will at least not leave the Nordics. If it brings you peace, you can even go and check out the physical data centers.
Stockholm is the last to get the new AWS services
If you’re planning on using the latest AWS services, the Stockholm Region is not the best choice. In Europe, the new services, as well as updates to existing services, appear first in Ireland. Gradually, after months or even a year, other Regions are updated as well.
According to the AWS service list Stockholm seems to be lacking some basic services like the managed Docker platform Fargate and the authentication service Cognito. Amazon’s CI/CD tools CodeBuild and CodePipeline are also missing. Lambda and API Gateway are, however, already available in Stockholm, which means it’s possible to launch serverless applications.
There are three Availability Zones in the Stockholm Region – that means three geographically separated data centers. This ensures service availability even if one of the data centers is disconnected, suffers a power outage, or is completely destroyed. The amount of Availability Zones in Stockholm is the same as in all European Regions.
Hold your horses
So would Poplatek recommend Finnish customers to build new services to Stockholm and transfer old ones as well? No we don’t. It is more important to benefit from the full potential of Amazon’s service catalog, and optimize the latencies only when it brings real benefits to the users. And even when optimizing, you should first try to reduce other suspects than the network ping.
Anyways, we welcome the new AWS Stockholm Region, as it potentially enables the use of cloud services to a new crowd of Finnish companies. Some like it since it’s close, some need it because of regulations and some fancy it for political reasons – and maybe some actually need it to reduce the network latency.
If you need help in reducing latencies or setting up your application in AWS, contact us to learn more!
Did you know that Poplatek runs the whole transaction system of Veikkaus? Read more about it here.