RosettaHub™ for MSPs
More customers, same team
Your margin is hours.
This is where they go.
Managed service providers rarely lose money on cloud. They lose it in the gap between a customer signing and a customer being governed, work that is nearly identical for every customer, done by hand for most of them, and billed to nobody.
The same five jobs,
on every customer you take on
Every customer needs all of it and it has to be right every time. Done by hand it scales with the customer count rather than with the value of the work, which is why the tenth customer costs about what the first one did.
Onboarding a new customer
The landing zone, the accounts, the roles, the budgets, the billing export. Near enough identical every time, and rebuilt by hand for most of them.
Answering “what did this cost us”
A monthly reconciliation across accounts and tag schemes that do not agree, finishing about two days after it stopped being useful.
Standing up guardrails, per customer
Permissions, service and region limits, spending caps. Written once per customer because there was nowhere to write them once.
Chasing what nobody switched off
Idle machines, orphaned volumes and forgotten environments, found by someone reading a report and then chased by someone else.
Getting ready for an assessment
Evidence gathered by hand at the point somebody asks for it, for controls that were supposed to be continuous.
The part native hierarchies cannot do
One engineer,
many unrelated customers
A cloud provider’s account hierarchy assumes one organisation with one tree. An MSP is the opposite shape: many customers who have nothing to do with each other, each with their own budgets, policies and compliance baseline, and engineers who work across all of them.
Here a user can belong to several unrelated organisations at once, each with its own roles and limits. One login, every customer, and no customer able to see another.
No login per customer
Federated, time-limited sessions into each customer’s console, under the role you hold there. Nothing long-lived to store, rotate or lose.
Share without an IAM ticket
Templates, images, policy sets and storage shared across accounts and clouds. The platform issues the credentials and revokes them when the share ends.
Build your catalogue once
A curated portfolio of environments becomes a private service catalogue you publish to every customer you manage, rather than rebuilding per engagement.
A new customer is governed
from the first day
Setting a customer up is one deployment into their management account, which creates the organisation, the functional accounts and the billing export. Accounts they already run are brought in the same way. After that the guardrails stop being something you apply.
New accounts come off a vending machine with the landing zone, roles, budgets, quotas and federated console access already attached, so day one for a new customer looks like day three hundred for an established one, and there is no drift window in between.
Cost per customer,
without tagging discipline
Attribution follows the account rather than a tag somebody has to maintain, and it is fixed when the cost is incurred, so a customer moving between your cost centres does not rewrite last quarter, and every run reconciles back to the bill.
The budget blocks the account
Cost is evaluated in real time from resource monitoring. The moment an account reaches its budget it is blocked, and the workloads that would have run the bill up stop there.
Headroom is a transfer
Budgets come down from a root budget the way funds move between accounts, so giving a customer more room is a transfer rather than a policy change, and it can be delegated.
Waste switches itself off
Twenty eight kinds of idle and orphaned resource found continuously, reported first and stopped when you say so, rather than chased by an engineer reading a report.
Compliance that is already
running when they ask
We record your customers’ cloud accounts and their configuration continuously against ten standards, including SOC 2, HIPAA, ISO 27001, PCI DSS, NIST 800-53 and GDPR, with every finding mapped to the control it breaks. Drift triggers remediation when it appears rather than when somebody asks for evidence.
Every account you provision carries the full policy set from its first minute, which is the difference between an assessment that reads a report and one that starts with a month of preparation.
Your customer’s security review,
answered in advance
The answers you can give before the questionnaire arrives.
No administrative access to start
The first level still covers cost, allocation, idle detection and compliance scanning.
Their data stays theirs
It deploys into their accounts, and their cost and usage data is queried where it already lives.
Nothing installed
No agent on a host and nothing in the network path.
Granted per account
Enforcement and remediation are separate levels, and removing the stack takes back whatever was granted.
Sessions, not stored keys
Short-lived federated sessions, so no static credential sits in your estate or theirs.
External IDs on cross-account access
The control on the AWS MSP checklist your auditor evaluates about your vendors rather than about you.
One practice covers
every cloud they arrive on
Customers arrive on the cloud they arrived on. The same budgets, quotas, roles and compliance policies apply on AWS, Azure and Google Cloud, with OVH and OpenStack also supported, and the same operations work on each.
One team, one set of skills, one way of doing things, rather than a separate capability you have to staff before you can say yes to the customer in front of you.
Common questions
How is this different from the cloud management tool we already resell?
Most of them report and hand the work back to your engineers, which is the part that costs you money. Here the guardrails arrive with the account, cost is evaluated in real time from resource monitoring so an account is blocked the moment it reaches its budget, and compliance runs continuously rather than being assembled before an assessment. It also covers Azure and Google Cloud on the same policy model, so a customer arriving on a second cloud is not a second practice.
Can we manage many unrelated customers without separate installs?
Yes, and this is the part native cloud hierarchies cannot express. A user can belong to several unrelated organisations at once, each with its own budgets, roles and compliance baseline, so one engineer can work across many customers without a login per customer and without any customer seeing another. Sharing is delegated by the platform, which issues the credentials and revokes them when the share ends.
What will our customers say in their security review?
Usually less than you expect. The first level is read-only and grants no administrative access at all, while still covering cost, allocation, idle detection and compliance scanning. It deploys into the customer’s own accounts, their data stays there, there is no agent on a host and no proxy in the network. Enforcement and remediation are separate levels, granted per account, and removing the stack withdraws whatever was granted.
How long does onboarding a new customer take?
One command on the customer’s management account creates the organisation, the functional accounts and the billing data export. Accounts you already manage are brought in with one more. After that, new accounts come off a vending machine with the landing zone, roles, budgets, quotas and federated console access already attached, so the work does not repeat per account.
Does it help with the AWS MSP Program validation checklist?
Yes, for the controls a platform can evidence. Identity and access management, a governed multi-account landing zone with standardised baselines applied at account creation, continuous posture management against ten standards, and infrastructure as code. Ask us for the control-by-control mapping.