RosettaOps and 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 | RosettaOps | |
|---|---|---|
| Clouds covered | AWS | AWS, Azure, Google Cloud, and more |
| Landing zone | A reference architecture you configure and operate | Created from one template, including the functional 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 functional 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.