Como sair da AWS sem reescrever toda a stack: guia prático 2026

A maioria dos times brasileiros que pensa em sair da AWS adia indefinidamente porque acredita estar diante de um projeto de "reescrever toda a stack". Não é. É um projeto de mapeamento, não de reescrita. E o mapeamento cabe numa planilha de doze linhas.

TL;DR — o que você vai ler em três minutos

Stack típica de SaaS brasileiro usa cerca de doze serviços AWS, e cada um deles tem alternativa portável que custa entre três e sete vezes menos. EC2 vira VPS em qualquer provedor (Hetzner, DigitalOcean, Magalu Cloud). RDS vira Postgres em VPS dedicado, Neon ou Supabase. ElastiCache vira Valkey auto-hospedado. S3 vira Cloudflare R2 ou Backblaze B2 — ambos com API S3-compatível, então o código nem muda. SQS vira fila baseada em Redis ou RabbitMQ. Lambda vira endpoint no app server tradicional ou Cloudflare Workers. ALB vira o roteador integrado do orquestrador. CloudFront vira Cloudflare grátis. IAM vira injeção de secrets no orquestrador.

Cronograma realista pra startup com cinco a dez aplicações: seis a oito semanas, oitenta a cento e sessenta horas de desenvolvimento. Economia típica: três a sete vezes na conta de infra, com retorno em menos de um mês de salário sênior.

Não migre se o seu compliance exige AWS nominalmente, se o time é único e foca em produto, ou se a stack usa lock-in profundo (DynamoDB com features específicas, Aurora Serverless v2, IAM cross-account complexo).

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Por que tantos times brasileiros adiam a saída da AWS?

A resposta honesta é confusão entre dois projetos diferentes. "Sair da AWS" virou sinônimo mental de "reescrever a aplicação". Não é a mesma coisa.

Reescrever a aplicação é trocar tecnologia central — banco relacional por NoSQL, framework síncrono por reativo, monolito por microsserviços. Isso sim leva trimestres. Sair da AWS é trocar a infra que sustenta a aplicação que você já tem. O código de domínio fica idêntico. Mudam endpoints de banco, credenciais, alguns SDKs e a forma de declarar deploy.

A confusão dura porque o time olha a console da AWS e vê duzentos serviços. Ninguém usa duzentos. A maior parte usa doze. Mapeie esses doze, encontre alternativa pra cada um, e o que resta é trabalho de execução — não de pesquisa.

Os doze serviços AWS que sua stack provavelmente usa

A planilha de início é essa. Tudo o que está fora dela na sua conta provavelmente é satélite — alarme do CloudWatch que ninguém olha, bucket S3 esquecido, função Lambda morta. Foque nos doze:

1. EC2 — máquinas virtuais que rodam app server e workers
2. RDS — banco relacional gerenciado (Postgres ou MySQL)
3. ElastiCache — Redis pra cache e sessão
4. S3 — armazenamento de objetos (uploads, backups, assets)
5. ALB / NLB — balanceador de carga na frente das EC2
6. CloudFront — CDN pra assets estáticos
7. Route 53 — DNS autoritativo
8. SES — email transacional
9. SQS / SNS — fila e pub-sub
10. IAM — credenciais e papéis pra serviços conversarem
11. CloudWatch — métricas e logs
12. Lambda — funções serverless

Se a sua conta tem todos os doze, parabéns: você é a stack mediana. Se tem oito ou nove, melhor — menos coisa pra migrar. Se tem cinco serviços muito específicos (Aurora Global, DynamoDB com Streams, EventBridge complexo), você está num caminho diferente — leia a seção de lock-ins antes de continuar.

Mapeamento serviço por serviço — alternativa, custo e complexidade

A tabela abaixo é o atalho. Cada linha tem detalhe expandido depois.

Câmbio considerado: cinco reais por dólar. Custos de antes assumem stack de SaaS pequeno-médio com cinco a dez aplicações ativas.

EC2 vira VPS em qualquer provedor

A migração mais óbvia. EC2 t3.medium custa cerca de trinta dólares mensais — cento e cinquenta reais. Hetzner CPX21 com a mesma classe de CPU e mais RAM custa sete euros e noventa e nove — quarenta e quatro reais. DigitalOcean fica no meio. Magalu Cloud é competitivo pra quem prioriza fatura em real e dado em território nacional.

O caminho técnico é provisionar a VPS, rodar o seu Ansible existente (ou um script de bootstrap simples), copiar o snapshot da EC2 ou subir a imagem do zero. Pra cada servidor, conte de duas a quatro horas. Não é a parte demorada da migração.

RDS vira Postgres self-hosted ou Neon/Supabase

Aqui há três caminhos honestos. O primeiro é Postgres rodando numa VPS dedicada, com backup automatizado via pg_dump em cron e replicação física pra um secundário em outra região. Custa o preço da VPS — cinquenta a cem reais mensais — pra substituir um RDS de setecentos.

O segundo é Neon. Postgres serverless com branching, ramp-up automático, plano gratuito generoso, planos pagos a partir de cinco dólares. Útil pra quem quer abandonar AWS sem assumir operação direta de banco.

O terceiro é Supabase, que entrega Postgres com APIs adicionais (auth, realtime, storage) e tier gratuito permanente. Faz sentido pra startups que toleram acoplamento ao Supabase em troca de simplicidade.

A migração em si é pg_dump seguido de restore no destino, com janela de manutenção curta — ou replicação lógica com cutover quase sem downtime se o seu Postgres for versão 13 ou superior. Quatro a oito horas dependendo do tamanho da base.

ElastiCache vira Valkey self-hosted

O Redis virou Valkey depois da mudança de licença em 2024 — fork mantido pela Linux Foundation. Roda em qualquer VPS com dois cliques. Trinta reais mensais substituem o ElastiCache de setenta e cinco.

A migração tem duas etapas. Primeiro, levantar o cluster Valkey com Sentinel pra failover automático. Segundo, popular o cache — script que lê da AWS e grava no destino, ou simplesmente deixar a aplicação preencher organicamente após o cutover (cache cold start de poucos minutos). Três a seis horas de trabalho.

S3 vira Cloudflare R2 (ou Backblaze B2)

Esse é o ganho mais imediato. Cloudflare R2 cobra zero pelo egresso — a fatia mais cara do S3 quando você serve assets pra usuários. Quinze centavos de dólar por GB armazenado, contra vinte e três centavos do S3 padrão. Backblaze B2 é uma alternativa quase idêntica, com integração ainda mais barata pra workloads de backup pesado.

A migração técnica é trivial: rclone copy s3:meu-bucket r2:meu-bucket em paralelo. Um terabyte transfere em torno de doze horas dependendo da banda. O código da aplicação muda exatamente uma linha — o endpoint do cliente S3. Toda biblioteca AWS SDK aceita configuração de endpoint custom; R2 e B2 implementam o protocolo S3 idêntico.

Volume típico de SaaS médio (cinquenta GB de uploads de usuário): R$75 mensais em R2 contra R$600 em S3 com egresso ativo. A economia paga uma semana de trabalho de migração no primeiro mês.

ALB vira roteador integrado do orquestrador

Se você está usando ALB, é porque tem várias EC2 atrás dele. A alternativa é o roteador embutido no orquestrador escolhido — HeroCtl, Caddy, ou o roteador embutido em outras stacks self-hosted. O orquestrador descobre os contêineres rodando, abre porta, terminam TLS via Let's Encrypt automático, distribui tráfego.

A migração troca a definição de target group AWS por uma definição de ingress no manifesto do orquestrador. Quatro a oito horas pra entender as regras certas. Cento e dez reais mensais economizados por balanceador, e o orquestrador aceita quantos hosts você quiser sem cobrança adicional.

CloudFront vira Cloudflare grátis

Esse merece uma menção em destaque. CloudFront cobra por GB transferido — quem serve vídeo ou downloads pesados sangra. Cloudflare oferece CDN global gratuita no plano free, com cache configurável, mitigação básica de DDoS e WAF rudimentar. Pra a maior parte dos casos de SaaS, é mais que suficiente.

A migração é trocar os nameservers do domínio pra Cloudflare e configurar regras de cache. Duas a quatro horas. A economia pode ser massiva — quatrocentos reais mensais pra quem tem volume médio de tráfego, milhares pra quem tem volume alto.

Route 53 vira Cloudflare DNS

DNS no Cloudflare é grátis e mais rápido que Route 53 na maioria das medições públicas. Migração é exportar a zone file, importar no Cloudflare, validar registros, mudar nameservers no registrar. Trinta minutos. Vinte e cinco reais mensais que voltam pro caixa.

SES vira Resend, Postmark ou Mailgun

A AWS é barata pra envio em volume, mas a entregabilidade do SES exige aquecimento de IP e configuração de reputação que tira tempo. Resend cobra vinte dólares por cinquenta mil emails mensais e tem entregabilidade superior fora da caixa. Postmark cobra quinze por dez mil. Mailgun cobre o caso de quem manda muito volume não-transacional.

A migração é trocar credenciais SMTP no app — uma hora de trabalho.

SQS e SNS viram Redis Streams ou RabbitMQ

A migração mais delicada. SQS é um serviço que faz uma coisa e faz bem; substituir exige escolher tecnologia de fila e refatorar produtor e consumidor.

O caminho mais curto é Redis Streams, principalmente se você já está rodando Valkey pra cache. Bibliotecas como Sidekiq (Ruby), BullMQ (Node), RQ (Python) e Asynq (Go) consomem Redis nativamente. RabbitMQ é mais robusto pra cenários de roteamento complexo. NATS é alternativa moderna pra pub-sub.

Pra cada fila, conte um a três dias dependendo da complexidade. Filas simples de jobs background são triviais. Filas com fan-out, dead letter queues e visibility timeout customizado exigem mais cuidado. Oitenta reais mensais economizados, e a fila roda na mesma VPS que o cache — zero adicional na infra.

IAM vira secrets do orquestrador

Aqui está a migração não-óbvia que pega muito time desprevenido. Na AWS, a aplicação acessa S3 e RDS sem credenciais explícitas no código — a EC2 herda um IAM role e o SDK busca tokens automaticamente. Fora da AWS, isso desaparece.

A solução é injeção de secrets pelo orquestrador. HeroCtl, k3s e similares aceitam secrets como recursos de primeira classe — você declara DATABASE_URL ou S3_ACCESS_KEY no manifesto do job e o orquestrador injeta como variável de ambiente no contêiner. Pra cenários mais sofisticados, HashiCorp Vault auto-hospedado faz rotação automática.

A migração é refatorar cada papel IAM em um conjunto de credenciais explícitas, criadas no provedor de destino (Cloudflare API token, Postgres user específico, etc), e declaradas como secrets. Quatro a oito horas pra uma stack média.

CloudWatch vira Prometheus + Loki

Métricas viram Prometheus + Grafana. Logs viram Loki + Grafana. Tudo roda em containers na mesma cluster. Duzentos e cinquenta reais mensais de CloudWatch viram zero adicional.

A configuração inicial leva cerca de quatro horas pra ficar produtiva: Prometheus com service discovery apontando pros agentes do orquestrador, Loki recebendo via Promtail ou diretamente do runtime de contêiner, Grafana com dashboards básicos. Há posts dedicados a essa migração no blog.

Lambda — a parte mais difícil

Lambda é o serviço com a maior variância de complexidade na migração. Depende totalmente de como você está usando.

Lambda HTTP simples (API Gateway → Lambda → resposta) é trivial. Vira endpoint no seu app server. O código da função muda pouco — handler do framework no lugar do handler do Lambda. Uma a duas horas por função.

Lambda event-driven (S3 dispara Lambda, SQS dispara Lambda, EventBridge agenda Lambda) é a parte cara. Pra eventos de S3, R2 oferece eventos via Cloudflare Workers — você reescreve a Lambda como Worker e mantém o padrão. Pra SQS, vira consumer no app server. Pra EventBridge agendado, vira cron no orquestrador.

Cenário pior: Lambda complexa com EventBridge, Step Functions e dead letter queues encadeados. Aqui é redesign. Reserve uma semana ou duas e desenhe um modelo de eventos mais simples — geralmente o sistema fica melhor.

Cronograma realista de seis a oito semanas

A ordem importa. Começar pelo banco é tentação e armadilha — banco é o último a migrar, não o primeiro.

Semana 1 — Inventário e decisão. Lista os doze serviços, anota custo atual, identifica integrações entre eles. Escolhe alternativa pra cada um. Documento de uma página com a tabela de mapeamento. Sem código ainda.

Semana 2 — Provisão do destino em paralelo. Levanta as VPS, instala o orquestrador (HeroCtl ou similar), configura DNS de teste apontando pra um subdomínio. Sobe Postgres, Valkey, Cloudflare R2. Tudo vazio. Smoke test: um "hello world" rodando.

Semana 3 — Migração de storage. S3 pra R2 com rclone. Costuma ser lenta (volume) mas baixíssimo risco. Aplicação ainda lê de S3, mas você valida que R2 está sincronizado. No fim da semana, dual-write — aplicação escreve nos dois.

Semana 4 — Migração do banco. Réplica lógica de Postgres do RDS pro destino. Cutover numa janela de manutenção curta — costuma ser minutos, não horas, com replicação lógica funcionando. Aplicação aponta pro novo banco. RDS fica como hot standby por uma semana.

Semana 5 — Migração de aplicações web. Apps que rodam em EC2 viram jobs no orquestrador. Roteador integrado faz o papel do ALB. DNS aponta pro orquestrador (ou pra Cloudflare na frente dele). Cutover gradual usando weighted DNS.

Semana 6 — Filas e jobs assíncronos. SQS sai, Redis Streams ou RabbitMQ entra. Workers rodam no orquestrador. Período de dual-consume pra garantir que nenhuma mensagem cai.

Semana 7 — Lambdas e workloads event-driven. A semana mais variável. Lambdas HTTP migram rapidamente. Lambdas event-driven exigem o redesign discutido acima. Se você tem mais de dez Lambdas complexas, considere estender pra duas semanas.

Semana 8 — Cutover final, monitoramento intensivo, decommission. Cloudflare na frente substitui CloudFront. Route 53 vira Cloudflare DNS. CloudWatch vai pra Prometheus + Loki. Última coisa: desliga as EC2 antigas e fecha a conta AWS — ou deixa um saldo mínimo se você ainda mantém algum serviço residual.

Os cinco lock-ins que mais doem na migração

Honestidade é importante: nem tudo migra fácil. Cinco coisas exigem trabalho extra e às vezes mudam a viabilidade do projeto:

1. DynamoDB com features específicas. GSI, Streams, scan limits, TTL. Não há equivalente direto. O caminho realista é redesenhar pra Postgres com JSONB, ou pra um NoSQL self-hosted (FoundationDB, ScyllaDB) — re-arquitetura, não migração.
2. Aurora-only features. Aurora Serverless v2 com auto-scaling de connections, Aurora Global Database, Aurora I/O optimized. Postgres self-hosted faz quase tudo, mas não tem o auto-scaling instantâneo. Pra workloads spiky, considere Neon (que oferece padrão similar).
3. IAM cross-service complexo. Times que usam IAM roles cross-account, Service Control Policies e organização hierárquica de contas têm controle de acesso embutido na arquitetura. Migrar exige reimplementar a hierarquia em outro lugar — Vault, Cloudflare Access, ou injeção de secrets do orquestrador. Conte dias, não horas.
4. Lambda + EventBridge complexo. Pipelines de eventos com vários hops, retries, dead letter queues. Não migra como está. Redesigne em torno de filas (RabbitMQ, NATS) e workers persistentes. Geralmente o sistema fica mais simples — mas leva tempo.
5. S3 events disparando Lambda. Padrão muito comum, e R2 com Cloudflare Workers cobre a maioria dos casos. Pra workloads que precisam de garantia exatamente-uma-vez ou ordering forte, troque pra padrão de fila — produtor escreve evento na fila quando arquivo é confirmado, worker consome.

A conta de economia, sem otimismo

Cenário típico de SaaS brasileiro com cinco aplicações:

Antes na AWS:

• Cinco EC2 t3.medium: R$750
• RDS db.t4g.large Multi-AZ: R$1.400
• ElastiCache cache.t4g.micro: R$75
• S3 com 100GB e egresso médio: R$300
• ALB: R$110
• CloudFront com volume médio: R$400
• Route 53 + SES: R$75
• CloudWatch logs/métricas: R$250
• Lambda com volume médio: R$200
• NAT Gateway: R$200
• Total: R$3.760/mês = R$45.120/ano

Depois auto-hospedado:

• Quatro VPS Hetzner CPX21 com orquestrador: R$176
• Postgres self-hosted (incluído nas VPS): R$0
• Valkey (incluído): R$0
• Cloudflare R2 50GB com egresso ilimitado: R$75
• Cloudflare CDN + DNS: R$0
• Resend pra email: R$100
• Prometheus + Loki (incluído): R$0
• Workers de fila (incluídos): R$0
• Total: R$351/mês = R$4.212/ano

Economia: R$3.409/mês, R$40.908/ano. Aproximadamente um mês de salário de engenheiro sênior.

A migração consome oitenta a cento e sessenta horas. Em horário de dev sênior interno, são entre dezesseis e trinta e dois mil reais. Retorno em cinco a dez meses, com economia perpétua depois.

A migração mais não-óbvia: secrets e credenciais

Vale repetir, porque é o que mais surpreende time experiente em AWS. Na AWS você acessa S3 sem credentials no código — IAM role da EC2 resolve. Acessa RDS via IAM authentication. Acessa parameter store via IAM. O time perde a noção de que essa "magia" existe.

Fora da AWS, toda credencial é explícita. Aplicação precisa de:

• Access key e secret pra R2 (criada no painel Cloudflare)
• Connection string com user e senha pro Postgres
• URL do Valkey com senha
• API key pra Resend
• Token pra Cloudflare API se você automatiza DNS

A solução do orquestrador é declarar tudo isso como secrets injetados no contêiner como variáveis de ambiente. O secret é criptografado em repouso no orquestrador e nunca aparece nos logs. Pra rotação automática e auditoria sofisticada, Vault auto-hospedado entra na jogada — mas a maioria dos times não precisa.

Plano: faça uma planilha com todas as credenciais que cada app precisa, crie cada uma no provedor de destino, declare como secret no orquestrador, injeta no contêiner. Quatro a oito horas pra uma stack média.

Quando NÃO migrar (perfis honestos)

Quatro situações em que sair da AWS é decisão errada:

Compliance que lista AWS nominalmente. FedRAMP, ITAR, certos contratos de governo americano e algumas certificações financeiras exigem que a infra rode sobre componentes pré-aprovados — e a maioria das listas inclui AWS, GCP, Azure, e poucos provedores adicionais. Se o seu cliente é uma agência federal americana, AWS resolve uma fatia do compliance que custaria meses replicar em outro lugar.

Time único focado em produto. Se você é o único dev e está construindo o produto, oito semanas redirecionadas pra migração matam roadmap. Faça quando tiver o segundo dev, ou quando os custos AWS passarem a representar fatia significativa do MRR. Antes disso, AWS é caro mas comprável.

Custos AWS abaixo de 2% do MRR. Conta de mil reais mensais pra startup que fatura cem mil. A economia é real mas o esforço não vale o foco. Migre quando a fatura passar de cinco a dez por cento do MRR — aí o ganho cobre a oportunidade perdida.

Lock-in profundo em DynamoDB ou Aurora Serverless v2. Já tratado acima. Se metade da sua arquitetura é DynamoDB com Streams, você não migra — re-arquiteta. Esse é projeto diferente, com escopo diferente, decisão diferente.

Estratégia híbrida — alternativa pra quem não quer migrar tudo

Times com cinquenta ou mais aplicações em AWS raramente migram em bloco. A estratégia híbrida funciona melhor:

• Mantém em AWS o que é caro de mover (Aurora com features específicas, Lambda crítica, DynamoDB)
• Move o que é barato de mover e caro de manter (S3 → R2, CloudFront → Cloudflare, EC2 não-críticas → VPS)
• Estabelece VPN ou conexão privada entre as duas pontas
• Economia parcial mas zero risco de migração radical

Resultado típico: corte de quarenta a sessenta por cento da fatura AWS, sem mexer nas peças críticas. Pra empresa que paga cinquenta mil mensais, isso é vinte a trinta mil de volta — e o restante migra organicamente nos doze meses seguintes, conforme times reescrevem componentes por outras razões.

HeroCtl como destino — o que muda na prática

HeroCtl é orquestrador de contêineres que roda em qualquer servidor Linux com Docker. Quatro VPS rodando HeroCtl entregam experiência operacional próxima do que você teria com ECS gerenciado — sem cobrança gerenciada, sem lock-in.

O que substitui:

• ALB vira o roteador integrado do HeroCtl, com TLS Let's Encrypt automático
• CloudWatch parcial vira métricas embutidas e logs centralizados nativos
• RDS automated backups vira backup gerenciado no Business Edition
• IAM roles em apps vira injeção de secrets no manifesto de job

O que continua igual: Docker rodando seu app exatamente como roda em ECS. Variáveis de ambiente, healthchecks, rolling deploys, multi-replicas. A aplicação não percebe a diferença.

Há três planos. Community é gratuito permanente, sem limite de servidores ou jobs — roda toda a stack descrita acima incluindo alta disponibilidade real, roteador, certificados, métricas e logs. Business adiciona SSO, RBAC granular, auditoria detalhada, backup gerenciado e suporte com SLA — útil pra quem já tem requisitos formais de plataforma. Enterprise adiciona escrow de código-fonte, suporte 24×7 e desenvolvimento dedicado. Os preços de Business e Enterprise estão publicados na página de planos, sem "fale com vendas" obrigatório.

O cluster público de demonstração roda em quatro servidores e a eleição de coordenador acontece em cerca de sete segundos quando o nó atual cai — número medido, não estimado.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Perguntas que a gente recebe sobre saída da AWS

Quanto tempo realmente leva migrar uma stack média?

Pra startup com cinco a dez aplicações, sem lock-ins profundos: seis a oito semanas com um dev sênior dedicando meio tempo, ou três a quatro semanas com dedicação total. Stacks maiores ou com Lambdas event-driven complexas: três a quatro meses. Stacks com DynamoDB ou Aurora Serverless v2 críticos: vire projeto de re-arquitetura, prazo de seis meses ou mais.

DynamoDB tem alternativa boa?

Não há substituto idêntico. As opções honestas são: Postgres com JSONB pra a maioria dos casos (resolve oitenta por cento dos usos de DynamoDB com performance excelente), ScyllaDB ou Cassandra self-hosted pra workloads que realmente precisam de NoSQL distribuído, FoundationDB pra quem precisa de transações distribuídas. Nenhum desses é "mude a connection string e pronto" — exigem mudança no modelo de dados.

Posso manter AWS pro banco e mover compute?

Sim, e é a estratégia híbrida mais comum. Aurora ou RDS continua na AWS, EC2 viram VPS Hetzner ou DigitalOcean, S3 vira R2. Você abre VPN entre as duas pontas e o app continua acessando RDS via endpoint privado. Economia tipicamente de cinquenta a setenta por cento da fatura AWS.

S3 → R2: quanto custa transferir 1TB?

R2 cobra zero de ingresso. AWS cobra a saída de S3 — aproximadamente nove centavos de dólar por GB nos primeiros 10 TB. Um terabyte custa cerca de noventa dólares pra sair da AWS, R$450. Tempo de transferência: doze a vinte e quatro horas com rclone paralelizado, dependendo da banda. Após a migração, R$75 mensais armazenando 50GB com egresso ilimitado, contra R$600 pelo mesmo no S3 com tráfego ativo.

Lambda — como migrar event-driven?

Depende do disparador. S3 disparando Lambda vira R2 com Cloudflare Workers (mesmo padrão, sem mudança radical). SQS disparando Lambda vira worker persistente no app server, consumindo da fila — geralmente código mais simples que a Lambda original. EventBridge agendado vira cron no orquestrador. EventBridge com regras complexas e Step Functions encadeados exige redesign — desenhe o fluxo em torno de uma fila central com workers consumidores, fica mais auditável.

RDS Multi-AZ → Postgres self-hosted é confiável?

Postgres com replicação física streaming e failover via Patroni atinge confiabilidade próxima do RDS Multi-AZ — desde que o time saiba operar. Se ninguém na equipe domina Postgres em produção, o caminho mais seguro é Neon ou Supabase, que entregam Postgres gerenciado com tier gratuito. Pra times com SRE ou DBA, self-hosted é viável e economiza substancial. Pra times sem essa competência, a economia não compensa o risco — pague pelo gerenciado.

Email SES → quem é mais barato?

Depende do volume. Até 10 mil emails mensais, Postmark a US$15 entrega muito mais (entregabilidade superior, dashboard melhor, suporte responsivo). Entre 50 mil e 100 mil mensais, Resend a US$20 é o melhor custo-benefício. Acima de 500 mil mensais, Mailgun ou Amazon SES competem em preço — e SES talvez faça sentido manter mesmo após migrar o resto. Email é dos poucos serviços AWS que pode ser racional manter.

DNS — tudo Cloudflare ou misturar?

Cloudflare resolve DNS, CDN, DDoS, WAF e workers no plano grátis. Pra a maioria das stacks, concentrar tudo lá simplifica operação e corta custo. A exceção é compliance que exige separação geográfica de provedor — alguns frameworks de governança pedem que DNS e CDN sejam de fornecedores distintos. Nesse caso, Cloudflare DNS + Bunny CDN (ou Fastly) cumpre a separação.

Compliance LGPD muda algo?

LGPD não exige hospedagem em território brasileiro. Exige que você saiba onde os dados estão e que tenha contrato adequado com o operador. Hetzner (Alemanha), DigitalOcean (várias regiões), Cloudflare R2 (multi-região) e Magalu Cloud (Brasil) são todos compatíveis com LGPD desde que o contrato esteja em ordem. Pra quem prefere dado em território nacional por preferência de cliente, Magalu Cloud é a alternativa direta.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Próximo passo concreto

Se você chegou até aqui, o próximo passo é a planilha. Lista os doze serviços, marca quais sua stack usa, anota custo atual de cada um, escolhe alternativa. Em uma tarde você sabe se a migração vale o esforço.

Quando estiver pronto pra provisionar o destino:

curl -sSL get.heroctl.com/install.sh | sh

Roda em qualquer servidor Linux com Docker. Os primeiros três viram quórum pro plano de controle replicado. Você submete jobs via CLI, API ou painel web embutido. O cluster decide onde rodar, faz health check, gerencia rolling deploys, emite certificados Let's Encrypt automaticamente.

Pra contexto adicional sobre custos e arquitetura, leia também AWS ECS vs Kubernetes vs auto-hospedado e Quanto custa hospedar SaaS brasileiro em 2026.

A migração é mais aborrecida do que difícil. O difícil é decidir começar.