Cloud / Amazon Elastic Load Balancing (ELB) Interview questions

Amazon Elastic Load Balancing (ELB) is a managed AWS service that spreads incoming traffic across multiple targets such as EC2 instances, containers, IP addresses and Lambda functions, in one or more Availability Zones.

It keeps checking the health of every target and sends requests only to the healthy ones. The load balancer itself scales automatically with traffic, so you never size or patch servers for it.

• Removes a single point of failure in front of your application
• Supports TLS termination, so certificates are managed in one place
• Integrates with Auto Scaling, ECS, EKS, Route 53, WAF and CloudWatch

ELB comes in four flavours: Application, Network, Gateway and Classic Load Balancer.

ELB offers four types. Three are current generation and one is legacy.

For new designs, pick ALB for HTTP traffic, NLB for raw TCP/UDP or static IPs, and GWLB for third-party network appliances.

An Application Load Balancer (ALB) works at layer 7 and routes requests by looking at their content: host name, URL path, headers, query string, HTTP method or source IP.

Beyond routing, it can redirect requests, return fixed responses, authenticate users through Cognito or any OIDC provider, and invoke Lambda functions directly. It understands HTTP/2, gRPC and WebSockets.

• Supports security groups and AWS WAF
• Terminates TLS using ACM certificates, with SNI for multiple domains
• Does not give you static IP addresses

A Network Load Balancer (NLB) operates at layer 4 and forwards TCP, UDP, TCP_UDP and TLS connections. It is built to handle millions of requests per second with very low latency and sudden traffic spikes.

Each enabled Availability Zone gets a fixed IP address, and for internet-facing NLBs you can attach an Elastic IP. By default the original client IP reaches instance targets untouched.

• Ideal for gaming, IoT, streaming, DNS and database proxies
• Can sit in front of an ALB to combine static IPs with layer 7 routing
• Backs AWS PrivateLink endpoint services

A Gateway Load Balancer (GWLB) lets you deploy, scale and manage fleets of virtual network appliances such as firewalls, intrusion detection systems and deep packet inspection tools. It acts as a transparent network gateway and a load balancer in one.

Traffic reaches it through a Gateway Load Balancer endpoint that you place in route tables. The GWLB wraps each packet in GENEVE (UDP port 6081) and sends it to an appliance, then forwards the inspected packet on to its destination.

Flows are hashed so both directions of a connection land on the same appliance, which stateful inspection needs.

The Classic Load Balancer (CLB) is the original ELB, now considered legacy. It balances at layer 4 (TCP, SSL) and at a basic layer 7 (HTTP, HTTPS) and registers EC2 instances directly rather than through target groups.

It lacks modern features: no path or host routing, no SNI so one certificate per listener, no Lambda or IP targets, and no WebSocket support on HTTP listeners. EC2-Classic, where CLB first lived, was retired in August 2022.

AWS recommends migrating to ALB or NLB, and the console offers a migration wizard to do it.

A target group is a logical set of targets that receives traffic from a load balancer listener. Listener rules point at target groups, not at individual servers.

Each target group has its own protocol and port, health check settings, routing algorithm and attributes like stickiness and deregistration delay. One target can belong to several target groups, which is how a single instance serves multiple ports or apps.

The target type is chosen at creation and cannot change: instance, ip, lambda or alb.

A listener is the process that checks for incoming connection requests on a specific protocol and port, such as HTTPS on 443.

On an ALB each listener has a default action plus optional rules that decide where a request goes. On an NLB the listener forwards to a target group, and TLS listeners also hold a certificate. A load balancer can have several listeners, for example 80 for redirects and 443 for the app.

• ALB listener protocols: HTTP, HTTPS
• NLB listener protocols: TCP, UDP, TCP_UDP, TLS
• GWLB uses a single listener that accepts all IP packets

A listener rule tells an ALB what to do with a request. Each rule has a priority, one or more conditions and one or more actions. Rules are checked from the lowest priority number upward, and the default rule runs last.

• Conditions: host-header, path-pattern, http-header, http-request-method, query-string, source-ip
• Actions: forward, redirect, fixed-response, authenticate-cognito, authenticate-oidc

aws elbv2 create-rule --listener-arn $LISTENER --priority 10 \
  --conditions Field=path-pattern,Values='/api/*' \
  --actions Type=forward,TargetGroupArn=$API_TG

Each rule can hold up to five condition values per condition type and a rule can combine several condition types, for example a host header and a path. All conditions in one rule must match (AND), while multiple values inside a single condition are matched with OR.

The difference is the scheme. An internet-facing load balancer has public IP addresses, sits in public subnets that route to an internet gateway, and its DNS name resolves to public IPs. It accepts traffic from anywhere that the security groups allow.

An internal load balancer has only private IPs and its DNS name resolves to private addresses, so it is reachable only from inside the VPC, peered VPCs, VPN or Direct Connect.

A common three-tier layout uses an internet-facing ALB for the web tier and an internal ALB between the web and application tiers. Routing and health checks work the same in both.

A health check is a periodic request the load balancer sends to each target. Targets that keep failing are marked unhealthy and receive no new traffic until they pass again.

These are the ALB defaults you can tune per target group:

Point the check at a lightweight path like /health that also confirms the app's critical dependencies are reachable.

With cross-zone load balancing, each load balancer node distributes its traffic across all registered targets in every enabled Availability Zone, not just its own. Without it, each node only uses targets in its own zone.

Take two targets in AZ-A and eight in AZ-B. DNS splits traffic 50/50 between the two zone nodes. With cross-zone off, each AZ-A target gets 25% and each AZ-B target about 6%. With it on, every target gets 10%.

When a target is deregistered or marked unhealthy it enters the draining state. The load balancer stops sending it new requests but lets in-flight requests finish. This window is the deregistration delay.

The default is 300 seconds, configurable from 0 to 3600. If requests take a second or two, lower it to 30 or so so deployments and scale-in finish faster. For long uploads or WebSockets, keep it higher.

When the delay expires, remaining connections are closed. On an NLB you can also choose whether to terminate connections on deregistration.

Sticky sessions (session affinity) bind a client to one target for a period so repeat requests land on the same server. You enable them in the target group attributes.

• Duration-based: the ALB issues an AWSALB cookie, valid from 1 second to 7 days
• Application-based: the ALB issues AWSALBAPP and ties it to your own app cookie
• NLB: stickiness is based on the client source IP

The downside is uneven load and lost sessions when a target dies or scales in. A better long-term design keeps session state in ElastiCache or DynamoDB so any target can serve any user.

You attach a target group to the Auto Scaling group, and the group handles registration for you.

1. Create a target group and an ALB listener that forwards to it
2. Attach the target group to the Auto Scaling group
3. New instances register automatically once launched, and terminating instances deregister (honouring draining)
4. Set the group's health check type to ELB so instances failing load balancer checks are replaced
5. Add a target tracking policy on ALBRequestCountPerTarget

Set a health check grace period that covers boot and app start time, or new instances may be killed before they are ready.

Path-based routing sends requests to different target groups based on the URL path. You add a listener rule with a path-pattern condition.

Patterns support * and ? wildcards and are case-sensitive. This lets one ALB front several microservices under a single domain.

Order matters. Give specific paths such as /api/v2/* a lower priority number than broader ones like /api/*, or the broader rule will capture the request first. Each target group can have its own health check path, so the API and static fleets are checked independently.

Host-based routing picks a target group from the Host header, using a host-header condition. For instance, api.example.com goes to the API fleet and shop.example.com to the storefront.

Wildcards work, so *.example.com can match every tenant subdomain. You can combine host and path conditions in one rule, and both are matched case-insensitively for host names.

This is the usual way to host many tenants or services behind one ALB and one public IP set. Pair it with an HTTPS listener holding one certificate per domain, or a wildcard certificate, so SNI picks the right certificate before the host rule picks the target group.

Terminate TLS on the ALB by adding an HTTPS listener with a certificate.

1. Request or import a certificate in AWS Certificate Manager
2. Create an HTTPS listener on port 443
3. Attach the certificate and choose a TLS security policy
4. Forward to a target group
5. Allow inbound 443 in the ALB security group

Targets can stay on HTTP (SSL offload) or you can use an HTTPS target group to re-encrypt traffic to the backend when compliance requires encryption in transit end to end.

Because the ALB terminates the client connection, your targets see the load balancer's IP, not the user's. The ALB adds X-Forwarded-For containing the client IP so the app can log or act on it.

It also sets X-Forwarded-Proto (http or https) and X-Forwarded-Port. If the request already had an X-Forwarded-For value, the ALB appends the new IP, giving a comma-separated list where the left-most entry is the original client.

Never trust it blindly for security decisions, since clients can send a forged value. An NLB does not use this header; it preserves the source IP instead.

The target type depends on the load balancer.

ip targets can be private addresses in the VPC, a peered VPC, or on-premises servers reached over VPN or Direct Connect. The alb type lets an NLB forward to an ALB, giving you static IPs in front of layer 7 routing.

Choose ip when targets are containers with their own ENI, when you need several ports on one host, or when the backend lives outside the VPC. Choose instance for classic EC2 fleets managed by Auto Scaling, where registration is automatic.

ELB pricing has two parts: an hourly charge for each running load balancer, and a usage charge measured in capacity units: LCU for ALB, NLCU for NLB and GLCU for GWLB.

An LCU counts the highest of four dimensions in each hour, and you pay only for that one:

• New connections: 25 per second
• Active connections: 3,000 per minute
• Processed bytes: 1 GB per hour for EC2 targets
• Rule evaluations: 1,000 per second

Public IPv4 addresses used by the load balancer are billed per hour as well, and standard data transfer charges still apply.

Chain security groups so the targets only accept traffic that came through the load balancer.

1. ALB security group: allow inbound 80/443 from the internet (or a restricted CIDR)
2. Target security group: allow the app port only from the ALB security group ID, not from 0.0.0.0/0
3. Put targets in private subnets with no public IPs
4. Use an HTTPS target group if traffic must stay encrypted inside the VPC
5. Attach AWS WAF to the ALB for application-layer filtering

Remember the health check port too, otherwise targets turn unhealthy even though the app is fine.

Keep an HTTP listener on port 80 whose default action is a redirect to HTTPS on 443. No target group is needed on that listener.

{
  "Type": "redirect",
  "RedirectConfig": {
    "Protocol": "HTTPS", "Port": "443",
    "Host": "#{host}", "Path": "/#{path}", "Query": "#{query}",
    "StatusCode": "HTTP_301"
  }
}

Use HTTP_301 for a permanent redirect. Use HTTP_302 while testing, since browsers cache 301 responses aggressively.

The security group on the ALB must allow port 80 as well as 443, otherwise browsers never reach the redirect. Also confirm the HTTPS listener exists and has a valid certificate before enabling the redirect, or users get a connection error instead of the site.

ELB publishes metrics to CloudWatch every minute under AWS/ApplicationELB (ALB) or AWS/NetworkELB (NLB). The ones worth alarming on:

Pair metrics with access logs when you need per-request detail.

A useful starter alarm set is: UnHealthyHostCount above 0 for five minutes, HTTPCode_ELB_5XX_Count above a small threshold, and TargetResponseTime p95 above your latency budget. Use the load balancer and target group dimensions together to see per-service behaviour, and add the RejectedConnectionCount metric to spot connection limits being hit.

Every load balancer gets an AWS DNS name like my-alb-123456.us-east-1.elb.amazonaws.com. It resolves to the IPs of the load balancer nodes, and those IPs can change as it scales, so never hardcode them.

Create a Route 53 alias record (A and AAAA) pointing your domain at the load balancer. Alias records work at the zone apex such as example.com, where a CNAME is not allowed, and queries to alias records for AWS resources are free.

With another DNS provider you can use a CNAME for subdomains like www.

An ALB is a layer 7 balancer that understands HTTP and makes routing choices from request content. An NLB is a layer 4 balancer that forwards connections without looking inside them.

Choose ALB for web apps and microservices, and NLB for non-HTTP protocols, fixed IPs or extreme throughput.

Cost and operations differ too. Both bill by the hour plus capacity units, but NLB's lower per-connection overhead suits very chatty, long-lived connections, while ALB's rich rules reduce the number of load balancers you need because one ALB can front many services.

Pick an NLB when the job is moving connections quickly and predictably rather than understanding requests.

• The protocol is not HTTP: UDP games, MQTT, DNS, SMTP, custom TCP
• Partners need to allowlist fixed IPs
• You face sudden spikes or millions of requests per second
• You are publishing a service via AWS PrivateLink
• Backends need the original client IP, or you want TLS passthrough

If you need both, register an ALB as an NLB target: clients see static IPs and you keep path and host routing behind them.

Stay with an ALB when you want layer 7 features: WAF, Cognito or OIDC login, redirects, header or path routing, or Lambda targets. Those are exactly the things an NLB cannot do, since it never reads the request.

An NLB creates one load balancer node per enabled subnet, and each node is backed by a network interface with a fixed IP. For internet-facing NLBs you can assign an Elastic IP to each node, and for internal ones you can pick the private IP from the subnet.

This helps when customers or partners firewall by IP address. An ALB cannot do this because its node IPs change as it scales.

To get static IPs for an ALB, either put an NLB in front with an ALB-type target group, or use AWS Global Accelerator, which gives two static anycast IPs.

Plan the subnets carefully. Every AZ you enable gets its own address, so a design with three AZs gives partners three IPs to allowlist. Adding an AZ later adds a new IP, which partners must be told about before you switch it on.

The ALB picks a target group first through listener rules, then picks a target inside it using the group's routing algorithm. Three are available:

Slow start mode works only with round robin. An NLB, by contrast, uses a flow hash on the connection tuple, so one connection always stays on one target.

Pick least outstanding requests when some requests take seconds and others milliseconds, because round robin can pile slow requests on one target. Pick weighted random when a faulty target returns errors fast, since anomaly mitigation shifts traffic away from it automatically. Round robin stays fine for uniform workloads.

If every target fails health checks in all enabled Availability Zones, the ALB fails open: it sends requests to all targets anyway, ignoring health status.

The reasoning is that a wrong health check (a bad path, a changed port) should not turn a working app into a total outage. Some requests may still succeed, and the app keeps serving.

This is different from a target group with no registered targets, where the ALB returns 503. Treat fail open as a signal to fix your health check or app quickly, since users may see errors.

Before relying on this behaviour, set CloudWatch alarms on UnHealthyHostCount. Fail open protects against a mistaken health check, but if the targets are really down users will still see errors, and you want to be paged before they report it.

ELB places a load balancer node in each Availability Zone you enable. DNS returns the IPs of all healthy nodes, so clients spread over them, and each node routes to targets.

flowchart LR
  C[Client] --> D["DNS lookup"]
  D --> N1["LB node AZ-A"]
  D --> N2["LB node AZ-B"]
  N1 --> T1["Targets AZ-A"]
  N1 -.cross-zone.-> T2["Targets AZ-B"]
  N2 --> T2
  N2 -.cross-zone.-> T1

If an AZ has no healthy targets or its node fails, ELB stops returning that node's IP and traffic moves to the other zones. With cross-zone enabled the surviving nodes can also use targets in other zones. Enable at least two AZs (ALB requires this) and keep targets in each. Zonal shift in Route 53 ARC lets you drain a zone manually.

A 502 means the ALB reached the target but got an invalid or no response. The usual causes:

• Target closed the connection before replying, often because its keep-alive timeout is shorter than the ALB idle timeout
• Malformed HTTP response or invalid headers
• HTTPS target group but the target fails the TLS handshake
• Lambda target returned a response in the wrong format or crashed

Check HTTPCode_ELB_502_Count and the access log's error_reason field. The most common fix is setting backend keep-alive higher than the ALB idle timeout, for example above 60 seconds, such as 65 in Node.js or Nginx.

To confirm, capture an access log line and compare elb_status_code with target_status_code. A 502 with a target status of - means the target never sent a valid response, which points to a closed connection or a crash rather than an application error.

A 503 means the ALB has no target to send the request to.

• The target group has no registered targets
• A listener rule forwards to an empty target group, for instance after an Auto Scaling group scaled to zero
• A Lambda target is being throttled
• In rare cases the ALB is still scaling during a very sharp spike

Check the target group's registered targets and the HTTPCode_ELB_503_Count metric. Note that targets which are merely unhealthy do not cause 503 when all of them fail, because the ALB fails open.

To tell it apart from an unhealthy-target problem, look at the target group's registered list first. An empty list means the cause is registration, such as a failed deployment or an Auto Scaling group with a desired capacity of zero, not the application itself.

A 504 means the ALB could not connect to the target in time, or the target did not respond before the idle timeout (60 seconds by default).

1. Check security groups and NACLs allow the ALB to reach the target port
2. Look at TargetResponseTime to spot slow endpoints
3. Investigate slow downstream calls such as databases or third-party APIs
4. Raise the ALB idle timeout only for endpoints that truly need long processing
5. Move long jobs to an asynchronous pattern with a queue

Raising the timeout hides slow code, so fix the cause first.

Remember that the ALB waits for a connection to the target for 10 seconds before giving up, which is a different clock from the idle timeout. A 504 within about 10 seconds usually means a network block, while one at around 60 seconds usually means a slow application.

The idle timeout is how long a connection can carry no data before the load balancer closes it.

For ALB, make sure backend keep-alive is longer than the idle timeout, otherwise the target may close a connection the ALB is about to reuse and you get 502s. For long-lived WebSockets or slow uploads, send heartbeats or TCP keepalives so the connection never sits idle.

Clients behind NAT devices can also drop idle flows earlier than the load balancer does, so a short keepalive interval, say every 30 seconds, is a safe default for long-lived sessions such as MQTT or WebSockets.

GWLB inserts a fleet of inspection appliances into the traffic path without changing client or server configuration.

sequenceDiagram
  participant C as Client
  participant E as GWLB Endpoint
  participant G as GWLB
  participant A as Appliance
  participant S as App Server
  C->>E: Packet via route table
  E->>G: Forward over PrivateLink
  G->>A: GENEVE encapsulated (UDP 6081)
  A->>G: Inspected packet
  G->>E: Return
  E->>S: Deliver to destination

1. Route tables (including an ingress route table on the internet gateway) send traffic to the GWLB endpoint
2. The endpoint forwards it to the GWLB through PrivateLink
3. GWLB picks an appliance using a 5-tuple flow hash and wraps the packet in GENEVE
4. The appliance inspects, allows or drops, then returns it
5. GWLB hands it back to the endpoint, which delivers it onward

The same appliance sees both directions of a flow, and health checks remove failed appliances from rotation. Appliances must understand GENEVE.

For instance targets, the NLB keeps the original client source IP by default, so the target sees the real address in the TCP or UDP packets. No header is needed.

For IP targets with TCP and TLS, preservation is off by default and targets see the NLB's private IP. You control it with the target group attribute preserve_client_ip.enabled.

One caveat is hairpinning: if a target connects to the NLB and the flow is routed back to that same target with the client IP preserved, the connection fails. Where preservation is off, enable Proxy Protocol v2 to pass the client details.

Security groups on the targets should therefore allow the real client ranges when preservation is on, because traffic no longer appears to come from the NLB. When preservation is off, allow the NLB's subnets instead.

Proxy Protocol v2 is a binary header the NLB adds at the start of a TCP connection, carrying the original client and destination address and port. When the connection is routed through PrivateLink it also includes the VPC endpoint ID.

Use it when client IP preservation is not available or turned off, such as IP-type targets or services published via PrivateLink. You enable it in the target group attributes.

The application or proxy on the target must parse the header. If it does not, it will see garbage bytes and the connection fails, so enable it only after the backend (Nginx, HAProxy, your app) is configured for it.

Server Name Indication (SNI) lets one listener serve several domains with different certificates. The client includes the host name in the TLS ClientHello, and the load balancer uses it to pick the matching certificate.

You attach a default certificate plus additional certificates to the HTTPS listener (ALB) or TLS listener (NLB). If no certificate matches, the default is used.

ALB chooses the best certificate for the client, preferring ECDSA over RSA when both match and the client supports it. The Classic Load Balancer does not support SNI, so each of its listeners holds a single certificate.

In practice, request one ACM certificate per domain or a certificate with several names, attach all of them to the listener, and test each host name with openssl s_client -servername. Old clients that do not send SNI will receive the default certificate.

Run the old version (blue) and new version (green) in separate target groups and shift traffic using the forward action with weights.

aws elbv2 modify-listener --listener-arn $L --default-actions '[{
  "Type":"forward",
  "ForwardConfig":{"TargetGroups":[
    {"TargetGroupArn":"'$BLUE'","Weight":90},
    {"TargetGroupArn":"'$GREEN'","Weight":10}]}}]'

1. Deploy green and wait for healthy targets
2. Send 10% of traffic to green and watch error and latency metrics
3. Increase gradually to 100%
4. Roll back instantly by setting blue to 100

Enable target group stickiness on the forward action if users must stay on one version during the shift.

Keep the blue fleet running until the green fleet has served full traffic through a normal peak, since removing it early takes away your instant rollback. After that, drain and scale blue down, and make green the new baseline for the next release.

You add an authenticate-cognito or authenticate-oidc action ahead of the forward action in an HTTPS listener rule. The ALB handles the login so your app does not need to.

1. Unauthenticated user hits the ALB
2. ALB redirects them to the identity provider
3. After login the provider sends an authorization code back to the ALB
4. ALB exchanges it for tokens, sets an AWSELBAuthSessionCookie, and forwards the request

Targets receive user claims in x-amzn-oidc-data (a signed JWT), plus x-amzn-oidc-identity and x-amzn-oidc-accesstoken. Verify the JWT signature in the app. OnUnauthenticatedRequest can be authenticate, deny or allow.

Set the session timeout to match your security policy, since the ALB cookie lasts up to 7 days by default. Also register the ALB's /oauth2/idpresponse URL as an allowed callback in the identity provider, or the login round trip will fail.

You associate a regional AWS WAF web ACL with the ALB. Requests are inspected before routing, and blocked ones never reach your targets.

• AWS managed rule groups for OWASP-style threats, bots and known bad inputs
• Rate-based rules to throttle abusive IPs
• IP set and geo match rules
• Custom rules on headers, URI, query string or body

WAF works with ALB but not with NLB, so for non-HTTP traffic you rely on security groups and NACLs. Enable WAF logging to see which rule blocked a request.

Start new rules in Count mode, review the logs for false positives, and only then switch to Block. This avoids blocking legitimate users while you tune managed rule groups.

Create a target group of type lambda, register the function, and forward a listener rule to it. The ALB invokes the function synchronously for each request.

1. Grant permission to elasticloadbalancing.amazonaws.com to invoke the function
2. ALB converts the HTTP request into a JSON event
3. Function returns JSON with statusCode, headers, body and isBase64Encoded
4. ALB converts it back into an HTTP response

def handler(event, context):
    return {"statusCode": 200,
            "headers": {"Content-Type": "text/html"},
            &quot;body&quot;: &quot;<h1>Hello from Lambda</h1>&quot;,
            &quot;isBase64Encoded&quot;: False}

Request and response payloads are limited to 1 MB, and health checks are off by default for Lambda target groups.

This is handy for small APIs, health pages or admin endpoints that do not justify a server. If clients send multiple values for one header or query parameter, enable multi-value headers on the target group so none are lost.

The AWS Load Balancer Controller runs inside the cluster, watches Kubernetes objects and creates ELB resources for them.

flowchart LR
  I[Ingress] --> C["LB Controller"]
  S["Service type LoadBalancer"] --> C
  C --> ALB[ALB]
  C --> NLB[NLB]
  ALB --> P[Pods]
  NLB --> P

• Ingress resources become an ALB with listener rules
• Service of type LoadBalancer with the controller's class becomes an NLB
• target-type: ip registers pod IPs directly, skipping NodePort and kube-proxy hops
• target-type: instance sends traffic to NodePorts on worker nodes

metadata:
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip

The controller needs IAM permissions, typically through IRSA or EKS Pod Identity.

Use IP mode in most clusters: it removes the extra hop through kube-proxy, lowers latency, and lets the ALB drain pods precisely during rolling updates when combined with pod readiness gates.

With bridge networking you set the container's host port to 0 and ECS picks a free ephemeral port for each task. ECS then registers instance-ID:port with the ALB target group.

This lets several copies of the same service run on one EC2 instance, each on a different host port, while the ALB still reaches all of them.

The instance security group must allow the ephemeral port range from the ALB security group. With awsvpc mode each task gets its own ENI and IP, so you use an ip target type and a fixed container port instead.

The target group health checks then run against the dynamically assigned port, so keep the health check port set to traffic-port rather than a fixed number. Otherwise every task would look unhealthy.

With mutual TLS (mTLS) the client must present a certificate as well as the server. You enable it on an HTTPS listener and give it a trust store, a CA certificate bundle kept in S3, with an optional revocation list.

Verify mode is the safer default for APIs and B2B integrations, since invalid clients are rejected at the edge before they cost you any backend capacity.

Certificate details arrive in headers such as X-Amzn-Mtls-Clientcert-Subject, which the app can use for authorisation, for example mapping a certificate subject to a customer account.

Slow start mode gives a newly registered target a gradually increasing share of requests during a warm-up window, instead of its full share immediately. The window is 30 to 900 seconds and it is off by default.

It protects apps that need time to warm up, such as JVMs that must JIT-compile code or services filling caches. Without it, a fresh target can be flooded and fail health checks.

It works only with the round robin algorithm. It is not supported with least outstanding requests or weighted random. A target leaves slow start when the window ends or it becomes unhealthy.

Choose a duration that matches your measured warm-up time. A value that is too short defeats the purpose, while a very long one leaves new capacity underused when you scale out during a spike.

Start from the reason code in the target group's Targets tab, then work through the network and app.

1. Confirm the app is listening on the health check port and interface
2. Allow the ALB security group to the health check port
3. Curl the health path from another host in the VPC
4. Check the matcher (a redirect 301 fails if only 200 is accepted)
5. Allow enough time for startup versus thresholds and grace period

If everything looks right but targets still fail, compare the health check path with what users hit. A path that needs authentication or a database call can fail only under the load balancer's anonymous request, so use a dedicated lightweight endpoint.

Access logs are optional and off by default. Turn them on in the load balancer attributes and choose an S3 bucket.

1. Create an S3 bucket in the same Region
2. Add a bucket policy that allows ELB log delivery
3. Enable access logs on the ALB
4. Logs are delivered about every five minutes as compressed files

Each line records the time, client IP and port, target, three processing times, ELB and target status codes, the request line, user agent, TLS cipher and an error reason when relevant.

Query them with Amazon Athena to find slow endpoints or 5xx spikes. ALB also offers separate connection logs for TLS details.

Logs can hold sensitive paths and IPs, so encrypt the bucket and set a lifecycle rule that expires old objects. Partition the Athena table by date to keep query costs low.

ELB balances live connections or requests across healthy targets inside a Region. Route 53 balances at the DNS layer by returning different answers to name lookups.

They work together: Route 53 latency or failover records point users to the nearest healthy Region, and an ELB in each Region balances across its targets.

Because resolvers cache answers for the TTL, a Route 53 failover can take minutes to take effect for some users, while an ELB stops sending traffic to a failed target within a few health check intervals. Keep TTLs low, such as 60 seconds, on records used for failover.