AWS Lambda with Go in 2026: Setup, Cold Starts and When to Use It

Go on AWS Lambda is a compiled binary behind the Lambda programming model, not a managed language runtime like Node.js. You build for Linux, name the executable bootstrap, and deploy it on provided.al2023 (or provided.al2). That path is fast and cheap for short, spiky work, and awkward once the same backend needs a connection pool, a queue consumer and a schedule that must not stop at 15 minutes.

This guide covers setup, packaging, cold starts, HTTP front doors and when to leave Lambda for always-on containers. It ends with Encore (infrastructure from code) as a Go alternative that keeps APIs, Postgres, queues and cron in one codebase without claiming to run on Lambda.

AWS Lambda with Go at a glance

Set up a Go handler

Initialize a module and pull the Lambda Go library. Handlers are ordinary functions that lambda.Start wires up. Clients and other heavy setup belong in init() or package scope so warm invocations reuse them:

package main

import (
	"context"
	"encoding/json"
	"log"

	"github.com/aws/aws-lambda-go/lambda"
)

type Order struct {
	OrderID string  `json:"order_id"`
	Amount  float64 `json:"amount"`
}

func handleRequest(ctx context.Context, raw json.RawMessage) error {
	var order Order
	if err := json.Unmarshal(raw, &order); err != nil {
		return err
	}
	log.Printf("processed order %s amount %.2f", order.OrderID, order.Amount)
	return nil
}

func main() {
	lambda.Start(handleRequest)
}

Valid signatures take zero to two arguments (optional context.Context first) and return zero to two values (optional error last), as listed in the handler docs. Event structs live in github.com/aws/aws-lambda-go/events when you integrate with API Gateway, SQS or S3.

Package for provided.al2023

Go does not need a language runtime on Lambda. Per the deployment package guide, cross-compile a Linux binary named bootstrap, put it at the root of the zip, and create the function with --runtime provided.al2023. The lambda.norpc build tag drops RPC code that only the deprecated go1.x runtime needed, which shrinks the zip:

The unzipped deployment package must stay under 250 MB. Prefer arm64 when you can: Graviton is the path AWS documents alongside provided.al2023, and smaller binaries usually mean less time spent pulling code on a cold start.

Cold starts in practice

A cold start is the time to download the package, start the environment and run package init before your handler runs. Go's baseline is often low because there is no language VM to boot, but the work you do in init dominates: loading the AWS SDK, opening TLS to other services, and reading large config all add up. Keep initialization outside the handler so warm invokes skip it, and keep the zip small.

Provisioned concurrency removes cold starts for a reserved number of environments at a steady cost. SnapStart is not the Go story the way it is for Java. Memory also buys CPU on Lambda (roughly one vCPU equivalent at 1,769 MB), so undersized functions can look "cold" when they are really CPU-starved on the first request. Measure with your own package and dependencies rather than a hello-world number from a blog.

Function URL vs API Gateway

A Lambda function URL is an HTTPS endpoint of the form https://<url-id>.lambda-url.<region>.on.aws. Auth is AWS_IAM or NONE, with optional CORS. The URL is public-internet only; PrivateLink does not apply to function URLs. Reserved concurrency caps concurrency and, through the function URL, effective request rate (about 10 RPS per unit of reserved concurrency).

API Gateway adds stages, authorizers, usage plans, request validation, mapping templates and broader integration patterns. Use it when the HTTP edge needs those controls. Use a Function URL when the function is the product and you want the shortest path from browser or webhook to Go.

Neither front door changes Lambda's 15-minute limit, 6 MB synchronous payload cap, or the one-connection-per-concurrent-invocation pattern that makes pooled Postgres painful without RDS Proxy.

When Lambda fits vs always-on containers

Lambda fits event handlers and APIs with spiky or low traffic that finish well inside 15 minutes, where paying per request and scaling to zero matter more than a warm process. S3 object processing, webhooks, fan-out from SQS and light CRUD behind a Function URL are the usual wins for Go.

Always-on containers (ECS on Fargate, or similar) fit services that hold database pools, WebSockets or long jobs, and backends that are several APIs plus workers plus schedules. Glue on Lambda multiplies: one function per trigger, an event source mapping per queue, IAM between each pair, and local testing through SAM or emulators. A Go service model pays off when the handler stays warm and keeps Postgres, queues and cron as first-class resources rather than bolt-on services.

How do you run Go APIs with Postgres, queues and cron without Lambda?

Encore combines an open source infrastructure SDK for TypeScript and Go with a platform that provisions and deploys into your own AWS or GCP account. On AWS, services run on Fargate (or EKS), not on Lambda. You keep writing Go; you stop wiring one Lambda per trigger for the application resources you own.

Set up the app

An orders service with a public API, Postgres, a Pub/Sub worker and a hourly sweep looks like this with released Go APIs only:

// order/order.go
package order

import (
	"context"

	"encore.dev/cron"
	"encore.dev/pubsub"
	"encore.dev/rlog"
	"encore.dev/storage/sqldb"
)

var db = sqldb.NewDatabase("orders", sqldb.DatabaseConfig{
	Migrations: "./migrations",
})

type CreateParams struct {
	SKU string `json:"sku"`
}

type CreateResponse struct {
	ID int64 `json:"id"`
}

type OrderCreated struct {
	ID  int64  `json:"id"`
	SKU string `json:"sku"`
}

var OrderCreatedTopic = pubsub.NewTopic[*OrderCreated]("order-created", pubsub.TopicConfig{
	DeliveryGuarantee: pubsub.AtLeastOnce,
})

//encore:api public method=POST path=/orders
func Create(ctx context.Context, p *CreateParams) (*CreateResponse, error) {
	var id int64
	err := db.QueryRow(ctx, `
		INSERT INTO orders (sku) VALUES ($1) RETURNING id
	`, p.SKU).Scan(&id)
	if err != nil {
		return nil, err
	}
	if _, err := OrderCreatedTopic.Publish(ctx, &OrderCreated{ID: id, SKU: p.SKU}); err != nil {
		return nil, err
	}
	return &CreateResponse{ID: id}, nil
}

var _ = pubsub.NewSubscription(
	OrderCreatedTopic, "fulfill-order",
	pubsub.SubscriptionConfig[*OrderCreated]{
		Handler: func(ctx context.Context, e *OrderCreated) error {
			rlog.Info("fulfilling order", "id", e.ID, "sku", e.SKU)
			return nil
		},
	},
)

var _ = cron.NewJob("sweep-stale-orders", cron.JobConfig{
	Title:    "Sweep stale orders",
	Every:    1 * cron.Hour,
	Endpoint: SweepStale,
})

//encore:api private
func SweepStale(ctx context.Context) error {
	rlog.Info("sweeping stale orders")
	return nil
}

-- order/migrations/1_create_orders.up.sql
CREATE TABLE orders (
  id BIGSERIAL PRIMARY KEY,
  sku TEXT NOT NULL,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

encore run starts Postgres locally and runs the API and Pub/Sub handler, per the Go SQL database and Pub/Sub docs. Cron jobs do not run locally; call SweepStale manually to test it, as noted in the cron docs. On deploy, Encore creates the Fargate service, RDS database, SNS topic and SQS subscription with a dead-letter queue, and provisions an IAM role for the service. There is no bootstrap zip, Function URL or API Gateway mapping per handler. For AWS APIs Encore does not model, keep using the AWS SDK for Go v2 inside the same service. APIs themselves use //encore:api as in the defining APIs guide.

An AI coding agent can add a column, a subscription or a cron endpoint in one change and verify it locally before you push.

Best fit: Go teams who outgrew one-function-per-trigger on Lambda and want a typed API with Postgres, queues and cron in their own AWS account.

Related guides

• Lambda vs Fargate
• AWS Lambda alternatives
• AWS SDK for Go v2
• Deploy a Go API to AWS
• Build a REST API in Go in 2026
• AWS Fargate explained