> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tensorcost.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Connect cloud accounts
> Connect AWS, Azure, and GCP so TensorCost can read your infrastructure spend — separate from connecting Bedrock, Azure OpenAI, or Vertex for AI usage.
# Connect cloud accounts
TensorCost reads your cloud provider's own cost and billing data — AWS, Azure, and GCP — to attribute infrastructure spend across your fleet. This is **read-only, always**: none of the three connections below grant TensorCost permission to create, modify, start, or stop anything in your account.
This page is about the **Cloud** tab of Connect — general infrastructure spend (compute, storage, networking, everything AWS/Azure/GCP bill you for). If you're connecting Amazon Bedrock, Azure OpenAI, or Vertex AI specifically to track LLM usage and get model-routing recommendations, that's the **AI** tab of the same page — see [Bedrock integration](/bedrock-integration) for that flow. The two are separate connections with separate credentials, even when they point at the same cloud account.
## Where to go
**Build → Connect**, Cloud tab (the default tab). Each provider is its own card: click **Connect →** to open its setup form, or **+ Add account** if you already have one connected and want to add another (all three providers support connecting more than one account/subscription/project).
## The three providers at a glance
| Provider | What TensorCost reads | Auth mechanism | Typical setup time |
| ------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------- | ---------------------------------- |
| [Amazon Web Services](/aws-cost-connect) | Cost and usage data via a cross-account IAM role; optionally a Cost and Usage Report (CUR 2.0) export for exact line-item detail | Cross-account IAM role + `sts:ExternalId` | A few minutes |
| [Microsoft Azure](/azure-cost-connect) | A daily FOCUS-format Cost Management export | TensorCost's own multi-tenant Entra application — no customer client secret | About 10 minutes, needs two people |
| [Google Cloud Platform](/gcp-cost-connect) | Your BigQuery billing export | A service account key you create, or Workload Identity Federation (no key at all) | 10–15 minutes |
FOCUS (the FinOps Open Cost and Usage Specification) is an industry-standard billing-data format. Where a provider's export uses it, that's noted above — you don't have to build or maintain the export format yourself, only turn it on.
## What "read-only" actually grants
Each connection is scoped to the minimum a FinOps tool needs to read spend, nothing more:
* **AWS** — the role TensorCost assumes has no write permissions on anything. It can read cost and usage data and, if you opt in, list and read objects in a CUR export bucket.
* **Azure** — two read-only RBAC roles: Cost Management Reader on the subscription, and Storage Blob Data Reader scoped to the export storage container. Nothing else.
* **GCP** — `roles/bigquery.dataViewer` on the billing-export dataset and `roles/bigquery.jobUser` to run the read query. Nothing else.
## Verify before you connect
All three providers have a **Verify** step before the account activates, and it's a real connectivity check, not a format check:
* AWS actually performs `sts:AssumeRole` against the role and External ID you entered.
* Azure actually mints a token and confirms it can list your export's storage container.
* GCP actually mints a token (or runs the full Workload Identity Federation exchange) and, if you've already pointed it at a BigQuery dataset, confirms it can read it.
Verify **fails closed**. If the export or dataset doesn't exist yet, or the connection can't reach it, Verify refuses the connection rather than silently activating something that will never produce data. One exception worth knowing: an export or dataset that exists but is currently *empty* still passes — a brand-new export can legitimately take up to 24 hours to write its first row, and that's a different, better state than "doesn't exist."
## Status after you connect
Once connected, each provider card shows one of these states:
| State | Meaning |
| ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
| **NOT CONNECTED** | No account connected yet for this provider |
| **AWAITING SYNC** | Connected and verified; the first scheduled sync hasn't run yet (normal for up to \~24 hours after connecting) |
| **CONNECTED** | Connected and synced within the last 24 hours |
| **STALE** | Synced before, but not in the last 24 hours — usually a stopped export or a broken pipeline on the provider side, not a credential problem |
| **ERROR** | At least one connected account is failing |
If you connect more than one account per provider (multiple AWS accounts, multiple Azure subscriptions, multiple GCP projects), the card rolls all of them into one status — worst-case wins, so one broken account shows as ERROR even if the others are healthy.
## Disconnecting
Removing a connection deletes the stored credentials and stops future syncs. Historical spend data already ingested is kept — you can reconnect later without losing your cost history.
## Next steps
Cross-account IAM role, ExternalId, optional CUR export.
Secretless by design — needs a directory admin and a subscription owner.
Service account key or Workload Identity Federation.