RequestResponse invocations. An asynchronous acceptance response, a queue consumer and a completed handler call are different contracts; the comparisons below do not make them interchangeable.
Each comparison is between directed service adapters with Lambda as the origin. Lambda to Cloud Run is one adapter; Cloud Run by itself is the backend, not the complete adapter.
General trade-offs
The target environment determines which execution services are candidates. A hosting choice belongs to the function’s lifecycle configuration; it is not selected independently on each Invoke, and changing a backend does not move in-flight work. The Lambda service catalog identifies each environment’s directed mappings and their packaging, lifecycle and invocation behavior.Invocation, packaging and capacity
Cloud Adapter preserves the supported Lambda request and response framing while routing the call to the selected execution service. Function readiness, successful transport and a successful handler result are three different observations. A function must be ready before routing is useful; an HTTP success can still carry
FunctionError.
Operating responsibilities
For each role, grant only the access needed to operate that component. These assignments do not imply that standalone Cloud Adapter provides BYOC telemetry routing or customer-access approvals.
Google Cloud
Cloud Run
Cloud Run is the documented Google Cloud backend. Google operates its request-driven execution platform; your team supplies the function artifact, identity, resource settings and application recovery. It can fit container-packaged handlers whose memory, execution duration and supported Lambda invocation behavior fit the mapping. It does not supply arbitrary Kubernetes scheduling controls or strict fleet-wide admission merely because the function has a maximum-instance setting. Read the Cloud Run mapping for compute rounding, packaging and concurrency. Its temporary-file writes count against function memory. A handler that fits its heap allocation can still exhaust memory while creating scratch files. A response deadline can expire without terminating the handler, so retries must tolerate late or overlapping completion. See Cloud Run request timeouts.Workload example: image processing
An infrequent handler includes native image libraries, reads a large input and writes a deterministic output object. It tolerates startup delay, but must preserve correct output after a retry. Cloud Run fits if the real image, largest allowed input and scratch-space demand fit the configured resource envelope. Measure startup after idle, startup after a rollout and execution time separately. Set a stable application job ID and commit output idempotently. A successful HTTP transport response is not proof of handler success; inspect FunctionError and the actual result object. Conversely, a caller timeout does not prove that nothing was written. The probe below distinguishes these observations. Compare configured warm capacity with the workload’s latency budget and idle cost. Keep downstream connection limits independent of the platform instance ceiling. During migration, route each new job ID to one destination, let prior work finish or explicitly retry it, and preserve the old artifact and route until results are accepted. External result objects need their own recovery and retention policy.Try synchronous retry and completion
This probe checks one logical output across repeated synchronous invocations. It uses Lambda to Cloud Run as a concrete fixture, not a preferred adapter. Apply the same invocation and output checks to other candidates using their deployment and storage setup. It does not certify event-source delivery, asynchronous invocation, aliases or exactly-once execution.1
Prepare an isolated function and result bucket
Use a disposable Google Cloud test deployment, a bucket named The conditional object creation and content check provide this fixture’s idempotency. Cloud Adapter does not make arbitrary handler side effects idempotent. Before the first run, confirm the two
acme-adapter-trial-results that you own, and a function named tradeoff-thumbnail. Substitute your own globally unique bucket name throughout; do not reuse another application’s bucket or function.Deploy this Python handler with the google-cloud-storage dependency through your existing function deployment. Give its target workload identity access only to the test result bucket. Wait for the function to become ready and record its adapter endpoint.tradeoff/image-100*.json objects do not exist.2
Inspect the mapping and configure the caller
3
Invoke twice with the same job ID
Run this command twice, saving the second response to Both calls should return no Expected content is the fixture’s
thumbnail-repeat.json:FunctionError and identify tradeoff/image-1001.json. Verify the actual object, not only the response:job_id and thumbnail-ok result. Use the AWS CLI invocation reference for its binary-payload and output-file conventions.4
Test an ambiguous completion without automatic retries
Save and run the following client. The explicit endpoint is the client-specific alternative to Wait for the fixture’s five-second delay to finish, inspect
AWS_ENDPOINT_URL_LAMBDA.tradeoff/image-1002.json, and then repeat that job through the normal CLI invocation. The expected accepted result is one correct logical output. A timeout before the write is also possible; record whether the first attempt actually committed. Caller timeout is not a cancellation test.If the result is missing, wrong or conflicting, preserve the handler logs, request identity and target object evidence before retrying. Use adapter debugging to distinguish routing, handler and native-storage failures.5
Clean up this trial
Stop callers, preserve the two response records, and remove only this trial’s two objects and function through their owning lifecycle. Retire the bucket only if it was created solely for the test and is empty. Remove temporary identity grants and clear
AWS_ENDPOINT_URL_LAMBDA before returning to native AWS work.Microsoft Azure
Functions, Container Apps and AKS
Use the Azure profiles to establish eligibility before pricing. A requirement for cluster-specific networking or scheduling can favor evaluating AKS; an application with compatible hosting requirements and no cluster operator can evaluate the managed choices. Neither is an across-the-board recommendation.
Workload example: interactive authentication
Consider a synchronous token-validation handler with quiet periods, sudden login bursts and a database with a limited connection budget. Compare Azure Functions Premium with Flex Consumption. Premium exposes a resource envelope and warm-capacity allocation that must be matched to the handler’s requirements. The application keeps its Lambda client and handler contract. Tensor9 packages the runtime and routes the supported invocation to Azure’s hosting service. Warm allocation reduces reliance on starting a new worker for the first request; it does not eliminate deployment or burst scale-out startup. Include idle-capacity charges in either plan’s configured cost. Measure the first call after idle, the first call after deployment and a burst larger than the warm fleet separately. Do not average those results into one latency number. A maximum-instance setting also needs a downstream connection budget: old and new deployments can overlap, and a replica ceiling is not proof of an exact simultaneous-request bound. Flex Consumption has its own code-package requirements and resource controls. Azure offers always-ready controls on Flex; this is not a universal warm-versus-cold product distinction. Compare the configured plans, packaging and measured behavior, including their warm allocation, rather than choosing from the names alone. See Azure hosting choices.Check container isolation and downstream demand
For a handler using temporary files or process-local caches, test concurrent requests and a worker failure. On Container Apps, record how the configured workers share resources. On AKS, record the replica resources and node placement. The installed workload’s isolation behavior matters more than the word container in the product name. For either option, measure the deployment overlap as well as steady state: old and new workers can use database connections at the same time. Include image production, dependency updates, rollback artifacts and application-side idempotency in the operating record.OCI
OCI Functions or OKE function Deployments
For a small synchronous transformation, test OCI Functions against the real package, first-call latency and response deadline. For a workload requiring a cluster placement or resource setting unavailable in that mapping, examine the OKE profile rather than assuming all Lambda configurations fit Functions. Compare the OCI Functions profile with the same handler contract.
Both candidates need a failure test after a side effect but before the caller receives success. Keep application data outside temporary worker storage, preserve idempotency keys and verify the target result before retrying an ambiguous completion. Include native identity and the permitted database network path in the test, not only a no-op handler.
Scaleway
Serverless Containers, Knative or Kubernetes Deployments
For occasional internal jobs, compare the measured idle allocation and startup delay of all eligible options. For steady traffic on an operated cluster, compare allocated worker capacity with Knative’s platform costs and the managed service’s resource model. The Scaleway profile and cluster profiles define different operating responsibilities.
Run the largest input, an overlapping retry and a deployment under traffic. A change of execution service does not transfer output objects or drain existing work automatically. Preserve the old route until in-flight work and result correctness have been reconciled.