feat(apigateway): added L2 construct support for Routing Rules on custom domain names #36928
+787
−0
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Issue # (if applicable)
Closes #36917.
Reason for this change
API Gateway supports routing rules on custom domain names to route traffic by path and/or header to different REST APIs. The
DomainNameL2 construct only exposed base path mappings and API mappings; using routing rules required dropping to L1 (CfnRoutingRule), manually building domain name ARNs, and losing synth-time validation. This change adds L2 support so routing rules can be defined with a type-safe API and validated at synth time.Description of changes
RoutingModeenumBASE_PATH_MAPPING_ONLY(default),ROUTING_RULE_ONLY, andROUTING_RULE_THEN_API_MAPPINGto control how the domain routes traffic (mappings only, routing rules only, or rules then mappings).DomainNameroutingModeprop; passed through toCfnDomainName.routingModeisROUTING_RULE_ONLYorROUTING_RULE_THEN_API_MAPPING,addRoutingRule()is allowed andaddBasePathMapping/addApiMappingare disallowed when mode isROUTING_RULE_ONLY(and vice versa), with clear errors.addRoutingRule()enforce this.addRoutingRule(id, options)creates a routing rule with priority, conditions (base paths and/or headers), and action (restApi, optional stage, optional stripBasePath).RoutingRuleL2 constructWraps
AWS::ApiGatewayV2::RoutingRulewith:basePaths?: string[]and/orheaders?: { header, valueGlob }[](AND between path and headers).restApi, optionalstage(defaults to API deployment stage), optionalstripBasePath.domainName: IDomainNameReffor cross-stack or imported domains.AddRoutingRuleOptionsinterfaceNamed type for
addRoutingRule()options (priority, conditions, action) for JSII compatibility.README
New “Custom domain routing rules” subsection under Custom Domains with examples for
addRoutingRule()and standaloneRoutingRule.Integration test
Domain name made unique per stack (
api-${stackName}.example.com) to avoid “domain already exists” conflicts on re-runs.Describe any new or updated permissions being added
None. The change only defines new L2 constructs that create existing CloudFormation resources (
AWS::ApiGateway::DomainNamewithRoutingMode,AWS::ApiGatewayV2::RoutingRule). No new APIs or IAM permissions are introduced.Description of how you validated changes
Unit tests
test/routing-rule.test.ts: path-only, header-only, and combined path+header conditions; standaloneRoutingRulewith imported domain; validation for priority range, header length, and max 2 header conditions.test/domains.test.ts:routingModeon Cfn;addRoutingRulerejected whenBASE_PATH_MAPPING_ONLY;addBasePathMapping/addApiMappingrejected whenROUTING_RULE_ONLY; nomappingwhenROUTING_RULE_ONLY; REGIONAL-only; and “addRoutingRule creates rule and uses domain ARN”.Integration test
integ.routing-rules.ts: stack with domain inROUTING_RULE_ONLY, path-based rule, header-based rule, and catch-all rule; domain name made unique per stack to avoid “domain already exists” on re-runs.Build/lint
yarn buildand lint pass (import order, indentation, JSII, TS6133 addressed).Checklist
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license