Why a public subnet and why should you care

Want a part of your VPC that actually talks to the internet without begging for permission Every public subnet in AWS VPC is basically the part of your network with a door to the world The trick is to give it a proper door a route out and sensible guards at the gate

Quick overview of the pieces you will touch

• AWS VPC for the network boundaries
• Public subnet inside an availability zone with a CIDR block
• Internet Gateway to let traffic leave and return
• Route Table with a default route for 0.0.0.0/0 pointing to the Internet Gateway
• Security Group and NACL to control traffic
• Optional VPC Endpoints and NAT if you want private instances to access AWS services or the internet

Step by step setup that does not require ritual sacrifices

1. Create or pick a VPC and a non conflicting CIDR block within your address plan
2. Create a subnet in your chosen availability zone and assign a CIDR from the VPC range This subnet will be public if we give it a route to an Internet Gateway
3. Create an Internet Gateway and attach it to your VPC Think of this as the door to the internet but the door is useless until the route table is told to use it
4. Create a Route Table and add a route for 0.0.0.0/0 that targets the Internet Gateway That tells instances in associated subnets where to walk out the door
5. Associate the new Route Table with the subnet If you skip this the subnet will sulk and remain private
6. When launching an instance choose auto assign public IP or attach an Elastic IP if you want a stable address

Notes about public IPs and Elastic IPs

An instance needs a public IP or an Elastic IP to receive inbound traffic from the internet Security Group rules still apply and you will not be exposed like a bug in a pancake unless you open ports

NACL and Security Group rules without the drama

Network ACLs are stateless so every response flow needs matching rules on inbound and outbound For example allow HTTP and HTTPS outbound and allow the ephemeral port range inbound if you want to permit responses Security Groups are stateful so opening inbound SSH or HTTP is enough to allow return traffic automatically

• NACL example rules allow inbound ephemeral ports and outbound HTTP HTTPS as needed
• Security Group example allow inbound SSH from trusted IPs and allow all outbound for normal egress

Private workloads and NAT what to use when

If you want instances that never have public IPs but still need to reach the internet use a NAT Gateway in a public subnet That provides egress for private subnets without exposing those instances to inbound internet traffic If your only goal is access to AWS services use VPC Endpoints for S3 or Dynamo to keep traffic off the public internet

Test your work like a responsible human

Launch an instance in the public subnet with a public IP or attach an Elastic IP Then SSH or curl a public endpoint to verify egress and try a simple inbound check like a web server or SSH from an allowed IP If something is broken check the route table association then the Internet Gateway attachment then the Security Group and NACL order of rules

Troubleshooting tips that actually help

• No outbound traffic Check that the route table has 0.0.0.0/0 pointing to the Internet Gateway and that the subnet is associated
• No inbound traffic Check the instance has a public IP or Elastic IP and that the Security Group allows the port you need
• Intermittent issues Check NACLs for missing complementary rules NACLs are stateless and will bite you if you forget replies

There you go You now have a public subnet in your AWS VPC that can send and receive traffic while still letting you be slightly smug about your routing knowledge Keep your Security Groups tight and use NAT and VPC Endpoints where privacy matters