What this prompt does
This prompt has the AI run a structured performance-tuning pass on [runtime] Lambda functions suffering [performance_issue]. The functions do [function_purpose] and are invoked [invocation_pattern]. It uses Lambda Power Tuning to find the optimal memory beyond [current_memory], implements [cold_start_strategy] with before/after metrics, sets up connection pooling for [external_connections] outside the handler, shrinks the package from [current_size] using Layers for [shared_dependencies], configures [reserved_concurrency] and provisioned concurrency for [critical_functions], converts blocking calls to [async_pattern], caches [cacheable_data], and builds a CloudWatch dashboard.
The structure works because it sequences the highest-leverage fixes first: Power Tuning and connection reuse outside the handler are usually where the real wins are. Initializing connections outside the handler means they persist across warm invocations rather than reconnecting every call. The ordered checklist keeps you from skipping the boring-but-important steps. Grounding the pass in your real [performance_issue] and [invocation_pattern] also tells the model whether cold starts or steady-state latency are the actual problem, since the fix differs sharply between a bursty function and a constantly-warm one.
When to use it
- Your Lambda latency or bill has crept up and you want a systematic tuning pass, not guesswork.
- Cold starts are hurting you and you need a concrete
[cold_start_strategy]with measured improvement. - Your functions reconnect to
[external_connections]on every invocation and you want pooling outside the handler. - Your deployment package is large and you want to move
[shared_dependencies]into Layers. - You need to protect downstream systems with
[reserved_concurrency]and warm[critical_functions]. - You have
[cacheable_data]that could persist across warm invocations instead of being re-fetched.
Example output
Expect a tuning report: instructions for running Lambda Power Tuning and interpreting the memory/cost curve, the [cold_start_strategy] implementation with before/after numbers, code showing connection pooling initialized outside the handler for [external_connections], a package-size reduction plan using Layers for [shared_dependencies], concurrency settings, an [async_pattern] conversion for non-blocking work, an in-memory caching approach for [cacheable_data], and a CloudWatch dashboard spec.
Pro tips
- Start with Lambda Power Tuning; more memory often means faster and cheaper because billed duration drops, so
[current_memory]is rarely the optimum. - Move every
[external_connections]client initialization outside the handler so warm invocations reuse the connection instead of reconnecting each time. - Only apply provisioned concurrency to
[critical_functions]like checkout and auth; it costs money whether invoked or not, so target it narrowly. - Use
[reserved_concurrency]to protect a fragile downstream like RDS from being overwhelmed by a Lambda scale-out, not just to cap cost. - Cache
[cacheable_data](config, feature flags, lookup tables) in module scope so it survives across warm invocations — but watch staleness on data that can change. - Convert genuinely non-blocking work to
[async_pattern]via SQS; do not make a call async if the caller actually needs the result synchronously. - Build the CloudWatch dashboard tracking duration, memory usage, cold-start ratio, and error rate first, so every later change has a baseline to measure against rather than a guess.
