Architecture
What runs where, and what we can see
It runs in your accounts.
So does your data.
Governance software asks for more trust than most purchases, so this page is the one a security reviewer should be able to read on their own. What is deployed, what it can reach, what leaves your estate, and how to take the access back.
Two planes, and only one
of them is ours
We operate a control plane as a managed service. Everything that touches your resources or your data runs inside your own accounts.
Operated by us
The control plane
The console, the API and the orchestration that decides what should happen. It holds your organisation structure, your policies and your budgets, and it calls into your accounts to act.
Yours
The application plane
The functions that watch cost, the events that trigger them, the compliance recorder, the queues, the logs and every resource anyone launches. All deployed into your accounts, all billed to you by your provider.
Your billing history stays
where it already lives
The usual arrangement is that a vendor ingests your billing and usage history into their own store, and reports on it from there. This does not. Two tables land in your own account: your billing in FOCUS 1.3, the FinOps Foundation open standard, and your provider’s own detailed export enriched with who and what each line of spend belongs to.
Queried where it lives
Your billing export is written to your own account, enriched there, and queried in place by the query service your cloud already provides. No history is shipped anywhere to be indexed.
No agent, no proxy
Nothing is installed on a host and nothing sits in your network path. There is no software of ours inside your applications to review, patch or trust.
Accounts, not contents
We govern accounts and their configuration. What your systems hold is not something we process, store or need in order to work.
The live picture of what is currently running is the one exception, and it has to be. Evaluating cost at the moment a resource is created means holding that picture somewhere fast enough to answer in the moment, so the platform keeps it. It is operational state rather than a copy of your history, and it records what exists rather than what is inside it.
Access is granted per account,
and it comes back
Governing cost takes far less access than most people assume. You choose the level when you connect an account, you can change it later, and each level is a different template rather than a setting we control.
Observe
No administrative access
Live cost, allocation, idle detection and compliance scanning, with no ability to change anything you run.
Govern
Still no administrative access
Budgets, quotas and restrictions enforced when a resource is created. Prevention does not require the power to act on what already exists.
Automate
Administrative, per account
Stopping, cleaning up, remediating and recycling. This is the level that needs it, and it is granted one account at a time.
Whatever you grant, you can withdraw. Removing the stack removes the roles it created, and the trust that let us assume them.
Built on things you
can already read
Where a component could be open or proprietary, it is open. That is a reversibility decision as much as a technical one: what you build here should not need rebuilding if you leave.
Cost data
Your billing is written to FOCUS 1.3, the FinOps Foundation open billing standard, on AWS and Azure. The tables read the same across both, and anything that speaks the spec can read them.
Compliance policies
Policy definitions in an open format you can read, audit and extend, rather than rules only the vendor can see.
Infrastructure as code
CloudFormation and Terraform, run as written. No intermediate language and no translation layer of ours between you and the cloud.
Big data
Standard Spark and Hadoop distributions with the applications you choose. No proprietary runtime to adopt.
The interface itself
A documented API with an OpenAPI description, SDKs, a command line and MCP servers. Anything the console does, you can do without it.
The first customer
We run on it
We run the whole platform. The servers behind this service are launched and managed as RosettaCloud formations. Our own cloud accounts, budgets, permissions and compliance run through RosettaOps. The same operations, the same console, and the same enforcement at the cloud API that you would be buying.
It is the estate the company runs on, and it has been managed this way for years.
We depend on every control we ship.
What happens if you leave
Your estate keeps running. Everything was created in your accounts through your provider’s own services, so the resources, the billing relationship and the cost tables behind them were never anywhere else, and those tables stay queryable by the query service your cloud already provides. What you lose is the console, the live view and the enrichment that shapes them, which is the service rather than the infrastructure underneath it.
A platform worth adopting should be able to answer that question in a paragraph.
Common questions
Where does our cloud cost and usage data go?
Your billing and usage history stays in your account. The export lands there, is enriched there and is queried there by the query service your cloud already provides, so there is no vendor data lake and no requirement to ship usage history to a third party before you can see a number. The live picture of what is running is different: that is operational state the platform holds, because evaluating cost as a resource is created means keeping it somewhere fast enough to answer in the moment. The console and the enrichment that shapes your tables are ours as well.
Is there an agent or a proxy to install?
No. Deployment is a template applied to your management account. Nothing is installed on a host, nothing sits in your network path, and there is no software of ours running inside your applications.
What access does RosettaHub hold on our accounts?
Whatever you granted, per account, and no more. Read-only reporting needs no administrative access at all, and preventive enforcement does not either. Acting on a resource that already exists does, and that is granted account by account. Removing the stack removes the access with it.
What happens to our estate if we stop being a customer?
Your estate keeps running. Everything was created in your accounts using your provider’s own services, so the resources, the billing relationship and the cost tables behind them are yours already and stay queryable by the query service your cloud already provides. What you lose is the console, the live view and the enrichment that shapes those tables, which are the service rather than the data. There is no runtime of ours for your workloads to depend on.