RosettaOps™ Landing Zone
The architecture RosettaOps deploys and keeps current
Landing zone
on autopilot
A landing zone is the governed multi-account structure everything else sits on. Normally it is a deployment: you build it, then you maintain it, and every change to your organisation is a change somebody makes by hand.
Ours is derived from your organisation and stays in step with it. Someone joins and their account, permissions and budget follow. Someone moves team and they follow again. On top of that we add the thing no landing zone has ever included: real-time FinOps.
Deployed once, or derived continuously
This is the difference that matters most, and it is not about which accounts exist. It is about what happens on the ordinary Tuesday when someone joins, a project starts, or a team is reorganised.
The usual model
A landing zone is a deployment
Accounts are vended from a template, and what happens inside them afterwards is a separate job. Permissions are configured per cloud. Budgets are watched by a different tool. Reorganisations are a migration.
Change is treated as drift: something to detect and correct back to the configuration you wrote. Which is right for a security baseline, and wrong for an organisation, because organisations change on purpose.
Ours
A landing zone is a projection
Your organisation chart, its roles, its projects and its budgets live in one place. The estate is derived from that and kept in step with it, on every cloud you use.
There is nothing to drift from, because nothing was configured by hand. Change the organisation and the estate converges on it.
What autopilot means in practice
Someone joins
They sign in through your identity provider and are onboarded automatically: their own sandboxed account, an initial budget, and the permissions their role carries. No ticket, no manual provisioning.
Someone changes role or team
What they may launch, where, and against which budget changes with them, and the cloud enforces it. You edit the role, not the policies.
A project starts
It gets its own accounts, its own budget and its own members, and cost rolls up to it from the first day rather than being reconstructed from tags later.
A budget is transferred or exhausted
The account permission policies are rewritten to match. Spend stops when the budget is gone and resumes when it is topped up, without anyone editing a policy document.
Someone leaves
Access is revoked everywhere at once, and the account can be cleaned and returned to the pool for the next person.
A landing zone that needs a project every time the organisation changes is a landing zone that will drift out of date. That is the part we put on autopilot.
And cost was never part of the concept
Ask what a landing zone is made of and the answer is consistent wherever you look: identity, logging and monitoring, governance, security, network design. Cost is not on that list. There is no account for it because it was never one of the foundations being laid.
Which leaves an odd shape. Separating accounts is justified partly on cost grounds, because an account is the only real boundary for billing. The structure built on that justification then delivers no cost capability. Billing consolidates up into the management account, the one everybody is told to lock down and keep workloads out of. And cost allocation gets prescribed somewhere else entirely, as tagging.
So the account boundary is sold as the strongest cost boundary you have, and then the actual work is done with tags, from an account nobody should be working in.
What we deploy
The standard structure, with one addition and one account doing more than usual.
Standard
Log archive
Immutable trails and log storage, isolated from the accounts they record.
Standard, extended
Audit
Security tooling, and the real-time Monitoring Service. Every account reports resource and AI usage here, and this is where budgets are evaluated against live spend.
Only from us
FinOps
Your cost data, in your cloud, in the open FOCUS standard, with the query engine beside it. No copy in ours. No ingestion fees. If you leave, the data and the account stay yours.
Adding an account costs nothing on its own. Clouds charge for what you run, not for how many accounts you run it in, which is the same reason the log archive and audit accounts are separate in the first place.
One command, and it exists
One template on your management account creates the organisation, the three accounts above, and your cost and usage report. Member accounts are then vended as people and projects need them, so there is nothing to deploy per account and nothing to deploy again later.
Bringing accounts you already have is two commands. Most teams are governed the same afternoon.
The runbooks: Onboard Your Organization →
Why that placement makes the numbers live
Most cost platforms read your cloud's billing data. It is accurate and it is late, usually by a day or more, and everything downstream inherits the lag. That is why a report can tell you what a runaway workload cost but never that it is running.
Putting the telemetry inside the estate changes what is possible. Every running resource carries an hourly estimate taken from your cloud's own pricing, totalled per account and reconciled against the bill as it arrives. So there is a live figure for what an account is spending right now, and the budget check runs against that rather than against yesterday.
AI spend is priced the same way, at token level. Every model call in every account is forwarded and priced within a minute, weighted by input and output, and added to that account's live cost. Model usage draws down the same budget as everything else, while it is happening.
This is what enforcement needs. To stop a launch when the budget is gone, you have to know it is gone now.
Already have a landing zone?
Then keep it. We deploy alongside what you have: bring your existing log archive and audit accounts by account number, and the FinOps account is the only new one.
If you run AWS Control Tower
It gives you a catalog of controls to switch on or off, and anything beyond the catalog you write and maintain yourself. Ours are an output of the platform: set a budget or a role, and the account's own permission policies follow. When the budget is exhausted they change, and when budget is transferred in they change back.
If you run Landing Zone Accelerator
It goes far wider than we do across AWS services, and if you need GovCloud or deep network topology as code, it is built for that and we are not an alternative to it. But you operate it: the pipelines, the config files, the version upgrades. And it holds a configuration steady by treating change as drift, which is the right behaviour for a security baseline and the wrong one for a budget.
Neither of them governs cost
Across everything both cover, there is no cost capability and no FinOps account. That is not an oversight. It is the scope of what a landing zone is taken to mean, and it is the part we changed.
And it is the same on every cloud
You describe what a user, a project or an organisation may do. Which regions, which services, which machine types, which models, how much budget. We translate that into whatever each provider enforces natively, so the decision is made once rather than once per cloud.
Your organisation chart and its roles live in one place. AWS, Azure, GCP, Alibaba Cloud, OVH and OpenStack all get the translation.
How much of this you switch on is up to you
All of it is RosettaOps, and there is nothing separate to buy. Start with visibility across accounts you already have, add enforcement when you want spend stopped rather than reported, and add lifecycle automation when you want accounts vended and cleaned up for you.