Você hospeda em um lugar só, digamos, um data center na Virgínia. Isso funciona bem para clientes em Nova Iorque ou Chicago, mas e alguém em Tóquio, em Londres ou em Sydney? Toda vez que essa pessoa visita seu site, a solicitação precisa cruzar oceanos e continentes apenas para chegar ao seu servidor. Cada imagem, cada carregamento de página, cada chamada de API faz a mesma longa jornada, esse atraso se acumula rapidamente. Na verdade, estudos mostram que um atraso de apenas um segundo no carregamento da página pode custar conversões e afastar visitantes frustrados. Mas aqui está o problema. O que acontece quando seu site viraliza ou uma botnet decide atacar? Seu servidor único na Virgínia é bombardeado. Ele fica lento e pode até travar completamente. Você fica preso sem um plano de contínuo. Você pode resolver o problema de disponibilidade criando cópias do seu site em diferentes regiões, como Tóquio, Londres ou São Paulo. Ajuda.

Mas agora você tem um novo problema. Como você envia cada visitante para o local correto? Você não quer que alguém no Japão acesse seu servidor no Zewa por acidente. E esse é uma maneira inteligente de rotiar o tráfego, e é exatamente aí que o Azure Front Door entra. Conheça o Guarda de Trânsito Global, que o Azure Front Door é. Pense no Azure Front Door como um guarda de trânsito global, não apenas um e um único cruzamento, mas milhares deles posicionados nos principais cruzamentos do mundo todo. Toda vez que alguém visita seu site, o guarda mais próximo intervém e diz você está em Tóquio, a loja mais rápida, você fica em Singapura. Deixa eu me levar você até lá. Então como isso é diferente de um balanceador de carga comum? A maioria dos balanceadores de carga trabalha na camada 4, observando endereços IP e portas para rotear o tráfego. Isso é bom para necessidades básicas. Mas o Azure Front Door trabalha na camada 7, o que significa que ele entende o tráfego HTTPS.

Ele pode olhar a URL digitada, verificar os cabeçalhos do navegador, ver que tipo de conteúdo está sendo solicitado e tomar decisões inteligentes de roteamento baseadas em tudo isso. Em vez de apenas dizer este IP vai para aquele servidor, o Front Door pode dizer esta solicitação de usuários da API vai para seu back-end no ZWA. Mas esta solicitação de imagens vai para a cópia em caixa em Tóquio. Agora veja o que torna isso possível nos bastidores. O Azure Front Door é executado na rede global da Microsoft com mais de 210 pontos de presença em mais de 130 locais metropolitanos no mundo todo. Anne, pense em cada ponto de presença como uma pequena cabine de tráfego, um escritório local em cada grande cidade que pode lidar com a solicitação inicial rapidamente. Quando um usuário visita seu site, ele se conecta ao ponto mais próximo em vez de viajar até o servidor de origem na Virgínia. Esse ponto então encaminha a solicitação pela rede privada da Microsoft até o seu back-end.

Isso é importante porque a internet pública é imprevisível. Seu tráfego pode passar por doses altas em redes diferentes, cada um adicionando latência e perda potencial de pacotes. A rede da Microsoft, por outro lado, é uma rede privada de alta velocidade que conecta seus data centers diretamente. Quando sua solicitação chega ao ponto de presença mais próximo, o restante da jornada acontece em uma via rápida e confiável. Você obtém tempos de carregamento mais rápidos, menor latência e uma experiência melhor para usuários em qualquer lugar, seja em Tóquio, Londres ou São Paulo. Tudo isso acontece automaticamente, sem que seus visitantes saibam que está lá. Três camadas de resiliência, como a FD permanece no ar. Agora, você pode estar pensando, essa ideia de um guarda de trânsito global parece ótima, mas o que acontece se o guarda falhar? Se o Azure Front Door é o ponto de entrada único para todo o seu aplicativo, esse é um grande ponto único de falha, certo?

A Microsoft pensou nisso. Eles criaram três camadas de resiliência no Front Door para que ele quase nunca saia do ar. Deixa eu me explicar cada uma dessas. Primeira camada é o front-end. Lembra daqueles mais de 210 pontos de presença que mencionei? Cada um é um posto de tráfego totalmente independente. Esses POPs estão em mais de 130 locais metropolitanos no mundo todo, operando dentro de data centers da Microsoft e instalações de colocation parceiras. Cada POP possui vários hacks de servidores com controladores de borda que atuam como um balanceador de carga integrado. Se um servidor dentro de um POP falha, o controlador de borda redireciona o tráfego para um servidor saudável no mesmo POP. E se um POP inteiro sair do ar, é aí que entra o endereçamento IPNCast. A solicitação do seu visitante é roteada automaticamente para o POP mais próximo. Sem interrupção e sem intervenção manual simplesmente acontece.

Segunda camada é o fallback. Mas e se um POP ficar sobrecarregado? Digamos que haja um pico massivo de tráfego ou que vários POPs em uma região caiam de uma vez. POPs restantes podem não ser capazes de lidar com a carga. É aí que entra a camada de fallback. Este é um conjunto separado de POPs, dezenas deles, não centenas, executando exatamente o mesmo software e arquitetura. Eles residem apenas em data centers da Microsoft e não em instalações parceiras. Quando um POP de front-end precisa reduzir o tráfego, ele transfere as solicitações para essa camada de fallback. Mesmo caixa, mesmo roteamento, mesmo segurança. Seus visitantes nunca percebem isso. Eles recebem seu conteúdo um pouco mais devagar, talvez, mas ainda o recebem. Terceira camada, o escudo de tráfego. Este é o supervisor. Pense nele como um centro de comando global que monitora toda a rede do front-door. Ele monitora padrões de tráfego, níveis de carga e integridade em todos os POPs.

Quando detecta que certos POPs estão sobrecarregados, ele não espera apenas a camada de backup entrar em ação. Ele redireciona o tráfego proativamente ao atualizar como o DNS resolve seu endpoint do front-door. Ele pode alternar de um IPN-cast global para um regional, movendo clientes para outros conjuntos de POPs completamente. Ele pode até cruzar continentes, se necessário. O escudo de tráfego, o que faz o front-door parecer quase mágico. Ele otimiza constantemente nos bastidores, ajustando rotas antes mesmo que os problemas ocorram. Agora eu preciso mencionar algo aqui. Em outubro de 2025, Azure Front-door sofreu uma interrupção significativa. Uma alteração de configuração ignorou as validações de segurança e causou problemas generalizados no Microsoft 365 Xbox Live e em milhares de sites de clientes. A Microsoft aprendeu com isso. Eles removeram todo o processamento assíncrono do pipeline de configuração.

Agora, cada caminho de código é testado durante a implementação. Eles reduziram o tempo de reversão de 4 horas para 1 e visam chegar a 10 minutos até março de 2026. Eles também estão introduzindo a segmentação por microcelas para limitar qualquer impacto futuro a menos de 1% dos locatários. O ponto é, nenhum sistema é perfeito, mas a arquitetura de 3 camadas do front-door foi projetada para sobreviver a quedas regionais, picos de tráfego e ter alguns erros de configuração. Para a maioria das aplicações, isso é mais do que o suficiente. Para sistemas realmente críticos, você pode colocar o Azure Traffic Manager antes do front-door como uma rota de emergência, mas esse é um tópico avançado para outro dia. Como ele direciona o tráfego, roteamento e grupos de origem? Então, temos esse guardas de trânsito global com mais de 210 cabines e 3 camadas de backup, mas como ele decide para onde enviar cada visitante?

Hum... É aí que entram os grupos de origem. Um grupo de origem é basicamente uma coleção de seus servidores de back-end. Pense nele como sua lista de lojas, os locais reais onde seu site e o aplicativo é executado. Você pode ter um servidor na América do Norte, um na Europa e um na Ásia. Todos eles entram no mesmo grupo de origem. Agora, o front-door não envia tráfego cegamente para todos eles. Ele verifica constantemente se estão ativos. Isso é chamado de som dentro da idade de health. Cada poucos segundos, cada pop do front-door testa seus servidores acessando um caminho específico, geralmente a raiz do site ou um endpoint dedicado de integridade como o health. Se um servidor não responder ou retornar um código de erro, front-door o marca combinativo e para de enviar tráfego para ele. É como um guarda de trânsito verificando se uma loja está realmente aberta antes de permitir a entrada de clientes.

Mas quando você tem vários servidores íntegros, a questão é qual deles devem receber o visitante. O front-door usa três fatores para decidir. Prioridade, latência e peso. E eles trabalham juntos em uma ordem específica. Primeiro é a prioridade. Você pode designar um servidor como principal e outro como backup. Defina o principal com prioridade 1 e o backup com prioridade 2. Em condições normais, todo o tráfego vai para o principal. Portanto, se o principal cair, o tráfego é transferido para o backup. Simples, certo? Isso é ótimo para configurações ativo-passivo, onde você quer que uma região processe tudo, a menos que falhe. Mas e se você quiser que ambos os servidores fiquem ativo? É aí que entra a latência. Se vários servidores tiverem a mesma prioridade, o front-door envia o tráfego para aquele com a menor latência ou tempo de resposta mais rápido a partir da localização do visitante.

Um usuário em Londres é direcionado ao seu servidor europeu, enquanto um usuário em Tóquio vai para o asiático. Vai para o asiático. Existe também uma configuração de sensibilidade, por padrão de 50 milissegundos. Se dois servidores estiverem dentro de uma diferença de 50 milissegundos entre si, e o front-door os considera igualmente rápidos. Isso evita a alternância constante entre os servidores, que são basicamente da mesma velocidade. Quando a latência está empatada, é aí que entra o peso. Você pode atribuir pesos para dividir o tráfego entre os servidores. Digamos que você queira testar uma nova versão do seu aplicativo. Você poderia dar ao seu servidor atual um peso de 90 e ao novo um peso de 10. Isso significa que aproximadamente 9 em cada 10 visitantes vão para a versão antiga e 1 em cada 10 vai para 9. Isso é perfeito para implementações graduais, testes A, B, ou apenas para balancear a carga entre servidores com capacidades diferentes.

Aqui está o ponto importante. Tudo isso acontece automaticamente. Você configura o grupo de origem uma vez e o front-door cuida do resto. Ele testa seus servidores, mede a latência, respeita as prioridades e distribui o tráfego com base no peso. E ele faz tudo isso na borda antes mesmo que a solicitação chegue ao seu back-end. Isso significa que seus servidores não precisam descobrir de onde veio o tráfego como roteá-lo. Eles apenas entregam o conteúdo. Segurança na borda, ou af e além. Então agora vamos falar sobre segurança. Como o front-door fica na borda da rede da Microsoft é o local perfeito para impedir ataques antes mesmo que eles cheguem aos seus servidores. Pense nisso como uma verificação de segurança na entrada de um prédio. Qualquer um que queira entrar precisa passar por ali primeiro. Esse ponto de controle é chamado de firewall de aplicativo web, ou WF, e está integrado tanto ao front-door standard quanto ao premium.

Ele bloqueia ataques comuns ao web automaticamente. Coisas como injeção de SQL, onde um invasor tenta inserir comandos maliciosos de banco de dados em um campo de formulário, ou cross-site scripting, onde injetam scripts em suas páginas, ou ataques de DDoS, onde tentam sobrecarregar seus servidores com tráfego. O WF detecta tudo isso na borda e descarta antes mesmo que sua origem veja qualquer coisa. Além das proteções automáticas, você também pode criar regras personalizadas. Por exemplo, se o seu site é destinado apenas a clientes na Europa, você pode bloquear totalmente o tráfego de outras regiões. Ou talvez você tenha anotado uma faixa de IP específica que insiste em sondar seu site, você também pode bloqueá-la. Você também pode filtrar com base em cabeçalho sua licitação, padrão de URL, ou até mesmo navegador que alguém está usando. O WF oferece um controle muito específico sobre quem entra e quem não entra.

É aqui que os níveis de preço fazem a diferença. O standard oferece regras de WF personalizadas, onde você define o que bloquear e permitir. Premium vai além adicionando conjuntos de regras gerenciados baseados na inteligência contra ameaças da Microsoft que são constantemente atualizados com base em padrões de ataques reais que a Microsoft observa em toda a sua rede. Premium também inclui proteção contra bots, que bloqueia automaticamente scrapers, preenchimento de credenciais e outros bots. E adiciona suporte ao Private Link, que permite conectar-se às suas origens por uma conexão de rede privada em vez da internet pública. Isso significa que seus servidores de back-end podem ficar completamente ocultos do mundo exterior. Apenas o front-door pode alcançá-lo. Isso é muito importante para a segurança. Muitos ataques não visam o front-door. Eles têm que encontrar a porta dos fundos. Se o seu servidor de origem tem um endereço IP público, os invasores podem sondá-lo diretamente e ignorar todas as suas proteções do front-door.

Com o Private Link, isso não é possível, pois a origem não possui um ponto de extremidade público e só é acessível através do front-door. Portanto, mesmo que alguém descubra o IP do seu servidor, não conseguirá acessá-lo. O resultado é uma defesa em profundidade. O WAF bloqueia ataques na camada de aplicação. Regras personalizadas lidam com seus requisitos específicos. A proteção contra bots interrompe ameaças. E o Private Link mantém suas origens invisíveis. Tudo isso acontece na borda antes mesmo que o tráfego chegue à sua infraestrutura para que seus servidores permaneçam focados em fornecer conteúdo e não em combater ataques. Caching tornando as coisas ainda mais rápidas. Então abordamos o roteamento de segurança, mas há outro recurso que torna o front-door realmente útil, o caching. Grande parte do conteúdo do seu site não muda com frequência. Imagens, arquivos CSS, bibliotecas de Javascript, fotos de produtos, talvez até algumas páginas HTML.

Se cada visitante tiver que buscar esses dados no seu servidor de origem, você estará desperdiçando tempo e banda, pois o servidor precisa processar a mesma requisição repetidamente, enviando os mesmos bytes pela internet a cada vez. Cache resolve isso mantendo uma cópia do conteúdo estático no pop de borda. Na próxima vez que alguém solicitar o mesmo arquivo, o pop entrega instantaneamente, sem nunca contatar sua origem. É como ter um pequeno armazém ao lado de cada cabine de pedágio. Em vez de enviar cada cliente de volta à fábrica principal, você apenas entrega a eles o que já está na prateleira. A diferença é desempenho dramática. Em vez de uma viagem de ida e volta através do oceano, a resposta vem de um servidor na mesma cidade. Milissegundos em vez de segundos. E seu servidor de origem ganha uma folga, pois processa menos requisições e pode focar no conteúdo dinâmico, que realmente precisa de processamento.

Agora o cache não é automático para tudo. É controle que é armazenado em cache por quanto tempo? O front-door respeita cabeçalhos de controle de cache padrão da sua origem, como Maxage ou S-Maxage. Você também pode configurar regras de cache diretamente, substituindo os cabeçalhos da origem, se necessário. Quando você atualiza um conteúdo, pode limpar o cache e dizer ao front-door para descartar as copias antigas e buscar as outras. Isso é importante para coisas como lançamentos de produtos ou mudanças de preço, onde a nova versão precisa estar visível imediatamente. Aqui você pode. O front-door não é apenas para conteúdo estático. Mesmo para conteúdo dinâmico, como APIs, páginas personalizadas ou carrinhos de compra, ele ainda acelera a entrega, pois, uma vez que a requisição atinge o pop mais próximo, ela viaja até sua origem pela espinha dorsal privada da Microsoft em vez da internet pública.

Essa espinha dorsal privada é mais rápida e confiável que a web aberta. Portanto, até as requisições não armazenadas em cache recebem um aumento de velocidade. Essa é uma das principais diferenças entre o front-door e uma CDN tradicional. Ela armazena apenas conteúdo estático em cache, é basicamente isso. O front-door armazena conteúdo estático em cache e acelera todo o resto. Uma oferta 2.1. Níveis de preços, qual escolher? Muito bem, vamos falar de dinheiro, porque essa é a grande questão. Quanto isso custa? E qual nível você deve realmente escolher? Antes de entrarmos nos números, aqui está o motivo pelo qual isso importa. O nível que você escolhe não afeta apenas o preço. Ele também determina a segurança e os recursos disponíveis para proteger sua aplicação. O Azure Front Door vem em três versões. É o mais antigo. Ele ainda funciona, mas a Microsoft recomenda não usá-lo para novos projetos.

Qual está sendo descontinuado? Sem novos recursos após 2025 e aposentadoria total em 2027. Portanto, se você está começando do zero, deve considerar o standard ou o premium. Aqui está a explicação mais simples. O standard custa US$ 35 dólares por mês como taxa base. Premium custa US$ 330 dólares por mês. É um grande salto, mas aqui está a parte interessante. As taxas de transferência de dados por gigabyte são idênticas entre os dois níveis. Na América do Norte e na Europa, o tráfego de saída custa cerca de 8,25 centavos por gigabyte nos primeiros 10 terabytes. A transferência da borda para a origem custa cerca de 2 centavos por gigabyte. O mesmo preço para ambos. Então, o que esses US$ 300 dólares estas oferecem? Funcionaria. Premium adiciona regras de WAF gerenciadas, alimentadas pela inteligência contra ameaças da Microsoft, que são atualizadas automaticamente com base em padrões de ataque reais.

Você também obtém proteção contra bots, suporte a link privado para que sua origem permaneça oculta da internet pública e análises de segurança mais profundas. O standard oferece balanceamento de carga global, cash, aceleração dinâmica e regras de WAF personalizadas. Você pode bloquear faixas de IP, países ou padrões de solicitação. Você apenas não recebe os conjuntos de regras gerenciadas ou link privado. Acho que obras por solicitação também são diferentes. O standard custa cerca de 9 centavos por 10 mil solicitações nos primeiros 250 milhões. Premium custa cerca de 15 centavos por 10 mil. Em escala, essa diferença aumenta. Então, como você escolhe? Aqui está a minha regra prana. Se você está executando um site ou API comum, algo que precise desempenho global e segurança básica, comece pelo standard. A taxa base de US$ 35 dólares é acessível e as regras de WAF personalizadas lidam com a maioria das ameaças comuns.

Você sempre pode fazer o API de mais tarde suas necessidades de segurança. Se você atua em um setor regulamentado, como saúde, finanças, governo ou lida com dados confidenciais de clientes, o Premium vale o custo extra. As regras de WAF gerenciadas detectam ameaças que você não pensasse em bloquear. O link privado mantém suas origens invisíveis e a proteção contra bots interrompe ataques automatizados que o standard detectaria. Uma última coisa. Se você está apenas servindo conteúdo estático e não precisa de roteamento ou recursos de segurança, uma CDN tradicional pode ser mais barata. O Azure CDN da Microsoft ainda existe e, para a entrega puramente estática, geralmente é mais econômico. Mas, para a maioria das aplicações reais, onde você precisa de roteamento, segurança, cache e aceleração, o front-door standard é o ponto ideal. Juntando tudo, um exemplo do mundo real. Deixe-me conduzi-lo por um cenário real para que você possa ver exatamente como todas essas peças funcionam juntas.

Imagine que você gerencia um site de comércio eletor. Você tem servidores em três regiões, América do Norte, Europa e Ásia. Seus clientes estão em todos os lugares, do Japão ao Brasil e África do Sul. Sem o front-door, um cliente em Tóquio se conecta diretamente ao seu servidor no Zewa. Cada imagem, página de produto e solicitação de checkout específico. Excelento. E se o seu servidor no Zewa cair, o cliente verá apenas um erro. Agora adicione o front-door. O cliente em Tóquio abre o seu site. O navegador dele acessa o local do Azul e mais próximo, chama de Tóquio. Esse local verifica a integridade dos seus três servidores. Todos estão pressionados. Ele mede a latência. O servidor asiático responde mais rápido. Então ele roteia a solicitação para lá pela rede privada da Microsoft. A página carrega em menos de um segundo em vez de três. Agora imagine que o servidor asiático fique sobrecarregado durante uma promoção relã.

As sondas de integridade do front-door detectam um aumento da latência. Ele começa a transferir o tráfego para o servidor europeu, a próxima melhor opção. Os clientes ainda têm uma experiência rápida, talvez não tão rápida quanto no servidor asiático, mas ainda mais rápida do que ir até o Zewa. Tudo failover acontece automaticamente, sem que ninguém precise alterar qualquer configuração. Enquanto isso, o off é executado na borda. Ele bloqueia uma tentativa de injeção de SQL de uma botnet sondando seu formato de TICA. Ele bloqueia o tráfego de faixas de IP maniciosas conhecidas. Limita a taxa de solicitação de um IP que está extraindo dados do seu catálogo de produtos. Nenhum desses ataques chega aos seus servidores de origem. Sua equipe de back-end nem sabe que eles aconteceram. E o conteúdo estático, imagens de produtos, arquivos CSS, bibliotecas JavaScript são armazenados em cache no local de Tóquio.

O primeiro visitante os carrega da origem asiática. O segundo visitante os obtém do cache de borda instantaneamente. Visitantes recorrentes veem tempos de carregamento quase instantâneos porque tudo o que precisam já está no local de borda próximo a eles. Tudo isso, roteamento mais rápido, failover automático, segurança de borda e conteúdo em cache funcionando em conjunto perfeitamente. Seus clientes nunca saberão que isso existe. Eles apenas veem um site rápido confiar. Aqui está o que lembrar. O Azure Front Door atua como um guarda de trânsito global roteando usuários para o servidor mais rápido armazenando conteúdo em cache na borda e bloqueando ataques antes que cheguem a você. Ele é construído sobre três camadas de resiliência, portanto mesmo que uma região caia seu site permanece no ar. Para a maioria dos projetos o nível standard por apenas o S35 mensais é o ponto ideal entre desempenho e custo.

Atualize para o premium quando precisar de segurança avançada ou link privado. Comece pequeno com uma única origem e cresça a partir daí. Front Door escala com você. Seu aplicativo web tem usuários espalhados por várias regiões que configuram o perfil do Front Door hoje mesmo. Até mesmo um único servidor obtém aceleração global e benefícios de segurança. Inscreva-se em sua plataforma de podcast favorita e compartilhe isso com alguém que esteja começando sua jornada na nua.