- Coverage by target cloud
- How the targets compare
- On Google Cloud
- On Azure
- On OCI
- On Private Kubernetes
Coverage by target cloud
How the targets compare
Each row compares a capability of Lambda with its adaptation on each target. A dash means this row is not stated for that target.Max adaptation
Infrastructure-only adaptation
On Google Cloud
How it works
On AWS your application calls Lambda through the AWS SDK; those calls are unchanged. At deploy time the compiler turns each function into a container image in the customer’s own registry: a container-image function uses the configured Lambda-compatible entrypoint, and a zip-packaged function is built into a container image at release. The AWS runtime client runs the handler; an HTTP Invoke wrapper delivers requests to that runtime. At runtime every invocation uses the Lambda Invoke protocol: the function image serves the Invoke API on its port, and the reply uses Lambda’s own framing, including function errors; execution deadlines follow the target limits below. Only synchronous request/response invokes are served. Cloud Run differs from the cluster targets by being container-serverless with true scale-to-zero, managed by Google . When no invokes arrive the service scales to zero (CPU throttled outside requests) and scales back up per request. Google, not Tensor9, enforces one request per instance, so Cloud Run holds one active HTTP request per instance. Code can continue after an HTTP timeout, so this setting alone does not guarantee that a timed-out handler has stopped before another request arrives. The configured timeout becomes Cloud Run’s request deadline: expiration returns HTTP 504 without terminating the container. A sized in-memory/tmp matches the authored ephemeral storage. Reserved concurrency maps to the revision’s maximum instance count, which Cloud Run can temporarily exceed; multiple revisions can also serve requests. This setting does not provide strict fleet-wide admission control. Cross-function invokes route through a caller-side adapter that resolves the callee by name, bound at apply, since the platform assigns a hostname the name alone cannot predict; the layer authenticates with identity tokens issued for the destination service, with no AWS keys on the path.
Each function runs as a Cloud Run service that scales to zero; Google enforces one request per instance, and a caller-side adapter routes cross-function invokes by name with keyless auth.
Operations and migration
Operations. Google operates Cloud Run’s scaling and availability; Tensor9 operates the invoke path. Invoke permissions are granted manually, and services run on the project’s default compute account. Migration. The function is compiled at the build and ships as its container image; there is no data to migrate at cutover. Capacity and speed. Throughput and latency are Cloud Run’s own, reported by your monitoring.Limitations
△ Where Lambda and Cloud Run stay different- CPU rounds up to a Cloud Run tier. CPU allocation rounds up to a gen2 tier; a sub-vCPU function rounds up to a full vCPU, and memory below the platform floor is brought up to it.
- The HTTP timeout does not terminate the handler. Cloud Run can return HTTP 504 while code continues running. Workloads that require execution to stop at the deadline need handler cancellation or process termination beyond this native request setting.
- Maximum instances is not exact reserved concurrency. Cloud Run can temporarily exceed the revision’s maximum, and multiple revisions may serve traffic. One request per instance does not impose a strict admission limit across the fleet.
- Cross-function calls reach only the same stack. A call to a function the build cannot see returns a clear error rather than reaching the wrong service.
- Synchronous invoke only. An asynchronous (Event) invoke returns a clear error; layers, event source mappings, aliases, and function URLs stop the build with a clear error rather than dropping silently.
Other considerations
Consider request isolation, idle capacity, and how functions call one another.- One active HTTP request per instance. Google applies this request limit at the platform. Warm requests reuse process memory and
/tmp; code left running after an HTTP timeout can overlap a later request. - Scale-to-zero removes idle instance compute; the next invoke may cold-start: the service scales to zero when no invokes arrive and back up per request, so instance compute follows the configured billing mode; registry storage, networking and other resources can still incur charges. A request arriving after scale-to-zero may need a container start.
- A callee address is bound at apply. Cloud Run assigns a hostname the function name alone cannot predict, so cross-function routing is resolved when the stack is applied and a callee that moves is picked up on the next apply; every hop authenticates with keyless identity tokens rather than AWS keys.
- Store durable state in a backing service. Function storage is temporary. Persist data through the services your handler calls so it survives instance replacement.
Function lifecycle and invocation
Maximum adaptation separates function lifecycle from invocation. Supported lifecycle requests record the desired function and reconcile it onto the selected hosting service; creation can return Pending before deployment finishes. The target service’s observed address then supplies the invocation route. A function must be Active before callers rely on that route. Invoke remains a request to the deployed handler through the Lambda adapter. Function readiness, successful HTTP delivery and a successful handler result are separate outcomes. Lifecycle adaptation does not add asynchronous event delivery, event sources, aliases or other features excluded by this target’s operation table. Existing performance results apply to the recorded invocation workload, not to runtime creation or code-update latency.On Azure
Via AKS function Deployments
How it works
Each function runs as an always-on Deployment on AKS, behind a cluster-local Service. A Lambda Invoke wrapper accepts synchronous requests and passes events to the function runtime. A runtime interface client runs the handler; the client alone does not make an arbitrary container expose the Invoke API.Function packaging and lifecycle
Zip functions are built into a container image with their runtime. Container-image functions need the configured Lambda-compatible entrypoint and Invoke wrapper. Publish the image to a registry the cluster can access, configure environment values, and wait for the deployed function to become ready. Supported lifecycle calls record desired configuration and update the selected hosting resources; a pending deployment is not yet an invocation endpoint.Cluster networking and identity
The customer configures the Azure virtual network, cluster access and node capacity. Callers must be able to reach the function Service, and the function needs network access to its dependencies. Azure workload identity can grant the function access to selected Azure services. The node or kubelet identity used for image pulls is a different identity. An AWS SDK call through another service adapter uses that adapter’s authorization path; native cloud access is configured separately.Execution limits and operations
A Deployment does not supply Lambda’s per-invocation sandbox, reserved-concurrency admission or request-driven scale-to-zero behavior. The authored timeout is not a Kubernetes process deadline, and container storage does not reproduce the configured Lambda /tmp quota. Asynchronous Event invocation, response streaming and the listed event integrations remain outside this target. Plan node upgrades and capacity, collect function logs, and verify handler errors as well as successful HTTP calls.Via Azure Container Apps
How it works
On AWS your application calls Lambda through the AWS SDK; those calls are unchanged. At deploy time the compiler turns each function into a container image (a container-image function runs as-is; a zip-packaged function is built into a container image at release) and runs it on Azure Container Apps , a managed container platform, not Azure Functions. At runtime the adapter serves the synchronous Invoke and returns the supported Lambda response fields and function-error framing. Only synchronous request/response invokes are served. What differs on Container Apps is where single-request concurrency comes from. Cloud Run and OCI Functions enforce one request per instance at the platform; Container Apps does not, so Tensor9’s adapter owns the ingress port and admits each invoke onto a free single-request worker itself, concurrency-aware, never co-scheduling two invokes on one worker. The platform’s own autoscaler still owns fleet scaling, moving replicas up and down with load and to zero when idle; the adapter ensures one active invocation per worker. At the default of one invoke per replica the platform’s ingress is not concurrency-aware, so a fraction of simultaneous invokes are shed and retried. Packing several single-request workers per replica behind a concurrency-aware router removes that, at the cost of those co-located workers sharing the container’s/tmp and host resources, which needs your confirmation that the handler tolerates it. Egress is mapped to an Azure managed identity, so requests need no AWS keys.
Each function runs on Azure Container Apps; an adapter owns the ingress port and admits one invoke per worker, since the platform does not hold single-request concurrency the way Cloud Run and OCI do.
Operations and migration
Operations. Microsoft operates Azure Container Apps’ scaling and availability; Tensor9 operates the invoke path, and the function code stays the vendor’s. Migration. The function is compiled at the build and ships as its container image; there is no data to migrate at cutover. Capacity and speed. Throughput and latency are Azure Container Apps’ own, reported by your monitoring.Limitations
△ Where Lambda and Azure Container Apps stay different- The adapter limits concurrent requests per worker. One invoke per worker is enforced by the adapter rather than enforced by the platform as on Cloud Run and OCI Functions.
- Burst traffic can require retries. At one invoke per replica the platform ingress is not concurrency-aware and sheds a fraction of simultaneous invokes (recovered by retry); a concurrency-aware router removes that but co-locates workers that share /tmp and host resources.
- No per-request platform deadline. The configured value is retained, but the connection backstop limits the caller’s response wait, not remote handler execution. The handler can continue after the caller times out; this does not enforce Lambda’s configured execution deadline.
- Synchronous invoke only. An asynchronous (Event) invoke returns a clear error; layers, event source mappings, aliases, and function URLs stop the build with a clear error rather than dropping silently.
Other considerations
Consider request isolation, idle capacity, and how functions call one another.- Fleet scaling and admission are separate. KEDA adjusts replicas within the configured bounds, including zero when the minimum permits it; independently, the adapter admits each invoke onto a free single-request worker, so isolation holds one invoke per worker regardless of how many replicas are up.
- Idle scales to zero; waking is a cold start: when the configured minimum allows the fleet to reach zero after idle, the first invoke pays a container start and billing follows use rather than a minimum warm capacity, which is the trade against the Premium plan’s always-ready instances.
- Egress needs no keys: the function’s outbound calls are mapped to an Azure managed identity, so credentials are the platform’s to rotate and nothing on the invoke path holds an AWS key.
- Store durable state in a backing service. Function storage is temporary. Persist data through the services your handler calls so it survives instance replacement.
Function lifecycle on Container Apps
Container App readiness establishes an invocation route, not a successful handler result. Per-worker admission, replica scaling and response-wait backstops remain distinct controls. See function lifecycle and invocation for Pending/Active state, supported lifecycle operations and invocation outcomes.Via Azure Functions (Flex Consumption)
How it works
On AWS your application calls Lambda through the AWS SDK; those calls are unchanged. At deploy time the compiler builds each function into a code package. Flex Consumption is code-only, so a container-image function routes to a container option (Container Apps or the Premium plan) rather than stopping the build. At runtime a translation layer adapts Azure’s HTTP-trigger invocation to the real Lambda runtime and returns the supported Lambda response fields and function-error framing. Only synchronous request/response invokes are served. Flex Consumption runs code packages. Tensor9 includes the routing binary with your handler and the AWS runtime client, and setshttp_concurrency to one. The platform gives each concurrent invocation its own instance, with separate memory and /tmp storage.
Each function can scale to a thousand instances and to zero when idle. The package shares about 4 GB of instance memory with the runtime and has about 0.8 GB of /tmp storage. Updating the routing binary requires rebuilding and redeploying the package. Container Apps runs the adapter as a separate process; Premium keeps instances warm to reduce cold-start latency.
Each function ships as one code package (your handler, the AWS-provided runtime client, the adapter, and the routing-layer binary together) on the Flex Consumption plan, which scales per function toward a thousand instances.
Operations and migration
Operations. Microsoft operates Azure Functions’ Flex Consumption scaling and availability; Tensor9 operates the invoke path, and the function code stays the vendor’s. Migration. The function is compiled at the build and ships as its code package; there is no data to migrate at cutover. Capacity and speed. Throughput and latency are the plan’s own, reported by your monitoring.Limitations
△ Where Lambda and the Flex Consumption plan stay different- Code packages only. Flex Consumption runs code, not container images; a container-image function routes to a container option (Container Apps or the Premium plan) rather than running here.
- Size ceilings. About 0.8 GB /tmp and about 4 GB instance memory shared with the runtime bundle; a /tmp-heavy or high-memory function routes to a container option.
- The routing layer updates only on redeploy. It ships inside the code package, so a routing-layer update requires rebuilding and redeploying the package; there is no separately-deployed process to update on its own.
- Synchronous invoke only. An asynchronous (Event) invoke returns a clear error; layers, event source mappings, aliases, and function URLs stop the build with a clear error rather than dropping silently.
Other considerations
Consider request isolation, idle capacity, and how functions call one another.- Each concurrent invoke gets its own instance. Tensor9 sets
http_concurrencyto one and the platform schedules to it, so every invoke has its own memory and/tmp; and no in-process state is shared across concurrent calls. - Flex Consumption scales to zero when idle: per-function target-based scaling reaches toward a thousand instances and to zero when idle, so it can handle many concurrent invocations and billing follows use, with a cold start on the first invoke after idle.
- Callees are resolved by the packaged routing binary: the routing layer is included as a binary beside the handler and resolves a callee by function name inside the deployed set, so a call to a function outside the stack returns a clear error rather than reaching real AWS.
- Store durable state in a backing service. Function storage is temporary. Persist data through the services your handler calls so it survives instance replacement.
Function lifecycle on Flex Consumption
A ready Azure Functions deployment supplies the invocation route. Code packaging, instance-size limits and synchronous-only delivery remain unchanged by lifecycle adaptation. See function lifecycle and invocation for Pending/Active state, supported lifecycle operations and invocation outcomes.Via Azure Functions (Premium)
How it works
On AWS your application calls Lambda through the AWS SDK; those calls are unchanged. At deploy time the compiler prepares each function for the Premium plan, which hosts the compiled container image directly or a code package. At runtime a translation layer adapts Azure’s invocation to the real Lambda runtime and returns the supported Lambda response fields and function-error framing; the routing layer is included as a binary inside the deployed artifact, packaged with the handler. Only synchronous request/response invokes are served. Premium keeps prewarmed instances ready to serve requests, corresponding to Lambda’s provisioned concurrency. These instances reduce first-request latency and are billed continuously, including when idle. Each concurrent invocation runs on a separate instance with its own memory and gigabytes of/tmp storage, more than the code-only Flex plan provides.
HTTP scaling is limited to 20 to 100 instances, depending on the SKU, compared with a thousand on Flex Consumption. Premium suits functions that need low cold-start latency; Flex Consumption supports more concurrent instances and bills according to use.
Each function runs on the Premium plan, which keeps always-ready prewarmed instances (to reduce cold-start latency) and hosts a container image or a code package.
Operations and migration
Operations. Microsoft operates Azure Functions’ Premium scaling and availability; Tensor9 operates the invoke path, and the function code stays the vendor’s. Migration. The function is compiled at the build and ships as its container image or code package; there is no data to migrate at cutover. Capacity and speed. Throughput and latency are the plan’s own, reported by your monitoring.Limitations
△ Where Lambda and the Premium plan stay different- Warm instances bill continuously. The always-ready floor is billed whether or not it serves traffic, so Premium costs more than the scale-to-zero options (Flex Consumption, Container Apps).
- A lower ceiling than Flex Consumption. HTTP scale-out reaches a 20-to-100-instance ceiling by SKU, well below Flex Consumption’s thousand.
- The routing layer updates only on redeploy. It ships inside the deployed artifact (a single container or code package, not a separately deployed service), so a routing-layer update requires rebuilding and redeploying.
- Synchronous invoke only. An asynchronous (Event) invoke returns a clear error; layers, event source mappings, aliases, and function URLs stop the build with a clear error rather than dropping silently.
Other considerations
Consider request isolation, idle capacity, and how functions call one another.- Compare cold-start latency and instance limits. Premium prewarms instances to reduce first-request latency, like Lambda’s provisioned concurrency. Flex Consumption supports more concurrent instances.
- Each concurrent invoke scales onto its own instance: concurrent invokes spread across separate instances, each with its own memory and a GB-sized
/tmpcloser to Lambda’s ephemeral storage than the code-only Flex plan, so no in-process state is shared across concurrent calls. - The plan hosts a container image or a code package: unlike code-only Flex Consumption, Premium runs the compiled container image directly or a code package, so a
/tmp-heavy or image-based function that Flex would route elsewhere runs here as-is. - Store durable state in a backing service. Function storage is temporary. Persist data through the services your handler calls so it survives instance replacement.
Function lifecycle on Premium
The Premium deployment must become ready before invocation; its warm capacity and bundled routing-layer update lifecycle retain the costs and redeployment requirements above. See function lifecycle and invocation for Pending/Active state, supported lifecycle operations and invocation outcomes.On OCI
Via OKE function Deployments
How it works
Each function runs as an always-on Deployment on OKE, behind a cluster-local Service. A Lambda Invoke wrapper accepts synchronous requests and passes events to the function runtime. A runtime interface client runs the handler; the client alone does not make an arbitrary container expose the Invoke API.Function packaging and lifecycle
Zip functions are built into a container image with their runtime. Container-image functions need the configured Lambda-compatible entrypoint and Invoke wrapper. Publish the image to a registry the cluster can access, configure environment values, and wait for the deployed function to become ready. Supported lifecycle calls record desired configuration and update the selected hosting resources; a pending deployment is not yet an invocation endpoint.Cluster networking and identity
The customer configures the OCI VCN, cluster access and node capacity. Callers must be able to reach the function Service, and the function needs network access to its dependencies. Configure the supported OCI workload identity or another approved credential for native OCI requests. Image-pull credentials and the cluster control-plane identity are separate from the function’s runtime permissions. An AWS SDK call through another service adapter uses that adapter’s authorization path; native cloud access is configured separately.Execution limits and operations
A Deployment does not supply Lambda’s per-invocation sandbox, reserved-concurrency admission or request-driven scale-to-zero behavior. The authored timeout is not a Kubernetes process deadline, and container storage does not reproduce the configured Lambda /tmp quota. Asynchronous Event invocation, response streaming and the listed event integrations remain outside this target. Plan node upgrades and capacity, collect function logs, and verify handler errors as well as successful HTTP calls.Via OCI Functions
How it works
On AWS your application calls Lambda through the AWS SDK; those calls are unchanged. At deploy time the compiler packages each function for OCI Functions: the function runs a real Lambda handler fronted by a supervisor image that speaks OCI Functions’ own invocation contract, so only the image packaging differs from the cluster targets, not the handler. At runtime the adapter serves the synchronous Invoke and returns the supported Lambda response fields and function-error framing. Only synchronous request/response invokes are served. OCI Functions differs by being managed function hosting: Oracle’s platform owns the invocation lifecycle end to end, reusing warm containers and scaling to zero when idle. Concurrency is enforced by the platform: concurrent requests use separate containers, reusing warm capacity when available, so no request shares process memory with another, Lambda’s default isolation, the same isolation as Cloud Run. Container Apps enforces this through the adapter. The adapter resolves a callee by its function name against the platform’s own directory at request time, so a redeployed callee is picked up automatically on the next call with no stored address table; requests are signed with the appliance’s own OCI identity (resource-principal or API-key signing), so requests need no AWS keys. Because OCI’s platform has firmer ceilings than the other clouds, the authored timeout applies up to OCI’s 300-second maximum and memory rounds up to an OCI tier, and a function configured above those limits is refused at the build with a clear error rather than running degraded.
Each function becomes an application-and-function pair on OCI Functions, Oracle’s managed FaaS; the platform reuses warm containers and starts more for concurrent demand and holds one request per container.
Operations and migration
Operations. Oracle operates OCI Functions’ scaling and availability; Tensor9 operates the invoke path, and the function code stays the vendor’s. Migration. The function is compiled at the build and ships as its container image; there is no data to migrate at cutover. Capacity and speed. Throughput and latency are OCI Functions’ own, reported by your monitoring.Limitations
△ Where Lambda and OCI Functions stay different- Timeout and memory meet OCI ceilings. The configured timeout applies up to OCI’s 300-second maximum and memory rounds up to an OCI tier; a Lambda function above those limits is rejected at the build with a clear error.
- Lambda’s /tmp cap is not restored. Ephemeral /tmp is the container’s own filesystem; Lambda’s sized ephemeral-storage limit is not reproduced.
- Reserved concurrency is not honored. The platform manages scaling per request, so an configured reserved-concurrency setting is not applied.
- Synchronous invoke only. An asynchronous (Event) invoke returns a clear error; layers, event source mappings, aliases, and function URLs stop the build with a clear error rather than dropping silently.
Other considerations
Consider request isolation, idle capacity, and how functions call one another.- Concurrency is enforced by the platform. Oracle assigns concurrent calls to separate container instances, so no invoke shares process memory with another (Lambda’s default isolation), and a handler that leaned on shared in-process state across concurrent calls does not get it here.
- Idle scales to zero; the first call is a cold start: the platform owns the invocation lifecycle end to end, reusing warm containers and scaling to zero when idle, so billing follows use and a cold call pays a container start.
- Callees are resolved at request time: the adapter looks a callee up by function name against the platform’s own directory on each call, so a redeployed callee is picked up automatically with no stored address table, and requests are signed with the appliance’s OCI identity rather than AWS keys.
- Store durable state in a backing service. Function storage is temporary. Persist data through the services your handler calls so it survives instance replacement.
Function lifecycle on OCI Functions
OCI function creation and activation precede invocation on the observed function route. The invocation measurements above do not measure creation or update time; OCI execution and packaging limits remain as documented. See function lifecycle and invocation for Pending/Active state, supported lifecycle operations and invocation outcomes.On Private Kubernetes
Via Kubernetes Cluster
How it works
On AWS your application calls Lambda through the AWS SDK; those calls are unchanged. At deploy time the compiler turns each function into a container image in the customer’s own registry: a container-image function keeps its handler code, with deployment packaging supplying the Invoke frontend around the runtime, and a zip-packaged function is built into a container image at release. At runtime the service adapter serves only the synchronous Invoke API and forwards each call to the deployed function, returning supported Lambda response fields: a handler that returns and one that throws use the supported response and function-error framing. Only synchronous request/response invokes are served. Each function runs as an always-on Kubernetes Deployment with one warm replica. It stays running when idle and can handle concurrent invocations in the same pod, so the handler must support concurrent execution. Scaling uses the target cluster’s autoscaling. The adapter derives the function’s cluster address from its name, without a lookup table. Kubernetes does not enforce Lambda’s request timeout, reserved concurrency, or configured/tmp capacity. The running replica avoids starting a container for each incoming request, but consumes cluster capacity while idle.
Each function runs as its own always-on Deployment; the adapter serves the synchronous invoke and returns the supported Lambda response fields and function-error framing.
Operations and migration
Operations. Tensor9 runs each function as a cluster workload and operates the invoke path; the nodes and capacity it runs on are the customer’s, and the function code stays the vendor’s. Migration. The function is compiled at the build and ships as its container image; there is no data to migrate at cutover. Capacity and speed. The invoke’s latency and throughput are the cluster’s own, reported by your monitoring, not anything measured here.Limitations
△ Where Lambda and an always-on Deployment stay different- No per-request deadline. Kubernetes does not enforce the configured Lambda execution deadline. The connection timeout limits the caller’s response wait; it does not terminate the remote handler, which can continue after that wait ends.
- Lambda’s /tmp cap is not restored. Ephemeral /tmp is the container’s own filesystem; Lambda’s sized ephemeral-storage limit is not reproduced.
- Reserved concurrency is not honored. An always-on replica has no per-request admission point, so configured reserved concurrency is not honored.
- Synchronous invoke only. An asynchronous (Event) invoke returns a clear error; layers, event source mappings, aliases, and function URLs stop the build with a clear error rather than dropping silently.
Other considerations
Consider request isolation, idle capacity, and how functions call one another.- The warm replica consumes capacity while idle: each function runs as one warm replica that stays up whether or not an invoke arrives, so there is no start-up latency and no scale-to-zero; cost comes from a continuously-running pod sized by the cluster autoscaling rather than pay-per-invoke.
- Concurrent invokes share the always-on replica: unlike the FaaS targets there is no per-request admission point, so invokes run together in the one pod and the handler must tolerate concurrent execution; you scale it with the cluster autoscaling rather than per invoke.
- Function names determine their addresses: the adapter composes the callee’s in-cluster address straight from the function name with no lookup table, so a redeployed callee in the same stack is reached without a re-apply while a call outside the stack returns a clear error rather than reaching real AWS.
- Store durable state in a backing service. Function storage is temporary. Persist data through the services your handler calls so it survives instance replacement.
Function lifecycle on Kubernetes
The function reconciles to an always-on Deployment on your cluster. Readiness does not establish a handler result or restore the absent execution deadline, reserved concurrency or sized /tmp cap. See function lifecycle and invocation for Pending/Active state, supported lifecycle operations and invocation outcomes.Via Knative Service
How it works
On AWS your application calls Lambda through the AWS SDK; those calls are unchanged. At deploy time the compiler turns each function into a container image in the customer’s own registry: a container-image function uses the configured Lambda-compatible entrypoint, and a zip-packaged function is built into a container image at release. The AWS runtime client runs the handler; an HTTP Invoke wrapper delivers requests to that runtime. At runtime the adapter serves only the synchronous Invoke API and forwards each call to the deployed function, returning the supported Lambda response fields and function-error framing. Only synchronous request/response invokes are served. Knative differs from the always-on Kubernetes Deployment by being request-driven: the platform scales the service up and down with load. By default it keeps one replica warm as a guard against cold starts and caps scale-out at a bounded ceiling (ten replicas by default, never unbounded). When a scaled-down revision is cold, the activator buffers the invoke while a new pod starts, so a cold call is delayed rather than dropped. Every function pod is restricted by a network policy: traffic in only from the Knative data plane and its own namespace, and no internet egress, so a function cannot quietly call back to real AWS. This option sits between the always-on Deployment and the managed function services (OCI Functions, Azure Functions): Tensor9 sets the replica limits (the minimum warm capacity and the ceiling) rather than a cloud provider. Knative’s revision-default deadline limits the HTTP response wait, not Lambda’s configured execution time. A timed-out response does not establish termination of the remote handler.
Each function runs as a cluster-local Knative Service that scales with request load behind the activator, blocked from the public internet by network policy.
Operations and migration
Operations. Tensor9 runs each function as a Knative Service and operates the invoke path; the nodes and capacity it runs on are the customer’s, and the function code stays the vendor’s. Migration. The function is compiled at the build and ships as its container image; there is no data to migrate at cutover. Capacity and speed. The invoke’s latency and throughput are the cluster’s own, reported by your monitoring, not anything measured here.Limitations
△ Where Lambda and a Knative Service stay different- Knative uses its default request deadline. The Knative revision default limits the HTTP response wait rather than enforcing Lambda’s configured execution deadline. The handler can continue after the response times out; that timeout is not a remote process-kill operation.
- Reserved concurrency does not change the replica limit. Scale is bounded by a minimum warm capacity and a fixed ceiling, but your reserved-concurrency setting does not move that ceiling.
- Lambda’s /tmp cap is not restored. Ephemeral /tmp is the container’s own filesystem; Lambda’s sized ephemeral-storage limit is not reproduced.
- Synchronous invoke only. An asynchronous (Event) invoke returns a clear error; layers, event source mappings, aliases, and function URLs stop the build with a clear error rather than dropping silently.
Other considerations
Consider request isolation, idle capacity, and how functions call one another.- One replica stays warm by default: the service keeps one replica warm by default and caps scale-out at a bounded ceiling, so a steady invoke is served warm while a scaled-down revision’s first call is buffered by the activator and delayed rather than dropped.
- Tensor9 sets the replica limits. Tensor9 configures the minimum and maximum replica counts. Set the maximum for peak traffic and budget for one replica that remains running while idle.
- Each function pod is blocked from the internet by network policy: a network policy admits traffic only from the Knative data plane and the pod’s own namespace and allows no internet egress, so a function cannot call back to real AWS; a callee is reached by composing its in-cluster address from the function name.
- Store durable state in a backing service. Function storage is temporary. Persist data through the services your handler calls so it survives instance replacement.