Skip to main content
In this lesson, you’ll learn how to use AWS security groups and network ACLs (NACLs) to control traffic to and from resources in a VPC. We’ll start by launching an EC2 instance so you have a resource to attach a security group to, then examine common rules, differences between security groups and NACLs, and practical best practices. I launched an EC2 instance named “server1” using the default Amazon Linux AMI.
Screenshot of the AWS EC2 "Launch an instance" web console showing the Name and tags and Application/OS Images sections, with "server1" entered as the instance name. A right-hand summary lists the chosen AMI (Amazon Linux), instance type (t2.micro), security group and a "Launch instance" button.

​
During EC2 launch: networking & security group choices

When you reach the networking section of the EC2 launch wizard, choose the VPC and subnet you want. For security groups, you have two main options:
  • Use an existing security group you already created, or
  • Create a new security group during the launch and then modify it after launch.
The console often suggests creating a new security group and will pre-populate common inbound rules depending on the OS (for Linux instances it typically adds SSH/TCP/22). You can edit that rule immediately or add/replace rules later in the EC2 console.

​
Common security group rule examples

Security groups let you allow specific inbound traffic and control outbound traffic. Examples:
  • Allow SSH from a specific IP: Protocol TCP, Port 22, Source 203.0.113.5/32
  • Allow HTTP from anywhere: Protocol TCP, Port 80, Source 0.0.0.0/0
  • Allow HTTPS from anywhere: Protocol TCP, Port 443, Source 0.0.0.0/0
  • Custom app port: Protocol TCP, Port 8080, Source 10.0.1.0/24
Table of commonly used ports:
Do not leave SSH open to 0.0.0.0/0 unless you have an additional layer of protection (bastion host, VPN, or strict key-based access). Always restrict SSH to known IPs or CIDR ranges when possible.

​
Key conceptual differences: Security groups vs NACLs

  • Security groups are stateful: if you allow inbound traffic on a port, the return traffic is automatically allowed outbound without an explicit rule.
  • Security groups are applied to network interfaces (ENIs) and operate at the resource (instance) level.
  • Security group rules are allow-only: anything not explicitly allowed is implicitly denied.
  • NACLs are applied at the subnet level and are stateless: you must configure both inbound and outbound rules; return traffic is not automatically allowed. NACL rules can be explicit allow or deny and are evaluated by rule number order.
Compare security groups and NACLs:
Use security groups for fine-grained, resource-level access control. Use NACLs for subnet-wide, stateless controls or when you need explicit deny rules that apply to all instances in a subnet.

​
Best practices & next steps

  • Apply the principle of least privilege: open only required ports and restrict source IPs.
  • Reuse security groups for resources that need the same access patterns to simplify management.
  • Use separate security groups for management (SSH), web traffic (HTTP/HTTPS), and application ports. Attach multiple security groups to a single instance if needed.
  • Monitor and audit security group rules regularly; AWS Config and CloudTrail can help detect changes.
  • When you need to expose an instance to the internet, consider using a bastion host, AWS Systems Manager Session Manager, or a VPN instead of opening SSH to the world.
Quick post-launch actions you can perform in the EC2 console:
  1. Select the instance → Network interfaces → Security groups → Manage security groups.
  2. Edit inbound rules to add HTTP/HTTPS or to restrict SSH to a known IP.
  3. Add additional security groups to the instance if you want to combine rule sets.
Use these resources to deepen your knowledge of AWS networking, and remember to test security rules in a controlled environment before applying them to production.

Watch Video