Secure AWS VPC Design and Configuration Guide

As more organizations move their infrastructure to the cloud, it’s essential to ensure the secure management of data and resources. AWS Virtual Private Cloud (VPC) is a crucial component of AWS networking, offering benefits such as:

• Hosting applications,
• EC2 management,
• Backup and disaster recovery,
• Hybrid cloud solutions, and much more.

However, VPC security should be a top priority, and organizations must consider factors such as the CIDR block, public and private subnets, network access control lists, and security groups.

In this blog post, we will discuss the best practices for designing and implementing a secure and efficient VPC that meets your specific needs. We will also explore how different AWS tools and services can help you achieve this goal.

AWS Virtual Private Cloud (VPC)

An AWS Virtual Private Cloud (VPC) is the keystone of AWS networking. VPC is an isolated virtual network that you define in your AWS infrastructure. Organizations use VPCs for different usage scenarios such as:

• Hosting Applications
• EC2 Management
• Back-up and Disaster Recovery
• Hybrid Cloud Solutions
• Cloud Migration and Data Center Operations
• Secure data and AWS Resources

VPC configuration and management could be difficult and confusing for most customers. It could be done with AWS Management Console, AWS CLI, AWS CloudFormation, or Terraform templates. On the other hand, AWS VPC security is one of the issues that should be considered.

In this blog post, we will answer your questions like:

• How should we construct a secure VPC design?
• What are the main points that we should review?
• How can we design a VPC with Terraform scripts?

AWS Global Infrastructure

AWS Global Infrastructure has different concepts. First of all, a region is defined as an isolated geographical area. A region has different availability zones which are one or more data centers that have redundant power, networking between them. Every region has at least two availability zones. With different availability zones, AWS customers ensure high availability of customer solutions.

For now, AWS announced 25 launched regions and 80 availability zones. New regions and availability zones continue to be launched day by day.

Public and Private Subnets on VPC

The first thing to consider when starting a custom VPC design is choosing a CIDR block for your custom VPC. For example, if you want to use different VPCs together, VPC CIDR blocks should not overlap. You cannot alter or modify your VPC’s CIDR block after creating it, so you should pick the CIDR block carefully.

An example VPC creation with a CIDR block Terraform template should be seen below:

resource aws_vpc create_vpc {          //creates a vpc
cidr_block = ${var.cidr_block_vpc}
enable_dns_support = true
enable_dns_hostnames = true
enable_classiclink = false
instance_tenancy = default
tags = {
    Name = ${var.vpc_name}
    }

Once you create a custom VPC, you should create subnets within this VPC. Subnets are very typical of what you would configure in your data center. When you launch a subnet, it’s within an availability zone. We ensure high availability by using different availability zones. While a public subnet has Internet access, a private subnet should not have public access directly.

Public and private subnets could be created with Terraform templates:

    resource  aws_subnet createsubnet {     //creates subnets
    count = length(var.cidr_block_subnet_pub)
    vpc_id = ${aws_vpc.create_vpc.id}
    cidr_block = ${var.cidr_block_subnet_pub[count.index]} //
    map_public_ip_on_launch =  true  //set false for private subnet

    availability_zone = ${var.availability_zone[count.index]}
    tags = {
        Name = ${var.pub_subnet_name[count.index]}
        }
 }

Note: On AWS Environment, a default VPC and public subnet are automatically created for each region in an AWS account. Default VPC should be removed if you want to build simple and secure data storage in your environment. Also, the number of VPCs per region in an account is limited to five and this is a soft limit. If you want all your VPC designed by your team, you should delete the default VPC.

Also see: Introduction to AWS Cloud Development Kit

5 Things Required For Internet Access on Public Subnet

1. A Public IP address
2. An Internet Gateway Attached to VPC
3. A Route Table to an Internet Gateway
4. Network Access Control List (NACL) for VPC
5. Security Groups

1. A Public IP address

When a public subnet resource wants Internet access, a Public IP address should be defined. In AWS environment, a Public IP address can be assigned in two ways:

2. An Internet Gateway Attached to VPC

Internet Gateway is a highly-scaled gateway managed by AWS. It performs 1:1 NAT and maps your private IP address to a public IP address.

We could create an Internet Gateway using Terraform scripts:

resource aws_internet_gateway internet_gw {   //creates an internet gw for public subnets
vpc_id = ${aws_vpc.create_vpc.id}
    tags = {
    Name = ${var.internet_gw_name}
    }
}

3. A Route Table to an Internet Gateway

As the name suggests, the routing table is used for routing your resources in VPC to your Internet Gateway. Public and private subnets have local targets for the private IP range.

 

A route table Terraform script could be seen below:

resource aws_route_table route_table {    //creates a route_table for public subnets
vpc_id = ${aws_vpc.create_vpc.id}
    route {
    cidr_block = ${var.route_table_cidr_block}
    gateway_id = ${aws_internet_gateway.internet_gw.id}
    }
    tags = {
        Name = ${var.route_table_name}
    }
}

4. Network Access Control List (NACL) for VPC

Network ACLs allow you to define the rules for the traffic flow. They are defined as subnet level. By default configurations, you will get default inbound and outbound traffic rules for the NACL. Default inbound and outbound rules allow all traffic.

For most clients, these default configurations are sufficient but, what if you want to fine-tune network ACL?

Inbound and outbound rules should be reconfigured for critical applications such as banking apps, and military applications.

5. Security Groups

The next security control is about using security groups. Security groups are tied to the Elastic Network Interface that is wrapped around your AWS resources. Security groups are applied to the instance EC2 level itself. An example of inbound security groups can be seen below:

This article may interest you: AWS IAM for Red and Blue Teams

An Example Scenario: Hosting a Web Application

A client wants to host a web application on a Web server in an AWS environment. The client needs a database server for user data. The database server should connect with a web application. This web application is related to banking operations, so network and server security is the priority.

What is the easiest and most secure way to configure this network and server environment?

The database server does not need any traffic coming from outside the VPC. It only needs traffic from the web server subnet. For these types of client requirements, we should:

• Create a VPC
• Create a private and public subnet
• Configure an Internet Gateway
• Configure a Route Gateway
• Create EC2 for web and database
• Configure Security Group rules
• Configure Network ACL rules

Network ACL Rules for Example Scenario

Inbound and outbound Network ACL rules for the private subnet can be seen below:

Security Group Rules for Example Scenario

Inbound security group rules for the web and database server can be seen below:

VPC Flow Logs

VPC Flow logs are used for metadata logging (source IP, destination IP, source port, destination port, etc.). You can capture all traffic or denied traffic. VPC Flow logs are applied to VPC, subnet, or Elastic Network Interface. If you enable VPC flow logs, configurations don’t impact throughput or latency.

VPC Flow logs could be used with different AWS services.

• Logs could be stored on S3 buckets and analyzed with AWS Athena.
• VPC flow logs could be integrated with AWS CloudWatch.
• For real-time anomaly detection, logs could be used with AWS Kinesis.

AWS VPC Traffic Mirroring

With VPC traffic monitoring, we investigate a little more than what we see in-network metadata. You can copy and filter network traffic from an elastic network interface of Amazon EC2 instances.

VPC Traffic Mirroring features could be used for:

• Detect Network & Security Anomalies
• Gain Operational Insights
• Compliance & Security Controls
• Troubleshoot Issues

You can use AWS VPC Traffic Mirroring with AWS Management Console, AWS CLI, AWS Traffic Mirroring API, or Query API.

Conclusion

AWS Virtual Private Cloud is a crucial component of AWS networking, offering benefits such as:

• Hosting applications,
• EC2 management,
• Back-up and disaster recovery,
• Hybrid cloud solutions, and much more.

With proper VPC configuration and management, organizations can ensure secure data and AWS resources. However, VPC security should be a top priority, and organizations must consider factors such as the CIDR block, public and private subnets, network access control lists, and security groups.

By following the best practices discussed in this blog post and utilizing AWS tools and services, organizations can design and implement a secure and efficient VPC that meets their specific needs.

We hope you found our article useful. Check out our Cloud Security services to stay secure!