Cloud Security Index
aws

high

Compliance Frameworks

BETA
NIST 800-53 Rev 5
SC-28
HIPAA
164.312(a)(2)(iv)
PCI DSS v4.0
3.5.1
ISO 27001:2022
A.8.24
SOC 2
CC6.1
CIS AWS Foundations Benchmark v3.0
2.2.1
AWS Foundational Security Best Practices
EC2.7

// Beta Mapping Disclaimer

Framework mappings are currently in beta. These references are generated based on technical specifications and common industry alignments. Mappings may be incomplete or inaccurate; always consult with a qualified auditor for official compliance validation.

Overview

Enforce encryption by default for EBS volumes and S3 buckets across the organization using AWS Organizations SCPs, EC2 account-level defaults, and S3 bucket-level default encryption settings.

Encrypting data at rest is a fundamental security requirement in any landing zone. AWS provides two complementary mechanisms that operate at different layers. At the account level, EC2 offers an "EBS encryption by default" setting that automatically encrypts all newly created EBS volumes and snapshots using a KMS key - either the AWS-managed default (aws/ebs) or a customer-managed key (CMK). At the organizational level, an SCP can deny any s3:PutObject request that lacks a valid server-side encryption header, preventing unencrypted object uploads regardless of bucket policy. Together with S3 bucket default encryption (SSE-S3 or SSE-KMS), these controls form a defense-in-depth approach that does not rely on individual developer or operator action in member accounts.

Encryption at rest protects data from unauthorized access if physical storage media is compromised, decommissioned insecurely, or accessed by cloud provider staff. It is a baseline requirement in virtually every regulatory framework (PCI DSS, HIPAA, NIST, ISO 27001). Centralizing enforcement via SCP and account-level defaults removes the dependency on per-bucket or per-volume configuration, eliminating human error as a gap vector in landing zone accounts.

Remediation Strategy

Enable EC2 EBS encryption by default in every region for every member account. Configure S3 bucket default encryption (SSE-S3 or SSE-KMS) on all existing buckets. Apply the SCP at the OU or root level to prevent unencrypted uploads going forward. Use a customer-managed KMS key for EBS encryption where key rotation and audit trail are required.

1.

Enable 'EBS Encryption by Default' in EC2 settings for every region in every member account (automate via AWS Config remediation or a Lambda across all accounts/regions).

2.

Optionally set a customer-managed KMS key as the default EBS encryption key per region to retain key lifecycle control.

3.

For S3: apply a default encryption configuration (SSE-S3 or SSE-KMS) on every bucket, or enforce via S3 Block Public Access combined with the SCP.

4.

Apply the DenyUnencryptedS3Uploads SCP at the root or target OU in AWS Organizations.

5.

Apply the DenyDisableEBSEncryptionDefault SCP at the root to prevent member accounts from reverting the setting.

6.

Use AWS Config rules (ec2-ebs-encryption-by-default, s3-bucket-server-side-encryption-enabled) to detect remaining gaps and trigger auto-remediation.

# Run for each region and each member account
aws ec2 enable-ebs-encryption-by-default \
  --region eu-central-1

# Optionally set a customer-managed KMS key as the default
aws ec2 modify-ebs-default-kms-key-id \
  --kms-key-id alias/my-ebs-default-key \
  --region eu-central-1

Enforcement Logic

Automatedconfig-rule

Two AWS Config managed rules cover this control. The rule ec2-ebs-encryption-by-default flags any account-region combination where the EC2 EBS encryption-by-default setting is disabled. The rule s3-bucket-server-side-encryption-enabled flags any S3 bucket that does not have a default encryption configuration applied. Both rules should be deployed as organization-level Config rules from the management or delegated administrator account so coverage spans all member accounts.

# EBS encryption by default
aws configservice get-compliance-details-by-config-rule \
  --config-rule-name ec2-ebs-encryption-by-default \
  --compliance-types NON_COMPLIANT

# S3 default encryption
aws configservice get-compliance-details-by-config-rule \
  --config-rule-name s3-bucket-server-side-encryption-enabled \
  --compliance-types NON_COMPLIANT
SPEC_METADATA

Complexity
low
Impact
low
Likelihood
medium
Residual Risk
low
Scope
ou
Environment
production, non-production
Resources
EBSS3KMS
Remediation
organization
Auto-Remediate
Available
Category
data-protection
Enforcement
mandatory
Tags
data-protectionencryptionebss3kmslanding-zonescp

Owner
Cloud Security
Type
team
Frequency
quarterly

// EXCEPTION

Accounts in the sandbox OU may be granted a time-limited exception for the S3 SCP to permit unencrypted uploads during proof-of-concept work, subject to security team approval and a maximum duration of e.g. 30 days.

// EXCEPTION

Legacy EBS volumes created before this control was enforced are exempt from retroactive re-encryption if the data owner provides a risk acceptance.

// SYSTEM_NOTE

BucketKeyEnabled should always be set to true on SSE-KMS configurations to reduce KMS API call volume and associated costs at scale. When selecting between SSE-S3 and SSE-KMS, prefer SSE-KMS in regulated workloads where independent key audit trails (CloudTrail KMS events) and key rotation policies are required. The DenyUnencryptedS3Uploads SCP uses StringNotLikeIfExists to avoid breaking bucket-to-bucket replication or pre-signed URL flows that do not pass the header explicitly - test in a non-production OU before promoting to root.