Outcome
By the end of this lesson, you will be able to map each cloud’s organizational primitives (AWS Organizations, GCP Folders/Projects, Azure Management Groups/Subscriptions), explain how the hierarchy enables inheritance, and predict how ZopNight integrates at each level.
| Prerequisites | M4.4.L1: Why multi-account |
| Time | 10 minutes |
1. Concept
Each cloud gives you a way to arrange accounts into a tree, and each calls it something different.
The idea underneath is identical. Rules set high up apply to everything below, unless something lower overrides them. Learn the shape once and the three vocabularies are a lookup table.
PROVIDER ORGANIZATIONAL PRIMITIVE HIERARCHY──────────────────────────────────────────────────────────────────AWS AWS Organizations Root → OU → AccountGCP Folder + Project Org → Folder → ProjectAzure Management Group + Subscription Tenant → MG → SubUnderstanding each cloud’s hierarchy is foundational for planning a ZopNight rollout, even though ZopNight connects at the leaf: one AWS account, one GCP project or one Azure subscription at a time. The one exception is an Azure tenant connection, which discovers its subscriptions for you.
AWS Organizations
ROOT (top-level) ├── OU "Production" │ ├── prod-account-1 │ ├── prod-account-2 │ └── prod-shared └── OU "Non-production" ├── dev-account ├── staging-account └── sandbox-accountConcepts:
- AWS Organizations: the top-level container that owns multiple AWS accounts.
- OU (Organizational Unit): a folder-like grouping of accounts. Service Control Policies (SCPs) at the OU level apply to all accounts in the OU.
- Account: the actual cloud account; holds resources.
- Management account: the account that created the Organization; billing aggregation lives here, and cross-account roles are typically issued from here.
ZopNight integration: Connect each AWS account on its own; there is no Organizations-level connector. The recommended method is a role created in that account by a CloudFormation quick-create stack, trusting ZopNight’s Google identity (keyless, assumed with sts:AssumeRoleWithWebIdentity). Static keys and temporary credentials are also accepted. Each account becomes one ZopNight cloud account.
GCP Folders + Projects
ORGANIZATION (example.com) ├── FOLDER "Production" │ ├── prod-platform (project) │ ├── prod-product (project) │ └── prod-shared (project) └── FOLDER "Non-production" ├── dev-platform (project) ├── staging-product (project) └── sandbox (project)Concepts:
- Organization: the top-level GCP entity tied to a domain.
- Folder: a grouping of projects (and sub-folders); supports policies that inherit.
- Project: the unit of resources, billing, and IAM. Every resource lives in a project.
ZopNight integration: Connect each project on its own; ZopNight does not discover projects from the organization. The recommended method is One-Click Connect: you sign in with Google and ZopNight creates and manages a service account in the project. A customer-managed service-account JSON key is the alternative.
Azure Management Groups
TENANT (example.com) ├── MG "Production" │ ├── prod-eu (subscription) │ └── prod-us (subscription) └── MG "Non-production" ├── dev (subscription) └── staging (subscription)Concepts:
- Tenant: the top-level Azure AD identity boundary for an organization.
- Management Group (MG): a grouping of subscriptions; supports policies that inherit.
- Subscription: the billing and resource container: equivalent to an AWS account or GCP project.
ZopNight integration: Connect a single subscription, or the tenant. A tenant connection discovers every subscription the credential can reach and creates a child cloud account for each. Authenticate with a service principal (recommended) or workload identity federation.
The hierarchy enables three things
The reason each cloud built these primitives is to enable three properties:
1. INHERITANCE Policies, tags, and budgets defined at higher levels apply to all descendants. "Production OU has SCP forbidding region X": every account in the OU inherits the restriction.
2. BILLING ROLLUP Cost can be aggregated at any level. Org-wide totals, per-OU subtotals, per-account details: all derived from the same underlying billing records.
3. ACCESS CONTROL Permissions at higher levels grant on all lower levels. An IAM role at the Organization level can act on any descendant account; team-specific access is granted at the OU/Folder/MG level.These three properties are why the hierarchy matters more than just “a way to group accounts.”
How ZopNight respects the hierarchy
ZopNight follows the leaves of the tree, not the tree itself:
DISCOVERY Runs per connected cloud account. The only parent and child it knows is an Azure tenant and its subscriptions.
COST ROLLUP Aggregates by provider, account, region, service, resource type, team and resource. There is no OU, folder or management-group level.
TAG VISIBILITY Tags applied at higher levels (via cloud-side policy) inherit downward and are visible in ZopNight with their inherited provenance.
TEAM MAPPING Teams are scoped to the resources and resource groups assigned to them, not to an OU or folder. To mirror a folder, assign its projects' resources (or a group holding them) to the team.The result: the cloud-side hierarchy still matters for your policies and billing, but ZopNight will not reproduce it. Keep a record of which accounts sit where, and connect new accounts as they are created.
Multi-cloud orgs
Many customers operate across multiple clouds. The patterns combine:
AWS Organization → ZopNight cloud-accounts (one per AWS account)GCP Organization → ZopNight cloud-accounts (one per project)Azure Tenant → ZopNight cloud-accounts (one per subscription)
ZopNight org sees the union, organized by provider.A mid-size customer might have an 8-account AWS Organization, a 12-project GCP Organization, and a 6-subscription Azure tenant; 26 cloud-accounts total in ZopNight, all under one ZopNight org.
Cost-allocation tags vs hierarchy
A common question: “should I use tags or hierarchy for cost allocation?” The answer is both, at different granularities.
HIERARCHY level Coarse: per-team, per-environment, per-regionTAG level Fine: per-application, per-feature, per-cost-center
Use hierarchy for boundaries that are infrequent and structural.Use tags for attributes that change frequently and apply withinan account.A platform team’s prod account has one place in the hierarchy. Within it, tags identify which application owns each resource. The two layers compose.
How ZopNight uses it
ZopNight does not draw your OU, folder or management-group tree. Cost Reports → Summary breaks spend down by provider, then by account inside each provider, and you can expand an account to see its split by resource type. Clicking an account row opens the Resources list filtered to that account.
COST REPORTS → SUMMARY, PROVIDER CARD EXAMPLE: AWS $1.38M/mo prod-platform-account $640K/mo prod-product-account $360K/mo prod-shared $200K/mo dev-account $80K/mo staging-account $60K/mo sandbox-account $40K/moTo get an OU-level number, keep the account-to-OU map yourself and add up the accounts, or put each OU’s resources in a resource group if you need that rollup inside ZopNight.
2. Demo
A multi-cloud enterprise wiring up to ZopNight:
ENTERPRISE: 8 AWS accounts under one AWS Organization 12 GCP projects under one Org with 3 folders 6 Azure subscriptions under one tenant with 2 MGs
ZOPNIGHT SETUP:
AWS: Step 1: In ZopNight, add an AWS account and launch the CloudFormation quick-create stack it offers Step 2: The stack creates a role trusting ZopNight's Google identity; paste the role ARN back into ZopNight Step 3: Repeat for each of the 8 accounts (one stack each) RESULT: 8 ZopNight cloud-accounts, one per AWS account
GCP: Step 1: In ZopNight, add a GCP project with One-Click Connect Step 2: Sign in with Google; ZopNight creates its service account in the project and binds the roles Step 3: Repeat for each of the 12 projects RESULT: 12 ZopNight cloud-accounts, one per GCP project
Azure: Step 1: Register an Azure AD application (service principal) Step 2: Grant Reader role at the tenant level Step 3: Connect ZopNight at tenant scope with tenant_id + app_id + secret Step 4: ZopNight discovers all 6 subscriptions and creates a child cloud account for each RESULT: 6 ZopNight cloud-accounts, one per subscription
GRAND TOTAL: 26 cloud-accounts under one ZopNight organizationCOST ROLLUP: org-wide view across all three providers, plus per-provider and per-account breakdownsA unified view across three clouds and 26 accounts. The AWS and GCP connections were repeated per account; only Azure fanned out on its own.
3. Hands-on (6 min)
Map your own cloud presence:
PROVIDER 1: __________ (e.g., AWS) Top-level entity: __________ (Organization name) Hierarchy structure: __________________________________________________________
Account count: _____ Connected to ZopNight: Yes / No Connection method: __________ (assume-role / direct / other)
PROVIDER 2: __________ (e.g., GCP) Top-level entity: __________ Hierarchy structure: __________________________________________________________ Project count: _____ Connected to ZopNight: Yes / No Connection method: __________
PROVIDER 3 (if any): __________ Hierarchy: __________ Resource count: _____ Connected: Yes / No
TOTAL ZopNight cloud-accounts: _____ Matches actual cloud-side account count? Yes / No If no: what's missing? __________________________________________________________If your ZopNight cloud-account count is lower than your actual cloud-side count, some accounts are not connected: investigate.
Do it through MCP. The same task you just did in the console, asked in one sentence.
BEFORE A ZopNight account with one cloud connected. Two or more cloud accounts connected.ASK "List our connected cloud accounts and tell me which ones have not finished discovery."CHECK the list against your cloud-side account count. Anything missing was never connected.Tools behind it: list_cloud_accounts (read, Explore), get_discovery_status (read, Explore). Connection details are in the MCP integration docs.
4. Knowledge check
Q1
For AWS Organizations, ZopNight connects:
A. To each of the member accounts individually, one single account at a time
B. To the management account via cross-account assume-role across all member accounts
C. Via VPC peering into the organisation’s management account first
D. Region by region, once for each region in every single account
Show answer
Correct: A. There is no Organizations-level connector. Each AWS account is connected on its own, usually with a CloudFormation quick-create stack that creates a role trusting ZopNight’s Google identity. Adding a new AWS account means connecting it too; ZopNight does not find it through the management account.
Q2
A GCP service account at the organization level with organization-viewer role:
A. Cannot access any of the underlying projects at all from that level
B. Has read access to all projects in the org (and any new projects added later)
C. Needs additional per-project credentials on top of that one
D. Needs the project-viewer role granted separately per project
Show answer
Correct: B. Org-level IAM grants cascade to every project, which is a GCP fact worth knowing. ZopNight, though, connects per project, so each project is added as its own cloud account even though one credential could read them all.
Q3
Azure Management Groups:
A. Are entirely flat, with no nesting permitted
B. Are deprecated by Microsoft these days
C. Form a hierarchy: tenant → MG → subscription
D. Map one-to-one onto the subscriptions
Show answer
Correct: C. Policies, role assignments, and tags at higher levels apply to all descendants. In ZopNight, a tenant connection discovers its subscriptions, but reports do not group by management group. MGs are Azure’s hierarchical primitive. The root MG is implicit; everything else nests beneath it.
5. Apply
Open Cost Reports and expand each provider on the Summary tab to see spend per connected account. Compare that account list with your cloud-side hierarchy; ZopNight shows accounts, not OUs, folders or management groups, so the map from account to OU lives with you.
For mature orgs, document the hierarchy in your team wiki: knowing “platform team’s prod workloads live in OU X / account Y / region Z” is the kind of context that gets lost without explicit documentation.
Related lessons
- L1: Why multi-account
- L3: Cross-account discovery (next)
- L4: Rollup vs isolation
- L5: Multi-account anti-patterns
Glossary terms touched
AWS Organizations · Management Group · Service Control Policy