> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tensor9.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Trade-offs in AWS Lambda

> Choose a Lambda adapter around invocation, startup, isolation and the resources your handler needs.

A function can run successfully and still be on the wrong backend. An authentication handler may need warm capacity. An image processor may need a particular container image and a large temporary working set. A private installation may value control over the runtime more than scale-to-zero.

Choose the execution model and the invocation contract together. This article compares synchronous `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](/cloud-adapter/service-catalog/aws/compute-containers/lambda-function) identifies each environment's directed mappings and their packaging, lifecycle and invocation behavior.

### Invocation, packaging and capacity

| Question                             | Why it matters                                                                                                                                         |
| ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Who waits for completion?            | Synchronous callers wait for a result. Durable asynchronous delivery needs a separate acceptance, persistence, retry and failure-destination contract. |
| What does a timeout stop?            | A response deadline can expire while the handler continues writing. A retry may overlap that work.                                                     |
| What is the isolation boundary?      | A worker process, a container replica and an isolated invocation are not the same thing. Warm invocations can reuse memory and temporary files.        |
| How is concurrency bounded?          | Requests per worker, maximum instances and a strict fleet-wide admission limit are distinct controls.                                                  |
| What must be packaged?               | Native libraries, image architecture, runtime startup and temporary storage can eliminate a candidate before price matters.                            |
| Who operates the execution platform? | Managed function hosting removes cluster duties, not image maintenance, application recovery or downstream capacity planning.                          |
| Where are the dependencies?          | A function near its caller but far from its database can add a network hop to every request.                                                           |

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

| Component or state                        | Budget and operation                                                                      | Capacity, recovery and failure boundary                                                                                    |
| ----------------------------------------- | ----------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- |
| Managed function runtime                  | Customer platform team funds and monitors it; provider operates hosting                   | Team selects resource tier, warm floor, ceilings and rollback artifact; one hosting failure can affect multiple functions  |
| Knative or Kubernetes runtime             | Customer platform team operates nodes, networking and runtime                             | Team upgrades, reserves headroom and restores deployment configuration; shared cluster incidents affect colocated handlers |
| Adapter routes and configuration          | Named adapter operating team deploys and monitors Tensor9                                 | Preserve desired configuration and any authoritative lifecycle state; restore function readiness before relying on routes  |
| Result objects and other application data | Application owner defines correctness; platform owner supplies native storage and backups | Restore independently of function code; retries and rollback must account for already committed side effects               |

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](/cloud-adapter/service-catalog/aws/compute-containers/lambda-function#cloud-run) 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](https://docs.cloud.google.com/run/docs/configuring/request-timeout).

### 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.

<Steps>
  <Step title="Prepare an isolated function and result bucket">
    Use a disposable Google Cloud test deployment, a bucket named `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](/cloud-adapter/deployment/provisioned). Give its target workload identity access only to the test result bucket. Wait for the function to become ready and record its adapter endpoint.

    ```python theme={null}
    import json
    import time
    from google.api_core.exceptions import PreconditionFailed
    from google.cloud import storage

    def handler(event, context):
        job_id = event["job_id"]
        if job_id not in {"image-1001", "image-1002"}:
            raise ValueError("Only this trial's job IDs are accepted")
        payload = json.dumps({"job_id": job_id, "result": "thumbnail-ok"},
                             sort_keys=True).encode()
        blob = storage.Client().bucket("acme-adapter-trial-results").blob(
            "tradeoff/" + job_id + ".json")
        try:
            blob.upload_from_string(payload, content_type="application/json",
                                    if_generation_match=0)
        except PreconditionFailed:
            if blob.download_as_bytes() != payload:
                raise ValueError("Job ID already has a different result")
        time.sleep(min(float(event.get("delay_after_write", 0)), 10))
        return {"job_id": job_id, "object": blob.name}
    ```

    The [conditional object creation](https://docs.cloud.google.com/storage/docs/request-preconditions) 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 `tradeoff/image-100*.json` objects do not exist.
  </Step>

  <Step title="Inspect the mapping and configure the caller">
    ```bash theme={null}
    tensor9 explain \
      -origin aws::1.0.0::lambda::function \
      -target google::1.0.0::cloud-run \
      -operation Invoke -fmt Human

    export AWS_ENDPOINT_URL_LAMBDA="<test adapter endpoint>"
    export AWS_PROFILE="adapter-test"
    export AWS_REGION="us-east-1"
    ```

    The AWS profile is the origin-facing identity accepted by the adapter. Google credentials belong to the function and adapter, not this caller. Profile inspection describes the mapping; it does not invoke the handler.
  </Step>

  <Step title="Invoke twice with the same job ID">
    Run this command twice, saving the second response to `thumbnail-repeat.json`:

    ```bash theme={null}
    aws lambda invoke \
      --function-name tradeoff-thumbnail \
      --invocation-type RequestResponse \
      --cli-binary-format raw-in-base64-out \
      --payload '{"job_id":"image-1001"}' \
      thumbnail-first.json
    ```

    Both calls should return no `FunctionError` and identify `tradeoff/image-1001.json`. Verify the actual object, not only the response:

    ```bash theme={null}
    gcloud storage cat gs://acme-adapter-trial-results/tradeoff/image-1001.json
    ```

    Expected content is the fixture's `job_id` and `thumbnail-ok` result. Use the [AWS CLI invocation reference](https://docs.aws.amazon.com/cli/latest/reference/lambda/invoke.html) for its binary-payload and output-file conventions.
  </Step>

  <Step title="Test an ambiguous completion without automatic retries">
    Save and run the following client. The explicit endpoint is the client-specific alternative to `AWS_ENDPOINT_URL_LAMBDA`.

    ```python theme={null}
    import json
    import boto3
    from botocore.config import Config
    from botocore.exceptions import ReadTimeoutError

    client = boto3.client("lambda", region_name="us-east-1",
        endpoint_url="<test adapter endpoint>",
        config=Config(read_timeout=1, retries={"total_max_attempts": 1}))
    try:
        response = client.invoke(FunctionName="tradeoff-thumbnail",
            InvocationType="RequestResponse",
            Payload=json.dumps({"job_id": "image-1002",
                                "delay_after_write": 5}).encode())
        print(response["Payload"].read())
    except ReadTimeoutError:
        print("Caller timed out; inspect the target before retrying")
    ```

    Wait for the fixture's five-second delay to finish, inspect `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](/cloud-adapter/debugging/overview) to distinguish routing, handler and native-storage failures.
  </Step>

  <Step title="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.
  </Step>
</Steps>

## Microsoft Azure

### Functions, Container Apps and AKS

| Backend                          | Strengths and workload fit                                                                                                                       | Costs and constraints to accept                                                                                                                              |
| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Azure Functions Flex Consumption | Code-package functions whose resource needs fit the hosting plan; configured always-ready capacity can serve a first-request latency requirement | Packaging and resource controls differ from Premium; compare configured idle allocation and bursts rather than treating it as universally cold               |
| Azure Functions Premium          | Handlers needing the plan's packaging/resource options and configured warm capacity                                                              | Warm allocation has an idle cost; scale-out and deployments still require startup testing                                                                    |
| Azure Container Apps             | Container-packaged handlers within a managed container execution model                                                                           | Compare worker isolation, temporary storage, per-replica resources and request handling with the Lambda mapping; replication is not strict admission control |
| AKS function Deployments         | Handlers requiring cluster placement and runtime control with an AKS operating team                                                              | Your team owns Kubernetes capacity, networking, upgrades and recovery alongside the function; allocated replicas consume capacity while idle                 |

Use the [Azure profiles](/cloud-adapter/service-catalog/aws/compute-containers/lambda-function#on-azure) 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](https://learn.microsoft.com/en-us/azure/azure-functions/functions-scale).

| Decision                             | Authentication example                                                                                                                                               |
| ------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Allowed environment and requirements | Azure; synchronous calls; first-request latency budget; bounded database connections                                                                                 |
| Candidates                           | Functions Premium and Flex Consumption                                                                                                                               |
| Selection scope                      | Function lifecycle configuration for either hosting plan; retain Lambda request/response calls                                                                       |
| Cost and owner                       | Record idle and active charges for each configured plan. Customer platform team monitors Azure hosting; application team owns connection pools and retry safety      |
| Evidence for each candidate          | [Lambda service profile](/cloud-adapter/service-catalog/aws/compute-containers/lambda-function#on-azure), followed by identical idle, deployment and burst tests     |
| Eligibility checks                   | Required package, resource envelope and measured latency must fit; exclude any configuration that exceeds the database connection budget                             |
| Next configuration step              | Set the hosting tier and warm floor through the deployment owner; test downstream saturation before raising the ceiling                                              |
| Migration and rollback               | Canary through the application's approved routing mechanism; retain the old deployment until new results are accepted. Rollback does not undo authentication writes. |

### 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

| Backend                  | Strengths and workload fit                                                                                    | Costs and constraints to accept                                                                                                        |
| ------------------------ | ------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
| OCI Functions            | Provider-operated invocation for handlers fitting the supported image, resource and synchronous-call contract | Native allocation and duration limits apply; do not infer strict Lambda reserved concurrency or identical temporary-storage behavior   |
| OKE function Deployments | Cluster placement and runtime controls for workloads with an OKE operator                                     | Customer-owned cluster capacity, rollout, networking and recovery; replica capacity and invocation admission remain different controls |

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](/cloud-adapter/service-catalog/aws/compute-containers/lambda-function#oke-function-deployments) rather than assuming all Lambda configurations fit Functions. Compare the [OCI Functions profile](/cloud-adapter/service-catalog/aws/compute-containers/lambda-function#oci-functions) 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

| Backend                        | Strengths and workload fit                                                   | Costs and constraints to accept                                                                                                              |
| ------------------------------ | ---------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- |
| Scaleway Serverless Containers | Provider-operated image execution for handlers fitting its directed contract | Check packaging, networking, resource tiers and duration; do not infer every Lambda lifecycle or delivery feature from successful invocation |
| Knative Service                | Request-driven function execution on a controlled cluster                    | Your team operates Knative networking and upgrades as well as Kubernetes; startup and shared-capacity pressure require testing               |
| Kubernetes Deployments         | Allocated workers on an existing operated cluster without a Knative platform | Idle replicas consume resources; implement and verify the required scaling and routing behavior through the deployment                       |

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](/cloud-adapter/service-catalog/aws/compute-containers/lambda-function#scaleway-serverless-containers) and [cluster profiles](/cloud-adapter/service-catalog/aws/compute-containers/lambda-function#kubernetes-cluster) 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.

## DigitalOcean

### Kubernetes Deployments

The documented backend is a function Deployment on Kubernetes. This can fit handlers that need an operated cluster in DigitalOcean and whose owners accept allocated workers, node capacity and cluster recovery. It does not mean DigitalOcean's separate native function products are Lambda adapters.

Measure idle replicas, simultaneous handler bursts and node replacement with the real images. A function's replica count is an allocation decision, not an exact upper bound on application-side effects or downstream calls. Use the [Kubernetes mapping](/cloud-adapter/service-catalog/aws/compute-containers/lambda-function#kubernetes-cluster), assign a platform recovery owner and test the application's timeout and retry contract before deployment.

## Akamai

### Knative or Kubernetes Deployments

Both documented backends run on the target cluster. Knative adds request-driven scheduling and capacity policy with its own platform operation; plain Deployments allocate workers without that extra platform. For many quiet functions, compare reclaimed idle allocation against startup delay and Knative's operating footprint. For steady handlers, compare the same throughput and rollout budget on allocated replicas.

The platform team owns node capacity, networking and recovery for both options. Test simultaneous bursts across functions and a failed shared routing component, not only one isolated handler. See the [Knative mapping](/cloud-adapter/service-catalog/aws/compute-containers/lambda-function#knative-service) and [Kubernetes mapping](/cloud-adapter/service-catalog/aws/compute-containers/lambda-function#kubernetes-cluster).

## Private Kubernetes

### Knative or Kubernetes Deployments

Both options keep execution in the customer's cluster. Choose between them using per-function latency, aggregate resource demand and the platform team's capacity to operate Knative. Private placement does not itself establish invocation isolation, data durability or a Lambda-style admission limit.

### Workload example: many mostly idle functions

A customer has an existing Kubernetes cluster and many low-volume internal handlers. Compare **Knative** with **plain Kubernetes Deployments**, both inside that cluster.

Knative's request-driven scheduling allows different functions to have different warm-capacity policies, including reclaiming eligible quiet functions' idle allocations. Compare configured warmth and measured startup against each handler's latency budget. The customer's platform team must own Knative networking, upgrades, scheduling and recovery in addition to Kubernetes itself.

Plain Deployments allocate workers through replica counts without adding Knative's execution platform. Measure idle resource consumption, request routing and available capacity alongside Knative's scaling behavior and platform footprint. Replica counts establish allocated workers, not a Lambda-style fleet-wide admission guarantee. Both alternatives need downstream connection limits and a response-timeout policy.

Test several functions bursting together. A per-function test can look healthy while their aggregate memory demand exceeds available nodes. Include cold image pulls, a worker crash, a rollout and failure of a shared routing component. Confirm that temporary files and process-local caches are not treated as durable state.

| Decision                             | Private-function example                                                                                                                                                                                                                                              |
| ------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Allowed environment and requirements | Customer Kubernetes only; many mostly idle functions; application-specific latency budgets                                                                                                                                                                            |
| Candidates                           | Knative Service and plain Kubernetes Deployments                                                                                                                                                                                                                      |
| Selection scope                      | Each function's deployment configuration; keep invocation and in-flight-work requirements explicit for both candidates                                                                                                                                                |
| Cost and owner                       | Customer platform team operates the cluster for both, and Knative in that option; compare idle replica allocations, recovered capacity and platform operation                                                                                                         |
| Evidence for each candidate          | [Kubernetes profile](/cloud-adapter/service-catalog/aws/compute-containers/lambda-function#kubernetes-cluster), [Knative profile](/cloud-adapter/service-catalog/aws/compute-containers/lambda-function#knative-service), and simultaneous multi-function burst tests |
| Eligibility checks                   | Verify latency, aggregate capacity, routing failure behavior and an assigned recovery owner for each configuration                                                                                                                                                    |
| Next configuration step              | Set a per-function warm floor and resource budget, then check aggregate node capacity                                                                                                                                                                                 |
| Migration and rollback               | Move one noncritical function first, preserve its previous Deployment and route, and verify results before expanding. External state and queued work need separate migration.                                                                                         |

## Next steps

Record the selected directed adapter, packaging, resource budget, response deadline, retry behavior and operating owner. Warmth and memory do not turn synchronous invocation into durable asynchronous delivery. Configure the chosen backend with [Tuning AWS Lambda](/cloud-adapter/tuning/aws-lambda).