AWS Lambda FFmpeg Video Processing: Layer, Container, and Limit Guide (2026)

The idea is seductive. Your app needs video processing. You already use Lambda for everything else. Drop a static ffmpeg binary into a layer, wire it to an S3 trigger, and call it done. Then the first real video hits. The function crashes. /tmp fills up. The 15-minute timeout kills your job. You bump memory to get CPU and your bill spikes.

This guide covers every Lambda limit that affects ffmpeg: layer quotas, container image constraints, /tmp storage, the timeout ceiling, CPU allocation, and cold starts. It shows the workarounds and where each one breaks. When they stop working, a hosted ffmpeg API like Very Good FFmpeg eliminates every limit with a single HTTP call.

Key Takeaways

• Lambda layer limit (250 MB unzipped) is the first wall. A full static ffmpeg build fits, but barely. Any other dependency pushes you over.
• Container image approach (10 GB limit) bypasses the layer constraint but does not help with /tmp or timeout limits.
• /tmp storage scales to 10,240 MB (matching memory) but is ephemeral. Every cold start means a fresh download of your source video.
• 15-minute hard timeout is the real ceiling for video work. Anything beyond short transcodes or thumbnail extraction risks partial output.
• CPU allocation is tied to memory. Below 1,769 MB you get less than 1 vCPU. ffmpeg is CPU-bound. You pay for memory you do not need just to get usable CPU.
• Workarounds exist (pipe to stdout, EFS mount, Step Functions chaining, stream copy) but each one adds complexity, cost, or fragility.
• For production video beyond thumbnails and short clips, a hosted ffmpeg API like Very Good FFmpeg eliminates all of these limits with a single HTTP call.

Background

How does ffmpeg run in AWS Lambda anyway?

Lambda runs your code in ephemeral, stateless containers. Each invocation gets a fresh execution environment with a read-only filesystem and a writable /tmp directory. The ffmpeg binary must be bundled into the deployment package and found at runtime.

There are two ways to include ffmpeg in a Lambda function.

Lambda layers. Download a static ffmpeg build from johnvansickle.com/ffmpeg/, place the binary at ffmpeg/bin/, zip it, and upload as a Lambda layer. The binary ends up at /opt/bin/ffmpeg. Your function calls it by path or adds /opt/bin to PATH. Layers are the simplest approach but hit the tightest size limit.

Container images. Build a Docker image with ffmpeg installed, push it to Amazon ECR, and deploy the image as the Lambda function. Multi-stage builds keep the final image lean. The image can be up to 10 GB uncompressed, which bypasses the 250 MB layer limit entirely.

The newer Amazon Linux 2023 (AL2023) runtime provides a smaller base image (under 40 MB vs over 100 MB for AL2) and an updated glibc (2.34 vs 2.26). This matters because some ffmpeg static builds require newer glibc. AL2023 is the basis for all current Lambda managed runtimes.

What are the actual AWS Lambda limits for 2026?

Every Lambda function operates within a set of hard quotas documented in the official Lambda limits page. Here is the full table of limits that matter for ffmpeg video processing:

The most painful limits for video work are layer size, /tmp storage, timeout, and CPU allocation. Each one requires specific workarounds.

Why is the 250 MB layer limit the first wall?

Because Lambda layers are limited to 250 MB unzipped across all layers, and a full static ffmpeg build takes up most of that space. A static ffmpeg binary with full codec support is roughly 50-70 MB compressed and larger uncompressed. It fits, but barely.

The problem is what you have to leave out. If your pipeline needs Python or Node.js runtime libraries, image processing tools like ImageMagick, audio codec libraries, or multiple ffmpeg variants (one for encoding, one for analysis), you will hit the 250 MB ceiling fast.

John Van Sickle's static ffmpeg builds at johnvansickle.com/ffmpeg/ are the standard source for Lambda layers. They provide builds for amd64 and arm64 (enabling Graviton Lambda for better price-performance). The binary bundles all libraries statically, so no installation is needed. Just extract, zip, and upload as a layer.

What happens when you exceed the layer limit?

Deployment fails with an error like Unzipped size must be smaller than 262144000 bytes. Lambda enforces this limit at deploy time and at runtime. There is no way around it.

You have three options:

1. Strip the binary. Remove debug symbols, unused codecs, and documentation from the ffmpeg build. Tools like strip can shave 20-30 MB off the binary.
2. Use a minimal ffmpeg build. Compile ffmpeg yourself with only the codecs and muxers you need. This is tedious but effective.
3. Switch to container images. This bypasses the 250 MB layer limit entirely with a 10 GB image allowance.

How does the container image approach bypass this?

Container images lift the deployment size limit from 250 MB to 10 GB. This is the recommended approach for any serious ffmpeg-in-Lambda setup.

The basic flow:

1. Write a Dockerfile that installs ffmpeg on an AWS base image (Amazon Linux 2023 or AWS-provided Node.js/Python images).
2. Use multi-stage builds to keep the final image small. Build ffmpeg from source or copy a static binary in a single stage.
3. Push the image to Amazon ECR.
4. Deploy the Lambda function from the ECR image URI.

FROM public.ecr.aws/lambda/python:3.12 as base
FROM alpine:3.19 as ffmpeg-builder
RUN apk add ffmpeg
FROM base
COPY --from=ffmpeg-builder /usr/bin/ffmpeg /usr/bin/ffmpeg
COPY app.py ${LAMBDA_TASK_ROOT}
CMD ["app.handler"]

A well-optimized container image with ffmpeg, Python runtime, and your code typically comes in under 500 MB. The trade-offs: ECR adds a deployment step, and cold starts are slightly slower because the image must be pulled and extracted. You still face /tmp and timeout limits.

Why won't your 4 GB video process in /tmp?

Because Lambda's default /tmp storage is only 512 MB, which is smaller than most video files. Even a 200 MB source video becomes a problem when ffmpeg generates intermediate files or uses /tmp for temporary working space.

The /tmp size matches your memory allocation. Set memory to 3,008 MB and /tmp becomes 3,008 MB. This is the primary workaround. But /tmp is ephemeral. It exists only for the lifetime of that invocation. On the next cold start, it is empty. Your function must download the source video from S3 to /tmp, process it, and upload the output back to S3 every time. That is download time plus processing time plus upload time, all counting against the 15-minute clock.

Can you use EFS to get around /tmp limits?

Yes. Lambda can mount an EFS filesystem, giving you persistent, scalable storage that is not tied to memory allocation.

The setup puts the Lambda function in a VPC, creates an EFS filesystem in the same VPC, and adds the EFS access point as a mount target. ffmpeg can then read and write to EFS as if it were local storage. Files persist between invocations.

The AWS Compute Blog has a complete walkthrough: processing a 60-minute MP4 video and extracting screenshots per second using ffmpeg on Lambda with EFS, writing 2,000+ JPG files back to EFS during a single invocation.

The downsides: VPC-enabled Lambda adds cold start latency (3-10 seconds). EFS costs money when idle ($0.08/GB-month plus throughput). You must manage EFS lifecycle, backup, and cleanup. The VPC dependency means your function cannot access the public internet without a NAT gateway. For most teams, mounting EFS just to process video in Lambda feels like fighting the architecture.

What about piping through memory instead?

The AWS media blog recommends avoiding /tmp entirely for outputs. Pass a presigned S3 URL as input and pipe ffmpeg output to stdout directly to S3 via put_object. Memory overhead is roughly 2x source file size plus 120-140 MB for ffmpeg. With 10,240 MB of memory, you can handle sources up to about 4 GB.

The limitation: not all ffmpeg operations support piping to stdout. HLS packaging, multi-file outputs, and complex filter graphs often require a real filesystem. The 15-minute timeout still applies.

Why is the 15-minute timeout the hard ceiling?

Because Lambda enforces a maximum execution time of 900 seconds (15 minutes) that cannot be increased. Any ffmpeg job that takes longer is killed regardless of how close it is to finishing. There is no slider past 15 minutes. It is a hard platform ceiling.

Short thumbnails finish in seconds. Transcoding a 30-minute 4K video with filters will not. Complex operations like HLS packaging, watermarking, and GPU filters eat time fast. Even with -codec: copy, large files take minutes just to read and write.

What happens when Lambda times out mid-job?

The ffmpeg process is killed immediately with no grace period. No SIGTERM for cleanup. The function exits with a Task timed out after 900.00 seconds error.

Typical failure modes:

• Truncated output. The video file ends mid-stream. ffmpeg did not write a proper moov atom (for MP4) or finalize the container. The output is unplayable or plays only the first few seconds.
• Corrupt intermediate files. If ffmpeg was writing to a temp file and got killed, the temp file stays in /tmp. The next invocation might pick it up and produce garbage output.
• Partial S3 upload. If your code writes output to S3 incrementally, the upload is also killed. You get a partial object in S3.

Lambda does not retry timed-out invocations automatically for asynchronous invocations. For synchronous invocations, you get one error and the client must retry. You need to build your own retry logic with exponential backoff.

Can you chain Lambda functions for longer jobs?

Yes, using AWS Step Functions to orchestrate multiple Lambda invocations. Split the source video into segments using ffmpeg's segment muxer, process each segment in a parallel Lambda invocation (each one under 15 minutes), and recombine the processed segments with a final ffmpeg concat step.

This works on paper. In practice, it adds significant complexity. You need a state machine for the split-process-rejoin flow. Each parallel branch must write output to a known location. If any branch fails, you handle partial results, retries, and compensation logic. The cost multiplies: multiple Lambda invocations plus Step Function state transition costs.

For a handful of daily jobs this is manageable. For a production pipeline at scale, you end up building a distributed job scheduler on top of Lambda. At that point, Lambda may not be the right compute model.

Why is CPU and memory a hidden cost problem?

Because ffmpeg is CPU-bound for almost every operation, but Lambda only gives you a full vCPU at 1,769 MB or more of memory. At 512 MB, you get about 0.3 vCPU. Above 1,769 MB, Lambda does not give more CPU, only more memory and /tmp.

This creates a perverse incentive. To get usable CPU for ffmpeg, you must allocate at least 1,769 MB of memory. If your video only needs 500 MB of RAM, you pay for over 1 GB of unused memory just to access reasonable CPU.

A thumbnail that takes 2 seconds locally can take 20+ seconds on low-memory Lambda. Bump memory to 3 GB and the job finishes in 3 seconds, but each invocation now costs 6x more. For thousands of videos a day, this adds up fast.

Memory above 1,769 MB does not give more CPU. You are paying for /tmp space only. If your job needs 10 GB of /tmp but only 500 MB of RAM, you pay for 10 GB of memory allocation.

Why does my ffmpeg crash with SIGSEGV in Lambda?

"SIGSEGV" (segmentation fault) is a commonly reported ffmpeg crash in Lambda. The root causes are almost always resource exhaustion.

Memory exhaustion. ffmpeg needs more memory than allocated. Common when processing high-resolution video with complex filter graphs. The solution is to increase memory allocation, which costs more.

Thread limit. Lambda allows 1,024 threads per execution environment. Some multi-threaded encoders spawn hundreds of threads, and combined with the Lambda runtime and your code, you can hit the ceiling.

Missing codecs. Static ffmpeg builds include most common codecs, but niche formats may require custom compilation. If ffmpeg was compiled without the codec your input uses, it can crash silently.

/tmp exhaustion. If /tmp fills up during processing, subsequent writes fail. ffmpeg may not handle ENOSPC (no space left) gracefully.

The hardest part of debugging these crashes is that the Lambda environment differs from your local machine. The same ffmpeg command that works on macOS may crash on Amazon Linux due to library differences or process limits.

Why are cold starts a silent multiplier?

Because every cold start must load the ffmpeg binary, initialize the runtime, and (if applicable) mount EFS, adding seconds of latency before processing begins. For user-facing APIs, this delay makes Lambda unsuitable for synchronous video processing.

A container image Lambda with ffmpeg may take 2-5 seconds for cold start. Add EFS and VPC, and you get 10-15 seconds before any ffmpeg work begins. You would need provisioned concurrency, which costs more.

For batch pipelines triggered by S3 events overnight, cold starts are tolerable. The key decision is whether your pipeline is synchronous (user waiting) or asynchronous (fire and forget).

When does ffmpeg in Lambda actually make sense?

ffmpeg in Lambda works well for short, compute-light operations that finish in seconds, use minimal /tmp, and fit within the 15-minute timeout.

Specific use cases that work:

• Thumbnail generation. Extract a single frame. Fast, minimal /tmp, finishes well under 15 minutes.
• Metadata and probe operations. Run ffprobe for codec info, resolution, duration. No transcoding means no CPU or /tmp pressure.
• Format detection and validation. Check that an uploaded file is a valid video before passing it downstream.
• Audio extraction from short clips. Grab the audio track from a 2-minute video. Predictable resource usage.
• Short transcodes with stream copy. Repackage a 1-minute video using -codec: copy. Container rewrap, minimal CPU.
• Batch pipelines with forgiving latency. Overnight jobs processing small files where 15 minutes per job is not a constraint.
• Low-volume, non-user-facing processing. Internal tools, admin uploads, or staging environments.

If your use case fits one of these buckets, Lambda ffmpeg is a reasonable choice once you handle layer setup, /tmp config, and memory allocation.

When should you give up and use a hosted ffmpeg API?

Switch to a hosted API when your videos exceed a few minutes, you need GPU acceleration, or you are building a user-facing service. When you hit multiple limits at once, the complexity of running ffmpeg in Lambda exceeds the value.

Switch to a hosted ffmpeg API when:

1. Videos exceed a few minutes. Any transcode taking more than 5 minutes risks timing out.
2. You need GPU acceleration. Lambda does not support GPU. H.265 encoding, AI upscaling, and complex filters benefit massively from GPU.
3. You are building a user-facing API. Cold starts and variable CPU make Lambda unsuitable for synchronous video APIs.
4. Processing time exceeds 15 minutes. There is no workaround for this limit.
5. You need predictable cost. Lambda pricing for high-memory ffmpeg jobs is hard to predict. Hidden costs from EFS, VPC, NAT gateway, and Step Functions compound.
6. You do not want to maintain video infrastructure. Lambda ffmpeg means owning layers, containers, EFS lifecycle, error handling, retries, and monitoring. That competes with product work.
7. Your team is small or video is a secondary feature. A 3-person team should not spend weeks building a Lambda video pipeline when a hosted API solves it in 30 minutes.

What does Very Good FFmpeg offer instead?

Very Good FFmpeg is a hosted ffmpeg API that eliminates every Lambda limit discussed here. You send ffmpeg commands as an HTTP request and get results back without provisioning any infrastructure.

The API is straightforward:

curl -X POST https://verygoodffmpeg.com/api/ffmpeg \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "input_files": {
      "input.mp4": "https://your-bucket.s3.amazonaws.com/input.mp4"
    },
    "output_files": ["output.mp4"],
    "ffmpeg_commands": [
      "-i {{input.mp4}} -c:v libx264 -crf 23 {{output.mp4}}"
    ]
  }'

The same ffmpeg flags, filter graphs, and codec options work through the API. No new DSL to learn. If it works in ffmpeg on the terminal, it works in the API.

How does cost compare between Lambda and Very Good FFmpeg?

Comparing Lambda costs for ffmpeg to a hosted API requires looking beyond the per-invocation price. Lambda includes execution costs plus hidden costs for EFS, VPC NAT gateway, and Step Functions. Very Good FFmpeg pricing is per-GB of data processed with no minimum.

For small volumes and simple jobs, Lambda can be cheaper per-job. For any serious video workload, the hosted API is cost-competitive and significantly less complex.

Verdict

Running ffmpeg in AWS Lambda is possible. Many teams do it for thumbnail generation, metadata extraction, and short clip transcoding. The limits can be worked around with container images, adequate memory, and careful tuning.

But every workaround has a shelf life. EFS mounting adds VPC complexity and cost. Pipe-to-memory strategies fail for complex filter graphs. Step Functions chaining turns a simple ffmpeg command into a distributed system. The 15-minute timeout is a wall no workaround can tear down.

For production-grade video processing, especially user-facing or high-volume pipelines, a hosted ffmpeg API like Very Good FFmpeg eliminates every limit with a single HTTP request. The job gets 16 dedicated CPU cores, GPU support, a 6-hour timeout, 32 GB of RAM, and no /tmp worries.

Build product features, not video infrastructure.

FAQ

Can I run ffmpeg in AWS Lambda?

Yes, via a static binary in a Lambda layer or inside a container image. But the 15-minute timeout, /tmp storage, and CPU limits often make it impractical for real video work.

What is the Lambda layer size limit for ffmpeg?

250 MB unzipped total across all layers. A full ffmpeg static binary is roughly 50-70 MB compressed and larger unzipped. Container images bypass this with a 10 GB limit.

How much /tmp storage does Lambda give you?

Default is 512 MB. You can scale up to 10,240 MB by increasing the function memory allocation. /tmp is ephemeral and wiped between cold starts.

What happens when Lambda times out during video processing?

The ffmpeg process is killed immediately, often producing a partial or corrupt output file. Lambda does not retry automatically. You must build your own retry and resume logic.

Is Very Good FFmpeg cheaper than running ffmpeg in Lambda?

For small volumes at low memory, Lambda can be cheaper per-job. For any real video processing volume, Very Good FFmpeg is often cheaper once you account for engineering time, infrastructure costs (EFS, VPC, NAT gateway, Step Functions), and Lambda execution at the high memory settings ffmpeg requires.

Can I use GPU acceleration in Lambda for ffmpeg?

No. AWS Lambda does not support GPU. Very Good FFmpeg offers Nvidia GPU acceleration on demand. For GPU-accelerated ffmpeg, you need ECS, EKS, SageMaker, or a hosted API.

What memory setting should I use for ffmpeg in Lambda?

At least 1,769 MB to get approximately 1 full vCPU. For /tmp space, set memory equal to the storage you need. Memory above 1,769 MB does not increase CPU.

Why does my ffmpeg crash with SIGSEGV in Lambda?

Common causes include memory exhaustion, the 1,024 thread limit per execution environment, missing codecs in the static ffmpeg build, or /tmp filling up mid-operation.

Is ffmpeg in Lambda good for thumbnails?

Yes. Thumbnail extraction is fast, uses minimal /tmp, and finishes well under 15 minutes. This is the most common successful use case for ffmpeg in Lambda.

Can I process videos longer than 15 minutes in Lambda?

Not in a single invocation. You must split the video, process segments in parallel via Step Functions, and recombine the results. Or use a hosted ffmpeg API with 6-hour timeouts.

References

• AWS Lambda quotas -- https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html
• AWS Lambda container image support -- https://docs.aws.amazon.com/lambda/latest/dg/images-create.html
• Processing UGC using Lambda and FFmpeg (AWS blog) -- https://aws.amazon.com/blogs/media/processing-user-generated-content-using-aws-lambda-and-ffmpeg/
• Amazon Linux 2023 runtime for Lambda (AWS blog) -- https://aws.amazon.com/blogs/compute/introducing-the-amazon-linux-2023-runtime-for-aws-lambda/
• Using EFS for AWS Lambda (AWS blog) -- https://aws.amazon.com/blogs/compute/using-amazon-efs-for-aws-lambda-in-your-serverless-applications/
• John Van Sickle static FFmpeg builds -- https://johnvansickle.com/ffmpeg/
• Stack Overflow -- ffmpeg in Lambda tag -- https://stackoverflow.com/questions/tagged/aws-lambda+ffmpeg
• Stack Overflow -- /tmp disk limit -- https://stackoverflow.com/questions/71927796/aws-lambda-tmp-disk-limit-with-ffmpeg
• Stack Overflow -- ffmpeg takes too long -- https://stackoverflow.com/questions/74859024/ffmpeg-lambda-takes-too-long
• Stack Overflow -- SIGSEGV crash -- https://stackoverflow.com/questions/75649832/ffmpeg-hls-conversion-error-on-aws-lambda-ffmpeg-was-killed-with-signal-sigseg
• Stack Overflow -- large files in Lambda -- https://stackoverflow.com/questions/68213300/aws-lambda-how-to-give-ffmpeg-large-files
• Stack Overflow -- only 5 seconds output -- https://stackoverflow.com/questions/67848232/ffmpeg-in-an-aws-lambda-will-only-output-5-seconds-of-converted-video
• Stack Overflow -- memory optimization -- https://stackoverflow.com/questions/67430366/how-can-i-control-and-reduce-memory-used-by-ffmpeg-in-aws-lambda
• Reddit r/aws -- ffmpeg in Lambda -- https://www.reddit.com/r/aws/comments/18muxcx/ffmpeg_in_lambda_is_it_really_that_bad/
• Very Good FFmpeg -- hosted FFmpeg API -- https://www.verygoodffmpeg.com/
• Very Good FFmpeg -- self-hosted vs hosted -- https://verygoodffmpeg.com/content/compare/self-hosted-ffmpeg
• Very Good FFmpeg -- vs AWS MediaConvert -- https://verygoodffmpeg.com/content/compare/aws-mediaconvert