Cloud Leadership: governance, cost and certification paths

01

The cloud leader's job: landing zones and account structure

In simple words

A big school is not one giant room. It has a building for each grade, a classroom for each class, and an office that sets the rules for everyone. In the cloud, a leader builds the same kind of map: separate spaces for each team, and one place at the top where the shared rules live.

Key facts

Before this course: Cloud Architecture: reliable, secure design (course 7.9.3). There you designed one workload well. Here you design the home that all workloads live in, and the rules that keep it safe and affordable.
Accounts are walls. AWS says an AWS account is an isolation boundary for identity and access management, and by default no access is allowed between accounts. AWS recommends using several accounts to separate workloads rather than one account, and says charges are based on resource usage, not on the number of accounts.
Each provider has a hierarchy:

Provider	Top	Groups	Where resources live	How rules flow
AWS	Organization (management account)	Organizational units (OUs)	Accounts	Policies attached to an OU apply to the accounts in it
Microsoft Azure	Root management group ("Tenant root group")	Management groups	Subscriptions, then resource groups	Access and policies cascade down by inheritance
Google Cloud	Organization	Folders	Projects	IAM roles and organization policies are inherited downward

Azure limits to know: a management group tree can be up to six levels deep, not counting the root level or the subscription level. Each management group and subscription has only one parent. Anything assigned at the root applies to every resource in the directory, so Microsoft says assignments at the root should be "must have" only.
Google Cloud: the organization is the parent of all folders and projects, and the effective policy on a resource combines its own policies with those inherited from above.
Landing zone: AWS describes a landing zone as an orchestration framework for your foundational AWS environment. In the Microsoft Cloud Adoption Framework (CAF), the outcome of Azure adoption is an Azure landing zone plus operational standards that support all workloads.
The Microsoft CAF lists seven phases: Strategy, Plan, Ready, Adopt, Govern, Secure and Manage. AWS keeps a clean security OU that holds only the essential security accounts designated by AWS Control Tower.
A cloud leader owns four things: the structure (this lesson), the rules (tags, cost and access, lessons 2 to 4), the change plan (migration, lesson 5) and the people (skills and reviews, lessons 6 and 7).

Step by step

Pick a made-up organization for this course, for example a clinic group with a website team, a bookings team and a finance team.
Write the top of the tree (organization or root group).
Add groups. One example structure: Security (log and audit accounts), Shared services (network, identity), Workloads (split into Production and Non-production) and Sandbox (for learning, with strict budgets). Microsoft's own example shows "Landing zones" (with Corp and Online) and "Sandbox" groups.
Under each group, list the accounts, subscriptions or projects, and give each one a named owner.
Write the three rules that must apply everywhere (for example: audit logs stay on, only approved Regions, every resource tagged). Put them at the highest group where they are truly "must have".
Write one rule that applies only to Sandbox (for example, a small budget with an action).
Check: every account has one parent and one owner, production is separate from non-production, and you can say why each top-level rule belongs at the top.

Watch on YouTube

Understanding multi-account management (AWS re:Invent 2020)AWS Events · YouTube · youtube.com

Videos by other creators on YouTube, for reference. They are not made by or affiliated with The Future Market.

LESSON 01The cloud leader's job: landing zones and account structure

LESSON 01 / ANIMATED LESSON / AI VOICE00:00 / 01:10

Voice

Read the video script

[Host] "One account for everything feels simple. Until one mistake breaks everything."
[Screen: a tree with Security, Shared services, Workloads and Sandbox] "A cloud leader draws the map first. Separate spaces for each team, and one place at the top for shared rules."
[Text on screen: Accounts are walls. Rules flow down.] "Accounts, subscriptions and projects are walls. Rules set higher up flow down to everything below."
[Host] "Put only the must-have rules at the very top. Everything else goes lower, closer to the team."

Try it now

Draw the hierarchy for your made-up organization on one page. Next to each group, write its owner and the rules attached to it. Underline any rule at the top that is not truly "must have", and move it lower.

ClaudeStuck? Copy a ready-made prompt for Claude

Copy this, open Claude, paste it, and Claude will walk you through the lesson step by step.

For a grown-up: Claude is for adults (18+). Copy this, paste it into Claude, and use the answer to explain the lesson to your child.

I'm learning "Cloud Leadership: governance, cost and certification paths" on The Future Market. Lesson 1: "The cloud leader's job: landing zones and account structure".

What the lesson teaches:
- Before this course: Cloud Architecture: reliable, secure design (course 7.9.3). There you designed one workload well. Here you design the home that all workloads live in, and the rules that keep it safe and affordable.
- Accounts are walls. AWS says an AWS account is an isolation boundary for identity and access management, and by default no access is allowed between accounts. AWS recommends using several accounts to separate workloads rather than one account, and says charges are based on resource usage, not on the number of accounts.
- Each provider has a hierarchy:
- Provider - Top - Groups - Where resources live - How rules flow
- AWS - Organization (management account) - Organizational units (OUs) - Accounts - Policies attached to an OU apply to the accounts in it
- Microsoft Azure - Root management group ("Tenant root group") - Management groups - Subscriptions, then resource groups - Access and policies cascade down by inheritance
- Google Cloud - Organization - Folders - Projects - IAM roles and organization policies are inherited downward

The exercise I'm working on:
Draw the hierarchy for your made-up organization on one page. Next to each group, write its owner and the rules attached to it. Underline any rule at the top that is not truly "must have", and move it lower.

I'm stuck. Please:
1. Explain the main idea in plain, simple words with one everyday example.
2. Walk me through the exercise one small step at a time. Ask me what I've done so far before giving the next step.
3. Don't just give me the final answer. Help me do it myself, and check my work when I share it.

I'm a parent helping my child (about 8 years old) with a lesson called "The cloud leader's job: landing zones and account structure" from the course "Cloud Leadership: governance, cost and certification paths".

Here's what the lesson says:
A big school is not one giant room. It has a building for each grade, a classroom for each class, and an office that sets the rules for everyone. In the cloud, a leader builds the same kind of map: separate spaces for each team, and one place at the top where the shared rules live.

The activity:
Draw the hierarchy for your made-up organization on one page. Next to each group, write its owner and the rules attached to it. Underline any rule at the top that is not truly "must have", and move it lower.

Please explain this so an 8-year-old understands: short sentences, a fun everyday example, and no hard words.
Then give me 3 simple questions I can ask my child to check they understood, and a way to do the activity together, one tiny step at a time.

Open Claude

Sources

AWS, Organizing your AWS environment using multiple accounts: docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment
Microsoft Learn, Organize your resources with management groups: learn.microsoft.com/en-us/azure/governance/management-groups/overview
Google Cloud, Resource hierarchy: docs.cloud.google.com/resource-manager/docs/cloud-platform-resource-hi
Microsoft Learn, Cloud Adoption Framework overview: learn.microsoft.com/en-us/azure/cloud-adoption-framework/overview
AWS Prescriptive Guidance, Migration strategy overview (landing zone): docs.aws.amazon.com/prescriptive-guidance/latest/strategy-migration/ov

My notes

I learned this

02