Migrate from AWS Lambda to Knative

Path 1: Migrate API-style Lambda applications to Knative Serving

Suitable for Lambda functions originally triggered by API Gateway, such as webhooks, REST APIs, lightweight inference endpoints, and backend microservice APIs. The core idea is to refactor the Lambda handler into an HTTP service, package it as a container image, deploy it as a Knative Service. Then use Knative’s built-in domain names, Ingress, and traffic management capabilities to expose the service.

Path 2: Migrate event-driven Lambdas to Knative Eventing

Suitable for functions triggered by object storage events, message queue events, publish/subscribe events, scheduled tasks, or data stream events. For these scenarios, choose the Broker/Trigger model of Knative Eventing based on the target architecture.

Scenario 1: API Gateway + Lambda → Knative Service

Before migration: Client → API Gateway → Lambda
After migration:  Client → Ingress/Gateway → Knative Service

Scenario 2: S3/SNS/SQS-triggered Lambda → object events/message systems + Knative

Before migration: S3/SNS/SQS → Lambda
After migration:  Object Storage / Message Queue / Event Bus → Knative Eventing → Knative Service

Or:

Queue/Topic → Consumer Container → Knative Service

Scenario 3: EventBridge scheduled tasks → CronJob / Eventing

Before migration: EventBridge Schedule → Lambda
After migration:  CronJob / Event Source / EventBridge Schedule → Knative Service

Refactor from Lambda handler to HTTP entry point

The most common code shape in Lambda is (Python Lambda example):

def handler(event, context):
    name = event.get("queryStringParameters", {}).get("name", "world")
    return {
        "statusCode": 200,
        "body": f"Hello, {name}"
    }

After migrating to Knative, refactor it into a standard web service (Python Flask example):

from flask import Flask, request

app = Flask(__name__)

@app.route("/", methods=["GET"])
def hello():
    name = request.args.get("name", "world")
    return f"Hello, {name}", 200

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=8080)

Package as a container image

Create a Dockerfile:

FROM python:3.11-slim

WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY app.py .
ENV PORT=8080
CMD ["python", "app.py"]

Create requirements.txt:

flask==3.0.0

containerConcurrency

Set the containerConcurrency field as follows to control the concurrency each instance can handle:

spec:
  template:
    spec:
      containerConcurrency: 10

Set the concurrency based on your specific scenario:

• Low concurrency: more stable and suitable for CPU-intensive tasks.

• High concurrency: fewer instances and lower cost, but requires evaluation of application thread safety and resource bottlenecks.

Minimum replicas

If your workload is sensitive to cold starts, set the min-scale annotation as follows to control the minimum number of replicas:

metadata:
  annotations:
    autoscaling.knative.dev/min-scale: "1"

Maximum replicas

To prevent runaway resource usage caused by traffic spikes, set the max-scale annotation as follows to control the maximum number of replicas:

metadata:
  annotations:
    autoscaling.knative.dev/max-scale: "50"

Resource requests and limits

Set the resources field as follows to properly allocate CPU and memory resources:

resources:
  requests:
    cpu: "500m"
    memory: "512Mi"
  limits:
    cpu: "1"
    memory: "1Gi"

Canary release example

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: hello-service
spec:
  traffic:
  - revisionName: hello-service-v1
    percent: 90
  - revisionName: hello-service-v2
    percent: 10
  template:
    metadata:
      name: hello-service-v2
    spec:
      containers:
      - image: registry.example.com/hello:2.0.0

This lets you:

• Validate the migrated version with low traffic.

• Roll back quickly.

• Compare the performance of the old and new versions.

Recommended cutover steps

1. Deploy the new version on Knative.

2. Use a test domain to validate functionality.

3. Route a small percentage of traffic as a canary.

4. Validate logs, latency, and error rates.

5. Cut over all traffic.

6. Keep Lambda running for a while as a fallback plan.