Por que o Signal usa a AWS

Quando a AWS caiu e o Signal foi arrastado junto, sobrou tweet ácido — inclusive de quem adoraria ver tudo fora das mãos dos “hyperscalers”. Mas a pergunta real não é uma cutucada moral: por que o Signal usa a AWS em vez de rodar sua própria infraestrutura?

Se você acha que é só escolha estratégica ou “falta de coragem”, respira fundo. A resposta tem menos a ver com preferência e mais com física, economia e escala — e é exatamente o tipo de debate que fervilha lá na comunidade Inteligência Artificial com Propósito (IAp).

O que é isso na prática?

Signal é um app de comunicação em tempo real: mensagens, chamadas de voz e vídeo, e tudo isso em grande escala. Para manter baixa latência e alta disponibilidade global, é preciso uma malha mundial de servidores, armazenamento e pontos de presença na borda (edge) — com monitoramento 24/7 e energia elétrica dedicada.

“O problema aqui não é que Signal ‘escolheu’ rodar na AWS… o problema é a concentração de poder no espaço de infraestrutura que faz parecer que não há outra escolha.” — Meredith Whittaker

Tradução: existem apenas alguns provedores com rede planetária pronta para isso — e montar uma do zero custa bilhões e anos. Por isso o Signal recorre a AWS, Azure ou Google Cloud — os únicos players que entregam essa escala sem que você vire uma operadora de data centers.

Por que isso importa agora?

• Risco sistêmico: quando poucos controlam o “nervosismo” da internet, uma falha atinge milhões de serviços.
• Privacidade vs. dependência: usar AWS não significa que suas mensagens são lidas pela Amazon — Signal usa criptografia ponta a ponta — mas existe uma dependência operacional real.
• Decisões políticas e comerciais: quando o chão é pequeno, qualquer movimento de um desses provedores impacta comunicação global, serviços públicos e empresas.

O que tecnicamente impede o Signal de “rodar sozinho”?

1. Escala — milhões de usuários simultâneos em chamadas/streams exigem rede distribuída e balanceamento em múltiplas regiões.
2. Latência — para voz e vídeo, cada milissegundo conta; servidores centralizados aumentam jitter e quedas de chamada.
3. Custo inicial — construir backbones, pontos de presença e redundância é investimento de bilhão, sem falar em operação contínua.
4. Expertise operacional — monitoramento global, mitigação de DDoS, atualizações seguras: é uma operação 24/7 que demanda times maduros.

O que ninguém te contou

Existem alternativas — multi-cloud, edge providers, clouds soberanas — mas todas têm trade-offs. Multi-cloud reduz risco de um único ponto de falha, porém aumenta complexidade, custo e latência operacional. Clouds soberanas podem ajudar na jurisdição, mas não substituem a presença de rede global dos hyperscalers.

Como começar? (para quem decide infra de comunicação)

• Mapeie requisitos: latência máxima aceitável, locais críticos, picos de tráfego.
• Considere híbrido: use um hyperscaler para backbone e players locais/edge para pontos críticos.
• Planeje tolerância a falhas: failover automático entre provedores e testes regulares de DR (disaster recovery).
• Implemente criptografia ponta a ponta — assim mesmo que a infraestrutura caia ou seja alvo de auditoria, os conteúdos ficam protegidos.


# exemplo rápido para testar conectividade HTTP/HTTPS
curl -I https://signal.org


Erros comuns

• Achar que criptografia elimina dependência de infraestrutura. Protege conteúdo, não conectividade.
• Subestimar custo operacional de multi-cloud; raramente é “mais barato”.
• Ignorar monitoramento de latência global — você verá problemas apenas quando usuários começarem a reclamar.

Dica extra do Prof. Leandro de Jesus

Não pense em migração como “trocar o provedor”. Pense em arquitetura por camadas: borda/edge, roteamento geográfico, orquestração entre provedores e um plano claro de rollback. É esse tipo de blueprint que a galera ensina e debate nos cursos e hacks da comunidade Inteligência Artificial com Propósito (IAp).

Alternativas reais — e quando elas funcionam

• Multi-cloud controlada: bom para reduzir risco, requer automação avançada.
• Edge + CDN: efetivo para reduzir latência em streaming e partes estáticas da aplicação.
• Clouds regionais/sovereign clouds: úteis para requisitos legais/jurisdicionais, mas não substituem presença global.

Conclusão: a resposta a “por que o Signal usa a AWS” não é vergonha nem traição — é pragmatismo. Para uma plataforma global, em tempo real e com forte compromisso de privacidade, há um jogo de trade-offs. Você protege conteúdo com criptografia, mas depende de infraestrutura para conectar pessoas.

E aí, vai continuar fazendo tudo no braço ou quer entender como montar uma arquitetura que equilibra privacidade, resiliência e custo? Vem discutir isso com a gente na comunidade Inteligência Artificial com Propósito (IAp) — tem curso, debate e hacks práticos que ensinam exatamente como lidar com esses dilemas. Conheça as aulas: https://comunidade.leandrodejesus.com.br/aulas