Build ALB listener rule configurations with path, host, header conditions and weighted target group actions.
Build ALB listener rule configurations with path, host, header conditions and weighted target group actions.
Required Fields
ListenerArnPriorityConditionsActionsOutput will appear here...Build an ALB listener rule combining match conditions (host header, path pattern, HTTP header, request method) with a weighted forward action across multiple target groups, useful for canary releases where a small percentage of traffic (20% in the example) is routed to a new target group version. Rule Priority determines evaluation order, ALB checks rules from lowest priority number to highest and stops at the first match, so a broadly-matching low-priority-number rule placed above a more specific one will shadow it entirely, a common cause of 'why is my new, more specific rule never matching' confusion.
Check Priority on the existing rules, ALB evaluates rules in ascending priority-number order and stops at the first match. A broader, lower-priority-number rule (say, a catch-all path-pattern match) that comes before your new, more specific rule will match first and the more specific rule never gets evaluated. Give more specific rules a lower priority number than broader ones, not the reverse.
It's a statistical target based on ALB's weighted random selection per request, not a guaranteed exact ratio over any short window, over a large enough request volume it converges close to the configured weights, but a small sample size can show meaningful deviation. For validating a canary against a specific request-count threshold, watch actual observed traffic rather than assuming the configured weight is instantaneously exact.
Yes, and when you do, ALB requires ALL of them to match (implicit AND) for the rule to fire, not any one of them. If you need an OR relationship between different condition types, you need separate rules with the same action rather than trying to combine them with an OR inside one rule's Conditions array.
The builder validates that ListenerArn, Priority, Conditions, and Actions all resolve before accepting the JSON as a valid CreateRule request, the fields ELB needs to know which listener the rule attaches to, its evaluation order, what triggers it, and what it does; it can't verify that Priority doesn't collide with an existing rule on the same listener, that's checked only against the live listener's current rule set.
Rule priority numbers should generally go from most-specific (lowest number) to least-specific (highest number, ending in the default action), a common mistake is adding new rules with an arbitrarily high priority number assuming 'higher number = higher priority', when ALB actually evaluates lower numbers first.
TargetGroupStickinessConfig matters more than people expect for canary testing, without it, a single user's requests can bounce between stable and canary target groups across the same session, muddying both the user experience and the canary's error-rate signal.
A weighted-target canary rollout needs monitoring on both target groups' health-check and error-rate metrics independently, ALB will happily keep sending 20% of traffic to a canary target group that's silently erroring at a high rate unless you're watching and ready to zero its weight out manually.
Was this tool helpful?
Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.