Curious, have you ever consulted a client not to use AWS? As in "your cost optimization is going to be not using AWS and using $x instead"?
That said, clients who come to me already have a significant investment with AWS. Getting rid of that is a high bar in terms of engineering effort.
That said, I've no financial incentive to recommend one provider over another. My clients pay me, the vendors do not.
We've pushed clients to competitors' products a few times, I was young and thought that was silly. However those clients spread the word about us and we didn't even have much of a marketing department, it was all word of mouth. Gaining their trust was gold and a really good long term investment.
"If you have content where you can't put a cache in front of it, and it drives significant bandwidth use, then AWS is not a great option"
Data driven applications on AWS are already expensive because of the high traffic costs, but storing/serving media on S3 single handedly lets your bill explode. For everyone who feels like the statements above are exaggerations, just check out their actual prices (https://aws.amazon.com/ec2/pricing/on-demand/) in comparison with a regular CDN (https://www.stackpath.com/pricing/).
But that's not what the commenter was saying, of course.
More like (paraphrasing) "before you go full-hog on AWS, do some simple math first." Which an amazingly high percentage of people neglect to do, these days.
I had a coworker who was turned off of AWS by clicking the "Dedicated IP" checkbox when deploying a CloudFlare distribution with SSL.
One month and $600[0] later he swears up and down that AWS is the devil.
You can spend an amazing amount of money on AWS by accident and/or without need. Hourly pricing is a huge footgun. Best to run everything through the "Simple" Monthly Calculator: https://calculator.s3.amazonaws.com/index.html
† About the monthly you-know-what bill now well into 5 figures, and climbing.
Your time is valuable too. It could be spent developing something novel instead of messing around with server configuration.
At the single instance very small scale, it simply doesn't matter all that much. "Our business failed because our infrastructure bill was $400 instead of $150 every month" isn't that common of a story.
Base load can be effectively migrated to AWS, depending upon how it's built / structured. It's hard to lose money on infrastructure by converting worker servers to spot instances or lambda functions, as a for-instance-- but it's VERY easy to lose months of engineering effort in doing so.
Remember as well: done right you're not just buying services from the cloud, but flexibility as well. Resizing on the fly, bursting, duplicating your infrastructure for a test-- these things add value.
A lot of teams rent space from places like OVH or Hetzner because the raw power is so much cheaper, and they already have the talent and tools to scale and manage a computing fleet (people like to think it's harder than it actually is).
Those marginal gains could potentially pay for a dozen engineers...
It depends. I have a toy service that exists entirely as an autoscaling group. That's pretty dynamic!
Counterpoint: Mainframes.
Step 1 is always "figure out what you've got, and why it is this way."
As you grow, start adding project tags to things. Automatically tag resources with the IAM user who creates them. Have an "untagged resources report" that goes out on a schedule.
Build with an eye towards "when someone freaks out in a year about the bill, what questions will they have, and how can I best position Future Me to answer them?"
Generally most of the time the best approach is to create solutions that can scale out independent from the HW / infrastructure they run on. With frameworks like K8s / Docker / e.a. this is now relatively easy.
With that for example you can start of with a few small cloud machines / docker containers. When you get continuous load - migrate some of them to 1-2 dedicated machines. Same with peak load - just spin up more images.
All that of course depends on what kind of application you are providing. If you are running a data intensive apps you might start directly with a dedicated machine.
Easy in, expensive out. One cost with cloud services many forget is the cost to get out again. Have a look at the AWS / Azure price-lists.
Respectfully, I'm going to disagree. I consult full time on AWS cost optimization / reduction / understanding.
If you blindly run things on AWS without an understanding of the costing model, that'll work for a time. As you scale, you start to realize "oh my god it runs on money."
There are myriad ways around that, but a blanket "never use AWS" isn't going to address it constructively.