AWS Security & Encryption

1. Three kinds of encryption

Before naming any service, be clear about where the data gets encrypted and who holds the key. There are three cases to keep apart, and the exam regularly asks you to pick the right one.

Encryption in flight (TLS / SSL)

The data is encrypted before it is sent and decrypted after it is received. TLS certificates are what make this work, and HTTPS is the everyday form of it. Encryption in flight is what stops a man-in-the-middle from reading credentials travelling between a client and a server: what crosses the wire is ciphertext, not Username: admin / Password: supersecret.

Server-side encryption at rest

The data arrives at the server in the clear (over HTTPS), and the server encrypts it before storing it, usually with a data key. On the way out, the server decrypts it before sending it back. The consequence is that the encryption and decryption keys have to be managed somewhere and the server must be able to reach them. This is what an AWS service such as S3 does for you.

Client-side encryption

The client encrypts the data, and the server never decrypts it — only a receiving client can. The storage service, whether FTP, S3 or anything else, holds an object it cannot read. Client-side encryption typically uses envelope encryption: a data key encrypts the object and the data key itself is protected.

Exam tip

“The service provider must not be able to read the data” always means client-side encryption. “Data must be encrypted at rest but the service handles it” means server-side encryption. “No man in the middle” means TLS.

2. AWS KMS (Key Management Service)

Whenever encryption is mentioned for an AWS service, KMS is almost always the answer. AWS manages the encryption keys for you, fully integrated with IAM for authorisation, which makes controlling access to your data a matter of writing policies. KMS key usage is auditable through CloudTrail, and KMS is integrated into most AWS services — EBS, S3, RDS, SSM and more.

Never store secrets in plaintext, least of all in your code. KMS encryption is also available through API calls from the SDK and CLI, so an encrypted secret can safely live in code or in an environment variable and be decrypted at runtime.

Key types by algorithm

Symmetric keys (AES-256) use a single key for both encryption and decryption. The AWS services integrated with KMS use symmetric keys. You never get access to the key material — every use goes through a KMS API call.

Asymmetric keys (RSA and ECC key pairs) have a public key for encryption and a private key for decryption, and support encrypt/decrypt or sign/verify operations. The public key is downloadable; the private key can never be accessed unencrypted. The use case is encryption outside of AWS, by users who cannot call the KMS API.

Note that “KMS Keys” is simply the new name for what used to be called Customer Master Keys.

Key types by ownership

Type	Cost
AWS Owned Keys — SSE-S3, SSE-SQS, SSE-DDB default keys	Free
AWS Managed Keys — aws/service-name, for example aws/rds or aws/ebs	Free
Customer managed keys created in KMS	$1 per month
Customer managed keys imported	$1 per month

On top of that you pay per API call to KMS, at $0.03 per 10,000 calls.

Key rotation

• AWS-managed KMS keys rotate automatically every year.
• Customer-managed KMS keys rotate automatically once you enable it, and can also be rotated on demand.
• Imported KMS keys only support manual rotation, done through an alias.

Exam tip

KMS keys are regional. A key in eu-west-2 cannot decrypt anything in ap-southeast-2 unless you are using a multi-region key.

3. KMS Key Policies

A key policy controls access to a KMS key, much like an S3 bucket policy controls access to a bucket. The difference is that you cannot control access without one — a key policy is mandatory.

• The default key policy is created when you do not supply one. It grants complete access to the key to the root user, which means the entire AWS account.
• A custom key policy lets you define which users and roles can use the key and who can administer it. This is what you need for cross-account access to your key.

4. Copying encrypted snapshots

Across regions

An EBS volume encrypted with KMS Key A in eu-west-2 produces a snapshot encrypted with the same key. Copying that snapshot to ap-southeast-2 triggers a KMS ReEncrypt operation so the copy is protected by KMS Key B in the destination region, and the volume restored there is encrypted with Key B.

Across accounts

Sharing an encrypted snapshot with another account follows a fixed sequence:

1. Create a snapshot encrypted with your own customer managed KMS key.
2. Attach a KMS key policy that authorises cross-account access.
3. Share the encrypted snapshot with the target account.
4. In the target account, create a copy of the snapshot and encrypt it with a customer managed key belonging to that account.
5. Create a volume from that copy.

Exam tip

The sequence above starts from a customer managed key of your own, and note that it does not end with the target account using your key: it copies the snapshot and re-encrypts that copy under a customer managed key in its own account.

5. KMS Multi-Region Keys

A multi-region key is one KMS key that exists as an exact duplicate of itself in several AWS Regions, and any of those duplicates will do in place of another. A primary key — for example in us-east-1 — is replicated to replica keys in us-west-2, eu-west-1, ap-southeast-2 and so on; the key ID, the key material and the automatic rotation are the same across all of them. Their ARNs differ only by region and share a mrk- key identifier.

That means you can encrypt in one region and decrypt in another, with no re-encryption and no cross-region API calls. Crucially, multi-region keys are not global: there is a primary and there are replicas, and each one is managed independently.

The use cases are global client-side encryption, encryption on DynamoDB Global Tables, and Global Aurora.

DynamoDB Global Tables with client-side encryption

You can encrypt specific attributes client-side using the Amazon DynamoDB Encryption Client. Combined with Global Tables, the already-encrypted data replicates to the other regions. If a multi-region key is replicated into the same regions as the table, clients there make low-latency KMS calls in their own region to decrypt the attribute locally. The payoff is that individual fields — a social security number, for instance — are protected and only decryptable by a client that has access to the key.

Global Aurora with client-side encryption

The same pattern applies to Aurora, using the AWS Encryption SDK to encrypt specific columns client-side. With Aurora Global Database replication plus a multi-region key replicated alongside, clients in each region decrypt locally. Here the extra benefit is explicit: specific fields are protected even from database administrators.

6. Encryption in S3 Replication

Replication behaves differently depending on how the source objects are encrypted:

• Objects that carry no encryption at all, and objects under SSE-S3, replicate without you doing anything.
• Objects under SSE-C — where the customer provides the key — are eligible for replication too.
• Objects under SSE-KMS are the exception: replication has to be switched on for them. You then name the KMS key that will encrypt the objects landing in the target bucket, adjust that target key’s key policy accordingly, and hand replication an IAM role holding kms:Decrypt on the source key and kms:Encrypt on the target key.

You may run into KMS throttling errors, and the way out of those is to ask for a Service Quotas increase.

Exam tip

You can use multi-region KMS keys with S3 replication, but S3 currently treats them as independent keys: the object is still decrypted and then re-encrypted. Multi-region keys do not save you the round trip here.

7. Sharing an AMI encrypted with KMS

Sharing an encrypted AMI with another account takes five steps:

1. The AMI in the source account is encrypted with a KMS key from the source account.
2. Modify the image attribute to add a launch permission for the target AWS account.
3. Share the KMS key that encrypted the snapshot the AMI references with the target account or IAM role.
4. The IAM role or user in the target account needs permissions for DescribeKey, ReEncrypt*, CreateGrant and Decrypt.
5. When launching an EC2 instance from the AMI, the target account can optionally specify a new KMS key of its own to re-encrypt the volumes.

8. SSM Parameter Store

Parameter Store is where configuration data and secrets go when you want them stored securely. KMS encryption is there if you want it and invisible when you use it: a parameter can hold a plaintext configuration value or an encrypted one, and an application asking for an encrypted parameter has its IAM permissions checked and the value decrypted through KMS before it ever sees it.

There is no infrastructure to run, it scales, the data is durable and the SDK is straightforward. Every configuration value and secret is kept as versions, access is governed by IAM, changes can be announced through Amazon EventBridge, and CloudFormation can read from it.

Hierarchy

Parameters are organized as paths, which makes it natural to separate environments:

/my-department/
  my-app/
    dev/
      db-url
      db-password
    prod/
      db-url
      db-password
  other-app/
/other-department/

A dev Lambda function fetches /my-department/my-app/dev/ and a prod function fetches the prod branch, both using the GetParameters or GetParametersByPath API.

Two special paths are worth knowing:

• /aws/reference/secretsmanager/secret_ID_in_Secrets_Manager — reach a Secrets Manager secret through Parameter Store.
• /aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2 — a public parameter holding the latest Amazon Linux AMI id.

Standard and advanced tiers

	Standard	Advanced
Parameters allowed per account and region	10,000	100,000
Maximum size of a parameter value	4 KB	8 KB
Parameter policies available	No	Yes
Cost	No additional charge	$0.05 per advanced parameter per month

Parameter policies

Available only on advanced parameters, policies let you assign a TTL to a parameter so that sensitive data such as a password is forced to be updated or deleted. Several policies can apply at once:

• Expiration — delete the parameter at a given date.
• ExpirationNotification — notify through EventBridge ahead of expiry.
• NoChangeNotification — notify through EventBridge if the parameter has not changed within a period.

9. AWS Secrets Manager

Secrets Manager is the newer service, purpose-built for secrets. Its distinguishing feature is the ability to force rotation of a secret every X days, and to generate the new secret automatically on rotation using a Lambda function. It integrates with Amazon RDS for MySQL, PostgreSQL and Aurora, and that RDS integration is mostly what it is meant for. Secrets are encrypted using KMS.

Multi-region secrets

A secret can be replicated across multiple AWS Regions. Secrets Manager keeps the read replicas in sync with the primary, and a read replica can be promoted to a standalone secret. The use cases are multi-region applications, disaster recovery strategies and multi-region databases.

Exam tip

Parameter Store and Secrets Manager overlap, but only Secrets Manager does automatic rotation with generated credentials and native RDS integration. If the question mentions rotating a database password automatically, it is Secrets Manager.

10. AWS Certificate Manager (ACM)

ACM exists to take the pain out of provisioning TLS certificates, keeping them current and getting them onto the things that serve traffic — which is what gives a website in-flight encryption over HTTPS. Both public and private TLS certificates are supported, the public ones cost nothing, and ACM renews certificates automatically.

Certificates can be loaded onto Elastic Load Balancers (CLB, ALB, NLB), CloudFront distributions and APIs on API Gateway. ACM cannot be used with EC2, because the certificate cannot be extracted from ACM and installed on an instance.

A typical layout puts an Application Load Balancer in front of an Auto Scaling group: clients speak HTTPS to the ALB using the certificate ACM provisions and maintains, and the ALB speaks plain HTTP to the instances behind it. The ALB can also carry an HTTP-to-HTTPS redirect rule, so an HTTP request is sent back to HTTPS rather than served.

Requesting a public certificate

1. List the domain names to include — a fully qualified domain name such as corp.example.com, or a wildcard domain such as *.example.com.
2. Choose a validation method: DNS validation or email validation. DNS validation is preferred because it can be automated, and works by adding a CNAME record to your DNS configuration, for example in Route 53. Email validation sends messages to the contact addresses in the WHOIS database.
3. Verification takes a few hours.
4. The public certificate is enrolled for automatic renewal; ACM renews ACM-generated certificates 60 days before expiry.

Importing a public certificate

You can generate a certificate outside ACM and import it. There is then no automatic renewal — you must import a replacement before it expires. ACM sends daily expiration events starting 45 days prior to expiration, and that number of days is configurable; the events appear in EventBridge, where a rule can route them to Lambda, SNS or SQS. AWS Config also offers a managed rule named acm-certificate-expiration-check, with a configurable threshold, that flags certificates approaching expiry.

API Gateway endpoint types

Where the certificate must live depends on the API Gateway endpoint type, so the two topics have to be learnt together.

Endpoint type	Who it is for	Certificate requirement
Edge-Optimized (default)	Global clients; requests routed through CloudFront edge locations to improve latency, though the API itself still lives in one region	The TLS certificate must be in us-east-1, the same region as CloudFront
Regional	Clients in the same region; can be manually combined with CloudFront for more control over caching and distribution	The certificate must be imported on API Gateway in the same region as the API stage
Private	Only accessible from your VPC through an interface VPC endpoint (ENI); access defined with a resource policy	—

For both public types you create a custom domain name in API Gateway and then point a CNAME — or better, a Route 53 A-Alias record — at it.

11. AWS WAF — Web Application Firewall

WAF protects web applications from common web exploits at Layer 7, the HTTP layer, as opposed to Layer 4 which is TCP/UDP. It can be deployed on an Application Load Balancer, API Gateway, CloudFront, an AppSync GraphQL API and a Cognito User Pool.

You configure a Web ACL (Web Access Control List) made of rules:

• IP Set — up to 10,000 IP addresses per set; use multiple rules if you need more.
• Inspection of HTTP headers, HTTP body or URI strings, which is what protects against SQL injection and cross-site scripting.
• Size constraints and geo-match, for blocking countries.
• Rate-based rules that count occurrences of events, which is the DDoS-relevant one.

Web ACLs are regional, except for CloudFront. A rule group is a reusable set of rules you can add to a Web ACL.

Exam tip

WAF does not support the Network Load Balancer, because the NLB is Layer 4. If you need both a fixed IP address and WAF, put Global Accelerator in front for the fixed IPv4 address and attach the Web ACL to an ALB behind it. The Web ACL must be in the same region as the ALB.

12. AWS Shield — DDoS protection

A distributed denial of service attack floods your application with requests from many sources at once. Shield comes in two tiers:

• AWS Shield Standard is free and activated for every AWS customer. It protects against attacks such as SYN and UDP floods, reflection attacks and other layer 3 and layer 4 attacks.
• AWS Shield Advanced is an optional service at $3,000 per month per organization. It protects against more sophisticated attacks on Amazon EC2, Elastic Load Balancing, CloudFront, Global Accelerator and Route 53; gives 24/7 access to the AWS DDoS response team; protects you against the higher bills caused by a DDoS-driven usage spike; and its automatic application layer DDoS mitigation creates, evaluates and deploys WAF rules on your behalf to mitigate layer 7 attacks.

13. AWS Firewall Manager

Firewall Manager manages security rules across all the accounts of an AWS Organization. You define a security policy — a common set of security rules — covering:

• WAF rules for Application Load Balancers, API Gateways and CloudFront;
• AWS Shield Advanced for ALB, CLB, NLB, Elastic IP and CloudFront;
• Security Groups for EC2, Application Load Balancer and ENI resources in a VPC;
• AWS Network Firewall at the VPC level;
• Amazon Route 53 Resolver DNS Firewall.

Policies are created at the region level, and the rules are applied to new resources as they are created, across all current and future accounts in the organization — which is precisely what makes it a compliance tool.

Choosing between WAF, Firewall Manager and Shield

The three are meant to be used together for comprehensive protection:

• WAF is where the Web ACL rules themselves get written. When the protection you need is granular — this resource, these rules — WAF on its own is the right answer and the other two add nothing.
• Reach for Firewall Manager alongside WAF once the question becomes organizational: WAF spanning several accounts, WAF configuration rolled out faster than by hand, or new resources picking up protection without anyone remembering to attach it.
• Shield Advanced sits on top of WAF and brings extras WAF does not have, notably the dedicated support of the Shield Response Team (SRT) and advanced reporting. Being attacked often is the reason to pay for it.

14. Best practices for DDoS resiliency

The practices fall into four themes, each tagged with best-practice numbers.

Mitigation at the edge (BP1, BP3)

• CloudFront (BP1) delivers the web application from the edge and protects against common DDoS attacks such as SYN floods and UDP reflection.
• Global Accelerator (BP1) lets users reach your application from the edge and integrates with Shield for DDoS protection. It is the answer when your backend is not compatible with CloudFront.
• Route 53 (BP3) resolves domain names at the edge and has its own DDoS protection mechanism.

Infrastructure layer defence (BP1, BP3, BP6)

Protect EC2 against high traffic by fronting it with Global Accelerator, Route 53, CloudFront and Elastic Load Balancing. EC2 with Auto Scaling (BP7) handles sudden surges, whether a flash crowd or an attack, and Elastic Load Balancing (BP6) scales with the traffic and spreads it across many instances.

Application layer defence (BP1, BP2, BP6)

Detect and filter malicious web requests: CloudFront caches static content and serves it from edge locations, shielding the backend; AWS WAF on top of CloudFront and the Application Load Balancer blocks requests by signature; rate-based rules automatically block the IPs of bad actors; managed rules block attacks based on IP reputation or block anonymous IPs; and CloudFront can block specific geographies. Shield Advanced contributes its automatic application layer mitigation, generating WAF rules to counter layer 7 attacks.

Reducing the attack surface (BP1, BP4, BP5, BP6)

• Obfuscate your resources by fronting Lambda functions and EC2 instances with CloudFront, API Gateway or Elastic Load Balancing.
• Security groups and NACLs (BP5) filter traffic by IP at the subnet or ENI level; Elastic IPs are protected by Shield Advanced.
• Protect API endpoints (BP4) by hiding EC2 and Lambda behind API Gateway, using edge-optimized mode or CloudFront with regional mode for more DDoS control, and combining WAF with API Gateway burst limits, header filtering and API keys.

15. Amazon GuardDuty

GuardDuty is intelligent threat discovery for your AWS account. It uses machine learning algorithms, anomaly detection and third-party data, is enabled with one click (with a 30-day trial) and requires no software installation.

Its input data is:

• CloudTrail event logs — unusual API calls, unauthorised deployments;
• CloudTrail management events — creating a VPC subnet, creating a trail;
• CloudTrail S3 data events — GetObject, ListObjects, DeleteObject;
• VPC Flow Logs — unusual internal traffic, unusual IP addresses;
• DNS logs — compromised EC2 instances exfiltrating encoded data inside DNS queries;
• optional features — EKS audit logs and runtime monitoring, RDS and Aurora login activity, EBS volumes, Lambda network activity, S3 data events.

Findings can trigger EventBridge rules targeting Lambda or SNS. GuardDuty also has a dedicated finding for cryptocurrency attacks.

16. Amazon Inspector

Inspector runs automated security assessments on three things and three things only:

• EC2 instances, using the AWS Systems Manager (SSM) agent, analyzing for unintended network accessibility and checking the running operating system against known vulnerabilities.
• Container images pushed to Amazon ECR, assessed as they are pushed.
• Lambda functions, identifying software vulnerabilities in the function code and its package dependencies, assessed as the functions are deployed.

Inspector scans continuously, but only when needed. It checks package vulnerabilities against a database of CVEs for EC2, ECR and Lambda, and network reachability for EC2. Every vulnerability carries a risk score so you can prioritize. Results are reported into AWS Security Hub and sent to Amazon EventBridge.

Exam tip

Do not let Inspector’s scope drift in your memory: EC2 instances, ECR container images and Lambda functions. It does not scan S3 buckets, databases or network configuration outside EC2 reachability.

17. AWS Macie

Macie is a managed service — nothing to run — whose job is data security and data privacy: it leans on machine learning and pattern matching to find the sensitive data you hold in AWS and help you protect it. In practice that means it analyzes S3 buckets, identifies and flags sensitive data such as personally identifiable information (PII), and notifies you through Amazon EventBridge, from which the finding can travel on to your other integrations.

Real-world example

A company must prove that no customer records containing PII have ended up in a public analytics bucket. Macie scans the bucket, flags the objects containing PII and raises an EventBridge event that triggers a Lambda function to quarantine them and notify the security team.

Quick recap

Item	What to remember for the exam
Three encryption models	In flight (TLS, stops MITM); server-side at rest (server holds the key); client-side (server can never decrypt, often envelope encryption)
KMS key algorithms	Symmetric AES-256 for AWS service integration, key material never exposed; asymmetric RSA/ECC for encrypt-decrypt or sign-verify, public key downloadable, for users outside AWS
KMS key ownership	AWS Owned and AWS Managed are free; customer managed, created or imported, cost $1 per month, plus $0.03 per 10,000 API calls
Key rotation	AWS-managed rotates yearly automatically; customer-managed rotates automatically once enabled plus on demand; imported keys only rotate manually via alias
Key policies	Mandatory — without one there is no access; default policy gives the root user full access; a custom policy is required for cross-account use
Snapshot copies	Cross-region copy triggers a ReEncrypt with the destination key; cross-account needs a customer managed key, a key policy allowing the target, then copy and re-encrypt in the target account
Multi-Region Keys	Same key ID and key material across regions, primary plus replicas, managed independently, not global; encrypt in one region and decrypt in another with no cross-region calls
S3 Replication	Unencrypted and SSE-S3 replicate by default; SSE-C can replicate; SSE-KMS must be enabled with a target key, adapted key policy and an IAM role with kms:Decrypt and kms:Encrypt; watch for KMS throttling; multi-region keys are treated as independent
Encrypted AMI sharing	Add a launch permission for the target account, share the KMS key, grant DescribeKey, ReEncrypt*, CreateGrant and Decrypt
SSM Parameter Store	Hierarchical paths, versioning, optional KMS encryption, IAM security, EventBridge notifications; standard tier 10,000 parameters and 4 KB, advanced tier 100,000 and 8 KB with parameter policies (TTL, expiration and change notifications)
Secrets Manager	Forced rotation every X days with Lambda-generated secrets, native RDS/Aurora integration, KMS encryption, multi-region replicas that can be promoted
ACM	Free public certificates with automatic renewal 60 days before expiry; DNS validation preferred over email; works with CLB/ALB/NLB, CloudFront and API Gateway, not EC2; imported certificates do not auto-renew and raise daily expiry events from 45 days out
API Gateway endpoints	Edge-optimized needs the certificate in us-east-1; regional needs it in the stage’s region; private is reached through an interface VPC endpoint with a resource policy
WAF	Layer 7, on ALB, API Gateway, CloudFront, AppSync and Cognito User Pools; IP sets up to 10,000 addresses; SQL injection, XSS, size, geo-match and rate-based rules; regional except CloudFront; no NLB support, so use Global Accelerator for a fixed IP
Shield	Standard is free for everyone against layer 3/4 attacks; Advanced costs $3,000 per month, covers EC2, ELB, CloudFront, Global Accelerator and Route 53, adds the DDoS response team, cost protection and automatic layer 7 mitigation
Firewall Manager	Organization-wide security policies for WAF, Shield Advanced, security groups, Network Firewall and Route 53 Resolver DNS Firewall; region-level policies applied to new resources automatically
GuardDuty	Threat detection from CloudTrail events and management/S3 data events, VPC Flow Logs and DNS logs, with optional EKS, RDS, EBS, Lambda and S3 sources; findings to EventBridge, Lambda or SNS; dedicated cryptocurrency finding
Inspector	Only EC2 (via SSM agent), ECR container images and Lambda functions; CVE package vulnerabilities plus EC2 network reachability; risk scores; reports to Security Hub and EventBridge
Macie	Machine learning and pattern matching over S3 to discover PII and other sensitive data, alerting through EventBridge