How to Set Up a Virtual Private Cloud on AWS

What Is a Virtual Private Cloud?

A Virtual Private Cloud (VPC) is an isolated virtual network within Amazon Web Services that gives you complete control over your cloud networking environment. Think of it as your own private data center in the AWS cloud, where you define IP address ranges, create subnets, configure route tables, and manage network gateways.

Unlike shared hosting environments, a VPC provides network-level isolation, ensuring your resources remain separate from other AWS customers. This isolation makes VPCs essential for organizations handling sensitive data, running production workloads, or requiring compliance with regulatory standards.

Benefits of Using AWS VPC

Implementing a properly configured VPC offers several advantages for cloud infrastructure. You gain granular control over network traffic flow, allowing you to segment resources into public and private subnets based on security requirements. This segmentation enables you to expose web servers to the internet while keeping database servers completely isolated.

VPCs also support hybrid cloud architectures through VPN connections and AWS Direct Connect, letting you extend your on-premises network seamlessly into the cloud. Additionally, you can implement advanced security controls including network access control lists (NACLs), security groups, and flow logs for comprehensive traffic monitoring.

For organizations exploring alternative cloud infrastructure solutions, Kamatera offers customizable virtual private servers with flexible networking configurations that can complement your AWS architecture for multi-cloud strategies.

Prerequisites for Setting Up a VPC

Before creating your VPC, ensure you have an active AWS account with appropriate IAM permissions. You’ll need permissions to create and manage VPC resources, including EC2 instances, security groups, and network interfaces. Familiarize yourself with basic networking concepts such as CIDR notation, subnetting, and routing protocols.

Additionally, plan your IP addressing scheme carefully. AWS reserves five IP addresses in each subnet, so account for this when calculating capacity. Understanding basic Linux commands and SSH connectivity will help when testing your configuration with EC2 instances.

Planning Your VPC Architecture

Proper planning prevents costly mistakes and rework. Start by determining your CIDR block range, which defines the total IP address space available in your VPC. A common choice is 10.0.0.0/16, providing 65,536 addresses, but select a range that won’t conflict with existing networks if you plan hybrid connectivity.

Design your subnet strategy based on availability zones and resource types. A typical architecture includes public subnets for internet-facing resources like load balancers and web servers, and private subnets for backend services like databases and application servers. Distributing subnets across multiple availability zones ensures high availability and fault tolerance.

Step-by-Step VPC Configuration

Creating Your VPC

Log into the AWS Management Console and navigate to the VPC Dashboard. Click “Create VPC” and choose “VPC only” for manual configuration, giving you full control over all components. Enter a descriptive name tag and specify your IPv4 CIDR block, such as 10.0.0.0/16.

Leave IPv6 CIDR block and tenancy settings at default unless you have specific requirements. Default tenancy runs instances on shared hardware, while dedicated tenancy uses physical servers exclusively for your account at higher cost. For most use cases, default tenancy provides adequate isolation and performance.

Configuring Subnets

Create subnets to divide your VPC into smaller network segments. Navigate to “Subnets” in the VPC Dashboard and click “Create subnet.” Select your newly created VPC and define your first public subnet with a CIDR block like 10.0.1.0/24, providing 256 addresses.

Choose an availability zone for high availability planning. Repeat this process to create additional subnets, including at least one private subnet (10.0.2.0/24) and ideally matching subnets in a second availability zone for redundancy. Name your subnets clearly, such as “Public-Subnet-AZ1” and “Private-Subnet-AZ1” for easy identification.

Setting Up an Internet Gateway

An internet gateway enables communication between your VPC and the internet. In the VPC Dashboard, select “Internet Gateways” and click “Create internet gateway.” Provide a descriptive name and create the gateway.

After creation, the gateway remains detached. Select it and choose “Attach to VPC,” then select your VPC from the dropdown. Each VPC can have only one internet gateway attached, establishing the primary connection point for internet-bound traffic.

Configuring Route Tables

Route tables control traffic flow between subnets and external networks. AWS automatically creates a main route table for your VPC, but best practice involves creating custom route tables for better organization and security.

Create a public route table by selecting “Route Tables” and clicking “Create route table.” Name it “Public-Route-Table” and associate it with your VPC. After creation, edit the routes and add a new route with destination 0.0.0.0/0 pointing to your internet gateway as the target. This route directs all internet-bound traffic through the gateway.

Associate this route table with your public subnets through the “Subnet associations” tab. Create a separate private route table without internet gateway routes for private subnets, keeping backend resources isolated from direct internet access.

Establishing Security Groups

Security groups act as virtual firewalls controlling inbound and outbound traffic at the instance level. Create a security group for your web servers by navigating to “Security Groups” and clicking “Create security group.”

Configure inbound rules to allow HTTP (port 80) and HTTPS (port 443) from 0.0.0.0/0 for public web access. Add SSH (port 22) restricted to your IP address for administrative access. Outbound rules typically allow all traffic by default, but restrict them for enhanced security in production environments.

Create separate security groups for different tiers, such as application servers and databases, implementing the principle of least privilege by allowing only necessary traffic between tiers.

Testing Your VPC Setup

Validate your configuration by launching an EC2 instance in your public subnet. During launch, select your VPC and public subnet, enable auto-assign public IP, and attach your web server security group. Connect via SSH using the command:

ssh -i your-key.pem ec2-user@your-public-ip

Once connected, install a simple web server to verify internet connectivity and routing:

sudo yum update -y
sudo yum install httpd -y
sudo systemctl start httpd
sudo systemctl enable httpd

Access the public IP in your browser to confirm the web server is reachable from the internet. This confirms your internet gateway, route tables, and security groups are properly configured.

Security Best Practices

Implement defense-in-depth by combining multiple security layers. Use network ACLs as an additional stateless firewall layer at the subnet level, complementing security groups. Enable VPC Flow Logs to capture IP traffic information for security analysis and troubleshooting.

Never place databases or sensitive resources in public subnets. Use NAT gateways to allow private subnet resources to initiate outbound internet connections for updates while preventing inbound access. Regularly audit security group rules and remove overly permissive configurations.

Consider taking structured cloud security courses to deepen your expertise. Platforms like Coursera offer comprehensive AWS certification programs that cover VPC architecture, security implementation, and advanced networking scenarios taught by industry professionals.

Enable AWS CloudTrail to log all API calls within your VPC for compliance and security auditing. Implement IAM policies following the principle of least privilege, granting users only the VPC permissions necessary for their roles.

Common Troubleshooting Tips

If instances in public subnets cannot access the internet, verify that your route table includes a route to the internet gateway and that the subnet association is correct. Confirm that instances have public IP addresses assigned, either through auto-assign settings or Elastic IPs.

Connection timeouts often indicate security group misconfigurations. Double-check that inbound rules allow traffic on required ports from appropriate sources. Remember that security groups are stateful, automatically allowing return traffic for established connections.

For connectivity issues between subnets, examine route tables and network ACLs. Unlike security groups, NACLs are stateless and require explicit rules for both inbound and outbound traffic. The default NACL allows all traffic, but custom NACLs start with deny-all rules.

Use VPC Reachability Analyzer to diagnose connectivity problems between source and destination resources. This tool analyzes the network path and identifies configuration issues preventing communication.