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 for 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.
5 Things Required For Internet Access on Public Subnet
When a public subnet resource wants Internet access, a Public IP address should be defined. On AWS environment, a Public IP address can be assigned in two ways:

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}
}
}
As the name suggests, the routing table is used for routing your resources in VPC to your Internet Gateway. Public and private subnet 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}
}
}
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, military applications.

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 instance EC2 level itself. An example of inbound security groups can be seen below:
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.AWS Athena.
- VPC flow logs could be integrated withAWS 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.
We hope you found our article useful. Check out our Cloud Security services to stay secure!