Is lambda layers compatible with Go?

Viewed 2845

Is it possible to use a Golang lambda with the new lambda layers feature from AWS?

I have been trying to find a solution to use layers with my Lambda function written in Go, but I have not been able to do so. I got it working with python lambda though. I feel like since the Go code is a compiled binary, it's not possible to use a layer import during runtime. If I have the code for the layer locally, the import gets compiled into the binary as well which defeats the purpose of using a layer.

Does anyone know or have any examples around of Lambda Layers using Golang?

3 Answers

Go dependencies are inside the compiled binary, thus you can't/don't need to use layers. The problem is solved at a language level. It doesn't have anything to do with the fact that it is compiled, C and C++ binaries still have dependencies.

Actually it is possible to provide a Go layer with a pre-compiled plugin however there are so many restrictions that it isn't really useful:

  • Plugin and app have to be compiled using exactly the same compiler version (e.g. no compatibility between 1.13.3 and 1.13.4).
  • If both plugin and app rely on the same dependency they have to use exactly the same version too.
  • When plugin's API uses custom interfaces and/or structs they need to be defined in a shared Go package that has to be imported by both plugin and app.
  • All dependencies common to both plugin and app have to be stored in the same folder structure!

In case of AWS Lambda Layers the last two points mentioned above make Go layers pretty useless. Since app code needs to import a shared package anyway why not import the actual package that would reside in the Go layer?

If I get this right the Go plugin system is meant to be used to provide pluggable implementations compiled and deployed together with the main application. It's not designed to be used by third parties to deliver custom application plugins.

The bottom line is: you can use Go + AWS Lambda Layers if you really want to however in practice it is not worth the effort in my opinion.

Unfortunately, in 2022, this is still a problem.

Yes, you could build a plugin and create a layer, inject it into your lambda, but CGO_ENABLED is a deal-breaker.

Basically, your lambda requires CGO_ENABLED=0 during the build step. (eg. GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -o main main.go)

However, with CGO disabled, using "plugin" in your lambda results in an error - plugin: not implemented

From what I can confirm, on local, when CGO is enabled both the times - i.e. while building plugin & the go module, importing plugin works as expected. However, in AWS, for your lambda to work you will need to disable CGO during the build which means, working with plugins is out of context.

Discussion here - https://github.com/golang/go/issues/19569

Related