Connecting a billing tool should not require creating another long-lived access key. Mosaic's AWS connection uses a role in your account, temporary credentials, and a small registration handshake. Here is what crosses the account boundary and what you can revoke.
The role is the access boundary
The CloudFormation stack creates a named IAM role with three Cost Explorer read
actions: ce:GetCostAndUsage, ce:GetDimensionValues, and ce:GetTags. Those
permissions let Mosaic retrieve billing dimensions and costs. They do not grant
workload writes or permission to read application objects from S3.
The trust policy identifies Mosaic's AWS account and requires an external ID. When a worker needs costs, it calls STS AssumeRole with that external ID and uses the returned temporary credentials. There is no customer IAM-user key to rotate in Mosaic. This follows AWS's third-party role access model.
Why an external ID and a callback token are different
The external ID binds a role-assumption request to a Mosaic connection. It helps prevent a customer from persuading a shared service to act against somebody else's role, the confused deputy problem. An external ID is a trust-policy condition, not a replacement for the trusted AWS principal.
Registration has a different purpose. A separate random callback token proves that the stack belongs to the current setup attempt. Mosaic encrypts both values in storage and exposes setup material only to authenticated organization administrators. Separating these values keeps the registration handshake independent of the role's ongoing access condition.
Let AWS identify the selected account
The customer chooses an account in AWS and creates the generated stack in
us-east-1. Console and CLI setup use the same persisted stack name, role name,
external ID, attempt identifier, and callback token. Resuming does not silently
rotate those parameters; restarting does.
An SNS-backed CloudFormation custom resource sends the role ARN and account identity to Mosaic's callback service. The customer does not deploy a Lambda function. Mosaic checks the token, current attempt, role name, account, and stack identity before recording the discovered role. A duplicate delivery cannot replace a connection with a different stack, and an older attempt cannot overwrite its replacement.
Registration is not billing readiness
A CloudFormation stack finishing successfully means the role and registration were created. It does not mean AWS billing data is ready. Mosaic first assumes the role, then probes Cost Explorer. Successful access queues the selected initial history import, from one to thirteen months, with six months as the default.
Checks persist their result and use a lease to avoid overlapping probes. A background schedule continues checks when the browser is closed. Activation and initial import creation share a database transaction, so a connection cannot become active halfway through queuing its first import.
When AWS specifically reports unavailable data, Mosaic suggests checking Cost Explorer enablement and allowing AWS to prepare billing data. A generic failure or an empty response cannot justify saying that Cost Explorer is disabled. AWS documents the preparation process.
Cost Explorer requests also have a cost. Historical ranges and pagination affect request counts; consult AWS's API pricing.
Revocation remains in your account
Disconnecting in Mosaic stops the connection while retaining imported history. Deleting the CloudFormation stack removes the role and sends a deletion callback; that callback can disable only the connection bound to that stack. If delivery fails, disconnect in Mosaic too.
For prerequisites, account selection, CLI instructions, and recovery steps, follow the AWS connection guide.