How to Choose a Cloud Provider
When choosing a cloud provider, you can look at brand recognition, security and storage features and other items. But cloud providers depend on networks just like the rest of us, and they’re not all created or configured equal.
In general, for those considering the cloud, it’s important to match up the location of your end users and the cloud location that’ll be serving them. You should also aim to continuously baseline performance when you first get started with a cloud provider, which will help down the road if there are performance issues.
Since each of the major cloud providers has multiple points of presence, it’s crucial that you consider the network impact of moving your data or apps out of your offices and into the cloud. To illustrate this impact, we’ve set up a quick comparison of the top three providers.
To get a look under the covers of the big three providers, we’ve done some testing. We set up a SaaS CRM demo system in the northwest point of presence (exact locations vary depending on provider) for the three largest public cloud providers: AWS, Azure and Google Cloud. Then, we waited for the results to come in, and they’ve certainly been interesting.
Testing from Los Angeles
This graphic below shows network traffic from Los Angeles to the closest location from the major providers in the northwest region. With our northwest-based CRM there really is no distinct winner. Google and AWS are located in neighboring Oregon while Azure is just a short distance from them in Northern California. Here, AWS may just win out, but all show extreme variability over the course of one month (lower is better here). The difference in physical distance does not fully manifest as additional network time for web requests (for reference, it takes 40 ms for cross-country traffic). What is most likely happening is routing changes.
Los Angeles → Northwest Region | AWS | Azure | Google
Testing from Atlanta
This next example shows the three providers’ network routes from our Atlanta-based monitor to the northwestern points of presence or availability zones. AWS is the slowest cloud provider, although all three experience variability throughout the monthlong window. With a much longer physical separation between synthetic user and server, we can ignore small variations in network speed. However, it is clear that AWS suffers from an average of 1.5 seconds additional latency. The cause could be varied, but with up to two seconds of extra time for web requests, this could lead to higher levels of user frustration. We can also see some consistency in the spikes observed, indicating that traffic may share routes and daily congestion issues.
It’s important to remember that our Seattle-based deployment is probably not the ideal, nor common, choice for an Atlanta-based company. But with so many startups coming out of the Silicon Valley area, there is a good chance that many SaaS apps you use every day are making this long-distance round trip.
Atlanta → Northwest Region | AWS | Azure | Google
Testing from New York
Our final example below shows the network performance along the network path from the New York zone to our northwest-based CRM. AWS still shows the slowest response times of the three providers. Google and Azure are consistently faster, save for one congestion issue observed in late January. Because we can assume that over time the internet will route much of this traffic similarly across the country, there is a good indication that routing behind AWS’ firewall might be the cause of the additional latency.
New York → Northwest Region | AWS | Azure | Google
What our Cloud Testing Found
We don’t have a large sample size, and our test deployment isn’t customized to the complexity of most modern apps, but our results reminded us how important it is to do location research when you’re planning your cloud deployments. Get out the map to see where your services and apps will be located when they’re in the cloud. Then match them up with where the users of those apps and services are.
There are a number of reasons that could contribute to what looks like a failure on AWS’ part to deliver fast responses, such as peering agreements in the middle of the country or additional routing behind their firewall. What is clear is that performance differs depending on where your end users are. Being aware of this fact will lead to better decisions when it comes to performance.
Testing cloud providers is not our sole purpose, but you can get the visibility we did (and you need) with AppNeta’s tools for any of your cloud apps. This kind of network insight may save the day when users are complaining of slowdowns or outages and you need to identify the root cause of performance degradation.