Cloud Networking - Learning Module

Loading content...

0/228

Cloud Network Models

The Cloud Networking Paradigm

Cloud computing has fundamentally transformed how organizations design, deploy, and manage network infrastructure. The traditional model—purchasing routers, switches, and firewalls; provisioning circuits; managing physical cabling—has given way to software-defined, API-driven networking abstractions that can be instantiated in minutes and scaled elastically based on demand.

Cloud network models represent the conceptual frameworks through which cloud providers expose networking capabilities to consumers. These models determine not just what you can build, but how you think about network architecture, security boundaries, and connectivity patterns. Understanding cloud network models is foundational to designing systems that leverage the cloud's full potential while avoiding the pitfalls of mismatched abstractions.

This page establishes the theoretical and practical foundations of cloud networking, examining the service models, responsibility boundaries, deployment paradigms, and architectural patterns that define modern cloud-native network design.

Learning Objectives

By completing this page, you will understand: (1) The three cloud service models (IaaS, PaaS, SaaS) and their networking implications, (2) The shared responsibility model for network security, (3) Deployment models (public, private, hybrid, multi-cloud), (4) Key differences between traditional and cloud networking paradigms, and (5) How major cloud providers implement these models in practice.

Cloud Service Models and Networking Implications

Cloud computing services are traditionally categorized into three layered models: Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS). Each model abstracts progressively more of the underlying infrastructure, with profound implications for how networking is exposed, controlled, and secured.

The Abstraction Stack:

Think of these models as layers of abstraction sitting atop physical infrastructure. At each layer, the cloud provider assumes more responsibility, and the consumer gains convenience at the cost of control. Networking follows this same pattern—the higher the abstraction, the less direct network configuration you manage.

Cloud Service Models: Networking Perspective
Model	Network Control	Consumer Manages	Provider Manages	Typical Use Cases
IaaS	Maximum control	Virtual networks, subnets, routing tables, firewalls, load balancers, VPN/peering	Physical network, hypervisor networking, global backbone	Custom VPCs, complex multi-tier architectures, network appliances
PaaS	Limited control	Ingress/egress rules, connection strings, sometimes VNet integration	Network isolation, internal routing, service discovery, TLS termination	App Services, managed databases, container services
SaaS	Minimal control	Authentication, API endpoints, sometimes IP whitelisting	All networking infrastructure, global distribution, CDN	Email, CRM, collaboration tools, business applications

Infrastructure as a Service (IaaS) Networking

IaaS provides the greatest networking flexibility, exposing virtual equivalents of traditional network primitives. Consumers can define:

Virtual Private Clouds (VPCs) / Virtual Networks (VNets): Isolated network environments with custom IP address ranges
Subnets: Logical divisions within a VPC for workload segmentation
Route Tables: Custom routing rules directing traffic between subnets, internet gateways, VPN tunnels, or peering connections
Security Groups / Network ACLs: Stateful and stateless firewall rules controlling ingress/egress traffic
Load Balancers: Layer 4 (TCP/UDP) and Layer 7 (HTTP/HTTPS) traffic distribution
NAT Gateways: Outbound internet access for private subnets without exposing inbound routes
VPN Gateways and Direct Connect: Secure connectivity to on-premises networks

Key Insight: IaaS networking closely mirrors traditional enterprise networking, but in a software-defined form. Network engineers familiar with Cisco IOS or Juniper JunOS concepts will find analogous primitives—just configured via API calls instead of CLI commands.

IaaS Network Design Principle

When designing IaaS networks, think in terms of blast radius. Segment workloads into subnets based on security requirements and failure domains. A compromised web server in a public subnet should not have network-level access to your database tier in a private subnet. Defense in depth applies to cloud networks just as it does to physical ones—perhaps even more so, given the attack surface of internet-exposed resources.

Platform as a Service (PaaS) Networking

PaaS abstracts the infrastructure layer, managing the operating system, runtime, and often the networking fabric. Consumers focus on deploying applications rather than configuring networks.

Networking Characteristics of PaaS:

Managed Ingress: The provider handles load balancing, TLS termination, and request routing. You configure domains and backends, not listeners and target groups.
Internal Service Discovery: Services communicate via DNS names or service meshes managed by the platform. You don't manage internal IP addresses.
Constrained Egress: Outbound traffic may route through platform-managed NAT. Some PaaS offerings support VNet integration, allowing deployment into customer-controlled subnets.
Implicit Isolation: Multi-tenant platforms isolate workloads using namespace mechanisms (containers, process isolation) rather than network-level separation.

Example: Azure App Service VNet Integration

Azure App Service can be integrated into a VNet, allowing the app to access resources in the VNet (databases, caches) as if it were deployed there. However, the app itself isn't deployed inside the VNet—the platform routes outbound traffic through a subnet you specify.

┌─────────────────────────────────────────────────────┐
│                   Azure Region                       │
│  ┌────────────────────┐   ┌──────────────────────┐  │
│  │   App Service      │   │    Your VNet         │  │
│  │   (PaaS)           │──▶│  ┌────────────────┐  │  │
│  │                    │   │  │ Private Subnet │  │  │
│  │  VNet Integration  │   │  │  (Databases,   │  │  │
│  │  Outbound Route    │   │  │   Caches)      │  │  │
│  └────────────────────┘   │  └────────────────┘  │  │
│                            └──────────────────────┘  │
└─────────────────────────────────────────────────────┘

Software as a Service (SaaS) Networking

SaaS represents complete abstraction of all infrastructure. Consumers interact with applications via well-defined APIs or user interfaces. Networking is entirely invisible.

Consumer Network Concerns in SaaS:

API Endpoints: Understanding which endpoints to whitelist in firewalls for outbound connectivity
IP Ranges: For services requiring IP-based access control, providers publish IP ranges (which may change)
Private Connectivity: Some enterprise SaaS offerings support private endpoints or PrivateLink, routing traffic over private backbones rather than the public internet
Data Residency: Networking configurations may affect which regional endpoints handle data, important for compliance

The Hidden Complexity:

SaaS providers operate massive, globally distributed networks to deliver their services. Consider a service like Salesforce or Microsoft 365:

Global traffic is routed to the nearest edge point-of-presence (PoP)
Requests traverse the provider's private backbone to the appropriate regional data center
Internal microservices communicate over service meshes with end-to-end encryption
Data replicates across regions for durability and disaster recovery

This complexity is entirely abstracted from the consumer—you experience low latency and high availability without understanding the underlying topology.

The Abstraction Trade-off

Higher abstraction levels trade control for convenience. IaaS gives you power but demands expertise. SaaS provides simplicity but limits customization. The right choice depends on your organizational capabilities and requirements. Many enterprises use all three models: SaaS for commodity applications, PaaS for custom application hosting, and IaaS for specialized workloads requiring fine-grained control.

The Shared Responsibility Model for Network Security

Cloud providers and consumers share responsibility for security, including network security. Understanding this boundary is critical—misconfiguration at the boundary has caused countless breaches.

The Fundamental Principle:

Cloud providers secure the infrastructure of the cloud. Consumers secure what they put in the cloud. For networking, this translates to:

Provider Responsibility: Physical network security, hypervisor isolation, DDoS protection at the edge, backbone encryption, data center physical security
Consumer Responsibility: VPC configuration, security group rules, network ACLs, encryption in transit, access controls, logging and monitoring

Shared Responsibility by Service Model
Component	IaaS	PaaS	SaaS
Physical network infrastructure	Provider	Provider	Provider
Hypervisor/host networking	Provider	Provider	Provider
Virtual network configuration	Customer	Provider/Shared	Provider
Firewall rules (Security Groups)	Customer	Shared	Provider
Encryption in transit (internal)	Customer	Provider/Shared	Provider
Encryption in transit (external)	Shared	Shared	Provider
Ingress/egress access control	Customer	Shared	Provider
Network logging/monitoring	Customer	Shared	Provider
DDoS protection (basic)	Provider	Provider	Provider
DDoS protection (advanced)	Customer add-on	Customer add-on	Provider

Common Security Misconfigurations

The shared responsibility model creates boundary zones where responsibility isn't always clear. Common network security failures include:

1. Overly Permissive Security Groups

Opening 0.0.0.0/0 (all IP addresses) on sensitive ports (SSH/22, RDP/3389, database ports) is a common mistake. Attackers continuously scan cloud IP ranges for exposed services.

2. Public Subnets for Private Resources

Placing databases or internal services in public subnets (with internet gateway routes) exposes them unnecessarily. Even with restrictive security groups, this violates defense in depth.

3. Missing Encryption in Transit

Assuming VPC traffic is secure because it's 'internal.' Other tenants can't see your traffic, but a compromised instance within your VPC can. Always use TLS for sensitive communication.

4. Neglecting Flow Logs

VPC Flow Logs (AWS), NSG Flow Logs (Azure), and VPC Flow Logs (GCP) capture network traffic metadata. Without these, detecting reconnaissance, exfiltration, or lateral movement becomes extremely difficult.

5. Default Network Configuration

Using default VPCs or default security groups is dangerous. Defaults are designed for ease of getting started, not security. Always create purpose-built network configurations.

The "It's in the Cloud, It's Secure" Fallacy

Cloud doesn't equal secure. Cloud provides secure infrastructure—physical security, DDoS absorption, encryption at rest, compliance certifications. But misconfigured resources in the cloud are often less secure than on-premises equivalents, because they're directly reachable from the internet. The shared responsibility model means YOUR configurations are YOUR security posture.

Defense in Depth for Cloud Networks

Apply layered security principles to cloud networks:

Layer 1: Edge Protection

Web Application Firewalls (WAF) at CDN or load balancer
DDoS protection services (AWS Shield, Azure DDoS Protection, Cloud Armor)
API gateways with rate limiting and authentication

Layer 2: Network Perimeter

Network ACLs for stateless subnet-level filtering
Security groups for stateful instance-level filtering
Network firewall services for centralized inspection

Layer 3: East-West Traffic

Microsegmentation using security groups or service mesh policies
Zero-trust network architectures assuming breach
Service-to-service authentication (mTLS, IAM-based auth)

Layer 4: Data Protection

Encryption in transit for all sensitive traffic
Private endpoints for cloud services (bypassing public internet)
Secrets management for credentials and certificates

Layer 5: Visibility and Response

VPC Flow Logs and Traffic Mirroring
SIEM integration and real-time alerting
Network traffic analysis and anomaly detection

Cloud Deployment Models

Beyond service models (IaaS/PaaS/SaaS), cloud deployments are categorized by ownership and access. Four primary deployment models exist: public cloud, private cloud, hybrid cloud, and multi-cloud. Each has distinct networking characteristics and design considerations.

Public Cloud

Public cloud resources are hosted by third-party providers (AWS, Azure, GCP, etc.) on shared infrastructure. Multiple customers' workloads run on the same physical hardware, isolated via hypervisors and software-defined networking.

Networking Characteristics:

Shared physical infrastructure, isolated virtual networks
Standard IP ranges (private RFC 1918 addresses within VPCs)
Internet connectivity via provider-managed edge
Cross-region connectivity via provider backbone
No visibility into underlying physical topology

Public Cloud Networking: Advantages and Considerations
Aspect	Advantage	Consideration
Scale	Effectively unlimited capacity; scale on demand	Large-scale deployments may encounter regional limits
Global Reach	Points of presence worldwide; low-latency access globally	Data sovereignty may restrict some regions
Cost	OpEx model; no upfront infrastructure investment	Egress charges can become significant at scale
Security	Provider handles physical security and DDoS absorption	Customer responsible for configuration; multi-tenancy concerns
Compliance	Many certifications available (SOC2, HIPAA, PCI)	Shared infrastructure may be prohibited for some workloads

Private Cloud

Private cloud infrastructure is dedicated to a single organization. It may be hosted on-premises or in a co-location facility, but is not shared with other tenants. Private cloud often uses the same technologies as public cloud (VMware, OpenStack, Kubernetes) but in a dedicated environment.

Networking Characteristics:

Organization controls the entire network stack
Traditional networking appliances (routers, firewalls) may coexist with SDN
No egress charges (aside from upstream ISP costs)
Full visibility and control over physical and logical topology
Limited scale; capacity must be pre-provisioned

Use Cases:

Highly regulated industries (financial services, healthcare, government)
Workloads with strict data residency requirements
Organizations with existing data center investments
Ultra-low-latency requirements where public cloud regions are too distant

Hybrid Cloud

Hybrid cloud combines on-premises (or private cloud) infrastructure with public cloud resources. Workloads span both environments, connected via secure network links.

Networking Challenges:

1. Connectivity: Establishing reliable, secure connections between on-premises and cloud. Options include:

Site-to-Site VPN: IPsec tunnels over the public internet. Lower cost but variable latency and bandwidth.
Dedicated Connections: AWS Direct Connect, Azure ExpressRoute, Google Cloud Interconnect. Dedicated circuits with predictable performance and potentially lower egress costs.

2. IP Address Space Management: Ensuring non-overlapping IP ranges between environments. CIDR block planning becomes critical.

3. DNS Resolution: Hybrid DNS strategies allowing cloud resources to resolve on-premises names and vice versa.

4. Routing Complexity: Determining which traffic stays local versus transiting to cloud. May require BGP for dynamic routing.

5. Security Policy Consistency: Applying consistent security policies across heterogeneous environments. Firewalls, ACLs, and security groups must align.

Converting Mermaid diagram...

Multi-Cloud

Multi-cloud involves using services from multiple public cloud providers simultaneously. Organizations may use AWS for compute, GCP for machine learning, and Azure for enterprise applications.

Networking Challenges:

1. Inter-Cloud Connectivity: Connecting workloads across different providers. Options include:

VPN between clouds (each cloud terminates one end)
Third-party cloud exchange services (Megaport, Equinix Cloud Exchange)
SD-WAN overlays providing unified connectivity

2. Inconsistent Abstractions: Each provider has different networking constructs. AWS VPCs differ from Azure VNets differ from GCP VPCs. Teams must understand multiple paradigms.

3. Latency and Egress Costs: Traffic between clouds typically traverses the public internet (unless using dedicated interconnects), adding latency and incurring egress charges from both providers.

4. Observability Fragmentation: Logs, metrics, and flow data are siloed in each provider's tooling. Unified visibility requires third-party solutions.

5. Security Policy Complexity: Maintaining consistent security across providers with different security group semantics, IAM models, and compliance certifications.

Multi-Cloud Reality Check

True multi-cloud (same workloads portable across providers) is rare and expensive. More common is 'multi-cloud by accident'—different teams or acquisitions using different providers. Before architecting for multi-cloud portability, honestly assess whether the flexibility benefits outweigh the complexity costs. Often, deep integration with one provider delivers more value than superficial compatibility with many.

Traditional vs Cloud Networking Paradigms

The shift to cloud networking isn't merely a change in location—it represents a fundamental paradigm shift in how networks are designed, provisioned, and operated. Understanding these differences helps organizations navigate the transition and leverage cloud networking effectively.

Paradigm Comparison: Traditional vs Cloud Networking
Aspect	Traditional Networking	Cloud Networking
Provisioning	Hardware procurement, physical installation, manual configuration (weeks to months)	API calls, Infrastructure as Code, self-service (minutes)
Scaling	Capacity planning, hardware upgrades, overprovisioning for peak	Elastic scaling, pay-per-use, scale to zero possible
Configuration	CLI/GUI on individual devices, configuration drift risk	Declarative templates (CloudFormation, Terraform), version-controlled
Failure Domains	Physical: racks, switches, circuits; requires redundant equipment	Abstracted: Availability Zones, regions; provider handles physical redundancy
IP Management	IPAM databases, DHCP servers, manual VLAN assignment	CIDR allocation, embedded DHCP, automatic IP assignment within subnets
Security Controls	Physical firewalls, ACLs on routers, network taps	Security groups, NACLs, flow logs, built-in DDoS protection
Observability	SNMP, NetFlow, physical probe points	VPC Flow Logs, Cloud-native monitoring, API-driven telemetry
Cost Model	CapEx: purchase equipment, OpEx: power/cooling/maintenance	OpEx: per-resource charges, egress-based data transfer costs

Key Paradigm Shifts

1. From Hardware to Software:

Traditional networks are defined by physical devices—routers, switches, firewalls with specific capabilities and interfaces. Cloud networks are software constructs. The 'router' enforcing your route table is a distributed service, not a box with a model number.

Implication: Network capacity is no longer bound by hardware limits. But you must understand the soft limits (rate limits, maximum routes per table, security groups per interface) of your cloud provider.

2. From Static to Dynamic:

Traditional networks are relatively static. Changes are planned, change-controlled, and executed infrequently. Cloud networks are dynamic—instances spin up with new IPs, auto-scaling groups resize, containers schedule across nodes.

Implication: Network designs must accommodate ephemerality. Hardcoded IP addresses fail. Service discovery, DNS-based routing, and identity-based security become essential.

3. From Centralized to Distributed:

Traditional networks route traffic through central choke points—core routers, firewalls, load balancers. Cloud networks are inherently distributed across availability zones and regions.

Implication: Traffic patterns differ. North-south (client to server) flows compete with east-west (server to server) traffic. Microservices architectures amplify east-west traffic, requiring service mesh or microsegmentation strategies.

The Stateless vs Stateful Distinction

Traditional network engineers often think in terms of stateful flows—TCP connections tracked through firewalls. Cloud security groups are typically stateful (return traffic automatically allowed), but Network ACLs are stateless (require explicit rules for both directions). This distinction trips up engineers accustomed to stateful devices everywhere. Always verify the state tracking behavior of each security layer.

Infrastructure as Code for Networks

Cloud networking enables—and demands—treating network configuration as code. Instead of clicking through consoles, networks are defined in Terraform, CloudFormation, Pulumi, or equivalent tools.

Benefits:

Version Control: Network configurations in Git, with history and rollback capability
Review Processes: Pull requests for network changes, peer review before deployment
Repeatability: Identical configurations across environments (dev/staging/prod)
Testing: Validate changes in lower environments before production
Compliance Automation: Policy-as-code tools verify configurations against baselines

Example: Terraform VPC Definition (AWS)

resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true
  
  tags = {
    Name        = "production-vpc"
    Environment = "production"
  }
}

resource "aws_subnet" "private" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.1.0/24"
  availability_zone = "us-east-1a"
  
  tags = {
    Name = "private-subnet-1a"
    Tier = "private"
  }
}

resource "aws_security_group" "web" {
  name        = "web-tier-sg"
  description = "Allow HTTPS inbound, all outbound"
  vpc_id      = aws_vpc.main.id
  
  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
  
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

This configuration is checked into version control, reviewed, and applied consistently across all environments. Changes are tracked, auditable, and reversible.

Provider-Specific Implementations

While cloud providers share similar conceptual models, their implementations differ significantly in terminology, capabilities, and defaults. Understanding these differences is essential for multi-cloud environments and for making informed provider decisions.

AWS (Amazon Web Services)

AWS pioneered many cloud networking patterns. Its Virtual Private Cloud (VPC) service is the foundation for AWS networking.

Key Components:

VPC: Isolated virtual network with up to /16 CIDR (65,536 addresses)
Subnets: Divide VPC CIDR across Availability Zones; classified as public (route to Internet Gateway) or private
Internet Gateway (IGW): Enables public internet access for VPC resources
NAT Gateway: Managed service for outbound internet from private subnets
Route Tables: Control traffic routing; associated with subnets
Security Groups: Stateful, instance-level firewall; allow rules only (implicit deny)
Network ACLs: Stateless, subnet-level firewall; allow and deny rules
VPC Peering: Connect two VPCs with private IP routing
Transit Gateway: Hub for connecting multiple VPCs and on-premises networks
PrivateLink: Access AWS services or hosted endpoints without traversing public internet

Cloud Provider Networking Terminology Comparison
Concept	AWS	Azure	GCP
Virtual Network	VPC	VNet	VPC
Subnet	Subnet	Subnet	Subnet/Subnetwork
Instance-level Firewall	Security Group	NSG (Network Security Group)	Firewall Rules
Subnet-level Firewall	Network ACL	NSG (at subnet level)	Firewall Rules (VPC level)
Internet Gateway	Internet Gateway	Implicit (public IP)	External IP / Cloud NAT
NAT Service	NAT Gateway	NAT Gateway / VM	Cloud NAT
Private Cloud Service Access	PrivateLink / VPC Endpoints	Private Endpoints	Private Service Connect
VPN Gateway	Virtual Private Gateway	VPN Gateway	Cloud VPN
Dedicated Connection	Direct Connect	ExpressRoute	Cloud Interconnect
Load Balancer (L4)	NLB (Network Load Balancer)	Azure Load Balancer	Network Load Balancer
Load Balancer (L7)	ALB (Application Load Balancer)	Application Gateway	HTTP(S) Load Balancer
Multi-VPC Hub	Transit Gateway	Virtual WAN	Network Connectivity Center

Azure (Microsoft Azure)

Azure networking aligns with enterprise consumption patterns, with strong hybrid cloud integration.

Distinctive Features:

Global VNets: VNets are regional, but global peering allows cross-region private connectivity
NSG Flexibility: Network Security Groups can attach to subnets OR network interfaces
Azure Firewall: Managed, cloud-native firewall service with threat intelligence
Virtual WAN: Simplified hub-and-spoke at global scale with automated routing
ExpressRoute: Premium connectivity with Global Reach enabling connectivity between on-premises sites via Microsoft backbone
Application Gateway: L7 load balancer with WAF capabilities built-in

Google Cloud Platform (GCP)

GCP's networking reflects Google's global network infrastructure, with unique architectural patterns.

Distinctive Features:

Global VPCs: Unlike AWS/Azure, GCP VPCs are global. Subnets are regional, but VPCs span the entire planet.
Automatic Mode VPCs: Can auto-create subnets in every region (convenient for prototyping)
Private Google Access: Instances without external IPs can reach Google APIs via internal routes
Cloud NAT: Regional, managed NAT service with automatic port allocation
Shared VPC: Allow resources from multiple projects to use a single VPC (centralized network management)
VPC Service Controls: Create security perimeters around sensitive services to prevent data exfiltration

The Global vs Regional VPC Distinction

GCP's global VPCs enable simpler multi-region designs—one VPC serves your entire global deployment. AWS and Azure require separate VPCs/VNets per region, connected via peering or transit services. This architectural difference affects CIDR planning, route table management, and multi-region failover designs. Neither approach is inherently better; they represent different trade-offs between simplicity and control.

Summary: Cloud Network Models

Cloud network models form the conceptual foundation for designing and operating network infrastructure in cloud environments. Mastery of these models enables architects to make informed decisions about service selection, security boundaries, and connectivity patterns.

Key Takeaways

•Service models (IaaS/PaaS/SaaS) determine networking control: IaaS provides maximum flexibility with virtual networks, subnets, and firewall rules. PaaS abstracts most networking. SaaS abstracts all networking.
•The shared responsibility model defines security boundaries: Cloud providers secure infrastructure; customers secure configuration. Misunderstanding this boundary causes breaches.
•Deployment models (public/private/hybrid/multi-cloud) have distinct networking challenges: Public cloud offers scale but requires careful security. Hybrid demands connectivity planning. Multi-cloud adds complexity.
•Cloud networking differs fundamentally from traditional networking: Software-defined, API-driven, dynamic, and ephemeral. Infrastructure as Code is essential for manageable cloud networks.
•Provider implementations vary in terminology and architecture: AWS VPCs, Azure VNets, and GCP VPCs have similar concepts but different behaviors. Global vs regional scoping significantly affects design.
•Defense in depth applies to cloud networks: Layer security from edge (WAF/DDoS) through perimeter (security groups) to east-west traffic (microsegmentation) to data (encryption).

What's Next:

With cloud network models understood, we'll dive deeper into Virtual Networks—the core abstraction that forms the foundation of cloud network architecture. We'll explore IP addressing, subnetting, routing, and the detailed mechanics of how virtual networks isolate and connect resources within a cloud provider's infrastructure.

Foundation Established

You now understand the fundamental models governing cloud networking. This conceptual foundation prepares you to design secure, scalable network architectures across any cloud provider. The remaining pages in this module will build on these concepts with progressively deeper technical detail.

Cloud Network Models

The Cloud Networking Paradigm

Learning Objectives

Cloud Service Models and Networking Implications

The Abstraction Stack:

Cloud Service Models: Networking Perspective
Model	Network Control	Consumer Manages	Provider Manages	Typical Use Cases
IaaS	Maximum control	Virtual networks, subnets, routing tables, firewalls, load balancers, VPN/peering	Physical network, hypervisor networking, global backbone	Custom VPCs, complex multi-tier architectures, network appliances
PaaS	Limited control	Ingress/egress rules, connection strings, sometimes VNet integration	Network isolation, internal routing, service discovery, TLS termination	App Services, managed databases, container services
SaaS	Minimal control	Authentication, API endpoints, sometimes IP whitelisting	All networking infrastructure, global distribution, CDN	Email, CRM, collaboration tools, business applications

Infrastructure as a Service (IaaS) Networking

IaaS provides the greatest networking flexibility, exposing virtual equivalents of traditional network primitives. Consumers can define:

Virtual Private Clouds (VPCs) / Virtual Networks (VNets): Isolated network environments with custom IP address ranges
Subnets: Logical divisions within a VPC for workload segmentation
Route Tables: Custom routing rules directing traffic between subnets, internet gateways, VPN tunnels, or peering connections
Security Groups / Network ACLs: Stateful and stateless firewall rules controlling ingress/egress traffic
Load Balancers: Layer 4 (TCP/UDP) and Layer 7 (HTTP/HTTPS) traffic distribution
NAT Gateways: Outbound internet access for private subnets without exposing inbound routes
VPN Gateways and Direct Connect: Secure connectivity to on-premises networks

IaaS Network Design Principle

Platform as a Service (PaaS) Networking

PaaS abstracts the infrastructure layer, managing the operating system, runtime, and often the networking fabric. Consumers focus on deploying applications rather than configuring networks.

Networking Characteristics of PaaS:

Managed Ingress: The provider handles load balancing, TLS termination, and request routing. You configure domains and backends, not listeners and target groups.
Internal Service Discovery: Services communicate via DNS names or service meshes managed by the platform. You don't manage internal IP addresses.
Constrained Egress: Outbound traffic may route through platform-managed NAT. Some PaaS offerings support VNet integration, allowing deployment into customer-controlled subnets.
Implicit Isolation: Multi-tenant platforms isolate workloads using namespace mechanisms (containers, process isolation) rather than network-level separation.

Example: Azure App Service VNet Integration

┌─────────────────────────────────────────────────────┐
│                   Azure Region                       │
│  ┌────────────────────┐   ┌──────────────────────┐  │
│  │   App Service      │   │    Your VNet         │  │
│  │   (PaaS)           │──▶│  ┌────────────────┐  │  │
│  │                    │   │  │ Private Subnet │  │  │
│  │  VNet Integration  │   │  │  (Databases,   │  │  │
│  │  Outbound Route    │   │  │   Caches)      │  │  │
│  └────────────────────┘   │  └────────────────┘  │  │
│                            └──────────────────────┘  │
└─────────────────────────────────────────────────────┘

Software as a Service (SaaS) Networking

SaaS represents complete abstraction of all infrastructure. Consumers interact with applications via well-defined APIs or user interfaces. Networking is entirely invisible.

Consumer Network Concerns in SaaS:

API Endpoints: Understanding which endpoints to whitelist in firewalls for outbound connectivity
IP Ranges: For services requiring IP-based access control, providers publish IP ranges (which may change)
Private Connectivity: Some enterprise SaaS offerings support private endpoints or PrivateLink, routing traffic over private backbones rather than the public internet
Data Residency: Networking configurations may affect which regional endpoints handle data, important for compliance

The Hidden Complexity:

SaaS providers operate massive, globally distributed networks to deliver their services. Consider a service like Salesforce or Microsoft 365:

Global traffic is routed to the nearest edge point-of-presence (PoP)
Requests traverse the provider's private backbone to the appropriate regional data center
Internal microservices communicate over service meshes with end-to-end encryption
Data replicates across regions for durability and disaster recovery

This complexity is entirely abstracted from the consumer—you experience low latency and high availability without understanding the underlying topology.

The Abstraction Trade-off

The Shared Responsibility Model for Network Security

Cloud providers and consumers share responsibility for security, including network security. Understanding this boundary is critical—misconfiguration at the boundary has caused countless breaches.

The Fundamental Principle:

Cloud providers secure the infrastructure of the cloud. Consumers secure what they put in the cloud. For networking, this translates to:

Provider Responsibility: Physical network security, hypervisor isolation, DDoS protection at the edge, backbone encryption, data center physical security
Consumer Responsibility: VPC configuration, security group rules, network ACLs, encryption in transit, access controls, logging and monitoring

Shared Responsibility by Service Model
Component	IaaS	PaaS	SaaS
Physical network infrastructure	Provider	Provider	Provider
Hypervisor/host networking	Provider	Provider	Provider
Virtual network configuration	Customer	Provider/Shared	Provider
Firewall rules (Security Groups)	Customer	Shared	Provider
Encryption in transit (internal)	Customer	Provider/Shared	Provider
Encryption in transit (external)	Shared	Shared	Provider
Ingress/egress access control	Customer	Shared	Provider
Network logging/monitoring	Customer	Shared	Provider
DDoS protection (basic)	Provider	Provider	Provider
DDoS protection (advanced)	Customer add-on	Customer add-on	Provider

Common Security Misconfigurations

The shared responsibility model creates boundary zones where responsibility isn't always clear. Common network security failures include:

1. Overly Permissive Security Groups

Opening 0.0.0.0/0 (all IP addresses) on sensitive ports (SSH/22, RDP/3389, database ports) is a common mistake. Attackers continuously scan cloud IP ranges for exposed services.

2. Public Subnets for Private Resources

Placing databases or internal services in public subnets (with internet gateway routes) exposes them unnecessarily. Even with restrictive security groups, this violates defense in depth.

3. Missing Encryption in Transit

Assuming VPC traffic is secure because it's 'internal.' Other tenants can't see your traffic, but a compromised instance within your VPC can. Always use TLS for sensitive communication.

4. Neglecting Flow Logs

5. Default Network Configuration

Using default VPCs or default security groups is dangerous. Defaults are designed for ease of getting started, not security. Always create purpose-built network configurations.

The "It's in the Cloud, It's Secure" Fallacy

Defense in Depth for Cloud Networks

Apply layered security principles to cloud networks:

Layer 1: Edge Protection

Web Application Firewalls (WAF) at CDN or load balancer
DDoS protection services (AWS Shield, Azure DDoS Protection, Cloud Armor)
API gateways with rate limiting and authentication

Layer 2: Network Perimeter

Network ACLs for stateless subnet-level filtering
Security groups for stateful instance-level filtering
Network firewall services for centralized inspection

Layer 3: East-West Traffic

Microsegmentation using security groups or service mesh policies
Zero-trust network architectures assuming breach
Service-to-service authentication (mTLS, IAM-based auth)

Layer 4: Data Protection

Encryption in transit for all sensitive traffic
Private endpoints for cloud services (bypassing public internet)
Secrets management for credentials and certificates

Layer 5: Visibility and Response

VPC Flow Logs and Traffic Mirroring
SIEM integration and real-time alerting
Network traffic analysis and anomaly detection

Cloud Deployment Models

Public Cloud

Networking Characteristics:

Shared physical infrastructure, isolated virtual networks
Standard IP ranges (private RFC 1918 addresses within VPCs)
Internet connectivity via provider-managed edge
Cross-region connectivity via provider backbone
No visibility into underlying physical topology

Public Cloud Networking: Advantages and Considerations
Aspect	Advantage	Consideration
Scale	Effectively unlimited capacity; scale on demand	Large-scale deployments may encounter regional limits
Global Reach	Points of presence worldwide; low-latency access globally	Data sovereignty may restrict some regions
Cost	OpEx model; no upfront infrastructure investment	Egress charges can become significant at scale
Security	Provider handles physical security and DDoS absorption	Customer responsible for configuration; multi-tenancy concerns
Compliance	Many certifications available (SOC2, HIPAA, PCI)	Shared infrastructure may be prohibited for some workloads

Private Cloud

Networking Characteristics:

Organization controls the entire network stack
Traditional networking appliances (routers, firewalls) may coexist with SDN
No egress charges (aside from upstream ISP costs)
Full visibility and control over physical and logical topology
Limited scale; capacity must be pre-provisioned

Use Cases:

Highly regulated industries (financial services, healthcare, government)
Workloads with strict data residency requirements
Organizations with existing data center investments
Ultra-low-latency requirements where public cloud regions are too distant

Hybrid Cloud

Hybrid cloud combines on-premises (or private cloud) infrastructure with public cloud resources. Workloads span both environments, connected via secure network links.

Networking Challenges:

1. Connectivity: Establishing reliable, secure connections between on-premises and cloud. Options include:

Site-to-Site VPN: IPsec tunnels over the public internet. Lower cost but variable latency and bandwidth.
Dedicated Connections: AWS Direct Connect, Azure ExpressRoute, Google Cloud Interconnect. Dedicated circuits with predictable performance and potentially lower egress costs.

2. IP Address Space Management: Ensuring non-overlapping IP ranges between environments. CIDR block planning becomes critical.

3. DNS Resolution: Hybrid DNS strategies allowing cloud resources to resolve on-premises names and vice versa.

4. Routing Complexity: Determining which traffic stays local versus transiting to cloud. May require BGP for dynamic routing.

5. Security Policy Consistency: Applying consistent security policies across heterogeneous environments. Firewalls, ACLs, and security groups must align.

Converting Mermaid diagram...

Multi-Cloud

Multi-cloud involves using services from multiple public cloud providers simultaneously. Organizations may use AWS for compute, GCP for machine learning, and Azure for enterprise applications.

Networking Challenges:

1. Inter-Cloud Connectivity: Connecting workloads across different providers. Options include:

VPN between clouds (each cloud terminates one end)
Third-party cloud exchange services (Megaport, Equinix Cloud Exchange)
SD-WAN overlays providing unified connectivity

2. Inconsistent Abstractions: Each provider has different networking constructs. AWS VPCs differ from Azure VNets differ from GCP VPCs. Teams must understand multiple paradigms.

4. Observability Fragmentation: Logs, metrics, and flow data are siloed in each provider's tooling. Unified visibility requires third-party solutions.

5. Security Policy Complexity: Maintaining consistent security across providers with different security group semantics, IAM models, and compliance certifications.

Multi-Cloud Reality Check

Traditional vs Cloud Networking Paradigms

Paradigm Comparison: Traditional vs Cloud Networking
Aspect	Traditional Networking	Cloud Networking
Provisioning	Hardware procurement, physical installation, manual configuration (weeks to months)	API calls, Infrastructure as Code, self-service (minutes)
Scaling	Capacity planning, hardware upgrades, overprovisioning for peak	Elastic scaling, pay-per-use, scale to zero possible
Configuration	CLI/GUI on individual devices, configuration drift risk	Declarative templates (CloudFormation, Terraform), version-controlled
Failure Domains	Physical: racks, switches, circuits; requires redundant equipment	Abstracted: Availability Zones, regions; provider handles physical redundancy
IP Management	IPAM databases, DHCP servers, manual VLAN assignment	CIDR allocation, embedded DHCP, automatic IP assignment within subnets
Security Controls	Physical firewalls, ACLs on routers, network taps	Security groups, NACLs, flow logs, built-in DDoS protection
Observability	SNMP, NetFlow, physical probe points	VPC Flow Logs, Cloud-native monitoring, API-driven telemetry
Cost Model	CapEx: purchase equipment, OpEx: power/cooling/maintenance	OpEx: per-resource charges, egress-based data transfer costs

Key Paradigm Shifts

1. From Hardware to Software:

2. From Static to Dynamic:

Implication: Network designs must accommodate ephemerality. Hardcoded IP addresses fail. Service discovery, DNS-based routing, and identity-based security become essential.

3. From Centralized to Distributed:

Traditional networks route traffic through central choke points—core routers, firewalls, load balancers. Cloud networks are inherently distributed across availability zones and regions.

The Stateless vs Stateful Distinction

Infrastructure as Code for Networks

Cloud networking enables—and demands—treating network configuration as code. Instead of clicking through consoles, networks are defined in Terraform, CloudFormation, Pulumi, or equivalent tools.

Benefits:

Version Control: Network configurations in Git, with history and rollback capability
Review Processes: Pull requests for network changes, peer review before deployment
Repeatability: Identical configurations across environments (dev/staging/prod)
Testing: Validate changes in lower environments before production
Compliance Automation: Policy-as-code tools verify configurations against baselines

Example: Terraform VPC Definition (AWS)

resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true
  
  tags = {
    Name        = "production-vpc"
    Environment = "production"
  }
}

resource "aws_subnet" "private" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.1.0/24"
  availability_zone = "us-east-1a"
  
  tags = {
    Name = "private-subnet-1a"
    Tier = "private"
  }
}

resource "aws_security_group" "web" {
  name        = "web-tier-sg"
  description = "Allow HTTPS inbound, all outbound"
  vpc_id      = aws_vpc.main.id
  
  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
  
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

This configuration is checked into version control, reviewed, and applied consistently across all environments. Changes are tracked, auditable, and reversible.

Provider-Specific Implementations

AWS (Amazon Web Services)

AWS pioneered many cloud networking patterns. Its Virtual Private Cloud (VPC) service is the foundation for AWS networking.

Key Components:

VPC: Isolated virtual network with up to /16 CIDR (65,536 addresses)
Subnets: Divide VPC CIDR across Availability Zones; classified as public (route to Internet Gateway) or private
Internet Gateway (IGW): Enables public internet access for VPC resources
NAT Gateway: Managed service for outbound internet from private subnets
Route Tables: Control traffic routing; associated with subnets
Security Groups: Stateful, instance-level firewall; allow rules only (implicit deny)
Network ACLs: Stateless, subnet-level firewall; allow and deny rules
VPC Peering: Connect two VPCs with private IP routing
Transit Gateway: Hub for connecting multiple VPCs and on-premises networks
PrivateLink: Access AWS services or hosted endpoints without traversing public internet

Cloud Provider Networking Terminology Comparison
Concept	AWS	Azure	GCP
Virtual Network	VPC	VNet	VPC
Subnet	Subnet	Subnet	Subnet/Subnetwork
Instance-level Firewall	Security Group	NSG (Network Security Group)	Firewall Rules
Subnet-level Firewall	Network ACL	NSG (at subnet level)	Firewall Rules (VPC level)
Internet Gateway	Internet Gateway	Implicit (public IP)	External IP / Cloud NAT
NAT Service	NAT Gateway	NAT Gateway / VM	Cloud NAT
Private Cloud Service Access	PrivateLink / VPC Endpoints	Private Endpoints	Private Service Connect
VPN Gateway	Virtual Private Gateway	VPN Gateway	Cloud VPN
Dedicated Connection	Direct Connect	ExpressRoute	Cloud Interconnect
Load Balancer (L4)	NLB (Network Load Balancer)	Azure Load Balancer	Network Load Balancer
Load Balancer (L7)	ALB (Application Load Balancer)	Application Gateway	HTTP(S) Load Balancer
Multi-VPC Hub	Transit Gateway	Virtual WAN	Network Connectivity Center

Azure (Microsoft Azure)

Azure networking aligns with enterprise consumption patterns, with strong hybrid cloud integration.

Distinctive Features:

Global VNets: VNets are regional, but global peering allows cross-region private connectivity
NSG Flexibility: Network Security Groups can attach to subnets OR network interfaces
Azure Firewall: Managed, cloud-native firewall service with threat intelligence
Virtual WAN: Simplified hub-and-spoke at global scale with automated routing
ExpressRoute: Premium connectivity with Global Reach enabling connectivity between on-premises sites via Microsoft backbone
Application Gateway: L7 load balancer with WAF capabilities built-in

Google Cloud Platform (GCP)

GCP's networking reflects Google's global network infrastructure, with unique architectural patterns.

Distinctive Features:

Global VPCs: Unlike AWS/Azure, GCP VPCs are global. Subnets are regional, but VPCs span the entire planet.
Automatic Mode VPCs: Can auto-create subnets in every region (convenient for prototyping)
Private Google Access: Instances without external IPs can reach Google APIs via internal routes
Cloud NAT: Regional, managed NAT service with automatic port allocation
Shared VPC: Allow resources from multiple projects to use a single VPC (centralized network management)
VPC Service Controls: Create security perimeters around sensitive services to prevent data exfiltration

The Global vs Regional VPC Distinction

Summary: Cloud Network Models

Key Takeaways

•Service models (IaaS/PaaS/SaaS) determine networking control: IaaS provides maximum flexibility with virtual networks, subnets, and firewall rules. PaaS abstracts most networking. SaaS abstracts all networking.
•The shared responsibility model defines security boundaries: Cloud providers secure infrastructure; customers secure configuration. Misunderstanding this boundary causes breaches.
•Deployment models (public/private/hybrid/multi-cloud) have distinct networking challenges: Public cloud offers scale but requires careful security. Hybrid demands connectivity planning. Multi-cloud adds complexity.
•Cloud networking differs fundamentally from traditional networking: Software-defined, API-driven, dynamic, and ephemeral. Infrastructure as Code is essential for manageable cloud networks.
•Provider implementations vary in terminology and architecture: AWS VPCs, Azure VNets, and GCP VPCs have similar concepts but different behaviors. Global vs regional scoping significantly affects design.
•Defense in depth applies to cloud networks: Layer security from edge (WAF/DDoS) through perimeter (security groups) to east-west traffic (microsegmentation) to data (encryption).

What's Next:

Foundation Established