AWS Connector

The AWS Connector is one running instance that owns one AWS account. It scans every region enabled in that account, discovers Lambda functions and ECS/Fargate resources, and — for the types you allow — either instruments them for you or reports on instrumentation you applied yourself. This page is the map. For hands-on tasks, see:

​

Resource types

The connector splits AWS resources into two domains — workloads, which it can instrument directly, and compute platforms, which it can only discover today:

​

EC2-launch-type ECS is a separate story

Everything on this page and in the AWS Connector section covers Fargate-launch-type ECS. EC2-launch-type ECS clusters are discovered as aws.ecs-cluster compute platforms, but Fargate forbids the privileged containers eBPF instrumentation needs, so EC2-backed clusters are covered by a different, cluster-wide agent rather than the per-service sidecar described here. That agent’s automatic deployment is not yet available — today aws.ecs-cluster gives you discovery and coverage only.

​

Odigos-managed vs. self-managed

Both workload types support two independent modes, chosen per type when you add or edit the connector. This is a connector-wide concept — see Odigos-managed vs. self-managed instrumentation for the general rules (the marker system, why you should pick one mode per workload, and so on). On AWS specifically: Self-managed is the default the moment you enable discovery without instrumentation for a type — nothing extra to configure. See Instrument Lambda and Instrument Fargate for the actual snippets, and Preload Lambda layer / Preload Fargate image for getting artifacts into your own account first if your organization requires that.

​

Supported languages

If a task runs more than one container — for example, an nginx or Envoy proxy sitting in front of your application — Odigos has to pick which one is the actual application to instrument. It does this by looking at what’s really running inside each container, not by which one has a public port. That distinction matters: the proxy is usually the container with the port mapping, but the proxy has no code to instrument — it’s the application container behind it that needs the agent. Picking by port would target the wrong container entirely. If Odigos can’t confidently identify exactly one application container — none of them look like an app, or more than one equally do — it marks the task unsupported rather than guessing. The same happens if the task definition is already at AWS’s 10-container limit, since there’s no room left for the extra container Odigos needs to add.

​

Telemetry export

Both Lambda and Fargate export OTLP only, and the destination must be reachable from the workload itself:

• Lambda ships an in-process collector inside the layer. Your function’s SDK exports to localhost inside the same sandbox; the collector forwards to your configured destination after the handler returns, so a slow or unreachable destination costs billed duration, not response latency.
• Fargate has no node-local collector — each instrumented task exports directly to the destination over its own network path. The destination endpoint must be reachable from the task’s VPC (public IP or NAT for a registry pull, plus whatever egress the destination itself needs).

​

Next steps

Self-managed instrumentation — pick your workload: Using @odigos/aws-cdk? Start from the CDK overview (install, destinations, markers), then the Lambda or Fargate construct reference. Still setting up the connector? See Add an AWS Connector. For Odigos-managed Sources after the connector is online, create them in Central once an OTLP destination is configured.