I write event (think food festival) software. 9-10 months out of the year there is almost zero traffic, 1-2 months have mild traffic, ~2 weeks are higher traffic, and then 1-5 days (during the event) are very busy.
I'd be hard pressed to find anything other than my current stack (Lambda/DynamoDB/S3/Route53/APIGateway) that costs as little. In the off-months my costs are ~$5 if that and in the month of the event that might get as high as $15-30. I cannot imagine being able to host it locally/colocated (for the month of the event) for that cheap and that doesn't even touch on the hardware cost (I'm thinking just electricity and co-locating costs).
Yes, I'm a small fish and this is just my side business but for me the cloud is way cheaper. Anything with very spiky/uncertain load can be good candidate for the "cloud" but a big part (IMHO) of making the cloud work is using the managed services and using them smartly. If all you do is spin up EC2 instances then no, the cloud is probably not going to be cheaper in the long run.
I think you're almost always gonna pay far more for cloud compute than on-prem. It's pretty standard for companies to have roughly 2x the "peak" load than "minimum" load, so while with on-prem you maybe have to over-provision by ~1.5-2x, that's greatly outweighed with how much more expensive cloud compute is vs. on-prem compute. The only exception is companies with extremely spikey demand - e.g. if your peaks are more like 10x or 100x your troughs, then yeah, cloud is probably cheaper from a pure compute POV.
However, unless you use HUGE amounts of compute, cloud is probably the right choice, because you probably save a tonne on salaries by going the cloud route. It's way easier to properly operate a managed DB than your own (especially in terms of no-downtime upgrades, no-downtime scaling, backup/recovery, etc.), same goes for managed file storage (S3 type things), same goes for managed pub/sub, same goes for managed K8s/whatever, same goes for managed load balancers, etc. For a lot of startups, total cloud spend is equivalent to just a few fulltime Engineer salaries, and they also use a tonne of cloud services, getting that all running well without AWS (or Google Cloud, Azure, whatever) would take way more than a few fulltime Engineer salaries.
FWIW, the last company I worked at (~1000 people), as our AWS bill was getting into the millions annually, we tried migrating off AWS, onto a colocation setup. I didn't work on that project myself, but my understanding is they spent a bunch of engineering effort on it, were still nowhere remotely close to being able to truly move off AWS, ultimately canned the project and moved all the colo stuff back to AWS. I think a lot of engineers underestimate how much effort it is to provide the kind of cloud services Amazon/Google/Microsoft provide, at comparable levels of reliability and ease of use. It's A LOT of effort.
With fixed hardware, you're always planning for max workloads.
The systems are scaled up for the "Black friday" sales event.
With cloud, you will plan for the steady state and just boost it up when you need to.
The anti-pattern is usually that when on-prem hits 80% load, some engineer is usually tapped to weed out all the slow code to push past procurement delays.
While in cloud, people just throw more hardware at it and ignore low hanging performance problems which are costing them money (& unlike the on-prem, fixing it will immediately reflect in the budget the next day).
At low scale it can definitely be true. My startup spends $0 on ops salaries because it's possible for an AWS-proficient backend dev to not need more than an hour or two a week to maintain the entire production infrastructure. Our AWS bill costs us less than it would take to hire a person to run on-prem physical infrastructure.
Not sure if you consider small startups to be realistic scenarios, though, so perhaps this doesn't count.
Their peak demand is insane, especially at race start, and is only sustained for a few hours for ~20 weekends a year.
AWS have already built a live streaming stack for their other customers with DRM and support for a wide variety of platforms. And there are other features like live rewind, restart, live to VOD etc.
It is also relatively straightforward to serve new countries, you don't have to build data centres all over the world, just stand up your infra in a new region.
Four jobs ago I worked on a search engine for a large national sales company. They'd sparingly ran TV ads. When they ran a TV ad their traffic would 10x immediately then a mild smooth increase over the next month or so. Would it have made sense for them to operate on prem machines that could handle their peak capacity, when they only needed their peak for hours per week?
A) a user base with usage that varies significantly over time
and
B) an architecture that can actually scale significantly up and down during the same time period
So if you have lots of web back ends and business logic and general workers for jobs that can just be shut down when there's no capacity needed, there's a ton of savings available in the cloud.
If you have a big monolithic architecture or some other organization where everything is just on all the time, the cloud makes less sense as a cost savings.
I once wrote an internal chat bot which was used less than 2 seconds per day, but was actually supremely useful as it really simplified some process or another and took a fraction of a second to run each time. The actual cost to run this in the cloud was approximately 1 cent per year. If I didn't have this cloud capability it would be hundreds of dollars per year to host or thousands of capital in machines and maintenance to host myself.
