I’ve always been one that like to take the road less traveled and enjoy long country drives. It’s just the pleasure of hitting the pause button between two end points that makes me go for a long trip.
However, when it comes to configuring cloud instances, I’ve always wanted the shorted and least painful paths for my data.This post is going to look at the particularities when selecting Amazon Web Services (AWS) regions, and believe it or not, you will get charged for the “distance” your data travels from the cloud to your customers. This can add-up substantially especially if you, like many of our customers in Finance and Manufacturing, have data intensive applications. When opting for AWS, this is something to pay extra attention to than pay a lot more afterwards as these costs can be up to 20% of your total subscription bill. With companies spending millions looking for ways to cut costs of 2 to 4 %, all you need is a little clever sleuthing, some know-how and a good understanding of your customer base, to reduce your AWS bills substantially.
When setting up AWS, one of the first decisions that you must make before you can do anything with it (management console, SDK, CLI, Load Balancers) is which region to choose. Most customers will just select the closest to them or their customers zone which kind of makes sense, I mean, AWS will default you to it. Unfortunately, proximity is not always the answer or at least, it’s not that simple. There are a lot of factors that go into selecting such features as not all regions are the same. Take speed, for example, which is different for each associated region. They key is to understand what the effect on cloud cost is when the features you need are coupled with the proximity to customers.
As of today, there are 18 public regions (some are reserved for the Government) and 55 availability zones. AWS is always expanding so check back their availability page for up to date information.
To start with, there are some cases where your choice of a zone it’s quite obvious. If most of your users access your applications from North America, then it typically makes sense to deploy your software in an AWS region located in the US or Canada. Sometimes, due to regulatory requirements you may be forced to choose a particular region or country, certain data should be stored as per law.
In other cases, where you are free from such limitations and your considerations concern mostly the ability of your cloud application to scale, here are few factors to consider:
- Cost varies per region, choose the wrong one and you could end up paying a lot more.
We use the AWS Price List API. This allows us to calculate the cost for our customers and that of our installations. You can query for the prices of AWS services using either JSON (with the Price List Service API) or HTML (with the AWS Price List API). You can also subscribe to Amazon Simple Notification Service (Amazon SNS) notifications to get alerts when prices of services change. These change periodically, such as when AWS cuts price levels, when new instance types are launched, or when new services are introduced, so make sure to keep an eye
- Regions have different latencies and data transfer speeds.
If you have an optimal configuration but the current region turns out to be more expensive, you can move to a new one, using a service that allows you to ping a region. There are many out there a nice and simple one that we use is cloudping.
For example, let’s say you deploy your components in the US-East. You can see that between Ohio and Virginia there is almost no difference in network latency. But Ohio is about 3% cheaper then Virginia, which taking into account the very cheap transfer allowed between the two, already says a lot about what you can save.
Now you also want to deploy your components to the West coast where the latency starts to climb with the distance traveled. California is about 20% more expensive then Oregon, so the obvious choice would be Oregon. Yet, latency isn’t everything. So, we need to look at the entire picture. Ohio is centrally located, cheaper then Oregon, offers just as many services while the difference in latency compared to Oregon will not be noticeable. You could also take advantage of the inter data center transfer fees an create a failsafe net between Ohio and Virginia.
- Some resources are more important than others
As I mentioned, latency is crucial but it’s not all there is. You will need to consider the type of resources that is vital to you and your application, looking at things like compute power or storage capacity. You may want to explore the AWS Service Catalog to determine what services are available in each and every region. The AWS Regional products services page will break down each of the main regions and is updated daily. So keep in mind that not all services are available in all regions and not all regions have the same availability zones:
There a lot of items to review and check boxes to check or uncheck when selecting the right instance features and regions for AWS. With a little bit of time you can tweak your deployment so it runs like a well-oiled machine. Making the right choices upfront can save you thousands and many headaches and more importantly, not hinder your applications to scale.
Need advice on how you can leverage AWS to your best use? Let us take a look at how we may save you thousands of your AWS bills, please contact us at firstname.lastname@example.org or read more about our experience with AWS here.
Images source: https://aws.amazon.com/