Understanding Amazon VPC Security with Subnets, NACL and Security Groups
7 min read
When it comes to securing your resources in the Amazon Virtual Private Cloud (VPC), two key concepts come into play: Network Access Control Lists (NACLs) and Subnets. Let's break down what they are and how they work together to create a secure environment for your cloud infrastructure.
What are Subnets in Amazon VPC?
A subnet is a section of a VPC in which you can group resources based on security or operational needs. Subnets are chunks of IP addresses in your VPC that allows you to group resources together. Subnets along with Networking Rules control whether resources are either publicly or privately available.
Public subnets contain resources that need to be accessible by the public, such as an online store’s website.
Private subnets contain resources that should be accessible only through your private network, such as a database that contains customers’ personal information and order histories.
In a VPC, subnets can communicate with each other. For example, you might have an application that involves Amazon EC2 instances in a public subnet communicating with databases that are located in a private subnet.
Network Traffic in a VPC
When a customer requests data from an application hosted in the AWS Cloud, this request is sent as a packet. A packet is a unit of data sent over the internet or a network.
It enters into a VPC through an internet gateway. Before a packet can enter into a subnet or exit from a subnet, it checks for permissions. These permissions indicate who sent the packet and how the packet is trying to communicate with the resources in a subnet.
The VPC component that checks packet permissions for subnets is a Network Access Control List (NACL).
Network Access Control List (NACL)
Packets are messages from the internet, and every packet that crosses the subnet boundaries gets checked against a network access control list or Network ACL. This check is to see if the packet has permission to either leave or enter the subnet, based on who it was sent from and how it's trying to communicate.
NACL controls inbound and outbound traffic at the subnet level within your VPC. It's a list of rules that specify what type of traffic (incoming or outgoing) is allowed to flow through, based on criteria like:
Protocol: TCP, UDP, ICMP, etc.
Port: Specific ports used by services (e.g., port 22 for SSH).
Source: IP address or subnet where the traffic originates from.
Destination: IP address or subnet where the traffic is directed to.
Each AWS account includes a default network ACL. When configuring your VPC, you can use your account’s default network ACL or create custom network ACLs.
By default, your account’s default network ACL allows all inbound and outbound traffic, but you can modify it by adding your own rules. For custom network ACLs, all inbound and outbound traffic is denied until you add rules to specify which traffic to allow. Additionally, all network ACLs have an explicit deny rule. This rule ensures that if a packet doesn’t match any of the other rules on the list, the packet is denied.
Stateless Packet Filtering
Network ACLs perform stateless packet filtering. They remember nothing and check packets that cross the subnet border each way: inbound and outbound. NACLs work using stateless packet filtering. This means for each incoming or outgoing packet, the NACL:
Inspects the packet header: It looks at the information contained in the header, like protocol, port, source, and destination.
Compares the packet to its rules: It checks if the packet matches any of the allow or deny rules in the NACL.
Allows or denies the packet: Based on the matching rule, the NACL decides whether to allow the packet to flow through or discard it.
Since NACLs don't remember past connections, you need separate rules for inbound and outbound traffic.
Security Groups
Network ACL only gets to evaluate a packet if it crosses a subnet boundary, in or out. It doesn't evaluate if a packet can reach a specific EC2 Instance or not. Sometimes you'll have multiple EC2 Instances in the same subnet. But they might have different rules around who can send the messages, and what port those messages are allowed to be sent to. So, you need instance-level network security as well. To solve instance-level access questions, AWS introduce Security Groups.
Every EC2 instance, when it's launched automatically comes the Security Group. By default, the Security Group does not allow any traffic into the instance at all. All ports are blocked, and all IP addresses sending packets are blocked. That's very secure but perhaps not very useful, if you want an instance to actually accept traffic from the outside say, a message from a Frontend instance or a message from the internet. So, obviously, you can modify the Security Group to accept a specific type of traffic. In the case of a website, you want web-based traffic or HTTPS to be accepted. But not other types of traffic say, an operating system or administration requests. With Security Groups, you allow specific traffic in, and by default, all traffic is allowed out.
A security group is a virtual firewall that controls inbound and outbound traffic for an Amazon EC2 instance. These rules specify:
Protocol: TCP, UDP, ICMP, etc.
Port: Specific ports used by services (e.g., port 22 for SSH).
Source: IP address or subnet where the traffic originates from.
Destination: IP address or subnet where the traffic is directed to.
Key Points about Security Groups
Mandatory: Every instance must be associated with a security group.
Default Rules: Security groups, by default, block all traffic. You need to explicitly define allowed inbound and outbound rules for your instances.
If you have multiple Amazon EC2 instances within a subnet, you can associate them with the same security group or use different security groups for each instance.
Stateful Packet Filtering
Security groups perform stateful packet filtering. They remember previous decisions made for incoming packets. When a packet response for that request returns to the instance, the security group remembers your previous request. The security group allows the response to proceed, regardless of inbound security group rules.
Difference between Security Group and Network ACL
| Feature | Security Group | Network ACL |
| Scope | Applies to individual EC2 instances | Applies to subnets within a VPC |
| Control | Controls Inbound and Outbound traffic of Instances | Controls Inbound and Outbound traffic of Subnet |
| Default Rule | Denies all inbound traffic | Denies all inbound traffic |
| Granularity | More granular control for individual instances | Provides broader control for all instances in a subnet |
| Stateful | Yes (return traffic is automatically allowed) | No (explicit rule needed for return traffic) |
| Use Case | Ideal for defining access to specific instances | Suitable for baseline security for all instances in a subnet |
Conclusion
By understanding and effectively utilizing Subnets, Network Access Control Lists (NACLs), and Security Groups, you can create a robust security posture for your VPC environment in AWS. Here's a quick recap:
Subnets: Segment your VPC into logical groupings based on security or functionality. Public subnets can host internet-facing resources, while private subnets hold sensitive data.
NACLs: Act as the first line of defence, controlling inbound and outbound traffic at the subnet level with stateless packet filtering. Define rules specifying allowed protocols, ports, source, and destination for traffic flow.
Security Groups: Function as firewalls at the instance level, providing granular control over inbound and outbound traffic for your EC2 instances. Leverage stateful packet filtering to allow return traffic based on established connections.
You can associate an instance with multiple security groups.
A subnet can only be associated with one NACL at a time.
NACLs provide a first layer of defence, while security groups offer a more granular second layer.
Remember, NACLs and Security Groups work together to provide a layered security approach. NACLs offer baseline protection at the subnet level, while Security Groups fine-tune access for individual instances. By implementing these security measures, you can ensure a safe and secure environment for your cloud resources in your AWS VPC.