What's changed: Deepened SCS-C02 Chapter 2 (added comparison tables, scenarios, FAQs, exam traps, deep-dive paragraphs to each section; localized figures to Japanese)
2.2Monitoring and Alerting
Understand real-time monitoring—CloudWatch (metrics/logs/alarms), metric filters, EventBridge, Config (config monitoring), and notifications. Detect and notify on anomalies immediately.
After collecting logs, connect to monitoring and notification. Detect anomalies with CloudWatch/Config and alert immediately.
2.2.1Monitoring and alerting
- CloudWatch: metrics/logs/alarms; trigger notifications/automation on threshold breach.
- Metric filters: turn security events (e.g., root login, auth failures) in logs into metrics/alarms.
- AWS Config: continuously monitor config changes and compliance drift (e.g., public S3).
- EventBridge/SNS: react to detections to trigger notifications or automated response.
Common on SCS-C02: alarm on log security events = metric filter → CloudWatch alarm, config change/compliance monitoring = AWS Config, detect root user login. Detect root login or MFA disablement instantly via metric filters/EventBridge.
SCS-C02 monitoring design probes "detecting security events promptly and without gaps, then connecting to response." CloudWatch metric filters extract patterns from CloudWatch Logs (fed by CloudTrail) for events like root user login, operations without MFA, repeated authorization failures (AccessDenied), IAM policy changes, security group or NACL changes, and CMK disablement/deletion scheduling, turning them into metrics with alarms (the CIS AWS Foundations recommended alarms are a classic example). AWS Config continuously evaluates config changes and compliance, detecting drift with managed rules (s3-bucket-public-read-prohibited, restricted-ssh, encrypted-volumes) and auto-remediating via remediation actions (SSM Automation). As the hub for reacting to state changes, EventBridge receives GuardDuty/Config/CloudTrail events and triggers SNS notifications and Lambda/SSM automated responses together. Note that metric filters apply only to logs after configuration (no retroactivity), and split roles: Config for configuration detection, GuardDuty for behavioral threats. Across an org, aggregate to a Config aggregator or Security Hub. The key is to detect critical security events (privileged operations, config drift) with metric filters/Config and reliably connect them to notification/automated response via EventBridge.
| What to detect | Means | Key point |
|---|---|---|
| Privileged/suspicious API ops | Metric filter → alarm | Root login/IAM change/AccessDenied (no retro) |
| Config change/compliance drift | AWS Config (rules) | Public S3/open SG; continuous eval + remediation |
| Behavioral threats | GuardDuty | ML detection of C2/anomalous API |
| Notify/respond | EventBridge → SNS/Lambda/SSM | Connect detection to response instantly |
Scenario: Instantly detect "root user login," "IAM policy change," and "CMK deletion scheduling" and notify the SOC. → Send CloudTrail to CloudWatch Logs, create a metric filter per event, and wire CloudWatch alarms + SNS notification. For configuration items (public S3, SG opened to 0.0.0.0/0), continuously detect with AWS Config rules and auto-remediate violations via EventBridge → SSM Automation. Cover critical-operation detection using the CIS AWS Foundations recommended alarms as a reference.
FAQ: Metric filters vs AWS Config? Metric filters detect "events appearing in logs" (an API operation occurring)—e.g., the “event” of a root login. AWS Config evaluates whether "a resource’s configuration state" is desired—e.g., whether S3 is in a public “state.” Remember: event detection = metric filters/EventBridge, state evaluation = Config.
Exam trap: Metric filters apply only to logs arriving after configuration and do not apply retroactively (query past logs with Athena/Logs Insights). Also, continuously evaluating "whether S3 is in a public configuration" is AWS Config, not a metric filter. Don’t mismatch the detection mechanism for events vs configuration state.
2.2.2Section summary
- Monitoring = CloudWatch (metric filters) + AWS Config (config)
- Notify/respond = EventBridge → SNS/Lambda
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. Alert immediately when CloudTrail logs a root user login. What?
Q2. Continuously detect if an S3 bucket is changed to public. What?
Q3. Connect a detected security event to notification and automated Lambda response. What?