Network Access Control Lists (NACLs)


Authorization Controls in AWS
Amazon S3
Security Groups
Network Access Control Lists (NACLs)

This course looks at some of the different methods that AWS implements to authorize access within your AWS account, whether this is a user requiring access to an AWS service, or a network packet trying to reach its destination.

Learning Objectives

  • Learn how authorization is granted when working within your AWS account
  • Understand how S3 handles its own authorization mechanisms
  • Use network access control lists to authorize network packets to enter and leave different parts of your VPC
  • Learn how AWS security groups provide security at the protocol and port access level

Intended Audience

  • AWS Administrators
  • Security Engineers
  • Security Architects
  • Anyone looking to increase their knowledge of security and how authorization is governed within AWS


To get the most out of this course you should have a basic understanding of AWS IAM, Amazon S3, VPCs, and EC2, but this is not essential.


If you have been working with VPCs for any length of time then you would have come across AWS Network Access Control Lists, also known as NACLs, and these can be considered a way of authorizing network packets to enter and leave different parts of your VPC.  Operating the Network layer,  NACLs provide a rule-based security feature for permitting ingress and egress network traffic at the protocol and subnet level. In other words, ACLs monitor and filter traffic moving in and out of your subnet, either allowing or denying access dependent on rule permissions. 

NACLs can be attached to one or more subnets within your virtual private cloud. If you haven't created a custom NACL, then your subnets will automatically be associated with your VPC's default NACL, and in this instance, the default allows all traffic to flow in and out of the network, as opposed to denying it.

The rule set itself is very simple, and has both an inbound and outbound list of rules, and these rules are comprised of just six different fields; these being 

  1. Rule Number: ACL rules are read in ascending order, and as soon as a network packet is received, it reads each rule in ascending order until a match is found. For this reason, you'll want to carefully sequence your rules with an organized numbering system. I would suggest that you leave a gap of at least 50 between each of your rules to allow you to easily add new rules in sequence later if it becomes necessary. 
  2. Type: this dropdown list allows you to select from a list of common protocol types, including SSH, RDP, HTTP, and POP3. You can alternatively specify custom protocols, such as varieties of ICMP. 
  3. Protocol: based on your choice of ‘Type’, the protocol option might be grayed out. For custom rules like TCP and UDP, however, you should provide a value. 
  4. Port Range: If you create a custom rule, you'll need to specify the port range for the protocol to use. 
  5. Source: this can be a net or a subnet range, a specific IP address, or even left open to traffic from anywhere. 
  6. Allow/Deny: Each rule must include an action specifying whether to Allow or Deny the traffic that meets the parameters of the rule.

So NACLs are not used to authorize an identity as such, instead, they are used to effectively authorize the network packet itself to enter or leave a specific subnet. It's important to note that NACLs are stateless. Therefore, when creating your rules, you'll need to apply an outbound reply rule to permit responses to inbound requests.

About the Author
Learning Paths

Stuart has been working within the IT industry for two decades covering a huge range of topic areas and technologies, from data center and network infrastructure design, to cloud architecture and implementation.

To date, Stuart has created 150+ courses relating to Cloud reaching over 180,000 students, mostly within the AWS category and with a heavy focus on security and compliance.

Stuart is a member of the AWS Community Builders Program for his contributions towards AWS.

He is AWS certified and accredited in addition to being a published author covering topics across the AWS landscape.

In January 2016 Stuart was awarded ‘Expert of the Year Award 2015’ from Experts Exchange for his knowledge share within cloud services to the community.

Stuart enjoys writing about cloud technologies and you will find many of his articles within our blog pages.