Hi,thinking of creating an app to limit AWS account spend, need honest opinions

Very helpful. Pretty hard to do comprehensively without (but less comprehensive solutions could still be useful).

The biggest question is "where are you going to get your data about current spend?. AFAIK the budget data lags behind usage (which is what I assume is the reason people haven't done this before). You can do this at a per-service level (e.g. EC2) by periodically polling EC2 for active resources and keeping a running tally of cost by yourself. This works well for some services like EC2, RDS (although serverless Aurora gets tricky), etc. However for other managed services like S3 or Lambda, it's harder to keep track of how much you have spent.

Cloudtrail could be useful here, but it probably doesn't have enough information to calculate actual cost (e.g. Lambda charging based on invocation time or Athena charging based on the volume of data scanned).

But even something as simple as a tool that keeps track of just your EC2 instance spend and shuts them down if it gets too high would be useful to developers who have AWS accounts for their side projects.

Yes I think less comprehensive solution could cover major services (EC2, lambda etc)

> The biggest question is "where are you going to get your data about current spend?. AFAIK the budget data lags behind usage

interesting, I was thinking I could poll billing metrics (total charges etc) to figure out account level charges.

In your experience, do you care more about EC2 costs or that was just an example?

> interesting, I was thinking I could poll billing metrics (total charges etc) to figure out account level charges.

If it were that easy, this would already exist ¯\_(ツ)_/¯

I think many people use AWS primarily for s3 and EC2 (and s3 costs are negligible for most side projects) so if you were picking a single service, EC2 would probably be the most broadly applicable (and IMO the most realistic one to actually build). On the other hand I would imagine that for many side project developers, their EC2 costs are the easiest to control - even if you do autoscaling, you can cap your max nodes.

What is most useful is tracking the total AWS spend because what really gets you is the service you weren't expecting to cost as much as it did, but that is a very very very hard problem.

I was looking at AWS Cost Explorer API, looks promising but don't know if it's granular enough.

after thinking about your comment on EC2, I think this tool could help smaller teams where you don't know who's doing what with the resources and you just need an upper limit of your monthly/daily spend.

about the last point, yes it's very hard to figure out. Also I thought most people check out the pricing page before trying out any aws services, wouldn't that give an estimate of what they are getting into (i.e. RDS, API gateway) ?

But again I always forget about the data transfer charges so you might be right about this.

I've used cost explorer enough to know that it lags meaningfully behind current costs, but you would probably have to do some measurements to know how much (I would guess several days). If you do that, remember that individual services (or even different components of a single service) might have different lag times. The cost explorer data seems pretty good though.

> I think this tool could help smaller teams where you don't know who's doing what with the resources and you just need an upper limit of your monthly/daily spend.

Yeah, definitely!

> But again I always forget about the data transfer charges

Yeah. AWS can have some pretty complex cost models since they charge based on the amount of resources you actually used - there are way more axes of cost than most people have time to think through.

If you end up building this, I suggest considering that many people will not want their resources automatically shut down, either because they want to serve the spike in traffic or because they are paranoid that there could be a mistake and have production infrastructure accidentally shut down. I would consider designing it so that users can choose to get a Slack message or something instead of having the resources shut down.

Unless I misunderstand your concept, using your website would entail granting it rights to my AWS account to access billing info and shutdown pretty much any service. So, something close to the Administrator policy. I guess you could do something more granular e.g. stop but not start, specify resources, etc but in any case I need to grant you enough rights to shut down my account, which is the entire premise of your service. What are the chances that I’ll grant this type of access to a 3rd party I don’t know about? Snowball, meet Hell.

Also, I don’t want my production account to be shut down. Notified, sure. But if my spending takes off because Elon Musk tweeted about my website and I’m getting a lot of hits (and hopefully a lot of new paying customers) I definitely do not want my service to go down.

In other words, your idea isn’t for me, but it might well work for side projects where you don’t want to spend too much and don’t care about the service going down. In any case the security aspect is going to be tough to manage properly, and is going to make your service a juicy target for hackers.

> Also, I don’t want my production account to be shut down. Notified, sure.

This is already an AWS feature: https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitori...

I'd advise against trying to turn this into a product. Companies will be hesitant to grant a third-party that level of privilege on their infrastructure. And sophisticated companies already have the means to manage their costs. For sophisticated deployments a third-party is unlikely to be in a good position to make those decisions. It's not as simple as "just turn it off". Unsophisticated companies tend to have a simple and predictable architecture with a (largely) fixed monthly cost. The product will be too complex for those simple companies. So I suspect a product like that will be "not good enough" for the serious companies, and too dangerous/difficult for simple companies.

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.

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).

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.

I think it's useful. Im not sure if any third party tools has a similar feature but definitely would be helpful specifically to those who are new to the product.

So you will have the option to auto stop services to minimize spend or terminate services if stopping will not reduce the bill (rds is an example).

User probably needs to be able to set priorities, locks, etc to prevent disruption of services in case they are using it for production.

agree. I could not find any third party tool that does that. Can you please tell me more about setting priorities, locks?

I would love this! I agree it seems like a missing feature of AWS. However as someone else commented I'm not sure how you could practically go about implementing it.

thanks, yea I'll try to figure that out