AWS Control Tower¶
AWS Control Tower gives you a well-designed landing zone and a catalogue of controls. What it assumes is a team who can design the structure, operate it, and assemble everything it deliberately leaves out.
What Control Tower does well¶
Worth stating plainly, because a comparison is only useful if it is honest about the thing being compared.
- A sound structure. A multi-account layout following AWS's own reference architecture, with a log archive and an audit account where they belong.
- A real controls catalogue. Preventive and detective controls, maintained by AWS, that apply where they say they do.
- Native. If AWS is the whole of your estate and you have the people to run it, that is a strong position.
Where the remaining work sits¶
A landing zone is a foundation, and a foundation is not the building.
| AWS Control Tower | RosettaHub | |
|---|---|---|
| Clouds covered | AWS | AWS, Azure, Google Cloud, and more |
| Landing zone | A reference architecture you configure and operate | Created from one template, including the log archive, audit and FinOps accounts and billing export |
| Expertise assumed | A team comfortable designing and running one | None in house |
| Budgets | Assembled from separate services, and they report | Checked at creation; an over-budget launch is refused |
| Cost allocation | Not part of it | By person and by project, with shared accounts split by weight |
| Compliance | A catalogue of controls to enable | Ten standards scanned continuously, each finding mapped to the control it breaks |
| Remediation | Build it yourself | Drift correction and automatic remediation |
| Self-service | Account provisioning for administrators | Environments launched by the people who need them, inside the guardrails |
| AI and model spend | Not covered | Model access as a permission, token cost attributed per person |
The four gaps that matter most in practice:
- Cost is a separate project. Budgets, allocation, showback and waste detection are assembled from other services, and the result reports rather than prevents. See Cost Management.
- The people who need environments still cannot get them. Account provisioning serves administrators. It does not give a researcher a cluster or an analyst a notebook, so the ticket queue survives the landing zone.
- One cloud. A second cloud means a second structure, a second permission model and a second cost picture.
- Somebody has to run it. Where that team does not exist, the landing zone tends not to either.
Deploying alongside Control Tower¶
You do not have to choose. RosettaOps deploys next to an existing Control Tower landing zone:
- You bring your existing log archive and audit accounts by account number
- A dedicated FinOps account is the only account added
- The organizational structure you already have is left as it is
See The Landing Zone for exactly what is deployed, and Deploy with Existing Accounts for the procedure.
Starting without a landing zone¶
If you have no landing zone yet, this is the case RosettaOps is built for. Setup is a template applied to your management account, which creates the organization structure, the log archive, audit and FinOps accounts and your billing data export. See Deploy: RosettaHub Creates Accounts.
Permissions and organizational units¶
Your organization chart, its roles and its budgets live in one place, and the equivalent structure is created on each cloud you use rather than maintained separately per provider. Membership can also cross organizations, which a strict account hierarchy cannot express. See Organizations and Account Access and Scopes.
Side by side with 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 | RosettaHub | |
|---|---|---|
| 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, Google Cloud and Alibaba Cloud |
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:#000Not 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 Separate Functional Accounts.
Landing Zone Accelerator¶
The Landing Zone Accelerator is a different kind of tool, and has its own page: AWS Landing Zone Accelerator.
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 | RosettaHub | |
|---|---|---|
| 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.