Remix.run Logo
▲ bryanrasmussen 4 hours ago

and if they're going to be a good decision maker they need to put their personal feelings from hobbyist times aside and realize stuff is different in the two scenarios.

▲zufallsheld 3 hours ago | parent | next [-]

How would they know if the service is any good when they didn't try the service as a hobbyist because of spending fears?

▲chii 3 hours ago | parent [-]

They would ask around, as well as perform a proper evaluation based on their current needs, rather than their experienced needs as a hobbyist?

▲dingaling 2 hours ago | parent [-]

Meanwhile while in the real business world, Cloud decisions are shaped by marketing campaigns and it's the hobbyists and old grey-beards who provide the empirical push-back and reality checks.

▲necovek 4 hours ago | parent | prev | next [-]

If your peak monthly cost for AWS services as a business is $100k, do you not think setting a $200k spending limit is reasonable?

Obviously, the system should provide ample time by warning in advance of reaching it (and could even offer suggestion to keep it at N times your peak from M months ago).

If as a business you set your spending limits so tight that you frequently run into them and it's not some unusual activity, the problem is not that spending limits are available :)

It is mostly about protecting from the unknown, likely unbounded attack on your infrastructure, where your spend might grow 100x: even if you can take $100k, you might not be able to take $10M in a month.

▲miki123211 2 hours ago | parent [-]

And if you use enough services, a global per-account spending limit can't distinguish between peak usage versus one service being abused.

Imagine you spend $100k on average each month, but spend around Christmas rises to $1m because of the specifics of your industry. With a global spending limit, you can't distinguish between $200k of general spend increases due to Black Friday versus $200k in fraudulent 2FA SMS to South Sudan.

▲bryanrasmussen an hour ago | parent [-]

I agree but I think also, as a programmer, surely this is not an insurmountable problem. The idea that pops into my head immediately when hearing this problem is

1. of course spending limits are monthly or even weekly basis. You set a yearly limit, probably most people will do something like November to January 4 times the limits set rest of year.

2. as you near limit calls go to people on your team to tell them you are getting near your limit. Estimate is 2 hours, what do you want. Double Limit for this time period? Triple Limit for This Time Period? Remove Limit Entirely, you will get back to us with potential new limit? It's the beginning of Christmas, the next time your limit resets is the 3rd of January, remove limit entirely and you will get back to them. Why do you decide to remove limit entirely, because you have info that Amazon doesn't, specifically your assassin Nisse doll has gone viral for this Christmas season! The shit is making bank!!

3. When setting limit you say "expected low usage", "expected high usage", "limit". Limit should be significantly above expected high usage. Service informs you - you have been over your expected high usage by 20% last three time periods. Would you like to increase limit and high usage by 20%? Please Look at your settings otherwise.

4. Phone calls when there is an unexpected peaking in usage, like one hour we are 300 thousand which is very high for you, next hour it is 1.5 million.

Obviously none of this stuff helps hobbyists but even the worst run businesses I've worked at would handle this. Otherwise they deserve to be hobbyists, there's no reason to be an organization if you're not organized.

Obviously these things do not stop fraudulent attacks abusing your service, but it does make it harder for them, at the same time making it more difficult for your stuff to just get shut off without you knowing.

Of course, as a programmer I am aware that all these services are created by programmers as effective or more effective than I, and who have undoubtedly thought about it more than I, so I must also assume there are reasons why my off the cuff suggestions are ludicrously unhelpful, but I lack the knowledge as to why this should be so.

▲lazyasciiart 24 minutes ago | parent [-]

The systems are hopefully created with the help of finance professionals who are familiar with a massive variety of unpredictable cost scenarios.

▲tomjen3 2 hours ago | parent | prev [-]

You are correct; however, you're also putting a lot of faith in people's ability to make decisions.

Another thing (that does not really apply at AWS anymore), is that todays's enthusiasts are going to be the future CTOs, and the easiest time to recruit them to your service is when they are still an enthusiast who gets to make decisions on their own because there's exactly one decision maker you have to appeal to and that person really likes to try new stuff.

That's why you can get a free fly.io and why we all use Tailscale. And it works too — if I was in charge and needed it, I would immediately go with Tailscale for a business; I know it and I use it.