AWS Cloud & DevOps Tutorial 0/70 lessons ~6 min read Lesson 48“IAM, VPC, EC2, Lambda, ECS, EKS, Terraform, CI/CD, and AWS operations”

AWS Organizations, Control Tower and Landing Zones

TechLearningPro outgrew the “one AWS account for everything” era the moment student labs, production learner APIs, shared CI runners, and finance reporting collided in the same bla

Course progress0%

Focus

15 guided sections

Practice signal

Examples included

Career prep

Interview Q&A included

AWS Organizations, Control Tower and Landing Zones

AWS Cloud & DevOps Engineering · Lesson 48 · Advanced Platforms and Networking

Lesson Overview

TechLearningPro outgrew the “one AWS account for everything” era the moment student labs, production learner APIs, shared CI runners, and finance reporting collided in the same blast radius. AWS Organizations creates a hierarchical container of accounts under a management account so you can apply Service Control Policies (SCPs), consolidate billing, and share resources with deliberate boundaries. AWS Control Tower sits on that foundation to provision a landing zone—baseline multi-account structure, guardrails, and an Account Factory—so new environments arrive consistent instead of hand-built snowflakes. This lesson teaches you to design Organizational Units (OUs) for dev / stage / prod, place shared services, reason about Control Tower guardrails, and propose a TechLearningPro landing zone without inventing undocumented APIs or pretending SCPs are IAM permission grants.

You closed Module 4 with FinOps habits in FinOps, Cost Explorer and Cost Optimization. Module 5 starts by making account structure the first architecture decision. Cross-links: AWS Account Setup, IAM Identity Center and Organizations for Identity Center foundations, Policy as Code and Infrastructure Compliance for SCP intent, and AWS Config and Compliance Automation for detective controls. Tag designs and lab notes Project=tlp-lesson48. Set organization- and account-level budgets before Account Factory experiments; clean up unused sandbox accounts and trial resources according to your org’s account-closure process—never leave orphan NAT Gateways or Control Tower customizations that bill quietly.

Learning Objectives

Explain why multi-account architecture reduces blast radius compared with a single shared account.
Describe the Organizations management account role and why workloads should not run there.
Design OU trees separating Security, Infrastructure, Sandbox, and Workloads (dev/stage/prod).
Distinguish SCPs (permission guardrails) from IAM identity policies (permission grants).
Map Control Tower landing zone components: shared accounts, guardrails, Account Factory.
Compare mandatory versus strongly recommended Control Tower guardrails at a conceptual level.
Propose Account Factory vending for TechLearningPro team sandboxes with tagging baselines.
Place Log Archive and Audit (security tooling) accounts appropriately in the OU tree.
Relate consolidated billing to Cost Explorer multi-account views from lesson 47.
Design enrollment of existing accounts versus greenfield Account Factory paths.
Identify when Control Tower is appropriate versus DIY Organizations + custom automation.
Document SCP deny examples as intent (not copy-paste unverified JSON as eternal truth).
Plan Identity Center permission sets mapped to OUs and accounts.
Troubleshoot “SCP denied” versus “IAM missing Allow” confusion.
Estimate cost drivers: Control Tower, Config rules, CloudTrail organization trails, shared networking.
Write an ADR for TechLearningPro’s landing zone OU layout.
Prepare interview answers on landing zones and account vending.
Preview cross-account access patterns in lesson 49 without implementing them yet.

Prerequisites

Foundational IAM and Organizations awareness from AWS Account Setup, IAM Identity Center and Organizations and AWS Identity and Access Management.
FinOps budgets enabled; permission to view Organizations console or architecture diagrams if management account access is restricted in class.
Willingness to treat production Control Tower changes as change-controlled—labs prefer design docs over mutating a shared company org.

Detailed Core Concepts

The problem a landing zone solves

Without structure, every team creates accounts ad hoc, attaches root users as break-glass forever, leaves public S3 buckets, and shares long-lived access keys across “just this one pipeline.” A landing zone is the opinionated baseline: OU layout, logging destinations, identity federation, networking hooks, tagging policy, and guardrails that make the secure path the easy path. TechLearningPro’s platform guild owns the landing zone; product guilds consume vended accounts.

AWS Organizations

Organizations is the control plane for multi-account management. The management account (formerly “master”) pays the consolidated bill, owns organization-level configuration, and should host almost no application workloads. Member accounts hold workloads. OUs group accounts for policy inheritance. Policies applied at an OU affect accounts beneath it (subject to current Organizations policy types and inheritance rules—verify docs when implementing).

Service Control Policies

SCPs are organization permission boundaries at the account/OU level: they can deny actions even if IAM allows them, and they never grant ability by themselves. Classic intents: deny leaving Regions outside an allowlist; deny disabling CloudTrail or GuardDuty; deny creating expensive instance families in Sandbox OUs. Always combine with Identity Center least privilege—SCPs are a safety net, not a substitute for good IAM.

Control Tower

Control Tower automates a multi-account landing zone on Organizations: creates or enrolls shared accounts (commonly Log Archive and Audit/Security Tooling patterns—confirm current Control Tower account roles in docs), applies guardrails (preventive and detective), and provides Account Factory to vend standardized accounts. It integrates with Identity Center for federated access. Customizations (CfCT / AFT and related patterns) extend baselines—treat those as advanced follow-ons and verify current recommended customization paths in AWS documentation.

Account Factory and AFT tease

Account Factory lets authorized users request accounts with baseline configuration. Account Factory for Terraform (AFT) and similar pipelines (when used) codify account provisioning. In this course you design the what (OU placement, tags, budgets, default VPC posture); implementation tooling is chosen later with verified docs.

Landing zone for TechLearningPro (dev / stage / prod)

Illustrative OU sketch (adapt; not a mandatory AWS blueprint):

Security OU — Log Archive, Audit/Security Tooling.
Infrastructure OU — Network hub, shared services, CI tooling account.
Workloads OU
- Dev OU — tlp-dev-* accounts or one multi-tenant sandbox with hard budgets.
- Stage OU — pre-prod mirrors.
- Prod OU — production learner APIs, payments-adjacent systems, content delivery origins.
Sandbox / Suspended OU — short-lived experiments and quarantined accounts.

Separate prod from dev so an SCP mistake in sandbox cannot delete prod trails, and so FinOps showback is unambiguous.

Guardrails and Config

Preventive guardrails often map to SCPs; detective guardrails often map to Config rules and Security Hub aggregation. Continuity with AWS Config and Compliance Automation and GuardDuty, Security Hub and Inspector: organization-level findings need somewhere to land—usually the Audit/Security account.

What Control Tower is not

It is not a replacement for application architecture, not automatic zero-trust networking, and not a license to ignore IAM. It will not magically make hybrid DNS correct (lesson 51) or DynamoDB capacity wise (lesson 53). It standardizes accounts and baselines.

Architecture and Design Diagrams

mermaid
flowchart TB
  Mgmt[Management account]
  Root[Root OU]
  Sec[Security OU]
  Infra[Infrastructure OU]
  Work[Workloads OU]
  Dev[Dev OU]
  Stage[Stage OU]
  Prod[Prod OU]
  Log[Log Archive]
  Audit[Audit / Security Tooling]
  Net[Network Hub]
  Shared[Shared Services]
  D1[tlp-dev-apps]
  S1[tlp-stage-apps]
  P1[tlp-prod-apps]

  Mgmt --> Root
  Root --> Sec
  Root --> Infra
  Root --> Work
  Sec --> Log
  Sec --> Audit
  Infra --> Net
  Infra --> Shared
  Work --> Dev
  Work --> Stage
  Work --> Prod
  Dev --> D1
  Stage --> S1
  Prod --> P1

mermaid
flowchart LR
  Request[Account request]
  Factory[Account Factory / pipeline]
  Baseline[Guardrails tags budgets Identity Center]
  Ready[Workload-ready account]
  Request --> Factory --> Baseline --> Ready

Technical Explanation

Policy inheritance mental model

Think of SCPs as nested filters: effective permissions = (IAM Allow) AND (not denied by any applicable SCP) AND (permission boundaries / session policies as applicable). Engineers debugging AccessDenied must check CloudTrail, IAM simulators, and Organizations policy simulator / effective policy views available in current consoles—confirm tooling names in docs. Never assume “I attached AdministratorAccess so SCPs cannot stop me.”

Management account hygiene

Break-glass root and management account MFA are non-negotiable. Prefer Identity Center for humans. Avoid deploying learner APIs into the management account—compromise there threatens the entire org. Billing and org APIs stay here; application blast radius stays in member accounts.

Consolidated billing and FinOps

Organizations consolidates invoices; Cost Explorer can filter by linked account and tags (lesson 47). Activate cost allocation tags org-wide. Per-account budgets catch runaway sandboxes before they surprise Finance.

Control Tower setup considerations

Setup chooses home Region for Control Tower, Regions to govern, and optional VPC configurations for new accounts. Default VPC deletion or restricted public subnet patterns are common security postures—document the choice. Enabling many Regions multiplies Config and logging cost—align with FinOps. Always read current Control Tower prerequisites (IAM permissions, existing Organizations state, opt-in Regions) before clicking Launch.

Enrolling existing accounts

Brownfield enrollment moves an account under Control Tower governance. Expect remediation of noncompliant resources. Plan maintenance windows; do not enroll production without a runbook. Document drift between custom baselines and Control Tower expectations.

Identity Center permission sets

Map roles like TLP-PlatformAdmin, TLP-Developer, TLP-ReadOnly, TLP-SecurityAuditor to accounts via assignments. Developers get power in Dev OU accounts, read-only in Prod, and elevate via break-glass with logging. Continuity with early IAM Identity Center lessons.

Networking hook (forward reference)

Landing zones often create a network account for Transit Gateway and shared services (lessons 49–52). Do not peer every VPC to every VPC from day one; design hub-and-spoke later. This lesson stops at where the network account lives.

Observability baselines

Organization CloudTrail to Log Archive, Config aggregators, Security Hub delegated admin—these belong in the Security OU story. Continuity with AWS CloudTrail and Audit Logging.

Cost honesty

Control Tower, Config rules, CloudTrail, GuardDuty, and VPC resources have pricing dimensions. Label every estimate with “verify current pricing.” Sandbox Account Factory spam is a real FinOps failure mode—gate requests and set budgets on every new account.

Security of the landing zone itself

Who can modify SCPs or disable guardrails is as sensitive as who can deploy to prod. Use change tickets, dual control for SCP edits, and CloudTrail monitoring for Organizations API calls. SCPs that deny organizations:LeaveOrganization (where applicable and verified) reduce rogue account escape—confirm current action names in docs before writing policies.

Practical Implementation or Design Walkthrough

Problem

Propose a TechLearningPro landing zone with separated workloads for dev, stage, and prod, plus Security and Infrastructure OUs. You may use diagrams and ADRs even if your classroom cannot mutate a real Organization.

Steps

Confirm budgets exist on the payer / lab account; tag notes Project=tlp-lesson48.
Draw current-state vs target OU tree for TechLearningPro.
List five preventive SCP intents (Region lock, trail protection, sandbox instance family limits, require IMDSv2 intent, deny public S3 ACL abuse intent)—cite AWS docs for action strings when implementing; do not invent APIs.
Place Log Archive and Audit accounts; describe what lands in each.
Place Network Hub and Shared Services under Infrastructure.
Define Account Factory intake: who can request, required tags (Owner, Environment, CostCenter, Project), default budget template.
Map Identity Center permission sets to Dev vs Stage vs Prod.
Write ADR: Control Tower vs DIY Organizations for TechLearningPro at current scale.
List cleanup: cancel unused Account Factory trials; remove lab SCPs from non-prod orgs only with approval; never “test SCP” in prod without change control.
Peer-review for management-account workload smell and missing FinOps hooks.

Enterprise Real-World Scenarios

Single account chaos at acquisition

Acquired LMS brand shares one account for CI, prod, and student sandboxes. First 30 days: create Organization (or enroll), carve Prod OU, move workloads carefully, apply Region SCP, enable org CloudTrail. Cultural onboarding matters as much as SCPs.

SCP breaks deployments

Platform tightens Region deny; CodePipeline in an unexpected Region fails. Symptom: AccessDenied on ecr:GetAuthorizationToken or deploy roles. Fix: inventory Regions actually used; update allowlist; communicate change. Continuity with Module 3 pipelines.

Management account becomes an app host

Early startup convenience; later incident scope includes billing and org APIs. Migration: create prod member accounts, move workloads, leave management thin.

Account Factory without budgets

Students vend 40 accounts; idle NAT and ALBs accumulate. Fix: mandatory budget CloudFormation/Customizations, TTL tags, automated cleanup jobs (design-level), FinOps review of Account Factory metrics.

Control Tower customization drift

Teams fork CfCT without tests; guardrails conflict. Fix: single platform pipeline, versioned baselines, staging Organization where possible for experiments.

Best Practices

Keep the management account nearly empty of workloads.
Separate Security, Infrastructure, Workloads, and Sandbox OUs.
Use SCPs as deny guardrails; grant via IAM/Identity Center.
Prefer Control Tower for greenfield consistency when it fits scale.
Require tags and budgets on every Account Factory request.
Centralize org CloudTrail and Config aggregation in Security accounts.
Change-control SCP and Control Tower updates.
Map Identity Center permission sets to environment risk.
Document OU ownership in a platform runbook.
Align Region governance with product latency needs and FinOps.
Plan brownfield enrollment with remediation runbooks.
Do not peer every VPC on day one—leave a network account hook.
Verify every policy action string against current AWS docs.
Teach developers “AccessDenied may be SCP” as first-class troubleshooting.
Review landing zone quarterly with Security and FinOps.

Common Mistakes and Anti-Patterns

Running production apps in the management account.
Treating SCPs as Allow policies.
Flat OU with no environment separation.
Account Factory without tagging or budgets.
Copy-pasting SCP JSON from blogs without verifying actions.
Disabling detective guardrails to “move faster.”
One shared admin role across all prod accounts with standing access.
Ignoring consolidated billing until the invoice shock.
Enrolling prod into Control Tower without a dry-run remediation list.
Inventing Control Tower “secret APIs” in lab writeups.

Troubleshooting and Design Review

Symptom	Cause	Action
AccessDenied despite Admin IAM	SCP deny	Inspect Organizations policies on OU/account
Account Factory request stuck	Prerequisite/guardrail failure	Check Control Tower and CloudTrail events; verify docs
Missing logs in Log Archive	Trail/Config mis-destination	Validate org trail and bucket policies
Cost spike after landing zone	Many Regions/Config rules	FinOps review; trim Regions; tag showback
Cannot assume role into new account	Identity Center assignment missing	Fix permission set assignments
Developers blame IAM only	SCP literacy gap	Train + document effective permission model

Interview Questions and Answers

Q1: What is a landing zone? A: Opinionated multi-account baseline (OUs, identity, logging, guardrails, networking hooks) for consistent secure accounts.
Q2: Organizations vs Control Tower? A: Organizations is the multi-account control plane; Control Tower automates a landing zone on top.
Q3: What do SCPs do? A: Set permission guardrails (often denies); they do not grant permissions alone.
Q4: Why not use the management account for apps? A: Blast radius and privilege concentration—compromise affects org control plane and billing.
Q5: OU purpose? A: Group accounts for policy inheritance and operational ownership.
Q6: Account Factory? A: Standardized account vending with baselines.
Q7: Log Archive vs Audit? A: Typical pattern: immutable/central logs vs security tooling aggregation—confirm current Control Tower roles in docs.
Q8: Preventive vs detective guardrails? A: Prevent blocks noncompliant actions; detect finds/report drift (e.g., Config).
Q9: How does FinOps relate? A: Consolidated billing, per-account budgets, tags, showback by OU/account.
Q10: Brownfield challenge? A: Remediating existing noncompliance before/during enrollment.
Q11: Identity Center role? A: Federated workforce access with permission sets per account.
Q12: DIY when? A: Unusual constraints, existing mature automation, or Control Tower feature gaps—justify in ADR.
Q13: First SCP examples? A: Region allowlists, protect CloudTrail/Config, sandbox spend limits—verify actions.
Q14: How debug SCP issues? A: CloudTrail + effective policy inspection + reproduce with least accounts.
Q15: Landing zone success metric? A: Time-to-secure-account, policy coverage, untagged spend ↓, incident blast radius ↓.

Hands-On Exercises

Exercise: Propose a landing zone with separated workloads

Deliverable: OU diagram (Mermaid or draw.io), SCP intent list (≥5) with doc links for actions you would use, Account Factory intake form fields, Identity Center permission set matrix (Dev/Stage/Prod), ADR Control Tower vs DIY, budget proof, Project=tlp-lesson48 tagging note, cleanup/closure plan for any lab accounts.

Challenge ADR

Constraint: TechLearningPro must isolate payment-adjacent prod from student sandboxes and prove org CloudTrail immutability intent. Extend the landing zone with a Suspended OU quarantine path and dual-control SCP change process.

Lab evidence checklist

OU diagram; SCP intents + doc citations; permission set matrix; ADR; budget screenshots; statement that no unverified API names were used; cleanup notes.

Narrative: the Friday SCP

A well-meant Region deny landed Friday evening and blocked a documented us-west-2 DR drill account. Postmortem: change calendar, staging org test, communication to pipeline owners. Landing zones need operations theater, not only YAML.

Continuity

Next: Cross-Account Access and Multi-Account Networking for IAM role assumption, RAM tease, and VPC patterns across the accounts you just placed. Later lessons add PrivateLink, hybrid links, Transit Gateway, and data platform ops.

Deep dive: SCP evaluation order literacy

Effective permissions require simultaneous mental models of identity policies, resource policies, SCPs, permission boundaries, and session policies. Practice with a worked example: developer role Allow s3:* on lab buckets, SCP denies s3:DeleteBucket in Prod OU—delete fails in prod, succeeds in sandbox if not denied there. Document the story for onboarding.

Deep dive: Control Tower home Region and multi-Region governance

Home Region hosts Control Tower resources; governed Regions expand detective/preventive coverage and cost. Align with exam-day traffic Regions and DR Regions from Backup, Disaster Recovery and Resilience. Do not enable “all Regions” casually.

Deep dive: account closure and quarantine

Closed accounts and Suspended OU patterns reduce zombie spend. Follow AWS account closure processes from current docs; do not invent CLI flags. Quarantine compromised accounts by moving OUs and attaching restrictive SCPs while investigating.

Extended enterprise scenario: university partnership sandboxes

Partner universities need isolated sandboxes with hard SCPs (no IAM user create, Region lock, max instance families). Account Factory + budgets + 14-day TTL tag. Platform reviews weekly orphan report.

Extended enterprise scenario: regulated content in Prod OU

Certain courses store regulated learner data. Prod OU gets tighter SCPs, mandatory encryption Config rules, and restricted permission sets. Dev OU cannot assume prod roles by default—preview lesson 49.

Extended practice scenario 1 — 48 aws organizations control tower and landing zones

Draft TechLearningPro OU tree with Security, Infrastructure, Workloads (dev/stage/prod), and Sandbox; peer-review management-account emptiness.

In a timed drill for landing zone and Organizations design, implement or design the core lab with a partner observing. The observer's job is to stop any step that invents API flags, hardcodes secrets, invents pricing numbers presented as current quotes, or skips budget and cleanup. After the drill, rewrite your ADR in ten lines: context, decision, consequences. Attach evidence: OU diagrams, SCP intent lists with doc links, permission set matrices, ADR, budget proof, and destroy confirmation for any lab resources.

Discuss how this lesson connects to FinOps (47), IAM Identity Center foundations, Config/CloudTrail organization patterns, and upcoming cross-account networking (49). List two failure modes you simulated or observed (SCP blocking deploys; Account Factory cost overrun), including detection and fix. Note which billable dimensions may move and when Cost Explorer would show them—verify current pricing pages; never invent rates.

Finally, teach back the lesson overview paragraph from memory, then check against the text. Gaps become flashcards. Premium courses finish when you can operate under time pressure without treating multi-account networking and data platforms as mystery consoles.

Extended practice scenario 2 — 48 aws organizations control tower and landing zones

Write five SCP intents with links to current AWS docs for action strings; mark any uncertain actions as TODO verify—never invent.

Extended practice scenario 3 — 48 aws organizations control tower and landing zones

Design Account Factory intake: required tags, budget template, approver, default Region set.

Extended practice scenario 4 — 48 aws organizations control tower and landing zones

Map Identity Center permission sets for Platform, Developer, ReadOnly, SecurityAuditor across Dev/Stage/Prod.

Extended practice scenario 5 — 48 aws organizations control tower and landing zones

Compare Control Tower vs DIY Organizations in a one-page ADR for a 15-account TechLearningPro org.

Extended practice scenario 6 — 48 aws organizations control tower and landing zones

List brownfield enrollment risks for an existing messy shared account; produce a remediation checklist.

Extended practice scenario 7 — 48 aws organizations control tower and landing zones

Design Log Archive bucket policy intent (immutability, encryption, restricted principals)—verify KMS/S3 patterns against docs and lesson 41 continuity.

Extended practice scenario 8 — 48 aws organizations control tower and landing zones

FinOps: propose per-OU budget strategy and showback using linked accounts in Cost Explorer.

Extended practice scenario 9 — 48 aws organizations control tower and landing zones

Simulate AccessDenied triage flowchart: IAM vs SCP vs resource policy decision tree.

Extended practice scenario 10 — 48 aws organizations control tower and landing zones

Region governance worksheet: list Regions TechLearningPro truly needs; justify each for latency, DR, or compliance.

Extended practice scenario 11 — 48 aws organizations control tower and landing zones

Guardrail catalog: pick three preventive and three detective controls and map owners.

Extended practice scenario 12 — 48 aws organizations control tower and landing zones

Account vending abuse case: draft TTL and cleanup policy for sandbox accounts.

Extended practice scenario 13 — 48 aws organizations control tower and landing zones

Document break-glass access to management account: MFA, vaulted credentials, monitored assumption.

Extended practice scenario 14 — 48 aws organizations control tower and landing zones

Change management: write a dual-control checklist for SCP updates.

Extended practice scenario 15 — 48 aws organizations control tower and landing zones

Draw before/after diagrams for moving CI runners out of the management account into Infrastructure OU.

Extended practice scenario 16 — 48 aws organizations control tower and landing zones

Security Hub delegated administrator placement decision record in Audit account.

Extended practice scenario 17 — 48 aws organizations control tower and landing zones

Tagging dictionary aligned with lesson 47; enforce via Account Factory defaults.

Extended practice scenario 18 — 48 aws organizations control tower and landing zones

Risk review: standing admin in all accounts vs just-in-time elevation—pick and justify.

Extended practice scenario 19 — 48 aws organizations control tower and landing zones

Classroom-only: if you lack org admin rights, deliver a complete design pack and have an instructor validate against a demo org screenshots.

Extended practice scenario 20 — 48 aws organizations control tower and landing zones

List Control Tower customization options at high level (AFT/CfCT awareness) with doc links—no fake module names.

Extended practice scenario 21 — 48 aws organizations control tower and landing zones

Incident tabletop: compromised developer credentials in Dev OU—what SCPs limit damage to Prod?

Extended practice scenario 22 — 48 aws organizations control tower and landing zones

Produce a 30-60-90 day landing zone rollout plan for TechLearningPro.

Extended practice scenario 23 — 48 aws organizations control tower and landing zones

Glossary flashcards for all bold terms in this lesson.

Extended practice scenario 24 — 48 aws organizations control tower and landing zones

Budget and cleanup sworn statement for any resources created while exploring Organizations/Control Tower UIs.

Extended practice scenario 25 — 48 aws organizations control tower and landing zones

Full dress rehearsal: OU diagram → SCP intents → permission matrix → ADR → peer review → teach-back.

Compliance evidence pack for auditors / Finance

OU diagram approved by Security; SCP change tickets; org CloudTrail proof; Control Tower guardrail status export (redact IDs); budget configs per critical accounts; Identity Center assignment screenshots; pricing verification dates for any cost claims.

Glossary drill

AWS Organizations; management account; member account; OU; SCP; Control Tower; landing zone; Account Factory; guardrail (preventive/detective); Log Archive; Audit account; consolidated billing; Identity Center permission set; brownfield enrollment; AFT (awareness).

Budget and cleanup sworn statement

I verified budgets remain enabled with alert subscribers for accounts touched in this lesson. I did not leave experimental Account Factory accounts billing without an owner. I labeled every cost figure with pricing-page retrieval dates or marked it illustrative. I invented no AWS API names. Signed ________ date ________.

Interview story to memorize

“At TechLearningPro we moved from one chaotic account to an Organizations landing zone with Security, Infrastructure, and Workloads OUs for dev/stage/prod, Control Tower guardrails, Account Factory with mandatory tags and budgets, and SCPs that deny dangerous actions while Identity Center grants least privilege—keeping the management account free of apps.”

Module 5 opening narrative

Observability and FinOps taught you to see and pay on purpose. Now structure the estate so blast radius, identity, and networking have a place to live. Lessons 48–53 build the advanced platform and networking spine before deeper data analytics lessons.

Self-assessment rubric

Area	Weight
Conceptual accuracy (Orgs/CT/SCP)	20%
OU / landing zone design quality	25%
Security and least-privilege thinking	20%
FinOps + operational realism	20%
Documentation, doc citations, cleanup	15%

Final synthesis before summary

A landing zone is culture encoded as accounts: who owns security logs, who can vend environments, what is denied by default, and how prod stays boring. TechLearningPro scales on that boredom.

Lesson Summary

AWS Organizations provides multi-account hierarchy, SCPs, and consolidated billing; Control Tower accelerates a governed landing zone with Account Factory and guardrails. Design TechLearningPro OUs for Security, Infrastructure, and Workloads across dev / stage / prod, keep the management account thin, grant via Identity Center, deny via SCPs, attach budgets and tags at birth, and verify every policy action against current AWS documentation. Tag Project=tlp-lesson48; clean up experimental accounts.

Next: Cross-Account Access and Multi-Account Networking.