As you said, using a key they generated (but not the default key) doesn't protect you from AWS-side attacks. The main advantage is more control over the key &

As you said, using a key they generated (but not the default key) doesn't protect you from AWS-side attacks. The main advantage is more control over the key & permissions on your side of the shared-responsibility model. AWS default key has a fixed policy and is wide open to your account, so it's not suitable for: - Using different keys for different situations/data within the account; this can help with defense-in-depth & errors in least privilege from escalating. Example: Lambda accidentally has overly-permissive S3 permissions, and you're using the default key. It could potentially read more S3 buckets/files than intended. With different keys, it couldn't decrypt the data in other buckets. - Using different accounts. Default keys are only usable within your account, you can't grant access to use it to other accounts (which might sound odd, but there's use cases where you'd consider doing this) - Default keys can't be used by some AWS services, e.g. the default key policy can't be used by CloudWatch Events to enqueue to an encrypted SQS queue, for instance. (workaround is adding a resource-policy to the queue, but I personally do not like resource-based policies -- I like all my permissions in IAM roles & policies so there's one place to audit and control) All this said, I often leverage the default keys heavily, as using your own KMS key is more expensive.