AWS CloudWatch Synthetics Canary

 


Synthetic monitoring — often called synthetic canaries — is your system’s way of sending fake users through your application to make sure everything is working, even when no real users are around. It’s proactive, predictable, and designed to catch issues before customers feel the pain.

Synthetic monitoring is automated, scripted traffic that runs on a schedule to test your application’s key flows.

A “synthetic canary” is simply:

A small, automated script that runs repeatedly to detect problems early — like a canary in a coal mine.

It’s not tied to deployments. It’s not real user traffic. It’s not a canary release.

It’s a monitoring probe.


Creating Canary in AWS:

I am going to configure canary for this demo endpoint https://dummy.restapiexample.com/api/v1/employees



Click on “Create Canary”.

Select “Heartbeat monitoring”.


If you would like to save the screenshot of the output to a S3 bucket, enable the checkbox.


Select the regions from where API must be tested.


Select the “Script editor”.


Above is the canary script that gets automatically created.

Select the schedule to run the canary.


Select the “Timeout” if needed.

Select the “Data Storage” to store the canary results:


Finally, click “Create Canary”.

It takes ~ 5 mins to create canary.


Wait for the canary to move from “Starting” to “Running” state.

We could see the “Last Run Status” as Passed. Which shows our canary is working fine.


Duration to perform the last canary was 462 ms.


Behind the scenes, it creates a lambda function which is invoked via event bridge rule to perform the test.

Why are we having 2 lambdas?

We are doing canary via 2 browsers “Chrome” and “Firefox”.  Hence, we see two lambdas.

Let’s look at the CloudWatch Metrics:


Looking at the output of the S3 bucket:



Comments

Popular posts from this blog

Agentic AI - Series 3

Agentic AI - Series 4

S3 - Directory Bucket