AWS VPC Security Best Practices

Amazon’s Virtual Private Cloud (VPC) is a virtual networking concept that allows AWS resources to communicate with each other over a private virtual network instead of the public internet. VPCs are similar to a traditional private local area network (LAN) in a data center, office, or home. AWS resources aligned with a VPC are assigned an IP address from a private network IP address range and, by default, can only communicate with other devices within that same VPC.

AWS sets up a default VPC within each region when you create your AWS account to help you get started. Unfortunately, the default options that provide quick and easy access can also be inherently insecure.

The AWS Shared Responsibility Model details how customers are responsible for the security of their applications and any data they store in the cloud, so it is essential to understand VPC security controls and how to implement them successfully. This article will review common AWS security mistakes — many of which result from default settings — and the AWS VPC security best practices that can help you avoid them.

An overview of the AWS Shared Responsibility Model (source).

Executive Summary: AWS VPC Security Best Practices Overview

Below is a list of common AWS VPC security mistakes. It includes information on what issues these mistakes can lead to and the corresponding best practice to prevent these issues. We’ll review each AWS VPC security best practice in more detail.

AWS VPC Security Best Practices

AWS VPC: A Crash Course

To understand AWS VPC security best practices, you need a baseline understanding of how VPCs work. Here are some key points to keep in mind before we proceed.

• A VPC is region-specific – a VPC cannot span different AWS regions. However, you can connect two or more VPCs together from the same or different AWS accounts and across regions using VPC Peering.
• A VPC is essentially a block of IPv4 addresses – VPCs are defined by a Classless Inter-Domain Routing (CIDR) block, for example, 10.0.0.0/16 or 192.168.0.0/24. It’s also possible to assign IPv6 addresses to a VPC – AWS will automatically assign you a /56 block of IPv6 addresses (you cannot chose your own), and you can then assign a /64 block to each subnet you create within that.
• VPC address blocks are broken into subnets – These blocks are then subdivided into subnets assigned to different availability zones within the region. The table below shows commonly used CIDR notation subnet blocks against the number of usable addresses. Note that AWS reserves the first four usable addresses in these subnets for their use

Additionally, there are many networking resources used within VPCs which can all play a role in achieving best practices. Here are the key terms to know to get the most out of this article:

• Route tables – A set of rules which determines how traffic is routed within and outside of the VPC.
• Internet gateways – A gateway that enables traffic to and from the internet. Any subnet associated with an internet gateway is considered a “public” subnet. A subnet with no internet gateway is considered a “private” subnet.
• NAT gateways – The primary purpose of Network Address Translation (NAT) is to allow instances in private subnets to access resources outside of the VPC. For example, NAT gateways can provide access to the internet.
• NACLs – Network Access Control Lists act as a means of controlling access in and out of a subnet. They can both allow and deny traffic.
• Security Groups – these control inbound and outbound access for AWS resources they are associated with.
• AWS PrivateLink – enables a private connection between resources in a VPC and other AWS services without requiring an internet connection.

Image shows VPC structure and resources in three Availability Zones (AZs)

AWS VPC Security Best Practices Explained

Now, let’s look at eight AWS VPC security best practices you can use to improve your cloud security posture.

Strategize and plan for growth before you implement your VPCs

You should plan your required subnets and their required capacity in advance. Then, account for future growth requirements. Once you have this information, you can choose your top-level CIDR range to cover all the required subnets.

Also, consider the use of Availability Zones (AZs) for high availability. Each AZ requires its own subnet. Even if you do not plan to use multiple AZs at first, that may change as you scale.  Organizations that expect to expand to multiple AZs should leave room in their top-level CIDR range for them.

Finally, think about the separation of resources. By default, without security controls like NACLs and Security groups, all AWS resources within a VPC can communicate with each other. Use separate VPCs to separate environments (for example, development from production), as well as separate clients.

Use private subnets

Unless an AWS resource must be accessed directly from the internet, place it in a private subnet (a subnet with no internet gateway attached). NAT gateways can be used to provide outbound internet access, and you can deploy multiple NAT gateways in multiple AZs for high availability.

This introduces the concept of “least privilege”, which states that a principal or resource should only be granted the rights or access that it requires. By placing non-internet enabled resources in a private subnet, an extra layer of security is introduced as internal resources can’t be accidentally exposed to the internet by a public IP address.

Additionally, consider using Elastic Load Balancers in public subnets to act as a security layer between your public presence and your applications. This is a recommended best practice but does have cost implications, so it may not be ideal for proof of concept and sandbox environments.

The three-tier infrastructure using private subnets to protect resources.

Avoid the use of the “default” VPC

Each region comes with a “default” VPC created by Amazon to help get people started using their platform. The “default” VPC consists of one IPv4 CIDR block (172.31.0.0/16) which provides up to 65,536 private IPv4 addresses, and then a “/20” subnet within each availability zone. An internet gateway is attached to the VPC, and default routes are set up for each subnet to route to this. Finally, any AWS resource created within these subnets is automatically assigned a public IP address.

As a result, any resources created will automatically be created in a public subnet, assigned a public IP address, and exposed to the internet. You can specifically request not to be given a public IP at creation. Although security group rules might prevent bad actors from accessing your resource, the risk of exposure is significantly higher than if the resource was created in a custom VPC under your control. As a result, AWS VPC security best practice dictates not to use this “default” VPC for anything other than sandbox environments.

Use AWS PrivateLink

Access to some AWS services is typically done via public access points (DNS names that resolve to public IP addresses). There is no option to only associate these with private IP addresses within a VPC. Examples of public access points are S3 buckets, DynamoDB tables, and SQS queues.

For resources that reside within a VPC, accessing these resources requires access to the internet via a public IP address assigned within a public subnet or via an alternative device such as a NAT gateway.

Image shows AWS PrivateLink communication from VPC to public AWS resources

AWS allows the creation of “gateway endpoints” which allow direct access to these public AWS resources without egressing via the internet. Using these endpoints to access these AWS services improves security. They can also reduce costs if an organization uses a NAT gateway for outbound internet traffic.

Use built-in security controls

AWS provides many built-in services for VPCs to help improve security. These include:

• Use multiple Security Groups to control traffic between AWS VPC resources. For example, use a security group for web-based services that allow HTTP / HTTPS traffic to ingress and database traffic to egress, and then a database security group that allows database traffic to ingress from the webservers group. This again follows the principle of “least privilege”, meaning resources can only access other resources on the required ports.                            💡 Pro-tip: Don’t use one “internal” security group and allow all traffic between internal resources. This lowers the overall security of your applications and data.

• Use Network Access Control Lists (NACLs) to control traffic within subnets. These stateless firewall devices allow and deny traffic based on IP address/subnet and network port, so they can be used to allow or block certain IP addresses.
• Use AWS Network Firewall to control local traffic between subnets and external traffic. For example, AWS Network Firewall can control exactly which resources can access a subnet dedicated to the database layer.
• If not using AWS Network Firewall, use VPC flow logs with CloudWatch for proactive monitoring. Integrate this into other AWS services such as Security Hub and GuardDuty to further enhance this by triggering proactive remediation steps.
• Use tools like AWS Config to enable logs and monitor for changes. This AWS VPC security best practice can alert organizations to events like the deployment of new internet gateways to ensure both outgoing internet access and incoming internet access can be controlled. Use IAM policies to deny the ability to create resources like new internet gateways.

VPC built-in security controls integrate into other AWS security services.

Perform a cost-benefit analysis

While many of these best practices should be implemented wherever possible, consider the cost of running devices such as NAT gateways, AWS Network Firewall, Elastic Load Balancers, Transit Gateways, and VPC gateways.

These services all have cost implications such as running costs, data egress/ingress charges, and ongoing maintenance and administration. Ensure you have taken these extra costs into account during your planning. For example, a test environment with no live data may not require the same security considerations as the production environment.

Deploy with automated tools

The use of Infrastructure as Code (IaC) tools (such as Terraform and CloudFormation) enables standardization and reliability. Base VPC code is usually identical for each environment. Therefore, security best practices can be “baked in” to each deployment with IaC, and security inspection and remediation tools can perform ongoing monitoring and compliance to ensure these remain in place.

Use an automated security inspection and remediation tool

A common issue when working in AWS is the misconfiguration of resources leading to security flaws and risk. This can be caused by using default settings when deploying a resource, accidentally choosing an incorrect option, or misunderstanding the consequences of a choice.

Automated IaC tools do not completely address this security challenge. In some cases, automation can amplify the issue. For example, if a setting is accidentally changed within the infrastructure as code that makes all S3 buckets publicly available.

To prevent this, a compliance solution that continually monitors and alerts for such things is highly recommended, especially one that offers automatic risk remediation. AWS offers built-in solutions such as AWS Config and  Security Hub.

Alternatively, a free and open-source tool like Paladin Cloud provides real-time visibility of any such misconfigurations and can auto-correct mistakes based on preset policies to avoid extended exposure.

The additional benefit of this open-source tool instead of an AWS service (other than the fact it’s free) is that it’s not AWS-specific. Paladin Cloud can holistically cover a “multi-cloud” environment, including other public clouds like Azure and GCP. It also offers an open, connector based architecture that allows enterprises to extend beyond the three cloud service providers into other cloud Software as a Service (SaaS) based enterprise systems such as threat intelligence and container scanning.

If you’d like to dive into the source code, check out Paladin Cloud’s GitHub repository.

Conclusion

At its core, a VPC is a virtual network – many of the best practices for creating and using a VPC are the same that apply to a physical network, such as developing the strategy and security architecture.

In summary, these steps can help you implement AWS VPC security best practices in your organization:

• Plan for future requirements to avoid complex workarounds or expensive re-designs and migrations later.
• Put in place reasonable security standards from the start to prevent potential compromises down the line, which could cause both financial and reputational damage.
• Use automation tools to guarantee deployments include these best practices.
• Enable logging and integrate these into other AWS or 3rd party solutions to proactively maintain them.