[OzzyB]

It's "serverless" in the sense that if the developer had provisioned a "server" then the max incursion of cost would equal the cost of that server, no more no less.

So yeah, let's blame the developer, but let's not play like mistakes don't happen and they're not costly in the "serverless" world.

[Terretta]

Use EC2, set an auto scaling threshold on CPU utilization, do something dumb, you’ll find you ran “a server” x n.

It’s easy to burn tens or hundreds of thousands ‘accidentally’ on “server”, easier than on serverless.

If you’re spending real money, you should have an account team. Talk to them if such a problem happens.

[bmelton]

> If you’re spending real money, you should have an account team. Talk to them if such a problem happens

The colloquialism for "real money", at least to me, is "a substantial sum". If that's what you intended, wouldn't it make sense that you wouldn't have an account team if the only time you spent real money was by accident?

[vacri]

An autoscaling group has a max spend of '"a server" x n', where you set what n is. Autoscaling groups don't keep adding servers forever.

[jzawodn]

LOL WAT? How is it "serverless" if you're provisioning a server?

[foobarchu]

He's saying that the problem is with "serverless architecture", because the problem could not possibly have happened without the use of a serverless architecture (e.g. provisioning a server). The problem is exclusive to serverless.

[skewart]

> The problem is exclusive to serverless.

That's simply not true. You can accidentally run up huge bills with EC2 instances too. One typo in your CloudFormation templates could spin up a ton of reserved p2.16xlarge's.

Of course, if you consider EC2, and other AWS services, to be "serverless" too - you're not physically managing your own racks after all - then, yeah, fair enough, it is a problem exclusive to these "serverless" IaaS/PaaS providers.

[Terretta]

That’s what he’s saying but that’s not correct.