Opening Framing
Traditional network security relied on physical topology—firewalls sat between network segments, and changing network architecture meant moving cables and hardware. Cloud networking is entirely software-defined. You can create isolated networks, segment workloads, and implement firewall rules through API calls. This flexibility enables security architectures impossible in physical data centers but also introduces new risks when misconfigured.
Cloud network security operates at multiple layers: Virtual Private Clouds (VPCs) provide network isolation, security groups act as stateful firewalls around instances, Network ACLs provide stateless subnet-level filtering, and various gateway services control traffic flow in and out of cloud environments. Understanding how these controls interact—and where gaps can emerge—is essential for secure cloud architecture.
This week covers VPC architecture, security groups and NACLs, network segmentation strategies, connectivity options, traffic inspection, and common network security misconfigurations.
Key insight: Cloud networking security is about controlling traffic flow at multiple layers—each layer has different capabilities and limitations.
1) Virtual Private Cloud (VPC) Fundamentals
VPCs provide isolated network environments within cloud providers, forming the foundation of cloud network security:
VPC Core Concepts:
WHAT IS A VPC:
┌─────────────────────────────────────────────────────────────┐
│ Virtual Private Cloud (VPC): │
│ - Logically isolated network within cloud provider │
│ - Your own private IP address space │
│ - Full control over network configuration │
│ - Isolated from other customers by default │
│ │
│ Think of it as: Your own data center network in the cloud │
└─────────────────────────────────────────────────────────────┘
VPC COMPONENTS:
┌─────────────────────────────────────────────────────────────┐
│ CIDR Block: │
│ - IP address range for the VPC (e.g., 10.0.0.0/16) │
│ - Cannot be changed after creation │
│ - Plan carefully for future growth │
│ │
│ Subnets: │
│ - Subdivisions of VPC CIDR │
│ - Tied to single Availability Zone │
│ - Public (internet accessible) or Private │
│ │
│ Route Tables: │
│ - Control traffic routing between subnets │
│ - Associated with subnets │
│ - Determine where traffic goes │
│ │
│ Internet Gateway: │
│ - Enables internet connectivity for VPC │
│ - Required for public subnets │
│ │
│ NAT Gateway: │
│ - Allows private subnets to reach internet │
│ - Prevents inbound internet connections │
│ - Outbound-only internet access │
└─────────────────────────────────────────────────────────────┘VPC Architecture:
Typical Secure VPC Architecture:
┌─────────────────────────────────────────────────────────────┐
│ REGION │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ VPC (10.0.0.0/16) │ │
│ │ │ │
│ │ ┌─────────────────┐ ┌─────────────────┐ │ │
│ │ │ AZ-1 (us-e-1a)│ │ AZ-2 (us-e-1b)│ │ │
│ │ │ │ │ │ │ │
│ │ │ ┌─────────────┐ │ │ ┌─────────────┐ │ │ │
│ │ │ │Public Subnet│ │ │ │Public Subnet│ │ │ │
│ │ │ │10.0.1.0/24 │ │ │ │10.0.2.0/24 │ │ │ │
│ │ │ │ (ALB) │ │ │ │ (ALB) │ │ │ │
│ │ │ └─────────────┘ │ │ └─────────────┘ │ │ │
│ │ │ │ │ │ │ │
│ │ │ ┌─────────────┐ │ │ ┌─────────────┐ │ │ │
│ │ │ │Private Sub │ │ │ │Private Sub │ │ │ │
│ │ │ │10.0.11.0/24 │ │ │ │10.0.12.0/24 │ │ │ │
│ │ │ │ (App Tier) │ │ │ │ (App Tier) │ │ │ │
│ │ │ └─────────────┘ │ │ └─────────────┘ │ │ │
│ │ │ │ │ │ │ │
│ │ │ ┌─────────────┐ │ │ ┌─────────────┐ │ │ │
│ │ │ │Private Sub │ │ │ │Private Sub │ │ │ │
│ │ │ │10.0.21.0/24 │ │ │ │10.0.22.0/24 │ │ │ │
│ │ │ │ (DB Tier) │ │ │ │ (DB Tier) │ │ │ │
│ │ │ └─────────────┘ │ │ └─────────────┘ │ │ │
│ │ └─────────────────┘ └─────────────────┘ │ │
│ │ │ │
│ └───────────────────────────────────────────────────────┘ │
│ │ │
│ ┌─────────┴─────────┐ │
│ │ Internet Gateway │ │
│ └─────────┬─────────┘ │
│ │ │
└──────────────────────────────┼──────────────────────────────┘
│
INTERNETPublic vs Private Subnets:
Subnet Types and Security:
PUBLIC SUBNET:
┌─────────────────────────────────────────────────────────────┐
│ Characteristics: │
│ - Route to Internet Gateway (0.0.0.0/0 → IGW) │
│ - Instances can have public IPs │
│ - Directly reachable from internet │
│ │
│ Use For: │
│ - Load balancers │
│ - Bastion hosts │
│ - NAT Gateways │
│ - Public-facing services │
│ │
│ Security Considerations: │
│ - Minimize resources in public subnets │
│ - Strict security groups required │
│ - Consider WAF for web traffic │
│ │
│ Route Table: │
│ Destination Target │
│ 10.0.0.0/16 local │
│ 0.0.0.0/0 igw-xxxxxx (Internet Gateway) │
└─────────────────────────────────────────────────────────────┘
PRIVATE SUBNET:
┌─────────────────────────────────────────────────────────────┐
│ Characteristics: │
│ - No direct route to Internet Gateway │
│ - Not reachable from internet │
│ - Can reach internet via NAT Gateway (outbound only) │
│ │
│ Use For: │
│ - Application servers │
│ - Databases │
│ - Internal services │
│ - Backend processing │
│ │
│ Security Considerations: │
│ - Primary location for workloads │
│ - Access via bastion or VPN │
│ - Still needs security groups │
│ │
│ Route Table: │
│ Destination Target │
│ 10.0.0.0/16 local │
│ 0.0.0.0/0 nat-xxxxxx (NAT Gateway) │
└─────────────────────────────────────────────────────────────┘
ISOLATED SUBNET:
┌─────────────────────────────────────────────────────────────┐
│ Characteristics: │
│ - No route to internet at all │
│ - Completely isolated │
│ - Access via VPC endpoints only │
│ │
│ Use For: │
│ - Highly sensitive workloads │
│ - Databases with no internet requirement │
│ - Compliance-sensitive systems │
│ │
│ Route Table: │
│ Destination Target │
│ 10.0.0.0/16 local │
│ (no default route) │
└─────────────────────────────────────────────────────────────┘Key insight: Default to private subnets. Only place resources in public subnets when they absolutely must be internet-accessible.
2) Security Groups and Network ACLs
Security groups and NACLs provide complementary layers of network access control:
Security Groups vs NACLs:
┌─────────────────────────────────────────────────────────────┐
│ SECURITY GROUPS │
├─────────────────────────────────────────────────────────────┤
│ Level: Instance (ENI) │
│ State: Stateful (return traffic automatically allowed) │
│ Rules: Allow only (implicit deny) │
│ Evaluation: All rules evaluated │
│ Applies To: Specific instances/resources │
│ │
│ Best For: │
│ - Micro-segmentation │
│ - Application-specific rules │
│ - Dynamic environments │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ NETWORK ACLs │
├─────────────────────────────────────────────────────────────┤
│ Level: Subnet │
│ State: Stateless (must allow return traffic explicitly) │
│ Rules: Allow and Deny │
│ Evaluation: Rules processed in order (lowest number first) │
│ Applies To: All traffic in/out of subnet │
│ │
│ Best For: │
│ - Subnet-level protection │
│ - Blocking known bad IPs │
│ - Compliance requirements │
│ - Defense in depth │
└─────────────────────────────────────────────────────────────┘
COMPARISON:
┌────────────────┬──────────────────┬──────────────────┐
│ Feature │ Security Group │ NACL │
├────────────────┼──────────────────┼──────────────────┤
│ Operates at │ Instance │ Subnet │
│ Stateful │ Yes │ No │
│ Allow rules │ Yes │ Yes │
│ Deny rules │ No (implicit) │ Yes (explicit) │
│ Rule order │ All evaluated │ Number order │
│ Default │ Deny all inbound │ Allow all │
│ │ Allow all out │ │
└────────────────┴──────────────────┴──────────────────┘Security Group Configuration:
Security Group Best Practices:
PRINCIPLE: Least Privilege Network Access
WEB SERVER SECURITY GROUP:
┌─────────────────────────────────────────────────────────────┐
│ Inbound Rules: │
│ ┌─────────┬──────────┬─────────────────────────────────┐ │
│ │ Type │ Port │ Source │ │
│ ├─────────┼──────────┼─────────────────────────────────┤ │
│ │ HTTPS │ 443 │ 0.0.0.0/0 (or CloudFront IPs) │ │
│ │ HTTP │ 80 │ 0.0.0.0/0 (redirect to HTTPS) │ │
│ └─────────┴──────────┴─────────────────────────────────┘ │
│ │
│ Outbound Rules: │
│ ┌─────────┬──────────┬─────────────────────────────────┐ │
│ │ Type │ Port │ Destination │ │
│ ├─────────┼──────────┼─────────────────────────────────┤ │
│ │ Custom │ 8080 │ sg-app-tier │ │
│ │ HTTPS │ 443 │ 0.0.0.0/0 (for external APIs) │ │
│ └─────────┴──────────┴─────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
APPLICATION TIER SECURITY GROUP:
┌─────────────────────────────────────────────────────────────┐
│ Inbound Rules: │
│ ┌─────────┬──────────┬─────────────────────────────────┐ │
│ │ Type │ Port │ Source │ │
│ ├─────────┼──────────┼─────────────────────────────────┤ │
│ │ Custom │ 8080 │ sg-web-tier (reference SG!) │ │
│ │ SSH │ 22 │ sg-bastion │ │
│ └─────────┴──────────┴─────────────────────────────────┘ │
│ │
│ Outbound Rules: │
│ ┌─────────┬──────────┬─────────────────────────────────┐ │
│ │ Type │ Port │ Destination │ │
│ ├─────────┼──────────┼─────────────────────────────────┤ │
│ │ MySQL │ 3306 │ sg-database-tier │ │
│ │ HTTPS │ 443 │ 0.0.0.0/0 │ │
│ └─────────┴──────────┴─────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
DATABASE TIER SECURITY GROUP:
┌─────────────────────────────────────────────────────────────┐
│ Inbound Rules: │
│ ┌─────────┬──────────┬─────────────────────────────────┐ │
│ │ Type │ Port │ Source │ │
│ ├─────────┼──────────┼─────────────────────────────────┤ │
│ │ MySQL │ 3306 │ sg-app-tier │ │
│ └─────────┴──────────┴─────────────────────────────────┘ │
│ │
│ Outbound Rules: │
│ ┌─────────┬──────────┬─────────────────────────────────┐ │
│ │ Type │ Port │ Destination │ │
│ ├─────────┼──────────┼─────────────────────────────────┤ │
│ │ (none or minimal - DB rarely needs outbound) │ │
│ └─────────┴──────────┴─────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
KEY PRACTICES:
- Reference security groups as sources (not IP ranges)
- Restrict outbound as well as inbound
- One security group per role/function
- Use descriptive names and tags
- Document purpose in descriptionsNACL Configuration:
Network ACL Examples:
PRIVATE SUBNET NACL:
┌─────────────────────────────────────────────────────────────┐
│ Inbound Rules: │
│ ┌──────┬────────┬──────────┬───────────────┬─────────────┐ │
│ │ Rule │ Type │ Port │ Source │ Action │ │
│ ├──────┼────────┼──────────┼───────────────┼─────────────┤ │
│ │ 100 │ Custom │ 8080 │ 10.0.1.0/24 │ ALLOW │ │
│ │ 110 │ SSH │ 22 │ 10.0.100.0/24 │ ALLOW │ │
│ │ 120 │ Custom │ 1024-65535│10.0.0.0/16 │ ALLOW │ │
│ │ * │ ALL │ ALL │ 0.0.0.0/0 │ DENY │ │
│ └──────┴────────┴──────────┴───────────────┴─────────────┘ │
│ │
│ Outbound Rules: │
│ ┌──────┬────────┬──────────┬───────────────┬─────────────┐ │
│ │ Rule │ Type │ Port │ Destination │ Action │ │
│ ├──────┼────────┼──────────┼───────────────┼─────────────┤ │
│ │ 100 │ MySQL │ 3306 │ 10.0.21.0/24 │ ALLOW │ │
│ │ 110 │ HTTPS │ 443 │ 0.0.0.0/0 │ ALLOW │ │
│ │ 120 │ Custom │ 1024-65535│10.0.0.0/16 │ ALLOW │ │
│ │ * │ ALL │ ALL │ 0.0.0.0/0 │ DENY │ │
│ └──────┴────────┴──────────┴───────────────┴─────────────┘ │
└─────────────────────────────────────────────────────────────┘
BLOCKING KNOWN BAD IPs (NACL):
┌─────────────────────────────────────────────────────────────┐
│ Inbound Rules: │
│ ┌──────┬────────┬──────────┬───────────────┬─────────────┐ │
│ │ Rule │ Type │ Port │ Source │ Action │ │
│ ├──────┼────────┼──────────┼───────────────┼─────────────┤ │
│ │ 10 │ ALL │ ALL │ 198.51.100.0/24│ DENY │ │
│ │ 20 │ ALL │ ALL │ 203.0.113.0/24│ DENY │ │
│ │ 100 │ HTTP │ 80 │ 0.0.0.0/0 │ ALLOW │ │
│ │ 110 │ HTTPS │ 443 │ 0.0.0.0/0 │ ALLOW │ │
│ │ * │ ALL │ ALL │ 0.0.0.0/0 │ DENY │ │
│ └──────┴────────┴──────────┴───────────────┴─────────────┘ │
│ │
│ Note: Lower rule numbers evaluated first │
│ Block rules must come before allow rules │
└─────────────────────────────────────────────────────────────┘
NACL CONSIDERATIONS:
- Stateless: Must allow ephemeral ports (1024-65535) for return traffic
- Rule order matters: Lower numbers processed first
- Explicit deny needed (unlike security groups)
- Use for subnet-level, broad controls
- Not ideal for fine-grained access controlKey insight: Use security groups for fine-grained, instance-level control. Use NACLs for subnet-level blocking and defense in depth.
3) Network Segmentation Strategies
Effective network segmentation limits blast radius and enforces security boundaries:
Segmentation Strategies:
MULTI-TIER ARCHITECTURE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ INTERNET │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ PUBLIC TIER (DMZ) │ │
│ │ - Load Balancers, WAF, CDN │ │
│ │ - Minimal attack surface │ │
│ └────────────────────────┬─────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ APPLICATION TIER (Private) │ │
│ │ - Web servers, app servers, containers │ │
│ │ - No direct internet access │ │
│ └────────────────────────┬─────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ DATA TIER (Isolated) │ │
│ │ - Databases, data stores │ │
│ │ - Most restricted access │ │
│ └──────────────────────────────────────────────────────┘ │
│ │
│ Traffic Flow: Internet → Public → App → Data │
│ Each tier has progressively more restricted access │
└─────────────────────────────────────────────────────────────┘
ENVIRONMENT SEPARATION:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PRODUCTION VPC STAGING VPC DEV VPC │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────┐ │
│ │ Strict │ │ Moderate │ │ Relaxed │ │
│ │ controls │ │ controls │ │ controls │ │
│ │ Limited │ │ Some access │ │ Broader │ │
│ │ access │ │ │ │ access │ │
│ └──────────────┘ └──────────────┘ └──────────┘ │
│ │
│ Options: │
│ 1. Separate VPCs (strongest isolation) │
│ 2. Separate subnets (moderate isolation) │
│ 3. Separate accounts (best practice) │
│ │
│ No Production ←→ Dev traffic allowed │
└─────────────────────────────────────────────────────────────┘
MICROSERVICES SEGMENTATION:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │Service A│◄──►│Service B│◄──►│Service C│◄──►│Service D│ │
│ │ SG-A │ │ SG-B │ │ SG-C │ │ SG-D │ │
│ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │
│ │
│ Each service has its own security group │
│ Traffic allowed only between necessary services │
│ │
│ SG-A: Allows inbound from SG-B only │
│ SG-B: Allows inbound from SG-A, SG-C │
│ SG-C: Allows inbound from SG-B only │
│ SG-D: Allows inbound from SG-C only │
│ │
│ Compromise of Service A cannot directly reach Service D │
└─────────────────────────────────────────────────────────────┘Multi-Account Strategy:
AWS Organizations Multi-Account Structure:
┌─────────────────────────────────────────────────────────────┐
│ ORGANIZATION ROOT │
│ │ │
│ ┌─────────────────────┼─────────────────────┐ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌───────────┐ ┌───────────┐ ┌───────────┐ │
│ │ Security │ │ Workloads │ │ Sandbox │ │
│ │ OU │ │ OU │ │ OU │ │
│ └─────┬─────┘ └─────┬─────┘ └─────┬─────┘ │
│ │ │ │ │
│ ┌───┴───┐ ┌────┴────┐ ┌───┴───┐ │
│ │ │ │ │ │ │ │
│ ▼ ▼ ▼ ▼ ▼ ▼ │
│ ┌────┐ ┌────┐ ┌──────┐ ┌──────┐ ┌─────┐ ┌─────┐ │
│ │Log │ │Sec │ │ Prod │ │ Dev │ │Dev1 │ │Dev2 │ │
│ │Arch│ │Tool│ │ │ │ │ │ │ │ │ │
│ └────┘ └────┘ └──────┘ └──────┘ └─────┘ └─────┘ │
│ │
│ Benefits: │
│ - Blast radius limited to single account │
│ - Separate billing and resource limits │
│ - Independent IAM boundaries │
│ - Service Control Policies per OU │
│ - Centralized security tooling in Security OU │
└─────────────────────────────────────────────────────────────┘
CROSS-ACCOUNT NETWORK PATTERNS:
┌─────────────────────────────────────────────────────────────┐
│ VPC Peering: │
│ - Direct connection between two VPCs │
│ - Non-transitive (A↔B, B↔C doesn't mean A↔C) │
│ - Good for: Few connections, simple topologies │
│ │
│ Transit Gateway: │
│ - Hub-and-spoke connectivity │
│ - Transitive routing │
│ - Centralized management │
│ - Good for: Many VPCs, complex topologies │
│ │
│ PrivateLink: │
│ - Expose service to other VPCs privately │
│ - Consumer creates endpoint in their VPC │
│ - No VPC peering required │
│ - Good for: Shared services, SaaS connectivity │
└─────────────────────────────────────────────────────────────┘Key insight: Segmentation is about limiting blast radius. When a breach occurs, proper segmentation contains the damage.
4) Connectivity and Traffic Control
Controlling how traffic enters and leaves cloud environments is essential for security:
Connectivity Options:
INTERNET CONNECTIVITY:
┌─────────────────────────────────────────────────────────────┐
│ Internet Gateway (IGW): │
│ - Bidirectional internet access │
│ - Required for public subnets │
│ - Highly available, managed by AWS │
│ │
│ NAT Gateway: │
│ - Outbound-only internet for private subnets │
│ - Instances can reach internet, internet can't reach them │
│ - Charged per hour and per GB │
│ │
│ Egress-Only Internet Gateway: │
│ - For IPv6 traffic │
│ - Similar to NAT Gateway for IPv6 │
└─────────────────────────────────────────────────────────────┘
PRIVATE CONNECTIVITY:
┌─────────────────────────────────────────────────────────────┐
│ VPC Endpoints (Gateway): │
│ - S3 and DynamoDB only │
│ - Traffic stays on AWS network │
│ - No NAT Gateway needed for these services │
│ - Free (no data processing charges) │
│ │
│ VPC Endpoints (Interface / PrivateLink): │
│ - Most AWS services │
│ - Creates ENI in your subnet │
│ - Private IP address for service │
│ - Charged per hour and per GB │
│ │
│ VPN (Site-to-Site): │
│ - Encrypted tunnel over internet │
│ - Connects on-premises to VPC │
│ - Cost-effective for moderate bandwidth │
│ │
│ Direct Connect: │
│ - Dedicated physical connection │
│ - Higher bandwidth, lower latency │
│ - More expensive, longer provisioning │
└─────────────────────────────────────────────────────────────┘VPC Endpoints for Security:
VPC Endpoints Security Benefits:
WITHOUT ENDPOINT:
┌─────────────────────────────────────────────────────────────┐
│ │
│ Private Subnet NAT GW Internet │
│ ┌──────────┐ ┌─────────┐ ┌─────────┐ │
│ │ EC2 │────────►│ NAT │──────►│ Internet│ │
│ │ Instance │ │ Gateway │ │ │ │
│ └──────────┘ └─────────┘ └────┬────┘ │
│ │ │
│ ▼ │
│ ┌─────────┐ │
│ │ S3 │ │
│ │ (Public)│ │
│ └─────────┘ │
│ │
│ Problems: │
│ - Traffic traverses public internet │
│ - NAT Gateway costs ($$$) │
│ - Potential data exposure │
└─────────────────────────────────────────────────────────────┘
WITH GATEWAY ENDPOINT:
┌─────────────────────────────────────────────────────────────┐
│ │
│ Private Subnet AWS Network │
│ ┌──────────┐ ┌─────────┐ │
│ │ EC2 │────────────────────────►│ S3 │ │
│ │ Instance │ (via VPC Endpoint) │ │ │
│ └──────────┘ └─────────┘ │
│ │
│ Benefits: │
│ - Traffic stays on AWS backbone │
│ - No NAT Gateway costs │
│ - Can restrict to specific buckets │
│ - Endpoint policies for access control │
└─────────────────────────────────────────────────────────────┘
S3 GATEWAY ENDPOINT POLICY:
{
"Statement": [
{
"Sid": "RestrictToSpecificBuckets",
"Effect": "Allow",
"Principal": "*",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": [
"arn:aws:s3:::my-app-bucket/*",
"arn:aws:s3:::my-logs-bucket/*"
]
}
]
}
S3 BUCKET POLICY (Restrict to VPC Endpoint):
{
"Statement": [
{
"Sid": "DenyNonVPCEndpoint",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::sensitive-bucket",
"arn:aws:s3:::sensitive-bucket/*"
],
"Condition": {
"StringNotEquals": {
"aws:sourceVpce": "vpce-1234567890abcdef"
}
}
}
]
}Traffic Inspection:
Traffic Inspection Options:
AWS NETWORK FIREWALL:
┌─────────────────────────────────────────────────────────────┐
│ Managed firewall service with: │
│ - Stateful inspection │
│ - Intrusion prevention (IPS) │
│ - Web filtering │
│ - Domain filtering │
│ │
│ Deployment: │
│ - Deployed in firewall subnet │
│ - Route traffic through firewall endpoints │
│ - Inspect ingress, egress, or east-west │
│ │
│ Use Cases: │
│ - Compliance requirements (inspect all traffic) │
│ - Threat detection at network layer │
│ - Blocking known malicious domains │
└─────────────────────────────────────────────────────────────┘
GATEWAY LOAD BALANCER (GWLB):
┌─────────────────────────────────────────────────────────────┐
│ Deploy third-party virtual appliances: │
│ - Next-gen firewalls (Palo Alto, Fortinet) │
│ - IDS/IPS systems │
│ - Deep packet inspection │
│ │
│ Architecture: │
│ - GWLB endpoints in your VPC │
│ - Traffic routed to appliance VPC │
│ - Inspected and returned │
└─────────────────────────────────────────────────────────────┘
VPC TRAFFIC MIRRORING:
┌─────────────────────────────────────────────────────────────┐
│ Copy network traffic for analysis: │
│ - Select source ENIs │
│ - Mirror to target (NLB, ENI) │
│ - Filter by protocol, port, direction │
│ │
│ Use Cases: │
│ - Security monitoring (IDS) │
│ - Threat detection │
│ - Forensics │
│ - Compliance monitoring │
└─────────────────────────────────────────────────────────────┘Key insight: VPC endpoints keep traffic private and reduce costs. Use them for all AWS service access from private subnets.
5) Common Network Security Misconfigurations
Network misconfigurations are among the most common cloud security issues:
Common Network Misconfigurations:
OVERLY PERMISSIVE SECURITY GROUPS:
┌─────────────────────────────────────────────────────────────┐
│ Problem: 0.0.0.0/0 on sensitive ports │
│ │
│ Dangerous Examples: │
│ - SSH (22) open to 0.0.0.0/0 │
│ - RDP (3389) open to 0.0.0.0/0 │
│ - Database ports (3306, 5432) open to 0.0.0.0/0 │
│ - All traffic allowed (0.0.0.0/0, all ports) │
│ │
│ Impact: │
│ - Direct attack surface from internet │
│ - Brute force attacks │
│ - Exploitation of vulnerabilities │
│ │
│ Fix: │
│ - Restrict to specific IPs or security groups │
│ - Use bastion hosts or Session Manager │
│ - Never expose management ports to internet │
└─────────────────────────────────────────────────────────────┘
PUBLIC SUBNETS FOR PRIVATE WORKLOADS:
┌─────────────────────────────────────────────────────────────┐
│ Problem: Databases or app servers in public subnets │
│ │
│ Why It Happens: │
│ - "Easier" to give public IP for access │
│ - Didn't understand public vs private │
│ - Default VPC has all public subnets │
│ │
│ Impact: │
│ - Direct internet exposure │
│ - Relies solely on security groups │
│ - One misconfiguration = breach │
│ │
│ Fix: │
│ - Private subnets for all non-public workloads │
│ - Bastion hosts or VPN for access │
│ - Don't use default VPC for production │
└─────────────────────────────────────────────────────────────┘
DEFAULT VPC USAGE:
┌─────────────────────────────────────────────────────────────┐
│ Problem: Using default VPC for production │
│ │
│ Default VPC Issues: │
│ - All subnets are public by default │
│ - Security groups may be too permissive │
│ - No deliberate network design │
│ - Shared with quick tests and experiments │
│ │
│ Fix: │
│ - Create custom VPCs for all workloads │
│ - Delete or restrict default VPC │
│ - Use infrastructure as code for consistency │
└─────────────────────────────────────────────────────────────┘
UNRESTRICTED OUTBOUND:
┌─────────────────────────────────────────────────────────────┐
│ Problem: All outbound traffic allowed │
│ │
│ Default Behavior: │
│ - Security groups allow all outbound by default │
│ - Instances can reach any internet destination │
│ │
│ Risk: │
│ - Data exfiltration to attacker infrastructure │
│ - C2 communication │
│ - Cryptomining │
│ │
│ Fix: │
│ - Restrict outbound to required destinations │
│ - Use VPC endpoints instead of internet │
│ - Egress filtering with firewall │
│ - Domain allowlisting │
└─────────────────────────────────────────────────────────────┘
MISSING VPC FLOW LOGS:
┌─────────────────────────────────────────────────────────────┐
│ Problem: No visibility into network traffic │
│ │
│ Impact: │
│ - Can't investigate incidents │
│ - No baseline for anomaly detection │
│ - Compliance failures │
│ │
│ Fix: │
│ - Enable VPC Flow Logs for all VPCs │
│ - Send to CloudWatch Logs or S3 │
│ - Analyze for security insights │
│ │
│ Flow Log Record: │
│ 2 123456789 eni-abc123 10.0.1.5 52.94.76.10 │
│ 34892 443 6 10 840 1620000000 1620000060 ACCEPT OK │
└─────────────────────────────────────────────────────────────┘Network Security Checklist:
Network Security Best Practices:
VPC DESIGN:
□ Custom VPC (not default) for all workloads
□ Private subnets for databases and app servers
□ Public subnets only for load balancers, NAT, bastion
□ Multi-AZ deployment for availability
□ Appropriate CIDR planning for growth
SECURITY GROUPS:
□ Least privilege - specific ports and sources
□ No 0.0.0.0/0 on management ports (SSH, RDP)
□ Reference security groups instead of IPs where possible
□ Restrict outbound traffic
□ Regular review and cleanup of unused rules
□ Descriptive names and documentation
NETWORK ACLs:
□ Used for subnet-level controls
□ Block known malicious IP ranges
□ Defense in depth with security groups
CONNECTIVITY:
□ VPC endpoints for AWS service access
□ No public IPs on private workloads
□ Site-to-Site VPN or Direct Connect for on-premises
□ PrivateLink for cross-account services
MONITORING:
□ VPC Flow Logs enabled
□ DNS query logging
□ Traffic analysis for anomalies
□ Alerting on security group changes
SEGMENTATION:
□ Separate VPCs or accounts per environment
□ Micro-segmentation between services
□ Transit Gateway for managed connectivity
□ No direct dev-to-prod network pathsKey insight: Most network security issues are misconfigurations, not sophisticated attacks. Prevent them with automation and regular auditing.
Real-World Context
Case Study: MongoDB Ransomware Attacks
In 2017, attackers scanned the internet for MongoDB databases exposed without authentication. They found thousands of databases with default configurations—no password required, listening on all interfaces. Many of these were cloud deployments where security groups allowed 0.0.0.0/0 on port 27017. Attackers deleted the data and left ransom notes. This mass exploitation demonstrated how a single security group misconfiguration exposes databases to the entire internet. Proper network security—private subnets, restricted security groups—would have prevented all these attacks.
Case Study: SSRF and Metadata Service
Server-Side Request Forgery (SSRF) attacks exploit applications that fetch URLs provided by users. In cloud environments, SSRF can access the metadata service at 169.254.169.254, retrieving IAM credentials. The Capital One breach used this technique. Network-level mitigations include: IMDSv2 (requires session tokens), restricting metadata service access via iptables, using VPC endpoints with restrictive policies, and network egress filtering to block metadata IP ranges from web servers.
Azure/GCP Network Security Comparison:
Cross-Provider Network Security:
AZURE:
┌─────────────────────────────────────────────────────────────┐
│ Virtual Network (VNet) = VPC equivalent │
│ Network Security Groups (NSG) = Security Groups │
│ - Applied to subnets or NICs │
│ - Support both allow and deny │
│ - Priority-based rule evaluation │
│ │
│ Azure Firewall = Managed firewall service │
│ Private Endpoints = Interface VPC endpoints │
│ Service Endpoints = Simplified private connectivity │
│ │
│ Key Difference: │
│ - NSGs have explicit allow AND deny rules │
│ - Application Security Groups (ASG) for grouping │
└─────────────────────────────────────────────────────────────┘
GCP:
┌─────────────────────────────────────────────────────────────┐
│ VPC Network = Global (spans regions) │
│ Firewall Rules = Applied at VPC level │
│ - Target by tags or service accounts │
│ - Priority-based evaluation │
│ │
│ Private Google Access = VPC endpoints equivalent │
│ Private Service Connect = PrivateLink equivalent │
│ Cloud NAT = NAT Gateway equivalent │
│ │
│ Key Difference: │
│ - VPC is global, subnets are regional │
│ - Firewall rules reference service accounts │
│ - Hierarchical firewall policies │
└─────────────────────────────────────────────────────────────┘Network security fundamentals apply across all cloud providers. Learn the concepts, then apply to specific provider implementations.
Guided Lab: Secure VPC Design and Implementation
In this lab, you'll design and implement a secure multi-tier VPC architecture.
Lab Environment:
- AWS account with VPC permissions
- AWS CLI or Console
- Network diagram tool
Exercise Steps:
- Design VPC CIDR and subnet layout
- Create VPC with public and private subnets
- Configure route tables for each subnet type
- Create Internet Gateway and NAT Gateway
- Design security groups for three-tier architecture
- Implement security groups with least privilege
- Create VPC endpoints for S3
- Enable VPC Flow Logs
- Test connectivity and verify isolation
Reflection Questions:
- How does network isolation reduce risk compared to flat networks?
- What traffic patterns do your security groups allow/deny?
- How would you detect a network security misconfiguration?
Week Outcome Check
By the end of this week, you should be able to:
- Design VPC architectures with appropriate segmentation
- Distinguish between public, private, and isolated subnets
- Configure security groups with least privilege
- Implement Network ACLs for subnet-level controls
- Deploy VPC endpoints for private AWS service access
- Design multi-tier and multi-account network architectures
- Identify and remediate common network misconfigurations
- Enable network monitoring with VPC Flow Logs
🎯 Hands-On Labs (Free & Essential)
Build and secure cloud networks through hands-on configuration and exploitation practice.
🌐 TryHackMe: AWS VPC and Network Security
What you'll do: Configure VPCs, subnets, security groups, and NACLs while
learning common misconfigurations.
Why it matters: Network isolation is your first line of defense in cloud
architecture.
Time estimate: 2-3 hours
🔐 AWS Skill Builder: VPC Security
What you'll do: Complete AWS VPC fundamentals and security lab—build multi-tier
architectures with proper segmentation.
Why it matters: Understanding VPC architecture prevents lateral movement in
breaches.
Time estimate: 2-3 hours
🛡️ HackTheBox: Cloud Network Penetration
What you'll do: Exploit misconfigured security groups and network ACLs in
realistic cloud network scenarios (free tier).
Why it matters: Attack simulation reveals gaps that documentation can't
show.
Time estimate: 3-4 hours
💡 Lab Strategy: Draw network diagrams as you build VPCs—visualizing traffic flow reveals security gaps before attackers do.
Resources
Lab
Complete the following lab exercises to practice cloud network security.