Uma transferência de energia em São Paulo testa o que o mapa anycast da Cloudflare na América Latina não pode prometer

Resumo

• A Cloudflare divulga uma ampla presença em cidades latino-americanas e 500 Tbps de interconexão externa global, mas não publica a quantidade de servidores, energia contratada, folga de portas ou rotas fisicamente diversas disponíveis em cada site latino-americano.
• Registros públicos estabelecem uma empresa costarriquenha, recursos de endereço na Costa Rica e uma implantação em San José associada à NIC.CR, mas não estabelecem que a empresa costarriquenha possui ou contrata cada rack regional, circuito ou relacionamento com clientes que carrega o nome Cloudflare.
• Anycast pode mover a alcançabilidade para longe de um local com falha, mas a recuperação bem-sucedida ainda depende de capacidade computacional e de rede sobressalente, energia independente do local, fibra metropolitana sobrevivente, cross-connects funcionando e pessoas autorizadas a restaurar o equipamento afetado.

A chave de transferência é onde o mapa para

Considere uma instalação neutra de operadoras na região metropolitana de São Paulo durante uma transferência elétrica programada. A alimentação da concessionária é removida do serviço, a energia ininterrupta sustenta a carga no intervalo entre as alimentações, e geradores ou um segundo caminho de concessionária devem assumir. Um técnico observa a distribuição de energia do rack e os cross-connects ópticos enquanto engenheiros de rede monitoram as rotas. Este é um caso de estresse, não um relato de um acidente específico da Cloudflare. É útil porque elimina a facilidade visual de um mapa global de borda.

No instante da transferência, as perguntas relevantes são concretas: quais gabinetes permaneceram energizados, quais roteadores mantiveram luz, quais peers permaneceram alcançáveis e quanto trabalho poderia ser aceito em outro lugar?

Os próprios avisos operacionais da Cloudflare revelam a resposta de rede pretendida. Durante um trabalho programado em sua localização GRU em 3 de julho de 2026, a empresa avisou que o tráfego poderia ser redirecionado, os usuários finais poderiam ver um ligeiro aumento na latência e as interfaces de interconexão privada ou de clientes nesse data center poderiam ficar temporariamente indisponíveis. O aviso posteriormente marcou o trabalho como concluído. Essa sequência é visível noregistro de manutenção de GRU. É uma evidência estreita: mostra uma janela de manutenção anunciada e o comportamento esperado das interfaces, não a identidade de um edifício, o motivo do trabalho, uma mudança medida de tráfego ou a quantidade de capacidade reserva usada em outro lugar.

Apágina de status públicomais ampla separa locais latino-americanos como San José e São Paulo em componentes nomeados e dá a cada um uma condição atual. Isso é uma visibilidade operacional valiosa, mas um componente verde é um instantâneo. Não revela se o componente representa uma sala ou várias, se duas salas compartilham uma subestação ou se um vizinho nominalmente disponível poderia aceitar uma carga regional súbita. Tampouco identifica qual empresa legal comprou a energia, alugou o rack ou assinou o pedido de cross-connect.

A intuição normal é que anycast resolve o problema de localização. Aexplicação da Cloudflare sobre anycastdiz que o mesmo endereço pode ser servido de vários locais e que tirar um data center offline pode fazer o tráfego fluir para um próximo. Isso descreve alcançabilidade. Não fabrica watts, ciclos de servidor ou portas descongestionadas no local receptor. Se São Paulo retirar rotas, os usuários podem cair no Rio de Janeiro, Curitiba, Porto Alegre, Buenos Aires, Santiago, Bogotá, Miami ou outro local disponível, dependendo das rotas que seus provedores de acesso selecionarem. Cada alternativa adiciona suas próprias condições de instalação, operadora e capacidade.

A transferência de energia, portanto, testa dois sistemas ao mesmo tempo. O primeiro é local: alimentações da concessionária, chaves, baterias, geradores, refrigeração, distribuição do rack, roteadores e cross-connects devem permanecer dentro das tolerâncias. O segundo é regional: as mudanças de rota devem se propagar limpidamente e os destinos que ganham tráfego devem ter folga utilizável. Um mapa de cidades não representa nenhum dos sistemas nessa resolução. Mostra geografia de serviço, não as dependências elétricas e comerciais que determinam se o failover é gracioso.

A lacuna importa porque os clientes experimentam o resultado como um serviço único, mesmo quando a responsabilidade física é dividida entre Cloudflare, operadores de instalações, operadoras, exchanges e contratados no local.

Um ponto de cidade não é um domínio de falha

Apágina de rede atualda Cloudflare apresenta uma grande presença latino-americana, com dezenas de cidades no Brasil e locais de San José a Bogotá, Lima, Santiago, Buenos Aires e além. A página também diz que todo serviço roda em todo data center. Essas afirmações estabelecem a amplitude pretendida da borda e o design de serviço comum. Não estabelecem que toda cidade contém o mesmo número ou geração de servidores, o mesmo número de upstreams, a mesma capacidade de receber tráfego de outra cidade ou a mesma proteção contra um evento de energia local.

A própria Cloudflare explicou por que a cidade é uma unidade muito grosseira. Em um relato de 2019 sobreescalar sua rede global, a empresa disse que uma cidade poderia conter até cinco implantações distintas. Também descreveu o planejamento de capacidade por endereço, não apenas por cidade, e descreveu o uso de fornecedores e mãos remotas no local para instalar servidores e cabear. A divulgação foi histórica e global; não é um censo atual da América Latina. Seu valor analítico contínuo é a distinção que faz: um rótulo de metrópole pode esconder vários endereços físicos, enquanto uma implantação em cidade pequena pode estar incorporada dentro de um provedor de serviços de internet em vez de um grande campus neutro.

A divulgação anual mais recente da empresa fornece a outra metade do limite. OFormulário 10-K de 2025da Cloudflare diz que sua rede estava hospedada em instalações de parceiros de colocation e provedores de serviços de internet em mais de 330 cidades e mais de 125 países no final de 2025. Diz que a Cloudflare tem acesso eletrônico e, em menor grau, físico a equipamentos hospedados por terceiros, mas não controla a operação dessas instalações. O mesmo arquivamento identifica perda de energia, decisões de operadoras, fechamentos de instalações, erro humano e limites de largura de banda como riscos. Esses não são enfeites teóricos em torno de um ponto; são o limite operacional do ponto.

A amplitude também vem em diferentes formas físicas. Um relato de expansão de 2023 disse que a Cloudflare havia alcançado mais de 300 cidades e descreveu um novo site em Campos dos Goytacazes, Brasil, interconectado com um provedor regional atendendo mais de 100 provedores de serviços de internet locais. A empresa relatou que as medições de latência melhoraram materialmente após a abertura do site. Esserelato de expansão de cidadesapoia a presença de uma borda liderada por parceiros perto dos usuários. Não divulga energia do rack, quantidade de servidores, utilização de portas ou a rota que carregaria a carga se o site parceiro falhasse.

Um domínio de falha útil deve ser desenhado em torno de dependências compartilhadas. Duas implantações em endereços diferentes podem ainda depender da mesma subestação da concessionária, duto de operadora, tecido de exchange, saída de longa distância ou fornecedor de suporte local. Por outro lado, dois gabinetes em um grande campus podem ter trilhas de energia significativamente separadas e entradas de fibra diversas. Listas públicas de cidades não resolvem nenhum dos casos.

Mesmo uma instalação nomeada não prova que dois circuitos de um cliente específico terminam em dispositivos separados ou que existe capacidade reservada por trás de cada um.

É por isso que uma contagem de cidades não é uma contagem de opções independentes de recuperação. É uma medida de alcance geográfico. Para convertê-la em uma afirmação de resiliência, um leitor precisaria do número de sites ativos por metrópole, sua correlação de energia e fibra, as cargas de trabalho habilitadas em cada um, a utilização normal e de emergência de cada porta e a política para retirar ou restaurar rotas. Nenhum desses itens pode ser inferido simplesmente porque São Paulo, San José e Bogotá aparecem no mesmo mapa.

A empresa costarriquenha é um limite, não um rótulo de ativo regional

CloudFlare Latin America S.R.L é uma presença legal costarriquenha real, não um apelido geográfico. O diário oficial da Costa Rica registrou uma ação corporativa de janeiro de 2026 por "Cloudflare Latin America S.R.L." e deu o número de pessoa jurídica 3-102-651761. O aviso dizia respeito ao seu endereço eletrônico oficial e representação residente, não a ativos de rede, mas aentrada do diárioé uma evidência pública recente de que a empresa existe dentro do sistema corporativo da Costa Rica.

Registros de números de internet fornecem uma ligação separada. Oregistro público da LACNIC para 190.93.240.0/20nomeia CloudFlare Latin America S.R.L como o registrante e dá um endereço na área de San José, enquanto contatos operacionais apontam para as operações de rede da Cloudflare em São Francisco. Isso apoia uma relação entre a empresa costarriquenha e recursos de endereço usados sob a operação mais ampla da Cloudflare. Não prova que todo endereço é servido apenas na Costa Rica. Anycast deliberadamente permite que os mesmos endereços de serviço sejam anunciados de múltiplos lugares, e um registro de endereço não é um inventário de racks ou documento de título.

A superfície do contrato com o cliente aponta em uma direção diferente. OAcordo de Assinatura Empresarialpadrão da Cloudflare afirma que o acordo público é entre o cliente e a Cloudflare, Inc., uma empresa de Delaware. Também permite uso de afiliadas e formulários de pedido separados de afiliadas. A conclusão correta é limitada: os termos públicos padrão não atribuem assinaturas empresariais ordinárias à empresa costarriquenha. Eles não descartam um formulário de pedido diferente, acordo fiscal local, contrato de locação, contrato de trabalho, acordo de operadora ou transação de afiliada. Esses documentos não são públicos no material revisado aqui.

A mesma cautela se aplica em toda a América Latina. Um rack com a marca Cloudflare no Brasil pode ser propriedade da Cloudflare, Inc., de outra afiliada, de um parceiro de serviço ou de uma contraparte de hospedagem sob termos não visíveis para estranhos. A empresa costarriquenha pode deter recursos de número específicos ou obrigações locais sem ser a parte contratante de uma sala em São Paulo. Por outro lado, a ausência de seu nome de uma página de instalação não mostraria que ela não tem papel financeiro ou operacional.

Registros públicos de instalações e roteamento normalmente identificam a rede ou a marca, não a alocação interna de direitos entre afiliadas.

Esse limite importa durante uma falha. A parte que pode pedir a uma operadora para testar níveis de luz, autorizar uma visita de mãos remotas, aprovar gastos de emergência ou fazer cumprir um compromisso de serviço pode não ser a mesma parte nomeada em um registro público de IP. Demandas regulatórias também podem se prender à empresa local mesmo quando decisões operacionais são tomadas em outro lugar. Sem contratos, registros de conselho ou divulgações explícitas de afiliadas, atribuir controle regional à CloudFlare Latin America S.R.L iria além das evidências.

A descrição mais defensável é, portanto, em camadas. Cloudflare, Inc. relata a rede global consolidada e suas dependências de instalações de terceiros. AS13335 é a identidade de roteamento global. CloudFlare Latin America S.R.L é uma empresa costarriquenha associada a recursos da LACNIC e a um registro legal costarriquenho atual. NIC.CR foi nomeada como a parceira para a primeira implantação em San José. Essas camadas claramente se relacionam a um serviço, mas não são intercambiáveis.

Uma história de borda regional que as colapsa em "a empresa costarriquenha opera a América Latina" transformaria associação em propriedade e propriedade em controle sem prova pública.

San José prova presença, não controle

A Cloudflare anunciou sua primeira implantação na Costa Rica em junho de 2021. Seurelato de expansão de San Josédisse que o local foi estabelecido com a NIC.CR, operada pela Academia Nacional de Ciências. Esta é uma evidência direta da empresa para uma presença implantada e um parceiro local nomeado na época. O mapa de rede atual e o componente de status indicam que San José permanece representado na pegada ativa. Nenhuma das divulgações nomeia o edifício, a quantidade de servidores, a alocação de energia, a lista de operadoras, o estoque de peças de reposição ou o proprietário contratual do equipamento.

A NIC Costa Rica descreve o CRIX como um exchange de internet neutro que permite que redes locais troquem tráfego em um ponto comum dentro do país em vez de depender de links internacionais. Essadescrição de infraestrutura da NIC.CRestabelece por que uma borda em San José pode importar: o peering local pode manter parte do tráfego costarriquenho local, reduzir a dependência de trânsito internacional para esse exchange e diminuir a distância para conteúdo armazenado em cache ou processado. Não estabelece o tamanho atual da porta da Cloudflare ou se todo provedor de acesso costarriquenho alcança a Cloudflare através do CRIX.

Oregistro de rede PeeringDBauto-relatado atual da Cloudflare identifica AS13335 como uma rede anycast global e lista suas relações de peering público e instalação. O registro inclui uma conexão CRIX operacional e relata uma porta de exchange de 200 Gbps para essa entrada no momento examinado. PeeringDB é uma evidência operacional importante porque a Cloudflare diz usar o serviço para provisionamento de peering. No entanto, seus valores permanecem auto-relatados e mutáveis. Uma velocidade de porta listada é a taxa nominal da interface, não o tráfego observado, a capacidade contratada, a capacidade sobressalente ou a prova de uma segunda porta fisicamente diversa.

Isso produz uma imagem precisa mas modesta de San José. Há uma presença na cidade anunciada com a NIC.CR, um componente de status atual, uma conexão pública de exchange e recursos de endereço registrados para a empresa costarriquenha. Não há endereço de instalação público nessas fontes. Não há contagem divulgada de implantações independentes dentro da metrópole. Não há diagrama unifilar de energia, figura de autonomia de gerador vinculada aos gabinetes da Cloudflare ou declaração de diversidade de rota mostrando entradas de fibra separadas ou caminhos upstream.

A distinção entre localidade e controle é especialmente importante aqui. O CRIX pode localizar tráfego entre redes conectadas, mas o próprio tecido do exchange se torna um elemento do caminho de serviço. Um cross-connect do roteador da Cloudflare para o exchange pode falhar enquanto os servidores permanecem energizados. A borda também pode permanecer alcançável através de trânsito enquanto uma sessão de peering local está inativa, ao custo de um caminho mais longo. Uma instalação pode permanecer operacional enquanto uma operadora sofre um corte metropolitano.

Um componente de cidade pode, portanto, ser degradado de várias maneiras que um ponto de cidade binário não pode descrever.

San José também não pode representar a rede regional. Mesmo que seu tráfego local seja pequeno o suficiente para uma porta de exchange e uma implantação, isso não diz nada sobre a capacidade de absorver tráfego da Guatemala, Panamá, norte da América do Sul ou Brasil. A ausência de uma série publicada de servidores e utilização impede uma comparação entre hardware instalado e folga de emergência.

A interface de exchange visível de 200 Gbps não deve ser adicionada às figuras de capacidade global como se fosse uma reserva independentemente utilizável; é uma interface em um conjunto maior de conexões de trânsito, privadas e públicas, e sua demanda ao vivo não é divulgada.

O que San José prova é significativo: a Cloudflare aproximou o serviço dos usuários costarriquenhos e estabeleceu uma relação de interconexão local. O que deixa sem resposta é a pergunta no título deste artigo. Quando uma metrópole latino-americana maior perde energia ou retira rotas, o registro público não mostra quanto tráfego San José poderia receber, quais aplicações poderia processar sob configurações de localidade do cliente ou qual empresa dirigiria a recuperação física.

São Paulo são várias salas, portas e dependências comerciais

São Paulo é a ilustração pública mais forte de por que um rótulo de cidade pode esconder várias superfícies operacionais distintas. O registro PeeringDB da Cloudflare lista a rede na Equinix SP2 e SP4 em Barueri, na Ascenty SPO02 e SPO03 em Osasco e na Elea SPO1 em São Paulo. Este não é necessariamente um inventário completo ao vivo, e uma listagem de instalação não revela quanto equipamento está ativo lá. Mostra que a metrópole não pode ser tratada responsavelmente como uma única sala.

Alista de locais de interconexão de clientesda Cloudflare de maio de 2026 torna a multiplicidade ainda mais explícita. Ela nomeia várias instalações em São Paulo para interconexão de clientes, incluindo Equinix SP2 e SP4, Ascenty SPO02 e SPO03, e Elea SPO1. O documento é uma lista de locais de serviço, não um mapa da borda ou backbone interno da empresa. Mostra onde uma conexão de cliente pode terminar; não mostra que todo site listado tem computação de borda idêntica, que conexões em dois edifícios usam rotas de operadora separadas ou que todo local pode substituir qualquer outro.

Divulgações de instalações adicionam contexto físico sem fechar a lacuna específica da Cloudflare. A Equinix diz que oSP4tem redundância UPS e gerador N+1, pelo menos 30 horas de autonomia de gerador em plena carga, refrigeração N+1 e serviços de mãos inteligentes. Essas são especificações do operador para o edifício. Não revelam qual trilha de energia alimenta a Cloudflare, a carga de seus gabinetes, o estado de manutenção de um componente particular, a quantidade de combustível presente em um dado dia ou se um circuito da Cloudflare cruza um ponto compartilhado antes de entrar na instalação.

O aviso de manutenção de GRU fornece uma pista comportamental ao vivo. Tratou o local de São Paulo como um componente do qual tráfego e interfaces privadas poderiam falhar. Não identificou qual dos vários edifícios estava envolvido. "GRU" pode representar um agrupamento operacional maior do que uma instalação, ou o aviso pode abstrair deliberadamente o detalhe da instalação. De qualquer forma, o rótulo do componente não deve ser lido como um endereço físico.

A diversidade metropolitana só ajuda quando as dependências são genuinamente independentes. SP2 e SP4 podem ser instalações separadas, mas os caminhos decisivos incluem fornecimento da concessionária, trilhas de gerador e UPS, salas de meet-me, dutos, anéis de operadora, tecidos de exchange e as saídas de backbone que conectam a metrópole a outras cidades. Duas interconexões de cliente pedidas em dois edifícios ainda podem convergir em uma rota de operadora. Duas implantações da Cloudflare ainda podem compartilhar autoridade de mudança ou uma dependência de controle regional. Nenhuma das fontes públicas mapeia essas correlações.

A concentração comercial adiciona outra camada. O 10-K diz que um número significativo de acordos importantes de colocation é com uma empresa não nomeada. A Equinix é visível na lista pública de instalações de São Paulo, mas o arquivamento não identifica o provedor concentrado, e seria sem suporte assumir o nome. O ponto relevante é que a distribuição física entre cidades ou salas não remove automaticamente a concentração contratual. Uma disputa com fornecedor, falha de suporte ou mudança adversa de preço pode afetar escolhas de expansão e restauração mesmo quando a rede permanece tecnicamente roteável.

São Paulo é, portanto, melhor descrita como uma metrópole com várias opções de interconexão e instalação publicamente visíveis, não como um pool quantificado de capacidade intercambiável. As evidências apoiam mais do que um ponto, mas menos do que um diagrama de resiliência. Mostram salas e serviços que poderiam participar da diversidade; não provam a independência, alocação ou capacidade de emergência necessária para que o façam.

Peering localiza tráfego, mas pode concentrar a metrópole

Apolítica de peeringde dezembro de 2025 da Cloudflare diz que AS13335 abrange mais de 335 cidades, pede que peers estabeleçam sessões em todos os locais mútuos e apoia interconexões privadas em múltiplos de 100 Gbps para redes acima de um limite de tráfego. Também recomenda usar todos os endereços disponíveis quando mais de um está presente em um exchange. Essas práticas podem melhorar a diversidade de caminhos e facilitar a movimentação de tráfego entre portas. Continuam sendo condições de política, não prova de que um peer latino-americano específico pediu cross-connects diversos ou manteve capacidade não utilizada suficiente.

A expansão histórica mostra como os arranjos locais podem ser diferentes. Em Medellín, a Cloudflare disse que seu lançamento em 2014 dependia da Internexa e que o serviço local era transportado sobre a rede terrestre da parceira. Oanúncio de Medellíndescreveu uma importante vantagem de alcance, mas também torna a dependência visível: a localidade do tráfego estava ligada ao backbone de um parceiro. A rede atual pode ser mais ampla; o relato antigo não pode ser tratado como uma topologia atual.

Em Quito, a empresa disse que seu site de 2017 foi possível através do exchange NAP.EC e que peers locais adicionais poderiam deslocar tráfego que antes era servido de Miami. Orelato de Quitodemonstra o valor de um exchange local e a dependência anterior de um hub no exterior. Novamente, não mostra os racks, portas ou destinos de fallback de hoje. Também ilustra que "local" é relacional: uma implantação é local apenas para redes que podem alcançá-la através de rotas aceitáveis.

Bogotá começou com outro arranjo físico divulgado. Orelato de Bogotá de 2018da Cloudflare disse que a implantação estava em uma instalação Tier III na zona franca da cidade. Registros públicos atuais listam a Cloudflare na Equinix BG2, mas a descrição histórica não nomeia esse site, então os dois registros não podem ser unidos em uma história contínua de instalação sem mais evidências. O que se pode dizer é que Bogotá teve uma presença física divulgada e agora tem uma listagem de instalação atual.

O caminho de longa distância entre essas metrópoles é igualmente importante. A Cloudflare diz que seu backbone usa fibra escura própria ou serviços de wavelength denso alugados dentro e entre cidades, comprados de parceiros operadoras globais. Adescrição do backboneda empresa chama explicitamente seu mapa ilustrado de simplificação que não mostra todos os caminhos. Essa cautela deve governar qualquer leitura de linhas entre pontos latino-americanos. Uma linha desenhada não identifica uma operadora, estação de aterragem, conduíte, wavelength, rota de proteção ou largura de banda disponível.

Peering pode reduzir custo de trânsito e evitar enviar tráfego local para Miami, mas também pode concentrar tráfego nas instalações onde o exchange está disponível. Se o exchange de internet local de um país e uma grande implantação de borda compartilham um edifício ou duto metropolitano, o desempenho local melhora durante a operação normal enquanto o risco físico correlacionado pode permanecer. Múltiplas sessões bilaterais em um único tecido de switch não protegem contra um evento em todo o tecido ou edifício. Múltiplas operadoras em uma única sala de meet-me não provam entradas diversas.

A evidência desejada é específica do caminho. Para cada grande metrópole, uma avaliação de resiliência identificaria as portas de exchange, interconexões privadas e links de trânsito; se seus cross-connects aterrissam em roteadores separados; se as operadoras saem através de dutos separados; e quais sites regionais podem anunciar as rotas afetadas após a retirada. Registros públicos revelam peças dessa imagem. Não revelam a cadeia completa, então alegações de failover regional sem emenda permanecem condicionais.

Anycast redireciona alcançabilidade, não eletricidade ou folga sobressalente

Anycast é poderoso porque separa um endereço de serviço de um destino físico. Quando um local para de anunciar uma rota, redes upstream podem selecionar outro anúncio. Mas o destino selecionado é o melhor caminho de acordo com a política de roteamento, não necessariamente a cidade geograficamente mais próxima ou o local com o maior pool de servidores não utilizado. Aorientação de roteamento geográficoda Cloudflare reconhece que as solicitações podem não alcançar o data center físico mais próximo e que a confiabilidade pode ter prioridade sobre a localidade.

Há três etapas distintas de recuperação. Primeiro, o local prejudicado deve ser removido do caminho de entrada, seja por retirada de rota, engenharia de tráfego ou mudança upstream. Segundo, a internet deve convergir em anúncios alternativos. Terceiro, os locais receptores devem aceitar as conexões adicionadas sem esgotar recursos de computação, memória, cache, roteador, cross-connect ou trânsito. As duas primeiras são ações de roteamento. A terceira é uma condição de capacidade.

Dentro de um local sobrevivente, a Cloudflare usa outra camada de distribuição. Seu relato sobreUnimogexplica como as conexões são distribuídas entre servidores, como servidores não saudáveis são removidos e por que a carga deve ser ajustada para máquinas de desempenho diferente. Isso pode contornar um servidor com falha ou host sobrecarregado dentro de um data center. Não pode ajudar se a sala inteira perder energia, o roteador de borda apagar ou todos os caminhos externos forem cortados. Nesse caso, a camada anycast regional deve carregar a recuperação.

Clientes de interconexão privada têm uma dependência adicional. Aorientação operacional de interconexãoatual da Cloudflare diz que uma implantação do cliente deve tolerar a perda não planejada de qualquer circuito único e que o failover entre circuitos redundantes deve ser automático. Também nota que a manutenção não é coordenada entre diferentes locais. Isso atribui parte da resiliência ao design do cliente: um cliente com uma interconexão física única em GRU pode perder esse caminho direto mesmo que a borda pública da Cloudflare permaneça disponível em outro lugar.

A diferença importa para os serviços afetados. Uma conexão de site público pode muitas vezes seguir outra rota anycast sem ação do cliente, embora latência e comportamento de cache possam mudar. Uma interconexão de rede privada pode exigir um segundo circuito, política de rota adequada e capacidade suficiente em sua terminação alternativa. Uma conexão de longa duração pode quebrar mesmo quando uma nova conexão bem-sucedida em outro lugar. Uma aplicação regionalizada pode ser restrita a um subconjunto de locais.

O caminho de origem de um cliente também pode permanecer prejudicado após a borda se mover, particularmente se a origem estiver conectada através da mesma metrópole.

A recuperação anycast é, portanto, uma transferência de demanda, não o desaparecimento da demanda. Se GRU normalmente processa um grande volume e se retira, alguma combinação de outros sites deve processá-lo. O registro público não divulga a carga normal de GRU, a parcela que pode ser servida do cache, a mistura de produtos, a distribuição de destino ou a utilização dos sites receptores. A frase "o tráfego pode ser redirecionado" é precisa, mas incompleta; descreve o movimento sem quantificar o pouso.

A afirmação de resiliência credível é condicional: a alcançabilidade pode se mover se as rotas se retirarem limpidamente, e o serviço pode continuar se os caminhos e locais alternativos tiverem os recursos necessários e estiverem autorizados a lidar com o trabalho. A eletricidade permanece local. A folga sobressalente permanece finita. Uma rota de internet pode apontar em torno de um edifício escuro, mas não pode tornar o edifício alternativo pronto.

Capacidade instalada não é capacidade de failover utilizável

A Cloudflare anunciou em abril de 2026 que havia ultrapassado 500 Tbps de interconexão externa. Crucialmente, a empresa definiu o número. Seurelato de 500 Tbpsdiz que o número é a soma de portas provisionadas voltadas para provedores de trânsito, peers privados, exchanges de internet e interconexões de clientes em mais de 330 cidades. Também diz que o número não é pico de tráfego e que a diferença suporta absorção de negação de serviço.

Essa é uma medida significativa de escala global. Não é uma tabela de capacidade latino-americana. Somar taxas de porta conta interfaces instaladas onde quer que estejam, mesmo que algumas portas não possam substituir outras. Uma interconexão de cliente em Bogotá não pode transportar automaticamente tráfego de cache público deslocado de São Paulo. Uma porta conectada a um peer alcança o tráfego desse peer, não todo usuário. Dois links de 100 Gbps no mesmo roteador ou rota de fibra são menos independentes do que dois links em instalações separadas.

A capacidade da porta também não diz nada diretamente sobre ciclos de servidor, armazenamento, calor do cache ou energia elétrica por trás dos roteadores.

A política de peering da Cloudflare reforça o problema da unidade. Apoia conexões privadas Nx100G e define limites de tráfego para solicitá-las, mas não publica a utilização atual. O PeeringDB marca o nível geral de tráfego da rede como não divulgado. A evidência pública resultante pode mostrar que grandes interfaces existem e nomear alguns locais; não pode mostrar quantos gigabits permanecem seguramente utilizáveis durante um evento regional.

A divulgação financeira é igualmente agregada. O 10-K relata $179,357 milhões em compromissos não canceláveis de largura de banda e outros colocation no final de 2025, distribuídos em períodos futuros. Isso prova que a empresa compra capacidade de rede e espaço de longo prazo em escala significativa. Não pode ser alocado para a América Latina a partir do arquivamento, e despesa não é throughput. Um contrato pode reservar espaço que ainda não está em serviço, cobrir um prazo fixo em vez de uma reserva de emergência, ou incluir produtos cuja capacidade não é intercambiável.

Figuras de instalação devem ser mantidas em sua própria categoria. O arranjo de energia N+1 do SP4 e a autonomia declarada do gerador descrevem o edifício. A Equinix diz queBogotá BG2tem redundância UPS e gerador N+1, 72 horas de autonomia de gerador e suporte 24 horas. Aespecificação de Lima LIM1da Cirion descreve energia 2N, refrigeração N+1 e mais de 2.200 metros quadrados de colocation com piso elevado. Registros públicos atuais associam a Cloudflare a essas instalações ou locais de interconexão de clientes, mas as classificações da instalação não são alocações da Cloudflare. Dizem o que o operador projetou, não quanta energia ou espaço de piso a Cloudflare comprou.

Capacidade de failover utilizável é mais estreita do que cada uma dessas medidas instaladas. É a parcela de computação alternativa, energia e recursos de rede que é saudável, alcançável, contratualmente disponível, compatível com o serviço afetado e não consumida no momento da falha. Deve permitir crescimento de tráfego durante a convergência, erros de cache, carga de ataque e a possibilidade de que uma segunda dependência esteja degradada. Uma reserva prudente não é, portanto, simplesmente "taxa de porta não utilizada."

Nenhuma fonte pública revisada aqui dá esse número por metrópole latino-americana. Essa ausência impede uma afirmação quantitativa de que o tráfego de São Paulo poderia ser totalmente absorvido dentro da região. O número global de 500 Tbps torna essa absorção plausível para muitos eventos comuns, mas plausibilidade não é medição. Até que a utilização por site, elegibilidade de serviço e limites de falha correlacionados sejam publicados, a conclusão correta é que a escala instalada é forte enquanto a folga regional utilizável permanece não divulgada.

A recuperação passa por mãos remotas, operadoras e autoridade de mudança

Quando uma sala perde energia, a retirada de rota é apenas o começo. Alguém deve determinar se as alimentações da concessionária, chaves, UPS, geradores, refrigeração e distribuição do rack estão estáveis. Alguém deve inspecionar a energia do roteador e servidor, verificar luz óptica, substituir componentes com falha, restaurar circuitos e sequenciar o equipamento de volta ao serviço. Em uma instalação de terceiros, essas tarefas cruzam limites organizacionais.

Orelato de falha de energia em Oregonda Cloudflare de novembro de 2023 está fora da América Latina e dizia respeito a serviços centrais, não a um site de borda latino-americano. Ainda é um exemplo valioso divulgado da cadeia de recuperação física. A instalação perdeu energia da concessionária e do gerador após uma falta à terra; baterias se esgotaram; acesso e pessoal complicaram o reinício do gerador; a Cloudflare soube do problema quando os roteadores ficaram offline; disjuntores então tiveram que ser substituídos; e os servidores foram trazidos de volta em uma sequência controlada. A empresa claramente separou fatos confirmados de especulação informada onde o operador da instalação não havia fornecido respostas.

A mesma instalação falhou novamente em março de 2024. Osegundo relato de evento de energiada Cloudflare disse que mudanças anteriores melhoraram a resposta e reduziram o impacto. A comparação mostra que a qualidade da recuperação depende de preparação, dependências testadas e critérios claros de ativação, não apenas de equipamento redundante em uma folha de especificações da instalação.

Para sites de borda latino-americanos, o 10-K diz que contratados terceiros podem instalar e manter hardware no exterior e que a Cloudflare não controla as operações de instalações de terceiros. Informações públicas de suporte à instalação ajudam a identificar uma dependência humana. Adisponibilidade de suporte de colocationda Equinix lista cobertura operacional no local 24 horas para Bogotá BG2, enquanto a cobertura difere em outros sites. Isso não revela a franquia de serviço da Cloudflare, alvo de resposta, inventário de peças sobressalentes ou se um técnico está autorizado a tocar em um dispositivo específico. Mostra por que o pessoal pertence à avaliação física.

A recuperação da operadora tem sua própria cadeia. Uma falha de cross-connect requer coordenação entre Cloudflare, a instalação e o peer ou operadora. Luz óptica baixa pode resultar de um conector sujo, fibra danificada, óptica com falha ou problema de caminho mais longo. Restaurar um lado sem confirmar o outro pode deixar a sessão inativa. Para uma interconexão de cliente, o cliente também deve ter failover automático e capacidade alternativa suficiente. Para uma falha de exchange, as sessões podem precisar se mover para caminhos privados ou de trânsito.

A autoridade de mudança pode se tornar a dependência mais lenta. A pessoa que vê um problema de rota pode não poder aprovar o acesso à instalação. A instalação local pode exigir uma carta de autorização antes de mover um cross-connect. Um contratado pode precisar de um número de despacho. Uma operadora pode insistir em testes em um ponto de demarcação antes de escalar. Uma afiliada pode deter o contrato enquanto uma equipe global de operações dirige o reparo. Nenhuma dessas etapas é visível em uma cor de status.

O caminho seguro de restauração também é mais lento do que simplesmente aplicar energia. Uma instalação retornando após um evento instável pode precisar de circuitos energizados em etapas para evitar carga de inrush. Dispositivos de rede devem ser verificados antes que os servidores atraiam tráfego. A saúde e a capacidade precisam ser confirmadas antes que as rotas retornem, caso contrário a demanda pode oscilar entre sites ou sobrecarregar uma sala parcialmente restaurada. O comportamento de cache e conexões de longa duração pode levar tempo adicional para normalizar.

Evidências públicas apoiam a capacidade da Cloudflare de aprender com eventos graves de energia e operar uma resposta global. Não divulgam runbooks de sites latino-americanos, peças sobressalentes locais, metas de tempo de recuperação ou mapas de autoridade. Essas omissões não provam fraqueza. Significam que a parte humana e contratual da resiliência não pode ser verificada independentemente a partir da pegada de cidades.

Quem sente a falha primeiro

A primeira população afetada depende de qual camada falha. Se um servidor falha mas o roteador e a sala permanecem saudáveis, a distribuição local de carga pode removê-lo com pouco efeito visível. Se uma porta de exchange falha, usuários de peers que dependiam dessa porta podem experimentar caminhos mais longos enquanto usuários chegando através de outras operadoras permanecem locais. Se um site inteiro se retira, muitas redes de acesso podem mudar juntas. Se uma metrópole perde vários caminhos correlacionados, uma região muito maior pode ser enviada para cidades mais distantes.

Usuários finais notam latência, redefinições de conexão, menor throughput ou erros. O padrão não será uniforme em um país. Um provedor de serviços de internet com uma sessão direta em San José pode seguir um caminho diferente de um que compra trânsito upstream. Redes móveis e fixas podem fazer escolhas de roteamento diferentes. Um acerto de cache pode ser concluído localmente enquanto uma solicitação não armazenada em cache ainda depende de uma origem na metrópole com falha. O status de "San José" ou "São Paulo" não se traduz, portanto, em uma experiência nacional.

Clientes da Cloudflare que usam interconexões privadas enfrentam um limite mais explícito. O aviso de GRU disse-lhes para esperar que as interfaces se tornassem indisponíveis e para arranjar failover em outro lugar. Se seu circuito alternativo está na mesma metrópole ou usa o mesmo caminho de operadora, a redundância nominal pode não ajudar. Se termina em outra cidade, deve ser dimensionado para a demanda transferida e seu roteamento deve ativar sem atraso manual. A continuidade da borda pública não restaura por si só um caminho privado.

Escolhas de localidade de dados estreitam o conjunto receptor. Adescrição dos Serviços Regionaisda Cloudflare diz que conexões criptografadas podem ser aceitas globalmente enquanto a descriptografia HTTPS e o processamento no nível da aplicação ocorrem apenas na região selecionada. Isso significa que um local fora do conjunto selecionado pode absorver a conexão de rede, mas não pode necessariamente realizar todo o trabalho. A capacidade de failover deve ser contada dentro da região de processamento permitida, não em cada ponto do mapa mundial.

Atabela de suporte de regiãoatual lista o Brasil como uma região gerenciada de Serviços Regionais. Não lista uma única região gerenciada cobrindo toda a América Latina, embora configurações personalizadas possam estar disponíveis para algumas opções. Um compromisso de localidade brasileira pode, portanto, tornar o número e a distribuição de sites brasileiros saudáveis especialmente importantes. Capacidade em Miami, Bogotá ou San José pode ser fisicamente alcançável, mas inelegível para descriptografia nessa configuração. A configuração de produto de cada cliente importa.

Serviços do setor público, bancos, varejistas, provedores de saúde, mídia, serviços de software e pequenos sites podem todos estar atrás da mesma borda, mas seus custos de falha diferem. Um pequeno atraso em uma página estática não é o mesmo que perda de uma conexão de pagamento, caminho de acesso de funcionário ou serviço de informação pública. Clientes com um segundo provedor ou rota de desvio podem se recuperar independentemente; clientes que dependem exclusivamente da Cloudflare precisam da borda da Cloudflare e de suas próprias origens para permanecerem conectados.

O 10-K da Cloudflare reconhece que os clientes podem perder acesso às suas redes ou à internet até que o serviço retorne ou eles acionem um desvio.

Os primeiros usuários a sentir uma falha não são, portanto, necessariamente os mais próximos da sala escura. São os usuários cujo provedor de acesso, produto, regra de localidade, circuito privado e caminho de origem deixam menos alternativas. Essa distribuição não pode ser derivada apenas da geografia. Requer dados de tráfego e configuração de cliente que não são públicos.

A evidência ainda faltando para uma afirmação credível de resiliência

As evidências públicas são suficientes para estabelecer uma superfície operacional latino-americana substancial. A Cloudflare lista uma ampla pegada de cidades. Relata uma implantação em San José com NIC.CR e um componente de status ativo lá. Seu registro PeeringDB mostra relações atuais de exchange e instalação. Material de interconexão de clientes identifica instalações nomeadas de São Paulo a Bogotá e Lima. Operadores de instalações publicam características de energia, refrigeração e suporte. A Cloudflare relata interconexão externa global em 500 Tbps e descreve abertamente riscos de instalações de terceiros, operadoras e energia.

Não é suficiente para provar que a região pode absorver a perda de uma grande metrópole sem impacto material. A evidência faltante começa com um inventário datado: instalações ativas por cidade, os serviços habilitados em cada uma, gerações de servidores, computação utilizável, energia de rack contratada e capacidade de porta externa. A próxima necessidade é utilização: carga normal e percentil alto, política de reserva, margem de ataque e a transferência máxima testada de cada grande domínio de falha. Totais globais não podem responder a essas perguntas locais.

A independência física também precisa de prova. Para cada par de sites nominalmente diversos, uma divulgação útil identificaria fornecimento separado da concessionária, trilhas de UPS e gerador, entradas de fibra, salas de meet-me, tecidos de exchange, rotas de operadora e saídas de longa distância. Declararia onde dois circuitos "diversos" convergem. Distinguiria um edifício separado de uma metrópole separada e uma metrópole separada de um caminho internacional de aterragem separado. A ilustração atual do backbone expressamente não mostra todas as rotas, e o marketing da instalação não mapeia circuitos específicos do cliente.

O limite legal e comercial permanece incompleto. O registro legal recente da empresa costarriquenha e o registro na LACNIC são fortes evidências de presença local, mas não há agenda pública atribuindo instalações regionais, contratos de operadoras, propriedade de equipamentos ou autoridade de emergência entre afiliadas da Cloudflare. O acordo padrão com o cliente nomeia a matriz de Delaware. Um relato credível deve, portanto, nomear a entidade contratante apenas onde um documento público o faz e evitar tratar o nome costarriquenho como um rótulo genérico de operador regional.

Evidências de recuperação incluiriam o caminho de alerta da instalação para a Cloudflare, compromissos de resposta de mãos remotas, localização de peças sobressalentes, escalação de operadora, limites de retirada de rota, ordem de reinicialização e prova de exercícios de site completo. Os incidentes em Oregon mostram por que esses detalhes importam, mas não estabelecem o desempenho latino-americano. A classificação N+1 ou 2N de uma instalação é uma entrada, não um resultado.

O teste deve incluir perda de toda a sala, perda de um caminho de operadora metropolitano e perda de uma região de localidade permitida, não apenas dispositivos individuais.

O impacto no cliente precisa de sua própria medição. Relatórios públicos poderiam mostrar, sem expor clientes, quanto tráfego se moveu, onde pousou, como a latência mudou, se as interconexões privadas falharam, se os serviços regionalizados permaneceram dentro de seus locais permitidos e quanto tempo levaram os caches e sessões de longa duração para estabilizar. O aviso de manutenção de GRU afirma a direção esperada da viagem, mas não publica nenhum desses resultados.

Nenhum dos itens faltantes prova que a Cloudflare carece de resiliência. O sigilo em torno de sites exatos e capacidade pode, por si só, proteger a segurança e o poder de barganha. O ponto é mais estreito: o mapa público e o número de capacidade global não podem sustentar uma promessa quantitativa de failover regional por si só. O que pode ser defendido é uma cadeia condicional.

A Cloudflare tem muitos locais e múltiplas formas de interconexão; anycast e distribuição local de carga podem mover o trabalho; instalações de terceiros e operadoras fornecem a plataforma física; e a recuperação bem-sucedida depende de energia independente, rotas, capacidade e ação humana que são apenas parcialmente visíveis.

Retorne, finalmente, à chave de transferência de São Paulo. Se a segunda alimentação se mantiver, os roteadores mantiverem luz e a instalação permanecer fresca, os usuários podem nunca saber que ela se moveu. Se a sala escurecer, as rotas podem sair. Se o serviço sobrevive graciosamente é decidido nas salas receptoras: seus watts sobressalentes, ciclos de servidor, portas, cargas de trabalho permitidas e caminhos funcionais. Essas são as quantidades que um ponto de cidade esconde.

Até que sejam divulgadas ou medidas independentemente, a leitura honesta da borda latino-americana da Cloudflare não é "o mapa se cura sozinho", mas "o mapa mostra onde uma cadeia física cuidadosamente mantida deve responder."