What Is Amazon CloudWatch? Metrics, Logs, and the $0 Alarm

Amazon CloudWatch is AWS’s built-in monitoring service — the dashboard that shows what your cloud is doing, the diary that keeps every log line your code prints, and the doorbell that wakes you when something breaks. Every AWS account already has it; there is nothing to install and nothing to sign up for. And here is Amazon CloudWatch’s strangest truth, the one that fills the search box with "why is CloudWatch so expensive": the service whose most famous job is warning you about surprise AWS bills is itself one of AWS’s most common surprise bills. Used one way, CloudWatch is genuinely free — including the 2 a.m. billing alarm this series promised you, which we set up below, step by step, at a running cost of $0.00. Used another way — usually by accident — it quietly becomes the biggest line on the invoice, billing more to watch your app than the app costs to run. This post explains how CloudWatch works, exactly where the free ends and the expensive begins, and how to stay on the right side of that line.

Jake learned the difference between watching and paying during a client’s worst week. An API was misbehaving intermittently, so Jake did the textbook thing: turned logging up to maximum — every request, full payload, in and out — found the bug in two days, fixed it, invoiced, moved on. He did not turn the logging back down. A month later the client forwarded their AWS bill with one line highlighted: CloudWatch was the most expensive item on it — more than the compute and the database combined. The app had been whispering ten kilobytes of debug detail into its diary a million times a day, and the diary charges by the page. The fix took four minutes: one log-level setting, one retention rule. Jake’s notebook entry from that evening: "The camera crew cost more than the play."

Ethan: "CloudWatch is two things wearing one badge. There’s the smoke detector — metrics and alarms. It came with the building, it’s always armed, and keeping it armed costs nothing. Then there’s the film crew — logs. They record every word spoken in every room, around the clock, and they charge by the reel. Both are useful. Both are called CloudWatch. Every surprise bill I’ve ever been shown came from someone who hired the film crew believing they’d bought a smoke detector."

The smoke detector and the film crew: what CloudWatch actually is

Strip the console clutter and CloudWatch is three rooms. Metrics are numbers over time — how many requests, how much CPU, how many errors, sampled again and again and drawn as graphs. Logs are text over time — the exact lines your code printed, kept and searchable. Alarms are promises — when this number crosses this line for this long, do that: send an email, run code, wake someone. Everything else in the service — dashboards, Logs Insights, anomaly detection, Live Tail — is furniture inside those three rooms.

The part beginners consistently miss, and the reason monitoring feels like a topic for "later": you are already using CloudWatch. The moment you created your first S3 bucket or ran your first Lambda function, AWS began publishing metrics about it — free, automatically, without asking. The graphs already exist. The logs, if you’ve run any Lambda at all, already exist too. This post isn’t inviting you to adopt a new service; it’s handing you the keys to one you already own.

How does CloudWatch work? Metrics — the pulse you already have

A metric is one number, measured repeatedly: Invocations on a Lambda function, CPUUtilization on an EC2 instance, 4XXError on an API. Nearly every AWS service publishes its own set without being asked — this is called basic monitoring, it samples every five minutes, and it is free. Two upgrades cost money, and both are choices you make on purpose: detailed monitoring tightens the sampling to every minute (billed per metric), and custom metrics — numbers your code reports, like "orders placed" or "photos processed" — run $0.30 per metric per month after the first ten free (prices here and throughout are US East as of August 2026).

Two honest details worth knowing early. First, CloudWatch is regional — metrics live in the region that produced them, so the Virginia console won’t show your Sydney servers; the search phrase "is CloudWatch global or regional" exists because everyone trips on this once. (Cross-region dashboards exist for when you genuinely need one view.) Second, a gotcha with its own FAQ entry below: EC2’s free metrics do not include memory usage. AWS can see your instance from the outside — CPU, disk, network — but what’s happening inside the operating system needs the CloudWatch agent installed, and the agent’s readings arrive as custom metrics, billed accordingly. The agent software itself is free; its chattiness is not.

The CloudWatch agent — when you need the inside view

For serverless pieces — Lambda, API Gateway, DynamoDB — you will never think about the agent; AWS runs the machinery, so AWS does the measuring. The agent enters the story the day you run an actual server, because that is the day you discover the memory gap described above. The honest sequence, so nothing surprises you:

1. Give the instance permission first. The agent talks to CloudWatch, and on AWS nothing talks to anything without an IAM role saying it may — attach the managed CloudWatchAgentServerPolicy to the instance’s role. Skipping this step is the classic reason the agent installs fine and reports nothing.
2. Install it — a package on Linux, an installer on Windows, one command either way; it is free software from AWS.
3. Run the configuration wizard and be deliberately stingy: it will cheerfully offer to collect dozens of readings, and each one you accept is a custom metric at $0.30 a month after your free ten. Memory used and disk free answer most 2 a.m. questions; start there.
4. Check the bill’s shape once after a week — the agent’s metrics appear under the CWAgent namespace, and a quick look confirms you are paying for exactly the numbers you chose and no more.

Logs — the diary your Lambda has been writing all along

Here is the small revelation this series promised back in the Lambda post: every print() statement your Lambda function ever ran went somewhere. That somewhere is CloudWatch Logs. Open the console, find the log group named after your function, and there they are — every run, every line, timestamped, back to the very first "hello". Nobody tells beginners this, and the moment of finding months of your own forgotten output is a genuine rite of passage.

The structure is simple: a log group per application (or per function), log streams inside it for each source, and tools on top — Logs Insights to query across everything with a SQL-ish language ("show me every line containing timeout in the last hour"), and Live Tail to watch lines arrive in real time while you test, with 1,800 free minutes a month, which is an hour of staring a day.

Now the caveat that earns its own section below, stated plainly here because it matters more than anything else on this page: logs are the paid half of CloudWatch. Ingestion — the act of accepting your log lines — costs $0.50 per GB after the free 5 GB each month, and storing them costs $0.03 per GB-month. And one default is set against you: new log groups keep everything forever. Retention ships as "Never expire" — the diary never throws out a page unless you tell it to. It is a thirty-second setting, and we set it in the playbook below.

Alarms — the doorbell, and everything it can do at 2 a.m.

An alarm watches one metric against one rule — errors above five for ten straight minutes, estimated charges above $5 — and changes state: OK, ALARM, or the honest third state people forget, INSUFFICIENT_DATA (no readings arriving, which is its own kind of bad news). The first ten standard alarms are free, $0.10 per metric per month after that — which is why a small project’s entire warning system costs nothing. What makes alarms more than notifications is what they can do:

Read that last row again, because it answers a question people search word for word — can a CloudWatch alarm trigger Lambda? Yes: directly, as a native alarm action, or the traditional way through SNS. A number crosses a line at 2 a.m., and code you wrote months ago quietly fixes the problem before your phone even buzzes. That is monitoring graduating into automation, and it is available on the free ten.

Dashboards, Insights, anomaly detection — the rest of the furniture

Around the three rooms, four pieces of furniture are worth knowing by name. Dashboards pin your chosen graphs to one page — Lambda errors next to API latency next to the bill — so a glance replaces a scavenger hunt; three of them, holding fifty metrics each, are free, and a solo project rarely needs a second. A worthwhile habit from day one: build the dashboard before things break, because the middle of an outage is a terrible time to learn where your graphs live.

Logs Insights is the search engine over your log groups — a small query language that answers questions like "count errors by hour" or "show the slowest twenty requests yesterday." There is a learning curve of about one honest afternoon, and the console’s sample queries carry you through most of it. Remember only that queries are billed by data scanned past the free allowance — one more reason the retention setting in the playbook below is your friend: less haystack, cheaper needle.

Anomaly detection handles the threshold you don’t know how to pick. Instead of guessing "is 200 requests a minute normal?", CloudWatch studies the metric’s own history and draws a gray band of expected behavior — weekday rhythms, nightly lulls — and an alarm can fire when reality leaves the band. It is the polite answer to the most common alarm mistake, which is alarming on a number you made up. And Synthetics canaries flip monitoring from passive to active: small scripts that visit your site or call your API on a schedule, from the outside, like a customer would — so you find out the login page is broken from a robot at 3 a.m. rather than a human at 9. Canaries are paid per run and cheerfully optional at hobby scale; they earn their keep the day real users depend on you.

The $0 billing alarm, step by step — promise kept

This series has told you since the billing post to buckle the seatbelt before driving. Here is the buckle, in seven steps, costing exactly nothing: one free alarm out of ten, notifying one email address through SNS’s free tier (the first thousand email deliveries a month are free, and a billing alarm sends… one).

1. In the AWS Console, open Billing and Cost Management → Billing preferences and turn on "Receive CloudWatch billing alerts." Without this checkbox, billing data never reaches CloudWatch at all.
2. Switch your console region to US East (N. Virginia). This is the one quirk everyone hits: billing metrics live only in us-east-1, whatever region your resources use. If you skimmed the "regional" section above, this is it coming back around.
3. Open CloudWatch → Alarms → Create alarm, choose Select metric → Billing → Total estimated charge, currency USD.
4. Set the condition: Greater than your comfort line. $5 is a good first threshold — low enough to catch a mistake in its first days, high enough to ignore rounding noise.
5. Under notifications, create a new SNS topic, name it something honest like billing-alerts, and enter your email address.
6. Open your inbox and click the confirmation link AWS sends. An unconfirmed subscription silently receives nothing — this missed click is the number-one reason billing alarms "don’t work."
7. Name the alarm, create it, and watch it settle from INSUFFICIENT_DATA to OK as the first readings arrive. Done. You will now hear about a runaway bill in hours, not at month-end.

Take a second to notice what you just built, because it’s easy to undersell: an always-on financial guardian, watching every service in your account, that will still be standing watch years from now — for $0.00 a month. This is CloudWatch at its absolute best, and it is the configuration we quietly assumed in every previous post that said "set the alarm first."

Is AWS CloudWatch free? The honest allowance

Genuinely free, every month, forever — not a twelve-month trial (figures for US East, August 2026):

Look at that table with a solo builder’s eyes and the honest verdict is: for the project this series has you building, CloudWatch is free. The free tier isn’t a teaser here; it’s a complete, permanent monitoring setup. So how do the horror stories happen?

Why is CloudWatch so expensive? The anatomy of the surprise

People genuinely type "why is CloudWatch so expensive" and "how is CloudWatch cost calculated" into search engines, usually the morning after a bill. The answer is that CloudWatch has no single price — it has a menu, and three items on the menu do almost all of the damage:

Now the arithmetic that turns a price list into a story — the same multiplication we did for Lambda, pointed the other way. Take a busy little API: a million requests a day, and someone (a past you, usually) left a debug line printing the full ten-kilobyte payload on every request. That is 10 GB of log ingestion a day — 300 GB a month — about $150 of CloudWatch, to record the diary of a Lambda workload whose actual compute, at that traffic, runs closer to $20. The monitoring out-bills the monitored by seven to one, and nothing malfunctioned: every service did exactly what it was told. The bill isn’t a punishment for logging; it’s a receipt for verbosity. Which means the fix isn’t "log less than you need" — it’s the five-minute playbook below, once, per project.

The cost-control playbook — five settings, five minutes

1. Set retention on every log group. CloudWatch → Log groups → select → Actions → Edit retention. Thirty days is plenty for a hobby project; even 1 year beats "Never expire." This is the single most skipped setting in AWS.
2. Log at levels, not at maximum. INFO for the story, ERROR for the problems, DEBUG only while actively debugging — and turn DEBUG off when the bug dies. Jake’s $150 lesson, one line of config.
3. Never log full payloads in production. Log IDs and outcomes ("order 8841 processed, 240 ms"), not the entire request body. You keep the plot, you drop 95% of the ink.
4. Use Infrequent Access for high-volume, rarely-read logs. Half the ingestion price ($0.25/GB) for logs you’ll only query when something breaks — the compliance-and-just-in-case pile.
5. Alarm on the bill itself. You built this above. The billing alarm is CloudWatch watching CloudWatch — if log costs ever run away, the smoke detector reports the film crew.

"Why is CloudWatch so bad?" — the honest complaints, weighed

People search that exact phrase, so let’s answer it instead of pretending everyone is thrilled. The complaints are real, and they cluster. The console sprawls: metrics, logs, alarms, and dashboards live on separate pages, and following one problem across them feels like walking between buildings — polished rivals put the same story on one screen. The regional split bites: anything running in three regions means checking three consoles or building a cross-region dashboard by hand. It is not to-the-second: standard metrics arrive on five-minute ticks, detailed on one-minute; the delay between an event and its graph frustrates people expecting a live feed. And the pricing needs a map — this post needed two tables for it, which is itself a review.

Here is the weighing, honestly done. Every one of those complaints is about polish, and the paid competition genuinely has more of it. But the case for CloudWatch is structural, not cosmetic: it is already there, in every account, wired into every service, with no agent to deploy for the basics, no vendor contract, and a permanent free tier that fully covers a small project — a sentence no competitor can say. The professional pattern isn’t "CloudWatch versus the fancy tools" anyway: the fancy tools read their AWS data from CloudWatch, which is why their polling shows up on your AWS bill. Learn CloudWatch first — it is the layer underneath whichever dashboard you end up loving. And for the project this series has you running, "free, integrated, and slightly awkward" beats "beautiful and billed per host per month" every month of the year.

Is CloudWatch a SIEM? What CloudWatch is not

A question search engines see constantly, because security teams keep having this meeting: no, CloudWatch is not a SIEM. A SIEM — security information and event management — hunts for intruders: correlating login patterns, flagging impossible travel, matching events against threat intelligence. CloudWatch hunts for malfunctions: error rates, latencies, full disks. A SIEM asks "is someone doing something they shouldn’t?"; CloudWatch asks "is the machine healthy?" They overlap only in that both consume logs — and yes, real SIEMs routinely read from CloudWatch Logs as a source. On AWS, the security-shaped questions belong to other names: GuardDuty for threat detection, Security Hub for posture, and — most importantly for this series — AWS CloudTrail, the service that records who did what in your account: every console click, every API call, every IAM identity attached to every action. Hold that thought; it’s where this series goes next. The one-line separation to keep: CloudWatch tells you what happened. CloudTrail tells you who did it.

What is CloudWatch Events? A rename AWS never finished explaining

If a tutorial tells you to use "CloudWatch Events," it isn’t wrong — it’s old. CloudWatch Events was the piece that reacted to happenings ("an instance stopped") and ran schedules ("every night at 2"). Years ago AWS grew it into a standalone service and renamed it Amazon EventBridge — same underpinnings, bigger ambitions — but the old name survives in a decade of tutorials, in exam questions, and in corners of the console itself. Translation rule: CloudWatch Events = EventBridge. Cron-style schedules that trigger Lambda functions — the "run my scraper every morning" pattern — live there now. CloudWatch kept the metrics, logs, and alarms; EventBridge took the calendar and the reflexes.

What to actually monitor on your first real project

Theory earns its keep when it's wired to something real. If you built the series’ end-to-end project — S3, Lambda, API Gateway, DynamoDB, bill of $0.00 — here is its complete warning system, using four of your ten free alarms:

Four alarms, one SNS topic, one email address — and your project now taps you on the shoulder instead of waiting to be caught broken. That gap matters more than it sounds: the difference between hearing it from your own alarm and hearing it from an annoyed user is, professionally speaking, the whole difference.

One warning about appetite before you go alarm-happy: every alarm you add makes each alarm quieter. Ten thoughtful alarms get answered; fifty twitchy ones get muted, and the real emergency dies in a muted channel — ask any on-call engineer about alarm fatigue and watch their eye twitch. The discipline is simple: alarm only on things you would genuinely get out of bed for, and let the dashboard carry everything that can wait for morning.

Is CloudWatch down? When the watcher blinks

"Is CloudWatch down" spikes in search whenever graphs go flat, and the honest checklist is short. First, flat is not always broken: a metric with no data draws no line, and INSUFFICIENT_DATA on a new alarm usually means "nothing measured yet," not "outage." Second, check the AWS Health Dashboard (health.aws.amazon.com) for the real answer, per region and per service. Third, know the dependency honestly: on the rare bad day when CloudWatch itself has an incident, your applications keep running — you are blind, not broken. Delayed metrics and quiet alarms during a CloudWatch incident are a known failure mode of every monitoring system in existence; it is the reason grown-up operations teams treat "no data" with the same suspicion as bad data. For a solo builder, the takeaway is calmer: don’t redeploy your app because a graph went flat — check the Health Dashboard first.

If you’re here for the certification

CloudWatch is exam-relevant at every level, and the questions are pleasantly predictable. Cloud Practitioner wants the sorting hat: monitoring is CloudWatch, who-did-what auditing is CloudTrail, threat detection is GuardDuty. Solutions Architect Associate leans on the gotchas this post flagged: memory needs the agent, billing metrics live in us-east-1, basic is five minutes and detailed is one, alarms can act (EC2 actions, Auto Scaling, Lambda) and not just notify. SysOps goes deepest — it is the monitoring exam — retention, Logs Insights, cross-account dashboards. If the certificate is your route, our guide to the 2026 certification changes maps the whole track honestly.

FAQ — Amazon CloudWatch, answered straight

What is Amazon CloudWatch in one sentence?

AWS’s built-in monitoring service: metrics (numbers over time), logs (what your code printed), and alarms (act when a number crosses a line) — already active in every AWS account.

Is AWS CloudWatch free?

For a small project, genuinely yes: unlimited basic service metrics, 10 alarms, 10 custom metrics, 5 GB of logs, and 3 dashboards are free every month, permanently. Costs start with heavy logging, metrics at scale, and constant API polling.

How does CloudWatch work?

AWS services publish metrics automatically; your code’s output lands in CloudWatch Logs; alarms watch metrics against rules you set and then notify (via SNS) or act (EC2 actions, Auto Scaling, Lambda). Dashboards draw it all in one place.

Is CloudWatch a SIEM?

No. CloudWatch detects malfunctions; a SIEM detects intruders. Real SIEMs often ingest CloudWatch Logs as a source, but the security jobs on AWS belong to GuardDuty, Security Hub, and CloudTrail.

Is CloudWatch region specific, or global?

Regional — metrics and logs live in the region that produced them, and the console shows one region at a time. The famous exception: billing metrics exist only in US East (N. Virginia). Cross-region dashboards exist when you need one view.

Why is CloudWatch so expensive?

Almost always log ingestion at $0.50/GB: verbose debug logging multiplied by real traffic. Custom metrics per-customer and third-party tools polling GetMetricData are the other two classics. The service isn’t overpriced so much as verbosity is underestimated.

How is CloudWatch cost calculated?

Per ingredient: GB of logs ingested ($0.50, tiered down at large volume) and stored ($0.03/GB-month), custom metrics ($0.30 each after 10), alarms ($0.10 after 10), API reads ($0.01 per thousand after a million), dashboards beyond three. Your bill’s CloudWatch line is the sum of those meters.

Does a CloudWatch alarm cost money?

The first ten standard alarms are free; after that, $0.10 per alarm metric per month. High-resolution alarms (sub-minute checking) cost more. A billing alarm fits comfortably in the free ten.

Can a CloudWatch alarm trigger a Lambda function?

Yes — directly, as a native alarm action, or through an SNS topic the function subscribes to. That’s the standard recipe for self-healing automation.

Can CloudWatch send emails?

Not by itself — alarms publish to an SNS topic, and SNS delivers the email (or SMS, or webhook). Create the topic during alarm setup and confirm the subscription email, or nothing arrives.

Does the CloudWatch agent cost money?

The agent software is free. What it sends is billed normally: memory and disk readings arrive as custom metrics ($0.30/month each after the free 10), and any logs it ships pay standard ingestion.

What is CloudWatch Events?

The old name for what is now Amazon EventBridge — the event-reaction and scheduling service. Any tutorial saying "CloudWatch Events" means EventBridge; cron schedules for Lambda live there.

Is CloudWatch down right now — how do I check?

Check the AWS Health Dashboard (health.aws.amazon.com) for the region and service. A flat graph or INSUFFICIENT_DATA usually means "no data measured," not an outage — and during a genuine CloudWatch incident your apps keep running; you’re blind, not broken.

What is the difference between CloudWatch and CloudTrail?

CloudWatch records what happened (performance, errors, output); CloudTrail records who did it (every API call and console action, tied to an identity). Health versus audit — you want both, for different bad days.

How long does CloudWatch keep metrics and logs?

Metrics: 15 months, automatic, with older data kept at coarser resolution. Logs: forever by default ("Never expire") — and billed for storage the whole time — until you set a retention period per log group. Set one today.

Why doesn’t CloudWatch show my EC2 memory usage?

Because AWS measures your instance from outside (CPU, network, disk I/O), and memory is only visible from inside the operating system. Install the CloudWatch agent to report it — as a custom metric, with custom-metric pricing.

What is Live Tail?

A real-time view of log lines as they arrive — the cloud version of watching a terminal scroll. 1,800 free minutes a month, which is a daily hour of watching your code think.

Do I need CloudWatch if I use Datadog or Grafana?

You’re using it either way — those tools read AWS data from CloudWatch, and their constant GetMetricData polling appears on your AWS bill next to their subscription. For a solo project, CloudWatch alone is plenty; third-party platforms earn their keep at team scale.

Where to go next

Revision note. Written August 28, 2026, after we checked prices against AWS’s pricing pages the same day and stamped "as of August 2026" where they appear — log ingestion rates and free-tier allowances are the kind of numbers AWS revises quietly, so if one has drifted by the time you read this, tell us through the contact page and we will bring the page back to true. This post keeps a promise the series hub has carried for weeks: the $0 alarm is real, it is above, and it took seven steps. The next promise is already made in the SIEM section — AWS CloudTrail in plain English: who pressed the button — because the first question after "what happened?" is always "who did that?". And if you are reading this the morning after a CloudWatch line item ruined your coffee: you are in the best company — that bill is one of the most-searched surprises in AWS, the fix is five settings above, and the diary really was only doing what it was told. Set the retention, drop the debug level, and forgive yourself. Everyone hires the film crew once.