Designing your hierarchy (with enterprise examples)
Principles and worked patterns for AWS Organizations, single accounts, multi-cloud groups, MSPs and regulated regions.
Designing your hierarchy (with enterprise examples)
How to decide what your tree should look like, and five worked patterns: one AWS Organization, one AWS account split by tags, many clouds and organisations, many customers, and regulated regions.
Where in CostGlassSettings → Hierarchy
PlanAll plans
Who can do thisAnyone planning the structure; see the Hierarchy guide for who can edit
Time needed15 minutes to read
In short
- Mirror how you are accountable for money, not how the cloud happens to be laid out. Business unit, then team, then environment works for most companies.
- Use the hierarchy for ownership and access: one place per account, and the right people seeing the right accounts.
- Use virtual tags for anything that cuts across accounts or lives inside one account, such as product, cost centre or customer.
- Use saved filters to reuse a slice of spend in views and reports.
- CostGlass does not import your AWS OU layout. You build the nodes and place the accounts yourself (by hand, by rule or by CSV).
Before you begin
- You have read Setting up your organisation hierarchy so the button names make sense.
- You know who in your company is responsible for each group of cloud accounts.
- Your cloud accounts are connected (or you know how many you will connect).
What is the best hierarchy?
There is no single best tree, but there is a good test: for each node, can you name one person or team who is accountable for its spend? If you can, the node is useful. If a node exists only because "that is where the account happens to be", it probably is not.
Principles
- Mirror accountability. Top level: the largest parts of the company (business units, subsidiaries or regions). Next: the teams that own the budgets. Last, if useful: environments such as Production and Non-production.
- Keep it shallow. Three or four levels is plenty. Every extra level is something to maintain.
- One account, one node. An account can sit in only one node, so choose the dimension that has to be exclusive, usually who owns it. Put the dimension that overlaps (product, project, customer) in virtual tags.
- Do not make the cloud the top level. A tree that starts with "AWS", "Azure", "Google" answers "how much do we spend on each cloud?" which Cost Explorer and Cloud Spend already show. Put clouds at the bottom: each team node holds that team's accounts from every cloud.
- Name nodes after things that last. Team names change less often than project names.
- Plan for access. Anyone you bind to a node sees everything under it. Make sure a node never contains accounts one group should not see.
| Shape | Good when | Watch out for |
|---|---|---|
| Business unit → team → environment | You have chargeback or showback by team, and different people own production and development. | Many small nodes if you have hundreds of accounts. Use rules or a CSV rather than clicking. |
| Subsidiary or region → team | Different legal entities or countries pay their own bills. | Teams that work across subsidiaries need accounts in more than one place. |
| By cloud provider | Only a separate team looks after each cloud. | Hides who owns the money, and duplicates what Cloud Spend already shows. |
| By product | A product team owns all its accounts. | Shared accounts (networking, logging) fit nowhere. Give them their own "Shared services" node. |
How hierarchy, virtual tags and saved filters fit together
HierarchyWho owns it and who can see it
A tree of nodes. Each cloud account is in exactly one node. Drives rollup totals and access: a person bound to a node sees only the accounts under it.
Virtual tagsHow to slice spend
Rules that label billed cost, for example "every charge in service X, or tagged team=checkout, belongs to Product = Checkout". They cut across accounts and work inside one account. Used for grouping in Reports, Cost Explorer and budgets. They do not restrict who can see anything.
Saved filtersA reusable selection
A named set of include and exclude conditions (services, regions, accounts, providers) that you apply to saved views and reports, so everyone uses the same definition of, say, "production compute".
A simple rule of thumb: if the answer must be exclusive and decides access, use the hierarchy. If it is a label on spend, use a virtual tag. If it is a repeated way of looking at spend, save it as a filter.
What the hierarchy does not do
The hierarchy is not a grouping option in Cost Explorer or Reports. To see spend grouped by team in those pages, express the team as a virtual tag (for example from account IDs). The hierarchy page itself shows the rollup for each node.
Pattern A: one AWS Organization with OUs
Situation. You have one AWS Organization, with member accounts grouped into AWS Organizational Units (OUs) such as Production, Non-Production and Sandbox, and teams own accounts inside them.
CostGlass does not import OUs
CostGlass reads which accounts exist in your Organization, but it does not read the OU layout. You recreate the structure you want, and you decide whether it copies your OUs or follows teams.
Option 1: mirror the OUs
Best when your OUs already represent who is accountable.
1
Connect the Organization
Use the organisation setup in Connect AWS so the member accounts are found. Wait for the first cost data; accounts appear in the tree page as they are discovered.
2
Create one node per OU
On Settings → Hierarchy click + New Department OU for each OU, using the same names. Add sub-nodes with + Add Sub-OU if you have nested OUs.
3
Export your account list from AWS
In the AWS Organizations console, list each account with its OU. You need the 12-digit account ID and the OU name for each.
4
Build a CSV
Make a file with the columns provider, native_account_id and one column per level. Use
aws as the provider.5
Import it
Click Bulk CSV Import, choose the file and click Upload & Build Tree. Check the result for skipped rows.
6
Keep it current
When you add an account in AWS, it appears at the root in Root Unplaced Accounts. Place it by hand, or re-upload the CSV.
Example CSV (illustrative account IDs)
Option 2: follow teams, not OUs
Best when an OU mixes several teams. Make the top level the teams, then put environments beneath. The CSV is the same shape, with team first and environment second.
If your account display names carry a convention (for example every name contains "prod"), an Auto-Rules rule with Display Name contains prod can place many accounts in one click of Run Rules Now.
A mid-sized company
The root has two nodes: Product Engineering and Data & Analytics. Under each are the teams, and under each team Production and Non-production hold the accounts. The Head of Data is bound to Data & Analytics and sees only those accounts. The finance lead is not bound and sees everything.
Pattern B: one AWS account, workloads separated only by tags
Situation. Everything runs in a single AWS account. Teams or products are told apart only by resource tags such as team or product.
A hierarchy cannot split one account
The hierarchy places whole accounts. One account is one node, so you cannot divide its spend between teams with nodes. Use virtual tags instead.
1
Keep the tree simple
Leave the account at the root, or put it in a single node such as Engineering.
2
Check your tags
Open Tag Explorer and Tag Compliance to see which tag keys exist and how much spend is untagged.
3
Create a virtual tag
In Virtual Tagging create a key such as Team. Add a rule per value that matches your cloud tag (for example the resource tag team equals checkout), and set a default value for everything that does not match.
4
Report on it
Group by the virtual tag in Reports and Cost Explorer, and set budgets per tag value.
Note
Tags are matched using the tags CostGlass has for each resource. Spend that is billed without a resource ID (for example some support or data transfer lines) cannot be matched to a tag and falls into the default value. See the Virtual Tagging guide for coverage.
Tip
If this is how you work today, consider whether separate AWS accounts per team would help later. That is your decision, but separate accounts also let the hierarchy restrict who sees what, which tags alone cannot do.
Pattern C: several AWS Organizations, Azure tenants, Google billing accounts and Oracle tenancies
Situation. A group with subsidiaries, each with its own AWS Organization, Azure tenant, Google Cloud billing account or Oracle tenancy, and you want one view across all of them.
1
Connect each one separately
Connect every AWS Organization, Azure tenant, Google Cloud billing account and Oracle tenancy on its own, from Settings → Cloud Accounts. Use Integrate another in the AWS wizard to add a second AWS Organization. See Connect your clouds.
2
Check the plan limit
Your plan sets a maximum number of connections. If you are refused with an upgrade prompt, you have reached it. See Billing & Plans.
3
Put subsidiaries or regions at the top
Under the root create one node per subsidiary (or region). Beneath each, create the teams.
4
Place accounts from every cloud
In the CSV use one row per account with the right provider value, for example
aws and azure. Several clouds can sit in the same team node.5
Bind leaders
Bind each subsidiary's finance lead to their top node. Group finance is not bound and sees every subsidiary.
Example tree (illustrative)
Note
Cloud Spend, Forecasting and Kubernetes Costs combine spend across the whole organisation and are not narrowed by a person's node. Plan on group-level people seeing those, or see which pages respect scope.
Pattern D: an MSP or reseller with many customers
Situation. You manage cloud costs for several customers and each customer must never see another.
Use one CostGlass organisation per customer
A hierarchy lives inside a single organisation, and the people of that organisation share its data. For strict separation between customers, create a separate CostGlass organisation for each, connect that customer's clouds there, and invite that customer's people to it.
- Each organisation has its own plan, billing, team, API keys and audit log.
- An email address can belong to only one organisation, so one of your engineers needs a separate email address for each customer organisation they work in. There is no screen that shows several organisations at once.
- Within one customer you can still use the hierarchy, virtual tags and saved filters as in the other patterns.
Note
If you want to give a customer a view limited to their own slice of a single organisation, that is what scoped access is for, but it is not a hard boundary for every page (see the list of pages that always show the whole organisation). For customers who must be fully separate, use separate organisations.
Pattern E: regulated regions
Situation. Data about EU users must stay in the EU, UK data in the UK, and so on.
When an organisation is created, the person choosing a region on the sign-up page chooses where all of its data is stored. The region is fixed from then on and cannot be changed. Each region is its own site with its own database, so a hierarchy cannot span regions.
- Create one CostGlass organisation per region, each signed up in that region. Connect only the cloud accounts whose cost data belongs there.
- Use the hierarchy inside each organisation as in the other patterns.
- Group-level reporting across regions is done outside CostGlass today (for example by combining exports from each organisation), because the organisations do not see each other.
- An email address can be registered in only one region. A person who works across regions needs a different address in each.
See Data residency & retention for what is fixed and what you can set.
A short design checklist
- Write down who is accountable for each group of accounts.
- Draw the tree on paper with at most four levels.
- Decide which cuts are exclusive (hierarchy) and which overlap (virtual tags).
- Prepare a CSV, or the rule patterns, to place the accounts.
- Create the nodes, import, and look at Root Unplaced Accounts: it should reach zero.
- Bind people, then sign in as one of them (or ask them) to check what they see.
Frequently asked questions
Should I copy my AWS OUs exactly?
Only if the OUs already match who is accountable. Otherwise design for accountability and map accounts into it.
Can I change the tree later?Yes. Nodes can be renamed and moved, and accounts can be moved between nodes at any time. Nothing is lost when you reorganise.
Does the hierarchy change my bill or cost data?No. It changes how accounts are grouped and who can see them. The spend itself is unchanged.
How is this different from a virtual tag?A virtual tag labels spend and can cut across or inside accounts, but does not limit who sees it. The hierarchy places whole accounts and drives access.