A comprehensive guide where Maya (Security Expert) helps Alex (Software Engineer) navigate the AWS security landscape
Table of Contents
- Introduction: The Security Conversation Begins
- The Big Picture: Security Layers in AWS
- Identity & Access Management (IAM)
-
Network Security Services
- AWS WAF & Shield
- VPC Security Groups & NACLs
-
Threat Detection & Monitoring
- Amazon GuardDuty
- AWS Security Hub
- Amazon Detective
-
Compliance & Configuration
- AWS Config
- AWS CloudTrail
-
Data Protection Services
- AWS KMS
- AWS Secrets Manager
- Amazon Macie
-
Application Security
- Amazon Inspector
- Amazon Cognito
- How They All Work Together
- Service Summary Reference
AWS Security Services by OSI Layer
| OSI Layer | Layer Name | AWS Security Services | Primary Function |
|---|---|---|---|
| Layer 7 | Application | • AWS WAF • AWS Shield Advanced • Amazon CloudFront • API Gateway • Amazon Cognito • Amazon Macie • AWS GuardDuty |
• Web application firewall • DDoS protection (application layer) • Content filtering • API authentication/authorization • Identity management • Data discovery and protection • Threat detection |
| Layer 6 | Presentation | • AWS Certificate Manager (ACM) • AWS KMS • AWS CloudHSM |
• SSL/TLS certificate management • Encryption key management • Hardware security module • Data encryption/decryption |
| Layer 5 | Session | • AWS IAM • AWS STS • AWS Secrets Manager • Amazon Cognito |
• Session management • Temporary credentials • Secret rotation • User session handling |
| Layer 4 | Transport | • Network Load Balancer (NLB) • AWS Shield Standard • AWS Network Firewall • Security Groups (stateful) |
• TCP/UDP traffic filtering • DDoS protection (transport layer) • Port-based filtering • Connection tracking |
| Layer 3 | Network | • Security Groups • Network ACLs (NACLs) • AWS Network Firewall • Route 53 Resolver DNS Firewall • AWS Transit Gateway • VPC Flow Logs |
• IP packet filtering • Subnet-level security • Routing control • DNS filtering • Network segmentation • Traffic monitoring |
| Layer 2 | Data Link | • AWS PrivateLink • VPC Peering • Elastic Network Interface (ENI) |
• Private connectivity • MAC-level isolation • Virtual network interfaces |
| Layer 1 | Physical | • AWS Direct Connect (with MACsec) • AWS Managed Infrastructure |
• Physical link encryption • Dedicated network connections • Physical security (AWS responsibility) |
Additional Cross-Layer Security Services
| Service | Description |
|---|---|
| AWS Security Hub | Centralized security findings across all layers |
| Amazon Inspector | Vulnerability scanning (Layers 3-7) |
| AWS Config | Configuration compliance across all layers |
| AWS CloudTrail | API activity logging across all services |
| Amazon Detective | Security investigation across multiple layers |
Note: Many AWS services operate across multiple OSI layers. This table categorizes them by their primary security function.
Introduction: The Security Conversation Begins
Alex: Hey Maya! I've been tasked with improving our application's security posture on AWS, and honestly, I'm overwhelmed. There are so many security services! Where do I even start?
Maya: laughs I hear that a lot! AWS security can feel like alphabet soup at first - IAM, WAF, KMS, GuardDuty... But here's the thing: each service has a specific purpose, and they're actually designed to work together like puzzle pieces.
Alex: That's reassuring. Can we start with the big picture? Like, which service does what?
Maya: Absolutely! That's the best place to start. Let me grab my coffee, and we'll walk through this together.
The Big Picture: Security Layers in AWS
Maya: Think of AWS security services as layers of protection, kind of like security in a building. You have:
- The front gate (network security)
- ID badges (identity and access)
- Security cameras (monitoring and detection)
- Locks on sensitive doors (data protection)
- Security audit logs (compliance and logging)
Let me show you a quick breakdown:
┌─────────────────────────────────────────────────────────────┐
│ AWS SECURITY LAYERS │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌───────────────────────────────────────────────────┐ │
│ │ Identity & Access: IAM, Organizations, Cognito │ │
│ └───────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌───────────────────────────────────────────────────┐ │
│ │ Network Security: WAF, Shield, Security Groups │ │
│ └───────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌───────────────────────────────────────────────────┐ │
│ │ Threat Detection: GuardDuty, Security Hub, │ │
│ │ Detective │ │
│ └───────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌───────────────────────────────────────────────────┐ │
│ │ Data Protection: KMS, Secrets Manager, Macie │ │
│ └───────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌───────────────────────────────────────────────────┐ │
│ │ Compliance & Audit: Config, CloudTrail │ │
│ └───────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
Alex: Okay, that's already much clearer! So it's not about picking one service, but using multiple services for different security needs?
Maya: Exactly! And the beauty is that they integrate with each other. For example, GuardDuty can send findings to Security Hub, which can trigger automated responses. But let's not get ahead of ourselves. Let's go layer by layer.
Identity & Access Management (IAM)
Alex: Alright, let's start with the first layer. I use IAM every day, but I feel like I might be missing some best practices.
Maya: IAM is your foundation - literally everything in AWS security starts here. Think of it as your master key system. Let me break down the key components:
| IAM Component | What It Is | When to Use It |
|---|---|---|
| Users | Individual identities for people | Rarely! Prefer federation or IAM Identity Center |
| Groups | Collections of users | When you need to manage permissions for multiple IAM users |
| Roles | Temporary credentials for services/apps | Most of the time! EC2, Lambda, ECS should use roles |
| Policies | JSON documents defining permissions | Always - attached to users, groups, or roles |
| Identity Center | SSO solution (formerly AWS SSO) | For employee access across multiple accounts |
Alex: Wait, you said "rarely" for IAM users? I thought that was the standard way?
Maya: Common misconception! Here's the modern approach:
OLD WAY (❌):
Developer → IAM User with Long-term Credentials → AWS Resources
NEW WAY (✅):
Developer → Identity Center/Federation → Temporary Credentials → AWS Resources
Application → IAM Role → AWS Resources
Maya: Long-term credentials are security risks. They can be leaked, they don't expire, and they're hard to rotate. Roles provide temporary credentials that automatically rotate.
Alex: That makes sense. What about policies? I always struggle with those JSON documents.
Maya: Let me show you the anatomy of a policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": "arn:aws:s3:::my-bucket/*",
"Condition": {
"IpAddress": {
"aws:SourceIp": "203.0.113.0/24"
}
}
}
]
}
Maya: The key parts are:
- Effect: Allow or Deny
- Action: What operations are permitted
- Resource: Which AWS resources this applies to
- Condition: Optional - when this policy applies
Alex: And there's like a hierarchy of denies and allows, right?
Maya: Yes! Remember this rule: Explicit Deny → Explicit Allow → Default Deny
- If there's an explicit DENY anywhere, access is denied (game over)
- If there's an explicit ALLOW and no deny, access is granted
- If there's nothing, access is denied by default
Key IAM Best Practices:
✅ Enable MFA for all human access
✅ Use roles instead of long-term credentials
✅ Follow principle of least privilege
✅ Use policy conditions to restrict access (IP, time, MFA)
✅ Regularly audit permissions with IAM Access Analyzer
✅ Use service control policies (SCPs) in Organizations for guardrails
Alex: IAM Access Analyzer? What's that?
Maya: Great question! It's a tool that analyzes your resources to find which ones are shared with external entities. It helps you answer: "Did I accidentally make my S3 bucket public?" or "Who has access to this KMS key?"
Network Security Services
Alex: Okay, IAM makes more sense now. What about network security? We have a web application that faces the internet.
Maya: Perfect use case! Let's talk about your network defense layer. You've got several tools here:
AWS WAF (Web Application Firewall) & Shield
Maya: Think of WAF as a bouncer at your application's front door, inspecting HTTP/HTTPS requests.
Internet Users
↓
┌─────────────────┐
│ AWS Shield │ ← DDoS Protection (Layer 3/4)
└─────────────────┘
↓
┌─────────────────┐
│ AWS WAF │ ← Application Layer Protection (Layer 7)
└─────────────────┘
↓
┌─────────────────┐
│ CloudFront/ALB │
│ API Gateway │
└─────────────────┘
↓
Your Application
Alex: What's the difference between WAF and Shield?
Maya: Great question!
| Feature | AWS Shield Standard | AWS Shield Advanced | AWS WAF |
|---|---|---|---|
| Cost | Free | $3,000/month | Pay per rule + requests |
| Protection | Layer 3/4 DDoS | Enhanced DDoS + cost protection | Layer 7 filtering |
| What It Blocks | Network/transport attacks | Large-scale DDoS | SQL injection, XSS, bot traffic, rate limiting |
| Automatic | Yes | Yes + DDoS Response Team | No, you configure rules |
Alex: So Shield is automatic, and WAF is customizable?
Maya: Exactly! Shield Standard is automatically enabled on all AWS accounts - it protects against common DDoS attacks. Shield Advanced is for enterprise protection with 24/7 support.
WAF is where you define rules. Let me show you some common use cases:
Common WAF Rules:
├── Rate Limiting
│ └── Block IPs making >2000 requests in 5 minutes
├── Geo Blocking
│ └── Block traffic from specific countries
├── SQL Injection Protection
│ └── Inspect query strings for malicious SQL
├── XSS Protection
│ └── Block cross-site scripting attempts
├── IP Reputation Lists
│ └── Block known malicious IPs
└── Bot Control
└── Distinguish between good bots and bad bots
Alex: Can you give me a practical example?
Maya: Sure! Here's a real-world scenario:
Problem: E-commerce site getting hit with credential stuffing attacks
Solution:
- WAF Rule 1: Rate limiting - max 5 login attempts per IP in 5 minutes
- WAF Rule 2: Geo-blocking - site only serves US customers, block other countries
- WAF Rule 3: Bot control - allow Google/Bing bots, block others
- Shield Standard: Automatically protecting against network DDoS
Alex: That's practical! What about internal network security?
VPC Security Groups & Network ACLs
Maya: Now we're talking about security within your VPC. You have two main tools:
| Feature | Security Groups | Network ACLs (NACLs) |
|---|---|---|
| Level | Instance/ENI level | Subnet level |
| State | Stateful (return traffic auto-allowed) | Stateless (must allow both ways) |
| Rules | Allow rules only | Allow and Deny rules |
| Evaluation | All rules evaluated | Rules processed in order |
| Default | Deny all inbound, allow all outbound | Allow all traffic |
Alex: Stateful vs stateless - can you explain that?
Maya: Sure! Let's use an example:
Scenario: Web server receiving request on port 443
SECURITY GROUP (Stateful):
┌─────────────────────────────────────────┐
│ Inbound: Allow port 443 from 0.0.0.0/0 │
│ │
│ Outbound: (automatic) Return traffic │
│ allowed even if not explicitly │
│ defined │
└─────────────────────────────────────────┘
NACL (Stateless):
┌─────────────────────────────────────────┐
│ Inbound: Allow port 443 from 0.0.0.0/0 │
│ Outbound: Allow ephemeral ports │
│ (1024-65535) for return │
│ traffic - must be explicit! │
└─────────────────────────────────────────┘
Alex: So Security Groups are smarter because they track connections?
Maya: Exactly! That's why Security Groups are your primary control, and NACLs are your backup defense layer. Here's the best practice:
Security Group Strategy:
Internet (0.0.0.0/0)
↓
[ALB Security Group]
├── Allow: 443 from 0.0.0.0/0
└── Allow: 80 from 0.0.0.0/0 (redirect to 443)
↓
[Web Server Security Group]
├── Allow: 80 from ALB Security Group
└── Allow: 443 from ALB Security Group
↓
[Database Security Group]
└── Allow: 3306 from Web Server Security Group
Alex: I love that you can reference other security groups! So much cleaner than IP addresses.
Maya: Right! And it automatically adjusts when instances scale. If you add more web servers with that security group, the database automatically allows them.
Threat Detection & Monitoring
Alex: Okay, so we've locked things down with IAM and network security. But how do we know if someone's actually attacking us?
Maya: Now we're getting into the detective controls! This is where AWS really shines. Let's talk about the threat detection trio: GuardDuty, Security Hub, and Detective.
Amazon GuardDuty
Maya: GuardDuty is your 24/7 security guard. It continuously monitors for malicious activity and unauthorized behavior.
Alex: How does it work?
Maya: It analyzes billions of events from multiple data sources:
┌─────────────────────────────────────────────────────┐
│ AMAZON GUARDDUTY │
├─────────────────────────────────────────────────────┤
│ │
│ Data Sources: │
│ ├── VPC Flow Logs │
│ ├── CloudTrail Event Logs │
│ ├── DNS Logs │
│ ├── Kubernetes Audit Logs │
│ ├── S3 Data Events │
│ └── EBS Volume Data │
│ │
│ ↓ │
│ │
│ Machine Learning + Threat Intelligence │
│ │
│ ↓ │
│ │
│ Security Findings: │
│ ├── Reconnaissance (port scanning, unusual API) │
│ ├── Instance Compromise (malware, crypto mining) │
│ ├── Account Compromise (leaked credentials) │
│ ├── Bucket Compromise (suspicious S3 access) │
│ └── Malicious IP Communication │
│ │
└─────────────────────────────────────────────────────┘
Alex: So I don't need to configure log collection? It just works?
Maya: Exactly! That's the beauty. You enable it with one click (per region), and it starts analyzing. No agents to install, no logs to manage.
Real-World Finding Example:
Finding: Unauthorized API Call
Severity: HIGH
Description: EC2 instance i-1234567890abcdef0 is making API
calls with temporary credentials that don't match
the instance's assigned role.
Possible Causes:
- Instance may be compromised
- Stolen credentials being used
- Legitimate but misconfigured application
Recommended Action:
1. Isolate the instance (change security group)
2. Snapshot for forensics
3. Review CloudTrail logs for all actions taken
4. Rotate credentials
Alex: Those findings look really actionable. Can I automate responses?
Maya: Absolutely! That's where EventBridge comes in. Common pattern:
GuardDuty Finding
↓
EventBridge Rule
↓
[Choose your response]
├── SNS → Email security team
├── Lambda → Isolate compromised instance
├── Step Functions → Full remediation workflow
└── Security Hub → Aggregate with other findings
Alex: Wait, Security Hub? Is that different from GuardDuty?
AWS Security Hub
Maya: Yes! GuardDuty is specialized threat detection. Security Hub is your central security dashboard that aggregates findings from multiple services.
┌──────────────────────────────────────────────────────┐
│ AWS SECURITY HUB │
│ (Central Security Dashboard) │
├──────────────────────────────────────────────────────┤
│ │
│ Findings Sources: │
│ ├── GuardDuty (threat detection) │
│ ├── Inspector (vulnerability scanning) │
│ ├── Macie (sensitive data discovery) │
│ ├── IAM Access Analyzer │
│ ├── Firewall Manager │
│ ├── Detective │
│ └── 50+ Partner Integrations (Palo Alto, etc.) │
│ │
│ ──────────────────────────────────────────────── │
│ │
│ Security Standards Compliance: │
│ ├── CIS AWS Foundations Benchmark │
│ ├── PCI DSS │
│ ├── AWS Foundational Security Best Practices │
│ └── Custom compliance frameworks │
│ │
│ ──────────────────────────────────────────────── │
│ │
│ Outputs: │
│ ├── Unified dashboard │
│ ├── Automated remediation │
│ └── Cross-region aggregation │
│ │
└──────────────────────────────────────────────────────┘
Alex: So it's like a SIEM (Security Information and Event Management) tool?
Maya: Sort of! It's AWS's cloud-native SIEM. Instead of managing log collectors and correlation rules, you just enable it, and it starts giving you a comprehensive security score and actionable insights.
Example Security Hub Dashboard:
| Priority | Count | Category |
|---|---|---|
| 🔴 Critical | 3 | Publicly accessible RDS instance with weak password |
| 🟠 High | 15 | S3 buckets without encryption |
| 🟡 Medium | 42 | Security groups allowing 0.0.0.0/0 on non-standard ports |
| 🟢 Low | 127 | CloudTrail log validation not enabled |
Security Score: 67/100
Alex: That's really useful for getting a holistic view. What about when you need to investigate an incident deeper?
Amazon Detective
Maya: That's exactly what Detective is for! If GuardDuty says "this looks suspicious," Detective helps you answer "what actually happened?"
Investigation Timeline:
1. GuardDuty: "EC2 instance is communicating with known
malicious IP"
↓
2. Security Hub: Aggregates finding with context
↓
3. Detective: Open investigation
↓
Visualization shows:
├── Timeline: What happened before and after?
├── Resource interactions: What did this instance touch?
├── IP analysis: Where else has this IP been seen?
├── API call patterns: What API calls were unusual?
└── Related findings: Are other resources affected?
Maya: Detective uses machine learning to build a graph database of your AWS environment, making it easy to see relationships and patterns.
Alex: So the workflow is: GuardDuty detects → Security Hub aggregates → Detective investigates?
Maya: Perfect summary! Though you don't always need all three. But together, they're powerful.
Best Practices for Threat Detection:
| Service | Enable When | Cost Consideration |
|---|---|---|
| GuardDuty | Always! First line of defense | ~$5/month for small account, scales with usage |
| Security Hub | When you have multiple security tools | $0.001 per finding + compliance check costs |
| Detective | When you need investigation capabilities | $2/GB of data ingested |
Compliance & Configuration
Alex: This is great, but my manager keeps asking about compliance. We need to prove we're following security best practices.
Maya: Ah, the audit question! This is where Config and CloudTrail come in. Let me explain the difference - people often confuse them.
AWS CloudTrail
Maya: CloudTrail answers: "WHO did WHAT and WHEN?"
┌─────────────────────────────────────────┐
│ AWS CLOUDTRAIL │
│ (Audit Log of API Calls) │
├─────────────────────────────────────────┤
│ │
│ Records: │
│ ├── Who made the request? │
│ ├── When was it made? │
│ ├── What action was performed? │
│ ├── What resource was affected? │
│ ├── Where from (IP address)? │
│ └── Was it successful or denied? │
│ │
│ Example Log Entry: │
│ { │
│ "eventName": "PutBucketPublicAccess",│
│ "userIdentity": { │
│ "userName": "alex@company.com" │
│ }, │
│ "eventTime": "2024-01-15T10:30:00Z", │
│ "sourceIPAddress": "203.0.113.42", │
│ "requestParameters": { │
│ "bucketName": "my-app-data" │
│ } │
│ } │
│ │
└─────────────────────────────────────────┘
Alex: So it's like a security camera recording everything?
Maya: Exactly! Every API call - whether from the console, CLI, SDK, or other services - gets logged. This is crucial for:
- Compliance audits: "Show me all changes to S3 permissions in Q4"
- Security investigations: "Who deleted this critical resource?"
- Troubleshooting: "Why did this deployment fail?"
CloudTrail Best Practices:
✅ Enable in all regions (even those you don't use)
✅ Enable log file validation (proves logs haven't been tampered with)
✅ Store logs in a dedicated security account
✅ Enable S3 and Lambda data events for sensitive resources
✅ Set up CloudWatch Logs integration for real-time alerting
✅ Never turn it off in production!
AWS Config
Maya: Config answers: "What is the STATE of my resources, and did it comply with my rules?"
┌─────────────────────────────────────────┐
│ AWS CONFIG │
│ (Configuration Management) │
├─────────────────────────────────────────┤
│ │
│ Tracks: │
│ ├── Resource inventory │
│ ├── Configuration history │
│ ├── Change tracking │
│ └── Compliance checking │
│ │
│ Timeline View: │
│ Jan 10: S3 bucket created │
│ ├── Encryption: disabled ❌ │
│ └── Versioning: disabled ❌ │
│ │
│ Jan 15: Configuration changed │
│ ├── Encryption: enabled ✅ │
│ └── Versioning: disabled ❌ │
│ │
│ Jan 20: Configuration changed │
│ ├── Encryption: enabled ✅ │
│ └── Versioning: enabled ✅ │
│ │
│ Compliance Rules: │
│ ├── S3 must have encryption ✅ │
│ ├── S3 must have versioning ✅ │
│ └── Overall Status: COMPLIANT │
│ │
└─────────────────────────────────────────┘
Alex: So CloudTrail is the "who and when," and Config is the "what and compliance"?
Maya: Perfect! Let me show you how they work together:
Scenario: Someone made an S3 bucket public
CloudTrail tells you:
├── WHO: sarah@company.com
├── WHEN: 2024-01-15 14:23:45 UTC
├── ACTION: PutBucketPolicy
└── FROM: IP 203.0.113.50
Config tells you:
├── BEFORE: Bucket was private
├── AFTER: Bucket is now public
├── COMPLIANCE: VIOLATION of rule "s3-bucket-public-read-prohibited"
└── RELATED CHANGES: Shows the exact policy change
Alex: That's powerful! Can Config automatically fix violations?
Maya: Yes! Through Config Remediation Actions. Here's a real example:
Config Rule: "All EBS volumes must be encrypted"
Remediation Action:
- Config detects non-encrypted EBS volume
- Automatically triggers SSM Automation document
- Creates encrypted snapshot
- Creates new encrypted volume from snapshot
- (Optionally) Notifies team about the change
Alex: What are some essential Config rules I should enable?
Maya: Great question! Here's my starter pack:
| Category | Config Rule | What It Checks |
|---|---|---|
| IAM | iam-root-access-key-check | Root user has no access keys |
| iam-user-mfa-enabled | All IAM users have MFA | |
| S3 | s3-bucket-public-read-prohibited | No public read access |
| s3-bucket-server-side-encryption | Encryption enabled | |
| EC2 | ec2-security-group-restricted-ssh | SSH not open to 0.0.0.0/0 |
| ec2-instance-managed-by-ssm | Instances use Systems Manager | |
| RDS | rds-encryption-enabled | Databases are encrypted |
| rds-multi-az-support | Production DBs have multi-AZ | |
| Network | vpc-flow-logs-enabled | Flow logs are enabled |
CloudTrail vs Config Summary:
┌──────────────────────────────────────────────────────┐
│ │
│ CLOUDTRAIL CONFIG │
│ (Activity Log) (Configuration DB) │
│ │
│ API calls vs Resource state │
│ Who did what vs What's configured │
│ Historical actions vs Current compliance │
│ Audit trail vs Drift detection │
│ │
│ Use together for complete picture! │
│ │
└──────────────────────────────────────────────────────┘
Data Protection Services
Alex: We've covered a lot! What about protecting the actual data? We have sensitive customer information.
Maya: Excellent question! Let's talk about the data protection trio: KMS, Secrets Manager, and Macie.
AWS KMS (Key Management Service)
Maya: KMS is your encryption key management system. Think of it as a super-secure vault for your encryption keys.
Alex: Why can't I just generate my own keys and store them in environment variables?
Maya: winces Oh no, please don't do that! Here's why KMS is critical:
❌ BAD: DIY Key Management
├── Keys stored in code or environment variables
├── Keys might be committed to Git
├── No audit trail of who used keys
├── Keys never rotated
├── Keys same in dev/staging/prod
└── If leaked, manual rotation nightmare
✅ GOOD: KMS
├── Keys never leave AWS HSM (Hardware Security Module)
├── Every key usage is logged in CloudTrail
├── Automatic rotation available
├── Fine-grained access control via IAM
├── Keys can be disabled/deleted
└── Integrated with most AWS services
Alex: What's the actual workflow?
Maya: Here's how it works:
┌──────────────────────────────────────────────────────┐
│ KMS ENCRYPTION WORKFLOW │
├──────────────────────────────────────────────────────┤
│ │
│ 1. You create a KMS Customer Master Key (CMK) │
│ │
│ 2. Application needs to encrypt data: │
│ ┌─────────────┐ │
│ │ Your App │ │
│ └──────┬──────┘ │
│ │ "Encrypt this data" │
│ ↓ │
│ ┌─────────────┐ │
│ │ KMS API │ │
│ └──────┬──────┘ │
│ │ Checks IAM permissions │
│ │ Uses CMK to encrypt │
│ │ Logs to CloudTrail │
│ ↓ │
│ Returns: Encrypted data │
│ │
│ 3. To decrypt, same process in reverse │
│ (must have kms:Decrypt permission) │
│ │
└──────────────────────────────────────────────────────┘
KMS Key Types:
| Key Type | Control | Use Case | Cost |
|---|---|---|---|
| AWS Managed Keys | AWS controls | S3, RDS default encryption | Free |
| Customer Managed Keys | You control (recommended) | Production data, compliance | $1/month + usage |
| AWS Owned Keys | AWS controls (invisible to you) | Some services use internally | Free |
| CloudHSM Keys | You control in dedicated HSM | Highest security requirements | $1+/hour |
Maya: For most applications, Customer Managed Keys are the sweet spot.
Alex: How do I actually use this with S3 or RDS?
Maya: It's usually just a checkbox or parameter:
S3 Example:
aws s3api put-object \
--bucket my-bucket \
--key sensitive-data.txt \
--body data.txt \
--server-side-encryption aws:kms \
--ssekms-key-id arn:aws:kms:us-east-1:123456789012:key/abc-123
RDS Example:
aws rds create-db-instance \
--db-instance-identifier my-database \
--storage-encrypted \
--kms-key-id arn:aws:kms:us-east-1:123456789012:key/abc-123
Maya: Most AWS services are KMS-integrated, so it's seamless!
AWS Secrets Manager
Alex: Okay, so KMS handles encryption keys. What about passwords, API keys, database credentials - where do those go?
Maya: That's exactly what Secrets Manager is for! It's built on top of KMS but designed specifically for secrets like:
- Database credentials
- API keys
- OAuth tokens
- Any sensitive configuration
What makes Secrets Manager special:
┌──────────────────────────────────────────────────────┐
│ SECRETS MANAGER FEATURES │
├──────────────────────────────────────────────────────┤
│ │
│ ✅ Automatic rotation (with Lambda) │
│ ├── RDS/Aurora: Built-in rotation │
│ ├── DocumentDB: Built-in rotation │
│ └── Custom: Your own rotation logic │
│ │
│ ✅ Encrypted at rest (using KMS) │
│ │
│ ✅ Fine-grained access control (IAM policies) │
│ │
│ ✅ Versioning (can retrieve previous versions) │
│ │
│ ✅ Audit trail (every access logged in CloudTrail) │
│ │
│ ✅ Cross-region replication │
│ │
└──────────────────────────────────────────────────────┘
Real-World Example:
Old Way (❌):
# Hardcoded in code or environment variable
DB_PASSWORD = "MyP@ssw0rd123" # NEVER DO THIS!
conn = connect(
host="database.example.com",
user="admin",
password=DB_PASSWORD
)
New Way (✅):
import boto3
import json
def get_secret():
client = boto3.client('secretsmanager')
response = client.get_secret_value(SecretId='prod/database/credentials')
secret = json.loads(response['SecretString'])
return secret
# Usage
secret = get_secret()
conn = connect(
host=secret['host'],
user=secret['username'],
password=secret['password'] # Retrieved securely
)
Alex: What about automatic rotation? How does that work?
Maya: Great question! Here's the flow for RDS:
Rotation Schedule: Every 30 days
Day 1: Secret created: password = "OldPassword123"
Day 30: Rotation triggered
├── Secrets Manager calls Lambda function
├── Lambda creates new DB user with new password
├── Lambda tests new credentials
├── Lambda updates secret: password = "NewPassword456"
├── Lambda marks old version as deprecated
└── Applications automatically get new password
Day 31: Old credentials still work (grace period)
Day 32: Old credentials deactivated
Alex: Wait, applications automatically get the new password?
Maya: They do if you retrieve secrets at runtime instead of caching them permanently. Best practice:
# ❌ BAD: Retrieve once at startup
secret = get_secret() # Cached for entire application lifetime
# ✅ GOOD: Retrieve and cache with TTL
secret = get_secret_cached(ttl=300) # Cache for 5 minutes
# ✅ BETTER: Use connection handler that refreshes
conn = get_db_connection() # Handles rotation automatically
Secrets Manager vs Systems Manager Parameter Store:
| Feature | Secrets Manager | Parameter Store |
|---|---|---|
| Cost | $0.40/secret/month | Free (Standard), $0.05 (Advanced) |
| Rotation | Built-in with Lambda | Manual |
| Cross-region | Yes, automatic | Manual replication |
| Best for | Sensitive secrets needing rotation | Configuration values, less sensitive |
| Version limit | ~100 versions | 100 versions |
Alex: When would I use Parameter Store over Secrets Manager?
Maya: Parameter Store is great for configuration:
- Feature flags
- Environment-specific settings
- Non-rotating API keys
- Configuration values
Use Secrets Manager when:
- You need automatic rotation
- It's highly sensitive (database passwords)
- You need cross-region replication
- Compliance requires regular rotation
Amazon Macie
Alex: Alright, I understand KMS and Secrets Manager. What's Macie?
Maya: Macie is your sensitive data detective for S3. It uses machine learning to automatically discover and protect sensitive data.
┌──────────────────────────────────────────────────────┐
│ AMAZON MACIE │
│ (Sensitive Data Discovery) │
├──────────────────────────────────────────────────────┤
│ │
│ What It Finds: │
│ ├── PII (Personally Identifiable Information) │
│ │ ├── Names, addresses, phone numbers │
│ │ ├── Social Security numbers │
│ │ └── Passport numbers │
│ ├── Financial Data │
│ │ ├── Credit card numbers │
│ │ └── Bank account numbers │
│ ├── Health Information (PHI) │
│ └── Credentials │
│ ├── API keys │
│ ├── AWS keys │
│ └── Private keys │
│ │
│ How It Works: │
│ 1. Scans your S3 buckets │
│ 2. Identifies sensitive data │
│ 3. Generates findings │
│ 4. Provides recommendations │
│ │
└──────────────────────────────────────────────────────┘
Example Macie Finding:
Finding: Multiple files containing credit card numbers
Severity: HIGH
Location: s3://customer-uploads/2024/01/
Details:
├── Files scanned: 1,247
├── Files with CCNs: 23
├── Total CCNs found: 156
└── Bucket encryption: DISABLED ⚠️
Recommendations:
1. Enable S3 bucket encryption
2. Enable S3 bucket versioning
3. Review bucket access policies
4. Consider moving to a dedicated sensitive data bucket
5. Implement lifecycle policy to delete old data
Alex: So Macie is like an auditor going through all our S3 buckets?
Maya: Exactly! It's especially valuable when:
- You have large amounts of S3 data
- You're not sure where sensitive data lives
- You need to comply with GDPR, PCI-DSS, HIPAA
- You want to prevent data leaks
Common Use Cases:
- Data Discovery: "Where is all our customer PII stored?"
- Compliance: "Prove we're properly protecting sensitive data"
- Migration Safety: "Make sure we don't migrate sensitive data to wrong environment"
- Incident Response: "What sensitive data was in that publicly exposed bucket?"
Application Security
Alex: We're really cooking now! What about security at the application level?
Maya: Let's talk about Inspector and Cognito - they handle different aspects of application security.
Amazon Inspector
Maya: Inspector is your automated vulnerability scanner for workloads.
┌──────────────────────────────────────────────────────┐
│ AMAZON INSPECTOR │
│ (Automated Vulnerability Management) │
├──────────────────────────────────────────────────────┤
│ │
│ What It Scans: │
│ ├── EC2 Instances │
│ │ ├── OS vulnerabilities │
│ │ ├── Installed packages │
│ │ └── Network exposure │
│ ├── Container Images (ECR) │
│ │ ├── Base image vulnerabilities │
│ │ └── Application dependencies │
│ └── Lambda Functions │
│ ├── Code vulnerabilities │
│ └── Package dependencies │
│ │
│ When It Scans: │
│ ├── Continuously (always on) │
│ ├── When instances launch │
│ ├── When images pushed to ECR │
│ ├── When Lambda deployed │
│ └── When new CVE published │
│ │
└──────────────────────────────────────────────────────┘
Alex: So it's like a vulnerability scanner that I don't have to manage?
Maya: Exactly! No agents to manage, no scan schedules to configure. Just enable it and it works.
Example Inspector Finding:
Finding ID: CVE-2024-12345
Resource: EC2 i-1234567890abcdef0
Severity: HIGH (CVSS 8.5)
Package: openssl-1.1.1k
Description: Buffer overflow in OpenSSL allows remote code execution
Path to Exposure:
├── Instance has public IP: Yes
├── Security group allows port 443: Yes
└── Risk: Externally exploitable
Remediation:
├── Update to openssl-1.1.1w or later
├── Command: sudo yum update openssl
└── Estimated fix time: 5 minutes
Alex: Does it integrate with CI/CD?
Maya: Yes! Here's a common DevOps workflow:
Developer commits code
↓
CI/CD Pipeline
↓
Build container image
↓
Push to Amazon ECR
↓
Inspector automatically scans ──→ Finds vulnerabilities
↓ ↓
No issues Issues found
↓ ↓
Deploy to production Block deployment
↓
Create ticket
↓
Notify team
Alex: Can I configure it to block deployments with high-severity vulnerabilities?
Maya: Absolutely! Here's a typical policy:
| Severity | Action |
|---|---|
| 🔴 Critical (9.0-10.0) | Block deployment, page on-call |
| 🟠 High (7.0-8.9) | Block deployment, create ticket |
| 🟡 Medium (4.0-6.9) | Allow with warning, create ticket |
| 🟢 Low (0.1-3.9) | Allow, log for review |
Amazon Cognito
Alex: What about user authentication? We're building a web app and need to handle user logins.
Maya: Don't build your own authentication! Use Cognito. Seriously, custom authentication is where most security vulnerabilities come from.
Cognito has two main components:
┌──────────────────────────────────────────────────────┐
│ AMAZON COGNITO │
├──────────────────────────────────────────────────────┤
│ │
│ 1. USER POOLS │
│ (Your own user directory) │
│ ├── Sign-up and sign-in │
│ ├── MFA support │
│ ├── Password policies │
│ ├── Email/phone verification │
│ └── Custom authentication flows │
│ │
│ 2. IDENTITY POOLS │
│ (Federated identities → AWS credentials) │
│ ├── User Pool users → AWS access │
│ ├── Social login (Google, Facebook) │
│ ├── SAML identity providers │
│ └── Anonymous guest access │
│ │
└──────────────────────────────────────────────────────┘
Alex: What's the difference between User Pools and Identity Pools?
Maya: Great question! This confuses everyone at first:
USER POOLS: Authentication (Who are you?)
└── "I'm Alex, here's my username and password"
└── Returns: JWT tokens for your application
IDENTITY POOLS: Authorization (What AWS resources can you access?)
└── "I'm authenticated via User Pool/Google/Facebook"
└── Returns: Temporary AWS credentials (STS tokens)
Common Architecture:
Mobile/Web App
↓
┌─────────────────┐
│ User Pool │ ← Authentication
│ "Who are you?" │
└────────┬────────┘
│ JWT Token
↓
┌─────────────────┐
│ Identity Pool │ ← Authorization
│ "What can you │
│ access?" │
└────────┬────────┘
│ AWS Credentials
↓
Access S3/DynamoDB/API Gateway directly from app
Alex: Can you give me a real-world example?
Maya: Sure! Photo sharing app:
1. User signs up
├── User Pool creates account
├── Sends verification email
└── Stores encrypted password
2. User logs in
├── User Pool validates credentials
├── Returns JWT tokens
└── App stores tokens
3. User uploads photo
├── App uses JWT to call API Gateway
├── API Gateway validates token
├── Lambda processes upload
└── Stores in S3
4. User wants to access their photos directly
├── App exchanges JWT for AWS credentials (Identity Pool)
├── Identity Pool returns STS credentials with policy:
│ "Allow s3:GetObject on s3://photos/${cognito-identity-id}/*"
└── App accesses S3 directly (no backend needed!)
Cognito Security Features:
| Feature | Purpose |
|---|---|
| MFA | SMS, TOTP, or software tokens |
| Advanced Security | Risk-based authentication, bot detection |
| Password Policies | Complexity requirements, rotation |
| Account Takeover Protection | Detect unusual sign-in activity |
| Compromise Credentials | Check against known breached passwords |
| Custom Authentication | Lambda triggers for custom logic |
Alex: This is way better than rolling our own auth!
Maya: Right? And it's compliant with SOC, PCI DSS, ISO, and other standards out of the box.
How They All Work Together
Alex: Okay, my head is spinning with all these services. How do they actually work together in a real application?
Maya: Let me show you a complete architecture that uses everything we've discussed!
Complete Secure Architecture Example
Scenario: E-commerce application with web frontend, API backend, and database
┌────────────────────────────────────────────────────────────────┐
│ USERS (Internet) │
└───────────────────────────────┬────────────────────────────────┘
│
┌───────────▼──────────┐
│ AWS Shield │ DDoS Protection (Layer 3/4)
│ (Standard) │
└───────────┬──────────┘
│
┌───────────▼──────────┐
│ CloudFront │ CDN + Edge security
│ + AWS WAF │ SQL injection/XSS protection
└───────────┬──────────┘
│
┌───────────────────▼───────────────────┐
│ │
┌───────▼────────┐ ┌──────────▼────────┐
│ Static Assets │ │ Application │
│ (S3 + KMS) │ │ Load Balancer │
│ │ │ (ALB) │
└────────────────┘ └──────────┬─────────┘
│
┌──────────▼─────────┐
│ ECS/Fargate │
│ (Containers) │
│ + IAM Roles │
└──────────┬─────────┘
│
┌──────────────────────────────┼──────────────────┐
│ │ │
┌───────▼────────┐ ┌──────────▼──────┐ ┌────────▼──────┐
│ RDS (Aurora) │ │ Secrets │ │ DynamoDB │
│ + KMS │ │ Manager │ │ + KMS │
│ + Encryption │ │ (DB creds) │ │ + Encryption│
└────────────────┘ └─────────────────┘ └───────────────┘
┌─────────────────────────────────────────────────────────────────────┐
│ SECURITY SERVICES LAYER │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ GuardDuty │ │ Inspector │ │ Macie │ │
│ │ (Threats) │ │ (Vulns) │ │ (Data) │ │
│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │
│ │ │ │ │
│ └──────────────────┼──────────────────┘ │
│ │ │
│ ┌────────▼────────┐ │
│ │ Security Hub │ Central dashboard │
│ └────────┬────────┘ │
│ │ │
│ ┌────────▼────────┐ │
│ │ EventBridge │ Automated response │
│ └────────┬────────┘ │
│ │ │
│ ┌────────▼────────┐ │
│ │ Lambda │ Remediation │
│ └─────────────────┘ │
│ │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ CloudTrail │ │ Config │ │ VPC Flow │ │
│ │ (Audit) │ │ (Compliance)│ │ Logs │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────┐
│ IDENTITY & ACCESS LAYER │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ Application Users ────→ Cognito User Pool ────→ Cognito Identity │
│ Pool │
│ Employees ────────────→ IAM Identity Center │
│ Applications ─────────→ IAM Roles │
│ Cross-Account ────────→ IAM Roles + AssumeRole │
│ │
└─────────────────────────────────────────────────────────────────────┘
Security Event Flow Example
Maya: Let me show you what happens when there's a security event:
INCIDENT: Compromised EC2 instance detected
Timeline:
─────────────────────────────────────────────────────────
T+0 seconds:
├── GuardDuty detects unusual API calls from EC2 instance
└── Finding: "Compromised EC2 instance making unauthorized API calls"
T+5 seconds:
├── GuardDuty sends finding to Security Hub
├── Security Hub aggregates with other findings
├── Security Hub sends event to EventBridge
└── CloudTrail logs all API calls for investigation
T+10 seconds:
├── EventBridge triggers Lambda function
├── Lambda executes automated response:
│ ├── 1. Snapshot EBS volume (forensics)
│ ├── 2. Change security group to isolate instance
│ ├── 3. Revoke IAM role credentials
│ └── 4. Tag instance as "compromised"
└── SNS sends notification to security team
T+30 seconds:
├── Security team receives alert
├── Opens AWS Detective to investigate
└── Detective shows:
├── Timeline of API calls
├── Resources accessed
├── Network connections made
└── Related findings
T+5 minutes:
├── Security team determines root cause
├── Config shows instance was launched without:
│ ├── SSM agent (no patch management)
│ └── Inspector scanning (vulnerability)
├── Inspector finding shows unpatched CVE
└── Incident documented
T+1 hour:
├── New Config rule deployed:
│ "All EC2 instances must have SSM agent"
├── Inspector continuous scanning enabled
└── Lambda function updated with new response logic
Alex: Wow, so the services really do orchestrate together!
Maya: Exactly! And here's the key insight: Each service is a specialist, but together they form a comprehensive defense.
Integration Patterns
Maya: Here are the common integration patterns you should know:
Pattern 1: Detective → Alerting
GuardDuty/Inspector/Macie
↓
Security Hub
↓
EventBridge
↓
SNS/Slack/PagerDuty
Pattern 2: Detective → Automated Response
GuardDuty detects threat
↓
EventBridge rule triggers
↓
Lambda executes remediation
↓
Systems Manager runs automation
↓
SNS sends confirmation
Pattern 3: Compliance Monitoring
Config evaluates resources
↓
Non-compliant resource detected
↓
Security Hub aggregates finding
↓
EventBridge triggers remediation
↓
Config re-evaluates
↓
Compliance restored
Pattern 4: Access Management
User authenticates (Cognito)
↓
Receives JWT token
↓
API Gateway validates token
↓
Lambda assumes IAM role (limited permissions)
↓
Retrieves secrets (Secrets Manager)
↓
Accesses data (encrypted with KMS)
↓
All actions logged (CloudTrail)
Maturity Model
Alex: This is a lot to implement. Where should I start?
Maya: Great question! Here's a maturity model:
| Level | Stage | Services to Implement | Time Frame |
|---|---|---|---|
| 1 | Foundation | IAM, Security Groups, CloudTrail | Week 1 |
| 2 | Basic Protection | WAF, Shield, KMS | Week 2-3 |
| 3 | Detection | GuardDuty, Config | Week 4 |
| 4 | Aggregation | Security Hub, Inspector | Month 2 |
| 5 | Automation | EventBridge + Lambda responses | Month 3 |
| 6 | Advanced | Detective, Macie, Custom automations | Month 4+ |
Level 1: Foundation (Start here!)
Week 1 Checklist:
☐ Enable MFA on root account
☐ Create IAM admin users (no root account usage)
☐ Enable CloudTrail in all regions
☐ Create security groups with least privilege
☐ Enable VPC Flow Logs
☐ Document what you have
Level 2: Basic Protection
Week 2-3 Checklist:
☐ Enable S3 encryption (default)
☐ Enable RDS encryption
☐ Set up KMS customer managed keys
☐ Deploy WAF on public-facing apps
☐ Review and restrict security groups
☐ Set up AWS Organizations (if multi-account)
Level 3: Detection
Week 4 Checklist:
☐ Enable GuardDuty in all regions
☐ Enable AWS Config
☐ Deploy essential Config rules
☐ Set up SNS topics for alerts
☐ Create runbooks for common findings
Alex: So I don't need to enable everything on day one?
Maya: Absolutely not! Start with the foundation and build up. Each level makes the next easier.
Service Summary Reference
Alex: This has been incredibly helpful! Can we create a quick reference summary?
Maya: Of course! Here's your cheat sheet:
Complete AWS Security Services Reference
| Service | Category | Primary Function | Key Use Cases | Cost Model |
|---|---|---|---|---|
| IAM | Identity | Access management for users, roles, policies | Authentication, authorization | Free |
| IAM Identity Center | Identity | SSO for employees across AWS accounts | Multi-account access | Free |
| Cognito | Identity | User authentication for applications | Mobile/web app auth | Pay per MAU |
| Organizations | Identity | Multi-account management | Account structure, SCPs | Free |
| Security Groups | Network | Virtual firewall at instance level | EC2, RDS, ALB access control | Free |
| NACLs | Network | Subnet-level firewall | Additional network layer | Free |
| WAF | Network | Web application firewall | Protect against OWASP Top 10 | Per rule + requests |
| Shield Standard | Network | DDoS protection | Automatic layer 3/4 protection | Free |
| Shield Advanced | Network | Enhanced DDoS protection | Enterprise DDoS defense | $3,000/month |
| GuardDuty | Detection | Intelligent threat detection | Malicious activity monitoring | Pay per GB analyzed |
| Security Hub | Detection | Centralized security dashboard | Aggregate all security findings | Per finding + checks |
| Detective | Detection | Security investigation | Incident analysis | Per GB ingested |
| Inspector | Detection | Vulnerability scanning | CVE detection in EC2/containers | Per scan |
| Macie | Detection | Sensitive data discovery | Find PII in S3 | Per GB scanned |
| CloudTrail | Compliance | API call logging | Audit trail | First trail free, then pay per event |
| Config | Compliance | Resource configuration tracking | Compliance monitoring | Per config item + rule evaluation |
| KMS | Data Protection | Encryption key management | Encrypt data at rest | $1/key/month + usage |
| Secrets Manager | Data Protection | Secrets storage & rotation | Store passwords, API keys | $0.40/secret/month |
| Systems Manager Parameter Store | Data Protection | Configuration & secrets storage | App config, simple secrets | Free (standard) |
| VPC Flow Logs | Logging | Network traffic logs | Network troubleshooting | CloudWatch Logs pricing |
Quick Decision Tree
Maya: Here's how to choose the right service:
What are you trying to do?
├─ Manage who can access AWS?
│ ├─ Employees → IAM Identity Center
│ ├─ Applications → IAM Roles
│ └─ Customers → Cognito
├─ Protect against attacks?
│ ├─ Network/DDoS → Shield + WAF
│ ├─ Application vulnerabilities → Inspector
│ └─ Malicious activity → GuardDuty
├─ Protect data?
│ ├─ Encrypt at rest → KMS
│ ├─ Store secrets → Secrets Manager
│ └─ Find sensitive data → Macie
├─ Monitor & detect?
│ ├─ Threats → GuardDuty
│ ├─ Compliance → Config
│ ├─ Central dashboard → Security Hub
│ └─ Investigate → Detective
└─ Audit & compliance?
├─ Who did what? → CloudTrail
├─ Configuration history → Config
└─ Generate reports → Security Hub
Service Relationships (How They Work Together)
┌─────────────────────────────────────────────────────────────┐
│ DATA SOURCES │
├─────────────────────────────────────────────────────────────┤
│ CloudTrail │ VPC Flow │ DNS Logs │ Config │ Inspector │ │
│ Logs │ Logs │ │ Rules │ Scans │ │
└──────┬──────────┬───────────┬──────┬──────────┬────────────┘
│ │ │ │ │
└──────────┴───────────┴──────┴──────────┘
│
┌───────────────┼───────────────┐
│ │ │
┌────▼────┐ ┌────▼────┐ ┌────▼────┐
│GuardDuty│ │ Config │ │Inspector│
│ │ │ Rules │ │ │
└────┬────┘ └────┬────┘ └────┬────┘
│ │ │
└──────────────┼──────────────┘
│
┌──────▼──────┐
│ Security Hub│ ← Central aggregation
└──────┬──────┘
│
┌────────────┼────────────┐
│ │ │
┌────▼────┐ ┌───▼────┐ ┌───▼──────┐
│Detective│ │EventBridge│ │Reports│
│(Investigate)│ (Automate) │ (Comply)│
└─────────┘ └───┬────┘ └─────────┘
│
┌────▼────┐
│ Lambda │
│(Remediate)
└─────────┘
Cost Optimization Tips
Alex: One last question - how do I keep costs under control?
Maya: Smart question! Here are my tips:
| Service | Cost Optimization Strategy |
|---|---|
| GuardDuty | ✅ Enable (cost is justified), consider S3 Protection selectively |
| Security Hub | ✅ Enable, disable unused standards, use aggregation regions |
| Detective | ⚠️ Enable when needed for investigation (can be turned off) |
| Inspector | ✅ Always on for containers/Lambda, continuous for EC2 |
| Macie | ⚠️ Run periodic scans instead of continuous for cost savings |
| Config | ⚠️ Be selective with resources tracked, use aggregator |
| CloudTrail | ✅ One trail per region free, use data events selectively |
| WAF | ⚠️ Consolidate rules, use managed rule groups |
| Secrets Manager | ⚠️ Use Parameter Store for non-rotated secrets |
Maya's Golden Rules:
- Start with free tier: CloudTrail, Shield Standard, IAM
- Enable critical detection: GuardDuty is non-negotiable
- Be strategic with scanning: You don't need to scan everything everywhere
- Use managed rules: AWS managed rules are often cheaper than custom
- Monitor your costs: Set up AWS Budgets for security services
Implementation Checklist
Maya: Here's your final implementation checklist:
Week 1: Foundation
☐ Create AWS Organization structure
☐ Enable IAM Identity Center for employee access
☐ Remove long-term credentials, use roles
☐ Enable MFA on all accounts
☐ Enable CloudTrail (all regions)
☐ Create logging S3 bucket (encrypted, versioned)
☐ Document your account structure
Week 2: Network Security
☐ Review and tighten security groups
☐ Enable VPC Flow Logs
☐ Deploy WAF on public-facing resources
☐ Configure WAF rate limiting rules
☐ Test WAF rules in count mode first
☐ Document network architecture
Week 3: Data Protection
☐ Create KMS customer managed keys
☐ Enable S3 default encryption
☐ Enable RDS/EBS encryption
☐ Migrate secrets to Secrets Manager
☐ Set up rotation for database credentials
☐ Review S3 bucket policies
Week 4: Detection & Monitoring
☐ Enable GuardDuty (all regions)
☐ Enable AWS Config
☐ Deploy foundational Config rules
☐ Enable Security Hub
☐ Configure Security Hub standards
☐ Set up SNS topics for alerts
☐ Create runbooks for incident response
Month 2: Automation & Improvement
☐ Enable Inspector
☐ Integrate Inspector with CI/CD
☐ Create EventBridge rules for automated response
☐ Deploy remediation Lambda functions
☐ Enable Macie (if needed)
☐ Test incident response runbooks
☐ Conduct tabletop security exercise
Month 3: Advanced & Optimization
☐ Enable Detective
☐ Fine-tune alerting (reduce noise)
☐ Optimize costs
☐ Implement advanced automation
☐ Create security dashboards
☐ Schedule regular reviews
☐ Document everything
Final Thoughts
Alex: Maya, this has been amazing. I feel like I can actually tackle AWS security now!
Maya: That's great! Remember these key principles:
🔑 Key Takeaways:
- Defense in Depth: Use multiple layers of security
- Least Privilege: Grant minimal permissions needed
- Automation: Automate security responses where possible
- Monitoring: You can't protect what you can't see
- Encryption: Encrypt data at rest and in transit
- Assume Breach: Plan for incidents, not just prevention
- Continuous Improvement: Security is a journey, not a destination
Alex: What's the single most important thing to remember?
Maya: If I had to pick one thing: Identity is your foundation. Get IAM right, and everything else becomes easier. Get it wrong, and nothing else matters.
Also, remember: Security is everyone's responsibility, not just the security team's. Make security easy and automatic for developers, and they'll follow best practices.
Alex: Thanks, Maya! Time to implement all this.
Maya: Good luck! And remember - start small, build incrementally, and don't try to do everything at once. Feel free to ping me when you have questions!
Additional Resources
Documentation:
- AWS Security Documentation: https://docs.aws.amazon.com/security/
- AWS Well-Architected Security Pillar: https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/
- AWS Security Blog: https://aws.amazon.com/blogs/security/
Training:
- AWS Security Fundamentals (free digital course)
- AWS Certified Security - Specialty certification
- AWS Security workshops: https://workshops.aws/
Tools:
- AWS Security Reference Architecture: Pre-built security patterns
- IAM Policy Simulator: Test IAM policies before deploying
- Access Analyzer: Find unintended resource access
- Trusted Advisor: Automated security recommendations
This conversation-based guide covers the core AWS security services. For specific implementation details, always refer to the official AWS documentation and consider your organization's specific compliance and security requirements.
Top comments (0)