[moduspol]

> Nothing is reduced just shifted away from your perspective. You pay for the server running your serverless code. You just share that cost.

This is no different from any other abstraction.

> Sharing the cost brings benefits but it also brings pain. First time you hit an AWS hard limit you will realize how much pain

Many AWS services have no architectural scaling limits. S3, Lambda, API Gateway, DynamoDB, SNS, and SQS are examples. And you can always take comfort in knowing that many people are actively using the service at far greater scale than you ever will.

That's not to say they won't ultimately limit (e.g.) how many S3 buckets you create, but being able to create unlimited S3 buckets is not necessary to use S3 as designed in a near-infinitely scalable way.

[geggam]

>Many AWS services have no architectural scaling limits. S3, Lambda, API Gateway, DynamoDB, SNS, and SQS are examples. And you can always take comfort in knowing that many people are actively using the service at far greater scale than you ever will.

All of those services have limits, just because you havent experienced that scale doesnt mean others havent.

[moduspol]

> All of those services have limits, just because you havent experienced that scale doesnt mean others havent.

See the sentence literally immediately after the one you quoted.

People are already using those services all day every day at far greater scale than most of us can ever hope to achieve. It's meaningless to pontificate on theoretical limits when the practical ones are higher than you can reach.

[liveoneggs]

> pontificate on theoretical limits

These "limits" are real and are hit pretty quickly (and it's easy to ask for bumps but they are still there)

S3 buckets is one of the first ones most people hit

[moduspol]

Parent comment is talking about hard limits--those which they will not raise. The soft limits aren't architectural--they're arbitrary to help prevent newbies racking up huge bills by mistake. And (as you noted) they do raise them.