AWS Network Load Balancer with Static Elastic IPs and Custom TCP Ports – SAP-C02 Study Guide | AWS Systems Architect Professional

Study guide

Technical reference and lesson notes

Purpose of This Lesson

This lesson demonstrates how to deploy an internet-facing Network Load Balancer (NLB) for an application listening on a custom TCP port, 8181. The design uses:

An Auto Scaling group (ASG) spanning two Availability Zones
A TCP target group containing the application instances
One static Elastic IP address (EIP) assigned to each NLB subnet
NLB security controls and a client-side network ACL (NACL) that allow only the approved destination IP addresses and port
A test client that accesses the service through the NLB DNS name

The lab highlights an important enterprise networking requirement: clients may be permitted to connect only to known IP addresses, even when the service is accessed through a load balancer.

Key Concepts

Network Load Balancer fundamentals

An NLB operates at Layer 4 and is designed for high-throughput, low-latency TCP, TLS, UDP, and related use cases. It forwards connections without requiring HTTP-aware routing rules such as URL paths or host headers.

For this application, the relevant configuration is:

Scheme: Internet-facing
IP address type: IPv4
Listener protocol: TCP
Listener port: 8181
Target protocol: TCP
Target port: 8181

The NLB listener receives client connections and forwards them to healthy instances in the target group.

Static public IP addresses per Availability Zone

An internet-facing NLB normally receives a static IP address for each enabled Availability Zone. When predictable addresses are required, you can associate an Elastic IP with the NLB subnet mapping in each Availability Zone.

This is useful when:

A partner firewall requires destination IP allowlisting
An enterprise egress firewall permits only approved public addresses
A third-party system cannot use DNS-based destination changes
Compliance requirements require known ingress addresses

Use a separate EIP for each NLB Availability Zone. Do not assign the same EIP to multiple NLB subnet mappings.

Although clients can connect using the NLB DNS name, DNS resolution returns the NLB node address appropriate for the request. The DNS name remains the preferred application endpoint because it preserves AWS-managed load-balancing behavior and avoids hard-coding addresses.

Target groups and health checks

The target group uses instance targets and forwards TCP traffic to port 8181. A target is eligible to receive traffic only when it passes the configured health check.

For a basic TCP service, a TCP health check verifies that a connection can be established to the target port. It does not validate an application response. An HTTP health check is more appropriate when the application must return a valid HTTP response, such as a specific status code or path response.

The health-check protocol should match what the application actually supports:

TCP health check: Confirms that the port accepts connections
HTTP or HTTPS health check: Confirms an application-level response

A target can be reachable at the network layer while still being unhealthy from the application’s perspective. Choose the health check based on the failure mode that must be detected.

Auto Scaling integration

The instances are launched through a launch template and managed by an Auto Scaling group across two Availability Zones. The ASG provides:

Instance replacement when a node fails
Distribution across Availability Zones
Consistent instance configuration through the launch template
A scalable target population for the NLB

The target group should be associated with the ASG so that new instances are automatically registered and terminated instances are removed. This avoids manual target registration.

For production, configure desired, minimum, and maximum capacity based on workload requirements rather than using a fixed two-instance demonstration configuration.

Security groups and custom ports

The instance security group must allow inbound TCP 8181 from the appropriate source. In a production design, avoid opening the port to 0.0.0.0/0 unless it is genuinely required.

Depending on the NLB configuration and AWS Region capabilities, an NLB can have an associated security group. If an NLB security group is used, it can restrict client traffic before the traffic reaches the targets. The target security group should then be designed to accept traffic from the NLB security group where supported, rather than from the entire internet.

A common layered pattern is:

NLB security group permits TCP 8181 from approved client sources.
Instance security group permits TCP 8181 from the NLB security group.
NACLs provide subnet-level, stateless controls as an additional boundary.

Do not use a NACL as a replacement for security groups. NACLs are stateless and require both inbound and outbound rules for return traffic.

Network ACL allowlisting

A NACL can allow or deny traffic based on protocol, port, and IP address. Rules are evaluated in ascending rule-number order, and processing stops at the first match.

To permit a client subnet to reach only the NLB’s two EIPs on TCP 8181, rules could conceptually look like this:

Rule	Protocol	Port	Destination	Action
97	TCP	8181	NLB EIP 1 `/32`	Allow
98	TCP	8181	NLB EIP 2 `/32`	Allow
99	TCP	8181	`0.0.0.0/0`	Deny
100	All traffic	All	`0.0.0.0/0`	Allow, if required by the remaining design

The specific rule numbers are not important; the ordering is. A broad allow rule placed before a restrictive deny would make the deny ineffective.

The /32 suffix represents one exact IPv4 address. It is appropriate when the policy must allow only the two NLB EIPs.

Because NACLs are stateless, a complete design must also account for response traffic, including ephemeral client ports. Restricting only outbound destination port 8181 may not be sufficient for every real deployment. Carefully review both the client subnet’s outbound rules and the return path’s inbound rules.

EIP cost and lifecycle

Elastic IP addresses can incur charges when allocated under current AWS pricing conditions, including situations where they are not actively associated. Short-lived labs generally cost little, but unused addresses should still be released promptly.

A safe cleanup sequence is:

Delete the NLB.
Delete or scale down the Auto Scaling group.
Terminate any standalone test instance.
Confirm EIP associations have been removed.
Release the EIPs.

If an EIP cannot be released, wait for the NLB deletion or other association removal to complete and then retry.

Exam-Relevant Takeaways

An NLB is a Layer 4 load balancer for TCP, TLS, UDP, and similar connection-oriented or high-performance workloads.
An internet-facing NLB can provide static public addresses, including customer-supplied Elastic IPs assigned per Availability Zone.
Use an NLB when clients or partners require IP-based allowlisting and the application does not need Application Load Balancer features such as path-based routing.
A listener and target group are separate configurations. The listener accepts client traffic; the target group defines where and how traffic is forwarded.
Select a target-group health check that validates the required layer: TCP for port availability, HTTP/HTTPS for application responses.
Associate the target group with an Auto Scaling group to register new instances automatically.
NACLs are stateless, evaluated in rule-number order, and require careful handling of return traffic.
Security groups are stateful and are generally the primary instance-level control. NACLs are subnet-level supplemental controls.
A DNS name should normally be used to reach the NLB even when static EIPs are configured.
Elastic IPs and other lab resources must be released or deleted to prevent unnecessary charges.

Architecture Decision Guide

Requirement	Recommended choice	Reason
Raw TCP service on a custom port	NLB with a TCP listener	Layer 4 forwarding without HTTP routing requirements
HTTP path or host-based routing	Application Load Balancer	Layer 7 routing features
Known public destination IPs for firewall allowlisting	NLB with EIPs per enabled AZ	Provides predictable per-AZ public addresses
TLS pass-through to targets	NLB TCP listener	Targets handle TLS termination
TLS termination at the load balancer	NLB TLS listener or ALB HTTPS listener	Choose based on protocol and routing requirements
Detect only whether a port accepts connections	TCP health check	Simple transport-level validation
Verify application status or response content	HTTP/HTTPS health check	Application-level validation
Automatically register replacement instances	ASG associated with target group	Lifecycle integration removes manual registration
Stateful instance access control	Security group	Return traffic is automatically allowed
Stateless subnet boundary or explicit ordered denies	Network ACL	Applies at subnet level and evaluates numbered rules

Common Exam Traps

Assuming an NLB provides one universal IP address: An NLB is distributed across Availability Zones. Plan for one address per enabled AZ when using static EIPs.
Using an ALB for a non-HTTP TCP service: ALB is intended for HTTP/HTTPS-aware workloads. Use an NLB for generic TCP.
Confusing listener and target ports: The listener port can differ from the target port, but both must be configured intentionally.
Using an HTTP health check for a raw TCP application: If the service does not speak HTTP, the health check fails even when the TCP service is healthy.
Putting a broad NACL allow before a deny: NACLs stop at the first matching rule. Rule order determines the effective policy.
Forgetting NACL return traffic: NACLs are stateless. Both directions and ephemeral ports may need explicit rules.
Treating NACLs like security groups: Security groups are stateful and attached to ENIs; NACLs are stateless and attached to subnets.
Hard-coding NLB IPs in application logic: Prefer the NLB DNS name unless an external firewall specifically requires IP allowlisting.
Forgetting that EIPs are regional resources: An EIP and the NLB using it must be in the same AWS Region.
Leaving lab resources running: NLBs, EC2 instances, ASGs, and EIPs can continue generating charges after testing.

Real-World Engineer Notes

Use at least two Availability Zones for production NLB deployments. Confirm that the target group has healthy capacity in each enabled AZ.
If the source is another VPC, choose the connectivity model deliberately: Transit Gateway, VPC peering, PrivateLink, or public internet access may produce different source-IP and routing behavior.
A client-side firewall may see the NLB node EIP as the destination, but the exact source-IP behavior depends on the NLB traffic pattern and network architecture. Validate with packet flow and flow logs rather than assumptions.
NACL changes affect every resource in the associated subnet. Keep subnet roles and NACL policies simple enough to audit.
Prefer a dedicated security group for the application rather than reusing a broad “web access” group across unrelated workloads.
For production, manage the launch template, ASG, target group, NLB, EIPs, IAM permissions, and NACLs with AWS CloudFormation, AWS CDK, or Terraform.
Enable health-check monitoring and alarms. A TCP health check may not detect application-level failures such as a process returning incorrect content.
Static EIPs solve destination allowlisting, but they do not automatically provide a stable single IP. If a consumer requires one address only, evaluate whether the protocol and architecture support another front-end design.

Quick Reference Summary

Service: Network Load Balancer
OSI layer: Layer 4
Example listener: TCP 8181
Target type: EC2 instances in an Auto Scaling group
Availability: Deploy across multiple AZs
Static addressing: Associate a distinct EIP with each NLB subnet mapping
Health check: TCP for transport availability; HTTP/HTTPS for application validation
Security groups: Stateful, resource-level controls
NACLs: Stateless, subnet-level controls evaluated in rule order
Allowlisting: Use exact /32 entries for individual NLB EIPs when required
Cleanup: Delete the NLB and ASG, terminate test resources, then release EIPs

Flashcards

Q: What OSI layer does an NLB primarily operate at?

A: Layer 4, forwarding connections based on transport protocols and ports.

Q: Which load balancer is appropriate for a generic TCP application on port 8181?

A: A Network Load Balancer with a TCP listener.

Q: How can an internet-facing NLB use predictable public IP addresses?

A: Associate an Elastic IP with each NLB subnet mapping, using one EIP per enabled Availability Zone.

Q: What does a TCP target-group health check prove?

A: That the target accepts a TCP connection on the health-check port; it does not prove that the application response is correct.

Q: Why associate a target group with an Auto Scaling group?

A: New instances are registered automatically and terminated instances are removed from service.

Q: In what order are NACL rules evaluated?

A: From the lowest rule number to the highest; evaluation stops at the first match.

Q: Are NACLs stateful?

A: No. Return traffic requires matching rules in the opposite direction.

Q: Are security groups stateful?

A: Yes. Return traffic is automatically permitted when the initial flow is allowed.

Q: What does 203.0.113.10/32 represent in a NACL rule?

A: One exact IPv4 address.

Q: Why might a company require NLB EIPs?

A: A partner or enterprise firewall may allow traffic only to explicitly approved destination IP addresses.

Q: Why is the NLB DNS name still useful when EIPs are configured?

A: DNS allows clients to use the load balancer’s managed endpoint rather than hard-coding addresses.

Q: What is a common cleanup dependency involving EIPs?

A: The NLB or another resource must be deleted or disassociated before its EIP can be released.

Practice Questions

Question 1

A company runs a proprietary TCP service on port 8181. A partner will connect from the internet, and its firewall can allow only a fixed set of destination IPv4 addresses. The service must run across two Availability Zones and automatically replace failed EC2 instances. Which architecture best meets the requirements?

A. Application Load Balancer with an HTTP listener and one static EIP
B. Network Load Balancer with TCP 8181, one EIP per AZ, and an ASG-backed target group
C. Classic Load Balancer with an HTTPS listener and one EIP
D. Route 53 latency-based routing directly to EC2 instances

Correct answer: B

Explanation: An NLB supports generic TCP traffic and static EIP assignment per enabled AZ. Associating the target group with an ASG provides automatic registration and replacement. ALB and HTTPS are inappropriate for a raw TCP service, and Route 53 does not replace the need for connection load balancing.

Question 2

An NLB target group forwards TCP traffic to port 8181. The application accepts TCP connections but does not implement HTTP. Targets are marked unhealthy when an HTTP health check is configured. What is the best correction?

A. Change the listener to UDP
B. Change the target group health check to TCP on port 8181
C. Remove all health checks
D. Change the target group protocol to HTTPS

Correct answer: B

Explanation: A TCP health check validates that the service accepts connections on the target port. An HTTP health check requires an HTTP-speaking application and can fail against a raw TCP service.

Question 3

A client subnet’s NACL contains rule 100 allowing all outbound traffic. An administrator adds rule 110 denying TCP port 8181 to 0.0.0.0/0, but clients can still connect to the NLB. Why?

A. NACL rules are evaluated from the highest number downward
B. Security groups always override NACL denies
C. The earlier broad allow rule matches first
D. NLBs ignore NACLs

Correct answer: C

Explanation: NACL rules are processed in ascending rule-number order. Rule 100 allows the traffic before rule 110 is evaluated, so the later deny is never reached. The deny must have a lower rule number than the broad allow, or the broad allow must be redesigned.

Question 4

A security team wants clients to reach TCP 8181 only through two known NLB EIPs. Which NACL entries most directly express this destination policy?

A. Allow TCP 8181 to 0.0.0.0/0; deny the two EIPs
B. Allow TCP 8181 to each EIP using /32; then deny TCP 8181 to all other destinations
C. Allow all traffic to the client subnet; restrict only the EC2 instances
D. Allow UDP 8181 to both EIPs

Correct answer: B

Explanation: Individual /32 rules match the exact NLB EIPs. A subsequent lower-priority catch-all deny blocks other destinations, provided the rule order is correct. The complete NACL design must also permit required return traffic because NACLs are stateless.

Question 5

An engineer finishes a temporary NLB lab and attempts to release its EIPs. AWS reports that an EIP is still associated. What should the engineer do first?

A. Allocate a replacement EIP in another Region
B. Delete the target group only
C. Remove the NLB or its subnet association, wait for propagation, and then release the EIP
D. Stop the EC2 instances and immediately release the EIP

Correct answer: C

Explanation: EIPs cannot be released while still associated with the NLB or another resource. Delete the NLB or remove the association, allow the control-plane change to complete, and retry the release.