AWS Observability
AWS observability covers the managed services for monitoring, logging, and tracing workloads running on Amazon's cloud. CloudWatch, X-Ray, and related tools collect metrics, aggregate logs, and trace requests across distributed systems to surface operational issues.
itCloud computing | OpenSkills.info
Intro
AWS Observability
AWS observability is your ability to understand an AWS workload from the telemetry it emits. Telemetry is the evidence: metrics, logs, and traces. Observability is the operating capability you build from that evidence.
The useful mental model is a path from outcome to evidence:
- Define the customer or business outcome that must remain healthy.
- Choose indicators that represent that outcome and its dependencies.
- Instrument the workload and collect the required telemetry.
- Turn important conditions into dashboards, service level objectives, and alarms.
- Investigate across metrics, logs, and traces when the condition changes.
- Retain enough evidence for later analysis without collecting data without a purpose.
Amazon CloudWatch is the center of this path in AWS. It monitors AWS resources and applications. It stores and analyzes metrics and logs, presents dashboards, evaluates alarms, and connects application performance data. AWS X-Ray provides the trace data model and trace backend. AWS CloudTrail records account activity, which answers a different class of questions.
Start with questions, not products
A dashboard is useful only when its signals answer an operating question. Begin with questions such as these:
- Are customers completing the important operation?
- Is latency within the target?
- Which dependency is adding delay or errors?
- Did a deployment change behavior?
- Who changed the AWS resource or policy?
- Is the monitoring system itself receiving current telemetry?
AWS Well-Architected guidance starts from key performance indicators tied to business requirements. This prevents a common failure: collecting every available signal while leaving the customer outcome invisible.
Monitoring and observability overlap, but they are not identical. Monitoring checks known conditions. Observability lets you investigate system behavior by combining evidence, including conditions you did not predict in advance.
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/implement-observability.html
Supports
- Observability connects business requirements and key performance indicators to metrics, logs, traces, application telemetry, dependency telemetry, and distributed tracing
- Observability supports understanding internal system behavior from external outputs
- An observability strategy should change as the workload changes
- https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html
Supports
- CloudWatch monitors AWS resources and applications and provides system-wide operational visibility
- CloudWatch includes metrics, alarms, dashboards, logs, application monitoring, infrastructure monitoring, cross-account monitoring, and OpenTelemetry support
- AWS services can publish metrics automatically and applications can publish custom metrics
- https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html
Supports
- A metric is a time-ordered set of data points identified by namespace, metric name, and dimensions
- Each unique dimension combination creates a distinct metric identity
- Statistics aggregate metric data over periods
- High-resolution custom metrics provide sub-minute granularity and can increase charges
- CloudWatch metrics are regional and metric data is retained with decreasing resolution over time
- https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html
Supports
- CloudWatch Logs centralizes, stores, searches, and analyzes logs from applications, systems, AWS services, and CloudTrail
- Logs can generate metrics, use data protection policies, field indexes, and cross-account or cross-Region centralization
- Log retention is indefinite by default and can be configured per log group
- Standard and Infrequent Access log classes serve different access and feature needs
- https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CloudWatch_Logs_Log_Classes.html
Supports
- Standard provides the full CloudWatch Logs feature set
- Infrequent Access has a lower ingestion price and a smaller feature set
- A log group's class cannot be changed after creation
- https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html
Supports
- Logs Insights supports interactive search and analysis for operational investigation
- Logs Insights cost depends on queried data volume
- Query scope, time range, and indexes affect scanned data and query efficiency
- https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Alarms.html
Supports
- CloudWatch supports metric, log, and composite alarms
- Metric alarms use OK, ALARM, and INSUFFICIENT_DATA states
- Alarm actions can notify or start supported automated actions
- Composite alarms combine other alarm states and can reduce notification noise
- CloudWatch does not validate that every configured alarm action exists
- https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Monitoring-Intro.html
Supports
- Application Signals provides application performance views, standardized dashboards, correlated trace spans, transaction search, and application maps
- Application Signals can use OpenTelemetry data from workloads on AWS, Kubernetes, and on-premises environments
- Synthetics, real user monitoring, metrics, and traces contribute different application perspectives
- https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-ServiceLevelObjectives.html
Supports
- An SLO evaluates an SLI threshold and attainment goal over a defined interval
- CloudWatch SLOs can use Application Signals latency and availability, other metrics, or metric expressions
- Error budgets and burn-rate alarms describe permitted misses and the speed of budget consumption
- https://docs.aws.amazon.com/xray/latest/devguide/xray-concepts.html
Supports
- X-Ray groups segments with a common request into traces and generates service graphs
- Segments describe service work and subsegments describe detailed work or downstream calls
- A trace identifier connects work for one request across services
- Sampling selects which requests are recorded
- https://docs.aws.amazon.com/xray/latest/devguide/xray-sdk-migration.html
Supports
- AWS recommends OpenTelemetry for application instrumentation
- OpenTelemetry spans, resources, attributes, sampling, propagators, collectors, and exporters map to X-Ray concepts
- The CloudWatch agent or an OpenTelemetry collector can receive traces and send them to X-Ray
- Trace sampling controls volume and cost by recording a subset of requests
- https://docs.aws.amazon.com/xray/latest/devguide/xray-sdk-daemon-timeline.html
Supports
- X-Ray SDKs and the X-Ray daemon entered maintenance mode on February 25, 2026
- AWS recommends migration to OpenTelemetry solutions for instrumentation and trace delivery to X-Ray
- https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-concepts.html
Supports
- CloudTrail events record activity in an AWS account
- CloudTrail event categories include management, data, network activity, and Insights events
- Management events record control-plane operations and data events record resource-level operations
- Trail events can be delivered to CloudWatch Logs for queries and alarms
- https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Cross-Account-Methods.html
Supports
- Observability Access Manager shares metrics, logs, traces, and related telemetry with a monitoring account within one Region
- Cross-account cross-Region console access provides views across account and Region boundaries
- CloudWatch centralization copies supported logs and metrics into central destinations across accounts and Regions
- Sharing and central copying have different data movement, access, and cost behavior
