Cloud Network Architecture
Cloud network architecture encompasses the design of virtual networks, subnets, security boundaries, and connectivity patterns that enable workloads to communicate securely across cloud environments. Unlike physical networks where topology emerges from cable runs and switch placements, cloud networks exist as software constructs that can be created, modified, and destroyed through API calls. This programmability creates both opportunity and risk: network changes that once required physical intervention now happen in seconds, demanding equivalent rigour in design and governance.
The architectural decisions made in cloud networking directly affect security posture, operational complexity, and cost. A virtual network with overly permissive security rules exposes workloads to lateral movement during compromise. Poorly designed egress paths generate unexpected data transfer charges. Subnet schemes that seemed adequate for initial deployment become constraints when the organisation expands to new regions or integrates acquired entities.
- Virtual Network
- A software-defined network boundary within a cloud provider, isolating resources and enabling IP address assignment. Called VPC (Virtual Private Cloud) in AWS and GCP, VNet in Azure.
- Subnet
- A subdivision of a virtual network with its own IP address range (CIDR block), typically associated with an availability zone and security controls.
- CIDR (Classless Inter-Domain Routing)
- Notation expressing IP address ranges as a base address and prefix length. 10.0.0.0/16 represents addresses 10.0.0.0 through 10.0.255.255 (65,536 addresses).
- Network Security Group
- A stateful firewall construct that filters traffic based on source, destination, port, and protocol. Attachable to subnets or individual resources.
- Private Endpoint
- A network interface that projects a cloud service into a virtual network, enabling access without traversing the public internet.
Virtual network fundamentals
A virtual network provides an isolated address space within a cloud region. Resources deployed into that virtual network receive private IP addresses from the defined range and can communicate with each other subject to security controls. Traffic between resources in the same virtual network does not traverse the public internet and incurs no data transfer charges within the same availability zone.
The CIDR block assigned to a virtual network determines its address capacity and constrains future growth. A /16 network provides 65,536 addresses; a /24 provides 256. Cloud providers reserve several addresses per subnet for gateway, DNS, and broadcast functions. In AWS, each subnet loses 5 addresses to these reservations. A /24 subnet therefore provides 251 usable addresses, not 256.
Address planning must account for the entire organisation’s cloud footprint plus on-premises ranges that will interconnect. Overlapping CIDR blocks between virtual networks that need to communicate creates routing conflicts that require NAT translation to resolve. The simplest approach allocates non-overlapping ranges from the start:
Organisation address plan:
10.0.0.0/8 Reserved for cloud and on-premises | +-- 10.0.0.0/16 On-premises datacentre +-- 10.1.0.0/16 AWS production (eu-west-1) +-- 10.2.0.0/16 AWS production (us-east-1) +-- 10.3.0.0/16 AWS non-production +-- 10.4.0.0/16 Azure production +-- 10.5.0.0/16 Future expansion +-- 10.10.0.0/16 Field office range (subdivided as /24 per site)Each /16 accommodates 256 subnets of /24 (251 hosts each) or different subdivisions as workload patterns require. Reserving contiguous blocks for future expansion prevents fragmentation as the organisation grows.
Segmentation and isolation
Network segmentation separates workloads into security domains with controlled communication paths between them. The granularity of segmentation reflects the organisation’s risk tolerance, compliance requirements, and operational complexity budget. More segments provide stronger isolation but increase the number of firewall rules to manage.
A three-tier web application demonstrates basic segmentation principles. The presentation tier (web servers) requires inbound access from the internet. The application tier (business logic) accepts connections only from the presentation tier. The data tier (databases) accepts connections only from the application tier. Each tier occupies its own subnet with security controls enforcing these access patterns.
+------------------------------------------------------------------+| VIRTUAL NETWORK: 10.1.0.0/16 |+------------------------------------------------------------------+| || +---------------------------+ +---------------------------+ || | PUBLIC SUBNET | | PUBLIC SUBNET | || | 10.1.0.0/24 (AZ-a) | | 10.1.1.0/24 (AZ-b) | || | | | | || | +-------+ +-------+ | | +-------+ +-------+ | || | | NAT | | ALB | | | | NAT | | ALB | | || | | GW | | node | | | | GW | | node | | || | +---+---+ +---+---+ | | +---+---+ +---+---+ | || +-------|----------|--------+ +-------|----------|--------+ || | | | | || +-------|----------|--------+ +-------|----------|--------+ || | PRIVATE SUBNET (APP) | | PRIVATE SUBNET (APP) | || | 10.1.10.0/24 (AZ-a) | | 10.1.11.0/24 (AZ-b) | || | | | | | | || | +------v------+ | | +------v------+ | || | | App servers | | | | App servers | | || | | (ASG) | | | | (ASG) | | || | +------+------+ | | +------+------+ | || +----------|----------------+ +----------|----------------+ || | | || +----------|----------------+ +----------|----------------+ || | PRIVATE SUBNET (DATA) | | PRIVATE SUBNET (DATA) | || | 10.1.20.0/24 (AZ-a) | | 10.1.21.0/24 (AZ-b) | || | | | | | | || | +------v------+ | | +------v------+ | || | | Database |<--------|----|-->| Database | | || | | primary | repl | | | replica | | || | +-------------+ | | +-------------+ | || +---------------------------+ +---------------------------+ || |+------------------------------------------------------------------+Figure 1: Three-tier segmentation across availability zones
The public subnets contain resources that require internet-routable addresses or serve as ingress points: load balancers, NAT gateways, and bastion hosts. Application and data subnets have no direct internet routes; their outbound traffic flows through NAT gateways in the public subnets.
Availability zone distribution ensures that a single zone failure does not eliminate all instances of any tier. The application load balancer spans both public subnets. Application servers in an auto-scaling group distribute across both application subnets. The database replicates between data subnets.
Workload isolation patterns
Organisations handling sensitive data require stronger isolation than subnet boundaries provide. A virtual network containing beneficiary data should not share a network boundary with a virtual network running public-facing marketing applications, even with security group rules preventing direct communication. Separate virtual networks eliminate the possibility of misconfiguration creating unintended paths.
The isolation granularity depends on data sensitivity and regulatory requirements. A proportionate model for most organisations:
+-------------------+ +-------------------+ +-------------------+| PRODUCTION | | SENSITIVE | | NON-PRODUCTION || WORKLOADS | | WORKLOADS | | ENVIRONMENTS || | | | | || - Public web | | - Beneficiary | | - Development || - APIs | | data systems | | - Testing || - Internal apps | | - Protection | | - Training || | | case mgmt | | || VNet: 10.1.0.0/16 | | VNet: 10.4.0.0/16 | | VNet: 10.3.0.0/16 |+--------+----------+ +--------+----------+ +--------+----------+ | | | | +---------+ | | +--->| Transit |<---------+ | | Gateway | | +----+----+ | | | +-----------------------------------------+ | +--------v--------+ | On-premises | | connectivity | +-----------------+Figure 2: Virtual network isolation by sensitivity
The transit gateway provides controlled routing between networks that require communication. The sensitive workload network connects to the transit gateway with restrictive route tables permitting only specific traffic patterns. Non-production networks cannot route to sensitive networks at all.
Network security controls
Network security groups operate as stateful firewalls evaluating traffic against ordered rule sets. A rule specifies source, destination, port range, protocol, and action (allow or deny). The stateful nature means that responses to permitted outbound connections automatically pass inbound without explicit rules.
Security group rules reference IP ranges, other security groups, or managed prefix lists. Referencing another security group rather than IP addresses creates dynamic rules that adapt as resources join or leave the referenced group. An application tier security group allowing inbound from the web tier security group automatically permits traffic from any current or future web server without rule updates.
Application tier security group rules:
Inbound:+----------+-------------+------------+---------+------------------------+| Priority | Source | Protocol | Port | Description |+----------+-------------+------------+---------+------------------------+| 100 | sg-web-tier | TCP | 8080 | App traffic from web || 110 | sg-bastion | TCP | 22 | SSH from bastion || 200 | 10.0.0.0/8 | TCP | 9090 | Metrics collection |+----------+-------------+------------+---------+------------------------+
Outbound:+----------+-------------+------------+---------+------------------------+| Priority | Destination | Protocol | Port | Description |+----------+-------------+------------+---------+------------------------+| 100 | sg-data-tier| TCP | 5432 | PostgreSQL to data || 110 | pl-s3 | TCP | 443 | S3 via prefix list || 120 | 0.0.0.0/0 | TCP | 443 | HTTPS to internet |+----------+-------------+------------+---------+------------------------+The prefix list reference (pl-s3) contains the IP ranges for S3 endpoints in the region, managed by the cloud provider. This approach permits S3 access without opening rules to arbitrary internet addresses.
Network access control lists (NACLs) provide subnet-level stateless filtering. Unlike security groups, NACLs require explicit rules for both request and response traffic. Their stateless nature makes them suitable for broad deny rules at the subnet boundary, such as blocking traffic from known malicious ranges. Most granular filtering belongs in security groups; NACLs serve as a secondary defence layer.
Default deny and explicit allow
Both security groups and NACLs should operate on a default-deny basis. Security groups implicitly deny all inbound traffic unless rules permit it. For outbound traffic, cloud providers create default allow-all rules that require removal to achieve default deny. Organisations with strict security requirements modify these defaults:
# AWS CLI: Remove default outbound rule from security groupaws ec2 revoke-security-group-egress \ --group-id sg-0123456789abcdef0 \ --ip-permissions '[{"IpProtocol": "-1", "IpRanges": [{"CidrIp": "0.0.0.0/0"}]}]'
# Add specific outbound rulesaws ec2 authorize-security-group-egress \ --group-id sg-0123456789abcdef0 \ --ip-permissions '[{"IpProtocol": "tcp", "FromPort": 443, "ToPort": 443, "IpRanges": [{"CidrIp": "0.0.0.0/0"}]}]'Default-deny outbound forces explicit documentation of every external dependency. Applications discover missing outbound rules during testing rather than operating with unmonitored external connections.
Load balancing patterns
Load balancers distribute traffic across multiple backend instances, providing scalability and fault tolerance. Cloud providers offer distinct load balancer types optimised for different protocols and use cases.
Application load balancers operate at layer 7 (HTTP/HTTPS) and route requests based on URL paths, headers, or hostnames. A single application load balancer can serve multiple applications through host-based routing, reducing the number of load balancers required:
+------------------------+ | Application Load | | Balancer | | (app.example.org) | +------------------------+ | +-------------------------+-------------------------+ | | | Host: api.* Host: web.* Host: admin.* | | | v v v +---------------+ +---------------+ +---------------+ | Target Group | | Target Group | | Target Group | | (API servers) | | (Web servers) | | (Admin app) | +---------------+ +---------------+ +---------------+Figure 3: Host-based routing with application load balancer
Network load balancers operate at layer 4 (TCP/UDP) with lower latency than application load balancers. They preserve the client’s source IP address, which application load balancers obscure by default. Network load balancers suit non-HTTP protocols and applications requiring source IP visibility for audit or rate limiting.
Internal load balancers serve traffic within the virtual network without internet exposure. A microservices architecture uses internal load balancers for service-to-service communication while external load balancers handle user-facing traffic. Internal load balancers incur no data transfer charges for traffic within the same availability zone.
Health checking and failover
Load balancers remove unhealthy instances from rotation based on configurable health checks. The health check target should verify actual application functionality, not merely that the instance responds. A database-backed application should validate database connectivity in its health endpoint:
# Flask health check endpoint@app.route('/health')def health_check(): try: # Verify database connectivity db.session.execute('SELECT 1') return jsonify({'status': 'healthy'}), 200 except Exception as e: return jsonify({'status': 'unhealthy', 'error': str(e)}), 503Health check parameters require tuning for application characteristics:
| Parameter | Recommended range | Considerations |
|---|---|---|
| Interval | 10-30 seconds | Shorter intervals detect failures faster but increase backend load |
| Timeout | 5-10 seconds | Must be less than interval; accommodate application response time |
| Unhealthy threshold | 2-3 failures | Prevents single transient failure from removing instance |
| Healthy threshold | 2 checks | Requires stability before returning instance to rotation |
For applications with slow startup (JVM-based applications, applications loading ML models), configure extended initial health check grace periods. An application requiring 90 seconds to start should have a 120-second grace period before health checks begin.
DNS in cloud environments
Cloud DNS services provide private zones visible only within virtual networks and public zones for internet-facing resources. Private zones enable internal service discovery without exposing names externally.
A private zone associated with a virtual network resolves queries from resources within that network. Resources in other networks receive NXDOMAIN unless those networks also associate with the zone:
Private zone: internal.example.org
+---------------------------+ +---------------------------+| Production VNet | | Non-Production VNet || (zone associated) | | (zone NOT associated) || | | || Query: db.internal | | Query: db.internal || Result: 10.1.20.5 | | Result: NXDOMAIN |+---------------------------+ +---------------------------+Split-horizon DNS presents different responses to the same query depending on the requester’s location. External queries for app.example.org resolve to the public load balancer IP. Internal queries resolve to the internal load balancer IP, keeping traffic within the private network and avoiding egress charges:
Public zone: example.org app.example.org -> 203.0.113.50 (public ALB)
Private zone: example.org (overrides public for internal queries) app.example.org -> 10.1.0.50 (internal ALB)Implementing split-horizon requires creating a private zone with the same name as the public zone and associating it with the virtual network. Private zone records take precedence for queries originating within associated networks.
DNS for hybrid environments
When virtual networks connect to on-premises infrastructure, DNS queries must resolve both cloud and on-premises resources. The resolution architecture depends on where authoritative DNS exists:
+------------------------------------------------------------------+| HYBRID DNS ARCHITECTURE |+------------------------------------------------------------------+
Cloud VNet On-premises+------------------------+ +------------------------+| | | || Cloud workloads | | On-premises servers || | | | | || v | | v || +-------------+ | | +-------------+ || | VNet DNS | | | | AD DNS | || | resolver | | | | (corp.local)| || +------+------+ | | +------+------+ || | | | | |+---------|--------------+ +---------|--------------+ | | | Conditional forwarding | | corp.local -> on-prem DNS | +----------------------------------->| | | |<-----------------------------------+ | cloud.example.org -> cloud DNS |Figure 4: Conditional forwarding for hybrid DNS
The cloud DNS resolver forwards queries for on-premises domains (corp.local) to on-premises DNS servers. On-premises DNS servers forward cloud domain queries (cloud.example.org) to cloud DNS endpoints. This bidirectional forwarding requires network connectivity between the environments and firewall rules permitting DNS traffic (UDP/TCP 53).
Hybrid connectivity
Connecting cloud virtual networks to on-premises infrastructure or field offices requires establishing secure network paths. The connection method depends on bandwidth requirements, latency sensitivity, and budget.
Site-to-site VPN establishes encrypted tunnels over the public internet. Each tunnel provides approximately 1.25 Gbps throughput in AWS (varies by provider). Multiple tunnels can aggregate bandwidth, though individual TCP connections are limited to single tunnel throughput. VPN suits workloads tolerant of internet latency variability and organisations without dedicated connectivity requirements:
On-premises Cloud+-------------------+ +-------------------+| | | || +-------------+ | IPsec tunnels | +-------------+ || | VPN device |--|========================|--| Virtual | || | (router/FW) |--|========================|--| gateway | || +-------------+ | (active/standby) | +-------------+ || | | |+-------------------+ +-------------------+
Route propagation: On-prem routes -> virtual gateway -> VNet route table VNet routes -> VPN device -> on-prem routingHigh-availability VPN configurations use multiple tunnels across different on-premises devices and cloud availability zones. Each tunnel terminates on a different endpoint, preventing single device failure from severing connectivity.
Dedicated connectivity (AWS Direct Connect, Azure ExpressRoute, GCP Cloud Interconnect) provides private network paths through colocation facilities. Dedicated connections offer consistent latency, higher throughput (1 Gbps to 100 Gbps), and avoidance of public internet. The setup requires contracts with connectivity providers and lead times measured in weeks to months.
For organisations with field offices connecting to cloud resources, the architecture combines headquarters connectivity with field office VPNs:
+------------------------------------------------------------------+| DISTRIBUTED CONNECTIVITY |+------------------------------------------------------------------+
+------------------+ | Cloud Region | | | | +------------+ | | | Transit | | | | Gateway | | | +-----+------+ | +--------|---------+ | +------------------------+------------------------+ | | | v v v+--------+--------+ +--------+--------+ +--------+--------+| HQ Connection | | Regional Hub | | Field Office || (Direct Connect)| | (Site-to-site | | (Site-to-site || | | VPN, 100 Mbps) | | VPN, 10 Mbps) || 1 Gbps dedicated| | | | |+-----------------+ +-----------------+ +-----------------+ | | | v v v Headquarters Regional office Field office (500 users) (50 users) (5 users)Figure 5: Tiered connectivity architecture
The transit gateway centralises routing, enabling field offices to communicate with headquarters through cloud infrastructure rather than requiring direct office-to-office connections. This hub-and-spoke model simplifies network management for geographically distributed organisations.
Private connectivity to services
Cloud provider services (object storage, managed databases, serverless functions) operate on shared infrastructure outside customer virtual networks. By default, traffic to these services routes over the public internet, even from resources within the same region. Private connectivity options keep this traffic within the cloud provider’s network.
Gateway endpoints provide private paths to specific services (S3 and DynamoDB in AWS) without requiring a network interface in the virtual network. Traffic routes through the gateway based on route table entries and incurs no data processing charges:
Route table entry for S3 gateway endpoint:
Destination Target Description----------- ------ -----------10.1.0.0/16 local Local VNet trafficpl-s3-eu-west-1 vpce-s3-gateway S3 via gateway endpoint0.0.0.0/0 nat-gateway Internet via NATThe prefix list (pl-s3-eu-west-1) contains S3’s IP ranges for the region. Traffic matching those destinations routes through the gateway endpoint instead of the NAT gateway, reducing NAT processing costs and keeping data within the provider’s network.
Interface endpoints (PrivateLink) create elastic network interfaces within subnets, projecting services into the virtual network with private IP addresses. Interface endpoints support a broader range of services than gateway endpoints but incur hourly charges and data processing fees:
+------------------------------------------------------------------+| VIRTUAL NETWORK |+------------------------------------------------------------------+| || Application subnet Endpoint subnet || +------------------+ +------------------+ || | | | | || | +------------+ | Private IP | +------------+ | || | | App server |--+----------------->| | Interface | | || | +------------+ | 10.1.50.10 | | endpoint | | || | | | | (Secrets | | || +------------------+ | | Manager) | | || | +-----+------+ | || +--------|---------+ |+------------------------------------------------------------------+ | | AWS PrivateLink v +----------------+ | Secrets Manager| | service | +----------------+Figure 6: Interface endpoint providing private access to Secrets Manager
Applications reference the endpoint’s DNS name or private IP address. With private DNS enabled, the service’s default hostname (secretsmanager.eu-west-1.amazonaws.com) resolves to the endpoint’s private IP within the virtual network, requiring no application code changes.
Third-party PrivateLink services
PrivateLink extends beyond cloud provider services to third-party SaaS offerings that support it. Connecting to a partner’s service through PrivateLink avoids exposing traffic to the public internet:
Your VNet Partner's VNet+-------------------+ +-------------------+| | | || +---------------+ | PrivateLink | +---------------+ || | Your app |-+--------------------|>| Endpoint | || | | | | | service (NLB) | || +---------------+ | | +-------+-------+ || | | | |+-------------------+ | v | | +---------------+ | | | Partner SaaS | | | | application | | | +---------------+ | +-------------------+The partner provides a service endpoint name. Creating an interface endpoint in your virtual network targeting that service name establishes the private connection. The partner approves the connection request before traffic flows.
Traffic routing and control
Virtual network routing determines how traffic flows between subnets, to and from the internet, and across connected networks. Each subnet associates with a route table containing rules evaluated in longest-prefix-match order.
A route table for a private application subnet illustrates common routing patterns:
| Destination | Target | Purpose |
|---|---|---|
| 10.1.0.0/16 | local | Traffic within VNet |
| 10.0.0.0/16 | tgw-abc123 | On-premises via transit gateway |
| 10.2.0.0/16 | pcx-def456 | Peered VNet in another region |
| pl-s3 | vpce-s3 | S3 via gateway endpoint |
| 0.0.0.0/0 | nat-gateway | Internet via NAT |
Routes to 10.0.0.0/16 (on-premises) and 10.2.0.0/16 (peered region) appear explicitly. Without these entries, traffic to those ranges would match the default route and attempt to reach them through the NAT gateway, failing.
Egress control and cost implications
Internet-bound traffic from private subnets routes through NAT gateways, which translate private source addresses to the NAT gateway’s public address. NAT gateways charge per GB processed in addition to hourly fees. A busy application generating 1 TB of outbound traffic monthly incurs approximately $45 in NAT processing charges (at $0.045/GB) beyond the hourly gateway cost.
Reducing NAT costs involves routing traffic that does not require internet access through alternative paths:
Cost optimisation routing:
Traffic type Route NAT cost?------------ ----- ---------S3 uploads/downloads Gateway endpoint NoSecrets Manager access Interface endpoint No (endpoint fee instead)CloudWatch logs Interface endpoint No (endpoint fee instead)SaaS application X Internet via NAT YesPartner API Y PrivateLink NoConsolidating NAT gateways across multiple virtual networks through a transit gateway reduces the number of gateways deployed but centralises a potential bottleneck. Each NAT gateway supports 55,000 simultaneous connections and 45 Gbps sustained throughput. Applications making many short-lived connections (web scrapers, distributed crawlers) can exhaust connection tracking capacity before bandwidth limits.
Egress filtering
Organisations requiring control over outbound destinations implement egress filtering through proxy servers or cloud-native filtering services. Security groups can restrict outbound traffic to specific IP ranges but cannot filter by domain name. A security group rule permitting TCP 443 to 0.0.0.0/0 allows HTTPS to any destination.
A web proxy (Squid, cloud-native web gateway) intercepts HTTP/HTTPS traffic and enforces domain allowlists:
Egress filtering architecture:
+------------------+ +------------------+ +------------------+| Application | | Web proxy | | Internet || server |------>| (filtering) |------>| || | | | | || HTTP_PROXY= | | Permits: | | || proxy:3128 | | - api.partner.* | | |+------------------+ | - pypi.org | +------------------+ | Denies: | | - everything | | else | +------------------+Applications configured with proxy environment variables route HTTP/HTTPS through the proxy. The proxy logs all requests, providing visibility into external dependencies and detecting unexpected outbound communication patterns that indicate compromise.
Multi-region patterns
Deploying across multiple cloud regions provides resilience against regional outages and reduces latency for geographically distributed users. Multi-region architectures range from simple DNS failover to active-active configurations with globally distributed databases.
The simplest multi-region pattern deploys the full application stack in two regions with DNS health checks routing users to the healthy region:
+------------------------------------------------------------------+| ACTIVE-PASSIVE MULTI-REGION |+------------------------------------------------------------------+
DNS health check | +-------------+-------------+ | | v v +---------+----------+ +---------+----------+ | EU-WEST-1 | | US-EAST-1 | | (primary) | | (standby) | | | | | | +------------+ | | +------------+ | | | Full app | | | | Full app | | | | stack | | | | stack | | | +------------+ | | +------------+ | | | | | | +------------+ | | +------------+ | | | Database | | | | Database | | | | (primary) |---|------|-->| (replica) | | | +------------+ | async| +------------+ | | | repl | | +--------------------+ +--------------------+Figure 7: Active-passive multi-region with asynchronous replication
The standby region receives database replicas through asynchronous replication. During normal operation, all traffic serves from the primary region. If health checks fail, DNS routes traffic to the standby region. The replication lag (seconds to minutes depending on write volume) represents potential data loss during failover.
Active-active configurations serve traffic from both regions simultaneously, reducing latency for users near each region. This pattern requires database architectures supporting multi-region writes or application designs that tolerate eventual consistency:
Global DNS (geolocation routing) | +------------------+------------------+ | | v v+--------+--------+ +--------+--------+| EU-WEST-1 | | AP-SOUTH-1 || | | || +----------+ | Bidirectional | +----------+ || | App + | | replication | | App + | || | Database |<--|-------------------|-->| Database | || +----------+ | (conflict | +----------+ || | resolution) | |+-----------------+ +-----------------+Conflict resolution mechanisms handle the case where users in both regions modify the same data simultaneously. Strategies include last-write-wins (simple but potentially loses updates), application-level merge logic (complex but preserves intent), and conflict-free replicated data types (CRDTs, suitable for specific use cases).
Inter-region networking
Virtual networks in different regions do not communicate by default. Inter-region connectivity options include:
VNet peering establishes direct routing between virtual networks. Intra-region peering incurs no data transfer charges; inter-region peering charges per GB transferred. Peering connections are non-transitive: if VNet A peers with B, and B peers with C, A cannot reach C through B without explicit A-C peering.
Transit gateway inter-region peering connects transit gateways in different regions, enabling any attached virtual network to reach networks attached to the remote transit gateway. This hub-and-spoke model scales better than full-mesh VNet peering for organisations with many virtual networks:
EU-WEST-1 US-EAST-1+-----------------------+ +-----------------------+| +-------+ | | +-------+ || | VNet A|---+ | | +---| VNet X| || +-------+ | | Inter-region | | +-------+ || v | peering | v || +-------+ +-+------+ | | +------+-+ +-------+ || | VNet B|-| Transit|=|====================|=|Transit |-| VNet Y| || +-------+ | Gateway| | | |Gateway | +-------+ || +---+----+ | | +----+---+ || +-------+ | | | | +-------+ || | VNet C|-----+ | | +-----| VNet Z| || +-------+ | | +-------+ |+-----------------------+ +-----------------------+Traffic between VNet A (EU) and VNet Y (US) traverses the local transit gateway, the inter-region peering, and the remote transit gateway. Route tables at each hop control which networks can communicate.
Implementation considerations
For organisations with limited IT capacity
Start with a single virtual network containing public and private subnets. Deploy web-facing resources in public subnets and everything else in private subnets with NAT gateway access. This two-tier model provides basic isolation without the complexity of extensive segmentation.
Use cloud provider defaults where reasonable. The default security group configuration (deny inbound, allow outbound) suits most initial deployments. Add specific inbound rules as applications require. Defer default-deny outbound until operational maturity supports the rule maintenance overhead.
Prefer managed NAT gateways over NAT instances despite higher per-GB costs. NAT instances require patching, monitoring, and failover configuration. The operational overhead exceeds cost savings for organisations without dedicated network operations staff.
Address space planning deserves investment even in simple deployments. Select a private range (/16 recommended) that does not conflict with any network the organisation connects to now or plausibly will in future. Re-addressing established virtual networks disrupts services and consumes significant effort.
For organisations with established IT functions
Implement formal address management tracking allocated ranges across all environments. IP Address Management (IPAM) tooling, whether cloud-native or third-party, prevents the conflicts that emerge when multiple teams independently select address ranges.
Establish network segmentation aligned with data classification. Sensitive workloads (beneficiary data, protection cases, financial systems) belong in isolated virtual networks with explicit connectivity to shared services. Document inter-network traffic flows and review them quarterly.
Deploy egress controls proportionate to risk. Organisations handling sensitive data benefit from web proxy filtering even with the operational complexity. The visibility into outbound traffic patterns proves valuable during security investigations.
Consider centralised network services (DNS, proxy, inspection) in a shared services virtual network. Transit gateway routing centralises traffic through these services without deploying them in each workload network.
For field-connected organisations
Hybrid connectivity design must account for variable field office bandwidth. A headquarters VPN concentrator serving field offices with 2 Mbps connections should not receive the same traffic engineering as one serving regional hubs with 100 Mbps dedicated links.
Implement WAN optimisation for field office traffic to cloud services. Caching proxies at field sites reduce repeated downloads. Protocol optimisation appliances or services reduce latency impact on interactive applications. These measures sit between field offices and the virtual network, not within the cloud network architecture itself, but the cloud architecture must accommodate them.
Design for connectivity interruptions. Applications serving field offices need graceful degradation when headquarters connectivity fails. Local caching, offline operation modes, and asynchronous synchronisation requirements flow back to how cloud networks route traffic and where data persists.