custom-resource-apigw-cw-role lambda gets created through serverless framework and how can I change it's runtime

[sadashiv-sumasoft]

Are you certain it's a bug?

• [X] Yes, it looks like a bug

Is the issue caused by a plugin?

• [X] It is not a plugin issue

Are you using the latest v3 release?

• [X] Yes, I'm using the latest v3 release

Is there an existing issue for this?

• [X] I have searched existing issues, it hasn't been reported yet

Issue description

I got a notification from AWS like Fwd: [Action Required]. AWS Lambda ends support for Node.js 16. When I hit the CLI command provided, I got to know that some custom-resource-apigw-cw-role lambda gets created, and it has the node 16.x runtime that gave me a warning.

How could I change the AWS-managed function runtime?

Service configuration (serverless.yml) content

N/A

Command name and used flags

sls deploy

Command output

N/A

Environment information

Framework Core: 3.33.0
Plugin: 6.4.0
SDK: 4.4.0

[tschumann]

It's hard-coded in lib/plugins/aws/custom-resources/index.js - I guess that should be updated to nodejs18.x or nodejs20.x

[sadashiv-sumasoft]

Yes, making that change is working well, but the next version should address this problem. The problem is that we cannot change that hard-coded value when we are deploying services through the pipeline and codebuild project.

[bradwood]

Hi

Any updates on this one -- the AWS cutoff for node 16 is fast approaching.

[Mmarzex]

@bradwood this is going to be fixed in the v4 beta coming out within the next week.

[bradwood]

@bradwood this is going to be fixed in the v4 beta coming out within the next week.

Any updates on this @Mmarzex -- it's been 3 weeks since this comment, but I'm not seeing v4 anywhere...

:pray: thank you

[bradwood]

Got another bunch of emails from AWS about this yesterday.

@Mmarzex ? Is this going upgrade going to happen? Or do I need we need to solve this another way? Maybe just do a 3.x.y patch release, just to fix the runtime? And decouple it from all the v4 stuff?

Just a thought.

[metafounder]

I am also interested in this

[pd-alex]

Same here. Also a bunch of AWS emails. The upgrade to SLS v4 is simply impossible given the size of our infra in the time remained. It would be great to have a 3.x.y patch release to fix this issue.

[JaroVDH]

Seeing how little time we have remaining (June 12), we have to look into alternatives already. We can't exactly keep our fingers crossed we'll eventually get this resolved at this point, so I want to be sure we can still keep our applications going.

Maybe managing the custom resources ourselves through other IaC is an option? Is there an easy way to see which resources were created as custom resource, or should we to go through each Lambda to see what they might've created?

[bradwood]

@JaroVDH we are kinda at this point too - if we can't get rid of this lambda by the cut-off we're going to have to do some kinda hand-rolled alternative. I'm really not keen to go there, as unpicking what it does it likely to be PITA. But we are also up against it now. It's a pity that this issue has not had more focus from the Serverless team. :-/

[whytspace]

if we can't get rid of this lambda by the cut-off

@bradwood I think you can actually get rid of this lambda function.

If you set provider.logs.restApi: false in serverless.(ts|yml|…) the additional lambda function is not generated. Don't know of the disadvantages of that approach though. I guess it has to do with the serverless dashboard, but I do not use that anyway

[JaroVDH]

If you set provider.logs.restApi: false in serverless.(ts|yml|…) the additional lambda function is not generated. Don't know of the disadvantages of that approach though. I guess it has to do with the serverless dashboard, but I do not use that anyway

This removes access logging for the API Gateway, which for many API's is a security requirement. It's easy to manually enable though, so it would be an option as fallback if Serverless cannot support it.

[jinman]

any update on this?

[bradwood]

@Mmarzex can you please let us know where we are with this?

[JaroVDH]

FYI, June 12 won't end up killing any services with custom resources just yet. https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html#runtimes-deprecated

Node.js 16: Deprecation date: Jun 12, 2024 Block function create: Feb 28, 2025 Block function update: Mar 31, 2025

I will still be pushing to remove these custom resources from our deploys before the June deadline, but it's good to know that at least we won't be stuck because of it.

[bradwood]

@JaroVDH thanks for this update. What about the idea of just releasing the runtime change as a 3.x.y release? Surely this is just a small change. Doing this takes all the pressure off waiting for v4 and keeps us all happy.

[JaroVDH]

@JaroVDH thanks for this update. What about the idea of just releasing the runtime change as a 3.x.y release? Surely this is just a small change. Doing this takes all the pressure off waiting for v4 and keeps us all happy.

Sorry for the confusion, I'm not affiliated with Serverless Framework; I'm just another impacted user :)

[bradwood]

Sorry for the confusion, I'm not affiliated with Serverless Framework; I'm just another impacted user :)

My bad -- apologies.

So I wonder if anyone who is part of the Serverless team is going to bother responding into this... It feels like we are just yelling into the abyss here... :cry: