AWS Per Second Pricing: Estimate Your Actual Savings

AWS Per Second Pricing: Estimate Your Actual Savings

On September 18, AWS announced that effective October 2nd, all standard Linux instances will be billed at per second rates instead of the hourly rates that have been in place since the EC2 service was launched back in 2006. Windows and SUSE Linux instances will remain hourly. Google and Azure have been offering per minute pricing for some time now, and it looks like AWS decided to answer that challenge, and try to leap-frog them down to persecond pricing.


Then a mere 8 days later, on September 26, Google matches that shot across the bow by dropping billing intervals to per second as well, effective immediately. It all makes for some good marketing press reminiscent of the air fare price war days, but in the end, how much is it going to affect your wallet? The answer of course, is it depends.

TL;DR "Show me the money" link to savings calculator

Case 1: Constant Load

If you are part of that crowd that just did a “lift and shift” to the cloud and are running the same number of instances as you were on-premise, and they run all the time (I know you are out there, even if you won’t admit it), then you are out of luck (on multiple fronts). This pricing change will have absolutely no impact on your costs at all. If you have varying loads and are using auto-scaling to scale up and down, then you should see some savings, but how much?

Case 2: Medium Daily Load Curve

Lets look at a fairly common example of a daily load curve that starts small, peaks sometime during midday, and falls off at night. Lets say we always keep a minimum of 2 instances running and at peak load we typically scale up to 10 instances. The first thing to take note of is the 2 instances running all the time are not going to see any costs savings. Secondly, scale up events have no impact either. The only thing that triggers potential savings with this new cost model is the scale down events. Depending on how close or far you were from the hour mark when you scaled down instances you now would be saving that fraction of an hour remaining. In our example here, scaling down from 10 to 2 in the late afternoon and evening gives us 8 opportunities for some savings. We could get lucky and save almost 8 hours of compute, or unlucky and save nothing, all depends on timing. Lets go with an average distribution though and assume on average we will save 30 minutes on each scale event, sometimes more, sometimes less, but it will probably even out to around that. Lets say we are using m4.larges in us-east-1, which cost $0.108 per hour.

On average, we just saved about $0.43 (8 x 0.5 x 0.108) for the day. Not even enough for a plain cup of coffee at Starbucks. What kind of percentage savings does that amount to? Again assuming a flat scale up and scale down curve, lets say that on average there are 6 instances running (halfway between 2 and 10), so the daily cost comes to $15.55, and our savings is about 2.8%. Again, not all that exciting, but at least by the end of the month we will have saved about $10, so we have enough for a couple of lattes once a month now.

Case 3: Heavy Daily Load Curve

So what about the case where you scale more dramatically, from 2 to say 200? I’ll leave the math as an exercise to the reader, but given the same assumptions, you’d save 4.1%, but given your bill was larger than the first case to begin with, that results in about $328 per month, or two lattes a day all month. (If you haven’t noticed, lattes are my currency of choice).

Case 4: Widely Varying Intra-day Loads

If your loads vary widely during the day, things might be a bit different for you. For example, instead of one daily load curve that peaks, say you have 4 different peaks during the day, so you are scaling up and down between 2 and 10 instance four times a day.  That changes things significantly.  Now we are up to 32 scale down events, and the rough savings comes out to about 33%.  Only thing is I suspect if you had loads like this you would typically not be scaling all the way back to 2 in between the peaks but instead let some of those instances run in anticipation of the next curve coming, so I suspect this is more of a contrived example that doesn't align with very many real world systems, but it is possible.

Case 5: New Architectural Pattern

There is one other use case where you could benefit substantially, and that is the architectural pattern of firing up one instance per task. If you do this and the instance only runs for say 15 minutes, you are now getting a 75% reduction in costs, which is pretty substantial. Only thing is, I don’t think many people are running this way today because it was hugely inefficient before this new pricing model. So effectively this is more of a new architecture pattern that is now viable from cost perspective whereas before it was not.

Model Your Savings

At AutoScalr, we have been building and optimizing cost models for quite some time, so we adapted some of our models and posted a Per Second Savings Estimator publicly that you can use for free.  Just plug your own values in to see what kind of savings you can expect. Here is a screen shot for the case 2 mentioned above:


If you run your production numbers through, post your results as a comment here and we can get an idea of average overall savings percentages that this pricing change is going to have. My personal opinion is it will not be all that much for the majority of applications running today, probably less than 5% on average.  What do you think?

Leave a reply

Your email address will not be published. Required fields are marked *