Day 22 covered how you observe and audit your environment. Today closes out the original 11-day service tour with the layer that actually protects it: encryption, secrets, backups, and the two services that guard the request path itself against attack. This is deliberately the last stop before we move into the extended set of services, since security genuinely underpins everything covered in the previous 10 days.
Encryption: In Transit vs At Rest
There are two fundamentally different moments where data needs protecting, and AWS treats them as separate problems with separate tools.
Encryption in transit protects data while it's traveling — between a user's browser and your server, or between two AWS services. This is what HTTPS provides, and in AWS, ACM (AWS Certificate Manager) is the service that makes HTTPS practical at scale: it issues free SSL/TLS certificates and, critically, handles automatic renewal — no more manually renewing a certificate every year and forgetting until it expires in production. ACM integrates directly with ELB, CloudFront, and API Gateway, so you attach a certificate to one of those and traffic is encrypted end-to-end without you managing certificate files by hand.
Encryption at rest protects data while it's sitting still — on a disk, in a database, in a backup. This relies on encryption keys, and KMS (Key Management Service) is where AWS manages the creation and lifecycle of those keys. KMS integrates with most storage and database services (S3, EBS, RDS, DynamoDB, and more) — when you enable encryption on a resource, you're almost always pointing it at a KMS key behind the scenes. AWS-managed keys are the default and require no setup, while customer-managed keys give you more control — you can define who's allowed to use the key, rotate it on a schedule (KMS supports automatic annual rotation for customer-managed keys), and revoke access entirely if needed. This is genuinely one of the most consequential security defaults in AWS: enabling encryption at rest on a resource costs almost nothing in setup effort, and skipping it is one of the most common, avoidable security gaps in real deployments.
AWS Secrets Manager
Secrets Manager exists to store secrets — database credentials, API keys, and other sensitive values — rather than the extremely common (and extremely risky) alternative of hardcoding them directly into application code or configuration files.
Beyond just storage, its standout feature is automatic rotation: Secrets Manager can rotate a database password on a schedule (say, every 30 days) by invoking a Lambda function that updates both the secret's value and the actual database credential in sync, so your application never has to be manually updated when a credential changes — it just fetches the current secret at runtime. This closes a real operational gap: rotating credentials manually is tedious enough that many teams simply never do it, which means a leaked credential from years ago can still be valid.
Worth knowing: AWS Systems Manager Parameter Store solves a similar problem for configuration values and secrets, and is cheaper (with a free tier), but doesn't offer Secrets Manager's built-in automatic rotation out of the box. Parameter Store tends to be the choice for general configuration and infrequently-changing secrets; Secrets Manager is the choice specifically when automatic rotation matters, like production database credentials.
AWS Backup
AWS Backup centrally manages and automates backups — instead of configuring backup schedules separately for EBS, RDS, DynamoDB, EFS, and every other service that needs one, you define a backup plan once (how often to back up, how long to retain each backup) and apply it across multiple resource types and services from a single place.
This matters more than it might sound like at first: without a centralized approach, backup configuration tends to drift — someone sets up EBS snapshots but forgets DynamoDB, or retention policies end up inconsistent across services because they were each configured separately, at different times, by different people. AWS Backup also supports cross-region and cross-account backup copies, which is important for disaster recovery scenarios where you specifically don't want your only backup living in the same Region (or even the same account) as the resource it's backing up — if that Region or account has a serious problem, you don't want your backup to be affected by the exact same problem.
AWS WAF (Web Application Firewall)
WAF protects web applications from common web exploits — it sits in front of your application (attached to an ALB, CloudFront distribution, or API Gateway) and inspects incoming HTTP/HTTPS requests before they reach your actual application.
What it actually filters for: AWS provides managed rule groups that catch well-known attack patterns without you having to write detection logic yourself — things like SQL injection attempts, cross-site scripting (XSS), and known bad IP addresses or bot signatures. You can also write custom rules, including rate-based rules that automatically block an IP address making an abnormally high number of requests in a short window — a simple but effective defense against both brute-force login attempts and certain denial-of-service patterns. WAF operates at the application layer (Layer 7), meaning it actually understands HTTP requests — headers, query strings, request bodies — rather than just raw network packets, which is what lets it catch attacks that live inside the content of a request rather than just its source or volume.
AWS Shield
Shield is a managed DDoS (Distributed Denial of Service) protection service — it defends against attacks designed to overwhelm your infrastructure with sheer volume of traffic rather than exploiting a specific vulnerability in your application code.
Shield Standard is automatically enabled on every AWS account at no additional cost, providing protection against the most common, frequently occurring network and transport layer (Layer 3/4) DDoS attacks. Shield Advanced is a paid tier that adds protection against larger, more sophisticated attacks, near real-time visibility into attacks as they happen, and — notably — access to the AWS DDoS Response Team (DRT) for direct help during an active attack, plus cost protection, which credits back the charges you'd otherwise incur from the scaling that an attack triggers (since a DDoS attack driving up your Auto Scaling Group could otherwise leave you with a legitimate-looking but attack-caused bill).
How they fit together
Together, these five form layered protection around two different things: encryption, Secrets Manager, and Backup protect your data — whether it's moving, sitting still, being authenticated against, or being recovered after something goes wrong — while WAF and Shield protect the request path itself, filtering out malicious or overwhelming traffic before it ever reaches your application. Neither layer substitutes for the other: airtight encryption doesn't stop a DDoS attack, and DDoS protection doesn't stop an unencrypted database from leaking data if someone gets unauthorized access to it.
Quick Recap Questions
- What's the practical difference between what ACM protects and what KMS protects?
- Why is automatic rotation such a meaningful feature in Secrets Manager, beyond just "storing secrets safely"?
- Why does AWS Backup's cross-region/cross-account capability matter specifically for disaster recovery?
- What's the difference between what WAF defends against and what Shield defends against?
Where to read & follow
- Hashnode: https://sr-palatasingh.hashnode.dev/series/aws-devops-blog
- GitHub: https://github.com/sr-palatasingh/AWS-DevOps-Blog/tree/main/posts
- LinkedIn: https://www.linkedin.com/in/soumyaranjan-palatasingh/
Coming up next
| Day | Topic | Services |
|---|---|---|
| 24 | Database — Extended | QLDB, Neptune |
Top comments (0)