Encryption in Flight, at Rest and Client-Side

By the end of this lesson you will be able to

• Explain what encryption is (plaintext, ciphertext, algorithm, key) and recognise the exam phrases that demand it.
• Tell symmetric from asymmetric encryption, and say what each is used for, including digital signatures.
• Describe encryption in flight with TLS: what it protects against, how certificates stop a man-in-the-middle, where TLS ends on AWS, and why the exam still says “SSL”.
• Describe server-side encryption at rest and client-side encryption: who encrypts, where the key lives, who can ever see plaintext, and the exam keywords for each.
• Explain envelope encryption with data keys, why KMS works that way (the 4 KB limit, speed, cost), and what happens when the KMS key is disabled.
• Combine the three models in a design, and pick the right one from a scenario.

#Why encrypt at all?

Chapter 21 is about protecting data and applications on AWS: encryption and keys (this lesson, KMS in 21.2, CloudHSM in 21.5), secrets (21.3), certificates (21.4), and the services that block and detect attacks (21.6, 21.7). Almost every exam question in this chapter reads the same way: find the keywords (who controls the key, free or paid, one Region or many, network layer or application layer) and pick the one service or option that fits. This first lesson gives you the vocabulary every other lesson builds on.

#Plaintext, ciphertext and the key

Encryption turns plaintext (data anyone can read) into ciphertext (data that looks like random bytes) using an algorithm and a key. Decryption turns it back. The algorithm is public and well studied (AES, RSA…); the only secret is the key. Whoever holds the right key reads the data; everyone else, including someone who copies every byte, gets nothing useful.

The main purpose is to protect data from unauthorised access: from someone who should not have it but somehow got the bytes. Permissions decide who may ask for data; encryption decides what someone can read if they get the bytes without asking. You need both.

#Symmetric and asymmetric encryption

There are two families of algorithms. You will meet their KMS versions in lesson 21.2; here are the ideas.

In practice the two work together. TLS uses asymmetric cryptography to agree a fresh symmetric session key, then encrypts the traffic with that symmetric key. AWS services encrypt your stored data with symmetric AES-256. Asymmetric keys show up when someone outside AWS must encrypt with a public key, or when you need to sign something (a document, a software release, a token) so others can verify who made it and that it was not changed.

#Three ways to protect data

Data is in one of two states, and there are two places to encrypt it at rest, which gives the three models the exam asks about:

They are not alternatives: a well-designed system uses in flight plus at rest everywhere, and adds client-side encryption for the most sensitive data.

#Encryption in flight: TLS

#What TLS does

Data in flight (or in transit) is data travelling from one place to another: a customer’s phone to your load balancer, an app server to a database, your data centre to S3. On the way it passes Wi-Fi routers, ISPs and switches you do not control. Anyone on that path could read it, or change it. This is the man-in-the-middle (MITM) attack.

TLS (Transport Layer Security) protects the connection:

• Confidentiality: data is encrypted before sending and decrypted after receiving, with a session key that only the two ends know.
• Integrity: every record carries a check, so a changed byte is detected and the connection drops.
• Authentication of the server: the server proves its identity with a certificate, signed by a certificate authority (CA) the client trusts. This web of CAs and certificates is the public key infrastructure (PKI). A MITM cannot present a valid certificate for your domain, because he has neither your private key nor a CA willing to sign one for him.

HTTPS is simply HTTP inside TLS. The same TLS also wraps database connections, mail, MQTT from IoT devices, and the AWS API itself.

#Where TLS ends on AWS

TLS protects one connection, from one end to the other. On AWS you decide where that end is:

• At the front door. An Application Load Balancer or Network Load Balancer (TLS listener), API Gateway, CloudFront or App Runner holds the certificate and terminates TLS. You get the certificates free from AWS Certificate Manager (ACM), which also renews them: lesson 21.4.
• All the way to the instance. If the rule is “encrypted end to end”, the ALB re-encrypts to an HTTPS target group, or an NLB passes TCP through untouched so the instances terminate TLS themselves. Lesson 6.4 covers termination, re-encryption and passthrough.

In transit inside AWS, the same idea applies service by service. You already met each one; here they are side by side:

#Server-side encryption at rest

#How server-side encryption works

Data at rest is data sitting in storage: an S3 object, an EBS volume, an RDS database, a DynamoDB table, an EFS file system, a snapshot, a backup. With server-side encryption (SSE):

1. The service receives your data (over TLS).
2. It encrypts it with a key, usually a data key, before writing it to disk.
3. When an allowed caller asks for the data, the service decrypts it and sends it back (over TLS).

The application does nothing different. It writes and reads as usual; there is no key in its code and no encryption library to call. That is the meaning of the exam’s “transparent to the application”.

The catch is in the slide’s last line: the keys must be managed somewhere, and the server must have access to them. Server-side encryption protects against storage falling into the wrong hands (a failed disk, a leaked backup, a copy of raw storage), but the service itself handles plaintext while it serves a request, and anyone the service lets in receives plaintext.

#Who holds the key

On AWS the key behind server-side encryption is one of three kinds of KMS key, or a key owned by the service itself. Lesson 21.2 goes into each; for now, the question that matters is how much control and audit you get:

• A key the service owns (for example SSE-S3, or DynamoDB’s default): free, nothing to manage, but no separate permission on the key and no record of its use. Anyone allowed to read the data gets plaintext.
• A KMS key: every use is checked against the key policy and IAM, and logged in CloudTrail. A reader needs permission on the data and on the key, so the key becomes a second gate. With a customer managed key you also decide who may use, rotate, disable or share it.

For S3 the four server-side options are SSE-S3, SSE-KMS, DSSE-KMS and SSE-C (where you send the key with each request); they were taught in full in lesson 10.8. EBS and RDS encryption, and their “choose at creation” rules, are in lessons 5.2 and 7.4.

#Client-side encryption

#How client-side encryption works

With client-side encryption, your application encrypts the data before it leaves your environment, and decrypts it after it comes back. The storage service receives ciphertext, stores ciphertext and returns ciphertext. It never sees plaintext or the key, and it could not decrypt the data even if it wanted to. This is end-to-end encryption (E2EE) in the storage sense: only the ends hold the key.

• The receiving client (your own app, or a partner who was given the key) decrypts.
• Any storage works: S3, DynamoDB, an FTP server, even an email attachment.
• AWS provides libraries so you do not invent cryptography yourself: the AWS Encryption SDK (any data), the Amazon S3 Encryption Client, and the AWS Database Encryption SDK for DynamoDB items. All of them use envelope encryption (next section).
• The key can come from your own key store, from an HSM, or from KMS. With KMS, the library still encrypts in your process: KMS only hands over a data key to an allowed caller, and S3 still sees only ciphertext.

The price is real:

• You run the whole cycle: key storage, rotation, access, and decryption in every program that reads the data.
• AWS services cannot look inside: no Athena queries, no Macie scan for personal data, no Lambda thumbnails, no full-text search, unless that code has the key.
• Lose the key and the data is gone. Nobody at AWS can help.

#Who can read it?

The one table to remember: for each model, who can ever see plaintext.

Try every cell yourself:

#Envelope encryption: how AWS really encrypts

#The problem with sending data to KMS

KMS keeps its keys inside hardware security modules, and a KMS key never leaves KMS unencrypted. So how does S3 encrypt a 5 GB object with it? Not by sending 5 GB to KMS:

• The KMS Encrypt operation accepts at most 4 KB (4,096 bytes) of plaintext. It is meant for small secrets such as a password, not files.
• Even for small items, a network call to KMS for every record would be slow, cost a request fee each time, and eat into the KMS request quota that every service in the account and Region shares.

#Data keys and the key-encryption key

The answer is envelope encryption: the data is encrypted with a data key, and the data key is encrypted with the KMS key. The KMS key here is a key-encryption key (KEK).

1. Ask for a data key

   The client (S3, EBS, or your own code through the Encryption SDK) calls GenerateDataKey on a KMS key. KMS checks permissions and returns the same data key twice: as plaintext, and encrypted under the KMS key.

2. Encrypt locally

   The client encrypts the data with the plaintext data key (AES-256), locally and fast, with no size limit.

3. Throw the plaintext key away

   The plaintext data key is wiped from memory as soon as possible.

4. Store the encrypted key with the data

   The encrypted data key is stored next to the ciphertext, in the same “envelope” (object metadata, volume metadata, the message header of the Encryption SDK).

5. To decrypt, unwrap the key only

   The client sends only the encrypted data key to KMS Decrypt. KMS checks permissions, logs the call in CloudTrail, and returns the plaintext data key. The client decrypts the data locally and wipes the key again.

Why this design wins:

• Speed and size: bulk data is encrypted where it is, never shipped to KMS. Only 32-byte keys travel.
• Cost and quota: one KMS call per data key, not per record. Libraries can even cache a data key for a few messages, and S3 Bucket Keys reuse one for many objects (lesson 10.8).
• Control stays central: every decrypt still needs KMS, so the key policy, IAM and CloudTrail apply to every read. Disable the KMS key and every envelope is sealed.
• Rotation is cheap: rotating the KMS key does not mean re-encrypting terabytes. KMS keeps older key material to unwrap older data keys, and new data keys are wrapped with the new material.
• Small blast radius: each object or volume has its own data key, so one leaked data key exposes one object, not everything.

A variant, GenerateDataKeyWithoutPlaintext, returns only the encrypted data key, for a component that will store it now and ask KMS to decrypt it later (EBS does this when it creates a volume, lesson 5.2).

#What goes wrong

• HTTP left open beside HTTPS. A load balancer listener on port 80 that serves the app instead of redirecting, or a bucket without a SecureTransport Deny: data travels in clear text from old clients. Redirect HTTP to HTTPS and deny non-TLS requests.
• Certificate checks turned off. An app or script with “verify = false” to silence an error accepts any certificate, so a MITM works again. Fix the trust store instead.
• “It is encrypted, so it is safe.” With server-side encryption, anyone who has read permission receives plaintext. Encryption at rest does not replace least-privilege permissions; a KMS key adds the second gate only if its key policy is actually narrow.
• AccessDenied although S3 allows the read. The object is SSE-KMS and the caller lacks kms:Decrypt (or the key policy does not trust its account). Grant the key permission, not more S3 permission.
• Data unreadable after a key change. A KMS key disabled or scheduled for deletion, an imported key whose material expired, or a client-side key lost on a laptop. Treat keys as more precious than the data.
• TLS terminated at the load balancer when the rule says end to end. The hop to the instances is plain HTTP. Use an HTTPS target group or NLB passthrough.
• Client-side encryption breaks other services. Athena, Macie, search or image processing return nonsense on ciphertext. Decide which fields really need it (for example only the NID scan, not the order history).
• Sensitive data outside the encrypted part. S3 server-side encryption does not encrypt object names, tags or metadata, so a key like nid/rina-akter-1990.jpg leaks a name. Use opaque IDs.

#Encryption in system design

A typical layered design for a Bangladeshi fintech:

• Edge: CloudFront or an ALB with an ACM certificate, TLS 1.2+ only, HTTP redirected to HTTPS.
• Inside: TLS from the ALB to the services where the policy demands it, TLS to RDS and ElastiCache forced by parameters, EFS mounted with tls.
• At rest, everywhere: EBS and RDS encrypted by default, S3 with SSE-KMS and Bucket Keys, all with customer managed keys whose key policies follow team boundaries, CloudTrail watching every use.
• Most sensitive fields: client-side encryption for NID scans and card data, with keys from a KMS key that only one service role may use.
• Secrets and certificates handled by Secrets Manager and ACM, not files on servers (lessons 21.3 and 21.4).

#Try it yourself

These commands use the AWS CLI v2 and OpenSSL. KMS keys cost about 1 USD a month, so schedule the key for deletion at the end.

# 1. Look at a real TLS handshake: protocol, cipher and the certificate chain
openssl s_client -connect aws.amazon.com:443 -servername aws.amazon.com -brief </dev/null
# CONNECTION ESTABLISHED
# Protocol version: TLSv1.3
# Ciphersuite: TLS_AES_128_GCM_SHA256
# Peer certificate: CN = aws.amazon.com
# Verification: OK

# 2. Plain HTTP versus HTTPS: the request line is readable only in the first case on the wire
curl -sv http://example.com -o /dev/null 2>&1 | grep -E '^> (GET|Host)'
curl -sv https://example.com -o /dev/null 2>&1 | grep -E 'SSL connection|subject:'

# 3. A symmetric KMS key for the lab
KEY_ID=$(aws kms create-key --description "enc-basics lab" --query KeyMetadata.KeyId --output text)
aws kms create-alias --alias-name alias/enc-basics-lab --target-key-id "$KEY_ID"

# 4. Encrypt a small secret directly with KMS (under 4 KB: fine)
aws kms encrypt --key-id alias/enc-basics-lab --plaintext fileb://<(echo -n 'db-password-example') \
  --query CiphertextBlob --output text > secret.b64

# 5. Try a 5 MB file directly: KMS refuses
head -c 5242880 /dev/urandom > big.bin
aws kms encrypt --key-id alias/enc-basics-lab --plaintext fileb://big.bin
# An error occurred (ValidationException) ... Member must have length less than or equal to 4096

# 6. Envelope encryption by hand: get a data key in two forms
aws kms generate-data-key --key-id alias/enc-basics-lab --key-spec AES_256 > dk.json
jq -r .Plaintext dk.json | base64 -d > dk.plain          # 32 bytes, use and destroy
jq -r .CiphertextBlob dk.json | base64 -d > dk.enc       # keep this next to the data

# 7. Encrypt the big file locally with the plaintext data key, then wipe the key
openssl enc -aes-256-cbc -pbkdf2 -in big.bin -out big.bin.enc -pass file:dk.plain
shred -u dk.plain

# 8. Later: ask KMS to unwrap only the small encrypted key, then decrypt locally
aws kms decrypt --ciphertext-blob fileb://dk.enc --query Plaintext --output text | base64 -d > dk.plain
openssl enc -d -aes-256-cbc -pbkdf2 -in big.bin.enc -out big.check -pass file:dk.plain
cmp big.bin big.check && echo "same file"
shred -u dk.plain

# 9. Server-side encryption needs no code: upload with SSE-KMS and look at the result
aws s3 cp big.bin s3://enc-lab-example/big.bin --sse aws:kms --sse-kms-key-id alias/enc-basics-lab
aws s3api head-object --bucket enc-lab-example --key big.bin \
  --query '[ServerSideEncryption,SSEKMSKeyId]'
# [ "aws:kms", "arn:aws:kms:ap-southeast-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab" ]

# 10. Clean up (the key waits 7 days before it is really deleted)
aws s3 rm s3://enc-lab-example/big.bin
aws kms schedule-key-deletion --key-id "$KEY_ID" --pending-window-in-days 7

Step 7 uses openssl enc only to show the idea; real applications use the AWS Encryption SDK, which does the same steps with authenticated encryption and stores the encrypted data key in the message header for you. Then open CloudTrail’s event history and filter by the event source kms.amazonaws.com: you will see your GenerateDataKey and Decrypt calls, but no record for anything you did locally with the plaintext key.

#Summary

Key takeaways

• Encryption = plaintext → ciphertext with a public algorithm and a secret key. Purpose: protect data from unauthorised access. Exam: “regulatory compliance”, “unauthorised access” → include encryption.
• Symmetric (one key, AES-256, fast, used for data) vs asymmetric (public + private key pair, RSA/ECC, slow, used to exchange keys and for digital signatures: private signs, public verifies).
• In flight: TLS (the exam’s “SSL”) encrypts before sending and decrypts after receiving, checks integrity, and authenticates the server with a CA-signed certificate, which defeats MITM. Keywords: HTTPS, “in transit”. On AWS: ACM certificates on ALB, NLB, API Gateway, CloudFront; end-to-end TLS to targets if required; aws:SecureTransport to deny plain HTTP.
• Server-side at rest: the service encrypts after receiving and decrypts before sending; transparent to the application, “minimal code changes”. The server must have access to the key. A KMS key adds a second gate (kms:Decrypt) and a CloudTrail audit trail; a service-owned key (SSE-S3) does not.
• Client-side: you encrypt before sending; AWS stores ciphertext and never sees plaintext or the key. Keywords: “full control before data leaves the network”, “AWS must never see plaintext”. Tools: AWS Encryption SDK, S3 Encryption Client, Database Encryption SDK. Cost: you manage keys; AWS services cannot process the content.
• Envelope encryption: GenerateDataKey returns a data key in plaintext and encrypted under the KMS key (the KEK); encrypt locally, wipe the plaintext key, store the encrypted key with the data; to read, send only the encrypted key to Decrypt. Needed because Encrypt takes at most 4 KB and because it is faster, cheaper and easier on the KMS quota.
• Lose or delete the KMS key and the data is gone: deletion waits 7–30 days (lesson 21.2).

Self-check: encryption basics30 questions