ADOT Collector, the AWS-supported build of the OpenTelemetry Collector
AWS Distro for OpenTelemetry Collector (see ADOT Roadmap at https://github.com/orgs/aws-observability/projects/4)
At a glance
- What is it?
- aws-observability/aws-otel-collector is the distribution Amazon builds and supports from the upstream OpenTelemetry Collector, shipping a curated set of receivers, processors, exporters and extensions that all target CloudWatch Metrics, Traces and Logs. It is a fork rather than a rebuild, and the README warns that four third-party exporters are scheduled for removal.
- Who is it for?
- Adopt ADOT Collector if you run telemetry on AWS and want a collector build with AWS support behind it rather than assembling the upstream binary yourself. Skip it if you need a component the distribution does not carry, since the component set is curated and narrower than upstream contrib.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 5 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 25, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What the distribution is and what it changes
The AWS Distro for OpenTelemetry Collector is an AWS supported version of the upstream OpenTelemetry Collector, distributed by Amazon. It supports the selected components from the OpenTelemetry community, and the README says it is fully compatible with AWS computing platforms including EC2, ECS and EKS.
The point of the distribution is the word supported. Upstream contrib has a large component catalogue and no guarantee that any of it will keep working with a given collector release. The ADOT distribution curates that list, develops some of it in house, and gives you a version Amazon stands behind, which matters when the collector is on your critical path for monitoring.
The scope is CloudWatch and friends. It enables users to send telemetry data to AWS CloudWatch Metrics, Traces and Logs backends as well as the other supported backends. The documentation site is aws-otel.github.io, and the README notes that the ADOT Collector is now generally available for metrics.
The relationship to upstream is that this is a fork with patches. The repository has a patches/ directory and a vendor/ directory, and the Makefile treats third party code as excluded from the lint and test targets, which is how a distribution of this kind manages the upstream code it carries.
The release history is steady: v0.48.0 in May 2026, v0.49.0 in July, v0.50.0 at the end of August, with the last push on 2026-10-20. The version numbers track the upstream collector's component versions rather than being ADOT's own scheme, and the go.mod confirms that, pinning a whole set of contrib components at v0.158.0.
The component table and what is developed in house
The README carries a table of the built-in components, and it explains the distinction that matters: the highlighted components are developed by AWS in house, while the rest are the essential default components the ADOT Collector will support.
The receivers include the Prometheus receiver and the OTLP receiver, which together cover the two common ways telemetry arrives: a Prometheus scrape and the OpenTelemetry protocol. Then there is the awsecscontainermetricsreceiver, the awsxrayreceiver for ingesting X-Ray segments, and the statsdreceiver for the older StatsD format. A later row adds the zipkinreceiver for Zipkin traces.
The processors are the transformation layer, and the list is short and practical: the attributesprocessor for modifying resource attributes, the resourceprocessor for resource attributes specifically, the batchprocessor for grouping before export, the memorylimiterprocessor for protecting the collector's own memory, and the probabilisticsamplerprocessor for keeping a sample of the traffic.
The exporters are where the AWS integration sits. The awsxrayexporter sends traces to X-Ray, and the awsemfexporter sends logs and metrics in the Amazon CloudWatch Metrics and Logs format. Then there is the prometheusremotewriteexporter, the otlpexporter for sending to another collector, the debugexporter for writing to the console while debugging, and the prometheusexporter.
The extensions are the operational and diagnostic pieces: the healthcheckextension for the health endpoint, the pprofextension as a performance profiler, the zpagesextension for debugging pipelines, the ecsobserver, the awsproxy for routing through an AWS proxy, and the sigv4authextension for signing requests with SigV4 credentials.
The distribution also ships AWS-specific components: the awsxrayreceiver, the awsecscontainermetricsreceiver and the awsproxy extension, which show what the distribution is for.
The go.mod also shows components the table does not list, including exporters for CloudWatch Logs, Datadog, Kafka, Logz.io, Prometheus, file and load balancing, plus an S3 configuration provider, and the SigV4 authentication extension.
Planned breaking changes and the removal notice
The README has a section titled Notice: ADOT Collector Planned Breaking Changes, and it names four exporter components that are to be removed from the distribution: datadog, logzio, sapm and signalfx. Users of those are pointed to a specific issue for the details.
That notice is worth understanding in context, because it shows what a curated distribution means in practice. The upstream contrib project has exporters for essentially every commercial observability vendor. Carrying all of them in a distribution Amazon supports is a maintenance commitment, and the ones with thin or absent community uptake are the ones that get dropped. The go.mod still lists the datadog, logzio and signalfx exporters at v0.158.0, which is consistent with them being present now and scheduled for removal.
This is the same trade-off that exists between the upstream collector and contrib, and between any distribution and its upstream, but with a different owner. If your pipeline sends to one of those four, the choice is between migrating to a supported path or staying on the upstream collector, which is where those exporters are not going away.
The notice also tells you how the project communicates. The mechanism is a GitHub issue linked from the README, which is the right level of formality for a distribution: a specific, discussable document rather than a changelog line.
Two other things about support channels. AWS Support tickets are accepted, and there is a separate aws-otel-community GitHub organisation for questions, alongside GitHub issues for bugs and feature requests, with a bug report template and a CONTRIBUTING.md for contributors.
The repository layout and what a distribution has to carry
The top level of the repository shows the shape of a distribution, and it is more than the collector source.
There is cmd/ for the command entry points and pkg/ for the collector packages, with config/ and a config.yaml holding the default pipeline configuration. The patches/ directory holds the changes applied to upstream code, and vendor/ holds the upstream collector itself, which is why the Makefile excludes both from the lint and test targets. tools/ contains the workflow tooling, including the linters directory the Makefile references.
Then there are the parts that are not code at all. examples/ has a subdirectory for each deployment target: docker, ec2, ecs and eks. deployment-template/ holds templates for standing the collector up. e2etest/ and testbed/ are where the stack-level testing happens. docs/ is the documentation. There are .aoc-stack-release.yml and .aoc-stack-test.yml workflow files, which is how the release pipeline and the test pipeline are separated.
There are also a few small files that explain themselves by existing. VERSION holds the release version that the Makefile reads. extracfg.txt sits next to the config directory, presumably holding extra configuration to apply. .env is present at the top level, which is worth a glance when you build the thing, because it may set defaults you did not expect. NOTICE and THIRD-PARTY-LICENSES.txt are the attribution files, and the presence of a third-party licence list is a reminder that a distribution carries code from many projects whose terms you inherit.
The CODE_OF_CONDUCT.md and CONTRIBUTING.md are the community documents, and the CONTRIBUTING file is what the README points at for contribution guidelines.
For an engineer joining the project, the practical reading order is the component table in the README, then the examples directory for your deployment target, then the patches directory if you need to know what AWS changed relative to upstream.
How it is built and how it compares with upstream
The Makefile shows how a distribution of this kind is put together, and the details are instructive.
The build is a Go build with CGO disabled and the binary trimmed with -trimpath, and the version information is injected through linker flags rather than compiled in from a file. The linker sets a Git hash, a version read from the VERSION file and a UTC build date, which is what lets you identify exactly which build is running from a support ticket.
The source selection is deliberate. The ALL_SRC target finds every Go file while excluding third_party directories, the testbed, the build output, the vendored code and the linter tools, with the comment that this is the code to run tests and lint against rather than the upstream code being carried. The same distinction shows in ALL_MODULES, which finds every go.mod in the tree so that build and test targets can be delegated per module.
The parallelism control is a PARALLEL variable with a comment that it is recommended for large runners with eight or more cores, which tells you how heavy a full build is.
There are stack release and test workflows in the repository as .aoc-stack-release.yml and .aoc-stack-test.yml, which suggests the collector is tested as a deployed stack rather than only as a binary, and there are deployment-template, e2etest and testbed directories along with examples for Docker, EC2, ECS and EKS.
The comparison with upstream is straightforward. The upstream OpenTelemetry Collector has every component in contrib and is rebuilt often, which means you get new components quickly and occasional breakage. The ADOT Collector has a narrower set, a slower release cadence and AWS support behind it.
The case for the distribution is supportability and the curated component set, particularly if your whole telemetry path lands in CloudWatch. The case against is exactly the removal notice: if a component you need is not in the table, you are on the upstream collector with the upstream support model.
The comparison with a third option is worth making too, which is the upstream collector with a small pinned configuration of the components you actually use. That is what a lot of teams do, and it means no distribution to track, at the cost of building and patching it yourself.
Editorial conclusion
Adopt ADOT Collector if you run telemetry on AWS and want a collector build with AWS support behind it rather than assembling the upstream binary yourself. Skip it if you need a component the distribution does not carry, since the component set is curated and narrower than upstream contrib. Verify first by reading the built-in components table in the README against the receivers and exporters your stack needs, then by checking the planned breaking changes issue for the four exporters marked for removal.
Frequently asked questions
What is the AWS Distro for OpenTelemetry Collector?
It is an AWS supported version of the upstream OpenTelemetry Collector, distributed by Amazon, supporting selected components from the OpenTelemetry community. It is compatible with EC2, ECS and EKS and sends telemetry to CloudWatch Metrics, Traces and Logs as well as other supported backends.
Which components does the ADOT Collector include?
A curated set: receivers including the Prometheus, OTLP, AWS X-Ray, ECS container metrics, StatsD and Zipkin receivers, processors including attributes, resource, batch, memory limiter and probabilistic sampler, exporters including AWS X-Ray, AWS EMF, Prometheus remote write, OTLP and debug, and extensions including health check, pprof, zPages, ECS observer, AWS proxy and SigV4 authentication.
Which ADOT Collector components are being removed?
The README has a notice about planned breaking changes naming the datadog, logzio, sapm and signalfx exporter components, and points users of those to a specific issue for the details. The go.mod still lists several of them, so they are present now and scheduled for removal.
How does the ADOT Collector differ from the upstream OpenTelemetry Collector?
The ADOT Collector is a fork with a curated component set and AWS support behind it, carrying AWS-specific components such as the AWS X-Ray receiver, the ECS container metrics receiver and the AWS proxy extension. Upstream carries the full contrib catalogue and is rebuilt more often, so it offers more components with less support.
How is the ADOT Collector built and how do you identify a build?
With a Makefile that compiles Go with CGO disabled and injects the Git hash, the version read from the VERSION file and a UTC build date through linker flags. A PARALLEL variable enables parallel module builds for runners with eight or more cores.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/aws-observability-aws-otel-collector)Was this useful?