2.1.1. Workload Monitoring Requirements and Strategies
First Principle: Effective monitoring starts with understanding what you need to protect, what threats you face, and what signals indicate those threats — then selecting the minimum set of tools that provide complete coverage without drowning you in noise.
Before enabling any monitoring tool, answer three questions:
- What are my critical assets? (databases, S3 buckets with PII, IAM admin roles)
- What threats target those assets? (credential theft, data exfiltration, privilege escalation)
- What signals would indicate those threats? (unusual API calls, traffic to known C2 IPs, new IAM users)
Monitoring Strategy Design:
| Signal Type | AWS Tool | What It Detects |
|---|---|---|
| API activity anomalies | GuardDuty | Unusual call patterns, compromised credentials |
| Resource health | CloudWatch | CPU spikes, memory pressure, error rates |
| Configuration drift | AWS Config | Resources deviating from security baselines |
| Sensitive data exposure | Macie | PII/PHI in S3 buckets, public access |
| Centralized findings | Security Hub | Aggregated view across all security services |
Health Checks serve as the simplest monitoring layer — ELB health checks verify application availability, Route 53 health checks verify endpoint reachability, and CloudWatch Synthetics canaries simulate user traffic to detect functional degradation that might indicate an attack.
⚠️ Exam Trap: GuardDuty doesn't analyze CloudWatch metrics or application logs. It analyzes CloudTrail, VPC Flow Logs, and DNS logs. Don't confuse GuardDuty's scope with CloudWatch's.
Scenario: A financial services company needs to monitor for unauthorized access to customer PII stored in S3 while also detecting unusual API patterns that might indicate credential compromise. Which combination of services provides both capabilities?
Reflection Question: Why does effective monitoring require multiple specialized tools rather than one "do everything" service?
