Securing Your AWS Environment with Virtual Private Clouds (VPC)

Welcome to our deep dive into the critical role of Virtual Private Clouds (VPC) in securing AWS environments. As more organizations migrate to the cloud, understanding the foundational aspects of network security within AWS becomes crucial. The VPC isn’t just a component of AWS—it’s the foundation upon which companies build much of their cloud infrastructure.

Security in the cloud is complex and non-negotiable. Therefore, correctly designing your VPC is essential for establishing a robust security posture. It ensures that all other resources deployed in the cloud inherit a strong security foundation. In this post, we’ll guide you through the deployment of VPCs to protect your resources and ensure that your solutions are resilient and prepared to meet today’s demanding availability and security requirements, giving you the confidence that your AWS environment is secure.

What is a VPC?

An AWS Virtual Private Cloud (VPC) is a segregated network segment on the AWS platform where you have complete control over connectivity, routing, and security. It mirrors an on-premise network but with the added advantages of AWS’ global network and scalability.

Below is an example of a VPC that spans multiple Availability Zones (AZs) in an AWS Region.

NOTE: The above diagram shows the VPC connected to the public Internet with an Internet Gateway (IGW). By default, VPCs have no connections to any outside networks.

If you’re just starting with AWS, familiarize yourself with the AWS Global Infrastructure. Network Segmentation When designing secure VPCs in AWS, your first line of defence is network segmentation. Network segmentation is the process of dividing your larger VPC into multiple subnets. By creating individual subnets, you have more control over the routing of your network traffic.

Here’s a list of the types of subnets we commonly create for our customers:

• Public: A public subnet allows resources to be accessed directly from the public Internet (assuming they have a routable IP address). Typically, we try to deploy only AWS-managed services, such as NAT Gateways or Application Load Balancers (ALBs) in public subnets.
• Private: Private subnets allow resources, like EC2 instances, to access the Internet indirectly. Typically, they route traffic through something else, such as a NAT Gateway.
• Protected: The routing associated with a protected subnet ensures that traffic does not leave the VPC. Typically, we use protected subnets for resources like databases.
• VPN-only: Resources deployed in a VPC-only style subnet can access resources in your on-premise network but cannot access the public Internet directly.

While a VPC is a regional service, subnets are bound to a particular Availability Zone (AZ). While not directly related to security, you should spread subnets across multiple AZs in a single region. You can build more resilient solutions by spreading resources across multiple AZs in a single AWS Region.

Network Access Control Lists (NACLs)

NACLs are stateless firewalls, so you must consider both inbound and outbound rules. They are optional and operate at the subnet level. NACLs also allow you to create both Allow and Deny rules. Rules in a NACL are ordered and processed from lowest to highest number. As soon as the traffic matches a rule, the traffic stops being analyzed by the NACL.

Every VPC you create comes with a default NACL that allows all traffic. Any custom NACLs you create will deny all traffic by default, and you must add rules specific to your application.

Here’s an example of how you might use an NACL to add a layer of security to your public subnets.

NOTE: You should regularly review any NACLs you may have deployed to ensure that the rules remain appropriate. You can also remove any NACLs that are no longer required.

Security Groups

Security Groups are stateful firewalls that operate at the Elastic Network Interface (ENI) level. Security Groups differ from NACL in two key ways:

• Security Groups are stateful, which means they track connections. If traffic is allowed in, the response is allowed out. The same logic is applied to outbound traffic - if it’s allowed out, then the response is allowed in.
• Security Groups are required. If you deploy a resource in a VPC with an ENI, you must associate it with at least one security group.

Every VPC you create comes with a default security group. The default security group allows all outbound traffic and all inbound traffic from other resources assigned to the default security group. Any custom security groups you create allow all outbound and no inbound traffic.

NOTE: You should remove all the inbound and outbound rules from the default security group.

Here’s an example of how you might use security groups to protect a fleet of web servers.

NOTE: Like NACLs, you should regularly review your security group rules and remove any stale groups that are no longer required.

Host-based tooling

If you’re deploying EC2 instances in your VPC, you can still access the operating system and use OS-level protections.

You can install Intrusion Detection and Prevention tools and configure the OS-level firewall if required.

Logging

We review many AWS accounts. We frequently encounter the issue of insufficient network traffic logging. While there are several methods of logging traffic in your VPC, we’ll concentrate on VPC Flow Logs.

VPC Flow Logs provide a high-level view of the traffic flowing into (or out of) your VPC. When deploying flow logs, you can configure it for a single ENI, one or more subnets, or the entire VPC.

Flow logs support writing log data to S3 or CloudWatch Logs, but a single flow log cannot write to both destinations simultaneously. If you’d like to do this, create separate flow logs.

It’s important to note that flow logs do not provide deep packet inspection. Instead, they give a single line for every packet the flow log captures. I often refer to this as an ‘apache’-style log.

Flow logs are essential for two reasons:

1. They provide an excellent source of information for troubleshooting. We regularly use flow log data to verify NACL and Security Group configurations. You can also use flow logs to help verify your routing. Start by checking your routing if you have flow logs enabled but don’t see any traffic. If you see the traffic marked as REJECTED, look for a resolution at the NACL or Security Group level. If you see the traffic marked as ‘ACCEPTED,’ you likely have an OS-level issue.
2. Capturing and storing flow log data may also help you meet compliance requirements.

Here’s an example of a VPC Flow Log writing to an S3 bucket. The data is replicated using Same Region Replication (SRR) to a centralized bucket.

AWS Web Application Firewall (WAF)

If you’re building publicly available solutions, you should add a Web Application Firewall (WAF) to your solution. The AWS WAF is a fully managed solution that can be integrated with several AWS services. Once implemented and configured, the WAF can act as your first line of defence and block malicious traffic as close to its source as possible.

The WAF can be integrated with regional and global services and deployed quickly and effectively with a wide range of pre-built rules. If you decide to implement a WAF, don’t forget about logging!

Here’s an example of an AWS WAF deployment associated with an ALB.

Like NACLs and Security Groups, you should regularly review your WAF rules to ensure they are still applicable and plug any holes you may have. Deploying a WAF is easy, but maintaining it can be challenging.

AWS Network Firewall

The AWS Network Firewall is a fully managed service that can help establish perimeter security for your VPCs. It provides high availability and scalability to ensure that all traffic is inspected. The service provides a stateful firewall, web filtering, and intrusion prevention.

If you are running multiple VPCs and would like to centralize your security, consider the Network Firewall another layer of protection.

Encryption

Encryption is your last line of defence. You should encrypt data while it is in transit and at rest.

Werner Vogels, Amazon CTO, used the phrase “Dance like nobody is watching, encrypt like everyone is” in his keynote talk from the 2019 edition of AWS Re: Invent. Encryption is an often overlooked aspect of network security and is a crucial component of your layered approach to security. Make sure to leave adequate time before implementing a solution to understand the customer’s encryption requirements and work data protection into every deployment.