Connecting your cloud

Scopes, permissions, collection cadence, and how Flux behaves when a source is throttled or unavailable.

Flux connects to your cloud read-only using a managed workload identity. There are no credentials in its codebase and none to rotate by hand.

Permissions #

Grant the Flux identity read access across every subscription in scope:

Permission Grants
Resource read Inventory, tags, configuration, change detection
Cost Management read Actual and amortized cost, daily history, charge detail
Advisor read Vendor recommendations
Metrics read Utilization for right-sizing and idle detection
Policy read Compliance posture and exemptions
Least privilege in practice A single custom reader role covering these is easier to audit than five separate assignments, and makes it obvious to a security reviewer that no write permission was granted anywhere.

Charge-level billing data #

For the deepest cost analysis — per-commitment utilization, discount realization against list price, and effective versus billed cost — Flux ingests billing exports in FOCUS format, the FinOps Foundation’s open billing standard.

Configure a recurring export to a storage container and grant the Flux identity read access to it. Flux imports each manifest idempotently, so a re-delivered export never double-counts.

Optional but worth it Everything else works without FOCUS data. Commitment utilization and discount analysis are the features that specifically depend on it.

Collection cadence #

Sources collect independently on their own schedules, which is what stops a slow or throttled source from holding up the rest:

Source Typical cadence Notes
Inventory Several times daily Each run is a retained snapshot
Cost Daily, checkpointed Resumes from where it stopped
Advisor Daily
Policy Daily
Telemetry Rolling Incremental, checkpointed per resource
FOCUS import Per export delivery Idempotent by manifest

When a source misbehaves #

Cloud billing APIs throttle aggressively on large estates. Flux is built for that rather than surprised by it:

  • Requests are paced against a shared rate gate, so parallel collectors cannot collectively exceed the quota.
  • Throttling is recorded, not just retried — you can see that a scope was throttled and when it will be retried.
  • Failed scopes are retried first on the next run, ahead of new work.
  • Last-good data survives. A failed run never replaces good data with partial data.
  • Coverage is visible. Integrations shows per-source freshness and which scopes are complete, partial, or stalled.
Partial coverage is surfaced, not smoothed over If a subscription’s cost data did not land, totals that include it are labelled partial. This is deliberate: a quietly incomplete total is worse than an obviously incomplete one, because someone will act on it.

Multi-subscription estates #

Add every subscription you want in scope. Flux treats each as an independent collection scope with its own checkpoint and retry state, then reports across them.

For allocation and showback across subscriptions, see Cost allocation — attribution is driven by tags, not subscription boundaries, so it works across a fragmented estate.