Select the right cloud regions, availability zones to optimize costs
Cloud computing can bring a multitude of unexpected costs. To stay within budget, evaluate the costs associated with regions and availability zones.
The role of regions and availability zones is increasingly important as public cloud providers seek to deliver resilient services. Cloud providers can offer redundancy, minimize latency and optimize failover performance when users employ more than one data center in a given geographic area. But with the growth of cloud computing, cost also becomes a top enterprise priority.
Today, the number of locations where users host their cloud workloads isn't just about resilience -- it's about cost. Let's consider some of the cost issues involved in the selection of cloud regions and availability zones (AZs).
Why do region or AZ prices fluctuate?
Different public cloud providers use different terminology and architecture to organize their respective public clouds. Amazon Web Services (AWS) deploys multiple data centers within geographic areas called regions, with each of the data centers within a region called AZs. AWS ties each AZ together with dedicated, high-speed connectivity to handle failover within the region as quickly as possible.
Google and Microsoft organize their clouds into a larger number of smaller cloud regions. For the purposes of this article, we will use the terms cloud regions and AZs interchangeably.
To minimize latency and improve performance, enterprises often select a region based on the location of their workloads' users. Others select a region based on legal or regulatory limitations that might physically restrict where they can locate data. Depending on the design of the application, users can create additional VMs in other cloud regions for uninterrupted availability -- often including load balancing to direct the application's network traffic.
Play your part
For each cloud service, public cloud users need to optimize instances. Find the smallest, least expensive instances that will fit the workload's needs and then identify the cheapest locations that will also meet those needs. Preform cost and performance assessments regularly to ensure the business is getting the lowest costs over time.
Cloud regions around the world are subject to different business costs related to energy, carbon penalties, real estate taxes and operating costs. There are also governmental costs such as taxes, duties and fees placed on services. Each of these factors is added into the service price in each region, and this results in cost differences between them.
For example, an m4.xlarge on-demand Windows EC2 instance in the AWS U.S.-East (Virginia) region currently costs $0.404 per hour. The same instance in the AWS U.S.-West (N. California) region currently costs $0.44 per hour, $0.446 per hour in the European Union (Frankfurt, Germany) region, and $0.455 per hour in the Asia Pacific (Singapore) region. These may not seem like huge differences, but the cost differential for dozens, hundreds or even thousands of instances taken over weeks, months and years can be startling.
What are some other cost considerations for cloud regions?
Depending on the global location of the deployment, public cloud services and usage may impose additional taxes, duties, VAT and sales tax where applicable. But all of the costs involved in an initial public cloud deployment are just the start. Admins then need to replicate part of the deployment to another region or AZ. In some cases, redundancy is simply a matter of replicating storage content, such as a duplicate RDS database. For additional redundancy and performance, admins might also replicate additional compute and other services to share the workload between cloud regions.
How many cloud regions do I need for an application?
Performance and availability requirements vary with each application or use case. Some workloads may not need more than one region or AZ. For example, a temporary test and development deployment typically won't benefit from a redundant deployment.
When resiliency is required, a second nearby region or an AZ is probably adequate for most enterprise applications. If one region fails, the workload can failover to, or continue operating from, the second selected region or AZ. Deploying a workload in more than two cloud regions or AZ is rare, and is typically reserved for the most critical workloads.
Consider data transfer costs between cloud regions when architecting redundant cloud applications. Generally, public cloud providers don't charge to put data into the cloud, but there is a cost to move data from the storage instance to the internet. When you employ redundancy or move data from cloud storage to other cloud regions, expect to pay additional costs.
For example, AWS charges $0.010 per GB to move data in the U.S.-East (Ohio) region from Amazon Simple Storage Service (S3) to U.S.-East (Northern Virginia), and $0.020 per GB to move data from Amazon S3 to any other AWS region. The data transfer costs can vary depending on the location of the original data storage site. An application that relies on significant data synchronization or other movement adds to the total cost. However, moving data from storage to a compute instance in the same region is usually free.
Is there a way to save money with certain instance types?
There are several additional ways to shave the cost of public cloud deployments -- including redundant deployments.
Public cloud providers seek to maximize their data center usage by offering deep discounts for idle or unused capacity. AWS calls these Spot Instances, while Google calls their closest competing offering preemptible VMs.
AWS Spot Fleets allow users to create and manage a fleet of up to 1,000 Elastic Compute Cloud spot instances. This is good option to create a diverse fleet of multiple instance types that run in multiple AWS AZs.
So the cost challenge for cloud architects is manifold. They must architect the right mix of right-sized services to deploy the application, then select cost-effective failover or redundant services in a region that meets performance demands. They should also design application to minimize usage, such as outbound data transfers, wherever possible.
