Data Encryption and Masking on AWS: KMS, TLS, and Anonymization

AWS KMS protects data through envelope encryption: KMS never encrypts your gigabytes of data directly with the KMS key. Instead, a service calls the GenerateDataKey API, receives a unique data key in both plaintext and encrypted form, encrypts your object or block locally with the plaintext data key, then discards the plaintext key and stores the encrypted copy of the data key alongside the ciphertext. To decrypt, the service sends the encrypted data key back to KMS, which returns the plaintext data key so the data can be decrypted in memory.

This design matters for two exam-relevant reasons. First, the KMS key itself never leaves KMS unencrypted — access to it is always mediated by the key policy and IAM, and every use is logged to AWS CloudTrail. Second, performance and cost stay manageable: the bulk encryption happens locally with a symmetric data key, and KMS is only called once per object (or less, with features like S3 Bucket Keys, which let a bucket reuse a short-lived bucket-level key to cut KMS request volume and cost dramatically for high-object-count workloads).

Revoking access is equally elegant. If you disable a customer managed key or deny a principal kms:Decrypt, every piece of data whose data key was wrapped by that KMS key becomes unreadable to that principal — you do not have to re-encrypt anything to cut someone off. That is why exam scenarios about "immediately revoke access to encrypted data" almost always resolve to changing the KMS key policy or disabling the key, not to rewriting objects.

Choose a customer managed key whenever a scenario demands control: you need to edit the key policy, share the key across accounts, disable or delete it on your schedule, or prove auditable control over rotation. Choose the AWS managed key (the ones named aws/s3, aws/redshift, and so on) when you just want KMS-backed encryption with CloudTrail visibility but no management burden. AWS owned keys are keys AWS uses on your behalf without showing them in your account at all — DynamoDB uses one by default.

The single most tested distinction: an AWS managed key can never be used by another AWS account. If a scenario involves cross-account access to encrypted S3 objects, Redshift snapshots, or EBS volumes, the answer requires a customer managed key — full stop. If a stem says the team is currently using SSE-KMS with the aws/s3 key and now needs to share with a partner account, the first step is re-encrypting or reconfiguring with a customer managed key.

Customer managed keys also support imported key material (bring your own key) and multi-Region keys — related keys in different Regions that share key material and key ID, so data encrypted in one Region can be decrypted in another without a cross-Region KMS call. Multi-Region keys are the clean answer for encrypted cross-Region replication and disaster recovery scenarios.

Access to a customer managed key is decided by the intersection of its key policy and IAM policies. The key policy is the primary, resource-based control — unlike most AWS resources, a KMS key does not implicitly trust even its own account: the default key policy contains a statement that delegates permission decisions to IAM by allowing the account root principal, and if you remove that statement, IAM policies alone can no longer grant access to the key.

Separate the two permission planes in your head. Key administrators get permissions like kms:PutKeyPolicy, kms:ScheduleKeyDeletion, and kms:EnableKey — they manage the key but should not necessarily be able to decrypt with it. Key users get kms:Encrypt, kms:Decrypt, kms:GenerateDataKey, and kms:DescribeKey. Exam answers that follow least privilege keep these roles distinct.

Grants are the third mechanism: temporary, programmatic permissions that AWS services use to act on your behalf. When Amazon Redshift or Amazon EBS needs to use your key for an asynchronous workflow, it creates a grant rather than requiring a key policy edit. You will also see the kms:ViaService condition key, which restricts a key so it can only be used through a specific service (for example, only via S3 in a given Region), and kms:EncryptionContext conditions, which bind a key operation to name-value pairs that must match at decrypt time — an integrity check that also shows up in CloudTrail logs for auditing.

Each major data store offers KMS integration, but the defaults and options differ, and the exam expects you to know which knob exists where.

Amazon S3 encrypts every new object by default with SSE-S3 (S3-managed AES-256 keys). Step up to SSE-KMS when you need key-level access control, CloudTrail logging of key usage, or cross-account sharing; enable S3 Bucket Keys with SSE-KMS to reduce KMS request costs on busy buckets. DSSE-KMS applies two independent layers of encryption for the strictest compliance regimes. SSE-C lets a client supply its own key with every request (S3 stores nothing), and client-side encryption — encrypting before upload, for example with the AWS Encryption SDK — means AWS never sees plaintext at all. You can require encryption on write with a bucket policy that denies PutObject requests lacking the expected s3 encryption header.

Amazon Redshift encryption is set at the cluster (or serverless namespace) level using KMS. Everything inside — data blocks, system metadata, and snapshots — is encrypted, and snapshots inherit the cluster's key. To share an encrypted snapshot with another account you must use a customer managed key and grant the other account access to it. DynamoDB is always encrypted at rest; your only choice is which key: the AWS owned key (default, free, invisible), the AWS managed aws/dynamodb key, or a customer managed key when auditors require key control. Backups and DynamoDB Streams data are covered as well.

Beyond the big three: AWS Glue can encrypt Data Catalog metadata, job bookmarks, and the S3 outputs its jobs write; Amazon EMR uses security configurations to encrypt EMRFS data in S3 and local disks on cluster nodes; and Amazon Kinesis Data Streams offers server-side encryption with KMS so records are encrypted before they land in the stream.

Configuring encryption across account boundaries always takes two grants, not one: the key policy in the producer account must allow the external account (or specific external principals) to use the key, and an IAM policy in the consumer account must grant its principals the matching kms:Decrypt or kms:GenerateDataKey permissions. Neither side alone is sufficient — a key policy that trusts account B does nothing until an admin in account B delegates that access onward with IAM. This double-gate is the most common cross-account wrong-answer trap.

Work through the canonical scenario: a central data lake account holds an S3 bucket encrypted with SSE-KMS under a customer managed key, and an analytics account must run Amazon Athena queries against it. You need three things: a bucket policy allowing the analytics account to read the objects, a key policy statement allowing the analytics account to decrypt with the key, and IAM permissions in the analytics account for both the bucket and the key. Miss the key policy and every GetObject fails with an access-denied error from KMS even though the S3 permissions look perfect.

S3 replication between accounts with KMS adds its own wrinkle: the replication role must be able to decrypt with the source key and encrypt with the destination key, and the destination bucket's key must permit the source account's replication role. For Redshift, sharing an encrypted snapshot cross-account requires granting the target account use of the customer managed key before authorizing the snapshot access. Whenever a scenario says data is encrypted with an AWS managed key and must cross accounts, the answer is to switch to a customer managed key first.

Encryption in transit on AWS means TLS. Every AWS service API endpoint supports HTTPS, so the work is not enabling TLS — it is refusing everything that is not TLS. For S3, attach a bucket policy that denies all actions when the aws:SecureTransport condition key is false; that single statement guarantees no object can be read or written over plain HTTP. For Amazon Redshift, set the require_ssl parameter to true in the cluster parameter group so JDBC and ODBC clients must connect over TLS. For Amazon RDS and Aurora, require SSL per engine (for example, PostgreSQL's rds.force_ssl) and validate server certificates from the AWS certificate bundle.

Distributed processing frameworks need in-transit protection between their own nodes too. Amazon EMR handles this through a security configuration that enables in-transit encryption with TLS certificates you provide, covering traffic between cluster nodes for frameworks like Spark and Tez. Amazon MSK encrypts traffic between brokers and can require TLS between clients and brokers. AWS Glue connections to JDBC sources can require SSL as part of the connection definition.

Encrypting before transit is the stricter posture: the client encrypts data before it ever leaves the producing system, so even the transport layer only ever carries ciphertext. The AWS Encryption SDK and the S3 client-side encryption feature implement this pattern with KMS-backed data keys, and DynamoDB has client-side encryption support through the AWS Database Encryption SDK. Choose client-side encryption in scenarios where a regulator or contract says AWS itself must never handle plaintext — server-side encryption, however strong, does not satisfy that requirement because the service briefly processes unencrypted data.

Masking and anonymization protect data that must remain queryable. Encryption is all-or-nothing per principal; masking lets the same table serve analysts who may see everything and analysts who must never see raw PII, per compliance laws like GDPR and HIPAA or company policy.

AWS Lake Formation data filters apply column-level, row-level, and cell-level security to data lake tables queried through Athena, Redshift Spectrum, and Amazon EMR. A filter can exclude sensitive columns entirely for a given principal (column-level), restrict which rows a team sees (row-level, for example only their own region's customers), or combine both (cell-level). Because Lake Formation enforces the filter at query time in the service, there is no second, scrubbed copy of the data to keep in sync.

Amazon Redshift dynamic data masking attaches masking policies to columns and applies them at query time based on the user's role: a support analyst sees the last four digits of a card number while a fraud team role sees the full value — same table, no duplicated data. For pipeline-time masking, AWS Glue offers a Detect PII transform (backed by managed PII entity detection) that can identify and then redact or hash sensitive fields as data flows through a job, and AWS Glue DataBrew provides redaction, substitution, and deterministic hashing transformations for data preparation. Amazon Macie is the discovery side of the story: it scans S3 buckets with machine learning and managed data identifiers to find where PII lives, telling you which datasets need masking at all.

Know the vocabulary distinctions for the exam. Masking hides part of a value for display. Tokenization replaces a value with a surrogate token and keeps the real value in a separate secure vault — the mapping is reversible only through that vault, and joins on the token still work, which makes it popular for payment data. Hashing is one-way and deterministic, good for joining datasets on an identifier without revealing it. Anonymization is irreversible removal or generalization of identifiers so individuals cannot be re-identified — once truly anonymized, data typically falls outside laws like GDPR, which is exactly why regulators set a high bar for calling something anonymized rather than merely pseudonymized.

Match the requirement phrase in the question to the control. "Prove who used the key and when" or "revoke a partner's access immediately" points to a customer managed KMS key and its key policy. "Minimize cost and management overhead for encryption at rest" points to default SSE-S3 or an AWS owned key. "Share encrypted data with another AWS account" means customer managed key plus a two-sided permission setup. "Reduce KMS request charges on a high-throughput bucket" is S3 Bucket Keys. "AWS must never see plaintext" is client-side encryption before transit.

For masking scenarios: "analysts must query the table but never see the SSN column" is a Lake Formation data filter (or Redshift dynamic data masking if the table lives in Redshift); "find out which of our thousands of buckets contain PII" is Amazon Macie; "replace card numbers with reversible surrogates that preserve joins" is tokenization; "remove identifiers permanently so the dataset is out of GDPR scope" is anonymization. If the scenario emphasizes doing this during ETL rather than at query time, reach for the Glue Detect PII transform or DataBrew.

Finally, watch for stems that mix layers. Encryption at rest does not protect data from an authorized user who can query it — that is masking's job. TLS does not protect stored data — that is at-rest encryption's job. A complete answer in a compliance scenario usually stacks all three: KMS at rest, TLS in transit, and masking or filters at the access layer.