Remotion Lambda: o que é e quando vale renderizar vídeo em lote na AWS?

Renderizar vídeo é caro em CPU, e isso não muda por decreto

Uma composição que sai rapidinho no seu notebook vira um gargalo feio quando o pedido muda pra "gera mil versões personalizadas, cada uma com nome, dado e trilha diferente"

É aí que entra o Remotion Lambda: a peça de batch rendering do Remotion, que espalha o trabalho por várias funções na AWS em vez de deixar uma máquina só suando sozinha

Mas se liga: nem todo projeto precisa disso

Se o seu volume é baixo, renderizar local resolve e te poupa de brigar com quota, IAM e bucket

Bora entender como a coisa funciona por dentro, e onde cada caminho se paga 🙂

Como o Remotion Lambda renderiza um vídeo em paralelo

A ideia central é simples: em vez de uma máquina renderizar o vídeo inteiro do frame 1 até o fim, o vídeo é cortado em pedaços e cada pedaço vai pra uma função diferente

Segundo a documentação do Remotion, o fluxo é esse:

• um orquestrador divide o vídeo em chunks
• várias funções Lambda renderizam esses chunks EM PARALELO
• cada função sobe o trecho parcial dela pro S3
• no fim, uma função junta tudo com FFmpeg e devolve o vídeo completo

É como cortar um filme em partes, dar uma parte pra cada pessoa da equipe e depois colar tudo de volta na ordem certa

Quanta gente entra nesse mutirão? Cada render usa entre 3 e 200 funções concorrentes

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

Por que o teto é 200 funções?

O Remotion limita esse número a 200 porque acima disso o ganho é decrescente

Ou seja, você paga mais invocação e coordenação pra ganhar cada vez menos tempo

Vale guardar esse número, porque ele muda a conta do lote inteiro: 200 é o teto POR RENDER, e a sua conta AWS ainda tem os limites dela, que a gente vê logo mais

Como configurar e disparar o primeiro render no Remotion Lambda

Antes de pensar em lote gigante, o caminho é sempre fazer UM render sair do início ao fim

São quatro passos, e cada um tem sua pegadinha clássica

1. Configure as credenciais AWS no .env da raiz do projeto

REMOTION_AWS_ACCESS_KEY_ID=<Access key ID>
REMOTION_AWS_SECRET_ACCESS_KEY=<Secret access key>

O CLI do Remotion lê essas variáveis automaticamente

O erro comum deste passo: usar as variantes sem o prefixo REMOTION_

Elas podem ser reservadas em ambientes como a Vercel e causar conflito entre o Remotion e o AWS CLI, então fica com as prefixadas mesmo

2. Faça o deploy da função de render na sua conta AWS

npx remotion lambda functions deploy

Esse comando cria a função que vai renderizar os chunks

O erro comum deste passo: achar que precisa de uma função por vídeo ou por projeto

Não precisa! Na prática, basta uma função por região da AWS e por versão do Remotion

O reuso olha a configuração inteira: se já existir uma função na mesma região, mesma versão, mesma memória, mesmo disco e mesmo timeout, o comando simplesmente devolve o nome da função que já está lá

Mudou memória, disco ou timeout? Aí sim entra uma função nova na jogada

3. Publique o seu projeto como site num bucket S3

npx remotion lambda sites create src/index.ts --site-name=my-video

Que site é esse? É o bundle do seu projeto Remotion hospedado no S3, que as funções vão abrir na hora de renderizar

O erro comum deste passo: reaproveitar o mesmo --site-name sem querer

Passar o mesmo nome SOBRESCREVE o deploy anterior, então cuidado se outro render em produção depende dele

4. Dispare o render usando a serve URL

npx remotion lambda render <serve-url> <composition-id>

A serve URL é a que o deploy do site te devolveu, e o composition id é o da composição que você quer renderizar

Deu certo aqui? Então o caminho mínimo já está de pé: credencial, função implantada, site no S3 e render saindo

Limites que travam o render em lote (e como resolver)

Agora a parte que costuma pegar todo mundo de surpresa quando o volume sobe

Sintoma: o render engasga por limite de concorrência

A causa quase sempre é quota da AWS, não bug do Remotion

O teto geral da AWS é de 1000 execuções Lambda concorrentes por região e por conta, com burst limit (o aumento máximo de concorrência em 10 segundos) de 1000, sendo apenas 500 em algumas regiões

Só que conta nova não nasce nesse teto: contas novas na AWS Lambda podem receber um limite de concorrência bem baixinho, tipo 10 execuções concorrentes

Ou seja, um valor é o teto geral da plataforma, o outro é o freio inicial que a sua conta carrega até você pedir aumento

E com 10, o seu render que pediria 200 funções simplesmente não tem onde rodar

A solução é pedir aumento de quota:

npx remotion lambda quotas increase

Ou fazer o pedido direto pelo console de Service Quotas, em https://console.aws.amazon.com/servicequotas/home

Sintoma: o render estoura o timeout

O timeout padrão da função implantada é de 120 segundos

A tentação óbvia é subir esse número até caber o vídeo, e é justamente aí que muita gente se ferra

A documentação recomenda o contrário: se o vídeo demora mais, aumente a CONCORRÊNCIA em vez do timeout

Faz sentido, né? Mais funções significa menos frames por função, e cada uma termina dentro da janela

O teto absoluto fica abaixo de 900 segundos, mas a recomendação é ficar em 120 segundos ou menos

Sintoma: o arquivo final não cabe

O disco disponível na função tem que ficar entre 512 MB e 10240 MB (10 GB)

E aqui tem um detalhe que não é óbvio: esse disco precisa acomodar os pedaços separados E o arquivo final concatenado, tudo junto

Por isso a saída fica limitada a cerca de 5 GB, o que dá aproximadamente 160 minutos de vídeo em Full HD

Se o seu caso é um único vídeo muito longo, esse teto é um sinal amarelo forte

Prevenção: dimensione antes de soltar o lote

A memória padrão da função é de 2048 MB

Antes de disparar mil renders, vale ajustar memória, disco e concorrência num render de teste e só depois escalar

E quando algo der errado, o lugar de olhar é o CloudWatch: por padrão o deploy cria um Log Group com informação de debug, com retenção padrão de 14 dias

Tome cuidado com esse prazo! Log de um lote que rodou mês passado pode simplesmente não estar mais lá

Como enfileirar milhares de renders com código e SQS

CLI é ótimo pra aprender, mas lote de verdade se dispara por código

1. Tenha a função já implantada

O disparo programático exige uma função Lambda já no ar, então o passo do functions deploy continua valendo

2. Chame o render pelo código

import { renderMediaOnLambda, getRenderProgress } from '@remotion/lambda/client'

const { renderId, bucketName } = await renderMediaOnLambda({ /* ... */ })

O import vem de @remotion/lambda/client, e a chamada devolve renderId e bucketName

Os parâmetros completos ficam na documentação da própria função, então confere lá antes de colar no seu código

3. Acompanhe o progresso

Duas formas: getRenderProgress() pra consultar o estado, ou um webhook

O webhook recebe um POST do Remotion quando o render termina, quando dá erro e quando estoura o timeout

Pra pipeline em lote, webhook costuma ser mais confortável do que ficar consultando de tempo em tempo

4. Ajuste a concorrência do render

Dá pra informar a quantidade de funções Lambda do render como alternativa ao framesPerLambda, e o Remotion calcula o framesPerLambda correspondente

É o mesmo parâmetro que resolve aquele problema de timeout lá de cima

5. Enfileire com Amazon SQS

Como o AWS Lambda tem limite de concorrência, a documentação indica usar o SQS pra enfileirar renders em background e avisar o usuário quando o processo terminar

O erro comum deste passo: achar que a fila serializa os renders

Não serializa! A fila avança assim que o render é DISPARADO, não quando ele termina, então os renders não executam todos em série

Se a sua orquestração já vive fora da AWS, o raciocínio é o mesmo de integrar o n8n com o AWS Lambda: quem chama é o fluxo, quem sofre é a função

Lambda, Vercel Sandbox, Cloud Run ou servidor próprio: qual escolher?

O Remotion tem mais de uma opção de renderização server-side, e a diferença principal é uma só: quem distribui o trabalho entre máquinas

A documentação recomenda o Lambda para a maioria das pessoas pelo melhor equilíbrio entre velocidade, facilidade de setup, maturidade, custo total e escalabilidade

E afirma que os clientes com maior volume de vídeos renderizados usam o Lambda

O ponto do Cloud Run merece atenção especial: Alpha e sem desenvolvimento ativo não é lugar confortável pra apoiar produto

Quanto custa: AWS por render mais licença do Remotion

Aqui tem uma pegadinha de orçamento: são DUAS camadas de custo, e gente experiente esquece a segunda

Sobre a camada AWS, um aviso importante: os preços variam conforme a região, o peso do bundle e flutuações de latência

A própria documentação recomenda medir o custo da SUA composição, e não extrapolar do exemplo

Pra isso existe a função estimatePrice(), que leva em conta a arquitetura de CPU, o tamanho do disco e o número de Lambdas invocadas

Sobre a camada de licença, o corte prático é esse: o Remotion é gratuito para indivíduos e empresas de até três pessoas, e a Company License só é obrigatória pra quem não se enquadra nessa licença gratuita

O Creators é pensado pra organizações que criam vídeos em baixo volume pra si mesmas, sem montar automação

O Automators é pra quem constrói automação de verdade: editor de vídeo, ferramenta prompt-to-video, pipeline automatizado ou embed do Remotion Player

E detalhe que economiza dinheiro: desenvolvedores que trabalham em projetos de automação não precisam de Seat

Um Seat cobre uma pessoa que escreve código Remotion ou usa ferramentas de coding agêntico, é transferível dentro da empresa, e só quem está usando ativamente precisa de Seat ativo

Quando o Lambda faz sentido e quando renderizar local já resolve

O critério de decisão cabe numa frase: compute cobrado só no render contra compute barato com ocioso pago

Cenários em que o batch na AWS se paga:

• pipeline prompt-to-video, onde o pedido chega a qualquer hora e precisa sair rápido
• editor de vídeo com render sob demanda do usuário final
• geração personalizada em massa, tipo o mesmo template com dados diferentes pra cada cliente
• picos irregulares de volume, aqueles em que o mês quase inteiro é calmo e um dia explode

Nesses casos, um servidor ligado 24 horas ficaria ocioso a maior parte do tempo, e você pagaria por esse silêncio

Cenários em que a máquina local ou um servidor único já resolvem:

• volume baixo e previsível
• render pontual, aquele que você roda de vez em quando
• vídeo único e longo, que esbarra no limite de saída de cerca de 5 GB (perto de 160 minutos em Full HD)

O último caso é o mais decisivo: se o formato do seu vídeo não cabe no teto, nenhuma quota resolve

E se a sua dor não é renderizar, e sim COORDENAR as etapas antes e depois do render, talvez o que você precise seja montar pipelines serverless com n8n em volta do que você já tem

Vídeo: para onde está indo a geração de vídeo

Pra situar o mercado de vídeo por IA hoje, esse vídeo do canal fala do Kling 3.0:

É o outro lado da moeda: de um lado o vídeo GERADO por modelo, do outro o vídeo PROGRAMADO em React e renderizado em escala

Vale usar o Remotion Lambda hoje?

Veredito honesto: pra quem precisa mesmo de render distribuído, o Remotion Lambda é a escolha padrão, e é isso que a documentação recomenda para a maioria das pessoas, pelo equilíbrio entre velocidade, facilidade de setup, maturidade, custo total e escalabilidade

O argumento mais forte é que é a ÚNICA das opções server-side que distribui o render entre máquinas, e que os clientes de maior volume estão nela

As ressalvas também são reais, e não adianta fingir que não existem:

• teto de saída em torno de 5 GB, que exclui vídeo único muito longo
• quotas de concorrência da AWS, que em conta nova podem começar em 10 execuções
• custo de licença assim que a empresa passa de três pessoas, com Minimum Spend de US$ 100 por mês no tier de automação

Nota de versão pra fechar: a versão mais recente do pacote remotion publicada no npm é a 4.0.516, e o Remotion 5.0 ainda não foi lançado (existe só uma lista incompleta de breaking changes planejadas)

Ou seja, dá pra construir em cima do 4.x sabendo que uma virada de major está no radar

Conclusão

A decisão cabe numa linha: Lambda quando o volume é alto ou imprevisível e você quer pagar só pelo render, máquina local ou servidor único quando o volume é baixo e constante

O próximo passo concreto é o mesmo que a documentação pede: rode UM render de teste da sua própria composição e meça o custo dela, com estimatePrice() levando em conta arquitetura de CPU, disco e número de Lambdas

Com esse número na mão, dimensionar o lote deixa de ser achismo

Até o próximo post! 🙂