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

# Cloud providers

> The read-only investigators for AWS, Azure and Google Cloud — what each one reads, what it needs connected, and where each stops.

Three catalog agents investigate incidents inside a cloud account: **AWS Infrastructure
Investigator**, **Azure Investigator**, and **Google Cloud Investigator**. Each takes an incident
description and the questions you want answered, reads that provider's own evidence, and returns
structured findings that cite what they are based on.

All three are strictly read-only. None of them has a mutating tool in any deployment mode, so none
can stop a resource, change a policy, or roll anything back — turning a finding into an action is
[Remediation Executor](/manage-your-agents/build/catalog/remediation-executor)'s job.

## AWS Infrastructure Investigator

Traces root causes through configuration changes, access-control layers and resource dependencies,
citing the CloudTrail event, metric or policy behind each claim.

| Source        | What it uses it for                                                 |
| ------------- | ------------------------------------------------------------------- |
| CloudTrail    | Who changed what, and when — the change timeline behind an incident |
| CloudWatch    | Metrics and alarms around the incident window                       |
| IAM           | Policies, roles and trust relationships, when access is the suspect |
| Resource APIs | Dependencies between resources, and their current configuration     |

**Before you deploy** — model access, plus AWS access unless the pod supplies its own identity. The
AWS connection offers two authentication modes, and which you see depends on where the agent runs:

| Mode                       | How it works                                                                                                                                                     | Offered for   |
| -------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------- |
| **Cross-account IAM role** | Komodor assumes a read-only role in your account per run, from a CloudFormation stack you deploy. No long-lived keys stored. You supply the 12-digit account ID. | Komodor cloud |
| **IRSA**                   | The pod inherits AWS access from its Kubernetes ServiceAccount's IAM role, so there is no connection to bind. You supply the role ARN.                           | Self-hosted   |

<Note>
  The AWS connection is optional because IRSA replaces it. Deployed self-hosted with a ServiceAccount
  that already carries the role, the agent needs no connection at all.
</Note>

<Warning>
  A connection is validated as configuration, not as working AWS access. A well-formed role ARN with
  insufficient permissions deploys cleanly and fails on the first run — read that run rather than
  treating a successful deploy as proof.
</Warning>

**Where it stops.** It sees only what its credentials reach. An investigation scoped to one account
cannot observe a cause living in another, and it reports the gap rather than inferring across it.

## Azure Investigator

Locates the affected resources, reads their metrics and logs, and correlates what it finds into
findings that each carry a portal deeplink — so the evidence can be opened rather than taken on
trust.

| Source          | What it uses it for                                                  |
| --------------- | -------------------------------------------------------------------- |
| Resource Graph  | Finding the affected resources and their relationships               |
| Monitor         | Metrics across the incident window                                   |
| Log Analytics   | Log queries, in KQL                                                  |
| AKS             | Cluster metadata, when the workload is on Kubernetes                 |
| Cost Management | Spend signals, when the symptom is financial rather than operational |

The five capabilities above were measured against a plain **Reader** role rather than assumed from
documentation.

**Before you deploy** — model access, and an Azure connection with read-only access across those
five capabilities.

<Note>
  Unlike the Datadog and Grafana investigators, this agent has no MCP Gateway path. Azure publishes no
  hosted MCP endpoint, so there is no remote server to bind and no group to pick — its Azure tooling
  runs alongside it, configured from the connection you select.
</Note>

**Where it stops.** One subscription's worth of evidence, bounded by what the connection's role
permits. Where a capability is not granted, it reports the gap instead of inferring around it.

## Google Cloud Investigator

Narrows the log stream structurally — by resource, log name and severity rather than free-text
search — pins the earliest failing entry, and correlates it against the audit log to find the change
that preceded it. Findings cite the exact filter and time window, so a conclusion can be reproduced
by running the same query yourself.

| Source           | What it uses it for                                              |
| ---------------- | ---------------------------------------------------------------- |
| Cloud Logging    | The failing entries, narrowed by resource, log name and severity |
| Cloud audit logs | The change that preceded the first failure                       |

**Before you deploy** — model access, a Google Cloud connection with read-only Cloud Logging access
for the project the service-account key belongs to, and an
[integration group](/manage-your-agents/build/integration-groups), because the agent reaches Cloud
Logging through a group-scoped gateway endpoint.

<Note>
  The connection is required rather than optional: the gateway is this agent's only path. No
  alternative tooling is bundled alongside it, so without a connection it has no tools at all.
</Note>

**Where it stops.** It reads nothing outside Cloud Logging — metrics, traces, resource
configuration and billing are all out of reach, and where a cause lives in one of those it
establishes the timeline and says plainly that the rest is not something it can see. It is scoped to
the single project its service-account key belongs to.

## Next steps

<CardGroup cols={2}>
  <Card title="Agent catalog" href="/manage-your-agents/build/catalog/overview">
    Every deployable agent, and what each one is for.
  </Card>

  <Card title="Integrations list" href="/manage-your-agents/build/built-in-integrations">
    Connecting AWS, Azure and Google Cloud.
  </Card>

  <Card title="Use specialized agents" href="/manage-your-agents/build/use-specialized-agents">
    Deploying a catalog agent and what you can change afterwards.
  </Card>

  <Card title="Remediation Executor" href="/manage-your-agents/build/catalog/remediation-executor">
    Turning a finding into an action, with approval.
  </Card>
</CardGroup>


## Related topics

- [APM](/manage-your-agents/build/catalog/apm.md)
- [Agent catalog](/manage-your-agents/build/catalog/overview.md)
- [Kubernetes](/manage-your-agents/build/catalog/kubernetes.md)
- [Integrations list](/manage-your-agents/build/built-in-integrations.md)
- [Providers](/security-and-governance/architecture-considerations/providers.md)