DevOps Knowledge Hub
DevOps Knowledge Hub

Guide to Building a Secure AWS VPC from Scratch

Learn how to build a secure AWS Virtual Private Cloud (VPC) from the ground up. This comprehensive guide covers essential concepts like CIDR blocks, subnets, and route tables. Discover step-by-step instructions for creating public and private subnets, configuring Internet Gateways and NAT Gateways, and implementing critical security measures using Security Groups and NACLs for optimal network isolation and protection.

29 views

Guide to Building a Secure AWS VPC from Scratch

Amazon Web Services (AWS) Virtual Private Cloud (VPC) is a fundamental building block for deploying applications and resources in the cloud. It provides a logically isolated section of the AWS Cloud where you can launch AWS resources in a virtual network that you define. Building a secure VPC from scratch is crucial for protecting your data and applications from unauthorized access. This guide will walk you through the essential steps of designing and configuring a new VPC, covering key components like subnets, route tables, and critical security considerations for optimal network segmentation and isolation.

A well-designed VPC is the foundation of a secure cloud infrastructure. It allows you to control your network environment, define access rules, and segment your resources based on their sensitivity and function. By carefully planning and implementing your VPC, you can significantly enhance the security posture of your AWS deployment, reducing the attack surface and preventing unintended data exposure. This guide will equip you with the knowledge to create a robust and secure VPC tailored to your specific needs.

Understanding Core VPC Concepts

Before diving into the configuration steps, it's essential to grasp the fundamental concepts of AWS VPC:

  • VPC (Virtual Private Cloud): A virtual network dedicated to your AWS account. It's a logically isolated section of the AWS Cloud where you can launch AWS resources.
  • Subnet: A range of IP addresses in your VPC. You can launch AWS resources into subnets that you create. Subnets are defined by their CIDR block, which is a subset of the VPC's CIDR block.
  • Route Table: A set of rules, called routes, that are used to determine where network traffic from your subnet or gateway is directed.
  • Internet Gateway (IGW): A VPC component that allows communication between your VPC and the internet. It enables instances in your VPC to connect to the internet and vice-versa.
  • NAT Gateway (Network Address Translation): A highly available and scalable NAT service that enables internet access for instances in a private subnet while preventing inbound connections initiated from the internet.
  • Security Group: Acts as a virtual firewall for your instances to control inbound and outbound traffic. It operates at the instance level.
  • Network Access Control List (NACL): An optional layer of security for your VPC that acts as a firewall for controlling traffic in and out of one or more subnets. It operates at the subnet level.

Step-by-Step VPC Creation

Let's begin building your secure VPC.

1. Plan Your IP Address Scheme

The first and most critical step is to plan your IP address range for the VPC and its subnets. This involves selecting a Classless Inter-Domain Routing (CIDR) block for your VPC.

  • VPC CIDR Block: Choose a private IP address range that doesn't overlap with your on-premises network or any other AWS VPCs you might connect to via VPN or Direct Connect. AWS recommends using RFC 1918 IP address ranges (10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16). The CIDR block can be from /16 (65,536 IP addresses) to /28 (16 IP addresses).

    • Example: 10.0.0.0/16 provides a large address space for your VPC.

  • Subnet CIDR Blocks: Divide your VPC's CIDR block into smaller CIDR blocks for your subnets. Ensure each subnet's CIDR block is a subset of the VPC's CIDR block and does not overlap with other subnets.

    • **Example (if VPC is 10.0.0.0/16):
      • Public Subnet 1: 10.0.1.0/24
      • Public Subnet 2: 10.0.2.0/24
      • Private Subnet 1: 10.0.10.0/24
      • Private Subnet 2: 10.0.11.0/24

2. Create Your VPC

Navigate to the VPC dashboard in the AWS Management Console and create a new VPC.

  1. Go to VPC Dashboard > Your VPCs > Create VPC.
  2. Name tag: Give your VPC a descriptive name (e.g., MySecureVPC).
  3. IPv4 CIDR block: Enter the CIDR block you planned (e.g., 10.0.0.0/16).
  4. IPv6 CIDR block: You can choose to enable an IPv6 CIDR block if needed.
  5. Tenancy: For most use cases, Default is suitable. Dedicated offers hardware isolation at a higher cost.
  6. Click Create VPC.

3. Create Subnets

Now, create your public and private subnets within the VPC.

  1. Go to VPC Dashboard > Subnets > Create subnet.
  2. VPC ID: Select the VPC you just created.
  3. Subnet name: Provide a name (e.g., MyPublicSubnet-AZ1).
  4. Availability Zone: Choose an Availability Zone (AZ). It's best practice to deploy resources across multiple AZs for high availability.
  5. IPv4 CIDR block: Enter the CIDR block for this subnet (e.g., 10.0.1.0/24).
  6. Click Create subnet.

Repeat this process to create all your planned public and private subnets, ensuring they are in different Availability Zones for resilience.

4. Create an Internet Gateway (IGW)

An IGW is needed for your public subnets to access the internet.

  1. Go to VPC Dashboard > Internet Gateways > Create internet gateway.
  2. Name tag: MyVPCInternetGateway.
  3. Click Create internet gateway.
  4. After creation, select the IGW, click Actions, and choose Attach to VPC. Select your VPC and click Attach internet gateway.

5. Create Route Tables

Route tables direct traffic within your VPC. You'll typically need at least two: one for public subnets and one for private subnets.

a. Public Route Table:

  1. Go to VPC Dashboard > Route Tables > Create route table.
  2. Name tag: MyPublicRouteTable.
  3. VPC: Select your VPC.
  4. Click Create route table.
  5. Select the newly created MyPublicRouteTable.
  6. Under the Routes tab, click Edit routes.
  7. Click Add route.
  8. Destination: 0.0.0.0/0 (all IPv4 traffic).
  9. Target: Select Internet Gateway and choose your IGW.
  10. Click Save routes.
  11. Associate Subnets: Go to the Subnet associations tab, click Edit subnet associations, and associate your public subnets with this route table.

b. Private Route Table (with NAT Gateway):

To allow instances in private subnets to initiate outbound connections to the internet (e.g., for software updates) without being directly accessible from the internet, you'll use a NAT Gateway.

  1. Create a NAT Gateway:

    • Go to VPC Dashboard > NAT Gateways > Create NAT gateway.
    • Name: MyNATGateway.
    • Subnet: Select one of your public subnets.
    • Connectivity type: Public.
    • Elastic IP allocation ID: Click Allocate Elastic IP to create and assign a new Elastic IP address.
    • Click Create NAT gateway.
    • Note: NAT Gateways incur costs. For basic outbound connectivity, ensure you have sufficient IP addresses available in your public subnet for the NAT Gateway..

  2. Create the Private Route Table:

    • Go to VPC Dashboard > Route Tables > Create route table.
    • Name tag: MyPrivateRouteTable.
    • VPC: Select your VPC.
    • Click Create route table.
    • Select the MyPrivateRouteTable.
    • Under the Routes tab, click Edit routes.
    • Click Add route.
    • Destination: 0.0.0.0/0.
    • Target: Select NAT Gateway and choose your NAT Gateway.
    • Click Save routes.
    • Associate Subnets: Go to the Subnet associations tab, click Edit subnet associations, and associate your private subnets with this route table.

6. Configure Security Groups

Security Groups act as stateful firewalls at the instance level. They allow or deny traffic based on rules you define.

  • Best Practice: Create specific security groups for different types of resources (e.g., web servers, database servers, application servers). Avoid using overly permissive rules.

Example: Web Server Security Group (WebServerSG)

  1. Go to VPC Dashboard > Security Groups > Create security group.
  2. Security group name: WebServerSG.
  3. Description: Allow HTTP and HTTPS access.
  4. VPC: Select your VPC.
  5. Inbound rules:
    • Type: HTTP, Protocol: TCP, Port range: 80, Source: 0.0.0.0/0 (or a more specific trusted IP range).
    • Type: HTTPS, Protocol: TCP, Port range: 443, Source: 0.0.0.0/0 (or a more specific trusted IP range).
    • (Optional) Type: SSH, Protocol: TCP, Port range: 22, Source: Your trusted IP address/range (crucial for management).
  6. Outbound rules: By default, allow all outbound traffic (0.0.0.0/0). You can restrict this if needed.
  7. Click Create security group.

Example: Database Server Security Group (DatabaseSG)

  1. Create a new security group named DatabaseSG.
  2. Inbound rules:
    • Add a rule allowing traffic on your database's default port (e.g., 3306 for MySQL, 5432 for PostgreSQL) only from the security group of your application servers (e.g., WebServerSG or AppServerSG).
    • Source: Select Custom and then type the ID of your application server security group.
  3. Outbound rules: Typically allow all outbound traffic.

7. Configure Network Access Control Lists (NACLs)

NACLs are stateless firewalls that operate at the subnet level. They act as an additional layer of defense.

  • Stateful vs. Stateless: Security Groups are stateful (if you allow inbound traffic, the outbound response is automatically allowed). NACLs are stateless (you must explicitly define rules for both inbound and outbound traffic).

  • Best Practice: NACLs are often left with default configurations unless specific subnet-level access control is required. They can be complex to manage.

If you need to use NACLs:

  1. Go to VPC Dashboard > Network ACLs > Create network ACL.
  2. Name tag: MyNacl.
  3. VPC: Select your VPC.
  4. Click Create network ACL.
  5. Select the NACL, and under Inbound Rules, add rules.
  6. Rule Numbers: NACLs evaluate rules in order, starting with the lowest numbered rule. Use numbers like 100, 200, 300, etc., to allow for future rule insertion.
  7. Allow/Deny: Specify whether to allow or deny traffic.
  8. Protocol, Port Range, Source/Destination: Define the traffic parameters.
  9. Remember to configure corresponding Outbound Rules.
  10. Associate the NACL with your subnets by going to the Subnet Associations tab.

Example Deployment Scenario

Consider a typical web application:

  • VPC: 10.0.0.0/16
  • Public Subnet 1 (us-east-1a): 10.0.1.0/24 (Associated with MyPublicRouteTable and IGW)
  • Public Subnet 2 (us-east-1b): 10.0.2.0/24 (Associated with MyPublicRouteTable and IGW)
  • Private Subnet 1 (us-east-1a): 10.0.10.0/24 (Associated with MyPrivateRouteTable and NAT Gateway)

  • Private Subnet 2 (us-east-1b): 10.0.11.0/24 (Associated with MyPrivateRouteTable and NAT Gateway)

  • Internet Gateway: Attached to the VPC.

  • NAT Gateway: Deployed in Public Subnet 1 with an Elastic IP.
  • Public Route Table: Directs 0.0.0.0/0 to the IGW. Associated with Public Subnets.

  • Private Route Table: Directs 0.0.0.0/0 to the NAT Gateway. Associated with Private Subnets.

  • Security Group for Load Balancers (in Public Subnets): Allows HTTP/HTTPS from 0.0.0.0/0.

  • Security Group for Web Servers (in Private Subnets): Allows HTTP/HTTPS from the Load Balancer SG, and SSH from your trusted IP.
  • Security Group for Databases (in Private Subnets): Allows MySQL/PostgreSQL from the Web Server SG.

Critical Security Considerations

  • Principle of Least Privilege: Grant only the necessary permissions for your security groups and NACLs. Restrict source IP addresses as much as possible.
  • Use Multiple Availability Zones: Distribute your subnets and resources across multiple AZs for high availability and disaster recovery. This is achieved by creating subnets in different AZs and associating them with appropriate route tables.
  • Regularly Review Security Groups and NACLs: As your application evolves, so should your security rules. Periodically audit and update them.
  • Avoid Public Subnets for Sensitive Resources: Databases, application servers, and other sensitive resources should reside in private subnets. Only resources requiring direct internet access (like load balancers or bastion hosts) should be in public subnets.
  • Consider Bastion Hosts: If you need to SSH into instances in private subnets, consider using a hardened bastion host in a public subnet. Restrict SSH access to the bastion host to known IP addresses.
  • VPC Flow Logs: Enable VPC Flow Logs to capture information about the IP traffic going to and from network interfaces in your VPC. This is invaluable for security monitoring and troubleshooting.
  • Network Segmentation: Use different VPCs and subnets to segment environments (e.g., development, staging, production) and different tiers of your application.

Conclusion

Building a secure AWS VPC from scratch involves careful planning and configuration of its core components. By understanding CIDR blocks, subnets, route tables, and leveraging security groups and NACLs effectively, you can establish a robust and isolated network environment for your AWS resources. Remember that security is an ongoing process, so continuous monitoring, review, and adherence to best practices are paramount to maintaining a secure cloud infrastructure.