> KMS is a hermetic system with no operator access with HSMs at its root, so that provides a pretty meaningful difference.
So, if I don't use a CMK (Customer Managed Key), what am I getting instead? Assumed (perhaps naively) KMS would still be used under the hood.
> a single change on a shared CMK can render an unbounded number of S3 objects inaccessible quickly.
I feel like you could achieve that with an IAM policy. I guess the key can apply to a wide range of unrelated AWS services so act like a ~meta policy. Seems useful.
And yep, a CMK can span many services and still give you a single point of control.
But compliance is still the major thing. Many regulators, auditors and compliance authorities are just happier with KMS being the point of control. Even though AWS operates KMS, and the services, KMS is a neat compartmentalized hermetic system with HSMs at its root. So it's quicker and neater to evaluate its surface area, TCB, and so on and it's a familiar pattern to finance and health regulators especially.
For a case like this, the upshot of it is that with permissions on the KMS key, S3 is effectively locked out and can't fetch it. KMS is a hermetic system with no operator access with HSMs at its root, so that provides a pretty meaningful difference. It also means that controls can be handled by different customer teams, and that a single change on a shared CMK can render an unbounded number of S3 objects inaccessible quickly.