SkarpChapter 6 of 26
Network Security Fundamentals: Amazon VPC, Subnets, and Security Groups
Most secure architectures on AWS start with the VPC: build an intuitive picture of subnets, routing, and security groups so you can safely expose what you must and lock down everything else.
Big Picture: VPCs and the Security Pillar
VPCs and Your Responsibility
Amazon VPC is your isolated slice of the AWS network. Under the shared responsibility model, you design its layout and security controls: IP ranges, subnets, routing, and firewalls.
Well-Architected Context
VPC topics sit mainly in the Security and Reliability pillars. The Security pillar focuses on using cloud technologies to protect data, systems, and assets and improve your security posture.
Mental Model
Imagine a VPC as an office building in AWS’s campus. Subnets are rooms, security groups and NACLs are locks, and public subnets are rooms with controlled windows to the street.
What The Exam Cares About
You must place resources in the right subnets, control traffic in and out, use multiple AZs for resilience, and pick the right tool: security group vs network ACL for each scenario.
Amazon VPC Basics: CIDR, AZs, and Routing
VPC Scope
A VPC is regional: it lives in one Region and can span multiple AZs. You choose a CIDR block, such as 10.0.0.0/16, for all IPs inside that VPC.
Subnets and AZs
You carve the VPC CIDR into subnets. Each subnet has its own CIDR and belongs to exactly one Availability Zone; subnets never cross AZs.
Routing Basics
Each subnet is associated with a route table. Routes decide where traffic goes: to an IGW, NAT gateway, VPC peering, VPN, or stays local.
Key Gateways
An Internet Gateway enables internet access for subnets that route to it. NAT gateways let private subnets reach out to the internet without accepting inbound connections.
VPC Endpoints
VPC endpoints give private connectivity to AWS services like S3 and DynamoDB, removing the need to traverse the public internet for those services.
Public vs Private Subnets: How and Why
What Makes a Subnet Public?
A subnet is public if its route table has a route to an Internet Gateway and the resource has a public or Elastic IP for direct internet reachability.
Uses for Public Subnets
Public subnets usually host internet-facing load balancers, bastion hosts, and NAT gateways that serve private subnets.
What Makes a Subnet Private?
Private subnets do not route directly to an IGW. They may route to a NAT gateway for outbound-only internet or to VPC endpoints for private AWS access.
Uses for Private Subnets
Private subnets host EC2 app servers, RDS databases, caches, and internal services that must not be reachable directly from the public internet.
Multi-AZ Layout Pattern
For security and reliability, create public and private subnets in at least two AZs. Put load balancers and NAT in public, and app and DB tiers in private subnets.
Worked Design: 2-Tier Web App in a VPC
Scenario Overview
Design a secure, highly available 2-tier app: internet users, EC2 web tier, RDS DB, only web tier internet-facing, multi-AZ, in a single VPC.
VPC and Subnets
Create VPC 10.0.0.0/16. In AZs 1a and 1b: public subnets 10.0.1.0/24 and 10.0.2.0/24; private subnets 10.0.11.0/24 and 10.0.12.0/24.
Internet and NAT Routing
Attach an IGW. Public subnets route 0.0.0.0/0 to IGW. Private subnets route 0.0.0.0/0 to NAT gateways in the public subnets for outbound-only internet.
Placing Resources
ALB in public subnets, EC2 web servers in private subnets via Auto Scaling, RDS in a DB subnet group using the private subnets in both AZs.
Security Flow
Internet → ALB SG (HTTPS) → Web tier SG (from ALB SG) → RDS SG (from web SG). Only the ALB is internet-facing; app and DB stay private.
Security Groups: Your Stateful Virtual Firewalls
What Security Groups Are
Security groups are stateful, instance-level virtual firewalls attached to ENIs of resources such as EC2, RDS, and load balancers.
Core Behaviors
They are stateful, support only allow rules, default to no inbound and all outbound allowed, and if any attached SG allows traffic, it is allowed.
Rule Structure
Each rule has direction, protocol, port or range, and a source or destination: CIDR, another security group, or a prefix list.
Referencing SGs
You can reference another SG as the source. That enables patterns like DB SG allowing inbound only from App SG, not from arbitrary IP ranges.
Exam Traps
Watch for misconfigured SGs on the wrong resource and remember statefulness: response traffic is allowed automatically without extra rules.
Network ACLs: Stateless Subnet-Level Filters
What NACLs Are
Network ACLs are stateless, subnet-level firewalls. Each subnet has one NACL; a NACL can be shared by multiple subnets.
Stateless and Ordered
NACLs are stateless, so you must allow both request and response. Rules are numbered; the first matching rule, allow or deny, decides the outcome.
Default vs Custom NACLs
The default NACL allows all inbound and outbound. Custom NACLs start with no rules, so all traffic is implicitly denied until you add rules.
Rule Fields
Each rule has a number, allow or deny, protocol, port range, and source or destination CIDR depending on direction.
Exam-Relevant Uses
Use NACLs to block specific IPs, add subnet-level protection, or troubleshoot when a custom NACL is blocking required ephemeral ports.
Security Groups vs NACLs: Choosing the Right Tool
Scope Comparison
Security groups attach to ENIs for instance-level control. NACLs attach to subnets and affect every resource within those subnets.
Stateful vs Stateless
Security groups are stateful: responses are automatically allowed. NACLs are stateless: you must allow both request and response explicitly.
Rules and Denies
Security groups only have allow rules and no order. NACLs have ordered allow and deny rules; the first matching rule decides.
Use Case Heuristics
Tier-to-tier trust or app-level access: use SGs. Blocking specific IPs or subnet-level controls: use NACLs.
Exam Patterns
Mentions of stateful, instance-level, or SG referencing SGs point to security groups. IP blocking or subnet boundaries point to NACLs.
Design Exercise: Lock Down What You Must, Expose Only What You Need
Work through this thought exercise to solidify your mental model. You do not need to write code; just reason step by step.
Scenario
You are deploying an internal analytics dashboard used only by employees over a corporate VPN. Requirements:
- No direct internet access to the dashboard servers.
- The dashboard pulls data from an RDS database.
- Admins sometimes need SSH access for troubleshooting, but only from the corporate network.
Your task
Pause after each bullet and decide:
- Subnet placement
- Where do you place the dashboard EC2 instances: public or private subnets? Why?
- Where do you place the RDS database?
- Internet access
- Do the dashboard EC2 instances need outbound internet? If yes, how do you provide it securely?
- Do you need an internet-facing load balancer at all?
- Security groups
- What inbound rules should the dashboard SG have? From which sources and on which ports (for example, HTTPS, SSH)?
- How should the RDS SG be configured to allow only the dashboard tier?
- Network ACLs
- Would you change the default NACLs? If you decide to, what problem are you solving that SGs alone cannot?
Self-check (peek only after you think it through)
- Both dashboard EC2 and RDS should be in private subnets; users reach the VPC via VPN or Direct Connect, not the internet.
- Outbound internet (if needed for updates) should go through a NAT gateway in a public subnet.
- Dashboard SG: allow HTTPS (and maybe SSH) only from the corporate VPN CIDR or a dedicated admin SG. RDS SG: allow DB port only from the dashboard SG.
- NACLs can stay default unless you have a specific IP-blocking or compliance requirement.
Quick Check 1: Subnets and Internet Access
Answer this exam-style question to test your understanding of public vs private subnets and NAT.
You run EC2 instances in a private subnet that must download OS updates from the internet, but must not be reachable from the internet. Which combination best meets this requirement?
- Assign public IPs to the instances and attach an Internet Gateway to the VPC.
- Place a NAT gateway in a public subnet and add a default route from the private subnet to the NAT gateway.
- Use a VPC endpoint for Amazon S3 and no other changes.
- Move the instances into a public subnet and restrict inbound traffic with security groups.
Show Answer
Answer: B) Place a NAT gateway in a public subnet and add a default route from the private subnet to the NAT gateway.
Instances in private subnets should not have public IPs. The standard pattern is to deploy a NAT gateway in a public subnet and configure the private subnet’s route table to send 0.0.0.0/0 traffic to the NAT. This allows outbound-only internet access. VPC endpoints help for specific AWS services but do not provide general internet access.
Quick Check 2: Security Group vs NACL
Test your ability to choose between security groups and network ACLs.
Your security team asks you to immediately block traffic from a single malicious IP address (203.0.113.50) reaching any instance in a public subnet, without changing instance-level settings. What is the most appropriate solution?
- Add a deny rule for 203.0.113.50 to the security group attached to each instance.
- Create a new NACL with a deny rule for 203.0.113.50 and associate it with the public subnet.
- Remove the Internet Gateway from the VPC.
- Remove all outbound rules from the security groups in the subnet.
Show Answer
Answer: B) Create a new NACL with a deny rule for 203.0.113.50 and associate it with the public subnet.
Security groups do not support explicit deny rules. The correct subnet-level control is a network ACL: create a rule denying traffic from 203.0.113.50 and associate that NACL with the public subnet. Removing the IGW would break all internet access, not just that IP.
Key Term Review: VPC Security Building Blocks
Flip through these flashcards to reinforce key terms and exam-relevant definitions.
- Amazon VPC
- A logically isolated virtual network in an AWS Region where you define IP ranges, subnets, routing, and network security controls for your resources.
- Public subnet (practical definition)
- A subnet whose route table has a route to an Internet Gateway and that contains resources with public or Elastic IPs, making them directly reachable from the internet (subject to security controls).
- Private subnet
- A subnet without a direct route to an Internet Gateway. Resources typically access the internet through a NAT gateway or VPC endpoints and are not directly reachable from the internet.
- Internet Gateway (IGW)
- A horizontally scaled, redundant VPC component that allows communication between resources in your VPC and the internet.
- NAT gateway
- A managed service in a public subnet that allows instances in private subnets to initiate outbound internet connections while preventing unsolicited inbound connections.
- Security group
- A stateful, instance-level virtual firewall for controlling inbound and outbound traffic to AWS resources using allow rules only.
- Network ACL (NACL)
- A stateless, subnet-level firewall with ordered allow and deny rules that control inbound and outbound traffic for all resources in associated subnets.
- Stateful vs stateless (in AWS networking)
- Stateful (security groups): return traffic is automatically allowed. Stateless (NACLs): you must explicitly allow both directions of traffic.
- VPC endpoint
- A private connection that enables resources in your VPC to access supported AWS services without using the public internet.
- DB subnet group (RDS)
- A collection of subnets, typically private, in different AZs that RDS uses to deploy database instances with high availability.
Putting It Together: Best Practices and Exam Patterns
Well-Architected Context
The AWS Well-Architected Framework has six pillars: Operational excellence, Security, Reliability, Performance efficiency, Cost optimization, Sustainability.
Relevant Pillars
VPC security mainly involves the Security pillar and the Reliability pillar, focusing on protection, availability, and controlled blast radius.
Core Patterns
Use multi-AZ VPCs, public subnets for internet-facing components, private subnets for app and data, SGs as primary controls, and NACLs for special cases.
Use VPC Endpoints
Prefer VPC endpoints to reach AWS services from private subnets without traversing the public internet, tightening your security posture.
Next Steps in Skarp
Diagnostics, mocks, and gap guides will pressure-test your VPC layouts and SG/NACL choices and feed weak items into your spaced review queue.
Key Terms
- Subnet
- A range of IP addresses in a VPC that resides in a single Availability Zone and contains resources such as EC2 instances.
- Amazon VPC
- A logically isolated virtual network in an AWS Region where you define IP ranges, subnets, routing, and network security controls for your resources.
- NAT gateway
- A managed service deployed in a public subnet that enables instances in private subnets to initiate outbound internet connections while blocking unsolicited inbound connections.
- VPC endpoint
- A private connection that enables resources in your VPC to access supported AWS services without using the public internet.
- Public subnet
- A subnet whose route table has a route to an Internet Gateway and that contains resources with public or Elastic IPs, making them directly reachable from the internet (subject to security controls).
- Private subnet
- A subnet without a direct route to an Internet Gateway; its resources typically reach the internet via NAT gateways or VPC endpoints and are not directly reachable from the internet.
- Security group
- A stateful, instance-level virtual firewall for controlling inbound and outbound traffic to AWS resources using allow rules only.
- DB subnet group
- A collection of subnets in different Availability Zones that Amazon RDS uses to deploy database instances, typically using private subnets for better security.
- Network ACL (NACL)
- A stateless, subnet-level firewall with ordered allow and deny rules that control inbound and outbound traffic for all resources in associated subnets.
- Internet Gateway (IGW)
- A horizontally scaled, redundant VPC component that allows communication between resources in your VPC and the internet.