Please fix the AWS free tier before somebody gets hurt

Post by burkaman » Wed, May 05, 2021, 1:20 PM UTC

davidgatti wrote: post #346

onion2k wrote: post #316

Earlier quoted context omitted.

Are you seriously suggesting that someone who wants to use AWS should go and read all the documentation and watch all the official videos available? That would take literally years. It's huge. It also doesn't solve the problem. If the user makes a mistake they still lose a ton of money. It's a really interesting problem. It's getting too big and too scary for a new developer to jump in and try AWS services, which mea…

1. yes I am, studying years to be a doctor, lawyer, Engineer etc from your point of view is also to much? Should you just start cutting people to figure out how a body works end expect for everything to be ok once you are done? The point being, yes you have to study to learn something, there is no way around it. 2. If money is a concern to you, then I should focus on learning how exactly the billing works and how to…

Post by Macha » Wed, May 05, 2021, 1:29 PM UTC

nix23 wrote: post #379

jiggawatts wrote: post #136

Everyone: PLEASE stop making the argument that it's "too hard" or even "impossible" to implement spending limits. As the article points out: Every other cloud does this! They all have non-production subscription types with hard spending limits. There's a difference between "unable" and "unwilling". The people that refuse to understand the difference are the same people that don't understand that "unsupported" isn't s…

>Don't walk down the same path as IBM's mainframes, where no student anywhere ever has been able to learn on their own WHAT? https://www.ibm.com/it-infrastructure/z/education/master-the... http://wotho.ethz.ch/tk4-/ https://sdl-hercules-390.github.io/html/ https://mainframe.informatik.uni-leipzig.de/ >There's a difference between "unable" and "unwilling". True words, look at the Links.

Post by StreamBright » Wed, May 05, 2021, 1:30 PM UTC

Post by fapjacks » Wed, May 05, 2021, 1:33 PM UTC

ghaff wrote: post #69

maxgashkov wrote: post #60

Earlier quoted context omitted.

That’s extremely hard to design, at least with the current state of what AWS bills and does not bill. Example: let’s assume you’ve set the cut-off budget too strict, spun off another shard for your stateful service (DB for example), it received and stored some data during the short window before some other service brought whole account over budget (i.e. paid egress crossed the threshold). To bring VM and EBS charges…

I think there's a good argument that they could do better. But there's also probably an argument that harder circuit breakers would result in posts like "AWS destroyed my business right when I was featured in the New York Times"--including things like deleting production data. I'm sort of sympathetic to the idea that AWS should have an experimental "rip it all down" option and kill all stateless services option but t…

Post by biztos » Wed, May 05, 2021, 1:36 PM UTC

crispyambulance wrote: post #354

swiftcoder wrote: post #336

Earlier quoted context omitted.

I'm also going to point out, as a former AWS engineer, that "too hard" isn't in the AWS engineering vocabulary. If an AWS engineer were to dismiss something as "too hard", they'd be on the fast track to a performance-improvement-plan. The problem isn't that it's too hard. It's that it isn't a business priority. As soon as it becomes prioritised, a legion of very smart AWS engineers will solve it.

As an antidote to the "nothing is too hard" flex... Everything has trade-off's. When a responsible person says something is "too hard" it's because they've evaluated the consequences and have deemed them too costly in terms of time, resources, cost, maintenance, or strategy/lost-opportunity. Some things really are "too hard". I agree it's not too hard technically but am surprised at your contradictory suggestion AWS…