CloudWatch Application Signals & Service Maps

A trace tells you what happened in one request. A service map tells you what happens across every request, aggregated: which services call which, how often, how fast, and how reliably.

CloudWatch Application Signals is AWS's newer APM-style (application performance monitoring) feature that builds exactly that view. It consumes the trace data your services already emit - from X-Ray or OpenTelemetry - and turns it into a visual service map plus SLO-style metrics like latency and availability, without you writing a new instrumentation layer.

This page describes Application Signals conceptually and how it relates to the tracing work covered earlier in this section, since the SDK-level enablement details are still evolving and worth verifying against current docs before you rely on them.

Recipe

The pattern: Application Signals is enabled at the service/platform level (via the CloudWatch console or a discovery mechanism for your compute platform), not by adding a new package to your SDK code. Your existing tracing setup - X-Ray or OpenTelemetry - is what feeds it.

# --- Python (boto3) ---
# Application Signals builds on the same X-Ray instrumentation you already have.
# The SDK-level code is unchanged - this is the same pattern as the X-Ray page.
from aws_xray_sdk.core import patch
import boto3
 
patch(["boto3"])   # traced calls here are what Application Signals visualizes
 
orders = boto3.client("dynamodb")
orders.get_item(TableName="Orders", Key={"id": {"S": "order-42"}})
 
# Enablement of Application Signals itself happens at the platform/console level -
# verify the exact current steps for your compute platform (Lambda, ECS, EKS) against AWS docs.

// --- TypeScript (AWS SDK v3) ---
// Application Signals builds on the same tracing instrumentation you already have.
// The SDK-level code is unchanged - this is the same pattern as the X-Ray page.
import AWSXRay from "aws-xray-sdk-core";
import { DynamoDBClient, GetItemCommand } from "@aws-sdk/client-dynamodb";
 
const orders = AWSXRay.captureAWSv3Client(new DynamoDBClient({}));
await orders.send(new GetItemCommand({ TableName: "Orders", Key: { id: { S: "order-42" } } }));
 
// Enablement of Application Signals itself happens at the platform/console level -
// verify the exact current steps for your compute platform against AWS docs.

When to reach for this:

• You already have X-Ray or OpenTelemetry tracing flowing and want an aggregated, visual view of service dependencies instead of reading individual traces.
• You want SLO-style latency/error metrics per service without building custom CloudWatch dashboards from scratch.
• You are troubleshooting "which downstream dependency is causing the slowdown" across many services.
• You have not instrumented any tracing yet - in that case, start with structured logging, then X-Ray or OpenTelemetry, before layering this on top.

Working Example

Since Application Signals is a console/platform-level feature built from existing trace data, the "working example" here is conceptual: what you would see, not new code to write.

# --- Python (boto3) ---
# No new SDK code - Application Signals reads the trace data your instrumented
# calls already produce. The instrumentation is identical to the X-Ray or
# OpenTelemetry pages in this section.
from aws_xray_sdk.core import xray_recorder, patch
import boto3
 
patch(["boto3"])
ddb = boto3.client("dynamodb")
 
@xray_recorder.capture("checkout_flow")
def checkout_flow(order_id: str):
    return ddb.get_item(TableName="Orders", Key={"id": {"S": order_id}})
    # This subsegment becomes one edge on the resulting service map:
    # checkout-service -> DynamoDB, with its own latency and error rate.

// --- TypeScript (AWS SDK v3) ---
// No new SDK code - Application Signals reads the trace data your instrumented
// calls already produce, the same instrumentation shown in the X-Ray page.
import AWSXRay from "aws-xray-sdk-core";
import { DynamoDBClient, GetItemCommand } from "@aws-sdk/client-dynamodb";
 
const ddb = AWSXRay.captureAWSv3Client(new DynamoDBClient({}));
 
export async function checkoutFlow(orderId: string) {
  return ddb.send(new GetItemCommand({ TableName: "Orders", Key: { id: { S: orderId } } }));
  // This subsegment becomes one edge on the resulting service map:
  // checkout-service -> DynamoDB, with its own latency and error rate.
}

What this demonstrates:

• No dedicated "Application Signals SDK" call is needed at the code level shown here - the value comes from trace data you are likely already producing.
• Each traced SDK call becomes a labeled edge on the resulting service map (caller -> AWS service or downstream service).
• The map aggregates across many requests, so a consistently slow edge stands out even when any single trace looks fine.
• The actual enablement (turning Application Signals on for a given service/platform) happens outside application code, and its exact steps are worth confirming against current AWS documentation for your compute platform.

Deep Dive

What Application Signals Adds Over Raw Traces

• A service map: nodes for each service (including AWS services like DynamoDB or S3), edges for calls between them, each annotated with latency and error rate.
• SLO-style metrics: availability and latency thresholds per service, so you can define what "healthy" means and get alerted when a service drifts from it.
• Automatic correlation between traces, logs, and metrics for the same service, reducing the manual work of pivoting between three separate tools.
• All of this is derived, not separately instrumented - the underlying data is the same X-Ray subsegments or OpenTelemetry spans covered earlier in this section.

How It Relates to X-Ray and OpenTelemetry

• Application Signals is described by AWS as built on top of X-Ray (and, increasingly, OpenTelemetry) trace data - it is a higher-level view, not a competing tracing mechanism.
• If your services already emit X-Ray subsegments or OTel spans for their AWS SDK calls, that data is the input Application Signals needs.
• If you have not instrumented tracing at all, Application Signals has nothing to visualize - the order in this section (logging, then X-Ray/OTel, then this page) reflects that dependency.
• Enablement specifics - whether it is a console toggle, an auto-instrumentation agent, or a discovery step per compute platform (Lambda, ECS, EKS, EC2) - vary and are actively evolving; treat "enabled via CloudWatch console/Application Signals discovery" as the conceptual answer, and verify exact current steps against AWS's own documentation before rollout.

Reading a Service Map in Practice

• Start from the node representing your own service, and look at its outbound edges to AWS services and downstream dependencies.
• A red or elevated-latency edge points you directly at which dependency to investigate, instead of scanning logs across every service in the chain.
• Compare the map over time, not just at one instant - a newly appeared edge or a newly slow one is often the first signal of a regression or a scaling problem.
• Use the map as a starting point, then drop into the underlying traces (X-Ray or OTel) for the specific request-level detail a map's aggregation necessarily hides.

Gotchas

• Expecting a service map with no tracing instrumented - Application Signals has nothing to draw from without X-Ray or OTel data flowing. Fix: instrument tracing first (see the X-Ray or OpenTelemetry pages), then enable Application Signals.
• Assuming enablement is purely a code change - it is largely a platform/console-level configuration, not a package you pip install. Fix: check the current AWS documentation for your specific compute platform's enablement path rather than assuming a single universal step.
• Reading a service map as if it were a single trace - it is aggregated across time and requests. Fix: use it to identify which edge to investigate, then pivot to individual traces for root cause.
• Ignoring that specifics change - AWS has iterated on Application Signals' enablement mechanics since launch. Fix: treat this page as the conceptual model, and verify exact steps against current docs before depending on them in a runbook.

Alternatives

FAQs

Related

• AWS X-Ray Tracing for SDK-Calling Services - the trace data this feature commonly consumes.
• OpenTelemetry Instrumentation for AWS SDKs - the vendor-neutral tracing alternative it can also consume.
• Observability for AWS SDK Applications - where this fits among the three observability pillars.
• Observability Best Practices - sampling and cardinality guidance that keeps this data affordable at scale.

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