## TL;DR
"Signal killed" on Lambda means the function exceeded its memory allocation. Raise the memory setting (guided by the CloudWatch `max memory used` metric) and trim the footprint. The runtime stops killing the process once it fits.

## Error
```text
lambda: Runtime exited with error: signal killed (memory)
```

## Steps
1. Confirm OOM: check the CloudWatch REPORT line for `Max Memory Used` versus the configured memory. Expected: usage at or over the limit.
2. Raise memory in the function configuration, in steps (for example double it). Expected: the next run reports headroom.
3. Note the CPU bonus: Lambda scales CPU with memory, so raising memory also speeds CPU-bound code. Expected: duration may drop too.
4. Trim the footprint: stream large payloads instead of loading them, process in chunks, and release references to big objects. Expected: max memory used falls.
5. Consider right-sizing tools or provisioned concurrency if the workload is spiky. Expected: stable runs without over-provisioning everything.

## When to use
- Lambda exits with signal killed and memory in the message
- Functions processing large files or datasets
- After adding memory-hungry dependencies

## When not to use
- Timeout errors (time, not memory)
- Cold-start latency complaints (different tuning)

## Tool compatibility
- AWS Lambda memory configuration; CloudWatch Logs REPORT memory metrics

## Variant phrasings
### lambda killed signal 9 memory
Raise the memory allocation; the REPORT line tells you how much headroom you need.

### lambda out of memory processing s3 file
Stream the object instead of downloading it whole; chunked processing fits small allocations.

## Why it happens
Lambda enforces the memory limit with the OOM killer: exceeding it kills the process immediately with no graceful degradation. Memory also gates CPU allocation, so under-provisioned functions are both killed and slow.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_F_YaJ4nC7a4QX8Ji7jpGLQ