One of them did a bunch of stuff that made use of AWS - but it didn't deliver any value to our customers, and probably made our product substantially worse. It cost $30k a day, and unquestionably was not worth the cost, and everyone on the team was fired after a few months.
A lot of companies are fine just using a handful of VPSes.
I think the biggest problem with starting on AWS is engineers are extremely susceptible to playing with new toys - for better or worse.
Engineers are going to try all AWSes new stuff, which is fine. The problem stems from engineers wanting to do stuff on the newest shiniest AWS toy whether that actually makes sense financially or much more importantly in terms of the product roadmap.
If design docs don't at least mention the cost - and your business cares about cost - then you should probably have a chat with the engineering dept.
At a prior FAANG job we included basic cost analysis in our decisions. You don't always need the cheaper option if it doesn't make sense, but you should probably know the traffic that shiny new toy will receive and the cost associated with it. (eg. soln A needs 25% more compute, and the internal price is X vs soln B needs 10% more compute, but will increase storage costs for caching at X per gb for ~Y gb).
I recall a case where a coworker (Senior SDE in Silicon Valley, so easily 25k a month salary) spent a month reducing our $500 SQS bill to $350 because our director wanted to see teams making smart financial optimizations. Meanwhile, our EC2 bill was $50k a month. Not everything is smart financially to focus on fixing. What is the compSci quote on premature optimization?
Of course, if you can't trust your developers to spend money wisely, you need guardrails on cost, no matter where you're spending it.
Sure - not everything at these companies needs to be on the cloud. But when you're dealing with sensitive information, you don't want people rolling their own infrastructure.
[0] https://press.aboutamazon.com/news-releases/news-release-det...