> ## Documentation Index
> Fetch the complete documentation index at: https://docs.odigos.io/llms.txt
> Use this file to discover all available pages before exploring further.
# 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](/central/adding-connections/remote-clusters) and [VM Agent](/central/adding-connections/vmagent).
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
Follow the [Central installation](/central/installation) guide.
Set `cloudConnectors.enabled=true`. See [Enable Cloud Connectors](/cloud-connectors/enable).
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](#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](/cloud-connectors/add-connectors/add-aws-connector)).
## 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](/cloud-connectors/aws/overview) 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](#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](/cloud-connectors/instrument-workloads#add-an-otlp-destination). For how to add and configure destinations, see the [Destinations overview](/enterprise/backends-overview).
## Next steps
Turn on the feature in Helm or the CLI, including Postgres settings.
Connect an AWS account and discover Lambda and ECS resources.
Connect a Google Cloud project and discover Cloud Run services.
Create Sources and track instrumentation after a connector is online.
Full AWS connector reference: flows, artifact preloading, and CDK/CloudFormation for every instrumentation type.