Connecting Your Cloud
How each provider connects, what credentials are used, how they are protected, and why read and execution access are kept separate.
Connecting a cloud account is the prerequisite for every data-bearing module in the product. This page explains what happens, per provider, and why the credential model is shaped the way it is.
Read access and execution access are separate
This is the most important idea on the page.
A connection is registered with read-only credentials for analysis. A second, higher-privilege execution role is what makes automated remediation possible, and it is verified and stored separately.
You can stay read-only forever
An organisation can run the entire analytical product indefinitely without granting any write access at all. Execution is opt-in, per connection, as a distinct step.
Per-provider credential model
Method: IAM AssumeRole with an External ID.
No long-lived access keys are ever stored. You create a role in your own account whose trust policy names the platform identity and a per-customer External ID. The External ID is what prevents the confused-deputy problem — another customer cannot trick the platform into assuming your role.
What gets ingested:
| Source | What it provides |
|---|---|
| Cost Explorer | Fast spend summaries |
| CUR via Athena | Authoritative billing detail, daily and hourly |
| CloudWatch metrics & Logs Insights | Measured utilisation — the evidence behind rightsizing |
| Live resource scanning | The inventory register |
| AWS Pricing API | Live prices for costing changes before they ship |
Active detectors: 102
How credentials are protected
Encrypted at rest
Every stored cloud credential is encrypted using Fernet symmetric encryption (AES-128-CBC with HMAC-SHA256) before it is persisted.
No shared identity
Each workspace executes exclusively under its own cloud credentials. There is no shared execution identity across customers.
AWS stores no keys at all
AssumeRole with External ID means there is no long-lived AWS credential in the platform to steal.
Disconnection is a sensitive action
Removing a cloud account requires a second, separately verified challenge — and triggers a cleanup path so no orphaned data is left behind.
The connection procedure
Read the platform identity panel
It shows the identity your role must trust and the External ID that must appear in the trust policy. Do not skip this — it is the input to the next step.
Create the read-only role in your provider
Use the documented policy for your provider. Grant read scope only at this stage.
Register the connection and verify
The permission preflight reports exactly which permissions are missing rather than failing opaquely later. Resolve every gap it reports.
Configure scan regions
Restrict to regions actually in use. Unnecessary regions waste time and API quota; missing regions create silent blind spots.
Run read-only until you trust the analysis
Work the findings, check them against your own dashboards, and let a full billing cycle pass. There is no rush to grant write access.
Add the execution role when ready
Create it separately in your provider and verify write access as a distinct, permission-gated step. Only then can Optimization, Autopilot, and Resource Parking execute.
Repeat for every account
Connect all accounts, not a representative sample. Partial connection produces confidently wrong totals across every other module.
Watch connection health
A silently failed connection is the most damaging failure mode in the product — every number downstream quietly becomes wrong. Connection health is surfaced in Cloud Accounts and on Overview, and failures raise a notification.