# Log routing architecture: pick the path per source

Logs reach Datadog by three paths. Each source should use exactly one, chosen deliberately.

## The three paths

1. **Agent**: host logs, container stdout/stderr, anything on a machine you control. The agent tails files and container logs, applies the source/service mapping, and ships. Default choice for your own compute.
2. **Forwarder (Lambda)**: AWS services that write to S3 or CloudWatch (ELB logs, CloudTrail, RDS, VPC flow logs). The forwarder subscribes and ships. Give it reserved concurrency (docs recommend at least 10) so a log flood does not starve it.
3. **Direct API**: apps that cannot run an agent or forwarder. Fine for low volume; at scale you are reimplementing batching the agent does for free.

## Design rules

- **One path per source.** The same log arriving via agent and forwarder is a duplicate-bill and a double-count. Audit for overlaps after every architecture change.
- **Tag at the edge.** Set source/service/env as close to the origin as possible (agent config, forwarder env). Routing and pipelines key off these; late tagging means misrouted logs.
- **S3 archival**: decide retention per log type up front. Everything into Datadog with long retention is the expensive default; archive cold logs to S3 and rehydrate on demand.
- **Cloud service logs via the integration**, not DIY forwarders: the AWS integration wires CloudWatch and S3 sources with the right parsing out of the box.

## Verify

For each log source, name its path and prove it: one live-tail check per path, no source appearing twice, and the forwarder concurrency metrics flat during a traffic spike.