In Parts 1 and 2 we discussed several ways that public cloud pricing can vary dramatically based on what you actually order – what configuration, options, support, discounts, etc., and how those very situational needs can make a very big difference regarding which service from which provider will save you the most money. In this post I’ll focus specifically on the availability of per-minute pricing from Google and Microsoft, and identify exactly when it makes a difference and how big a difference it makes.
The first thing to understand is that compute instance pricing from these four leading IaaS providers is not really usage-based. If you spin up an AWS compute instance and don’t release it for an hour, but your workload only uses 5% of the CPU’s horsepower for that hour, you will still pay the same price as if it used 100%. Even though cloud has been around for a while, that still comes as a shock to a lot of people. The pricing is closer to being usage-based than it was with traditional IT outsourcing because we pay for 1-hour increments rather than 1-month increments with multi-year commitments, but we’re still paying for access to capacity, just in smaller chunks.
So how does that relate to our pricing comparison? Have a look back at Figure 1 from Part 1 of this series. The label on the X-axis is “Percentage of Hours Used Per Month,” which is my attempt to indicate that, to a cloud service, hours used and minutes used (or even seconds used) are not the same thing. For example, since there are 730 hours in an average month, that means that the 50% mark on the chart signifies 365 hours of the month with at least some usage in each hour. If your application runs 12 hours a day, 7 days a week, and releases the instances for the remaining hours, that would just about get you to 50% on the chart. And I’m sure there are plenty of applications out there that fit that profile or something close to it. For our sample configuration, apps that run on GCE, Azure, AWS On Demand or SoftLayer Hourly compute instances are generating much less cost for cloud infrastructure than they would with reserved instances or monthly billing options because they pay nothing for compute 50% of the time. But what if the workload isn’t all concentrated within those 365 hours each month? What if it’s more dispersed over time?
For illustration let’s take the most extreme example and see what happens to Figure 1 when we assume that the workload for the compute instances is as dispersed as possible over an average month. That would mean that the 50% usage is spread over every hour of the month, 30 minutes each hour. You’re still using your compute instances 50% of the time, but now you’re using 100% of the hours in the month instead of 50% of them. The number of minutes you’re using each month, however, is still 50%. In that scenario, AWS On Demand, SoftLayer Hourly Billing, and any other cloud service that charges for each hour that your instance runs, will cost the same as if you were using it 100% of the time. Here’s what the cost looks like graphically, using the same configuration we used for Figure 1:
If you are like a lot of people, you may be having one of those “holy crap” moments right about now. Sorry about that. Let’s talk about what happens to each curve:
- AWS reserved instances and SoftLayer Monthly stay where they were because they are unaffected by usage – you pay the rate you signed up for regardless.
- AWS On Demand and SoftLayer Hourly are now horizontal lines (the AWS On Demand line may actually look dotted here because it’s hidden under the dotted line for SoftLayer Monthly). Since those two services charge for every hour you use any of, and you are using at least a little of every hour, you pay the same as 100% usage until you get to zero percent, where you’re only paying a small amount for 1 TB of storage and nothing for compute.
- Azure’s curve stays exactly where it was, since the per-minute pricing with no minimum is the most granular of all these services (we haven’t looked at services with true usage-based pricing, like AWS Lambda). If you only use 30 minutes each hour, you only pay for 30 minutes each hour.
- The curve for Google Compute Engine stays where it was until you get to 16.7% usage. Why? Because GCE has per-minute pricing, but with a 10-minute minimum each hour, and 10 is 16.7% of 60. So you only pay for what you use, but only after you’ve used at least 10 continuous minutes. Once you release the instance, the 10 minute minimum starts again, so the chart is actually a little kind to Google since it assumes continuous use each hour.
Conclusion: If you are using an IaaS service that charges by the hour for compute instances, and your workload is very dispersed over time, you could be leaving A LOT of money on the table vs. a service that charges by the minute or even reserved instances.
What about other configurations? Just for fun, let’s look at the “More RAM” Configuration that we showed in Figure 3 (from Part 2), and adjust it for a time-dispersed workload:
That’s a huge difference, because the extra memory makes the compute instances more expensive for this configuration. The explanation of what happens to each curve is the same as for our first configuration, but Google looks even better in this scenario, just as they did in Figure 3, because the AWS and Azure configurations required some over-provisioning to meet the requirements. The important thing is to look at the size of the gaps in this chart. When you get down to lower average usage levels, say around 30%, you’re looking at differences in actual cost of almost 4 times. Don’t let anyone tell you that all the big IaaS services are priced the same. Each of them has strengths in different situations, but they can be very far apart on actual cost. And we’ve only looked at a few, small sample configurations. We’ve also looked at workloads that are as concentrated over time as possible vs. workloads that are as dispersed as possible. There’s also every scenario in between, and there’s a very good chance that your workload is one of those!
Conclusion: If you don’t thoroughly understand your application’s workload patterns, you could be leaving a large amount of money on the table with hourly pricing, especially if your workload is intermittent and dispersed over time.