IMHO, vendor lock-in comes in different flavors, with different risks. I see IaaS like AWS (and others) like vendor lock-in but with a very long time life. Changing your infrastructure is kind of changing the language in which you wrote your applications. It can be done, but could only if the savings really overcome the costs. And the risks with some big players like this exist but are reasonable (depending on your cases) On the other end, I take vendor lock-in with SaaS very more seriously. Vendors provide great value (for a more or less hopefully reasonable price), but usually it's a smaller part of your application, and no matter the wrapping or abstraction you're trying to do, the treatment/transformations they do on your data, and why you choose them are quite difficult to replace without having to recreate this. (I'm thinking of many analytics solution here).

At the end of the day, engineering capacity is limited, and vendors can really help getting the non-core work of your application done. Hence for many of us you need to leverage vendors if you want to focus on the features of your product with some reasonable velocity. And thinking of vendor lock in is nice, because it forces you to ask the following questions:

• how likely is this vendor to disappear in a few months?
• how stable it their pricing policy (breaking API changes occurs, but in my experience, most of the migrations from a vendor to another solution - vendor or in house - has been caused by pricing changes or the vendor closing the shop)

Every team will have different needs and constraints, so take into account your own risk tolerance, your own need for velocity against your competitors (which would require you to spend less time on the underlying infrastructure) and all these kind of criteria.

Good luck if they discontinue the service or change the api in such a way that it breaks your system. Use these type of services sparingly or wrap it in a way that moving means you only have to change code in one place.

No other cloud services provider has features like AWS. You'll simply end up using more time developing services AWS already has. You can write your own services in containers and host them serparately, but that'd be re inventing the wheel. Unless you don't have time and resources (developers) constraint, you should definitely go with whatever saves you both time and money.