I've done quite a bit of cloud cost optimization in the past (sometimes referred to as finops). There's a pedantic discussion to be had as to what is serverless and what is PaaS, but that should be saved for another day.
The underlying problem I found working with teams is that they all too frequently wanted to use these cloud-native technologies (serverless, etc.) which means thinking in microservices by definition, but usually architected for monoliths. This was accomplished in a few ways: 1) the serverless job did everything for you so in effect it was a monolith 2) they didn't want to use any intermediary storage/cache layer and relied heavily on both sides being up and available (synchronous brittle systems) 3) they went TOO hard in the microservices direction and made things way too complicated 4) their testing suites were half-baked (more the industry/tools fault than the users tbh) and weren't sufficiently air-gapped or mostly incomplete.
If you've been around for more than a decade - we have seen this before: AWS specifically sold the concept of "lift-and-shift" to C-suites a dozen years ago and now that MO is so baked in it's going to take a new generation of services with the right selling points to undo it. Lift-and-shift doesn't work because, as stated above, monoliths aren't for the cloud for a sufficiently sophisticated system. It's the reason DHH and others are advocating for "cloud repatriation". And then there are the small cases, comparatively speaking, like the ones listed on this site. These examples are what happens when you give very powerful tooling to people who do not understand it or the implications of it. But too, this is also partly (maybe even mostly) the vendors' fault: "From localhost to https, in seconds. Deploy from Git or your CLI." is the perfect selling point for a DIY-er or someone running a small business. But what comes along with that low barrier to entry is a downside that could be very expensive when the s**t hits the fan.