## TL;DR

Lambda@Edge caps generated responses at 1 MB. Functions that build large pages, bundle assets, or proxy big origin bodies hit the wall. Shrink the response (paginate, compress, stream via origin), or move the heavy lifting to the origin and keep the edge function to headers and routing.

## The query

```text
lambda@edge error: generated response size exceeds 1 MB
```

## Use this when

- The edge function fails on large responses.
- It works for small pages and fails for big ones.
- The function proxies or generates the body itself.

## Not for

- Deployment package size limits (different limit).
- Function timeouts (duration problem).
- CloudFront distribution config errors (config problem).

## Steps

### Step 1: Measure the response size

Log the byte length of the body the function returns.

Expected result: the failing responses measure over 1 MB. Size, not content, is the blocker.

### Step 2: Stop generating big bodies at the edge

Return a redirect or a small placeholder from the edge function and let the origin or S3 serve the large content directly.

Expected result: the edge response stays tiny. The heavy bytes never pass through the function's response path.

### Step 3: Compress and paginate where the edge must respond

If the edge function must build the body, enable compression and paginate large datasets so no single response exceeds the cap.

Expected result: responses fit. Clients reassemble pages as needed.

### Step 4: Use origin-response triggers for transformation, not generation

Transform the origin's response (headers, small rewrites) instead of replacing the body wholesale.

Expected result: the large body flows from the origin; the function only touches what it must.

### Step 5: Verify with the largest real payload

Expected result: the biggest production response passes. Add a size assertion so growth re-triggers an alert, not an outage.

## Why it happens

Lambda@Edge runs at CloudFront edge locations with strict response budgets for latency. The 1 MB cap keeps edge responses fast. Functions written like origin servers (render everything, return everything) work until the first large payload.

## Edge cases

- The limit applies to the generated response, not to origin passthrough. Proxying without buffering avoids it.
- Viewer-request triggers cannot generate large bodies at all; use origin-facing triggers for body work.
- Compression counts: the cap applies to the final encoded response. Compress before measuring.
- CloudFront Functions (the lighter alternative) have even smaller limits; do not 'fix' this by switching runtimes without checking.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_HNzUJac_ykQ5b-IEObyGWQ