A familiar conversation: a client builds a successful workload on AWS and wins a new business line that requires Azure. Or runs Azure primarily because the Microsoft 365 footprint pulled them there, then acquires a SaaS company built on Google Cloud. Suddenly the question is whether to mirror the existing landing zone design on the new cloud, or rebuild from each cloud’s idioms.

Our answer in every case has been the same. Don’t mirror. Each of these clouds has a hierarchical model, a security baseline, and a guardrails philosophy that reflects how its product teams think. Forcing AWS to look like Azure or Azure to look like Google Cloud usually produces something that works against the platform’s strengths.

What follows is the comparison we actually use in Stage 1 cloud security reviews. Seven dimensions. AWS, Azure, and Google Cloud side by side. What each delivers out of the box, where it requires bespoke engineering, and which one we’d pick in a given scenario.

Why the Landing Zone Is the Decision Underneath Every Cloud Security Conversation

Before you can argue about CSPM tooling, detection content, or DevSecOps gates, you have to decide what your cloud looks like at the foundation. The landing zone is the multi-account or multi-subscription structure that everything you build will land in. It sets the identity model, the network segmentation pattern, the guardrails, the audit-log routing, and the encryption posture before any workload is deployed.

In our experience, organizations that skip serious landing zone work in year one spend year two paying for it. Cloud sprawl is harder to retrofit than to engineer up front. The post-mortems on cloud breaches we read consistently trace back to gaps that should have been closed at the landing zone layer: an overly permissive IAM role, an unmonitored account in another region, a network path that bypassed central egress.

The good news is that all three major clouds now ship landing zone frameworks. The less good news is that they’re not interchangeable, and the choice of which one to build on (or which one to add a second cloud to) deserves more attention than it usually gets.

The Seven Dimensions We Score

Dimension 1: Account / subscription hierarchy

AWS: Organizations + Organizational Units (OUs) + member accounts. AWS Control Tower automates baseline provisioning with Account Factory. Strong account-level isolation; tax on cross-account workflows is real.

Azure: Tenant + Management Groups + Subscriptions + Resource Groups. Enterprise-Scale (the canonical reference) hierarchy is opinionated and consistent. Subscription vending is a first-class concept.

Google Cloud: Organization + Folders + Projects. The cleanest hierarchical model of the three. Folders are infinitely nestable, projects are the unit of resource ownership, and the boundary semantics are clearer than AWS accounts or Azure subscriptions.

What we’d actually pick: Google Cloud has the cleanest hierarchy for greenfield. AWS wins where you need hard account-level isolation (regulated workloads, mergers). Azure wins where Enterprise-Scale’s prescription is an advantage.

Dimension 2: Identity foundation

AWS: AWS IAM Identity Center (formerly SSO) federated to your IdP (Entra ID or Okta). IAM roles for cross-account access. SCPs at the OU level for guardrails.

Azure: Entra ID native to the platform. Azure RBAC at management-group, subscription, resource-group, and resource levels. Privileged Identity Management for JIT elevation.

Google Cloud: Cloud Identity or Workforce Identity Federation. IAM allow-policies at the org, folder, project, and resource levels. Conditional bindings for context-aware access.

What we’d actually pick: Azure wins outright if Entra ID is already your enterprise identity plane. AWS is comparable when paired with IAM Identity Center and a federated IdP. Google Cloud’s IAM model is technically clean but requires more discipline to operationalize at scale.

Dimension 3: Network segmentation

AWS: VPCs with Transit Gateway for hub-and-spoke. Central egress through a security VPC. Network Firewall as the inspection layer. PrivateLink for service exposure.

Azure: VNets with Virtual WAN or hub-spoke topology. Azure Firewall and Firewall Manager as inspection. Private Endpoints. Network Manager for centralized governance.

Google Cloud: Shared VPC with VPC Service Controls as the strong differentiator. Service Controls let you draw a perimeter around resources that no IAM permission can bypass. The closest thing to a real data-exfiltration boundary on any of the three.

What we’d actually pick: Google Cloud wins on data-exfiltration prevention if VPC Service Controls fit your architecture. AWS and Azure are roughly even on hub-spoke transit; Azure has the smoother Network Manager experience, AWS has the deeper third-party ecosystem (Palo Alto, Aviatrix, Cisco).

Complete a 2-Minute Cybersecurity Assessment to Identify Security Gaps.

Dimension 4: Guardrails (policy-as-code at the platform layer)

AWS: Service Control Policies (SCPs) at the OU level. AWS Config Rules for resource-state evaluation. AWS Control Tower for guardrail packaging.

Azure: Azure Policy with built-in and custom definitions. Initiatives bundle policies for common compliance frames (PCI, HIPAA, NIST). Defender for Cloud surfaces non-compliance in one view.

Google Cloud: Organization Policies as the primary guardrail. Less granular than Azure Policy today, but the rules are simpler and the failure modes are clearer.

What we’d actually pick: Azure has the deepest out-of-the-box guardrail library. AWS has the most-engineered guardrail pattern for organizations that prefer SCP-driven prevention over Config-driven detection. Google Cloud sits behind on guardrail surface area but has the simplest semantics.

Dimension 5: Audit logging and detection telemetry

AWS: CloudTrail (control plane) plus CloudWatch Logs and VPC Flow Logs (data plane). GuardDuty as the threat-detection layer. Security Hub for aggregation.

Azure: Activity Log plus diagnostic settings per resource type. Defender for Cloud + Microsoft Sentinel for detection. Tight integration with Microsoft’s broader telemetry ecosystem.

Google Cloud: Cloud Audit Logs (Admin Activity, Data Access, System Event) plus VPC Flow Logs. Security Command Center as the aggregator. Chronicle for SIEM.

What we’d actually pick: All three have matured. Azure has the smoothest path if you’re committing to Microsoft Sentinel as your SIEM. AWS has the deepest third-party SIEM ecosystem. Google Cloud’s audit logging is the most granular by default but data-access logging gets expensive fast at volume.

Dimension 6: Encryption and key management

AWS: KMS with customer-managed keys (CMK). Granular grants. CloudHSM for FIPS 140-2 Level 3. BYOK well supported. Strong, but configuration is per-service and per-region.

Azure: Key Vault as the central store. Managed HSM for FIPS 140-2 Level 3. Customer-managed keys are well supported but rotation discipline is operationally heavier than AWS or GCP.

Google Cloud: Cloud KMS as the central store. Cloud HSM for hardware-backed keys. Default encryption is broader at rest than AWS (every storage class encrypted by default with Google-managed keys; customer-managed is the upgrade).

What we’d actually pick: All three are comparable in capability. Google Cloud’s encryption defaults are the most-secure-out-of-the-box. AWS has the deepest tuning surface. Azure is the easiest if Key Vault is already integrated with the rest of your Azure operations.

Dimension 7: Cost and operational governance

AWS: AWS Organizations consolidated billing. Cost Explorer + Budgets. Compute Optimizer for rightsizing. Reserved Instances + Savings Plans for commitment discounts.

Azure: Cost Management + Billing scopes. Azure Advisor recommendations. Reservations + Savings Plans. EA / MCA contract structure changes the picture meaningfully for large estates.

Google Cloud: Billing accounts (separate from organization hierarchy). Budgets and forecasts. Committed Use Discounts. The cost data plane is the cleanest of the three; the operational tooling is the most basic.

What we’d actually pick: Azure typically has the best contractual cost optimization for enterprises (EA / MCA discounts), AWS the deepest cost-engineering ecosystem. Google Cloud is the easiest to read the bill on but the hardest to actively optimize without third-party tools.

How This Plays Out in Practice

A manufacturing client running primarily on Azure decided to add AWS for an acquired analytics SaaS product. The first reflex was to replicate their CAF Enterprise-Scale design on AWS by mapping management groups to OUs one-to-one. Six months later, the cross-account IAM model was a mess, Service Control Policies kept fighting the prescriptive setup, and the engineering team was burning sprints retrofitting things AWS does naturally with looser hierarchy and tighter account boundaries.

We rebuilt the AWS landing zone from AWS’s own primitives. Three OUs (Workloads, Sandbox, Shared Services). Two SCP packs (production-restrictive and dev-permissive). Identity Center federated to the existing Entra ID tenant. Six weeks instead of six months. The takeaway we’ve used in every cloud review since: respect each cloud’s defaults. Mirroring across clouds is appealing intellectually and expensive in practice.

If You’re Designing a Landing Zone in 2026

Three guardrails we’d apply to any client decision today, regardless of cloud. First, lean into the idioms. Second, treat identity, network segmentation, and audit logging as non-negotiable on day one; everything else can iterate. Third, plan for the second cloud you’ll add even if you don’t have one yet. The cost of designing a landing zone that’s not multi-cloud-aware shows up the day you acquire a company on a different cloud.

Our cloud security practice engineers landing zones across all three platforms, with the operating-model design that sits underneath the architecture. Programs map to NIST 800-53 Rev. 5, CIS Benchmarks per cloud, and the framework you’re audited against (SOC 2 Compliance, HIPAA Compliance, GDPR Compliance, PCI DSS Compliance). Detection and 24×7 operations are co-delivered with established SOC partners; the landing zone work itself is in-house.

For the full cloud security practice and the eight-pillar program that builds on top of the landing zone, see our Cloud Security Services page. For the identity layer that underpins every landing zone decision, see our Identity and Access Management Services page.