I wonder how much of this is a primary goal or just a nice side-effect for AWS. I imagine the custom internal forks of all this stuff, and their own data manage

I wonder how much of this is a primary goal or just a nice side-effect for AWS. I imagine the custom internal forks of all this stuff, and their own data management systems are simply not compatible with the native variations that the products themselves have. From AWS's perspective it might seem wasteful to pro-actively support outbound data, and as a nice side-effect it makes it harder to leave or host an alternative. For us, this is just part of the calculation; if we have special cases we run it ourselves, but the case also has to justify the inter-AZ replication and other side-effects. The way we use AWS services also assumes migration paths outside of what you would normally do (binlog or CDC options) where we don't migrate 'the database' but 'the service' that relies on the persistence offering. This is of course much harder if some of your functionality relies on AWS-specific things, but for the average persistence system (ES, RDBMS, NoSQL, Redis, Memcache, object storage, Kafka, MQ) it really isn't all that exciting and the AZ cost is hardly a significant factor of the showstopper kind. Perhaps this also is due to the way we designed our persistence systems; we only allow single-owner persistence, so no shared redises, databases or tables or schemas. We also don't do any binlog PITR, we use Kafka rewinds in between RDBMS snapshots since the database isn't the only factor in our consistency and partition tolerance conundrum. And Kafka itself is so 'thin' on the server side that binary exports/imports are only tied to the major version and highly dependant on what the client does (which is something AWS does not control - if they would their MSK offering would be useless). Using AWS as a 'virtual datacenter' or 'managed version of the thing you already have' is bound to turn into a PITA. That applies to GCP as well, but almost 10x for Azure. Ironically, you're better off not using the big three if that is what you want, you don't get a lot of the features, but you also pay a fraction of the cost. And if you're not using the features anyway (or see them as a problem), Linode, Vultr, DO, even Scaleway are all a much better fit anyway. In my cases where we use AWS, it's almost always for the same reasons: - We use enough of it to get discounts - We use enough of it to allow us to do 10x with the same people, it is a very significant force multiplier - We require some of the cross-service facilities like IAM, KMS, ACM, Security Groups In a small number of cases it's also for compliance reasons, but I try to stay away from that since that usually comes with a checkbox clipboard manager/auditor regime as well, and I don't enjoy managing or working for those.