Lesson 2: Monitoring Requirements and Health Checks

Before we start

This course follows AWS's own SCS-C03 exam guide. The guide isn't reproduced here, and you can download it free from the AWS Certification site. Check the official exam page for the current length, price and languages. This course is independent of AWS and not endorsed by it, and no course can promise you a pass.

This level covers Domain 1: Detection (16%), Task 1.1, Skills 1.1.1 and 1.1.2: analyze workloads to determine monitoring requirements, then design and implement workload monitoring strategies (for example, by configuring resource health checks).

Decide what to monitor first

A common mistake is to turn on every metric and then drown in alerts. A better approach is to work like a building surveyor: look at the plans, find what's valuable, and work out how someone would break in. For any workload, go through three things:

1. Architecture. List the public entry points, such as Route 53 names, load balancers, API Gateway stages and CloudFront distributions. List the dependencies too, such as databases and third-party APIs. Each entry point needs an outside-in health signal. Each component needs inside-out metrics.
2. Data sensitivity. Where does regulated or confidential data live? The more sensitive the data, the tighter your thresholds and the faster your alerts need to reach people.
3. Threat model. What does an attack look like in numbers? Credential stuffing shows up as a spike in 4xx responses on the login path. A DDoS shows up as a jump in request counts and latency. If the attack disables something, the signal is often missing data.

Here's a worked example: a customer portal behind an ALB, served at portal.example.com, holding PII.

Walkthrough 1: an SNS topic for alerts

Every alarm needs somewhere to send its alert.

# Route 53 health check metrics exist only in US East (N. Virginia),
# so build the alerting for them in us-east-1
aws sns create-topic --name sec-alerts --region us-east-1
# -> "TopicArn": "arn:aws:sns:us-east-1:111122223333:sec-alerts"

aws sns subscribe --region us-east-1 \
  --topic-arn arn:aws:sns:us-east-1:111122223333:sec-alerts \
  --protocol email --notification-endpoint secops@example.com
# Email subscriptions stay "PendingConfirmation" until someone clicks the link.

Walkthrough 2: a Route 53 health check

aws route53 create-health-check \
  --caller-reference portal-hc-2026-10-21 \
  --health-check-config '{
    "Type": "HTTPS_STR_MATCH",
    "FullyQualifiedDomainName": "portal.example.com",
    "Port": 443,
    "ResourcePath": "/health",
    "SearchString": "status:ok",
    "RequestInterval": 30,
    "FailureThreshold": 3
  }'
# caller-reference: a unique value that makes retries safe
# HTTPS_STR_MATCH: the body must contain the string, not just return 2xx/3xx
# RequestInterval: 10 or 30 seconds
# FailureThreshold: consecutive failures before a checker calls it unhealthy

How Route 53 decides:

• Health checkers in locations around the world each probe the endpoint. For HTTP(S) checks, each checker needs a TCP connection within 4 seconds and a 2xx/3xx status code within 2 seconds after connecting.
• With string matching, the string must appear in the first 5,120 bytes of the response body.
• If more than 18% of checkers report the endpoint healthy, Route 53 considers it healthy. This stops one isolated network path from flapping the status.

There are three types of health check:

• Endpoint: probes an IP address or domain name.
• Calculated: a parent check that combines up to 255 child checks.
• CloudWatch alarm: follows the alarm's data stream. It doesn't support cross-account alarms.

Gotcha: certificates. HTTPS health checks don't validate SSL/TLS certificates. An expired certificate won't fail the check, so monitor certificates some other way.

Gotcha: firewalls. If security groups or NACLs filter by source IP, allow the ROUTE53_HEALTHCHECKS ranges published in ip-ranges.json. Otherwise your own firewall makes a healthy endpoint look dead.

Walkthrough 3: alarm on the health check

A health check on its own doesn't notify anyone. You alarm on its metric, which lives in the AWS/Route53 namespace in us-east-1 only.

aws cloudwatch put-metric-alarm --region us-east-1 \
  --alarm-name portal-endpoint-unhealthy \
  --namespace AWS/Route53 --metric-name HealthCheckStatus \
  --dimensions Name=HealthCheckId,Value=abcd1234-ef56-7890-abcd-1234567890ab \
  --statistic Minimum --period 60 --evaluation-periods 1 \
  --threshold 1 --comparison-operator LessThanThreshold \
  --treat-missing-data breaching \
  --alarm-actions arn:aws:sns:us-east-1:111122223333:sec-alerts
# HealthCheckStatus is 1 when healthy and 0 when unhealthy, so Minimum < 1 means it failed
# treat-missing-data breaching: for security, silence is suspicious, not fine

Expect a delay of several minutes between a failed check and the SNS email. Design your response time around that.

Walkthrough 4: a metric alarm and a composite alarm

The next alarm covers login abuse. It goes in the workload's own Region, which is eu-west-2 in this example.

aws cloudwatch put-metric-alarm --region eu-west-2 \
  --alarm-name portal-4xx-spike \
  --namespace AWS/ApplicationELB --metric-name HTTPCode_Target_4XX_Count \
  --dimensions Name=LoadBalancer,Value=app/portal-alb/50dc6c495c0c9188 \
  --statistic Sum --period 300 --evaluation-periods 2 \
  --threshold 500 --comparison-operator GreaterThanThreshold
# No --alarm-actions: this alarm is an input to the composite below

The composite alarm sends a page only when the abuse signal and a latency signal fire together:

aws cloudwatch put-composite-alarm --region eu-west-2 \
  --alarm-name portal-likely-attack \
  --alarm-rule 'ALARM("portal-4xx-spike") AND ALARM("portal-high-latency")' \
  --alarm-actions arn:aws:sns:eu-west-2:111122223333:sec-alerts-euw2
# Rule functions: ALARM(), OK(), INSUFFICIENT_DATA(); operators: AND, OR, NOT

The rule above refers to a second metric alarm, portal-high-latency, built the same way on the ALB's TargetResponseTime. It sends its alert to an SNS topic in eu-west-2, because each alarm sends to a topic in its own Region.

Composite alarms can also take an actions suppressor. While the suppressor alarm is in ALARM, for example during a maintenance window, the composite alarm takes no actions. Two cautions: don't create composite alarms that depend on each other, because the cycle stops their evaluation. And keep the child alarms' own notifications off, or you get the noise back.

Choosing the right tool

• Metric alarm: one metric crosses one threshold. Examples are a 4xx spike, CPU usage, or a health check failing.
• Composite alarm: several alarms combined with Boolean logic. Use it to cut noise, to ask for corroborating signals, or to suppress alerts during maintenance.
• Route 53 health check: outside-in reachability and correctness from many locations. It can also drive DNS failover.

What the exam asks about this

Expect scenarios such as: "alerts are too noisy" (use a composite alarm), "we need to know if the public endpoint is reachable from the internet" (use a Route 53 health check plus a CloudWatch alarm and SNS), and "the alarm for the health check never appears" (it was created outside us-east-1). Firewall-blocked checkers and the gap in certificate validation also make good distractors.

Key takeaways

• Work out monitoring requirements from the architecture, data sensitivity and threat model, then map each requirement to a signal.
• A Route 53 health check calls an endpoint healthy when more than 18% of checkers report it healthy. Its metrics live only in us-east-1.
• HTTPS health checks don't validate certificates. Allow the ROUTE53_HEALTHCHECKS IP ranges through your firewalls.
• Use a metric alarm for one signal, a composite alarm to combine signals or cut noise, and a health check for outside-in availability.
• For security alarms, consider treating missing data as breaching.