Does this runtime still use an extra RPC hop by default when used with SAM, and if so, how to disable it?

[refacktor]

According to this article from December 2021, titled "Using a Custom Runtime for Go-Based Lambda Functions,"

the native runtime for Go is split into two programs that communicate via RPC calls.

Is this still accurate in 2023?

The article also provides instructions on how to switch to a more efficient configuration that bypasses RPC:

the aws-lambda-go library you are already using provides a custom runtime mode out of the box. The library has logic to determine whether it is running in a native or custom runtime. This means all you need to do is change your build process to rename the produced binary to bootstrap and it will work in a custom runtime without any changes to the handler code.

and remove unused libraries

The aws-lambda-go library provides a build tag called lambda.norpc to remove all RPC logic from the built binary, reducing its size. Binary size contributes to Lambda cold-start time, so any reduction we make will help improve this metric.

it even provides a revised build command:

GOOS=linux go build -o ./bootstrap ./... -tags lambda.norpc

However, this last point is what's giving me some difficulty. I'm using aws-lambda-go indirectly via SAM (sam init). It is not clear where the above build command can be inserted. It is also not clear whether it's even necessary at this time, about 14 months later.

Any clarification or hints on how to investigate this further, would be great.

[nolotz]

Hi @refacktor,

According to this article from December 2021, titled "Using a Custom Runtime for Go-Based Lambda Functions,"

the native runtime for Go is split into two programs that communicate via RPC calls.

Is this still accurate in 2023?

Yes, adding a go lambda.norpc build tag is still a thing.
What's added without the tag present can be found here

The article also provides instructions on how to switch to a more efficient configuration that bypasses RPC:

the aws-lambda-go library you are already using provides a custom runtime mode out of the box. The library has logic to determine whether it is running in a native or custom runtime. This means all you need to do is change your build process to rename the produced binary to bootstrap and it will work in a custom runtime without any changes to the handler code.

and remove unused libraries

The aws-lambda-go library provides a build tag called lambda.norpc to remove all RPC logic from the built binary, reducing its size. Binary size contributes to Lambda cold-start time, so any reduction we make will help improve this metric.

it even provides a revised build command:

GOOS=linux go build -o ./bootstrap ./... -tags lambda.norpc

However, this last point is what's giving me some difficulty. I'm using aws-lambda-go indirectly via SAM (sam init). It is not clear where the above build command can be inserted. It is also not clear whether it's even necessary at this time, about 14 months later.

Any clarification or hints on how to investigate this further, would be great.

I'm not a big SAM user, but after having a quick look at the default GoModulesBuilder, it seems not to be supported out of the box. However, you could achieve it with a custom make file.

[jtuliani]

If you install an up-to-date version of SAM, you will see 'sam init' offers a 'go (provided.al2)' option in the Hello World samples. This shows how to set up a SAM template for a function using Go on provided.al2. In summary:

• Set the Runtime provided.al2
• Set the Handler to bootstrap
• Add a Metadata section, containing BuildMethod: go1.x

Using the 'BuildMethod' means you no longer need to use a Makefile.

Here's an example template section:

Resources:
  HelloWorldFunction:
    Type: AWS::Serverless::Function 
    Metadata:
      BuildMethod: go1.x
    Properties:
      Handler: bootstrap
      Runtime: provided.al2
      Architectures:
        - x86_64

[jtuliani]

Closing, please flag if anything else required.