Migração segura e acessível para a AWS com arquitetura híbrida

1. Contexto

Pequenas empresas e empreendedores solo muitas vezes hesitam em migrar suas aplicações para a nuvem por preocupações com custo, complexidade ou dependência do fornecedor. No entanto, servidores on-premises envolvem custos operacionais mais altos e fixos — não no modelo pay-as-you-go — e limitam a escalabilidade e a segurança.

Este artigo apresenta uma arquitetura híbrida na AWS voltada para esse público: baixo custo, alta disponibilidade e segurança embutida. A solução usa serviços gerenciados e serverless para reduzir manutenção e despesas fixas, mantendo a estrutura simples o suficiente para ser operada por times pequenos.

O modelo baseia-se em separar o frontend e o backend em ambientes independentes, cada um otimizado para seu papel, mas integrados dentro de uma única infraestrutura em nuvem — incluindo um banco de dados relacional centralizado e seguro acessado pelo backend. Essa separação permite modularidade, ciclos de implantação independentes e escalabilidade sob demanda, com custo operacional médio de cerca de ~US$45/mês e US$15/ano para o registro do domínio.

2. Arquitetura Original e Limitações do Monólito

Como exemplo, considere um monólito Django + DRF, em que frontend e backend compartilham o mesmo servidor, ciclo de deploy e recursos de hardware — o que impede atualizações independentes e escalabilidade eficiente.

A migração começa separando logicamente os serviços:

• Frontend: Django Templates, hospedado no Elastic Beanstalk com domínio customizado e certificado SSL (ACM)
• Backend: API REST em AWS Lambda, exposta via HTTP API Gateway, integrada ao RDS por meio do RDS Proxy, com credenciais no Secrets Manager
• Comunicação: o frontend consome a API via chamadas server-to-server, eliminando requisições diretas do navegador

Com essa separação, cada serviço tem seu próprio ciclo de vida e pode evoluir e escalar de forma independente.

3. Implementação da Migração

3.1 Arquitetura Híbrida Inteligente

O frontend em Django é hospedado no Elastic Beanstalk, entregando páginas renderizadas no servidor (SSR) para garantir desempenho consistente e indexação adequada por mecanismos de busca (SEO). O serviço oferece escalonamento automático gerenciado, reduzindo a necessidade de gerenciamento manual de infraestrutura e mantendo os custos sob controle.

O Elastic Beanstalk é uma excelente alternativa ao ECS devido à sua simplicidade operacional e relação custo-benefício: ele abstrai a infraestrutura, permite implantações diretas de aplicações Django sem conteinerização complexa e integra-se nativamente ao ACM para HTTPS.

No backend, o uso de AWS Lambda remove a necessidade de manter servidores rodando 24/7 — um benefício relevante para aplicações com baixo tráfego noturno — tornando os custos estritamente proporcionais ao uso real. Essa abordagem garante escalabilidade automática e previsibilidade financeira sem comprometer o desempenho.

O banco de dados, que anteriormente rodava como uma instância MySQL dedicada em um servidor local neste exemplo, usa o Amazon RDS, configurado em uma sub-rede privada para impedir acesso direto da internet. A comunicação entre Lambda e RDS passa pelo RDS Proxy, que mantém um pool de conexões reutilizáveis.

Essa configuração fornece compatibilidade funcional com o ORM do Django, menor latência durante picos de tráfego e segurança aprimorada, já que somente a função Lambda pode acessar o banco de dados. O RDS gerenciado elimina tarefas administrativas como backups e atualizações, mantendo custos previsíveis e ambientes de dados isolados.

3.2 Lidando com os Desafios Django + Lambda

Executar um framework tradicional como Django em um ambiente serverless requer ajustes específicos. A seguir, considerações-chave para estabilidade e desempenho:

• Compatibilidade orientada a eventos: o Django foi projetado para servidores WSGI persistentes, o que o torna incompatível por padrão com o modelo sob demanda do AWS Lambda. Para habilitar a execução, use o Mangum, uma ponte entre o HTTP API Gateway e o Django via ASGI. Essa camada adapta os ciclos de requisição ao modelo do Lambda.
• Otimização de latência e conexões:
• Funções Lambda executam sob demanda, causando dois atrasos comuns: cold start e configuração de conexão com o banco.
• Cold start (2–5 segundos) ocorre quando uma instância é invocada pela primeira vez. Geralmente é desprezível em aplicações com tráfego moderado.
• Conexões com o banco podem adicionar 300–800 ms por requisição se cada Lambda abrir uma nova sessão TCP, alcançando rapidamente o limite de ~1000 conexões do MySQL.
• Use o RDS Proxy para manter um pool de conexões persistentes, reduzindo a latência média para ~50 ms, estabilizando o acesso e permitindo escalabilidade fluida.

Essa combinação Lambda + RDS Proxy garante escalabilidade elástica, baixa manutenção e precificação por uso.

3.3 Domínio e HTTPS

Executar um framework tradicional como Django em um ambiente serverless requer ajustes específicos. A seguir, considerações-chave para estabilidade e desempenho:

• Compatibilidade orientada a eventos: o Django foi projetado para servidores WSGI persistentes, o que o torna incompatível por padrão com o modelo sob demanda do AWS Lambda. Para habilitar a execução, use o Mangum, uma ponte entre o HTTP API Gateway e o Django via ASGI. Essa camada adapta os ciclos de requisição ao modelo do Lambda.
• Otimização de latência e conexões:
• Funções Lambda executam sob demanda, causando dois atrasos comuns: cold start e configuração de conexão com o banco.
• Cold start (2–5 segundos) ocorre quando uma instância é invocada pela primeira vez. Geralmente é desprezível em aplicações com tráfego moderado.
• Conexões com o banco podem adicionar 300–800 ms por requisição se cada Lambda abrir uma nova sessão TCP, alcançando rapidamente o limite de ~1000 conexões do MySQL.
• Use o RDS Proxy para manter um pool de conexões persistentes, reduzindo a latência média para ~50 ms, estabilizando o acesso e permitindo escalabilidade fluida.

Essa combinação Lambda + RDS Proxy garante escalabilidade elástica, baixa manutenção e precificação por uso.

4. Segurança em Camadas

A arquitetura adota uma abordagem de defesa em profundidade, na qual cada componente opera com privilégios mínimos dentro de uma rede isolada.

• Isolamento de rede: todos os fluxos de dados do backend ocorrem dentro de uma VPC privada. Lambda e RDS residem em sub-redes privadas, protegidos por security groups restritivos. O tráfego entre eles passa pelo RDS Proxy, evitando conexões diretas ao banco e minimizando exposição.
• Gerenciamento de credenciais: senhas e chaves de acesso são armazenadas no AWS Secrets Manager e no Parameter Store, nunca no código-fonte. As permissões de acesso a segredos seguem o princípio do menor privilégio, concedidas somente às funções que precisam delas.
• Autenticação de usuários: a API REST usa JWTs gerenciados no servidor e armazenados em cookies de sessão seguros. O navegador recebe apenas o cookie; o JWT em si nunca é exposto ao JavaScript nem transmitido por lógica no cliente — reduzindo a superfície de ataque e prevenindo vazamentos.
• Acesso administrativo seguro: durante desenvolvimento e testes, uma instância EC2 com OpenVPN pode ser implantada dentro da mesma VPC como um bastion host. Esse ponto de entrada permite validar Lambda, RDS Proxy e outros componentes sem expor endpoints públicos.

Nota: Escolher um OpenVPN autogerenciado em vez do AWS Client VPN ajuda a manter o orçamento sob controle. Essa opção, porém, requer familiaridade com OpenVPN (DNS, roteamento, iptables). Uma AMI pré-configurada do catálogo da AWS pode simplificar toda essa configuração.

5. Documentação da API

A documentação é gerada automaticamente com DRF Spectacular, que expõe um schema OpenAPI 3.0 e interface interativa em /api/docs/.

Isso garante consistência entre ambientes e reduz dependência de documentação manual.

6. AWS CDK – Infraestrutura como Código (IaC)

O AWS CDK oferece uma abordagem mais programável que o CloudFormation e é mais integrado à AWS do que o Terraform. Ele permite reutilizar lógica de programação real (loops, funções, classes) em vez de YAML — sendo o ideal para desenvolvedores com experiência prática.

Embora o CDK não empacote aplicações por padrão, usar a classe PythonFunction automatiza build e empacotamento com Docker, evitando ferramentas extras.

Mesmo em projetos pequenos, o CDK adiciona previsibilidade, controle de versão e reprodutibilidade de ambientes — crítico se o aplicativo crescer ou exigir migração futura.

Isso substitui ferramentas mais antigas como o Zappa, que não tem suporte ao HTTP API Gateway (v2) e depende do modelo REST (v1), levando a problemas de envio de cabeçalhos e autenticação baseada em JWT.

As permissões seguem  least privilege, e as saídas das pilhas permitem integração sem acoplamento rígido. Essa mudança do manual para o declarativo traz reprodutibilidade, segurança e uma fonte única de verdade para o ambiente AWS.

7. Monitoramento e Observabilidade

A observabilidade é mantida em nível essencial para sustentar a estabilidade operacional.

• Elastic Beanstalk realiza verificações de health por meio do ALB
• API Gateway registra requisições e erros no CloudWatch Logs

Essas ferramentas ajudam a detectar rapidamente erros de integração e problemas de disponibilidade.

Para melhores insights, considere evoluir para rastreamento distribuído com o AWS X-Ray e construir painéis de desempenho no CloudWatch.

8. Benefícios Arquiteturais

Um benefício menos óbvio da arquitetura híbrida é a eliminação dos problemas de CORS.

Em SPAs, o JavaScript do navegador faz requisições de API entre domínios, o que introduz complexidade e riscos de segurança. Nesta configuração, o navegador fala apenas com o frontend (vahltech.com no Elastic Beanstalk), e o Django realiza chamadas servidor-a-servidor para a API usando o módulo requests.

Do ponto de vista do navegador, toda a comunicação acontece dentro do mesmo domínio, eliminando a configuração de CORS, as requisições preflight e vulnerabilidades relacionadas.

Os tokens JWT também ficam completamente ocultos do cliente: eles trafegam somente entre o frontend em Django e a API de backend, armazenados em cookies de sessão HttpOnly — criptografados e inacessíveis via JavaScript. O resultado é uma arquitetura mais simples e segura, com menos pontos de falha.

9. Custos Estimados

Total estimado (uso leve): ~US$44–45/mês | ¹ Base de preço: us-east-1

> Durante o desenvolvimento, uma instância EC2 com OpenVPN foi usada, elevando o custo temporariamente. Esse item foi removido do custo final de produção.

10. Conclusão e Próximos Passos

Esta arquitetura demonstra que é possível construir aplicações AWS seguras, escaláveis e com bom custo-benefício, mesmo em cenários de baixo orçamento.

Com custo médio de ~US$45/mês, o modelo equilibra automação, isolamento de rede e segurança embutida - oferecendo uma base sólida para sistemas de pequeno a médio porte.

Próximos passos recomendados:

• Aprimorar observabilidade com rastreamento distribuído via AWS X-Ray
• Criar painéis de desempenho no CloudWatch
• Automatizar o pipeline de implantação usando CDK Pipelines
• Para escalonamento de dados, considerar réplicas de leitura e sharding no Amazon RDS

Essa combinação consolida uma arquitetura moderna, sustentável e escalável — que pode servir como referência prática para migrações de baixo custo e alto controle.

Nota final: Tudo o que foi descrito aqui não é apenas teórico. Você pode explorar o código-fonte completo neste repositório open source: github.com/Val-Cantarelli/Meta-AWS-Capstone.

Artigo publicado originalmente em Dev.to em 22/10/2025: https://dev.to/vahl/how-small-businesses-can-migrate-to-aws-securely-and-cost-effectively-using-a-hybrid-architecture-56ao