Beware the sticker shock – cloud services pricing is nothing close to simple, especially as you come to terms with the dollar amount on your monthly cloud bill. While cloud service providers like AWS, Azure, and Google were meant to provide compute resources to save enterprises money on their infrastructure, cloud services pricing is complicated, messy, and difficult to understand. Here are 7 ways that cloud providers obscure pricing on your monthly bill:
1 – They use varying terminology
For the purpose of this post, we’ll focus on the three biggest cloud service providers: AWS, Azure, and Google. Between these three cloud providers alone, different analogies are used for just about every component of services offered.
For example, when you think of a virtual machine (VM), that’s what AWS calls an “instance,” Azure calls a “virtual machine,” and Google calls a “virtual machine instance.” If you have a group of these different machines, or instances, in Amazon and Google they’re called “auto-scaling” groups, whereas in Azure they’re called “scale sets.” There’s also different terminology for their pricing models. AWS offers on-demand instances, Azure calls it “pay as you go,” and Google refers to it as “sustained use.” You’ve also got “reserved instances” in AWS, “reserved VM instances” in Azure, and “committed use” in Google. And you have spot instances in AWS, which are the same as low-priority VMs in Azure, and preemptible instances in Google.
2 – There’s a multitude of variables
Operating systems, compute, network, memory, and disk space are all different factors that go into the pricing and sizing of these instances. Each of these virtual machine instances also have different categories: general purpose, compute optimized, memory optimized, disk optimized and other various types. Then, within each of these different instance types, there are different families. In AWS, the cheapest and smallest instances are in the “t2” family, in Azure they’re called the “A” family. On top of that, there are different generations within each of those families, so in AWS there’s t2, t3, m2, m3, m4, and within each of those processor families, different sizes (small, medium, large, and extra large). So there are lots of different options available. Oh, and lots confusion, too.
3 – It’s hard to see what you’re spending
If you aren’t familiar with AWS, Azure, or Google Cloud’s consoles or dashboards, it can be hard to find what you’re looking for. To find specific features, you really need to dig in, but even just trying to figure out the basics of how much you’re currently spending, and predicting how much you will be spending – all can be very hard to understand. You can go with the option of building your own dashboard by pulling in from their APIs, but that takes a lot of upfront effort, or you can purchase an external tool to manage overall cost and spending.
4 – It’s based on what you provision…not what you use
Cloud services pricing can charge on a per-hour, per-minute, or per-second basis. If you’re used to the on-prem model where you just deploy things and leave them running 24/7, then you may not be used to this kind of pricing model. But when you move to the cloud’s on-demand pricing models, everything is based on the amount of time you use it.
When you’re charged per hour, it might seem like 6 cents per hour is not that much, but after running instances for 730 hours in a month, it turns out to be a lot of money. This leads to another sub-point: the bill you get at the end of the month doesn’t come until 5 days after the month ends, and it’s not until that point that you get to see what you’ve used. As you’re using instances (or VMs) during the time you need them, you don’t really think about turning them off or even losing servers. We’ve had customers who have servers in different regions, or on different accounts that don’t get checked regularly, and they didn’t even realize they’ve been running all this time, charging up bill after bill.
You might also be overprovisioning or oversizing resources — for example, provisioning multiple extra large instances thinking you might need them someday or use them down the line. If you’re used to that, and overprovisioning everything by twice as much as you need, it can really come back to bite you when you go look at the bill and you’ve been running resources without utilizing them, but are still getting charged for them – constantly.
5 – They change the pricing frequently
Cloud services pricing has changed quite often. So far, they have been trending downward, so things have been getting cheaper over time due to factors like competition and increased utilization of data centers in their space. However, don’t jump to conclude that price changes will never go up.
Frequent price changes make it hard to map out usage and costs over time. Amazon has already made changes to their price more than 60 times since they’ve been around, making it hard for users to plan a long-term approach. Also for some of these instances, if you have them deployed for a long time, the prices of instances don’t display in a way that is easy to track, so you may not even realize that there’s been a price change if you’ve been running the same instances on a consistent basis.
6 – They offer cost savings options… but they’re difficult to understand (or implement)
In AWS, there are some cost savings measures available for shutting things down on a schedule, but in order to run them you need to be familiar with Amazon’s internal tools like Lambda and RDS. If you’re not already familiar, it may be difficult to actually implement this just for the sake of getting things to turn off on a schedule.
One of the other things you can use in AWS is Reserved Instances, or with Azure you can pay upfront for a full year or two years. The problem: you need to plan ahead for the next 12 to 24 months and know exactly what you’re going to use over that time, which sort of goes against the nature of cloud as a dynamic environment where you can just use what you need. Not to mention, going back to point #2, the obscure terminology for spot instances, reserved instances, and what the different sizes are.
7 – Each service is billed in a different way
Cloud services pricing shifts between IaaS (infrastructure as a service), which uses VMs that are billed one way, and PaaS (platform as a service) gets billed another way. Different mechanisms for billing can be very confusing as you start expanding into different services that cloud providers offer.
As an example, the Lambda functions in AWS are charged based on the number of requests for your functions, the duration, and the time it takes for your code to execute. The Lambda free tier includes 1M free requests per month and 400,000 GB-seconds of compute time per month, or you can get 1M request free and $0.20 per 1M requests thereafter, OR use “duration” tier and get 400,000 GB-seconds per month free, $0.00001667 for every GB-second used thereafter – simple, right? Not so much.
Another example comes from the databases you can run in Azure. Databases can run as a single server or can be priced by elastic pools, each with different tables based on the type of database, then priced by storage, number of databases, etc.
With Google Kubernetes clusters, you’re getting charged per node in the cluster, and each node is charged based on size. Nodes are auto-scaled, so price will go up and down based on the amount that you need. Once again, there’s no easy way of knowing how much you use or how much you need, making it hard to plan ahead.
What can you do about it?
Ultimately, cloud service offerings are there to help enterprises save money on their infrastructures, and they’re great options IF you know how to use them. To optimize your cloud environment and save money on costs, we have a few suggestions:
Recently, I’ve been on a few phone calls where I get asked about cost management of resources built in AWS using Terraform provisioning. One of the great things about working with ParkMyCloud customers is that I get a chance to talk to a lot of different technical teams from various types of businesses. I get a feel for how the modern IT landscape is shifting and trending, plus I get exposed to the variety of tools that are used in real-world use cases, like Atlassian Bamboo, Jenkins, Slack, Okta, and Hashicorp’s Terraform.
Terraform seems to be the biggest player in the “infrastructure as code” arena. If you’re not already familiar with it, the utilization is fairly straightforward and the benefits quickly become apparent. You take a text file, use it to describe your infrastructure down to the finest detail, then run “terraform apply” and it just happens. Then, if you need to change your infrastructure, or revoke any unwanted changes, Terraform can be updated or roll back to a known state. By working together with AWS, Azure, VMware, Oracle, and much more, Terraform can be your one place for infrastructure deployment and provisioning.
How to Use Terraform Provisioning and ParkMyCloud with AWS Autoscaling Groups
I’ve talked to a few customers recently, and they utilize Terraform as their main provisioning tool, while ParkMyCloud is their ongoing cloud governance and cost control tool. Using these two systems together is great, but one main confusion comes in with AWS’s AutoScaling Groups. The question I usually get asked is around how Terraform handles the changes that ParkMyCloud makes when scheduling ASGs, so let’s take a look at the interaction.
When ParkMyCloud “parks” an ASG, it sets the Min/Max/Desired to 0/0/0 by default, then sets the values for “started” to the values you had originally entered for that ASG. If you run “terraform apply” while the ASG is parked, then terraform will complain that the Min/Max/Desired values are 0 and will change them to the values you state. Then, when ParkMyCloud notices this during the next time it pulls from AWS (which is every 10 minutes), it will see that it is started and stop the ASG as normal.
If you change the value of the Min/Max/Desired in Terraform, this will get picked up by ParkMyCloud as the new “on” values, even if the ASG was parked when you updated it. This means you can keep using Terraform to deploy and update the ASG, while still using ParkMyCloud to park the instances when they’re idle.
How to Use Terraform to Set Up ParkMyCloud
If you currently leverage Terraform provisioning for AWS resources but don’t have ParkMyCloud connected yet, you can also utilize Terraform to do the initial setup of ParkMyCloud. Use this handy Terraform script to create the necessary IAM Role and Policy in your AWS account, then paste the ARN output into your ParkMyCloud account for easy setup. Now you’ll be deploying your instances as usual using Terraform provisioning while parking them easily to save money!
Wake up and smell the wasted cloud spend. The cloud shift is not exactly a shift anymore, it’s an evident transition. It’s less of a “disruption” to the IT market and more of an expectation. And with enterprises following a visible path headed towards the cloud, it’s clear that their IT spend is going in the same direction: up.
Enterprises have a unique advantage as their cloud usage continues to grow and evolve. The ability to see where IT spend is going is a great opportunity to optimize resources and minimize wasted cloud spend, and one of the best ways to do that is by identifying and preventing cloud waste.
So, how much cloud waste is out there and how big is the problem? What difference does this make to the enterprises adopting cloud services at an ever-growing rate? Let’s take a look.
The State of the Cloud Market in 2018
The numbers don’t lie. For a real sense of how much wasted cloud spend there is, the first step is to look at how much money enterprises are spending in this space at an aggregate level.
Gartner’s latest IT spending forecast predicts that worldwide IT spending will reach $3.7 trillion in 2018, up 4.5 percent from 2017. Of that number, the portion spent in the public cloud market is expected to reach $305.8 billion in 2018, up $45.6 billion from 2017.
The last time we examined the numbers back in 2016, the global public cloud market was sitting at around $200 billion and Gartner had predicted that the cloud shift would affect $1 trillion in IT spending by 2020. Well, with an updated forecast and over $100 billion dollars later, growth could very well exceed predictions.
The global cloud market and the portion attributed to public cloud spend are what give us the ‘big picture’ of the cloud shift, and it just keeps growing, and growing, and growing. You get the idea. To start understanding wasted cloud spend at an organizational level, let’s break this down further by looking at an area that Gartner says is driving a lot of this growth: infrastructure as a service (IaaS).
Wasted Cloud Spend in IaaS
As enterprises increasingly turn to cloud service providers like Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP) to provide compute resources for hosting components of their infrastructures, IaaS plays a significant role in both cloud spend and cloud waste.
Of the forecasted $305.8 billion dollar public cloud market for 2018, $45.8 billion of that will be spent on IaaS, ⅔ of which goes directly to compute resources. This is where we get into the waste part:
44% of compute resources are used for non-production purposes (i.e. development, staging, testing, QA)
The majority of servers used for these functions only need to run during the typical 40-hour work week (Monday through Friday, 9 to 5) and do not need to run 24/7
Cloud service providers are still charging you by the hour (or minute, or even by the second) for providing compute resources
The bottom line: for the other 128 hours of the week (or 7,680 minutes, or 460,800 seconds) – you’re getting charged for resources you’re not even using. And there’s a large percent of your waste!
What You Can Do to Prevent Wasted Cloud Spend
Turn off your cloud resources.
The easiest and fastest way to save money on your idle cloud resources is by simply not using them. In other words, turn them off. When you think of the cloud as a utility like electricity, it’s as simple as turning off the lights every night and when you’re not at home. With ParkMyCloud you can automatically schedule your cloud resources to turn off when you don’t need them, like nights and weekends, and eliminate 65% or more on your monthly bill with AWS, Azure, and Google. Wham. bam.
Turn on your SmartParking.
You already know that you don’t need your servers to be on during nights and weekends, so you shut them off. That’s great, but what if you could save even more with valuable insight and information about your exact usage over time?
With ParkMyCloud’s new SmartParking feature, the platform will track your utilization data, look for patterns and create recommended schedules for each instance, allowing you to turn them off when they’re typically idle.
There’s a lot of cloud waste out there, but there’s also something you can do about it: try ParkMyCloud today.
You might read the headline statement that the cost of cloud computing is dropping and say “Well, duh!”. Or maybe you’re on the other side of the fence. A coworker recently referred me to a very interesting blog on the Kapwing site that states Cloud costs aren’t actually dropping dramatically. The author defines“dramatically” based on the targets set by Moore’s Law or the more recently proposed Bezos’ Law, which states that “a unit of [cloud] computing power price is reduced by 50 percent approximately every three years.” The blog focused on the cost of the Google Cloud Platform (GCP) n1-standard-8 machine type, and illustrated historical data for the Iowa region:
N1-standard-8 Cost per Hour
The Kapwing blog also illustrates that the GCP storage and network egress costs have not changed at all in three years. These figures certainly add up to a conclusion that Bezos’ Law is not working…at least not for GCP.
Whose law is it anyway?
If we turn this around and try to apply Bezos’ Law to, well, Bezos’ Cloud we see a somewhat different story.
The approach to measuring AWS pricing changes needs to be a bit more systematic than for GCP, as the AWS instance types have been evolving quite a bit over their history. This evolution is shown by the digit that follows the first character in the instance type, indicating the version or generation number of the given instance type. For example, m1.large vs. m5.large. These are similar virtual machines in terms of specifications, with 2 vCPUs and about 8GB RAM, but the m1.large was released in October 2007, and the m5.large in November 2017. While the “1” in the GCP n1-standard-8 could also be a version number, it is still the only version I can see back to at least 2013. For AWS, changes in these generation numbers happen more frequently and likely reflect the new generations of underlying hardware on which the instance can be run.
Show me the data!
In any event, when we make use of the Internet Archive to look at pricing changes of the specific instance type as well as the instance type “family” as it evolves, we see the following (all prices are USD cost per hour for Linux on-demand from the us-east-1 region in the earliest available archived month of data for the quoted year):
*Latest Internet Archive data from Dec 2017 but confirmed to match current Jan 2018 AWS pricing.
FWIW: The second generation m2.large instance type was skipped, though in October 2012 AWS released the “Second Generation Standard” instances for Extra Large and Double Extra Large – along with about an 18% price reduction for the first generation.
To confirm that we can safely compare these prices, we need to look at how the mX.large family has evolved over the years:
ECU is “Elastic Compute Unit” – a standardized measure AWS uses to support comparison between CPUs on different instance types. At one point, 1 ECU was defined as the compute-power of a 1GHz CPU circa 2007.
I realize that the AWS mX.large family is not equivalent to the GCP n1-standard-8 machine type mentioned earlier, but I was looking for an AWS machine type family with a long history and fairly consistent configuration(and this is not intended to be a GCP vs AWS cost comparison).
The drop in the cost of cloud computing looks kinda dramatic to me…
The net average of the 3-year reduction figures is -58% per year, so Bezos’ Law is looking pretty good. (And there is probably an interesting grad-student dissertation somewhere about how serverless technologies fit into Bezos’ Law…) When you factor the m1.large ECU of 4 versus the m5.large ECU of 10 into the picture, more than doubling the net computing power, one could easily argue that Bezos’ Law significantly understates the situation. Overall, there is a trend here of not just a significantly declining prices, but also greatly increased capability (higher ECU and more RAM), and certainly reflecting an increased value to the customer.
So, why has the pricing of the older m1 and m3 generations gone flat but is still so much more expensive? On the one hand, one could imagine that the older generations of underlying hardware consume more rack space and power, and thus cost Amazon more to operate. On the other hand, they have LONG since amortized this hardware cost, so maybe they could drop the prices. The reality is probably somewhere in between, where they are trying to motivate customers to migrate to newer hardware, allowing them to eventually retire the old hardware and reuse the rack space.
There is definite motivation here to do a lateral inter-generation “rightsizing” move. We most commonly think of rightsizing as moving an over-powered/under-utilized virtual machine from one instance size to another, like m5.large to m5.medium, but intergenerational rightsizing can add up to some serious savings very quickly. For example, an older m3.large instance could be moved to an m5.large instance in about 1 minute or less (I just did it in 55 seconds: Stop instance, Change Instance Type, Start Instance), immediately saving 39%. This can frequently be done without any impact to the underlying OS. I essentially just pulled out my old CPU and RAM chips and dropped in new ones. Note that it is not necessarily this easy for all instance types – some older AMI’s can break the transition to a newer instance type because of network or other drivers, but it is worth a shot, and the AWS Console should let you know if the transition is not supported (of course: as always make a snapshot first!)
For the full view of cloud compute cost trends, we need to look at both the cost of specific instance types, and the continually evolving generations of that instance type. When we do this, we can see that the cost of cloud computing is, in fact, dropping dramatically…at least on AWS.
A few weeks ago at the 2017 AWS re:Invent conference in Las Vegas, we had the opportunity to meet some of our customers at the booth, get their product feedback, and a few shared their ParkMyCloud reviews as video testimonials. As part of our ongoing efforts to save money on cloud costs with a fully automated, simple-to-use SaaS platform, we rely on our customers to give us insight into how ParkMyCloud has helped them. Here’s what they had to say:
TJ McAteer, Prosight Specialty Insurance
“It’s all very well documented. We got it set up within an afternoon with our trial, and then it was very easy to differentiate and show that value – and that’s really the most attractive piece of it.”
As the person responsible for running the cloud engineering infrastructure at ProSight Specialty Insurance, ParkMyCloud had everything TJ was looking for. Not only that, but it was easy to use, well managed, and demonstrated its value right away.
James LaRocque, Decision Resources Group
“What’s nice about it is the ability to track financials of what you’re actually saving, and open it up to different team members to be able to suspend it from the parked schedules and turn it back on when needed.”
As a Senior DevOps engineer at Decision Resources Group, James LaRocque discovered ParkMyCloud at the 2016 AWS re:Invent and has been a customer ever since. He noted that while he could have gone with scripting, ParkMyCloud offered the increased benefits of financial tracking and user capabilities.
“The return on investment is huge.”
Kurt Brochu, Sysco Foods
“We had instant gratification as soon as we enabled it.”
Kurt Brochu, Senior Manager of the Cloud Enablement Team at Sysco Foods, was immediately pleased to see ParkMyCloud saving money on cloud costs as soon as they put it into action. Once he was able to see how much they could save on their monthly cloud bill, the next step was simple.
“We were able to save over $500 in monthly spend by just using it against one team. We are rolling out to 14 other teams over the course of the next 2 weeks.”
Mark Graff, Dolby Labs
“The main reason why we went for it was that it was easy to give our users the ability to start and stop instances without having to give them access to the console.”
Mike Graff, the Senior Infrastructure Manager at Dolby Labs, became a ParkMyCloud customer thanks to one of his engineers in Europe.
“We just give them credentials, they can hop into ParkMyCloud and go to start and stop instances. You don’t have to have any user permissions in AWS – that was a big win for us.”
We continue to innovate and improve our platform’s cloud cost management capabilities with the addition of SmartParking recommendations, SmartSizing, Alicloud and more. Customer feedback is essential to making sure that not only are we saving our customers time and money, but also gaining valuable insight into what makes ParkMyCloud a great tool.
If you use our platform, we’d love to get a ParkMyCloud review from you and hear about how ParkMyCloud has helped your business – there’s a hoodie in it for you! Please feel free to participate in the comments below or with a direct email to email@example.com
Today, we’re excited to bring you SmartParkingTM – automatic, custom on/off schedules for individual resources based on AWS CloudWatch metrics!
ParkMyCloud customers have always appreciated parking recommendations based on keywords found in their instance names and tags – for example, ParkMyCloud recommends that an instance tagged “dev” can be parked, as it’s likely not needed outside of a Monday-Friday workday.
Now, SmartParking will look for patterns in your utilization data from AWS CloudWatch, and create recommend schedules for each instance to turn them off when they are typically idle. This minimizes idle time to maximize savings on your resources.
With SmartParking, you eliminate the extra step of checking in with your colleagues to make sure the schedules you’re putting on their workloads doesn’t interfere with their needs. Now you can receive automatic recommendations to park resources when you know they won’t be used.
SmartParking schedules are provided as recommendations, which you can then click to apply. This release supports SmartParking for AWS resources, with plans to add Azure and Google Cloud SmartParking.
Instance utilization report from AWS CloudWatch data
SmartParking schedule created from instance utilization data
Customize Your Recommendations like your 401K
Different users will have different preferences about what they consider “parkable” times for an instance. So, like your investment portfolios, you can choose to receive SmartParking schedules that are “conservative”, “balanced”, or “aggressive”. And like an investment, a bigger risk comes with the opportunity for a bigger reward.
If you’d like to prioritize the maximum savings amount, then choose aggressive SmartParking schedules. You will park instances – and therefore save money – for the most time, with the “risk” of occasional inconvenience by having something turned off when someone needs it. Your users can always log in to ParkMyCloud and override the schedule with the “snooze button” if they need to use the instance when it’s parked.
On the other hand, if you would like to ensure that your instances are never parked when they might be needed, choose a conservative SmartParking schedule. It will only recommend parked times when the instance is never used. Choose “balanced” for a happy medium.
What People are Saying: Save More, Easier than Ever
Several existing ParkMyCloud customers have previewed the new functionality. “ParkMyCloud has helped my team save so much on our AWS bill already, and SmartParking will make it even easier,” said Tosin Ojediran, DevOps Engineer at a FinTech company. “The automatic schedules will save us time and make sure our instances are never running when they don’t need to be.”
Already a ParkMyCloud user? Log in to your account to try out the new SmartParking. Note that you will need to have AWS CloudWatch metrics enabled for several weeks in order for us to see your usage trends and make recommendations. If you haven’t already, you will need to update your AWS policy.