Proposed flow for this scenario
- Listener uses target group
- Registered eligible target
- Health port and path
- SG and NACL request/reply
- Synthetic response and matcher
- Threshold-driven state
This flow describes a design to evaluate. Follow the supported console workflow below to practice with local resources. Its scope appears with the controls; no cloud resources are provisioned.
Decision checkpoints
| Choice | Fits when | Watch for |
|---|---|---|
| Network repair | The health request or return traffic is blocked. | Opening the worker publicly when the intended source is the ALB. |
| Health contract repair | The application path or response does not match readiness expectations. | Marking every error code healthy to obtain a green badge. |
Identify the target and its reason
For synthetic QuantumSketch, open the target group actually used by the listener. Confirm the registered target and zone rather than inspecting another healthy group. Record whether the state is initial, unhealthy, unused or draining and the reason exposed by the local diagnostic.
An EC2 running state proves a lifecycle state, not a listening process or a valid health endpoint. A new task or instance may also be registered but still await the selected health checks. Keep useful capacity distinct from desired count.
Follow the health path and response
Inspect target port, health-check path and expected matcher. Then check ALB egress, target ingress and stateless ACL request/reply rules. An application returning the wrong response and a blocked packet path can both produce unhealthy targets, but require different repairs.
For real infrastructure, verify the application listener and the actual health request behavior as well. Host handling, response timing and readiness logic can matter. Do not change several rules or broaden the success matcher before understanding the observed failure.
Reproduce a selected local fault
Register a synthetic target with a known local application response, observe a healthy result, then set a failing health response or remove its modeled access. Inspect the stated reason and restore only that boundary.
Advance the selected health-check intervals and recheck threshold-driven recovery. This model samples configuration and preset responses; it sends no live HTTP. It does not prove host readiness, container correctness or every real ALB health feature.
Changed scenario and fail-open
Question: all registered targets are unhealthy in every enabled Availability Zone, but the ALB still attempts a request. Does that prove health checks are disabled? No. AWS documents fail-open behavior for that condition. The local diagnostic labels its selected fail-open attempt; empty groups and unavailable target placement are different cases.
A successful synthetic attempt is not a substitute for restoring healthy capacity. Verify the intended target selection and useful customer operation after repair. Use the target-group and load-balancer console links below to inspect the selected local configuration and health transitions; they do not reproduce production probing or latency.
Practice the supported console workflow
Sources and scope
Reviewed against these official references. The model’s supported scope appears alongside its controls.
How we review explanations