Most CloudWatch monitoring is reactive: a metric alarm fires after latency climbs or error rates spike — which means real users already felt the problem before your pager went off. And if traffic to an endpoint drops to zero because it’s completely broken, some metric-based alarms never fire at all, because “no requests” can look identical to “no problem.” The DOP-C02 exam expects you to close that gap with proactive, synthetic monitoring: continuously testing your endpoints and user journeys on a schedule, whether or not real customers are hitting them, so you detect an outage before anyone reports it.
This guide covers the two AWS services the Monitoring and Logging domain uses for that job — CloudWatch Synthetics (canaries) and CloudWatch RUM (real-user monitoring) — and it clears up the single most common point of confusion in the whole topic: a Synthetics canary and a canary deployment are unrelated things that happen to share a word. It assumes you already know reactive CloudWatch — metrics, alarms, Logs Insights — which the DOP-C02 monitoring and observability guide covers; here we build the proactive layer on top.
First, Kill the Confusion: Canary Monitoring vs Canary Deployment
The word “canary” shows up in two completely different AWS contexts, and the exam knows candidates mix them up.
| Synthetics canary (monitoring) | Canary deployment (release) | |
|---|---|---|
| What it is | A scripted probe that tests an endpoint or workflow on a schedule | A deployment strategy that shifts a small % of traffic to a new version, then the rest |
| Service | CloudWatch Synthetics | CodeDeploy (also ECS/Lambda traffic shifting) |
| Purpose | Detect outages and regressions proactively | Release new code with limited blast radius |
| Example name | A canary that loads /health every minute | Canary10Percent5Minutes |
| Exam signal | ”test the endpoint on a schedule,” “detect an outage before customers" | "shift 10% of traffic, then the rest,” “validate a release in production” |
Both borrow the “canary in a coal mine” metaphor — an early warning — but they solve different problems. If a scenario is about detecting whether something is up, it’s Synthetics. If it’s about releasing a new version safely, it’s a canary deployment, which the DOP-C02 deployment strategies guide covers. Keep the two in separate mental boxes and a whole class of trick questions becomes easy.
CloudWatch Synthetics: Canaries That Test Like a User
A canary is a configurable script that runs on a schedule and exercises your application exactly the way a customer would — loading a URL, calling an API, or clicking through a multi-step workflow — from the outside. Under the hood each canary runs as a managed AWS Lambda function using a Synthetics runtime (Node.js with Puppeteer, or Python with Selenium), so you get real browser or HTTP behavior, not just a TCP ping.
Every run produces rich, debuggable artifacts and metrics:
- CloudWatch metrics in the
CloudWatchSyntheticsnamespace —SuccessPercent,Duration,Failed, and HTTP status counts (2xx,4xx,5xx). You build alarms on these. - Artifacts in Amazon S3 — screenshots, HTTP Archive (HAR) files, and logs for every run, so when a canary fails you can see exactly what the “user” saw.
- CloudWatch Logs for the script’s own output.
The blueprints you should recognize
You rarely write a canary from scratch on the job — the console ships blueprints that generate the script for you. Knowing what each one is for is enough for the exam:
| Blueprint | What it monitors |
|---|---|
| Heartbeat monitoring | Loads a single URL and verifies it returns successfully and (optionally) renders — the classic “is the site up?” check |
| API canary | Issues a sequence of REST API calls with headers/body and validates responses and status codes |
| Broken link checker | Crawls a page and reports links that 404 |
| GUI workflow builder / Canary Recorder | Multi-step browser flows — log in, add to cart, check out — recorded as a script |
| Visual monitoring | Captures a screenshot each run and compares it to a baseline, catching visual/layout regressions |
Scheduling and reaching private endpoints
A canary runs on a rate or cron schedule — as often as once a minute — or as a one-off. To monitor a private endpoint (an internal ALB, a service with no public DNS), you configure the canary to run inside your VPC, and it reaches the target over private networking just like your own workloads.
Turning a failing canary into action
A canary on its own only observes. To make it respond, alarm on its metrics and wire the alarm into your existing remediation path:
Synthetics canary (every 1 min)
│ publishes SuccessPercent, Duration, 4xx/5xx
▼
CloudWatch alarm (SuccessPercent < 100 for 2 datapoints)
│ ALARM
▼
Amazon SNS ──► on-call notification
└────► Lambda / SSM Automation runbook (auto-remediation)That alarm-to-remediation pattern is the same one the incident response and auto-remediation guide develops for reactive alarms — the only difference is that the signal source is a proactive synthetic test rather than a real-traffic metric. A common exam scenario: “a critical login endpoint must be tested continuously, and the on-call engineer paged the moment it breaks, even at 3 a.m. with no live traffic.” The answer is a Synthetics canary + CloudWatch alarm + SNS, not a metric alarm on request latency (which needs live traffic to mean anything).
A minimal canary schedule, in CloudFormation terms
You don’t need to memorize the full resource, but recognize its shape — a canary bundles the script (from S3 or inline), a runtime version, a schedule, and an artifact bucket:
Type: AWS::Synthetics::Canary
Properties:
Name: checkout-heartbeat
RuntimeVersion: syn-nodejs-puppeteer-9.0
ArtifactS3Location: s3://my-canary-artifacts/checkout/
ExecutionRoleArn: !GetAtt CanaryRole.Arn
Schedule:
Expression: "rate(1 minute)"
RunConfig:
TimeoutInSeconds: 60
StartCanaryAfterCreation: true
Code:
Handler: pageLoadBlueprint.handler
S3Bucket: my-canary-scripts
S3Key: checkout-heartbeat.zipCloudWatch RUM: What Real Users Actually Experience
Synthetics tells you whether an endpoint responds to a simulated user from AWS infrastructure. It cannot tell you that customers on a specific mobile browser in a particular region are seeing slow page loads. That’s real-user monitoring (RUM).
CloudWatch RUM collects client-side telemetry from actual browsers. You create an app monitor, embed the generated RUM web client (a JavaScript snippet) in your web application, and it streams back:
- Performance — page load times and Core Web Vitals (LCP, INP, CLS)
- Errors — JavaScript errors and failed requests as real users hit them
- Sessions and journeys — how users move through the app
- Client breakdowns — by browser, device, OS, and geography
RUM data is viewable in the console and can be surfaced as CloudWatch metrics for alarming. Critically, RUM can integrate with AWS X-Ray, linking a slow or failed browser session to the backend trace behind it — end-to-end visibility from the user’s click through every service. (The RUM web client authenticates via a Cognito identity pool so unauthenticated browsers can send data without exposing credentials.)
Synthetics vs RUM: pick the right lens
They are complements, not substitutes, and the exam tests the distinction directly:
| CloudWatch Synthetics | CloudWatch RUM | |
|---|---|---|
| Data source | Simulated users (scripts from AWS) | Real users (their browsers) |
| Runs when | On a schedule, 24/7, even with zero traffic | Only when real users are active |
| Great at | Detecting outages proactively, uptime SLAs, testing critical paths before customers | Understanding real experience, per-browser/geo issues, Core Web Vitals |
| Blind spot | Can’t see problems only real users/devices hit | Can’t detect an outage when no one is online to trigger it |
| Exam signal | ”detect before customers,” “scheduled endpoint test" | "measure actual user experience,” “which browsers are slow” |
The strongest operational answer often uses both: canaries guarantee you learn about an outage first, and RUM explains what real users are living through the rest of the time.
A Note on Feature Flags and Experiments
You may see older material pair Synthetics and RUM with CloudWatch Evidently for feature flags and A/B experiments. Be aware that Evidently reached end of support (October 2025), and AWS now directs feature-flag and progressive-rollout use cases to AWS AppConfig feature flags. For the exam, understand the concept — evaluating a feature per-user at the application layer, and rolling it out gradually — but map it to AppConfig rather than Evidently, and don’t confuse an application-layer feature flag (who sees a feature) with a CodeDeploy canary deployment (which infrastructure gets traffic).
Exam Decision Table
| Scenario | Answer |
|---|---|
| Detect an outage before customers report it | Synthetics canary + alarm + SNS |
| Continuously test a login/checkout workflow on a schedule | Synthetics GUI workflow canary |
| Monitor a private internal endpoint proactively | Synthetics canary configured to run in the VPC |
| Catch visual/layout regressions on a page | Synthetics visual monitoring blueprint |
| Understand real-user page load times by browser/region | CloudWatch RUM |
| Link a slow browser session to its backend trace | RUM + X-Ray |
| Shift 10% of production traffic to a new version, then the rest | CodeDeploy canary deployment (not Synthetics) |
| Gradually expose a new feature to a % of users at the app layer | AWS AppConfig feature flags |
Common DOP-C02 Traps
- Confusing a Synthetics canary with a canary deployment. Monitoring vs release — different services, different purpose.
- Reaching for a metric alarm when there’s no traffic. A latency/error alarm needs live requests to be meaningful; a canary works at 3 a.m. with zero users.
- Assuming RUM detects outages. RUM only sees what real users generate; if everyone’s asleep, it’s silent. Use Synthetics for uptime.
- Forgetting canaries can run in a VPC. Private endpoints are monitorable — you don’t need to make them public.
- Treating a canary as self-healing. A canary detects; you still need an alarm plus an action (SNS, Lambda, or an SSM Automation runbook) to remediate.
- Citing Evidently as a current service. It’s end-of-support — map feature flags to AppConfig.
How to Practice This Topic
Reading the difference between Synthetics and RUM is easy; recalling the right one under exam pressure, inside a dense scenario stem, is the actual skill. Build a heartbeat canary against any public URL, add an API canary with a status-code check, wire a CloudWatch alarm on SuccessPercent, and watch the artifacts land in S3 when you deliberately break the target. Then read a batch of scenario questions and force yourself to name the service and the trap in one line before looking at the options.
Timed, scenario-driven questions are the fastest way to get there. Sailor.sh’s AWS Certified DevOps Engineer – Professional (DOP-C02) Mock Exam Bundle is built around exactly the “which service, which pattern” scenarios the real exam uses, with detailed explanations that reinforce distinctions like canary-monitoring versus canary-deployment so they stick. Use this article to learn the mechanics; use full-length practice to make the recognition automatic. For the complete domain map and logistics, start with the DOP-C02 exam guide for 2026.
Frequently Asked Questions
What is a CloudWatch Synthetics canary?
A canary is a configurable script that runs on a schedule (as a managed Lambda function) to test an endpoint, API, or user workflow from the outside — like a simulated user. It publishes CloudWatch metrics such as SuccessPercent and Duration and stores screenshots, HAR files, and logs in S3 for debugging.
How is a Synthetics canary different from a canary deployment?
They’re unrelated despite the shared word. A Synthetics canary is a monitoring probe (CloudWatch Synthetics) that tests whether something works. A canary deployment is a release strategy (CodeDeploy) that shifts a small percentage of traffic to a new version before the rest. Monitoring versus releasing.
When should I use Synthetics instead of a CloudWatch metric alarm?
Use Synthetics when you need to detect problems proactively, independent of live traffic — testing a critical endpoint on a schedule, catching outages at times of low or zero usage, or validating a full user journey. A metric alarm is reactive and needs real requests to be meaningful.
Can a canary monitor a private endpoint that isn’t on the internet?
Yes. Configure the canary to run inside your VPC and it can reach internal ALBs and private services over private networking, just like your own workloads.
What does CloudWatch RUM add over Synthetics?
RUM captures real user experience from actual browsers — page load times, Core Web Vitals, JavaScript errors, and breakdowns by browser, device, and geography — and can link sessions to backend traces via X-Ray. Synthetics simulates users on a schedule; RUM observes the real ones. Most mature setups use both.
Is CloudWatch Evidently still the answer for feature flags?
No. Evidently reached end of support in October 2025. For feature flags and progressive feature rollouts, use AWS AppConfig feature flags. Know the concept for the exam, but map it to AppConfig.
Key Takeaways
- Proactive beats reactive for detecting outages: Synthetics canaries test on a schedule, even with zero live traffic, so you learn about a break before customers do.
- A Synthetics canary (monitoring) is not a canary deployment (CodeDeploy release) — the shared word is the trap.
- Canaries run as managed Lambda, publish
SuccessPercent/Duration/status metrics, store screenshots and HAR files in S3, can run in a VPC, and only respond when paired with an alarm + SNS/remediation. - RUM measures real-user experience (Core Web Vitals, JS errors, per-browser/geo) and links to X-Ray; Synthetics and RUM are complements.
- Feature flags and experiments now map to AWS AppConfig — Evidently is end-of-support.