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 | Capability | Area | Support | Required tier | Operations | Notes | | ---------------------------------------------------------- | ------------- | ------------ | ------------- | ---------- | --------------------------------------------------------------------------------------------------------------------------------------- | | Environment variables | Configuration | Supported | - | - | Configured on the function workload. | | Ephemeral storage (/tmp) | Configuration | Out of scope | - | - | The container filesystem does not reproduce Lambda's configured /tmp cap. | | Function lifecycle | Configuration | Partial | - | - | Supported lifecycle requests reconcile function configuration onto the selected cluster; invocation requires observed Active readiness. | | Reserved concurrency | Configuration | Out of scope | - | - | A Deployment replica count is not a Lambda reserved-concurrency limit. | | Timeout | Configuration | Partial | - | - | The authored timeout does not provide a per-request Kubernetes process deadline. | | Event sources, layers, aliases, versions and function URLs | Integration | Out of scope | - | - | These source integrations are outside the selected Kubernetes function deployment. | | Asynchronous (Event) invocation | Invocation | Out of scope | - | - | This target serves synchronous calls; it does not provide an asynchronous event queue. | | Zip packaging | Packaging | Supported | - | - | The runtime base and function code are built into a container image. | | Operation | Area | Support | Depth | Notes | | ------------------------ | ---------- | ------------ | ---------- | -------------------------------------------------------------------------------------------- | | Invoke | Invocation | Supported | Common | Synchronous RequestResponse calls reach the configured function through its cluster Service. | | InvokeWithResponseStream | Invocation | Out of scope | Most usage | Response streaming is outside this deployment contract. | #### 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 | Capability | Area | Support | Required tier | Operations | Notes | | ------------------------------------------------------------ | ----------------- | ------------ | ------------- | ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Compute sizing | Configuration | Supported | - | - | memory is applied as authored; CPU derived from Lambda's delivered compute (the continuous memory/1769 vCPU credit rate, its binding throughput ceiling, not the stepped visible-core count) mapped onto the Container App's cpu/memory allocation | | Environment variables | Configuration | Supported | - | - | your function's environment variables are set on its workload | | Ephemeral storage (/tmp) | Configuration | Partial | - | - | each invoke runs in its own process, but concurrent invokes on one replica share the container filesystem; a private, sized /tmp per concurrent invoke needs container privileges the managed platform withholds, and a single-invoke-per-replica mode restores it at a scale-up cost | | Reserved concurrency | Configuration | Supported | - | - | configured reserved concurrency maps to the app's replica/worker bound | | Timeout | Configuration | Partial | - | - | Container Apps has no per-request execution deadline. The authored value is passed through, but the connection backstop only limits the caller's response wait. It does not terminate the remote handler; the handler can continue after the wait ends. | | Event source mappings | Event integration | Out of scope | - | - | not compiled; the build stops with a clear error rather than silently dropping them | | Asynchronous (Event) invocation | Invocation | Out of scope | - | - | the Event invocation type of Invoke is not served; a synchronous RequestResponse Invoke is | | Layers | Packaging | Out of scope | - | - | not compiled; the build stops with a clear error | | Zip packaging | Packaging | Supported | - | - | a zip-packaged function is built into a container image at release: the runtime base plus your code, fronted by the AWS-provided runtime client | | Aliases / versions / provisioned concurrency / function URLs | Routing | Out of scope | - | - | not compiled; the build stops with a clear error | | Operation | Area | Support | Depth | Notes | | ------------------------ | ---------- | ------------ | ---------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Invoke | Invocation | Supported | Common | a sync Invoke routes to the Container App, resolved to the callee by function name through the caller's routing layer (Container Apps co-locates it on shared localhost, like Cloud Run) | | InvokeWithResponseStream | Invocation | Out of scope | Most usage | response streaming is not served; the synchronous RequestResponse invoke is the served path | #### 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](/service-adapters/aws/compute-containers/lambda#function-lifecycle-and-invocation) for Pending/Active state, supported lifecycle operations and invocation outcomes. ### Via Azure Functions (Flex Consumption) | Capability | Area | Support | Required tier | Operations | Notes | | ------------------------------------------------------------ | ----------------- | ------------ | ------------- | ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Compute sizing | Configuration | Supported | - | - | memory is applied where it fits the plan's instance size; CPU derived from Lambda's delivered compute (the continuous memory/1769 vCPU credit rate, its binding throughput ceiling, not the stepped visible-core count); see the memory-ceiling limit below | | Environment variables | Configuration | Supported | - | - | your function's environment variables are set on its workload | | Ephemeral storage (/tmp) | Configuration | Partial | - | - | each invoke gets its own instance and its own /tmp (platform-isolated), but Flex Consumption caps instance /tmp near 0.8 GB, so a function that authored more ephemeral storage routes to a container option instead of running here | | Reserved concurrency | Configuration | Supported | - | - | configured reserved concurrency maps to the plan's maximum instance count | | Timeout | Configuration | Supported | - | - | the authored timeout (Lambda's 3s default when unset) is enforced by the platform at the configured deadline; the adapter returns Lambda's timeout contract | | Event source mappings | Event integration | Out of scope | - | - | not compiled; the build stops with a clear error rather than silently dropping them | | Asynchronous (Event) invocation | Invocation | Out of scope | - | - | the Event invocation type of Invoke is not served; a synchronous RequestResponse Invoke is | | Container-image packaging | Packaging | Out of scope | - | - | Flex Consumption runs code packages, not container images, so a container-image function routes to a container option (Container Apps or the Premium plan) rather than stopping the build | | Layers | Packaging | Out of scope | - | - | not compiled; the build stops with a clear error | | Zip packaging | Packaging | Supported | - | - | the natural fit here, because Flex Consumption is code-only; the AWS-provided runtime client and the Tensor9 adapter ride in the same code package | | Aliases / versions / provisioned concurrency / function URLs | Routing | Out of scope | - | - | not compiled; the build stops with a clear error | | Operation | Area | Support | Depth | Notes | | ------------------------ | ---------- | ------------ | ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Invoke | Invocation | Supported | Common | a sync Invoke reaches the function through a translation layer that adapts Azure's HTTP-trigger invocation to the real Lambda runtime, with the callee resolved by function name through the caller's routing layer | | InvokeWithResponseStream | Invocation | Out of scope | Most usage | response streaming is not served; the synchronous RequestResponse invoke is the served path | #### 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 sets `http_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_concurrency` to 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](/service-adapters/aws/compute-containers/lambda#function-lifecycle-and-invocation) for Pending/Active state, supported lifecycle operations and invocation outcomes. ### Via Azure Functions (Premium) | Capability | Area | Support | Required tier | Operations | Notes | | ------------------------------------------------------------ | ----------------- | ------------ | ------------- | ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Compute sizing | Configuration | Supported | - | - | memory is applied as authored; CPU derived from Lambda's delivered compute (the continuous memory/1769 vCPU credit rate, its binding throughput ceiling, not the stepped visible-core count), mapped onto the Premium instance SKU (EP1/EP2/EP3) | | Environment variables | Configuration | Supported | - | - | your function's environment variables are set on its workload | | Ephemeral storage (/tmp) | Configuration | Supported | - | - | each invoke gets platform-isolated instance storage; the Premium instance's /tmp is sized in GB (no \~0.8 GB code-plan cap), closer to Lambda's ephemeral storage than the Flex Consumption option | | Reserved concurrency | Configuration | Supported | - | - | configured reserved concurrency maps to the plan's maximum instance count (Premium's burst ceiling is 20-100 by SKU) | | Timeout | Configuration | Supported | - | - | the authored timeout (Lambda's 3s default when unset) is enforced by the platform at the configured deadline; the adapter returns Lambda's timeout contract | | Event source mappings | Event integration | Out of scope | - | - | not compiled; the build stops with a clear error rather than silently dropping them | | Asynchronous (Event) invocation | Invocation | Out of scope | - | - | the Event invocation type of Invoke is not served; a synchronous RequestResponse Invoke is | | Container-image packaging | Packaging | Supported | - | - | a container-image function runs directly, because Premium hosts custom containers, so the compiled image (AWS-provided runtime client + Tensor9 adapter + your handler + the routing-layer binary) runs as-is | | Layers | Packaging | Out of scope | - | - | not compiled; the build stops with a clear error | | Zip packaging | Packaging | Supported | - | - | a zip-packaged function ships as a code package (the runtime bundle rides in the package, as on the Flex Consumption option) | | Aliases / versions / provisioned concurrency / function URLs | Routing | Out of scope | - | - | not compiled; the build stops with a clear error | | Operation | Area | Support | Depth | Notes | | ------------------------ | ---------- | ------------ | ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Invoke | Invocation | Supported | Common | a sync Invoke reaches the function through a translation layer that adapts Azure's HTTP-trigger invocation to the real Lambda runtime, with the callee resolved by function name through the caller's routing layer | | InvokeWithResponseStream | Invocation | Out of scope | Most usage | response streaming is not served; the synchronous RequestResponse invoke is the served path | #### 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 `/tmp` closer 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](/service-adapters/aws/compute-containers/lambda#function-lifecycle-and-invocation) for Pending/Active state, supported lifecycle operations and invocation outcomes. ## On OCI ### Via OKE function Deployments | Capability | Area | Support | Required tier | Operations | Notes | | ---------------------------------------------------------- | ------------- | ------------ | ------------- | ---------- | --------------------------------------------------------------------------------------------------------------------------------------- | | Environment variables | Configuration | Supported | - | - | Configured on the function workload. | | Ephemeral storage (/tmp) | Configuration | Out of scope | - | - | The container filesystem does not reproduce Lambda's configured /tmp cap. | | Function lifecycle | Configuration | Partial | - | - | Supported lifecycle requests reconcile function configuration onto the selected cluster; invocation requires observed Active readiness. | | Reserved concurrency | Configuration | Out of scope | - | - | A Deployment replica count is not a Lambda reserved-concurrency limit. | | Timeout | Configuration | Partial | - | - | The authored timeout does not provide a per-request Kubernetes process deadline. | | Event sources, layers, aliases, versions and function URLs | Integration | Out of scope | - | - | These source integrations are outside the selected Kubernetes function deployment. | | Asynchronous (Event) invocation | Invocation | Out of scope | - | - | This target serves synchronous calls; it does not provide an asynchronous event queue. | | Zip packaging | Packaging | Supported | - | - | The runtime base and function code are built into a container image. | | Operation | Area | Support | Depth | Notes | | ------------------------ | ---------- | ------------ | ---------- | -------------------------------------------------------------------------------------------- | | Invoke | Invocation | Supported | Common | Synchronous RequestResponse calls reach the configured function through its cluster Service. | | InvokeWithResponseStream | Invocation | Out of scope | Most usage | Response streaming is outside this deployment contract. | #### 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 | Capability | Area | Support | Required tier | Operations | Notes | | ------------------------------------------------------------ | ----------------- | ------------ | ------------- | ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Compute sizing | Configuration | Supported | - | - | memory selects the function's resource tier at build time, snapped up to an OCI tier (e.g. 1769 MiB → 2048); the tier determines CPU; memory ceils to an OCI tier up to 3072 MB; a larger Lambda stops the build with a clear error | | Environment variables | Configuration | Supported | - | - | set on the function's workload | | Ephemeral storage (/tmp) | Configuration | Out of scope | - | - | the function gets the container filesystem; Lambda's sized /tmp cap is not reproduced on OCI Functions | | Reserved concurrency | Configuration | Out of scope | - | - | configured reserved concurrency is not honored on OCI Functions | | Timeout | Configuration | Supported | - | - | the authored timeout applies up to OCI's 300s ceiling (a longer Lambda timeout stops the build with a clear error); enforced by the platform, and the adapter returns Lambda's timeout contract | | Event source mappings | Event integration | Out of scope | - | - | not compiled; the build stops with a clear error rather than silently dropping them | | Asynchronous (Event) invocation | Invocation | Out of scope | - | - | the Event invocation type of Invoke is not served; a synchronous RequestResponse Invoke is | | Layers | Packaging | Out of scope | - | - | not compiled; the build stops with a clear error | | Zip packaging | Packaging | Supported | - | - | a zip-packaged function is built into a container image at release: the runtime base plus your code, fronted by the AWS-provided runtime client | | Aliases / versions / provisioned concurrency / function URLs | Routing | Out of scope | - | - | not compiled; the build stops with a clear error | | Operation | Area | Support | Depth | Notes | | ------------------------ | ---------- | ------------ | ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Invoke | Invocation | Supported | Common | synchronous RequestResponse resolved by function name at request time; a redeployed callee is picked up automatically. Signing, idle-resume, and a real Lambda handler running through the runtime interface client validated on live OCI (2026-07-10); warm p50 8.5 ms and steady-state cold-start p50 365 ms measured in-region, with image-cached cold-start results distinguished from first image pulls | | InvokeWithResponseStream | Invocation | Out of scope | Most usage | response streaming is not served; the synchronous RequestResponse invoke is the served path | #### 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](/service-adapters/aws/compute-containers/lambda#function-lifecycle-and-invocation) for Pending/Active state, supported lifecycle operations and invocation outcomes. ## On Private Kubernetes ### Via Kubernetes Cluster | Capability | Area | Support | Required tier | Operations | Notes | | ------------------------------------------------------------ | ----------------- | ------------ | ------------- | ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Compute sizing | Configuration | Supported | - | - | memory is applied as authored; CPU derived from Lambda's delivered compute (the continuous memory/1769 vCPU credit rate, its binding throughput ceiling, not the stepped visible-core count), emitted as a CFS CPU limit | | Environment variables | Configuration | Supported | - | - | set on the function's workload | | Ephemeral storage (/tmp) | Configuration | Out of scope | - | - | the function gets the container filesystem; Lambda's sized /tmp cap is not reproduced on Kubernetes | | Reserved concurrency | Configuration | Out of scope | - | - | configured reserved concurrency is not honored on Kubernetes | | Timeout | Configuration | Partial | - | - | Kubernetes has no per-request execution deadline. The authored value is passed through, but the connection backstop above Lambda's 900s maximum only limits the caller's response wait. It does not terminate the remote handler; the handler can continue after the wait ends. | | Event source mappings | Event integration | Out of scope | - | - | not compiled; the build stops with a clear error rather than silently dropping them | | Asynchronous (Event) invocation | Invocation | Out of scope | - | - | the Event invocation type of Invoke is not served; a synchronous RequestResponse Invoke is | | Layers | Packaging | Out of scope | - | - | not compiled; the build stops with a clear error | | Zip packaging | Packaging | Supported | - | - | a zip-packaged function is built into a container image at release: runtime base plus your code, fronted by the AWS-provided runtime client | | Aliases / versions / provisioned concurrency / function URLs | Routing | Out of scope | - | - | not compiled; the build stops with a clear error | | Operation | Area | Support | Depth | Notes | | ------------------------ | ---------- | ------------ | ---------- | --------------------------------------------------------------------------------------------------------- | | Invoke | Invocation | Supported | Common | routed in-cluster by function name; the function serves the real Invoke API (synchronous RequestResponse) | | InvokeWithResponseStream | Invocation | Out of scope | Most usage | response streaming is not served; the synchronous RequestResponse invoke is the served path | #### 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](/service-adapters/aws/compute-containers/lambda#function-lifecycle-and-invocation) for Pending/Active state, supported lifecycle operations and invocation outcomes. ### Via Knative Service | Capability | Area | Support | Required tier | Operations | Notes | | ------------------------------------------------------------ | ----------------- | ------------ | ------------- | ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Compute sizing | Configuration | Supported | - | - | memory is applied as authored; CPU derived from Lambda's delivered compute (the continuous memory/1769 vCPU credit rate, its binding throughput ceiling, not the stepped visible-core count), emitted as a CFS CPU limit | | Environment variables | Configuration | Supported | - | - | set on the function's workload | | Ephemeral storage (/tmp) | Configuration | Out of scope | - | - | the function gets the container filesystem; Lambda's sized /tmp cap is not reproduced on Knative | | Reserved concurrency | Configuration | Out of scope | - | - | configured reserved concurrency is not honored on Knative | | Timeout | Configuration | Partial | - | - | the Knative revision default (300s) limits the HTTP response wait, not the authored Lambda execution timeout; the handler can continue after a response timeout | | Event source mappings | Event integration | Out of scope | - | - | not compiled; the build stops with a clear error rather than silently dropping them | | Asynchronous (Event) invocation | Invocation | Out of scope | - | - | the Event invocation type of Invoke is not served; a synchronous RequestResponse Invoke is | | Layers | Packaging | Out of scope | - | - | not compiled; the build stops with a clear error | | Zip packaging | Packaging | Supported | - | - | a zip-packaged function is built into a container image at release: runtime base plus your code, fronted by the AWS-provided runtime client | | Aliases / versions / provisioned concurrency / function URLs | Routing | Out of scope | - | - | not compiled; the build stops with a clear error | | Operation | Area | Support | Depth | Notes | | ------------------------ | ---------- | ------------ | ---------- | --------------------------------------------------------------------------------------------------------- | | Invoke | Invocation | Supported | Common | routed in-cluster by function name; the function serves the real Invoke API (synchronous RequestResponse) | | InvokeWithResponseStream | Invocation | Out of scope | Most usage | response streaming is not served; the synchronous RequestResponse invoke is the served path | #### 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. #### Function lifecycle on Knative The function reconciles to a Knative revision and invokes through its cluster-local route. Revision readiness, the activator's response deadline and handler completion are separate; warm and maximum replicas retain the limits above. See [function lifecycle and invocation](/service-adapters/aws/compute-containers/lambda#function-lifecycle-and-invocation) for Pending/Active state, supported lifecycle operations and invocation outcomes. [Service Catalog](/service-adapters/catalog).