(elasticloadbalancingv2): Allow regex path patterns

[azatoth]

Describe the feature

Currently PathPatternListenerCondition will only allow specifying plain values, but according to https://docs.aws.amazon.com/elasticloadbalancing/latest/application/rule-condition-types.html#path-conditions we can specify regex values instead.

Use Case

when using old style values, you often need to specify two different entries, one for the main level, and one for the children, i.e. ListenerCondition.pathPatterns(["/api", "/api/*"])

Using regex, we would be able to reduce it to a single entry, and/or make it more complex: ListenerCondition.regexPathPatterns(["^/api/?.*$"])

Proposed Solution

add a separate regexPathPatterns function for regex values if we want to keep the backward compatibility of the current function. The difference in the CFN is to use the key RegexValues instead of Values.

Other Information

No response

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

AWS CDK Library version (aws-cdk-lib)

2.231.0

AWS CDK CLI version

2.1033.0

Environment details (OS name and version, etc.)

Ubuntu 24.04.3 LTS

[pahud]

Hi @azatoth,

Thank you for this feature request! This appears to be a valid enhancement that would provide valuable functionality for ALB path pattern matching.

You're correct that AWS Application Load Balancer supports regex path patterns through the RegexValues property in CloudFormation, but the CDK currently only exposes the literal Values property through

aws-cdk/packages/aws-cdk-lib/aws-elasticloadbalancingv2/lib/alb/conditions.ts

Line 116 in 61ee074

values: this.values,

Your proposed solution to add a separate regexPathPatterns function is a good approach that maintains backward compatibility.

This would enable more concise and powerful path matching as you described, reducing multiple literal patterns like ["/api", "/api/*"] to a single regex pattern like ["^/api/?.*$"].

We encourage community contributions for enhancements like this! If you're interested in implementing this feature, please feel free to submit a pull request. The implementation should follow the existing pattern established by other condition types in the conditions.ts file.

Thank you for taking the time to identify this gap and propose a solution!