Deploy rápido sem montar EC2, VPC nem IAM: guia de PaaS

Resposta curta#

Para um projeto pequeno ou médio, normalmente você não precisa subir instâncias EC2, desenhar uma VPC nem brigar com políticas de IAM. Um PaaS (Platform as a Service) faz esse trabalho por você: você conecta o repositório, faz git push e a plataforma compila, faz o deploy, atribui um domínio com HTTPS e opera a camada de infraestrutura.

Montar sua própria infraestrutura na AWS vale a pena quando você tem requisitos de compliance, de rede ou de escala que um PaaS não atende. Para a maioria das startups e times pequenos, começar num PaaS é mais rápido e consome muito menos horas de engenharia.

Seu backend já funciona em localhost, o código está pronto, e surge a pergunta que trava times inteiros: onde faço o deploy disso sem montar um EC2, uma VPC, um load balancer, regras de IAM e meia dúzia de serviços? É uma das dúvidas mais repetidas entre desenvolvedores, porque o deploy acaba sendo mais difícil do que escrever a aplicação. O motivo é que nuvens de propósito geral como AWS, Google Cloud ou Azure são caixas de ferramentas, não soluções prontas: elas oferecem centenas de serviços e esperam que você seja ao mesmo tempo arquiteto, engenheiro de redes e responsável pela segurança.

Documentação: AWS · Documentação do Amazon EC2 ↗ · AWS · O que é a Amazon VPC ↗ · AWS · Boas práticas de segurança no IAM ↗

O que envolve fazer deploy na AWS “na mão”#

Para publicar uma única aplicação numa instância EC2 do zero, o caminho mínimo é este:

• Criar e configurar uma VPC: sub-redes públicas e privadas, tabelas de rotas e internet gateway.
• Subir uma instância EC2 e escolher tipo, AMI e armazenamento.
• Configurar security groups: quais portas abrir e para quem.
• Definir roles e políticas de IAM com privilégio mínimo.
• Instalar o runtime, as dependências e um gerenciador de processos.
• Montar um load balancer (ALB) e certificados TLS.
• Configurar um pipeline de CI/CD para não fazer deploy na mão toda vez.
• Resolver monitoramento, logs, backups, patches do sistema operacional e rotação de credenciais.

Cada item é razoável isoladamente, mas, no conjunto, é trabalho de plataforma antes que o seu primeiro usuário veja o app. Além disso, no modelo de responsabilidade compartilhada da AWS, quando você usa EC2, o sistema operacional convidado, seus patches, a configuração de rede e as permissões são responsabilidade sua. Para um time que precisa validar uma ideia nesta semana, isso é tempo que não vai para o produto.

Para se aprofundar: Como separar ambientes (dev, staging e produção) na AWS

Documentação: AWS · O que é a Amazon VPC ↗ · AWS · Boas práticas de segurança no IAM ↗ · AWS · Modelo de responsabilidade compartilhada ↗ · AWS · Documentação do Amazon EC2 ↗

O que é um PaaS e por que ele resolve isso#

Um PaaS abstrai essa camada de infraestrutura. O fluxo típico se resume a um git push: a plataforma detecta a linguagem (Node, Python, Go etc.), gera uma imagem ou artefato executável, faz o deploy na sua camada de computação gerenciada e entrega uma URL com HTTPS pronto.

Muitas plataformas detectam a linguagem com buildpacks, um mecanismo popularizado pelo Heroku e hoje padronizado no projeto Cloud Native Buildpacks, que transforma o código-fonte numa imagem OCI sem que você escreva um Dockerfile. Outras também aceitam um Dockerfile quando você precisa de mais controle.

O que some da sua lista é a VPC, o IAM de infraestrutura, os servidores para aplicar patch e a renovação manual de certificados. O que continua sendo seu: o código, as dependências, os segredos e a configuração do app. Um PaaS não isenta você da segurança no nível da aplicação; ele tira de você a parte que não diferencia o seu produto.

Para que seu app funcione bem em qualquer PaaS, e para poder sair dele se um dia precisar, aplique dois princípios do The Twelve-Factor App: a configuração fica em variáveis de ambiente, nunca no código, e o processo escuta na porta indicada pela plataforma.

FROM node:22-slim
WORKDIR /app
ENV NODE_ENV=production

COPY package*.json ./
RUN npm ci --omit=dev
COPY . .

# A plataforma injeta PORT; o app deve lê-la com process.env.PORT
ENV PORT=8080
EXPOSE 8080
USER node
CMD ["node", "server.js"]

Documentação: Heroku Dev Center · How Heroku Works ↗ · Cloud Native Buildpacks · Documentação ↗ · The Twelve-Factor App (em espanhol) ↗ · The Twelve-Factor App · Configurações ↗ · Docker · Referência do Dockerfile ↗

Comparativo: infraestrutura própria, PaaS e opções gerenciadas#

A tabela resume as diferenças práticas entre montar a infraestrutura na mão, usar um PaaS e ficar nos serviços gerenciados da sua nuvem. São tendências gerais: o resultado depende do provedor específico, da sua aplicação e do que o seu time já sabe operar.

Antes de escolher uma plataforma específica, veja como ela cobra, em quais regiões roda, que suporte oferece e se você consegue levar a aplicação para outro lugar sem reescrevê-la. Se você está avaliando plataformas gerenciadas para times sem DevOps dedicado, a Codifly tem o comparativo entre C4C7OPS e Qovery com as fontes.

Se preferir ficar dentro da AWS, também há opções gerenciadas: o Elastic Beanstalk faz o deploy de aplicações sem que você administre a infraestrutura subjacente, e o Amazon ECS com Fargate executa containers sem servidores para gerenciar. Atenção ao AWS App Runner: a AWS o fechou para novos clientes e recomenda o Amazon ECS Express Mode como caminho de migração.

Documentação: AWS · O que é o Elastic Beanstalk ↗ · AWS · Amazon ECS no AWS Fargate ↗ · AWS · Mudança de disponibilidade do App Runner ↗

Quando vale a pena montar sua própria infraestrutura#

Um PaaS nem sempre é a resposta. Considere uma infraestrutura gerenciada por você quando:

• Você tem requisitos de compliance rígidos, por exemplo dados que precisam ficar numa região ou conta sob seu controle total, ou auditorias diretas sobre a rede (PCI DSS, HIPAA, soberania de dados).
• Você precisa de uma configuração de rede específica: peering, VPNs complexas, sub-redes isoladas ou integração com serviços internos de uma VPC corporativa.
• Você opera numa escala em que o custo por unidade de computação do PaaS supera claramente o custo de operar por conta própria, incluindo as horas de engenharia.
• Seu time já tem engenharia de plataforma dedicada e a infraestrutura faz parte do núcleo do negócio.

A escolha não é “PaaS contra AWS”, é abstração contra controle. Enquanto você não tiver uma dessas necessidades, a infraestrutura gerenciada por um PaaS é um padrão razoável. Quando elas aparecerem, esse é o ponto de virada para ir para EC2 com VPC e IAM, ou para orquestração com ECS ou EKS.

Para se aprofundar: Padrões de infraestrutura que não funcionam a longo prazo

Documentação: AWS · O que é a Amazon VPC ↗ · AWS · O que é o Amazon ECS ↗

Do git push à produção, passo a passo#

• Conecte seu repositório: vincule seu repositório do GitHub ao PaaS e defina o comando de build e a porta de escuta como variável de ambiente.
• Faça git push: a plataforma detecta a mudança, compila, cria o processo ou container e o expõe num domínio HTTPS automático.
• Configure as variáveis de ambiente: adicione credenciais e configuração de produção sem mexer em servidores nem em arquivos de sistema.
• Esteja pronto para migrar se precisar: mantenha o app containerizado com um Dockerfile padrão e evite dependências proprietárias do PaaS, para poder levá-lo ao ECS ou EKS quando for necessário.

Esse último passo é o seguro barato: se o app é portável, começar num PaaS não prende você. Sempre dá para migrar depois; começar ao contrário, montando toda a infraestrutura antes de ter usuários, custa semanas que um time pequeno não tem.

Documentação: The Twelve-Factor App (em espanhol) ↗ · Docker · Referência do Dockerfile ↗ · AWS · O que é o Amazon ECS ↗

Decisão final: PaaS ou infraestrutura própria#

O segredo está em avaliar qual recurso é mais escasso no seu time: horas de engenharia ou controle sobre a infraestrutura. Se a sua prioridade é validar o produto, chegar aos usuários e andar rápido, um PaaS reduz o atrito do deploy a um git push. Se você opera sob requisitos regulatórios rígidos, precisa de controle granular de rede ou projeta uma escala em que o custo por instância seja determinante, investir em EC2, VPC e IAM faz sentido.

Regra prática: se o seu time não tem ninguém dedicado à infraestrutura e o seu app não lida com dados que exigem isolamento por norma, faça o deploy num PaaS. Você vai estar em produção com HTTPS, domínio e escalabilidade básica logo depois de terminar o código. Se precisa controlar sub-redes, políticas de acesso no nível de rede ou se integrar a uma VPC corporativa, monte infraestrutura própria.

O importante é que a decisão seja consciente, e não por inércia. Comece com a opção que permite entregar valor mais rápido e migre só quando tiver evidências claras de que a limitação do PaaS está segurando você.

Documentação: AWS · Modelo de responsabilidade compartilhada ↗