Fundamentação Teórica: Provision an App Service Plan

1. Intuição Inicial

Imagine que você quer alugar um espaço de escritório para sua equipe. Você não aluga as cadeiras e mesas individualmente. Você aluga um andar de um prédio que já vem com estrutura: energia, internet, ar-condicionado, segurança. Quantas pessoas trabalham naquele andar e o que cada uma faz é responsabilidade sua, mas a infraestrutura física é do prédio.

O App Service Plan funciona exatamente assim: é a infraestrutura alugada do Azure onde seus apps rodam. O Plan define o "tamanho do escritório" (CPU, memória, armazenamento), o "bairro" (região), e quanto você paga. Os apps que você instala nesse Plan são como os funcionários trabalhando no escritório: consomem os recursos disponíveis, mas compartilham a mesma infraestrutura.

Você não paga pelo app em si: você paga pelo App Service Plan. Um plan com 3 apps ou com 1 app tem o mesmo custo base. Isso é fundamental para entender como provisionar Plans de forma eficiente.

2. Contexto

O papel do App Service Plan no ecossistema Azure App Service

100%

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

Por que o App Service Plan existe como recurso separado

Sem o conceito de App Service Plan, cada Web App precisaria definir sua própria infraestrutura. Isso tornaria impraticável hospedar múltiplos apps na mesma infraestrutura (aumentando custo), e dificultaria a gestão centralizada de recursos.

O App Service Plan é o modelo de cobrança do Azure App Service: você paga pela infraestrutura reservada, não pelo número de requisições processadas (exceto no plano de Consumo de Azure Functions).

O que depende do App Service Plan

Web Apps, API Apps e Mobile Apps: precisam de um App Service Plan para existir
Deployment Slots: disponíveis em tiers Standard e acima, fazem parte do Plan
Scaling capabilities: o tier do Plan determina o máximo de instâncias e se auto scaling está disponível
Features de rede: VNet Integration, Private Endpoints e outras funcionalidades dependem do tier
Custom domains e SSL: disponíveis a partir do tier Basic

3. Construção dos Conceitos

3.1 Os tiers do App Service Plan

O tier define a classe do hardware e as capacidades disponíveis. Os tiers são agrupados em categorias:

100%

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

Tiers Compartilhados (Free e Shared): os workers físicos são compartilhados com outros clientes da Microsoft (multi-tenancy). São adequados apenas para desenvolvimento e testes. Não oferecem SLA e têm limites severos de CPU por dia.

Tiers Dedicados (Basic, Standard, Premium): cada instância do Plan roda em workers físicos dedicados exclusivamente ao seu tenant. Outros clientes da Microsoft não compartilham esse hardware. Oferecem SLA e capacidades de produção.

Tiers Isolados (Isolated v2 com ASE): o App Service Environment (ASE) é um ambiente completamente isolado em sua própria rede virtual, com workers físicos dedicados. É o máximo nível de isolamento, segurança e conformidade disponível no App Service.

3.2 Tabela comparativa detalhada dos tiers

Tier	SKU	vCPU	RAM	Storage	Max Instâncias	Auto Scale	Slots	Custom Domain	VNet Integration
Free	F1	Compartilhado	1 GB	1 GB	1	Não	0	Não	Não
Shared	D1	Compartilhado	1 GB	1 GB	1	Não	0	Sim	Não
Basic	B1	1	1.75 GB	10 GB	3	Manual	0	Sim	Não
Basic	B2	2	3.5 GB	10 GB	3	Manual	0	Sim	Não
Basic	B3	4	7 GB	10 GB	3	Manual	0	Sim	Não
Standard	S1	1	1.75 GB	50 GB	10	Sim	5	Sim	Sim
Standard	S2	2	3.5 GB	50 GB	10	Sim	5	Sim	Sim
Standard	S3	4	7 GB	50 GB	10	Sim	5	Sim	Sim
Premium v3	P0v3	0.25	1.75 GB	250 GB	30	Sim	20	Sim	Sim
Premium v3	P1v3	1	4 GB	250 GB	30	Sim	20	Sim	Sim
Premium v3	P2v3	2	8 GB	250 GB	30	Sim	20	Sim	Sim
Premium v3	P3v3	4	16 GB	250 GB	30	Sim	20	Sim	Sim
Isolated v2	I1v2	2	8 GB	1 TB	100	Sim	20	Sim	Dedicado

3.3 Parâmetros de provisionamento

Ao criar um App Service Plan, você define:

Nome: identificador único dentro do Resource Group

Subscription e Resource Group: onde o Plan será criado

Sistema Operacional: Windows ou Linux. Esta escolha é imutável após a criação. Apps Windows e Linux não podem coexistir no mesmo Plan.

Região: onde o Plan será hospedado fisicamente. Determina latência para usuários e deve ser na mesma região dos outros recursos da aplicação.

Tier e SKU: o tier determina as capacidades; o SKU dentro do tier determina CPU/RAM por instância.

Zona de Disponibilidade (Zone Redundancy): disponível nos tiers Premium v3 e Isolated v2. Distribui instâncias automaticamente entre as 3 zonas de disponibilidade da região. Requer mínimo de 3 instâncias e tem implicação de custo.

3.4 Zone Redundancy no App Service Plan

Zone Redundancy é uma propriedade do App Service Plan que garante que as instâncias sejam distribuídas entre as 3 zonas de disponibilidade. Com 3 instâncias em um Plan zone-redundant, cada instância fica em uma zona diferente.

Isso garante que mesmo se um datacenter inteiro falhar, 2/3 das instâncias continuam operando. O SLA sobe para 99,99% com zone redundancy e múltiplas instâncias.

Importante: Zone Redundancy requer que capacity >= 3 e que o tier seja Premium v3 ou Isolated v2.

4. Visão Estrutural

Relacionamento entre App Service Plan e os recursos

100%

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

Fluxo de decisão para escolha de tier

100%

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

5. Funcionamento na Prática

Ciclo de vida de um App Service Plan

100%

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

Comportamentos não óbvios

Um App Service Plan vazio ainda gera cobrança. O Plan é cobrado pelo tempo em que existe, mesmo sem nenhum app. Um Plan B2 sem apps custa o mesmo que um B2 com 10 apps. Planos não utilizados devem ser deletados.

Sistema Operacional é imutável após a criação. Se você criar um Plan com Windows e precisar hospedar um app Linux, terá que criar um novo Plan Linux. A mesma coisa acontece no sentido inverso. Isso é uma propriedade fundamental do Plan que não pode ser alterada.

Apps no mesmo Plan compartilham os mesmos workers. Se você tem 3 instâncias e 3 apps, cada requisição vai para um worker, mas todos os 3 apps estão em todos os 3 workers. Não é possível fazer um app usar apenas 1 instância enquanto outro usa todas as 3.

Deletar um App Service Plan requer que todos os apps sejam removidos primeiro. Se o Plan tiver qualquer app associado (Web App, API App, etc.), a tentativa de deletar o Plan falhará. Você deve deletar ou mover todos os apps primeiro.

Trocar o tier do Plan pode causar uma breve reinicialização dos apps. Especialmente ao mover entre classes de hardware diferentes (ex: Basic para Standard), os workers físicos mudam e os apps são brevemente reiniciados. Janelas de manutenção devem ser planejadas para uptime crítico.

Free e Shared têm limites de CPU por dia (CPU quota). O tier Free permite 60 minutos de CPU por dia por app, e o Shared permite 240 minutos. Quando a quota é atingida, os apps ficam offline até o próximo dia. Esses tiers não são adequados para qualquer carga de produção.

Um Resource Group pode ter múltiplos Plans. Não há limitação de quantos Plans existem em um Resource Group. A separação é por escolha de design, não por restrição técnica.

6. Formas de Implementação

Portal do Azure

Quando usar: criação inicial, exploração de opções, ambientes únicos

Passo a passo:

Portal > App Services > + Create > Web App (o Plan é criado junto) OU Portal > App Service plans > + Create (criação standalone do Plan)
Selecionar Subscription e Resource Group
Definir nome do Plan
Selecionar região
Selecionar sistema operacional (Windows ou Linux)
Selecionar pricing tier:
- Clicar em Explore pricing tiers
- Visualizar as opções por categoria
- Selecionar o tier e SKU desejado
Para Zone Redundancy: opção disponível para Premium v3+
Review + Create

Limitação: não reproduzível, sem controle de versão.

Azure CLI

# Criar App Service Plan Linux com Premium v3
az appservice plan create \
  --resource-group "rg-webapp" \
  --name "asp-ecommerce-prod" \
  --location "brazilsouth" \
  --is-linux \
  --sku P2V3 \
  --number-of-workers 2

# Criar App Service Plan Windows com Standard
az appservice plan create \
  --resource-group "rg-webapp" \
  --name "asp-dotnet-prod" \
  --location "brazilsouth" \
  --sku S2 \
  --number-of-workers 2
# Sem --is-linux = Windows por padrão

# Criar App Service Plan com Zone Redundancy (Premium v3, mínimo 3 instâncias)
az appservice plan create \
  --resource-group "rg-webapp" \
  --name "asp-ha-prod" \
  --location "brazilsouth" \
  --is-linux \
  --sku P2V3 \
  --number-of-workers 3 \
  --zone-redundant

# Ver detalhes de um App Service Plan
az appservice plan show \
  --resource-group "rg-webapp" \
  --name "asp-ecommerce-prod" \
  --query "{
    Nome: name,
    OS: kind,
    SKU: sku.name,
    Tier: sku.tier,
    Instancias: sku.capacity,
    Localizacao: location,
    ZoneRedundant: properties.zoneRedundant
  }" \
  --output json

# Listar todos os App Service Plans de uma subscription
az appservice plan list \
  --output table

# Listar apenas Plans em um Resource Group
az appservice plan list \
  --resource-group "rg-webapp" \
  --output table

# Listar apps hospedados em um Plan
az webapp list \
  --resource-group "rg-webapp" \
  --query "[?appServicePlanId == '/subscriptions/<sub-id>/resourceGroups/rg-webapp/providers/Microsoft.Web/serverFarms/asp-ecommerce-prod'].{Nome: name, Estado: state}" \
  --output table

# Mudar o tier/SKU de um Plan (Scale Up)
az appservice plan update \
  --resource-group "rg-webapp" \
  --name "asp-ecommerce-prod" \
  --sku P3V3

# Deletar App Service Plan (todos os apps devem ter sido removidos primeiro)
az appservice plan delete \
  --resource-group "rg-webapp" \
  --name "asp-ecommerce-prod" \
  --yes

# Verificar preços dos SKUs disponíveis em uma região
az billing rate-card get-by-filter \
  --filter "OfferDurableId eq 'MS-AZR-0003P' and Currency eq 'BRL' and Locale eq 'pt-BR' and RegionInfo eq 'BR'" \
  --query "Meters[?contains(MeterName, 'App Service')]" \
  --output table

Azure PowerShell

# Criar App Service Plan Linux
New-AzAppServicePlan `
  -ResourceGroupName "rg-webapp" `
  -Name "asp-ecommerce-prod" `
  -Location "brazilsouth" `
  -Tier "PremiumV3" `
  -WorkerSize "Medium" `  # P2v3: Small=P1v3, Medium=P2v3, Large=P3v3
  -Linux `
  -NumberofWorkers 2

# Criar App Service Plan Windows
New-AzAppServicePlan `
  -ResourceGroupName "rg-webapp" `
  -Name "asp-dotnet-prod" `
  -Location "brazilsouth" `
  -Tier "Standard" `
  -WorkerSize "Medium" `  # S2
  -NumberofWorkers 2

# Ver detalhes do Plan
Get-AzAppServicePlan `
  -ResourceGroupName "rg-webapp" `
  -Name "asp-ecommerce-prod" |
  Select-Object Name, Location, Sku, @{N="OS"; E={$_.Kind}}, @{N="Workers"; E={$_.Sku.Capacity}}

# Listar todos os Plans de um RG
Get-AzAppServicePlan -ResourceGroupName "rg-webapp" |
  Format-Table Name, Location, @{N="Tier"; E={$_.Sku.Tier}}, @{N="SKU"; E={$_.Sku.Name}}, @{N="Capacity"; E={$_.Sku.Capacity}}

# Mudar o tier
Set-AzAppServicePlan `
  -ResourceGroupName "rg-webapp" `
  -Name "asp-ecommerce-prod" `
  -Tier "PremiumV3" `
  -WorkerSize "Large"  # P3v3

# Deletar Plan
Remove-AzAppServicePlan `
  -ResourceGroupName "rg-webapp" `
  -Name "asp-ecommerce-prod" `
  -Force

Bicep

// App Service Plan Linux com Premium v3
resource appServicePlan 'Microsoft.Web/serverfarms@2022-09-01' = {
  name: 'asp-ecommerce-prod'
  location: 'brazilsouth'
  kind: 'linux'  // 'linux' para Linux; omitir ou 'app' para Windows
  sku: {
    name: 'P2V3'
    tier: 'PremiumV3'
    size: 'P2V3'
    family: 'Pv3'
    capacity: 2  // Número de instâncias
  }
  properties: {
    reserved: true  // true = Linux; false = Windows
    zoneRedundant: false  // true = distribuir entre availability zones (requer capacity >= 3)
    perSiteScaling: false  // false = scaling por Plan; true = scaling por app (rarely used)
  }
  tags: {
    Environment: 'Production'
    CostCenter: 'CC-2045'
    ManagedBy: 'bicep'
  }
}

// App Service Plan Windows com Standard
resource appServicePlanWindows 'Microsoft.Web/serverfarms@2022-09-01' = {
  name: 'asp-dotnet-prod'
  location: 'brazilsouth'
  sku: {
    name: 'S2'
    tier: 'Standard'
    size: 'S2'
    family: 'S'
    capacity: 2
  }
  properties: {
    reserved: false  // Windows
  }
}

// App Service Plan com Zone Redundancy
resource aspZoneRedundant 'Microsoft.Web/serverfarms@2022-09-01' = {
  name: 'asp-ha-prod'
  location: 'brazilsouth'
  kind: 'linux'
  sku: {
    name: 'P2V3'
    tier: 'PremiumV3'
    capacity: 3  // Mínimo 3 para zone redundancy
  }
  properties: {
    reserved: true
    zoneRedundant: true  // Distribui entre as 3 zonas
  }
}

Terraform

resource "azurerm_service_plan" "prod" {
  name                = "asp-ecommerce-prod"
  resource_group_name = azurerm_resource_group.main.name
  location            = azurerm_resource_group.main.location
  os_type             = "Linux"  # ou "Windows"
  sku_name            = "P2v3"
  worker_count        = 2
  zone_balancing_enabled = false  # true para zone redundancy (requer worker_count >= 3)

  tags = {
    Environment = "Production"
    ManagedBy   = "terraform"
  }
}

# Web App no Plan criado acima
resource "azurerm_linux_web_app" "app" {
  name                = "webapp-ecommerce"
  resource_group_name = azurerm_resource_group.main.name
  location            = azurerm_service_plan.prod.location
  service_plan_id     = azurerm_service_plan.prod.id

  site_config {
    application_stack {
      node_version = "20-lts"
    }
  }
}

7. Controle e Segurança

RBAC para App Service Plans

Diferentes times podem ter diferentes níveis de acesso ao App Service Plan:

Role	O que pode fazer	Caso de uso
Website Contributor	Gerenciar apps mas não o Plan	Times de dev gerenciam seus apps
Contributor	Gerenciar tudo, incluindo o Plan	Time de cloud ops
Reader	Visualizar tudo	Times de auditoria, finanças

Azure Policy para Plans

# Auditar Plans sem zone redundancy em produção
az graph query -q "
Resources
| where type == 'microsoft.web/serverfarms'
| where tags.Environment == 'Production'
| where properties.zoneRedundant == false
| project name, resourceGroup, sku.name, tags"

# Listar Plans com tier Free ou Shared que ainda existem
az graph query -q "
Resources
| where type == 'microsoft.web/serverfarms'
| where sku.tier in ('Free', 'Shared', 'Dynamic')
| project name, resourceGroup, subscriptionId, sku.tier"

Cost Management por App Service Plan

App Service Plans são cobrados por hora, independente do uso. Para otimização de custo:

# Listar Plans sem apps associados (candidatos para deleção)
az graph query -q "
Resources
| where type == 'microsoft.web/serverfarms'
| join kind=leftouter (
    Resources
    | where type == 'microsoft.web/sites'
    | summarize appCount = count() by planId = tostring(properties.serverFarmId)
  ) on \$left.id == \$right.planId
| where isnull(appCount) or appCount == 0
| project name, resourceGroup, subscriptionId, sku=sku.name, tier=sku.tier"

8. Tomada de Decisão

Escolha do tier

Situação	Tier recomendado	Motivo
Aprendizado, POC, tutorial	Free (F1)	Zero custo para explorar
Desenvolvimento com custom domain	Basic (B1)	Custo mínimo com custom domain
Staging/homologação	Basic (B2/B3)	Recursos adequados sem auto scale
Produção leve (< 1000 req/min)	Standard (S1/S2)	Auto scale disponível
Produção média com VNet	Standard ou Premium v3	VNet Integration requer Standard+
Produção de alto desempenho	Premium v3 (P2v3/P3v3)	Melhor hardware, mais slots, zone redundancy
Compliance máximo, rede isolada	Isolated v2 com ASE	Rede dedicada, máximo isolamento

Linux vs. Windows

Critério	Linux	Windows
Runtimes suportados	Node.js, Python, Ruby, PHP, Java, .NET	Node.js, PHP, Java, .NET, ASP.NET
Custo	Geralmente 10-15% menor	Ligeiramente maior
Containers	Suporte nativo	Via Windows Container (especial)
Runtime .NET	.NET 6+ suportado	.NET Framework + .NET 6+
Recomendação para novos projetos	Linux (exceto .NET Framework legado)	Apenas para .NET Framework ou Windows-specific

Um Plan para tudo vs. Plans separados por app

Abordagem	Vantagem	Desvantagem	Quando usar
Um Plan para todos os apps	Custo menor, menos overhead	Apps competem por recursos	Dev/test, apps de baixo tráfego
Plan por app	Isolamento total, scaling independente	Custo maior	Produção com apps críticos e tráfego variável
Plan por ambiente	Isolamento prod/staging	2x Plans por app	Padrão recomendado para produção

9. Boas Práticas

Separe produção e desenvolvimento em Plans diferentes. Colocar apps de dev no mesmo Plan de produção pode causar degradação de produção quando um desenvolvedor sobe código pesado. Sempre use Plans separados por ambiente.

Nomeie Plans com convenção que inclua ambiente e propósito. asp-ecommerce-prod, asp-ecommerce-dev, asp-backoffice-prod são muito melhores que MyPlan1 ou WebHostingPlan. O nome do Plan é visível em logs de custo e facilita chargeback.

Use Premium v3 em vez de Standard para novas arquiteturas. O Premium v3 usa hardware de geração mais recente (Dv5) com melhor performance por custo que o Standard, que usa hardware mais antigo. Para novos deployments, P1v3 frequentemente oferece melhor custo-benefício que S2.

Configure tags no App Service Plan, não apenas nos apps. O Plan é o objeto de cobrança. Tags como CostCenter, Project e Environment no Plan garantem que os custos apareçam corretamente nos relatórios do Cost Management.

Para produção, sempre use mínimo 2 instâncias. Um Plan com 1 instância não tem alta disponibilidade. Se o único worker tiver uma falha, a aplicação fica indisponível até o App Service provisionar um novo worker. Com 2 instâncias, sempre há redundância.

Ative Zone Redundancy para workloads críticos em Premium v3+. A diferença de custo de ter 3 instâncias em vez de 2 compensa o SLA de 99,99% contra 99,95%. Para aplicações com impacto financeiro por downtime, zone redundancy é o padrão recomendado.

Evite misturar apps de diferentes domínios de falha no mesmo Plan. Um app de processamento pesado no mesmo Plan que uma API crítica de usuário significa que o processamento pesado pode degradar a API. Separe workloads por criticidade e perfil de uso.

10. Erros Comuns

Erro	Por que acontece	Como evitar
Plan gerado com OS errado	Não perceber que a escolha de OS é permanente	Verificar o OS antes de criar; planejar com antecedência
Plan Free usado em produção	Falta de conhecimento sobre limites	Usar Basic ou superior para qualquer app de produção
Plan sem apps gerando custo	Criado para teste e esquecido	Auditoria regular de Plans vazios; deletar Plans não utilizados
Todos os apps no mesmo Plan sem isolar criticidade	Economia de custo no início	Separar apps críticos de produção em Plans dedicados
Plan na região errada para o usuário	Não planejar a localização do usuário	Escolher região próxima aos usuários finais
Plan Windows para app Node.js/Python novo	Herança de hábitos	Para novos apps, Linux tem melhor performance e custo
Zone redundancy sem mínimo de 3 instâncias	Não saber sobre o requisito mínimo	Ao habilitar zone redundancy, configurar capacity >= 3
Tentar deletar Plan com apps associados	Não remover apps primeiro	Verificar e mover/deletar todos os apps antes de deletar o Plan

O erro mais custoso

Criar Plans de teste que nunca são deletados. Um Plan B2 em standby (sem apps, sem tráfego) cobra ~R$400-600/mês dependendo da região. Uma organização com 20 Plans de teste "esquecidos" pode estar gastando R$8.000-12.000/mês em infraestrutura inativa. Implemente um processo de revisão mensal de Plans sem apps ou com baixíssimo uso.

11. Operação e Manutenção

Verificar saúde e uso dos Plans

# Ver CPU e memória médias do Plan nas últimas 24 horas
az monitor metrics list \
  --resource "/subscriptions/<sub-id>/resourceGroups/rg-webapp/providers/Microsoft.Web/serverFarms/asp-ecommerce-prod" \
  --metric "CpuPercentage,MemoryPercentage" \
  --interval PT1H \
  --aggregation Average \
  --start-time "$(date -u -d '24 hours 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-ecommerce-prod" \
  --query "sku.capacity" \
  --output tsv

# Listar apps em um Plan com seu estado
az webapp list \
  --resource-group "rg-webapp" \
  --query "[?appServicePlanId contains 'asp-ecommerce-prod'].{Nome: name, Estado: state, URL: defaultHostName}" \
  --output table

# Auditoria de Plans e seus apps em toda a subscription
az graph query -q "
Resources
| where type == 'microsoft.web/serverfarms'
| join kind=leftouter (
    Resources
    | where type == 'microsoft.web/sites'
    | summarize Apps = make_list(name) by planId = tostring(properties.serverFarmId)
  ) on \$left.id == \$right.planId
| project PlanName=name, RG=resourceGroup, Tier=sku.tier, SKU=sku.name, AppCount=array_length(Apps), Apps"

Limites e quotas

Recurso	Free (F1)	Basic	Standard	Premium v3
Apps por Plan	10	Ilimitado	Ilimitado	Ilimitado
CPU por dia	60 min	Ilimitado	Ilimitado	Ilimitado
Memória por app	1 GB	Depende do SKU	Depende do SKU	Depende do SKU
Armazenamento total	1 GB	10 GB	50 GB	250 GB
Domains SSL customizados	0	500	500	500
Deployment Slots	0	0	5	20

12. Integração e Automação

Provisioning automático com Pipeline de CI/CD

# Azure DevOps: criar Plan e Web App como parte de um pipeline de provisionamento
steps:
  - task: AzureCLI@2
    displayName: 'Provisionar App Service Plan'
    inputs:
      azureSubscription: 'prod-subscription'
      scriptType: 'bash'
      scriptLocation: 'inlineScript'
      inlineScript: |
        # Criar RG se não existir
        az group create \
          --name "$(RESOURCE_GROUP)" \
          --location "brazilsouth" \
          --tags Environment="$(ENVIRONMENT)" Project="$(PROJECT_NAME)"

        # Criar Plan
        az appservice plan create \
          --resource-group "$(RESOURCE_GROUP)" \
          --name "$(ASP_NAME)" \
          --location "brazilsouth" \
          --is-linux \
          --sku "$(ASP_SKU)" \
          --number-of-workers "$(ASP_WORKERS)" \
          --tags \
            Environment="$(ENVIRONMENT)" \
            Project="$(PROJECT_NAME)" \
            ManagedBy="azure-devops"

        echo "App Service Plan provisionado com sucesso: $(ASP_NAME)"

Integração com Azure Advisor para recomendações de custo

O Azure Advisor analisa App Service Plans e gera recomendações quando detecta:

Plans com baixíssimo uso de CPU (< 20% média) por 14+ dias
Plans com apenas 1 app que poderia ser movido para um Plan existente
Plans com tier muito alto para o uso observado

# Ver recomendações do Advisor para App Service Plans
az advisor recommendation list \
  --category Cost \
  --query "[?contains(resourceMetadata.resourceId, 'serverFarms')].{
    Plan: resourceMetadata.resourceId,
    Problema: shortDescription.problem,
    Solucao: shortDescription.solution,
    EconomiaAnual: extendedProperties.annualSavingsAmount
  }" \
  --output table

13. Resumo Final

Pontos essenciais:

O App Service Plan é a infraestrutura de computação onde apps do Azure App Service rodam; você paga pelo Plan, não pelo app
Todo Web App, API App e WebJob precisa de um App Service Plan para existir
O sistema operacional (Windows ou Linux) do App Service Plan é imutável após a criação
Tiers Free e Shared são multi-tenant (infraestrutura compartilhada); Basic, Standard e Premium são workers dedicados
Auto Scale só está disponível a partir do tier Standard
Zone Redundancy requer tier Premium v3 ou Isolated v2 e mínimo de 3 instâncias

Diferenças críticas:

Plan vs. App: o Plan é a infraestrutura; o App é a aplicação que usa essa infraestrutura. O Plan cobra por hora; o App não tem custo direto
Tiers compartilhados vs. dedicados: Free e Shared dividem hardware com outros clientes; Basic e acima têm workers exclusivos
Basic vs. Standard: Basic suporta até 3 instâncias com scaling manual; Standard suporta auto scale e até 10 instâncias
Standard vs. Premium v3: Premium v3 tem hardware mais moderno, mais slots (20 vs. 5), mais instâncias (30 vs. 10) e suporte a zone redundancy

O que precisa ser lembrado para o AZ-104:

O parâmetro --is-linux no CLI define o OS como Linux; sem ele, Windows é o padrão
O parâmetro --sku aceita: F1, D1, B1/B2/B3, S1/S2/S3, P0V3/P1V3/P2V3/P3V3, I1v2/I2v2/I3v2
Zone redundancy (--zone-redundant) requer --number-of-workers 3 mínimo
Plans vazios (sem apps) continuam gerando cobrança
O tier Free limita a 60 minutos de CPU por dia por app
A propriedade reserved: true no Bicep/ARM indica Linux; reserved: false indica Windows
Deployment Slots: Basic = 0 slots, Standard = 5 slots, Premium v3 = 20 slots

1. Intuição Inicial​

2. Contexto​

O papel do App Service Plan no ecossistema Azure App Service​

Por que o App Service Plan existe como recurso separado​

O que depende do App Service Plan​

3. Construção dos Conceitos​

3.1 Os tiers do App Service Plan​

3.2 Tabela comparativa detalhada dos tiers​

3.3 Parâmetros de provisionamento​

3.4 Zone Redundancy no App Service Plan​

4. Visão Estrutural​

Relacionamento entre App Service Plan e os recursos​

Fluxo de decisão para escolha de tier​

5. Funcionamento na Prática​

Ciclo de vida de um App Service Plan​

Comportamentos não óbvios​

6. Formas de Implementação​

Portal do Azure​

Azure CLI​

Azure PowerShell​

Bicep​

Terraform​

7. Controle e Segurança​

RBAC para App Service Plans​

Azure Policy para Plans​

Cost Management por App Service Plan​

8. Tomada de Decisão​

Escolha do tier​

Linux vs. Windows​

Um Plan para tudo vs. Plans separados por app​

9. Boas Práticas​

10. Erros Comuns​

O erro mais custoso​

11. Operação e Manutenção​

Verificar saúde e uso dos Plans​

Limites e quotas​

12. Integração e Automação​

Provisioning automático com Pipeline de CI/CD​

Integração com Azure Advisor para recomendações de custo​

13. Resumo Final​

1. Intuição Inicial

2. Contexto

O papel do App Service Plan no ecossistema Azure App Service

Por que o App Service Plan existe como recurso separado

O que depende do App Service Plan

3. Construção dos Conceitos

3.1 Os tiers do App Service Plan

3.2 Tabela comparativa detalhada dos tiers

3.3 Parâmetros de provisionamento

3.4 Zone Redundancy no App Service Plan

4. Visão Estrutural

Relacionamento entre App Service Plan e os recursos

Fluxo de decisão para escolha de tier

5. Funcionamento na Prática

Ciclo de vida de um App Service Plan

Comportamentos não óbvios

6. Formas de Implementação

Portal do Azure

Azure CLI

Azure PowerShell

Bicep

Terraform

7. Controle e Segurança

RBAC para App Service Plans

Azure Policy para Plans

Cost Management por App Service Plan

8. Tomada de Decisão

Escolha do tier

Linux vs. Windows

Um Plan para tudo vs. Plans separados por app

9. Boas Práticas

10. Erros Comuns

O erro mais custoso

11. Operação e Manutenção

Verificar saúde e uso dos Plans

Limites e quotas

12. Integração e Automação

Provisioning automático com Pipeline de CI/CD

Integração com Azure Advisor para recomendações de custo

13. Resumo Final