How to Securely Launch an EC2 Instance within a Custom VPC

Launching an Amazon EC2 instance in the default VPC is fast, but it often gives you less control than a production or staging environment needs. A custom VPC lets you choose the address range, split public and private subnets, and decide exactly which paths reach the internet.

This guide shows a practical secure layout: a public subnet for load balancers or bastion hosts, a private subnet for application instances, route tables that match those roles, and security groups that allow only required traffic.

Understanding the Core Components of a Secure VPC

A Virtual Private Cloud (VPC) is the foundation upon which all secure AWS networking is built. Before launching an instance, you must ensure the following components are correctly configured:

1. VPC: The main container for your network, defining a private IP address range (CIDR block).
2. Subnets: Divisions within the VPC, categorized as Public (with direct internet access) or Private (isolated).
3. Internet Gateway (IGW): Required for resources in public subnets to communicate with the internet.
4. Route Tables: Rules that dictate where network traffic from subnets is directed.
5. Security Groups (SGs): Stateful firewalls that control inbound and outbound traffic at the instance level.

Step 1: Creating the Custom VPC and Subnets

We begin by creating the network enclosure and segmenting it into functional areas. For a standard setup, we recommend at least one public and one private subnet.

1.1 Creating the VPC

When creating your VPC, select a private CIDR block that does not overlap with any on-premises networks you might connect to later (e.g., using AWS VPN or Direct Connect).

Example VPC CIDR: 10.0.0.0/16

1.2 Creating Subnets

Each subnet lives in one Availability Zone (AZ). Production VPCs usually use matching public and private subnets across at least two AZs, but this example keeps the layout small with one public and one private subnet in us-east-1a.

• Public Subnet: 10.0.1.0/24 (Used for bastion hosts or load balancers)
• Private Subnet: 10.0.2.0/24 (Used for application servers and databases)

Step 2: Configuring Internet Connectivity and Routing

Resources in private subnets should not have direct internet access. Resources in the public subnet must be routed correctly to reach the internet via an Internet Gateway (IGW).

2.1 Attaching an Internet Gateway (IGW)

1. Create an IGW resource in the AWS console.
2. Attach this IGW to your newly created VPC.

2.2 Configuring Route Tables

Route tables define traffic pathways. You need at least two: one for the public subnet and one for the private subnet.

Public Route Table

This table directs all non-local traffic (0.0.0.0/0) to the attached Internet Gateway.

Destination	Target
10.0.0.0/16 (VPC CIDR)	local
0.0.0.0/0	igw-xxxxxxxx (Your IGW ID)

Associate this route table with your Public Subnet (10.0.1.0/24).

Private Route Table

This table only allows internal communication. Crucially, it should have no route pointing to the IGW.

Destination	Target
10.0.0.0/16 (VPC CIDR)	local

Associate this route table with your Private Subnet (10.0.2.0/24).

Best Practice: If resources in the private subnet need to download patches or updates, you should use a NAT Gateway placed in the public subnet. The Private Route Table would then point 0.0.0.0/0 traffic to the NAT Gateway instead of the IGW.

Step 3: Defining Strict Security Group Rules

Security Groups (SGs) act as virtual firewalls for your EC2 instances. They operate at the instance level and are stateful (return traffic is automatically allowed).

For a secure setup, you should adhere to the principle of least privilege, explicitly allowing only necessary inbound traffic.

Example Security Group for a Web Server (Private Subnet)

If this EC2 instance is an application server only accessible from an application load balancer (ALB) residing in the public subnet, the rules should be highly restrictive:

Inbound Rules

Type	Protocol	Port Range	Source
HTTP	TCP	80	SG ID of the ALB
HTTPS	TCP	443	SG ID of the ALB
SSH	TCP	22	IP Range of your Corporate Network or Bastion Host SG ID

Outbound Rules

By default, outbound traffic is usually allowed to all destinations (0.0.0.0/0). You can restrict this further if required (e.g., only allowing connections to an RDS instance SG).

Security Tip: Never assign 0.0.0.0/0 to port 22 (SSH) or port 3389 (RDP) on a public-facing security group. Always restrict management access to known, internal IP ranges.

Step 4: Launching the EC2 Instance Securely

When launching your instance, ensure you map it to the correct network components established above.

1. Choose AMI and Instance Type: Select your desired Amazon Machine Image (AMI) and hardware specifications.
2. Network Settings: In the 'Configure Instance Details' step:
   • Network: Select your Custom VPC.
   • Subnet: Select the Private Subnet (10.0.2.0/24) if you are launching an application server that should not be directly exposed to the internet.
   • Auto-assign Public IP: Ensure this is Disabled if launching into a private subnet. (If you select a public subnet, you may enable this for an instance needing direct public access, like a bastion host).
   • Security Groups: Select the Security Group you configured in Step 3.
3. Storage and Key Pair: Configure storage and associate a key pair for secure SSH access.

Accessing Instances in a Private Subnet

Since the instance residing in the private subnet has no public IP address, you cannot SSH directly from the public internet. You must use one of two secure methods:

1. Bastion Host (Jump Box): Launch a small, hardened EC2 instance in the Public Subnet. You SSH into the bastion host first, and then from the bastion host, SSH into the private instance using its private IP address.
2. AWS Systems Manager (SSM) Session Manager: This is the preferred modern method. If the instance has the SSM agent installed and an appropriate IAM role attached allowing SSM connectivity, you can initiate a secure shell session directly from the AWS Console without needing inbound SSH rules or Bastion Hosts.

Summary and Next Steps

Securing an EC2 instance within a custom VPC involves layering network security from the macro level (VPC, Subnets, Route Tables) down to the micro level (Security Groups). By carefully controlling IP addressing and traffic flow:

• You ensure application servers reside in isolated private subnets.
• You use the IGW or NAT Gateway only where necessary.
• You apply the principle of least privilege via Security Group ingress rules.

Once your instance is launched, remember to monitor its activity using AWS CloudTrail and VPC Flow Logs to maintain continuous visibility into your private network traffic.