Cloud Landing Zone Architecture: Accounts, Guardrails and Org Policy Across AWS, Azure and GCP

Most cloud landing zone architecture failures are not caused by a missing diagram. They happen because a team treated the landing zone as a one-time bootstrap project, deployed a vendor template, and never decided which guardrail belongs at which layer. Two years later a developer in a sandbox account can create a public bucket, a “temporary” exception has outlived three reorganisations, and nobody can say which policy actually denied a failed deployment.

This matters in 2026 because the policy surface has grown. AWS now has service control policies, resource control policies and declarative policies. Azure has management groups, Azure Policy with a dozen effects, and a platform-versus-workload split. Google Cloud has managed, legacy and custom organization policy constraints with dry-run mode. Each cloud evaluates restrictions at a different point in a request’s life.

You will leave with a layer model for placing every guardrail, a side-by-side comparison of the three hierarchies, the hard quotas that shape the design, runnable infrastructure-as-code for one guardrail per cloud, and a rollout and drift playbook.

What this covers: the control planes every landing zone needs, the three hierarchies compared, guardrail evaluation semantics, networking and logging topology, account vending and IaC delivery, quotas, failure modes and a launch checklist.

Context and Background

A landing zone is the pre-built, governed environment into which workloads are placed. The term is common to all three vendors, but each defines it slightly differently. AWS describes a landing zone as a well-architected multi-account environment, and AWS Control Tower orchestrates AWS Organizations, AWS Service Catalog and IAM Identity Center to build one. Microsoft splits the idea in two: a platform landing zone (the management group hierarchy, shared connectivity, identity and management services) and one or more workload landing zones where application teams deploy inside the platform’s guardrails. Google Cloud’s equivalent is a resource hierarchy of organization, folders and projects with organization policies attached, usually built from Terraform blueprints.

The incumbents have converged on a shared shape. A tree of containers (accounts, subscriptions, projects) groups workloads by risk and lifecycle. Policy attached high in the tree flows down. A small number of platform-owned accounts hold logs, security tooling and network hubs. New workload containers are created by an automated vending process rather than a ticket. Anything else, from the number of tiers to the naming scheme, is a local decision.

What is less well understood is that the three clouds disagree about when a policy is evaluated and whether it can grant. An AWS service control policy (SCP) never grants permission; it only sets the ceiling of what identities in member accounts may be granted. A Google Cloud organization policy constrains the configuration a resource may have, regardless of who asks. Azure Policy evaluates the resource request itself and can modify, deny, audit or deploy companion resources. Mixing those mental models is the most common source of confusing denials. For the AWS side in depth, see our post on AWS IAM policy evaluation logic, SCPs and permission boundaries.

This post takes a deliberately different angle from the vendor reference guides and from our existing coverage of identity and IaC. The existing posts on Terraform state, drift detection and plan/apply pipelines and internal developer platforms and golden paths cover delivery tooling and the developer experience. Here the unit of analysis is the guardrail itself: where it is evaluated, what it can and cannot see, what it costs in quota, and how it fails. Facts about vendor limits below were checked against official documentation in November 2026 and are dated accordingly; limits change, so confirm them before you commit a design.

The Five Control Planes of a Landing Zone

Every landing zone, regardless of cloud, has to answer five questions. Which containers exist and how are they nested? Who is allowed to do what inside them? Which configurations are forbidden or required? How does traffic flow between and out of them? Where do the logs go and who reads them? Call these the hierarchy, identity, policy, network and telemetry planes. A design is complete only when each plane has an owner, an automation path and a break-glass procedure.

The reason to name them separately is that vendors bundle them differently. Control Tower bundles hierarchy, identity and logging into one managed setup and leaves networking to you. The Azure landing zone accelerators bundle hierarchy, policy, connectivity and logging into one deployment. Google’s foundation blueprints bundle hierarchy, organization policy, logging sinks and shared VPC. When you adopt a bundle, you inherit its answers for every plane at once, including the ones you would have answered differently.

Reference Architecture: Containers, Guardrails and Shared Services

A landing zone is a tree of containers with policy attached at the branches and a small set of platform-owned shared services beside it. The same logical layout works on all three clouds: a root, a platform branch (security, logging, network, identity), a workloads branch split by environment or data sensitivity, a sandbox branch with tight budgets, and a quarantine branch for suspended or compromised containers. Guardrails attach to branches, never to individual workload containers.

Figure 1: Reference cloud landing zone architecture. Policy attaches to branches, shared services live in platform containers, and workloads are vended into the leaf branches.

The figure shows the logical shape. The root carries only the guardrails that every container must obey, such as denying actions in unapproved regions and protecting the logging and security tooling from tampering. The platform branch holds containers owned by a central team. The workload branch is where application teams operate, and it is subdivided by the policy differences you actually need, not by org-chart boxes.

Hierarchy: design for policy inheritance, not for the org chart

The most durable rule of hierarchy design is that a branch should exist only if it carries a different set of guardrails or a different set of administrators. A branch for “Finance department” that has the same policies as “Engineering department” adds nesting depth and no control. Nesting is also capped. AWS Organizations allows five levels of OUs under the root. Azure management groups allow six levels, not counting the tenant root group or the subscription level, and up to 10,000 management groups per directory. Google Cloud’s hierarchy is organization, folders and projects, and the folder nesting limit is documented separately in the resource manager quotas.

A workable default is three tiers under the root: platform, workloads and sandbox, with workloads split into production and non-production, and optionally a further split for regulated data. Azure’s published landing zone guidance uses the same instinct, placing workload subscriptions under a workload landing zones group and then in Online, Corp or Local child groups according to connectivity needs. AWS accounts and Google projects map onto the same idea.

The unit of isolation also differs. An AWS account is a hard identity, billing and quota boundary. An Azure subscription is a billing and quota boundary within a single Microsoft Entra tenant, and every subscription in a management group must trust the same tenant. A Google project is a lighter-weight container that shares the organization’s identity, and many teams use one project per workload per environment. These are not interchangeable, so avoid copying a topology from one cloud to another without re-deriving the blast radius.

Guardrails: four layers with four different failure behaviours

Think of guardrails as four layers. Preventive guardrails stop a request. Corrective guardrails change or repair the resource after the fact. Detective guardrails report. Proactive (pre-deployment) guardrails scan the infrastructure-as-code plan before anything is created. Control Tower’s own taxonomy mirrors this: preventive controls use SCPs, resource control policies (RCPs) and declarative policies from AWS Organizations, detective controls use AWS Config rules, and proactive controls use AWS CloudFormation hooks on resources provisioned through CloudFormation.

The reason to separate the layers is that each fails differently. A preventive guardrail fails closed and produces an access-denied error that developers find hard to diagnose. A detective guardrail fails open: the bad resource exists until someone acts. A proactive guardrail covers only the paths that go through your pipeline. A mature landing zone uses all four, and uses preventive guardrails sparingly for the few things that must never happen, because a preventive guardrail is the only layer that blocks a console click or a direct API call.

Shared services: log archive, security tooling, network hub, identity

Four shared services appear in every design. A log archive receives immutable copies of audit logs, and nobody except a tiny platform group can delete from it. A security tooling container runs detection and posture services with read access across the estate. A network hub terminates private connectivity, egress inspection and shared DNS. An identity provider, federated to the cloud, issues short-lived credentials. Control Tower creates the first two for you (log archive and audit accounts) when it builds a landing zone; the network hub and your enterprise identity federation remain your responsibility.

Keep these services in separate containers from each other. Merging log archive and security tooling feels efficient until a security operator needs to administer a tool and ends up with delete rights on evidence. Separation of duties is the point of having separate accounts, subscriptions or projects.

How the Three Clouds Compare

The vendors implement the five planes with different primitives. The table below maps them. Treat it as a translation guide, not a feature scorecard, because the primitives are not exact equivalents.

Plane	AWS	Azure	Google Cloud
Hierarchy	Organization, OUs, accounts	Tenant root group, management groups, subscriptions, resource groups	Organization, folders, projects
Managed bootstrap	AWS Control Tower landing zone	Azure landing zone accelerators (Bicep or Terraform)	Foundation blueprints in Terraform
Preventive policy	SCPs, RCPs, declarative policies	Azure Policy deny and denyAction	Organization policy constraints
Corrective policy	Config remediation, custom automation	Azure Policy modify, append, deployIfNotExists	Custom automation, Config Validator style checks
Detective policy	Config rules, Security Hub	Azure Policy audit, auditIfNotExists, Defender for Cloud	Security Command Center, dry-run policies
Account vending	Account Factory, Account Factory for Terraform	Subscription vending	Project factory modules
Network hub	Transit Gateway, Cloud WAN	Hub VNet or Virtual WAN	Shared VPC, Network Connectivity Center

Two differences deserve emphasis. First, only AWS has a clear separation between a policy that limits principals (SCPs) and one that limits resources (RCPs). Second, Google’s organization policy is the only one of the three that is purely about resource configuration and cannot be satisfied by granting a role.

Guardrail Semantics: Where Each Cloud Evaluates Policy

Guardrails do different jobs on each cloud because they are evaluated at different points. In AWS, an SCP sets a permission ceiling for principals and an RCP sets a permission ceiling for resources. In Azure, Azure Policy evaluates the Resource Manager request and the resource’s resulting properties. In Google Cloud, an organization policy constrains the configuration of a resource regardless of the caller’s IAM roles.

Figure 2: One create request traced through each cloud. AWS checks the SCP ceiling and the resource policy ceiling, Azure Policy runs modify and deny before audit, and Google evaluates organization policy alongside IAM.

AWS: SCP guardrails and resource control policies

An SCP never grants anything. It filters what an identity-based or resource-based policy is allowed to grant to principals in member accounts. The effective permission is the intersection of the SCPs on every level from the root down to the account, and the identity policy. That is why you must keep a baseline FullAWSAccess policy attached when you use deny-list SCPs, and why detaching it without a replacement allow-list locks everything out. SCPs do not affect the management account, which is a strong reason to keep workloads out of it entirely, and they do not restrict service-linked roles.

Resource control policies, introduced in late 2024, fill the other half. An RCP sets the maximum permissions on resources in member accounts, whoever the caller is, including callers from outside your organization. That makes RCPs the natural tool for a data perimeter, such as “S3 buckets, KMS keys and SQS queues in this organization may only be accessed by principals in this organization”. Official documentation and AWS announcements through 2026 list a widening set of supported services, including S3, STS, KMS, SQS, Secrets Manager, DynamoDB, Cognito and CloudWatch Logs. Coverage is explicit per service, so an RCP written for one service does not extend to a service added later. RCPs also do not apply to resources in the management account, and they do not govern service-linked roles. The supported list moves frequently; check it before relying on an RCP for a control objective.

The quotas shape how you organise policies. The AWS Organizations documentation gives these limits as of November 2026:

Quota	Value
SCP maximum size	10,240 characters
SCPs attached per root, OU or account	10
RCP maximum size	5,120 characters
RCPs attached per root, OU or account	5 (the automatically attached `RCPFullAWSAccess` counts)
SCPs per organization	10,000
RCPs per organization	2,000 (raised from 1,000 in July 2026)
OU nesting depth	5 levels

The attachment limit is the binding one. Because an RCP is capped at 5,120 characters and only five can attach to a target, and one of those slots is taken by the default, you effectively have four custom RCPs and roughly 20 KB of policy text per target. The practical design is thematic policies, such as one for identity perimeter, one for network perimeter and one for encryption, rather than one policy per service. Our deeper look at the evaluation algorithm is in the AWS IAM policy evaluation logic post.

Azure: management groups and Azure Policy effects

Azure Policy attaches at a management group, subscription or resource group, and assignments inherit downward. Policy definitions are grouped into initiatives, which are the unit you assign. The effect determines behaviour. Microsoft’s documentation lists eleven effects, among them deny, audit, modify, append, deployIfNotExists, auditIfNotExists, denyAction, manual and disabled. For a create or update request, evaluation proceeds in this order: disabled first, then append and modify (because they can change the request), then deny, then audit, then manual, then auditIfNotExists, with denyAction last. deny is evaluated before audit so an unwanted resource is not logged twice. After the resource provider returns success, auditIfNotExists and deployIfNotExists evaluate whether companion resources exist.

This ordering has a practical consequence. A modify policy that adds a required tag will make a deny policy on missing tags pass, so you can pair them: modify to fix, deny as the backstop when the modification cannot be applied. Azure also uniquely lets a policy deploy things. A deployIfNotExists assignment can enable diagnostic settings on every new resource, which is how the landing zone reference implementations make logging automatic. The price is a managed identity with deployment permissions per assignment, and remediation tasks for resources that existed before the assignment.

Management group assignments at the tenant root group apply to every resource in the directory, so Microsoft’s guidance is that only “must have” policies and role assignments belong there. Azure Resource Manager caches the hierarchy for up to 30 minutes, so a subscription move is not instantly reflected in policy evaluation or the portal.

Google Cloud: organization policy constraints

An organization policy applies to the organization, a folder or a project, and descendants inherit it by default. Constraints come in boolean and list forms, and list values accept prefixes such as is:, under: and in: to match a single resource, a resource and its children, or everything containing a value. Google distinguishes managed constraints, which are the newer parameterised type that supports simulation through Policy Intelligence, legacy managed constraints (formerly called predefined), and custom constraints that you define yourself. A subtle point from the documentation: legacy constraints merge according to hierarchy evaluation rules, whereas managed constraints do not merge. A child either enforces the parent’s managed policy or replaces it entirely, so an override is a complete restatement, not a delta.

Three features make organization policy the most operationally gentle of the three. Dry-run mode enforces a policy for auditing: violations are logged but nothing is blocked. Tag-conditional policies let you enforce a constraint only on resources carrying a particular tag. And new policies are generally not applied retroactively, so a restrictive policy marks existing resources as violating but does not break them. That last point is a trap as well as a convenience, because it means a clean deploy proves nothing about the pre-existing estate.

Comparison matrix: which layer solves which problem

Requirement	AWS	Azure	Google Cloud
Deny unapproved regions	SCP with region condition	Azure Policy deny on allowed locations	Resource locations constraint
Block public storage	SCP, RCP or declarative policy	Policy deny on public network access	Public access prevention constraint
Org-only data access	RCP data perimeter	Private endpoints plus policy	VPC Service Controls (a separate product)
Auto-enable logging	Control Tower, Config remediation	deployIfNotExists	Aggregated log sinks via IaC
Preview impact before enforcing	Test in a non-production OU, Access Analyzer for SCP-related reviews	audit effect or enforcement mode DoNotEnforce	Dry-run mode and Policy Intelligence simulation
Require tags at creation	Tag policies, SCP on `aws:RequestTag`	modify or append plus deny	Tag-conditional policies, custom constraints

The service names in the second row of Azure and Google are examples of mechanism, not an exhaustive list of constraints. Always confirm that a specific constraint or built-in policy definition exists for the service you need.

Delivering the Landing Zone as Code

Guardrails written in a console are guardrails nobody reviews. Every landing zone should be defined in version control, applied by a pipeline with its own narrow identity, and reconciled continuously. The three snippets below each implement the same objective, restricting resource locations, in the native mechanism of one cloud. They are minimal illustrations: the region lists and resource names are placeholders, and you should test them in a non-production branch of your hierarchy before attaching anywhere high.

AWS: a region-deny SCP and an identity-perimeter RCP in Terraform

variable "allowed_regions" {
  type    = list(string)
  default = ["eu-west-1", "eu-central-1"]
}

variable "org_id" { type = string } # e.g. o-xxxxxxxxxx
variable "target_ou_id" { type = string }

resource "aws_organizations_policy" "region_deny" {
  name = "deny-unapproved-regions"
  type = "SERVICE_CONTROL_POLICY"
  content = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Sid      = "DenyOutsideApprovedRegions"
      Effect   = "Deny"
      # Global services are exempted via NotAction. Extend this list
      # for the global services your estate uses.
      NotAction = ["iam:*", "organizations:*", "route53:*", "cloudfront:*",
                   "support:*", "budgets:*", "sts:*"]
      Resource = "*"
      Condition = {
        StringNotEquals = { "aws:RequestedRegion" = var.allowed_regions }
        ArnNotLike = {
          "aws:PrincipalARN" = ["arn:aws:iam::*:role/PlatformBreakGlass"]
        }
      }
    }]
  })
}

resource "aws_organizations_policy_attachment" "region_deny" {
  policy_id = aws_organizations_policy.region_deny.id
  target_id = var.target_ou_id
}

resource "aws_organizations_policy" "identity_perimeter" {
  name = "rcp-identity-perimeter"
  type = "RESOURCE_CONTROL_POLICY"
  content = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Sid       = "OrgIdentitiesOnly"
      Effect    = "Deny"
      Principal = "*"
      Action    = ["s3:*", "sqs:*", "kms:*", "secretsmanager:*"]
      Resource  = "*"
      Condition = {
        StringNotEqualsIfExists = { "aws:PrincipalOrgID" = var.org_id }
        BoolIfExists            = { "aws:PrincipalIsAWSService" = "false" }
      }
    }]
  })
}

Two cautions. The RCP above would block legitimate third-party vendor access to your buckets, so a real data perimeter needs an exception list of trusted external account IDs, and AWS’s published data-perimeter guidance is the place to take the exact condition patterns from. And SCPs and RCPs must be enabled as policy types on the organization root first, which Control Tower-managed organizations typically already have for SCPs.

Azure: an allowed-locations assignment at a management group

data "azurerm_management_group" "workloads" {
  name = "alz-workloads"
}

data "azurerm_policy_definition" "allowed_locations" {
  # Built-in definition, display name as published by Microsoft.
  display_name = "Allowed locations"
}

resource "azurerm_management_group_policy_assignment" "allowed_locations" {
  name                 = "allowed-locations"
  management_group_id  = data.azurerm_management_group.workloads.id
  policy_definition_id = data.azurerm_policy_definition.allowed_locations.id
  display_name         = "Restrict workload regions"
  enforce              = true   # set false for DoNotEnforce rollout

  parameters = jsonencode({
    listOfAllowedLocations = { value = ["westeurope", "northeurope"] }
  })
}

The enforce = false switch maps to the assignment’s enforcement mode DoNotEnforce, which evaluates and reports compliance without blocking requests. Use it for the first week of every new assignment.

Google Cloud: a managed org policy with dry-run in Terraform

variable "org_id" { type = string }

resource "google_org_policy_policy" "resource_locations" {
  name   = "organizations/${var.org_id}/policies/gcp.resourceLocations"
  parent = "organizations/${var.org_id}"

  # Start in dry run: log violations, block nothing.
  dry_run_spec {
    rules {
      values {
        allowed_values = ["in:eu-locations"]
      }
    }
  }
}

Once the audit logs show no unexpected violations over a full business cycle, add a spec block with the same rule to move from dry run to enforcement. Remember that the policy is not retroactive: pre-existing resources outside the allowed locations stay where they are and need a separate remediation list.

Account, subscription and project vending

Vending is the process by which a new workload container is created, placed in the right branch, wired to the network hub, enrolled in logging, given baseline budgets and handed to a team. It is the single highest-leverage automation in a landing zone, because it converts the landing zone from a design document into a product. AWS offers Control Tower Account Factory, which is built on AWS Service Catalog provisioned products, and a Terraform variant. Microsoft names subscription vending as a design area and recommends automating it as request volume grows. On Google Cloud, a project factory Terraform module plays the same role.

Figure 3: A vending request flows through review, a plan with policy checks, an apply by a narrowly scoped pipeline identity, and enrolment into logging, networking and budgets, followed by continuous drift detection.

A good vending request is a small declarative file: owner, environment tier, cost centre, data classification and network needs. The pipeline validates it, runs policy-as-code checks against the plan, creates the container in the correct branch, and returns a pull request that adds the workload’s own repository and identity. For the state, locking and drift mechanics of the pipeline itself, see our post on Terraform state management, drift detection and plan/apply pipelines, and for tool choice the comparison of Terragrunt, OpenTofu and Terraform Stacks.

Network and Telemetry Topology

Networking is where landing zones most often diverge from their diagrams, because teams under deadline add peering links that bypass the hub. The topology that scales is hub and spoke: workload networks connect to a hub that owns egress, inspection, shared DNS and private connectivity to on-premises sites. On AWS the hub is usually a Transit Gateway or Cloud WAN core network in a dedicated network account. On Azure it is a hub virtual network or a Virtual WAN hub in the connectivity subscription. On Google Cloud a Shared VPC host project or Network Connectivity Center plays the role. Which is best depends on your scale and on how much routing control you want to retain, and each product has its own quotas that you should read before committing.

Figure 4: Workload spokes reach the internet and on-premises sites only through the hub, while audit and flow logs from every container stream to a write-once log archive owned by a separate team.

The guardrail that protects this topology is the one that stops teams from building their own: deny creation of internet gateways, public IP addresses and peering connections in workload branches, except via the approved path. On AWS that is an SCP, on Azure a deny policy on public IP and peering resources, and on Google Cloud organization policy constraints such as those that restrict external IPs and shared VPC usage. Name the allowed exceptions explicitly in the policy so that the exception is itself reviewable.

Telemetry follows a similar rule: everything is written to a place the workload team cannot alter. Control Tower sets up an organization trail and a log archive account for this. In Azure, diagnostic settings are enabled by deployIfNotExists policies and sent to a central Log Analytics workspace or storage account. In Google Cloud, an aggregated log sink at the organization or folder routes audit logs to a protected destination. Three habits matter more than product choice. Retain audit logs for at least as long as your regulator requires. Alert on changes to the logging configuration itself. And practise retrieving evidence from the archive before an incident forces you to.

Cost visibility is part of the same plane. A hierarchy that mirrors policy boundaries rarely mirrors cost boundaries, so tag or label at vending time and normalise billing data across clouds. See our posts on the FOCUS specification and cloud billing normalisation and cloud cost anomaly detection. The Kubernetes layer inside each spoke has its own guardrails, and the same layering logic applies; our posts on ValidatingAdmissionPolicy with CEL and default-deny network policy and microsegmentation cover that tier. Data-layer design, such as multi-region active-active databases, also constrains the region guardrails you can safely set.

Trade-offs, Gotchas and What Goes Wrong

The most common failure is the unowned exception. A team needs a region outside the allow-list, a platform engineer adds a condition to the SCP for their role, and the exception is never removed. After a year the policy is a maze of principal ARNs. Give every exception an owner, a reason and an expiry date in the policy-as-code repository, and fail the pipeline when an expiry passes.

The second is policy that cannot be tested where it fails. A deny that works in a sandbox may break a service-linked workflow in production because the SCP does not govern service-linked roles but your own automation role might be caught. Roll out in rings: a canary OU or management group first, then non-production, then production, with a documented rollback that anyone on call can execute. On Azure use enforcement mode DoNotEnforce, on Google use dry-run, and on AWS rely on a canary OU because there is no native audit mode for SCPs.

Third, quota exhaustion by design. With five RCPs per target, one of which is the default, and 5,120 characters each, a long list of exceptions will overflow a policy. Use condition keys and tags rather than enumerating ARNs, and keep exception lists short. On Azure, assignments at the tenant root apply to everything, so a mistaken deny there is a tenant-wide outage with a 30-minute hierarchy cache delaying visible recovery.

Fourth, false confidence from detective controls. A dashboard of “compliant” resources proves only that evaluation ran. Config rules, Azure audit effects and Security Command Center findings cover a defined set of resource types, and new services are often unsupported for months. Pair detective coverage with a periodic inventory of resource types in use that have no control.

Fifth, the management account problem. SCPs and RCPs do not apply to the AWS management account’s own resources, so anything you place there is outside your guardrails. Keep the management account, the Azure tenant root assignments and the Google organization administrator group to a minimum, protect them with the strongest authentication, and run nothing there.

Finally, drift between the landing zone and its baseline. Control Tower flags drift when someone alters managed resources, and updating a landing zone version can require re-registering OUs. Azure accelerators and Google blueprints drift when subscriptions or projects are changed outside the pipeline. Schedule a plan-only run daily and treat a non-empty plan as a ticket.

Practical Recommendations

Start by deciding the policy at each layer, not the tool. Write down, on one page, the five to ten things that must never happen in your estate (public data stores, disabling audit logs, unapproved regions, root credentials in use, deleting the log archive) and assign each to a preventive guardrail. Everything else goes to the corrective, detective or proactive layers.

Adopt the vendor bootstrap for the plane it covers well, and be explicit about what it leaves out. Control Tower gives AWS a fast path for hierarchy, identity and logging. The Azure accelerators give a complete platform landing zone including connectivity. On Google Cloud, start from a foundation blueprint rather than a blank folder. Then wrap your own policies, vending and network additions around that baseline as code.

Treat the landing zone as a product with a backlog, an on-call rotation and a changelog. Version it, tag releases and communicate policy changes to workload teams before they take effect. Prefer fewer, themed policies over many narrow ones, and prefer tags and conditions over lists of identifiers.

A launch checklist:

Define the hierarchy only where policy or administration differs, and stay below the nesting limits.
Keep the management account, tenant root and organization administrator group free of workloads.
Separate log archive, security tooling, network hub and identity into distinct containers with distinct owners.
Write every guardrail as code, with an owner, rationale and expiry for each exception.
Roll out each guardrail through a canary, then non-production, then production, using audit or dry-run modes where they exist.
Automate vending, including logging enrolment, network attachment, budgets and baseline tags.
Run a daily plan-only drift check and a quarterly break-glass and log-retrieval exercise.
Re-verify vendor quotas and supported-service lists every quarter.

Frequently Asked Questions

What is a cloud landing zone?

A cloud landing zone is a pre-configured, governed environment into which workloads are deployed. It combines a hierarchy of accounts, subscriptions or projects, identity federation, preventive and detective guardrails, a network hub, and centralised logging. AWS Control Tower, Azure landing zone accelerators and Google Cloud foundation blueprints each automate part of it. The aim is that a new workload inherits security, networking and audit settings on day one instead of building them by hand.

Do I need AWS Control Tower, or can I use Organizations directly?

You can use AWS Organizations directly, and Control Tower itself lets you work in Organizations, including SCPs and RCPs, and register existing organizations and accounts. Control Tower adds managed log archive and audit accounts, Account Factory, a controls catalogue and a dashboard. Teams with strong platform engineering sometimes prefer pure Organizations plus Terraform for flexibility. Teams that want a supported baseline quickly usually start with Control Tower and extend it.

How do SCPs differ from IAM policies?

An IAM policy grants permissions to a principal. An SCP grants nothing; it defines the maximum permissions that principals in member accounts can ever receive. The effective permission is the intersection of every applicable SCP and the identity or resource policy that allows the action. SCPs also do not apply to the management account or to service-linked roles. Use SCPs for organisation-wide must-never-happen rules, and IAM policies for day-to-day least privilege.

What is the difference between SCPs and resource control policies?

SCPs limit what principals in your accounts can do. Resource control policies limit what can be done to resources in your accounts, regardless of who the caller is, including callers outside your organization. RCPs therefore suit data-perimeter rules such as organisation-only access to storage and keys. They cover a defined list of services, are limited to five per target including the default, and do not apply to management account resources.

How does Azure Policy compare to Google Cloud organization policy?

Azure Policy evaluates requests and resource properties and can deny, audit, modify, append or deploy related resources. Google Cloud organization policy constrains resource configuration and offers boolean, list and custom constraints, plus dry-run mode. Azure can remediate automatically through deployIfNotExists; Google mostly blocks or audits and leaves remediation to automation. Both inherit down their hierarchies, but Google’s managed constraints replace rather than merge at lower levels.

How many accounts, subscriptions or projects should we start with?

Start with the minimum that gives you separation of duties: a management or organization root, a log archive, a security tooling container, a network hub, and one production and one non-production container per workload. Add sandbox containers with budget limits. Resist creating containers for every team before the vending automation exists, because manual creation is where inconsistent baselines begin. Re-check each cloud’s account and project quotas before planning a large rollout.

Comments

Leave a Reply Cancel reply

Tag Cloud

Categories