Cloud Connectors Overview

Use Odigos Central Cloud Connectors to discover and instrument cloud workloads across supported providers from a single control plane.

Cloud Connectors are the third connection type in Odigos Central, alongside Remote Clusters and VM Agent.

Each connector manages one cloud account boundary (for example an AWS account, a GCP project, or another supported provider). From Central you discover workloads in that account, create Sources for the ones you want to observe, and track instrumentation progress.

Prerequisites

1. Install Odigos Central

   Follow the Central installation guide.

2. Enable Cloud Connectors

   Set cloudConnectors.enabled=true. See Enable Cloud Connectors.

3. Prepare cloud access

   Create a cloud identity (e.g. IAM role or service account) with only the permissions you want the connector to have. See You control the access scope.

Why use Cloud Connectors?

• Unified management — Manage serverless and cloud workloads alongside Kubernetes clusters and VM hosts from the same Central UI
• Automatic discovery — Surface instrumentable workloads in the account boundary without hunting for each resource by hand
• Flexible scale — Instrument one workload or many at once from discovery; nothing is instrumented until you choose
• Less operational overhead — Avoid manually attaching layers, agents, or env vars on every Lambda or Cloud Run service
• Centralized credentials — Cloud credentials live as Secrets in the Central cluster; one connector owns one account boundary for clear blast radius and ownership

You control the access scope

Cloud Connectors do not get blanket access to your cloud environment. What each connector can discover and instrument is limited by the access you grant.

Scope is defined by your cloud permissions (e.g. IAM policies or service account roles), plus the resource types you enable on the connector. Odigos only acts within that boundary.

Three layers work together:

1. Cloud credentials and permissions — The role or service account you attach decides which APIs and resources the connector can call. Narrow policies mean a narrower discovery and instrumentation footprint.
2. Connector capabilities — When you add a connector, you choose which resource types may be discovered and which may be instrumented (per-type capabilities).
3. Sources — Even after discovery, nothing is instrumented until you create Sources for the workloads you select.

Provider-specific permission lists are covered on the corresponding Add connector pages (for example Add AWS).

Workloads and compute platforms

Connectors organize resources into two domains:

• Workloads — resources Odigos discovers and can instrument directly (for example AWS Lambda or GCP Cloud Run).
• Compute platforms — managed environments such as ECS clusters, GKE, or Compute Engine. These can be discovered today; installing a separate Odigos agent onto them expands coverage over time.

You choose which resource types to discover and instrument when you add a connector (per-type capabilities).

Odigos-managed vs. self-managed instrumentation

When adding or editing a connector, choose an instrumentation method for each workload type:

Discovery	Instrumentation	Mode	Who applies the change
On	On	Odigos-managed (automatic)	Odigos attaches instrumentation for you (a Lambda layer + environment, or a sidecar injected into an ECS task definition) and keeps it in place on every reconcile cycle.
On	Off	Self-managed (IaC)	You apply the change yourself — CloudFormation, CDK, Terraform, or by hand. Odigos only discovers and reports status; it never modifies the resource.
Off	—	Not discovered	The type is not surfaced at all.

Rather than using a dedicated mode toggle, Odigos controls access through per-type instrumentation settings. This ensures self-managed workloads are safe by default—Odigos cannot touch or configure a resource unless its instrumentation capability is active.

Pick self-managed when your organization already provisions Lambda functions or ECS task definitions through CloudFormation, CDK, or Terraform and you want that pipeline to stay the source of truth. Pick Odigos-managed when you want instrumentation applied and kept up to date without changing your IaC.

A self-managed workload shows as Not Instrumented / Waiting for you until Odigos observes that you’ve applied its instrumentation, then it flips to Instrumented on its own — there is nothing to click on the Odigos side. If a self-managed workload is later disabled as a Source or its Source is deleted while your instrumentation is still applied, it reports an error rather than silently going dark — Odigos never removes instrumentation it did not apply, so taking it back out is yours to do.

Instrument a given workload one way, not both. A function or service you instrument yourself and also enable as an Odigos-managed Source is owned by both sides — every IaC deploy reasserts your configuration, every Odigos reconcile reasserts its own, and you get a new function version or task revision on every round trip.

For AWS specifically, see AWS Connector for how to instrument Lambda and Fargate yourself with CloudFormation or CDK, and how to preload artifacts into your own account first.

Resource coverage

Current coverage includes the following providers and resource types. Additional providers may be added over time.

Provider	Discover	Instrument
AWS Lambda (aws.lambda)	Yes	Yes — Odigos-managed or self-managed
Amazon ECS Fargate tasks (aws.fargate-task)	Yes	Yes — Odigos-managed or self-managed
Amazon ECS clusters (aws.ecs-cluster, aws.fargate-cluster)	Yes	n/a (coverage/grouping only; agent install coming soon)
GCP Cloud Run (gcp.cloud-run)	Yes	Yes
GKE (gcp.gke) / Compute Engine (gcp.gce)	Yes	Coming soon

Supported languages

Direct instrumentation depends on the workload type:

Workload	Supported languages
AWS Lambda (aws.lambda)	Java, Python, Node.js, Ruby
Amazon ECS Fargate tasks (aws.fargate-task)	Java, Python, Node.js, .NET, PHP, Ruby
GCP Cloud Run (gcp.cloud-run)	Java, Python, Node.js, .NET

Other Lambda runtimes (for example Go or .NET) can still be discovered; they are not instrumented until support for those runtimes is added. On Fargate, Go and any other eBPF-based language cannot be instrumented at all — Fargate does not allow the privileged containers eBPF needs — and a task with no other instrumentable container is reported unsupported.

AWS Lambda Ruby, and Fargate PHP and Ruby, support OTLP HTTP only. See Telemetry export for destination protocol limits.

Telemetry export

Instrumented workloads export OpenTelemetry data to an OTLP endpoint you configure on the connector. That endpoint must be reachable from the cloud environment (for example from Lambda or Cloud Run).

Lambda, Fargate, and Cloud Run support OTLP destinations only. Fargate tasks export directly to the destination — there is no node-local collector on ECS the way there is inside the Lambda layer, so the destination endpoint must be reachable from the task’s VPC.

Protocol support for AWS Lambda:

• Python, Node.js, Java — OTLP gRPC and OTLP HTTP
• Ruby — OTLP HTTP only

Protocol support for Amazon ECS Fargate:

• Java, Python, Node.js, .NET — prefer OTLP HTTP but honor OTLP gRPC if that’s all the destination offers
• PHP, Ruby — OTLP HTTP only; without an OTLP HTTP endpoint on the destination these languages cannot be instrumented at all

GCP Cloud Run supports OTLP gRPC and OTLP HTTP.

See Add an OTLP destination. For how to add and configure destinations, see the Destinations overview.

Next steps

Enable Cloud Connectors

Turn on the feature in Helm or the CLI, including Postgres settings.

Add AWS connector

Connect an AWS account and discover Lambda and ECS resources.

Add GCP connector

Connect a Google Cloud project and discover Cloud Run services.

Instrument workloads

Create Sources and track instrumentation after a connector is online.

AWS Connector

Full AWS connector reference: flows, artifact preloading, and CDK/CloudFormation for every instrumentation type.