I've been in an environment like this, and while I understand being reluctant to locking ones self into a relationship that will be hard to renegotiate later, i

I've been in an environment like this, and while I understand being reluctant to locking ones self into a relationship that will be hard to renegotiate later, it is self-defeating to try to abstract away everything your cloud provider , erm, provides. Here's what makes sense to me: 1. Design your system as components that communicate via interfaces you can implement easily anywhere. In other words, don't design your system to use a proprietary system to communicate. If you can't easily reimplement dynamo or s3, don't make that an inextricable part of your system between your services. 2. Use the cloud services that make implementation easier inside your services. The idea is to reduce the implementation effort/investment as much as you can. Sure, porting to something else could be costly later, but you are saving real effort now. When and if you do need to reimplement on another provider, attempt to do the same thing. 3. If your business doesn't really need or want cloud, don't do cloud. Doing cloud half-way is worse than a well thought out alternative.