Why bother with a public subnet anyway

If you want your EC2 instance to answer the outside world and not hide under a pile of private IPs, you need a public subnet, an Internet Gateway and sensible security group rules. This guide walks through the practical steps to get SSH and HTTP working without accidentally turning your server into a public squirrel feeder.

Create the VPC and the public subnet

Create a VPC with a CIDR block that fits your needs, for example 10.0.0.0/16. Inside that VPC add a subnet that will be your public subnet. Pick a subnet CIDR like 10.0.1.0/24. Either enable auto assign public IPv4 on that subnet or plan to assign a public IP when you launch the instance.

Quick checklist

• VPC created with desired CIDR
• Public subnet created inside the VPC
• Auto assign public IPv4 turned on if you prefer convenience

Attach an Internet Gateway and update the route table

Attach an Internet Gateway to the VPC. Then edit the route table associated with the public subnet and add a route for 0.0.0.0/0 sending traffic to the Internet Gateway. That single route is what lets packets leave and return, which is necessary for SSH and HTTP to work.

Launch the EC2 instance

Pick an AMI and instance type that fits your workload. Make sure the instance is launched into the public subnet and that it receives a public IP. If the subnet does not auto assign a public IP, check the Assign Public IP option at launch. Choose a key pair for SSH access and attach an appropriate IAM role for any AWS API calls the instance will make.

Create security groups with TCP rules for SSH and HTTP

Create or edit a security group and add inbound TCP rules for the ports you need. For example add rules that allow TCP port 22 for SSH and TCP port 80 for HTTP. Avoid using 0.0.0.0/0 in production unless you enjoy surprise log entries and angry incident tickets. Instead restrict SSH to your office IP or VPN range and restrict HTTP if you have a limited client base.

• Allow TCP 22 from your IP range for SSH
• Allow TCP 80 from 0.0.0.0/0 only if you need public web access
• Attach the security group to the instance at launch or modify it later

Test connectivity and troubleshoot like a calm detective

SSH to the instance using the public IP and your key pair. Open the HTTP endpoint in a browser to verify the web server is reachable. If something fails check these items in this order

• Is the Internet Gateway attached to the VPC
• Does the route table for the subnet have 0.0.0.0/0 pointing to the Internet Gateway
• Does the instance have a public IP or elastic IP assigned
• Are the security group inbound rules allowing the correct TCP ports from the right sources
• Is any host firewall on the instance blocking access

Security tips that won't make your boss faint

Use key pairs for SSH. Use IAM roles for permissions and avoid embedding secrets on the instance. Lock down SSH to known IP ranges and consider using a bastion host or Session Manager if you want fewer open doors. For public web servers use a load balancer and WAF when traffic or attackers become a thing.

This covers the essentials for deploying an AWS EC2 instance into a public subnet with Internet Gateway routing and security group TCP rules for SSH and HTTP. Follow those steps and your instance will be reachable, supported, and less likely to be the site of some poor bot's late night party.