SageMaker notebook instance encryption should be enabled

SageMaker notebook instances store ML models, training data, and exploratory code on attached EBS volumes. Without an explicit kms_key_id, you lose key-level governance and may fail controls that require explicit KMS key configuration, even when account-level EBS default encryption is enabled.

Data scientists frequently work with production datasets containing PII, financial records, or health information. A single notebook volume without explicit KMS encryption can quietly become a gap in an otherwise encrypted data pipeline.

Retrofit consideration

Existing notebook instances cannot have KMS encryption added after creation. You must stop the instance, create a new one with kms_key_id set, and migrate any saved notebooks and data. This causes downtime and requires re-attaching lifecycle configurations.

Implementation

Choose the approach that matches how you manage Terraform.

Terraform resources

Use AWS provider resources directly. See docs for the resources involved: aws_sagemaker_notebook_instance.

resource "aws_sagemaker_notebook_instance" "this" {
  instance_type   = "ml.t2.medium"
  name            = "pofix-abc123"
  role_arn        = "arn:aws:iam::123456789012:role/example-role"
  security_groups = ["sg-12345678"]
  subnet_id       = "subnet-12345678"

  kms_key_id = "arn:aws:kms:us-east-1:123456789012:key/12345678-1234-1234-1234-123456789012"
}

What this control checks

The control validates that aws_sagemaker_notebook_instance has kms_key_id set to a valid key identifier, either a key ID or key ARN. When kms_key_id is omitted or empty, the control fails. To pass, set kms_key_id to a key in the same region as the notebook instance. The SageMaker execution role must also hold kms:Decrypt and kms:GenerateDataKey permissions on that key.

Common pitfalls

Encryption cannot be added to existing instances
kms_key_id is a ForceNew attribute on aws_sagemaker_notebook_instance. Changing it triggers resource destruction and recreation, which deletes any data on the notebook's EBS volume. Back up /home/ec2-user/SageMaker contents before applying.
KMS key policy must grant SageMaker access
CreateNotebookInstance fails with AccessDeniedException if the key policy omits kms:CreateGrant, kms:Decrypt, and kms:GenerateDataKey* for the SageMaker service or the notebook's IAM role. Terraform won't catch this at plan time.
Cross-account KMS keys require additional grants
A kms_key_id from a different AWS account requires both a key policy in the key-owning account and an IAM policy in the notebook account. Missing either side causes creation failures that surface only at apply time.
Default SSE-EBS encryption is not the same as this control
Account-level default EBS encryption via aws_ebs_encryption_by_default may encrypt the underlying volume, but compliance checks specifically look for the KmsKeyId field on the SageMaker API response. Relying on default EBS encryption alone will still fail this control.

Audit evidence

Auditors expect Config rule results showing sagemaker-notebook-instance-kms-key-configured as COMPLIANT for all notebook instances, plus aws sagemaker describe-notebook-instance output with a non-null KmsKeyId for each. The KMS key policy should confirm only authorized principals hold decrypt access. CloudTrail CreateNotebookInstance events showing KmsKeyId was passed at creation round out the evidence, along with a full inventory confirming no instances were created without it.

Framework-specific interpretation

SOC 2: CC6.7 covers protection of data in transit and at rest. A customer-managed KMS key on notebook storage means access depends on both IAM permissions and cryptographic key access, which is precisely what the criterion expects.

PCI DSS v4.0: Requirement 3.4 mandates that PAN be rendered unreadable where stored. For notebook instances that process or store cardholder data during analysis, KMS encryption provides that protection. Requirement 3.5 adds key management obligations that a customer-managed key helps address.

HIPAA Omnibus Rule 2013: The Security Rule's encryption addressable specification at 164.312(a)(2)(iv) requires a technical safeguard against unauthorized disclosure of ePHI. Encrypting notebook volumes where ePHI might be loaded or analyzed covers this specification.

GDPR: Article 32 requires appropriate technical measures proportionate to the risk, with encryption listed explicitly. ML notebooks frequently handle personal data during analysis, and encrypting the attached storage is a direct application of this obligation.

NIST SP 800-53 Rev 5: SC-28 calls for cryptographic mechanisms to protect the confidentiality of information at rest. Encrypting SageMaker notebook volumes with KMS satisfies this requirement for ML workstation data.

FedRAMP Moderate Baseline Rev 4: At the Moderate baseline, SC-28 requires encryption of federal data at rest using FIPS-validated cryptographic modules. KMS keys backed by FIPS 140-2 validated HSMs meet that requirement for data processed in SageMaker notebooks.

Tool mappings

Use these identifiers to cross-reference this control across tools, reports, and evidence.

Compliance.tf Control: sagemaker_notebook_instance_encryption_at_rest_enabled
AWS Config Managed Rule: SAGEMAKER_NOTEBOOK_INSTANCE_KMS_KEY_CONFIGURED
Checkov Checks: CKV_AWS_187, CKV_AWS_22
Powerpipe Controls: aws_compliance.control.sagemaker_notebook_instance_encrypted_with_kms_cmk, aws_compliance.control.sagemaker_notebook_instance_encryption_at_rest_enabled
Prowler Check: sagemaker_notebook_instance_encryption_enabled
KICS Query: f3674e0c-f6be-43fa-b71c-bf346d1aed99

Last reviewed: 2026-03-09