AWS / Intermediate: application service contracts / Lesson 9
Load balancing, DNS, and TLS
Connect discovery, listener rules, target health, scaling, and application identity into a complete request path.
On this page
Lesson goals
- Explain the assumptions, responsibilities, and trade-offs of load balancing, dns, and tls.
- Interpret both examples and distinguish declared intent from verified evidence.
- Diagnose the listed failures and justify the worked decisions without using a real AWS account, credential, or service.
Choose the correct traffic abstraction
Elastic Load Balancing offerings serve different protocols and connection models. An Application Load Balancer handles application-layer routing under its documented feature set, while other load-balancer types have different contracts. Do not assume one target type, TLS mode, health model, or network feature applies to all of them. Start from the user protocol, identity requirements, request behavior, failure domains, and backend capabilities. The first synthetic flow record names an ALB-style HTTPS path and separates frontend TLS from target protocol. No listener, certificate, DNS record, load balancer, or target group is created.
client_name: booking.example.invalid
frontend: HTTPS-reviewed-certificate-policy
listener_action: approved-host-and-path-rule
target_protocol: explicitly-selected
target_port: application-contract-defined
authorization: application-owned
claim: no-live-routing-or-certificate-verification
The reserved .invalid name cannot be a real customer endpoint. TLS termination, backend encryption, and application permission are independent review decisions.
Trace listener and target contracts
A listener accepts a protocol and port and applies configured actions or rules to eligible targets. The target groupโs protocol, port, registration, network reachability, and health settings must match the application. A declared target port does not start a listener on the guest or container. The second synthetic diagnostic record contrasts an application listening on 8080 with a target configured for 80. It supports a port-contract investigation rather than proving every unhealthy target is a port error. Review the current target type and platform integration before changing routing, and keep least-privilege traffic rules on every relevant boundary.
target_reference: lab-target-a
application_listener_port: 8080
configured_target_port: 80
synthetic_health: unsuccessful
next_question: verify-port-and-network-contract
not_proven: DNS-or-IAM-failure
The mismatch is a specific lead, not captured AWS output or a complete root cause. No target is queried and no port is opened.
Keep DNS and TLS identity distinct
Route 53 can provide authoritative DNS and supported routing policies, but DNS answers and failover are affected by record configuration, TTL, health evaluation, and client caching. A DNS change is not an instantaneous migration of every existing connection. TLS requires the intended name, trusted certificate, and compatible listener and client policy. Certificate provisioning or managed renewal has validation and ownership prerequisites. A certificate verifies a peer identity according to the clientโs trust policy; it does not grant application permissions. Decide whether encryption also continues between the load balancer and target, because a private subnet is not equivalent to encrypted transport.
Coordinate target health and replacement
Health checks control routing eligibility under the selected load-balancer behavior; they do not replace a full user transaction. Auto Scaling health and replacement policy are another layer and must be configured intentionally. A shallow endpoint can pass while authentication, database writes, or an important customer cohort fails. Conversely, a dependency-sensitive check can remove every target during one shared outage. Design readiness, startup allowance, draining, and long-lived connection behavior as a contract. A traffic switch or target deregistration does not guarantee all accepted work finished, and retries after interruption may need application idempotency.
Verify the end-to-end route safely
Define the bounded user outcome, intended host name, frontend protocol, listener rule, target group, application port, identity, and dependency assumptions. Correlate safe health and application evidence before changing exposure. Include both successful and prohibited cases in an authorized isolated verification, and preserve the exact deployment association. This lesson performs no DNS lookup, certificate request, connection, health check, port forwarding, traffic shift, or cloud call. Its diagrams and records are non-runnable teaching data. A load balancer improves distribution only when target health, surviving capacity, state compatibility, and user authorization are also correctly designed.
Common errors and fixes
A healthy target is assumed to prove booking correctness
- Why it happens
- Routing health replaced the business contract.
- How to fix it
- Verify a bounded authorized user journey separately.
- Prevent it next time
- Keep infrastructure and user-level acceptance evidence.
A DNS change is expected to move every connection immediately
- Why it happens
- Caching and connection lifetime were ignored.
- How to fix it
- Plan TTL, client behavior, draining, and observation.
- Prevent it next time
- Rehearse the selected migration contract in isolation.
Private targets are assumed encrypted
- Why it happens
- Network placement was confused with transport protection.
- How to fix it
- Review target protocol and TLS policy explicitly.
- Prevent it next time
- Document encryption boundaries on the request path.
Check your understanding
1. An ALB listener uses HTTPS while its target uses HTTP. Is the entire path necessarily encrypted?
Show worked solution
No. Client-to-balancer protection and balancer-to-target protection are separate. Evaluate whether the declared data and trust policy permits that target hop or requires TLS there too. Do not infer confidentiality solely from a public HTTPS URL.
2. Targets fail health after a release but DNS still resolves. Which evidence should come next?
Show worked solution
Compare selected target identity, application listener, health path and protocol, startup state, network controls, and safe application logs. Keep DNS and IAM as separate hypotheses unless evidence points there. A targeted contract comparison is more useful than changing every timeout or opening all ports.
Key takeaways
- Elastic Load Balancing offerings serve different protocols and connection models.
- Route 53 can provide authoritative DNS and supported routing policies, but DNS answers and failover are affected by record configuration, TTL, health evaluation, and client caching.
- Define the bounded user outcome, intended host name, frontend protocol, listener rule, target group, application port, identity, and dependency assumptions.