Cloud Landing Zones by Traffic Flow: AWS Azure GCP 2026

Q: What is a cloud landing zone, in one sentence?

A cloud landing zone is a pre-configured, governed environment — networking, identity, security controls, and policy guardrails — that workloads land into so every deployment inherits the same isolation, inspection, and compliance posture by default. It is the foundation laid before the first application rather than retrofitted after, and it is owned centrally so individual teams cannot drift from the baseline. Designing it by traffic flow means the perimeter, segmentation, egress, and inspection controls are decided per flow class (ingress, egress, east-west, hybrid, management) rather than per cloud service, which is what makes the same architecture portable across AWS, Azure, and GCP.

Q: Why design a landing zone by traffic flow instead of by service?

Because the service names diverge across clouds but the thing being secured — a packet moving from somewhere to somewhere — does not. There are only five canonical flow classes in any enterprise cloud: North-South ingress, North-South egress, East-West (spoke-to-spoke), hybrid (cloud-to-datacentre), and the management plane. Each carries a distinct threat model and a distinct first-line control. Organising the design around those five flows rather than around a specific firewall product makes the architecture portable: you build against the function (a forced-tunnel egress firewall with an FQDN allow-list) and then bind it to AWS Network Firewall, Azure Firewall, or GCP Cloud NGFW. It also makes the design auditable, because every control maps to a named flow obligation rather than a vendor feature.

Q: What does DMZ-first, defence-in-depth mean for a cloud network?

DMZ-first means the topology is built outward from a controlled inspection boundary rather than inward from the workloads: every flow that crosses a trust boundary is forced through a dedicated inspection zone — the cloud descendant of the on-prem DMZ — before it reaches anything that matters. In practice this is hub-and-spoke, where a central hub owns the firewall, DMZ subnets, DNS, egress, and hybrid termination, and each workload spoke has no direct internet path and no direct peering to siblings. Defence-in-depth means no single control is load-bearing: an attacker who defeats the edge WAF still meets a perimeter firewall, then east-west segmentation, then workload identity, then data-layer encryption and access policy. Defeating one layer buys nothing on its own.

Q: How do AWS, Azure, and GCP map for landing-zone networking?

Each landing-zone construct is defined by its function and has a native equivalent in all three clouds. Hub-spoke connectivity is AWS Transit Gateway, Azure Virtual WAN / VNet peering, or GCP Network Connectivity Center / Shared VPC. The central L3-L7 firewall is AWS Network Firewall + Gateway Load Balancer, Azure Firewall Premium, or GCP Cloud NGFW. Micro-segmentation is Security Groups + NACLs, NSGs + Application Security Groups, or VPC firewall rules + network tags. Private service access is PrivateLink, Private Endpoint, or Private Service Connect. Edge protection is WAF + Shield + CloudFront, Front Door + WAF + DDoS Protection, or Cloud Armor + Cloud CDN. Build the architecture against the function column and it ships on any cloud, or all three, without redesign.

Q: Why is egress control more important than most teams assume?

Because egress is where data exfiltration and command-and-control callbacks happen, and it is the flow teams most often leave open. A landing zone that inspects ingress with a WAF but leaves an open 0.0.0.0/0 route outbound has secured the front door and left the back door wide. The control is a forced-tunnel egress firewall with an FQDN allow-list: all outbound traffic is routed through the hub firewall (via a User-Defined Route in Azure, a VPC route to a Network Firewall endpoint in AWS, or Cloud NAT + Secure Web Proxy in GCP), and only explicitly allowed destinations are permitted. This is the single most effective control against exfiltration in all three clouds, and it is also where cost discipline matters because per-GB inspection charges dominate at scale.

Q: How much does inspected egress cost across the three clouds?

For a mid-size estate pushing roughly 10 TB/month of inspected egress (US list prices, accessed 2026): AWS Network Firewall is about $0.395/endpoint-hour (~$285/month per AZ) plus ~$0.065/GB processed, landing near $1,236/month before NAT Gateway data-processing. Azure Firewall Premium is about $1.277/deployment-hour (~$932/month) plus ~$0.016/GB, near $1,096/month with TLS inspection and IDPS included. GCP Cloud NGFW Enterprise lands in a comparable ~$900–$1,300/month band. The bands overlap, so the architectural lesson is not which firewall is cheapest — it is that per-GB inspection cost dominates, so the high-leverage decision is what you route through inspection. Sending backup or intra-region storage traffic through the L7 firewall is the most common way teams triple the bill for no security gain.

Q: When should I use hub-spoke versus a transit mesh?

Use a single inspected VPC/VNet with tiered subnets when you have fewer than a handful of workloads and one team — it is simplest, but it outgrows segmentation quickly. Use classic hub-spoke with a central firewall in the hub for most enterprises with low east-west traffic; the watch-out is that the hub firewall can become a chokepoint if you route everything through it. Add per-spoke micro-segmentation on top of hub-spoke for regulated estates with moderate east-west traffic, automating the rules so they do not sprawl. Move to a transit mesh — AWS Transit Gateway, Azure Virtual WAN, or GCP Network Connectivity Center with a dedicated inspection VPC — only when you have many VPCs, multiple regions, and high east-west volume that needs transitive routing. Cost and route complexity scale up with the mesh, so do not reach for it before the traffic justifies it.

Q: Can one landing-zone design satisfy AU, EU, UK, SG, IN, CN, HK, and US compliance?

Largely yes — the same DMZ-first controls (segmentation, forced egress, hardened just-in-time admin, centralised immutable logging, least privilege) satisfy the technical core of Essential Eight (AU), NIS2 and GDPR (EU), the NCSC Cloud Security Principles (UK), MAS TRM (SG), DPDP and CERT-In directives (IN), MLPS 2.0 and PIPL (CN), the PDPO (HK), and FedRAMP / NIST 800-53 (US). The work is two-fold: map each control to the local framework's language, and pin data residency to the correct region. The portability comes from encoding controls as preventive policy guardrails (Service Control Policies, Azure Policy, Organization Policy) that reject non-compliant deployments at creation, and from landing regulated workloads in spokes whose region is fixed by policy while the connectivity hub can remain global.

Q: What are the most common landing-zone anti-patterns?

The recurring failures are: a flat network with no spokes (one compromised host reaches everything); inspecting ingress but not egress (exfiltration walks straight out); public management ports (the most-scanned attack surface); an un-sized hub firewall used as a chokepoint for all traffic including backups (saturation plus a tripled bill); spoke-to-spoke peering shortcuts that bypass central inspection; a click-ops landing zone built by hand that drifts and cannot be reproduced; transitive flat trust extended from on-prem so ransomware gains a cloud blast radius; and relying on detective review instead of preventive policy guardrails. Each has a direct fix — segment, force egress, use a bastion, inspect only boundary-crossing traffic, route inter-spoke through the hub, build as code, terminate hybrid in the hub, and enforce guardrails at creation.

Q: In what order should I mature a landing zone?

Follow a five-stage ladder, bottom-up. Stage 0 (flat): a single VPC/VNet, public IPs, manual changes — the first incident is estate-wide. Stage 1 (segmented): hub-and-spoke, a central firewall, DMZ ingress termination, private workload subnets — ingress is inspected. Stage 2 (egress-controlled): forced-tunnel egress with FQDN allow-lists, private service access so traffic to cloud services never touches the internet, and east-west default-deny. Stage 3 (governed): the whole zone is infrastructure-as-code, policy guardrails reject non-compliant deployments at creation, logging streams to an immutable store, and just-in-time admin replaces standing access. Stage 4 (multi-cloud and tested): the same traffic-flow architecture is expressed identically on AWS, Azure, and GCP via the service-mapping table, residency is pinned per region, and the design is exercised with red-team egress and segmentation-bypass drills rather than assumed.

Satyam Kumar

Retour au blog

multi-cloud-infrastructure

Designing Cloud Landing Zones by Traffic Flow — A Defence-in-Depth, DMZ-First Architecture for AWS, Azure, and GCP (2026)

By Satyam KumarJune 11, 202615 min read

cloud-landing-zone hub-and-spoke-network defence-in-depth dmz-architecture multi-cloud-networking aws-network-firewall azure-firewall gcp-cloud-ngfw network-segmentation egress-control zero-trust-network transit-gateway cloud-adoption-framework landing-zone-accelerator cloud-security-architecture data-residency micro-segmentation finops-egress

Designing Cloud Landing Zones by Traffic Flow — A Defence-in-Depth, DMZ-First Architecture for AWS, Azure, and GCP (2026)

Frequently Asked Questions

Partager l'article

Twitter LinkedIn WhatsApp

Satyam Kumar

Founder & AI Architect, AppScale LLP

Architecte AI & Cloud. J'aide les équipes à construire des systèmes qui scalent pour des millions.

LinkedIn GitHub

Designing Cloud Landing Zones by Traffic Flow — A Defence-in-Depth, DMZ-First Architecture for AWS, Azure, and GCP (2026)

Frequently Asked Questions

Partager l'article

Comments

Leave a comment