AWS + Linux Combo — Part 10: VPC, Networking & Security Groups
Every EC2 instance you launch exists inside a network. That network is called a VPC — Virtual Private Cloud. Understanding how VPCs, subnets, and security groups work is what separates someone who just launches instances from someone who can design and secure real cloud infrastructure. This knowledge is tested in every cloud certifications and asked in every cloud engineering interview.
What is a VPC?
A VPC is your own private network inside AWS. Think of it as renting a section of AWS's massive data center network and making it yours. You control the IP address range, the subnets, the routing, and what can communicate with what. When you create an AWS account, AWS automatically creates a default VPC in each region with sensible settings so you can immediately launch instances. But for production, you should design your own VPC.
Key VPC Components
- CIDR Block — The IP address range for your VPC, e.g., 10.0.0.0/16 gives you 65,536 IP addresses.
- Subnets — Subdivisions of your VPC. A subnet lives in one Availability Zone. Resources in a subnet share that zone's network.
- Public Subnet — A subnet connected to an Internet Gateway. Resources here can have public IPs and be reached from the internet.
- Private Subnet — No direct internet access. Used for databases, backend services, and anything that should not be public.
- Internet Gateway (IGW) — The connection between your VPC and the internet. Without an IGW, nothing in your VPC can reach the internet.
- Route Table — Rules that determine where network traffic goes. Public subnets have a route sending 0.0.0.0/0 traffic to the IGW.
- NAT Gateway — Allows instances in private subnets to initiate outbound internet connections (for software updates, for example) without being reachable from the internet.
Security Groups In Depth
Security Groups are stateful firewalls attached to EC2 instances. Stateful means if you allow inbound traffic on a port, the response traffic is automatically allowed — you do not need to add an outbound rule for it.
# Create a security group
aws ec2 create-security-group --group-name web-server-sg --description "Security group for web server" --vpc-id vpc-0abc123
# Allow HTTP from anywhere
aws ec2 authorize-security-group-ingress --group-id sg-0abc123 --protocol tcp --port 80 --cidr 0.0.0.0/0
# Allow HTTPS from anywhere
aws ec2 authorize-security-group-ingress --group-id sg-0abc123 --protocol tcp --port 443 --cidr 0.0.0.0/0
# Allow SSH from your IP only
aws ec2 authorize-security-group-ingress --group-id sg-0abc123 --protocol tcp --port 22 --cidr $(curl -s ifconfig.me)/32
# List inbound rules
aws ec2 describe-security-groups --group-ids sg-0abc123Network ACLs vs Security Groups
While Security Groups protect individual instances, Network ACLs (NACLs) protect entire subnets. Key differences: Security Groups are stateful, NACLs are stateless (you need both inbound and outbound rules). Security Groups only allow traffic — they cannot deny specific IPs. NACLs support both allow and deny rules with numbered priorities. For most use cases, Security Groups are sufficient. NACLs add an extra layer for environments with strict compliance requirements.
VPC Peering and Private Communication
VPC Peering lets two VPCs communicate with each other privately — traffic never goes over the public internet. This is used when you have separate VPCs for different environments (dev, staging, production) and need them to communicate:
# Create peering connection
aws ec2 create-vpc-peering-connection --vpc-id vpc-111 --peer-vpc-id vpc-222
# Accept the peering request
aws ec2 accept-vpc-peering-connection --vpc-peering-connection-id pcx-0abc123Checking Network Configuration on Linux
# View network interfaces
ip addr show
ifconfig # older systems
# View routing table
ip route show
route -n
# Check open ports
ss -tlnp
netstat -tlnp
# Test connectivity
ping google.com
curl -I https://srjahir.in
traceroute 8.8.8.8In Part 11, we will cover monitoring and logging — using CloudWatch to track your server's health and set up alerts for when things go wrong.
Security Groups vs NACLs
AWS has two layers of network access control that work together. Security Groups are stateful firewalls attached to individual resources (EC2 instances, RDS databases, load balancers). Stateful means return traffic is automatically allowed — you only need to define inbound rules for incoming connections, and the response traffic is automatically permitted. Security Groups can reference other Security Groups as sources, enabling patterns like "allow traffic from the web server security group to the database security group" without specifying IP addresses. Network ACLs (NACLs) are stateless firewalls attached to subnets. Stateless means you must explicitly allow both inbound and outbound traffic for each connection. NACLs process rules in order by rule number and stop at the first match. Use NACLs for broad subnet-level controls and Security Groups for resource-specific access control.
VPC Peering and Transit Gateway
When resources in different VPCs need to communicate, VPC Peering creates a direct network connection between two VPCs — traffic routes through the AWS backbone without going over the internet. Peering is limited to two VPCs and does not support transitive routing (if A peers with B and B peers with C, A cannot reach C through B). For connecting many VPCs, AWS Transit Gateway acts as a central hub — each VPC connects to Transit Gateway and can reach any other connected VPC. This hub-and-spoke model simplifies management as the number of VPCs grows and supports more complex routing policies.
Practice Exercise
Create a VPC with one public subnet and one private subnet from scratch using the AWS console or CLI. Create an Internet Gateway and attach it to the VPC. Configure route tables: the public subnet route table should have a route to the Internet Gateway for 0.0.0.0/0. Create security groups for a web server (allow HTTP/HTTPS from internet, SSH from your IP) and a database (allow port 5432 from the web server security group only). Launch EC2 instances in both subnets and verify the web server can reach the internet but the database instance cannot. Draw a diagram of what you built.