Khone buffers requests by route and batching dimensions for a few milliseconds, invokes target Lambdas with batched payloads, and routes each per-request response back to the original caller. It deliberately trades a few milliseconds per request for lower target invocation cost and fewer cold starts, especially when handlers are waiting on downstream I/O rather than consuming CPU. That's the whole pitch.
The gateway is a Rust Lambda Function URL router running on Lambda Managed Instances. It accepts HTTP requests, batches inside each execution environment, invokes target Lambdas with batched payloads, and demultiplexes per-request responses back to clients. Batches that exceed the invoke payload limit are split before invocation when possible.
Adopt Khone with the smallest change that fits your workload — from a layer drop-in for handlers that cannot change, to a native batch handler when one invocation should share data loading across all items.
A Lambda layer + Runtime API proxy presents one outer batch invocation as multiple virtual runtime invocations. Existing handlers run unmodified.
A small wrapper preserves the familiar single-request handler shape. The adapter handles batch correlation, per-item errors, and response formatting.
The handler receives the whole batch. Use it when one invocation should share data loading, fan-out, or response generation across all items.
The KhoneGateway macro creates the gateway Lambda, Function URL, execution role, and config artifact. Your stack supplies target functions and an existing LMI capacity provider.
Transform:
- AWS::Serverless-2016-10-31
- KhoneGateway
Resources:
GatewayService:
Type: Khone::Gateway::Service
Properties:
CapacityProviderArn: !Ref GatewayCapacityProviderArn
MemorySize: 2048
Timeout: 30
ExecutionEnvironmentMemoryGiBPerVCpu: 2.0
PerExecutionEnvironmentMaxConcurrency: 64
ConfigPrefix: !Sub "khone/${AWS::StackName}/gateway/"
GatewayConfig:
DefaultTimeoutMs: 2000
Spec:
openapi: 3.0.0
paths:
/items/{id}:
get:
x-target-lambda: !GetAtt ItemsFn.Arn
x-khone:
maxBatchSize: 16
maxWaitMs: 35
invokeMode: response_streamconst { batchAdapter } = require("khone-lambda-adapter");
// Single-request handler shape - preserved.
async function handleItem(event) {
const item = await db.get(event.pathParameters.id);
return {
statusCode: 200,
headers: { "content-type": "application/json" },
body: JSON.stringify(item),
};
}
// Adapter handles batch correlation, per-item errors,
// and the NDJSON response framing.
exports.handler = batchAdapter(handleItem);The public benchmark normalizes target invocation cost to the standard endpoint, an API Gateway HTTP API plus Lambda baseline, at 100%. In the high-traffic profile,target-aware batching delivered the lowest estimated target cost. The standard endpoint stays fastest because it avoids the gateway hop. Khone trades some of that latency for lower target invocation cost; as a side effect, traffic spikes can stay on warm sandboxes already processing batches instead of forcing new cold starts. The target Lambdas call a backend Lambda URL that simulates delayed downstream responses.
of standard target invocation cost in the curated round-2 high-traffic public report.
| Profile | Endpoint | P95 | Target cost |
|---|---|---|---|
| Low · 1/10/50 rps | standard | 198 ms | 100.0% |
| Low · 1/10/50 rps | steady | 317 ms | 65.4% |
| Low · 1/10/50 rps | adaptive | 283 ms | 85.1% |
| Low · 1/10/50 rps | target-aware | 463 ms | 45.1% |
| High · 50/100/150 rps | standard | 197 ms | 100.0% |
| High · 50/100/150 rps | steady | 308 ms | 32.4% |
| High · 50/100/150 rps | adaptive | 304 ms | 36.2% |
| High · 50/100/150 rps | target-aware | 464 ms | 17.7% |
Start with workload fit and quickstart, deploy the LMI gateway, connect handlers, and keep the exact contracts close when you need them.
Connect target handlers to the gateway.
Read and reproduce the public benchmark snapshot.
Look up fields, protocols, APIs, and commands.