Even if you are cloud native, it makes sense to have scaffolding to allow for vendor mitigation, unless you want to tie your entire companies future to the whim

Even if you are cloud native, it makes sense to have scaffolding to allow for vendor mitigation, unless you want to tie your entire companies future to the whims of a single company. Monitoring and persistence layers are cross cutting and already an abstraction with impedance mismatch already. You don't need a full blown SOA2 systems, just minimal scaffolding to build on later. Even if you stick to AWS for the remainder of time, that scaffolding will help when you grow, AWS services change, or you need a multi cloud strategy. As a CTO, you need to also de-risk in the medium and longer term, and keeping options open is a part of that. Building tightly coupled systems with lots of leakage is stepping over dollars to pick up pennies unless selling and exiting is your plan for the organization. The author doesn't mention what they had to write, but typically it is cloud provider implementation details leaking into your code. Just organizing ansible files in a different way can often help with this. If I was a CTO who thought this option was completely impossible for my org, I would start on a strategic initiative to address it ASAP. Once again you don't need to be able to jump tomorrow, but to me the belief that a vendor has you locked in would be a serious issue to me.