Hacker News new | ask | show | jobs
by adventured 2141 days ago
Since the available billing information lags actual usage, track the cost data over time and interpolate it forward in time to be a projected / estimated real-time figure, and act according to that projection. Be sure to let users know how your system works and that it's a calculation you're running based on a smoothed cost (you can make that as rigid or not as makes sense, you could look for variances in times of day to the cost for example and adjust your real-time estimates accordingly, and so on).

It's entirely unnecessary to be exact, you need to be close enough. This is especially true since it's a feature a lot of people want, they'll accept some weakness in the system within reason.

You could offer a flex range the customer can set, a tolerance. If you can't reliably get near that (eg if you can't get within N% when back-checking your estimates versus what ends up being the actual billing), then you let the customer know with a status update and the customer can make a decision as to what to do at that point (they could stop using your service, they could adjust the tolerance, and so on).

Require a minimum number of polled data points before the system comes alive and becomes capable of shutting down services. You need a certain number of records before you can reasonably extrapolate anything.

This system won't work well in cases of normal usage with a sudden extreme burst that blows out the customer's budget (where the customer is hoping to prevent that type of unexpected one-off surge). You could do an accelerated estimate guess if you see a very large, very unusual spike, and jump ahead as a means to over-protect (another setting the customer could choose, they could set a caution level that guides how much you should accelerate ahead in cases of huge surges).

If you're successful, Amazon will kill you or buy you (possibly ask to buy you for cheap, then kill you if you refuse). As with similar hyper platforms, the platform eats its own ecosystem inhabitants in the name of growth. And this is a blatantly obvious feature that is widely demanded, so if you figure out a way to do it even modestly well, they'll knock you out eventually. Print money for a while if you can, charge as much as you can, prepare for the inevitable; consider selling to a cloud service company if you can find the right offer.

2 comments

Thanks for the detailed writeup. I think projecting future costs would be hard but someone pointed out in previous comments that service specific rules ( EC2, S3) etc could be more realistic.

Also what do you think about AWS Cost Explorer API? It looks like it can provide monthly/daily charges and we can build rules for customer tolerance, like you mentioned.

You need to be very careful with projecting, particularly in a production environment. Costs are not evenly distributed across the month (e.g. IIRC reserved instances hit on the first of the month with a potentially very large cost).