AWS KMS:
how one invoice stays encrypted for seven years

Amazon S3 applies SSE-S3, server-side encryption with keys S3 manages itself, to every new object written since 5 January 2023. The cipher is AES-256, it costs nothing, and default encryption can no longer be removed from any bucket. Objects stored before that date were left as they were.

DynamoDB encrypts every table at rest and has no switch to turn that off. EBS and RDS are the opt-in pair. EBS has an account setting, encryption by default, that applies to one Region at a time. RDS takes the decision when a database is created, and keeps it.

Every KMS key does the same work: AES-256-GCM, run inside the same hardware. What differs is who owns the key. An AWS owned key belongs to the service and is shared across many accounts. It is free, you cannot see it, and it writes nothing to your CloudTrail.

An AWS managed key, such as aws/s3 or aws/ebs, sits in your account, where you can see and audit it. You cannot edit its key policy, it rotates every year, and it has no monthly fee. AWS stopped creating this type for new services in 2021.

A customer managed key costs $1 a month and is yours to configure: its policy, its rotation, its deletion. Exam questions and older documentation call it a CMK, short for customer master key, a name AWS dropped in 2021.

Under SSE-S3, a PutObject makes no request to KMS at all. S3 manages those keys internally, so the upload leaves no KMS event in CloudTrail, and no key permission exists that could refuse a reader. The only permission between a role and the bytes is s3:GetObject.

SSE-KMS adds a second, independent check. To return an object, S3 calls kms:Decrypt as the reader, and the key’s policy can refuse that call even when the bucket allowed the read. That second check is what the dollar a month in the next step pays for.

At 16:00 on 5 November 2026, the role key-admin calls CreateKey: a symmetric key (SYMMETRIC_DEFAULT), multi-Region, with origin AWS_KMS, meaning KMS generates the key material itself. Four seconds later CreateAlias names it alias/invoices-2026. These are calls #1 and #2.

The key costs $1 a month, prorated by the hour, however much data it encrypts. Requests are billed separately: the first 20,000 a month are free across all Regions, then every 10,000 cost $0.03. This chapter adds 2 calls, and Σ KMS calls is now 2.

The KMS Encrypt operation accepts at most 4,096 bytes of plaintext with a symmetric key. The invoice is 188,416 bytes, 46 times that. A KMS key’s material never leaves KMS’s hardware security modules in plaintext, so the key cannot travel to the file either.

Those HSMs are FIPS 140-3 Level 3 validated, under NIST certificate #4884 from 18 November 2024. The way out of the limit is to ask KMS for a new key instead of sending it the file, and to do the bulk encryption inside S3.

At 09:00:00 on 6 November, invoice-app uploads the PDF with PutObject. S3 calls GenerateDataKey on alias/invoices-2026 with KeySpec AES_256, which is call #3. KMS returns a 32-byte data key twice: once in plaintext, and once encrypted under invoices-2026.

S3 encrypts the PDF with AES-256-GCM using the plaintext copy, removes that copy from memory, and stores the encrypted copy alongside the object. AWS calls this envelope encryption: the encrypted data key is written on the outside of the envelope, where anyone can read it and only a kms:Decrypt call can use it.

The stored object is the ciphertext plus metadata. HeadObject returns three encryption fields: ServerSideEncryption: aws:kms, SSEKMSKeyId with the key’s ARN, and BucketKeyEnabled: false. The encrypted data key is stored with the object too, but S3 never returns it.

That encrypted data key holds more than 32 encrypted bytes. KMS writes a reference to the key that encrypted it into the ciphertext, which is why Decrypt with a symmetric key needs no KeyId parameter: KMS reads the reference and finds invoices-2026 by itself.

Every KMS call S3 makes for this object carries an encryption context: the key aws:s3:arn paired with the object’s ARN. KMS binds the pair to the ciphertext as additional authenticated data, input that is checked but not encrypted, so Decrypt must present the same pair.

KMS calls are CloudTrail management events, recorded by default, and the encryption context appears in each one in plain text. Policies can test it with kms:EncryptionContext:aws:s3:arn, and an auditor can see exactly which object was read. The price of that visibility is a rule: nothing secret goes into an encryption context.

At 09:00:02 the mailer reads the invoice back with GetObject to attach it to the customer’s email. S3 sends the stored encrypted data key and the encryption context to Decrypt, call #4, gets the plaintext data key back, and decrypts the PDF before returning it.

Without S3 Bucket Keys, every read of an SSE-KMS object is a KMS request on the bill. One million reads cost $3.00 in Decrypt calls (1,000,000 ÷ 10,000 × $0.03), before the free tier. Σ KMS calls is now 4.

Every KMS key carries exactly one key policy, a resource policy attached to the key itself. No principal can use invoices-2026 unless that policy allows it, either by naming the principal or by handing the decision to IAM. S3 buckets work differently: in the bucket’s own account, an IAM policy alone can open a bucket, but never a key.

The handover is one statement whose principal is the account itself, arn:aws:iam::111122223333:root. The console names it “Enable IAM User Permissions”. With it, IAM policies in the account count. Without it, a role with AdministratorAccess is refused, and a policy that names nobody able to manage the key can only be repaired by AWS Support.

At 14:10 dev-readonly asks for INV-0042.pdf. The role has the AWS managed ReadOnlyAccess policy, which allows s3:Get* on every bucket and, for KMS, only kms:Describe*, kms:Get* and kms:List*. S3 checks s3:GetObject first, and it passes.

Then S3 calls Decrypt as dev-readonly, and KMS finds nothing in the key policy or the role that allows it. KMS returns AccessDeniedException, S3 returns a 403 to the developer, and CloudTrail records the refused call as #5. Σ moves from 4 to 5.

The console’s default key policy splits people into two statements. Key administrators get the management actions, such as kms:Create*, kms:Put*, kms:Disable* and kms:ScheduleKeyDeletion, and no kms:Decrypt. Key users get Encrypt, Decrypt, ReEncrypt*, GenerateDataKey* and DescribeKey.

The split has one weak point. kms:PutKeyPolicy replaces the whole policy, so an administrator who holds it can add a statement giving their own role Decrypt. That makes it the permission to alert on. Every PutKeyPolicy is a CloudTrail event, and chapter 04 adds one.

invoice-app’s statement in the key policy carries two conditions. kms:ViaService must equal s3.us-east-1.amazonaws.com, so the request has to come from S3 acting for the role. kms:EncryptionContext:aws:s3:arn must match arn:aws:s3:::ledger-invoices/*, so the object has to be in this bucket.

Suppose an attacker copies the app’s credentials and one encrypted data key. A direct Decrypt call from their laptop matches neither condition and is refused. The same credentials can still read invoices through S3, where the bucket’s own policy and logs apply.

A grant gives one principal permission to use one key for a listed set of operations, without editing the key policy. AWS services create grants as they work: EBS when it attaches an encrypted volume, RDS when it starts an encrypted instance. Chapter 03 shows both.

One key holds up to 50,000 grants, the service-made ones included. They appear in ListGrants, never in GetKeyPolicy, and they end with RetireGrant or RevokeGrant. So the full answer to “who can decrypt invoices-2026?” comes from three places: the key policy, the IAM policies in the account, and the grant list.

The PDF renderer writes a temporary copy of INV-0042 to an encrypted EBS volume. EBS called KMS when the volume was created, with GenerateDataKeyWithoutPlaintext, which returns only the encrypted copy of a new data key. It called again at attach time: CreateGrant for the host, then Decrypt to recover the volume’s data key.

From then on the plaintext volume key stays in host memory, outside the instance, and every block the renderer writes is encrypted there. The temporary file costs no KMS calls. Encryption by default is an account setting in each Region, off until you turn it on.

ledger-db, the RDS Postgres database that holds INV-0042’s row, was created encrypted under a second key, alias/ledger-db. Like EBS, RDS calls KMS when the instance starts, not on each insert, so the invoice’s row added 0 calls.

The key choice is final. RDS can’t encrypt an existing unencrypted instance, can’t move an instance to another key, and can’t make an encrypted read replica of an unencrypted instance. The one route is a snapshot, a copy of that snapshot under the new key, and a restore, which builds a new instance with a new endpoint.

The invoice index lives in a DynamoDB table, which is encrypted at rest with no way to turn that off. It offers three keys: an AWS owned key (the default, free and invisible), the AWS managed key aws/dynamodb, or a customer managed key.

An UpdateTable call switches between them while the table keeps serving reads and writes. That is the opposite of RDS in the previous step. An exam question asking to “change the key with no downtime” has a one-call answer for DynamoDB and a migration for RDS.

The app’s database password sits in Secrets Manager, envelope-encrypted under a KMS key like the invoice. Each GetSecretValue makes Secrets Manager call Decrypt, so an app that fetches the secret on every request also calls KMS on every request. Client-side caching cuts that to one fetch per cache period.

A secret costs $0.40 a month plus $0.05 per 10,000 API calls. Parameter Store SecureString parameters on the standard tier are free up to 4 KB, and they encrypt through KMS too. In both, the key decides sharing: a secret under aws/secretsmanager can’t be read from another account, because nobody can add that account to an AWS managed key’s policy.

With an S3 Bucket Key, S3 asks KMS for a short-lived bucket-level key and derives each object’s data key from it, instead of calling KMS for every object. AWS puts the saving at up to 99% of KMS requests. At 2,000,000 reads a day, that is 2,000,000 Decrypt calls ($6.00) against about 20,000 ($0.06).

The cost is visibility. The encryption context becomes the bucket ARN, so every KMS event names ledger-invoices instead of the object, and key-policy conditions written on object ARNs stop matching. The bucket keeps Bucket Keys off to keep a per-object trail, so Σ still holds at 5.

An AWS managed key’s policy is written by the service that created it, and nobody can edit it. Cross-account access needs exactly that edit: a statement naming the other account. So aws/s3, aws/ebs, aws/rds and aws/secretsmanager can never be used from outside the account that holds them.

The exam’s favourite case is an EBS snapshot. A snapshot encrypted with aws/ebs can’t be shared at all. The fix is a copy in the same Region under a customer managed key: share that key with the other account, then share the copy. This is why invoices-2026 was customer managed from its first day.

On 2027-03-31 at 10:12 the auditor role in account 444455556666 asks S3 for INV-0042. The bucket policy names that account, so S3’s own check passes. S3 then calls Decrypt as the auditor’s role, call #6, and KMS refuses it: the key policy has no statement for 444455556666.

KMS logs a refused cross-account request only in the caller’s account. The auditor’s CloudTrail holds call #6, and ledger-prod’s trail has no record that anyone outside the account tried. To see refused attempts on its key, the key owner has to ask the other account for its logs.

At 10:30 key-admin calls PutKeyPolicy, call #7. The new statement names arn:aws:iam::444455556666:root, allows kms:Decrypt, and keeps the auditor to S3 with kms:ViaService. Naming the account’s root hands the final decision to that account’s own IAM policies.

So the auditor’s account must also give its role kms:Decrypt on the key, and it has to name the full key ARN. An alias is looked up in the caller’s own account, where alias/invoices-2026 doesn’t exist. At 10:41 the read succeeds, call #8, and this time it is logged in both accounts.

At 09:00:41 on 2026-11-06, the day INV-0042 was written, S3 replication copied it to ledger-invoices-dr in us-west-2. Replication skips SSE-KMS objects unless the rule opts in with SseKmsEncryptedObjects and names a destination key in ReplicaKmsKeyID, which must be a key in the destination Region.

The s3-replication role needs kms:Decrypt on the source key and kms:Encrypt on the destination key. It calls Decrypt in us-east-1, call #9, and Encrypt in us-west-2, call #10. S3 doesn’t test the key when the rule is saved: a rule naming the wrong key still returns 200 OK, and every replication then fails.

invoices-2026 is a multi-Region key. On 2026-11-05 key-admin called ReplicateKey, call #11, which created a replica in us-west-2 with the same key ID and the same key material. The replica is still a separate key, with its own key policy, grants and aliases, billed as a second key.

S3 replication didn’t need the shared material, because S3 decrypts and re-encrypts every replica anyway. A multi-Region key matters when ciphertext crosses Regions without being re-encrypted, such as items encrypted client-side and copied by a DynamoDB global table. The replica Region then decrypts locally, without calling us-east-1.

That makes 6 calls in this chapter, and Σ stands at 11.

Automatic key rotation is one API call. On 2026-11-05, minutes after creating the key, key-admin called EnableKeyRotation with RotationPeriodInDays set to 365, call #12. Every 365 days KMS now generates new key material for invoices-2026 and makes it the version used for new encryptions.

Since 2024-04-12 the period can be anything from 90 to 2,560 days, with 365 as the default, and RotateKeyOnDemand rotates at once. AWS managed keys rotate every year, a schedule AWS shortened from about 1,095 days in May 2022.

Automatic rotation isn’t available for asymmetric keys, HMAC keys or keys in custom key stores. Keys with imported key material can’t rotate automatically either; since 2025-06-06 they can rotate on demand.

On 2027-11-05 KMS rotates invoices-2026 by itself, call #13. CloudTrail records a RotateKey event with eventType AwsServiceEvent and rotationType AUTOMATIC: there is no caller, because nobody asked. New key material becomes the current version, used for every encryption from then on.

Nothing else about the key changes. The key ID, ARN, alias, key policy and grants stay the same, so no application or policy needs an update. The 2026 key material stays inside KMS, and so will each later version, until the key itself is deleted. Not one object is re-encrypted.

On 2028-02-14 the customer downloads INV-0042 again from the billing portal. S3 sends KMS the same encrypted data key it stored in 2026, call #14. That ciphertext records which version of the key material encrypted it, and KMS decrypts it with that version: the 2026 one.

Neither S3 nor invoice-app knows a rotation happened, and neither has to. A caller never picks a key version; KMS reads it from the ciphertext. Rows #12 to #14 are this chapter’s 3 calls, and they bring Σ to 14.

Rotation limits how much data one version of the key material encrypts. It does nothing for two other risks. A plaintext data key that leaked decrypts its one object forever, whatever happens to the KMS key. Leaked credentials with kms:Decrypt decrypt data under every version, old and new.

After a suspected compromise, create a new key and re-encrypt the data under it: ReEncrypt for KMS ciphertext, an S3 copy in place for objects. Then point the alias at the new key with UpdateAlias and disable the old one.

Rotation has a small price. The first and second rotations each add $1 a month to the key, and later rotations add nothing, so a rotating key tops out at $3 a month.

On 2029-06-01 the compliance role calls DescribeKey on invoices-2026, call #15. The answer carries the four fields an auditor asks about: Origin AWS_KMS, KeyManager CUSTOMER, KeyState Enabled and MultiRegionKeyType PRIMARY. Origin says where the key material was made and where it lives.

Origin takes four values. AWS_KMS means KMS generated the material in its own HSMs; EXTERNAL means you imported it; AWS_CLOUDHSM means it lives in a CloudHSM cluster you own; EXTERNAL_KEY_STORE means it never enters AWS. CreateKey sets the value for good, so a different origin means a new key and re-encrypted data. Σ goes from 14 to 15.

A key with origin EXTERNAL starts empty. CreateKey makes its key ID and policy, GetParametersForImport returns a wrapping public key and an import token, and you encrypt your own 256-bit key material with that public key on your side. ImportKeyMaterial hands the wrapped material to KMS, which unwraps it inside its HSMs. This is imported key material, often called BYOK.

Two controls come with it. You can set an expiry date, after which KMS deletes the material, and DeleteImportedKeyMaterial removes it at once, with no waiting period. KMS can’t regenerate imported material. If its copy is deleted or expires and you no longer have yours, everything encrypted under the key is unreadable for good.

A key with origin AWS_CLOUDHSM lives in a custom key store. KMS keeps the key ID, the key policy and the API, but the key material is generated and used inside an AWS CloudHSM cluster your team owns. The cluster is single-tenant, and only users you create can log in to it. AWS can’t recover its keys if you lose those credentials.

KMS connects a key store only to a cluster with at least two active HSMs in different Availability Zones. At the us-east-1 list price for hsm2m.medium in November 2026, $1.60 an hour, two HSMs cost 2 × 730 × $1.60 = $2,336 a month before they hold a single key. S3 and every other integration work unchanged, because callers still call KMS.

An external key store, launched in December 2022, keeps key material in a key manager you run outside AWS. KMS sends every encrypt and decrypt request for those keys to an XKS proxy, a service you also run, which passes it to your key manager. Data is encrypted twice: once with KMS’s own key material, once with your external key.

That puts a switch in your hands. Turn off the proxy and every ciphertext under those keys becomes unreadable, to AWS as much as to anyone, and every S3 GetObject for such an object fails. The same switch makes availability and latency your problem: each KMS call now waits on a network path and a service that AWS doesn’t operate.

CloudHSM also works without KMS. Applications talk to the cluster directly through PKCS#11, JCE or OpenSSL, so no IAM policy decides who uses a key, no KMS CloudTrail event records the use, and no S3 or EBS integration exists. That fits TLS offload for web servers, Oracle Transparent Data Encryption, and signing with algorithms KMS doesn’t offer.

Older exam questions used “FIPS 140-2 Level 3” as the cue for CloudHSM. KMS’s own HSMs have been FIPS 140-3 Level 3 validated since November 2024 (NIST certificate #4884), so that cue now fits every option. The cues that still point to CloudHSM are single tenancy, exclusive control of the HSMs, and standard crypto APIs.

On 2034-01-03, INV-0042 exists in more places than anyone listed: the object in ledger-invoices, any noncurrent versions S3 versioning kept, and the replica in ledger-invoices-dr in us-west-2. Every one is ciphertext under invoices-2026 or its replica. Deleting the key makes all of them unreadable at once, which is called crypto-shredding.

The method reaches only ciphertext under that key. The auditor downloaded INV-0042 in 2027, and their copy is plaintext on their own machine, so no KMS deletion touches it. That is why the company keeps one key per year of invoices: when a retention period ends, deleting one key removes a whole year without listing a single object.

DisableKey takes effect at once and is reversible: the key refuses every request until EnableKey, and it still costs $1 a month. ScheduleKeyDeletion starts a waiting period of 7 to 30 days, 30 by default. During it the key is in pending deletion, refuses every request and costs nothing. CancelKeyDeletion returns it, disabled.

A multi-Region primary can’t be deleted while a replica exists. At 09:00 key-admin schedules the us-west-2 replica with a 7-day wait (call #16), then the primary with 30 days (call #17). The primary goes to PendingReplicaDeletion, and its 30 days start only when the replica is deleted, on 2034-01-10.

At 02:00 on 2034-01-09 a forgotten tax-export job asks S3 for INV-0042. S3 calls Decrypt as the job’s role (call #18), and KMS answers KMSInvalidStateException, with an error message saying the key is pending deletion. Like every refused call, it is written to CloudTrail.

AWS documents a CloudWatch metric filter for exactly this: match KMS events whose error message ends in “is pending deletion.” and alarm on the first one. The alarm reaches the security team the same morning. They confirm the job is retired and let the countdown run. Had the job still mattered, CancelKeyDeletion would have kept every 2026 invoice readable.

On 2034-01-10 KMS deletes the replica (call #19), and on 2034-02-09 it deletes the primary (call #20), with every version of its key material. Both are CloudTrail events with eventType AwsServiceEvent and no principal behind them. Nothing can restore the key afterwards, AWS Support included.

INV-0042 is still in ledger-invoices: 188,416 bytes of ciphertext and the encrypted data key beside them, billed as storage until a lifecycle rule removes them. Every request for the object now fails, because the key its envelope names no longer exists. Σ ends at 20 KMS calls.