CloudWatch via SDK Best Practices

Q: What's the single biggest CloudWatch cost mistake?

High-cardinality custom metrics via raw PutMetricData dimensions. A per-customer or per-request-id dimension multiplies billed metrics fast - move that data to EMF instead.

Q: How do I stop Logs Insights queries from getting expensive or slow?

Narrow the time range, always add a limit, and cancel anything unexpectedly long-running with StopQuery instead of letting it scan to its limit.

This is the checklist to run before shipping a CloudWatch-based observability setup beyond the Core section's single metric and alarm.

Each item is a rule stated positively, with a one-line rationale. The groups run in the same order this section covers: metrics, EMF, logs, alarms, and dashboards.

How to Use This List

Treat each box as an audit question against your own monitoring code.
The groups follow this section's page order: custom metrics, EMF, Logs Insights, composite/anomaly alarms, dashboards.
Revisit this list whenever you add a new service's metrics or a new alarm.
Most rules apply whether the CloudWatch resources are provisioned from the SDK or from IaC.

A - Custom Metrics (PutMetricData)

Batch MetricDatum entries into one call. PutMetricData accepts up to 1,000 items per call; batching cuts request count and cost versus one call per metric.
Set an explicit Unit on every metric. An unset unit defaults to None, making graphs and alarms harder to read correctly.
Bound dimension cardinality deliberately. Each unique namespace/name/dimension combination is a separately billed metric - avoid per-customer or per-request-id dimensions here.
Match dimensions exactly between publish and alarm. An alarm only sees a metric whose dimensions match what you published, name and value both.
Pick a period you can act on. Sub-minute (high-resolution) custom metrics cost more and add noise; 60 or 300 seconds fits most cases.

B - Embedded Metric Format (EMF)

Use EMF for high-cardinality custom metrics. It amortizes cost into log ingestion instead of multiplying billed metrics per dimension value.
Always include the full _aws.CloudWatchMetrics envelope. A JSON log without it is just a log line - no metric gets extracted.
Keep dimension field names in sync with the JSON object. Dimensions arrays must reference keys that actually exist alongside the metric values.
Remember EMF is a log format, not an API call. There is no PutEmbeddedMetric operation - it rides on PutLogEvents or plain stdout in Lambda.
Keep low-cardinality core metrics on direct PutMetricData. EMF is not a wholesale replacement - use it where cardinality actually demands it.

C - Logs & Logs Insights

Scope query time ranges narrowly. A wide startTime/endTime window over a busy log group risks hitting the per-query scan limit.
Always set a limit in the query string. Without one, fields and stats queries can return far more rows than you need.
Poll GetQueryResults with a bound. Cap total polling attempts or elapsed time, and call StopQuery on anything stuck or unexpectedly expensive.
Treat the query language as opaque text. fields/filter/stats/sort is a distinct syntax passed as a plain string - there is no field-by-field query builder to fight.
Query across log groups instead of duplicating calls. logGroupNames accepts more than one group per query when a request fans out across services.

D - Alarms, Composite Alarms & Anomaly Detection

Alarm on rates or anomaly bands, not raw counts. Raw counts scale with traffic and cause flapping alerts; metric math or ANOMALY_DETECTION_BAND stays meaningful across traffic levels.
Wire every alarm's AlarmActions somewhere. An alarm with no action changes state silently - route it to an SNS topic or other target.
Combine related alarms with a composite AlarmRule. Reduce paging noise by requiring several conditions (ALARM(a) AND ALARM(b)) before notifying anyone.
Give anomaly detectors time to learn. Expect INSUFFICIENT_DATA for roughly the first two weeks, and don't page on it during that window.
Set TreatMissingData deliberately. Choose notBreaching, breaching, or ignore based on what missing data should mean for that specific alarm.
Use NOT to suppress alarms during maintenance. Reference a maintenance-window alarm with NOT in a composite AlarmRule instead of disabling alarms manually.

E - Dashboards as Code

Generate dashboards from code, not hand-editing. Build the JSON widget layout programmatically so it stays reproducible across environments.
Set region explicitly per widget. Metric and log widgets viewed from a different default region can render blank without it.
Read-modify-write the whole DashboardBody. There is no per-widget patch operation - PutDashboard always replaces the full layout for that name.
Pick one source of truth per dashboard. Manual Console edits get silently overwritten by the next code-driven PutDashboard call.
Validate generated JSON before sending. Parse it locally first; a malformed widget only surfaces as a Console rendering error otherwise.

FAQs

What's the single biggest CloudWatch cost mistake?

High-cardinality custom metrics via raw PutMetricData dimensions. A per-customer or per-request-id dimension multiplies billed metrics fast - move that data to EMF instead.

Why alarm on rates instead of counts?

Raw counts scale with traffic, so a busy period looks the same as a broken one. A rate, percentage, or anomaly band stays meaningful regardless of traffic level, giving a stabler signal.

How do I stop Logs Insights queries from getting expensive or slow?

Narrow the time range, always add a limit, and cancel anything unexpectedly long-running with StopQuery instead of letting it scan to its limit.

Do composite alarms replace ordinary alarms?

No, they sit on top of ordinary alarms, combining their states with boolean logic. You still need the underlying PutMetricAlarm alarms to exist first.

How long before anomaly detection is trustworthy?

About two weeks, long enough to learn daily and weekly seasonality. Treat earlier INSUFFICIENT_DATA states as expected, not a bug.

Should dashboards be hand-built in the Console?

For a single, rarely-changed dashboard, that's fine. Once you need the same layout across environments or want it regenerated automatically, move to code-generated PutDashboard JSON and treat it as the source of truth.

Is EMF always cheaper than PutMetricData?

Not universally - it's specifically cheaper at high cardinality, since it rides on log ingestion instead of multiplying billed metrics per dimension value. Low-cardinality core metrics often still fit direct PutMetricData well.

CloudWatch's Metrics/Logs/Alarms/Events Model - the four-pillar model these rules apply to.
Custom Metrics & Embedded Metric Format (EMF) - the cost trade-off behind group A and B.
Composite Alarms & Anomaly Detection - the alarm-noise rules in group D.
Dashboards as Code via SDK - the generation habits in group E.

Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+).

CloudWatch via SDK Best Practices

This is the checklist to run before shipping a CloudWatch-based observability setup beyond the Core section's single metric and alarm.

Each item is a rule stated positively, with a one-line rationale. The groups run in the same order this section covers: metrics, EMF, logs, alarms, and dashboards.

How to Use This List

Treat each box as an audit question against your own monitoring code.
The groups follow this section's page order: custom metrics, EMF, Logs Insights, composite/anomaly alarms, dashboards.
Revisit this list whenever you add a new service's metrics or a new alarm.
Most rules apply whether the CloudWatch resources are provisioned from the SDK or from IaC.

A - Custom Metrics (PutMetricData)

Batch MetricDatum entries into one call. PutMetricData accepts up to 1,000 items per call; batching cuts request count and cost versus one call per metric.
Set an explicit Unit on every metric. An unset unit defaults to None, making graphs and alarms harder to read correctly.
Bound dimension cardinality deliberately. Each unique namespace/name/dimension combination is a separately billed metric - avoid per-customer or per-request-id dimensions here.
Match dimensions exactly between publish and alarm. An alarm only sees a metric whose dimensions match what you published, name and value both.
Pick a period you can act on. Sub-minute (high-resolution) custom metrics cost more and add noise; 60 or 300 seconds fits most cases.

B - Embedded Metric Format (EMF)

Use EMF for high-cardinality custom metrics. It amortizes cost into log ingestion instead of multiplying billed metrics per dimension value.
Always include the full _aws.CloudWatchMetrics envelope. A JSON log without it is just a log line - no metric gets extracted.
Keep dimension field names in sync with the JSON object. Dimensions arrays must reference keys that actually exist alongside the metric values.
Remember EMF is a log format, not an API call. There is no PutEmbeddedMetric operation - it rides on PutLogEvents or plain stdout in Lambda.
Keep low-cardinality core metrics on direct PutMetricData. EMF is not a wholesale replacement - use it where cardinality actually demands it.

C - Logs & Logs Insights

Scope query time ranges narrowly. A wide startTime/endTime window over a busy log group risks hitting the per-query scan limit.
Always set a limit in the query string. Without one, fields and stats queries can return far more rows than you need.
Poll GetQueryResults with a bound. Cap total polling attempts or elapsed time, and call StopQuery on anything stuck or unexpectedly expensive.
Treat the query language as opaque text. fields/filter/stats/sort is a distinct syntax passed as a plain string - there is no field-by-field query builder to fight.
Query across log groups instead of duplicating calls. logGroupNames accepts more than one group per query when a request fans out across services.

D - Alarms, Composite Alarms & Anomaly Detection

Alarm on rates or anomaly bands, not raw counts. Raw counts scale with traffic and cause flapping alerts; metric math or ANOMALY_DETECTION_BAND stays meaningful across traffic levels.
Wire every alarm's AlarmActions somewhere. An alarm with no action changes state silently - route it to an SNS topic or other target.
Combine related alarms with a composite AlarmRule. Reduce paging noise by requiring several conditions (ALARM(a) AND ALARM(b)) before notifying anyone.
Give anomaly detectors time to learn. Expect INSUFFICIENT_DATA for roughly the first two weeks, and don't page on it during that window.
Set TreatMissingData deliberately. Choose notBreaching, breaching, or ignore based on what missing data should mean for that specific alarm.
Use NOT to suppress alarms during maintenance. Reference a maintenance-window alarm with NOT in a composite AlarmRule instead of disabling alarms manually.

E - Dashboards as Code

Generate dashboards from code, not hand-editing. Build the JSON widget layout programmatically so it stays reproducible across environments.
Set region explicitly per widget. Metric and log widgets viewed from a different default region can render blank without it.
Read-modify-write the whole DashboardBody. There is no per-widget patch operation - PutDashboard always replaces the full layout for that name.
Pick one source of truth per dashboard. Manual Console edits get silently overwritten by the next code-driven PutDashboard call.
Validate generated JSON before sending. Parse it locally first; a malformed widget only surfaces as a Console rendering error otherwise.

FAQs

What's the single biggest CloudWatch cost mistake?

High-cardinality custom metrics via raw PutMetricData dimensions. A per-customer or per-request-id dimension multiplies billed metrics fast - move that data to EMF instead.

Why alarm on rates instead of counts?

Raw counts scale with traffic, so a busy period looks the same as a broken one. A rate, percentage, or anomaly band stays meaningful regardless of traffic level, giving a stabler signal.

How do I stop Logs Insights queries from getting expensive or slow?

Narrow the time range, always add a limit, and cancel anything unexpectedly long-running with StopQuery instead of letting it scan to its limit.

Do composite alarms replace ordinary alarms?

No, they sit on top of ordinary alarms, combining their states with boolean logic. You still need the underlying PutMetricAlarm alarms to exist first.

How long before anomaly detection is trustworthy?

About two weeks, long enough to learn daily and weekly seasonality. Treat earlier INSUFFICIENT_DATA states as expected, not a bug.

Should dashboards be hand-built in the Console?

Is EMF always cheaper than PutMetricData?

CloudWatch's Metrics/Logs/Alarms/Events Model - the four-pillar model these rules apply to.
Custom Metrics & Embedded Metric Format (EMF) - the cost trade-off behind group A and B.
Composite Alarms & Anomaly Detection - the alarm-noise rules in group D.
Dashboards as Code via SDK - the generation habits in group E.

Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+).

CloudWatch via SDK Best Practices

Buscar en la documentación

CloudWatch via SDK Best Practices