Lesson 2: CloudWatch Metrics: Namespaces, Dimensions, Custom Data

Why metrics come first

Everything in Domain 1 builds on CloudWatch metrics: alarms, dashboards, Auto Scaling policies and automated fixes. If you misread how a metric is identified or summarised, your alarm may never fire, or it may fire every night at 2 a.m. for no reason. This level covers how a metric is built and how you publish your own. (As a reminder from Level 1: the exam guide belongs to AWS and is free on its website. The exam has 65 questions, 50 of them scored, runs 130 minutes and needs a scaled 720 to pass. This course is independent of AWS and can't promise you a pass.)

An analogy: CloudWatch is a filing cabinet of time series.

• Namespace is the drawer. AWS services use AWS/{service}, so you get AWS/EC2, AWS/RDS and so on. Every data point you publish must name a namespace, because there is no default. Pick your own name, such as Shop/Checkout, and do not start it with AWS/.
• Metric name is the folder, for example CPUUtilization.
• Dimensions are labels on the folder, written as name/value pairs like InstanceId=i-0abc…. You can have up to 30 per metric. A dimension is part of the metric's identity, so every new combination of values creates a separate metric.
• Data points are the pages: a timestamp, a value and an optional unit.

Metrics exist only in the Region where they were created. You cannot delete them. A metric expires after 15 months with no new data.

Statistics and periods: how raw points become a number

A statistic summarises the data points inside a period. A period can be 1, 5, 10 or 30 seconds, or any multiple of 60. The default is 60. The common statistics are Average, Minimum, Maximum, Sum and SampleCount, plus percentiles such as p99.

Here is how to pick one:

A real-world example: an API averages 120 ms, so the dashboard looks green. But p99 is 4 s, so one request in a hundred is painfully slow. When a question mentions "some users" or "tail latency", the answer is almost always a percentile.

Gotcha: percentiles need raw values. If you send a pre-aggregated statistic set (--statistic-values Sum=…,Minimum=…,Maximum=…,SampleCount=…), you generally can't get percentiles back. Percentiles also don't work when any value is negative.

Walkthrough: publish a custom metric

AWS services publish their own metrics. For business or application numbers, you push them yourself. CloudWatch never pulls data from you.

# Standard resolution (stored at 1-minute granularity), one dimension
aws cloudwatch put-metric-data \
  --namespace "Shop/Checkout" \
  --metric-name OrdersPlaced \
  --dimensions Environment=prod \
  --unit Count \
  --value 42
# Success returns nothing (HTTP 200, empty body).
# A new metric can take up to 2 minutes to return statistics,
# and up to 15 minutes to show up in list-metrics.

Read it back. Note that get-metric-statistics uses a different dimension syntax:

aws cloudwatch get-metric-statistics \
  --namespace "Shop/Checkout" --metric-name OrdersPlaced \
  --dimensions Name=Environment,Value=prod \
  --statistics Sum SampleCount \
  --start-time 2026-10-17T09:00:00Z --end-time 2026-10-17T10:00:00Z \
  --period 300

Gotcha, and a favourite on the exam: CloudWatch does not combine your custom metrics across dimensions. If you publish with Environment=prod,Host=web1, a query for just Environment=prod returns nothing. You must ask for exactly the dimension combination you published. Some AWS metrics, like AWS/EC2, can be combined across dimensions. Your own metrics can't.

High-resolution metrics

Custom metrics can be standard resolution (1-minute granularity) or high resolution (1-second granularity). All AWS service metrics are standard resolution by default.

# High resolution: --storage-resolution 1 (the default, 60, means standard)
aws cloudwatch put-metric-data \
  --namespace "Shop/Checkout" \
  --metric-name QueueDepth \
  --storage-resolution 1 \
  --unit Count --value 317

You can read high-resolution data at periods of 1, 5, 10 or 30 seconds, or any multiple of 60. There is a trade-off in retention, because CloudWatch rolls data up as it ages:

So a 1-second spike from last week is now just part of a 1-minute (or coarser) data point. Cost matters too: you pay for every PutMetricData call, so publishing every second is expensive. Batch values into one call where you can. One request can carry up to 1,000 metrics, and the Values/Counts arrays hold up to 150 values per metric while keeping percentiles available. AWS now suggests OpenTelemetry for new custom-metric code, but put-metric-data is what you need to know for exam questions.

EC2: basic vs detailed monitoring

• Basic monitoring is the default and free. Instance metrics arrive in 5-minute periods. Status check metrics (StatusCheckFailed, _Instance, _System, _AttachedEBS) arrive every 1 minute at no charge.
• Detailed monitoring costs extra and gives you 1-minute periods.

aws ec2 monitor-instances   --instance-ids i-1234567890abcdef0   # turn on detailed
aws ec2 unmonitor-instances --instance-ids i-1234567890abcdef0   # back to basic
# At launch: aws ec2 run-instances ... --monitoring Enabled=true

In CloudFormation, set Monitoring: true on AWS::EC2::Instance.

What EC2 does not report by default: the hypervisor only sees the instance from the outside. You get CPUUtilization, NetworkIn/Out, NetworkPacketsIn/Out, DiskRead/WriteOps (instance store only), EBS metrics for Nitro-based instances, CPU credit metrics and status checks. You do not get memory usage, disk-space (filesystem) usage or swap, because those live inside the guest OS. To get them, something inside the instance has to publish them. That is the CloudWatch agent, covered in the next level.

Production tip: detailed monitoring doesn't change your EBS volume metrics. Also, a 1-minute alarm on a basic-monitoring instance just sees gaps, so set alarm periods at or above the metric's resolution.

What the exam asks about this

• Pick the statistic for a scenario: p99/p95 for tail latency, Sum for counts, Maximum for any-spike.
• "Custom metric shows no data": usually a dimension mismatch, the wrong Region, or a metric that is too new.
• Sub-minute visibility means a high-resolution custom metric (--storage-resolution 1). Remember the 3-hour retention.
• Five-minute graphs mean basic monitoring. The fix is monitor-instances (detailed monitoring).
• "Memory or disk-space metric missing" means EC2 doesn't publish it, so you need the agent.

Key takeaways

• A metric is identified by namespace + name + dimensions. Each unique dimension combination is a separate metric, and custom metrics are never combined across dimensions.
• Statistics summarise data per period. Use percentiles when the average hides problems, and send raw values if you need them.
• put-metric-data publishes custom metrics. --storage-resolution 1 makes them high resolution, which is kept at that granularity for only 3 hours.
• EC2 basic monitoring gives 5-minute data for free (status checks every 1 minute). Detailed monitoring gives 1-minute data for a fee.
• EC2 never reports memory or disk-space usage on its own.