Skip to content

The Landing Zone

A governed multi-account structure that is derived from your organization and stays in step with it, rather than deployed once and maintained by hand. Plus real-time FinOps, which no landing zone architecture includes at all.

Two Things at Once

It is worth separating what RosettaOps does to a landing zone, because they are independent and either one alone would be a smaller claim.

We put the landing zone on autopilot. The usual model is a deployment: accounts vended from a template, permissions configured per cloud, budgets watched by a different tool, and a reorganization handled as a project. Ours is derived from your organization -- its structure, roles, projects and budgets -- and kept in step with it. Someone joins and their account, permissions and budget follow. Someone changes team and they follow again. Nothing was configured by hand, so there is nothing to drift from.

We add real-time FinOps. Cost governance is not part of the landing zone concept anywhere, which is why it normally arrives afterwards as a dashboard over yesterday's bill. A dedicated FinOps account, a live cost estimate per resource, and token-level AI pricing put it in the foundation instead.

The rest of this page covers both, and how the structure compares with what AWS provides.

What a Landing Zone Is

AWS defines it as "a cloud environment that offers a recommended starting point, including default accounts, account structure, network and security layouts". The idea is well established and not ours: separate accounts are the strongest isolation boundary AWS offers, so a well-run estate puts each function in its own account rather than piling everything into one.

The AWS multi-account guidance gives the reasons: security control, blast-radius containment, data isolation, quota allocation, and billing separation. On the last of these it is unambiguous -- an account is the only way to separate items at a billing level, and costs are allocated by account by default.

What a landing zone then delivers is a shorter list, and a consistent one across AWS's guidance: identity management, logging and monitoring, governance, security, and network design. Note what is not in it.

RosettaOps deploys a landing zone on the same pattern, with the same foundations, and adds the one the list leaves out. The functional accounts in the deployment runbooks are exactly this: FinOps, audit, and log archive, each isolated, each with its own role.

On Autopilot

A landing zone is normally a deployment. Accounts are vended from a template, and what happens inside them afterwards is a separate job: permissions configured per cloud, budgets watched by a different tool, reorganizations handled as a project. The configuration you wrote is the reference point, and anything that diverges from it is drift to be corrected.

That is the correct model for a security baseline, which should not move. It is the wrong model for an organization, which moves on purpose.

RosettaOps derives the estate from your organization instead. Structure, roles, projects and budgets live in the portal as the single place they are defined, and the cloud estate is produced from them and kept in step.

What happens when your organization changes

Event What follows, without anyone editing a policy
Someone joins They authenticate through your identity provider and are onboarded: their own sandboxed cloud account, an initial budget transferred, and the permissions their role carries. See User Onboarding
Someone changes role or team What they may launch, in which regions, against which budget changes with them, and the cloud enforces it. You edit the role; the policies are regenerated
A project starts It gets accounts, a budget and members of its own. Cost rolls up to the project from the first day, because the boundary is an account rather than a tag applied afterwards
A budget is transferred or exhausted The account's own permission policies are rewritten to match. Creation stops when the budget is gone and resumes when it is topped up
Someone leaves Access is revoked across every cloud at once, and the account can be cleaned and returned to the pool for reassignment

Convergence rather than drift

Because nothing in the estate was configured by hand, there is no hand-written state to diverge from. Every setup run converges: it compares what the account has against what your organization currently says it should have, and reconciles the difference. Running it twice changes nothing the second time.

This is why the account access model is expressed as scopes and roles rather than as policy documents. The documents are an output. If you change what a role may do, the next run rewrites them; if someone edits one by hand, the next run puts it back.

Autopilot has a second layer

This page is the estate layer: which accounts exist, who reaches them, and under what budget.

Below it, individual resources follow schedules and triggers of their own -- machines stopped overnight, action taken when a budget threshold is crossed. That layer is covered in Landing Zone Autopilot.

They compose. The estate layer decides an account exists with a budget; the resource layer decides what happens to the machines inside it when that budget runs low.

Compared with AWS Control Tower

AWS Control Tower is the AWS-native way to establish a landing zone. It creates a Log Archive account and an Audit account (the whitepaper calls it Security Tooling) in a Security OU, alongside your management account, and vends further accounts through Account Factory.

RosettaOps establishes an equivalent structure, and differs in two ways that matter.

AWS Control Tower RosettaOps
Management / payer account
Log archive account
Audit account
Account vending Account Factory Account Vending Machine
Identity, logging, security, governance
Preventive controls A catalog of controls, enabled or disabled Policies authored by the platform, rewritten as state changes
Custom policy Hand-authored in Organizations, outside drift detection An output of budgets, quotas and restrictions
Account model Per workload and environment, shared by teams Per user and per project as the normal case, workload accounts too
Cost governance as a landing zone capability —
FinOps account —
Clouds AWS only AWS, Azure, GCP, Alibaba Cloud, OVH, OpenStack

Two rows carry most of the difference. A landing zone is not scoped to include cost governance at all, so cost arrives later, from somewhere else, as a reporting layer. And preventive control is a catalog you configure rather than a policy engine that responds to what an account is doing.

graph TD
    Root["Organization root"]

    Root --> Mgmt["Management account<br/><i>payer, no workloads</i>"]
    Root --> SecOU["Security OU"]
    Root --> FinOU["FinOps"]
    Root --> Members["Member accounts<br/><i>per user, per project</i>"]

    SecOU --> Log["Log archive"]
    SecOU --> Audit["Audit<br/><b>Monitoring Service,<br/>OAM sink, org trail,<br/>Bedrock token events</b>"]
    FinOU --> Fin["FinOps account<br/><b>FOCUS cost data,<br/>query engine, dashboards</b>"]

    Members -. "resource + Bedrock events" .-> Audit
    Audit -. "enforce budget" .-> Members
    Audit <-. "reconcile against billing" .-> Fin

    style Mgmt fill:#fff9c4,stroke:#f9a825,color:#000
    style Log fill:#e3f2fd,stroke:#1565c0,color:#000
    style Audit fill:#e3f2fd,stroke:#1565c0,color:#000
    style Fin fill:#e8f5e9,stroke:#2e7d32,color:#000
    style Members fill:#f5f5f5,stroke:#616161,color:#000

Not a replacement for Control Tower where you already run it

If you have a Control Tower landing zone, RosettaOps deploys alongside it rather than against it -- bring your existing log archive and audit accounts by ID, and only the FinOps account is new. See Deploy: With Separate Functional Accounts.

The FinOps Account

The missing account is a symptom. The cause is that cost is not a landing zone capability at all.

Ask what a landing zone is made of and the answer is consistent across AWS's guidance: identity management, logging and monitoring, governance, security, and network design. Cost governance is not on that list. It is not a foundation the landing zone lays, which is why there is no account for it -- there is nothing to put in one.

That leaves an odd shape, and it is AWS's own reasoning that makes it odd:

  1. Cost is a headline justification for the multi-account structure. An account is the only way to separate items at a billing level; costs allocate by account by default; separate accounts are how you map spend to projects.
  2. The landing zone built on that justification delivers no cost capability. It gives you isolation, logging, controls and identity.
  3. Billing consolidates upward into the management account -- which AWS says should hold no business workloads, should have restricted access, and which service control policies cannot constrain at all.
  4. Cost allocation is then prescribed elsewhere, as tagging. The Cloud Adoption Framework's guidance is cost allocation tags and Cost Categories -- a reporting layer applied on top of the account structure that was justified on cost grounds in the first place.

So the account boundary is presented as the strongest cost boundary available, and then the actual cost work is done with tags, from an account nobody should be working in. The data, the engine that queries it, and anything that acts on either have nowhere sanctioned to live.

The usual escape is to send it all to a vendor, where it becomes someone else's asset in someone else's cloud.

RosettaOps gives it a home. A dedicated FinOps account, in your organization, holding:

What lives there Why it matters
FOCUS 1.3 cost data Standard-format cost data in your account, queryable with SQL, not a vendor's proprietary schema
The query engine Athena or the equivalent on your cloud. You pay your cloud's query cost and nothing else -- no ingestion fees, no per-gigabyte charges
The billing pipeline Cost and usage reports land here and are reconciled against live estimates
Cost dashboards Served from your own data

Three consequences follow:

  • Your cost data never leaves your cloud. There is no copy in ours. If you stop being a customer, the data and the account stay yours.
  • The management account stays clean. Cost tooling has somewhere to run that is not the account AWS tells you to lock down.
  • Access can be delegated normally. A FinOps team can be given access to a FinOps account. Giving them the management account instead is what AWS guidance exists to prevent.

The extra account costs nothing

AWS charges on resource usage, not on the number of accounts. A dedicated functional account carries no inherent cost penalty -- which is the same argument AWS makes for the log archive and audit accounts.

Compared with Landing Zone Accelerator

Landing Zone Accelerator on AWS is the other thing people mean by "we already have a landing zone". It is a different kind of tool from Control Tower and worth separating.

LZA is an open-source CDK solution you deploy into your own accounts and then operate. Configuration lives in YAML files in an S3 bucket, an installer pipeline and a core pipeline synthesize and deploy from them, and the result covers 35 or more AWS services: networking including Transit Gateway and Network Firewall, security services, Config rules, Security Hub. AWS recommends running it on top of Control Tower rather than instead of it, and it expects Control Tower's three mandatory accounts to exist.

It is genuinely strong at things we do not attempt. If you need GovCloud or the US Secret and Top Secret regions, deep network topology as code, or conformance packs mapped to a specific regulatory framework, LZA is built for exactly that and we are not an alternative to it.

Three differences matter if you are weighing the two.

You operate LZA. We operate RosettaOps. The pipelines run in your accounts, so config correctness, failed pipeline runs, version upgrades and CDK bootstrap collisions are yours. AWS is precise that there are no additional charges for the solution, which is true and excludes the pipeline infrastructure and the staff time. That is a reasonable trade for the control it gives you, and it is a real line in a budget.

LZA treats change as drift. We treat change as the mechanism. LZA deploys a known-good state from your configuration and watches for divergence from it, which is the correct behaviour for a security and network baseline. It gives you no way to express a policy that should change when an account exhausts its budget, because from its point of view that would be drift. Governance that reacts to what an account is doing is a different job from governance that holds a configuration steady, and both are worth having.

Cost governance is absent there too. Across 35-plus services and a solution built for the most heavily regulated estates on AWS, there is no cost capability and no FinOps account. That is not an oversight by AWS; it is the scope of what a landing zone is understood to cover, which is the point made above.

Control Tower Landing Zone Accelerator RosettaOps
Operated by AWS You RosettaHub
Configured through Console and API YAML config and a CDK pipeline Budgets, roles and quotas
Breadth on AWS Foundational Very broad, 35+ services Governance and cost
GovCloud, secret regions — —
Reacts to account state — —
Cost governance — —
Clouds AWS AWS AWS, Azure, GCP, Alibaba Cloud, OVH, OpenStack

These stack rather than compete

The common shape is Control Tower as the foundation, LZA for network and security depth where the regulatory requirement demands it, and RosettaOps for cost governance, per-user account vending and the clouds beyond AWS. Bring your existing log archive and audit accounts by ID and the FinOps account is the only one we add.

The Audit Account Does More Here

Control Tower's Audit account is a security account: a read-only vantage point for security tooling across the organization.

RosettaOps keeps that job and adds another. The audit account is where the real-time Monitoring Service runs, and it is the telemetry hub for the whole estate: the central monitoring Lambda, the observability sink that member accounts link into, the organization CloudTrail, and the event queue that Bedrock usage flows into.

That placement is what makes the platform's cost signals live rather than retrospective.

Cost, before the bill

Most cost platforms read the cloud's billing data. That data is good, and it is late -- a day or more behind, sometimes several. Everything downstream inherits the lag, which is why a report can tell you what a runaway workload cost but never that it was running.

RosettaOps works from two sources at once:

Source What it gives Latency
Resource events Something was created, changed, stopped Immediate on the event rule; CloudTrail within minutes
The cloud's own pricing data What that resource costs per hour Immediate
Billing reports What it actually cost The cloud's own lag

An hourly cost estimate is computed for every running resource from the cloud's pricing, totalled per account, and continuously reconciled against billing reports as they arrive. So there is a live number for an account's spend at any moment, and a budget check that runs against it continuously rather than after a report lands.

That is what enforcement needs. Blocking a launch when a budget is exhausted requires knowing the budget is exhausted now. A platform whose only input is yesterday's bill can raise an alert; it cannot make the decision in time to matter.

AI spend, at token level

Bedrock usage is tracked the same way, and separately, because it behaves differently from compute: no long-running resource to observe, just calls that cost money.

Every sub-account forwards Bedrock invocation events -- InvokeModel, Converse, RetrieveAndGenerate -- to the audit account, where they are queued and consumed by the monitoring Lambda. Usage is priced in weighted units, output weighted more heavily than input, and added to the account's live cost. Latency is well under a minute.

Model spend is then governed by the account budget, the same ceiling as compute and storage, rather than by a separate mechanism. That is the point of pricing it in real time: an AI workload draws down the same budget as everything else, while it is running.

A platform reading the bill finds out afterwards -- and until recently, AWS's billing data did not break Bedrock down per principal at all.

Token quotas are not enforced today

Usage is measured and priced continuously, and the account budget is what stops spend. A distinct token-level quota, capping model calls independently of cost, is not something RosettaOps enforces yet.

This is what the FinOps and audit accounts are for

The account structure is not bookkeeping. Cost data needs a home that is not the management account, and the telemetry that makes it real-time needs somewhere to run with a view across every member account. That is the FinOps account and the audit account respectively, and it is why the landing zone is where this capability belongs rather than something added afterwards.

Governance: A Catalog, or a Policy Engine

Control Tower's preventive controls are service control policies. The difference is not the mechanism, it is who writes them and when.

Control Tower gives you a catalog: controls are mandatory, strongly recommended, or elective, and you enable or disable the elective ones. The SCPs behind them are named aws-guardrails-* and AWS is explicit that you must not edit them -- doing so "could result in the controls entering an unknown state, requiring you to reset your landing zone or re-register your OU". Anything the catalog does not cover, you author yourself in AWS Organizations and attach to OUs, or package through Customizations for AWS Control Tower as manifest files in an S3-triggered pipeline. Those custom policies fall outside Control Tower's drift detection, which audits only its own managed SCPs, so your own change control governs them.

All of it is static. A control is on or off; a custom SCP says what it said when you wrote it.

RosettaOps writes the policies, and rewrites them. Service control policies are an output of the platform, not a configuration item you maintain:

Control Tower RosettaOps
Preventive mechanism SCPs SCPs
Who authors them AWS for the catalog; you for anything else RosettaOps
Changing them Enable or disable a control; hand-author custom SCPs Set a budget, quota or restriction; the policy follows
Reacting to account state — Budget exhausted, quota reached, account frozen -- the policy changes, then changes back
Drift on custom policy Your own change control Converged on every setup run

That last row is what "closed-loop" means in practice. When a budget is exhausted, RosettaOps rewrites the account's own permission policies so the next launch fails at the cloud's API, and restores them when budget is transferred in. There is no equivalent in a catalog model, because a catalog has nothing to react to.

Account Model: Workloads, or People and Projects

AWS's recommended structure is workload-oriented. The foundational and application OUs are Security, Infrastructure, Workloads and Sandbox: accounts per environment and per workload, shared by the teams that work on them, with access managed through roles.

AWS does contemplate accounts per person -- the Individual Business Users OU groups "AWS accounts associated with individual employees or business units" -- but it sits among the Advanced OUs, as a specific use case rather than a foundation, and no vending machinery is aimed at it.

RosettaOps is built for that shape as the normal case. The Account Vending Machine assigns a sandboxed account per user or per project, with its own budget and quotas, and recycles it on return. Both models coexist: bring your workload accounts and govern them, vend per-user accounts alongside them, or do both in one estate.

This is the architectural form of allocating cost by account rather than by tag. If each user or project has an account, cost rolls up by user and project without any tagging discipline at all.

Identity

AWS does not require IAM Identity Center, and it does federate to your IdP

It is worth being accurate here, because the opposite is often assumed. Control Tower offers self-managed account access as a setup option, and IAM Identity Center itself federates to Okta, Microsoft Entra ID, Ping, Google Workspace, JumpCloud, OneLogin, Active Directory, or any SAML 2.0 source. Your corporate identity provider works either way.

The real difference is what you give up to use it. If you choose self-managed access in Control Tower, "AWS Control Tower no longer creates IAM roles and groupings for customer-specific use -- neither during landing zone setup nor during account provisioning with Account Factory". The account-provisioning automation and your own identity plumbing pull against each other: take the automation and take Identity Center with it, or bring your own and wire up access yourself.

RosettaOps does not make you choose. It connects to your organization's identity provider through SSO and still vends accounts, applies permissions, and issues federated console sessions into them. Identity is not in the path of the automation.

Why Other Platforms Do Not Do This

Cost platforms generally ingest your billing data into their own data lake and serve dashboards from there. That is a reasonable architecture for a reporting product, and it is why those products can be cheap to run: their cost-to-serve is API calls.

It has three consequences a governed estate feels:

  1. The data is theirs, in their cloud. Residency, retention and portability follow their terms.
  2. Ingestion is metered. Per-gigabyte or per-resource pricing scales with the estate you are trying to make cheaper.
  3. Nothing there can act. A data lake outside your account can produce a recommendation. It cannot stop a launch.

The last is the structural one, and it is why the FinOps account exists rather than a pipeline into ours. Enforcement has to happen where the resources are.

Next