Cloud Networking Fundamentals
VPCs, cloud architecture, security groups, hybrid connectivity, and multi-cloud networking
Chapter 9: Cloud Networking Fundamentals
The $150 Million Misconfiguration
In 2019, a misconfigured Web Application Firewall at a major financial institution allowed an attacker to exploit a server-side request forgery vulnerability and access the AWS metadata service. The attacker retrieved temporary credentials from the instance metadata and used them to access over 100 million customer records stored in S3 buckets.
The technical root cause? A cloud networking misconfiguration that allowed internal traffic to reach the metadata service combined with overly permissive IAM roles. The result was one of the largest data breaches in history, a $80 million fine, and an estimated $150 million in total costs.
This incident illustrates a crucial truth: cloud networking isn’t just traditional networking in someone else’s data center—it’s a fundamentally different paradigm with its own architecture, its own security model, and its own failure modes. Understanding cloud networking is no longer optional for security professionals.
Why Cloud Networking Matters
If you’ve been following along through this book, you’ve learned how networks work: IP addresses, routing, firewalls, and all the protocols that move data from one place to another. Cloud networking uses all of these concepts—but implements them in software, at massive scale, with new abstractions layered on top.
Think of the difference between driving your own car and using a ride-sharing service. The basic physics of transportation are the same, but the user experience, the economics, and the failure modes are completely different. Similarly, cloud networking uses the same fundamental protocols we’ve discussed, but everything is virtualized, API-driven, and shared across thousands of customers.
The shift to cloud computing has transformed how organizations build and operate networks:
| Traditional Networking | Cloud Networking |
|---|---|
| Physical hardware procurement | API-driven resource creation |
| Weeks to deploy new networks | Minutes to deploy new networks |
| Fixed topology | Programmable, dynamic topology |
| Hardware firewall appliances | Software-defined security controls |
| Capital expenditure | Operational expenditure |
| Local administrative control | Shared responsibility model |
For security professionals, this shift means:
- New attack surfaces: Cloud metadata services, IAM misconfigurations, cross-tenant attacks
- New defensive tools: Native cloud security services, infrastructure as code
- New skills required: Understanding cloud-specific networking concepts
In this chapter, we’ll build up from the fundamental building block—the Virtual Private Cloud—through subnets and security controls, to more advanced topics like hybrid connectivity and the critical security topic of instance metadata services. By the end, you’ll understand how cloud networks are structured and where the security risks lie.
Virtual Private Clouds (VPCs)
The foundation of cloud networking is the VPC—your isolated piece of the cloud. Before we can discuss cloud security, we need to understand what a VPC is and how it works.
What Is a VPC?
A Virtual Private Cloud (VPC) is a logically isolated virtual network within a cloud provider’s infrastructure. Think of it as your own private data center in the cloud—you control the IP addressing, subnets, routing, and security.
VPC Conceptual View
VPC Conceptual View:
───────────────────
┌────────────────────────────────────────────────────────────────┐
│ YOUR VPC │
│ (10.0.0.0/16) │
│ │
│ ┌─────────────────────┐ ┌─────────────────────┐ │
│ │ Public Subnet │ │ Private Subnet │ │
│ │ (10.0.1.0/24) │ │ (10.0.2.0/24) │ │
│ │ │ │ │ │
│ │ ┌─────┐ ┌─────┐ │ │ ┌─────┐ ┌─────┐ │ │
│ │ │ Web │ │ Web │ │ │ │ App │ │ DB │ │ │
│ │ └─────┘ └─────┘ │ │ └─────┘ └─────┘ │ │
│ │ │ │ │ │
│ └─────────┬───────────┘ └─────────┬───────────┘ │
│ │ │ │
│ └────────────┬─────────────┘ │
│ │ │
│ ┌─────┴─────┐ │
│ │ Router │ │
│ └─────┬─────┘ │
│ │ │
└──────────────────────────┼─────────────────────────────────────┘
│
┌──────┴──────┐
│ Internet │
│ Gateway │
└──────┬──────┘
│
[Internet]VPC Components
| Component | Purpose | AWS Name | Azure Name | GCP Name |
|---|---|---|---|---|
| Virtual Network | Isolated network | VPC | VNet | VPC |
| IP Range | Address space | CIDR Block | Address Space | Subnet Range |
| Subdivision | Network segments | Subnet | Subnet | Subnet |
| Internet Access | Outbound connectivity | Internet Gateway | - (built-in) | - (built-in) |
| Routing | Traffic direction | Route Table | Route Table | Routes |
| Access Control | Traffic filtering | Security Groups, NACLs | NSGs | Firewall Rules |
IP Addressing in VPCs
When creating a VPC, you define a CIDR block—the IP address range for your virtual network.
Best practices:
- Use RFC 1918 private ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
- Plan for growth—expanding CIDR ranges later is complicated
- Avoid overlapping ranges if you’ll connect multiple VPCs
- Leave room for subnets in multiple availability zones
VPC IP Planning Example
VPC IP Planning Example:
───────────────────────
Company VPC: 10.0.0.0/16 (65,536 addresses)
Production Subnets:
├── Public: 10.0.0.0/24 (256 addresses) - AZ-a
├── Public: 10.0.1.0/24 (256 addresses) - AZ-b
├── Private: 10.0.10.0/24 (256 addresses) - AZ-a
├── Private: 10.0.11.0/24 (256 addresses) - AZ-b
└── Database: 10.0.20.0/24 (256 addresses) - AZ-a/b
Development VPC: 10.1.0.0/16
Staging VPC: 10.2.0.0/16
(Non-overlapping ranges allow VPC peering)** COMMON MISTAKE**
Using 10.0.0.0/16 for every VPC. When you later need to connect VPCs or to on-premises networks, overlapping addresses create routing nightmares. Always plan address space as if all your VPCs will eventually need to communicate.
Subnets and Availability Zones
Once you have a VPC with an IP address range, the next step is dividing it into subnets. This is where cloud networking introduces its first critical security concept: the distinction between public and private subnets.
This distinction is fundamental to cloud security architecture. Getting it wrong is one of the most common causes of cloud breaches—resources that should be internal get exposed to the internet, or resources that need internet access are blocked and configured with workarounds that introduce vulnerabilities.
Public vs. Private Subnets
The distinction between public and private subnets is fundamental to cloud security:
Public Subnet:
- Has a route to an Internet Gateway
- Resources can have public IP addresses
- Accessible from the internet (if security groups allow)
- Use for: Load balancers, bastion hosts, public-facing services
Private Subnet:
- No direct route to the internet
- Resources have only private IP addresses
- Internet access via NAT Gateway (outbound only)
- Use for: Application servers, databases, internal services
Traffic Flow
Traffic Flow:
────────────
Inbound (Internet → Your Resources):
Internet → Internet Gateway → Public Subnet → (if needed) NAT → Private Subnet
Outbound (Your Resources → Internet):
Private Subnet → NAT Gateway → Internet Gateway → Internet
┌──────────────────┐
│ Internet │
└────────┬─────────┘
│
┌────────┴─────────┐
│ Internet Gateway │
└────────┬─────────┘
│
┌─────────────────┼─────────────────┐
│ │ │
┌─────┴─────┐ ┌──────┴──────┐ ┌─────┴─────┐
│ Public │ │ NAT │ │ Public │
│ Subnet │ │ Gateway │ │ Subnet │
│ (AZ-a) │ │ │ │ (AZ-b) │
└───────────┘ └──────┬──────┘ └───────────┘
│
┌─────────────────┼─────────────────┐
│ │ │
┌─────┴─────┐ ┌──────┴──────┐ ┌─────┴─────┐
│ Private │ │ Private │ │ Private │
│ Subnet │ │ Subnet │ │ Subnet │
│ (AZ-a) │ │ (AZ-b) │ │ (AZ-c) │
└───────────┘ └─────────────┘ └───────────┘Availability Zones
Cloud providers operate multiple data centers in each region, called Availability Zones (AZs). AZs are:
- Physically separate data centers
- Connected via high-bandwidth, low-latency links
- Isolated failure domains (power, cooling, networking)
High availability pattern: Deploy resources across multiple AZs so that failure of one AZ doesn’t cause complete outage.
MultiAZ Deployment
Multi-AZ Deployment:
───────────────────
┌─────────────────┐
│ Load Balancer │
└────────┬────────┘
│
┌─────────────┼─────────────┐
│ │ │
┌──────┴──────┐ ┌────┴────┐ ┌──────┴──────┐
│ AZ-a │ │ AZ-b │ │ AZ-c │
│ │ │ │ │ │
│ ┌───────┐ │ │┌───────┐│ │ ┌───────┐ │
│ │Web 1 │ │ ││Web 2 ││ │ │Web 3 │ │
│ └───────┘ │ │└───────┘│ │ └───────┘ │
│ │ │ │ │ │
│ ┌───────┐ │ │┌───────┐│ │ ┌───────┐ │
│ │App 1 │ │ ││App 2 ││ │ │App 3 │ │
│ └───────┘ │ │└───────┘│ │ └───────┘ │
│ │ │ │ │ │
└─────────────┘ └─────────┘ └─────────────┘Security Note: AZ design affects attack blast radius. Compromising a single AZ shouldn’t provide lateral movement to other AZs if security groups and network ACLs are properly configured. However, shared services (like NAT Gateways) can create cross-AZ dependencies.
Security Groups and Network ACLs
Now we arrive at the heart of cloud network security: controlling which traffic can flow where. In traditional networks, you’d configure firewall rules on dedicated firewall appliances. In the cloud, this functionality is built into the platform itself through security groups and network ACLs.
Understanding the difference between these two controls—and how they work together—is essential for designing secure cloud architectures.
Cloud networking provides two primary layers of traffic filtering:
Security Groups
Security groups are stateful virtual firewalls attached to instances (or other resources).
Characteristics:
- Operate at the instance level
- Stateful: return traffic automatically allowed
- Allow rules only (no explicit deny)
- Evaluated before traffic reaches instance
Security Group Example
Security Group Example:
─────────────────────
Web Server Security Group:
INBOUND:
┌──────────┬──────────┬─────────────────────┬────────────────────┐
│ Protocol │ Port │ Source │ Description │
├──────────┼──────────┼─────────────────────┼────────────────────┤
│ TCP │ 80 │ 0.0.0.0/0 │ HTTP from anywhere │
│ TCP │ 443 │ 0.0.0.0/0 │ HTTPS from anywhere│
│ TCP │ 22 │ 10.0.0.0/16 │ SSH from VPC only │
└──────────┴──────────┴─────────────────────┴────────────────────┘
OUTBOUND:
┌──────────┬──────────┬─────────────────────┬───────────────────┐
│ Protocol │ Port │ Destination │ Description │
├──────────┼──────────┼─────────────────────┼───────────────────┤
│ All │ All │ 0.0.0.0/0 │ Allow all outbound│
└──────────┴──────────┴─────────────────────┴───────────────────┘Security group best practices:
- Principle of least privilege—only allow necessary traffic
- Use security group references instead of CIDR when possible
- Create separate groups for different tiers (web, app, database)
- Document the purpose of each rule
Network ACLs (NACLs)
Network ACLs are stateless firewalls at the subnet level.
Characteristics:
- Operate at the subnet level
- Stateless: must explicitly allow return traffic
- Allow and deny rules
- Processed in order by rule number
NACL Example
NACL Example:
────────────
INBOUND Rules:
┌────────┬──────────┬───────────┬───────────────────┬────────┐
│ Rule # │ Protocol │ Port │ Source │ Action │
├────────┼──────────┼───────────┼───────────────────┼────────┤
│ 100 │ TCP │ 80 │ 0.0.0.0/0 │ ALLOW │
│ 110 │ TCP │ 443 │ 0.0.0.0/0 │ ALLOW │
│ 120 │ TCP │ 22 │ 10.0.0.0/8 │ ALLOW │
│ 130 │ TCP │ 1024-65535│ 0.0.0.0/0 │ ALLOW │← Ephemeral ports for return traffic
│ * │ All │ All │ 0.0.0.0/0 │ DENY │
└────────┴──────────┴───────────┴───────────────────┴────────┘
OUTBOUND Rules:
┌────────┬──────────┬───────────┬───────────────────┬────────┐
│ Rule # │ Protocol │ Port │ Destination │ Action │
├────────┼──────────┼───────────┼───────────────────┼────────┤
│ 100 │ TCP │ 80 │ 0.0.0.0/0 │ ALLOW │
│ 110 │ TCP │ 443 │ 0.0.0.0/0 │ ALLOW │
│ 120 │ TCP │ 1024-65535│ 0.0.0.0/0 │ ALLOW │← Response traffic
│ * │ All │ All │ 0.0.0.0/0 │ DENY │
└────────┴──────────┴───────────┴───────────────────┴────────┘Security Groups vs. NACLs
| Feature | Security Groups | Network ACLs |
|---|---|---|
| Level | Instance | Subnet |
| Statefulness | Stateful | Stateless |
| Rules | Allow only | Allow and Deny |
| Processing | All rules evaluated | Rules processed in order |
| Default | Deny all inbound, allow all outbound | Allow all |
| Use case | Primary access control | Subnet-level backup defense |
PRO TIP
Use security groups as your primary defense (they’re easier to manage due to statefulness). Use NACLs as a backup layer to block known-bad IP ranges or as a subnet-wide emergency shutoff.
Cloud Provider Comparison
The concepts we’ve discussed—VPCs, subnets, security groups—exist in all major cloud providers, but the terminology and implementation details differ. If you work in a multi-cloud environment (and many organizations do), understanding these differences is essential.
Let’s look at how AWS, Azure, and GCP implement cloud networking, and where their approaches diverge.
AWS Networking
AWS VPC Architecture
AWS VPC Architecture:
────────────────────
┌─────────────────────────────────────────────────────────────────┐
│ VPC │
│ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ Public Subnet │ │ Private Subnet │ │
│ │ │ │ │ │
│ │ ┌─────────────┐ │ │ ┌─────────────┐ │ │
│ │ │ EC2 Instance│ │ │ │RDS Database │ │ │
│ │ │ │ │ │ │ │ │ │
│ │ │ [SG: web] │ │ │ │ [SG: db] │ │ │
│ │ └─────────────┘ │ │ └─────────────┘ │ │
│ │ │ │ │ │
│ │ [NACL: public] │ │ [NACL: private] │ │
│ └────────┬────────┘ └────────┬────────┘ │
│ │ │ │
│ │ ┌──────────────────────┘ │
│ │ │ │
│ ┌────────┴─────────┴────────────────┐ │
│ │ Route Table │ │
│ │ 10.0.0.0/16 → local │ │
│ │ 0.0.0.0/0 → igw-xxx │ │
│ └─────────────────┬─────────────────┘ │
│ │ │
│ ┌────────┴────────┐ │
│ │Internet Gateway │ │
│ └────────┬────────┘ │
└─────────────────────┼───────────────────────────────────────────┘
│
[Internet]AWS-specific services:
- VPC Endpoints: Private connectivity to AWS services without internet
- Transit Gateway: Hub for connecting multiple VPCs and on-premises networks
- PrivateLink: Private connectivity to SaaS services
- VPC Flow Logs: Network traffic logging for analysis and troubleshooting
Azure Networking
Azure VNet Architecture
Azure VNet Architecture:
───────────────────────
┌─────────────────────────────────────────────────────────────────┐
│ VNet │
│ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ Subnet │ │ Subnet │ │
│ │ │ │ │ │
│ │ ┌─────────────┐ │ │ ┌─────────────┐ │ │
│ │ │ VM │ │ │ │ SQL DB │ │ │
│ │ │ │ │ │ │ │ │ │
│ │ │ [NSG: web] │ │ │ │[NSG: data] │ │ │
│ │ └─────────────┘ │ │ └─────────────┘ │ │
│ │ │ │ │ │
│ │ [NSG: subnet] │ │ [NSG: subnet] │ │
│ └─────────────────┘ └─────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Azure Firewall │ │
│ └─────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘Azure-specific features:
- Network Security Groups (NSGs): Can attach to subnets or NICs
- Azure Firewall: Managed firewall service with threat intelligence
- Virtual Network Service Endpoints: Private access to Azure services
- Azure Bastion: Secure RDP/SSH access without public IPs
GCP Networking
GCP VPC Architecture
GCP VPC Architecture:
────────────────────
┌─────────────────────────────────────────────────────────────────┐
│ Global VPC │
│ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ Subnet │ │ Subnet │ │
│ │ (us-east1) │ │ (europe-west1) │ │
│ │ │ │ │ │
│ │ ┌─────────────┐ │ │ ┌─────────────┐ │ │
│ │ │ Compute │ │ │ │ Compute │ │ │
│ │ │ Engine VM │ │ │ │ Engine VM │ │ │
│ │ └─────────────┘ │ │ └─────────────┘ │ │
│ │ │ │ │ │
│ │ [Firewall Rules apply to entire VPC, filtered by tags] │
│ └─────────────────┘ └─────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
Key difference: GCP VPCs are global by default (subnets are regional)GCP-specific features:
- Global VPCs: Single VPC can span all regions
- Firewall Rules: Apply at VPC level, filter by network tags
- Private Google Access: Access Google APIs without public IP
- Shared VPC: Centralized VPC shared across projects
Provider Comparison Summary
| Feature | AWS | Azure | GCP |
|---|---|---|---|
| VPC Scope | Regional | Regional | Global |
| Subnet Scope | Availability Zone | Regional | Regional |
| Security Control | Security Groups + NACLs | NSGs | Firewall Rules |
| Private Service Access | VPC Endpoints | Service Endpoints | Private Google Access |
| Multi-VPC Hub | Transit Gateway | Virtual WAN | Cloud Interconnect |
Hybrid Connectivity
So far, we’ve discussed cloud networking as if it exists in isolation. But most organizations don’t move everything to the cloud at once—they run hybrid environments with some systems in the cloud and others in traditional data centers. Connecting these environments securely is one of the most critical challenges in cloud networking.
Several options exist, each with different trade-offs in cost, performance, and complexity:
VPN Connections
Site-to-Site VPN creates an encrypted tunnel over the public internet.
VPN Architecture
VPN Architecture:
────────────────
On-Premises Cloud VPC
Network
┌──────────────┐ ┌──────────────┐
│ │ │ │
│ ┌────────┐ │ IPsec Tunnel over Internet │ ┌────────┐ │
│ │VPN │ │◄══════════════════════════════════►│ │VPN │ │
│ │Gateway │ │ │ │Gateway │ │
│ └────────┘ │ │ └────────┘ │
│ │ │ │
│ 10.0.0.0/8 │ │ 172.16.0.0/12│
└──────────────┘ └──────────────┘Characteristics:
- Quick to set up (hours)
- Low cost (just bandwidth)
- Encrypted (IPsec)
- Variable performance (depends on internet)
- Single points of failure possible
Dedicated Connections
Direct connections provide private, dedicated links between your data center and cloud provider.
| Provider | Service Name | Bandwidth Options |
|---|---|---|
| AWS | Direct Connect | 1 Gbps, 10 Gbps, 100 Gbps |
| Azure | ExpressRoute | 50 Mbps - 10 Gbps |
| GCP | Cloud Interconnect | 10 Gbps, 100 Gbps |
Direct Connect Architecture
Direct Connect Architecture:
───────────────────────────
On-Premises Colocation Facility AWS
┌─────────────┐ ┌─────────────────────────┐ ┌─────────────┐
│ │ │ │ │ │
│ Your │ │ ┌─────────┐ ┌──────┐ │ │ ┌─────────┐│
│ Network │─────┼──┤ Your ├──┤ AWS │──┼─────┼──┤ Direct ││
│ │ │ │ Router │ │ DX │ │ │ │ Connect ││
│ │ │ └─────────┘ │Router│ │ │ │ Gateway ││
│ │ │ └──────┘ │ │ └─────────┘│
│ │ │ │ │ │ │
└─────────────┘ └─────────────────────────┘ │ │ │
│ ┌───┴───┐ │
│ │ VPC │ │
│ └───────┘ │
└─────────────┘Characteristics:
- Consistent, predictable performance
- Higher bandwidth available
- Not encrypted by default (add your own)
- Higher cost
- Longer setup time (weeks to months)
Security Note: Direct connections aren’t encrypted by default—they’re just dedicated private links. For sensitive traffic, implement IPsec or MACsec encryption over the direct connection. Many organizations run VPN over Direct Connect for defense in depth.
VPC Peering
VPC Peering connects two VPCs for direct communication.
VPC Peering
VPC Peering:
───────────
┌─────────────────┐ Peering ┌─────────────────┐
│ VPC A │ Connection │ VPC B │
│ 10.0.0.0/16 │◄════════════════════════►│ 172.16.0.0/16 │
│ │ │ │
│ ┌─────────┐ │ │ ┌─────────┐ │
│ │Instance │────┼──────────────────────────┼────│Instance │ │
│ └─────────┘ │ │ └─────────┘ │
│ │ │ │
└─────────────────┘ └─────────────────┘
Requirements:
- Non-overlapping CIDR ranges
- Route table entries in both VPCs
- Security groups allowing trafficLimitations:
- Non-transitive (A↔B and B↔C doesn’t mean A↔C)
- Cannot peer VPCs with overlapping CIDRs
- Cross-region peering may have different pricing
Transit Gateway / Virtual WAN
For complex multi-VPC architectures, cloud providers offer hub-and-spoke connectivity:
Transit Gateway Architecture
Transit Gateway Architecture:
────────────────────────────
┌─────────────────────┐
│ Transit Gateway │
│ │
│ (Hub for all │
│ VPC connections) │
└──────────┬──────────┘
│
┌────────────────────┼────────────────────┐
│ │ │
┌─────┴─────┐ ┌─────┴─────┐ ┌─────┴─────┐
│ VPC A │ │ VPC B │ │ VPC C │
│ │ │ │ │ │
│Production │ │Development│ │ Shared │
│ │ │ │ │ Services │
└───────────┘ └───────────┘ └───────────┘
│
│
┌──────────┴──────────┐
│ On-Premises via │
│ VPN / Direct │
└─────────────────────┘Cloud Load Balancing and CDNs
Load Balancers
Cloud load balancers distribute traffic across multiple backend instances:
| Type | Layer | Use Case |
|---|---|---|
| Network Load Balancer | Layer 4 (TCP/UDP) | High performance, low latency |
| Application Load Balancer | Layer 7 (HTTP/HTTPS) | Content-based routing, WAF integration |
| Gateway Load Balancer | Layer 3 | Security appliance insertion |
Application Load Balancer
Application Load Balancer:
─────────────────────────
Users → [ALB] → Path-based routing:
│
├── /api/* → API Server Pool
├── /static/* → Static Content Pool
└── /* → Web Server PoolContent Delivery Networks (CDNs)
CDNs cache content at edge locations close to users:
CDN Architecture
CDN Architecture:
────────────────
User in Asia User in Europe User in Americas
│ │ │
▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐
│ Edge │ │ Edge │ │ Edge │
│ Tokyo │ │ London │ │ NYC │
└────┬────┘ └────┬────┘ └────┬────┘
│ │ │
└───────────────┼──────────────────┘
│
┌──────┴──────┐
│ Origin │
│ Server │
│ (your VPC) │
└─────────────┘Security considerations:
- CDN can mask origin IP (but misconfiguration can leak it)
- DDoS mitigation at the edge
- WAF often integrated with CDN
- Certificate management for HTTPS
THINK ABOUT IT
If an attacker discovers your origin server’s IP address (bypassing the CDN), what security controls remain? How would you detect if someone is trying to attack your origin directly?
Instance Metadata Service
Now we come to one of the most critical security topics in cloud networking—and the exact vulnerability that enabled the breach described at the beginning of this chapter.
The Instance Metadata Service (IMDS) is a cloud feature that seems helpful but has become one of the most exploited attack vectors in cloud environments. Understanding it is essential for anyone working with cloud infrastructure.
What Is IMDS?
Every cloud instance can query a special HTTP endpoint (typically 169.254.169.254) to retrieve information about itself: instance ID, IP address, region, and—critically—temporary security credentials.
Metadata Service Example (AWS)
Metadata Service Example (AWS):
──────────────────────────────
$ curl http://169.254.169.254/latest/meta-data/
ami-id
hostname
instance-id
instance-type
local-ipv4
public-ipv4
iam/ ← Security credentials here!
$ curl http://169.254.169.254/latest/meta-data/iam/security-credentials/MyRole
{
"AccessKeyId": "ASIA...",
"SecretAccessKey": "...",
"Token": "...",
"Expiration": "2025-01-21T12:00:00Z"
}IMDS Security Risks
The metadata service is a prime target for attackers:
- SSRF Attacks: If an application can be tricked into making HTTP requests to arbitrary URLs, attackers can point it at the metadata service
- Container Escapes: Containers might access the host’s metadata service
- Credential Theft: Stolen temporary credentials provide cloud API access
IMDS Mitigations
| Mitigation | Description |
|---|---|
| IMDSv2 (AWS) | Requires session token, blocks SSRF via header requirement |
| Metadata concealment | GKE’s approach to block metadata from pods |
| Instance profiles | Least-privilege IAM roles |
| Network controls | Block 169.254.169.254 from containers |
IMDSv2 Example
IMDSv2 Example:
──────────────
# Step 1: Get session token
$ TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" \
-H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
# Step 2: Use token to query metadata
$ curl -H "X-aws-ec2-metadata-token: $TOKEN" \
http://169.254.169.254/latest/meta-data/
# SSRF attacks can't easily add custom headers, blocking the attackSecurity Note: The Capital One breach mentioned in the chapter opening exploited IMDS. Always use IMDSv2 (or equivalent protections), apply least-privilege IAM roles, and implement network controls around metadata access. See Part II, Chapter 10 for exploitation techniques.
Cloud Networking Security Best Practices
Defense in Depth
Cloud Security Layers
Cloud Security Layers:
─────────────────────
┌─────────────────────────────────────────────────────────────────┐
│ Layer 1: Edge Protection │
│ - WAF, DDoS protection, CDN │
├─────────────────────────────────────────────────────────────────┤
│ Layer 2: Network Perimeter │
│ - VPC design, security groups, NACLs │
├─────────────────────────────────────────────────────────────────┤
│ Layer 3: Subnet Segmentation │
│ - Public/private separation, micro-segmentation │
├─────────────────────────────────────────────────────────────────┤
│ Layer 4: Instance Protection │
│ - Host-based firewalls, endpoint protection │
├─────────────────────────────────────────────────────────────────┤
│ Layer 5: Application Security │
│ - Input validation, authentication, encryption │
├─────────────────────────────────────────────────────────────────┤
│ Layer 6: Data Protection │
│ - Encryption at rest and in transit, access controls │
└─────────────────────────────────────────────────────────────────┘Security Checklist
- Use private subnets for backend resources
- Implement least-privilege security groups
- Enable VPC Flow Logs
- Use VPC endpoints for AWS service access
- Enable IMDSv2 and restrict IAM role permissions
- Implement encryption in transit (TLS)
- Use dedicated security account for monitoring
- Regular security group audits
- Network architecture documentation
TRY IT YOURSELF
If you have access to a cloud account:
- Create a VPC with public and private subnets
- Launch an instance in each subnet
- Configure security groups to allow SSH to public instance only
- Verify the private instance is not directly accessible
- Enable VPC Flow Logs and observe the traffic patterns
Key Takeaways
-
VPCs provide isolated virtual networks in the cloud with your own IP addressing, routing, and security controls
-
Subnets divide VPCs; public subnets have internet access, private subnets don’t
-
Security groups (stateful, instance-level) and NACLs (stateless, subnet-level) provide layered traffic filtering
-
Cloud providers differ in terminology and implementation, but core concepts are similar
-
Hybrid connectivity options include VPN, direct connections, and VPC peering
-
IMDS is a critical attack vector—use IMDSv2 and restrict permissions
-
Defense in depth applies to cloud networking just as it does to traditional networks
Review Questions
-
What is a VPC, and how does it provide network isolation?
-
Explain the difference between public and private subnets.
-
How do security groups differ from network ACLs? When would you use each?
-
Why is the instance metadata service a security concern, and how can you protect it?
-
Compare VPN and direct connection options for hybrid connectivity.
Further Reading
- AWS VPC Documentation: docs.aws.amazon.com/vpc
- Azure Virtual Network: docs.microsoft.com/azure/virtual-network
- GCP VPC: cloud.google.com/vpc/docs
- “Cloud Security Alliance Guidance”: cloudsecurityalliance.org