DEV Community

Cover image for Go vs Python on AWS Lambda: a practical Terraform shootout (with Function URLs)
AWS Community Builders profile image Oluwafemi Lawal
Oluwafemi Lawal for AWS Community Builders

Posted on

Go vs Python on AWS Lambda: a practical Terraform shootout (with Function URLs)

If you've been living in AWS for a while, you've probably seen a pattern:

  • Python becomes the "default Lambda language" because it's quick to write and easy to ship.
  • Go shows up when someone says, "This Lambda is basically a tiny compute worker… why is it slow and expensive?"

In this post, we'll build the same Lambda twice (Go and Python), deploy both with Terraform, put them behind Lambda Function URLs, and run a simple benchmark that makes Go look unfair, on purpose.

Use case: Telemetry burst aggregation

A client sends an array of events (endpoint, status code, duration). The function returns:

  • total events
  • unique users
  • status code counts
  • p95 duration (requires sorting a big slice/list)
  • top endpoints by hit count

This is a very "Lambda-ish" job: bursty, CPU-heavy, and latency-sensitive.

Heads-up: Go's managed runtime is deprecated

AWS deprecated the go1.x managed runtime. Go is still supported on Lambda, but you run it through an OS-only runtime such as provided.al2023 (custom runtime) and ship a bootstrap executable in your zip.

Docs:

This matters because it slightly changes packaging (but you still write normal Go with aws-lambda-go).

What you'll build

Project available at https://github.com/Femi-lawal/go_v_py_lambda

Two endpoints:

  • telemetry-go → provided.al2023 → compiled bootstrap
  • telemetry-py → python3.12 → app.handler

Both exposed through Function URLs so you can curl them without API Gateway.

⚠️ For a real system, do not use AuthType = NONE in production. Use AWS_IAM or put CloudFront/WAF in front.

Function URL docs: https://docs.aws.amazon.com/lambda/latest/dg/urls-configuration.html

Why Go outshines Python in this specific setup

Go advantages (for this use case)

  • Faster cold starts (compiled binary, minimal runtime overhead)
  • CPU-bound speed (JSON decode + sorting + maps)
  • Lower memory pressure (often fewer "surprise" allocations)
  • Easy to parallelize parsing/aggregation with goroutines when it makes sense

Python advantages (in general)

  • Fast iteration and fewer steps to "get something running"
  • Huge ecosystem (data parsing, scientific libs, AWS tooling)
  • Great when your Lambda is mostly orchestration (glue code) or IO-bound work

The trade-off

Go is fantastic when your Lambda is:

  • hot path
  • CPU-heavy
  • cost-sensitive at scale

Python is fantastic when your Lambda is:

  • mostly IO (calling APIs, DynamoDB, S3, etc.)
  • rapidly changing
  • maintained by teams who live in Python day-to-day

Project layout

Here's a small repo layout you can copy:

.
├── infra
│   ├── main.tf
│   ├── versions.tf
│   └── outputs.tf
├── lambda-go
│   ├── go.mod
│   ├── go.sum          # auto-generated by go mod tidy
│   └── main.go
├── lambda-py
│   └── app.py
└── scripts
    ├── gen_payload.py
    └── bench.sh
Enter fullscreen mode Exit fullscreen mode

The Lambda code (same logic, two languages)

1) Python: lambda-py/app.py 

import json
import time

def handler(event, context):
    start = time.time()

    body = event.get("body") or ""
    if event.get("isBase64Encoded"):
        import base64
        body = base64.b64decode(body)

    if isinstance(body, (bytes, bytearray)):
        body = body.decode("utf-8")

    try:
        events_ = json.loads(body) if body else []
        if not isinstance(events_, list):
            raise ValueError("Expected a JSON array")
    except Exception as e:
        return {
            "statusCode": 400,
            "headers": {"content-type": "application/json"},
            "body": json.dumps({"error": "invalid request", "detail": str(e)}),
        }

    counts = {}
    status_counts = {}
    unique_users = set()
    durations = []

    for ev in events_:
        if not isinstance(ev, dict):
            continue

        endpoint = ev.get("endpoint", "unknown")
        counts[endpoint] = counts.get(endpoint, 0) + 1

        status = str(ev.get("status", "unknown"))
        status_counts[status] = status_counts.get(status, 0) + 1

        uid = ev.get("user_id")
        if uid is not None:
            unique_users.add(str(uid))

        d = ev.get("duration_ms", 0)
        try:
            durations.append(int(d))
        except Exception:
            durations.append(0)

    durations.sort()
    p95 = durations[int(0.95 * (len(durations) - 1))] if durations else 0

    top_endpoints = sorted(counts.items(), key=lambda kv: kv[1], reverse=True)[:5]

    compute_ms = int((time.time() - start) * 1000)

    return {
        "statusCode": 200,
        "headers": {"content-type": "application/json"},
        "body": json.dumps(
            {
                "total_events": len(events_),
                "unique_users": len(unique_users),
                "p95_duration_ms": p95,
                "top_endpoints": top_endpoints,
                "status_counts": status_counts,
                "compute_ms": compute_ms,
                "language": "python",
            }
        ),
    }
Enter fullscreen mode Exit fullscreen mode

2) Go: lambda-go/main.go

Go on provided.al2023 expects your deployment zip to contain an executable named bootstrap at the root.

package main

import (
    "context"
    "encoding/json"
    "sort"
    "time"

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

type TelemetryEvent struct {
    Endpoint   string `json:"endpoint"`
    Status     int    `json:"status"`
    DurationMS int    `json:"duration_ms"`
    UserID     string `json:"user_id"`
}

type Response struct {
    TotalEvents     int               `json:"total_events"`
    UniqueUsers     int               `json:"unique_users"`
    P95DurationMS   int               `json:"p95_duration_ms"`
    TopEndpoints    [][2]interface{}  `json:"top_endpoints"`
    StatusCounts    map[string]int    `json:"status_counts"`
    ComputeMS       int64             `json:"compute_ms"`
    Language        string            `json:"language"`
    Error           string            `json:"error,omitempty"`
    ErrorDetail     string            `json:"detail,omitempty"`
}

func handler(ctx context.Context, req events.LambdaFunctionURLRequest) (events.LambdaFunctionURLResponse, error) {
    start := time.Now()

    var items []TelemetryEvent
    if req.Body != "" {
        if err := json.Unmarshal([]byte(req.Body), &items); err != nil {
            out, _ := json.Marshal(Response{Error: "invalid request", ErrorDetail: err.Error(), Language: "go"})
            return events.LambdaFunctionURLResponse{
                StatusCode: 400,
                Headers:    map[string]string{"content-type": "application/json"},
                Body:       string(out),
            }, nil
        }
    }

    counts := make(map[string]int, 64)
    statusCounts := make(map[string]int, 16)
    unique := make(map[string]struct{}, 128)
    durations := make([]int, 0, len(items))

    for _, ev := range items {
        ep := ev.Endpoint
        if ep == "" {
            ep = "unknown"
        }
        counts[ep]++

        statusCounts[itoa(ev.Status)]++

        if ev.UserID != "" {
            unique[ev.UserID] = struct{}{}
        }

        durations = append(durations, ev.DurationMS)
    }

    sort.Ints(durations)
    p95 := 0
    if len(durations) > 0 {
        p95 = durations[int(0.95*float64(len(durations)-1))]
    }

    // Top 5 endpoints
    type kv struct {
        k string
        v int
    }
    tmp := make([]kv, 0, len(counts))
    for k, v := range counts {
        tmp = append(tmp, kv{k: k, v: v})
    }
    sort.Slice(tmp, func(i, j int) bool { return tmp[i].v > tmp[j].v })
    topN := 5
    if len(tmp) < topN {
        topN = len(tmp)
    }
    top := make([][2]interface{}, 0, topN)
    for i := 0; i < topN; i++ {
        top = append(top, [2]interface{}{tmp[i].k, tmp[i].v})
    }

    out, _ := json.Marshal(Response{
        TotalEvents:   len(items),
        UniqueUsers:   len(unique),
        P95DurationMS: p95,
        TopEndpoints:  top,
        StatusCounts:  statusCounts,
        ComputeMS:     time.Since(start).Milliseconds(),
        Language:      "go",
    })

    return events.LambdaFunctionURLResponse{
        StatusCode: 200,
        Headers:    map[string]string{"content-type": "application/json"},
        Body:       string(out),
    }, nil
}

// tiny int->string helper (avoids fmt.Sprintf)
func itoa(n int) string {
    if n == 0 {
        return "0"
    }
    neg := false
    if n < 0 {
        neg = true
        n = -n
    }
    var buf [12]byte
    i := len(buf)
    for n > 0 {
        i--
        buf[i] = byte('0' + n%10)
        n /= 10
    }
    if neg {
        i--
        buf[i] = '-'
    }
    return string(buf[i:])
}

func main() {
    lambda.Start(handler)
}
Enter fullscreen mode Exit fullscreen mode

lambda-go/go.mod:

module telemetry-go

go 1.22

require github.com/aws/aws-lambda-go v1.48.0
Enter fullscreen mode Exit fullscreen mode

Terraform: deploy both functions the same way

infra/versions.tf 

terraform {
  required_version = ">= 1.5.0"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      # Needs support for provided.al2023 and modern runtimes.
      version = ">= 5.26.0"
    }
  }
}

provider "aws" {
  region = var.aws_region
}
Enter fullscreen mode Exit fullscreen mode

infra/main.tf 

variable "aws_region" {
  type    = string
  default = "us-east-1"
}

locals {
  project = "go-vs-python-lambda"
}

data "aws_caller_identity" "current" {}

resource "aws_iam_role" "lambda_exec" {
  name = "${local.project}-exec"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect = "Allow"
      Principal = { Service = "lambda.amazonaws.com" }
      Action = "sts:AssumeRole"
    }]
  })
}

resource "aws_iam_role_policy_attachment" "basic" {
  role       = aws_iam_role.lambda_exec.name
  policy_arn = "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole"
}

# --------------------
# Packaging
# --------------------

# Python zip: just zip the folder
data "archive_file" "py_zip" {
  type        = "zip"
  source_dir  = "${path.module}/../lambda-py"
  output_path = "${path.module}/dist/lambda-py.zip"
}

# Go zip: expects dist/bootstrap already built
data "archive_file" "go_zip" {
  type        = "zip"
  source_file = "${path.module}/dist/bootstrap"
  output_path = "${path.module}/dist/lambda-go.zip"
}

# --------------------
# Lambdas
# --------------------

resource "aws_lambda_function" "py" {
  function_name = "${local.project}-py"
  role          = aws_iam_role.lambda_exec.arn

  filename         = data.archive_file.py_zip.output_path
  source_code_hash = data.archive_file.py_zip.output_base64sha256

  runtime = "python3.12"
  handler = "app.handler"

  timeout      = 10
  memory_size  = 512
  architectures = ["arm64"]
}

resource "aws_lambda_function" "go" {
  function_name = "${local.project}-go"
  role          = aws_iam_role.lambda_exec.arn

  filename         = data.archive_file.go_zip.output_path
  source_code_hash = data.archive_file.go_zip.output_base64sha256

  runtime = "provided.al2023"
  handler = "bootstrap"

  timeout      = 10
  memory_size  = 512
  architectures = ["arm64"]
}

# --------------------
# Function URLs (public for demo)
# --------------------

resource "aws_lambda_function_url" "py" {
  function_name      = aws_lambda_function.py.function_name
  authorization_type = "NONE"
}

resource "aws_lambda_function_url" "go" {
  function_name      = aws_lambda_function.go.function_name
  authorization_type = "NONE"
}

# As of late 2024, Function URLs may require BOTH InvokeFunctionUrl and InvokeFunction permissions
# depending on your account settings. We grant both for compatibility.
resource "aws_lambda_permission" "py_url" {
  statement_id           = "AllowPublicInvokeUrlPy"
  action                 = "lambda:InvokeFunctionUrl"
  function_name          = aws_lambda_function.py.function_name
  principal              = "*"
  function_url_auth_type = "NONE"
}

resource "aws_lambda_permission" "py_invoke" {
  statement_id  = "AllowPublicInvokePy"
  action        = "lambda:InvokeFunction"
  function_name = aws_lambda_function.py.function_name
  principal     = "*"
}

resource "aws_lambda_permission" "go_url" {
  statement_id           = "AllowPublicInvokeUrlGo"
  action                 = "lambda:InvokeFunctionUrl"
  function_name          = aws_lambda_function.go.function_name
  principal              = "*"
  function_url_auth_type = "NONE"
}

resource "aws_lambda_permission" "go_invoke" {
  statement_id  = "AllowPublicInvokeGo"
  action        = "lambda:InvokeFunction"
  function_name = aws_lambda_function.go.function_name
  principal     = "*"
}
Enter fullscreen mode Exit fullscreen mode

infra/outputs.tf 

output "python_url" {
  value = aws_lambda_function_url.py.function_url
}

output "go_url" {
  value = aws_lambda_function_url.go.function_url
}
Enter fullscreen mode Exit fullscreen mode

Build & deploy

1) Build the Go bootstrap for arm64

From the repo root:

mkdir -p infra/dist

cd lambda-go
GOOS=linux GOARCH=arm64 CGO_ENABLED=0 go build -ldflags "-s -w" -o ../infra/dist/bootstrap .
cd ..

chmod +x infra/dist/bootstrap
Enter fullscreen mode Exit fullscreen mode

2) Terraform apply 

cd infra
terraform init
terraform apply
Enter fullscreen mode Exit fullscreen mode

Terraform will output both URLs.

Generate a payload and hit both endpoints

scripts/gen_payload.py 

import json
import random
import string

def rand_user():
    return "u_" + "".join(random.choices(string.ascii_lowercase + string.digits, k=8))

def main(n=20000):
    endpoints = ["/login", "/search", "/checkout", "/profile", "/feed", "/ping"]
    out = []
    for _ in range(n):
        out.append({
            "endpoint": random.choice(endpoints),
            "status": random.choice([200, 200, 200, 201, 400, 401, 403, 500]),
            "duration_ms": int(random.expovariate(1/120)) + random.randint(0, 30),
            "user_id": rand_user(),
        })
    print(json.dumps(out))

if __name__ == "__main__":
    main()
Enter fullscreen mode Exit fullscreen mode

Run it:

python3 scripts/gen_payload.py > payload.json
Enter fullscreen mode Exit fullscreen mode

Invoke:

PY_URL="$(cd infra && terraform output -raw python_url)"
GO_URL="$(cd infra && terraform output -raw go_url)"

curl -s -X POST "$PY_URL" -H "content-type: application/json" --data-binary @payload.json | jq
curl -s -X POST "$GO_URL" -H "content-type: application/json" --data-binary @payload.json | jq
Enter fullscreen mode Exit fullscreen mode

Quick benchmark (side-by-side)

Option A: hey 

# Install hey (if you don't have it)
# macOS: brew install hey
# Linux:  https://github.com/rakyll/hey

hey -n 200 -c 20 -m POST -H "content-type: application/json" -D payload.json "$PY_URL"
hey -n 200 -c 20 -m POST -H "content-type: application/json" -D payload.json "$GO_URL"
Enter fullscreen mode Exit fullscreen mode

Option B: a tiny bench.sh

scripts/bench.sh:

#!/usr/bin/env bash
set -euo pipefail

PY_URL="$(cd infra && terraform output -raw python_url)"
GO_URL="$(cd infra && terraform output -raw go_url)"

echo "Python URL: $PY_URL"
echo "Go URL:     $GO_URL"

for url in "$PY_URL" "$GO_URL"; do
  echo
  echo "== Benchmarking: $url"
  hey -n 200 -c 20 -m POST -H "content-type: application/json" -D payload.json "$url"
done
Enter fullscreen mode Exit fullscreen mode

What to look for in the results

When you benchmark:

  • p95 / p99 latency: Go often wins when the handler is CPU-heavy.
  • cold start: run once after no traffic for a while and compare first-hit latency.
  • cost: Lambda charges for GB-seconds. If Go finishes faster at the same memory size, your bill can drop.

Also look at CloudWatch logs and metrics:

  • Duration
  • Max memory used
  • Init duration (cold start)

Actual Benchmark Results

We ran a comprehensive benchmark with the following configuration:

  • Memory: 512 MB (both functions)
  • Architecture: ARM64 (Graviton2)
  • Region: us-east-1
  • Iterations per test: 30
  • Payload sizes: 100, 1,000, 5,000, 10,000, and 20,000 events

Latency Chart

Cold Start Chart

Latency Summary (all times in milliseconds)

Events Payload Size Language Cold Start Avg Latency P50 P95 P99
100 8 KB Python 272 70 66 89 98
100 8 KB Go 136 41 39 54 55
1,000 82 KB Python 68 72 70 82 107
1,000 82 KB Go 46 53 52 68 74
5,000 411 KB Python 124 124 121 151 160
5,000 411 KB Go 135 108 102 130 140
10,000 822 KB Python 220 205 202 236 263
10,000 822 KB Go 190 197 199 221 261
20,000 1.6 MB Python 422 473 460 573 595
20,000 1.6 MB Go 357 359 359 391 396

Go vs Python Speedup Factor

Payload Avg Latency Speedup P95 Latency Speedup Cold Start Speedup
100 events (8 KB) 1.70x faster 1.66x faster 2.00x faster
1,000 events (82 KB) 1.35x faster 1.21x faster 1.47x faster
5,000 events (411 KB) 1.15x faster 1.16x faster 0.92x
10,000 events (822 KB) 1.04x faster 1.07x faster 1.16x faster
20,000 events (1.6 MB) 1.32x faster 1.46x faster 1.18x faster

Key Observations

  1. Cold Starts: Go's cold start is up to 2x faster for small payloads. At 100 events, Go cold starts at ~136ms vs Python's ~272ms. This matters for bursty, event-driven workloads.

  2. Small Payloads Win Big: For small to medium payloads (100-1000 events), Go's advantage is most pronounced (1.35x-1.70x faster). This is where the JSON parsing and initial setup overhead dominates.

  3. Large Payloads Converge: At 10,000+ events, the speedup narrows (1.04x-1.32x) because the actual computation time dominates over runtime overhead. However, Go maintains a consistent advantage in tail latencies (P95/P99).

  4. Predictable Tail Latencies: Go's P95 to P99 spread is tighter. For 20,000 events:

    • Python: P95=573ms, P99=595ms (22ms spread)
    • Go: P95=391ms, P99=396ms (5ms spread)

This predictability is critical for SLO compliance.

  1. Internal Compute Time: At larger payloads, Python's internal compute time (compute_ms from the response) is actually slightly lower than Go's for sorting operations (20K events: Python=117ms, Go=140ms). This is because Python's timsort is highly optimized C code, while Go's sort.Ints is pure Go. However, the compute_ms metric only measures post-JSON-parse processing. Go's faster JSON deserialization (which dominates at scale) isn't captured in this number. The total end-to-end latency still favors Go due to faster JSON parsing and lower runtime overhead.

Cost Implications

With Lambda ARM64 (Graviton2) pricing at $0.0000133334 per GB-second (20% cheaper than x86):

Scenario Python (avg) Go (avg) Monthly Savings (1M invocations)
100 events 70ms 41ms $0.20
1,000 events 72ms 53ms $0.13
20,000 events 473ms 359ms $0.76

Calculation: (Python_ms - Go_ms) / 1000 × 0.5 GB × $0.0000133334 × 1,000,000 invocations

At scale (100M invocations/month with 20,000-event payloads), that's approximately $76/month savings just by choosing Go, plus the inherent 20% ARM64 discount on top of x86 pricing.

When I'd choose Go vs Python for Lambda

I reach for Go when:

  • this function is on the hot path (lots of traffic)
  • it does non-trivial compute (parsing, compression, crypto, transforms)
  • I care about predictable latency at scale
  • I want small deployment packages and simple dependencies

I reach for Python when:

  • the function mostly orchestrates AWS services
  • the logic changes often (product iteration)
  • I need a library ecosystem advantage
  • it's a glue script with real business value and low perf pressure

Final notes and improvements

If you want to make this "production-ish":

  • flip Function URLs to AWS_IAM auth (or front with CloudFront/WAF)
  • set log retention (so you don't pay forever)
  • add structured logging + tracing
  • add provisioned concurrency if you need consistent latency under cold starts

Additional Benchmark Scenarios to Try

1. Memory Configuration Comparison

Try running the same benchmarks at different memory levels:

# In main.tf, change memory_size to test:
memory_size = 256   # Minimum viable
memory_size = 512   # Balanced (our test)
memory_size = 1024  # 2x CPU
memory_size = 1769  # Full vCPU
memory_size = 3008  # 2 vCPUs
Enter fullscreen mode Exit fullscreen mode

Expected behavior: Go benefits less from extra memory since it's already efficient. Python may see bigger gains from more CPU (Lambda CPU scales with memory).

2. Concurrent Request Simulation

Test how each handles concurrent bursts:

# Using hey for concurrency testing
hey -n 500 -c 50 -m POST -H "content-type: application/json" -D payload.json "$GO_URL"
hey -n 500 -c 50 -m POST -H "content-type: application/json" -D payload.json "$PY_URL"
Enter fullscreen mode Exit fullscreen mode

Watch for:

  • Error rates under load
  • Latency distribution (P50 vs P99 gap)
  • Throttling behavior

3. I/O-Bound Workload Comparison

Modify the Lambda to include DynamoDB or S3 calls:

# In app.py - add I/O operation
import boto3
dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('telemetry-events')

# Write aggregated result to DynamoDB
table.put_item(Item={'id': str(uuid.uuid4()), 'result': result})
Enter fullscreen mode Exit fullscreen mode

Expected result: The Go vs Python gap narrows significantly when I/O dominates. For pure I/O workloads, Python's simplicity often wins.

4. Package Size Impact

Compare deployment package sizes:

Language Package Size Contains
Go 6.3 MB Single static binary
Python 1.2 KB Just app.py

But with dependencies:

Language Package Size Contains
Go 6.3 MB Still just the binary
Python + pandas + numpy 50+ MB Requires layers or container

5. Provisioned Concurrency Test

To eliminate cold starts entirely:

resource "aws_lambda_provisioned_concurrency_config" "go" {
  function_name                     = aws_lambda_function.go.function_name
  provisioned_concurrent_executions = 10
  qualifier                         = aws_lambda_function.go.version
}
Enter fullscreen mode Exit fullscreen mode

This adds ~$0.000004463 per GB-second for provisioned capacity.

Real-World Use Cases Where These Results Matter

✅ Good fit for Go Lambda:

  • API Gateway backends - Low latency matters for user-facing APIs
  • Kinesis/SQS processors - High throughput event processing
  • Real-time data aggregation - Like our telemetry example
  • Image/video thumbnail generation - CPU-bound transforms
  • JWT validation layers - Crypto operations benefit from Go

✅ Good fit for Python Lambda:

  • ML inference with SageMaker - Rich SDK ecosystem
  • Data pipeline orchestration - Step Functions triggers
  • S3 event handlers - boto3 makes this trivial
  • Slack/Discord bots - Rapid iteration matters more
  • One-off automation scripts - Time-to-deployment wins

Cleanup

Don't forget to tear down your infrastructure when done:

cd infra
terraform destroy -auto-approve
Enter fullscreen mode Exit fullscreen mode

Reproducibility

To reproduce these benchmarks yourself:

# 1. Clone and enter the project
git clone https://github.com/Femi-lawal/go_v_py_lambda
cd go_v_py_lambda

# 2. Build the Go binary for ARM64 Lambda
cd lambda-go
go mod tidy
GOOS=linux GOARCH=arm64 CGO_ENABLED=0 go build -ldflags "-s -w" -o ../infra/dist/bootstrap .
cd ..

# 3. Deploy with Terraform
cd infra
terraform init
terraform apply -auto-approve

# 4. Generate test payload
python3 scripts/gen_payload.py 20000 > payload.json

# 5. Run benchmarks (requires 'hey' - install via: go install github.com/rakyll/hey@latest)
PY_URL="$(terraform output -raw python_url)"
GO_URL="$(terraform output -raw go_url)"

hey -n 100 -c 10 -m POST -H "content-type: application/json" -D ../payload.json "$PY_URL"
hey -n 100 -c 10 -m POST -H "content-type: application/json" -D ../payload.json "$GO_URL"

# 6. Cleanup when done
terraform destroy -auto-approve
Enter fullscreen mode Exit fullscreen mode

Summary

Our benchmarks confirm the conventional wisdom with hard numbers:

Metric Go Advantage
Cold Start (small payload) 2x faster
Warm Latency (small payload) 1.7x faster
Warm Latency (large payload) 1.3x faster
P95 Tail Latency 1.2x-1.7x tighter
Monthly Cost Savings (ARM64) ~$76 at 100M requests

The takeaway: If your Lambda is on the hot path, does CPU work, and you care about cost or latency SLOs, Go is worth the learning curve. If you're gluing AWS services together or iterating rapidly, Python's ergonomics win.

Happy building

Top comments (0)