Vercel ou AWS: qual usar no sistema web (e quando usar as duas)

A conversa costuma começar com o time técnico, ou com o fornecedor, dizendo algo como "vamos subir na Vercel, é só conectar o repositório". Pouco depois, alguém do financeiro ou da TI pergunta por que não colocar tudo na AWS, onde a empresa já tem conta, contrato e outros sistemas rodando. As duas sugestões fazem sentido, e é justamente por isso que a decisão trava.

Vercel e AWS não são o mesmo tipo de produto. A Vercel é uma plataforma de publicação focada em front-end e em aplicações web modernas, especialmente as feitas com Next.js, framework mantido pela própria empresa. A AWS é uma nuvem completa, com centenas de serviços de computação, banco de dados, rede, filas, armazenamento e segurança. É como comparar um apartamento mobiliado com um terreno: um entrega pronto o que a maioria precisa, o outro permite construir qualquer coisa, mas exige projeto.

Este texto mostra como decidir pelo formato da aplicação e, principalmente, pelo que ela precisa ao redor dela. Vale o mesmo raciocínio para alternativas parecidas, como Netlify de um lado e Azure ou Google Cloud do outro.

Resposta curta: se o sistema é principalmente front-end, site, portal ou aplicação Next.js com back-end leve, a Vercel (ou similar) entrega deploy sem atrito e costuma ser a melhor escolha. Se ele depende de filas, tarefas longas, banco de dados na mesma rede privada, VPN com clientes ou exigências de região e compliance, a nuvem completa vira o lugar natural. Muitas empresas acertam usando as duas: front na plataforma, back-end na nuvem.

O que a Vercel faz e por que desenvolvedores gostam dela

A proposta da Vercel é tirar a infraestrutura do caminho de quem escreve a aplicação. O desenvolvedor conecta o repositório de código, e cada alteração enviada gera uma nova versão publicada automaticamente. Cada proposta de mudança ganha um endereço de pré-visualização próprio, que o gestor pode abrir no celular e aprovar antes de ir para produção.

O que costuma conquistar os times:

• Deploy sem atrito. Não há servidor para configurar, sistema operacional para atualizar nem balanceador para montar. O fluxo de integração e entrega contínuas já vem embutido.
• Pré-visualização por mudança. Revisar uma tela nova vira algo trivial, e isso encurta o ciclo entre pedir um ajuste e ver o ajuste funcionando.
• Entrega global de conteúdo. Páginas e arquivos estáticos ficam em uma rede de distribuição, perto de quem acessa, o que ajuda na velocidade percebida.
• Funções sob demanda. Pequenos trechos de back-end, como receber um formulário ou consultar uma API, rodam sem servidor dedicado, no modelo serverless.
• Integração natural com Next.js. Como o framework e a plataforma vêm da mesma empresa, recursos novos do Next.js tendem a funcionar ali com pouca configuração.
• Marketplace de integrações. Bancos de dados gerenciados, monitoramento e outros serviços de terceiros podem ser conectados a partir da própria plataforma.

Para um site institucional, uma landing page, um portal de conteúdo ou o front-end de um sistema cujo back-end está em outro lugar, isso resolve muito bem. Construir o mesmo fluxo do zero numa nuvem completa dá trabalho e, em muitos casos, não traz ganho real para o negócio.

O que muda numa nuvem completa como a AWS

Na AWS, e de forma parecida no Azure e no Google Cloud, a empresa não recebe uma plataforma pronta: recebe peças. Máquinas virtuais, contêineres, funções serverless, bancos de dados gerenciados, filas de mensagens, armazenamento de arquivos, redes privadas, firewalls, gerenciamento de identidade e acesso, monitoramento e muito mais.

Essa liberdade tem duas faces:

• Cabe praticamente qualquer arquitetura. Um sistema de gestão com processamento noturno, integração com ERP, fila de emissão de notas e banco relacional grande encontra ali tudo o que precisa, no mesmo ambiente.
• Alguém precisa montar e cuidar. Rede, permissões, backups, atualização, monitoramento e custo não se configuram sozinhos. Existem serviços que simplificam a publicação de aplicações web dentro da própria AWS, mas o desenho do ambiente continua sendo responsabilidade de quem contrata.

Se a dúvida também envolve qual nuvem completa escolher, o comparativo entre AWS, Azure e Google Cloud trata disso. E se a pergunta é ainda mais ampla, incluindo VPS e hospedagem tradicional, vale ler onde hospedar um sistema web.

Tarefas longas, filas, banco e rede privada: os limites da plataforma

Plataformas como a Vercel foram desenhadas para responder requisições web rapidamente. É aí que elas brilham, e é também aí que aparecem os limites quando o sistema faz mais do que isso. Os limites exatos de cada plano mudam com o tempo, então confirme os atuais com o fornecedor; o que importa aqui é o tipo de necessidade.

Tarefas que demoram

Gerar um relatório pesado, importar uma planilha com muitas linhas, processar imagens em lote, conciliar extratos bancários ou rodar um fechamento mensal são tarefas que podem levar minutos. Funções serverless de plataformas de front-end têm tempo máximo de execução e não foram pensadas para trabalho prolongado. Dá para contornar dividindo o trabalho em partes, mas, a partir de certo ponto, o contorno vira a arquitetura inteira.

Filas e processamento em segundo plano

Sistemas de gestão vivem de tarefas assíncronas: enviar e-mails em massa, emitir documentos fiscais, sincronizar pedidos com um marketplace, reprocessar o que falhou. Isso pede fila de mensagens e processos que fiquem rodando para consumir essa fila. Na nuvem completa, fila e trabalhadores são peças nativas. Plataformas de front-end vêm adicionando recursos como rotinas agendadas e processamento em segundo plano, mas eles tendem a ser mais recentes e mais restritos, e é comum o time recorrer a um serviço externo especializado para segurar esse volume.

Banco de dados perto da aplicação

Um sistema que faz muitas consultas por tela sente a distância entre a aplicação e o banco. Quando o banco está na mesma rede privada que o back-end, a comunicação é rápida e o banco não precisa ficar exposto à internet. Com funções rodando em uma plataforma e o banco em outro provedor, é preciso cuidar de conexões, latência e de como liberar o acesso com segurança.

Rede privada e VPN com clientes

Integrações corporativas muitas vezes exigem que o tráfego venha de um endereço fixo conhecido, passe por uma VPN com o parceiro ou acesse sistemas que não estão na internet pública, como um ERP rodando no servidor do cliente. Nuvens completas oferecem redes privadas, endereços fixos e conexões VPN como peças padrão. Em plataformas de front-end, esse tipo de recurso, quando existe, costuma ser mais restrito e ligado a planos específicos.

Região dos dados, compliance e contrato corporativo

Há empresas em que a escolha não é técnica, é contratual. Alguns cenários comuns:

• Região dos dados. Cliente, contrato ou política interna exige que os dados fiquem no Brasil. A LGPD, por si só, não exige isso: ela permite transferência internacional de dados nas condições que a própria lei define. Mesmo assim, muitos contratos e políticas de clientes pedem. As nuvens completas permitem escolher explicitamente em qual região cada recurso roda, inclusive no Brasil. Em plataformas de front-end, geralmente é possível escolher a região das funções, mas é preciso verificar com cuidado onde ficam logs, cache, dados de build e serviços integrados. O artigo sobre dados na nuvem no Brasil e LGPD detalha quando isso importa de verdade.
• Auditoria e controles. Setores regulados, como saúde, financeiro e serviços para governo, costumam pedir trilha de auditoria, controle fino de acesso e evidências de segurança. Nuvens completas atendem esse público há muitos anos e oferecem esses controles em profundidade, com a ressalva de que configurá-los corretamente continua sendo trabalho de quem contrata.
• Contrato e faturamento. Se a empresa já tem conta corporativa em uma nuvem, com faturamento centralizado, suporte contratado e políticas de segurança definidas, colocar o novo sistema no mesmo ambiente simplifica compras, governança e auditoria.

Nada disso significa que a Vercel não atenda empresas exigentes. Ela tem oferta corporativa e trata de segurança e conformidade. Significa que, quando o requisito é específico, ele precisa ser confirmado com o fornecedor antes da decisão, e não descoberto depois que o sistema está no ar.

Arquitetura combinada: front na Vercel, back-end na nuvem

Em muitos projetos, a melhor resposta é não escolher. A arquitetura combinada funciona assim:

• Front-end na Vercel (ou similar): telas, páginas públicas, portal do cliente e o back-end leve que só repassa chamadas. O time ganha deploy simples, pré-visualização e entrega rápida das páginas.
• Back-end na nuvem completa: a API principal, o banco de dados, as filas, os processos em segundo plano, as integrações com ERP e parceiros e tudo o que precisa de rede privada ou região definida.

Os dois conversam por uma API bem definida, com autenticação.

Esse desenho tem custos que precisam ser assumidos de olhos abertos:

• Dois fornecedores para administrar, com contas, permissões e faturas separadas.
• Mais um ponto de atenção na comunicação entre front e back-end: configuração de domínios, CORS, autenticação e tempo de resposta.
• Monitoramento em dois lugares, o que exige juntar logs e alertas para entender um problema de ponta a ponta.

Para um sistema pequeno, isso pode ser exagero, e colocar tudo em um lugar só é mais sensato. Para um sistema com portal público importante e um back-end corporativo robusto, a divisão costuma compensar. Em datas de pico de acesso, por exemplo, ter as páginas servidas por uma rede de distribuição alivia bastante a carga que chega ao back-end.

Custo: previsibilidade de cada modelo

Comparar preço de tabela entre as duas opções raramente ajuda, porque elas cobram coisas diferentes. O que vale entender é como a conta se comporta quando o sistema cresce.

• Na plataforma de front-end, a cobrança gira em torno de planos com franquias de uso. Para sites e portais de tráfego moderado, a conta tende a ser simples e previsível. O ponto de atenção é o uso intensivo de funções, de imagens otimizadas e de tráfego: quando o sistema passa a fazer trabalho de back-end pesado dentro da plataforma, o excedente pode crescer mais rápido do que o esperado.
• Na nuvem completa, cada recurso é cobrado pelo uso: máquinas, banco, armazenamento, transferência de dados, filas. Isso dá controle fino, mas também abre espaço para desperdício, como ambientes de teste esquecidos ligados, bancos superdimensionados e tráfego entre regiões que ninguém planejou.

Nos dois casos, três hábitos evitam surpresa: configurar alertas de gasto desde o primeiro dia, revisar a fatura todo mês com alguém que entende o que cada item significa e simular o custo com o volume esperado para daqui a um ano, não só para o lançamento. Se a conta de nuvem já está alta, o texto sobre como reduzir custos de nuvem mostra onde costuma estar o desperdício.

Lembre também do custo que não aparece na fatura: horas de alguém cuidando do ambiente. A plataforma pronta cobra pela conveniência; a nuvem completa dá mais margem para otimizar a conta, mas exige gente para operar. Para uma empresa sem time de infraestrutura, esse custo de operação costuma pesar mais que a diferença na conta mensal.

Tabela comparativa: Vercel x AWS

Os recursos dos dois lados evoluem com frequência. Use a tabela como mapa de perguntas e confirme os detalhes atuais com cada fornecedor.

Quando escolher cada um

Sinais de que a Vercel (ou similar) é a melhor escolha

• O projeto é um site, landing page, portal de conteúdo ou o front-end de um sistema cujo back-end já existe.
• A aplicação é feita em Next.js ou em outro framework moderno de front-end bem suportado pela plataforma.
• O back-end necessário é leve: formulários, chamadas a APIs de terceiros, autenticação, consultas rápidas.
• O time é pequeno e não tem ninguém dedicado a infraestrutura, e você prefere que ele gaste o tempo nas funcionalidades.
• Não há exigência contratual de região, rede privada ou VPN.
• A velocidade de publicar e revisar mudanças pesa mais que o controle fino do ambiente.

Sinais de que a nuvem completa (AWS, Azure ou GCP) é a melhor escolha

• O sistema tem processamento pesado ou demorado: importações, relatórios grandes, fechamentos, conciliações.
• Há filas, rotinas agendadas e processos rodando o tempo todo em segundo plano.
• O banco de dados é grande, muito consultado e deve ficar em rede privada junto da aplicação.
• Existem integrações que exigem IP fixo, VPN ou acesso a sistemas fora da internet pública.
• Contratos, clientes ou o setor exigem região definida, trilhas de auditoria e controles específicos.
• A empresa já tem conta corporativa em uma nuvem, com governança e faturamento organizados.

Sinais de que a arquitetura combinada vale a pena

• O sistema tem uma face pública importante (site, loja, portal do cliente) e um núcleo operacional pesado.
• Times diferentes cuidam do front-end e do back-end, cada um com seu ritmo de publicação.
• Você quer a experiência de deploy da plataforma para as telas sem abrir mão do controle da nuvem para os dados.

Se nenhum desses sinais é forte, comece simples. Um sistema que nasce pequeno numa plataforma bem escolhida pode migrar o back-end para a nuvem quando a necessidade aparecer, desde que o código tenha sido escrito sem amarrar tudo a recursos exclusivos de um fornecedor.

Perguntas frequentes

A Vercel serve para back-end?

Serve para back-end leve, como formulários, autenticação, chamadas a APIs de terceiros e consultas rápidas, por meio de funções serverless. Para tarefas demoradas, filas, processamento em segundo plano, banco de dados em rede privada ou VPN com parceiros, a Vercel fica mais restrita, e um back-end numa nuvem completa como a AWS costuma ser o caminho mais sólido.

Dá para usar Next.js fora da Vercel?

Sim. O Next.js é mantido pela Vercel, mas é um framework de código aberto e pode rodar em outras plataformas e em nuvens completas como AWS, Azure ou Google Cloud. A diferença é que, fora da Vercel, alguns recursos exigem mais configuração. Evitar amarrar o código a recursos exclusivos da plataforma facilita uma migração futura.

Vercel ou AWS: qual sai mais barato?

Depende do uso, porque as duas cobram coisas diferentes. A Vercel trabalha com planos e franquias, e a conta tende a ser previsível para sites e portais de tráfego moderado. A AWS cobra cada recurso pelo uso, o que permite otimizar, mas exige alguém operando o ambiente, e esse custo de operação muitas vezes pesa mais que a fatura.

É possível migrar da Vercel para a AWS depois?

Sim, especialmente quando o código foi escrito sem depender de recursos exclusivos da plataforma. Um caminho comum é começar com tudo na Vercel e, quando aparecem filas, tarefas longas ou exigências de rede privada, mover o back-end para a AWS e manter o front-end na Vercel, numa arquitetura combinada que conversa por uma API autenticada.

Como a Pervian Tech ajuda a decidir e escolher onde o sistema vai rodar

Começamos pelo sistema, não pelo provedor. No diagnóstico inicial gratuito, levantamos o que a aplicação faz, que tarefas rodam em segundo plano, onde está o banco, com quem ela precisa se integrar e quais exigências de contrato, região e auditoria existem. Com esse mapa, a escolha entre Vercel, AWS ou os dois deixa de ser opinião e passa a ser consequência.

Quando a plataforma pronta atende, recomendamos a plataforma pronta e configuramos o fluxo de publicação. Quando o sistema pede nuvem completa, desenhamos e montamos o ambiente com rede, acessos, backups, monitoramento e esteira de deploy, e deixamos tudo documentado para que a empresa não fique refém de ninguém. Quando faz sentido combinar, definimos a fronteira entre as duas partes antes de escrever a primeira linha. Saiba mais sobre o nosso trabalho em cloud e DevOps e veja outros textos da categoria cloud e infraestrutura.

O investimento é definido sob consulta, depois de entender o tamanho do sistema e o que ele precisa ao redor. Se você está decidindo onde publicar um sistema novo ou repensando onde o atual roda, fale com a gente.