> ## Documentation Index
> Fetch the complete documentation index at: https://docs.bronto.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Amazon EKS Logs and Traces

> Choose the right ingestion path for pod logs, control plane logs, and distributed traces from Amazon EKS clusters.

Amazon EKS emits pod `stdout` / `stderr` logs from your workloads and — when your applications are instrumented with OpenTelemetry — distributed traces. EKS clusters also emit control plane logs (API server, audit, scheduler, controller manager, authenticator); those are written directly to CloudWatch by AWS and cannot be collected by an in-cluster agent.

## Recommended method

[**ADOT**](./aws-adot) — the OpenTelemetry Collector on EKS collects pod logs and application traces and ships them over OTLP to Bronto. Deploy as a DaemonSet on EC2 node groups; on Fargate-backed EKS, deploy as a per-pod sidecar instead — DaemonSets can't run on Fargate nodes. Use the same `service.name` / `service.namespace` routing as your other OTel workloads (see [Data Organization](/Search-and-Visualize/Partitions)).

## Alternatives

* [**Fluent Bit on EKS**](./aws-fluent-bit-eks) — DaemonSet that collects container logs from every node; lighter than a full collector.
* [**Self-Managed OTel Collector**](./aws-custom-otel) — full control over the OpenTelemetry pipeline when ADOT's distribution doesn't fit.
* [**CloudWatch Log Forwarder**](./aws-client-cloudwatch) — required path for EKS control plane logs, which are CloudWatch-only.

See [Ingesting AWS Data into Bronto](./aws-overview) for the full service-to-method mapping.

## References

* [Amazon EKS — control plane logs](https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html)