.png)
Amazon CloudWatch Integration Guide
Connect Amazon CloudWatch metrics, logs, alarms, and operational events with enterprise systems through authenticated AWS service APIs and AWS-supported event intermediaries.
Amazon CloudWatch integration options at a glance
Amazon CloudWatch provides HTTPS service APIs for publishing and retrieving metrics, managing alarms and dashboards, and querying CloudWatch Logs. These APIs use AWS service protocols and Signature Version 4 rather than a conventional resource-oriented REST model. Alarm notifications and supported AWS events can be routed through Amazon SNS or Amazon EventBridge, while high-volume logs can use AWS subscription destinations. Martini can consume the APIs, sign requests through a controlled AWS authentication configuration, expose an endpoint for intermediary-delivered notifications, schedule metric or alarm synchronization, and map or transform observability data for incident, analytics, or monitoring platforms.
| Integration point | Supported by Amazon CloudWatch? | Common use cases | How Martini supports it |
|---|---|---|---|
| HTTPS service APIs | Limited | Use CloudWatch APIs to publish metrics, retrieve metric series, manage alarms and dashboards, and operate on CloudWatch Logs. These are AWS service APIs rather than conventional resource-oriented REST APIs. | Martini can consume HTTPS APIs through workflows and reusable services. AWS request signing, region selection, credentials, and request details must be configured for the target CloudWatch API. |
| Bulk and asynchronous APIs | Yes | PutMetricData publishes batches of metric data, GetMetricData retrieves multiple time series, and CloudWatch Logs supports batched log operations and asynchronous Logs Insights queries. | Martini can construct bounded batches, orchestrate asynchronous start-and-retrieve operations, map responses, and apply retry or checkpoint logic. |
| Webhooks and outbound callbacks | Limited | CloudWatch alarms can publish notifications to supported AWS targets, and supported AWS events can be routed through EventBridge. CloudWatch does not provide a universal direct webhook for every metric, log, or alarm operation. | Martini can expose an authenticated API endpoint for SNS, EventBridge, Lambda, or another supported intermediary and can validate and process incoming event payloads. |
| Metrics ingestion and retrieval | Yes | PutMetricData publishes custom measurements, while GetMetricData, GetMetricStatistics, and ListMetrics support metric retrieval, discovery, filtering, and statistics. | Martini can map business or operational values to namespaces, metric names, dimensions, timestamps, units, and values, or normalize retrieved series for another platform. |
| CloudWatch Logs APIs | Yes | CloudWatch Logs APIs support log groups, log streams, log events, filtering, retention, subscription configuration, and Logs Insights query operations. | Martini can retrieve or publish selected log data, run bounded query workflows, redact sensitive fields, and forward normalized events to enterprise systems. |
| Database and analytics access | Limited | Logs Insights, Metrics Insights, metric statistics, and metric data queries provide analytics capabilities, but CloudWatch does not expose relational database access. | Martini can orchestrate query requests and transform results, while relational persistence can be handled through a separately configured database endpoint. |
| Authentication | Yes | CloudWatch uses IAM authorization, AWS Signature Version 4, IAM roles, temporary STS credentials, policies, and region-specific service endpoints. | Martini can keep credentials, role assumptions, regions, and signing configuration in protected environment configuration or secrets and use them in API workflows. |
| File and attachment APIs | No | CloudWatch is not a general file or document management system. Some APIs can return rendered metric widget images, but this is not a general file exchange mechanism. | Martini should use CloudWatch APIs for observability data and connect separately to a file or object-storage endpoint when file exchange is required. |
How Amazon CloudWatch exposes data and business events
Amazon CloudWatch HTTPS service APIs
CloudWatch exposes HTTPS service APIs for metrics, alarms, dashboards, CloudWatch Logs, anomaly detection, and related operations. Requests use AWS service protocols and require the correct region, service endpoint, IAM authorization, and Signature Version 4 signing rather than a conventional REST resource model.
Martini implementation pattern
Martini implementation pattern: a workflow prepares a signed CloudWatch request, invokes the selected operation, handles response pagination or asynchronous query state, maps the result to a canonical model, and writes it to a target system or stores a checkpoint.
Implementation sequence
Metrics ingestion and retrieval
CloudWatch supports custom metric publication through PutMetricData and metric retrieval through GetMetricData, GetMetricStatistics, and ListMetrics. Metric queries can use namespaces, names, dimensions, time ranges, periods, and statistics.
Martini implementation pattern
Martini implementation pattern: a scheduled or API-triggered workflow retrieves only the required metric windows or receives business data, normalizes dimensions and timestamps, and either forwards measurements or publishes them to CloudWatch in bounded batches.
Implementation sequence
CloudWatch Logs APIs and Insights
CloudWatch Logs supports log groups, streams, log events, filtering, publishing, and Logs Insights queries. Logs Insights query execution can be asynchronous, requiring a start operation followed by result retrieval.
Martini implementation pattern
Martini implementation pattern: a workflow either retrieves a narrow log window through the Logs API, starts and polls a Logs Insights query, or processes selected intermediary-delivered log batches. It then filters, redacts, deduplicates, and forwards the result.
Implementation sequence
Alarm and AWS event notifications
CloudWatch alarm state changes can publish to supported AWS targets such as Amazon SNS, while supported AWS service events can be routed through Amazon EventBridge. This is feature-specific event delivery, not a universal CloudWatch webhook facility.
Martini implementation pattern
Martini implementation pattern: expose a protected Martini API endpoint or receive data through a supported intermediary, validate the event, derive an idempotency key, apply severity and routing rules, and invoke the downstream incident or notification API.
Implementation sequence
Common Amazon CloudWatch integration patterns
Pattern 1: Synchronize CloudWatch alarms to ServiceNow
When to use this pattern
Use this pattern when operations teams need CloudWatch alarm state changes represented as incidents or updates in ServiceNow. It supports scheduled discovery through DescribeAlarms or event-driven delivery through SNS or EventBridge, with stable identifiers preventing repeated notifications from creating duplicate incidents.
Integration direction
Example Mapping
| Amazon CloudWatch Field | Canonical Field | Target Field |
|---|---|---|
| AlarmArn | sourceAlarmId | correlation_id |
| AlarmName | alarmName | short_description |
| StateValue | alarmState | state or severity |
| StateReason | stateReason | description |
Martini implementation pattern
Martini receives an intermediary-delivered event or retrieves alarms on a schedule, validates the AWS context, derives a key from the alarm ARN and state transition timestamp, maps severity and operational context, and creates or updates the ServiceNow incident. Transient target failures are retried, while duplicate keys are treated as already processed.
Martini capabilities used
- workflows
- API consumption
- API exposure
- AWS request authentication
- data mapping
- business rules
- idempotency
- error handling
Pattern 2: Forward selected CloudWatch Logs to Splunk
When to use this pattern
Use this pattern when only selected CloudWatch Logs data must be forwarded to Splunk for search, security analysis, or compliance. It is appropriate for filtered or moderate-volume transfers where Martini should apply enrichment, redaction, and delivery rules rather than move every log event.
Integration direction
Example Mapping
| Amazon CloudWatch Field | Canonical Field | Target Field |
|---|---|---|
| logGroupName | sourceLogGroup | source |
| logStreamName | sourceLogStream | host or source |
| timestamp | eventTimestamp | _time |
| message | eventMessage | _raw |
Martini implementation pattern
A scheduled workflow queries a bounded time range or receives selected log batches from an AWS-supported delivery path. Martini filters records, extracts structured fields, redacts sensitive values, sends bounded batches to the chosen Splunk ingestion endpoint, and stores a checkpoint so retries do not resend the same event set unnecessarily.
Martini capabilities used
- scheduling workflows
- API consumption
- JSON handling
- data mapping
- validation
- redaction rules
- checkpointing
- retry handling
Pattern 3: Publish business metrics to CloudWatch
When to use this pattern
Use this pattern when application or integration activity must be visible in CloudWatch as custom metrics, such as order counts, processing latency, integration failures, or queue depth. The source can be an API request, an upstream application event, or a scheduled aggregation.
Integration direction
Example Mapping
| Amazon CloudWatch Field | Canonical Field | Target Field |
|---|---|---|
| orderCount | businessMetricValue | MetricDatum.Value |
| orderProcessing | metricNamespace | Namespace |
| region | metricDimension | Dimensions |
| completedAt | metricTimestamp | Timestamp |
Martini implementation pattern
Martini receives or calculates business measurements, validates the namespace and dimensions, converts timestamps to UTC, groups compatible values into PutMetricData batches, and submits them using SigV4-authenticated requests. The workflow applies bounded retries and records failed batches for replay without silently changing metric semantics.
Martini capabilities used
- API exposure
- workflows
- data mapping
- business rules
- batch processing
- AWS request authentication
- error handling
Pattern 4: Synchronize CloudWatch metrics with Datadog
When to use this pattern
Use this pattern when an organization needs a centralized observability platform containing AWS and non-AWS measurements. The workflow can retrieve selected CloudWatch time series, enrich them with business metadata, and forward normalized values rather than exporting every available metric.
Integration direction
Example Mapping
| Amazon CloudWatch Field | Canonical Field | Target Field |
|---|---|---|
| MetricName | metricName | metric name |
| Namespace | metricNamespace | namespace or tag |
| Dimensions | metricTags | tags |
| MetricDataResults.Values | metricValues | points |
Martini implementation pattern
A scheduler invokes GetMetricData or GetMetricStatistics for controlled regions, namespaces, dimensions, and UTC windows. Martini follows pagination, handles missing or late-arriving data, converts dimensions to Datadog tags, enriches measurements, and forwards batches with a checkpoint and retry policy.
Martini capabilities used
- scheduling workflows
- API consumption
- data mapping
- time-series normalization
- pagination
- rate-limit handling
- checkpointing
- monitoring
Applications commonly integrated with Amazon CloudWatch
Amazon CloudWatch commonly participates in AWS-native event and observability architectures. Martini can orchestrate selected data flows between CloudWatch, AWS intermediary services, and named enterprise applications without assuming that CloudWatch provides a universal webhook or direct application connector.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Amazon SNS | Deliver CloudWatch alarm notifications to subscribers, queues, or downstream processing services. | Amazon CloudWatch → Amazon SNS → Martini | Configure Martini to expose an authenticated API endpoint for an SNS-delivered notification, validate the request, normalize the alarm payload, and route it to the appropriate workflow or target system. |
| Amazon EventBridge | Route supported AWS and CloudWatch-related events through rules and targets for event-driven processing. | Amazon CloudWatch → Amazon EventBridge → Martini | Receive supported event payloads through an EventBridge target or intermediary, validate event identity and type, apply routing rules, and invoke downstream APIs from a Martini workflow. |
| AWS Lambda | Process alarm notifications, log subscriptions, or operational events with custom AWS-hosted code. | Amazon CloudWatch → AWS Lambda → Martini | Use Lambda as the AWS-supported intermediary when required, then have it call a Martini API or forward normalized data to a workflow for enrichment, deduplication, and delivery. |
| Amazon Kinesis Data Firehose | Stream selected CloudWatch Logs data to storage, search, or analytics destinations. | Amazon CloudWatch Logs → Amazon Kinesis Data Firehose → Martini | Use AWS-native streaming for high-volume log delivery and reserve Martini for receiving selected batches, applying validation and redaction, and orchestrating delivery to an enterprise endpoint. |
| Amazon S3 | Archive CloudWatch Logs or operational data for long-term retention and analytics. | Amazon CloudWatch → Amazon S3 → Martini | Process exported or staged operational data through an appropriate API-based workflow, normalize records, and persist checkpoints so repeated exports do not create duplicate downstream results. |
| Datadog | Consolidate AWS metrics, logs, and alarms into an enterprise observability platform. | Amazon CloudWatch → Martini → Datadog | Query selected metrics or logs, map namespaces and dimensions to the Datadog model, redact sensitive content, and send bounded batches with retry and checkpoint handling. |
| Splunk | Centralize AWS operational logs and security events for search, alerting, and compliance analysis. | Amazon CloudWatch Logs → Martini → Splunk | Use CloudWatch Logs APIs or an AWS-supported delivery path, filter and redact events in Martini, then forward normalized batches to the chosen Splunk ingestion endpoint. |
| ServiceNow | Create or update incidents from CloudWatch alarm state changes and operational events. | Amazon CloudWatch → Amazon SNS or Amazon EventBridge → Martini → ServiceNow | Receive an intermediary-delivered alarm event, derive an idempotency key from the alarm ARN and state transition, map severity and context, and create or update the ServiceNow incident. |
How to build a Amazon CloudWatch integration in Martini
Objective
Establish the CloudWatch integration using IAM permissions, AWS credentials or role assumptions, the correct region, and Signature Version 4 request signing.
Instructions in Martini
- Define the required CloudWatch actions and least-privilege IAM policy
- Store credentials, role configuration, region, and signing settings in protected environment configuration or secrets
- Choose whether the workflow will call CloudWatch directly or receive events through SNS, EventBridge, Lambda, or another supported intermediary
Objective
Select a trigger that matches the CloudWatch use case: scheduled polling for metrics, alarms, or logs, or an API trigger for intermediary-delivered notifications.
Instructions in Martini
- Use a scheduler for bounded metric, alarm, or Logs Insights queries
- Expose a protected Martini API for SNS, EventBridge, or Lambda-delivered events
- Define polling windows, event filters, and maximum execution boundaries
Objective
Obtain the CloudWatch data while handling AWS service response formats, continuation tokens, and asynchronous query states.
Instructions in Martini
- Invoke the required CloudWatch HTTPS service operation
- Follow NextToken values until the configured page or execution limit is reached
- Poll asynchronous Logs Insights queries until completion when applicable
- Preserve source account, region, event IDs, alarm ARNs, and log stream identifiers
Objective
Coordinate validation, enrichment, routing, and target delivery in a reusable Martini workflow rather than embedding integration logic in a one-off script.
Instructions in Martini
- Separate retrieval, normalization, business rules, and target delivery into clear workflow stages
- Route alarms, metrics, and logs according to namespace, state, severity, or source
- Use intermediary services for high-volume AWS-native delivery when direct polling is inefficient
Objective
Convert CloudWatch metrics, alarms, logs, and event payloads into the canonical model required by the target platform.
Instructions in Martini
- Map namespaces, metric names, dimensions, timestamps, values, alarm state, and log context
- Normalize timestamps to UTC and convert dimensions to target tags or attributes
- Redact credentials, tokens, personal information, or sensitive application payloads from logs
- Validate required fields before downstream delivery
Objective
Apply routing, filtering, deduplication, and enrichment rules that determine which CloudWatch data becomes downstream work.
Instructions in Martini
- Use alarm ARN, state transition time, event ID, or deterministic event hash as an idempotency key
- Filter log groups, namespaces, dimensions, and time ranges to control volume
- Assign target severity and ownership based on alarm state, source, and operational context
- Handle missing metrics and late-arriving log events explicitly
Common Amazon CloudWatch data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Metrics | Publish, retrieve, aggregate, or synchronize time-series measurements identified by namespace, metric name, dimensions, timestamp, and value. | Datadog, New Relic, Splunk, reporting databases, operational dashboards | Martini maps metric structures, normalizes timestamps and units, handles time windows and pagination, and can publish batches through PutMetricData. |
| Namespaces | Group AWS service or custom application metrics into logical monitoring domains. | Observability platforms, data warehouses, monitoring catalogs | Martini uses namespaces as routing and classification fields and can apply allowlists or business rules before forwarding data. |
| Dimensions | Identify and filter metric series with attributes such as InstanceId, FunctionName, or LoadBalancer. | Monitoring platforms, analytics stores, incident systems | Martini preserves dimension name/value pairs, converts them to target tags or attributes, and applies mappings for target-specific naming. |
| Alarms | Evaluate thresholds or anomaly conditions and represent state changes that can invoke configured AWS actions. | ServiceNow, Jira, Amazon SNS, Amazon EventBridge, notification systems | Martini retrieves alarms or receives intermediary-delivered notifications, maps state and context, and uses stable alarm identifiers for idempotent processing. |
| Log groups | Contain related log streams, retention policies, metric filters, subscription filters, and destinations. | Splunk, Datadog, Amazon S3, data warehouses, security platforms | Martini filters selected groups, orchestrates queries or forwarding, applies redaction, and records checkpoints for repeatable processing. |
| Log streams and log events | Represent ordered streams and timestamped log entries within a log group. | Splunk, Datadog, incident systems, operational databases | Martini preserves stream identifiers and timestamps, extracts relevant fields, deduplicates deterministic events, and forwards bounded batches. |
Authentication and security considerations
IAM and Signature Version 4
Amazon CloudWatch service APIs use IAM authorization and AWS Signature Version 4. Requests require the correct service, region, timestamp, canonical request, and signing configuration.
Credentials and roles
Use protected environment configuration or secrets for access keys, temporary STS credentials, role assumptions, and region settings. Cross-account integrations should use an appropriate IAM trust relationship and least-privilege policy.
Protected event endpoints
Martini APIs receiving SNS, EventBridge, Lambda, or other AWS-originated notifications should require authentication and authorization, validate request content, and apply network and operational controls.
Data protection
CloudWatch Logs may contain credentials, tokens, personal information, or application payloads. Filter and redact sensitive values before forwarding logs to another platform.
Operational considerations for Amazon CloudWatch integrations
Quotas and retries
CloudWatch applies service quotas and throttling. Use bounded concurrency, exponential backoff with jitter, and retry policies for transient failures.
Pagination and asynchronous queries
Follow continuation tokens such as NextToken and enforce page or execution limits. Logs Insights workflows must handle asynchronous query start and result retrieval operations.
Regions and accounts
CloudWatch data is often regional and account-specific. Multi-region or cross-account workflows should explicitly manage account identity, role assumption, endpoint selection, and per-region checkpoints.
Time and ordering
Use UTC internally and define handling for late metrics, missing data, overlapping polling windows, and asynchronous log delivery. Do not assume global ordering across log streams.
Idempotency and schema change
Use stable alarm, event, log, or metric identifiers to prevent duplicate downstream work. Tolerate unknown response fields and keep AWS request schemas and IAM policies under change control.
Why use Martini instead of scripts or point-to-point integrations?
Reusable orchestration
Martini separates CloudWatch retrieval or event intake from validation, transformation, business rules, and delivery, allowing the same integration assets to support multiple AWS accounts, regions, and targets.
Controlled API and event integration
Martini can consume CloudWatch HTTPS service APIs and expose protected APIs for SNS or EventBridge-delivered events without requiring a dedicated vendor connector.
Reliable data movement
Workflows can handle pagination, asynchronous queries, batching, retries, checkpoints, deduplication, and target-system failures more consistently than isolated scripts.
Maintainable mappings
Centralized mappings and transformations make namespaces, dimensions, alarm states, timestamps, and log fields easier to adapt as AWS response schemas or downstream requirements change.
Frequently asked questions
Amazon CloudWatch can be integrated through its authenticated HTTPS service APIs for metrics, alarms, dashboards, and CloudWatch Logs. Alarm notifications and supported AWS events can be routed through Amazon SNS or Amazon EventBridge, while selected log data can use AWS subscription mechanisms. An integration platform can retrieve, publish, transform, and route this data to incident, observability, analytics, or operational systems.
Yes. Martini can consume Amazon CloudWatch HTTPS service APIs using AWS IAM authorization and Signature Version 4, publish custom metrics, retrieve metrics and logs, synchronize alarms, and expose an API for notifications delivered through SNS, EventBridge, Lambda, or another supported intermediary. No native Martini CloudWatch connector is documented in the supplied materials.
No. A dedicated Amazon CloudWatch connector is not required. Martini can use CloudWatch's native HTTPS service APIs, AWS Signature Version 4 authentication, and supported event paths such as SNS or EventBridge, with workflows handling mapping, routing, retries, and downstream API calls.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Amazon CloudWatch with Martini. Integrations are subject to the provisioned capacity of the Martini environment. Separate costs may apply from AWS, cloud infrastructure, SNS, EventBridge, target applications, or other third-party systems depending on subscription, usage, and deployment model.
Use CloudWatch HTTPS service APIs for controlled metric, alarm, dashboard, and log operations. Use PutMetricData for custom metric publication, GetMetricData or GetMetricStatistics for metric retrieval, and CloudWatch Logs APIs or Logs Insights for log analysis. Use SNS or EventBridge for supported event-driven delivery instead of assuming a universal direct webhook facility. CloudWatch does not provide an official GraphQL or SOAP API.
CloudWatch does not provide a universal direct webhook for all metrics, logs, alarms, or API operations. Alarm state changes can publish to supported AWS targets such as SNS, and supported AWS events can be routed through EventBridge. CloudWatch Logs can also use supported subscription destinations. Martini can receive these intermediary-delivered notifications through an exposed, secured API.
Martini can run scheduled workflows that query selected metrics, alarms, or logs over bounded time windows, follow pagination tokens, and poll asynchronous Logs Insights queries. It can also process event-driven notifications. Checkpoints, UTC timestamps, stable source identifiers, and idempotency keys help manage overlapping polling windows, retries, late data, and duplicate deliveries.
A Martini workflow can apply exponential backoff with jitter, bounded concurrency, retry policies, and checkpointing for transient AWS or target-system failures. It should use alarm ARNs, state transition timestamps, event IDs, log identifiers, or deterministic hashes to detect duplicates. Rate limits, pagination, regional scope, and large query windows should be controlled explicitly.
Related Martini documentation
CloudWatch APIs
Transformation
Connect Amazon CloudWatch with Martini
Use Martini to orchestrate Amazon CloudWatch APIs, alarms, logs, metrics, and AWS-supported event delivery across your enterprise systems.