Tags Archives: nacls

AWS Security Groups (SGs) and Network Access Control Lists (NACLs) – What’s the Difference?

Security Groups or SGs are an essential part of the task of securing your incoming and outgoing network traffic within a VPC.


However, SGs also have limitations and shouldn’t be thought of as the only line of defence.


AWS provides a range of additional networking security tools, such as Network ACLs, AWS Network Firewall, DNS Firewall, AWS WAF (Web Access Firewall), AWS Shield, as well as monitoring and compliance tools like AWS Security Hub, GuardDuty, and Network Access Analyzer.


Quick Overview of the Main Features of AWS Security Groups


Security groups are access control lists (ACLs) that allow network traffic inbound and outbound from an Elastic Network Interface (ENI). SGs serve as a basic firewall system for all AWS resources to which they are attached.


Note for exam: Security groups implicitly DENY traffic, they only have “allow” rules, and not “deny” rules.


Thus the absence of an “allow” rule will implicitly DENY access


Security group rules are “stateful” – meaning that if a server can communicate outbound to a service, the return traffic to that server will also be automatically permitted.


This behaviour contrasts with Network ACLs which are “stateless”.


Security groups are VPC-specific and thus also region-specific – which means they can only be used within the VPC where they are created.


Sole exception to this is where there is a peering connection to another VPC, in which case they can be referred to in the peered VPC.


Security groups can be applied to multiple instances within a VPC, and can be valid across subnets within that VPC.


When a VPC is first created, a “default” security group is automatically created by AWS for it and within it.


This default SG has no inbound rules and just a single outbound rule, which allows all traffic to any destination (


If a new resource is launched within the VPC without association to an SG then it will automatically be assigned to this “default” SG.


By default, a new security group attached to a group of instances does not allow these instances to communicate with each other. For this to be possible you need to create new inbound and outbound rules, and then define the source and destination as the security group itself.


Note that SGs are allocated to the actual Elastic Network Interface device (ENI) which is attached to an EC2 instance, as opposed to the EC2 / RDS instance itself.


You can assign up to five SGs to each Elastic Network Interface. Thus an EC2 instance with multiple ENIs could actually therefore have more than five security groups assigned to it, though this is not best practice.



Best Practices for Deploying Security Groups


Avoid using the “default” security group


The “default” security group should not be used for active AWS resources. The reason is that new AWS resources could be inadvertently assigned to it and so be permitted undesired access to your resources. Since you cannot delete the default SG, you should instead delete all inbound and outbound rules in the “default” SG instead.


Then create new SGs for your AWS resources. Then ensure any new AWS resources are assigned to the correct SGs you created.


Keep the number of your created SGs to a minimum


The AWS EC2 Launch Wizard will encourage you to create a new security group for each EC2 instance you create. However, the problem with that is that it can lead to the creation of too many security groups, which then become hard to manage and track.


Instead of relying on the Launch Wizard, you should decide on a strategy for creating security groups based on your actual application and service access needs and then assign them in accordance with your requirements.


Restrict, restrict, restrict


This means you should always strive to ensure all new security groups apply the principle of least privilege. this means for example:


Don’t open inbound traffic for the whole VPC CIDR-IP or subnet range unless absolutely necessary.


Also avoid allowing all IP addresses ( unless absolutely necessary.


Restrict outbound traffic where possible e.g. do not open all ports to the internet, for example, only open HTTP/HTTPS to allow internet webaccess.


If allowing a specific service, only open the ports and protocols required for that service. For example, for DNS, you open port 53 for TCP and UDP, and only to the external DNS provider – for example for Google DNS that would be


Open relevant ports and protocols to other security groups, rather than for IP addresses/subnets. This is because AWS recommends using dynamic IP addresses.


Develop a security group strategy


Set a strategy for creating and using security groups based on your application and service needs. Then use AWS tools to enforce this strategy.


Some examples of strategy options:


Decide the best way to set up your security groups.


For example: deploy one security group per service type, such as “mysql-db”, “web”, “ssh-access”,“active-directory”. Then assign the required inbound and outbound ports for that service


Define one security group per application type, such as “web-servers”, “file-servers”, or “db-servers”. Then assign the ports for that application or service.


Define one security group per operating system, such as “linux” or “windows”, then assign the basic ports required for that OS.

Define one or two default SGs to cover access requirements common to all or most of the servers in the VPC. This minimises the total number of security groups required.


if all instances need outbound using HTTP / HTTPS to access the web
if all instances need an inbound port for eg a monitoring system.

Try to use a naming strategy which provides clarity to help avoid confusion if you manage multiple VPCs. If each VPC has a security group called for example “web-servers”, then it can quickly become difficult to keep track of which is which.


AWS Firewall Manager can help create security group policies and associate them with accounts and resources. It can also be used to monitor and manage the policies for all linked accounts.


AWS Security Hub works with CloudTrail and CloudWatch to monitor and trigger alarms based on security best practice alerts.


One indication to watch out for is the rate of change within SG rules – such as ports being opened and closed again within a very short time period.


AWS Config can be used to ensure compliance with defined best practices. Config Rules can be created to check and alert for non-compliance, and then perform automated remediation steps.


For example, checking for unrestricted security group rules and ensuring the “default” AWS SG has no inbound or outbound rules set.






An EC2 security group plays the role of a firewall. By default, a security group will deny all incoming traffic while permitting all outgoing traffic



You define group behavior by setting policy rules that will either block or allow specified traffic types.




You can update your security group rules and/or apply them to multiple instances.




Security groups control traffic at the instance level.



However, AWS also provides you with network access control lists (NACLs) that are associated with entire subnets rather than individual instances.




Security Groups Simplified


Security Groups are used to control access (SSH, HTTP, RDP, etc.) with EC2. They act as a virtual firewall for your instances to control inbound and outbound traffic.



When you launch an instance in a VPC, you can assign up to five security groups to the instance. 



Note that security groups act at the instance level, not the subnet level.





Security groups filters IP & Port according to rules. 



This is the basic firewalling system of AWS, this can be modified…



Security Group INBOUND allows inbound port 22 traffic from your computer




Security Group OUTBOUND allows outbound ANY PORT to ANY IP



In other words,



by default in AWS:


All INBOUND traffic is blocked by default
All OUTBOUND traffic is authorized by default





Security groups can be attached to MULTIPLE EC2 instances, not just assigned to a single EC2.





An instance can also belong to multiple security groups.



They are set for a specific region or VPC combination. So they are NOT cross-regional.



Security groups operate OUTSIDE the EC2 not inside it – so if the traffic is already blocked then the EC2 won’t see it. So it is not an “app” running on your EC2 but a service running outside of it.



Best practice is to create a separate security group just for SSH access.




TIP for error-debugging:



if your application gives a “time out” error, then it is not accessible and this means it is most likely a security group issue.



if your application gives a “connection refused” error, then it is an application-internal error or the application is not running.





Security Groups Key Details



Security groups control inbound and outbound traffic for your instances (they act as a Firewall for EC2 Instances) while NACLs control inbound and outbound traffic for your subnets (they act as a Firewall for Subnets). Security Groups usually control the list of ports that are allowed to be used by your EC2 instances and the NACLs control which network or list of IP addresses can connect to your whole VPC.



Every time you make a change to a security group, that change occurs immediately.



Whenever you create an inbound rule, an outbound rule is created immediately. This is because Security Groups are stateful. This means that when you create an ingress rule for a security group, a corresponding egress rule is created to match it. This is in contrast with NACLs which are stateless and require manual intervention for creating both inbound and outbound rules.



Security Group rules are based on ALLOWs and there is no concept of DENY when in comes to Security Groups. This means you cannot explicitly deny or blacklist specific ports via Security Groups, you can only implicitly deny them by excluding them in your ALLOWs list.



Because of the above detail, everything is blocked by default. You must intentionally allow access to certain ports.



Security groups are specific to a single VPC, so you can’t share a Security Group between multiple VPCs. However, you can copy a Security Group to create a new Security Group with the same rules in another VPC for the same AWS Account.



Security Groups are regional and CAN span AZs, but can’t be cross-regional.



Outbound rules exist if you need to connect your server to a different service such as an API endpoint or a DB backend. You need to enable the ALLOW rule for the correct port though so that traffic can leave EC2 and enter the other AWS service.



You can attach multiple security groups to one EC2 instance and you can have multiple EC2 instances under the umbrella of one security group.



You can specify the source of your security group (basically who is allowed to bypass the virtual firewall) to be a single /32 IP address, an IP range, or even a separate security group.



You cannot block specific IP addresses with Security Groups (use NACLs instead).



You can increase your Security Group limit by submitting a request to AWS



Reachability Analyzer


The Reachability Analyzer is an AWS web-dashboard tool you can deploy to check network reachability from a source and to a destination via a specifically named port. There is a cost incurred of currently 10c per check.


This is very useful in debugging any SG or NACL traffic problems.













Continue Reading

AWS NACLs – Network Access Control Lists

The AWS Network Access Control List (NACL) is a security layer for your VPC that acts as a firewall for controlling traffic in and out of one or more subnets.


NACLs vs. Security Groups


NACLs and Security Groups (SGs) both have similar purposes. They filter traffic according to rules, to ensure only authorized traffic is routed to its destination.




NACLs are used to control access to network resources. They reside on subnets and evaluate traffic based on defined rules which you set, and use these rules to determine whether or not traffic should be allowed to pass through the subnet.


NACLs are “STATELESS” which means they require you to create separate rules for BOTH INCOMING AND OUTGOING traffic. Just because a particular data stream is allowed into the subnet, this doesn’t mean it will automatically be allowed out.


NACLs are processed in numerical ie serial order. Thus if you want traffic to be permitted both in and out of a subnet, you have to set network access rules for both directions.


NACLs are automatically applied to everything within that subnet, so there is no need to apply NACLs to individual resources as they are created. This means less network admin overhead for managers.



Security Groups


Security Groups apply to EC2 instances and operate like a host-based firewall. As with NACLs they apply rules that determine whether traffic to or from a given EC2 instance should be allowed.


This provides for more finely tuned traffic control for resources that have specific network traffic requirements.


Security Groups unlike NACLs are stateful; this means that any traffic that is allowed into your EC2 instance will automatically be allowed out again and vice versa.


All security groups rules are evaluated according to a default “deny everything unless allowed” policy. This means that if no ALLOW exists, then traffic will be blocked.


Security Groups must be applied at the time of resource creation and have to be explicitly configured.



Similarities and Differences Between NACLs and Security Groups


Both NACLs and Security Groups utilize rules that prevent unwanted traffic from accessing your network. The rules themselves also look similar. But a notable difference between them is that NACLs allow for DENY rules to be explicitly created.


It is important to ensure that your security group rules and your NACLs are not working against one another. Thus it is important to understand when it is best to use NACLs and when it is best to use SGs.


The major difference between them is in where they are applied. NACLs are applied at the SUBNET level, while Security Groups are applied at the EC2 instance level.


NACLs protect the network while Security Groups protect the resource.


As NACLs are higher up in the architecture, they apply to a much wider set of resources. Any NACL rule you create will therefore impact the operation of every resource located within the subnet.


Security Groups on the other hand only affect the EC2 instances to which they are attached.



When to Use NACLs


NACLs are best used sparingly. Because NACLs apply to the full set of resources in a subnet, their impact is wide and substantial.


NACLs are most effective for filtering external traffic to internal subnets. They can also be useful for applying traffic controls between the subnets themselves.




Best Practices for Using NACLs


Use NACLs sparingly and deploy them based on the function of the subnet they are attached to


Keep NACLs simple and only use them to deny traffic if possible


Restrict who can create or modify NACLs through IAM rules


Build your Security Group rules into your NACLs


Ensure that your inbound and outbound rules make sense ie that they match


When numbering your NACLs, be sure to leave room for future rules


Audit your rules frequently and delete any rules that are unused or redundant


Deploy NACLs to also control your subnet-to-subnet traffic and ensure logical separation between them



NACLS – Essential Points To Remember For Exam


One NACL per subnet


New subnets always get assigned to a default NACL – this ALLOWS all traffic in and out by default!


BUT – newly created NACLS DENY by default! – if last rule is an * (asterisk)


Rules are numbered from 1 to 32766  – and LOWEST  numbers have the HIGHEST priority!


Number your rules in 100s steps for ease of admin.


So if a rule numbered 100 allows and another rule numbered 200 denies for same traffic, then the rule nunber 100 will win – ie the traffic will be allowed. 


Remember the basic essential differences between NACLs and SGs





operate at EC2 instance level


support allow rules only


are STATEFUL – which means return traffic is ALWAYS automatically allowed, regardless of rules




Applies to an EC2 instance when specified





operate at SUBNET level


support both ALLOW AND DENY rules


are STATELESS – which means return traffic has to be explicitly allowed by setting appropriate NACL rules – using ephemeral ports


Rules are evaluated in order from LOWEST to HIGHEST, lowest first match wins


Automatically apply to all EC2s in the respective subnet.



Reachability Analyzer


The Reachability Analyzer is an AWS web-dashboard tool you can deploy to check network reachability from a source and to a destination via a specifically named port. There is a cost incurred of currently 10c per check.


This is very useful in debugging any SG or NACL traffic problems.





Continue Reading