Use code pipeline/cloud build then either container registry and ecs or beanstalk.
You get everything you mentioned for free with either set up.
Seriously it takes moments to write terraform or even do it by hand.
Use code pipeline/cloud build then either container registry and ecs or beanstalk.
You get everything you mentioned for free with either set up.
Seriously it takes moments to write terraform or even do it by hand.
This comes on top of the benefit that architecting for multi-cloud at that scale usually forces you to simplify/rationalize/automate ruthlessly and so is probably beneficial for a "mature" org with lots of cruft anyway.
That said there may only be a few dozen companies in the world where this makes sense. I happen to work for one, but most engineers don't. Even then, this is at the extreme right of the maturity curve, meaning that there is lots of lower-hanging fruit to pick first
So yeah, one of the clients we were working with had to move from AWS to GCP (mostly for utilizing cloud credits). The setup was small but the estimated time was nearly 2-3 months. It's really a pain, and I think a lot of organizations don't think of doing it because when they weigh rewards and the effort/time needed, it doesn't make sense.
If we need to move it then we move it... not exactly difficult or time consuming. There are always ways of half moving things too, for example we could move the container deployment to another cloud but keep our build process and object store at the original vendor and so on.
In reality we are not going to be shifting production load between cloud vendors every 2 weeks.