(1) You save a ton of money on bandwidth when you move data from AWS to AWS
(2) Your stack, in most cases, needs to be near each other to minimize latency. Databases get wrecked by this.
This is why, cloud database providers have to often transparently show you which cloud you're launching on  which effectively means AWS is going to get a good share of it anyway. My uninformed guess is that EC2&S3 are by far their biggest money maker which is going to be what unbundlers target.
I'm all for the unbundling and will probably take part in some of it, but I don't think it will be that easy.
This is only because AWS grossly overcharges for bandwidth. If you move all services that have high bandwidth requirements to providers with reasonable prices you'll save a significant amount of money.
Further, Snowflake is a good example of an unbundled service that has more capabilities than AWS Redshift (for instance, zero copy clones). They use AWS for infrastructure - the entire warehouse is stored on S3 - and value add on top of it.
So why choose differently ?
AWS's killer feature has nothing to do with tech, it's the smooth billing process (techies choose, management pays and supervises). If you can put together a smooth process for paying for 3rd party software in your organization, you can unlock massive improvements in quality for a pittance.
I almost mentioned IAM in my post as a co-killer-feature, but I've only ever witnessed its power in AWS learning material / conferences, not being leveraged IRL, so I decided not to speculate. I'm more dev than ops, so even though I've seen a decent number of AWS environments the fact that they have all used IAM in a clumsy, coarse manner doesn't really mean much.
Do you have a feel for how frequently ops manages to actually leverage the fine-grained power features in IAM?
The issue I have with IAM is that it is not possible to be sufficiently fine grained - for example I cannot grant an instance permission to read its own tag values but not those of other instances, since the EC2 IAM API is stuck in the state of 85% done at which most AWS services eventually seem to plateau.
From my experience, Snowflake is both more performant AND cheaper than Redshift or other RDS options from AWS.
Would add that edge compute, running cloud paradigms (code instead of config; automation; management abstractions), partially addresses these limitations for many use cases.
Costly to move the data off, but longer-term ROI for those orgs that are willing to make long-term decisions.
Meanwhile, as edge matures, greenfield apps should be edge-centric, rather than cloud-centric (doesn't mean they won't have cloud components...they will do the processing and storage where it best makes sense).
Couldn't you build your software stack in a cloud-portable way but, at any given time, still have 100% of it on whatever your current cloud provider is? And then switch to another cloud provider from time to time if/when the costs make it worthwhile.
The first problem is that you wind up using the least common denominator. You’re paying public cloud providers a premium, so this essentially equates to throwing away money.
The second is that there are some cases where what seems like the same thing isn’t, or best practice is wildly different between providers. Get in a room with an AWS expert and an Azure expert and talk about what an account is.
In other words, it's not about moving your entire stack off Amazon's cloud, it's about moving parts of your stack off Amazon's software even if all of it may still run inside Amazon's cloud.
You're simply moving from being locked in by AWS to being locked in by a bunch of much smaller cloud vendors.
2) Contemporary site/app development renders the latency of individual requests irrelevant. The whole page is going to boop and bounce around for 20 seconds anyway, why make a big deal about it?
The web is a measurably worse experience now than it was 10 years ago (maybe even 5), so it's ironic that Goodhart's Law has led so many astray toward measuring smaller and smaller trees within a growing forest. "Well but we have to get the request for number of friends below 10ms" while the other 400 requests on the page are dilly-dallying and experiencing their own latencies. Then the CSS gets applied.
I've managed racks for customers too, but managed hosting at Hetzner is now usually cost-effective vs. colo-hosting in London where I am. Since they also offer cloud services (though pretty basic) now, there's the option of mixing and matching.
Paying for use isn't awful, as long as you're not paying AWS list prices which are rather high.
AWS is lets say .08 per GB or $30K/month for same bandwidth?
And if you beleive you can run your business on their $15/month network then they would own the market - but oddly they peer with basically NO ONE of any quality - because THEY don't actually pay for the bandwidth either and just totally oversaturate their peering links.
for some of the common whining at least in the past.