> the most funny thing is that cloud engineering teams have no problem of using EC2 hosts, but somehow don't want to rent dedicated servers/VPC from regular datacenter companies.

It is trivial to provision and unprovision an EC2 instance automatically, within seconds if your deployment needs to scale up or scale down. That's what makes it fundamentally different from a bare metal server.

Now, I'm not denying that it might still be more cost effective when compared to AWS to provision a few more dedicated servers than you'll need, but when you have really unpredictable workloads it's not easy to keep up.

the whole concept of a need to spin up more VM instances to meet increased load is flawed and is driven by cloud vendors to make money.

if you are spinning up and shutting down VMs to meet demand curve - something is seriously wrong with your architecture.

Did it ever occur to you, how come stackoverflow uses ~8 dedicated servers to serve entire world and doesn't need to spin up and shutdown VMs to meet global customer demand?

--

When planning compute infrastructure, it is important to go back to basics and not fall for cloud vendor's propaganda

> serve entire world and doesn't need to spin up and shutdown VMs to meet global customer demand?

You said it yourself. Not all applications need to serve entire world, therefore demand will be lower when people go to sleep.

Even with global applications there are regulations that require you to host applications and data in specific regions. Imagine an application that is used by customers in Europe, Australia, and the US. They need to be served from regional data centres, and one cluster will be mostly sleeping when the other is running (because of timezones). With dedicated servers you would waste 60-70% of your resources, while using something like EC2/Fargate you can scale down to almost 0 when your region is sleeping.