AWS KMS Key Scope Guide


This guide recommends how and why to scope KMS keys in order to control access to data effectively and support encryption at rest.  This guide is written for Architects and Engineering & Security Management who are designing an AWS data security strategy.

Guidelines and Considerations for Scope of AWS KMS Keys

The scope of usage for a given key managed by AWS’ Key Management Service (KMS) should be bounded by the primary architectural and organizational boundaries of the data being protected.

The SDLC Stage (Environment) that data belongs to should be included is a dimension in all further segmentation to enforce partitions between environments.  Segmenting by stage should  prevent an application or user in a low security context (dev) from reading data from a high security context (prod), by default.

When thinking about the following scopes, keep in mind that (people) operators and owners of the data may need an IAM entity with at least privileges to decrypt the application’s data to support debugging, at least during development.

You might choose to provision keys for any of the following dimensions:

  • Business Unit + SDLC Stage
  • Functional Domain + SDLC Stage
  • App + SDLC Stage
  • Team + SDLC Stage

Effective IAM for AWS

Effective IAM book

Learn how to secure AWS with IAM built for continuous delivery.

KMS key scopes

Business Unit + SDLC Stage

The business unit, e.g. Retail/Business Intelligence/Enterprise, and SDLC Stage, e.g. dev/stage/prod, provides a coarse-grained scope enabling a wide swath of people and applications within a business unit access to a dataset.  If you have adopted k9 Security’s recommended segmentation of AWS accounts by Business Unit and Stage of the SDLC, then the default keys within an AWS account effectively provide this segmentation.  A key with this wide of a scope might be appropriate for implementing a ‘default’ key to use for ensuring encryption at rest.  This is good for ensuring e.g. all data in a bucket is encrypted, but there’s no meaningful access control provided by using this key aside from verifying the data is being accessed by an IAM principal belonging to the account or the account itself.

Functional Domain + SDLC Stage

A key provisioned for a particular functional domain, such as patient data or orders, in a given stage is useful for protecting that domain’s data.  One useful pattern is to give some roles the ability to Encrypt data, but not the ability to Decrypt it.  These write privileges could support a semi-trusted data collection process, while the ability to decrypt the data is reserved for a separate downstream process using a different role.  Organizations that partition AWS accounts by Business Unit and SDLC stage will often scope keys to a functional domain.

Application + SDLC Stage

The finest granularity of a scope likely to find widespread use is that of a single application in a particular SDLC stage.  An application-scoped key should be used when an application must ensure that some data remains private to itself, typically identified by an IAM role.

One interesting use case for application scoped keys is ‘locking’ application data to a process with a current IAM principal authorized to decrypt it.  For example, an identity management application could encrypt application-level password hashes before storing them in a database to ensure that only a process that currently has access to decrypt data with the application’s key may do so.

Team + SDLC Stage

A team of people might choose to store sensitive documents in AWS and encrypt those documents with a key available only to members of their IAM group or those able to assume the team’s role.  This data would be separate from applications developed by the team and could include sensitive communications, large binaries with secrets built into them, or secrets that have not (yet) moved to a secret repository.

Lock down access to the key

Once you have provisioned KMS keys to protect data with appropriate scopes, the next step is to lock down access to those keys. It is very common for IAM principals to have permissions to encrypt or decrypt on all keys in an account. But you can use KMS key policy to establish a data perimeter to scale your data access management.  And k9 Security provides KMS key policy generators for Terraform and CDK to help you lock down access to KMS keys.  Our IAM access analyzer can tell you who has administration, read, and write capabilities for your keys.


This guide recommends several scopes for AWS Key Management Service (KMS) keys.  The scopes align with architectural and organizational boundaries and the Software Development Life Cycle (SDLC) stages. k9 Security advocates for segmenting access based on the SDLC stage to maintain a strong security posture, ensuring development environments cannot access production data.

Key scoping dimensions presented include combinations of Business Unit, Functional Domain, Application, Team, and SDLC Stage. Each offers varying levels of granularity and access control:

  • Business Unit + SDLC Stage: Provides broad access across a business unit, useful for a ‘default’ key ensuring encryption at rest but limited in meaningful access control.
  • Functional Domain + SDLC Stage: Protect specific data domains, allowing differentiated access rights for data collection and processing use cases at the domain granularity.
  • Application + SDLC Stage: Ensures data privacy for individual applications, allowing differentiated access rights for data collection and processing use cases at the application granularity.
  • Team + SDLC Stage: Facilitates encryption for sensitive documents accessible only to specific team members, separate from application data.

KMS key scopes are a crucial tool for ensuring data security and enforcing access control within AWS environments.  k9 Security hopes this guide has helped you and is happy to help with any questions.

Contact Us

Please contact us with questions or comments. We’d love to discuss AWS security with you.

Effective IAM for AWS

Effective IAM book

Learn how to secure AWS with IAM built for continuous delivery.