# Migrar app para serverless: os passos e o que muda no custo

> O que sua aplicação precisa ter para rodar 100% serverless na AWS: sem estado, Fargate ou Lambda, banco gerenciado e por que o custo acompanha o uso.

- Autor: Henrylle Maia, consultor AWS
- Publicado em: 2026-10-15
- Assuntos: Migração, Serverless, Custos
- URL: https://pages.formacaoaws.com.br/blog/migrar-app-para-serverless/
- Aula de origem: "O que fazer para migrar sua app para 100% Serverless" (https://www.youtube.com/watch?v=0bmB959Pq-A)

No fim deste texto você vai saber o que a sua aplicação precisa ter para rodar 100% serverless na AWS e quais são os dois caminhos que eu apresentei: Fargate no lugar das EC2, ou funções Lambda no lugar do servidor. Vai entender também por que, nesse modelo, o custo passa a acompanhar o uso e não a capacidade que você deixou ligada.

## O que é "100% serverless" aqui

Serverless, nesta conversa, é um cenário em que a sua aplicação não tem nenhum servidor para você gerenciar. Você não sobe instância EC2 para rodar os serviços: quem se preocupa com a infraestrutura é a AWS, que lança os recursos para a aplicação.

Gravei esta aula em novembro de 2021, depois de ter levado uma aplicação local para a nuvem da AWS, com alta disponibilidade, no Bootcamp Imersão AWS, em outubro. A aplicação é a Bia, um front-end em React e uma API em Node. Dali eu parto para dois cenários de migração.

## Passo 1: tire o estado da aplicação

Este é o primeiro requisito, e vale para qualquer um dos caminhos: **a aplicação não pode ter estado**. Se ela tem, você não chega nem a um cenário de alta disponibilidade, que dirá a um serverless.

O que isso significa na prática. Imagine várias instâncias atendendo a mesma aplicação. Você faz uma requisição e ela cai na máquina 1. Faz a mesma requisição de novo e ela cai na máquina 2. A resposta tem que ser a mesma.

Se a aplicação guarda informação dentro da máquina, isso quebra. Exemplo: o usuário envia uma imagem, ela fica guardada na máquina 1, e a requisição seguinte cai na máquina 2, onde essa imagem não existe. Esse é um estado preso à máquina, e ele impede a migração para alta disponibilidade e, por consequência, para o cenário 100% serverless.

> **Importante:** antes de escolher serviço, procure o que a sua aplicação grava localmente. Enquanto isso existir, nenhum dos dois caminhos abaixo funciona.

## Passo 2: caminho 1, Fargate no lugar das EC2

O primeiro cenário parte de uma aplicação que já está em alta disponibilidade com **containers**, que foi onde chegamos no evento. A mudança é simples: você configura a aplicação para não levantar instâncias EC2 para rodar os serviços e passa a usar o **Fargate**. Você coloca só o serviço; a AWS cuida da infraestrutura.

O segundo ponto desse caminho é o banco. Você migra para um banco serverless da estrutura do RDS e também se despreocupa dele. Com Fargate e banco serverless, a aplicação fica 100% serverless.

É o caminho mais simples dos dois, e nem por isso menos válido: a aplicação chega ao 100% serverless por ele também.

## Passo 3: caminho 2, funções Lambda atendendo a API

O segundo cenário é a arquitetura que, para mim, é uma das mais incríveis para aplicações serverless. Em vez de atender as requisições com containers, você usa **Lambda**. Traz mais desafios, mas é também o mais interessante.

O desenho que usei na aula:

**Fluxo:** Usuário (faz a requisição) → CDN (é a entrada de tudo) → Amazon S3 (entrega o front-end) → ALB e Lambda (a origem do CDN, com as funções da API) → Banco serverless (sem servidor para gerenciar)

Na arquitetura anterior, o usuário passava por um Application Load Balancer (ALB) e as requisições eram distribuídas para os serviços no Fargate. Aqui entra um CDN na ponta:

- **CDN como centralizador.** Ele recebe as requisições do usuário e é a entrada de tudo. A origem dele aponta para o ALB.
- **ALB e funções Lambda.** O ALB fica na frente e conversa com as funções Lambda, que atendem a API no lugar dos servidores.
- **Front-end no S3.** Você entrega o front-end pelo S3 e o roteia pelo CDN.
- **Banco serverless.** Embaixo, o banco também é 100% serverless.

![O CDN na ponta, ligado ao ALB e ao S3 do front-end; o ALB chama as funções Lambda, que falam com o BD serverless, tudo dentro da AWS](https://pages.formacaoaws.com.br/blog/assets/posts/migrar-app-para-serverless/cdn-alb-lambda-s3.svg)

Nesse cenário não existe nenhum servidor, e a arquitetura é extremamente escalável.

## Por que o custo muda

A maior vantagem do segundo cenário sobre o primeiro é o custo. A explicação é um gráfico de custo contra o recurso demandado.

**Com instâncias EC2.** Para ter alta disponibilidade, você precisa de pelo menos duas instâncias, e elas custam desde o primeiro minuto, mesmo sem nenhuma requisição. Quando a demanda sobe, o auto scaling aloca mais instâncias (no desenho, de 2 para 3 e depois para 4). Quando a demanda cai, ele volta para 2. Entre a linha do que a aplicação pede e a linha do que está alocado fica uma folga: capacidade ligada e paga sem necessidade.

![Gráfico de custo contra recurso com EC2: o custo sobe em degraus, de 2 para 3 e 4 instâncias, e volta a 2, sempre acima da linha laranja da demanda](https://pages.formacaoaws.com.br/blog/assets/posts/migrar-app-para-serverless/custo-ec2-escala.svg)

**Com Lambda.** A aplicação começa com zero recurso alocado. Chegou uma requisição, a função processa, e parou de cobrar. Chegou outra, processa de novo, e para de cobrar. O custo fica muito próximo do que de fato foi requisitado, sem essa folga.

![Gráfico de custo contra recurso com Lambda: a linha de custo acompanha de perto a curva laranja da demanda](https://pages.formacaoaws.com.br/blog/assets/posts/migrar-app-para-serverless/custo-lambda.svg)

Dois cuidados que eu mesmo fiz questão de dizer: o serverless traz desafios, e não é para toda aplicação. Não é bala de prata que resolve custo de qualquer cenário.

## Passo 4: escolha a ferramenta para fazer a migração

Para executar essa migração, você precisa de uma ferramenta que automatize o processo. Eu conheço duas de que gosto muito:

- **Serverless Framework.** Ajuda no deploy da aplicação na AWS e faz mais do que isso.
- **AWS SAM (Serverless Application Model).** É a ferramenta nativa da AWS, e é a que eu vou usar nessa migração.

Escolha uma antes de começar, porque é nela que a arquitetura serverless vai ser descrita.

## Checklist

- Procure o que a sua aplicação grava localmente (imagens, sessão, arquivos). Se há estado preso à máquina, resolva isso primeiro.
- Defina o caminho: Fargate com banco serverless (mais simples) ou Lambda atrás do CDN, com front-end no S3 (mais avançado).
- Decida se o seu caso é de serverless: não é para toda aplicação, nem resolve o custo de qualquer cenário.
- Escolha a ferramenta: Serverless Framework ou AWS SAM.

Serverless é um modelo em que você paga pelo uso e deixa de gerenciar servidor, mas só funciona depois que a aplicação perde o estado. Se você quer levar a sua aplicação para a AWS por um desses caminhos, vale uma conversa sobre o seu cenário antes de escolher.