Capacidade com folga
Banda real com folga para os picos, não um número de manchete que satura justo quando você mais precisa.
Infraestrutura de e-mail
Servidores KumoMTAMTA de código aberto, Rust + Lua, sem tarifa por mensagemServidores PowerMTALicenciado, pools VirtualMTA, suporte do fornecedorEntregabilidadeWarm-up, alinhamento DMARC, feedback loopsServidores
Bare metal — AMD EPYCInquilino único Turin / Genoa, até 192 núcleosServidores GPU e IANVIDIA Blackwell B200 / H200, PCIe Gen5VPSInstâncias por núcleo nos mesmos hosts EPYCCloud e rede
CloudInstâncias por hora, snapshots, NVMe Gen5Proteção contra DDoSAbsorção na borda incluída em cada servidorRede e regiõesAmsterdã · Frankfurt · Londres · AshburnRede
Uma boa rede de hospedagem se julga pelo que ela faz por você: diversidade de rotas entre vários operadores e peering direto, espaço IP limpo com reputação comprovada que protege a entregabilidade, dual-stack IPv4 e IPv6, anycast e absorção de DDoS sempre ativa. Fazemos peering na Europa —AMS-IX, DE-CIX e LINX— e em Ashburn, e dizemos com honestidade quando uma rede premium importa de verdade e quando o IX.br e um provedor no Brasil ganham para o seu tráfego.
Em resumo
Os fundamentos
Seis coisas, e nenhuma é uma única cifra de manchete. Uma rede é boa quando os caminhos que o seu tráfego de fato toma são diversos, sem congestão e confiáveis.
Banda real com folga para os picos, não um número de manchete que satura justo quando você mais precisa.
Vários operadores de trânsito mais peering direto, para que a queda de um provedor não deixe você sem saída.
Endereços com reputação comprovada e mantidos limpos: a metade de rede da entregabilidade do e-mail.
Rotas curtas e estáveis até onde vivem os seus usuários e os grandes provedores de caixa, não só uma média bonita.
Mitigação na borda dos ataques comuns, sempre ativa, como parte da rede e não como um extra.
Os dois protocolos em cada servidor: IPv6 para o futuro, IPv4 limpo para compatibilidade e e-mail.
O marketing de redes adora um número: terabits de backbone, um logo de operador Tier-1, um mapa com muitos pontos. Nenhum diz se o seu e-mail vai chegar à caixa ou se o seu site vai carregar rápido para alguém em São Paulo ou em Lisboa. O que se mede de verdade é mais chato e mais útil: latência e a sua variação até os destinos que importam para você, perda de pacotes sob carga, quantas rotas independentes há até um mesmo lugar, e se os endereços de onde você envia estão limpos.
Cada salto em uma rota soma milissegundos, e cada 100 ms de latência a mais reduz de forma apreciável as conversões no comércio eletrônico e nos pagamentos. Por isso preferimos rotas curtas e previsíveis —menos saltos, menos operadores intermediários congestionados— a uma cifra grande que satura no horário de pico. Medimos a rede pelo percentil, não pela média: uma média rápida que dispara no p99 é justo o que um usuário nota.
O trânsito compra de um operador acima o acesso a toda a tabela de roteamento da internet: alcance a todos os lugares, mas pagando a um terceiro para transportar o seu tráfego. O peering troca tráfego diretamente com outra rede, muitas vezes sem custo em um ponto neutro, e dá o caminho mais curto aos destinos comuns. As boas redes usam os dois: trânsito para o alcance universal, peering para a velocidade e a resiliência até onde vivem os seus usuários e os provedores de caixa.
No nosso caso, isso tem nomes concretos. Fazemos peering nos grandes pontos neutros europeus —AMS-IX em Amsterdã, DE-CIX em Frankfurt e LINX em Londres— e em Ashburn, na costa leste dos EUA, um dos núcleos de interconexão mais densos do mundo. Esse posicionamento dá rotas curtas às redes europeias e norte-americanas e aos grandes provedores de caixa, que é onde o e-mail de alto volume precisa de caminhos limpos.
E aqui vai a parte honesta sobre o Brasil. O IX.br de São Paulo é o maior ponto de troca de tráfego do mundo, com pico acima de 22 Tbit/s e milhares de Sistemas Autônomos, e uma rede conectada a ele alcança boa parte do endereçamento brasileiro por rotas domésticas curtas, cortando perto de 100 ms ante o caminho por backbones internacionais. Nós não estamos no IX.br. Então, para uma aplicação cujo público é sobretudo brasileiro, um provedor presente no IX.br entrega uma latência que nós, a partir da Europa ou de Ashburn, não temos como igualar —e dizemos isso em vez de fingir o contrário.
Porque um endereço IP carrega uma reputação, e essa reputação viaja com cada mensagem que você envia. Endereços com histórico de spam, abuso ou entradas em listas negras mandam o e-mail para o spam e disparam filtros de segurança por mais afinado que esteja o seu servidor. O espaço limpo, com reputação comprovada, usado de forma constante e mantido por gestão ativa de abuso, é a metade de rede da entregabilidade —a outra metade, a autenticação e o aquecimento, vive no próprio servidor de envio.
Mantê-lo limpo é uma prática, não um ajuste de um dia. Vigiamos os blocos por listagens, atendemos rápido os relatórios de abuso, conservamos o espaço em uso constante para que os provedores aprendam a confiar nele, e reservamos históricos limpos para os hosts de envio. Quando entra um cliente novo de e-mail, ele parte de espaço saudável em vez de herdar a má fama de um vizinho anterior.
Por enquanto você precisa dos dois, e por isso rodamos dual-stack em cada servidor. A adoção de IPv6 cresce sem parar mas ainda não chega à metade do tráfego global, então o IPv6 olha para o futuro enquanto o IPv4 se conserva para a compatibilidade, as integrações de terceiros e a entregabilidade de e-mail, onde muitos sistemas ainda assumem IPv4. O pool livre de endereços IPv4 está esgotado há anos, o que torna o espaço IPv4 limpo um ativo real, com preço, que não se dá de graça.
A consequência prática é simples: atribuímos um IPv4 e um bloco IPv6 a cada servidor, e endereços IPv4 adicionais conforme a necessidade justificada, em linha com a política de endereçamento. Não inflamos o número de IPs que distribuímos —o espaço limpo é escasso e o tratamos como tal— e isso, por sua vez, é parte de por que a reputação do nosso espaço se mantém saudável.
A borda
O seu servidor chega à internet por uma borda com várias saídas. O que mantém a rede em pé ante falhas e ataques é ter muitos caminhos, não um muito grande.
O roteamento descansa em duas ideias. O BGP mantém várias sessões ao mesmo tempo —dois trânsitos e um peering de troca— de modo que, se uma rota se degrada ou cai, o tráfego simplesmente sai por outra sem que ninguém note. O anycast anuncia o mesmo endereço a partir de vários sites para que cada usuário chegue ao mais próximo. Juntas —muitas saídas, e o mesmo endereço respondido a partir do lugar mais perto— são quase toda a forma como uma rede segue em pé ante falhas comuns e ataques deliberados.
A mesma diversidade que sobrevive a uma falha resiste a um ataque, e por isso aqui roteamento e segurança não são projetos separados. Uma inundação que chega por uma rota pode ser desviada, limpa ou descartada na borda enquanto o tráfego legítimo segue fluindo pelas outras, e o anycast reparte um ataque grande entre os sites em vez de deixar que ele se concentre em um. Projetados juntos, roteamento e mitigação tornam a rede difícil de derrubar por acidente ou de propósito.
edge1# show ip bgp summary
BGP router identifier 203.0.113.1, local AS number 64500
Neighbor AS Up/Down State/PfxRcd
198.51.100.2 3356 31w2d 986214 # trânsito — operador A
198.51.100.6 174 24w5d 985880 # trânsito — operador B
80.81.192.1 6695 18w0d 142037 # peering — ponto neutro (DE-CIX FRA)
# dois trânsitos mais peering — uma rota pode cair sem que você note A redundância útil não é um número em um folheto, mas uma propriedade que você nota no dia em que algo falha e nada acontece. A borda tem vários roteadores; cada um fala com vários operadores e com o ponto neutro; e a energia, a refrigeração e os enlaces dos data centers seguem o mesmo princípio de não ter um único ponto de falha. Os grandes IXs onde fazemos peering, por exemplo, mantêm redes de troca redundantes e isoladas entre si, prontas para suportar a falha completa de uma delas, e a interconexão entre data centers vai por fibras escuras redundantes com rotas diversificadas.
Quando falamos de disponibilidade, preferimos ser concretos a prometer um número redondo. Dizemos o que é redundante e o que não é, onde está o risco residual, e o que o acordo de nível de serviço cobre em termos que você possa verificar. Um compromisso de disponibilidade que não explica como se mede nem o que exclui não vale grande coisa; preferimos um mais modesto e honesto que você consiga auditar.
A absorção dos ataques volumétricos comuns vem incluída na rede, sempre ativa, sem que você precise pedir nem pagar à parte. Ela é filtrada e limpa na borda, antes de o tráfego malicioso chegar ao seu servidor, e a diversidade de rotas reparte a carga em vez de deixar um único enlace saturar. Para o risco hipervolumétrico de verdade —os ataques que superam a capacidade de qualquer borda— oferecemos mitigação rio acima, ajustada à sua exposição, porque envolve capacidade de trânsito real e seria desonesto empacotá-la como uma promessa vaga.
A razão de fazer isso na borda, e não só rio acima, é de tempo e de custo. Um filtro perto do servidor descarta os pacotes-lixo assim que chegam, antes de consumirem a sua capacidade ou dispararem os seus alarmes, e deixa passar o tráfego legítimo com uma latência que quase não muda. Distinguir um do outro é o trabalho difícil: vigiamos padrões —picos de SYN, amplificação de DNS ou NTP, inundações a uma única porta— e ajustamos as regras ao que de fato ataca, em vez de bloquear às cegas e arriscar derrubar também os seus usuários reais.
Quando você envia e-mail em volume e a reputação importa, quando a latência é parte do seu produto, ou quando o tráfego é alto o bastante para que a congestão ou a queda de um único operador custem dinheiro. Nesses casos, a diversidade de rotas, o espaço IP limpo e o peering bem posicionado se pagam sozinhos. Um site pequeno e de pouco tráfego, por outro lado, vai muito bem com conectividade padrão, e não vamos cobrar por rotas e capacidade que você não vai usar.
Também não somos uma CDN global, e não vamos fingir que somos. Operamos um backbone multi-homed com rotas fortes às redes que os nossos clientes usam e aos grandes provedores de caixa, nas regiões onde operamos. Para conteúdo que precise estar a milissegundos de cada continente —e o Brasil é um exemplo claro, dada a distância das nossas regiões— uma CDN dedicada à frente da nossa origem é a ferramenta certa, e dizemos isso quando é o seu caso em vez de exagerar o nosso alcance.
Colocamos os servidores onde você precisa, dentro da nossa pegada: Amsterdã, Frankfurt e Londres, na Europa, e Ashburn, na costa leste dos EUA. Para um público europeu ou norte-americano, e para a infraestrutura de e-mail —cujos destinos são os grandes provedores de caixa globais— esse posicionamento dá rotas curtas e limpas. Ashburn é a nossa região mais próxima do Brasil, perto de 120 ms de São Paulo, o que serve bem a cargas globais ou que toleram essa latência.
A residência de dados se segue de escolher a região. Operar dentro da UE torna a conformidade com o GDPR um fato verificável, e a LGPD permite a transferência internacional com base legal e salvaguardas, com a configuração, os logs e o roteamento sob o nosso controle de ponta a ponta. Aqui vai o limite honesto: não temos PoP em solo brasileiro nem presença no IX.br, então se a sua carga serve sobretudo usuários no Brasil ou exige dados no país, um provedor nacional conectado ao IX.br é a escolha certa, e dizemos isso com clareza.
Vale ainda nomear o que isso significa na prática. Para um SaaS que atende clientes brasileiros mas roda a sua lógica e os seus dados na nuvem, a distância costuma ser aceitável, ainda mais com uma CDN à frente para o conteúdo estático. Para jogos, trading, telemedicina ou qualquer coisa em tempo real voltada ao Brasil, os cerca de 120 ms de Ashburn pesam, e ali um datacenter no Brasil ganha de forma clara. Preferimos que você escolha a região com os números à frente, não com um mapa de marketing.
Operamos a rede que sustenta os nossos próprios serviços: backbone multi-homed, espaço IP limpo, dual-stack, anycast no DNS e na mitigação, e peering na Europa e em Ashburn. Não revendemos uma CDN de terceiros como se fosse nossa nem prometemos presença em cada continente, e não estamos no IX.br. Onde agregamos valor é em rotas diversas e limpas até onde o seu tráfego de fato vai —Europa, América do Norte e os grandes provedores de caixa— e em dizer quando outra ferramenta, ou um provedor no Brasil, encaixa melhor.
Essa franqueza é parte do serviço. Se o seu site precisa estar a poucos milissegundos de usuários no Brasil, recomendamos uma CDN à frente ou um provedor no IX.br; se a sua carga é pequena, dizemos que a conectividade padrão sobra. O que não faremos é vender um backbone premium que você não vai usar só porque soa bem em uma fatura.
Perguntas
O que se pergunta sobre a rede por baixo de um servidor.
Capacidade real com folga, diversidade de rotas entre vários operadores mais peering direto, espaço IP limpo com reputação comprovada, latência baixa e constante, absorção de DDoS sempre ativa, e tanto IPv4 quanto IPv6. Um único número impressionante —uma cifra grande de backbone ou um logo de Tier-1— diz pouco por si só; o que importa é se as rotas que o seu tráfego de fato toma são diversas, sem congestão e confiáveis.
O trânsito compra de um operador acima o acesso a toda a tabela de roteamento da internet, o que dá alcance a todos os lugares. O peering troca tráfego diretamente com outra rede, muitas vezes sem custo em um ponto neutro, o que dá o caminho mais curto aos destinos comuns. As boas redes usam os dois: trânsito para alcance universal, peering para velocidade e resiliência até onde estão os seus usuários e os provedores de caixa.
Porque um endereço IP carrega uma reputação. Endereços com histórico de spam, abuso ou entradas em listas negras mandam o e-mail para a caixa de spam e disparam filtros de segurança por mais bem configurado que esteja o seu servidor. O espaço limpo, com reputação comprovada, usado de forma constante e mantido limpo por gestão ativa de abuso, é a metade de rede da entregabilidade —e é justo o espaço que reservamos aos hosts de envio.
Por enquanto você precisa dos dois. A adoção de IPv6 segue crescendo mas ainda está abaixo da metade do tráfego global, então o dual-stack é a norma: IPv6 para o futuro e IPv4 conservado para compatibilidade, integrações de terceiros e entregabilidade de e-mail. O pool livre de IPv4 está esgotado, então o espaço IPv4 limpo é um ativo real e com preço, e rodamos os dois protocolos em cada servidor.
Anycast anuncia o mesmo endereço a partir de vários lugares para que cada usuário chegue ao mais próximo. É como funcionam o DNS resiliente e a absorção de DDoS em larga escala, porque o tráfego se reparte entre os sites em vez de se concentrar em um. Você se beneficia dele no nosso DNS e na mitigação pensando nisso ou não; a maioria das cargas não precisa rodar o seu próprio anycast.
Não estamos no IX.br, e aqui vamos ser honestos sobre o que isso significa. O IX.br de São Paulo é o maior ponto de troca de tráfego do mundo, com mais de 22 Tbit/s e milhares de Sistemas Autônomos, e estar conectado a ele corta perto de 100 ms na latência ante rotas que passam por backbones internacionais. As nossas regiões ficam na Europa e em Ashburn, então para uma aplicação que serve sobretudo usuários no Brasil, um provedor presente no IX.br entrega latência muito menor do que nós. Onde a nossa rede brilha é em cargas voltadas à Europa e aos EUA, e na infraestrutura de e-mail, onde os destinos são os grandes provedores de caixa globais e não os olhos do usuário brasileiro.
Não, e não vamos fingir o contrário. Operamos um backbone multi-homed com rotas fortes às redes que os nossos clientes usam e aos grandes provedores de caixa, nas regiões onde operamos. Para conteúdo que precise estar a milissegundos de cada continente —incluindo o Brasil— uma CDN dedicada à frente da nossa origem é a ferramenta certa, e dizemos isso quando é o caso em vez de exagerar o nosso alcance.
Quando você envia e-mail em volume e a reputação importa, quando a latência é parte do seu produto, ou quando o tráfego é alto o bastante para que a congestão ou a queda de um único operador custem dinheiro. Um site pequeno e de pouco tráfego vai bem com conectividade padrão. Preferimos ajustar a rede à sua carga a vender capacidade e rotas que você não vai usar.
O seu público, o seu volume de e-mail e a sua tolerância a latência —e dizemos se a nossa rede encaixa, se vale uma CDN à frente, ou se um provedor no IX.br serve melhor o Brasil. Sem exagerar o nosso alcance.