Load Balancing via SDK Best Practices

A load balancer is easy to stand up and easy to get subtly wrong. A health check that hammers the database, a 300-second drain that makes every deploy crawl, a stale TLS policy, an orphaned load balancer billing by the hour - these are the everyday ways ELB v2 automation costs money or drops traffic.

Walk this list once now, then use it as a review checklist before shipping any code that creates or manages load balancers, listeners, or target groups. All examples use elbv2 / @aws-sdk/client-elastic-load-balancing-v2.

How to Use This List

• Each item is a rule stated positively, with a one-line rationale.
• Groups run roughly in order of impact: type choice and health checks first, then deploys, security, and cost.
• Check the boxes against your own code as a quick audit.
• Revisit whenever you add a load-balanced service or move code to a new account or region.

A - Choosing the Right Type

• Pick the type deliberately. Type is fixed at creation - application for HTTP routing, network for L4, static IP, or lowest latency. Switching means a new load balancer.
• Use an ALB for HTTP routing. Path, host, and header rules on one ALB beat running many single-purpose load balancers.
• Use an NLB for non-HTTP or fixed IPs. TCP/UDP workloads, IP allowlists, and extreme throughput belong on an NLB with SubnetMappings.
• Spread across at least two AZs. List subnets in multiple Availability Zones so one AZ failure does not take the service down.

B - Health Check Design

• Keep the health endpoint shallow. A /healthz that touches the database marks the whole fleet unhealthy when that dependency slows; check only the process is alive.
• Set an explicit matcher. A range like 200-299 is safer than a lone 200 if the endpoint can return a 204.
• Tune detection time on purpose. Failure detection is roughly UnhealthyThresholdCount x HealthCheckIntervalSeconds; lower both to fail fast, not so low that targets flap.
• Keep timeout below interval. HealthCheckTimeoutSeconds must be less than HealthCheckIntervalSeconds or the API rejects it.

Create the target group with deliberate, shallow health-check settings.

# --- Python (boto3) ---
import boto3
 
elbv2 = boto3.client("elbv2", region_name="us-east-1")
elbv2.create_target_group(
    Name="web-tg", Protocol="HTTP", Port=80, VpcId="vpc-0abc",
    TargetType="instance",
    HealthCheckPath="/healthz",
    HealthCheckIntervalSeconds=10,
    HealthCheckTimeoutSeconds=5,
    UnhealthyThresholdCount=2,          # ~20s to detect failure
    Matcher={"HttpCode": "200-299"},
)

// --- TypeScript (AWS SDK v3) ---
import { ElasticLoadBalancingV2Client, CreateTargetGroupCommand } from "@aws-sdk/client-elastic-load-balancing-v2";
 
const elbv2 = new ElasticLoadBalancingV2Client({ region: "us-east-1" });
await elbv2.send(new CreateTargetGroupCommand({
  Name: "web-tg", Protocol: "HTTP", Port: 80, VpcId: "vpc-0abc",
  TargetType: "instance",
  HealthCheckPath: "/healthz",
  HealthCheckIntervalSeconds: 10,
  HealthCheckTimeoutSeconds: 5,
  UnhealthyThresholdCount: 2,           // ~20s to detect failure
  Matcher: { HttpCode: "200-299" },
}));

C - Zero-Downtime Deploys

• Set deregistration delay to fit your requests. Lower the 300s default to just above your longest normal request (often ~30s) so deploys drain cleanly without crawling.
• Wait for draining to finish. Poll DescribeTargetHealth until a removed target leaves draining for unused before terminating it.
• Confirm new targets are healthy before cutover. A target is initial until it passes checks; only shift traffic once it is healthy.
• Use slow start for cold targets. Ramp traffic with slow_start.duration_seconds so a fresh target is not overwhelmed before caches warm.

Set the deregistration delay so connection draining matches your traffic.

# --- Python (boto3) ---
import boto3
 
elbv2 = boto3.client("elbv2", region_name="us-east-1")
elbv2.modify_target_group_attributes(
    TargetGroupArn="arn:...:targetgroup/web-tg/111",
    Attributes=[{"Key": "deregistration_delay.timeout_seconds", "Value": "30"}],
)

// --- TypeScript (AWS SDK v3) ---
import { ElasticLoadBalancingV2Client, ModifyTargetGroupAttributesCommand } from "@aws-sdk/client-elastic-load-balancing-v2";
 
const elbv2 = new ElasticLoadBalancingV2Client({ region: "us-east-1" });
await elbv2.send(new ModifyTargetGroupAttributesCommand({
  TargetGroupArn: "arn:...:targetgroup/web-tg/111",
  Attributes: [{ Key: "deregistration_delay.timeout_seconds", Value: "30" }],
}));

D - TLS & Security

• Terminate with ACM certificates. They are free and renew automatically as long as the DNS validation record stays published - no rotation code.
• Pick a modern SslPolicy. Use a current ELBSecurityPolicy-TLS13-* so the listener rejects outdated TLS versions.
• Redirect HTTP to HTTPS. Give port 80 a default redirect action to 443 so no client stays on plaintext.
• Match the certificate region. An ALB/NLB certificate must be in the same region as the load balancer; only CloudFront uses us-east-1.
• Scope security groups. For an NLB with source IP preservation, target security groups must allow the client CIDR, not the load balancer.

Create the HTTPS listener with a modern policy and an ACM certificate.

# --- Python (boto3) ---
import boto3
 
elbv2 = boto3.client("elbv2", region_name="us-east-1")
elbv2.create_listener(
    LoadBalancerArn="arn:...:loadbalancer/app/web-alb/abc",
    Protocol="HTTPS", Port=443,
    Certificates=[{"CertificateArn": "arn:...:certificate/site"}],
    SslPolicy="ELBSecurityPolicy-TLS13-1-2-2021-06",
    DefaultActions=[{"Type": "forward", "TargetGroupArn": "arn:...:targetgroup/web-tg/111"}],
)

// --- TypeScript (AWS SDK v3) ---
import { ElasticLoadBalancingV2Client, CreateListenerCommand } from "@aws-sdk/client-elastic-load-balancing-v2";
 
const elbv2 = new ElasticLoadBalancingV2Client({ region: "us-east-1" });
await elbv2.send(new CreateListenerCommand({
  LoadBalancerArn: "arn:...:loadbalancer/app/web-alb/abc",
  Protocol: "HTTPS", Port: 443,
  Certificates: [{ CertificateArn: "arn:...:certificate/site" }],
  SslPolicy: "ELBSecurityPolicy-TLS13-1-2-2021-06",
  DefaultActions: [{ Type: "forward", TargetGroupArn: "arn:...:targetgroup/web-tg/111" }],
}));

E - Reliability, Cost & Cleanup

• Wait on the availability waiter. Use load_balancer_available (boto3) or waitUntilLoadBalancerAvailable (SDK v3) before adding listeners instead of a sleep.
• Tag every resource. Tag load balancers, target groups, and listeners with Name, Environment, and Owner so nothing is orphaned or unattributable.
• Delete unused load balancers. An idle ALB/NLB bills per hour plus capacity units; tear down what a deploy or test left behind.
• Weigh NLB cross-zone cost. Cross-zone is free on an ALB but adds inter-AZ transfer on an NLB - enable it only when target counts are uneven.
• Rely on built-in retries. Both SDKs retry throttling and transient errors with backoff; tune max attempts rather than reimplementing retries.
• Log the request id on failure. Capture ResponseMetadata.RequestId (boto3) or $metadata.requestId (SDK v3) for support and correlation.

FAQs

Related

• ALB vs NLB: Choosing a Load Balancer Type - the type decision behind group A.
• Target Groups & Health Check Tuning - the health-check and draining settings in groups B and C.
• Listeners & Routing Rules - the redirect and forward actions referenced in group D.
• TLS Termination & ACM Integration - the certificate and policy guidance in group D.

Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+).