System Design (HLD)Cloud Security Architecture

Cloud Security Architecture

LevelAdvanced

Duration90 mins

TopicCloud Security Architecture

3 / 5

Network Security (VPC, Security Groups)

The Network Perimeter in the Cloud

In 2017, security researchers discovered that MongoDB databases belonging to thousands of organizations—including healthcare providers and financial institutions—were openly accessible from the internet. The databases contained hundreds of terabytes of sensitive data. These weren't database vulnerabilities; they were network security failures. The databases were simply deployed without proper network isolation, accepting connections from any IP address.

Cloud networking is fundamentally different from traditional networking. There are no physical firewalls to install, no cables to trace, no switches to configure. Instead, cloud providers offer software-defined networking (SDN) constructs: Virtual Private Clouds (VPCs), security groups, network ACLs, and flow logs. Understanding these abstractions is essential for building secure cloud architectures.

Network security complements IAM. While IAM controls WHO can access resources, network security controls WHERE traffic can come from and go to. Together, they create defense in depth.

What You Will Learn

By the end of this page, you will understand VPC architecture and subnet design, security groups and network ACLs, public versus private network topologies, network traffic flow and inspection, and common network security misconfigurations that lead to breaches.

Virtual Private Cloud (VPC) Fundamentals

A Virtual Private Cloud (VPC) is a logically isolated section of the cloud provider's network where you launch resources. Think of it as your own private data center within the cloud—you control the IP address range, subnets, routing tables, and network gateways.

Why VPCs Matter:

Isolation — Resources in your VPC are isolated from other customers and even from your other VPCs by default
Control — You define the network topology, IP addressing, and connectivity rules
Security — Network-level controls complement identity-based controls
Compliance — Many regulations require network isolation for sensitive workloads

VPC Core Components:

VPC Building Blocks

•CIDR Block — The IP address range for your VPC (e.g., 10.0.0.0/16 provides 65,536 addresses). Choose carefully—this is difficult to change later and must not overlap with on-premises networks if you plan hybrid connectivity.
•Subnets — Subdivisions of your VPC CIDR, each associated with an Availability Zone. Subnets are where you place resources. They can be public (with internet access) or private (isolated).
•Route Tables — Rules that determine where network traffic is directed. Each subnet is associated with a route table that controls outbound traffic routing.
•Internet Gateway (IGW) — Connects your VPC to the public internet. Without an IGW route, resources have no direct internet access.
•NAT Gateway — Enables private subnet resources to initiate outbound internet connections (for updates, API calls) while remaining unreachable from the internet.
•VPC Endpoints — Private connections to AWS services that don't traverse the public internet. Critical for security-sensitive architectures.

VPC Architecture Visual:

┌────────────────────────── VPC (10.0.0.0/16) ──────────────────────────┐
│                                                                        │
│   ┌─────────────────── Availability Zone A ───────────────────┐       │
│   │                                                            │       │
│   │   ┌──────────────────┐    ┌──────────────────┐            │       │
│   │   │  Public Subnet   │    │  Private Subnet  │            │       │
│   │   │   10.0.1.0/24    │    │   10.0.3.0/24    │            │       │
│   │   │                  │    │                  │            │       │
│   │   │  ┌────────────┐  │    │  ┌────────────┐  │            │       │
│   │   │  │ Web Server │  │    │  │  Database  │  │            │       │
│   │   │  └────────────┘  │    │  └────────────┘  │            │       │
│   │   │                  │    │                  │            │       │
│   │   └──────────────────┘    └──────────────────┘            │       │
│   │            │                       │                       │       │
│   └────────────│───────────────────────│───────────────────────┘       │
│                │                       │                               │
│   ┌─────────────────── Availability Zone B ───────────────────┐       │
│   │            │                       │                       │       │
│   │   ┌──────────────────┐    ┌──────────────────┐            │       │
│   │   │  Public Subnet   │    │  Private Subnet  │            │       │
│   │   │   10.0.2.0/24    │    │   10.0.4.0/24    │            │       │
│   │   │  ┌────────────┐  │    │  ┌────────────┐  │            │       │
│   │   │  │ Web Server │  │    │  │  Database  │  │            │       │
│   │   │  └────────────┘  │    │  └────────────┘  │            │       │
│   │   └──────────────────┘    └──────────────────┘            │       │
│   │                                                            │       │
│   └────────────────────────────────────────────────────────────┘       │
│                │                       │                               │
│                ▼                       ▼                               │
│        ┌─────────────┐         ┌─────────────┐                        │
│        │   Internet  │         │     NAT     │                        │
│        │   Gateway   │         │   Gateway   │                        │
│        └─────────────┘         └─────────────┘                        │
│                │                       │                               │
└────────────────│───────────────────────│───────────────────────────────┘
                 ▼                       │
             Internet ◀──────────────────┘

Key Design Principle:

Public subnets have routes to the Internet Gateway; private subnets do not. Resources in private subnets can access the internet through a NAT Gateway (placed in a public subnet), but the internet cannot initiate connections to them.

Security Groups: Instance-Level Firewalls

Security Groups are stateful, virtual firewalls that control inbound and outbound traffic at the instance (or ENI) level. They're the primary mechanism for controlling network access to cloud resources.

Key Characteristics:

Stateful — If you allow inbound traffic, the response is automatically allowed. You don't need separate outbound rules for response traffic.
Allow-only — Security groups only support allow rules. There's an implicit deny for anything not explicitly allowed.
Instance-level — Each instance can have multiple security groups. Rules from all groups are aggregated.
Dynamic membership — You can reference other security groups in rules, not just IP addresses. This enables rules like 'allow traffic from the load balancer security group.'
VPC-scoped — Security groups exist within a VPC and can only be used by resources in that VPC.

Example Security Group for Web Server
Direction	Protocol	Port Range	Source/Destination	Purpose
Inbound	TCP	443	0.0.0.0/0	HTTPS from internet
Inbound	TCP	80	0.0.0.0/0	HTTP from internet (redirect to HTTPS)
Inbound	TCP	22	10.0.0.0/8	SSH from internal only
Outbound	TCP	443	0.0.0.0/0	HTTPS to external APIs
Outbound	TCP	5432	sg-database	PostgreSQL to database SG

Security Group Best Practices:

Security Group Design Principles

•Never use 0.0.0.0/0 for admin ports — SSH (22), RDP (3389), and database ports should never be open to the entire internet. Use bastion hosts, VPNs, or Systems Manager Session Manager.
•Reference security groups, not IPs — Instead of hardcoding IP addresses, reference the security group of the source. This accommodates auto-scaling and dynamic IPs.
•Use separate groups for roles — Create distinct security groups for web servers, app servers, databases. Apply the principle of least privilege to network access.
•Document every rule — Use descriptions for each rule. Future you (or your successor) will want to know why that rule exists.
•Minimize outbound rules — Default outbound allows all traffic. Restrict this when possible to limit lateral movement if an instance is compromised.
•Regular audits — Security groups accumulate rules over time. Regularly review and remove unnecessary rules.

The 0.0.0.0/0 Trap

Security group rules with source 0.0.0.0/0 mean 'allow from anywhere on the internet.' This is often appropriate for web servers (ports 80/443) but is a critical security failure for SSH, RDP, or database ports. Automated scanners continuously probe for these misconfigurations.

Network ACLs: Subnet-Level Controls

Network Access Control Lists (NACLs) are stateless, optional layer of security that acts as a firewall for controlling traffic in and out of subnets. While security groups operate at the instance level, NACLs operate at the subnet level.

Key Differences from Security Groups:

Security Groups vs. Network ACLs
Characteristic	Security Groups	Network ACLs
Level	Instance/ENI	Subnet
State	Stateful (return traffic automatic)	Stateless (explicit rules for both directions)
Rule type	Allow only	Allow and Deny
Rule processing	All rules evaluated	Rules processed in order by number
Default	Deny all inbound, allow all outbound	Allow all (default NACL)
Association	Multiple SGs per instance	One NACL per subnet

When to Use NACLs:

NACLs are useful for:

Blocking known malicious IPs — When you need to explicitly deny traffic from specific IP ranges across an entire subnet
Compliance requirements — Some compliance frameworks require explicit subnet-level deny rules
Defense in depth — Adding an additional layer of network control beyond security groups
Emergency response — Quickly blocking traffic at the subnet level during an incident

Example NACL Configuration:

┌────────────────────────────────────────────────────────────────────┐
│                        Network ACL: acl-web                         │
├────────────────────────────────────────────────────────────────────┤
│                          INBOUND RULES                              │
├───────┬──────────┬──────┬───────────────────┬──────────────────────┤
│ Rule# │ Protocol │ Port │    Source         │   Allow/Deny         │
├───────┼──────────┼──────┼───────────────────┼──────────────────────┤
│  100  │   TCP    │  443 │   0.0.0.0/0       │   ALLOW              │
│  110  │   TCP    │   80 │   0.0.0.0/0       │   ALLOW              │
│  120  │   TCP    │ 1024-65535 │ 10.0.0.0/8  │   ALLOW (ephemeral)  │
│  200  │   ALL    │  ALL │   192.168.1.100/32│   DENY (blocked IP)  │
│   *   │   ALL    │  ALL │   0.0.0.0/0       │   DENY (implicit)    │
├───────┴──────────┴──────┴───────────────────┴──────────────────────┤
│                          OUTBOUND RULES                             │
├───────┬──────────┬──────┬───────────────────┬──────────────────────┤
│  100  │   TCP    │  443 │   0.0.0.0/0       │   ALLOW              │
│  110  │   TCP    │ 1024-65535 │ 0.0.0.0/0   │   ALLOW (ephemeral)  │
│   *   │   ALL    │  ALL │   0.0.0.0/0       │   DENY               │
└───────┴──────────┴──────┴───────────────────┴──────────────────────┘

Important NACL Considerations:

Stateless requires ephemeral ports — Since NACLs are stateless, you must allow return traffic on ephemeral ports (typically 1024-65535)
Rule order matters — Rules are evaluated in order from lowest to highest number. First match wins.
Affects all instances — NACL rules apply to ALL instances in the associated subnet
Default NACL is permissive — The VPC's default NACL allows all traffic. Custom NACLs deny all by default.

Prefer Security Groups

In most cases, security groups are sufficient and easier to manage. Use NACLs as an additional defense layer, not as a replacement for properly configured security groups. The stateless nature of NACLs makes them more error-prone.

Designing Public and Private Networks

A fundamental cloud network security decision is determining which resources need public internet access (and thus exposure to internet-based attacks) versus which should remain private. The general principle: expose only what must be exposed.

Tiered Architecture Pattern:

Most secure architectures follow a tiered model where only a thin edge layer is publicly accessible:

┌─────────────────────────────────────────────────────────────────────────┐
│                                                                         │
│                              INTERNET                                   │
│                                                                         │
└────────────────────────────────────┬────────────────────────────────────┘
                                     │
                                     ▼
┌─────────────────────────────────────────────────────────────────────────┐
│                         PUBLIC SUBNET (DMZ)                              │
│   ┌─────────────┐    ┌─────────────┐    ┌─────────────┐                │
│   │     ALB     │    │     CDN     │    │    WAF      │                │
│   │  (Public)   │    │   Origin    │    │  Endpoint   │                │
│   └──────┬──────┘    └──────┬──────┘    └─────────────┘                │
│          │                  │                                           │
└──────────│──────────────────│───────────────────────────────────────────┘
           │                  │
           ▼                  ▼
┌─────────────────────────────────────────────────────────────────────────┐
│                       PRIVATE SUBNET (Application)                       │
│   ┌─────────────┐    ┌─────────────┐    ┌─────────────┐                │
│   │   Web App   │    │   API Svc   │    │   Worker    │                │
│   │  Instances  │    │  Containers │    │   Queue     │                │
│   └──────┬──────┘    └──────┬──────┘    └─────────────┘                │
│          │                  │                                           │
└──────────│──────────────────│───────────────────────────────────────────┘
           │                  │
           ▼                  ▼
┌─────────────────────────────────────────────────────────────────────────┐
│                        PRIVATE SUBNET (Data)                             │
│   ┌─────────────┐    ┌─────────────┐    ┌─────────────┐                │
│   │   Primary   │    │   Replica   │    │   Cache     │                │
│   │   Database  │    │   Database  │    │   Cluster   │                │
│   └─────────────┘    └─────────────┘    └─────────────┘                │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘

Tiered Architecture Principles

•Public Tier (DMZ) — Only load balancers, CDN origins, and WAF endpoints. No application logic, no data storage. Hardened against internet attacks.
•Application Tier — Private subnets with application servers, containers, workers. Access only from load balancers and internal services. No direct internet access.
•Data Tier — Most isolated layer. Databases, caches, storage. Access only from application tier. No internet connectivity whatsoever.
•Outbound via NAT — Application and data tiers can reach the internet (for updates, external APIs) through NAT Gateway, but internet cannot initiate connections.
•VPC Endpoints for AWS Services — Use PrivateLink/VPC Endpoints to reach AWS services (S3, DynamoDB, etc.) without traversing the internet.

Zero-Trust Considerations:

Modern network security increasingly follows zero-trust principles—the idea that we shouldn't trust traffic just because it originates from inside our network perimeter. In cloud architectures:

Encrypt internal traffic — Use TLS between services even within private subnets
Authenticate service-to-service calls — Use mTLS or signed requests, not just network position
Segment aggressively — Create separate security groups for each service
Log everything — VPC Flow Logs capture all traffic for analysis
Assume breach — Design so that compromise of one component doesn't give access to everything

Private Doesn't Mean Safe

A private subnet is not inherently secure—it's just not directly reachable from the internet. Compromised instances, misconfigured services, or lateral movement from other compromised systems can still attack private resources. Defense in depth is essential.

VPC Connectivity and Hybrid Networking

Cloud networks rarely exist in isolation. Production architectures require connections to on-premises data centers, other VPCs, partner networks, and cloud services. Each connectivity option has security implications.

VPC-to-VPC Connectivity:

VPC Connectivity Options
Option	Use Case	Security Considerations
VPC Peering	Direct connection between two VPCs	Route tables must be explicitly configured; security groups still apply; non-transitive
Transit Gateway	Hub-and-spoke for multiple VPCs	Centralized control; can segment routing domains; shared routing
PrivateLink	Expose services to other VPCs/accounts	One-way; consumer initiates; service endpoints are private
VPN (Site-to-Site)	Encrypted tunnel over internet	Encrypted but uses public internet; limited bandwidth
Direct Connect	Dedicated physical connection	Private; high bandwidth; higher cost; physical setup required

Hybrid Cloud Networking:

Connecting cloud VPCs to on-premises networks introduces additional complexity:

┌─────────────────────────────────────────────────────────────────────────┐
│                          ON-PREMISES DATA CENTER                         │
│   ┌─────────────────┐                      ┌─────────────────┐          │
│   │ Corporate       │                      │    Customer     │          │
│   │ Applications    │                      │    Gateway      │          │
│   └─────────────────┘                      └────────┬────────┘          │
│                                                      │                   │
└──────────────────────────────────────────────────────│───────────────────┘
                                                       │
                    ┌──────────────────────────────────┴───────────────────┐
                    │           VPN / Direct Connect                        │
                    └──────────────────────────────────┬───────────────────┘
                                                       │
┌──────────────────────────────────────────────────────│───────────────────┐
│                              AWS CLOUD               │                    │
│   ┌─────────────────────────────────────────────────────────────────┐   │
│   │                      TRANSIT GATEWAY                             │   │
│   └───────────┬───────────────────┬───────────────────┬─────────────┘   │
│               │                   │                   │                  │
│               ▼                   ▼                   ▼                  │
│   ┌───────────────┐   ┌───────────────┐   ┌───────────────┐             │
│   │   VPC: Prod   │   │   VPC: Dev    │   │ VPC: Shared   │             │
│   │   10.1.0.0/16 │   │  10.2.0.0/16  │   │  10.3.0.0/16  │             │
│   └───────────────┘   └───────────────┘   └───────────────┘             │
│                                                                          │
└──────────────────────────────────────────────────────────────────────────┘

Security Considerations for Hybrid:

CIDR overlap — Ensure on-premises and cloud networks don't use overlapping IP ranges
Routing complexity — Carefully plan routing tables to prevent unintended connectivity
BGP security — For Direct Connect, secure BGP sessions and validate route announcements
Encryption — VPN traffic is encrypted; Direct Connect is private but consider encryption for sensitive data
Network segmentation — Don't give cloud full access to on-prem or vice versa—segment by function

VPC Endpoints and PrivateLink

•Gateway Endpoints — For S3 and DynamoDB. Traffic stays on AWS network via route table entries. No additional cost.
•Interface Endpoints (PrivateLink) — For most AWS services. Creates ENIs in your VPC. Traffic never leaves AWS network.
•Customer PrivateLink — Expose your services to other accounts/VPCs privately. Consumers connect to your NLB via private endpoint.
•Benefits — No internet gateway required, no public IPs, reduced attack surface, potentially lower data transfer costs.

Prefer Private Connectivity

Use VPC endpoints for AWS service access whenever possible. Traffic to S3, DynamoDB, KMS, and other services doesn't need to traverse the internet. This reduces attack surface and can improve latency.

Traffic Inspection and Monitoring

Network security isn't just about blocking bad traffic—it's about visibility into what traffic is flowing. Without monitoring, you can't detect attacks, troubleshoot issues, or verify that security controls are working.

VPC Flow Logs:

VPC Flow Logs capture information about IP traffic going to and from network interfaces in your VPC. They're essential for security monitoring and forensics.

Flow Log Record Format:
┌───────────────────────────────────────────────────────────────────────────┐
│ version account-id interface-id srcaddr dstaddr srcport dstport protocol │
│ packets bytes start end action log-status                                │
└───────────────────────────────────────────────────────────────────────────┘

Example Record:
2 123456789012 eni-abc123 10.0.1.15 10.0.2.25 443 49152 6 12 3456 
1620000000 1620000060 ACCEPT OK

Interpretation:
- Source: 10.0.1.15:443 (internal server)
- Destination: 10.0.2.25:49152 (internal client)
- Protocol: TCP (6)
- 12 packets, 3,456 bytes
- Action: ACCEPT (allowed by security group/NACL)

What Flow Logs Reveal:

Pattern	Security Implication
Rejected traffic to SSH/RDP	Potential reconnaissance/brute force
Unexpected outbound connections	Possible malware C&C communication
Large data transfers to unknown IPs	Potential data exfiltration
Traffic between unexpected instances	Lateral movement
Connections to known bad IPs	Active compromise

Advanced Network Monitoring

•Traffic Mirroring — Copy actual packet data (not just metadata like flow logs) for deep inspection. Use with IDS/IPS systems.
•AWS Network Firewall — Managed firewall service with stateful inspection, intrusion detection, and URL filtering.
•Third-party appliances — Deploy virtual firewalls (Palo Alto, Fortinet, etc.) for advanced threat detection.
•GuardDuty — AWS threat detection service that analyzes VPC Flow Logs, DNS logs, and CloudTrail to identify threats.
•DNS logging — Route 53 Resolver query logs reveal DNS requests, useful for detecting malware domains.

Network Firewall Deep Inspection:

For environments requiring deep packet inspection, stateful protocol analysis, or intrusion detection, AWS Network Firewall provides a managed solution:

                    Internet
                        │
                        ▼
┌───────────────────────────────────────────────────────────────────┐
│                    Network Firewall Endpoint                       │
│   ┌─────────────────────────────────────────────────────────────┐ │
│   │  Rule Groups:                                                │ │
│   │  - Stateful rules (5-tuple, domain, Suricata)               │ │
│   │  - Stateless rules (packet filtering)                       │ │
│   │  - Managed threat signatures                                 │ │
│   └─────────────────────────────────────────────────────────────┘ │
└────────────────────────────────────┬──────────────────────────────┘
                                     │
                                     ▼
                              Protected Subnets

Alerting and Response:

Monitoring is only valuable if you act on findings:

Define baseline behavior — Know what normal traffic looks like
Alert on anomalies — Significant deviations from baseline
Automated response — For high-confidence threats, automate blocking
Incident runbooks — Document response procedures for common alerts

Flow Logs Cost Money

VPC Flow Logs generate data that you pay to store and process. At scale, this can be significant. Use sampling, filter to relevant traffic, and set appropriate retention periods. But don't skip flow logs entirely—the visibility is essential for security.

Common Network Security Misconfigurations

Network security failures in the cloud are almost always configuration errors, not technology failures. Understanding common misconfigurations helps you avoid them and detect them during security reviews.

Critical Network Misconfigurations

•SSH/RDP open to 0.0.0.0/0 — Administrative ports exposed to the entire internet. Attackers continuously scan for these and will find them within hours.
•Database ports exposed — PostgreSQL (5432), MySQL (3306), MongoDB (27017) accessible from the internet. Many breach reports start here.
•Public subnets for databases — Databases placed in public subnets with public IP addresses, even if security groups are restrictive.
•Overly permissive outbound rules — Allowing all outbound traffic enables data exfiltration and C&C communication.
•Missing VPC endpoints — Traffic to AWS services going over the internet when it could stay private via VPC endpoints.
•Default VPC usage — The default VPC has permissive defaults. Production workloads should use custom VPCs with deliberate configuration.
•Unused security groups — Old security groups with broad rules that shouldn't exist anymore.
•Cross-VPC trust without restriction — VPC peering or Transit Gateway without appropriate route and security group restrictions.

Detection and Remediation:

Misconfiguration	Detection Method	Remediation
Open admin ports	AWS Config Rules, Security Hub	Restrict to known IPs, use bastion
Public databases	Config Rules, custom scans	Move to private subnet, use proxy
Missing flow logs	AWS Config	Enable flow logs for all VPCs
Over-permissive SGs	IAM Access Analyzer, manual audit	Remove unnecessary rules
Default VPC in use	AWS Config rule	Migrate to custom VPCs
Missing encryption	Security Hub checks	Enable encryption in transit, require TLS

Automated Remediation:

For high-risk misconfigurations, automate remediation:

EventBridge Rule: "Security group allows 0.0.0.0/0 on SSH"
        │
        ▼
Lambda Function: Remove rule and notify
        │
        ▼
SNS Topic: Alert security team

This pattern ensures dangerous misconfigurations are corrected immediately, not days later when a human reviews alerts.

Misconfiguration Is the Leading Cause

Studies consistently show that cloud breaches are primarily caused by configuration errors, not zero-day exploits or sophisticated attacks. Focus your security efforts on getting the basics right: least privilege, private by default, continuous monitoring.

Summary: Mastering Cloud Network Security

Network security is the perimeter that determines what traffic can reach your cloud resources. While IAM controls who is authorized, network controls determine what can physically connect.

Key Takeaways

•VPCs provide isolation — Design VPCs with appropriate CIDR ranges, public and private subnets, and careful routing.
•Security groups are your primary control — Stateful, instance-level rules that should follow least privilege. Never expose admin ports to the internet.
•NACLs add defense in depth — Stateless subnet-level controls for blocking IPs and additional layering.
•Private by default — Only expose what must be exposed. Databases, application servers, and internal services belong in private subnets.
•Use VPC endpoints — Keep traffic to cloud services off the public internet for better security and often better performance.
•Monitor everything — VPC Flow Logs provide essential visibility. You can't secure what you can't see.
•Configuration is the vulnerability — Most cloud network breaches are misconfigurations. Automate detection and remediation.

What's Next:

With network controls establishing the perimeter, we next explore encryption services—protecting data both at rest and in transit. Even if network controls fail, properly encrypted data remains protected from unauthorized access.

Page Complete

You now understand cloud network security architecture—from VPC design through security groups and NACLs to traffic monitoring. This knowledge enables you to design network topologies that minimize attack surface and provide defense in depth.

3 / 5

Loading learning content...

System Design (HLD)Cloud Security Architecture

Cloud Security Architecture

LevelAdvanced

Duration90 mins

TopicCloud Security Architecture

3 / 5

Network Security (VPC, Security Groups)

The Network Perimeter in the Cloud

Network security complements IAM. While IAM controls WHO can access resources, network security controls WHERE traffic can come from and go to. Together, they create defense in depth.

What You Will Learn

Virtual Private Cloud (VPC) Fundamentals

Why VPCs Matter:

Isolation — Resources in your VPC are isolated from other customers and even from your other VPCs by default
Control — You define the network topology, IP addressing, and connectivity rules
Security — Network-level controls complement identity-based controls
Compliance — Many regulations require network isolation for sensitive workloads

VPC Core Components:

VPC Building Blocks

•CIDR Block — The IP address range for your VPC (e.g., 10.0.0.0/16 provides 65,536 addresses). Choose carefully—this is difficult to change later and must not overlap with on-premises networks if you plan hybrid connectivity.
•Subnets — Subdivisions of your VPC CIDR, each associated with an Availability Zone. Subnets are where you place resources. They can be public (with internet access) or private (isolated).
•Route Tables — Rules that determine where network traffic is directed. Each subnet is associated with a route table that controls outbound traffic routing.
•Internet Gateway (IGW) — Connects your VPC to the public internet. Without an IGW route, resources have no direct internet access.
•NAT Gateway — Enables private subnet resources to initiate outbound internet connections (for updates, API calls) while remaining unreachable from the internet.
•VPC Endpoints — Private connections to AWS services that don't traverse the public internet. Critical for security-sensitive architectures.

VPC Architecture Visual:

┌────────────────────────── VPC (10.0.0.0/16) ──────────────────────────┐
│                                                                        │
│   ┌─────────────────── Availability Zone A ───────────────────┐       │
│   │                                                            │       │
│   │   ┌──────────────────┐    ┌──────────────────┐            │       │
│   │   │  Public Subnet   │    │  Private Subnet  │            │       │
│   │   │   10.0.1.0/24    │    │   10.0.3.0/24    │            │       │
│   │   │                  │    │                  │            │       │
│   │   │  ┌────────────┐  │    │  ┌────────────┐  │            │       │
│   │   │  │ Web Server │  │    │  │  Database  │  │            │       │
│   │   │  └────────────┘  │    │  └────────────┘  │            │       │
│   │   │                  │    │                  │            │       │
│   │   └──────────────────┘    └──────────────────┘            │       │
│   │            │                       │                       │       │
│   └────────────│───────────────────────│───────────────────────┘       │
│                │                       │                               │
│   ┌─────────────────── Availability Zone B ───────────────────┐       │
│   │            │                       │                       │       │
│   │   ┌──────────────────┐    ┌──────────────────┐            │       │
│   │   │  Public Subnet   │    │  Private Subnet  │            │       │
│   │   │   10.0.2.0/24    │    │   10.0.4.0/24    │            │       │
│   │   │  ┌────────────┐  │    │  ┌────────────┐  │            │       │
│   │   │  │ Web Server │  │    │  │  Database  │  │            │       │
│   │   │  └────────────┘  │    │  └────────────┘  │            │       │
│   │   └──────────────────┘    └──────────────────┘            │       │
│   │                                                            │       │
│   └────────────────────────────────────────────────────────────┘       │
│                │                       │                               │
│                ▼                       ▼                               │
│        ┌─────────────┐         ┌─────────────┐                        │
│        │   Internet  │         │     NAT     │                        │
│        │   Gateway   │         │   Gateway   │                        │
│        └─────────────┘         └─────────────┘                        │
│                │                       │                               │
└────────────────│───────────────────────│───────────────────────────────┘
                 ▼                       │
             Internet ◀──────────────────┘

Key Design Principle:

Security Groups: Instance-Level Firewalls

Key Characteristics:

Stateful — If you allow inbound traffic, the response is automatically allowed. You don't need separate outbound rules for response traffic.
Allow-only — Security groups only support allow rules. There's an implicit deny for anything not explicitly allowed.
Instance-level — Each instance can have multiple security groups. Rules from all groups are aggregated.
Dynamic membership — You can reference other security groups in rules, not just IP addresses. This enables rules like 'allow traffic from the load balancer security group.'
VPC-scoped — Security groups exist within a VPC and can only be used by resources in that VPC.

Example Security Group for Web Server
Direction	Protocol	Port Range	Source/Destination	Purpose
Inbound	TCP	443	0.0.0.0/0	HTTPS from internet
Inbound	TCP	80	0.0.0.0/0	HTTP from internet (redirect to HTTPS)
Inbound	TCP	22	10.0.0.0/8	SSH from internal only
Outbound	TCP	443	0.0.0.0/0	HTTPS to external APIs
Outbound	TCP	5432	sg-database	PostgreSQL to database SG

Security Group Best Practices:

Security Group Design Principles

•Never use 0.0.0.0/0 for admin ports — SSH (22), RDP (3389), and database ports should never be open to the entire internet. Use bastion hosts, VPNs, or Systems Manager Session Manager.
•Reference security groups, not IPs — Instead of hardcoding IP addresses, reference the security group of the source. This accommodates auto-scaling and dynamic IPs.
•Use separate groups for roles — Create distinct security groups for web servers, app servers, databases. Apply the principle of least privilege to network access.
•Document every rule — Use descriptions for each rule. Future you (or your successor) will want to know why that rule exists.
•Minimize outbound rules — Default outbound allows all traffic. Restrict this when possible to limit lateral movement if an instance is compromised.
•Regular audits — Security groups accumulate rules over time. Regularly review and remove unnecessary rules.

The 0.0.0.0/0 Trap

Network ACLs: Subnet-Level Controls

Key Differences from Security Groups:

Security Groups vs. Network ACLs
Characteristic	Security Groups	Network ACLs
Level	Instance/ENI	Subnet
State	Stateful (return traffic automatic)	Stateless (explicit rules for both directions)
Rule type	Allow only	Allow and Deny
Rule processing	All rules evaluated	Rules processed in order by number
Default	Deny all inbound, allow all outbound	Allow all (default NACL)
Association	Multiple SGs per instance	One NACL per subnet

When to Use NACLs:

NACLs are useful for:

Blocking known malicious IPs — When you need to explicitly deny traffic from specific IP ranges across an entire subnet
Compliance requirements — Some compliance frameworks require explicit subnet-level deny rules
Defense in depth — Adding an additional layer of network control beyond security groups
Emergency response — Quickly blocking traffic at the subnet level during an incident

Example NACL Configuration:

┌────────────────────────────────────────────────────────────────────┐
│                        Network ACL: acl-web                         │
├────────────────────────────────────────────────────────────────────┤
│                          INBOUND RULES                              │
├───────┬──────────┬──────┬───────────────────┬──────────────────────┤
│ Rule# │ Protocol │ Port │    Source         │   Allow/Deny         │
├───────┼──────────┼──────┼───────────────────┼──────────────────────┤
│  100  │   TCP    │  443 │   0.0.0.0/0       │   ALLOW              │
│  110  │   TCP    │   80 │   0.0.0.0/0       │   ALLOW              │
│  120  │   TCP    │ 1024-65535 │ 10.0.0.0/8  │   ALLOW (ephemeral)  │
│  200  │   ALL    │  ALL │   192.168.1.100/32│   DENY (blocked IP)  │
│   *   │   ALL    │  ALL │   0.0.0.0/0       │   DENY (implicit)    │
├───────┴──────────┴──────┴───────────────────┴──────────────────────┤
│                          OUTBOUND RULES                             │
├───────┬──────────┬──────┬───────────────────┬──────────────────────┤
│  100  │   TCP    │  443 │   0.0.0.0/0       │   ALLOW              │
│  110  │   TCP    │ 1024-65535 │ 0.0.0.0/0   │   ALLOW (ephemeral)  │
│   *   │   ALL    │  ALL │   0.0.0.0/0       │   DENY               │
└───────┴──────────┴──────┴───────────────────┴──────────────────────┘

Important NACL Considerations:

Stateless requires ephemeral ports — Since NACLs are stateless, you must allow return traffic on ephemeral ports (typically 1024-65535)
Rule order matters — Rules are evaluated in order from lowest to highest number. First match wins.
Affects all instances — NACL rules apply to ALL instances in the associated subnet
Default NACL is permissive — The VPC's default NACL allows all traffic. Custom NACLs deny all by default.

Prefer Security Groups

Designing Public and Private Networks

Tiered Architecture Pattern:

Most secure architectures follow a tiered model where only a thin edge layer is publicly accessible:

┌─────────────────────────────────────────────────────────────────────────┐
│                                                                         │
│                              INTERNET                                   │
│                                                                         │
└────────────────────────────────────┬────────────────────────────────────┘
                                     │
                                     ▼
┌─────────────────────────────────────────────────────────────────────────┐
│                         PUBLIC SUBNET (DMZ)                              │
│   ┌─────────────┐    ┌─────────────┐    ┌─────────────┐                │
│   │     ALB     │    │     CDN     │    │    WAF      │                │
│   │  (Public)   │    │   Origin    │    │  Endpoint   │                │
│   └──────┬──────┘    └──────┬──────┘    └─────────────┘                │
│          │                  │                                           │
└──────────│──────────────────│───────────────────────────────────────────┘
           │                  │
           ▼                  ▼
┌─────────────────────────────────────────────────────────────────────────┐
│                       PRIVATE SUBNET (Application)                       │
│   ┌─────────────┐    ┌─────────────┐    ┌─────────────┐                │
│   │   Web App   │    │   API Svc   │    │   Worker    │                │
│   │  Instances  │    │  Containers │    │   Queue     │                │
│   └──────┬──────┘    └──────┬──────┘    └─────────────┘                │
│          │                  │                                           │
└──────────│──────────────────│───────────────────────────────────────────┘
           │                  │
           ▼                  ▼
┌─────────────────────────────────────────────────────────────────────────┐
│                        PRIVATE SUBNET (Data)                             │
│   ┌─────────────┐    ┌─────────────┐    ┌─────────────┐                │
│   │   Primary   │    │   Replica   │    │   Cache     │                │
│   │   Database  │    │   Database  │    │   Cluster   │                │
│   └─────────────┘    └─────────────┘    └─────────────┘                │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘

Tiered Architecture Principles

•Public Tier (DMZ) — Only load balancers, CDN origins, and WAF endpoints. No application logic, no data storage. Hardened against internet attacks.
•Application Tier — Private subnets with application servers, containers, workers. Access only from load balancers and internal services. No direct internet access.
•Data Tier — Most isolated layer. Databases, caches, storage. Access only from application tier. No internet connectivity whatsoever.
•Outbound via NAT — Application and data tiers can reach the internet (for updates, external APIs) through NAT Gateway, but internet cannot initiate connections.
•VPC Endpoints for AWS Services — Use PrivateLink/VPC Endpoints to reach AWS services (S3, DynamoDB, etc.) without traversing the internet.

Zero-Trust Considerations:

Modern network security increasingly follows zero-trust principles—the idea that we shouldn't trust traffic just because it originates from inside our network perimeter. In cloud architectures:

Encrypt internal traffic — Use TLS between services even within private subnets
Authenticate service-to-service calls — Use mTLS or signed requests, not just network position
Segment aggressively — Create separate security groups for each service
Log everything — VPC Flow Logs capture all traffic for analysis
Assume breach — Design so that compromise of one component doesn't give access to everything

Private Doesn't Mean Safe

VPC Connectivity and Hybrid Networking

VPC-to-VPC Connectivity:

VPC Connectivity Options
Option	Use Case	Security Considerations
VPC Peering	Direct connection between two VPCs	Route tables must be explicitly configured; security groups still apply; non-transitive
Transit Gateway	Hub-and-spoke for multiple VPCs	Centralized control; can segment routing domains; shared routing
PrivateLink	Expose services to other VPCs/accounts	One-way; consumer initiates; service endpoints are private
VPN (Site-to-Site)	Encrypted tunnel over internet	Encrypted but uses public internet; limited bandwidth
Direct Connect	Dedicated physical connection	Private; high bandwidth; higher cost; physical setup required

Hybrid Cloud Networking:

Connecting cloud VPCs to on-premises networks introduces additional complexity:

┌─────────────────────────────────────────────────────────────────────────┐
│                          ON-PREMISES DATA CENTER                         │
│   ┌─────────────────┐                      ┌─────────────────┐          │
│   │ Corporate       │                      │    Customer     │          │
│   │ Applications    │                      │    Gateway      │          │
│   └─────────────────┘                      └────────┬────────┘          │
│                                                      │                   │
└──────────────────────────────────────────────────────│───────────────────┘
                                                       │
                    ┌──────────────────────────────────┴───────────────────┐
                    │           VPN / Direct Connect                        │
                    └──────────────────────────────────┬───────────────────┘
                                                       │
┌──────────────────────────────────────────────────────│───────────────────┐
│                              AWS CLOUD               │                    │
│   ┌─────────────────────────────────────────────────────────────────┐   │
│   │                      TRANSIT GATEWAY                             │   │
│   └───────────┬───────────────────┬───────────────────┬─────────────┘   │
│               │                   │                   │                  │
│               ▼                   ▼                   ▼                  │
│   ┌───────────────┐   ┌───────────────┐   ┌───────────────┐             │
│   │   VPC: Prod   │   │   VPC: Dev    │   │ VPC: Shared   │             │
│   │   10.1.0.0/16 │   │  10.2.0.0/16  │   │  10.3.0.0/16  │             │
│   └───────────────┘   └───────────────┘   └───────────────┘             │
│                                                                          │
└──────────────────────────────────────────────────────────────────────────┘

Security Considerations for Hybrid:

CIDR overlap — Ensure on-premises and cloud networks don't use overlapping IP ranges
Routing complexity — Carefully plan routing tables to prevent unintended connectivity
BGP security — For Direct Connect, secure BGP sessions and validate route announcements
Encryption — VPN traffic is encrypted; Direct Connect is private but consider encryption for sensitive data
Network segmentation — Don't give cloud full access to on-prem or vice versa—segment by function

VPC Endpoints and PrivateLink

•Gateway Endpoints — For S3 and DynamoDB. Traffic stays on AWS network via route table entries. No additional cost.
•Interface Endpoints (PrivateLink) — For most AWS services. Creates ENIs in your VPC. Traffic never leaves AWS network.
•Customer PrivateLink — Expose your services to other accounts/VPCs privately. Consumers connect to your NLB via private endpoint.
•Benefits — No internet gateway required, no public IPs, reduced attack surface, potentially lower data transfer costs.

Prefer Private Connectivity

Traffic Inspection and Monitoring

VPC Flow Logs:

VPC Flow Logs capture information about IP traffic going to and from network interfaces in your VPC. They're essential for security monitoring and forensics.

Flow Log Record Format:
┌───────────────────────────────────────────────────────────────────────────┐
│ version account-id interface-id srcaddr dstaddr srcport dstport protocol │
│ packets bytes start end action log-status                                │
└───────────────────────────────────────────────────────────────────────────┘

Example Record:
2 123456789012 eni-abc123 10.0.1.15 10.0.2.25 443 49152 6 12 3456 
1620000000 1620000060 ACCEPT OK

Interpretation:
- Source: 10.0.1.15:443 (internal server)
- Destination: 10.0.2.25:49152 (internal client)
- Protocol: TCP (6)
- 12 packets, 3,456 bytes
- Action: ACCEPT (allowed by security group/NACL)

What Flow Logs Reveal:

Pattern	Security Implication
Rejected traffic to SSH/RDP	Potential reconnaissance/brute force
Unexpected outbound connections	Possible malware C&C communication
Large data transfers to unknown IPs	Potential data exfiltration
Traffic between unexpected instances	Lateral movement
Connections to known bad IPs	Active compromise

Advanced Network Monitoring

•Traffic Mirroring — Copy actual packet data (not just metadata like flow logs) for deep inspection. Use with IDS/IPS systems.
•AWS Network Firewall — Managed firewall service with stateful inspection, intrusion detection, and URL filtering.
•Third-party appliances — Deploy virtual firewalls (Palo Alto, Fortinet, etc.) for advanced threat detection.
•GuardDuty — AWS threat detection service that analyzes VPC Flow Logs, DNS logs, and CloudTrail to identify threats.
•DNS logging — Route 53 Resolver query logs reveal DNS requests, useful for detecting malware domains.

Network Firewall Deep Inspection:

For environments requiring deep packet inspection, stateful protocol analysis, or intrusion detection, AWS Network Firewall provides a managed solution:

                    Internet
                        │
                        ▼
┌───────────────────────────────────────────────────────────────────┐
│                    Network Firewall Endpoint                       │
│   ┌─────────────────────────────────────────────────────────────┐ │
│   │  Rule Groups:                                                │ │
│   │  - Stateful rules (5-tuple, domain, Suricata)               │ │
│   │  - Stateless rules (packet filtering)                       │ │
│   │  - Managed threat signatures                                 │ │
│   └─────────────────────────────────────────────────────────────┘ │
└────────────────────────────────────┬──────────────────────────────┘
                                     │
                                     ▼
                              Protected Subnets

Alerting and Response:

Monitoring is only valuable if you act on findings:

Define baseline behavior — Know what normal traffic looks like
Alert on anomalies — Significant deviations from baseline
Automated response — For high-confidence threats, automate blocking
Incident runbooks — Document response procedures for common alerts

Flow Logs Cost Money

Common Network Security Misconfigurations

Critical Network Misconfigurations

•SSH/RDP open to 0.0.0.0/0 — Administrative ports exposed to the entire internet. Attackers continuously scan for these and will find them within hours.
•Database ports exposed — PostgreSQL (5432), MySQL (3306), MongoDB (27017) accessible from the internet. Many breach reports start here.
•Public subnets for databases — Databases placed in public subnets with public IP addresses, even if security groups are restrictive.
•Overly permissive outbound rules — Allowing all outbound traffic enables data exfiltration and C&C communication.
•Missing VPC endpoints — Traffic to AWS services going over the internet when it could stay private via VPC endpoints.
•Default VPC usage — The default VPC has permissive defaults. Production workloads should use custom VPCs with deliberate configuration.
•Unused security groups — Old security groups with broad rules that shouldn't exist anymore.
•Cross-VPC trust without restriction — VPC peering or Transit Gateway without appropriate route and security group restrictions.

Detection and Remediation:

Misconfiguration	Detection Method	Remediation
Open admin ports	AWS Config Rules, Security Hub	Restrict to known IPs, use bastion
Public databases	Config Rules, custom scans	Move to private subnet, use proxy
Missing flow logs	AWS Config	Enable flow logs for all VPCs
Over-permissive SGs	IAM Access Analyzer, manual audit	Remove unnecessary rules
Default VPC in use	AWS Config rule	Migrate to custom VPCs
Missing encryption	Security Hub checks	Enable encryption in transit, require TLS

Automated Remediation:

For high-risk misconfigurations, automate remediation:

EventBridge Rule: "Security group allows 0.0.0.0/0 on SSH"
        │
        ▼
Lambda Function: Remove rule and notify
        │
        ▼
SNS Topic: Alert security team

This pattern ensures dangerous misconfigurations are corrected immediately, not days later when a human reviews alerts.

Misconfiguration Is the Leading Cause

Summary: Mastering Cloud Network Security

Network security is the perimeter that determines what traffic can reach your cloud resources. While IAM controls who is authorized, network controls determine what can physically connect.

Key Takeaways

•VPCs provide isolation — Design VPCs with appropriate CIDR ranges, public and private subnets, and careful routing.
•Security groups are your primary control — Stateful, instance-level rules that should follow least privilege. Never expose admin ports to the internet.
•NACLs add defense in depth — Stateless subnet-level controls for blocking IPs and additional layering.
•Private by default — Only expose what must be exposed. Databases, application servers, and internal services belong in private subnets.
•Use VPC endpoints — Keep traffic to cloud services off the public internet for better security and often better performance.
•Monitor everything — VPC Flow Logs provide essential visibility. You can't secure what you can't see.
•Configuration is the vulnerability — Most cloud network breaches are misconfigurations. Automate detection and remediation.

What's Next:

Page Complete

3 / 5