AWS VPC Security: 19 Best Practices

In This Article

• What is AWS VPC?
• 19 AWS VPC Security Best Practices
• Choose Right VPC Type
• Choose Right CIDR Block
• Use Multiple Availability Zones
• Use AWS IAM to Manage Access to VPC resources
• Implement Multi-Factor Authentication (MFA)
• Use Multiple Environments
• Use Security Groups
• Use Network Access Control Lists
• Use VPC Endpoints
• Use VPC Peering or Transit Gateway
• Use Traffic Mirroring
• Use Private Subnets for Sensitive Resources
• Use NAT Gateway For Outbound Traffic
• Encrypt Data in Transit and at Rest
• Enable VPC Flow Logs
• Use Network Access Analyzer
• Use Proper VPC Resource Naming and Tagging
• Monitor Your VPC Resources
• Implement DDoS Protection
• Summary

What is AWS VPC?

AWS Virtual Private Cloud (VPC) allows you to define your own virtual network for launching AWS resources, such as EC2 instances, load balancers, RDS databases, NAT gateways, and more. A VPC essentially resembles a traditional network that you would manage in your data center but with all the scalability and high availability benefits of using the AWS cloud.

The main building blocks of an Amazon VPC are:

• VPC: Defines the virtual private network.
• Subnets: Segments the VPC into smaller sections.
• Internet Gateway: Enables internet access for public subnet.
• Route tables: Directs and routes traffic within the VPC.
• NACLs: Provide an additional layer of security at the subnet level.
• Security Groups: Virtual firewalls that control inbound and outbound traffic to instances.
• Elastic IP Addresses: Static public IP addresses.

19 AWS VPC Security Best Practices

Every AWS region comes with a default VPC that is automatically created for you. This provides a quick way to start using it immediately and deploy your VPC resources. While it may be tempting to use the default VPC, it’s often recommended to create a custom VPC specifically designed for your use case. This approach allows you to make more informed decisions about the configuration of your virtual network. Now, let’s take a look at the VPC security best practices that everyone should consider when setting up a new VPC or updating an existing VPC configuration.

Choose Right VPC Type

Before you start creating your VPC and its related resources, it’s important to first understand what type of VPC is best suited for your use case. These are main VPC types that cover most of the AWS cloud architectures:

• Public VPC: Contains subnets that have direct access to the internet via an Internet Gateway.

• Private VPC: Contains subnets without direct internet access.

• Hybrid VPC: Combines both public and private subnets, allowing for a mix of internet-facing and internal-only resources.

• Central Egress VPC: A specialized VPC used to centralize outbound internet traffic from multiple spoke VPCs, often using shared NAT Gateways.

• Shared Services VPC: Focuses on centralizing common services (such as Active Directory, DNS, logging, and monitoring) to be used by multiple VPCs, enhancing management, cost efficiency, and security. Often, a shared services VPC is connected to on-premises networks using site-to-site VPN connections to enable access to services and databases running there.

By understanding which VPC type or combination of types (in the case of using multiple VPCs) fits into your AWS network architecture, you will be able to perform the initial VPC setup more efficiently (e.g., by creating only the subnets that will actually be used by your application).

Choose Right CIDR Block

Another important task is to choose the right CIDR block . When setting up a VPC, you first define a CIDR block (size must be between /16 and /28) for the entire VPC and then create smaller CIDR blocks for each of the VPC subnets you will use in your virtual network.

There are several reasons why this is important for VPC security:

• To avoid overlaps with on-premises networks. For example, to set up a site-to-site VPN connection with your on-premises network, you should ensure that your VPC and subnet CIDR blocks do not conflict with those used in your on-premises network.
• Preventing IP exhaustions. Choose wisely the CIDR block for your subnets. Analyze the approximate number of your potential AWS resources (ex. EC2 instances, VPC interface endpoints, Lambda functions etc.) that you plan to deploy to specific subnets and choose the CIDR block accordingly.
• Simplifying security groups and NACL management. By separating CIDR blocks (= specific subnet) based on purpose (e.g., one block for RDS databases, one for EC2 instances, and one for Lambdas), you can simplify the use of security groups and NACLs within the VPC.

Use Multiple Availability Zones

An availability zone in AWS refers to an isolated location, which is a logical grouping of one or more data centers that reside in a specific part of the world (referred to as a region). Each region in AWS has two or more availability zones that you can use.

Utilizing multiple availability zones in a VPC enhances high availability, scalability, disaster recovery, and compliance. It ensures that your applications remain available even if one of the availability zones becomes unavailable.

To start using a specific availability zone in your VPC, create a new subnet and choose the availability zone where this subnet should be located. After that, you can begin deploying resources like EC2 instances in that specific subnet, and behind the scenes, these instances will be deployed in the corresponding availability zone.

Use AWS IAM to Manage Access to VPC resources

AWS Identity and Access Management (AWS IAM) is used to control and manage access to your AWS resources. Regardless of whether you use IAM roles (e.g., cross-account roles, service roles), users, or identity federation for accessing and deploying VPC resources in the AWS cloud, you should always create least-privilege IAM policies. By limiting access rights to the minimum necessary to perform specific tasks, you improve the overall security posture of your VPC.

AWS offers managed VPC policies that provide permissions for several common use cases (e.g., granting full access to VPC resources, granting read-only access to VPC resources) that you can assign to your users, roles, or identities. These policies provide a good starting point for creating more customized VPC policies later on.

Implement Multi-Factor Authentication (MFA)

Whether you are using the AWS console or assuming an IAM role via the AWS Command Line Interface (CLI) to access and manage VPC resources, MFA should always be enabled by default. This adds an additional layer of security and ensures that you are indeed the person authorized to access these resources.

Use Multiple Environments

Nowadays, most of our AWS infrastructure, including VPC-related components, is managed as infrastructure as code (IaC) using various tools like CDK, Terraform, and Serverless Framework . This allows us to easily deploy consistent cloud infrastructures that can be used for development, quality assurance, staging, pre-production, and production environments.

To improve VPC security (e.g., reduce the attack surface, prevent cross-environment access, limit user access, and prevent accidental data compromise), it’s important to separate these environments by having fully isolated VPC setups for each one. It’s often recommended to have a separate AWS account for each environment your application requires (e.g., one account for development, one for pre-production, and one for production).

Use Security Groups

AWS security groups play an important role in VPC security and should be considered the primary approach for controlling inbound and outbound traffic to your VPCs.

Use Network Access Control Lists

Similar to security groups, network access control lists (NACLs) control inbound and outbound traffic to your VPCs at the subnet level. NACLs are primarily used when there is a need to enable or disable specific traffic (e.g., SSH on port 22 or blacklist a specific IP address) for a particular subnet/s.

Use VPC Endpoints

VPC endpoints enable you to connect privately to AWS services (e.g., S3, DynamoDB, EC2, CloudWatch, etc.).

How does this improve VPC security? By using VPC endpoints, communication with other AWS services occurs over private IP addresses, ensuring that traffic between your Amazon VPC and the service remains within the AWS network and doesn’t leave it.

Use VPC Peering or Transit Gateway

There can be different VPC network architectures (e.g., central egress VPC, shared services VPC) where there is a requirement to route traffic from one VPC to other VPCs. To route traffic privately between two VPCs, thereby improving overall VPC security, we can use one of the following AWS services:

• VPC peering connections
• Transit gateway and VPC attachments

Use Private Subnets for Sensitive Resources

Depending on the type of application you are building, there is a solid chance it will consist of databases (like RDS, Aurora), application and business logic compute resources (like EC2, ECS), elastic file storage (EFS), etc. It’s a VPC security best practice to deploy these resources in private subnets without public IP addresses so that they are not directly accessible from the public internet.

If your application needs to be accessible publicly then use a public ALB or NLB to route traffic to the EC2 instances that are deployed in private subnets and do not have public IP addresses.

Use NAT Gateway For Outbound Traffic

There are various use cases where your deployed resources (such as EC2 instances) in private subnets still require outbound internet access:

• To install and update software.
• To integrate with external third-party services. For example, sending application logs to enhance monitoring and alerting or performing security scans by connecting to external services.
• To download dependencies and libraries needed for the application to function, such as pulling container images from public container registries like Docker Hub.

You can use a NAT gateway to allow instances in private subnets to connect to the public internet while preventing unsolicited inbound connections.

Use Traffic Mirroring

You can use traffic mirroring to enhance overall VPC network security by copying network traffic from an elastic network interface to your security and monitoring appliances. This approach allows for deep packet inspection, real-time threat detection, and non-intrusive performance monitoring.

While this provides many VPC security-related benefits, be aware that there are additional costs associated with using this functionality, which can significantly increase depending on your AWS network architecture.

Encrypt Data in Transit and at Rest

Data encryption in transit and at rest is now the default standard. Most VPC-related resources (such as EBS volumes and RDS databases) have data encryption at rest enabled by default, but it should still be on everyone’s checklist when designing secure VPC environments.

Use Transport Layer Security (TLS) to encrypt data in transit when communicating with VPC resources.

Enable VPC Flow Logs

Amazon VPC flow logs help capture information about the traffic flowing into and out of network interfaces in your VPC.

One flow log record contains:
2 123456789012 eni-abc123de 192.168.1.10 203.0.113.1 443 49152 6 10 840 1622476800 1622476860 ACCEPT OK

• Version: 2 - The version of the VPC Flow Logs format.
• Account ID: 123456789012 - The AWS account ID where the flow log was created.
• Interface ID: eni-abc123de - The ID of the network interface for which the traffic is recorded.
• Source Address: 192.168.1.10 - The source IP address of the traffic.
• Destination Address: 203.0.113.1 - The destination IP address of the traffic.
• Source Port: 443 - The source port of the traffic.
• Destination Port: 49152 - The destination port of the traffic.
• Protocol: 6 - The protocol number (6 for TCP).
• Packets: 10 - The number of packets transferred during the flow.
• Bytes: 840 - The number of bytes transferred during the flow.
• Start Time: 1622476800 - The start time of the flow (Unix timestamp).
• End Time: 1622476860 - The end time of the flow (Unix timestamp).
• Action: ACCEPT - Indicates whether the traffic was accepted or rejected.
• Log Status: OK - The status of the flow log record.

Whenever you use Amazon VPC for your back-end services, consider enabling Flow Logs. This will help identify and respond to potential security threats, ensuring a more secure VPC environment.

Use Network Access Analyzer

Network Access Analyzer helps identify unintended network access to your VPC resources. This is especially useful in complex AWS network architectures that include VPC peering connections, transit gateways, VPN connections, or VPC endpoints. AWS Network Access Analyzer enhances VPC security by providing visibility into network paths how your instances can be accessed.

Use Proper VPC Resource Naming and Tagging

Using a consistent and descriptive naming convention for VPC resources (ex. {env}-{purpose}-vpc) helps in managing and identifying resources easily. It improves clarity, especially in complex environments with multiple VPCs and resources.

In addition to consistent naming, you should use tags to enhance VPC security by improving visibility and organization. Example tags:

• Environment / Stage: Environment=Production, Stage=Development
• Role: Role=CentralEgress, Role=Spoke
• Owner: Owner=SecurityTeam
• Project: Project=ERP

Monitor Your VPC Resources

Use AWS Config to monitor configuration changes in your AWS infrastructure. This provides visibility into changes in your AWS architecture and can be highly beneficial for security, audit, and compliance teams. Additionally, you can use AWS Config rules to continuously evaluate whether your VPC resources comply with specific security standards like AWS Foundational Security Best Practices v1.0.0 (FSBP) or the CIS AWS Foundations Benchmark.

You should also use AWS CloudTrail to track user activity and API usage when accessing VPC-related resources. This will give your security team a clear understanding of who accessed what (e.g., a user listing all VPCs in a specific region or creating an EC2 instance).

Implement DDoS Protection

Use AWS Shield and AWS WAF to protect your applications from Distributed Denial of Service (DDoS) attacks and other web application threats.

AWS Shield Standard is enabled by default for all AWS customers at no additional cost. It provides automatic protection against the most common and frequently occurring network and transport layer DDoS attacks. There is also a paid tier that offers more advanced functionality to enhance the security of your application.

Additionally, I recommend using AWS WAF rate-based rules to limit the number of requests from a single IP address, helping to mitigate DDoS attacks that aim to overwhelm your application with traffic. I would apply these rules to any publicly available application or endpoint.

Summary

There is no magic button to turn it on and have your VPC and its resources automatically secured. Improving the cloud security posture for your VPC is a continuous journey for your development and security teams. This process consists of many smaller and larger tasks and checks that will take time to efficiently incorporate into your applications and services.

How should I start? Take this list of 19 VPC security best practices to your development and security teams—schedule a brainstorming session, go through this list, and evaluate which practices should be enabled (if not already) for your use case, implementing them one by one.