KMS key per application or per service

Hi,

I don't think there is a 'one size fits all' answer here. I think you need to think about: -

• Account strategy - are you separating by environment, application, business unit, scope of external accreditation (e.g. PCI-DSS)
• Who's developing / administering the applications (one team, multiple teams etc.) and whether it's being done via shared tooling, separate tooling etc.
• How highly you want to separate your data

I wouldn't personally suggest you create a central KMS account and then share the keys out from there in a large environment. It's complex from a permissions point of view and in very large environments you could end up with throttling issues.

You also want to think about the costs of KMS. There's a cost per key, and also the way you use KMS in services like S3 can significantly impact the cost of KMS API usage.

There's an AWS best practice guide to KMS that might be useful to you here.

I'd be inclined to go for one key per application, rather than a shared key per service, or multiple keys per application, unless you're specifically trying to do something different with the data and want to limit the rights to a certain area (e.g. archive) using both IAM permissions as well as limits on what can be done with the keys, yuor application uses different classifications of data that you need to treat differently (different algorithms, being backed by a HSM etc.) or using different purposes (e.g. encrypt / decrypt versus sign/verify).

Mark