AWS Load Balancer Architecture Diagrams: ALB vs NLB Examples
Every non-trivial AWS architecture diagram has a load balancer somewhere in it, and it is usually the box that reviewers argue about: is it an ALB or an NLB, does it span the right Availability Zones, where are the target groups, and why is CloudFront pointing straight at EC2? This guide walks through four reference load balancing architectures — ALB to ECS/EC2 across multiple AZs, NLB for TCP and gRPC traffic, ALB with Lambda targets, and CloudFront in front of an ALB — plus the decision rules for choosing between ALB, NLB, and Gateway Load Balancer. For each pattern you get concrete drawing guidance (AZ boundaries, target groups, health checks) and a plain-English prompt you can use to generate the diagram automatically.
ALB vs NLB vs Gateway Load Balancer: which one goes in your diagram?
Elastic Load Balancing is one family with three current members, and picking the wrong one is the most common error in AWS ELB diagrams. The Application Load Balancer operates at layer 7: it terminates HTTP/HTTPS, routes on host header, path, query string, and HTTP method, and supports weighted target groups for canary deployments. The Network Load Balancer operates at layer 4: it forwards TCP, UDP, and TLS traffic with connection-level (not request-level) routing, offers a static IP per Availability Zone with optional Elastic IPs, and preserves the client source IP by default. The Gateway Load Balancer is the specialist: it uses the GENEVE protocol on port 6081 to transparently insert third-party appliances — firewalls, IDS/IPS, deep packet inspection — into the traffic path.
The decision rule is shorter than most comparison tables suggest. If you route on anything inside the HTTP request (paths, hostnames, headers, cookies for stickiness), you need an ALB. If you need static IPs for allowlisting, non-HTTP protocols (MQTT, syslog, SMTP, game-server UDP), millions of requests per second with single-digit-millisecond latency, or a PrivateLink endpoint service, you need an NLB. If you are chaining traffic through a Palo Alto, Fortinet, or Check Point appliance fleet, that is the Gateway Load Balancer — and in diagrams it appears as a bump-in-the-wire in a separate inspection VPC, not as the entry point for application traffic.
gRPC deserves a specific call-out because it trips people up. Since 2020 the ALB supports gRPC natively: it speaks HTTP/2 end-to-end, routes on gRPC service and method names, and health-checks using gRPC status codes. An NLB also carries gRPC fine — it just passes it through as opaque TCP, so you lose per-method routing and gRPC-aware health checks. Choose ALB for gRPC when you want routing intelligence, NLB when you want raw throughput or TLS passthrough to the pod.
How do you diagram an ALB with ECS or EC2 across multiple AZs?
This is the canonical AWS application load balancer architecture diagram, and its structure should always be the same: a VPC rectangle containing two or three Availability Zone lanes, public subnets on top, private subnets below, the ALB node spanning the public subnets, and ECS tasks or EC2 instances in the private subnets. The single most important detail beginners get wrong is drawing one ALB icon inside one AZ. An ALB is a regional service that places a node in every enabled AZ — draw one ALB icon positioned across the AZ boundary lines, or centered above them with connections into each public subnet, so the multi-AZ nature is unambiguous.
Target groups are the second thing your diagram must show explicitly, because they are where routing decisions land. Draw the ALB listener (port 443) with its rules — for example, /api/* forwards to the api target group and everything else to the web target group — then draw each target group as a labeled grouping around its ECS tasks or EC2 instances. For ECS with awsvpc networking mode, targets register by IP, and each task gets its own ENI in the private subnet; annotate the target group with target type ip and the container port. An Auto Scaling group for EC2 targets gets its own dashed boundary around the instances.
Health checks belong on the edge between the target group and its targets, not floating in space. A small label like HTTP GET /healthz, 30s interval, 2 healthy / 5 unhealthy threshold tells a reviewer exactly what failover behavior to expect. Finish the pattern with the supporting cast: an internet gateway at the VPC edge, NAT gateways in each public subnet for outbound task traffic, and a Route 53 alias record pointing at the ALB DNS name. Example generation prompt: "AWS architecture diagram: VPC with 2 availability zones, internet-facing ALB in public subnets, HTTPS listener with path rules /api/* and /*, two target groups pointing to ECS Fargate tasks in private subnets, NAT gateway per AZ, Route 53 and internet gateway at the top, official AWS icons."
When should you use an NLB, and how does the diagram differ?
Reach for the Network Load Balancer when the traffic is not plain HTTP or when the network properties matter more than routing logic: a fleet of MQTT brokers for IoT ingestion, a multiplayer game server on UDP, a self-managed database proxy on TCP 5432, TLS passthrough where the backend must terminate the certificate, or an API that enterprise customers reach through AWS PrivateLink. The NLB is also the standard answer when a customer firewall team asks for IPs to allowlist — attach one Elastic IP per AZ and those addresses never change.
An NLB diagram looks structurally similar to the ALB one but differs in three visible ways. First, draw one NLB node icon per AZ, each annotated with its static or Elastic IP — this is the feature you chose the NLB for, so it should be legible. Second, listeners are ports, not rules: label the arrows TCP 443 or UDP 7777 rather than path patterns. Third, mark cross-zone load balancing explicitly, because it is off by default on NLB (unlike ALB, where it is always on); if it is disabled, each NLB node only sends traffic to targets in its own AZ, and your arrows should stay inside the AZ lane to reflect that.
For a gRPC-over-NLB pattern — common with Kubernetes services exposed via a Service of type LoadBalancer — draw the NLB forwarding TCP 443 to an IP target group whose targets are pod IPs registered by the AWS Load Balancer Controller. Add a note that TLS terminates in the pod, so the security review can see there is no plaintext hop. Example generation prompt: "AWS diagram: Network Load Balancer with Elastic IP in each of 3 AZs, TCP 443 listener with TLS passthrough, IP target group of EKS pods in private subnets, cross-zone load balancing disabled, PrivateLink endpoint service attached for a consumer VPC on the right."
ALB with Lambda targets and CloudFront in front: two patterns worth drawing correctly
The ALB supports Lambda functions as a target type, which gives you HTTP routing to serverless code without API Gateway. It suits teams migrating a path at a time: the listener rule sends /legacy/* to an EC2 target group while /v2/reports goes to a Lambda target group. Diagram it as a normal ALB with one target group whose single member is a Lambda function icon — no subnet placement needed, since Lambda targets live outside your VPC lanes unless the function itself is VPC-attached. Annotate the constraint that matters: Lambda targets have a 1 MB response payload limit via ALB, and health checks are optional pings rather than required probes.
Putting CloudFront in front of an ALB is the standard pattern for global user bases, and the diagram order is strict: users, then Route 53, then CloudFront, then the ALB origin, then targets. CloudFront terminates TLS at 600+ edge locations, caches static responses, and keeps connections to the origin warm over the AWS backbone. Two security details make the diagram review-ready: attach AWS WAF to the CloudFront distribution (not only the ALB), and show the ALB restricted so it only accepts traffic from CloudFront — via the managed prefix list for CloudFront origins in the ALB security group, plus a custom origin header verified by a listener rule. Without that restriction, attackers can bypass CloudFront and hit the ALB directly, and a good reviewer will flag it.
Example generation prompts: "AWS diagram: ALB with two listener rules, /api/* to an ECS target group in private subnets across 2 AZs, /reports/* to a Lambda target group outside the VPC, official AWS icons" and "AWS architecture diagram: Route 53 to CloudFront with WAF attached, CloudFront origin is an internet-facing ALB in 2 AZs, ALB security group allows only the CloudFront managed prefix list, ECS Fargate services behind it, S3 bucket as a second CloudFront origin for static assets."
How do you draw AZ boundaries, target groups, and health checks clearly?
AZ boundaries are the skeleton of any load balancer AWS diagram, so draw them as vertical lanes with consistent width and label them with real AZ IDs (us-east-1a, us-east-1b) rather than AZ 1 and AZ 2. Nest containers strictly — region contains VPC, VPC contains AZs, AZs contain subnets, subnets contain resources — and never let an instance icon float outside a subnet. Color subnets by tier the way AWS's own reference diagrams do: green-tinted for public, blue-tinted for private, so the reader can verify at a glance that no compute sits in a public subnet.
Target groups should be drawn as labeled dashed rectangles around their members, with the target type (instance, ip, or lambda) and port in the label. Route listener arrows from the load balancer to the target group boundary, not to individual instances — the whole point of a target group is that membership is dynamic, and arrows to specific instances imply a static wiring that does not exist. When one ALB has several listener rules, label each arrow with its condition (host: admin.example.com, path: /api/*) so the routing table is readable straight off the diagram.
Health checks are best rendered as a small annotation on the target group rather than extra arrows, which clutter fast. A one-line note — HC: HTTPS /health, 15s, 3/3 — carries everything an operator needs. If you are drawing this in draw.io manually, the AWS 2025 shape library has dedicated shapes for Application Load Balancer, Network Load Balancer, and Gateway Load Balancer under the Networking and Content Delivery category; use those instead of the generic ELB icon so the LB type is visible without reading labels. Mermaid can express these topologies in its architecture syntax but cannot render AZ lanes with official AWS icons well, and Lucidchart handles all of it but paywalls the AWS shape libraries beyond a small document limit — draw.io remains the free default for this diagram class.
Generate ALB and NLB architecture diagrams from a text prompt
Every pattern in this guide follows rigid conventions — region/VPC/AZ nesting, official icons, target group boxes, labeled listeners — which is exactly the kind of structure AI diagram generators handle well. AIDrawIO takes a plain-English description like the prompts above and produces a draw.io-compatible diagram using the official AWS architecture icon set, with AZ lanes and subnet containers already nested correctly. The output is draw.io XML, so nothing is locked in: open it in AIDrawIO's editor or diagrams.net, drag the target groups around, fix a label, and export to SVG or PNG for the design doc.
A prompt pattern that works reliably: name the load balancer type explicitly, state the AZ count, list each listener with its rule and target group, and say where targets live. For example: "AWS architecture diagram: internet-facing Application Load Balancer across us-east-1a and us-east-1b, HTTPS 443 listener, rule /api/* to ECS Fargate target group and default to EC2 Auto Scaling group target group, both in private subnets, health check GET /healthz every 30 seconds, NAT gateways, Route 53 alias record on top." Vague prompts like "web app with load balancer" produce generic results; the specificity is what buys you a reviewable diagram on the first generation.
You can try this on the free AWS diagram generator at aidrawio.com/en/tools/aws-diagram-generator — 5 generations per hour, no account needed. If you already have a whiteboard photo of your load balancing architecture, uploading the sketch converts it into an editable vector diagram, and version history keeps the ALB-only iteration around after you evolve it into the CloudFront-fronted design. For teams that prefer diagrams-as-code, Mermaid or Diagrams (the Python library) remain solid alternatives when the topology lives in a repo and visual fidelity matters less than diffability.
무료로 사용 AWS generator
AI-generated AWS architecture diagrams. Describe in plain English, get draw.io XML in seconds. No account required.
자주 묻는 질문
What is the difference between ALB and NLB in AWS?
The Application Load Balancer works at layer 7, terminating HTTP/HTTPS and routing on paths, hostnames, and headers, while the Network Load Balancer works at layer 4, forwarding TCP/UDP/TLS connections without inspecting them. Choose ALB when routing logic depends on the HTTP request; choose NLB for static IPs, non-HTTP protocols, TLS passthrough, or PrivateLink endpoint services.
Should I use ALB or NLB for gRPC?
The ALB supports gRPC natively over HTTP/2, including routing on gRPC service and method names and health checks based on gRPC status codes. An NLB carries gRPC as opaque TCP, which works but loses method-level routing — use it only when you need TLS passthrough to the backend or maximum raw throughput.
How do I show Availability Zones in an AWS load balancer diagram?
Draw AZs as vertical lanes inside the VPC container, labeled with real AZ names like us-east-1a, with public subnets on top and private subnets below. Draw the ALB spanning all AZ lanes since it is a regional service with a node in each enabled AZ, and place one NLB node per lane when the static per-AZ IPs are the point.
When should I use a Gateway Load Balancer?
Use the Gateway Load Balancer when you need to insert third-party network appliances — firewalls, IDS/IPS, or deep packet inspection — transparently into the traffic path. It uses the GENEVE protocol on port 6081 and typically appears in diagrams as an inspection VPC that traffic transits, not as the application entry point.
Do I need CloudFront in front of my ALB?
CloudFront in front of an ALB adds edge TLS termination, static caching, and transport over the AWS backbone, which helps global user bases most. If you add it, restrict the ALB to accept traffic only from the CloudFront managed prefix list and verify a custom origin header, otherwise attackers can bypass the CDN and hit the ALB directly.