Monitoring and alerting foundations

Analyzing workloads for monitoring requirements

Domain 1, Detection, is about seeing trouble early. Skill 1.1.1 asks you to look at a workload and decide what to monitor. The exam rarely asks “which service exists?”. It asks “which signal answers this requirement with the least effort?”. So start from the requirement, not from the tool.

Every requirement maps to one of five kinds of signal: metrics (numbers over time), logs (records of what happened), events (something just changed), health checks (is it reachable and working?) and findings (a security service thinks something is wrong). Today covers the first four and how to alert on them. Findings get a full day tomorrow.

$ aws cloudwatch list-metrics --namespace AWS/ApplicationELB \
    --metric-name HTTPCode_Target_5XX_Count
{ "Metrics": [ {
    "Namespace": "AWS/ApplicationELB",
    "MetricName": "HTTPCode_Target_5XX_Count",
    "Dimensions": [
      { "Name": "LoadBalancer", "Value": "app/shop-alb/50dc6c495c0c9188" } ] } ] }

Health checks and synthetic monitoring

Skill 1.1.2 gives one example by name: resource health checks. AWS has three kinds, and the exam tests which one fits. Route 53 health checks test endpoints from outside and can drive DNS failover. ELB health checks decide which targets get traffic. CloudWatch Synthetics canaries run a script that behaves like a real user.

ELB health checks and CloudWatch Synthetics

An ALB target group checks each target with HTTP or HTTPS. By default it checks every 30 seconds with a 5-second timeout, takes a target out after 2 failures, puts it back after 5 successes, and expects status 200. A CloudWatch Synthetics canary is a script (Node.js, Python or Java) that runs as a Lambda function on a schedule, as often as once per minute. Browser canaries use Playwright, Puppeteer or Selenium to click through pages, take screenshots and check content, so they also catch defacement or injected scripts. Canaries publish metrics such as SuccessPercent in the CloudWatchSynthetics namespace, and they can run inside a VPC to test internal endpoints.

$ aws route53 create-health-check --caller-reference shop-2026-10-10 \
  --health-check-config '{
    "Type": "HTTPS_STR_MATCH",
    "FullyQualifiedDomainName": "shop.example.com",
    "ResourcePath": "/health",
    "SearchString": "OK",
    "RequestInterval": 10,
    "FailureThreshold": 3 }'
{ "HealthCheck": { "Id": "abcd1234-...", "HealthCheckConfig": { ... } } }

CloudWatch metrics and metric filters on CloudTrail

Many security signals start as log lines, not numbers. A metric filter turns matching log events into a CloudWatch metric, so you can put an alarm on it. The classic exam case: send CloudTrail to CloudWatch Logs and alert on root user activity, unauthorized API calls and console sign-in without MFA.

Metrics basics the exam expects

A metric belongs to a namespace (for example AWS/EC2), has a name and up to several dimensions, and is read with a statistic (Sum, Average, Maximum, percentiles) over a period. AWS services publish many metrics for free; your own app or a metric filter publishes custom metrics (one example is LogMetrics, the namespace the CIS remediation steps use). The two other CIS patterns to recognise are {($.errorCode="*UnauthorizedOperation") || ($.errorCode="AccessDenied*")} for unauthorized API calls, and a ConsoleLogin pattern with $.additionalEventData.MFAUsed != "Yes" for sign-in without MFA.

$ aws logs put-metric-filter --log-group-name aws-cloudtrail-logs \
  --filter-name UnauthorizedAPICalls \
  --filter-pattern '{($.errorCode="*UnauthorizedOperation") || ($.errorCode="AccessDenied*")}' \
  --metric-transformations metricName=UnauthorizedAPICalls,metricNamespace=LogMetrics,metricValue=1,defaultValue=0

$ aws cloudwatch put-metric-alarm --alarm-name cis-unauthorized-api \
  --namespace LogMetrics --metric-name UnauthorizedAPICalls \
  --statistic Sum --period 300 --evaluation-periods 1 \
  --threshold 1 --comparison-operator GreaterThanOrEqualToThreshold \
  --alarm-actions arn:aws:sns:eu-west-1:111122223333:security-alerts

Alarms, composite alarms and anomaly detection

An alarm watches one metric (or a metric math expression) and changes state. For skill 1.1.4 you need to tune alarms so they catch real problems and stay quiet otherwise. The tools are M out of N evaluation, missing data handling, composite alarms that combine several alarms, and anomaly detection bands that learn what normal looks like.

Anomaly detection and missing data

Anomaly detection trains on up to two weeks of a metric’s history and learns hourly, daily and weekly patterns and trends. It draws a band of expected values; a higher threshold value makes the band wider. An anomaly detection alarm has no static threshold: it fires when the metric goes above the band, below it, or either. You can exclude time periods such as deployments from training, and use it on metric math expressions. Every alarm has three states: OK, ALARM, INSUFFICIENT_DATA. Datapoints to alarm gives “M out of N” (for example 3 out of 5 periods). TreatMissingData can be missing (the default), notBreaching, breaching or ignore.

$ aws cloudwatch put-composite-alarm --alarm-name shop-health \
  --alarm-rule '(ALARM("cpu-high") OR ALARM("api-5xx-high")) AND NOT ALARM("deploy-running")' \
  --actions-suppressor deploy-running \
  --actions-suppressor-wait-period 120 \
  --actions-suppressor-extension-period 300 \
  --alarm-actions arn:aws:sns:eu-west-1:111122223333:oncall

EventBridge rules, SNS notifications and dashboards

Alarms watch numbers over time. Many security signals are single events: a GuardDuty finding, a Security Hub finding, a security group change, a Config rule turning NON_COMPLIANT. An EventBridge rule matches these events by pattern the moment they arrive and sends them to a target, often an SNS topic for people or a Lambda function for automatic response.

SNS notifications and dashboards

Amazon SNS fans one message out to email, SMS, HTTPS endpoints, Lambda, SQS and chat tools. For an encrypted topic, the KMS key must be customer managed and its key policy must give the publishing service kms:GenerateDataKey* and kms:Decrypt. CloudWatch dashboards show metrics, alarms and log query results on one screen; one dashboard can include metrics from several Regions, and with cross-account sharing, from several accounts. A dashboard is for people looking; it never notifies anyone by itself.

$ aws events put-rule --name gd-high \
  --event-pattern '{"source":["aws.guardduty"],
    "detail-type":["GuardDuty Finding"],
    "detail":{"severity":[{"numeric":[">=",7]}]}}'

$ aws events put-targets --rule gd-high \
  --targets Id=sns1,Arn=arn:aws:sns:eu-west-1:111122223333:security-alerts

Aggregating events across accounts and Regions

Real companies have dozens or hundreds of accounts in many Regions. Skill 1.1.3 asks you to aggregate security and monitoring events so one team can see and alert on everything from one place. Three features do most of the work: CloudWatch cross-account observability, cross-account EventBridge event buses and the Security Hub home Region.

Cross-account EventBridge buses and the Security Hub home Region

To send events to another account, the receiving account adds a resource-based policy to its event bus that allows specific accounts or the whole organization (for example with aws:PrincipalOrgID). The sending account creates a rule whose target is that bus ARN; new cross-account bus targets need an IAM role in the sender. The sender pays for the events. Events that arrive from another account are not forwarded again to a third account. For findings, Security Hub CSPM cross-Region aggregation (the aggregation Region is now called the home Region) replicates findings, insights, control statuses and security scores from linked Regions to one home Region, both ways, at no extra cost. It only collects from Regions where Security Hub CSPM is already enabled. Combined with a delegated administrator, one account and one Region see the whole organization. Day 2 goes deeper into Security Hub.

# security account (444455556666): bus policy
{ "Version": "2012-10-17", "Statement": [ {
    "Sid": "AllowOrgPutEvents", "Effect": "Allow", "Principal": "*",
    "Action": "events:PutEvents",
    "Resource": "arn:aws:events:eu-west-1:444455556666:event-bus/security",
    "Condition": { "StringEquals": { "aws:PrincipalOrgID": "o-a1b2c3d4e5" } } } ] }

# member account: forward GuardDuty findings
$ aws events put-targets --rule fwd-guardduty --targets \
  Id=central,Arn=arn:aws:events:eu-west-1:444455556666:event-bus/security,\
RoleArn=arn:aws:iam::111122223333:role/EventBridgeForwardRole

Cheatsheet extras: target permissions, monitoring intervals and alert recipes

Your cheat sheet spends a whole page on troubleshooting alerts that “don’t fire”. The top cause is permissions on the target, especially the difference between a Lambda function’s function policy and its execution role. It also lists a few classic CloudTrail events every security team should alert on, and the EC2 monitoring intervals.

$ aws lambda add-permission --function-name terminate-unapproved \
    --statement-id allow-eb-rule --action lambda:InvokeFunction \
    --principal events.amazonaws.com \
    --source-arn arn:aws:events:eu-west-1:111122223333:rule/unapproved-ec2

# Resulting statement in the function policy
{ "Effect": "Allow",
  "Principal": { "Service": "events.amazonaws.com" },
  "Action": "lambda:InvokeFunction",
  "Resource": "arn:aws:lambda:eu-west-1:111122223333:function:terminate-unapproved",
  "Condition": { "ArnLike": { "AWS:SourceArn":
      "arn:aws:events:eu-west-1:111122223333:rule/unapproved-ec2" } } }

Monitoring intervals and what CloudWatch can’t see

EC2 sends metrics to CloudWatch every 5 minutes for free (basic monitoring). Detailed monitoring sends them every 1 minute for an extra charge, and custom high-resolution metrics can go down to 1 second. Faster data means alarms can react sooner. The hypervisor can’t see inside the guest, so memory, disk space and running processes need the CloudWatch agent (the procstat plugin tracks processes). Older material says “CloudWatch can’t record processes”; today the agent can.

Classic alert recipes from the cheat sheet

Each one works as an EventBridge rule on “AWS API Call via CloudTrail” (fast, per event, needs a trail) or as a metric filter plus alarm on the CloudTrail log group (counts and thresholds). People who only need to look at dashboards and alarms get CloudWatchReadOnlyAccess, not admin rights.

Lecture summary map

Day 1 of Detection on one screen.

1. Mind map

2. Match the requirement to the answer

3. “If the question says… pick…”

Must-remember cheat sheet

Core quiz

Check the basics first. Pick an answer, then press Check.

Hard quiz

Harder than most real exam questions on purpose, with one “choose two” and one matching question. Aim for 9 out of 12 before Day 2.

Practice test questions (from your mock exams)

These 9 questions come from your own SCS-C03 mock exams, matched to today’s topics. Wording was modernized where services were renamed (for example CloudWatch Events is now Amazon EventBridge), and each answer was checked against current AWS behavior; where the mock’s answer key was wrong, the explanation says so. The source (mock and question number) is at the end of each explanation.

Hands-on lab (30 minutes, low cost)

1. Create an SNS topic security-alerts with an email subscription and confirm the email.
2. Edit (or create) a CloudTrail trail so it also sends to a CloudWatch Logs log group. Let the console create the IAM role.
3. Add the CIS unauthorized API calls metric filter from section 03 (namespace LogMetrics, value 1, default 0) and an alarm with Sum ≥ 1 over 5 minutes that notifies the topic.
4. Trigger it: as an IAM user with no EC2 permissions, run aws ec2 describe-instances. CloudTrail can take several minutes to deliver; watch the metric, the alarm going to ALARM, and the email.
5. Create an EventBridge rule with pattern {"source":["aws.guardduty"]} targeting the topic. If GuardDuty is on, use Generate sample findings in its console and watch the emails arrive.
6. Optional: create a Route 53 health check on a public URL and look at its HealthCheckStatus metric in us-east-1.
7. Clean up: delete the alarm, metric filter, EventBridge rule, health check and topic. Remove the CloudWatch Logs delivery from the trail or set a short log retention: CloudWatch Logs charges for ingestion and storage, Route 53 health checks bill monthly, and GuardDuty bills after its free trial.