What level of usage warrants these kinds of setups? Say, beyond a workflow that runs CI on PR/master off of Github (Actions or CircleCI etc) and deploys to something like Heroku or Vercel.
Do companies run apps that get 1k rps on stuff like cell-based-architechture (mentioned in top comment)?
Kinesis? Services operating at massive, hard-to understand scales?
FWIW, I work at Amazon, and a lot of things are still solved with "Boring" tech that's not "web scale". Even without our own ranks we've got to remind people that engineering is about fitting the architecture to the requirements and no more. It seems to be lost knowledge these days that an RDBMS gets you really, really far. The vast majority of apps -- even those that appear superficially "large" -- will never see usage patterns that justify anything more than a box and a database. You'd be surprised which systems are just humming along unceremoniously with a humble 3-tier architecture
So, as you scale up and out in size, you stop being able to depend on higher level abstractions from elsewhere.
You can't build a Tier-1 service like S3 or EBS on top of RDS. If you need a database solution to help you with building and running tools of that scale, it has to be something else that is a lot less complex and a lot more robust.
It's okay for RDS to be dependent on a Tier-1 service like S3 or EBS, but not the reverse. You don't want to get into priority inversion problems here.
And when your service has to be in every AZ in every region, and they all have to be kept separately running, then things get even more complex.
Then you have to ask yourself what is the bootstrap process for building a new region.
Do companies run apps that get 1k rps on stuff like cell-based-architechture (mentioned in top comment)?