Problema
Subir npm start em uma EC2 sem process manager, sem healthcheck e com build feito na máquina de produção. Ou misturar SSR com assets estáticos sem CloudFront e pagar latência e custo desnecessários.
Solução
Separar artefato imutável (imagem Docker ou bundle versionado) de config por ambiente. Next: standalone output para container enxuto; assets long-lived no S3 + CloudFront; TLS no ALB ou CloudFront. Node API atrás do mesmo ALB ou subdomínio com routing rules.
Arquitetura
Internet → CloudFront (estático + opcional cache HTML)
→ ALB → target group ECS/EC2 (Next SSR / API)
S3 bucket (assets públicos, OAC)
ECR (imagens)
Secrets Manager / SSM para env
- CI builda e publica tag semver.
- CD atualiza serviço com rolling deployment.
Código
Dockerfile multi-stage (conceito):
FROM node:22-alpine AS deps
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
FROM deps AS build
COPY . .
RUN npm run build
FROM node:22-alpine AS runner
WORKDIR /app
ENV NODE_ENV=production
COPY --from=build /app/.next/standalone ./
COPY --from=build /app/.next/static ./.next/static
COPY --from=build /app/public ./public
EXPOSE 3000
CMD ["node", "server.js"]Performance
Cache de borda para rotas que suportam; compressão; HTTP/2 no ALB; imagens otimizadas via loader do Next apontando para CDN.
Melhorias futuras
ECS Fargate + auto scaling por CPU/RPS; WAF; blue/green com CodeDeploy.
Conclusão
AWS bem usada é automação + limites claros de rede e deploy. Isso casa com vagas que pedem cloud “de verdade”, não só conta criada.