RosettaHub™ and AWS Control Tower
Landing zones without the landing zone team
A good answer,
if you can staff it.
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 around it that it deliberately leaves out. Plenty of organisations do not have that team and still need the result.
What Control Tower is good at
Worth stating plainly, because the comparison is only useful if it is honest about the thing being compared.
A sound structure
A multi-account layout that follows AWS’s own reference architecture, with a log archive and an audit account where they should be.
A real controls catalogue
Preventive and detective controls that are maintained by the provider and that genuinely apply where they say they do.
Native, and staying that way
It is part of the platform. If AWS is the whole of your estate and you have the people to run it, that is a strong position.
Where the work
is still yours to do
A landing zone is the foundation, and a foundation is not the building. What follows is the part organisations underestimate, and it is where most of the effort actually goes.
Cost is a separate project
Budgets, allocation, showback and waste detection are assembled from other services, and the result reports rather than prevents.
The people who need environments still cannot get them
Account provisioning is for 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, however it arrives, means a second structure, a second permission model and a second cost picture to reconcile.
And somebody has to run it
The assumption underneath all of it. Where that team does not exist, the landing zone tends not to either.
Side by side
| 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 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, and 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 |
If you already run Control Tower,
keep it
It deploys alongside an existing Control Tower landing zone: you bring your log archive and audit accounts by account number, and a dedicated FinOps account is the only one added. The structure you already have stays as it is.
What you gain is the layer above it. Cost enforced when a resource is created rather than reported afterwards, allocation by person and project, continuous compliance, and self-service for the people the landing zone was built to serve in the first place.
See exactly what gets deployed →Common questions
Is this a replacement for AWS Control Tower?
It can be, and it does not have to be. If you have no landing zone yet, this gives you one without needing the in-house expertise to design and run it. If you already have Control Tower, this deploys alongside it: you bring your log archive and audit accounts by account number, and a dedicated FinOps account is the only one added.
What does Control Tower not cover?
It is a landing zone and a controls catalogue, and it does that job on AWS. Cost is a separate set of services you assemble yourself, allocation by person and project is not part of it, there is no self-service layer for the people who actually need environments, and it does not extend to your other clouds.
We do not have a cloud platform team. Is a landing zone realistic for us?
That is the case this is built for. Setup is a template applied to your management account, which creates the organisation structure, the functional accounts and your billing data export. The result is a governed multi-account estate without anyone on staff having had to design one.
How are permissions and organisational units handled differently?
Your organisation chart, its roles and its budgets live in one place, and the equivalent structure is created on each cloud you use rather than being maintained separately per provider. Membership can also cross organisations, which a strict account hierarchy cannot express.