Build NLB target group configurations with health checks, stickiness, and deregistration delay settings.
Build NLB target group configurations with health checks, stickiness, and deregistration delay settings.
Required Fields
NameProtocolPortVpcIdTargetTypeHealthCheckConfigurationOutput will appear here...The builder validates that Name, Protocol, Port, VpcId, TargetType, and HealthCheckConfiguration all resolve before accepting the JSON as a valid CreateTargetGroup request, the fields ELB needs to know the target group's identity, network placement, traffic protocol, and how to determine target health; it doesn't validate that the configured health-check path actually exists on your backend.
Build an NLB target group operating at the TCP/TLS layer (unlike ALB's HTTP-layer target groups), where health checks can still use an HTTP/HTTPS protocol even though the target group's own traffic Protocol is TCP, a common point of confusion since the health-check protocol and the data-plane protocol are configured independently. PreserveClientIp: true (the default for TCP/TLS target groups with instance targets) means the backend sees the real client source IP rather than the NLB's IP, which matters for IP-based access control lists on the backend but requires the security group to allow the actual client IP ranges, not just the NLB's.
A migration from ALB to NLB for the same backend often breaks IP-based access controls silently, because NLB with PreserveClientIp changes what source IP the backend actually sees, always verify backend security groups/firewalls are updated for the new IP visibility model before cutting traffic over.
An HTTP/HTTPS health check on a TCP target group gives meaningfully better failure detection than a bare TCP handshake check, use it whenever the backend has a real health endpoint, don't default to TCP-only health checks just because the target group's data protocol is TCP.
Stickiness on NLB works differently from ALB's cookie-based stickiness, source_ip-based stickiness means clients behind a shared NAT or corporate proxy all appear as one source IP and get routed to the same target, which can create unexpected load imbalance for that shared-IP population.
Yes, this is standard for NLB target groups, HealthCheckProtocol is configured independently of the target group's Protocol. A TCP or TLS target group commonly uses an HTTPS health check with a specific path to get an application-level 'am I actually healthy' signal, rather than relying on a bare TCP handshake, which only proves the port is open, not that the application behind it is functioning.
Yes, with PreserveClientIp true, the backend sees the actual client's source IP, so its security group or host-level firewall needs to allow the real client IP ranges. With it false (or for IP-target-type target groups where it's not applicable the same way), the backend instead sees the NLB's own IP as the source, and the security group would need to allow the NLB's IPs instead, this is a common migration gap when moving a workload from ALB (where PreserveClientIp isn't a factor the same way) to NLB.
DeregistrationDelay is the timeout period during which a deregistering target stops receiving new connections but existing ones are allowed to complete naturally. ConnectionTermination, when enabled, forcibly closes any connections still open once that DeregistrationDelay timeout is reached, rather than letting them linger indefinitely, useful for ensuring a deployment or scale-in event actually completes cleanly rather than waiting on a long-lived connection that never closes on its own.
Was this tool helpful?
Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.