Skip to main content
This walkthrough explains the layered network security that protects a simple web application running behind an Application Load Balancer (ALB) on AWS. You’ll see how the ALB, security groups, network ACLs (NACLs), and AWS WAF work together, what each controls, and where to inspect these settings in the AWS Console. Current application behavior: an internet-facing ALB distributes HTTP traffic to a target group containing two EC2 instances. Each instance serves a simple page that identifies itself.
A browser screenshot showing a simple web page that reads "Hi from ip-172-31-5-121.us-east-2.compute.internal." The address bar shows an AWS load balancer hostname and the connection is marked "Not secure."

​
Application Load Balancer (ALB)

  • The ALB is the public entry point. It’s configured with an internet-facing scheme and listens on HTTP port 80.
  • When a client request arrives at the ALB listener (HTTP :80), the ALB forwards the request to the target group that contains the EC2 instances.
  • Because the ALB terminates incoming requests and forwards them to targets, it’s the natural place to attach application-layer protections (for example, AWS WAF).

​
Security group for the ALB

  • The ALB has a security group that explicitly allows inbound HTTP (TCP) on port 80 from the internet (0.0.0.0/0), which makes the ALB reachable from public clients.
  • Keep the ALB security group minimal: only the ports/protocols and sources required for public access.
A screenshot of the AWS EC2 Security Groups console showing the "Inbound rules" tab for a security group. It lists one inbound rule allowing HTTP (TCP) over IPv4.

​
EC2 instance security group

  • EC2 instances use their own security group (EC2-SG). Rather than allowing HTTP from 0.0.0.0/0, EC2-SG allows HTTP only from the ALB’s security group (the ALB SG ID is the source).
  • This pattern ensures instances accept traffic only when routed through the ALB and prevents direct internet access to instance ports.
A screenshot of the AWS EC2 "Security Groups" console showing a list of three security groups with their IDs, names (EC2-SG, LB-SG, default) and VPC links. The page header shows the AWS region and a "Create security group" button.

​
Network ACLs (NACLs)

  • ALB nodes are deployed across multiple Availability Zones; each node resides in a subnet. NACLs are attached to subnets and therefore filter traffic entering and leaving those subnets.
  • NACLs are stateless: inbound and outbound rules are evaluated independently. Any allowed inbound traffic must have a corresponding outbound rule to permit the return traffic.
  • NACLs operate at the subnet level and act as a coarse-grained filter, while security groups are resource-level and stateful.
To determine which NACLs apply to the ALB, open the load balancer’s network mappings and inspect the subnets the ALB uses—those subnets are associated with specific NACLs.
A screenshot of the AWS VPC console showing the "Network ACLs" page. It highlights a network ACL (acl-0b69917eeb84b15b2) that is associated with three subnets, with subnet IDs listed in a popup.
Inspect the NACL rules for the selected ACL. The example below shows an explicit allow for all traffic from 0.0.0.0/0 and the implicit deny rule that applies when no allow exists. NACL rules are evaluated by rule number order; the explicit allow demonstrates typical rule ordering versus the default deny behavior.
A screenshot of the AWS VPC console on the Network ACLs page showing the Inbound rules tab. It lists two rules for "All traffic" with rule 100 allowing 0.0.0.0/0 and a fallback rule denying all.

​
AWS WAF (Web Application Firewall)

  • AWS WAF operates at Layer 7 and inspects HTTP/HTTPS requests. It can block, allow, or count requests based on conditions you define (IP sets, rate-based rules, SQL injection/XSS protections, geo-blocking, etc.).
  • You can associate a Web ACL with an ALB to add application-layer protections that complement security groups and NACLs.
  • WAF is ideal for protecting the application from common web threats and bot traffic; SGs/NACLs continue to manage network-level access.

​
Quick reference and where to look in the Console

  • ALB: EC2 > Load Balancers — check listeners, target groups, and network mappings.
  • ALB security group: EC2 > Security Groups — inspect inbound rules for port 80/443.
  • EC2 instance SG: EC2 > Security Groups — confirm the source is the ALB SG.
  • NACLs: VPC > Network ACLs — view associated subnets and rule order.
  • WAF: AWS WAF & Shield > Web ACLs — associate with ALB for Layer 7 rules.
Useful references:
Layered controls at a glance (good for documentation and audits):For example, make EC2 instances accept HTTP only from the ALB security group to prevent direct public access.
Best-practice warnings:
  • Don’t open instance ports to 0.0.0.0/0. Use the ALB as the public entry point and configure EC2 security groups to accept traffic only from the ALB SG.
  • Remember NACLs are stateless: if inbound is allowed, ensure outbound is explicitly allowed too.
  • Verify NACL and SG rules after changes to avoid accidentally blocking ALB-to-instance traffic.
  • Confirm ALB is internet-facing only where needed and only required listeners are open (HTTP/HTTPS).
  • Set ALB SG to allow only necessary client-facing ports.
  • Configure EC2 SG to allow traffic solely from the ALB SG (use SG ID as source).
  • Review NACLs on ALB subnets to ensure they don’t unintentionally deny or over-permit traffic.
  • Consider adding an AWS WAF Web ACL on the ALB for application-layer protections (rate limiting, known-bad IPs, common attack signatures).
That covers the layered approach for securing this ALB-backed application: ALB as the public entry point, ALB security group allowing public HTTP access, EC2 security groups permitting traffic only from the ALB, subnet-level NACLs for coarse filtering, and an optional WAF for additional Layer 7 protection.

Watch Video