Sobre AWS/Cloudflare, centralização da web e brio

Publicado em Maio 2, 2026

Esse post vai ser só uma reclamação sem solução real, mas vale como registro próprio da percepção do nosso tempo. Esteja avisado.

Em outubro/2025, a principal área da AWS ficou offline por conta de um problema de DNS no DynamoDB. Em novembro/2025, a Cloudflare ficou fora devido a um problema de mudança de comportamento de query e um código sem proteção suficiente. Em ambos os casos, “a internet”, essa entidade metafísica, sofreu com muitos serviços ficando offline ou inoperáveis. Sites fora do ar, redes sociais caíram, aplicativos sem funcionar… você sabe como é.

E a reação geral foi um grande “meh, faz parte”. A percepção da comunidade é que são ossos do ofício, e que o preço a se pagar pelas facilidades que esses serviços trazem é aceitar esse 0.01% de indisponibilidade e cruzar os braços quando ocorre.

Eu fico triste nesse posicionamento.

O racional

O argumento prático é sempre o mesmo: sua aplicação foi construída para a cloud, então não tem muito o que fazer caso “a cloud” esteja fora do ar. Nem há tanto impacto, porque, se “a cloud” está fora do ar, provavelmente seus clientes também estão, já que eles também estão na ““cloud””. A disponibilidade está dentro do SLA contratado, e você já até previu isso em contrato, então tudo bem. O sistema está fora, mas dentro de “limites aceitáveis”. Faz parte de usar a “““cloud”””.

O argumento financeiro para essa situação também é conhecido. Não faz sentido você pensar em multi-cloud/multi-region para sua aplicação que não é de missão crítica. O custo de fazer isso e manter a sincronização entre as diferentes áreas ou provedores é proibitivo, e muitas vezes superam o resultado financeiro, então não faz sentido ter algum tipo de fallback.

Mas esse é um lugar amargo e frágil.

A fragilidade

Se a cloud provider demorar cinco dias para voltar para o ar, eu devo esperar esses cinco dias? Se começarem a aumentar o preço eu tenho que comer a minha margem e aceitar esse aumento? Que alternativas eu tenho na minha aplicação “cloud first” quando as coisas dão errado? E, se eu não tenho alternativas, vale a pena questionar quem nessa situação está se beneficiando.

E outra, a economia que cloud leva ao desenvolvimento é tão real assim? Como podemos medir isso? Se voce usar os serviços da cloud, o resultado final do sistema vai ser diferente do que seria num ambiente on-premise (isso é esperado), então quanto essa flexibilidade é de fato real, e quanto é apenas uma forma diferente de ver uma dependência nova?

“Mas para um evento de grande tráfego em um curto espaço de tempo, a escababilidade infinita da cloud é imbatível”. Você tem razão. Mas sabe o que não é infinito? O seu bolso. As vezes é bom você ver e sentir onde sua aplicação está engargalando para poder tomar uma decisão consciente em cima de restrições reais e casos reais.

Ou, se a sua aplicação é como a média das aplicações cloud por aí, seu banco de dados ainda vai ser o gargalo quando o spike vier. Você não percebeu isso porque seu sistema ainda não sofreu pressão real.

Onde estamos ganhando ao colocar tudo e todos os sistemas do mundo em um lugar só?

Não sou contra construir sistemas em cloud. Já construi e continuo construindo em cloud em diversos cenários e sei dos benefícios. Não sou contra a Cloudflare, visto que até esse blog está atrás do proxy da Cloudflare, sei que resolve um problema sério e real de uma forma elegante. Mas há custos e envolvidos não óbvios nessas escolhas, e não é fingindo que está tudo bem que tudo fica automaticamente bem.

A internet é um lugar muito mais centralizado hoje do que era antes, tanto sobre os sites que visitamos, quanto onde disponibilizamos nossas coisas.

E nós estamos vendo isso como um trade-off aceitável.