> ## 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. # Tuning AWS Lambda > Tune Lambda execution resources, warm capacity, concurrency and deadlines for each target runtime. Tune the directed service adapter you selected: for example, **AWS Lambda to Google Cloud Run**. The backend is Cloud Run; the adapter is the origin-to-target pairing and its supported behavior. The same Lambda memory or timeout value can require different target resources on a different adapter. Start with [Trade-offs in AWS Lambda](/cloud-adapter/trade-offs/aws-lambda) if you have not chosen a hosting model. This article covers [configuration scope](#put-each-setting-with-its-owner), [Cloud Run](#lambda-to-cloud-run), [Azure](#lambda-to-azure-functions), [private Kubernetes](#lambda-to-knative-or-kubernetes), [other container runtimes](#other-container-runtimes), and a [safe tuning procedure](#make-a-measured-change). ## Put each setting with its owner | Control | Scope and owner | Example | | --------------------------------------------------------- | ------------------------------------------------------------------ | --------------------------------------------------------- | | Backend selection | Function lifecycle and deployment | Select `google::1.0.0::cloud-run` for the Lambda function | | Handler memory, timeout and environment | Origin function configuration, interpreted by the selected profile | Request 1,024 MiB and a 30-second timeout | | Accepted target-native tuning fields | The selected adapter's function tuning surface | Cloud Run `template.timeout` | | Hosting plan, nodes, private networking and shared quotas | Target installation or infrastructure owner | Azure Premium SKU; Kubernetes node capacity | | Business concurrency and retry policy | Application | Limit simultaneous database writes; use stable job IDs | Use [tuning tags](/cloud-adapter/tuning/overview) only for paths accepted by the selected adapter. A field in a provider API is not automatically an accepted `t9:tuning:` path. An operator changing a shared hosting plan is doing something different from configuring one function. Backend selection does not migrate a function by renaming a tag. Treat a change of hosting service as deployment and routing work, with the old artifact retained for reversal. The [Lambda profile](/cloud-adapter/service-catalog/aws/compute-containers/lambda-function) describes which lifecycle and invocation operations belong to each pairing. ## Lambda to Cloud Run ### Size the actual working set Measure runtime baseline, native libraries, input buffers, output buffers and temporary files together. The Cloud Run mapping uses memory for temporary-file contents; `/tmp` is not a separate durable disk budget. A 600 MiB heap plus 500 MiB of scratch data is not a safe fit in a 1 GiB memory allocation. For an illustrative image worker, compare 1,024 MiB and 2,048 MiB using the same image and largest permitted input. Record peak resident memory, scratch usage, elapsed processing time and retries. Choose the smaller setting only if it retains operational headroom during the worst observed input, not merely the median one. These values are trial inputs, not a sizing recommendation for every handler. Inspect the resulting CPU and memory on the target revision. The mapping and native resource tiers determine the allocation; equal Lambda memory values are not evidence of identical CPU performance across Cloud Run, Azure Functions and Kubernetes. Keep the image, dependency versions and input set fixed while comparing resource sizes. ### Set a deadline that has a defined meaning The origin `Timeout` and the accepted Cloud Run `template.timeout` field both concern invocation duration. Avoid conflicting values. For a function whose intended request deadline is 30 seconds, the corresponding target tuning fragment is: ```json theme={null} { "t9:backend": "google::1.0.0::cloud-run", "t9:tuning:template.timeout": "30s" } ``` This is the **tags fragment** of the function lifecycle request, not a complete `CreateFunction` body or an instruction to edit a running native service behind its controller. Supply code, identity and other required function fields through the supported lifecycle. Inspect the effective target revision after it becomes ready. If the origin already expresses the desired deadline, prefer that single source of intent over adding a redundant override. A Cloud Run deadline ends the response wait; it does not establish that the handler stopped. Google's [request-timeout documentation](https://docs.cloud.google.com/run/docs/configuring/request-timeout) makes this distinction explicit. Use bounded downstream calls, application deadlines and idempotent commits. Do not solve a slow dependency by simply raising every timeout: longer waits retain more concurrent work and connections. For a job that normally completes within ten seconds, an illustrative budget could be a 20-second application work deadline, a 30-second target request deadline and a 35-second caller read timeout. The gaps provide time to report a controlled failure. Verify them against startup and network behavior; they are not a guarantee that the target will terminate unfinished application work at 20 seconds. ### Budget warmth and concurrency separately A warm floor controls allocated readiness; the maximum instance count controls a scaling boundary. Neither replaces application admission control. Include old/new revision overlap and temporarily excess instances in the downstream budget. Do not raise per-instance request concurrency without checking the selected Lambda adapter's isolation contract. Suppose a database permits 80 application connections. If each worker can retain four connections, 20 active workers already consume that allowance before migrations, admin access or overlapping deployments. Start below that arithmetic ceiling, reserve headroom and enforce a connection pool limit. A native instance cap alone does not prove a strict 80-connection upper bound. Configure warm instances and capacity through the deployment's accepted controls and review native revision settings. Do not infer that every native scaling field is a tuning tag. Measure three separate cases: a first call after idle, a new release and a burst beyond the warm fleet. Paying for two warm workers does not prewarm the other workers required by a large burst. ## Lambda to Azure Functions ### Flex Consumption Use the profile's code-package model and measure the complete package: the handler, runtime, libraries and embedded invocation components. Updating an embedded component requires a rebuilt deployment artifact. An image that works on a container-hosting service is not itself a Flex code package. Choose the memory allocation and always-ready policy through the function app's supported deployment controls. Test a quiet period followed by a burst and observe instance count, initialization and temporary storage. Flex's always-ready setting is a real capacity choice, with an idle cost; do not compare it to Premium while pretending that one option is necessarily cold. Microsoft's [Flex Consumption documentation](https://learn.microsoft.com/en-us/azure/azure-functions/flex-consumption-plan) describes these hosting controls. For a small authentication handler, start from its connection and first-request budgets. Compare a low warm allocation with scale-to-zero using the same code and request mix. If the measured tail meets the requirement without warmth, reclaim the idle allocation. If it does not, add warm capacity or reconsider the selected hosting plan rather than obscuring timeouts with extra retries. ### Premium Premium adds an explicit hosting-plan capacity floor and supports the profile's larger resource and packaging choices. Select the plan SKU for the actual memory, CPU and scratch-space demand, then configure the always-ready allocation and scale-out policy. A larger plan changes more than the function's nominal memory value. For a native-library worker, compare the current plan with the next candidate size using representative files. Record initialization, processing duration, temporary storage and cost per successful result. Count repeated or failed invocations in that cost. More memory is useful when it prevents resource failures or materially improves throughput; it is not a substitute for fixing unbounded buffers. Keep the plan's shared capacity visible. Functions sharing a plan can compete during deployments and bursts. The platform owner pays for and monitors the plan; the application owner defines per-function admission and dependency budgets. Consult the [Premium profile](/cloud-adapter/service-catalog/aws/compute-containers/lambda-function#azure-functions-premium) and [native Premium guidance](https://learn.microsoft.com/en-us/azure/azure-functions/functions-premium-plan) before changing hosting configuration. ## Lambda to Knative or Kubernetes For **Knative**, tune function resource requests and limits, minimum warm replicas, scale-out ceilings and startup behavior through the deployment owner. Reserve cluster headroom for simultaneous bursts across functions. A function's ability to scale does not mean that a node exists on which to schedule it. For **plain Kubernetes Deployments**, replicas are allocated workers. Tune replicas, requests/limits, rollout overlap and the dependency connection pool together. This model does not acquire request-driven scale-to-zero merely because the handler uses the Lambda API. A Kubernetes liveness restart is also not a per-invocation deadline. Consider 30 low-volume functions with one always-warm worker each. Measure the combined idle reservations before deciding whether Knative's shared platform footprint is worthwhile. Then test a simultaneous burst across ten functions in addition to testing one function in isolation. Record pending pods, image-pull duration, node pressure, handler startup and end-to-end completion. One worker per replica provides a clearer process-resource boundary than packing many workers into one container. Packing can reduce overhead but shares memory, temporary files and crash scope. Use only the worker model described by the chosen profile. Tuning does not make process-local storage durable or prevent a cluster-wide outage. ## Other container runtimes | Directed adapter | Controls to inspect | What to verify before raising capacity | | ---------------------------------------- | -------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | | Lambda to Azure Container Apps | CPU/memory tier, replica floor and ceiling, worker placement | Whether workers share temporary storage and memory; completion after timeout; deployment overlap | | Lambda to OCI Functions | Function allocation tier, image, timeout and application network placement | Actual startup, native resource rounding and downstream reachability | | Lambda to Scaleway Serverless Containers | Container CPU/memory, minimum/maximum instances and network configuration | Image compatibility, startup and deadline behavior in the selected profile | These are target deployment controls, not a claim that every row has a corresponding tuning-tag path. Keep resource tier, private networking and shared quotas in the infrastructure that owns them. Preserve the origin handler contract while inspecting the resulting native allocation. ## Make a measured change Run the [synchronous completion probe](/cloud-adapter/trade-offs/aws-lambda#try-synchronous-retry-and-completion) first. It supplies the fixture, endpoint configuration, explicit-client alternative, expected output and cleanup. Use `tradeoff-thumbnail`, not a production handler. Record the image digest, directed adapter, effective target configuration and input fixture. Separate first-after-idle, warm, deployment and burst measurements. Preserve function errors as well as successful timings. For the Cloud Run example, compare two memory allocations before changing warmth. Keep input, concurrency and deadline fixed. For an Azure comparison, keep the application workload fixed while changing the hosting allocation. Review the target diff and wait for ready routing before sending trial traffic. A tuning value being admitted is not proof that a ready native revision has that value. Inspect the effective configuration and record which revision handled the requests. Measure latency percentiles, error rate, peak resources and downstream connections. Repeat caller timeout, retry of the same job ID and rollout overlap. Check the native output object after a timeout; do not assume an error response means the write did not happen. Use [Explain](/cloud-adapter/debugging/explain-sdk) when investigating the route or target operation, but collect performance baselines without diagnostic overhead as a separate run. Preserve the report and native evidence for the same request identity. Accept a setting only when it meets the workload's correctness and resource budgets. Restore the previous deployment configuration and image if it does not. Wait for the old route to be ready, account for outstanding work, and verify downstream state before repeating a failed job. Remove only the disposable function and fixture objects when finished. Return any temporary warm allocation to its original level and remove temporary credentials or grants. A completed test should not leave an idle hosting bill behind. Keep a short record of the chosen resource envelope, startup budget, downstream connection allowance, accepted timeout semantics and rollback artifact. Re-run the relevant cases when the handler's dependencies, image size or traffic shape changes. Return to [Trade-offs in AWS Lambda](/cloud-adapter/trade-offs/aws-lambda) if meeting the new requirements would require a different execution model.