Launching EC2 instances within a VPC (along with Wizard)

Source: Dev.to

Launching VPC Resources on AWS

In today’s project, I created and launched EC2 instances inside a custom Amazon VPC. The goal was to see how instances behave when deployed in public and private subnets and to understand how AWS networking components work together in a real‑world setup. This hands‑on task helped me move beyond theory and actually visualize VPC architecture through AWS’s resource maps.

Through the project I learned:

• EC2 instances can be launched in different subnets, and subnet selection directly affects accessibility.
• AWS simplifies VPC creation using its built‑in wizard.
• Route tables, Internet Gateways, and NAT Gateways interact to provide connectivity for public and private resources.

Launching an EC2 Instance Inside a VPC

Step 1: Creating the EC2 instance

I navigated to the EC2 dashboard and chose Launch Instance. I selected an Amazon Machine Image (AMI) that defines the operating system and picked an instance type based on the required compute capacity. These choices form the base configuration of the EC2 instance.

Step 2: Creating a key pair for authentication

A key pair is required for secure access. I gave the key pair a name, selected the key‑pair type (RSA or ED25519), and kept the default .pem format for SSH access. The private key acts as a credential for directly accessing and managing the instance.

Step 3: Editing network settings

After the basic details, I edited the network settings:

• Chose the VPC where the instance should be launched.
• Selected the appropriate subnet (public or private).
• Associated an existing security group or created a new one to control inbound and outbound traffic.

Once reviewed, the EC2 instance was launched successfully.

Overall flow:
Launch Instance → Choose AMI → Select Instance Type → Create Key Pair → Edit Network Settings → Choose VPC and Subnet → Launch Instance.

Creating a VPC Using the “VPC and More” Wizard

Step 1: Selecting “VPC and more”

Instead of the traditional “VPC only” option, I selected VPC and more. This wizard automatically creates key networking components and provides a visual resource map that shows availability zones, subnets, route tables, and Internet Gateways.

Step 2: Naming and tenancy configuration

I added a name tag, which AWS used to auto‑generate names for related resources such as subnets. I then chose the tenancy type:

• Default tenancy – resources run on shared hardware (cost‑effective).
• Dedicated tenancy – resources run on isolated hardware (higher cost).

For most standard workloads, default tenancy is sufficient.

Step 3: Configuring availability zones and subnets

I selected the number of Availability Zones and the number of public and private subnets required. AWS automatically distributed the subnets across the chosen zones and attached them to the appropriate route tables. Public subnets were linked to an Internet Gateway, while private subnets remained isolated from direct internet access.

Step 4: Configuring the NAT gateway

Finally, I added a NAT gateway. The NAT gateway enables instances in private subnets to access the internet securely, handling outbound traffic without exposing private resources to inbound connections and eliminating the need for public IP addresses on private instances.

Key Takeaway

This project gave me a practical understanding of how AWS networking components work together as a unified system. Rather than viewing EC2, VPCs, subnets, and gateways as separate services, I saw how they integrate to form a secure and scalable cloud architecture. Using the VPC wizard and launching instances in different subnets made the concepts much clearer and easier to retain.

Special thanks to NextWork for providing the platform to learn about this project.