A city portal must send a small share of Application Load Balancer requests to a new target group and leave the rest on the current group. Changing the public DNS record and waiting out a long TTL was proposed. What should carry the canary?
Select an answer to reveal the explanation.
Short Explanation
Shift a little traffic at the door instead of reprinting every map. You weight the listener forward action so a small share hits the new target group while the current group keeps the rest. The trap is canarying with a DNS TTL when the balancer already knows both groups.
Full Explanation
An Application Load Balancer forward action can list more than one target group, each with a weight. A small weight on the new group and the remaining weight on the current group sends only that share of requests to the canary, and moving the weights back is the rollback. A DNS cutover changes name resolution, waits on resolver caches for the TTL, and does not split requests across target groups behind the same balancer. An in-place swap of every target puts the full request rate on the new build at once. A geolocation record selects by country, so the canary would be one country's users rather than a small share of all requests. Weights apply to requests the listener forwards, and stickiness can keep a returning client on the group it already used, so the mix of unique clients can differ from the weight. Set the small weight, compare request counts on the two target groups, and confirm the new group receives only the small share. Keep both target groups registered and healthy before shifting weight, or the small share lands on targets that fail their checks.