O item "criar e configurar o Azure App Service" do guia de habilidades do AZ-104 tem oito entradas: provisionar um plano do App Service, configurar o dimensionamento do plano, criar um App Service, configurar certificados e TLS, mapear um nome DNS personalizado existente, configurar backup, configurar a rede e configurar slots de implantação. Planos e slots foram explicados em um artigo anterior, mas dimensionamento, certificados, domínios personalizados e backup mal foram tocados. O exame gosta especialmente de perguntar "Qual é a camada mínima para usar este recurso?".
Este artigo cobre as tarefas que aparecem na operação do App Service: os recursos que cada camada do plano libera, escalar verticalmente e horizontalmente (dimensionamento automático e escala automática), os registros DNS de domínios personalizados, como escolher um certificado TLS, backups automáticos e personalizados, e as configurações de rede para o tráfego de entrada e de saída. O básico de planos do App Service e slots de implantação está em Dominando Contêineres do Azure e App Service.
---
A Camada do Plano Decide Quais Recursos Você Tem
Mudar para um plano de celular melhor não só aumenta os dados; também libera recursos como roteamento ou roaming internacional. Os planos do App Service funcionam do mesmo jeito: a camada (tipo de preço) muda não só o desempenho, mas também os recursos disponíveis. Free e Shared compartilham VMs com aplicativos de outros clientes, a partir do Basic eles rodam em VMs dedicadas, e o Isolated v2 isola também a rede virtual.
!Recursos liberados conforme a camada do plano do App Service sobe
| Camada | Instâncias máximas | Principais recursos liberados nesta camada | |------|------|------| | Free · Shared | 1 compartilhada (sem escala horizontal) | Para desenvolvimento e teste; Free não aceita domínio personalizado | | Basic | 3 dedicadas | TLS para domínio personalizado, backup, integração com VNet, pontos de extremidade privados | | Standard | 10 dedicadas | Dimensionamento automático, 5 slots de implantação | | Premium (v2, v3, v4) | 30 dedicadas | 20 slots de implantação, escala automática (por tráfego HTTP), instâncias maiores | | Isolated v2 | 100 dedicadas | App Service Environment, isolamento de rede |
Os aplicativos de um mesmo plano compartilham as mesmas instâncias de VM, então escalar o plano ou adicionar instâncias afeta todos os aplicativos desse plano.
Dica para o exame: "O aplicativo está em um plano Basic e precisa de slots de implantação" significa escalar verticalmente para Standard ou superior. "Adicionar instâncias automaticamente conforme o uso de CPU" também exige Standard ou superior.
---
Escalar Verticalmente e Horizontalmente
Quando um restaurante lota, mudar a cozinha para um espaço maior e contratar mais cozinheiros são soluções diferentes. No App Service, a primeira é escalar verticalmente (scale up) e a segunda é escalar horizontalmente (scale out).
| Método | O que faz | O que lembrar | |------|------|------| | Escala vertical | Muda a camada ou o tamanho do plano (CPU, memória, disco, recursos extras) | Se falta um recurso, escale verticalmente | | Escala horizontal manual | Define diretamente o número de instâncias | Basic e superior | | Dimensionamento automático (Azure autoscale) | Ajusta o número de instâncias com regras baseadas em métricas (CPU, memória, solicitações) ou agendas | Standard e superior; definir instâncias mínimas, máximas e padrão, e regras de aumento e redução | | Escala automática (automatic scaling) | A plataforma ajusta pelo tráfego HTTP, sem regras | Premium v2–v4, pico máximo de até 30, não suportada para o tráfego de slots |
As regras de dimensionamento automático devem vir em pares: uma para aumentar e outra para reduzir. Com só uma regra de aumento, as instâncias nunca diminuem quando a carga cai, e o custo continua.
Dica para o exame: "Subir para 5 instâncias toda segunda às 9h e voltar para 2 às 18h" é dimensionamento automático por agenda. "Adicionar uma instância quando a CPU passar de 70%" é uma regra por métrica, e precisa de uma regra de redução correspondente (por exemplo, abaixo de 30%).
---
Mapeando um Domínio Personalizado
Um aplicativo do App Service recebe por padrão o endereço nomedoapp.azurewebsites.net. Para usar o domínio da empresa (www.contoso.com), crie registros na zona DNS pública do domínio e adicione o domínio no App Service. A camada Free não aceita domínios personalizados, e zonas DNS privadas não são suportadas.
| Nome a mapear | Registro a criar | Valor | |------|------|------| | Subdomínio (www.contoso.com) | CNAME | nomedoapp.azurewebsites.net | | Verificação de propriedade do subdomínio | TXT (asuid.www) | A ID de verificação de domínio do aplicativo | | Domínio raiz (contoso.com) | A | O endereço IP do aplicativo (não use CNAME na raiz) | | Verificação de propriedade do domínio raiz | TXT (asuid) | A ID de verificação de domínio do aplicativo |
A ID de verificação de domínio no registro TXT evita o sequestro de subdomínio, em que outra pessoa mapeia o mesmo subdomínio para o próprio aplicativo do App Service. Dá para usar um registro A em um subdomínio, mas o IP do aplicativo pode mudar, por isso o CNAME é recomendado.
Dica para o exame: "Mapear o domínio raiz contoso.com" significa um registro A mais um registro TXT asuid; "www.contoso.com" significa um CNAME mais um registro TXT asuid.www. Uma opção que cria um CNAME no domínio raiz está errada.
---
Certificados TLS e HTTPS
Para servir HTTPS em um domínio personalizado, é preciso vincular um certificado ao aplicativo, o que exige Basic ou superior. Há quatro formas de obter um certificado.
| Método | Custo | Características | |------|------|------| | Certificado gerenciado do App Service | Gratuito | Renova sozinho; sem curinga, não pode ser exportado, não suportado no App Service Environment | | Certificado do App Service | Pago | Gerenciado pelo Azure, aceita curinga, pode ser renovado e exportado | | Importar do Key Vault | Conforme o certificado | Quando você gerencia certificados de forma centralizada no Key Vault | | Carregar um certificado privado | Conforme o certificado | Um arquivo PFX comprado de outra autoridade de certificação |
Escolha o tipo de vinculação: SSL SNI (Basic e superior, ilimitado) ou SSL baseado em IP (um incluído a partir do Standard) Ativar Somente HTTPS redireciona solicitações HTTP para HTTPS Defina uma versão mínima de TLS para rejeitar conexões com versões antigas Um certificado gerenciado para domínio raiz exige que o aplicativo esteja acessível pela internet na criação e na renovação, então restrições de IP podem fazê-lo falhar
Dica para o exame: "Um certificado curinga *.contoso.com gratuito" é um requisito impossível. O certificado gerenciado gratuito não aceita curingas, então é preciso comprar um certificado do App Service ou importá-lo do Key Vault.
---
Backup e Restauração
O backup do App Service é suportado nas camadas Basic, Standard, Premium e Isolated, e existe em dois tipos.
| Item | Backup automático | Backup personalizado | |------|------|------| | Configuração | Não precisa; roda sozinho a cada hora | Você configura com uma conta de armazenamento | | Tamanho | 30 GB | 10 GB (até 4 GB podem ser um banco de dados vinculado) | | Banco de dados vinculado | Não entra no backup | Alguns bancos suportados (o suporte termina em 31 de março de 2028) | | Frequência | A cada hora, não configurável | Agendado (até a cada hora no Premium) ou manual | | Retenção | 30 dias, não configurável | 0–30 dias ou indefinida | | Download | Não é possível | Pode ser baixado como blobs |
Você pode restaurar um backup sobrescrevendo um aplicativo existente ou restaurando em um aplicativo ou slot novo. Na camada Basic, só o slot de produção pode ter backup e restauração.
Dica para o exame: "Baixar os arquivos de backup e mantê-los por 90 dias" significa backups personalizados. Os automáticos não permitem mudar a retenção nem ser baixados.
---
Rede: o Caminho de Entrada e o de Saída
A rede do App Service fica bem menos confusa quando você separa as direções. Os recursos que controlam o tráfego que entra no aplicativo são diferentes dos recursos para o tráfego que o aplicativo envia para fora.
| Direção | Recurso | O que faz | |------|------|------| | Entrada | Restrições de acesso | Regras de permitir ou negar por endereço IP, ponto de extremidade de serviço ou marca de serviço (até 512 por aplicativo) | | Entrada | Ponto de extremidade privado | Acessar o aplicativo por um IP privado da VNet; Basic e superior | | Saída | Integração com rede virtual | Permite que o aplicativo acesse recursos dentro da VNet (VMs, pontos de extremidade privados etc.); Basic e superior; precisa de uma sub-rede dedicada e delegada | | Saída | Conexões híbridas | Acessa um host e uma porta locais específicos por meio de uma retransmissão |
A integração com rede virtual é só de saída, então sozinha ela não dá acesso privado da VNet para o aplicativo. Você pode associar um NSG e uma UDR à sub-rede de integração para controlar o tráfego de saída do aplicativo.
Dica para o exame: "O aplicativo precisa acessar uma VM com SQL Server na VNet pelo IP privado" significa integração com rede virtual; "esconder o aplicativo da internet e permitir acesso só pela VNet" significa um ponto de extremidade privado (e bloquear o acesso público). Os dois atuam em direções opostas e um não substitui o outro.
---
Referência Rápida do Exame
Pontos-chave para revisar uma última vez antes do exame.
| Tema | O que lembrar | |------|------| | Free · Shared | VMs compartilhadas, sem escala horizontal; Free sem domínio personalizado | | Basic | 3 dedicadas; TLS de domínio personalizado, backup, integração com VNet, pontos de extremidade privados | | Standard | 10 dedicadas; dimensionamento automático; 5 slots | | Premium | 30 dedicadas; 20 slots; escala automática | | Escala vertical vs horizonta