Skip to content

The RosettaOps Model

An observation baseline on every cloud account, plus governance capabilities you grant one at a time -- across AWS, Azure, GCP, Alibaba Cloud, OVH, and OpenStack.

Three Editions, and a Set of Grants

No enterprise lets a new vendor touch its workloads on day one. Cloud operations teams need to validate a platform's value before granting it permission to change anything they run. RosettaOps is built around that, in two layers that are easy to confuse and worth keeping apart.

What you buy is an edition, and there are three. They line up with the three things RosettaOps does:

Edition What it adds
Observe See it Visibility plus the real-time Monitoring Service. Touches nothing you run
Govern Stop it Preventive enforcement at your cloud's own API. Still no administrative path for RosettaHub
Automate Fix it Remediation, cleanup, federated console access, and account vending
Build Build it Automate plus RosettaCloud, switched on across the accounts so the people working in them can provision for themselves

The boundary between Govern and Automate is the one that matters: Govern prevents, Automate remediates. Preventing something means writing policy, which needs no administrative rights. Acting on a resource that already exists does.

Governance is expressed as roles, not as any one cloud's policy language

You describe what a user, project or organization may do -- which regions, which services, which instance types, which models, how much budget -- and RosettaOps translates that into whatever each provider enforces natively. On AWS that translation produces service control policies; other clouds have their own mechanisms and get their own translation.

That is why a governance decision is made once rather than per cloud, and why this documentation talks about roles and budgets rather than policy documents. Your organizational structure and its roles live in the portal, which is the single place they are defined, and everything downstream is derived from it.

What you grant is a set of capabilities, chosen per cloud account. They are not a ladder and they do not have to be taken in order. An account can be fully governed without RosettaHub being able to create an account in it. It can provision self-service compute without RosettaHub being able to delete anything. The combinations are yours to pick.

This is not a tier system

RosettaOps has no fixed tiers of access. Capabilities are recorded per cloud account as an independent set, so two accounts in the same organization can carry entirely different grants. See Account Access and Scopes for what each capability grants and how it is deployed.

The Baseline

Every connected cloud account gets the same starting point, and none of it touches the resources you run:

Baseline capability What it covers
Inventory Describe compute, storage, network, and identity resources across accounts and providers
FinOps Billing and cost data collection, stored in your own cloud account
Monitoring The real-time Monitoring Service: live cost estimate plus continuous cost-vs-budget evaluation

That baseline is the whole of Observe, and it is where most customers start. It reads your estate and deploys its own instrumentation to do so; it does not touch the resources you run. See Observe for exactly what gets created.

The Grants

Everything beyond the baseline is granted deliberately, per account:

Capability What it lets RosettaOps do Administrative reach
Permissions Govern the organization: translate roles into the cloud's own policy layer, manage organizational structure, quota increases, contacts No
Federation Sign your users directly into the cloud provider's console, and share resources across accounts Yes
RosettaCloud Provision infrastructure on the account from Formations Yes
Destroy Stop and delete resources: cleanup, account recycling, halting spend Yes
Lifecycle Create cloud accounts, use organization root access, change a member account's root email Only over accounts RosettaHub creates

Governance is the cheap grant. Doing things in the account is the expensive one.

The intuitive guess is the wrong way round, so this is worth reading carefully.

Permissions leaves RosettaHub bounded by narrow, resource-scoped policies. An estate can be fully governed -- policies, organizational units, quotas -- while RosettaHub cannot start, stop, or delete a single resource in it.

Federation and RosettaCloud are administrative, and inherently so. Federated console access means putting your user into the account with real permissions. Provisioning a Formation means creating whatever that Formation describes. Neither can be done from a read-only position. RosettaHub does this through separate roles rather than by widening its governance role, but the reach is real.

Destroy is the one grant that attaches AdministratorAccess to RosettaHub's governance role, because stopping arbitrary resources is an administrative act. That is precisely what it is for: halting an account's spend and cleaning it up afterwards. An enforcement action that cannot stop the meter is not enforcement.

Lifecycle attaches no administrator policy at all. Its action set is small and fully enumerated. What it carries is structural and applies only to accounts RosettaHub creates: AWS plants an administrator role inside every new account it makes, and the account's root email address is a RosettaHub-generated one. Bring your own account IDs and neither applies. See Account Access and Scopes for how to close the bootstrap path once setup is verified.

What holds an administrative role in check

On a member account, the service control policy. It binds every principal in that account including the account's own root user, so it is a genuine perimeter rather than a policy attached to one role.

The management account is exempt from service control policies, which is why it is treated differently: it and the designated FinOps, audit, and log-archive accounts receive a read-only federation role with a read-only permissions boundary, rather than the member-account one.

Wherever Federation or RosettaCloud is granted, the organizational policy layer is doing the containing. It is not optional.

How the Editions Map to the Grants

graph LR
    subgraph obs ["OBSERVE -- baseline, always"]
        B1["Inventory"]
        B2["FinOps"]
        B3["Monitoring Service"]
    end

    subgraph gov ["GOVERN -- no admin path"]
        G1["Permissions"]
    end

    subgraph aut ["AUTOMATE -- admin path"]
        A1["Destroy"]
        A2["Federation"]
        A3["Lifecycle"]
        A4["RosettaCloud"]
    end

    obs --> gov --> aut

    style obs fill:#e3f2fd,stroke:#1565c0,color:#000
    style gov fill:#e8f5e9,stroke:#2e7d32,color:#000
    style aut fill:#fff3e0,stroke:#e65100,color:#000
Edition Grants Administrative path
Observe The baseline alone None
Govern Baseline plus Permissions None
Automate Baseline plus Permissions, plus any of Federation, RosettaCloud, Destroy, Lifecycle Yes

Each is a strict superset of the one above it. Because the grants are per account, an Automate customer does not have to enable everything everywhere -- a common shape is Destroy on development and sandbox accounts and nothing beyond Permissions on production.

Observe and Govern are the same file

Both deploy from the Governance template family, and the only difference is one parameter. That family carries no switch that would grant an administrative scope, so neither edition can acquire one by configuration. Moving from Observe to Govern is a parameter change; moving to Automate means deploying a different template, deliberately.

Observe -- See it

Access Level: Observation, not read-only

Observe does not modify, stop, or delete anything you run. It is not read-only, though, and we would rather say so than have you find out from the template: monitoring an account means deploying instrumentation into it.

On each account Observe creates EventBridge rules on cost-incurring events, CloudWatch alarms, an AWS Config recorder, a topic and queue for compliance findings, an OAM link to your audit account, and the IAM roles those run as. Everything it creates is named RosettaHub*, and every role is created under a permissions boundary the same template provisions.

None of it touches a resource you own. A claim that survives someone reading the template is worth more than a stronger one that does not.

Observe gives you real-time, multi-cloud visibility -- the unified view that most organizations lack. Many enterprises operate across two or more clouds with no unified cost or compliance picture. Observe solves that immediately, and adds the real-time Monitoring Service so cost-vs-budget signals fire continuously rather than after the bill arrives.

Capabilities

Capability Description
Real-time resources Live inventory of every cloud resource across accounts and providers
Real-time cost estimation Event-driven cost tracking across all connected clouds -- not billing-lag estimates
Real-time Monitoring Service Live cost estimate plus continuous cost-vs-budget evaluation. Surfaces overspend continuously, not after the bill arrives
Unified multi-cloud cost dashboard Single view of spend across AWS, Azure, GCP, Alibaba Cloud, OVH, and OpenStack
Cost allocation Account, project, team, and tag-based breakdowns; multi-account rollups
Resource inventory and audit Complete catalog of cloud resources with metadata and ownership
Compliance posture scanning Findings against 10 standards (SOC 2, HIPAA, PCI DSS, GDPR, NIST 800-53/171/CSF, FedRAMP, ISO 27001, CIS) -- read-only findings, no remediation
Idle detection Identifies idle compute, idle databases, orphaned storage volumes and snapshots, unattached IP addresses, idle load balancers
Savings recommendations Commitment and reservation utilisation, right-sizing, Spot conversion candidates
Real-time AI usage tracking Track AI model API consumption across providers
Exportable reports Download cost, inventory, and compliance data for stakeholders

Standalone Value

Observe answers questions that many organizations simply cannot answer today:

  • How much are we spending across all clouds, right now?
  • Are we on track against budget today, or did we already blow past it last week?
  • Which accounts have resources that violate compliance baselines?
  • Who owns the resources driving the most cost?

The data Observe surfaces typically reveals enough waste to build the business case for Automate.

Govern -- Stop it

Access Level: Policy Only

Govern lets RosettaOps write and attach the policies that stop overspend and restrict what your teams can provision. It gives RosettaHub no administrative path to your accounts and no ability to touch a resource that already exists.

Govern is the same deployment as Observe with one parameter changed. What that parameter buys is the difference between reporting a problem and preventing it.

Enforcement lands at your cloud provider's own API, not in our middleware. When a budget is exhausted or a quota reached, the next launch fails because the cloud refuses it -- including from the cloud console, and including for principals that have nothing to do with RosettaHub.

Capabilities

Everything in Observe, plus:

Capability Description
Budget hard stops Real-time budget caps that prevent overspend, not just alert on it
Quota enforcement Creation-time limits on machines, volumes, storage, instance types
Region and service restrictions Control which cloud services and regions users can provision in
Account sandboxing Policy guardrails at the account boundary so blast radius is bounded
AI governance Token usage priced in real time and counted against the account budget, restrictions on which models each role can call, token audit trail
Organizational structure Organizational units, quota increase requests, alternate contacts

What Govern deliberately excludes

Anything that acts on a resource after it exists. That includes compliance remediation: Govern scans continuously and reports findings, but fixing a finding means changing a resource, so it belongs to Automate. Same for autostop, idle cleanup, Spot hibernation, drift correction, account freeze and account recycling. Also federated console access and self-service provisioning, which need identities RosettaHub cannot create from this deployment.

That is not a packaging decision. Those capabilities require an administrative path to the account, and the point of Govern is that there is not one.

Why this edition exists

For the organisation that wants enforcement but will not give a vendor administrative rights over its cloud accounts. Read-only tools cannot stop anything. Full-platform tools need administrative access. Govern is the combination that was hard to express before governance and administration were properly separated: enforcement at your cloud's own API, with no administrative path held by us.

Automate -- Fix it

Access Level: What You Grant

Automate can auto-remediate compliance drift, and modify, stop, and terminate existing resources -- on the accounts where you granted the matching capability, and subject to Protected Account Designation.

Automate closes the loop. Where Govern stops new fires from starting, Automate puts out the ones already burning.

Capabilities

Everything in Govern, plus the following. Which of these a given deployment can actually do depends on the grants you made, so read this alongside Account Access and Scopes.

Preventive enforcement, inherited from Govern

Capability Description
Budget hard stops Real-time budget caps that prevent overspend, not just alert on it
Quota enforcement Creation-time limits on machines, volumes, storage, instance types
Region and service restrictions Control which cloud services and regions users can provision in
Account sandboxing Policy guardrails at the account boundary so blast radius is bounded
AI governance Token usage priced in real time and counted against the account budget, model restrictions, token audit trail

Remediation, which is what Automate adds

Capability Description
Compliance enforcement Auto-remediate findings against the ten standards, rather than only reporting them
Auto-remediation on drift Automatically correct configuration drift after provisioning
Account freeze and unfreeze Suspend all non-essential compute in an account instantly, and restore it later

Permissions and access

Capability Description
RBAC Role-based access control across all platform resources
Role-based service restrictions Control which cloud services and instance types users can provision
Federated multi-cloud console Single sign-on console access across AWS, Azure, GCP. Included at no extra charge, and switched on or off per account
Role and identity management Manage cloud identities, roles, and permissions from one UI
Account provisioning from pools Vend cloud accounts instantly from warm pools with guardrails already applied

Cost actions

Capability Description
Spot instance hibernation Automatically hibernate Spot instances to preserve state and reduce cost (60-90% savings)
Autostop Stop idle compute on trigger or schedule
One-click idle cleanup Apply savings recommendations as a single action
Account cleanup Identify and remove idle resources, orphaned storage volumes, unused snapshots
Compute shutdown on trigger or schedule Stop or terminate instances based on inactivity, time-of-day, or custom triggers

Lifecycle automation

Capability Description
Account Vending Machine (AVM) Pool, assign, sandbox, clean, and return cloud accounts on demand
Scheduled resource lifecycle policies Define policies that automatically age out, resize, or terminate resources on a schedule

Lifecycle automation is optional for brownfield estates

AVM needs the Lifecycle grant, and you do not have to give it. Brownfield buyers commonly adopt Automate purely for remediation on existing accounts -- autostop, idle cleanup, drift correction -- without granting account creation and without restructuring their account estate.

RosettaCloud on the account is a separate thing

The RosettaCloud grant turns on RosettaCloud self-service provisioning inside the account. That is a distinct product rather than an Automate capability, so it is licensed as the full platform. See RosettaCloud.

Critical Safety: Protected Accounts

Protected Account Designation

Any cloud account can be designated as Protected. Protected accounts are exempt from all automated actions at the platform level -- no cleanup, no shutdown, no freeze. This ensures that production workloads and other critical environments are never touched by automation, regardless of any policy or schedule configured in Automate.

Protected Account Designation is the safety mechanism that makes lifecycle automation viable for enterprises. Teams can automate aggressively in development and sandbox accounts while maintaining absolute certainty that production is off limits.

It is a second, independent control from the grants. A resource is only touched if the account carries the matching capability and is not Protected.

Feature Comparison

Which capabilities are available in each edition, and what each one needs granted.

Capability Observe Govern Automate
Administrative path held by RosettaHub none none yes
Real-time resources (live inventory)
Real-time cost estimation
Real-time Monitoring Service
Unified multi-cloud cost dashboard
Cost allocation (account, project, team, tag)
Resource inventory and audit
Compliance posture scanning (findings)
Idle detection
Savings recommendations
Real-time AI usage tracking
Exportable reports
RBAC
Budget hard stops
Quota enforcement (machines, volumes, storage)
Region and service restrictions
Account sandboxing
Compliance enforcement and auto-remediation
AI governance (real-time AI cost against budget, model restrictions)
Organizational units, quota increases, contacts
Auto-remediation on drift
Account freeze / unfreeze
Federated multi-cloud console access
Role and identity management
Spot instance hibernation
Autostop
One-click idle cleanup
Account cleanup (idle / orphaned resources)
Compute shutdown on trigger / schedule
Scheduled resource lifecycle policies
Account Vending Machine
Account provisioning from pools
Protected Account Designation
RosettaCloud self-service in the account full platform

The line to read is the first one. Observe and Govern both leave RosettaHub with no administrative path to your accounts; everything above the Auto-remediation row is reached without one.

How Customers Progress

Each edition earns the next, and each one delivers on its own.

Observe reveals the problem

Most organizations begin with Observe because it requires zero write access -- the lowest possible risk. Within days, the unified cost dashboard, real-time resource inventory, and Monitoring Service surface waste that was previously invisible: idle instances, orphaned volumes, accounts with no budget controls, and compliance gaps.

This data alone often reveals six- or seven-figure annual savings opportunities.

Govern stops it getting worse

Once stakeholders can see the waste, the question becomes how to stop more of it appearing. Govern answers that without changing the risk posture: RosettaHub still holds no administrative path to your accounts, and the enforcement lands at your cloud provider's own API rather than in our middleware.

For many organizations this is the destination rather than a waypoint. Budgets that cannot be exceeded, quotas that hold at creation time, and regions and services that are simply unavailable will stop most of what Observe surfaced.

Automate cleans up what is already there

Prevention does nothing about the idle fleet you already own. Automate is the edition that acts on running resources: autostop, idle cleanup, drift remediation, and account recycling. That requires an administrative path, which is the real step change, and it is why it is a separate edition rather than another parameter.

Within Automate the grants are still chosen per account. A typical sequence:

  1. Destroy on development and sandbox accounts, where cleanup and autostop deliver the fastest savings, and often nowhere else.
  2. Federation where people need console access. It is included at no extra charge and toggles per account.
  3. RosettaCloud where teams want self-service provisioning through Formations.
  4. Lifecycle only if you want RosettaHub creating and recycling accounts for you.
graph LR
    See["<b>See it</b>\n\nObserve reveals waste.\n<i>Touches nothing you run.</i>"]
    Stop["<b>Stop it</b>\n\nGovern prevents more of it.\n<i>Still no admin path.</i>"]
    Fix["<b>Fix it</b>\n\nAutomate cleans up\nwhat is already running.\n<i>Production is protected.</i>"]

    See -->|"Data builds the case"| Stop
    Stop -->|"Prevention is not cleanup"| Fix

    style See fill:#e3f2fd,stroke:#1565c0,color:#000
    style Stop fill:#e8f5e9,stroke:#2e7d32,color:#000
    style Fix fill:#fff3e0,stroke:#e65100,color:#000

There is no requirement to progress. Organizations can remain on Observe or Govern as long as those meet their needs.

Next Steps