Maybe the point is that just having the S3 and CDN isn’t enough to move customers.
If you’re using AWS, S3 (and Cloudfront) it will just be a tiny part of your infrastructure, why would you move that out of AWS and lose the integration coming from having everything in AWS?
Because it's significantly cheaper and diversifies your presence across multiple providers.
It's a good idea to split origin and CDN, this way requests can be served from cache while origin is down or overloaded.
Plus I'd challenge the suggestions that S3 and CDN are a tiny portion of the infrastructure. For a lot of sites it's a significant chunk, things remaining wouldn't be many, maybe compute, DNS, and CI.
> diversifies your presence across multiple providers.
In this case, for most AWS/CF customers, that diversification is of the "downtime on either represents downtime for their customer" variety. (I'm still a fan of this offering and the pressure it put on the current high price of egress bandwidth, of course.)
If S3 was down, R2 would be up but the rest of your app on AWS would probably be down in the affected (based on the cascading failures in prior S3 outages) so most AWS users are going to be down.
If R2 was down and you didn’t rely on anything else that relied on R2, sure, you could repoint DNS and/or issue S3-direct URLs and then clean it up on the way back out.
“Additional options” doesn’t come without “additional complexity” and that complexity has a cost.
R2’s a great cost-saving move here; I don’t think it’s a reliability improvement generally.
It might be only part of your infrastructure but on many projects it’s a significant fraction of your total expenditure and storage egress is one of the things limiting use of external services. Having a cheap data access option makes it easy to reconsider those choices when you don’t have to factor egress into the cost of trying an alternative.