Overview
Configure EBS encryption-by-default for a region so new EBS volumes and snapshot copies are automatically encrypted with the chosen KMS key. The process evaluates your current region setting, enumerates and vets candidate customer-managed keys (CMKs), verifies and prepares any required key policy or grant changes, collects explicit user selection and consent, applies authorized changes, enables the EBS default encryption setting using the selected key (or the AWS-managed alias), and validates the result by creating and inspecting test volumes and snapshots. Every step produces machine-readable artifacts and audit metadata (API request IDs, timestamps, raw responses) and records approver identities, scheduling and rollback preferences. Note: enabling encryption-by-default is region-scoped and affects only newly created volumes/snapshots.
Execution Details
Phase: Assessment
Purpose: discover current state and build a vetted list of keys you can use as the region default.
Get EBS encryption-by-default status
- Read and record the current region-level setting (enabled/disabled), the default key if present (ARN/ID/alias), whether the feature is available in the region, and any service-returned caveats (e.g., existing volumes unaffected).
- Produce a machine-readable status artifact containing state, default key details, API metadata, and an advisory note.
List candidate KMS keys
- Enumerate customer-managed KMS keys in the region (handling pagination) and collect key metadata: KeyId/ARN, aliases, state, spec/usage, creation date, raw key policy, rotation status, and tags.
- Filter out unsuitable keys (asymmetric/HMAC, disabled/pending deletion, cross-region/account, missing policy visibility) and record exclusion reasons.
- Produce a candidate keys artifact listing suitable keys and excluded keys with reasons and summary counts.
Check KMS key policies and grants
- For each candidate CMK, fetch full key policy and current grants; capture raw policy JSON and grant listings.
- Evaluate whether policy/grants permit EBS usage (required KMS actions and appropriate principals/conditions such as kms:ViaService and aws:SourceAccount). Capture policy excerpts that pass or fail and detect any cross-account implications.
- Prepare minimal example policy statements and/or grant JSON that would allow EBS/EC2 to use the key (scoped by service and account conditions) to minimize blast radius.
- Flag keys that have policy-change risk (owned/managed elsewhere, rotation disabled, cross-account) and produce a per-key evaluation artifact containing metadata, policy excerpts, grant info, recommended changes, risk flags, and audit fields.
User selection and approval
- Present the encryption status, candidate CMKs, per-key evaluations, and recommended policy/grant changes; guide the user through selection options (a specific CMK or alias/aws/ebs).
- Collect explicit, machine-readable user choices: selected KeyId/ARN, consent to modify key policy or create grants (with any constraints), owner approvals for cross-account/managed keys, scheduling preferences (immediate or time window), rollback/error-handling preferences, and whether to create test volumes.
- Produce a signed approval artifact capturing the selection, consents, scheduling, rollback policy, approver identity and timestamp.
Phase: Configuration
Purpose: apply authorized key policy/grant changes and enable encryption-by-default using the approved key.
Prepare and apply KMS policy changes or grants
- Load the approval artifact and confirm consent. If consent is absent, prepare changes but mark them as pending.
- Fetch and record pre-change key policy and grants for audit.
- Construct minimal, scoped policy statements or create grants that allow kms:Encrypt, kms:GenerateDataKey*, kms:DescribeKey and kms:CreateGrant for EC2/EBS principals, applying kms:ViaService and aws:SourceAccount/SourceArn conditions as requested.
- Apply authorized policy edits or create grants; capture before/after policy JSON or GrantId and record API metadata. If not applied, store prepared JSON snippets and an "apply-instructions" artifact for the key owner.
- Verify post-change effective policy/grants, record diffs, and produce a policy-change artifact that documents applied or pending changes, authorizer identity, and follow-up steps.
Enable EBS encryption-by-default
- Verify prerequisites (policy/grant changes applied or authorized) and honor the user-specified timing (immediate or scheduled window).
- Set the region’s EBS encryption-by-default to use the selected CMK (or AWS-managed alias), recording pre-change and post-change service responses and full API metadata.
- On success, optionally create test volumes with default settings to confirm they are encrypted with the chosen key; capture volume IDs and encryption metadata.
- If errors occur (permission denied, invalid key, region mismatch), capture detailed error payloads and follow the user’s rollback policy (attempt automatic rollback if requested and permitted).
- Produce an enablement-result artifact summarizing prior and new states, configured key ARN, API metadata, test volume IDs (if any), and any errors or pending prerequisites.
Phase: Validation
Purpose: confirm the configured default key is used for new volumes/snapshots and that KMS permissions function as intended.
- Verify default encryption and test volumes
- Re-read the region setting to confirm it reports enabled and matches the chosen KeyId/ARN; capture API metadata.
- Inspect each test volume (or create a new test volume if none were created) to confirm Encrypted==true, KmsKeyId corresponds to the selected CMK (or its alias), and volume state is healthy; gather full volume metadata and API request details.
- Create and inspect a snapshot of a test volume to ensure it is encrypted and associated with the same KMS key.
- Verify that any applied policy/grant changes allow EBS/EC2 to perform necessary KMS operations by confirming the above operations succeeded without KMS access errors.
- Record any mismatches, KMS permission errors, region/key inconsistencies or other abnormalities and provide remediation guidance.
- Produce a consolidated verification report (machine-readable) that contains final encryption-by-default state, configured key ARN, test volume/snapshot evidence, API metadata, pass/fail status, remediation steps, and links to approval and policy-change artifacts; optionally deliver the report to approvers and record delivery metadata.
Artifacts, Auditing, and Risk Controls
- Every phase produces machine-readable artifacts: status, candidate keys, per-key evaluations, user approvals, prepared policy/grant JSON, policy-change records, enablement results, and verification reports.
- All artifacts include API request IDs, timestamps, raw responses where relevant, approver identities and timestamps, and explicit risk flags (cross-account, policy-change-risk, excluded keys with reasons).
- The process respects explicit user constraints (scope of policy edits, scheduling, rollback behavior) and will not apply key policy changes without recorded consent; when consent is not given, prepared changes are stored with clear apply instructions for key owners.
This plan guides you from discovery through controlled configuration and verification to enable EBS encryption-by-default with strong auditability, minimal privilege policy changes, and explicit user control over timing and policy modifications.