Cloud Networking Done Right: Best Practices for AWS, Azure, and GCP

Master the fundamentals of cloud networking with this comprehensive guide. Learn how to properly architect network solutions across AWS, Azure, and Google Cloud for security, performance, and cost-effectiveness.

Rishi Parikh

Author

Vinay Adiga

Author

Jun 22, 2024

29 min read

The Foundation of Cloud Architecture

When building in the cloud, networking is the foundation upon which everything else rests. A well-designed network architecture ensures security, performance, scalability, and cost-effectiveness. However, poor networking decisions can lead to security vulnerabilities, operational bottlenecks, and unexpected costs that compound over time.

Each major cloud provider—AWS, Azure, and Google Cloud—offers its own unique networking services and paradigms. While they share many conceptual similarities, the implementation details, terminology, and best practices can vary significantly. This comprehensive guide will walk you through fundamental networking concepts across cloud providers and provide concrete, actionable guidance for architecting robust cloud networks.

Core Networking Components

Before diving into platform-specific details, let’s establish a common vocabulary and understanding of core networking components:

Virtual Networks: The Foundation

The virtual network is the fundamental building block of cloud networking, providing isolated environments for your resources.

AWS Virtual Private Cloud (VPC): A logically isolated section of the AWS cloud where you can launch resources in a virtual network you define.
Azure Virtual Network (VNet): The fundamental building block for your private network in Azure, enabling Azure resources to securely communicate with each other, the internet, and on-premises networks.
Google Cloud Virtual Private Cloud (VPC): A global private network that provides networking functionality for Compute Engine VM instances, GKE clusters, and serverless services.

Subnets: Effective Network Segmentation

Subnets divide your virtual network into smaller, manageable segments, enabling you to organize resources and apply different security policies.

AWS Subnets: Must reside entirely within one Availability Zone and cannot span zones. Subnets can be public (with internet access) or private.
Azure Subnets: Segments of a VNet with their own security and routing policies. Unlike AWS, a subnet in Azure can span availability zones.
Google Cloud Subnets: Regional resources that represent a range of IP addresses in a VPC network. Each subnet is associated with a region.

Routing: Controlling Traffic Flow

Routing tables define how traffic flows between subnets, virtual networks, and external destinations.

AWS Route Tables: Control traffic between subnets and to/from internet gateways, virtual private gateways, transit gateways, and other VPC endpoints.
Azure Route Tables: Define the rules (routes) that determine where network traffic is directed. Each subnet can have zero or one route table associated with it.
Google Cloud Routes: Global resources attached to a single VPC network that specify how packets should be forwarded within the network.

Internet Connectivity: Secure Access

Securely connecting your cloud resources to the internet is a fundamental requirement for most applications.

AWS Internet Connectivity: Achieved through Internet Gateways, NAT Gateways, and Elastic IPs.
Azure Internet Connectivity: Provided via Public IP addresses, NAT Gateway, and Azure Firewall.
Google Cloud Internet Connectivity: Implemented through external IP addresses, Cloud NAT, and Cloud Firewall.

Private Connectivity: Hybrid Cloud

Connecting your on-premises network with your cloud environment is essential for hybrid cloud architectures.

AWS Private Connectivity: Options include Direct Connect, Site-to-Site VPN, and Transit Gateway.
Azure Private Connectivity: Enabled through ExpressRoute, VPN Gateway, and Virtual WAN.
Google Cloud Private Connectivity: Available via Dedicated Interconnect, Partner Interconnect, and Cloud VPN.

Network Security: Defense in Depth

Protecting your network requires multiple layers of security controls.

AWS Network Security: Implemented through Security Groups, Network ACLs, and AWS Network Firewall.
Azure Network Security: Enforced via Network Security Groups, Application Security Groups, and Azure Firewall.
Google Cloud Network Security: Managed with VPC Firewall Rules, Cloud Armor, and Security Command Center.

Cloud Provider Comparison: Key Differences

While the core concepts are similar, important differences exist in implementation, scalability, and management.

Architecture and Scope

AWS VPC: Regional construct with subnets in specific Availability Zones.
Azure VNet: Regional resource that can span availability zones.
Google Cloud VPC: Global resource with regional subnets, offering unique global networking capabilities.

IP Addressing

AWS: Supports IPv4 and dual-stack (IPv4+IPv6). VPCs require a CIDR block specification.
Azure: Supports IPv4 and dual-stack architectures. Address space is defined at the VNet level.
Google Cloud: Supports IPv4 and dual-stack, with unique capabilities for internal IPv6 addresses.

Network Performance

AWS: Network bandwidth scales with instance size. Enhanced networking options available.
Azure: Accelerated networking provides low latency, reduced jitter, and low CPU utilization.
Google Cloud: Tier_1 networking offers best performance. VM bandwidth scales with vCPU count.

Pricing Models

AWS: Charges for NAT gateways, VPN connections, data transfer, and certain VPC endpoints.
Azure: Charges for public IP addresses, VPN gateways, NAT gateways, and outbound data transfer.
Google Cloud: Charges for IP addresses, Cloud NAT, load balancers, and a network tiered pricing model.

Essential Best Practices Across All Providers

Regardless of your cloud provider, these core principles will help you design robust, secure, and efficient networks:

1. Implement Proper Network Segmentation

Use separate subnets for different application tiers (web, application, database).
Isolate production, testing, and development environments in different VPCs/VNets where possible.
Follow the principle of least privilege when defining connectivity between segments.

Example subnet allocation in AWS:

VPC CIDR: 10.0.0.0/16

Production:
  - Public Web tier: 10.0.0.0/24, 10.0.1.0/24 (multiple AZs)
  - Private App tier: 10.0.16.0/24, 10.0.17.0/24
  - Private Data tier: 10.0.32.0/24, 10.0.33.0/24

Staging:
  - Public Web tier: 10.0.64.0/24, 10.0.65.0/24
  - Private App tier: 10.0.80.0/24, 10.0.81.0/24
  - Private Data tier: 10.0.96.0/24, 10.0.97.0/24

2. Plan IP Address Space Carefully

Allocate non-overlapping CIDR blocks between environments and on-premises networks.
Leave room for growth when assigning subnets.
Document your IP allocation strategy to avoid future conflicts.

3. Implement Defense in Depth

Use multiple security layers (network ACLs, security groups/firewall rules, application firewalls).
Deny by default and allow only required traffic.
Implement network traffic inspection for critical segments.

4. Optimize for Cost

Understand data transfer costs between regions, zones, and to the internet.
Use private endpoints/service endpoints where available to reduce data transfer costs.
Implement VPC/VNet peering for internal communication where appropriate.

5. Design for High Availability

Distribute resources across multiple availability zones.
Design redundant network paths.
Implement appropriate failover mechanisms for networking components.

6. Document Network Architecture

Maintain up-to-date network diagrams.
Document IP address allocations, routing rules, and security policies.
Use Infrastructure as Code (IaC) to enforce documentation.

Provider-Specific Best Practices

AWS Networking Best Practices

VPC Design

Size your VPC appropriately: Use a CIDR block that provides enough IP addresses for future growth.
Create subnet tiers: Public subnets for internet-facing resources, private subnets for internal resources.
Implement Transit Gateway for hub-and-spoke network architectures connecting multiple VPCs.
Consider VPC endpoints: Use Gateway and Interface endpoints to access AWS services privately.
Utilize multiple Availability Zones: Design your network to span at least three AZs for high availability.

Understanding and Choosing CIDR Blocks

CIDR (Classless Inter-Domain Routing) notation is a fundamental concept for cloud networking. A CIDR block consists of an IP address followed by a forward slash and a prefix length (e.g., 10.0.0.0/16). The prefix length determines how many IP addresses are available:

/16 provides 65,536 IP addresses (commonly used for VPCs)
/20 provides 4,096 IP addresses (often used for medium-sized subnets)
/24 provides 256 IP addresses (common for smaller subnets)
/28 provides 16 IP addresses (used for small, specialized subnets)

When choosing CIDR blocks for your AWS environment:

Plan for scale: Select a VPC CIDR that accommodates your growth (usually /16 to /20).
Avoid overlaps: Ensure CIDR blocks don’t overlap with other VPCs, on-premises networks, or cloud environments.
Use private ranges: Stick to private IP ranges (10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16).
Reserve space: A common practice is to allocate the first portion of your VPC CIDR for public subnets, the middle for private application subnets, and the latter portion for database or specialized workloads.
Document your scheme: Create a CIDR allocation document to track IP assignments across your organization.

Example of a well-planned CIDR allocation strategy:

Organization: 10.0.0.0/8

Production Environment: 10.0.0.0/12
  - US-East Region: 10.0.0.0/16
    * Public subnets: 10.0.0.0/20, 10.0.16.0/20, 10.0.32.0/20 (by AZ)
    * Private app subnets: 10.0.64.0/19, 10.0.96.0/19, 10.0.128.0/19 (by AZ)
    * Database subnets: 10.0.160.0/20, 10.0.176.0/20, 10.0.192.0/20 (by AZ)
    * Reserved future use: 10.0.208.0/20

Development Environment: 10.16.0.0/12
  - Dev VPCs: 10.16.0.0/16, 10.17.0.0/16, etc.

Testing Environment: 10.32.0.0/12
  - Test VPCs: 10.32.0.0/16, 10.33.0.0/16, etc.

Staging Environment: 10.48.0.0/12
  - Staging VPCs: 10.48.0.0/16, 10.49.0.0/16, etc.

Example VPC architecture in Terraform:

module "vpc" {
  source = "terraform-aws-modules/vpc/aws"
  version = "~> 3.0"

  name = "my-vpc"
  cidr = "10.0.0.0/16"

  azs             = ["us-west-2a", "us-west-2b", "us-west-2c"]
  private_subnets = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
  public_subnets  = ["10.0.101.0/24", "10.0.102.0/24", "10.0.103.0/24"]
  database_subnets = ["10.0.201.0/24", "10.0.202.0/24", "10.0.203.0/24"]

  enable_nat_gateway = true
  single_nat_gateway = false
  one_nat_gateway_per_az = true

  enable_vpn_gateway = false

  # VPC Endpoints for S3 and DynamoDB
  enable_s3_endpoint = true
  enable_dynamodb_endpoint = true

  # Additional VPC Endpoints for private AWS service access
  create_vpc_endpoints = true
  vpc_endpoint_gateway_services = ["s3", "dynamodb"]
  vpc_endpoint_interface_services = ["ec2", "ecr.api", "ecr.dkr", "logs", "ssm", "secretsmanager"]

  tags = {
    Environment = "production"
    Project     = "Example"
  }
}

# AWS Transit Gateway with multiple VPC attachments
resource "aws_ec2_transit_gateway" "main" {
  description                     = "Main Transit Gateway"
  default_route_table_association = "enable"
  default_route_table_propagation = "enable"
  tags = {
    Name = "main-transit-gateway"
  }
}

# Attach production VPC to Transit Gateway
resource "aws_ec2_transit_gateway_vpc_attachment" "production" {
  subnet_ids         = module.production_vpc.private_subnets
  transit_gateway_id = aws_ec2_transit_gateway.main.id
  vpc_id             = module.production_vpc.vpc_id

  tags = {
    Name = "tgw-attachment-production"
  }
}

# Attach staging VPC to Transit Gateway
resource "aws_ec2_transit_gateway_vpc_attachment" "staging" {
  subnet_ids         = module.staging_vpc.private_subnets
  transit_gateway_id = aws_ec2_transit_gateway.main.id
  vpc_id             = module.staging_vpc.vpc_id

  tags = {
    Name = "tgw-attachment-staging"
  }
}

# Create routes between VPCs via Transit Gateway
resource "aws_route" "production_to_staging" {
  count                  = length(module.production_vpc.private_route_table_ids)
  route_table_id         = module.production_vpc.private_route_table_ids[count.index]
  destination_cidr_block = module.staging_vpc.vpc_cidr_block
  transit_gateway_id     = aws_ec2_transit_gateway.main.id
}

Security

Use both security groups (stateful) and NACLs (stateless) for defense in depth.
Implement VPC Flow Logs for network traffic analysis and troubleshooting.
Use AWS Network Firewall for additional protection of sensitive workloads.
Apply AWS PrivateLink to securely connect services across different VPCs.
Implement AWS WAF for web application protection against common exploits.

Example Security Group configuration:

# Web tier security group
resource "aws_security_group" "web_tier" {
  name        = "web-tier-sg"
  description = "Security group for web tier"
  vpc_id      = module.vpc.vpc_id

  # Allow HTTPS from anywhere
  ingress {
    description = "HTTPS from internet"
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  # Allow HTTP from anywhere (could be restricted in production)
  ingress {
    description = "HTTP from internet"
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  # Outbound access to application tier only
  egress {
    description     = "Access to app tier"
    from_port       = 8080
    to_port         = 8080
    protocol        = "tcp"
    security_groups = [aws_security_group.app_tier.id]
  }
}

# Application tier security group
resource "aws_security_group" "app_tier" {
  name        = "app-tier-sg"
  description = "Security group for application tier"
  vpc_id      = module.vpc.vpc_id

  # Only allow traffic from web tier
  ingress {
    description     = "Access from web tier"
    from_port       = 8080
    to_port         = 8080
    protocol        = "tcp"
    security_groups = [aws_security_group.web_tier.id]
  }

  # Outbound access to database tier only
  egress {
    description     = "Access to database tier"
    from_port       = 5432
    to_port         = 5432
    protocol        = "tcp"
    security_groups = [aws_security_group.db_tier.id]
  }
}

# Database tier security group
resource "aws_security_group" "db_tier" {
  name        = "db-tier-sg"
  description = "Security group for database tier"
  vpc_id      = module.vpc.vpc_id

  # Only allow traffic from application tier
  ingress {
    description     = "PostgreSQL from app tier"
    from_port       = 5432
    to_port         = 5432
    protocol        = "tcp"
    security_groups = [aws_security_group.app_tier.id]
  }

  # No outbound access
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

# VPC Flow Logs Configuration
resource "aws_flow_log" "vpc_flow_logs" {
  log_destination      = aws_cloudwatch_log_group.flow_logs.arn
  log_destination_type = "cloud-watch-logs"
  traffic_type         = "ALL"
  vpc_id               = module.vpc.vpc_id

  tags = {
    Name = "vpc-flow-logs"
  }
}

resource "aws_cloudwatch_log_group" "flow_logs" {
  name = "/aws/vpc-flow-log/main-vpc"
  retention_in_days = 90

  tags = {
    Name = "vpc-flow-logs"
  }
}

Connectivity

Use VPC endpoints for private connectivity to AWS services.
Implement Direct Connect for high-bandwidth, low-latency connections to on-premises.
Use Transit Gateway for simplified connectivity between multiple VPCs and on-premises networks.
Configure VPC peering for direct network routing between VPCs.
Implement AWS Client VPN for secure remote access to your VPC.

Example Direct Connect and Transit Gateway configuration:

# Direct Connect Gateway
resource "aws_dx_gateway" "main" {
  name            = "main-dx-gateway"
  amazon_side_asn = 64512
}

# Direct Connect Connection
resource "aws_dx_connection" "main" {
  name            = "main-dx-connection"
  bandwidth       = "1Gbps"
  location        = "EqDC2"
  provider_name   = "Example Provider"
}

# Direct Connect Virtual Interface
resource "aws_dx_private_virtual_interface" "main" {
  connection_id    = aws_dx_connection.main.id
  name             = "main-private-vif"
  vlan             = 100
  address_family   = "ipv4"
  bgp_asn          = 65000
  amazon_address   = "169.254.0.1/30"
  customer_address = "169.254.0.2/30"
  dx_gateway_id    = aws_dx_gateway.main.id
}

# Associate Direct Connect Gateway with Transit Gateway
resource "aws_dx_gateway_association" "main" {
  dx_gateway_id         = aws_dx_gateway.main.id
  associated_gateway_id = aws_ec2_transit_gateway.main.id

  allowed_prefixes = [
    "10.0.0.0/8",
    "172.16.0.0/12",
    "192.168.0.0/16"
  ]
}

# Site-to-Site VPN as backup for Direct Connect
resource "aws_vpn_connection" "main" {
  customer_gateway_id = aws_customer_gateway.main.id
  transit_gateway_id  = aws_ec2_transit_gateway.main.id
  type                = "ipsec.1"

  static_routes_only = false

  tags = {
    Name = "main-vpn-connection"
  }
}

resource "aws_customer_gateway" "main" {
  bgp_asn    = 65000
  ip_address = "203.0.113.1"
  type       = "ipsec.1"

  tags = {
    Name = "main-customer-gateway"
  }
}

Azure Networking Best Practices

VNet Design

Plan your address space carefully: Ensure it doesn’t overlap with other networks.
Implement hub-and-spoke topology using VNet peering or Azure Virtual WAN for large deployments.
Use Network Security Groups (NSGs) at both the subnet and NIC levels.
Create dedicated subnets for different services (App Service, Azure Functions, Azure SQL, etc.).
Utilize service endpoints to provide secure, direct connectivity to Azure services.

Example hub-and-spoke architecture using Bicep:

// Hub VNet with Azure Firewall
resource hubVnet 'Microsoft.Network/virtualNetworks@2022-07-01' = {
  name: 'hub-vnet'
  location: location
  properties: {
    addressSpace: {
      addressPrefixes: [
        '10.0.0.0/16'
      ]
    }
    subnets: [
      {
        name: 'AzureFirewallSubnet'
        properties: {
          addressPrefix: '10.0.0.0/26'
        }
      }
      {
        name: 'GatewaySubnet'
        properties: {
          addressPrefix: '10.0.1.0/27'
        }
      }
      {
        name: 'BastionSubnet'
        properties: {
          addressPrefix: '10.0.2.0/26'
        }
      }
      {
        name: 'ManagementSubnet'
        properties: {
          addressPrefix: '10.0.3.0/24'
          networkSecurityGroup: {
            id: managementNsg.id
          }
          routeTable: {
            id: firewallRouteTable.id
          }
        }
      }
    ]
  }
}

// Spoke VNet 1: Web Applications
resource spokeVnet1 'Microsoft.Network/virtualNetworks@2022-07-01' = {
  name: 'web-spoke-vnet'
  location: location
  properties: {
    addressSpace: {
      addressPrefixes: [
        '10.1.0.0/16'
      ]
    }
    subnets: [
      {
        name: 'WebSubnet'
        properties: {
          addressPrefix: '10.1.0.0/24'
          networkSecurityGroup: {
            id: webNsg.id
          }
          routeTable: {
            id: firewallRouteTable.id
          }
          serviceEndpoints: [
            {
              service: 'Microsoft.Web'
              locations: [
                '*'
              ]
            }
          ]
        }
      }
      {
        name: 'AppSubnet'
        properties: {
          addressPrefix: '10.1.1.0/24'
          networkSecurityGroup: {
            id: appNsg.id
          }
          routeTable: {
            id: firewallRouteTable.id
          }
          delegations: [
            {
              name: 'appServiceDelegation'
              properties: {
                serviceName: 'Microsoft.Web/serverFarms'
              }
            }
          ]
        }
      }
    ]
  }
}

// Spoke VNet 2: Data Services
resource spokeVnet2 'Microsoft.Network/virtualNetworks@2022-07-01' = {
  name: 'data-spoke-vnet'
  location: location
  properties: {
    addressSpace: {
      addressPrefixes: [
        '10.2.0.0/16'
      ]
    }
    subnets: [
      {
        name: 'SqlSubnet'
        properties: {
          addressPrefix: '10.2.0.0/24'
          networkSecurityGroup: {
            id: dataNsg.id
          }
          routeTable: {
            id: firewallRouteTable.id
          }
          serviceEndpoints: [
            {
              service: 'Microsoft.Sql'
              locations: [
                '*'
              ]
            }
          ]
        }
      }
      {
        name: 'StorageSubnet'
        properties: {
          addressPrefix: '10.2.1.0/24'
          networkSecurityGroup: {
            id: dataNsg.id
          }
          routeTable: {
            id: firewallRouteTable.id
          }
          serviceEndpoints: [
            {
              service: 'Microsoft.Storage'
              locations: [
                '*'
              ]
            }
          ]
        }
      }
    ]
  }
}

// VNet Peering: Hub to Spoke 1
resource hubToSpoke1Peering 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2022-07-01' = {
  parent: hubVnet
  name: 'hub-to-web-spoke'
  properties: {
    allowVirtualNetworkAccess: true
    allowForwardedTraffic: true
    allowGatewayTransit: true
    useRemoteGateways: false
    remoteVirtualNetwork: {
      id: spokeVnet1.id
    }
  }
}

// VNet Peering: Spoke 1 to Hub
resource spoke1ToHubPeering 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings@2022-07-01' = {
  parent: spokeVnet1
  name: 'web-spoke-to-hub'
  properties: {
    allowVirtualNetworkAccess: true
    allowForwardedTraffic: true
    allowGatewayTransit: false
    useRemoteGateways: true
    remoteVirtualNetwork: {
      id: hubVnet.id
    }
  }
}

// Route Table for forcing traffic through Firewall
resource firewallRouteTable 'Microsoft.Network/routeTables@2022-07-01' = {
  name: 'firewall-route-table'
  location: location
  properties: {
    routes: [
      {
        name: 'to-internet-via-firewall'
        properties: {
          addressPrefix: '0.0.0.0/0'
          nextHopType: 'VirtualAppliance'
          nextHopIpAddress: azureFirewall.properties.ipConfigurations[0].properties.privateIPAddress
        }
      }
    ]
  }
}

Example Azure CLI for hub-and-spoke implementation:

# Create Hub VNet
az network vnet create \
  --name Hub-VNet \
  --resource-group MyResourceGroup \
  --address-prefixes 10.0.0.0/16 \
  --subnet-name GatewaySubnet \
  --subnet-prefix 10.0.0.0/24

# Create Azure Firewall Subnet
az network vnet subnet create \
  --name AzureFirewallSubnet \
  --resource-group MyResourceGroup \
  --vnet-name Hub-VNet \
  --address-prefix 10.0.1.0/26

# Create Spoke VNet for Workloads
az network vnet create \
  --name Spoke1-VNet \
  --resource-group MyResourceGroup \
  --address-prefixes 10.1.0.0/16 \
  --subnet-name WorkloadSubnet \
  --subnet-prefix 10.1.0.0/24

# Create Spoke VNet for Data services
az network vnet create \
  --name Spoke2-VNet \
  --resource-group MyResourceGroup \
  --address-prefixes 10.2.0.0/16 \
  --subnet-name DataSubnet \
  --subnet-prefix 10.2.0.0/24

# Peer Hub to Spoke 1
az network vnet peering create \
  --name HubToSpoke1 \
  --resource-group MyResourceGroup \
  --vnet-name Hub-VNet \
  --remote-vnet Spoke1-VNet \
  --allow-vnet-access \
  --allow-forwarded-traffic \
  --allow-gateway-transit

# Peer Spoke 1 to Hub
az network vnet peering create \
  --name Spoke1ToHub \
  --resource-group MyResourceGroup \
  --vnet-name Spoke1-VNet \
  --remote-vnet Hub-VNet \
  --allow-vnet-access \
  --allow-forwarded-traffic \
  --use-remote-gateways

Security

Use Azure Firewall for centralized network traffic filtering.
Implement Private Link for secure access to Azure PaaS services.
Enable Azure DDoS Protection for critical workloads.
Configure Azure Bastion for secure management access to VMs.
Use Just-In-Time VM Access to reduce attack surface.

Example NSG configuration with Bicep:

// Web tier NSG
resource webNsg 'Microsoft.Network/networkSecurityGroups@2022-07-01' = {
  name: 'web-nsg'
  location: location
  properties: {
    securityRules: [
      {
        name: 'allow-https-inbound'
        properties: {
          description: 'Allow HTTPS inbound'
          protocol: 'Tcp'
          sourcePortRange: '*'
          destinationPortRange: '443'
          sourceAddressPrefix: 'Internet'
          destinationAddressPrefix: '*'
          access: 'Allow'
          priority: 100
          direction: 'Inbound'
        }
      }
      {
        name: 'allow-http-inbound'
        properties: {
          description: 'Allow HTTP inbound'
          protocol: 'Tcp'
          sourcePortRange: '*'
          destinationPortRange: '80'
          sourceAddressPrefix: 'Internet'
          destinationAddressPrefix: '*'
          access: 'Allow'
          priority: 110
          direction: 'Inbound'
        }
      }
      {
        name: 'deny-all-inbound'
        properties: {
          description: 'Deny all inbound traffic'
          protocol: '*'
          sourcePortRange: '*'
          destinationPortRange: '*'
          sourceAddressPrefix: '*'
          destinationAddressPrefix: '*'
          access: 'Deny'
          priority: 4096
          direction: 'Inbound'
        }
      }
    ]
  }
}

// Application tier NSG
resource appNsg 'Microsoft.Network/networkSecurityGroups@2022-07-01' = {
  name: 'app-nsg'
  location: location
  properties: {
    securityRules: [
      {
        name: 'allow-web-tier'
        properties: {
          description: 'Allow traffic from web tier'
          protocol: 'Tcp'
          sourcePortRange: '*'
          destinationPortRange: '8080'
          sourceAddressPrefix: '10.1.0.0/24' // Web tier subnet
          destinationAddressPrefix: '*'
          access: 'Allow'
          priority: 100
          direction: 'Inbound'
        }
      }
      {
        name: 'deny-all-inbound'
        properties: {
          description: 'Deny all other inbound traffic'
          protocol: '*'
          sourcePortRange: '*'
          destinationPortRange: '*'
          sourceAddressPrefix: '*'
          destinationAddressPrefix: '*'
          access: 'Deny'
          priority: 4096
          direction: 'Inbound'
        }
      }
    ]
  }
}

// Azure Firewall Policy
resource firewallPolicy 'Microsoft.Network/firewallPolicies@2022-07-01' = {
  name: 'fw-policy'

  properties: {
    threatIntelMode: 'Alert'
    sku: {
      tier: 'Standard'
    }
  }
}

// Application Rule Collection Group
resource applicationRuleCollectionGroup 'Microsoft.Network/firewallPolicies/ruleCollectionGroups@2022-07-01' = {
  parent: firewallPolicy
  name: 'app-rule-collection-group'
  properties: {
    priority: 300
    ruleCollections: [
      {
        ruleCollectionType: 'FirewallPolicyFilterRuleCollection'
        name: 'app-rule-collection'
        priority: 100
        action: {
          type: 'Allow'
        }
        rules: [
          {
            ruleType: 'ApplicationRule'
            name: 'allow-microsoft-services'
            protocols: [
              {
                port: 443
                protocolType: 'Https'
              }
            ]
            targetFqdns: [
              '*.microsoft.com'
            ]
            sourceAddresses: [
              '10.0.0.0/8'
            ]
          }
          {
            ruleType: 'ApplicationRule'
            name: 'allow-azure-services'
            protocols: [
              {
                port: 443
                protocolType: 'Https'
              }
            ]
            targetFqdns: [
              '*.azure.com'
            ]
            sourceAddresses: [
              '10.0.0.0/8'
            ]
          }
        ]
      }
    ]
  }
}

// Network Rule Collection Group
resource networkRuleCollectionGroup 'Microsoft.Network/firewallPolicies/ruleCollectionGroups@2022-07-01' = {
  parent: firewallPolicy
  name: 'network-rule-collection-group'
  properties: {
    priority: 200
    ruleCollections: [
      {
        ruleCollectionType: 'FirewallPolicyFilterRuleCollection'
        name: 'network-rule-collection'
        priority: 100
        action: {
          type: 'Allow'
        }
        rules: [
          {
            ruleType: 'NetworkRule'
            name: 'allow-dns'
            ipProtocols: [
              'UDP'
            ]
            sourceAddresses: [
              '10.0.0.0/8'
            ]
            destinationAddresses: [
              '168.63.129.16'
            ]
            destinationPorts: [
              '53'
            ]
          }
        ]
      }
    ]
  }
}

Connectivity

Use ExpressRoute for dedicated private connectivity to Microsoft cloud services.
Implement Azure Virtual WAN for optimized and automated branch-to-branch connectivity.
Use Azure Bastion for secure RDP and SSH access to your VMs.
Deploy Private Link services for secure access to PaaS offerings.
Implement Azure Front Door for global load balancing and WAF capabilities.

Example ExpressRoute and VPN configuration with Bicep:

// ExpressRoute Circuit
resource expressRouteCircuit 'Microsoft.Network/expressRouteCircuits@2022-07-01' = {
  name: 'my-expressroute-circuit'
  location: location
  sku: {
    name: 'Standard_MeteredData'
    tier: 'Standard'
    family: 'MeteredData'
  }
  properties: {
    serviceProviderProperties: {
      serviceProviderName: 'Equinix'
      peeringLocation: 'Silicon Valley'
      bandwidthInMbps: 1000
    }
    allowClassicOperations: false
    peeringLocation: 'Silicon Valley'
    circuitProvisioningState: 'Enabled'
  }
}

// ExpressRoute Gateway
resource expressRouteGateway 'Microsoft.Network/virtualNetworkGateways@2022-07-01' = {
  name: 'er-gateway'
  location: location
  properties: {
    gatewayType: 'ExpressRoute'
    vpnType: 'RouteBased'
    sku: {
      name: 'ErGw1AZ'
      tier: 'ErGw1AZ'
    }
    ipConfigurations: [
      {
        name: 'default'
        properties: {
          privateIPAllocationMethod: 'Dynamic'
          subnet: {
            id: resourceId('Microsoft.Network/virtualNetworks/subnets', hubVnet.name, 'GatewaySubnet')
          }
          publicIPAddress: {
            id: erGatewayPip.id
          }
        }
      }
    ]
    enableBgp: true
    activeActive: false
  }
}

// Public IP for ER Gateway
resource erGatewayPip 'Microsoft.Network/publicIPAddresses@2022-07-01' = {
  name: 'er-gateway-pip'
  location: location
  sku: {
    name: 'Standard'
  }
  properties: {
    publicIPAllocationMethod: 'Static'
    publicIPAddressVersion: 'IPv4'
  }
}

// VPN Gateway for backup connectivity
resource vpnGateway 'Microsoft.Network/virtualNetworkGateways@2022-07-01' = {
  name: 'vpn-gateway'
  location: location
  properties: {
    gatewayType: 'Vpn'
    vpnType: 'RouteBased'
    sku: {
      name: 'VpnGw1AZ'
      tier: 'VpnGw1AZ'
    }
    ipConfigurations: [
      {
        name: 'default'
        properties: {
          privateIPAllocationMethod: 'Dynamic'
          subnet: {
            id: resourceId('Microsoft.Network/virtualNetworks/subnets', hubVnet.name, 'GatewaySubnet')
          }
          publicIPAddress: {
            id: vpnGatewayPip.id
          }
        }
      }
    ]
    enableBgp: true
    activeActive: true
    vpnClientConfiguration: {
      vpnClientAddressPool: {
        addressPrefixes: [
          '172.16.0.0/24'
        ]
      }
      vpnClientProtocols: [
        'OpenVPN'
      ]
      vpnAuthenticationTypes: [
        'Certificate'
      ]
    }
  }
}

// Public IP for VPN Gateway
resource vpnGatewayPip 'Microsoft.Network/publicIPAddresses@2022-07-01' = {
  name: 'vpn-gateway-pip'
  location: location
  sku: {
    name: 'Standard'
  }
  properties: {
    publicIPAllocationMethod: 'Static'
    publicIPAddressVersion: 'IPv4'
  }
}

Google Cloud Networking Best Practices

VPC Design

Leverage the global nature of GCP VPCs to design simpler networks.
Use shared VPC for centralized network administration across multiple projects.
Implement VPC Service Controls to create security perimeters around resources.
Configure Private Service Access for Google-managed services.
Utilize VPC Flow Logs for network monitoring and troubleshooting.

Example VPC setup with Google Cloud SDK:

# Create custom VPC with global routing
gcloud compute networks create my-custom-network \
    --subnet-mode=custom \
    --bgp-routing-mode=global \
    --mtu=1460

# Create subnets in different regions
gcloud compute networks subnets create subnet-us-central1 \
    --network=my-custom-network \
    --region=us-central1 \
    --range=10.0.0.0/20 \
    --secondary-range=services=10.0.32.0/20,pods=10.0.64.0/20 \
    --enable-private-ip-google-access \
    --enable-flow-logs

gcloud compute networks subnets create subnet-europe-west1 \
    --network=my-custom-network \
    --region=europe-west1 \
    --range=10.1.0.0/20 \
    --secondary-range=services=10.1.32.0/20,pods=10.1.64.0/20 \
    --enable-private-ip-google-access \
    --enable-flow-logs

Example Shared VPC configuration:

# Set up host project for Shared VPC
gcloud compute shared-vpc enable host-project-id

# Associate service projects with the host
gcloud compute shared-vpc associated-projects add service-project-id-1 \
    --host-project host-project-id

gcloud compute shared-vpc associated-projects add service-project-id-2 \
    --host-project host-project-id

# Grant service project access to specific subnets
gcloud compute shared-vpc associated-projects get-iam-policy host-project-id

# Grant IAM roles
gcloud projects add-iam-policy-binding host-project-id \
    --member="serviceAccount:service-account@service-project-id-1.iam.gserviceaccount.com" \
    --role="roles/compute.networkUser"

Example Terraform configuration for GCP VPC:

# Create a VPC network
resource "google_compute_network" "vpc_network" {
  name                    = "vpc-network"
  auto_create_subnetworks = false
  routing_mode            = "GLOBAL"
  mtu                     = 1460
}

# Create subnets
resource "google_compute_subnetwork" "us_central1_subnet" {
  name          = "us-central1-subnet"
  ip_cidr_range = "10.0.0.0/20"
  region        = "us-central1"
  network       = google_compute_network.vpc_network.id

  secondary_ip_range {
    range_name    = "services"
    ip_cidr_range = "10.0.32.0/20"
  }

  secondary_ip_range {
    range_name    = "pods"
    ip_cidr_range = "10.0.64.0/20"
  }

  private_ip_google_access = true

  log_config {
    aggregation_interval = "INTERVAL_5_SEC"
    flow_sampling        = 0.5
    metadata             = "INCLUDE_ALL_METADATA"
  }
}

resource "google_compute_subnetwork" "europe_west1_subnet" {
  name          = "europe-west1-subnet"
  ip_cidr_range = "10.1.0.0/20"
  region        = "europe-west1"
  network       = google_compute_network.vpc_network.id

  secondary_ip_range {
    range_name    = "services"
    ip_cidr_range = "10.1.32.0/20"
  }

  secondary_ip_range {
    range_name    = "pods"
    ip_cidr_range = "10.1.64.0/20"
  }

  private_ip_google_access = true

  log_config {
    aggregation_interval = "INTERVAL_5_SEC"
    flow_sampling        = 0.5
    metadata             = "INCLUDE_ALL_METADATA"
  }
}

# VPC Peering
resource "google_compute_network_peering" "peering1" {
  name         = "peering-network1-to-network2"
  network      = google_compute_network.vpc_network.id
  peer_network = google_compute_network.vpc_network2.id

  import_custom_routes = true
  export_custom_routes = true
}

Network Security

Use hierarchical firewall policies for consistent security across the organization.
Implement Cloud Armor for protection against DDoS and application attacks.
Use VPC Service Controls to mitigate data exfiltration risks.
Enable IAP (Identity-Aware Proxy) for secure access to VMs and applications.
Configure Security Command Center for centralized security monitoring.

Example hierarchical firewall policy:

# Create organization firewall policy
gcloud compute network-firewall-policies create org-policy \
    --organization=ORGANIZATION_ID \
    --description="Organization-wide firewall policy"

# Add rules to the policy
gcloud compute network-firewall-policies rules create 1000 \
    --firewall-policy=org-policy \
    --organization=ORGANIZATION_ID \
    --description="Allow internal traffic" \
    --direction=INGRESS \
    --action=ALLOW \
    --src-ip-ranges=10.0.0.0/8 \
    --dest-ip-ranges=10.0.0.0/8 \
    --layer4-configs=all

gcloud compute network-firewall-policies rules create 2000 \
    --firewall-policy=org-policy \
    --organization=ORGANIZATION_ID \
    --description="Deny all ingress by default" \
    --direction=INGRESS \
    --action=DENY \
    --src-ip-ranges=0.0.0.0/0 \
    --dest-ip-ranges=0.0.0.0/0 \
    --layer4-configs=all \
    --priority=65000

Example VPC firewall rules with Terraform:

# Allow internal traffic between instances on the same network
resource "google_compute_firewall" "allow_internal" {
  name    = "allow-internal"
  network = google_compute_network.vpc_network.name

  allow {
    protocol = "tcp"
    ports    = ["0-65535"]
  }

  allow {
    protocol = "udp"
    ports    = ["0-65535"]
  }

  allow {
    protocol = "icmp"
  }

  source_ranges = ["10.0.0.0/8"]
}

# Allow SSH via IAP
resource "google_compute_firewall" "allow_iap_ssh" {
  name    = "allow-iap-ssh"
  network = google_compute_network.vpc_network.name

  allow {
    protocol = "tcp"
    ports    = ["22"]
  }

  source_ranges = ["35.235.240.0/20"] # IAP's IP range
}

# Allow HTTPS to frontend web servers
resource "google_compute_firewall" "allow_https" {
  name    = "allow-https"
  network = google_compute_network.vpc_network.name

  allow {
    protocol = "tcp"
    ports    = ["443"]
  }

  source_ranges = ["0.0.0.0/0"]
  target_tags   = ["web-server"]
}

# Cloud Armor Security Policy
resource "google_compute_security_policy" "security_policy" {
  name = "my-security-policy"

  # Block specified IP ranges
  rule {
    action   = "deny(403)"
    priority = "1000"
    match {
      versioned_expr = "SRC_IPS_V1"
      config {
        src_ip_ranges = ["203.0.113.0/24", "198.51.100.0/24"]
      }
    }
    description = "Block known malicious IPs"
  }

  # Rate limiting
  rule {
    action   = "rate_based_ban"
    priority = "2000"
    match {
      versioned_expr = "SRC_IPS_V1"
      config {
        src_ip_ranges = ["*"]
      }
    }
    rate_limit_options {
      conform_action = "allow"
      exceed_action  = "deny(429)"
      enforce_on_key = "IP"
      rate_limit_threshold {
        count        = 100
        interval_sec = 60
      }
    }
    description = "Rate limiting"
  }

  # Default rule
  rule {
    action   = "allow"
    priority = "2147483647"
    match {
      versioned_expr = "SRC_IPS_V1"
      config {
        src_ip_ranges = ["*"]
      }
    }
    description = "Default rule, higher priority overrides it"
  }
}

Connectivity

Use Cloud Interconnect for high-bandwidth connectivity to your data center.
Implement Private Service Connect for private access to Google and third-party services.
Use Cloud NAT for outbound internet access from instances without public IP addresses.
Configure Cloud VPN for secure tunnels to on-premises networks.
Utilize Cloud Router for dynamic route exchange with external networks.

Example Cloud Interconnect and Cloud Router configuration:

# Cloud Router for BGP session
resource "google_compute_router" "router" {
  name    = "my-cloud-router"
  network = google_compute_network.vpc_network.name
  region  = "us-central1"

  bgp {
    asn = 64514
  }
}

# Cloud NAT configuration
resource "google_compute_router_nat" "nat" {
  name                               = "my-cloud-nat"
  router                             = google_compute_router.router.name
  region                             = google_compute_router.router.region
  nat_ip_allocate_option             = "AUTO_ONLY"
  source_subnetwork_ip_ranges_to_nat = "ALL_SUBNETWORKS_ALL_IP_RANGES"

  log_config {
    enable = true
    filter = "ERRORS_ONLY"
  }
}

# Dedicated Interconnect
resource "google_compute_interconnect_attachment" "dedicated_interconnect" {
  name                     = "my-interconnect-attachment"
  region                   = "us-central1"
  type                     = "DEDICATED"
  router                   = google_compute_router.router.id
  interconnect             = "my-interconnect-id"
  vlan_tag8021q            = 1000
  bandwidth                = "BPS_10G"
  admin_enabled            = true

  # BGP configuration for the interconnect
  bgp {
    session_range               = "169.254.0.1/30"
    advertised_route_priority   = 100
    customer_router_ip_address  = "169.254.0.2"
  }
}

# Cloud VPN
resource "google_compute_ha_vpn_gateway" "vpn_gateway" {
  name = "ha-vpn-gateway"
  network = google_compute_network.vpc_network.id
  region  = "us-central1"
}

resource "google_compute_external_vpn_gateway" "external_gateway" {
  name            = "external-gateway"
  redundancy_type = "TWO_IPS_REDUNDANCY"

  interface {
    id         = 0
    ip_address = "203.0.113.1"
  }

  interface {
    id         = 1
    ip_address = "203.0.113.2"
  }
}

resource "google_compute_vpn_tunnel" "tunnel1" {
  name                  = "ha-vpn-tunnel1"
  region                = "us-central1"
  vpn_gateway           = google_compute_ha_vpn_gateway.vpn_gateway.id
  peer_external_gateway = google_compute_external_vpn_gateway.external_gateway.id

  shared_secret         = "a-very-secret-key"
  router                = google_compute_router.router.id
  vpn_gateway_interface = 0
  peer_external_gateway_interface = 0
}

resource "google_compute_vpn_tunnel" "tunnel2" {
  name                  = "ha-vpn-tunnel2"
  region                = "us-central1"
  vpn_gateway           = google_compute_ha_vpn_gateway.vpn_gateway.id
  peer_external_gateway = google_compute_external_vpn_gateway.external_gateway.id

  shared_secret         = "another-very-secret-key"
  router                = google_compute_router.router.id
  vpn_gateway_interface = 1
  peer_external_gateway_interface = 1
}

# Cloud Router BGP sessions for VPN tunnels
resource "google_compute_router_interface" "router_interface1" {
  name       = "router-interface1"
  router     = google_compute_router.router.name
  region     = google_compute_router.router.region
  ip_range   = "169.254.1.1/30"
  vpn_tunnel = google_compute_vpn_tunnel.tunnel1.name
}

resource "google_compute_router_peer" "router_peer1" {
  name                      = "router-peer1"
  router                    = google_compute_router.router.name
  region                    = google_compute_router.router.region
  peer_ip_address           = "169.254.1.2"
  peer_asn                  = 65000
  advertised_route_priority = 100
  interface                 = google_compute_router_interface.router_interface1.name
}

Advanced Networking Patterns and Best Practices

Multi-Cloud Network Architecture

When designing networks that span multiple cloud providers, consider these best practices:

Establish consistent IP addressing across all environments.
Implement centralized connectivity using Transit Gateways or similar hub services.
Use overlay technologies like SD-WAN for unified connectivity.
Create standardized security policies that work across providers.

Example using Aviatrix for multi-cloud networking:

# Aviatrix Transit Network across multiple clouds
provider "aviatrix" {
  controller_ip           = "controller-ip"
  username                = "admin"
  password                = var.aviatrix_password
  skip_version_validation = false
}

# AWS Transit Gateway
resource "aviatrix_transit_gateway" "aws_transit" {
  cloud_type        = 1
  account_name      = "aws-account"
  gw_name           = "aws-transit"
  vpc_id            = "vpc-id"
  vpc_reg           = "us-west-2"
  gw_size           = "c5.xlarge"
  subnet            = "10.0.0.0/24"
  ha_subnet         = "10.0.1.0/24"
  ha_gw_size        = "c5.xlarge"
  enable_active_mesh = true
}

# Azure Transit Gateway
resource "aviatrix_transit_gateway" "azure_transit" {
  cloud_type        = 8
  account_name      = "azure-account"
  gw_name           = "azure-transit"
  vpc_id            = "vnet-resource-group:vnet-name"
  vpc_reg           = "West US 2"
  gw_size           = "Standard_B2ms"
  subnet            = "10.1.0.0/24"
  ha_subnet         = "10.1.1.0/24"
  ha_gw_size        = "Standard_B2ms"
  enable_active_mesh = true
}

# GCP Transit Gateway
resource "aviatrix_transit_gateway" "gcp_transit" {
  cloud_type        = 4
  account_name      = "gcp-account"
  gw_name           = "gcp-transit"
  vpc_id            = "network-name"
  vpc_reg           = "us-west1"
  gw_size           = "n1-standard-1"
  subnet            = "10.2.0.0/24"
  ha_subnet         = "10.2.1.0/24"
  ha_gw_size        = "n1-standard-1"
  enable_active_mesh = true
}

# Transit Peering between AWS and Azure
resource "aviatrix_transit_gateway_peering" "aws_azure_peering" {
  transit_gateway_name1 = aviatrix_transit_gateway.aws_transit.gw_name
  transit_gateway_name2 = aviatrix_transit_gateway.azure_transit.gw_name
}

# Transit Peering between Azure and GCP
resource "aviatrix_transit_gateway_peering" "azure_gcp_peering" {
  transit_gateway_name1 = aviatrix_transit_gateway.azure_transit.gw_name
  transit_gateway_name2 = aviatrix_transit_gateway.gcp_transit.gw_name
}

Zero Trust Network Architecture

Implementing Zero Trust principles in your cloud networking:

Verify explicitly - Always authenticate and authorize based on all available data points.
Use least privilege access - Provide just enough access, just-in-time.
Assume breach - Design as if your network is already compromised.

Example using AWS and a Zero Trust approach:

# Identity-based network security groups in AWS
resource "aws_security_group" "app_security_group" {
  name        = "app-sg"
  description = "Identity-based access controls"
  vpc_id      = module.vpc.vpc_id

  # No ingress rules defined with CIDR blocks
  # Instead, authentication happens at the application level
}

# AWS Network Firewall with strict inspection
resource "aws_networkfirewall_firewall_policy" "zero_trust_policy" {
  name = "zero-trust-fw-policy"

  firewall_policy {
    stateless_default_actions          = ["aws:drop"]
    stateless_fragment_default_actions = ["aws:drop"]

    stateful_rule_group_reference {
      resource_arn = aws_networkfirewall_rule_group.strict_inspection.arn
    }
  }
}

# AWS IAM for service-to-service communication
resource "aws_iam_role" "service_role" {
  name = "service-to-service-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Principal = {
          Service = "ec2.amazonaws.com"
        }
      }
    ]
  })
}

# Session Manager for secure shell access without SSH ports
resource "aws_iam_role_policy_attachment" "ssm_policy" {
  role       = aws_iam_role.service_role.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore"
}

Cost-Effective Networking

Strategies to optimize cloud networking costs:

Right-size NAT gateways and other expensive networking components.
Use interface endpoints (AWS) or private endpoints (Azure) to reduce data transfer costs.
Implement transit solutions to minimize inter-region traffic.
Monitor and analyze traffic patterns to identify cost optimization opportunities.

Example cost-optimized AWS networking:

# Shared NAT Gateway
module "vpc" {
  source = "terraform-aws-modules/vpc/aws"
  version = "~> 3.0"

  name = "cost-optimized-vpc"
  cidr = "10.0.0.0/16"

  azs             = ["us-west-2a", "us-west-2b", "us-west-2c"]
  private_subnets = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
  public_subnets  = ["10.0.101.0/24", "10.0.102.0/24", "10.0.103.0/24"]

  # Use a single NAT Gateway to save costs
  enable_nat_gateway = true
  single_nat_gateway = true

  # Use VPC endpoints for S3 and DynamoDB (free)
  enable_s3_endpoint = true
  enable_dynamodb_endpoint = true

  # Additional VPC Endpoints for private AWS service access
  create_vpc_endpoints = true
  vpc_endpoint_gateway_services = ["s3", "dynamodb"]
  vpc_endpoint_interface_services = ["ec2", "ecr.api", "ecr.dkr", "logs", "ssm", "secretsmanager"]

  tags = {
    Environment = "production"
    Project     = "Example"
  }
}

# Use Gateway VPC Endpoints for AWS services to save on NAT costs
resource "aws_vpc_endpoint" "s3" {
  vpc_id       = module.vpc.vpc_id
  service_name = "com.amazonaws.us-west-2.s3"
  vpc_endpoint_type = "Gateway"
  route_table_ids = module.vpc.private_route_table_ids
}

# Use Interface VPC Endpoints for AWS services to save on NAT costs
resource "aws_vpc_endpoint" "ecr_api" {
  vpc_id            = module.vpc.vpc_id
  service_name      = "com.amazonaws.us-west-2.ecr.api"
  vpc_endpoint_type = "Interface"
  subnet_ids        = module.vpc.private_subnets
  security_group_ids = [aws_security_group.vpc_endpoints.id]
  private_dns_enabled = true
}

# Restrict EC2 instances using IMDSv2 with a max hop of 1
resource "aws_launch_template" "secure_instance" {
  name = "secure-instance"

  metadata_options {
    http_endpoint = "enabled"
    http_tokens   = "required"  # Force IMDSv2
    http_put_response_hop_limit = 1  # Increase security
  }
}

Enhanced Monitoring and Troubleshooting

Advanced monitoring strategies across all cloud providers:

Centralize logs and metrics from all network components.
Set up automated alerts for network performance degradation.
Use packet capture tools for detailed troubleshooting.
Implement network observability platforms for visualization.

Example AWS NetworkMonitoring setup:

# VPC Traffic Mirroring
resource "aws_ec2_traffic_mirror_target" "analysis_target" {
  description          = "Traffic analysis target"
  network_load_balancer_arn = aws_lb.analysis.arn
}

resource "aws_ec2_traffic_mirror_filter" "filter" {
  description = "Traffic mirror filter"
}

resource "aws_ec2_traffic_mirror_filter_rule" "inbound_rule" {
  traffic_mirror_filter_id = aws_ec2_traffic_mirror_filter.filter.id
  rule_number    = 1
  rule_action    = "accept"
  destination_cidr_block = "0.0.0.0/0"
  source_cidr_block = "0.0.0.0/0"
  direction       = "ingress"
}

resource "aws_ec2_traffic_mirror_session" "session" {
  description              = "Traffic mirror session"
  traffic_mirror_filter_id = aws_ec2_traffic_mirror_filter.filter.id
  traffic_mirror_target_id = aws_ec2_traffic_mirror_target.analysis_target.id
  network_interface_id     = aws_instance.monitored_instance.primary_network_interface_id
  session_number           = 1
}

# CloudWatch Metrics for Network Monitoring
resource "aws_cloudwatch_dashboard" "network_dashboard" {
  dashboard_name = "network-monitoring"
  dashboard_body = jsonencode({
    widgets = [
      {
        type   = "metric"
        x      = 0
        y      = 0
        width  = 12
        height = 6
        properties = {
          metrics = [
            [ "AWS/EC2", "NetworkIn", "InstanceId", aws_instance.monitored_instance.id ],
            [ ".", "NetworkOut", ".", "." ]
          ]
          period = 300
          stat   = "Average"
          region = "us-west-2"
          title  = "Network Traffic"
        }
      },
      {
        type   = "metric"
        x      = 0
        y      = 6
        width  = 12
        height = 6
        properties = {
          metrics = [
            [ "AWS/NATGateway", "BytesOutToDestination", "NatGatewayId", module.vpc.natgw_ids[0] ],
            [ ".", "BytesInFromDestination", ".", "." ]
          ]
          period = 300
          stat   = "Sum"
          region = "us-west-2"
          title  = "NAT Gateway Traffic"
        }
      }
    ]
  })
}

# AWS Network Manager for global network visibility
resource "aws_networkmanager_global_network" "global_network" {
  description = "My global network"
}

resource "aws_networkmanager_site" "site" {
  global_network_id = aws_networkmanager_global_network.global_network.id
  description       = "Site in US West"
  location {
    latitude  = "37.3382"
    longitude = "-121.8863"
  }
}

resource "aws_networkmanager_device" "device" {
  global_network_id = aws_networkmanager_global_network.global_network.id
  site_id           = aws_networkmanager_site.site.id
  description       = "Transit Gateway"
  type              = "transit-gateway"
  model             = "cloud"
  vendor            = "aws"
  location {
    latitude  = "37.3382"
    longitude = "-121.8863"
  }
}

# VPC Flow Logs with Athena queries
resource "aws_flow_log" "enhanced_flow_log" {
  log_destination      = aws_s3_bucket.flow_logs.arn
  log_destination_type = "s3"
  traffic_type         = "ALL"
  vpc_id               = module.vpc.vpc_id

  max_aggregation_interval = 60

  destination_options {
    file_format        = "parquet"
    per_hour_partition = true
  }
}

Conclusion: Cloud Networking Excellence

Effective cloud networking requires careful planning and an understanding of each provider’s unique characteristics. While the core concepts remain consistent, implementation details vary significantly between AWS, Azure, and Google Cloud.

When developing your cloud networking strategy:

Start with clear requirements: Define your security, performance, and connectivity needs.
Design with growth in mind: Build flexibility into your network architecture.
Automate everything: Use Infrastructure as Code to define and manage network resources.
Implement proper monitoring: Detect and address issues before they impact users.
Document thoroughly: Maintain up-to-date network diagrams and configurations.
Optimize continuously: Regularly review network architecture for cost and performance improvements.
Test disaster recovery: Ensure your network architecture can withstand failures and outages.
Apply defense in depth: Implement multiple security controls at different layers.

By following these best practices and understanding the nuances of each cloud provider, you can build robust, secure, and efficient network architectures that will scale with your organization’s needs. Remember that cloud networking is not a one-time setup but an ongoing process that requires continuous improvement and adaptation.

Network Topology Recommendations by Workload Type

Workload Type	AWS	Azure	GCP
Web Applications	VPC with public/private subnets, ALB, WAF	Hub-spoke VNet with Azure App Service, Front Door	Global VPC with Cloud Load Balancing, Cloud Armor
Microservices	EKS with VPC CNI, Transit Gateway	AKS with CNI, Azure Firewall	GKE with network policies, Cloud NAT
Data Analytics	Private subnets, VPC Endpoints	Private Link, Service Endpoints	Private Service Connect, VPC Service Controls
Hybrid Applications	Direct Connect, Transit Gateway	ExpressRoute, Virtual WAN	Cloud Interconnect, Cloud Router
Multi-region	Multiple regional VPCs, Transit Gateway	Global VNet peering, Traffic Manager	Global VPC, Cloud DNS, Global Load Balancing

Final Recommendations

The cloud networking landscape continues to evolve rapidly, with providers introducing new services and features regularly. As you build your cloud networking strategy, consider these final recommendations:

Start small and expand: Begin with a simple, well-designed network architecture and expand as your needs grow.
Focus on security and compliance: Build security into your network from the ground up, not as an afterthought.
Understand the tradeoffs: Every network design decision involves tradeoffs between security, performance, complexity, and cost.
Document your decisions: Create and maintain detailed documentation of your network architecture and the reasoning behind key decisions.
Keep learning: Cloud networking is a rapidly evolving field. Invest in continuous learning and stay updated with best practices.

At Quabyt, we specialize in designing and implementing optimal cloud networking solutions across all major providers. Our cloud architects can help you navigate these complexities and build a networking foundation that enhances security, performance, and cost-effectiveness for your specific requirements. Contact us to learn how we can help you get cloud networking right the first time.

Cloud Networking Done Right: Best Practices for AWS, Azure, and GCP

The Foundation of Cloud Architecture

Core Networking Components

Virtual Networks: The Foundation

Subnets: Effective Network Segmentation

Routing: Controlling Traffic Flow

Internet Connectivity: Secure Access

Private Connectivity: Hybrid Cloud

Network Security: Defense in Depth

Cloud Provider Comparison: Key Differences

Architecture and Scope

IP Addressing

Network Performance

Pricing Models

Essential Best Practices Across All Providers

1. Implement Proper Network Segmentation

2. Plan IP Address Space Carefully

3. Implement Defense in Depth

4. Optimize for Cost

5. Design for High Availability

6. Document Network Architecture

Provider-Specific Best Practices

AWS Networking Best Practices

VPC Design

Understanding and Choosing CIDR Blocks

Security

Connectivity

Azure Networking Best Practices

VNet Design

Security

Connectivity

Google Cloud Networking Best Practices

VPC Design

Network Security

Connectivity

Advanced Networking Patterns and Best Practices

Multi-Cloud Network Architecture

Zero Trust Network Architecture

Cost-Effective Networking

Enhanced Monitoring and Troubleshooting

Conclusion: Cloud Networking Excellence

Network Topology Recommendations by Workload Type

Final Recommendations

Related Posts

Serverless Containers: AWS ECS Fargate vs. Azure Container Apps vs. Google Cloud Run

Serverless Functions: AWS Lambda vs. Azure Functions vs. Google Cloud Functions

Building Trust: Ethical and Secure Generative AI Solutions

From Web to Mobile: A Comprehensive Guide to Migrating React Apps to React Native