Fundamentação Teórica: Configure Scaling for an App Service Plan

---

1. Intuição Inicial

Imagine que você tem um restaurante. O restaurante tem uma cozinha (o App Service Plan) e vários pratos no menu (os Web Apps, APIs, Function Apps hospedados nele). A cozinha define a capacidade máxima de produção: quantos chefs estão disponíveis, qual o equipamento disponível. Se a demanda aumentar, você pode:

• Escalar verticalmente (scale up): trocar sua cozinha pequena por uma maior, com equipamentos melhores e mais chefs
• Escalar horizontalmente (scale out): abrir cozinhas idênticas em paralelo, cada uma com o mesmo equipamento

No Azure App Service, o App Service Plan é exatamente essa cozinha: ele define os recursos de infraestrutura (CPU, memória, número de instâncias) que todos os apps hospedados nele compartilham. Configurar scaling para um App Service Plan significa definir as regras que determinam quando e como essa cozinha cresce ou encolhe.

---

2. Contexto

A relação entre App Service Plan e Apps

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Ponto crítico: todos os apps dentro de um App Service Plan compartilham os mesmos recursos. Se o Plan tem 3 instâncias e o Web App consome todo o CPU de uma instância, os outros apps no mesmo Plan são afetados. Essa é a razão pela qual apps de diferentes criticidades devem estar em Plans separados.

Por que configurar scaling é importante

O App Service Plan tem um custo fixo baseado no tier e no número de instâncias, independente de quantas requisições os apps recebem. Sem scaling automático:

• Você provisiona para o pico: gasta o mês inteiro pelo custo máximo
• Você provisiona para a média: durante picos, os apps ficam lentos ou indisponíveis

Com scaling automático bem configurado, o Plan cresce durante picos e encolhe nas horas de baixa demanda, otimizando custo e performance simultaneamente.

---

3. Construção dos Conceitos

3.1 Tiers do App Service Plan e capacidade de scaling

O tier do App Service Plan determina o que é possível em termos de scaling:

Tier	Scale Up (SKUs)	Scale Out (instâncias)	Auto Scale	Slots de Deploy
Free (F1)	Não	1 (fixo)	Não	0
Shared (D1)	Não	1 (fixo)	Não	0
Basic (B1/B2/B3)	Sim	Até 3	Manual apenas	0
Standard (S1/S2/S3)	Sim	Até 10	Sim	5
Premium v3 (P0v3 a P3v3)	Sim	Até 30	Sim	20
Isolated v2 (I1v2 a I3v2)	Sim	Até 100	Sim	20

Auto Scaling (scaling automático) só está disponível a partir do tier Standard. Os tiers Free, Shared e Basic suportam apenas scaling manual.

3.2 Scale Up vs. Scale Out

Scale Up (Escalonamento Vertical): muda o SKU do App Service Plan para um com mais CPU e memória. Por exemplo, de B1 (1 vCPU, 1.75 GB) para P2v3 (2 vCPU, 8 GB). Todos os apps no Plan imediatamente recebem mais recursos.

Scale Out (Escalonamento Horizontal): aumenta o número de instâncias do App Service Plan. Com 3 instâncias, os apps têm 3 workers processando requisições em paralelo. O Azure distribui automaticamente as requisições entre as instâncias.

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

3.3 Manual Scaling vs. Auto Scaling

Manual Scaling: você define um número fixo de instâncias. O Plan mantém exatamente esse número indefinidamente, independente da carga.

Auto Scaling: o Azure ajusta automaticamente o número de instâncias baseado em regras ou métricas. É composto por:

Scale-out rule (quando adicionar instâncias): condição que dispara aumento de instâncias Scale-in rule (quando remover instâncias): condição que dispara redução de instâncias Min/Max instances: limites que o auto scaling respeita Default capacity: número de instâncias quando nenhuma regra ativa

3.4 Tipos de Auto Scaling no App Service

O App Service tem dois motores de auto scaling que precisam ser distinguidos:

Classic Autoscale (Azure Monitor Autoscale):

• Baseado em métricas do Azure Monitor
• Regras customizáveis de CPU, memória, métricas customizadas
• Cooldown configurável
• Scheduling (escalar em horários específicos)
• Disponível em Standard e acima

Automatic Scaling (preview/GA em 2024):

• Novo mecanismo nativo do App Service
• Baseado em requisições HTTP concorrentes
• Mais simples, sem necessidade de configurar regras explícitas
• O Azure gerencia automaticamente o scaling baseado no tráfego
• Disponível apenas em Premium v3 e Isolated v2

Para o AZ-104, o foco é no Classic Autoscale que é mais amplamente disponível e mais frequentemente cobrado.

3.5 Estrutura de uma regra de Auto Scale (Classic)

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

3.6 Profiles de Auto Scale

Um Profile agrupa regras e capacidades para um contexto específico. Existem três tipos:

Default Profile: sempre ativo quando nenhum outro profile se aplica. Toda configuração de autoscale deve ter um profile default.

Fixed Date Profile: ativo em uma data/período específico (ex: Black Friday 25/11). Substitui o default durante aquele período.

Recurrence Profile: ativo em horários recorrentes (ex: segunda a sexta das 8h às 18h). Substitui o default nesses períodos.

---

4. Visão Estrutural

Fluxo completo de scaling no App Service

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Hierarquia de scaling no App Service

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

---

5. Funcionamento na Prática

Quando as regras são avaliadas

O Auto Scale Engine avalia as regras a cada 30-60 segundos. Para cada avaliação, ele verifica se alguma condição de scale-out ou scale-in é verdadeira e age conforme as regras.

Comportamento com múltiplas regras de scale-out: Se QUALQUER regra de scale-out for verdadeira, o scaling ocorre. As regras de scale-out são combinadas com lógica OR: basta uma ser verdadeira.

Comportamento com múltiplas regras de scale-in: TODAS as regras de scale-in devem ser verdadeiras simultaneamente para que o scale-in ocorra. As regras de scale-in são combinadas com lógica AND: todas devem ser verdadeiras.

Este comportamento assimétrico é intencional: o Azure é conservador no scale-in para evitar remover instâncias precipitadamente.

Cooldown e Flap Avoidance

O cooldown é o período após uma ação de scaling durante o qual nenhuma nova ação de scaling é tomada. Isso evita oscilações rápidas (scale-out, scale-in, scale-out em sequência rápida).

Por padrão:

• Cooldown de scale-out: 5 minutos
• Cooldown de scale-in: 5 minutos

Para workloads com picos muito rápidos, pode ser necessário reduzir o cooldown de scale-out.

Comportamentos não óbvios

Scale Up requer uma breve reinicialização dos apps. Ao mudar o SKU do App Service Plan, os workers são realocados para hardware diferente. Os apps sofrem uma breve interrupção durante essa transição. Use deployment slots para zero-downtime durante scale-up.

Scale out não requer reinicialização. Adicionar instâncias é transparente para os apps. Novas instâncias são criadas em paralelo e começam a receber tráfego do load balancer sem interromper as existentes.

Todos os apps no Plan sobem juntos durante scale out. Se o Plan tem 3 apps e escala de 2 para 3 instâncias, todos os 3 apps passam a ter 3 instâncias. Não é possível fazer um app ter 3 instâncias e outro ter 2 no mesmo Plan.

O App Service Plan cobra pelo número de instâncias, não pelo uso. Um Plan P2v3 com 3 instâncias ativas cobra pelo mesmo valor quer as instâncias estejam com 100% de CPU ou 0%. Auto scaling não reduz custo durante picos, mas reduz custo durante vales ao fazer scale-in para o mínimo.

O profile default é o fallback, não o principal. Uma confusão comum: o "default" profile é ativado quando nenhum outro profile (de horário ou data específica) se aplica. É o estado base, não uma configuração especial.

Metrics disponíveis para scaling

Métrica	Nome no Azure	Uso típico
CPU Percentage	CpuPercentage	Mais comum; escala em carga de processamento
Memory Percentage	MemoryPercentage	Escala quando apps consomem muita memória
Disk Queue Length	DiskQueueLength	I/O intensivo
Http Queue Length	HttpQueueLength	Requisições esperando worker disponível
Bytes Received	BytesReceived	Escala por volume de tráfego de entrada
Bytes Sent	BytesSent	Escala por volume de resposta

HttpQueueLength é frequentemente a métrica mais útil para apps web: ela indica que há requisições esperando na fila do IIS/Kestrel porque não há workers disponíveis. Quando essa métrica cresce, é sinal claro que mais instâncias são necessárias.

---

6. Formas de Implementação

Portal do Azure

Quando usar: configuração inicial, ajustes pontuais, visualização do histórico de scaling

Para Scale Up (mudar SKU):

1. Portal > App Service Plan > Scale up (App Service plan)
2. Selecionar o novo tier/SKU
3. Apply

Para Scale Out manual:

1. Portal > App Service Plan > Scale out (App Service plan)
2. Selecionar Manual scale
3. Definir número de instâncias
4. Save

Para Auto Scale:

1. Portal > App Service Plan > Scale out (App Service plan)
2. Selecionar Custom autoscale
3. Definir Min/Max/Default instances
4. Adicionar regra de scale-out:
   • Metric source: App Service Plan
   • Metric: CpuPercentage
   • Operator: Greater than
   • Threshold: 75
   • Duration: 5 minutes
   • Action: Increase count by 2
   • Cool down: 5 minutes
5. Adicionar regra de scale-in (simétrica)
6. Save

---

Azure CLI

# Scale Up: mudar o SKU do App Service Plan
az appservice plan update \
  --resource-group "rg-webapp" \
  --name "asp-producao" \
  --sku P2V3

# Scale Out manual: definir número fixo de instâncias
az appservice plan update \
  --resource-group "rg-webapp" \
  --name "asp-producao" \
  --number-of-workers 3

# Ver configuração atual do App Service Plan
az appservice plan show \
  --resource-group "rg-webapp" \
  --name "asp-producao" \
  --query "{SKU: sku.name, Workers: sku.capacity, Tier: sku.tier}" \
  --output json

# Configurar Autoscale via Azure Monitor
ASP_ID=$(az appservice plan show \
  --resource-group "rg-webapp" \
  --name "asp-producao" \
  --query "id" --output tsv)

# Criar configuração de autoscale com perfil default
az monitor autoscale create \
  --resource-group "rg-webapp" \
  --resource "$ASP_ID" \
  --resource-type "Microsoft.Web/serverFarms" \
  --name "autoscale-asp-producao" \
  --min-count 2 \
  --max-count 10 \
  --count 3

# Adicionar regra de scale-out (CPU > 75%)
az monitor autoscale rule create \
  --resource-group "rg-webapp" \
  --autoscale-name "autoscale-asp-producao" \
  --scale out 2 \
  --condition "CpuPercentage > 75 avg 5m"

# Adicionar regra de scale-in (CPU < 25%)
az monitor autoscale rule create \
  --resource-group "rg-webapp" \
  --autoscale-name "autoscale-asp-producao" \
  --scale in 1 \
  --condition "CpuPercentage < 25 avg 10m"

# Adicionar regra baseada em HttpQueueLength
az monitor autoscale rule create \
  --resource-group "rg-webapp" \
  --autoscale-name "autoscale-asp-producao" \
  --scale out 3 \
  --condition "HttpQueueLength > 100 avg 3m"

# Criar profile de horário comercial (mais instâncias de seg a sex)
az monitor autoscale profile create \
  --autoscale-name "autoscale-asp-producao" \
  --resource-group "rg-webapp" \
  --name "horario-comercial" \
  --min-count 4 \
  --max-count 10 \
  --count 4 \
  --start "2026-01-01 08:00" \
  --end "2027-12-31 18:00" \
  --recurrence week mo tu we th fr \
  --timezone "E. South America Standard Time"

# Criar profile de Black Friday (data específica, mais capacidade)
az monitor autoscale profile create \
  --autoscale-name "autoscale-asp-producao" \
  --resource-group "rg-webapp" \
  --name "black-friday-2026" \
  --min-count 8 \
  --max-count 20 \
  --count 10 \
  --start "2026-11-27 00:00" \
  --end "2026-11-28 23:59" \
  --timezone "E. South America Standard Time"

# Ver histórico de scaling
az monitor autoscale history \
  --resource-group "rg-webapp" \
  --name "autoscale-asp-producao" \
  --output table

# Verificar configuração atual de autoscale
az monitor autoscale show \
  --resource-group "rg-webapp" \
  --name "autoscale-asp-producao" \
  --output json

# Desabilitar autoscale temporariamente (mantém as regras)
az monitor autoscale update \
  --resource-group "rg-webapp" \
  --name "autoscale-asp-producao" \
  --enabled false

# Reabilitar autoscale
az monitor autoscale update \
  --resource-group "rg-webapp" \
  --name "autoscale-asp-producao" \
  --enabled true

---

Azure PowerShell

# Scale Up: mudar SKU
Set-AzAppServicePlan `
  -ResourceGroupName "rg-webapp" `
  -Name "asp-producao" `
  -Tier "PremiumV3" `
  -WorkerSize "Medium"  # P2v3

# Scale Out manual
Set-AzAppServicePlan `
  -ResourceGroupName "rg-webapp" `
  -Name "asp-producao" `
  -NumberofWorkers 3

# Criar regras de autoscale
$aspId = (Get-AzAppServicePlan -ResourceGroupName "rg-webapp" -Name "asp-producao").Id

# Regra de scale-out
$scaleOutRule = New-AzAutoscaleRule `
  -MetricName "CpuPercentage" `
  -MetricResourceId $aspId `
  -TimeGrain ([TimeSpan]::FromMinutes(1)) `
  -Statistic Average `
  -TimeWindow ([TimeSpan]::FromMinutes(5)) `
  -TimeAggregationOperator Average `
  -Operator GreaterThan `
  -Threshold 75 `
  -ScaleActionCooldown ([TimeSpan]::FromMinutes(5)) `
  -ScaleActionDirection Increase `
  -ScaleActionValue 2 `
  -ScaleActionType ChangeCount

# Regra de scale-in
$scaleInRule = New-AzAutoscaleRule `
  -MetricName "CpuPercentage" `
  -MetricResourceId $aspId `
  -TimeGrain ([TimeSpan]::FromMinutes(1)) `
  -Statistic Average `
  -TimeWindow ([TimeSpan]::FromMinutes(10)) `
  -TimeAggregationOperator Average `
  -Operator LessThan `
  -Threshold 25 `
  -ScaleActionCooldown ([TimeSpan]::FromMinutes(5)) `
  -ScaleActionDirection Decrease `
  -ScaleActionValue 1 `
  -ScaleActionType ChangeCount

# Profile default
$profile = New-AzAutoscaleProfile `
  -DefaultCapacity 3 `
  -MaximumCapacity 10 `
  -MinimumCapacity 2 `
  -Rule @($scaleOutRule, $scaleInRule) `
  -Name "default"

# Aplicar configuração de autoscale
Add-AzAutoscaleSetting `
  -ResourceGroupName "rg-webapp" `
  -Location "brazilsouth" `
  -Name "autoscale-asp-producao" `
  -TargetResourceId $aspId `
  -AutoscaleProfile $profile

---

Bicep

// App Service Plan
resource appServicePlan 'Microsoft.Web/serverfarms@2022-09-01' = {
  name: 'asp-producao'
  location: 'brazilsouth'
  sku: {
    name: 'P2V3'
    tier: 'PremiumV3'
    capacity: 3  // Número inicial de instâncias
  }
  properties: {
    reserved: false  // false = Windows; true = Linux
  }
}

// Autoscale Settings
resource autoscale 'Microsoft.Insights/autoscaleSettings@2022-10-01' = {
  name: 'autoscale-asp-producao'
  location: 'brazilsouth'
  properties: {
    enabled: true
    targetResourceUri: appServicePlan.id
    profiles: [
      {
        name: 'default'
        capacity: {
          default: '3'
          minimum: '2'
          maximum: '10'
        }
        rules: [
          // Scale-out: CPU > 75% por 5 minutos
          {
            metricTrigger: {
              metricName: 'CpuPercentage'
              metricResourceUri: appServicePlan.id
              timeGrain: 'PT1M'
              statistic: 'Average'
              timeWindow: 'PT5M'
              timeAggregation: 'Average'
              operator: 'GreaterThan'
              threshold: 75
            }
            scaleAction: {
              direction: 'Increase'
              type: 'ChangeCount'
              value: '2'
              cooldown: 'PT5M'
            }
          }
          // Scale-out: HttpQueueLength > 100 por 3 minutos
          {
            metricTrigger: {
              metricName: 'HttpQueueLength'
              metricResourceUri: appServicePlan.id
              timeGrain: 'PT1M'
              statistic: 'Average'
              timeWindow: 'PT3M'
              timeAggregation: 'Average'
              operator: 'GreaterThan'
              threshold: 100
            }
            scaleAction: {
              direction: 'Increase'
              type: 'ChangeCount'
              value: '3'
              cooldown: 'PT3M'
            }
          }
          // Scale-in: CPU < 25% por 10 minutos
          {
            metricTrigger: {
              metricName: 'CpuPercentage'
              metricResourceUri: appServicePlan.id
              timeGrain: 'PT1M'
              statistic: 'Average'
              timeWindow: 'PT10M'
              timeAggregation: 'Average'
              operator: 'LessThan'
              threshold: 25
            }
            scaleAction: {
              direction: 'Decrease'
              type: 'ChangeCount'
              value: '1'
              cooldown: 'PT10M'
            }
          }
        ]
      }
      // Profile para horário comercial
      {
        name: 'horario-comercial'
        capacity: {
          default: '4'
          minimum: '4'
          maximum: '15'
        }
        rules: []  // Sem regras adicionais; escala fixo em 4 durante o horário
        recurrence: {
          frequency: 'Week'
          schedule: {
            timeZone: 'E. South America Standard Time'
            days: ['Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday']
            hours: [8]
            minutes: [0]
          }
        }
      }
    ]
  }
}

---

7. Controle e Segurança

Monitorar e auditar decisões de scaling

# Ver histórico de eventos de scaling
az monitor autoscale history \
  --resource-group "rg-webapp" \
  --name "autoscale-asp-producao" \
  --start-time "$(date -u -d '7 days ago' +%Y-%m-%dT%H:%M:%SZ)" \
  --end-time "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  --output table

# Ver número atual de instâncias
az appservice plan show \
  --resource-group "rg-webapp" \
  --name "asp-producao" \
  --query "sku.capacity" \
  --output tsv

# Alertas quando scaling atinge maxCount
az monitor autoscale settings create-notification \
  --autoscale-name "autoscale-asp-producao" \
  --resource-group "rg-webapp" \
  --send-to-subscription-administrator true \
  --webhooks "https://hooks.slack.com/services/..."

RBAC para controle de scaling

Para prevenir que equipes de desenvolvimento alterem o scaling de produção acidentalmente:

# Criar role customizada que permite ver mas não alterar scaling
az role definition create --role-definition '{
  "Name": "App Service Scaling Viewer",
  "Actions": [
    "Microsoft.Web/serverFarms/read",
    "Microsoft.Insights/autoscaleSettings/read"
  ],
  "NotActions": [
    "Microsoft.Web/serverFarms/write",
    "Microsoft.Insights/autoscaleSettings/write"
  ],
  "AssignableScopes": ["/subscriptions/<sub-id>"]
}'

---

8. Tomada de Decisão

Scale Up vs. Scale Out

Situação	Escolha	Motivo
App com única thread que não paraleliza	Scale Up	Mais CPU por instância, sem benefício de múltiplas instâncias
App web stateless com muitas requisições	Scale Out	Distribuição de carga, melhor custo-benefício
App com memória insuficiente causando OOM	Scale Up	Mais RAM por instância
Pico previsível de usuários simultâneos	Scale Out	Mais workers em paralelo
App legado com problemas de concorrência	Scale Up	Evitar distribuição que expõe problemas de estado

Manual vs. Autoscale

Situação	Escolha	Motivo
Carga previsível e constante	Manual	Evita overhead de autoscale desnecessário
Carga variável ao longo do dia	Autoscale com schedule	Previsível, sem métricas complexas
Carga imprevisível e variável	Autoscale com métricas	Responde a condições reais
Black Friday / evento especial	Fixed Date Profile	Pré-provisionar capacidade máxima
Dev/test com baixo uso	Manual com mínimo	Custo controlado sem scaling automático

Escolha de métrica para autoscale

Métrica	Quando usar	Cuidado
CpuPercentage	Apps CPU-bound (processamento, cálculos)	Pode não refletir problemas de I/O ou memória
HttpQueueLength	APIs web com muitas requisições simultâneas	Ideal para apps web; indica gargalo direto
MemoryPercentage	Apps que carregam grandes datasets em memória	Scaling não resolve memory leaks
Múltiplas métricas	Apps complexos com variação mista	Combinar CPU e HttpQueueLength

---

9. Boas Práticas

Sempre configure um scale-in rule conservador. O scale-in agressivo pode remover instâncias prematuramente durante uma carga ainda alta. Use uma janela de tempo maior (10-15 minutos) e um threshold mais baixo (CPU < 20-25%) para scale-in do que para scale-out.

Configure notificações de autoscale. Receba emails ou webhooks quando o autoscale age. Isso permite identificar se o autoscale está respondendo adequadamente, se está oscilando, ou se atingiu o maxCount e não consegue mais escalar.

Teste o scaling antes da produção. Execute testes de carga que forcem scale-out e scale-in. Verifique que o cooldown está adequado, que as regras são ativadas nos momentos corretos e que os apps não têm problemas de estado compartilhado entre instâncias.

Use profiles de schedule para cargas previsíveis. Se você sabe que o pico é de segunda a sexta das 9h às 17h, configure um profile de schedule que aumenta o minimum para um número razoável nesses horários. Isso é mais confiável do que esperar o autoscale reagir ao pico.

Separe apps de diferentes criticidades em Plans diferentes. Se um app consome todos os recursos do Plan durante um pico, os outros apps no mesmo Plan são degradados. Apps de produção e dev/test nunca devem compartilhar o mesmo Plan.

Configure o minimum com alta disponibilidade em mente. Um minimum de 1 instância significa que se essa instância falhar, o app fica indisponível até o autoscale criar uma nova. Para produção, configure minimum >= 2 para garantir HA.

---

10. Erros Comuns

Erro	Por que acontece	Como evitar
Auto Scale não funciona no tier Basic	Basic não suporta autoscale	Usar Standard ou superior para autoscale
Scale-in remove instâncias durante carga ainda alta	Threshold de scale-in muito alto ou window muito curta	Usar threshold conservador (< 25%) e window longa (10+ min)
Autoscale oscila sem parar (flapping)	Cooldown muito curto ou thresholds sobrepostos	Aumentar cooldown; garantir que os thresholds não se sobrepõem
Scale-out não acontece em tempo hábil para pico súbito	Cooldown muito longo ou window de avaliação muito longa	Reduzir window de avaliação para picos rápidos
All apps degradados quando um faz pico	Apps diferentes compartilhando o mesmo Plan	Separar apps de diferentes criticidades em Plans diferentes
Scale Up causa downtime nos apps	Não se preparar para a reinicialização durante scale up	Usar deployment slots para zero-downtime
Metric source errado nas regras	Selecionar a VM ou subscription em vez do App Service Plan	Verificar que metricResourceUri aponta para o Plan, não para o app
MaxCount muito baixo sem alerta	Autoscale atinge o limite sem conseguir mais escalar	Configurar alerta quando instâncias == maxCount

O erro mais custoso

Não configurar scale-in, resultando em um App Service Plan que cresce durante picos mas nunca diminui. O Plan permanece com o número máximo de instâncias indefinidamente, mesmo nos períodos de baixíssima carga. Com 10 instâncias P2v3 rodando 24h por dia quando 3 seriam suficientes, o custo desnecessário pode ser de milhares de reais por mês.

---

11. Operação e Manutenção

Verificar estado e histórico de scaling

# Ver número atual de instâncias do Plan
az appservice plan show \
  --resource-group "rg-webapp" \
  --name "asp-producao" \
  --query "{SKU: sku.name, Instancias: sku.capacity, Tier: sku.tier}" \
  --output json

# Ver métricas de CPU do Plan nas últimas 4 horas
az monitor metrics list \
  --resource "/subscriptions/<sub-id>/resourceGroups/rg-webapp/providers/Microsoft.Web/serverFarms/asp-producao" \
  --metric "CpuPercentage" \
  --interval PT5M \
  --aggregation Average \
  --start-time "$(date -u -d '4 hours ago' +%Y-%m-%dT%H:%M:%SZ)" \
  --end-time "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  --output table

# Ver HttpQueueLength nas últimas 4 horas
az monitor metrics list \
  --resource "/subscriptions/<sub-id>/resourceGroups/rg-webapp/providers/Microsoft.Web/serverFarms/asp-producao" \
  --metric "HttpQueueLength" \
  --interval PT1M \
  --aggregation Average \
  --start-time "$(date -u -d '4 hours ago' +%Y-%m-%dT%H:%M:%SZ)" \
  --end-time "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  --output table

Limites importantes

Limite	Valor
Instâncias máximas por Plan (Standard)	10
Instâncias máximas por Plan (Premium v3)	30
Instâncias máximas por Plan (Isolated v2)	100
Apps por App Service Plan	Sem limite definido (prático: dezenas)
Regras por profile de autoscale	10
Profiles por autoscale setting	20
Minimum recomendado para produção	2 (para HA)

---

12. Integração e Automação

Scaling com métricas de Application Insights

Para scaling baseado em métricas de performance da aplicação (não apenas do servidor):

# Criar regra de autoscale usando métrica customizada do Application Insights
# (requer metric namespace correto)
az monitor autoscale rule create \
  --resource-group "rg-webapp" \
  --autoscale-name "autoscale-asp-producao" \
  --condition "requests/duration > 2000 avg 5m" \
  --scale out 2 \
  --metric-resource-id "/subscriptions/<sub-id>/resourceGroups/rg-webapp/providers/microsoft.insights/components/appinsights-ecommerce"

Pipeline de deploy com scaling pré-configurado

# Azure DevOps: pre-scale antes de deploy, post-scale para produção
steps:
  - task: AzureCLI@2
    displayName: 'Pre-scale para deploy'
    inputs:
      scriptType: 'bash'
      inlineScript: |
        # Aumentar instâncias antes do deploy para absorver tráfego durante warmup
        az appservice plan update \
          --resource-group rg-webapp \
          --name asp-producao \
          --number-of-workers 6

  - task: AzureWebApp@1
    displayName: 'Deploy da aplicacao'
    inputs:
      appName: 'ecommerce-api'
      package: '$(Build.ArtifactStagingDirectory)/**/*.zip'

  - task: AzureCLI@2
    displayName: 'Restaurar autoscale pos-deploy'
    inputs:
      scriptType: 'bash'
      inlineScript: |
        # Reabilitar autoscale (desabilitado para scaling manual acima)
        az monitor autoscale update \
          --resource-group rg-webapp \
          --name autoscale-asp-producao \
          --enabled true

---

13. Resumo Final

Pontos essenciais:

• O App Service Plan define o tier (CPU/memória por instância) e o número de instâncias; todos os apps no Plan compartilham esses recursos
• Scale Up muda o SKU (ex: S1 para P2v3): mais CPU e memória por instância; requer breve reinicialização
• Scale Out muda o número de instâncias: mais workers em paralelo; sem reinicialização dos apps
• Auto Scale está disponível apenas a partir do tier Standard; Free, Shared e Basic suportam apenas scaling manual
• Regras de scale-out são combinadas com OR (qualquer uma dispara scale-out)
• Regras de scale-in são combinadas com AND (todas devem ser verdadeiras para scale-in)
• Profiles permitem configurações diferentes por horário (recurrence) ou data específica (fixed date)

Diferenças críticas:

• Scale Up vs. Scale Out: scale up aumenta recursos por instância (vertical); scale out aumenta número de instâncias (horizontal)
• Manual vs. Autoscale: manual mantém número fixo; autoscale varia baseado em métricas ou schedule
• Default Profile vs. outros profiles: default é o fallback quando nenhum profile de horário/data está ativo
• Classic Autoscale vs. Automatic Scaling: Classic usa regras baseadas em métricas do Azure Monitor (disponível no Standard); Automatic é o novo mecanismo nativo baseado em HTTP requests (apenas Premium v3+)

O que precisa ser lembrado para o AZ-104:

• Autoscale requer tier Standard ou superior; Basic suporta apenas máximo 3 instâncias com scaling manual
• O autoscale setting é um recurso separado (Microsoft.Insights/autoscaleSettings), não uma propriedade do App Service Plan
• Métrica HttpQueueLength indica que há requisições esperando worker; é a métrica mais direta para apps web
• CoolDown padrão é 5 minutos para ambos scale-out e scale-in
• Escalonamento horizontal máximo: 10 instâncias (Standard), 30 (Premium v3), 100 (Isolated v2)
• O target resource do autoscale setting deve ser o App Service Plan (Microsoft.Web/serverFarms), não o Web App