The three big clouds, Amazon Web Services (AWS), Microsoft Azure and Google Cloud, solve the same problems with different names and a few real differences. This page maps their networks, security rules, load balancers, private access, identity and hybrid links side by side, and shows how a packet really moves through each one.
All three clouds group data centres into regions, and split each region into zones with separate power, cooling and networking. The biggest difference is scope. An AWS VPC (virtual private cloud) and an Azure VNet (virtual network) live in one region, while a Google Cloud VPC is global. That one fact changes how I design addressing, routing and resilience on each platform.
Swipe sideways to see the whole diagram.
AWS. A VPC belongs to one region, and every subnet sits in exactly one Availability Zone. For resilience I create a subnet in each of three zones for every tier, and spread instances and load balancer nodes across them. Another region needs its own VPC, joined by peering or a Transit Gateway.
Azure. A VNet belongs to one region, but its subnets are not tied to a zone. Zone resilience comes from placing each virtual machine (VM), disk and zone redundant service in a zone, not from the subnet. Not every Azure region has availability zones, so I check before I promise zone resilience.
Google Cloud. A VPC network is global and subnets are regional. Instances in different regions on the same VPC reach each other on internal addresses with no peering, which makes multi region designs simpler. The flip side is that one VPC's routes and firewall rules now reach across the world, so I control them centrally.
| Item | AWS | Azure | Google Cloud |
|---|---|---|---|
| Top of the hierarchy | Organization, with organisational units | Microsoft Entra tenant, with management groups | Organization, with folders |
| Unit of isolation and billing | Account | Subscription, holding resource groups | Project |
| Private network scope | VPC, one region | VNet, one region | VPC network, global |
| Subnet scope | One Availability Zone | The region, across zones | The region, across zones |
| Smallest subnet | /28 | /29 | /29 |
| Addresses kept by the provider | 5 per subnet: network, router, DNS (Domain Name System), one reserved, broadcast | 5 per subnet: network, gateway, two for DNS, broadcast | 4 per primary range: network, gateway, second to last, broadcast |
Every VPC and VNet takes address space from one plan that covers on premises and all three clouds. Overlapping ranges are the most expensive mistake to undo, as anyone who has merged two companies knows. Subnetting is on the Internet Protocol (IP) addressing page.
A zone can fail. I place every production tier in at least two zones, and three where the service supports it, and test that the load balancer really drains a failed zone.
Accounts, subscriptions and projects are created by a landing zone with guardrails already applied. That design is on the cloud architecture page.
Once you know which service does which job, moving between clouds gets much easier. Filter the map by job, then step through one application built three times.
| Job | AWS | Azure | Google Cloud |
|---|---|---|---|
| Private network | Amazon VPC | Virtual Network (VNet) | VPC network |
| Routing | Route tables on subnets | System routes plus route tables (user defined routes) | Routes on the VPC, scoped by priority and network tags |
| Shared network across teams | VPC sharing through AWS Resource Access Manager | A hub VNet that spokes peer with | Shared VPC from a host project |
| Route to the internet | Internet gateway | Built in, with no gateway object | Default internet gateway route |
| Outbound NAT (network address translation) | NAT gateway, zonal or regional | NAT Gateway on the subnet | Cloud NAT |
| Fixed public address | Elastic IP address | Standard public IP address | Static external IP address |
| Filter at the instance | Security group: stateful, allow rules only | Network security group (NSG) on the NIC (network interface card): stateful, allow and deny | VPC firewall rules and policies: stateful, aimed by tag or service account |
| Filter at the subnet | Network ACL (access control list): stateless, allow and deny, numbered order | Network security group on the subnet | No separate layer; rules apply across the VPC, plus hierarchical policies |
| Managed firewall | AWS Network Firewall | Azure Firewall | Cloud Next Generation Firewall |
| Web application firewall (WAF) and DDoS (distributed denial of service) protection | AWS WAF and AWS Shield | Azure Web Application Firewall and Azure DDoS Protection | Google Cloud Armor |
| Layer 7 load balancer | Application Load Balancer | Application Gateway | Application Load Balancer |
| Layer 4 load balancer | Network Load Balancer | Azure Load Balancer | Network Load Balancer |
| Global front door | Amazon CloudFront and AWS Global Accelerator | Azure Front Door | Global external Application Load Balancer |
| DNS | Route 53 public and private hosted zones, Resolver endpoints | Azure DNS, private DNS zones, DNS Private Resolver | Cloud DNS public and private zones, forwarding |
| Private access to a service | PrivateLink interface endpoints, gateway endpoints for S3 and DynamoDB | Private Link with private endpoints, and service endpoints | Private Service Connect and Private Google Access |
| Network peering | VPC peering, not transitive, also between regions | VNet peering, not transitive, also between regions | VPC Network Peering, not transitive, global |
| Transit hub | Transit Gateway, AWS Cloud WAN (wide area network) | Virtual WAN, or a hub VNet with Azure Firewall and Route Server | Network Connectivity Center |
| VPN (virtual private network) | Site to Site VPN, two tunnels per connection | VPN Gateway, active active | HA (high availability) VPN, two interfaces for a 99.99% service level |
| Private connection | AWS Direct Connect | Azure ExpressRoute | Cloud Interconnect, Dedicated or Partner |
| BGP (Border Gateway Protocol) with on premises | Virtual private gateway or Transit Gateway, Direct Connect gateway | Virtual network gateway, Azure Route Server | Cloud Router |
| Identity | IAM (identity and access management) and IAM Identity Center | Microsoft Entra ID | Cloud Identity or Google Workspace, with Cloud IAM |
| Permissions | IAM policies written in JSON (JavaScript Object Notation), attached to identities or resources | Azure role based access control, assigned at a scope | IAM roles granted to principals on a resource |
| Guardrails | Service control policies and resource control policies | Azure Policy | Organization Policy |
| Identity for workloads | IAM roles for EC2 (Elastic Compute Cloud) and Lambda | Managed identities | Service accounts |
| Virtual machines | Amazon EC2 | Azure Virtual Machines | Compute Engine |
| Kubernetes | Amazon EKS (Elastic Kubernetes Service) | Azure Kubernetes Service (AKS) | Google Kubernetes Engine (GKE) |
| Serverless | AWS Lambda | Azure Functions | Cloud Run and Cloud Run functions |
| Object storage | Amazon S3 | Azure Blob Storage | Cloud Storage |
| Block and file storage | Amazon EBS (Elastic Block Store), EFS (Elastic File System) and FSx | Managed Disks, Azure Files, Azure NetApp Files | Persistent Disk, Hyperdisk, Filestore |
| Relational database | Amazon RDS (Relational Database Service) and Aurora | Azure SQL Database | Cloud SQL, AlloyDB, Spanner |
| Flow logs | VPC Flow Logs | Virtual network flow logs | VPC Flow Logs |
| Path checking | Reachability Analyzer | Network Watcher | Connectivity Tests |
| Monitoring | Amazon CloudWatch | Azure Monitor | Cloud Monitoring |
| Infrastructure as code | CloudFormation and the AWS Cloud Development Kit (CDK) | Bicep and Azure Resource Manager (ARM) templates | Infrastructure Manager, which runs Terraform |
Swipe sideways to see the whole diagram.
On AWS. Route 53 points the name at an Application Load Balancer with AWS WAF, which sends requests to web instances in an Auto Scaling group across three zones. Security groups allow the web tier only from the load balancer and the database only from the web tier. S3 is reached through a gateway endpoint, and the network joins on premises through Direct Connect.
On Azure. Azure DNS points at an Application Gateway with its web application firewall, in front of a VM scale set spread across zones. Network security groups and application security groups do the filtering. Azure SQL and Blob Storage are reached through private endpoints, and ExpressRoute links the VNet, or its hub, to on premises.
On Google Cloud. Cloud DNS points at an Application Load Balancer with Cloud Armor, in front of a managed instance group. VPC firewall rules aimed at service accounts do the filtering. Cloud SQL and Cloud Storage are reached privately through Private Service Connect, and Cloud Interconnect with a Cloud Router joins on premises.
A server in a private subnet still needs updates and application programming interfaces (APIs) on the internet, but nothing on the internet should be able to start a connection to it. NAT solves both: outbound flows leave with a shared public address, and only their replies come back. Each cloud builds it differently.
Swipe sideways to see the whole diagram.
AWS. The private subnet's route table sends 0.0.0.0/0 to a NAT gateway in a public subnet, and the public subnet's route table sends 0.0.0.0/0 to the internet gateway. The NAT gateway swaps the VM's private address for its Elastic IP. A zonal NAT gateway serves one zone, so I put one in each zone; a regional NAT gateway, available since November 2025, spans zones on its own and needs no public subnet.
Azure. There is no internet gateway object. A NAT Gateway attached to the subnet gives every VM in it static public addresses for outbound traffic, and takes priority over other outbound methods. The old default outbound access, where Azure picked an address for you, is going: virtual networks created with API versions after 31 March 2026 get private subnets by default, so I always design outbound on purpose.
Google Cloud. The default route points at the default internet gateway, and Cloud NAT translates addresses inside Google's software defined network. There is no NAT appliance to size, patch or make highly available. Cloud NAT is configured on a Cloud Router, which only holds the settings and carries none of the traffic.
NAT keeps a table of each flow the VM started, so only replies come back in. Nothing on the internet can open a connection to a VM that has no public address.
Partners often allow my traffic by source address. NAT with fixed public addresses gives them one short list to trust, which is much easier than a public address per VM.
Sending storage or database traffic through NAT costs a processing charge per gigabyte and crosses the public edge. Private endpoints, further down this page, keep it inside.
Users never reach a web server directly. DNS sends them to a load balancer, which ends the TLS (Transport Layer Security) session, checks the request and passes it to a healthy server in a private subnet. Step through one request.
Swipe sideways to see the whole diagram.
The user looks up the name, and DNS returns the load balancer's address. On AWS I use a Route 53 alias record, because a load balancer's addresses can change. Global load balancers on Azure Front Door and Google Cloud answer from many locations at once.
The load balancer ends the TLS session with a managed certificate, and a web application firewall checks the request: AWS WAF, the Azure WAF on Application Gateway or Front Door, or Google Cloud Armor. Bad requests stop at the edge.
The load balancer probes every server on a health check path. A server that fails is taken out of rotation, so users never reach it. Here the zone 2 server has failed, and all traffic goes to zone 1.
The request goes to a healthy server in a private subnet. Its security group or NSG allows traffic only from the load balancer, never from the internet, so the server itself needs no public address.
The reply returns through the load balancer. A layer 7 load balancer is a proxy, so the server sees the load balancer's address, and the user's address arrives in the X-Forwarded-For header for logs and rules.
| Type | AWS | Azure | Google Cloud | When I use it |
|---|---|---|---|---|
| Layer 7, one region | Application Load Balancer | Application Gateway | Regional Application Load Balancer | Web apps and APIs: routing by host or path, TLS, WAF. |
| Layer 4 | Network Load Balancer | Azure Load Balancer | Network Load Balancer, proxy or passthrough | Non web protocols, very high throughput, fixed addresses. |
| Global layer 7 | CloudFront in front of an ALB (Application Load Balancer). Global Accelerator is the layer 4 anycast option | Azure Front Door | Global external Application Load Balancer | Users worldwide, failover between regions, edge caching. |
| DNS based | Route 53 routing policies | Traffic Manager | Cloud DNS routing policies | Steering between regions or clouds by health, weight or location. |
| Appliance insertion | Gateway Load Balancer | Gateway Load Balancer | Third party appliances behind an internal load balancer | Sending traffic through a scaled set of firewalls. |
A stateful filter remembers each connection, so a reply is allowed back automatically. A stateless filter judges every packet on its own, so the reply needs its own rule. On AWS a request passes the subnet's network ACL (NACL), which is stateless, and then the instance's security group (stateful). Change the rules and watch where the packets stop.
Swipe sideways to see the whole diagram.
The page loads. The request passes both filters. The security group remembers it and lets the reply out, and the NACL has an outbound rule for the reply's port.
| Filter | Applies to | Stateful | Rules | Order and defaults |
|---|---|---|---|---|
| AWS security group | Each network interface | Yes | Allow only. Can refer to other security groups. | All rules are considered together. New groups allow all outbound and no inbound. |
| AWS network ACL | A subnet | No | Allow and deny | Numbered, lowest first, first match wins. The default ACL allows all; a new custom ACL denies all. |
| Azure network security group | A subnet, a NIC, or both | Yes | Allow and deny, with service tags and application security groups | Priority 100 to 4096, lowest first. Default rules allow the VNet and the Azure load balancer, and deny other inbound. |
| Google Cloud firewall rules and policies | Instances, chosen by network tag or service account | Yes | Allow and deny | Priority 0 to 65535, lowest number first. Implied rules allow all egress and deny all ingress. Hierarchical policies from the organisation apply first. |
The security group or NSG on each workload is my main control. The web tier accepts HTTPS (Hypertext Transfer Protocol Secure) from the load balancer only, and the app tier only from the web tier, by referring to the group rather than to addresses. NACLs stay broad.
These rules see addresses and ports only. Traffic between spokes and out to the internet goes through a central firewall: AWS Network Firewall, Azure Firewall, Cloud Next Generation Firewall, or an NVA (network virtual appliance), a vendor firewall running as a VM.
Every rule lives in Terraform, Bicep or CloudFormation and is reviewed before it merges. Policy as code blocks rules that open management ports to the whole internet, and flow logs go to central logging.
Storage, databases and other platform services listen on public endpoints by default. A private endpoint puts the service on an address inside my network, so traffic stays on private addresses and the public endpoint can be switched off. The part people miss is DNS.
Swipe sideways to see the whole diagram.
Without private access, the VM reaches the storage service's public endpoint through NAT. It works, but the traffic leaves the private network, pays NAT processing charges and needs the service open to the internet.
A private endpoint gives the service a private address in my subnet. AWS PrivateLink interface endpoints and Azure private endpoints are network interfaces. A Private Service Connect endpoint on Google Cloud is an internal forwarding rule. For S3 and DynamoDB, AWS also offers free gateway endpoints that work through the route table instead.
Clients still use the service's normal name, so a private DNS zone must answer that name with the private address. On Azure that means zones such as privatelink.blob.core.windows.net, linked to every VNet that needs them. Most broken private endpoints I see are DNS faults.
The VM now connects straight to the endpoint, and the traffic stays on the provider's network. On premises clients use the same endpoint over the private connection, as long as their DNS forwards the zone to a cloud resolver such as Route 53 Resolver or Azure DNS Private Resolver.
With private access proven, I turn off public network access on the service, or restrict it to the endpoint with a policy. Now the data has no path to the internet even if a key leaks.
Few workloads live in one network. Teams get their own VPCs or VNets, which then need to talk to each other and to on premises sites. Peering is simple but does not scale; a transit hub does. The full hybrid design, with resilient private connections, is on the cloud architecture page.
Swipe sideways to see the whole diagram.
Peering. Two networks exchange routes directly, with no gateway in the path and no bandwidth bottleneck. But peering is not transitive: if A peers with B and B with C, A still cannot reach C. A full mesh grows quickly, with ten networks needing 45 peerings, so peering suits a handful of networks, not a hundred. Address ranges must not overlap.
Transit hub. Every network attaches once to a hub: an AWS Transit Gateway, an Azure Virtual WAN hub or hub VNet, or a Google Cloud Network Connectivity Center hub. The hub's route tables decide who can reach whom, and a firewall in the hub can inspect traffic between networks. This is my default beyond a few networks.
Hybrid. On premises joins the hub over private connections: AWS Direct Connect, Azure ExpressRoute or Google Cloud Interconnect, in two locations, with BGP choosing the path and a VPN over the internet as the last resort. On Google Cloud, Cloud Router runs the BGP sessions. On AWS and Azure the private connection's BGP peers are the provider's edge routers, and the VPN's BGP ends on the cloud gateway.
| Option | AWS | Azure | Google Cloud |
|---|---|---|---|
| VPN over the internet | Site to Site VPN: two tunnels per connection, to different endpoints | VPN Gateway, with active active instances | HA VPN: two interfaces and two tunnels for a 99.99% service level |
| Private connection | Direct Connect: dedicated ports of 1, 10, 100 or 400 Gbps, or hosted connections from 50 Mbps to 25 Gbps through partners | ExpressRoute through a provider, or ExpressRoute Direct ports straight into Microsoft | Dedicated Interconnect at 10, 100 or 400 Gbps per link, or Partner Interconnect |
| Where BGP runs | On each virtual interface, with the AWS Direct Connect router. Routes attach to a virtual private gateway or, through a Direct Connect gateway, a Transit Gateway. VPN BGP ends on the gateway itself | ExpressRoute: with the Microsoft Enterprise Edge (MSEE) routers, and the ExpressRoute gateway learns from them. VPN: on the VPN gateway. Azure Route Server for appliances | Cloud Router, for Interconnect and HA VPN |
| Hub | Transit Gateway, or Cloud WAN for global networks | Virtual WAN, or a hub VNet | Network Connectivity Center |
| Direct link to another cloud | AWS Interconnect (multicloud), generally available with Google Cloud since April 2026 | A partner fabric, or ExpressRoute and the other cloud's private link meeting in one colocation site | Cross-Cloud Interconnect to AWS, Azure, Oracle Cloud Infrastructure and Alibaba Cloud |
When two networks already overlap, routing alone cannot join them. Either I publish the one service that is needed through PrivateLink, Private Link or Private Service Connect, or I translate addresses. That means a private NAT gateway on AWS, Private NAT on Google Cloud, and NAT rules on the VPN gateway or a firewall on Azure.
The MTU (maximum transmission unit) depends on the path. Inside an AWS VPC, instances use 9001 byte jumbo frames, but an internet gateway or VPN carries 1,500 bytes and a Transit Gateway 8,500. Azure starts at 1,500. Google Cloud networks default to 1,460 and can go up to 8,896. I set the smallest value on the path, or clamp the TCP maximum segment size.
All three run dual stack networks with IPv4 and IPv6 (Internet Protocol version 6). On AWS, IPv6 addresses are globally routable, so an egress only internet gateway gives private subnets outbound IPv6 while blocking connections in. I plan IPv6 prefixes in the same address plan as IPv4.
In the cloud, identity is the first control, ahead of any network rule. Every API call is checked against who is asking and what they are allowed to do on that resource. The three clouds build this from the same parts: a hierarchy, identities, roles, guardrails and identities for workloads.
Swipe sideways to see the whole diagram.
Everything sits in a tree. AWS uses an Organization with organisational units and accounts. Azure uses a Microsoft Entra tenant, management groups, subscriptions and resource groups. Google Cloud uses an Organization, folders and projects. Policies set high in the tree flow down to everything below.
Engineers sign in through one identity provider with MFA (multi factor authentication): IAM Identity Center on AWS, Microsoft Entra ID on Azure, Cloud Identity or Google Workspace on Google Cloud, often federated with the company directory. No long lived personal keys.
On Azure and Google Cloud, a role granted at a level is inherited by everything beneath it. Here a read only database role on Production reaches the database in the Payments account. AWS works differently: IAM Identity Center assigns permission sets account by account, and only the guardrails are inherited down the tree. I grant roles to groups, never to individuals, and at the lowest level that works.
Guardrails set at the top deny actions whatever a role allows: service control policies on AWS, Azure Policy, and Organization Policy on Google Cloud. Typical rules keep data in approved regions and stop anyone turning off logging.
Applications get their own identities from the platform: IAM roles for EC2 and Lambda, managed identities on Azure, service accounts on Google Cloud. The platform issues short lived tokens, so no passwords or keys sit in code.
Virtual machines sit in my subnets, so they follow every rule on this page. Managed services and serverless functions run in the provider's network instead, and need a deliberate path into mine to reach private data. Who looks after which layer is set out in the shared responsibility model on the cloud architecture page.
Swipe sideways to see the whole diagram.
AWS Lambda. A function attached to a VPC reaches it through network interfaces that Lambda creates in the chosen private subnets, under the function's own security group. Once attached, it reaches the internet only through a NAT gateway, so I plan that path too.
Azure Functions. VNet integration on the Flex Consumption, Premium or App Service plans sends the function's outbound traffic into a subnet delegated to it. Inbound access can be made private with a private endpoint on the function app.
Cloud Run. Direct VPC egress places the service's outbound traffic straight onto a subnet, or a Serverless VPC Access connector carries it. Firewall rules and routes then treat it like any other traffic in the VPC.
EC2 instances, Azure VMs and Compute Engine instances live in my subnets, so routing, filtering and NAT apply to them directly. Patching the operating system stays my job.
Databases, storage and queues are reached through private endpoints, or through a peering that the provider sets up, as with Google Cloud's private services access for Cloud SQL.
EKS, AKS and GKE give each pod an address, often from the VPC itself, which can use up subnets faster than expected. I size pod address ranges before the first cluster goes live.
An API gateway terminates TLS, checks who is calling, limits request rates and routes each path to a function. A function idle for a while starts cold, so the first call is slower. Where that matters I keep instances warm: provisioned concurrency on Lambda, always ready instances on Azure Functions, minimum instances on Cloud Run.
Compute is easy to price. Network charges surprise people, because they depend on where data goes. The patterns are the same in all three clouds, though the rates differ and change, so I always check the current price lists.
Swipe sideways to see the whole diagram.
Inbound. Data arriving from the internet is usually free, which is why it is easy to fill a cloud and harder to leave it.
To the internet. Data leaving to the internet is charged per gigabyte, getting cheaper in volume. A content delivery network in front of busy content usually costs less per gigabyte and is faster for users.
Between zones. AWS and Google Cloud charge for traffic between zones in the same region, in both directions on AWS. Azure removed that charge. Resilience across zones is worth paying for, but chatty tiers that talk constantly across zones can quietly cost more than the servers.
Between regions. Replication and backups to another region are charged per gigabyte. I size disaster recovery copies with that in mind, and compress or send only changes where I can.
NAT and endpoints. NAT gateways and private endpoints charge per hour and per gigabyte processed. Sending large storage traffic through NAT is a classic waste: an S3 gateway endpoint carries it for free.
There is no cable to trace in the cloud. I check configuration in the order a packet meets it: name resolution, security rules, the route table, the gateway or peering, then the destination and its way back. Each cloud has tools that check this path for me. Pick a symptom.
Swipe sideways to see the whole diagram.
The private endpoint is not used. I run nslookup or dig on the client. If the name returns a public address, the private DNS zone is missing, not linked to this network, or on premises DNS is not forwarding the zone to the cloud resolver.
Users cannot reach the app. The load balancer shows unhealthy targets. The server's security group or NSG must allow the load balancer's own address range or security group, and Google Cloud health checks come from fixed Google ranges that need a firewall rule.
A VM cannot reach the internet. I check the subnet's effective routes for 0.0.0.0/0. On AWS it must point at a NAT gateway. A zonal NAT gateway must sit in a public subnet with a route to the internet gateway. A regional NAT gateway needs no public subnet, but the VPC still needs an internet gateway. On Azure I check the NAT Gateway is attached to this subnet. On Google Cloud I check Cloud NAT covers this subnet and region.
A peered network is unreachable. Peering being active is not enough. Both sides need routes to each other's ranges, the security rules must allow the traffic, and peering never carries traffic onwards to a third network.
On premises cannot connect. I check the BGP session on the cloud gateway, which prefixes are advertised and received each way, and route propagation into the subnets' route tables. Overlapping address ranges between cloud and site are a common, painful cause.
It works one way only. A stateless NACL without a rule for the reply's ports, or a reply that leaves by a different path and meets a stateful firewall that never saw the request. Flow logs on both ends show where the reply disappears.
| Check | AWS | Azure | Google Cloud |
|---|---|---|---|
| Can this source reach that destination? | Reachability Analyzer: aws ec2 create-network-insights-path, then start-network-insights-analysis | Network Watcher connection troubleshoot and IP flow verify: az network watcher test-ip-flow | Connectivity Tests: gcloud network-management connectivity-tests create |
| Which route wins? | The subnet's route table: aws ec2 describe-route-tables | Effective routes on the NIC: az network nic show-effective-route-table, or next hop | gcloud compute routes list, and the route analysis in Connectivity Tests |
| Which rule allowed or blocked it? | Security groups and NACLs: aws ec2 describe-security-groups | Effective security rules: az network nic list-effective-nsg | Firewall rules logging and gcloud compute firewall-rules list |
| What really flowed? | VPC Flow Logs | Virtual network flow logs, which replace NSG flow logs | VPC Flow Logs |
| Packet capture | VPC Traffic Mirroring | Network Watcher packet capture | Packet Mirroring |
From inside a VM, the usual tools still work: curl -v, nc -vz host 443, traceroute -T and dig. My general method is on the troubleshooting page.
Whether the work is a new landing zone, a migration or tidying up an estate that grew by accident, I follow the same path. I agree the outcome, find out what really exists, design the network and identity foundations, prove them, then hand over a platform the operations team can run and keep current.
Swipe sideways to see the whole diagram.
I start with the reason: a data centre exit, faster delivery, resilience or a new service. I agree how success will be measured, such as cost per workload, recovery time or release frequency, and who decides what, including where data may live.
Functional requirements cover what must connect to what, which services are allowed, and how teams get accounts or subscriptions. Non functional ones set availability, recovery, latency, residency, security and cost targets, each with a number I can test.
I map what is really running: servers and their dependencies, current cloud accounts, address ranges, flows and spend. Overlapping address ranges, public storage and forgotten accounts show up here, long before they cause an outage or a breach.
I design the hierarchy and guardrails, the hub and routing, the address plan, private access, hybrid connectivity, identity and logging. The design authority reviews it, and decisions go into the decision log with the reasons.
Everything is built as code, usually Terraform, through a pipeline with policy checks. I test routes, security rules, private DNS and hybrid failover, then move a pilot workload before the migration waves start, each with a rollback plan.
Before the first workload moves, I agree who owns the platform, the network and each application. Alerts, flow logs and cost reports are live from day one, and hypercare ends only when alerts are tuned and runbooks are proven.
Cloud services change every month: features retire, defaults change and prices move. I track retirement notices, review cost and use each quarter, keep guardrails current and plan savings commitments before they renew. The 2026 change to Azure default outbound access is an example: new networks built from old templates get no default internet access.
What it must do.
How well it must do it, with a number wherever one can be agreed.
These are typical starting targets for a cloud landing zone. The client sets the final numbers, and each one is checked by a test or by a policy in code.
| Tool or source | What it tells me |
|---|---|
| AWS Transform, Azure Migrate or Google Cloud Migration Center | Server inventory, dependencies and sizing for migration. |
| VPC Flow Logs and virtual network flow logs | Which workloads really talk to each other, and how much. |
| Cost Explorer, Azure Cost Management, Cloud Billing reports | Current spend by service, account and tag. |
| AWS Well Architected Tool, Azure Advisor, Recommender | The provider's own view of risks and waste. |
| Terraform state and the cloud consoles | What has been built, and what has drifted from the code. |
| IP address management export | Every range in use, so cloud ranges never overlap. |
Cloud network faults are configuration faults: there is no cable to check. I follow the packet through name resolution, security rules, routes, gateways and the reply, and use each provider's path checking tools to prove where it stops.
| Layer | What I check |
|---|---|
| 1 and 2 · Physical and link | Handled by the provider. On private connections I check port state, light levels and errors with the carrier. |
| 3 · Network | Effective routes, peering and hub route tables, NAT and BGP prefixes, with az network nic show-effective-route-table or gcloud compute routes list. |
| 4 · Transport | Security groups, NSGs, NACLs and firewall rules, with az network nic list-effective-nsg and flow logs. |
| 5 to 7 · Application | DNS answers with dig, TLS and certificates with curl -v, load balancer health and WAF logs. |
| Identity | API calls denied by a role or guardrail, found in CloudTrail, the Azure activity log or Cloud Audit Logs. |
My general method is on the troubleshooting page, and the cloud faults I see most are in the troubleshooting section above.
I agree how the platform will be run before the first workload moves, so ownership is clear on day one.
Who owns the landing zone, the network, security tooling and each application, and how to reach the provider's support.
Alerts on connectivity, hybrid link and BGP state, load balancer health, certificate expiry and unusual spend.
API logs, flow logs and firewall logs sent to a central account and kept for the agreed period.
Changes made in code through a pipeline, with policy checks, peer review and an approved change for production.
Budgets, alerts and tagging per team, with a monthly review of the largest and fastest growing costs.
Repeat faults fixed in the shared modules, so every team gets the fix at once.
A cloud platform keeps changing underneath you. I plan for that from the start.
My cloud work has always been part of wider network, security and data centre programmes, which is why I care so much about how each platform really moves packets.
My cloud architecture certification. I have also trained in Microsoft Azure and Google Cloud Platform.
Led network and security transformation from discovery to provisioning across Cisco Nexus, Catalyst SD-WAN, SD-Access and AWS, Azure and Google Cloud environments.
Lead architect on network, cloud and data centre modernisation programmes, from discovery to operational handover, across several client environments.
Directed architecture and delivery across AWS, Google Cloud, Azure, disaster recovery, Catalyst SD-WAN, SD-Access and security, and led and mentored a team of 4 engineers.
Shaped network security for AVEVA Historian and, during the OSIsoft acquisition, the PI System, moving process data securely to data centre and cloud.
Hybrid and multi cloud design, built as code with Terraform, Ansible and Python.
Backed by AWS Certified Solutions Architect Professional. I have also trained in Microsoft Azure and Google Cloud Platform. See all credentials
Every page follows the same idea: how it works, the choices that matter, and where I have used it. The foundations pages explain the basics the others build on.
