5.3.1. Encryption at Rest and in Transit with KMS
💡 First Principle: "At rest" protects data stored on disk; "in transit" protects data moving between services. AWS KMS (Key Management Service) is the central key management hub — it generates, stores, rotates, and audits encryption keys used by S3, Redshift, Glue, EMR, and virtually every AWS service. Understanding KMS key types and encryption methods is essential for the exam.
Encryption at rest options for S3:
| Method | Key Management | Audit | Cost | Use When |
|---|---|---|---|---|
| SSE-S3 | AWS manages keys | No per-key audit | Free | Default encryption, no special requirements |
| SSE-KMS | Customer manages keys in KMS | CloudTrail logs every key use | Per-request KMS cost | Need audit trail, cross-account control, or key rotation control |
| SSE-C | Customer provides keys per request | Customer manages | Free (but complex) | Regulatory requirement for customer-managed keys |
| CSE | Client-side encryption before upload | Customer manages | Free (but most complex) | Need end-to-end encryption, data encrypted before reaching AWS |
KMS key types: AWS managed keys (aws/s3, aws/redshift — AWS creates and manages), Customer managed keys (CMK — you create, control policies, enable rotation), and AWS owned keys (internal to AWS, invisible to you). Automatic rotation on a customer managed key creates new key material every year by default (configurable from 90 to 2,560 days), and you can also rotate on demand for an unplanned rotation (up to 25 times per key). For a fixed schedule such as quarterly, AWS recommends automatic rotation with a custom rotation period rather than repeated on-demand rotations. KMS keeps all earlier key material, so existing data still decrypts, nothing is re-encrypted, and applications keep using the same key ID. Amazon Redshift encrypts at rest natively (data blocks, system metadata, snapshots) with a key managed by AWS KMS or, on older node types, a hardware security module (HSM). Redshift has its own managed storage, so S3 encryption does not cover it.
Encryption in transit uses TLS (Transport Layer Security). AWS SDKs and the console use HTTPS by default, but S3 still accepts plain HTTP unless you forbid it: to require TLS, add a bucket policy statement that denies s3:* when the condition key aws:SecureTransport is false. SSE settings protect data at rest and do nothing for transit. For data flowing between VPC resources, VPC endpoints ensure traffic stays on the AWS network. The v1.1 syllabus adds "encryption in transit or before transit" — referring to encrypting data before it enters the pipeline (client-side encryption) and ensuring all data movement uses TLS.
Cross-account encryption: When sharing encrypted data across accounts, the KMS key policy must grant kms:Decrypt permission to the consuming account's principals. This is a common exam scenario — "Account A shares encrypted S3 data with Account B." It needs both sides: the key policy in Account A must allow the external account or principal, and the IAM policy of the calling principal in Account B (for example the Glue job role) must allow kms:Decrypt on the key ARN. For S3 objects, the bucket policy must also grant s3:GetObject (see 3.1.1). Keys are never copied between accounts.
⚠️ Exam Trap: SSE-KMS has a requests-per-second quota (5,500–30,000 depending on Region). High-throughput S3 operations (millions of PUTs/GETs) can hit KMS throttling limits. If a question describes S3 performance degradation with SSE-KMS, the answer may involve requesting a KMS quota increase or using S3 bucket keys (which reduce KMS API calls by caching the data key at the bucket level).
Reflection Question: A company shares encrypted S3 data with a partner in a different AWS account. The partner can access the S3 objects but gets "AccessDenied" when trying to read them. What's likely missing?
