The code for the AWS billing system must be glorious. There are so many ways to pay for things, changing constantly, with an enormous number of accounts and even a number or ways to get credits back due to outages, customer support, or discount codes. And they have to account for internal Amazon use too. And bugs can really only be caught by people reimplementing parts of the system to make sure they get the same results.
A cloud provider billing system is quite a beast, often overlooked and mostly under appreciated. I built one from scratch and led the team responsible for it.
One of my earliest jobs was working for a mobile-phone billing company, in Scotland.
Every day we'd use UUCP to copy billing-records from random-systems to a central host, running SCO Unixware. Then the daily "billing run" would total, reconcile, and massage the data.
The result of the processing would be a pile of CSV files which would then get further massaged by a collection of Perl scripts.
I did some consulting for a Telco on their billing run. It ran on a very, very large computer for its day. The run typically took 16+ hours, sometimes as many as 22 hours, leading to some very white knuckle moments when it threatened to delay the start of the next day's run.
Cloud computing gets cheaper all the time, why should you commit to spending a certain amount of money? This seems like just another way for AWS to increase vendor lock-in and profits through making complicated payment structures that make people believe they're better off.
This was always the drawback of RIs. You had to risk that your instance type would get cheaper over the term of the reservation. Now your “risk” is that your business will shrink or that your spend will get so much cheaper over three years that you lose money.
Getting a discount from a vendor if you commit to spend more over a period of years and signing long term contracts is standard practice.
And despite all of the cries of “lock-in” at a certain scale, you’re always for all practical purposes, “locked in” to your infrastructure. Very few decision makers want to take on a migration that’s not part of a merger. The rewards are too slim and the risk of regressions are too high.
Jeff: Tip for future posts of this nature: a link to a help page or other unauthenticated page showing the actual plans would be helpful. I'm on my phone and can't auth to my aws account to explore the new system but would have loved to take a peek at what the actual plans and pricing are. I'm sure their are other techys on here in the same boat.
Your article implies that the only way to see this info is to login to your was console but you can't assume everybody who would be interested in switching to aws now that you have this system has one or would bother to set one up to explore this feature. And I'm sure there does exist some public listing I'm just pointing out how better this could have been communicated.
I think so. GCP Committed Use Discounts allow you to commit in aggregate in terms of vCPU and Memory, but you are still constrained by region and the commits are bifurcated (gen 1, gen 2, custom, etc.). Savings Plans are dollar based so they automatically float to any region and instance. Way better than Committed Use Discounts imo.
Does anybody know if (and how) this applies to spot instances? None of the language seems to exclude application to spot prices, though I realize the use-it-or-lose-it nature of these discounts has some tensions with bursty spot workflows.
The compute plan is a big deal (meaning important not cost break although that too). The inflexibility of RIs really hurts and makes it hard to actually benefit from the savings. This doesn't quite match Google's approach but it is much simpler to understand.
I don't think it's likely happening for Lambda anytime soon. I can neither confirm, nor deny that I know anything about the underlying costs for Lambda.
Because the broad feature is called Savings Plans with two initial options of Compute and EC2 Instance, I have to believe AWS will at some point release a Database Savings Plan, a Storage Savings Plan, etc. As with RIs, the compute team goes first and the other service teams follow.
IIRC this (or something very similar) has already existed for several years for RDS as an undocumented policy. I forget the exact rules, but you should be able to ask an Amazon employee to change your reservation for you as long as it's the same instance type and you're spending at least as much money.
Getting a way out by selling your RIs was important due to there inflexibility. I think those who feel they may want that could opt for the compute plan which is useful as long as you use EC2 in any form.
Savings Plans are way more flexible and will automatically float, so as long as you aren't overcommitted, you'll get a discount. One of the benefits of Standard EC2 RIs however is they can be disposed of via the RI Marketplace if you do actually need to reduce your commit. That of course is predicated on the RI Marketplace having liquidity, and if people are moving to Savings Plans instead, there may be no buyers. People may still want inflexible but shorter terms. Will be interesting to see how it plays out.
Savings Plans will always match as long as there is usage somewhere and you're not overcommitted. Standard RIs can get mismatched even with other uncovered usage, but can be disposed of via the RI Marketplace (that of course assumes there is a buyer out there somewhere). Once you make a Savings Plan commit, you are stuck with it. They have different "benefits".
