Because fundamentally there are tiers of service that one need to use: There's a critical core infrastructure - i would argue that it is: * some sort of centr

Because fundamentally there are tiers of service that one need to use: There's a critical core infrastructure - i would argue that it is: * some sort of centralized management platform even if platform is just a set of deploy scripts ( 1 instance ), * Origin DNS servers ( 3 instances - one per AZ) * HTTP/HTTPS entry points ( 3 instances - one per AZ) , * A couple of database servers ( say primary and a backup 2 - instances ). * I would add job server though it probably could be collapsed into the management platform. You need to have fixed IP addresses for this ( you really do not want to deal with service discovery at this level ) and you want it to be at a provider that won't ever make you need to renumber, or preferably a provider that does not ever break fundamental things like IP address assignment, or a provider that would run out of resources. One's "internet presence" disappears when this dies. Running all of this as a core workload on AWS/GCP/Azure is a no brainier - it will cost about $100/mo, be nearly insta-rebuildable and re-deployable and a couple configuration files in git would take care of bringing up the beach head up. At this point your core is up and everything else becomes service specific. This is the point where costs become a consideration but drive to low cost should not come at the expense of tooling. If by embracing ephemeral resources and existing tooling one can cut the base AWS/GCP/Azure price down by 80% most people would think it is a win over having to invest into building tooling to make containers stable ( as in always behave in a predictable manner ) on a provider that can shave off 95% of the costs. The biggest issues with the cloud providers is the cost of IO and cost of bandwidth which scales linearly with the workload but that's an issue for very specific subset of customers that should be hiring real ops people.