Lantern’s old server had a public IP address and a firewall that, honestly, nobody had looked at in two years. Its database listened on port 5432 on the same machine. On AWS the database will run on its own, and the first question is: who can even reach it? The answer is designed in Amazon VPC, your private network inside AWS.
\nA VPC (virtual private cloud) is an isolated network in one Region with an IP range you choose, such as 10.0.0.0/16 (65,536 addresses). Every Region gives each account a default VPC with public subnets, handy for experiments; production gets a VPC you design.
A subnet is a slice of that range inside one Availability Zone, such as 10.0.1.0/24 (256 addresses, of which AWS reserves five). Because subnets are zonal, resilience means pairs: Lantern uses two AZs, each with one public and one private subnet.
Nothing about the subnet itself. It is the route table:
\nPublic route table Private route table\n10.0.0.0/16 -> local 10.0.0.0/16 -> local\n0.0.0.0/0 -> igw-0abc... 0.0.0.0/0 -> nat-0def...A subnet whose route table sends 0.0.0.0/0 (everything not local) to an internet gateway is public: a resource there with a public IP can talk to the internet and be reached from it. A private subnet has no route to the internet gateway, so nothing on the internet can start a connection to it. If private resources need to start outbound connections, say to download OS updates, they route through a NAT gateway that sits in a public subnet.
Lantern’s database and the migration server go in private subnets. The public subnets hold only the NAT gateway and, later, a load balancer.
\n\nA security group is an allow-list attached to a resource’s network interface: an instance, an RDS database, a Lambda function inside the VPC. Three properties make them pleasant to work with:
\nlantern-app-sg group” means “from anything wearing that group”, however many instances that is and whatever their IPs.aws ec2 authorize-security-group-ingress \\\n --group-id sg-0db1111111111111a \\\n --protocol tcp --port 5432 \\\n --source-group sg-0app222222222222bThat one rule says it all: the database accepts PostgreSQL from the app tier and nothing else.
\n\nA network ACL filters traffic at the subnet boundary. It differs from a security group in every way:
\n| \n | Security group | \nNetwork ACL | \n
|---|---|---|
| Attached to | \nResources (network interfaces) | \nSubnets | \n
| Rules | \nAllow only | \nAllow and deny | \n
| State | \nStateful: replies allowed | \nStateless: replies need rules | \n
| Order | \nAll rules considered | \nLowest rule number first, first match wins | \n
Because ACLs are stateless, allowing inbound 443 is not enough: the reply leaves from port 443 to the client’s ephemeral port (1024–65535), and the outbound rules must allow that too. The default network ACL allows everything both ways, and most teams leave it that way and do the real work in security groups. Reach for a custom ACL when you need a subnet-wide deny, such as blocking an abusive address range.
\nThe VPC, subnets, route tables, security groups and ACLs are free. What bills is what you put in them: NAT gateways per hour plus per gigabyte, public IPv4 addresses per hour, and cross-AZ traffic per gigabyte. One NAT gateway per AZ is the resilient choice; a single shared one saves money and accepts that an AZ failure cuts private outbound traffic. For Lantern’s size, the sensible default is one NAT gateway plus gateway endpoints, and revisit when traffic grows. (Since late 2025 AWS also offers a regional NAT gateway that spreads across AZs by itself and needs no public subnet; compare its price before you switch.)
\nThat completes the core services. Section four puts them together and ships the new Lantern.
\n","toc":[{"id":"sec-1","text":"A VPC and its subnets","level":2},{"id":"sec-2","text":"What makes a subnet public","level":2},{"id":"sec-3","text":"Security groups: stateful firewalls on resources","level":2},{"id":"sec-4","text":"Network ACLs: stateless rules on subnets","level":2},{"id":"sec-5","text":"What this costs","level":2}],"takeaways":["A VPC is your private network in one Region, and each subnet is an address range inside a single Availability Zone.","A subnet is public only because its route table sends 0.0.0.0/0 to an internet gateway; private subnets have no such route.","Security groups are stateful allow-lists attached to resources, and they can name another security group as the allowed source.","Network ACLs are stateless rule lists on subnets, evaluated in number order, and can deny as well as allow.","NAT gateways and public IPv4 addresses bill by the hour, while gateway endpoints let private subnets reach S3 and DynamoDB at no extra charge."],"further":[{"title":"How Amazon VPC works","url":"https://docs.aws.amazon.com/vpc/latest/userguide/how-it-works.html"},{"title":"Control traffic to your AWS resources using security groups","url":"https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html"},{"title":"Control subnet traffic with network access control lists","url":"https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html"},{"title":"Gateway endpoints","url":"https://docs.aws.amazon.com/vpc/latest/privatelink/gateway-endpoints.html"}],"quiz":[{"q":"Two subnets in Lantern’s VPC are identical except that one has a route 0.0.0.0/0 → igw-0abc… in its route table. What does that route change?
Lantern’s database security group must accept PostgreSQL connections only from the app servers. Which inbound rule is best?
","options":[{"text":"TCP 5432 from the app servers’ security group.","why":"Correct. Referencing a security group keeps working when app servers are replaced or scaled, without tracking IP addresses."},{"text":"TCP 5432 from 0.0.0.0/0, because the database is in a private subnet anyway.","why":"A private subnet is one layer of protection. Allowing the whole internet removes the second layer and lets anything inside the VPC connect."},{"text":"All traffic from the VPC’s CIDR range.","why":"That lets every resource in the VPC reach every port on the database, which is far wider than the app needs."},{"text":"TCP 5432 from the current private IP address of each app server.","why":"It works until an instance is replaced and gets a new address. Then connections fail, or a stranger’s instance inherits the old IP."}],"answer":0},{"q":"A network ACL allows inbound TCP 443 from anywhere, but HTTPS requests to an instance in the subnet time out, while its security group allows 443. What is the likely cause?
","options":[{"text":"Security groups override network ACLs, so the ACL is ignored.","why":"Both layers apply. Traffic must pass the network ACL and the security group."},{"text":"The instance needs a NAT gateway to answer requests.","why":"A NAT gateway is for private resources starting outbound connections. Replies to inbound requests in a public subnet go through the internet gateway."},{"text":"Network ACLs are stateless, so the outbound rules must also allow the reply traffic to ephemeral ports.","why":"Correct. Unlike security groups, a network ACL does not remember the connection, so return traffic needs its own allow rule."},{"text":"Port 443 is blocked by AWS on new accounts.","why":"AWS does not block 443 for your resources. Inbound traffic is controlled by your own network ACLs and security groups."}],"answer":2}],"exercise":{"kind":"spot-bug","language":"bash","code":"#!/usr/bin/env bash\nset -euo pipefail\nVPC_ID=\"vpc-0abc1234def567890\"\n\nAPP_SG=$(aws ec2 create-security-group --group-name lantern-app-sg \\\n --description \"Lantern app servers\" --vpc-id \"$VPC_ID\" \\\n --query GroupId --output text)\nDB_SG=$(aws ec2 create-security-group --group-name lantern-db-sg \\\n --description \"Lantern PostgreSQL\" --vpc-id \"$VPC_ID\" \\\n --query GroupId --output text)\n\n# Visitors reach the app over HTTPS during the migration\naws ec2 authorize-security-group-ingress --group-id \"$APP_SG\" \\\n --protocol tcp --port 443 --cidr 0.0.0.0/0\n\n# Maintainers need a shell on the app servers\naws ec2 authorize-security-group-ingress --group-id \"$APP_SG\" \\\n --protocol tcp --port 22 --cidr 0.0.0.0/0\n\n# Only the app servers may talk to PostgreSQL\naws ec2 authorize-security-group-ingress --group-id \"$DB_SG\" \\\n --protocol tcp --port 5432 --cidr 0.0.0.0/0","bugLines":[18,22],"title":"Review the security group script","prompt":"A volunteer wrote this script to create Lantern’s security groups during the migration. The comments describe the intent, and the intent is right. Select every line where the code does not match a safe version of that intent.
\n","hints":["Public HTTPS on the app servers is intended for now. Look at the other two rules.","Which rule exposes a port that attackers scan for constantly, to the whole internet?","The database comment says “only the app servers”. What does0.0.0.0/0 mean?"],"explanation":"Line 18 opens SSH to every address on the internet. Maintainers should use AWS Systems Manager Session Manager, which needs no inbound rule at all; if SSH is unavoidable, restrict --cidr to a known office or VPN range such as 203.0.113.0/24. Line 22 lets anything reach PostgreSQL. Replace the CIDR with a reference to the app tier’s group, so the rule follows the app servers wherever they run:
aws ec2 authorize-security-group-ingress --group-id \"$DB_SG\" \\\n --protocol tcp --port 5432 --source-group \"$APP_SG\"Line 14 is fine: during the migration visitors do reach the app over HTTPS. Being in a private subnet would reduce the damage of line 22, but defence in depth means each layer should be correct on its own.
\n","checkLabels":{}},"words":777,"readMinutes":4}