AWS Connectivity Patterns: Internal vs. External Load Balancing

This guide explores the architectural nuances of Elastic Load Balancing (ELB) placement within a Virtual Private Cloud (VPC), focusing on how connectivity patterns differ between internet-facing and internal-only deployments.

Learning Objectives

• Differentiate between internet-facing (external) and internal load balancers based on IP addressing and subnet placement.
• Design a multi-tier connectivity pattern using both internal and external ELBs.
• Identify target group requirements for both public and private backends.
• Explain the role of cross-zone load balancing in achieving high availability.

Key Terms & Glossary

• Internet-facing (External) ELB: A load balancer that has public IP addresses and is accessible from the internet.
• Internal ELB: A load balancer that has only private IP addresses and is used to route traffic within a VPC or connected networks.
• ELB Nodes: The managed compute resources created by AWS in each enabled Availability Zone (AZ) to handle incoming traffic.
• Listener: A process that checks for connection requests using a configured protocol and port.
• Cross-zone Load Balancing: A feature that allows an ELB node to distribute traffic across all registered targets in all enabled AZs, rather than just targets in its own AZ.

The "Big Idea"

Load balancers serve as the architectural glue of a VPC. By strategically placing external load balancers at the edge to receive user traffic and internal load balancers between application tiers, you create a "security-in-depth" model. This pattern ensures that backend application and database servers remain isolated from the public internet while remaining accessible to the components that need them.

Formula / Concept Box

Hierarchical Outline

1. Connectivity Patterns Overview
   • External Placement: Positioned in public subnets to receive public traffic.
   • Internal Placement: Positioned to separate application tiers (Web, App, Data).
2. External Load Balancer Mechanics
   • Node Addressing: Public IP addresses assigned to listeners.
   • Target Flexibility: Can route to private IP targets even if the ELB is public.
3. Internal Load Balancer Mechanics
   • Node Addressing: Only private IP addresses assigned to nodes.
   • Service Separation: Enables microservices to communicate without internet exposure.
4. Resiliency Features
   • Availability Zones: Distributing nodes across AZs for fault tolerance.
   • Cross-zone Load Balancing: Balances load evenly regardless of target density per AZ.

Visual Anchors

Multi-Tier Connectivity Pattern

ELB Node Placement Logic

Definition-Example Pairs

• Internal Load Balancer: A load balancer that routes requests to targets using only private IP addresses.
  • Example: A company uses an Internal Application Load Balancer (ALB) to allow their frontend React servers (in a private subnet) to talk to their backend Java API servers (also in a private subnet).
• Connection Draining (Deregistration Delay): A process that allows a load balancer to complete in-flight requests before removing a target.
  • Example: When an Auto Scaling Group terminates an instance, the ELB stops sending new requests but waits 300 seconds for current users to finish their checkout process before killing the connection.

Worked Examples

Scenario: Architecting for a High-Security Financial App

The Requirement: The application must accept traffic from the public web but must ensure the database is never reachable via an internet-facing component.

The Solution Step-by-Step:

1. Deploy External ALB: Place the ELB in two Public Subnets (AZ-A and AZ-B). Assign a security group allowing Port 443 from 0.0.0.0/0.
2. Deploy Web Servers: Place EC2 instances in Private Subnets. Configure their security group to allow Port 80/443 only from the External ALB's security group.
3. Deploy Internal ALB: Place an internal ELB in the Private Subnets. This ELB receives traffic from the Web Servers and points to the App Servers.
4. Target Groups: Set the Target Type to instance or ip. Note that the External ALB can target the private IP addresses of the Web Servers directly.

[!TIP] An EC2 instance does not require a public IP address to receive traffic from an internet-facing load balancer. The ELB nodes in the public subnet act as the bridge.

Checkpoint Questions

1. Does an internal load balancer require an Internet Gateway (IGW) to function?
2. Can an internet-facing load balancer have targets in a private subnet? If so, what is the connectivity requirement?
3. In a three-tier architecture (Web, App, Data), where would you typically place an internal load balancer?

▶Click to view answers

1. No. Internal load balancers route traffic entirely within the AWS network or over VPN/Direct Connect.
2. Yes. The targets can be in a private subnet as long as the ELB nodes have network reachability to the targets' private IPs.
3. Between the Web tier and the App tier, and/or between the App tier and the Data tier.

Muddy Points & Cross-Refs

• Confusion between Subnet Type vs. ELB Type: Users often think a "Public ELB" must have "Public Targets." This is false. The ELB type only defines the entry point, not the exit point.
• Cross-Zone vs. Multi-AZ: An ELB is "Multi-AZ" by virtue of having nodes in multiple subnets. "Cross-zone" is a specific setting that determines if a node in AZ-A can send traffic to an instance in AZ-B.
• Cross-Ref: For deeper info on security, see VPC Security Groups vs. Network ACLs.

Comparison Tables

Connectivity Pattern Comparison