The problem is that the FAANGS run single-process servers at a scale of thousands of VMs, so in their mind 1 VM == 1 App role. They have no concept of sharing a single VM for dozens of apps.
Google invented Kubernetes, Apple runs Kubernetes and previously was heavily into Mesos, likewise for Netflix. And I've seen a lot of Engineering tech blogs and worked on AWS for a decade and never have I ever seen anyone spinning up thousands of micro-VMs in that way.
Not only are there all sorts of account limits you would immediately hit and have to negotiate but the networking would be problematic to say the least.
Meanwhile you can spin up ECS, EKS, Fargate which allow you to run thousands of containerised apps without any headaches at all. Plus they support you having unique IAM roles for each container.
It's functional, but I think it's not as polished as the rest of Kubernetes which is why Kubernetes has a multi tenancy SIG that spawned the hierarchical namespace controller (https://github.com/kubernetes-sigs/hierarchical-namespaces) and virtual clusters (https://github.com/kubernetes-sigs/cluster-api-provider-nest...)
"Multi-tenancy in Kubernetes: implementation and optimization" - https://www.cncf.io/blog/2022/11/09/multi-tenancy-in-kuberne...
"...As we can see from the above discussion, the sharing of Kubernetes clusters is not an easy task; multi-tenancy is not a built-in feature of Kubernetes and can only be implemented with other projects’ support in tenant isolation on both control and data planes. This has resulted in considerable learning and adaptation costs for the entire solution. As a result, we are seeing an increasing number of users adopt multi-cluster solutions instead..."
While ECS/Fargate is easier, it’s still not headache free and you’re not taking into account how many large enterprises run lots of commercial off the shelf software on VMs.
They do, it's called a container or a function, which have their own IAM/auth/role.
The problem is that many companies have very rigid IT departments so even though in theory it can be done somewhat easily, in some places it can be a months-long process to actually get it done.
I have a government customer running 150 web apps in about 20 vCPUs. If you naively multiply 150 apps by the minimum scale for HA, non-prod, and the 2 vCPU minimum for cloud hosts you end up with 450-600 vCPUs! That’s expensive even for governments.
While it's technically possible to run something like an old ASP.NET Web Forms app in a container, it'll be painful.
You should have put that in your first comment, I've removed my downvote!
Az functions might not be the most optimal in terms of per request cost, but for the volume of traffic we are pushing it doesn't scale into the equation.
Operationally, they're basically magic. TLS, auth, etc. all handled. GitHub deploys with zero drama. Whatever margin we sacrifice at the request billing is more than compensated by how well our engineers are sleeping at night.
B. Enterprises run a ton of commercial off the shelf software hosted on VMs
C. Ever heard of Windows? It’s still big in the enterprise
There's also shared vs dedicated and burstable options if you need to go lower. Which clouds don't (in practice) offer 1 vCPU?
GovCloud may be different for security purposes, not sure.