CLB、ALB、NLB在VPC中的部署架构及NACL配置疑问咨询
Great question! Let’s break this down clearly, since understanding how AWS load balancers fit into your VPC architecture is critical for securing and scaling your applications.
First, let’s contrast with Classic Load Balancers (CLBs) to set context: CLBs are deployed directly inside your VPC subnets—they’re essentially EC2 instances managed by AWS. That means subnet-level Network Access Control Lists (NACLs) apply directly to CLB traffic, since NACLs enforce rules for all traffic entering or exiting a subnet.
Application Load Balancers (ALBs) are different. They’re fully managed by AWS and live in AWS’s own infrastructure, not your VPC subnets. When you create an ALB, you select "associated subnets" (one per AZ) — these subnets act as routing anchors, letting the ALB connect to your private subnets and workloads. But since the ALB itself isn’t inside your subnets, NACLs (which only operate at the subnet level) don’t apply to it. Instead, you use security groups to control ALB traffic—security groups are resource-level, so they can directly allow/deny traffic to and from the ALB.
Think of the ALB as sitting at the edge of your VPC, but outside your actual subnets. It’s a managed service that AWS runs, but it’s peered with your VPC via the associated subnets you select. The ALB gets public IPs (if it’s internet-facing) that route to AWS’s infrastructure, and it uses the associated subnets to reach your private resources (like EC2 instances in private subnets).
Key points:
- ALB is not an instance in your subnets
- Associated subnets are just for AZ-level routing and connectivity
- Security groups are the primary way to secure ALB traffic
Network Load Balancers (NLBs) share some similarities with ALBs but have a key difference related to placement:
- Like ALBs, NLB’s core processing happens in AWS’s managed infrastructure
- However, when you create an NLB, AWS provisions an Elastic Network Interface (ENI) in each of your associated subnets. This ENI has an IP address from your subnet’s CIDR range and acts as the traffic endpoint for the NLB.
Even though the ENI is in your subnet, most users still don’t rely on NACLs for NLB security. Why? Because NACLs are stateless (you have to explicitly allow return traffic) and more cumbersome to manage, while security groups (which apply to the NLB’s ENI) are stateful and easier to configure for most use cases.
Let’s use text-based diagrams to make this concrete:
ALB/NLB vs. CLB Architecture
ALB/NLB Setup
[Internet] ↓ [ALB/NLB (AWS Managed Infrastructure)] ↓ [Your VPC] ┌──────────────────────────────────────────────────────┐ │ Public Subnet 1 (ALB/NLB Associated Subnet) │ │ - ALB: No local resources, just routing anchor │ │ - NLB: Elastic Network Interface (ENI) resides here │ │ ┌────────────────────────────────────────────────┐ │ │ │ Security Group (Controls ALB/NLB Traffic) │ │ │ └────────────────────────────────────────────────┘ │ └──────────────────────────────────────────────────────┘ ↓ ┌──────────────────────────────────────────────────────┐ │ Private Subnet 1 (Your Workloads) │ │ - EC2 Instances / ECS Tasks / Lambda Functions │ │ - Security Group (Workload Traffic Control) │ │ - NACL (Applies to Subnet Inbound/Outbound) │ └──────────────────────────────────────────────────────┘
CLB Setup
[Internet] ↓ [Your VPC] ┌──────────────────────────────────────────────────────┐ │ Public Subnet 1 │ │ - CLB Instance Runs Directly Here │ │ - Security Group (CLB Traffic Control) │ │ - NACL (Applies to CLB & Subnet Traffic) │ └──────────────────────────────────────────────────────┘ ↓ ┌──────────────────────────────────────────────────────┐ │ Private Subnet 1 (Your Workloads) │ └──────────────────────────────────────────────────────┘
内容的提问来源于stack exchange,提问作者karthiks

