canonical: https://jentic.com/apis/amazonaws.com/amazon-cloudwatch

# AWS Amazon CloudWatch

Jentic publishes the only available OpenAPI specification for Amazon CloudWatch, keeping it validated and agent-ready. Amazon CloudWatch is AWS's metric, alarm, and dashboard service for cloud and application observability - it ingests time-series metric data, evaluates static and anomaly-detection alarms, runs Contributor Insights rules, manages metric streams to downstream consumers, and stores configurable dashboards. The 76 endpoints cover PutMetricData ingest, GetMetricData and GetMetricStatistics queries, alarm CRUD with composite alarm support, dashboard JSON management and metric stream provisioning to Kinesis Firehose.

## For AI agents

Push and query time-series metrics, configure metric and composite alarms, manage dashboards, and stream metrics to downstream consumers across an AWS account.

## Scope

Does not handle log ingestion, distributed tracing, or synthetic uptime checks - use for metric publishing, alarms, dashboards, and metric streams only.

## Capabilities

- Publish custom metric data points with dimensions, units, and statistical sets to any namespace
- Query historical metric values with GetMetricData using period, statistic, and metric math expressions
- Configure metric alarms (static thresholds and anomaly-detection bands) and composite alarms that combine other alarms
- Manage CloudWatch dashboards as versioned JSON, including widget layout and per-widget metric queries
- Run Contributor Insights rules over CloudWatch Logs to surface top-N contributors against a metric
- Stream filtered metrics to Kinesis Firehose destinations for ingestion into data warehouses
- Tag CloudWatch resources for cost allocation and apply per-resource IAM policies

## Use cases

### Publish and Query Custom Application Metrics

Engineering teams need a place to ship custom application metrics - request counts, queue depths, business KPIs - and query them for dashboards and alerts. CloudWatch's PutMetricData accepts batched data points with dimensions and statistical sets, and GetMetricData runs metric math expressions across them with up to a one-second resolution. The same data backs alarms and dashboards without needing a separate time-series database.

Example prompt: Call PutMetricData with namespace=MyApp, MetricName=OrdersProcessed, dimensions=[{Name:Service,Value:checkout}], and a value, then query the same metric with GetMetricData over the last hour

### Drive Auto-Remediation From Composite Alarms

Production runbooks often need to trigger only when several conditions hold simultaneously - high error rate AND high latency AND a recent deploy. CloudWatch composite alarms combine other alarms with boolean expressions and notify SNS or trigger Systems Manager actions. An agent can wire up the constituent alarms, build the composite expression, and attach actions for paging or rollback.

Example prompt: Call PutMetricAlarm for ErrorRateHigh and LatencyHigh, then PutCompositeAlarm with AlarmRule='ALARM(ErrorRateHigh) AND ALARM(LatencyHigh)' and an SNS topic action

### Stream a Filtered Metric Set Into a Data Lake

Organisations centralising telemetry in a data lake need a continuous feed of CloudWatch metrics rather than polling GetMetricData on a schedule. Metric streams push selected namespaces and metric names through Kinesis Firehose to S3, Splunk or third-party observability platforms in OpenTelemetry or JSON formats. An agent can filter by namespace and provision the stream end-to-end without writing collector code.

Example prompt: Call PutMetricStream with a filter for namespace=AWS/Lambda, an OutputFormat of opentelemetry0.7, and a Kinesis Firehose ARN as the destination

### AI Agent Integration for Observability Operations

Through Jentic, an SRE-style agent can manage CloudWatch entirely through natural-language intents - query metrics, create alarms, edit dashboards, mute actions during a deploy. Jentic resolves each intent to the right CloudWatch operation and brokers SigV4 credentials, so on-call automation can be built from LLM tool calls rather than bespoke boto3 scripts.

Example prompt: Resolve the intent 'create a CloudWatch alarm on Lambda errors' via Jentic search, load the PutMetricAlarm schema, and execute it with a metric, threshold, period and SNS action

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | /#Action=PutMetricData | Publish custom metric data points |
| POST | /#Action=GetMetricData | Query metric data with metric math expressions |
| POST | /#Action=PutMetricAlarm | Create or update a metric alarm |
| POST | /#Action=PutCompositeAlarm | Create or update a composite alarm |
| POST | /#Action=DescribeAlarms | List alarms with filters by state and prefix |
| POST | /#Action=PutDashboard | Create or update a dashboard JSON definition |
| POST | /#Action=PutMetricStream | Provision a metric stream to Kinesis Firehose |
| POST | /#Action=DeleteAlarms | Delete one or more alarms |

## Key resources

- **Metrics** — Publish, query, and list time-series metric data with dimensions
- **Alarms** — Create, describe, enable, disable, and delete metric and composite alarms
- **Anomaly Detectors** — Configure machine-learning anomaly detection bands on metrics
- **Dashboards** — Manage CloudWatch dashboard JSON definitions and widgets
- **Insight Rules** — Run Contributor Insights rules over CloudWatch Logs to surface top contributors
- **Metric Streams** — Stream filtered metrics to Kinesis Firehose destinations
- **Tags** — Tag and untag CloudWatch resources for cost allocation

## Why Jentic

- **Setup:** Wiring Amazon CloudWatch by hand means implementing Signature Version 4 signing, resolving the regional monitoring host, and building the query-style Action parameters yourself. Through Jentic you install once, import CloudWatch from the API Directory, store the AWS keys once, and your agent calls it.
- **Permission scoping:** CloudWatch is an action API where metric names, alarms, and dashboards travel in the request body, so scope the agent to the operations it needs, such as PutMetricData, GetMetricData, and DescribeAlarms. You choose the operations it may call, so ones like alarm deletion are not included unless you add them.
- **Credential handling:** Your AWS access keys are stored once, encrypted, by your own Jentic One instance and each request is signed with Signature Version 4 at execution time. They never enter the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'create a CloudWatch alarm on Lambda errors' or 'publish a custom metric', and Jentic returns the matching CloudWatch operation with its input schema, so the agent calls PutMetricAlarm or PutMetricData without browsing the reference docs.

## Related APIs

- **Amazon CloudWatch Logs** — CloudWatch Logs ingests log data that backs metric filters and Contributor Insights rules in CloudWatch
- **Amazon EventBridge** — EventBridge routes CloudWatch alarm state changes to Lambda, Step Functions and other targets for remediation
- **AWS X-Ray** — X-Ray adds distributed tracing alongside CloudWatch's metrics and alarms
- **Amazon CloudWatch Application Insights** — Application Insights auto-discovers metrics and alarms for common workloads

## FAQ

### Why is there no official OpenAPI spec for Amazon CloudWatch?

AWS does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call Amazon CloudWatch via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer.

### What authentication does the Amazon CloudWatch API use?

CloudWatch is signed with AWS Signature Version 4 using IAM access keys. Permissions are governed by the cloudwatch:* actions, with separate IAM scopes for PutMetricData, alarm management, dashboards and metric streams. Through Jentic, those AWS credentials sit in your Jentic One instance and are used to sign each request on the agent's behalf.

### Can I publish high-resolution metrics with the CloudWatch API?

Yes. PutMetricData accepts a StorageResolution of 1 (one second) on individual data points to support high-resolution metrics, alongside the default 60-second resolution. High-resolution metrics are billed at a higher rate and surface in alarms with periods as low as 10 seconds.

### What are the rate limits for CloudWatch?

PutMetricData supports up to 1,000 metric data points per request and is throttled per-account per-region; AWS publishes service quotas that can be raised on request. Treat throttling as expected at high cardinality and batch metrics by namespace and dimension before sending.

### How do I create a CloudWatch alarm through Jentic?

Use the Jentic search query 'create a CloudWatch alarm', load the PutMetricAlarm schema, and execute it with AlarmName, MetricName, Namespace, Threshold, Period, ComparisonOperator and an SNS topic ARN as the AlarmAction. Jentic signs the request with SigV4 on the agent's behalf.

### How does anomaly detection work in CloudWatch?

Call PutAnomalyDetector with a Namespace, MetricName and Stat to build a learned baseline band for that metric, then reference the anomaly detection band in a PutMetricAlarm via the ThresholdMetricId field instead of a static Threshold. The alarm fires when the metric leaves the modelled band.

### Can I limit what my agent is allowed to do with the Amazon CloudWatch API?

Yes. Because you run Jentic One yourself, your own rules decide which CloudWatch operations and credentials the agent can use. CloudWatch is an action API where metric names, alarms, and dashboards travel in the request body, so you scope the agent to only the operations it needs, such as PutMetricData, GetMetricData, and DescribeAlarms. Higher-impact operations like alarm deletion are not available to the agent unless you explicitly add them.