Running an OpenTelemetry collector as a sidecar in each Amazon Elastic Container Service (Amazon ECS) task works at small scale. It doesn’t hold up across a multi-account estate, and on Windows it doesn’t run at all. The AWS Distro for OpenTelemetry (ADOT) collector ships as a Linux container. It can’t run as a sidecar alongside a Windows . NET Framework task. Those services then go uninstrumented, or they carry a sidecar that can’t start on Windows and consumes resources without collecting anything. The sidecar model also adds cost on Linux at scale. A collector in each task carries a per-task CPU and memory overhead.
Configuration drifts as each copy changes independently, and there is no central point for ingestion policy. In this post, you replace per-task sidecars with a single centralized ADOT collector, a “gateway,” deployed in a dedicated observability account. You push OpenTelemetry Protocol (OTLP) data from workloads across many accounts to the gateway over private connectivity through AWS Transit Gateway. The gateway exports traces to AWS X-Ray and metrics and logs to Amazon CloudWatch.
This pattern extends the 2021 post Using AWS Distro for OpenTelemetry Collector for cross-account metrics collection on Amazon ECS , which centralized metrics only through a Prometheus scrape with remote write to Amazon Managed Service for Prometheus. Here you centralize the full signal set of traces, metrics, and logs with an OTLP push gateway, and cover Windows . NET Framework tasks that a Linux sidecar can’t. It’s the Amazon ECS counterpart to Implement centralized observability for multi-account Amazon EKS for Amazon Elastic Kubernetes Service (Amazon EKS). You will learn how to deploy the gateway behind an internal Network Load Balancer, connect workload accounts, instrumen