[APIGateway] LambdaIntegration: Add option to create a single trigger/permission with wildcards only instead of one for each ApiGateway Resource

[phrastnik]

For the Lambda ApiGateway integration, add an option to prefer a single wildcard trigger/integrationPermission instead of multiple triggers/integrationPermissions for each URL/endpoint/resource defined in the ApiGateway.

Currently the created triggers in the AWS console looks like that:

arn:aws:execute-api:us-east-1:123:api_id/prod/GET/v1/parent_res_1/*
arn:aws:execute-api:us-east-1:123:api_id/prod/POST/v1/parent_res_1/*
arn:aws:execute-api:us-east-1:123:api_id/prod/GET/v1/parent_res_2/*
...

The requested feature would allow to have something like that instead:

arn:aws:execute-api:us-east-1:123:api_id/*

Use Case

In case of APIs with a larger amount of urls/endpoints/resources, it is likely to get a "The final policy size (XXX) is bigger than the limit (20480)" error.

In our case, we run into that for an API with around 15 resources and worked around temporarily by setting LambdaIntegrationOptions.allowTestInvoke to false. This cut the number of triggers/IntegrationPermissions in half and the policy didn't hit the limit anymore.
However, we would prefer leaving allowTestInvoke to true.
Moreover as the API grows over time, we will likely run into the same issue again later: the faster the API grows, the sooner. Implementing something like described in #5774 (comment) (also see below) currently seems to be something like a last resort for us.

Implication of the current state of CDK in this respect for us is that the CDK ApiGateway -> LambdaIntegration cannot be easily used for APIs with a considerable amount of endpoints because the CDK stack will break sooner or later when adding more resources to the APIGateway.

Proposed Solution

• Add boolean option singleWildcardTrigger or singleWildcardIntegrationPermission to aws_cdk.aws_apigateway.LambdaIntegrationOptions.
• Per default, it is false and everything works like as it does currently.
• In case of true, only a single trigger with wildcards is generated (see above).
• With the existing allowTestInvoke option, there is already an option which works globally an all tiggers/integrationPermissions as well. So something very similar is already available.

Other

There is a similar (duplicate?) issue which as been closed already #5774 (closed #5774 (comment) by AWS).
The discussions in the end (after closing by AWS) are about workarounds (subclassing CDK) for something which seems to be missing as a feature, thus I created a new issue. Feel free to reopen the original one and add this as a duplicate.

Please also check #5774 (comment) which has been added after closing the issue. This comment describes the problem exactly the same as we see it.

---

This is a 🚀 Feature Request

[nija-at]

Thanks for filing this issue. I'd like to understand this issue a little more, before looking at the solution.

Which specific resource's policy size is reaching the limit? Is this the policy for the lambda function?
Are you using the same lambda function for all your Rest API methods and resources?

Can you provide a code sample of relevant CDK code so I can see how you are using this? Specifically, how you are setting up the RestApi and LambdaIntegration.

[phrastnik]

Thanks nija-at for looking into that. Here the additional information:

• Which specific resource's policy size is reaching the limit? Is this the policy for the lambda function?
  Yes, it's the policy for the lambda function.

• Are you using the same lambda function for all your Rest API methods and resources?
  Yes we do. We're running a lot of different Lambdas and APIs backed by Lambdas in our account and region. Additionally, 2 stages (staging, prod) are also running in this account in us-east-1. So adding a dedicated Lambda for each resource for each API for each stage seemed to be not the way to go - the resulting high number of Lambdas would be hard to manage.

• Can you provide a code sample of relevant CDK code so I can see how you are using this? Specifically, how you are setting up the RestApi and LambdaIntegration.

This is the code, would be nice if it's possible to do something in different way to avoid hitting the policy limit.

    public void defineApiGateway(CisStackProps cisStackProps, FunctionBase lambda) {   
	   //... some init code ...
	   RestApi api = RestApi.Builder.create(this, cisStackProps.getApiGatewayInternalName())
               .restApiName(cisStackProps.getApiGatewayInternalName())
               .endpointConfiguration(
                       EndpointConfiguration.builder()
                       .types(List.of(EndpointType.PRIVATE))
                       .vpcEndpoints(List.of(vpcEndpoint))
                       .build()
                       )
               .deploy(Boolean.TRUE)
               .deployOptions(StageOptions.builder()
                       .stageName(cisStackProps.getEnvPostfix())
                       .loggingLevel(MethodLoggingLevel.INFO)
                       .tracingEnabled(Boolean.TRUE)
                       .dataTraceEnabled(Boolean.TRUE)
                       .accessLogDestination(
                               new LogGroupLogDestination(LogGroup.fromLogGroupName(this, "apiGatewayAccessLogGroup_" + cisStackProps.getEnvPostfix(), cisStackProps.getApiGatewayInternalLoggroupName()))
                        )
                       .accessLogFormat(AccessLogFormat.clf())
                       .build())
               .cloudWatchRole(Boolean.FALSE)
               .policy(PolicyDocument.fromJson(this.createResourcePolicy(vpcEndpoint.getVpcEndpointId())))
               .build();
	   
	   //... other configs like domainName, apiKey(s), usagePlans  ...
	   
	   LambdaIntegration lambdaIntegration = new LambdaIntegration(
               lambda, 
               LambdaIntegrationOptions.builder()
                   .allowTestInvoke(Boolean.FALSE) //This is the workaround in place, the policy size is reduced because no additional testInvoke policy entries are created
                   //.singleWildcardIntegrationPermission(Boolean.TRUE) This would be a proposal for the suggested additional feature, currently not working, of course                   
                   .build()
           );
	   
	   //LambdaIntegration lambdaIntegration = new LambdaIntegration(lambda); -> this caused the error as the Lambda policy would get too large with all the additional testInvokes for each resource
	   
       
           IResource v1Res = api.getRoot().addResource("v1");
           IResource assetsRes = v1Res.addResource("assets");
           IResource videoRes = assetsRes.addResource("video");
           this.prepareResource(lambdaIntegration, videoRes, "POST");
	   
	   IResource videoByIdRes = videoRes.addResource("{guid}");
           this.prepareResource(lambdaIntegration, videoByIdRes, "GET");
           
           //... more resource defintions, the more we add, the more we fear that the policy size hits the limit and we have no acceptable workarounds anymore

	}

    private void prepareResource(Integration integration, IResource res, String method) {
        this.addIntegration(integration, res, method);
        this.addCorsOptions(res);  //this adds CORS responses to the resource, no LambdaIntegration but MockIntegration, so should not be relevant for the issue
    }

    private void addIntegration(Integration integration, IResource res, String method) {
        res.addMethod(method, integration,
                MethodOptions.builder()
                        .apiKeyRequired(Boolean.TRUE)
                        .build()
        );
    }

Hope that helps, happy to give some more information if necessary,
Peter.

[nija-at]

Thanks Peter.

This is something we can improve in the CDK, however, I think we can do better than adding another property.

We should look into doing something more automatic - detect when the list of policies has reached a certain count and attempt to collapse them into a shorter prefix match, such as in your case.