Azure Front Door e Traffic Manager para Failover

Neste artigo você vai configurar o azure front door failover e o Traffic Manager para orquestrar o tráfego de entrada da Landing Zone multi-região, garantindo que uma falha em Brazil South redirecione automaticamente para East US — sem intervenção manual. Vamos implantar o Azure Front Door Premium com WAF e o Traffic Manager com roteamento por prioridade, ambos apontando para os IPs públicos dos Azure Firewalls criados no Art. 03, usando Terraform com remote state.

Sumário

• Front Door vs Traffic Manager — quando usar cada um
• Arquitetura do lab
• Pré-requisitos
• Variáveis de ambiente
• Passo 1 — Azure Front Door com WAF
• Passo 2 — Traffic Manager com roteamento por prioridade
• Passo 3 — Executar o Terraform
• Como funciona o failover automático
• Verificar a configuração
• Testar o failover
• Troubleshooting
• Limpeza dos recursos
• Próximos passos

Front Door vs Traffic Manager — quando usar cada um

Azure Front Door e Traffic Manager são frequentemente confundidos por fazerem roteamento global, mas atuam em camadas diferentes e têm casos de uso distintos. Entender essa diferença é essencial para projetar o azure front door failover corretamente na Landing Zone.

Característica	Azure Front Door	Traffic Manager
Camada	L7 (HTTP/HTTPS) — anycast global	L4/DNS — resolução DNS
Protocolo	HTTP e HTTPS apenas	Qualquer protocolo TCP/UDP
Failover RTO	Segundos (health probe + anycast)	Minutos (TTL do DNS)
WAF integrado	✅ (Bot protection, OWASP rules)	❌
Cache / CDN	✅ (edge caching global)	❌
SSL Offload	✅	❌
Custo	Alto (perfil Premium ~$330/mês base)	Baixo (~$0.54/milhão de queries)
Ideal para	Workloads HTTP, apps web, APIs	Endpoints não-HTTP, failover DNS, RTO relaxado

Para este lab, usamos os dois em paralelo para fins didáticos: o Front Door cobre workloads HTTP com WAF, enquanto o Traffic Manager demonstra o failover por DNS — útil para serviços como banco de dados ou qualquer endpoint TCP que o Front Door não suporta.

Arquitetura do lab

O azure front door failover e o Traffic Manager apontam para os IPs públicos dos Azure Firewalls criados no Art. 03. O Firewall atua como ponto de entrada único em cada região — o Front Door e o Traffic Manager apenas decidem qual região recebe o tráfego em cada momento.

Recurso	Tipo	Origem (prioridade 1)	Origem (prioridade 2)
afd-blog-castilho	Front Door Premium	pip-afw-blog-castilho-brazilsouth	pip-afw-blog-castilho-eastus
tm-blog-castilho	Traffic Manager (Priority)	pip-afw-blog-castilho-brazilsouth	pip-afw-blog-castilho-eastus

Em operação normal, 100% do tráfego vai para Brazil South (priority 1). Quando o health probe detecta falha no Firewall primário, o tráfego migra automaticamente para East US (priority 2) sem intervenção manual.

Pré-requisitos

• Azure Firewall implantado em ambas as regiões (Art. 03) — IPs públicos pip-afw-blog-castilho-brazilsouth e pip-afw-blog-castilho-eastus existentes
• Terraform ≥ 1.5 e Azure CLI autenticado
• Storage Account de remote state configurado (bootstrap do Art. 02)
• Permissão Contributor no Resource Group rg-blog-castilho-network-brazilsouth

Variáveis de ambiente

export AZURE_SUBSCRIPTION_ID="<SUBSCRIPTION_ID>"
export TF_STATE_RG="rg-blog-castilho-tfstate"
export TF_STATE_SA="<storage-account-name>"
export TF_STATE_CONTAINER="tfstate"

Passo 1 — Azure Front Door com WAF

O azure front door failover com WAF Premium reúne vários recursos em um único deployment Terraform: o perfil CDN, a WAF policy, o endpoint, o origin group com health probe, as duas origens por região e a rota. Veja o main.tf completo:

data "azurerm_resource_group" "this" {
  name = "rg-blog-castilho-network-brazilsouth"
}

data "azurerm_public_ip" "firewall_brazilsouth" {
  name                = "pip-afw-blog-castilho-brazilsouth"
  resource_group_name = "rg-blog-castilho-network-brazilsouth"
}

data "azurerm_public_ip" "firewall_eastus" {
  name                = "pip-afw-blog-castilho-eastus"
  resource_group_name = "rg-blog-castilho-network-eastus"
}

resource "azurerm_cdn_frontdoor_profile" "this" {
  name                = "afd-blog-castilho"
  resource_group_name = data.azurerm_resource_group.this.name
  sku_name            = "Premium_AzureFrontDoor"
  tags                = var.tags
}

resource "azurerm_cdn_frontdoor_firewall_policy" "this" {
  name                = "wafblogcastilho"
  resource_group_name = data.azurerm_resource_group.this.name
  sku_name            = azurerm_cdn_frontdoor_profile.this.sku_name
  enabled             = true
  mode                = var.waf_mode   # "Prevention"
  tags                = var.tags
}

resource "azurerm_cdn_frontdoor_endpoint" "this" {
  name                     = "ep-blog-castilho"
  cdn_frontdoor_profile_id = azurerm_cdn_frontdoor_profile.this.id
  tags                     = var.tags
}

resource "azurerm_cdn_frontdoor_origin_group" "this" {
  name                     = "og-blog-castilho"
  cdn_frontdoor_profile_id = azurerm_cdn_frontdoor_profile.this.id
  session_affinity_enabled = false

  load_balancing {
    sample_size                        = 4
    successful_samples_required        = 3
    additional_latency_in_milliseconds = 50
  }

  health_probe {
    path                = "/health"
    protocol            = "Https"
    interval_in_seconds = 30
    request_type        = "GET"
  }
}

resource "azurerm_cdn_frontdoor_origin" "brazilsouth" {
  name                           = "origin-brazilsouth"
  cdn_frontdoor_origin_group_id  = azurerm_cdn_frontdoor_origin_group.this.id
  host_name                      = data.azurerm_public_ip.firewall_brazilsouth.ip_address
  origin_host_header             = data.azurerm_public_ip.firewall_brazilsouth.ip_address
  http_port                      = 80
  https_port                     = 443
  priority                       = 1
  weight                         = 1000
  enabled                        = true
  certificate_name_check_enabled = false
}

resource "azurerm_cdn_frontdoor_origin" "eastus" {
  name                           = "origin-eastus"
  cdn_frontdoor_origin_group_id  = azurerm_cdn_frontdoor_origin_group.this.id
  host_name                      = data.azurerm_public_ip.firewall_eastus.ip_address
  origin_host_header             = data.azurerm_public_ip.firewall_eastus.ip_address
  http_port                      = 80
  https_port                     = 443
  priority                       = 2
  weight                         = 1000
  enabled                        = true
  certificate_name_check_enabled = false
}

resource "azurerm_cdn_frontdoor_route" "this" {
  name                          = "route-blog-castilho"
  cdn_frontdoor_endpoint_id     = azurerm_cdn_frontdoor_endpoint.this.id
  cdn_frontdoor_origin_group_id = azurerm_cdn_frontdoor_origin_group.this.id
  cdn_frontdoor_origin_ids = [
    azurerm_cdn_frontdoor_origin.brazilsouth.id,
    azurerm_cdn_frontdoor_origin.eastus.id,
  ]
  https_redirect_enabled = true
  patterns_to_match      = ["/*"]
  supported_protocols    = ["Http", "Https"]
  forwarding_protocol    = "HttpsOnly"
  link_to_default_domain = true
}

resource "azurerm_cdn_frontdoor_security_policy" "this" {
  name                     = "secpolicy-blog-castilho"
  cdn_frontdoor_profile_id = azurerm_cdn_frontdoor_profile.this.id

  security_policies {
    firewall {
      cdn_frontdoor_firewall_policy_id = azurerm_cdn_frontdoor_firewall_policy.this.id
      association {
        domain {
          cdn_frontdoor_domain_id = azurerm_cdn_frontdoor_endpoint.this.id
        }
        patterns_to_match = ["/*"]
      }
    }
  }
}

Entendendo o origin group

O origin_group controla como o Front Door decide para qual origem enviar o tráfego. Os parâmetros de load_balancing definem o comportamento de failover:

Parâmetro	Valor	Significado
sample_size	4	Número de health probes avaliadas por ciclo
successful_samples_required	3	Mínimo de probes bem-sucedidas para considerar origem saudável
additional_latency_in_milliseconds	50	Latência aceitável além da melhor origem — evita flapping
interval_in_seconds	30	Intervalo entre health probes
priority (origin)	1 ou 2	Menor número = preferência — todos os requests vão para priority 1 se saudável

Passo 2 — Traffic Manager com roteamento por prioridade

O Traffic Manager usa roteamento por DNS — quando o cliente resolve o FQDN do perfil, o Traffic Manager responde com o IP da origem de maior prioridade que esteja saudável. Portanto, o failover do Traffic Manager depende do TTL configurado: com TTL de 30 segundos, o failover pode levar até 30 segundos após a detecção da falha.

resource "azurerm_traffic_manager_profile" "this" {
  name                   = "tm-blog-castilho"
  resource_group_name    = data.azurerm_resource_group.this.name
  traffic_routing_method = "Priority"

  dns_config {
    relative_name = "tm-blog-castilho"
    ttl           = var.ttl   # 30 segundos
  }

  monitor_config {
    protocol                     = "HTTPS"
    port                         = 443
    path                         = "/health"
    interval_in_seconds          = 30
    timeout_in_seconds           = 9
    tolerated_number_of_failures = 3
  }

  tags = var.tags
}

resource "azurerm_traffic_manager_external_endpoint" "brazilsouth" {
  name       = "endpoint-brazilsouth"
  profile_id = azurerm_traffic_manager_profile.this.id
  target     = data.azurerm_public_ip.firewall_brazilsouth.ip_address
  priority   = 1
  weight     = 100
}

resource "azurerm_traffic_manager_external_endpoint" "eastus" {
  name       = "endpoint-eastus"
  profile_id = azurerm_traffic_manager_profile.this.id
  target     = data.azurerm_public_ip.firewall_eastus.ip_address
  priority   = 2
  weight     = 100
}

O tolerated_number_of_failures = 3 significa que o Traffic Manager precisa detectar 3 falhas consecutivas antes de marcar o endpoint como degradado. Com intervalo de 30 segundos e 3 falhas, o tempo mínimo de detecção é de 90 segundos — por isso, para aplicações com SLA rigoroso, o Front Door é mais indicado.

Passo 3 — Executar o Terraform

# Front Door
cd scripts/art-05-front-door-traffic-manager/afd-blog-castilho

cat > backend.hcl <<EOF
resource_group_name  = "$TF_STATE_RG"
storage_account_name = "$TF_STATE_SA"
container_name       = "$TF_STATE_CONTAINER"
key                  = "afd-blog-castilho.tfstate"
EOF

terraform init -backend-config=backend.hcl -reconfigure
terraform apply -var subscription_id="$AZURE_SUBSCRIPTION_ID"

# Traffic Manager
cd scripts/art-05-front-door-traffic-manager/tm-blog-castilho

cat > backend.hcl <<EOF
resource_group_name  = "$TF_STATE_RG"
storage_account_name = "$TF_STATE_SA"
container_name       = "$TF_STATE_CONTAINER"
key                  = "tm-blog-castilho.tfstate"
EOF

terraform init -backend-config=backend.hcl -reconfigure
terraform apply -var subscription_id="$AZURE_SUBSCRIPTION_ID"

O azure front door failover demora entre 5 e 15 minutos para provisionar — a propagação dos nós de edge é global. O Traffic Manager é quase imediato.

Como funciona o failover automático

Com o azure front door failover configurado por prioridade, o comportamento é determinístico: enquanto a origem de priority 1 (Brazil South) responder com 2xx ou 3xx no endpoint /health, todo o tráfego é direcionado para ela. Ao detectar falha, o Front Door redireciona para priority 2 sem alterar o DNS do cliente.

Cenário	Front Door	Traffic Manager
Brazil South saudável	100% → BRS	DNS resolve → BRS IP
BRS falha detectada	Segundos — anycast redireciona	~90s detecção + TTL (30s) propagação
BRS volta a funcionar	Automático após probes OK	Automático após TTL expirar
Transparente para o cliente	✅ (IP do Front Door não muda)	❌ (cliente precisa re-resolver DNS)

Verificar a configuração

# Verificar Front Door
az afd profile show \
  --resource-group rg-blog-castilho-network-brazilsouth \
  --profile-name afd-blog-castilho \
  --query "{name:name, sku:sku.name, provisioningState:provisioningState}" \
  --output table

# Exemplo de output esperado:
# Name               Sku                      ProvisioningState
# -----------------  -----------------------  -----------------
# afd-blog-castilho  Premium_AzureFrontDoor   Succeeded

# Verificar endpoint e hostname do Front Door
az afd endpoint list \
  --resource-group rg-blog-castilho-network-brazilsouth \
  --profile-name afd-blog-castilho \
  --query "[].{name:name, hostname:hostName}" \
  --output table

# Exemplo de output esperado:
# Name               Hostname
# -----------------  ---------------------------------------------------
# ep-blog-castilho   ep-blog-castilho-c5f5fza3a6b6d9e4.z01.azurefd.net

# Verificar origens
az afd origin list \
  --resource-group rg-blog-castilho-network-brazilsouth \
  --profile-name afd-blog-castilho \
  --origin-group-name og-blog-castilho \
  --query "[].{name:name, host:hostName, priority:priority, enabled:enabledState}" \
  --output table

# Verificar Traffic Manager
az network traffic-manager profile show \
  --resource-group rg-blog-castilho-network-brazilsouth \
  --name tm-blog-castilho \
  --query "{name:name, routing:trafficRoutingMethod, status:profileStatus, fqdn:dnsConfig.fqdn}" \
  --output table

# Verificar endpoints do Traffic Manager
az network traffic-manager endpoint list \
  --resource-group rg-blog-castilho-network-brazilsouth \
  --profile-name tm-blog-castilho \
  --query "[].{name:name, target:target, priority:priority, status:endpointStatus}" \
  --output table

# Exemplo de output esperado:
# Name                  Target          Priority    Status
# --------------------  --------------  ----------  -------
# endpoint-brazilsouth  <BRS_IP>        1           Enabled
# endpoint-eastus       <EUS_IP>        2           Enabled

Testar o failover

Para testar o azure front door failover e simular uma falha de região no Traffic Manager sem derrubar a infra real, desabilite o endpoint primário diretamente via CLI:

# Desabilitar endpoint primário (simula falha de região)
az network traffic-manager endpoint update \
  --resource-group rg-blog-castilho-network-brazilsouth \
  --profile-name tm-blog-castilho \
  --name endpoint-brazilsouth \
  --type externalEndpoints \
  --endpoint-status Disabled

# Verificar resolução DNS (aguardar até ~60s para propagação)
nslookup tm-blog-castilho.trafficmanager.net
# Output esperado: deve resolver para o IP de East US

# Restaurar endpoint primário
az network traffic-manager endpoint update \
  --resource-group rg-blog-castilho-network-brazilsouth \
  --profile-name tm-blog-castilho \
  --name endpoint-brazilsouth \
  --type externalEndpoints \
  --endpoint-status Enabled

Para o azure front door failover, o teste é feito desabilitando o origin, não o endpoint:

# Desabilitar origin primário no Front Door
az afd origin update \
  --resource-group rg-blog-castilho-network-brazilsouth \
  --profile-name afd-blog-castilho \
  --origin-group-name og-blog-castilho \
  --origin-name origin-brazilsouth \
  --enabled-state Disabled

# Aguardar ~60s e verificar que o tráfego vai para East US
# Restaurar
az afd origin update \
  --resource-group rg-blog-castilho-network-brazilsouth \
  --profile-name afd-blog-castilho \
  --origin-group-name og-blog-castilho \
  --origin-name origin-brazilsouth \
  --enabled-state Enabled

Troubleshooting

Erro	Causa	Solução
Origin marcado como degradado imediatamente	Endpoint /health não existe ou retorna 4xx/5xx	Configure a rota /health no Firewall ou mude o path da health probe para /
FrontDoorNameNotAvailable	Nome do perfil Front Door já em uso globalmente	Nomes de Front Door são globais — altere o nome no Terraform
Traffic Manager sempre resolve para EUS	Endpoint BRS marcado como degradado	Verifique se o Firewall de BRS tem regra permitindo HTTPS 443 na health probe
SkuNotSupported no WAF	SKU do WAF não compatível com o perfil	WAF do Front Door exige Premium_AzureFrontDoor no perfil — confirme o sku_name
Failover não ocorre no Front Door	successful_samples_required muito alto	Reduza para 2 em ambiente de lab para failover mais rápido

Limpeza dos recursos

cd scripts/art-05-front-door-traffic-manager/afd-blog-castilho
terraform destroy -var subscription_id="$AZURE_SUBSCRIPTION_ID"

cd scripts/art-05-front-door-traffic-manager/tm-blog-castilho
terraform destroy -var subscription_id="$AZURE_SUBSCRIPTION_ID"

Próximos passos

Com o azure front door failover e o Traffic Manager configurados, a camada de entrada da Landing Zone está completa. O próximo artigo aborda o DNS Privado Multi-Região — configurando zonas DNS privadas para resolução interna entre Hub e Spokes em Brazil South e East US, sem expor nomes internos à internet.

Interessado em saber mais sobre artigos relacionados ao Microsoft Azure CLIQUE AQUI

🚀 Vamos nos conectar?

Não perca nenhuma oportunidade! Cadastre-se nas minhas redes e no canal do YouTube para receber conteúdos de TI, Cloud, Azure, Kubernetes e DevOps em primeira mão.

📺 YouTube: Jefferson Castilho – MVP💼 LinkedIn: Jefferson Castilho 👥 Facebook: Jefferson Castilho

Dica: No Facebook, todos os artigos do blog são publicados automaticamente. Vale a pena curtir!

---

💬 Dúvidas ou Problemas?

Com o intuito de ajudar a comunidade, caso você tenha dúvidas ou encontre problemas na execução dos comandos deste artigo, deixe um comentário abaixo. Responderei o mais breve possível!

Muito obrigado pela visita e até o próximo post!

Jefferson Castilho Especialista em Cloud & DevOps.

---

Este guia técnico é exclusivo do Blog do Castilho. Explore nossa para mais conteúdos sobre IA e Cloud.