So which cloud provider offers a HARD spend limit? I just want to fund my account e.g. $20/month and never, ever, spend a cent over that. Even if my account gets hacked for bitcoin mining or whatever, I don't want to spend a cent over that.
With AWS, you can do it, via a trigger on a spend notification and a script, but the whole thing is a giant kludge. It should be a default feature. It should be a default feature for all cloud providers.
I'm literally using them less because this isn't a feature they offer. Even the free tier of AWS is too risky without hard limits.
I think the closest you can get is using a VPS like DigitalOcean where you pay $X for a server and there's no autoscaling to worry about. But even with those, if you go over the bandwidth limit (although with DO the bandwidth limit is a lot higher) you would be charged more.
The unfortunate reality is that hobby developers that just want to pay $20/month aren't the target audience for GCP etc. They don't really care if you're using them less for your personal hobby projects. They target large enterprises, and those large enterprises would have very little use for something like "cap my spend at $20".
Even as an AWS employee, I sometimes use non-AWS hosting providers for my own projects. Even outside of the billing situation, AWS is often too complicated for my use cases. It's just not targeted at me and my hobby development projects.
disclaimer: am AWS employee but the above is my own opinion and not official position of the company, etc etc.
> and those large enterprises would have very little use for something like "cap my spend at $20".
For the enterprise as a whole, probably not. But it would still be useful to be able to create sandbox accounts for experimentation with a hard limit on spend. Or give developers their own cloud accounts to run development and testing infrastructure that they can control, without having to worry about them accidentally spending way too much.
+1 to this; also an AWS employee, also use other VPS providers for personal projects (Hetzner and Vultr). Don't need the full breadth of AWS services to tinker with Caddy and Tailscale, but more than that I simply follow the practice of "don't shit where you eat".
Backblaze B2 has separate hard spending limits for storage, bandwidth, and requests, which is an elegant solution to the "but what happens to your data if you hit the limit?" objections you often see in these threads.
Not a full "cloud provider" per se, but you might want to check out NearlyFreeSpeech.net[0]. It's fully pay as you go--"If your balance runs out, your web site hosting suspends automatically."
(I should note that I haven't used them myself, I'm just impressed by their website/business model.)
Maybe not the kind of "cloud provider" you're thinking about but tarsnap works on a prepaid basis. You top up your account and it debits that account daily. You get warnings when you go in the red. Super simple.
> So which cloud provider offers a HARD spend limit?
It still baffles me that this isn't the default. Then again, egress/ingress costs also baffle me, why not just offer capped speed and unlimited bandwidth?
I doubt that i'll ever willingly use a platform that i pay for myself, which can just decide to charge me bunches of money because of my site/app getting DDoS'ed (assuming not all components are fully protected at the edge or something) or suddenly gaining popularity.
In my eyes, such scalability should be opt in (or at least opt out) and by default my apps should just break under the load, much like any self-hosted software would, which may be preferable in some circumstances (e.g. API manages backpressure as best as it can, once request queues fill up, it just gives "503 Service Unavailable" with something like "Retry-After" and any clients/front ends are supposed to show messages to try again later, or automatically retry after a while).
To that end, here's a list of providers that give you such fixed resources (in this case VPSes) and that i personally have used in the past:
Of course, some of those also offer managed services, but in my eyes it's far safer to just run MySQL/MariaDB/PostgreSQL/MongoDB/Redis and any other piece of software in Docker (or OCI compatible) containers, as opposed to using something proprietary, even with protocol compatibility. That way, it's also possible to migrate between providers easily, should the need arise.
Would you be comfortable with losing all of your data and going down when the spend limit is hit? That's fundamentally why this is not as simple as you think
> Would you be comfortable with losing all of your data and going down when the spend limit is hit?
This doesn't feel to me like a generous enough statement about all of the finer points.
Would i be okay with my servers no longer responding to web requests (or doing so with reduced port speeds with some of the above hosts, e.g. Time4VPS) in case of spending limits being unexpectedly hit? Yes, definitely, since my projects going dark for a bit or slowing down would be preferable to me ending up not being able to pay my rent and having to rely on public outcry about the large bill and the vendor's mood that day towards letting that one slide.
Would i be okay with my servers running out of space and no longer writing new data to any database, merely responding with the appropriate errors instead? Yes, definitely, because that probably signals the fact that for some reason lots of space has suddenly started getting used for no reason, something that happened so fast that i didn't even get to plan the appropriate scaling, once Zabbix would warn me about 80% of the disk being full (or any monitoring tool would have an alert set up for this). This would probably also be yet another sanity check.
Would i be okay with my servers suddenly ceasing to exist and being wiped from existence, for any reason short of excessive abuse complaints or repeated ToS violations? I most certainly wouldn't want this to happen, yet in my experience it has never actually happened - some of the vendors listed allow you to pre pay for the resources you're about to use (e.g. Time4VPS and Contabo), even offering discounts for longer term reservations much like AWS does, without unexpected charges to you like AWS would do. In contrast, some of the other vendors listed allow you to pay based on hourly usage (Hetzner, Scaleway, Vultr, DigitalOcean, at least IIRC), but also won't have unpredictable pricing spikes because of set limits for the most part (ingress/egress charges may still apply, however, a worrying trend in the industry that muddies the waters), if i pay for a 5$ VPS every month, that's what i can expect to pay most months regardless of usage (assuming 100% uptime).
With these factors in mind, my servers being wiped would probably have to happen due to either me misusing those services, or alternatively me failing to pay the bills even with the more predictable pricing structures, which is actually very much like a person's electricity being turned off due to them not paying for it - as unpleasant as that'd be, no surprises there. Personally, i don't subscribe to the belief that managed services with unpredictable billing are the only way to do software nowadays, something that Richard Stallman coined as SaaSS (Services as a Software Substitute) and about which you can read more here: https://www.gnu.org/philosophy/who-does-that-server-really-s...
Alas, as long VPS uptime with predefined resources is the unit of computation that you're paying for, everything else should be fairly simple from there onwards.
As long as you are paying by the minute for server time and by the byte-hour for storage, running out of money means you don't get any more minutes or any more byte-hours. No more server time means your servers just vanish into the ether. It doesn't mean they start returning error pages of being unable to write to the database.
They don't reach into your servers and meddle with your nginx configuration. They don't shrink your disk volumes to the amount that's already in use. That wouldn't be possible.
> As long as you are paying by the minute for server time and by the byte-hour for storage, running out of money means you don't get any more minutes or any more byte-hours.
Exactly, that's why I said that being able to prepay for a month ahead (or a similar period) is a good thing, as is anything else that makes billing predictable (such as no auto scaling).
> No more server time means your servers just vanish into the ether. It doesn't mean they start returning error pages of being unable to write to the database.
Come to think of it, that's probably the case for most people out there who just use one account/card for all of their resources.
What i described is indeed possible with a tiered approach: alotting most of your funds to keeping the DBs alive with all of your data and whatever is left apart from that for the more dynamic components - VPSes that work as load balancers or others that host your APIs.
Of course, the ways to achieve something like that are plentiful, for example, multiple accounts with different virtual cards (which may or may not be allowed), using multiple different service providers for different parts of the system (e.g. if one has better storage plans and latency isn't an issue, for example, data centers in same country), using multiple service providers for redundancy (hard to do for most DBs, easier for container clusters) or even using functionality provided by the platforms themselves (which may or may not exist when it comes to billing, even though DigitalOcean had a pretty lovely way of grouping resources into projects).
Come to think of it, that's probably a space that could use a lot of improvements.
> They don't reach into your servers and meddle with your nginx configuration. They don't shrink your disk volumes to the amount that's already in use. That wouldn't be possible.
This isn't even necessary. If platforms allowed me to say: "Here's a bunch of API nodes that I'll give up to X$ for the following month and here's another DB node that I'll prepay in full with Y$ for the following month" then none of the other multi-cloud deployment strategies or tiering would even need to be considered.
If we want to consider situations with auto scaling or other types of dynamic billing, then we should also be able to say something along the lines of: "For those API nodes with my preconfigured init script, i want at least Z instances available with the given funds, whereas any remainder can be used up for autoscaling up to W total nodes. Thus, if the alotted funds run out, it all will return to the prepaid/reserved minimum of Z instances for the rest of the billing period."
AWS Lambda can charge you for usage at sub second resolutions and yet neither they nor other cloud platforms provide good resource prioritization solutions or fine grained billing limits, doing just alerts at best? I'm not sure why that is, but until things change, we'll just have to live with workarounds. Technically some of that would already be possible with something like Reserved Instances on AWS (https://aws.amazon.com/ec2/pricing/reserved-instances/), but that's still not granular enough IMO. Then you'd just have RIs and "everything else" as opposed to resource groups with spending limits.
Furthermore, if my Time4VPS server runs out of bandwidth, I'm not expected to pay more, the port speed just goes down until the end of the prepaid billing period. That's the sort of simplicity that's one of the best current options, with minimal hassles. And if i ever can't afford to renew 10 API servers, then I'll just get 5 or whatever amount i can afford.
More platforms should be like that, maybe at a day/hour/... resolution, though and with APIs that allow us to decide ourselves how often we want to renew services and for what periods, like a few clever scripts online that you can find for turning off AWS/other service instances when not in use. Currently any fine grained controls that you want on those platforms would have to be done programmatically, but it's not like you could easily manage ingress/egress costs that way.
I think your line of thinking is rooted in the assumptions that these cloud services use the fact that they don't do what you describe as a ploy to make more money. Instead it's that they choose to invest in other kinds of functionality; while the concepts you describe are certainly possible to build, they are specifically demanded by a narrow subset of the market which makes them difficult to prioritize
I'll simply use services that fall more in line with what i want and i urge others to do the same, to better suit their needs and avoid the possibility of some very unpleasant financial circumstances down the road, at least as far as personal projects are concerned. Hence the list of some lovely providers in the post above.
They'll simply continue to work with their current approaches to billing, missing out on the 0.01% (read: humorous made up figure to not create the impression that i believe that huge platforms should work like i expect them to, my ego isn't that huge) or so of additional income that they'd get by catering to all of the people like me in the world. That's the beauty of a (mostly) free market - supply and demand.
It's definitely bigger than that as losing out on people like you means losing out on your future potential successes! So definitely important to keep this top of mind for those of us in the biz. It's one way to find competitive advantage in the growth funnel
Would you be comfortable with losing all of your data and going down when the spend limit is hit? That's fundamentally why this is not as simple as you think
Edit: On second thought this is probably a bad idea, but I'm leaving my original comment below for posterity.
Probably easiest to generate a virtual card number with a spend limit, off the top of my head I know Capital One offers this, Apple will also generate virtual card numbers though I don't know if you can set a spend limit on them.
With AWS, you can do it, via a trigger on a spend notification and a script, but the whole thing is a giant kludge. It should be a default feature. It should be a default feature for all cloud providers.
I'm literally using them less because this isn't a feature they offer. Even the free tier of AWS is too risky without hard limits.