Cold-start tuning

Settings and code changes that shorten Lambda cold starts, each backed by a measurement from the benchmark or from a dated one-off probe. The effect depends on memory tier, architecture, and handler, so test any change against your own function before relying on it.

Some levers remove work. Others only move it into the Init phase, which shortens an on-demand cold start only below about 1.8 GB, where Init gets more CPU than the handler; at larger sizes the work costs about the same in either phase. That extra CPU is undocumented behavior that AWS can change. Environments initialized before any request arrives (provisioned concurrency, SnapStart, Lambda's proactive initialization) take init work off the request path at any size. A provisioned-concurrency init did not get the extra CPU, though: at 128 MB it ran at the tier's share, ~17x slower than the same init on demand (only the first ~10 seconds of an init are boosted). The table marks each lever as "Removes work" or "Moves to Init".

Every runtime

Do one-time setup at init

Create clients, read configuration, and do other one-time work outside the handler, so it runs during the Init phase.

Below about 1.8 GB, the Init phase appears to get more CPU than the handler, which runs on the tier's share of a vCPU. The same work therefore finishes sooner at init, and the difference is largest at the smallest tiers: the Rust SDK's aws_config::load() takes ~55 ms at init but ~900 ms in the handler at 128 MB (same work, different phase).

At 1,769 MB and above the handler has at least a full vCPU, so moving work to init no longer shortens an on-demand cold start. It still helps with provisioned concurrency, SnapStart, and proactive initialization, where Init runs before the request.

Keep .zip packages small

Lambda downloads a .zip in full before Init starts, so its size cost appears in no REPORT metric: a flat floor up to a few MB, then roughly 3-8 ms per MB. A container image loads lazily: only the blocks that are read get fetched, that cost appears in Init Duration, and it grows with how much the function reads at init. For a container image, the amount read at init matters more than the image size. Measurements: zip vs container image.

Why the first request is slow: loading code

Linux loads a program's code lazily, in 4 KB pages. The first use of a page triggers a page fault, and the kernel brings the page into memory. It then stays in the page cache, the kernel's in-memory copy of file contents, so later uses are cheap. A fault that has to read from disk first is a major fault.

On Lambda, a .zip function's code sits on a read-only squashfs image (/var/task) compressed with gzip in 128 KB blocks. The first touch of a page therefore reads the compressed block containing it from a virtual disk and decompresses the whole 128 KB in the kernel, even if only one small function in it is needed. That costs about 7 µs of CPU per KB read on arm64, roughly 0.5 ms per block. It is CPU time charged to the function, so at 128 MB the handler's small CPU share stretches it about tenfold.

An example from the crypto probe: aws-lc's first random-number call in the handler caused 3 major faults, read 478 KB from the disk and used ~4.5 ms of CPU. With a full vCPU (1,024 MB and up, or in Init) it took about that long in wall time too, so the time is computation rather than waiting on I/O. At 128 MB it took ~48 ms; on a local machine, where the file is cached, ~27 µs.

• Only code the cold start runs costs time. Code that never runs is never loaded, and code that first runs in the handler costs the most.
• Where the linker places code changes the cost. Code first used by the first request costs one block load per block it lands in, so where the linker happens to place it can add or save tens of ms at 128 MB (see putting it together).
• The fault count is a poor measure. The kernel reads ahead around a faulting page, so one fault can load one or several blocks; the cost follows the KB read.
• The page cache counts toward the function's memory. Reading a 20 MB packaged file raised "Max Memory Used" by exactly 20 MB. At the limit the kernel evicts cached pages instead of failing the function: a 128 MB function that read 150 MB of packaged files peaked at ~117 MB, and its own code pages had been evicted too, so the next steps faulted again (9 major faults instead of 5).

Rust

Several levers attack the same cost, loading code, so their gains overlap rather than add up; putting it together shows the combinations on smithyfull.

Load root certificates from the CA bundle

Applies to: rustls-native-certs, which the AWS SDK for Rust uses by default to load the OS root certificates, on provided.al2023.

By default, rustls-native-certs loads the CA bundle plus every file in /etc/ssl/certs and /etc/pki/tls/certs. On provided.al2023 each root appears there several times: in the bundle, as its own file, and as two hash symlinks to that file, and both directories also link to the bundle. Every one of those is read and parsed. Setting the function's environment variable SSL_CERT_FILE=/etc/pki/tls/certs/ca-bundle.crt makes it read only the bundle. In this test both configurations returned the identical set of 251 roots.

(rustls-native-certs 0.8.4, load_native_certs() timed inside the function, 20 forced cold starts per cell.)

The Rust SDK builds its HTTPS client inside aws_config::load(), so for a handler that loads its config at init, the Init columns apply.

rustls-native-certs 0.8.5 (released 2026-10-13, #256) reads each file in the certificate directories only once, without changing which roots load. In the SDK probe (25 forced cold starts per cell), root loading inside aws_config::load() dropped from ~27 ms with 0.8.4 to ~16 ms with 0.8.5 at both 128 MB and 1,024 MB, and Init dropped by the same ~11 ms. With 0.8.5, setting SSL_CERT_FILE therefore saves ~16 ms instead of ~27 ms. On the benchmark's smithyfull with 0.8.5 it took ~13 ms off the cold start in eu-central-1 and ~22 to ~26 ms in us-east-1, at 128 MB and 1,024 MB alike (putting it together). The single-lever Rust measurements elsewhere on this page used 0.8.4.

The x86_64 handler cell with SSL_CERT_FILE split into two groups, about half the samples near 3 ms and half near 38 ms, consistent with the load sometimes crossing a CPU-throttling boundary. In the crypto probe at 128 MB, such a wait lasted ~19 ms and landed on whichever step crossed the boundary: DNS lookups that otherwise took ~1 ms took ~19 ms while using ~0.2 ms of CPU.

Go's crypto/x509 loads its roots differently: it still scans both directories when only SSL_CERT_FILE is set; see skip the certificate directory scan.

Disable jitter entropy at build time

Build with AWS_LC_SYS_NO_JITTER_ENTROPY=1. AWS-LC then skips CPU jitter entropy collection, which otherwise runs the first time anything in the process uses its random number generator, typically the first TLS handshake. That removes the one-time cost in whichever phase it would have landed, roughly half a second in the handler at 128 MB. If you keep jitter entropy on, seed the RNG at init instead.

Reading the executable at init does not replace this. Jitter collection is CPU work, which the read does not remove. With jitter entropy on, the first rand::fill in the handler at 128 MB took ~630 ms without the read and still ~485 ms (~35 ms of CPU) with it.

Turn off the SDK crates' default features

The SDK crates' default features include a legacy HTTP client (hyper 0.14 with rustls 0.21 and ring), and aws-config's defaults add SSO and credential_process support. A Lambda function needs none of these:

aws-config = { version = "1", default-features = false, features = ["rt-tokio", "default-https-client"] }
aws-sdk-dynamodb = { version = "1", default-features = false, features = ["rt-tokio", "default-https-client"] }

This leaves the SDK's default hyper 1.x client with rustls on aws-lc, so behavior is unchanged unless you used SSO, credential_process or SigV4a (an S3 default feature, needed for Multi-Region Access Points). In the SDK probe (25 forced cold starts per cell, interleaved) the three-client binary shrank from 10.0 MB to 8.1 MB, Init dropped by ~7 ms, and the cold start went from ~330 ms to ~300 ms at 128 MB and from ~166 ms to ~152 ms at 1,024 MB.

The removed code never runs, and with the executable already in the page cache both builds took the same time, so the gain comes from loading less code:

• Unread bytes cost nothing. 2 MiB of padding the process never reads left the cold start unchanged.
• The default build loads more of itself for the same work. It had ~600 KB more of its executable in memory after Init (5.0 MB against 4.4 MB) and ~850 KB more after the first request (6.8 MB against 5.9 MB), with a few more major faults and ~6 ms more CPU at Init. Which code those extra pages hold was not traced.
• It overlaps with the executable read. With the executable read at init, turning off default features saved only ~6 to ~18 ms more, mostly because the smaller file is quicker to read.
• SigV4a alone made no measurable difference when added back.

Consider rustls on ring

The SDK's HTTPS client can use rustls on ring instead of aws-lc. Leave the SDK crates' default features off as above, drop default-https-client, and pass the client to the loader:

aws-smithy-http-client = { version = "1", features = ["rustls-ring"] }

use aws_smithy_http_client::{Builder, tls};

let http = Builder::new()
    .tls_provider(tls::Provider::Rustls(tls::rustls_provider::CryptoMode::Ring))
    .build_https();
let config = aws_config::defaults(BehaviorVersion::latest()).http_client(http).load().await;

The three-client binary shrank to 6.7 MB, and the cold start went from ~371 ms to ~239 ms at 128 MB and from ~166 ms to ~146 ms at 1,024 MB. Most of that is less code to load: setting up rustls and making the first two handshakes caused 8 major faults reading 877 KB from the disk with aws-lc, and 4 faults reading 399 KB with ring, while warm handshakes took the same time with either library (~2 ms at init).

With the executable read at init, smithyfull was still ~27 ms faster with ring at 128 MB and ~5 ms faster at 1,024 MB. Most of that remainder is about 1 ms more CPU in aws-lc's first request, partly from mapping more already-cached pages, stretched by the handler's CPU share at 128 MB. With connections opened at init instead, ring was 6 to 11 ms faster than aws-lc.

Open each client's connection at init

Applies to: the AWS SDK for Rust, which builds its HTTPS connection to a service on the first request to it.

That first request resolves DNS, opens the TCP and TLS connection, and runs code for the first time, all at the handler's CPU share. Making one real, side-effect-free call per client at init moves that work into the Init phase, and running the calls concurrently overlaps their round trips:

// In main(), after building the clients and before lambda_runtime::run.
// An error response (such as an S3 404) still leaves the connection open.
let _ = tokio::join!(
    kms.encrypt().key_id(&key_id).plaintext(Blob::new(b"warm".to_vec())).send(),
    ddb.get_item().table_name(&table).key("pk", AttributeValue::S(pk.clone())).send(),
    s3.head_object().bucket(&bucket).key(&receipt_key).send(),
);

(15 forced cold starts per cell.)

Init grew by ~18 ms (one client) to ~36 ms (three), and the first request dropped to about a warm request's time.

• At small memory sizes the gain relies on the Init CPU boost, like any one-time setup at init.
• With a single client, expect no gain at 1 GB and above, where the handler has enough CPU: opening the connection costs about the same in either phase.
• With several clients the calls at init run concurrently, while the handler's first requests open their connections one after another. This overlap does not depend on the Init CPU boost; smithyfull still gained ~10 to ~16 ms at 1,769 MB (one full vCPU) and 3,008 MB.

Read the executable at init

Applies to: Rust binaries on provided.al2023, when nothing else at init touches most of the code. Go gained ~25 ms at 128 MB on arm64 and nothing at larger sizes, and Java gained nothing (see other runtimes).

Reading the whole executable once, first thing in main(), loads and decompresses all of it in one sequential pass while Init still has plenty of CPU. Later first uses then find their pages already in the page cache instead of decompressing them in the handler:

#[tokio::main]
async fn main() -> Result<(), Error> {
    // First thing: read the executable once so its pages are in the page cache.
    if let Ok(mut exe) = std::fs::File::open("/proc/self/exe") {
        let _ = std::io::copy(&mut exe, &mut std::io::sink());
    }
    // ... create the clients, then lambda_runtime::run(service_fn(handler)).await
}

After the read the crypto probe saw no major faults at all:

(15 forced cold starts per cell.)

The read itself costs Init time, mostly decompression: ~8 ms for the 3.2 MB crypto probe, ~32 ms for a 6.7 MB binary, ~48 ms for the 10 MB SDK probe, and ~15 ms of Init growth on smithyfull (11.5 MB). Whether that pays depends on the memory size, since the handler's CPU share decides how expensive the first touches would have been:

(25 forced cold starts per cell, interleaved.)

• Where it pays. At 128 and 256 MB. It breaks even around 512 MB and costs ~5 to ~10 ms from 768 MB up, also at 1,769 and 3,008 MB. On x86_64 it paid more: smithyfull at 128 MB went from ~487 ms to ~332 ms, and at 1,024 MB from ~231 ms to ~243 ms.
• It held in a second region and on every host generation. Built with the benchmark's lockfile, smithyfull at 128 MB went from ~361 ms to ~276 ms in eu-central-1 and from ~395 ms to ~298 ms in us-east-1. Split by host CPU, with both regions pooled: ~401 to ~295 ms on Graviton2, ~363 to ~282 ms on Graviton3, ~292 to ~226 ms on Graviton4.
• It adds nothing once connections are opened at init, since those calls already touch the code at init. Use it when you cannot make calls at init.
• Memory. The read keeps the whole binary in the page cache, which counts toward the function's memory: "Max Memory Used" rose by ~2 MB on smithyfull, which would otherwise have cached about 9 of its 11.5 MB anyway. At small sizes it is only worth it while the binary plus the function's own memory stay well under the limit, or the kernel evicts the pages again.
• Alternatives that did not help: reading the file on a background thread, and asking for readahead with posix_fadvise(POSIX_FADV_WILLNEED).

Other runtimes: Go and Java

The same test on copies of this benchmark's Go and Java oneclient handlers (10 to 20 forced cold starts per cell) found little or no gain:

• Go. About 80% of a Go binary was already in memory when main() started, in a minimal Go function as well as with the SDK: Go's runtime and package initialization run before main() and touch nearly every 128 KB block of code. With the certificate directory scan skipped, so that the rest of the cold start varied little, the read removed the first request's ~7 remaining major faults and gained ~25 ms at 128 MB on arm64 (~294 ms to ~268 ms). At 256 MB, at 1,024 MB, and on x86_64 at 128 MB the change was under ~5 ms.
• Java. The JVM and its class library are not on the compressed code image, and the JVM already reads the function's jars while Init builds the client. The first request was limited by CPU instead (class loading and interpreted code: ~10 s at 128 MB, ~2.3 s at 512 MB, ~1.1 s at 1,024 MB). Reading the jars or the JDK's class image at init left it unchanged, and the class image raised "Max Memory Used" from ~145 MB to ~259 MB. For Java, see prime SnapStart instead.

Seed the aws-lc-rs RNG at init

Applies to: aws-lc-rs (the default crypto backend for rustls and the AWS SDK for Rust), built without AWS_LC_SYS_NO_JITTER_ENTROPY=1.

aws-lc-rs collects CPU jitter entropy the first time anything in the process uses its random number generator. A TLS handshake does that, so if the first TLS connection happens in the handler, the cost lands in the first invocation. One call at init moves it, without a network call:

// In main(), before starting the Lambda runtime.
let mut seed = [0u8; 32];
aws_lc_rs::rand::fill(&mut seed).expect("aws-lc-rs RNG");

(Timed inside the function, 15 forced cold starts per row.)

The call moves the work rather than removing it, so the gain relies on the Init CPU boost like any one-time setup at init and disappears at about 1.8 GB and above. Disabling jitter entropy removes the cost at every size.

The handler-side call ran on a newly spawned thread, as a tokio worker would, so seeding on the main thread at init covers other threads too.

Check that cargo tree -i aws-lc-sys shows a single version. Each aws-lc-sys version links its own copy of AWS-LC with its own RNG, so seeding one copy leaves the one your TLS stack uses unseeded. The jitter-entropy panel shows how the cost grows as memory shrinks.

Order cold-start code at link time

Applies to: Rust binaries linked with lld, on x86_64. On arm64 it did not help (see arm64).

The functions a cold start runs are spread across the whole binary, so Init and the first request decompress many 128 KB blocks that hold mostly code they never run. A linker can be told to place a list of functions next to each other (lld's --symbol-ordering-file), which packs the cold-start code into fewer blocks.

In the experiment, one Init and first request of smithyfull ran locally under valgrind's callgrind, against the real services and behind a stand-in for the Lambda runtime API. That listed the 2,427 functions of the binary that ran. Linking with that list moved the 2.6 MB of cold-start code from 64 of the binary's 75 code blocks into 23:

(20 forced cold starts per cell, two runs.)

• No Init cost. Unlike the executable read, ordering costs nothing at larger sizes.
• It cannot remove every block load. The first request ran 1.7 MB of code that Init did not, which needs about 13 blocks in any layout; its major faults went from 22 to 15. At 128 MB the read still did better, and the two together were about the same as the read alone.
• One combined list worked best. Listing Init's functions first and the request's after them did no better, because request code mixed in with Init's lands in blocks Init loads anyway.
• It held in a repeat. A repeat in eu-central-1 and us-east-1 took the 128 MB cold start from ~504 ms to ~394 ms and from ~510 ms to ~398 ms.

On arm64 it did not help

The same source built for arm64, ordered by a profile of an arm64 run (callgrind in an emulated arm64 container), was no faster at 128, 256 or 1,024 MB, measured in both regions (20 forced cold starts per cell and region):

In a trace of the pages each phase touched, the arm64 default layout already left the first request with 12 blocks to load (x86_64: 17), and ordering did not get it lower: the code only the first request runs needs about that many blocks in any layout. Ordering still shrank the code Init touched by about 40%, but Init runs on boosted CPU, so that saved only ~3 ms.

A list does not carry over between architectures. Mapped onto the arm64 build by name, the x86_64 list packed Init's code but missed much of the first request's: 279 of the functions the arm64 run executed had no counterpart in it, most likely because the compiler inlines differently per architecture. That code ended up in blocks of its own, and the first request had 20 blocks to load instead of 12.

Compare opt-level z and 3

opt-level=z usually produces a smaller binary and a lower cold init, partly because there is less code to load. opt-level=3 usually produces faster warm invocations, by a wide margin for CPU-bound handlers. Neither holds for every binary, so build both and measure. Results per scenario: opt-level: speed vs size.

Putting it together

Applied to the benchmark's smithyfull handler (Smithy server SDK plus KMS, DynamoDB and S3 clients), the levers cut its cold start at 128 MB by about half with calls at init, and by about a quarter to a third without. After tuning, the cold start depends much less on the memory tier. Gains overlap where levers cut the same loading cost: opening connections at init makes the executable read redundant, and once the executable is read, turning off default features or switching to ring adds only ~5 to ~30 ms. SSL_CERT_FILE targets a separate cost and adds up with the others.

(The benchmark's lockfile at the time: aws-config 1.8.18, rustls-native-certs 0.8.5. 20 forced cold starts per cell, both regions at the same time.)

The same combinations measured a day earlier with aws-config 1.12 gave ~373 ms as in the benchmark, ~246 ms with no calls at init and ~147 ms with calls at init, at 128 MB in eu-central-1.

The same levers on the SDK probe's single DynamoDB client (rustls on ring, SSL_CERT_FILE, the connection opened at init) took its cold start at 128 MB from ~221 ms to ~68 ms.

With one full vCPU (1,769 MB) the levers that only move work into Init stop mattering, but SSL_CERT_FILE (an Init cost at every size), rustls on ring and overlapping the connections at init still add up. The results at 3,008 MB were the same within a few ms:

(25 forced cold starts per cell.)

Measured without effect

These did not move the cold start beyond run-to-run noise at 128 MB or 1,024 MB:

• An explicit region (.region(...) on the loader): the region provider chain finds AWS_REGION first and is already cheap.
• Explicit credentials (EnvironmentVariableCredentialsProvider on the loader): load() dropped from ~55 ms to ~13 ms, but building the first client grew by the same amount. Root certificates are loaded when the first HTTPS client is set up, which the default credential chain triggers inside load() and an explicit provider leaves to Client::new.
• A current-thread tokio runtime instead of the multi-threaded default.
• mimalloc as the global allocator.
• S3 request checksums only when required (request_checksum_calculation), for cold or warm PutObject.
• X25519 instead of post-quantum X25519MLKEM768 key exchange, on the first handshake or later ones.
• A newer Smithy server SDK (http-1x codegen with lambda_http 1, instead of the http 0.x codegen the benchmark used until 2026-10-15) for smithyfull.
• A non-PIE executable (-C relocation-model=static on the final crate only, through cargo-lambda's zig toolchain, smithyfull): the dynamic loader's 640 KB of relocations went away and Init dropped by ~3 ms, but the first request at 128 MB got slower, from ~279 ms to ~333 ms, because the new layout made it take 23 major faults instead of 16. At 1,024 MB both took ~174 ms cold.
• Changing the kernel's read-around for the executable (madvise with MADV_RANDOM or MADV_SEQUENTIAL on its mappings, first thing in main(), crypto probe): the faults got smaller or larger, but their CPU cost followed the amount read from disk, ~6 to ~8 µs per KB, and that barely changed.

Java

Prime SnapStart

Enable SnapStart and register a CRaC beforeCheckpoint hook that runs one representative invocation during init, so the AWS SDK's lazy class loading and JIT are captured in the snapshot. Unprimed SnapStart on an SDK-heavy handler can be slower than no SnapStart at all.

Go

Skip the certificate directory scan

Applies to: Go's crypto/x509, which the AWS SDK for Go v2 uses for TLS, on provided.al2023.

On Linux, Go loads the root certificates from the first CA bundle file it finds and then from every file in /etc/ssl/certs and /etc/pki/tls/certs. On provided.al2023 those directories hold each root again as its own file, plus both bundle files, so the same roots are read and parsed several times. Setting the function's environment variable SSL_CERT_DIR to a directory that does not exist makes Go skip the scan and load only the bundle (Go ignores a missing directory):

SSL_CERT_DIR=/nonexistent

Setting only SSL_CERT_FILE, the Rust lever, does not help here, because Go scans the directories either way.

With the variable, the function loaded the same 251 roots, and the first request read ~1.8 MB less from disk and used ~36 ms less CPU on arm64. Go loads the roots on the first HTTPS call, so without a warm-up that saving lands in the handler, where the 128 MB CPU share stretched it to ~775 ms: the cold start went from ~1,053 ms to ~265 ms (x86_64: ~1,407 ms to ~339 ms). It removes the work rather than moving it, so it also helps at 1,024 MB (~160 ms to ~88 ms), and "Max Memory Used" dropped by ~5 MB. The table under warm the SDK's lazy setup has all the numbers.

The saving happens once per process, however many clients there are. On the benchmark's threeclient (DynamoDB, KMS and S3 clients) it was about the same as on oneclient: ~1,382 ms to ~427 ms at 128 MB and ~211 ms to ~140 ms at 1,024 MB in eu-central-1. A repeat run reproduced the oneclient result in both eu-central-1 (~1,148 ms to ~275 ms) and us-east-1 (~1,338 ms to ~343 ms).

The trade-offs are those of loading roots from the CA bundle in Rust: a CA copied only into a certificate directory, rather than added with update-ca-trust, no longer loads, and on a base image without a bundle at a path Go knows, no roots load at all and every TLS call fails with an unknown-authority error. Make a test call to each service the function depends on before rolling it out.

Warm the SDK's lazy setup at init

The AWS SDK for Go v2 loads the OS certificate pool, builds its HTTP transport, and resolves credentials on the first service call, not when the client is created. In a probe taken 2026-07 (arm64, 128 MB) that setup cost ~1.3 s on the first request (same work, different phase); most of it is the certificate directory scan. As with any init placement, this only shortens an on-demand cold start below about 1.8 GB.

Most of that setup is local, so it can be triggered at init without a request:

// In main() or init(), after config.LoadDefaultConfig.
// Load the OS root certificates; crypto/x509 caches them for the process.
if _, err := x509.SystemCertPool(); err != nil {
	log.Fatal(err)
}
// Resolve credentials into the config's cache; on Lambda they come from
// environment variables, so this makes no network call.
if _, err := cfg.Credentials.Retrieve(ctx); err != nil {
	log.Fatal(err)
}

The first TLS handshake to each service still happens on the first request to it. A throwaway call at init (GetItem here) also opens that connection, with the costs described under open each client's connection at init.

(15 forced cold starts per cell.)

The local warm-up moves ~48 ms of CPU (arm64) into Init, which at 128 MB is far cheaper than paying it in the handler; at 1,024 MB it gains less than skipping the scan, because it moves the work instead of removing it. The two combine, and the fastest variant at every size made a real call at init with the scan skipped.