Skip to main content

AWS Glossary

Amazon CloudWatch Application Signals

Application Signals is an APM service inside CloudWatch — application-level latency, error, and availability monitoring with SLOs, dependency mapping, and OpenTelemetry integration.

Definition

Amazon CloudWatch Application Signals is AWS’s application performance monitoring (APM) layer inside CloudWatch. It delivers RED metrics (rate, errors, duration) per service and operation, auto-discovered service maps, SLOs with error-budget tracking, and OpenTelemetry (OTLP) ingestion for polyglot instrumentation. Auto-instrumentation supports common runtimes (Java, Python, Node.js, .NET); Lambda, ECS, and EKS coverage expanded through 2025–2026. Enable Transaction Search to unlock full span search and the unified Application Signals pricing that includes X-Ray traces. Service Events (announced July 6, 2026) automatically capture exception/latency snapshots and deployment events for instrumented Java, Python, and JavaScript services. CloudWatch Investigations adds GenAI-assisted hypothesis generation for incident triage.

When to use it

  • Teams wanting APM on AWS without a separate SaaS vendor for standard Java/Python/Node/.NET workloads
  • Organizations already paying for CloudWatch logs and metrics who need service-level SLOs and dependency maps in the same console
  • GenAI observability alongside traditional services — trace model latency, tool calls, and downstream dependencies in one service map
  • Cost-conscious mid-market teams where third-party APM per-host pricing exceeds CloudWatch span ingestion at similar volume

When not to use it

  • Deep browser RUM and session replay requirements — dedicated front-end observability vendors still lead feature depth (see CloudWatch RUM for lighter AWS-native coverage)
  • Multi-cloud APM as a single pane — Application Signals is AWS-centric
  • Runtimes without auto-instrumentation and no appetite to maintain OpenTelemetry exporters yourself
  • Sub-millisecond precision debugging where specialized profilers and eBPF tooling are mandatory

Tips

  • Start with one or two critical user journeys for SLOs — too many SLOs on day one produces noisy burn-rate alerts
  • Configure trace sampling on high-traffic Lambda and API paths — 100% head-based sampling on bursty workloads inflates CloudWatch bills
  • Enable Transaction Search before expecting full Application Signals APM features
  • Use Service Events after deploys to check whether new exceptions appeared without writing custom exception pipelines
  • Wire CloudWatch Investigations into the on-call playbook with linked dashboards and recent deployment markers
  • Instrument with ADOT — do not start net-new work on the X-Ray SDKs (maintenance mode since February 25, 2026)
  • Align Application Signals service names with Cost Explorer tags and team ownership for faster incident routing

Gotchas

Serious

  • Sampling misconfiguration: Default aggressive tracing on serverless at scale can make CloudWatch the largest line item overnight.
  • SLO alert fatigue: Calendar-window and rolling-window burn alerts without tuning page engineers for normal deployment noise.
  • GenAI blind spots: Model invocations through uninstrumented custom clients may appear as generic HTTP dependencies — instrument Bedrock SDK calls explicitly.

Regular

  • Service map discovery lag after deploys can hide new dependencies until traffic patterns stabilize.
  • X-Ray and Application Signals terminology overlap in older docs — follow current Application Signals setup guides for new workloads; treat X-Ray as the trace backend, not the primary UI.
  • Investigations quality depends on surrounding telemetry — sparse logs yield weak automated hypotheses.

Official references

Related Articles

Observability Beyond CloudWatch (2026): When to Add Application Signals, ADOT, Managed Prometheus, and Grafana — and When Not To

The reflex to bolt Amazon Managed Prometheus + Grafana onto every workload is how observability bills quietly double. CloudWatch Application Signals now gives you an auto-discovered service map, SLOs, and traces with near-zero setup; AMP only earns its keep when you are PromQL-native or drowning in high-cardinality metrics — where ingestion (not retention) is the cost driver. Here is the decision matrix, an ADOT dual-export config, and the three levers that actually cut the AMP bill.

Read article

AWS CloudWatch Observability: Metrics, Logs, and Alarms Best Practices

CloudWatch is the most underused service on every AWS bill — and the most overspent on the ones that take it seriously. Logs, metrics, and alarm patterns that catch real outages without burying you in noise (or in the bill).

Read article

AWS Observability Costs: Cardinality Budgets & FinOps Limits

CloudWatch Logs Insights bills $0.005 per GB scanned and high-cardinality custom metrics multiply costs. Cardinality budgets, sampling rules, and FinOps fixes.

Read article

How to Debug Production Issues Across Distributed AWS Systems

A 500ms latency spike in a distributed system could be a slow RDS query, a Lambda cold start, a downstream API timeout, or a CloudWatch Logs ingestion delay. Finding the cause requires correlated logs, traces, and metrics — not grep.

Read article

Amazon CloudWatch Pricing: The 10 Billing Dimensions Behind Your Observability Bill

CloudWatch bills across ten distinct dimensions — Logs ingestion at $0.50/GB, Logs storage, custom metrics with cardinality multipliers, alarms tiered by resolution and type, dashboards at $3 each, Synthetics canary runs, RUM events, X-Ray traces, Container Insights, and cross-region replication. Logs ingestion is the largest line on most accounts.

Read article

Need help with this topic?

Our AWS-certified team implements, audits, and optimizes these services in production — from Bedrock RAG pipelines to multi-account landing zones.