AWS Security and Encryption - KMS, Secrets Manager, WAF, Shield, GuardDuty

Overview and What You Will Learn

Encryption and secrets are the layer most teams get wrong first, and the layer attackers go after first. This topic covers the full defense stack AWS gives you for protecting data and detecting threats:

• AWS KMS — how encryption keys actually work in AWS, and the difference between AWS Owned, AWS Managed, and Customer Managed Keys
• SSM Parameter Store vs Secrets Manager — which one to use for config values vs credentials that need to rotate
• CloudHSM — dedicated hardware key management for strict compliance requirements
• ACM — free, auto-renewing TLS certificates and where they can (and can't) be attached
• WAF and Shield — Layer 7 application firewalling and DDoS protection
• GuardDuty, Inspector, and Macie — the three AWS threat-detection services and when each one fires

By the end you'll be able to pick the right encryption/secrets service for a given workload, wire up certificate and DDoS protection correctly, and know what each detection service actually catches versus what it doesn't.

Why This Matters in Production

In January 2025, a ransomware group called Codefinger started targeting AWS accounts directly — not through malware, but by abusing a legitimate S3 feature. Using stolen or leaked AWS credentials, the attackers re-encrypted victims' S3 objects with SSE-C (server-side encryption with a customer-supplied key), generating that key themselves and never handing it to AWS. Because S3 stores only verification material for an SSE-C key, not the key itself, once the attacker held the only working copy, recovery was impossible without paying for it. They then set the encrypted files to auto-delete within seven days to pressure victims into paying.

No AWS vulnerability was exploited — the entire attack relied on obtaining valid account credentials and using AWS's own encryption feature against the account owner. It's a clean example of why "we use encryption" means nothing on its own: who controls the key is the actual security boundary. AWS's response was structural — as of April 2026, SSE-C is now disabled by default on new general-purpose S3 buckets and a set of existing ones, though it can still be explicitly re-enabled, so knowing this history matters even if you never touch SSE-C directly.

This is exactly the mindset this topic builds: KMS, Secrets Manager, WAF, Shield, and GuardDuty aren't a checklist to enable once — they're a set of decisions about who can hold, use, and rotate the keys that protect your data, and how fast you'd notice if that control slipped.

AWS KMS — Key Management Service

KMS is the encryption backbone almost every other AWS service quietly depends on. Every encrypted S3 object, every encrypted EBS volume, every encrypted RDS database, and every secret in Secrets Manager ultimately depends on a KMS key. If you understand KMS, most of AWS's "encryption at rest" story falls into place; if a KMS key is misconfigured or compromised, that same dependency chain becomes the attacker's shortcut.

What KMS actually manages:

Key types in KMS:

Remember

the deciding question is almost always "do I need to share this key across accounts, or control its policy myself?" If yes → Customer Managed Key. If no, and you just want encryption on by default → the AWS Managed Key is free and sufficient. Secrets Manager itself recommends the AWS managed key aws/secretsmanager for most cases since there's no cost to using it, and reserves a customer managed key for when you need cross-account access or a custom key policy.

Encryption models KMS supports:

KMS supports symmetric, asymmetric, and envelope encryption models. In practice on AWS you'll mostly interact with symmetric CMKs (used by S3, EBS, Secrets Manager, SSM SecureString) and envelope encryption (a data key encrypts your actual data, and that data key is itself encrypted by your KMS key — this is what happens under the hood every time you enable SSE-KMS on S3).

Key rotation:

Enable automatic annual rotation on every Customer Managed Key you create. Rotation doesn't re-encrypt existing data — KMS keeps old key material available to decrypt anything encrypted under it, while new encryption operations use the fresh key material. This limits how much is exposed if a key is ever compromised, without breaking anything already encrypted.

A real, current attack path to know — Codefinger and SSE-C:

The Codefinger campaign above is the reason security teams now explicitly call out SSE-C as a risk. The fix is to restrict SSE-C usage via IAM policy so it can't be used unless explicitly required, keep encryption keys centralized in KMS instead, and use Service Control Policies to limit which users and applications can perform cryptographic operations at all. Since Codefinger, many organizations have restricted or blocked SSE-C entirely — if your account doesn't have a deliberate reason to use SSE-C, don't leave it available.

Security

if you ever see a KMS key scheduled for deletion that you didn't schedule, or S3 objects suddenly encrypted with an algorithm your team doesn't use, treat it as an active incident, not a configuration drift — both are consistent with a credential-compromise ransomware pattern, not an accident.

AWS SSM Parameter Store

SSM Parameter Store is the free, simple option for storing configuration values and secrets as key-value pairs, part of AWS Systems Manager.

Parameter types:

Standard vs Advanced tier:

Parameter policies (Advanced tier only) let you attach expiration and notification behavior directly to a parameter:

AWS Secrets Manager

A newer service specifically built for storing and rotating secrets — database credentials, API keys, OAuth tokens. The key difference from SSM Parameter Store is built-in automatic rotation.

Your app always fetches the latest password from Secrets Manager. It never breaks because it never stores the password itself.

Multi-Region Secrets:

Replicate secrets across multiple AWS regions. Replica stays in sync with primary automatically. If primary region fails, promote replica to standalone secret.

SSM Parameter Store vs Secrets Manager:

Remember

The decision between SSM Parameter Store and Secrets Manager comes down to one question: does this secret need automatic rotation? If yes, use Secrets Manager. If no, SSM Parameter Store is free and sufficient.

CloudHSM — Dedicated Hardware Key Management

KMS is a software-managed service. CloudHSM provisions dedicated encryption hardware for you — an HSM (Hardware Security Module). You manage your own encryption keys entirely.

Key facts:

CloudHSM vs KMS:

Use CloudHSM when: FIPS 140-2 Level 3 compliance is required, your organisation needs to own and manage all key material with zero AWS involvement, regulatory requirements mandate dedicated hardware.

AWS Certificate Manager (ACM)

ACM provisions, manages, and auto-renews TLS certificates for HTTPS. Public certificates are free.

Where ACM certificates can be used:

Common Mistake

ACM certificates cannot be used directly with EC2 instances. The certificate cannot be extracted from ACM and installed manually. Use ACM only with the supported services above.

DNS Validation (preferred):

Import your own certificate:

Edge-Optimized API Gateway certificate rule:

Remember

Edge-Optimized API Gateway uses CloudFront under the hood. All CloudFront certificates must be in us-east-1 globally. If your certificate is in ap-south-1 and your API is Edge-Optimized, it will not work.

AWS WAF — Web Application Firewall

WAF protects web applications from attacks at Layer 7 (HTTP/HTTPS). It evaluates each request against rules you define — allow, block, or count.

Where WAF can be attached:

WAF cannot attach to NLB — NLB operates at Layer 4, WAF requires Layer 7.

Web ACL rule types:

Fixed IP with WAF + ALB:

ALB does not have a static IP — its IPs can change. When clients or firewalls need to whitelist a fixed IP, use Global Accelerator in front of ALB.

WAF Web ACL must be in the same region as the ALB. Global Accelerator provides the fixed IP.

AWS Shield — DDoS Protection

Shield Standard (free, automatic):

Shield Advanced ($3,000/month per organisation):

When Shield Advanced is worth it:

Threat Detection — GuardDuty, Inspector, Macie

Amazon GuardDuty — runtime threat detection:

Monitors your account continuously using ML and threat intelligence. One click to enable. No agents.

GuardDuty generates findings. Connect findings to EventBridge to trigger SNS alerts or Lambda automated responses. GuardDuty detects — it does not block.

Amazon Inspector — vulnerability scanning:

Automated security assessments for EC2, container images in ECR, and Lambda functions.

Inspector performs continuous scanning — re-scans automatically when changes happen. Every finding gets a risk score for prioritisation. Findings go to EventBridge and Security Hub.

GuardDuty vs Inspector:

Amazon Macie — sensitive data classification:

Discovers, classifies, and protects sensitive data in S3. Uses ML and pattern matching to find PII, financial data, and confidential business information.

Real example at an Indian fintech: a developer accidentally uploads a file containing customer KYC data to an S3 bucket. Macie detects PAN card and Aadhaar number patterns, generates an alert, fires an EventBridge event, and Lambda restricts bucket access automatically.

Hands-on Lab — KMS, Secrets Manager, and GuardDuty

Step 1 — Create a Customer Managed KMS Key

Step 2 — Create a secret in Secrets Manager

Step 3 — Retrieve the secret from application code

Step 4 — Store config values in SSM Parameter Store

Step 5 — Enable GuardDuty

Step 6 — Cleanup

Production Best Practices and Common Pitfalls

• Enable GuardDuty in every AWS account and every region from day one — it is one click and the cost is minimal compared to the cost of a breach
• Use Secrets Manager for any credential that needs rotation — SSM Parameter Store has no built-in rotation
• Enable KMS key rotation on all Customer Managed Keys — rotating keys limits the exposure window if a key is ever compromised
• Use KMS CMKs for cross-account encrypted snapshot sharing — AWS Managed Keys cannot be shared
• Never put API keys or database passwords in Lambda environment variables — use Secrets Manager and retrieve at initialisation
• Set up ACM expiry alerts with EventBridge on day one for imported certificates — ACM does not auto-renew imported certs
• Use WAF rate-based rules on all public-facing APIs — basic DDoS and brute-force protection at minimal cost
• Enable Macie on buckets containing PII or financial data — the first data classification run often finds data in places teams did not expect
• Restrict or deny SSE-C on S3 buckets unless you have a specific, documented reason to use it — this closes the exact path the Codefinger ransomware campaign used

Quick Reference and Troubleshooting Commands

Common problems and fixes:

Common Mistake

Using SSM Parameter Store Standard tier for database passwords that need rotation. SSM has no built-in rotation. You would need to write your own rotation Lambda, schedule it, update RDS manually, and store the new value. Secrets Manager handles all of this natively. Use Secrets Manager for any credential that must rotate automatically.

Security

GuardDuty generates findings but does not block anything. It detects — your response infrastructure must block. Wire GuardDuty findings to EventBridge → Lambda that automatically adds the offending IP to a WAF IP block list or a NACL deny rule. Detection without automated response is incomplete security.

Tip

Run Macie on all S3 buckets at least once after initial setup. Teams are consistently surprised by what Macie finds — developer test data containing real customer records, legacy files with unmasked payment information, backup files with credentials. The first scan is almost always the most valuable.