AWS Distro for OpenTelemetry

AWS-supported distribution of OpenTelemetry — instrument once, send correlated traces, metrics, and logs to multiple observability backends.

Key point

AWS Distro for OpenTelemetry (ADOT) is the AWS-supported distribution of the open-source OpenTelemetry (OTel) project — instrument an application once and send traces, metrics, and logs to multiple backends (X-Ray, CloudWatch, Prometheus, Datadog, etc.).
ADOT replaces the need for vendor-specific SDKs (X-Ray SDK, CloudWatch Agent for custom metrics) with a single, vendor-neutral instrumentation layer and collector.

AWS Distro for OpenTelemetry (ADOT) is a secure, production-ready, AWS-supported distribution of the OpenTelemetry project — it provides SDKs, auto-instrumentation agents, and a collector to capture traces, metrics, and logs from applications and send them to one or more observability backends.

ADOT is free to use. Costs come from the destination services (X-Ray, CloudWatch, Prometheus) that receive the telemetry data.

Core Concepts

Concept	Description
OpenTelemetry (OTel)	CNCF open-source standard for collecting traces, metrics, and logs in a vendor-neutral way
ADOT SDK	AWS distribution of OTel SDKs for Java, Python, JavaScript, Go, .NET, Ruby, PHP, Swift, and Android
ADOT Collector	A pipeline process that receives, processes, and exports telemetry data to one or more backends
Receiver	Collector component that ingests data (OTLP, Jaeger, Zipkin, StatsD, X-Ray, Prometheus, etc.)
Processor	Collector component that transforms data in-flight (batching, filtering, attribute modification)
Exporter	Collector component that sends data to a backend (X-Ray, CloudWatch, Prometheus, OTLP, Datadog)
Auto-instrumentation	Automatic trace capture without code changes — available for Java, Python, JavaScript, and .NET
OTLP	OpenTelemetry Protocol — the standard wire protocol for sending telemetry between components

How ADOT Works

Application (any language)
    → ADOT SDK / Auto-instrumentation Agent
        → ADOT Collector
            ├── Receiver (OTLP, Jaeger, StatsD, X-Ray)
            ├── Processor (batch, filter, attributes)
            └── Exporter(s)
                ├── AWS X-Ray (traces)
                ├── Amazon CloudWatch (metrics + logs)
                ├── Amazon Managed Prometheus (metrics)
                ├── Third-party (Datadog, Splunk, New Relic, etc.)
                └── Any OTLP-compatible backend

Deployment Models

Model	How	Best For
Sidecar	Collector runs as a sidecar container alongside the app	ECS, EKS per-pod collection
Daemon	Collector runs as a DaemonSet (one per node) or host-level process	EKS cluster-wide, EC2 instances
Lambda Layer	ADOT Lambda Layer adds collector and auto-instrumentation to Lambda	Serverless tracing
EKS Add-on	Managed ADOT add-on installed via EKS console or API	Simplified EKS observability
On-premises	Collector installed on any host with outbound HTTPS to AWS	Hybrid cloud, multi-cloud tracing

Supported Compute Platforms

Platform	Integration Method
Amazon ECS (Fargate)	Sidecar container with ADOT Collector
Amazon ECS (EC2)	Sidecar or daemon container
Amazon EKS	EKS managed add-on, DaemonSet, or sidecar
AWS Lambda	ADOT Lambda Layer (auto-instrumentation + collector)
Amazon EC2	Install ADOT Collector as a system service
AWS App Runner	Built-in OpenTelemetry support
On-premises	Install ADOT Collector on any Linux, Windows, or container
Other clouds	Install ADOT Collector with IAM credentials for AWS export

ADOT vs X-Ray SDK vs CloudWatch Agent

Criteria	ADOT	X-Ray SDK	CloudWatch Agent
Standard	OpenTelemetry (vendor-neutral, CNCF)	AWS-proprietary	AWS-proprietary
Signal types	Traces + metrics + logs	Traces only	Metrics + logs only
Multi-backend export	Yes — any OTel-compatible backend	X-Ray only	CloudWatch only
Auto-instrumentation	Yes (Java, Python, JS, .NET)	Limited	No (agent collects OS metrics)
Vendor lock-in	Low — switch backends without re-instrument	High — tied to X-Ray	High — tied to CloudWatch
AWS recommendation	Preferred for new applications	Supported, not deprecated	Still recommended for OS-level metrics
Language support	Java, Python, JS, Go, .NET, Ruby, PHP, Swift	Java, Python, JS, Go, .NET, Ruby	N/A (agent-based, not SDK)

When to Use ADOT vs X-Ray SDK

Scenario	Recommendation
New application — need distributed tracing	ADOT (AWS recommended)
Existing app already instrumented with X-Ray SDK	Keep X-Ray SDK (no need to migrate unless multi-backend is needed)
Need to send traces to both X-Ray and a third-party	ADOT (multi-exporter)
Multi-cloud or hybrid — services on AWS + other clouds	ADOT (vendor-neutral)
Only need OS-level metrics (CPU, memory, disk)	CloudWatch Agent
Need metrics + traces from a single instrumentation	ADOT
Lambda with minimal setup — traces only	X-Ray active tracing (simplest) or ADOT Lambda Layer

Common Use Cases

Vendor-neutral observability — Instrument once with OpenTelemetry, export to X-Ray for traces and CloudWatch for metrics without separate SDKs.
Multi-backend tracing — Send the same trace data to both AWS X-Ray and a third-party APM tool (Datadog, Splunk, New Relic) simultaneously.
EKS cluster observability — Deploy ADOT as an EKS managed add-on to collect traces and Prometheus metrics from all pods cluster-wide.
Hybrid/multi-cloud tracing — Run ADOT Collector on on-premises or non-AWS servers to send traces to X-Ray for a unified service map.
Lambda observability — Add the ADOT Lambda Layer for automatic trace capture with zero code changes via auto-instrumentation.

SAA/SAP Exam Tips

SAA Tip: "Vendor-neutral tracing" or "send traces to multiple backends" → AWS Distro for OpenTelemetry (ADOT). X-Ray SDK sends traces to X-Ray only.

SAP Tip: For new applications, AWS recommends ADOT over the X-Ray SDK. Existing X-Ray SDK instrumentation continues to work — migration is optional.

SAP Tip: ADOT itself is free. Costs are incurred by the destination services (X-Ray per trace, CloudWatch per metric, Prometheus per ingested sample). Factor in multi-backend export when estimating observability costs.

Cross-Cloud Equivalents

Provider	Service / Solution	Notes
AWS	AWS Distro for OpenTelemetry	Baseline
Azure	Azure Monitor OpenTelemetry Distro	Azure's OTel distribution for .NET, Python, JS
GCP	Google Cloud OpenTelemetry support	Native OTel integration with Cloud Trace
On-Premises	OpenTelemetry Collector (upstream), Jaeger, Grafana Alloy	Community OTel collector + backends

Pricing Model

Dimension	Unit	Notes
ADOT SDK	Free	No charge for the SDK or auto-instrumentation agent
ADOT Collector	Free	No charge for the collector — runs on existing compute
Destination costs	Varies	X-Ray: per million traces. CloudWatch: per metric/log GB. Prometheus: per sample ingested.

AWS X-Ray — distributed tracing backend that receives traces from ADOT or the X-Ray SDK
Amazon CloudWatch — metrics, logs, and alarms — receives metrics and logs from ADOT Collector
Amazon ECS and EKS — run ADOT Collector as a sidecar or EKS managed add-on
AWS Lambda — add ADOT Lambda Layer for auto-instrumented tracing