Cloud Networking

---
name: cloud-networking
description: "Cross-platform comparison and architecture guidance for cloud networking across AWS, Azure, and GCP: VPC/VNet design, hybrid connectivity, security groups, transit architectures, private service access, and multi-cloud networking patterns. Use for \"cloud networking\", \"VPC design\", \"VNet design\", \"hybrid cloud\", \"multi-cloud\", \"Transit Gateway vs vWAN\", \"security groups vs NSGs\", \"cloud interconnect\", \"PrivateLink\", \"cloud firewall\". Do NOT use for aws-vpc-, azure-vnet-, or gcp-vpc-specific configuration -- use that technology's own skill. Do NOT use for cloud compute, IAM, or account-level architecture -- that is the cloud-platforms plugin."
license: MIT
---

# Cloud Networking

This skill covers cloud networking technologies across AWS, Azure, and GCP, providing deep expertise in virtual network design, hybrid connectivity, cloud-native security controls, transit architectures, and multi-cloud networking patterns. Sibling cloud-platform technology skills provide detailed implementation guidance.

## When to Use This Skill vs. a Technology Skill

**Use this skill when the question is cross-cloud, comparative, or architectural:**
- "Compare AWS VPC vs Azure VNet vs GCP VPC architecture"
- "Design a multi-cloud connectivity strategy"
- "Security Groups vs NSGs vs GCP Firewall Rules -- what are the differences?"
- "Should I use Transit Gateway or VPC peering?"
- "Plan a CIDR allocation strategy across three clouds"
- "How does private service access differ across clouds?"

**Route to a technology skill when the question is cloud-specific:**
- "Configure a Transit Gateway with route table segmentation" --> the `aws-vpc` skill
- "Set up Azure Firewall Premium with TLS inspection" --> the `azure-vnet` skill
- "Configure GCP HA VPN to AWS" --> the `gcp-vpc` skill

## How to Approach Tasks

1. **Classify** the request:
   - **Architecture / Design** -- Load `references/concepts.md` for shared responsibility, VPC patterns, hybrid connectivity
   - **Cloud comparison** -- Compare relevant cloud constructs, then route for implementation
   - **Troubleshooting** -- Identify the cloud provider, then consult the appropriate technology skill
   - **Multi-cloud** -- Assess connectivity requirements across providers
   - **Migration** -- Evaluate source/target cloud and hybrid connectivity options

2. **Gather context** -- Cloud provider(s), scale (VPCs/VNets, subnets, endpoints), traffic patterns (internet egress, inter-VPC, hybrid), compliance requirements, existing on-premises infrastructure

3. **Analyze** -- Apply cloud networking principles. Consider shared responsibility model, provider-specific limitations, cost implications, and operational complexity.

4. **Recommend** -- Provide specific guidance with provider trade-offs and cost awareness

5. **Qualify** -- State assumptions about scale, compliance, and traffic patterns

## Cloud Provider Comparison

### Virtual Network Fundamentals

| Aspect | AWS VPC | Azure VNet | GCP VPC |
|---|---|---|---|
| **Scope** | Regional | Regional | Global |
| **Subnets** | AZ-scoped | Regional (AZ-aware) | Regional |
| **Reserved IPs** | 5 per subnet | 5 per subnet | 4 per subnet |
| **Max CIDRs** | 5 per VPC (secondary) | Multiple address spaces | Multiple subnets per VPC |
| **IPv6** | Dual-stack supported | Dual-stack supported | Dual-stack supported |
| **Default isolation** | VPC is isolated | VNet is isolated | VPC is isolated |
| **Cross-region** | Requires peering/TGW | Requires peering/vWAN | Native (global VPC) |

### Security Controls

| Aspect | AWS | Azure | GCP |
|---|---|---|---|
| **Instance-level** | Security Groups (stateful) | NSGs at NIC + subnet (stateful) | VPC Firewall Rules (stateful) |
| **Subnet-level** | NACLs (stateless) | NSGs at subnet | VPC Firewall Rules (tag-based) |
| **Organization-level** | AWS Firewall Manager | Azure Policy + Firewall Manager | Hierarchical Firewall Policies |
| **Managed firewall** | AWS Network Firewall | Azure Firewall (Standard/Premium) | Cloud Armor (L7) |
| **WAF** | AWS WAF | Azure WAF (AFD/AppGW) | Cloud Armor |
| **DDoS** | Shield Standard/Advanced | DDoS Protection Standard | Cloud Armor (always-on) |
| **Group abstraction** | SG references | Application Security Groups | Network tags / Service accounts |

### Transit Architecture

| Aspect | AWS | Azure | GCP |
|---|---|---|---|
| **Hub service** | Transit Gateway (TGW) | Virtual WAN (vWAN) | Network Connectivity Center (NCC) |
| **Max attachments** | 5,000 per TGW | Varies by hub type | Hub + spokes model |
| **Routing** | TGW route tables | vWAN routing policies | NCC route tables |
| **Segmentation** | Multiple route tables | Routing intent policies | Export filters per spoke |
| **Cross-region** | TGW peering (non-transitive) | Multi-hub vWAN | Native (global VPC) |
| **Firewall integration** | TGW + Network Firewall | Secured Virtual Hub | NCC + Cloud Armor |

### Hybrid Connectivity

| Aspect | AWS | Azure | GCP |
|---|---|---|---|
| **Dedicated line** | Direct Connect (1/10/100G) | ExpressRoute (50M-100G) | Cloud Interconnect (10/100G) |
| **VPN** | Site-to-site VPN (~1.25 Gbps) | VPN Gateway (1-10 Gbps) | HA VPN (3 Gbps per tunnel) |
| **SD-WAN integration** | TGW Connect | vWAN NVA | NCC SD-WAN spoke |
| **Private service access** | PrivateLink | Private Link | Private Service Connect |

### Cost Considerations

| Cost Factor | AWS | Azure | GCP |
|---|---|---|---|
| **Inter-AZ traffic** | Charged | Free (same region) | Free (same region) |
| **Inter-region traffic** | Charged | Charged | Charged |
| **NAT Gateway** | Per-hour + per-GB | Included in Azure Firewall | Per-hour + per-GB |
| **Transit hub** | Per-attachment + per-GB | Per-hub + per-GB | Per-spoke + per-GB |
| **VPN** | Per-hour + per-GB | Per-hour + per-GB | Per-hour + per-GB |

**Key cost insight**: AWS charges for inter-AZ data transfer ($0.01/GB each direction). This significantly impacts architectures that spread services across AZs. Azure and GCP do not charge for intra-region cross-AZ traffic.

## Design Principles

### CIDR Planning

- Allocate non-overlapping address spaces across all environments (on-prem, AWS, Azure, GCP)
- Overlapping CIDRs prevent VPC/VNet peering and complicate routing
- Use RFC 1918 ranges: 10.0.0.0/8 provides the largest space
- Reserve ranges for growth: do not allocate /16 per VPC if /20 suffices
- Document all allocations in a central IPAM system

**Example allocation strategy:**
```
On-premises:  10.0.0.0/8
AWS:          172.16.0.0/12
Azure:        192.168.0.0/16
GCP:          100.64.0.0/10 (CGN range, or use remaining 172.x)
```

### Hub-and-Spoke Pattern

Use transit hubs (TGW, vWAN, NCC) as central interconnection points:
- Spoke VPCs/VNets connect only to the hub -- no direct spoke-to-spoke peering
- Hub provides centralized routing, security inspection, and logging
- Segmentation via route tables (Dev/Staging/Prod isolation)
- Reduces peering complexity from O(n^2) to O(n)

### Private Service Access

Prefer PrivateLink / Private Link / PSC over VPC peering for service exposure:
- Reduces blast radius (no full network connectivity)
- Consumer sees only a private endpoint IP, not the provider's network
- Cross-account and cross-region supported on all providers
- Provider controls access via approval workflows

### Egress Control

Centralize internet egress through managed NAT/firewall services:
- AWS: NAT Gateway per AZ + optional AWS Network Firewall
- Azure: Azure Firewall (force-tunnel all subnets via UDR)
- GCP: Cloud NAT per region
- Enables consistent logging, URL filtering, and threat detection on outbound traffic

### Security Group Hygiene

- Avoid `0.0.0.0/0` (any) in source/destination rules
- Use security group references (AWS), ASGs (Azure), or network tags (GCP) instead of IP addresses
- Review and remove unused rules quarterly
- Use service tags (Azure) or managed prefix lists (AWS) for cloud service IP ranges
- Implement least-privilege: only allow required ports and protocols

## Multi-Cloud Connectivity Patterns

### VPN Mesh

Simplest approach for connecting clouds:
- AWS VPN <-> Azure VPN Gateway, AWS VPN <-> GCP HA VPN, etc.
- BGP-based dynamic routing preferred over static routes
- Bandwidth limited by VPN tunnel capacity (1-10 Gbps depending on provider)
- Use case: Low-bandwidth, cost-sensitive multi-cloud connectivity

### Dedicated Interconnect via Colo

Enterprise-grade multi-cloud connectivity:
- Establish presence at a colocation facility (Equinix, Megaport, etc.)
- Direct Connect, ExpressRoute, and Cloud Interconnect all terminate at the colo
- Cross-connect between providers at the colo for low-latency, high-bandwidth connectivity
- Use case: Production workloads requiring consistent latency and high throughput

### Cloud Exchange / Virtual Interconnect

Managed multi-cloud connectivity:
- Megaport, Equinix Fabric, or similar cloud exchange services
- Virtual cross-connects between cloud providers without physical colo presence
- Pay-per-use pricing with flexible bandwidth
- Use case: Agile multi-cloud connectivity without long-term infrastructure commitment

## Technology Routing

| Request Pattern | Route To |
|---|---|
| AWS VPC, Security Groups, TGW, Direct Connect, PrivateLink | the `aws-vpc` skill |
| Azure VNet, NSGs, Azure Firewall, vWAN, ExpressRoute | the `azure-vnet` skill |
| GCP VPC, Firewall Rules, Cloud NAT, Cloud Armor, NCC | the `gcp-vpc` skill |

## Common Pitfalls

1. **Overlapping CIDRs** -- The most common multi-cloud networking mistake. Plan CIDR allocation before deploying the first VPC. Remediation after the fact requires network address translation or re-IP'ing workloads.

2. **Ignoring inter-AZ data transfer costs (AWS)** -- Applications that chatty-communicate across AZs in AWS incur significant data transfer charges. Place tightly coupled services in the same AZ or use placement groups.

3. **Confusing stateful vs stateless security** -- Security Groups (AWS/Azure NSG) are stateful; NACLs (AWS) are stateless. Mixing up these models leads to puzzling connectivity issues where return traffic is blocked.

4. **Not using transit hubs at scale** -- VPC/VNet peering is non-transitive. At 10+ VPCs, peering becomes unmanageable. Use TGW/vWAN/NCC from the start for any environment that will grow.

5. **Exposed management ports** -- SSH (22) and RDP (3389) open to 0.0.0.0/0 is the most exploited misconfiguration in cloud networking. Use bastion hosts, SSM Session Manager, or Azure Bastion instead.

6. **NAT Gateway as bottleneck** -- A single NAT Gateway in one AZ creates a single point of failure and potential bandwidth bottleneck. Deploy one per AZ for HA.

7. **GCP global VPC misconception** -- GCP VPC is global, but subnets are regional. Resources in different regions can communicate within the same VPC without peering, but firewall rules and NAT are still regional.

## Reference Files

- `references/concepts.md` -- Shared responsibility model, VPC design patterns, hybrid connectivity fundamentals, security groups vs ACLs. Read for architecture and design questions.