Skip to content

Onboard Your Organization

From registration form to governed cloud accounts. This is the RosettaOps path.

This is one of two ways to be onboarded

This page is the organization path: RosettaOps, many accounts, many people, and governance over both.

If you are one person bringing a cloud account you already own, you want RosettaCloud instead, and the shorter Sign Up as an Individual path -- one template, a free tier, and no organization to create.

For bringing individual people into an organization that already exists -- self-registration, manager-created users, SSO auto-provisioning -- see User Onboarding.

For the same registration done through the console with screenshots, see the Register Your Organization tutorial.

The Flow

flowchart TD
    Reg["1. Submit the registration form"] --> Email["2. Sign in<br/><i>the console shows your setup keys</i>"]
    Email --> Deploy["3. Run the deployment runbook<br/>for your estate"]
    Deploy --> Done["Cloud accounts registered<br/>and governed"]

    style Reg fill:#e3f2fd,stroke:#1565c0,color:#000
    style Email fill:#fff9c4,stroke:#f9a825,color:#000
    style Deploy fill:#e8f5e9,stroke:#2e7d32,color:#000
    style Done fill:#e8f5e9,stroke:#2e7d32,color:#000

Step 1 -- Register the Organization

Submit the institution registration form:

https://www.rosettahub.com/registration/institution.xhtml

This creates your organization on the platform and the first user account, which becomes the owner of everything that follows.

Step 2 -- Sign In and Collect Your Setup Keys

RosettaHub emails you your console credentials. Everything the deployment needs is shown in the console the first time you sign in, not emailed.

Sign in. Because your organization has no cloud account yet, a setup keys panel opens automatically, with a Copy button beside every field:

What Used for
User Uid A CloudFormation parameter. Identifies the platform user the organization attaches to, and doubles as the sts:ExternalId on the control role's trust policy
Setup Api Key A CloudFormation parameter. Authorises the registration call each template makes back to the platform
Subscription A picker for Observe, Govern or Automate. The command below changes to match
Setup command One aws cloudformation create-stack command, ready to run, with your values and your edition's flags already filled in

The panel gives you the simplest deployment: one command, on the account you are signed in from, with that account taking on every role. Automate additionally creates the FinOps, audit and log-archive accounts for you, because leaving their ids empty is the instruction to create them.

That is enough to be up and running. Two situations need more than one command, and both are covered by the runbooks in Step 3:

  • A landing zone with separate FinOps, audit and log-archive accounts. Each family has a functional template for those, deployed before the management one.
  • Bringing cloud accounts you already have. Those need the member template as a stack set.

The region in the command

It is where the setup stack and its Lambda are created, and it must be one of us-east-1, us-west-2, eu-west-1 or ap-southeast-1, because that is where the function's code bucket exists. It does not limit where you can then run anything.

Save the keys before you close the panel

The panel opens for users who have neither a cloud account nor a key set, so it stops appearing once Step 3 has registered your first account, and it does not come back.

Keep the Setup Api Key somewhere durable: you need it again for every further account you register, whether that is a member stack set or another stack later on. Your User Uid is not at risk, because it stays available on the dashboard.

Keep the setup key safe

It is a platform credential, not an AWS one. It authorises registering cloud accounts against your organization. Templates declare it as NoEcho, so it stays out of CloudFormation console output and stack events, but anyone who can read a deployed stack's Lambda configuration in an account can retrieve it. Treat it accordingly, and rotate it through the console if you suspect exposure.

Step 3 -- Deploy

Two questions decide this. The first picks your runbook, the second picks your template and flags.

Which runbook: who owns the accounts?

  • RosettaHub creates them

    One command. Leave the functional account IDs empty and RosettaHub creates the FinOps, audit and log-archive accounts, then vends member accounts as users need them.

    Automate only -- creating accounts needs the Lifecycle grant.

    Greenfield runbook

  • You bring existing accounts, roles on the payer

    Two commands. One stack on the payer, one StackSet across the accounts you already have.

    Any edition.

    Payer-only runbook

  • You bring existing accounts, separate functional accounts

    Four phases, in order. The control role deploys first so the functional templates can trust it.

    Any edition.

    Functional-accounts runbook

The member StackSet is for accounts you already have

Accounts RosettaHub creates are set up at creation and need no StackSet. You deploy the member template only over accounts you are bringing across. Estates with both do both.

Which template: which edition did you buy?

Edition Template family Flags
Observe RosettaOpsGovernance* EnablePermissions=false
Govern RosettaOpsGovernance* EnablePermissions=true
Automate RosettaOpsAdmin* EnableDestroy, EnableFederation, EnableRosettaCloud, EnableLifecycle. EnablePermissions is not a parameter here -- it is always on

Each runbook repeats this table and shows the commands for one family, so you never have to hold the mapping in your head while deploying.

Prerequisite for both

Member accounts are deployed by StackSet under service-managed permissions, which requires AWS Organizations with all features enabled. Consolidated billing alone will not do. You create no roles for StackSets yourself; CloudFormation provisions what it needs through Organizations trusted access. Ask us if your security review needs the detail of what that puts in your accounts.

What You Are Deploying

Which templates apply depends on the edition you bought. All are published as plain CloudFormation YAML at a public path, need no credentials to fetch, and can be read in full before you deploy anything.

BASE=https://com-rosettahub-public-code.s3.eu-west-1.amazonaws.com/cloudformation/2.0.0
curl -O $BASE/RosettaOpsGovernance.yaml
Edition Family Templates Key parameter
Observe Governance RosettaOpsGovernance* EnablePermissions=false
Govern Governance RosettaOpsGovernance* EnablePermissions=true
Automate Admin RosettaOpsAdmin* EnableDestroy, EnableFederation, EnableRosettaCloud, EnableLifecycle

Observe and Govern are the same file

Moving from Observe to Govern is a parameter change on a stack you have already deployed. Moving to Automate means deploying a different family, deliberately -- because that is where RosettaHub first gains an administrative path to an account. See Account Access and Scopes.

Within a family, which template goes to an account depends on what that account is:

Template Deploy to When
...Management Your management (payer) account Always
(base name) Every ordinary member account Always
...Functional FinOps, audit or log-archive accounts Only if those are separate accounts
RosettaOpsControlRole Your management (payer) account Only alongside the above
RosettaOpsOrgAccessRoleTrust Member accounts Optional, and last

Most organizations deploy the first two.

After Onboarding