compliance.tf
Compliance ControlsAmazon SageMaker

SageMaker notebook instances should be encrypted using CMK

SageMaker notebook instances store ML models, training data, and exploratory code on attached EBS volumes. The default AWS managed key encrypts this data, but you cannot control its rotation schedule, define key policies, or audit its usage independently through CloudTrail. A CMK gives you direct control over who can decrypt the volume, lets you revoke access instantly by disabling the key, and produces a clear audit trail of every cryptographic operation.

Data science workloads frequently process sensitive datasets including PII, financial records, or healthcare information. Without CMK encryption, you lose the ability to enforce separation of duties between the team that provisions notebooks and the team that controls encryption keys.

Retrofit consideration

Changing the KMS key on an existing SageMaker notebook instance requires stopping the instance, and in some cases recreating it entirely. Terraform will force replacement if kms_key_id is added to an instance that was created without one.

Implementation

Choose the approach that matches how you manage Terraform.

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 aws_sagemaker_notebook_instance resource must include kms_key_id set to the ARN of a customer managed KMS key. A configuration passes when kms_key_id is present and references a valid CMK ARN rather than an AWS managed key alias like alias/aws/sagemaker. It fails when kms_key_id is omitted or empty, which causes SageMaker to fall back to the default AWS managed key. The referenced key should exist as an aws_kms_key resource or data source with a key policy granting SageMaker kms:CreateGrant, kms:Decrypt, and kms:GenerateDataKey*.

Common pitfalls

Force replacement on existing instances

Terraform will destroy and recreate the notebook instance when you add kms_key_id to an existing resource. The local EBS volume data doesn't survive the replacement. Back up notebooks to S3 using lifecycle configurations before applying the change.

Key policy missing SageMaker grants

The CMK's key policy must allow SageMaker to use the key. If the policy lacks kms:CreateGrant for the sagemaker.amazonaws.com service principal (or the notebook execution role), instance creation fails with an access denied error even when kms_key_id is correctly set.

Using AWS managed key alias passes Terraform but fails control

Setting kms_key_id to alias/aws/sagemaker or the ARN of the AWS managed SageMaker key passes Terraform validation but fails this compliance control. The check specifically requires a customer managed key where KeyManager equals CUSTOMER.

Cross-region key references

KMS keys are region-specific. Reference a CMK ARN from a different region than the notebook instance and creation will fail. Make sure the aws_kms_key or aws_kms_alias data source targets the same region as the aws_sagemaker_notebook_instance.

Audit evidence

Auditors expect AWS Config rule evaluation results showing all SageMaker notebook instances have a non-null KmsKeyId referencing a customer managed CMK. The aws sagemaker describe-notebook-instance CLI output for each instance should include the KmsKeyId field with a CMK ARN. Cross-referencing that ARN against aws kms describe-key should confirm KeyManager is CUSTOMER, not AWS.

CloudTrail logs for CreateNotebookInstance and UpdateNotebookInstance calls should show KmsKeyId in the request parameters. Compliance scan output from Prowler or Security Hub with the relevant check enabled works as continuous evidence between point-in-time reviews.

Framework-specific interpretation

PCI DSS v4.0: For notebooks that handle cardholder data, Requirement 3.4 requires PAN be rendered unreadable at rest and Requirement 3.5 covers protecting the keys used for that purpose. CMKs let you enforce key access through IAM and key policies, and revoke decryption access without touching the underlying data.

HIPAA Omnibus Rule 2013: 45 CFR 164.312(a)(2)(iv) lists encryption of ePHI at rest as an addressable implementation specification, meaning covered entities must implement it or document why an equivalent measure was chosen instead. SageMaker notebooks used for healthcare analytics routinely land ePHI on local EBS volumes during processing. CMK encryption gives you the access control and CloudTrail auditability needed to demonstrate the technical safeguard is in place.

ISO/IEC 27001:2022: A.8.24 (Use of Cryptography) expects encryption keys to be governed under an organizational cryptographic policy, not delegated to the service provider. Customer managed keys let you define ownership, set rotation schedules, and restrict usage to authorized principals, which is what A.8.24 asks you to document in the ISMS.

GDPR: Article 32 calls for technical measures appropriate to the risk. For notebooks processing personal data, CMK encryption means the data controller retains direct control over decryption access and can revoke it immediately by disabling the key, supporting data protection by design without depending on AWS to manage the key material.

NIST SP 800-53 Rev 5: SC-12 and SC-28 together require organization-managed cryptographic key lifecycle controls and protection of information at rest. CMKs satisfy both: they give you rotation control, the ability to revoke access by disabling the key, and an independent audit of every decrypt operation through CloudTrail.

FedRAMP Moderate Baseline Rev 4: At the Moderate baseline, SC-12 and SC-28 expect agency-managed key material for federal data. An AWS managed key doesn't satisfy this because the key lifecycle sits outside organizational control. CMKs let you document key ownership, rotation, and access controls in the system security plan.

Tool mappings

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

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

Last reviewed: 2026-03-09

On this page

Ask AI about this

Help improve this page