Cloud Accounts
Registering and verifying credentialed links to AWS, Azure, GCP, and OCI — with separated read and execution roles and precise permission preflight.
At a glance
| Route | /aws-accounts |
| Group | Admin |
| Page permission | aws_accounts |
What it is
The connection management module. It registers and verifies credentialed links to AWS accounts, Azure subscriptions, GCP projects, and OCI tenancies, configures scan regions and execution roles, and runs permission preflight checks.
This module is the prerequisite for every data-bearing module in the product. Nothing else works properly until connections are verified here.
Who it is for
Cloud administrators and platform engineers performing initial onboarding and ongoing connection management.
How it works
Credential models, per provider
| Provider | Method | Notes |
|---|---|---|
| AWS | IAM AssumeRole with per-customer External ID | No long-lived access keys are ever stored |
| Azure | Service Principal | Client secret encrypted before persistence |
| GCP | Service Account key | Key material encrypted before persistence |
| OCI | API signing key | Encrypted before persistence |
Read and execution are separated
An organisation can run the entire analytical product indefinitely without granting any write access at all. This is a supported permanent posture, not just an onboarding phase.
Preflight reports precisely what is missing
A permission preflight reports exactly which permissions are missing — rather than failing opaquely at scan time, when the cause is much harder to diagnose.
Disconnection is clean and gated
Disconnection triggers a cleanup path so a removed account does not leave orphaned data, and it is a sensitive action requiring separate verification.
Features
- AWS connection via IAM AssumeRole with External ID; no access keys stored
- Azure, GCP, and OCI connections, all encrypted at rest
- Separate read and execution roles, verified independently
- Permission preflight reporting precisely which permissions are missing
- Per-account scan region configuration
- Billing settings per account
- Write-access verification as a distinct, permission-gated step
- Platform identity disclosure — the identity your role must trust
- AWS Organizations support with account assignment
- Disconnection with cleanup, gated by sensitive-action verification
- Connection health and notification on failure
How to use it
Read the platform identity panel first
This is the identity your IAM role must trust, and the External ID that must be set in its trust policy.
Create the read-only role using the documented policy
Then register the connection.
Run verify, and resolve everything preflight reports
Before proceeding. A partially permissioned connection produces confidently wrong numbers.
Configure scan regions
Restrict to regions actually in use. Unnecessary regions waste time and API quota; missing ones create blind spots.
Run in read-only mode until the analysis is trusted
There is no rush. Work findings, validate them, let a billing cycle pass.
Add the execution role when ready
Create it separately in your provider and verify write access as a distinct step.
Connect all accounts, not a representative sample
Partial connection produces confidently wrong totals — and silently disables the entire cross-cloud detector family.
Monitor connection health
A silently failed connection is the most damaging failure mode in the product, because every number downstream quietly becomes wrong.
Why it matters
Credential handling is where a cost platform earns or loses trust.
AssumeRole with External ID
Rather than access keys — there is no long-lived AWS credential in the platform to steal.
Everything else encrypted
Fernet symmetric encryption before persistence.
Read separated from execution
So write access is a deliberate, later, revocable decision.
Precise permission reporting
Rather than opaque failures that take days to diagnose.
Together these make the security review that precedes adoption survivable — and the read-only-first posture lets an organisation derive full analytical value before granting any write access at all.
Connects to
- The prerequisite for every data-bearing module in the product
- Ingestion runs surface in Overview
- Execution roles required by Optimization, Autopilot, and Resource Parking
- Permission state visible in Inventory coverage
- Step-by-step guide: Connecting your cloud
Org Analytics
Organisation-level analytics spanning every workspace — aggregate spend, account coverage, control adoption, and operational posture.
Integrations
The external connection hub — issue tracking, chat alerting and approvals, source control, Kubernetes ingestion, remediation controls, and execution windows.