AWS Data Security Controls: KMS Encryption, S3 Encryption, and Key Management

Almost every AWS service encrypts data at rest by calling AWS Key Management Service, so the real architectural decision is never "should I encrypt" — it is which kind of key the service should use. KMS offers three ownership levels, and SAA-C03 scenarios are written so that only one of them satisfies the requirement.

AWS owned keys belong to the service itself and give baseline encryption with nothing to manage or audit. DynamoDB is the clearest example: every DynamoDB table is encrypted at rest by default with an AWS owned key at no extra charge; choosing aws/dynamodb or a customer managed key adds KMS request charges in exchange for visibility or control. AWS managed keys live in your account and appear in CloudTrail, but the control stops there: AWS rotates them every year, you cannot edit their key policies, use them across accounts, disable them or delete them. They carry no monthly key fee, yet calls to them are still billed per request — so moving an SSE-KMS bucket from a customer managed key to aws/s3 does not cut request costs (S3 Bucket Keys do; see the S3 section).

Customer managed keys are the answer whenever the requirement includes control: restrict which roles or services can use the key, separate key administrators from key users, share encrypted data with another account, disable the key immediately, choose a rotation schedule, or audit against a key policy you wrote. How those policies are built is the next section.

Key deletion is deliberately slow. You schedule deletion with a waiting period of 7 to 30 days (30 by default). While the key is pending deletion it cannot be used for any cryptographic operation, which surfaces anything still depending on it. Cancelling the deletion returns the key in the Disabled state — it must be enabled again before data decrypts. Once the waiting period ends, the key material is gone and everything it encrypted is permanently unreadable. When you only need to stop use, disable the key instead; disabling is reversible.

Underneath all of this sits envelope encryption: KMS keys never leave KMS unencrypted and can only encrypt small payloads directly, so services generate a data key, encrypt your data with it locally, and use the KMS key only to encrypt the data key. The encrypted data key is stored alongside the data; decryption means asking KMS to unwrap the data key first. That is why disabling one KMS key can instantly cut off access to terabytes of data — and why CloudTrail records a KMS API call whenever encrypted data is opened.

Default answers (encryption with AWS owned or AWS managed keys) encrypt the data but fail any requirement for editable policies, independent decrypt control, cross-account sharing or a custom rotation schedule; they win only when the requirement is plain encryption at rest with the least cost or effort.

Access to a KMS key starts with its key policy: every KMS key has exactly one, and no principal — not even the account root user — can use the key unless the key policy allows it, either directly or by delegating to IAM. IAM policies, grants and conditions all work inside that frame.

Delegating to IAM. The default key policy contains a statement that allows the account principal (arn:aws:iam::111122223333:root). That statement does not mean only the root user — it lets IAM policies in the account grant access to the key. Without it, IAM policies have no effect on the key. The trade-off: with delegation on, any IAM administrator who can write IAM policies can give themselves the key. When a requirement says only a named role may use a key, remove the broad delegation and name that role directly as a principal in the key policy. Service control policies and permissions boundaries only limit access; they never grant it.

Separating administrators from users. A well-formed key policy has (at least) two statements with no kms:* for either:

Scoping use to a service. The kms:ViaService condition key allows a principal to use the key only when the request comes through a named AWS service on its behalf — for example s3.us-east-1.amazonaws.com. A role with that condition can read SSE-KMS objects through S3 but cannot call kms:Decrypt directly from a script.

Grants are the other delegation mechanism: a grant gives a specific grantee principal a set of operations on one key without editing the key policy. AWS services use grants to work with your key on your behalf (EBS attaching an encrypted volume, for example), and you can create them for temporary access. Grants have no expiry date; access ends when the grant is revoked (by a key administrator) or retired (by the retiring principal). Creating a grant needs kms:CreateGrant.

Cross-account use is always two-sided. The key policy in the owning account must allow the external account (or a specific principal in it), and an IAM policy in the external account must allow its principals to use the key. The external account must reference the key by its key ARN — aliases cannot be used across accounts. Only customer managed keys can be shared this way. A common variation: launching EC2 Auto Scaling instances from an AMI (or snapshots) encrypted with another account's customer managed key. The key policy must allow the external account to use the key, including kms:CreateGrant; then, from the external account, you create a grant for its Auto Scaling service-linked role, because a service-linked role's own policy cannot be edited.

KMS is a multi-tenant managed service: your keys are protected by hardware security modules that AWS operates and shares across customers, with strong logical isolation. For most workloads — including regulated ones — that is enough, and KMS wins on integration: every major AWS service can call it natively, CloudTrail logs every operation, and IAM plus key policies govern access. AWS CloudHSM exists for the narrower case where compliance language demands more than logical isolation: a dedicated, single-tenant hardware security module inside your VPC, where you manage the users and keys on the device and AWS has no access to your key material at all. FIPS validation is not the differentiator: the HSMs behind standard AWS KMS are themselves validated at FIPS 140-3 Security Level 3, so a Level 3 requirement on its own is met by KMS. CloudHSM is for single-tenant or exclusive control of the HSM.

Three nuances keep appearing in questions. First, CloudHSM and KMS are not mutually exclusive: a KMS custom key store backed by CloudHSM keeps the key material of KMS keys in your own cluster, giving you KMS's service integration on top of single-tenant hardware — the answer when a scenario needs both native S3/EBS integration and dedicated HSMs. It supports only symmetric encryption KMS keys, and you use them through the KMS API (KMS operates them in your cluster through its own kmsuser crypto user), so it cannot hold asymmetric signing keys or give applications PKCS #11 access — those needs call for using CloudHSM directly. Second, a KMS external key store (XKS) keeps the key material in a key manager outside AWS, reached through a proxy you run. That changes where the root key lives, not where encryption happens: with server-side encryption the AWS service still handles the plaintext data and the plaintext data key in memory. If AWS must never be able to decrypt the data at all, only client-side encryption with keys held outside AWS meets it — client-side encryption whose data key is wrapped by a KMS key still leaves a key in AWS that can decrypt. Third, CloudHSM shifts operational responsibility to you: durability, user management, and client configuration are your problem, so it loses every "LEAST operational overhead" contest.

On the exam, read the compliance sentence literally. "Auditable, centrally controlled encryption keys" means KMS customer managed keys. "Dedicated hardware," "single-tenant," or "exclusive control of the HSM" means CloudHSM (or a CloudHSM-backed custom key store when native service integration is also required). "FIPS 140 Level 3" alone does not — KMS already meets it. Choosing CloudHSM for an ordinary audit requirement is the classic over-engineering trap.

Encryption at rest protects stored data; TLS protects data moving between clients and your architecture and between tiers inside it. On AWS the certificate machinery is AWS Certificate Manager (ACM): it issues public TLS certificates for domains you validate (DNS validation is the practical choice) and deploys them to the managed endpoints that terminate TLS for you — Elastic Load Balancing, CloudFront and API Gateway. Standard ACM public certificates are free but usable only on those integrated services. Since June 2025 you can also request an exportable public certificate (chosen at request time) and export it with its private key to install on EC2 instances or on-premises servers; public certificates issued before 17 June 2025 cannot be exported. For internal names that public CAs will not certify, use private certificates from AWS Private CA through ACM.

The placement rule: ACM certificates are regional resources. A certificate can only be attached to resources in the Region where it was requested or imported — an ALB in eu-west-1 needs a certificate in eu-west-1. The one carve-out is CloudFront: because CloudFront is a global service, the ACM certificate for a distribution must exist in us-east-1 (N. Virginia), regardless of where your origins or users are. When TLS has two legs — viewer to CloudFront and CloudFront to an ALB origin in another Region — each leg needs its own certificate in its own Region.

Issuing a certificate is half the job; enforcing encryption is the other half, and each service has its own lever:

• ALB: keep the HTTP :80 listener but make its default action a redirect to HTTPS :443.
• CloudFront has two separate settings. The viewer protocol policy governs browser-to-edge traffic: Redirect HTTP to HTTPS sends an HTTP 301 to the HTTPS URL, while HTTPS only rejects HTTP requests outright. The origin protocol policy governs edge-to-origin traffic: HTTPS only always encrypts that leg, while Match viewer uses whatever the viewer used. End-to-end encryption needs both set.
• S3: add a bucket policy statement that explicitly denies every request where aws:SecureTransport is false. An Allow conditioned on aws:SecureTransport being true does not work as enforcement — principals whose IAM policies already grant S3 access are allowed by those policies over plain HTTP. Only an explicit Deny overrides every Allow.
• RDS: enforce TLS server-side with a parameter in the DB parameter group — require_secure_transport for MySQL and MariaDB, rds.force_ssl for PostgreSQL and SQL Server — so unencrypted connections are refused. Clients should also verify the server by trusting the RDS certificate authority bundle (for example sslmode=verify-full on PostgreSQL), which protects against impersonation, not just eavesdropping.

Transit encryption is tested in two shapes: placement (which Region a certificate goes in — regional resource vs the CloudFront us-east-1 rule) and enforcement (a requirement that all access be encrypted is met by the redirect, protocol policy, Deny statement or database parameter, not merely by attaching a certificate).

Compliance frameworks require keys and certificates to be rotated; the decision is which mechanism is automatic, which is opt-in, and which is your job.

How KMS rotation works. Rotating a KMS key generates new key material inside the same key and keeps every previous version. The key ID, ARN and alias never change; new encryption uses the newest material and old ciphertexts still decrypt with the material that created them, so nothing is re-encrypted. Rotation limits how much data any one generation of key material protects; it does not retire old ciphertexts.

So any interval other than one year, or rotation on demand, requires a customer managed key. Manual rotation via aliases is the only case where the key ID changes: applications that reference the alias need no code change, but old data still needs the old key, so the old key must stay enabled. With imported material, keep the material you import: deleting key material that is associated with the key leaves ciphertext it protected unreadable until that same material is imported again.

Certificates. ACM automatically renews the certificates it issued: for DNS-validated public certificates, renewal works only while the certificate is in use and the CNAME validation record stays in DNS — delete it and renewal stalls in the pending-validation renewal status and the certificate stays issued only until it expires. Email-validated certificates need a human to approve renewal, which is the main reason to prefer DNS validation. Private certificates issued from AWS Private CA through ACM are also renewed by ACM. Imported certificates are never renewed by ACM: you obtain a new certificate from your CA and re-import it. ACM helps you notice: it emits approaching-expiration events to Amazon EventBridge (by default starting 45 days before expiry for imported and private certificates and 30 days before for public ones; the window is configurable with PutAccountConfiguration), which can trigger a notification or automation.

A recurring expired-certificate outage points to imported or email-validated certificates; the durable fix is ACM-issued, DNS-validated certificates with the validation record left in place. A yearly-rotation requirement with no application change is plain KMS automatic rotation — re-encrypting data is never part of it.

S3 encrypts every new object by default with SSE-S3, so the exam question is never whether S3 data is encrypted — it is whether the default satisfies the stated requirement. The options differ on exactly two axes that scenarios exploit: who owns the key and what audit and access control you get over it.

The decision rule compresses well. No key requirement → SSE-S3. Audit, key-level access control, or cross-account → SSE-KMS with a customer managed key. KMS request costs at scale → enable Bucket Keys (switching to aws/s3 does not help — AWS managed key requests are billed too). Two layers required → DSSE-KMS. "AWS must never see the plaintext" → client-side encryption — no server-side option can meet that wording, because every SSE variant has S3 performing the encryption on data it momentarily holds in plaintext. Even an XKS-backed KMS key does not change this, because S3 still holds the plaintext data key. To mandate a particular encryption type on uploads, use a bucket policy that denies PutObject unless the request specifies the required server-side encryption header.

What enabling Bucket Keys changes. Bucket Keys apply only to objects written after you enable them; existing objects keep their per-object data keys until they are rewritten — for example with an S3 Batch Operations Copy job in place. They also change the KMS encryption context for new objects from the object ARN to the bucket ARN, so a key policy condition or monitoring rule that matches object-ARN encryption context stops matching and must be updated to the bucket ARN.

One more SSE-KMS behavior earns its own trap: because decryption requires KMS permissions, a principal can have full S3 permissions and still get access-denied on a KMS-encrypted object. Exam stems describe exactly that symptom — "the user has s3:GetObject but receives an error on some objects" — and the answer is missing kms:Decrypt on the key. Expect the S3 options to appear side by side as answer choices, differing only in key ownership; match the requirement's strongest word (audit, control, never-see-plaintext) to the table row that provides it.

Block storage and database encryption share one governing rule: encryption is set when the resource is created, and cannot be toggled on an existing resource in place. Everything the exam asks about EBS and RDS encryption is a consequence of that rule.

EBS volumes encrypt with a KMS key (the aws/ebs AWS managed key by default, or a customer managed key you specify), covering the volume, its snapshots, and data moving between the volume and the instance. Enable EBS encryption by default at the account/Region level and every new volume is encrypted without anyone remembering to tick the box — the standard answer to "ensure all future volumes are encrypted with LEAST operational overhead." Encryption is sticky in the safe direction: snapshots of an encrypted volume are encrypted, and volumes restored from encrypted snapshots are encrypted; you cannot strip encryption off. For an existing unencrypted volume, you cannot switch encryption on in place; you create a new, encrypted volume and swap it in. Either snapshot the volume and create a new volume from that snapshot with encryption enabled (choosing your KMS key) — EBS can create an encrypted volume directly from an unencrypted snapshot — or copy the snapshot with encryption enabled first when you want an encrypted snapshot to keep, share or launch from. The copy step is also how you re-encrypt under a different key, and how you prepare encrypted snapshots for another account — which requires a customer managed key whose key policy allows that account, because snapshots encrypted with the AWS managed aws/ebs key cannot be shared.

RDS follows the same shape. Enable encryption at instance creation and it covers the instance's storage, automated backups, snapshots, and read replicas. You cannot encrypt a running unencrypted instance, and you cannot restore an unencrypted snapshot directly into an encrypted instance. Nor can you create an encrypted read replica of an unencrypted instance — replicas inherit the source's encryption state. The migration path: take a snapshot → copy the snapshot with encryption enabled → restore a new instance from the encrypted copy → repoint the application. For a large, busy database where the cutover window must be short, restore the encrypted copy and then keep it in sync with AWS DMS change data capture (CDC) from the original until you switch over. RDS also offers a managed alternative: a blue/green deployment can create its green environment encrypted with a KMS key, which encrypts an unencrypted DB instance (or changes the key of an encrypted one) and then switches over with little downtime. Replicas add a regional wrinkle: KMS keys are regional, so a cross-Region encrypted read replica or snapshot copy is encrypted with a key in the destination Region, which you specify during the copy.

Exam scenarios here are procedural: "an unencrypted production database must be encrypted to meet a new compliance requirement — what should the solutions architect do?" For RDS the chain is snapshot → encrypted copy → restore → cut over (with DMS CDC, or an encrypted blue/green deployment, when downtime must be minimal); for EBS it is snapshot → encrypted volume (directly or via an encrypted copy) → swap. Distractors offer the impossible shortcuts: "modify the instance to enable encryption" or "enable encryption on the existing volume." If an option flips encryption on in place, eliminate it.

Encryption protects data from whoever lacks the key; access controls decide who legitimately gets to it, and Task 1.3 expects you to layer them. The first layer is the policy pair. IAM policies are identity-based: attached to users and roles, they answer "what can this principal do, across all services?" S3 bucket policies are resource-based: attached to the bucket, they answer "who may touch this bucket, and under what conditions?" Within one account, access is granted if either an IAM policy or the bucket policy allows it and nothing explicitly denies it — an explicit deny anywhere always wins. Bucket policies earn their place in three situations IAM alone handles badly: cross-account access (grant another account's principals access without creating roles for each), bucket-wide guardrails (deny unencrypted uploads, deny non-TLS transport), and condition-based restriction (allow access only from specific VPC endpoints or IP ranges).

The second layer is the blunt instrument: S3 Block Public Access. It can be set at four levels — organization (an AWS Organizations S3 policy, since November 2025, which applies all four settings together to member accounts), account, bucket and access point — and S3 enforces the most restrictive combination. A bucket-level setting can add protection but can never loosen an account- or organization-level block. Block Public Access overrides any bucket policy or ACL that would make data public; it is the preventive answer to "no bucket may ever be made public," stronger than detective alerts after the fact. Across many accounts, the organization-level policy is the one control nobody in a member account can switch off.

Public content without public buckets. When a site must serve objects to the internet while Block Public Access stays on, put CloudFront with origin access control (OAC) in front of a private bucket. The bucket policy allows the CloudFront service principal (cloudfront.amazonaws.com) to read objects only when AWS:SourceArn equals your distribution's ARN. That policy is not public, so Block Public Access does not block it, and the bucket itself is never reachable directly.

The third layer is the network path. By default, traffic from a VPC to S3 resolves to public service endpoints. A VPC gateway endpoint for S3 (or DynamoDB) keeps that traffic on the AWS network with no internet gateway or NAT in the path, at no charge; interface endpoints (AWS PrivateLink) do the same for most other services via an ENI in your subnet. The governance move the exam loves: combine the endpoint with a bucket policy that denies access unless the request arrives via your endpoint (condition on aws:sourceVpce) — now the data has exactly one door, and it is private. "Data must not traverse the public internet" is a VPC endpoint requirement, not an encryption requirement.

The fourth layer is knowing what you hold and who is touching it. Three services answer three different questions:

Governance answers are usually layered: a preventive control (Block Public Access, Deny conditions, endpoint-only bucket policies) combined with the private path or discovery tool the requirement names. A detective tool where prevention was demanded, or a single control where the scenario lists several requirements, is the usual distractor.

Compliance requirements about data usually arrive as sentences about time: keep it for seven years, make it undeletable, be able to recover it, keep a copy in another Region or account. Each phrase maps to a specific control.

Immutability is S3 Object Lock: write-once-read-many (WORM) protection for object versions, on a bucket with versioning enabled (a prerequisite). Object Lock can be turned on when a bucket is created or later on an existing versioned bucket. A bucket's default retention applies only to object versions written after it is set; existing objects need retention applied explicitly — at scale, with an S3 Batch Operations Object Lock retention job. The modes are the decision point:

Recovery from mistakes is versioning: overwrites and deletes become recoverable prior versions (a simple delete only adds a delete marker), with MFA Delete as an extra gate on permanent deletion.

Cost-aligned retention is lifecycle configuration. Transition rules move objects to cheaper storage classes as they age; expiration rules end them. In a versioned bucket the actions differ in a way that is easy to get wrong:

• Expiration on current versions does not delete data — it adds a delete marker, and the old data becomes a noncurrent version that keeps costing money.
• NoncurrentVersionExpiration permanently deletes noncurrent versions a set number of days after they become noncurrent; it is what actually removes the data.
• ExpiredObjectDeleteMarker only cleans up delete markers that have no versions left behind them.

For the archive tier, match access needs: S3 Glacier Instant Retrieval serves objects in milliseconds and costs less to store than Standard-IA for data read only a few times a year (Standard-IA and One Zone-IA suit roughly monthly access); Glacier Flexible Retrieval and Glacier Deep Archive are cheaper still but require a restore before an object can be read. Storage-class pricing is covered in depth in cost-optimized storage. A seven-year retention requirement is typically Object Lock for immutability plus a lifecycle rule for cost.

Replication is availability, not point-in-time protection. S3 Replication (Cross-Region or Same-Region; versioning required on both buckets) copies objects to another bucket, optionally in another account. Three details decide many designs:

• A replication rule copies only objects written after it exists; existing objects need S3 Batch Replication.
• SSE-KMS objects are skipped unless the rule opts in to replicating them and names a destination KMS key; the replication role then needs kms:Decrypt on the source key and kms:Encrypt on the destination key.
• Replication propagates changes faithfully, so it protects against losing a Region, not against a bad write or deletion upstream.

Backups give point-in-time recovery. AWS Backup centralises it across services with a backup plan: a schedule, a retention (lifecycle) period, optional copy actions to a vault in another Region or another account, and resource assignment by tag so new resources are protected automatically. Amazon Data Lifecycle Manager is narrower — it automates EBS snapshots and EBS-backed AMIs only. AWS Backup Vault Lock extends WORM to the backups: in governance mode users with the right IAM permissions can still remove the lock; in compliance mode, once its grace period ends, no one — not an administrator, not the root user — can delete recovery points early or change the lock. Where the threat is account compromise, a copy in the same account (even in another Region) can be deleted by the attacker; a cross-account copy, ideally into a locked vault, survives.

Stems distinguish these by intent: "recover from accidental deletion or corruption" needs versioning or backups; "retain in a second Region" needs replication or cross-Region backup copies; "survive a compromised account" needs cross-account copies; "prevent anyone from tampering with retained data" needs Object Lock or Vault Lock in compliance mode.

Scenario 1 — auditable keys and a partner account. A financial-services company stores reports in S3. Regulators require that the security team control exactly which principals can decrypt the data, that every decryption be auditable, and that a partner AWS account be able to read one prefix. Work the requirements against the key-type ladder. SSE-S3 fails immediately: no key policy, no key-usage audit trail. SSE-KMS with the AWS managed aws/s3 key gets CloudTrail logging of key use but fails twice — its key policy cannot be edited, and AWS managed keys cannot be used cross-account. CloudHSM is over-engineering: nothing in the requirement says single-tenant hardware, and it would add operational burden without adding a required capability. The answer is SSE-KMS with a customer managed key: the security team authors the key policy (control), CloudTrail records every encrypt/decrypt (audit), and a key policy statement plus the partner's IAM policies grant cross-account decryption — paired with a bucket policy granting the partner account access to the prefix. This elimination pattern — each stronger requirement killing one more option — is exactly how the real items are constructed.

Scenario 2 — the unencrypted production database. An audit finds a production RDS instance unencrypted; the new policy requires encryption at rest with a customer managed key, with minimal disruption. There is no in-place toggle, so any option that "modifies the instance to enable encryption" is wrong by mechanism. The path: snapshot the instance → copy the snapshot with encryption enabled, selecting the customer managed key → restore a new instance from the encrypted copy → cut the application over. If the database is large and busy, keep the new instance in sync with AWS DMS change data capture so the cutover takes minutes rather than the length of the restore. An RDS blue/green deployment with an encrypted green environment is the managed way to reach the same short switchover. Two shortcuts fail by mechanism: an encrypted read replica of the unencrypted instance cannot be created, and an unencrypted RDS snapshot cannot be restored directly into an encrypted instance. EBS differs here: an encrypted volume can be created straight from an unencrypted snapshot.

Scenario 3 — seven years, untouchable. A healthcare provider must retain records for seven years, guarantee no employee — including administrators — can delete or alter them, and minimize storage cost. "No one including administrators" selects Object Lock in compliance mode (governance mode fails: privileged users can override it), which requires versioning. Cost drives a lifecycle rule transitioning records to a Glacier storage class. If the stem adds "survive a Regional disaster," layer Cross-Region Replication to a second locked bucket. Three requirements, three controls, one answer option that contains all three — the option with only two is the trap.