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 data 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.
Queried where it lives
Your billing export is written to your own account and queried in place. No copy is taken and 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.
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.
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 data and the billing relationship were never anywhere else. Remove the stack and what you lose is the governance layer, not 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?
Nowhere. Your billing export lands in your own account and is queried there. There is no vendor data lake, no copy held on our side, and no requirement to ship usage history to a third party before you can see a report about it.
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?
It keeps running. Everything was created in your accounts using your provider’s own services, so the resources, the data and the billing relationship are all yours already. There is no runtime of ours for your workloads to depend on.