Chapter 64: AWS Detection and Response
AWS Detection and Response (often just called threat detection & incident response on AWS)
This is not a single service with a big shiny button. It is a layered, intelligent, mostly automated system that watches your AWS environment 24/7, notices when something is wrong (or about to go wrong), alerts you quickly, and in many cases — starts helping you respond automatically.
If you ignore detection & response, bad things usually happen in this order:
- Someone compromises an IAM key / role
- They quietly run crypto-mining or exfiltrate data for weeks/months
- You wake up to a ₹1–5 lakh surprise bill + angry customers + newspaper headline
- You spend 2–3 weeks doing forensic investigation with no logs
The goal of AWS Detection and Response is simple: Catch the attacker early → give you visibility → help you stop them before damage is severe.
Let’s walk through it like a real classroom session — no marketing fluff, just the truth with Hyderabad examples.
1. The Three Core Phases of Detection & Response on AWS (2026)
| Phase | What it really means | Main AWS services doing the heavy lifting | Typical time-to-detect in a well-configured account |
|---|---|---|---|
| 1. Continuous Monitoring & Detection | Watching everything that happens — looking for anomalies, known attack patterns, misconfigurations | GuardDuty, Security Hub, Config, Macie, Inspector | Hours to days (GuardDuty usually catches within 24–48 h) |
| 2. Alerting & Prioritization | Turning thousands of raw signals into a short, prioritized list of “things you should actually care about today” | Security Hub, Amazon EventBridge, SNS, AWS Chatbot (Slack/Teams) | Minutes to hours after detection |
| 3. Investigation & Response | Digging into what happened + stopping the bleeding + recovering | Detective, Security Hub Insights, AWS Systems Manager Automation, Lambda + Step Functions playbooks | Hours to days (depending on severity) |
2. The Main Detection Engines (The Watchdogs)
| Service | What it watches / detects | How it works (simple) | Typical finding in Hyderabad startup (2026) | Approx Monthly Cost (small–medium account) |
|---|---|---|---|---|
| Amazon GuardDuty | Threat intelligence + anomaly detection | ML + threat intel feeds + CloudTrail + VPC Flow Logs + DNS logs | “Compromised EC2 instance running crypto-miner” | ₹1,500 – ₹8,000 |
| Amazon Macie | Sensitive data discovery & access anomaly | ML scans S3 buckets for PII, financial data, credentials | “Aadhaar numbers found in public S3 bucket” | ₹2,000 – ₹12,000 |
| AWS Config | Configuration compliance & change tracking | Continuous rules engine (e.g., “S3 bucket should not be public”) | “Security group allows 0.0.0.0/0 on port 22” | ₹500 – ₹3,000 |
| AWS Inspector | Vulnerability scanning (EC2, Lambda, ECR images) | Agentless scans for CVEs & best-practice violations | “EC2 instance running outdated OpenSSL CVE-2022-0778” | ₹1,000 – ₹6,000 |
| Amazon Detective | Investigation & root-cause analysis | Graph-based correlation of GuardDuty + CloudTrail + VPC Flow Logs | “Timeline of how attacker used stolen IAM role” | ₹2,000 – ₹10,000 (pay-per-GB ingested) |
3. Real Hyderabad Example — Full Detection & Response Flow
Your startup “TeluguBites” (restaurant discovery & food ordering app):
Setup (very typical production pattern in 2026):
- All services in ap-south-2 (Hyderabad Region)
- Multi-AZ ECS Fargate + Aurora PostgreSQL + S3 + CloudFront + ALB
- Developers use IAM Identity Center (SSO)
- CI/CD via CodePipeline + GitHub
What happens when an attacker compromises a developer’s IAM access key:
Phase 1 — Detection (usually within 24–48 hours)
- Developer accidentally commits access key to GitHub public repo
- Attacker finds key → creates new EC2 instance → starts crypto-mining
- GuardDuty sees:
- Unusual API activity from new IP (CredentialAccess:IAMUser/AnomalousBehavior)
- EC2 instance communicating with known mining pool (CryptoCurrency:EC2/BitcoinTool.B)
- Macie sees unusual volume of GET requests to S3 buckets containing PII → flags potential exfiltration
- Config sees new security group allowing SSH from 0.0.0.0/0 → flags non-compliance
Phase 2 — Alerting & Prioritization
- All findings land in Security Hub → single dashboard
- High-severity GuardDuty finding → triggers EventBridge rule
- EventBridge → SNS topic → sends Slack message + email to on-call engineer
- Severity = HIGH → engineer wakes up at 3 AM (or auto-playbook starts)
Phase 3 — Investigation & Response
- Engineer opens Amazon Detective → sees:
- Graph timeline: when key was used, which APIs were called, which EC2 instance was launched
- Which S3 buckets were accessed
- Engineer revokes compromised IAM key via IAM console
- Uses AWS Systems Manager Automation → one-click “terminate suspicious EC2 instances” playbook
- Enables GuardDuty Malware Protection on EC2 → scans & quarantines infected instance
- Rotates all secrets in Secrets Manager that the compromised role could access
Total time from detection to containment: usually 1–4 hours (with good setup) Without GuardDuty/Security Hub → could be weeks/months
Monthly cost example (moderate traffic):
- GuardDuty → ~₹2,000–6,000
- Security Hub + Detective → ~₹2,000–8,000
- Macie (if enabled on S3) → ~₹2,000–10,000
- Total detection & response cost → ₹6,000–25,000/month (very cheap insurance)
4. Quick Hands-On – Enable Basic Detection
- GuardDuty console → Enable GuardDuty (takes ~24 hours for first findings)
- Security Hub console → Enable Security Hub → it auto-pulls GuardDuty + Config + Inspector
- Amazon Macie → Enable Macie → create sensitive data discovery job on your S3 buckets
- Wait 24–48 hours → open Security Hub dashboard → see first findings & insights
Summary Table — AWS Detection & Response Cheat Sheet (2026 – India Focus)
| Goal / Threat | Primary Service(s) | Golden Rule / Best Practice |
|---|---|---|
| Catch credential compromise & crypto-mining | GuardDuty | Enable on day 1 — it’s one of the highest ROI services |
| Find PII & sensitive data exposure | Amazon Macie | Enable on all S3 buckets — auto-discover & alert |
| Configuration misconfiguration drift | AWS Config + Security Hub | Enable Config rules → Security Hub shows compliance score |
| Investigate “how did this happen?” | Amazon Detective | Use after GuardDuty finding — graph timeline is magic |
| Central dashboard & prioritization | Security Hub | Enable everything → one pane of glass for all findings |
Teacher’s final note (real talk – Hyderabad 2026):
Detection & response is the difference between “we caught the attacker after 2 hours and no data was stolen” and “we discovered the breach 3 months later after customers complained”.
Most production incidents in India right now are not AWS being hacked — they are:
- Compromised IAM keys used for crypto-mining (bill shock)
- Public S3 buckets leaking PII (Macie would have caught this)
- No GuardDuty → blind to attacker activity for months
Do these three things today and you’re already safer than most:
- Enable GuardDuty in every region you use
- Enable Security Hub — it pulls GuardDuty + Config + Macie + Inspector
- Enable Amazon Macie on all S3 buckets
Got it? This is the “catch the attacker before they steal data or run up your bill” lesson.
Next?
- Step-by-step: Enable GuardDuty + Security Hub + Macie in a new account?
- Deep dive: How GuardDuty finds crypto-mining & credential abuse?
- Or how to build an automated response playbook with EventBridge + Lambda?
Tell me — next whiteboard ready! 🚀🕵️♂️
