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 handed out from a standard setup, 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’s 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 left out of the concept
Ask what a landing zone is made of and you get the same list everywhere: identity, logging, governance, security, network design. Cost is not on it.
Which is an odd shape. Accounts are separated partly on cost grounds, because an account is the only real billing boundary. The structure built on that reasoning then ships no cost capability, and 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 step, and it exists
Everything above is created for you in one step: the account structure, the three accounts and your billing data export. See what this looks like on AWS. After that, accounts appear as people and projects need them, so there is nothing to set up per account.
Bringing accounts you already have takes one more step. Most teams are governed the same afternoon.
Which is the part worth pausing on. This is the work that is otherwise scoped, staffed and billed by the week, and the reason it takes an afternoon is that the decisions are already made and the steps already written.
The runbooks: Onboard Your Organization →
Built for teams without
a platform function
A governed landing zone is normally a project, and it assumes people in-house who know the cloud deeply enough to design it and keep it running. Plenty of organisations need the structure and do not have that team. Ours is derived from your organisation, so there is far less to design and nothing to maintain by hand.
If you run AWS Control Tower
A strong foundation, and we work alongside it. Bring your existing log archive and audit accounts by account number, and the FinOps account is the only new one.
If you run Landing Zone Accelerator
It reaches deeper into AWS itself: transit gateways and centralised egress across accounts, organisation-wide enablement of services like GuardDuty and Security Hub, and configuration mapped to frameworks such as NIST 800-53. If you need those, or GovCloud, that is what it is built for. It also expects a team to operate it.
Neither of them governs cost
Across everything both cover, there is no cost capability and no FinOps account. That is the scope of what a landing zone is taken to mean, and it is the part we changed.
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. That is why a report tells you what a runaway workload cost, never that it is running.
Putting the telemetry inside the estate changes that. Every running resource carries an hourly estimate from your cloud’s own pricing, totalled per account and reconciled against the bill as it arrives. The budget check runs against that live figure, not yesterday.
AI spend is priced the same way, at token level. Every model call is priced within five minutes and added to that account’s live cost, drawing down the same budget as everything else.
This is what enforcement needs. To stop a launch when the budget is gone, you have to know it is gone now.
Accounts, not tags
The account is the allocation unit
This is the other reason the structure matters. Most platforms allocate cost with tags alone, and a tag is a reporting layer. It cannot block a launch. An account can.
Scripted launches ship untagged
Auto-scaling, SDKs and CI pipelines drop tags routinely.
Tags do not backfill
A tag applied on day 30 leaves 29 days unattributed, permanently.
Shared services cannot be tagged
Networking, data transfer and support put a ceiling on how accurate tagging gets.
Account Vending Machine™
Accounts in seconds, and back again
Pre-provisioned accounts wait in a managed pool. On demand, RosettaOps takes one, applies the sandbox and hands it over. When the work is done it is cleaned and returned. No manual vending, no zombie accounts, no residual access.
Every assignment is timestamped, so cost rolls up by user and by project over any window you ask for, even when accounts change hands.
Your existing tags keep working. Accounts are where enforcement lives; reporting is a separate question, and tag-based dashboards run from day one.
And it is the same on every cloud
You describe what a user, a project or an organisation may do. Which regions, services, machine types and models, and how much budget. Each cloud is then told in its own language, so you decide once rather than once per cloud.
Your organisation chart and its roles live in one place. AWS, Azure, Google 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.
Common questions
Do I need cloud expertise to set up a landing zone?
No. The structure is derived from your organisation rather than designed by hand, so there is no landing zone project and no platform team required. One step on your management account creates the organisation, the functional accounts and your billing data export.
Can RosettaOps work alongside AWS Control Tower?
Yes. It deploys alongside an existing Control Tower landing zone. You bring your log archive and audit accounts by account number, and the dedicated FinOps account is the only one added.
Does a landing zone include cost governance?
Not normally. A landing zone is defined as identity, logging, governance, security and network design, so there is no cost account in the standard structure and budgets usually arrive afterwards as a separate dashboard. Ours puts a dedicated FinOps account in the structure itself.
How is this different from Landing Zone Accelerator?
Landing Zone Accelerator goes wider across AWS services and is built for cases like GovCloud and deep network topology as code, and it expects a team to operate it. Ours suits teams who need the structure without that operating burden, and it adds cost governance.