OpenApiGatewayToLambda - Use Existing Lambda Version

[StephenGoodall]

Is it possible to specify a Version/Alias when using the OpenApiGatewayToLambda ApiIntegration with an existing Lambda object?

Use Case

I'm hoping to use OpenApiGatewayToLambda with a versioned Lambda, so I can use SnapStart.
Currently, I believe the construct gets the Function ARN, which is for $LATEST.

Proposed Solution

Possibly have a "existing_lambda_version_obj" or "existing_lambda_alias_obj" type as input for the ApiIntegration - then extract the ARN for that version/alias in the OpenAPI Helper class, when it works out the uriResolvedValue

Other

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

---

This is a 🚀 Feature Request

[biffgaut]

Thanks - we'll take a look.

[biffgaut]

What we're exploring is adding an optional parameter to ApiIntegration that will give you more control over the Lambda function:

export interface ApiIntegration {
  readonly id: string;
  readonly existingLambdaObj?: lambda.Function;
  readonly functionVersion?: number;
  readonly lambdaFunctionProps?: lambda.FunctionProps;
}

1. Would this satisfy your requirements?
2. We're assuming you are supplying an existingLambdaObj parameter, because if lambdaFunctionProps is used to create a new function there will be no published versions. Is this correct?
3. Are you strictly using version, or are there alias considerations at this time? (limiting this answer to what you need now, rather than what you might want in the future will help us get you what you need sooner)

[biffgaut]

Is your Lambda function defined in the same CDK stack as the openapigateway-lambda construct?

We're running into an issue where the number for a newly created version is a token and can't be included in the spec (setting up the gateway from the spec is outside of the CDK and can't process tokens). We're starting to look at aliases as an alternative.

[StephenGoodall]

Thanks for the quick response!

Is your Lambda function defined in the same CDK stack as the openapigateway-lambda construct?

Yes it's in the same stack, snippet below (edited a little for confidentiality 🙂 ):

        # DotNet Bundling
        dotnet_bundling_options = {
            "command": [
                "/bin/sh",
                "-c",
                " dotnet tool install -g Amazon.Lambda.Tools"
                + " && dotnet build"
                + " && dotnet-lambda package --package-location /asset-input --output-package /asset-output/function.zip",
            ],
            "image": lambda_.Runtime.DOTNET_8.bundling_image,
            "user": "root",
        }
        # Create the Lambda function to receive the request - dotnet

        api_handler_FooBar_stringdecode = lambda_.Function(
            self,
            f"FooBarStringDotNet-ApiHandler-{environment}",
            function_name=f"{environment}-FooBar-string-dotnet-openapigw_handler",
            runtime=lambda_.Runtime.DOTNET_8,
            code=lambda_.Code.from_asset("./lambda/APIGWHandlerFooBarStringDotNet/src/APIGWHandlerFooBarStringDotNet", bundling=dotnet_bundling_options),
            handler="APIGWHandlerFooBarStringDotNet::APIGWHandlerFooBarStringDotNet.Function::FunctionHandler",
            vpc=vpc,
            vpc_subnets=ec2.SubnetSelection(
                subnet_type=ec2.SubnetType.PRIVATE_ISOLATED
            ),
            memory_size=1024,
            timeout=Duration.minutes(5),
        )

        # Create the API Integration for the OpenAPI Gateway
        FooBar_string_decode_api_integration = ApiIntegration(id="FooBarStringDecodeFunction", existing_lambda_obj=api_handler_FooBar_stringdecode)

1. Would this satisfy your requirements?

Yeah I think that would work, the SnapStart options seem to just require that you link to a published version, not $LATEST, so anything that can point to a specific version should work. I guess in the CDK, we could create the function, then a version separately. Then pass a property of that Version object in as the functionVersion parameter?

2. We're assuming you are supplying an existingLambdaObj parameter, because if lambdaFunctionProps is used to create a new function there will be no published versions. Is this correct?

Originally I was using the aws_lambda_python_alpha.PythonFunction help bundle up the dependencies, so that's why i was using the existingLambdaObj parameter - I've since figured out how to use the bundling options so I could probably just use the lambda Function Props to build it as part of the ApiIntegration instead.

3. Are you strictly using version, or are there alias considerations at this time? (limiting this answer to what you need now, rather than what you might want in the future will help us get you what you need sooner)

I believe requiring a version is a limitation of the SnapStart feature - but you can also use an Alias as it would point to a specific version (I wasn't planning on using an Alias, but would be happy to do that if it was needed):

This is for something that's still in the proof of concept stage for us, so I'm happy to be flexible and try different things out - I don't have anything strict preferences etc. 🙂

The main reason for using the "OpenApiGatewayToLambda" was just to make it so we had to write the OpenAPI yaml file and kind of force us into having that documentation (otherwise it tends to get let behind as you move on to other work), I did however also build a similar stack using the "traditional" way of adding resources and LambdaIntegrations and that worked with an Alias as the "handler" (possibly as that accepts an IFunction rather than Function), so your idea of using Alias rather than Version sounds like it should work well.

As it's still in the proof of concept stage, I may actually end up using the traditional way, or even SAM as that makes some of the API config a little easier if we switch it over to a HTTP API (such as CORS using the x-amazon-apigateway-cors OpenAPI extension rather than adding it manually per endpoint) - I thought the Alias/Version option was something worth bringing to your attention though as it could be possible that other users may want to use SnapStart now that it's a bit more widely supported