AWS SAP-C02 Drill: High-Availability TCP Service with Static IP - The NLB Design Trade-off Analysis

While preparing for the AWS SAP-C02, many candidates get confused by Network Load Balancer (NLB) static IP capabilities versus Application Load Balancer (ALB) features. In the real world, this is fundamentally a decision about IP stability for third-party whitelisting vs. operational complexity. Let’s drill into a simulated scenario.

The Scenario

#

TechFlow Analytics, a B2B SaaS provider, is launching a real-time data ingestion service that enterprise clients will access via TCP protocol over a static port (8443). Due to strict corporate security policies, TechFlow’s clients require fixed IP addresses to add to their firewall allowlists before they can consume the service.

The platform team must ensure:

• High availability across multiple Availability Zones within the us-east-1 region
• Public internet accessibility via the DNS name data-ingest.techflow.io
• Static IP addresses that remain constant even during infrastructure changes
• Support for TCP protocol on a custom port

The CTO has allocated budget for a professional-grade solution but wants to avoid over-engineering.

Key Requirements

#

Design an architecture that provides multi-AZ redundancy, static IP addresses for client whitelisting, and DNS-based access to a TCP service, while minimizing operational overhead.

The Options

#

A) Deploy Amazon EC2 instances with Elastic IP addresses attached; create a Network Load Balancer (NLB) exposing the static TCP port; register EC2 instances as targets; create a Route 53 name server record set named data-ingest.techflow.io pointing to the EC2 Elastic IPs; provide the EC2 Elastic IPs to clients for whitelisting.

B) Create an Amazon ECS cluster with service definitions; assign public IP addresses to the ECS cluster; create a Network Load Balancer (NLB) exposing the TCP port; create a target group with the ECS cluster name assigned to the NLB; create a Route 53 A record set named data-ingest.techflow.io pointing to the ECS cluster public IPs; provide ECS cluster IPs to clients for whitelisting.

C) Deploy Amazon EC2 instances for the service; create one Elastic IP address per Availability Zone; create a Network Load Balancer (NLB) exposing the specified TCP port; assign the Elastic IPs to the NLB (one per AZ); create a target group and register EC2 instances; create a Route 53 A (Alias) record set named data-ingest.techflow.io pointing to the NLB DNS name.

D) Create an Amazon ECS cluster with service definitions; assign public IP addresses to each ECS host; create an Application Load Balancer (ALB) exposing the static TCP port; create a target group with the ECS service definition assigned to the ALB; create a Route 53 CNAME record set associated with the public IPs; provide EC2 instance Elastic IPs to clients for whitelisting.

Correct Answer

#

Option C.

The Architect’s Analysis

#

Correct Answer

#

Option C is the winning architecture.

Step-by-Step Winning Logic

#

This solution leverages the Network Load Balancer’s unique capability to accept Elastic IP address assignment per Availability Zone. Here’s why it’s optimal:

1. Static IP Guarantee: NLB allows you to assign one Elastic IP per enabled AZ. These IPs remain constant even if backend instances change, satisfying the whitelisting requirement.

2. Multi-AZ High Availability: By distributing targets across AZs and assigning per-AZ Elastic IPs, the architecture achieves zone-level fault tolerance. If one AZ fails, traffic automatically flows through the remaining healthy AZs.

3. Protocol Optimization: NLB operates at Layer 4 (TCP/UDP), making it ideal for custom TCP ports without the HTTP/HTTPS overhead of ALB.

4. DNS Abstraction: Using a Route 53 Alias record pointing to the NLB DNS name provides a stable, friendly hostname while the NLB’s static IPs handle the actual whitelisting.

5. Operational Simplicity: Clients whitelist the NLB’s Elastic IPs (typically 2-3 for multi-AZ), not individual instance IPs. Backend scaling doesn’t require client firewall updates.

The Traps (Distractor Analysis)

#

Why not Option A?

• Breaks High Availability Abstraction: Providing individual EC2 Elastic IPs to clients defeats the purpose of a load balancer. If an instance fails, clients whitelisting that specific IP lose connectivity until manual intervention.
• Operational Nightmare: Scaling horizontally requires distributing new Elastic IPs to all clients and coordinating firewall updates—unacceptable in enterprise environments.
• Incorrect DNS Configuration: A “name server record set” (NS record) is used for DNS delegation, not for pointing to service IPs.

Why not Option B?

• Architectural Impossibility: You cannot “assign public IP addresses to the ECS cluster” as an entity. ECS tasks run on EC2 instances (EC2 launch type) or Fargate (which uses ENIs), but there’s no cluster-level IP.
• Target Group Misconfiguration: You register ECS tasks (via IP or instance mode) to target groups, not “the ECS cluster name.”
• Dynamic IP Problem: ECS task IPs are ephemeral and change during deployments, violating the static IP requirement.

Why not Option D?

• Protocol Mismatch: Application Load Balancers operate at Layer 7 (HTTP/HTTPS). While ALB can handle TCP via listener rules, it’s not optimized for arbitrary TCP ports and adds unnecessary HTTP processing overhead.
• Static IP Limitation: ALB does not support Elastic IP assignment. Its IP addresses are dynamic and managed by AWS, making whitelisting unreliable.
• DNS Confusion: The option mixes CNAME records with public IPs (CNAMEs point to hostnames, not IPs) and suggests providing “EC2 instance Elastic IPs” despite using ALB—logically inconsistent.

The Architect Blueprint

#

Diagram Note: Clients resolve data-ingest.techflow.io to the NLB, which has one static Elastic IP per AZ (203.0.113.10, 203.0.113.20). These IPs are whitelisted once by clients, while backend EC2 instances can scale independently without impacting client configurations.

The Decision Matrix

#

FinOps Note: The $60-80/month premium of Option C over Option A is negligible compared to the cost of manual incident response when individual EC2 instances fail in Option A. The NLB’s per-AZ static IP capability is a feature specifically designed for this use case, justifying the investment.

Real-World Practitioner Insight

#

Exam Rule

#

For the SAP-C02 exam, when you see:

• “Static IP address” + “TCP protocol” + “multi-AZ” → Think NLB with per-AZ Elastic IPs
• “Whitelisting” or “allowlist” requirements → Eliminate any option with dynamic IPs
• “High availability” + exposing individual instance IPs → Architectural anti-pattern

Key Exam Traps:

• ALB cannot provide static IPs (requires AWS Global Accelerator for static IPs with ALB)
• Individual EC2 Elastic IPs break the HA abstraction of load balancing
• Route 53 Alias records are preferred over A records when pointing to AWS load balancers

Real World

#

In a production environment, we would additionally consider:

1. AWS Global Accelerator (if clients are geographically distributed): Provides 2 static anycast IPs globally, fronting the NLB for improved performance and DDoS protection (~$300/month base cost).

2. Connection Draining & Health Checks: Configure aggressive health check intervals (10 seconds) and appropriate deregistration delays to minimize failover detection time.

3. Auto Scaling Groups: Attach EC2 instances via ASG to automatically replace unhealthy targets, which the exam scenario implies but doesn’t detail.

4. TLS Termination: If the TCP protocol carries sensitive data, implement TLS at the NLB level (NLB supports TLS termination as of 2019) to offload certificate management from backend instances.

5. Cost Optimization: For steady-state workloads, consider Reserved Instances for the EC2 targets and NLB capacity. For variable workloads, use Savings Plans with Fargate instead of EC2 for better elasticity.

6. Monitoring: Set up CloudWatch alarms for:

   • NLB UnHealthyHostCount metrics per AZ
   • Target response times
   • Active connection counts to detect capacity issues

7. IP Exhaustion Planning: If the service scales to dozens of AZs (unlikely in one region), NLB’s per-AZ EIP model could consume your Elastic IP quota (default 5 per region). Request a limit increase proactively.