AWS KMS and Encryption for Developers: Keys, Envelopes, and Certificates

Encryption at rest protects data where it is stored; encryption in transit protects data moving over the network. The exam expects you to name the mechanism for each and to notice when a scenario requires both.

At rest means the bytes on disk are ciphertext: S3 objects, EBS volumes and snapshots, DynamoDB tables, RDS databases, SQS messages. Almost every AWS service implements it through integration with AWS KMS — the service calls KMS to obtain data keys and encrypts your data transparently. Your job as a developer is usually a configuration choice (which key?) rather than encryption code.

In transit means TLS on the wire. AWS service endpoints are HTTPS, so SDK calls are already encrypted in transit. For your own applications, you terminate TLS with certificates from AWS Certificate Manager on the front door: CloudFront distributions, Application Load Balancers, and API Gateway custom domains.

Two enforcement details the exam favors. First, you can require encrypted transport with a policy: an S3 bucket policy that denies requests where aws:SecureTransport is false rejects any plaintext HTTP access. Second, the two protections are independent — encrypting at rest does nothing for the network path, and TLS does nothing for stored data. A compliance requirement of "data must be encrypted at rest and in transit" is asking for both mechanisms, and answers that supply only one are distractors. As a reading shortcut: when a question mentions certificates, think transit; when it mentions KMS keys, think rest.

Certificate management on AWS splits between two services, and the split is exactly what the exam tests: AWS Certificate Manager (ACM) issues publicly trusted TLS certificates, while AWS Private CA runs your own certificate authority for internal trust.

ACM public certificates are free, requested in minutes, and validated by DNS or email. The validation method matters: DNS-validated certificates renew automatically as long as the validation record stays in place, while email validation requires a human to respond — so DNS validation is the answer whenever a scenario mentions renewal toil or expired-certificate outages. ACM deploys these certificates to integrated services — CloudFront, Elastic Load Balancing, API Gateway custom domains — and stores and rotates the private key for you. That integration is also the boundary: when you need a certificate on something ACM doesn't integrate with, ACM's public certificates aren't the tool.

AWS Private CA issues certificates trusted only where you install your root of trust — exactly what you want for internal microservice TLS, mutual TLS (mTLS) where clients present certificates too, IoT devices, and development environments. Private CA certificates can be exported with their private keys and installed anywhere, including EC2 instances and on-premises servers. API Gateway's mutual TLS feature pairs naturally with it: you upload a truststore of CA certificates, and only clients presenting certificates that chain to it may connect.

Decision rule: public users on the internet → ACM public certificate; internal services, client certificates, or certificates you must export → AWS Private CA.

The client-side versus server-side question is really: who turns plaintext into ciphertext, and who holds the keys? With server-side encryption, you send plaintext over TLS and the AWS service encrypts before storing and decrypts on retrieval. With client-side encryption, your application encrypts before anything leaves it — AWS only ever stores ciphertext and cannot decrypt it. S3 offers the full menu, and its table is the canonical exam comparison:

Details worth points: S3 now applies SSE-S3 to every new object by default. SSE-KMS adds two things SSE-S3 cannot: a CloudTrail audit record of every key use, and a second authorization gate — a caller needs permission on the object and on the key to decrypt. SSE-C requires HTTPS and requires you to send the same key again to read the object back; lose the key, lose the data. Client-side encryption typically pairs with KMS through envelope encryption in your own code. Match the trigger phrase and these questions become free marks.

KMS keys differ on two axes: who manages them, and what cryptography they perform.

Ownership tiers. AWS owned keys belong to a service's own fleet — you don't see them, configure them, or pay for them (DynamoDB's default encryption uses one). AWS managed keys are created per service in your account with aliases like aws/s3; only that service can use them, their key policies are read-only, and rotation is automatic and unchangeable. Customer managed keys are the ones you create — and the only tier where you control the key policy, enable or disable the key, schedule deletion, configure rotation, create grants, and share across accounts. Any scenario demanding control, audit specifics, or cross-account use points at a customer managed key.

Key policies deserve respect: every KMS key has exactly one, and it is the primary authorization gate. The default policy delegates to IAM by granting the account root full access; if a key policy doesn't delegate to IAM or name a principal directly, IAM policies alone cannot grant use of that key. This inversion — the resource policy comes first — is unusual among AWS services and a favorite trap.

Symmetric versus asymmetric. Symmetric keys are the default: a single AES-256 key that never leaves KMS unencrypted — all Encrypt, Decrypt, and GenerateDataKey operations happen inside the service. Asymmetric keys are RSA or ECC key pairs used for encrypt/decrypt or sign/verify; the public key is downloadable, so parties outside AWS can encrypt or verify signatures without calling KMS, while the private key stays inside. Aliases are mutable pointers to keys — applications reference alias/app-key, and repointing the alias to a new key is how manual rotation stays invisible to code.

Envelope encryption exists because of one hard limit: the KMS Encrypt API accepts at most 4 KB (4,096 bytes) of plaintext. KMS is built to encrypt keys, not data — so you encrypt data locally with a data key, and use KMS only to protect that data key. This is the single most-tested KMS mechanic on the exam.

Encrypting a 500 MB video file, step by step:

1. Call GenerateDataKey, naming your KMS key. KMS returns the same data key twice: once in plaintext, once encrypted under your KMS key.
2. Encrypt the file locally with the plaintext data key (AES-256) — fast, no network round trips, no size limit.
3. Store the encrypted data key alongside the ciphertext — as object metadata, a file header, or a database column.
4. Erase the plaintext data key from memory. Nothing durable now holds usable key material.

To decrypt: read the encrypted data key from storage, call KMS Decrypt on it (the ciphertext blob itself identifies which KMS key protected it), receive the plaintext data key, decrypt the file locally, and discard the key again. Notice what never happens: the 500 MB file never travels to KMS, and only two small KMS calls occur across the whole lifecycle.

Two refinements: GenerateDataKeyWithoutPlaintext returns only the encrypted copy, for components that store now and decrypt later; and this whole pattern is exactly what the AWS Encryption SDK and the S3 encryption clients implement for you. Exam trigger: "encrypt a large file with KMS" — the correct answer contains GenerateDataKey, never a bare Encrypt call.

Using a KMS key across account boundaries requires both sides to say yes — the same two-sided rule as cross-account IAM, with the key policy playing the resource-based part.

Suppose account A owns the key and account B's application must decrypt with it:

1. The key policy in account A must allow account B (its root, or specific principals) the needed actions — typically kms:Encrypt, kms:Decrypt, kms:GenerateDataKey, and kms:DescribeKey.
2. An IAM policy in account B must grant its principals those same actions on the key's ARN. Delegation through the key policy alone is not enough; B's identities still need their own allow.

Reference the key by its full ARN in cross-account configuration — aliases are account-local and will not resolve from account B. The classic exam symptom: "account B receives an access denied error when decrypting objects encrypted with account A's KMS key" — the fix is almost always the key policy in A, the IAM policy in B, or both. S3 objects under SSE-KMS add one more gate: a cross-account reader needs permission on the bucket and on the key.

Grants are the third instrument: programmatic, temporary permissions attached to a key that allow specific operations for a specific grantee, created with CreateGrant and revocable at any time — no policy edits required. AWS services use grants behind the scenes when they must use your key on your behalf (EBS attaching an encrypted volume, for example). Reach for grants when access must be delegated dynamically and revoked cleanly; use the key policy for durable, declarative sharing.

Key rotation rules vary by key type, and the exam probes the edges.

Customer managed symmetric keys support automatic rotation — opt-in, off by default. Enable it and KMS rotates the backing key material on a yearly cycle. Three properties matter: the key's ID, ARN, aliases, and policy do not change; KMS retains every previous version of the key material, so ciphertext encrypted years ago still decrypts with no re-encryption job; and rotation is transparent — applications keep calling the same key. You can disable automatic rotation at any time, which simply stops future rotations.

AWS managed keys (the aws/service keys) rotate automatically every year, and you can neither turn that off nor tune it.

Keys that cannot auto-rotate: asymmetric keys, HMAC keys, and keys with imported key material. For imported material you supplied the bytes yourself, so KMS cannot generate replacements — you rotate manually: create a new key with fresh material, then repoint the application's alias to it. Manual rotation by alias-repointing is the universal fallback, and it is the reason applications should reference aliases rather than key IDs. Imported material carries extra caveats at concept level: you are responsible for keeping a copy (KMS cannot recover imported material you delete), and you may set an expiration on it.

Keep rotation distinct from disabling: rotation swaps key material while the key keeps working; disabling a key blocks every cryptographic operation until it is re-enabled — a kill switch, not maintenance. Scheduled deletion goes further still and, once complete, makes all data encrypted under the key permanently unreadable.

Development work needs keys and certificates too, and the exam touches the basics. EC2 key pairs secure SSH access: AWS stores only the public key, you download the private key exactly once at creation, and you can import your own public key generated with ssh-keygen. Lose the private key and you don't reset it — you replace the key pair. For TLS in development, teams typically issue certificates from AWS Private CA or self-sign; ACM's public certificates exist to serve traffic on integrated AWS services, not to hand you a key file for arbitrary local use — when a certificate must live somewhere ACM doesn't integrate with, that is Private CA territory.

Know the encryption posture of the services you build with:

• S3 — every new object is encrypted by default with SSE-S3; step up to SSE-KMS when you need auditability or key-level access control.
• EBS — KMS-encrypted volumes protect data at rest, the snapshots taken from them, and data moving between the instance and the volume; you can force encryption for the whole account with encryption by default.
• DynamoDB — always encrypted at rest; your only choice is which key: AWS owned (default), the AWS managed key, or a customer managed key.
• Lambda environment variables — encrypted at rest with KMS automatically; for sensitive values you can supply a customer managed key and use console encryption helpers so values are decrypted only inside your function code.

One boundary note: environment variables are configuration, not a vault. Real secrets belong in AWS Secrets Manager or Systems Manager Parameter Store — both of which encrypt their contents with KMS keys, exactly as you would now expect.