Arquitetura de linha de base das Máquinas Virtuais do Azure

Este artigo fornece uma arquitetura de referência fundamental para uma carga de trabalho implantada em Máquinas Virtuais do Azure.

A carga de trabalho de exemplo assumida por essa arquitetura é um aplicativo Web de várias camadas voltado para a Internet que é implantado em conjuntos separados de máquinas virtuais (VMs). As VMs são provisionadas como parte das implantações dos Conjuntos de Dimensionamento de Máquinas Virtuais do Azure. Essa arquitetura pode ser usada para estes cenários:

• Aplicativos privados. Esses aplicativos incluem aplicativos internos de linha de negócios ou soluções comerciais prontas para uso.
• Aplicativos públicos. Esses aplicativos são voltados para a Internet. Essa arquitetura não se destina a computação de alto desempenho, cargas de trabalho de missão crítica, aplicativos altamente afetados pela latência ou outros casos de uso especializados.

O foco principal dessa arquitetura não é o aplicativo. Em vez disso, este artigo fornece orientação para configurar e implantar os componentes de infraestrutura com os quais o aplicativo interage. Eles incluem componentes de computação, de armazenamento, de rede e de monitoramento.

Essa arquitetura serve como ponto de partida para uma carga de trabalho hospedada em IaaS (infraestrutura como serviço). A camada de dados é intencionalmente excluída desta orientação para manter o foco na infraestrutura de computação.

Layout do artigo

Arquitetura	Decisão de design	Abordagem do Well-Architected Framework
▪ Diagrama da arquitetura ▪ Recursos de carga de trabalho Recursos de apoio ▪ Fluxos de usuários	▪ Opções de design de VM ▪ Discos ▪ Rede ▪ Monitoramento ▪ Gerenciamento de Atualizações	▪ Confiabilidade ▪ Segurança ▪ Otimização de custos

Arquitetura

Baixe um Arquivo Visio dessa arquitetura.

Para obter informações sobre esses recursos, consulte a documentação do produto Azure indicada em Recursos relacionados.

Componentes

Essa arquitetura consiste em vários serviços do Azure para recursos de carga de trabalho e recursos de apoio de carga de trabalho. Os serviços de cada uma e suas funções são descritos nas seções a seguir.

Recursos de carga de trabalho

• As Máquinas Virtuais do Azure servem como o recurso de computação para o aplicativo e são distribuídas entre zonas de disponibilidade. Para fins ilustrativos, é utilizada uma combinação de VMs do Windows e do Linux.

  Conjuntos de Dimensionamento de Máquinas Virtuais do Azure no modo de orquestração flexível são usados para provisionar e gerenciar as VMs.

  O aplicativo de exemplo pode ser representado em duas camadas, cada uma exigindo a própria computação.

  • O front-end executa o servidor Web e recebe solicitações do usuário.
  • O back-end executa outro servidor Web atuando como uma API da Web que expõe um único ponto de extremidade no qual a lógica de negócios é executada.

  As VMs front-end têm discos de dados (Premium_LRS) anexados, que podem ser usados para implantar um aplicativo sem estado. As VMs back-end persistem os dados em discos locais do Premium_ZRS como parte da operação. Esse layout pode ser estendido para incluir uma camada de banco de dados para armazenar o estado da computação front-end e back-end. Essa camada está fora do escopo dessa arquitetura.

• A Rede Virtual do Azure fornece uma rede privada para todos os recursos de carga de trabalho. A rede é segmentada em sub-redes, que servem como limites de isolamento.

• O Gateway de Aplicativo do Azure é o único ponto de entrada que direciona solicitações para os servidores front-end. A SKU selecionada inclui o WAF (Firewall de Aplicativo Web do Azure) integrado para maior segurança.

• O Azure Load Balancer Interno direciona o tráfego da camada front-end para os servidores back-end.

• O SKU padrão do Azure Load Balancer concede acesso de saída à Internet às VMs usando três endereços IP públicos.

• O Azure Key Vault armazena os certificados usados para comunicação TLS (Transport Layer Security) de ponta a ponta. Ele também pode ser usado para segredos de aplicativos.

Recursos de apoio de carga de trabalho

• O Azure Bastion concede acesso operacional às VMs por meio de protocolos seguros.

• O Application Insights coleta logs e métricas do aplicativo. Como o aplicativo não é o foco dessa arquitetura, a coleta de logs não é demonstrada na implementação.

• O Log Analytics é o coletor de dados de monitoramento que coleta logs e métricas dos recursos do Azure e do Application Insights. Uma conta de armazenamento é provisionada como parte do espaço de trabalho.

Fluxos de usuários

Há dois tipos de usuários que interagem com os recursos de carga de trabalho: o usuário e o operador da carga de trabalho. Os fluxos para esses usuários são mostrados no diagrama de arquitetura anterior.

Usuário da carga de trabalho

1. O usuário acessa o site usando o endereço IP público exposto do Gateway de Aplicativo.

2. O Gateway de Aplicativo recebe tráfego HTTPS, descriptografa dados usando um certificado externo para inspeção de WAF e os criptografa novamente usando o certificado curinga interno para transporte para o front-end.

3. O Gateway de Aplicativo equilibra o tráfego entre VMs front-end e encaminha a solicitação para uma VM front-end.

4. A VM front-end selecionada se comunica com uma VM back-end usando o endereço IP privado do balanceador de carga, não o IP de qualquer VM individual. Essa comunicação também é criptografada usando o certificado curinga interno.

5. A VM back-end descriptografa a solicitação usando o certificado interno. Depois que o back-end processa a solicitação, ele retorna o resultado para o front-end, que retorna o resultado para o gateway de aplicativo e, finalmente, retorna o resultado para o usuário.

Operador

As VMs nessa arquitetura podem exigir acesso direto dos operadores, mas recomendamos que o acesso remoto seja minimizado por meio da automação e que seja monitorado. O acesso pode se destinar a situações de correção de falhas, solução de problemas ou parte de um processo de implantação automatizado. Essa arquitetura não tem IPs públicos para acesso ao plano de controle. O Azure Bastion atua como um gateway sem servidor, permitindo que as operações acessem VMs via SSH ou RDP. Essa configuração garante um gerenciamento de acesso seguro e eficiente.

1. O operador entra no portal ou na CLI do Azure.
2. O operador acessa o serviço Azure Bastion e se conecta remotamente à VM desejada.

Opções de design de VM

Ao selecionar SKUs, é importante ter uma expectativa de desempenho de linha de base. Várias características influenciam o processo de tomada de decisão, incluindo:

• CPU, memória e operações de entrada/saída de disco por segundo (IOPS).
• Arquitetura de processadores.
• Tamanho da imagem do sistema operacional.

Por exemplo, se você estiver migrando uma carga de trabalho de um ambiente local que exija máquinas com processador Intel, escolha SKUs de VM que comportem processadores Intel.

Para obter informações sobre SKUs de VM com suporte, consulte Tamanhos de máquinas virtuais no Azure.

Inicialização

As VMs geralmente precisam ser inicializadas, que é um processo no qual as VMs são preparadas e ajustadas para executar o aplicativo. As tarefas comuns de inicialização incluem instalar certificados, configurar o acesso remoto, instalar pacotes, ajustar e proteger a configuração do sistema operacional e formatar e montar discos de dados. É importante automatizar o processo de inicialização o máximo possível, para que o aplicativo possa ser iniciado na VM sem atraso ou intervenção manual. Veja as recomendações para automação:

• Extensões de máquinas virtuais. Essas extensões são objetos do Gerenciador de Recursos do Azure que são gerenciados por meio da implantação de IaC (Infraestrutura como Código). Dessa forma, qualquer falha é relatada como uma implantação com falha na qual você pode agir. Se não houver uma extensão para suas necessidades de inicialização, crie scripts personalizados. É recomendável executar os scripts por meio da Extensão de Script Personalizado do Azure.

  Veja algumas outras extensões que podem ser usadas para instalar ou configurar automaticamente a funcionalidade nas VMs.

  • O Agente do Azure Monitor (AMA) coleta dados de monitoramento do SO convidado e os entrega ao Azure Monitor.
  • A versão 2 da Extensão de Script Personalizado do Azure (Windows, Linux) baixa e executa scripts em VMs (máquinas virtuais) do Azure. Essa extensão é útil para automatizar a configuração de pós-implantação, instalação de software ou qualquer outra configuração ou tarefas de gerenciamento.
  • A extensão de máquina virtual do Azure Key Vault (Windows, Linux) fornece atualização automática de certificados armazenados em um Key Vault detectando alterações e instalando os certificados correspondentes.
  • A extensão de Integridade do Aplicativo com Conjuntos de Dimensionamento de Máquinas Virtuais é importante quando os Conjuntos de Dimensionamento de Máquinas Virtuais do Azure fazem atualizações contínuas automáticas. O Azure depende do monitoramento de integridade das instâncias individuais para fazer as atualizações. Você também pode usar a extensão para monitorar a integridade do aplicativo de cada instância no conjunto de dimensionamento e realizar reparos de instância usando Reparos Automáticos de Instância.
  • O Microsoft Entra ID e o OpenSSH (Windows, Linux) integram-se à autenticação do Microsoft Entra. Você já pode usar o Microsoft Entra ID como uma plataforma de autenticação básica e uma autoridade de certificação para entrar com o SSH em uma VM do Linux usando o Microsoft Entra ID e a autenticação baseada em certificado OpenSSH. Essa funcionalidade permite gerenciar o acesso a VMs com o RBAC (controle de acesso baseado em função) do Azure e políticas de Acesso Condicional.

• Configuração baseada em agente. As VMs Linux podem usar uma configuração de estado desejado nativa leve disponível por meio do cloud-init em várias imagens de VM fornecidas pelo Azure. A configuração é especificada e é feito o controle de versão com seus artefatos IaC. Trazer sua própria solução de gerenciamento de configuração é outra maneira. A maioria das soluções segue uma abordagem declarativa de primeiro lugar para inicializar, mas oferece suporte a scripts personalizados para flexibilidade. As opções conhecidas incluem Desired State Configuration para Windows, Desired State Configuration para Linux, Ansible, Chef, Puppet e outros. Todas essas soluções de configuração podem ser emparelhadas com extensões de VM para uma melhor experiência.

Na implementação de referência, toda a inicialização é feita por meio de extensões de VM e scripts personalizados, incluindo um script personalizado para automatizar a formatação e a montagem do disco de dados.

Consulte o Well-Architected Framework: RE:02 - Recomendações para design de automação.

Conectividade da VM

Para habilitar a comunicação privada entre uma VM e outros dispositivos em uma rede virtual específica, a placa de adaptador de rede (NIC) da VM é conectada a uma das sub-redes da rede virtual. Se você precisar de várias NICs para sua VM, saiba que um número máximo de NICs está definido para cada tamanho de VM.

Se a carga de trabalho precisar de comunicação de baixa latência entre VMs na rede virtual, considere a rede acelerada, que tem suporte das NICs de VM do Azure. Para obter mais informações, consulte Benefícios da rede acelerada.

Conjuntos de Dimensionamento de Máquinas Virtuais com Orquestração Flexível

As VMs são provisionadas como parte de Conjuntos de Dimensionamento de Máquinas Virtuais com Orquestração Flexível. Os Conjuntos de Dimensionamento de Máquinas Virtuais são agrupamentos lógicos de VMs que são usados para atender às necessidades de negócios. Os tipos de VMs em um agrupamento podem ser idênticos ou diferentes. Eles permitem gerenciar o ciclo de vida de máquinas, adaptadores de rede e discos usando APIs e comandos padrão da VM do Azure.

O modo de orquestração flexível facilita as operações em grande escala e ajuda nas decisões de dimensionamento granular.

A configuração do domínio de falha é necessária para limitar o efeito de falhas de hardware físico, interrupções de rede ou interrupções de energia. Com conjuntos de dimensionamento, o Azure distribui uniformemente instâncias entre domínios de falha para resiliência contra um único problema de hardware ou de infraestrutura.

Recomendamos que você transfira a alocação de domínio de falha para o Azure para máxima propagação de instância, aumentando a resiliência e a disponibilidade.

Discos

Para executar o sistema operacional e os componentes do aplicativo, os discos de armazenamento são anexados à VM. Considere o uso de discos efêmeros para o sistema operacional e discos gerenciados para armazenamento de dados.

O Azure oferece uma variedade de opções em termos de desempenho, versatilidade e custo. Comece com o SSD Premium para a maioria das cargas de trabalho de produção. Sua escolha depende da SKU da VM. As SKUs que oferecem suporte ao SSD Premium contêm um s no nome do recurso, por exemplo, Dsv4 , mas não Dv4.

Para obter mais informações sobre as opções de disco com métricas, como capacidade, IOPS e taxa de transferência, consulte Comparação de tipos de disco.

Considere as características do disco e as expectativas de desempenho ao selecionar um disco.

• Limitações de SKU da VM. Os discos funcionam dentro da VM à qual estão conectados, que têm limites de IOPS e taxa de transferência. Verifique se o disco não restringe os limites da VM e vice-versa. Selecione o tamanho do disco, o desempenho e os recursos da VM (núcleo, CPU, memória) que executam de forma ideal o componente do aplicativo. Evite o superprovisionamento, pois isso afeta o custo.

• Alterações de configuração. É possível alterar algumas configurações de desempenho e de capacidade do disco enquanto uma VM está em execução. No entanto, muitas alterações podem exigir o novo provisionamento e a reconstrução do conteúdo do disco, afetando a disponibilidade da carga de trabalho. Portanto, planeje cuidadosamente a seleção de SKU da VM e do disco para minimizar o retrabalho e o impacto na disponibilidade.

• Discos do SO Efêmero Provisione discos do sistema operacional como discos efêmeros. Use discos gerenciados somente se os arquivos do sistema operacional precisarem ser mantidos. Evite usar discos efêmeros para armazenar componentes e estado do aplicativo.

  A capacidade dos discos do SO efêmero depende da SKU da VM escolhida. Verifique se o tamanho do disco de imagem do sistema operacional é menor do que o cache disponível ou o disco temporário da SKU. Você pode usar o espaço restante para armazenamento temporário.

• Desempenho do disco. O pré-provisionamento de espaço em disco com base na carga de pico é comum, mas pode causar a subutilização de recursos porque a maioria das cargas de trabalho não sustenta a carga de pico.

  Monitore os padrões de uso da carga de trabalho, observando picos ou operações sustentadas de alta leitura e considere esses padrões na seleção da SKU da VM e do disco gerenciado.

  É possível ajustar o desempenho sob demanda alterando os níveis de desempenho ou usando os recursos de bursting oferecidos em algumas SKUs de disco gerenciado.

  Embora o superprovisionamento reduza a necessidade de bursting, ele pode causar capacidade não utilizada pela qual você está pagando. O ideal é combinar os dois recursos para obter os melhores resultados.

• Ajuste o cache para a carga de trabalho. Defina as configurações de cache para todos os discos com base no uso do componente do aplicativo.

  Os componentes que executam principalmente operações de leitura não exigem alta consistência transacional do disco. Esses componentes podem se beneficiar do cache somente leitura. Componentes com uso intenso de gravação que exigem alta consistência transacional do disco geralmente têm o armazenamento em cache desabilitado.

  O uso do cache de leitura e gravação poderá causar perda de dados se a VM falhar e não é recomendável para a maioria dos cenários de disco de dados.

Nessa arquitetura:

• Os discos do sistema operacional de todas as VMs são efêmeros e estão localizados no disco de cache.

  O aplicativo de carga de trabalho no front-end (Linux) e no back-end (Windows Server) são tolerantes a falhas de VM individuais e ambos usam imagens pequenas (cerca de 30 GB). Esses atributos os tornam qualificados para usar discos do sistema operacional efêmero criados como parte do armazenamento local da VM (partição de cache) em vez do disco do sistema operacional persistente que é salvo em recursos de armazenamento remotos do Azure. Essa situação não gera nenhum custo de armazenamento para discos do sistema operacional e também melhora o desempenho, fornecendo latências mais baixas e reduzindo o tempo de implantação da VM.

• Cada VM tem seu próprio disco gerenciado Premium SSD P1, fornecendo uma taxa de transferência provisionada básica adequada para a carga de trabalho.

Layout de rede

Essa arquitetura implanta a carga de trabalho em uma única rede virtual. Os controles de rede são uma parte significativa dessa arquitetura e são descritos na seção Segurança .

Esse layout pode ser integrado a uma topologia corporativa. Esse exemplo é mostrado na arquitetura de linha de base de máquina virtual em uma zona de destino do Azure.

Rede virtual

Uma das decisões iniciais de layout de rede está relacionada ao intervalo de endereços de rede. Lembre-se do crescimento de rede previsto durante a fase de planejamento de capacidade. A rede deve ser grande o suficiente para sustentar o crescimento, que pode precisar de constructos de rede extras. Por exemplo, a rede virtual deve ter a capacidade de acomodar as outras VMs resultantes de uma operação de dimensionamento.

Por outro lado, dimensione corretamente seu espaço de endereço. Uma rede virtual excessivamente grande pode ocasionar subutilização. É importante observar que, após a criação da rede virtual, o intervalo de endereços não pode ser modificado.

Nessa arquitetura, o espaço de endereço é definido como /21, uma decisão baseada no crescimento projetado.

Considerações sobre sub-rede

Dentro da rede virtual, as sub-redes são divididas com base nos requisitos de funcionalidade e de segurança, conforme descrito aqui:

• Uma sub-rede para hospedar o gateway de aplicativo, que serve como o proxy reverso. O Gateway de Aplicativo exige uma sub-rede dedicada.
• Uma sub-rede para hospedar o balanceador de carga interno para distribuir o tráfego para VMs back-end.
• Sub-redes para hospedar as VMs de carga de trabalho, uma para front-end e outra para back-end. Essas sub-redes são criadas de acordo com as camadas do aplicativo.
• Uma sub-rede para o host do Azure Bastion para facilitar o acesso operacional às VMs de carga de trabalho. Por design, o host do Azure Bastion precisa de uma sub-rede dedicada.
• Uma sub-rede para hospedar pontos de extremidade privados criados para acessar outros recursos do Azure no Link Privado do Azure. Embora as sub-redes dedicadas não sejam obrigatórias para esses pontos de extremidade, nós as recomendamos.

Semelhante às redes virtuais, as sub-redes devem ter o tamanho certo. Por exemplo, convém aplicar o limite máximo de VMs com suporte da Orquestração flexível para atender às necessidades de dimensionamento do aplicativo. As sub-redes de carga de trabalho devem ser capazes de acomodar esse limite.

Outro caso de uso a ser considerado são as atualizações do sistema operacional da VM, que podem exigir endereços IP temporários. O dimensionamento correto fornece o nível desejado de segmentação, garantindo que recursos semelhantes sejam agrupados para que regras de segurança significativas por meio de NSGs (grupos de segurança de rede) possam ser aplicadas aos limites da sub-rede. Para obter mais informações, consulte Segurança: Segmentação.

Tráfego de entrada

Dois endereços IP públicos são usados para fluxos de entrada. Um endereço se destina ao Gateway de Aplicativo que serve como proxy reverso. Os usuários se conectam usando esse endereço IP público. A carga do proxy reverso equilibra o tráfego de entrada para os IPs privados das VMs. O outro endereço se destina ao acesso operacional por meio do Azure Bastion.

Baixe um Arquivo Visio dessa arquitetura.

Tráfego de saída

Essa arquitetura usa o Load Balancer de SKU padrão com regras de saída definidas por meio das instâncias de VM. O Load Balancer foi escolhido porque tem redundância de zona.

Baixe um Arquivo Visio dessa arquitetura.

Essa configuração permite que você use os IPs públicos do balanceador de carga para fornecer conectividade de saída com a Internet para as VMs. As regras de saída permitem definir explicitamente as portas SNAT (conversão de endereços de rede) de origem. As regras permitem dimensionar e ajustar essa capacidade por meio da alocação manual de portas. Alocar manualmente a porta SNAT com base no tamanho do pool de back-end e no número de frontendIPConfigurations pode ajudar a evitar o esgotamento de SNAT.

Recomendamos que você aloque portas com base no número máximo de instâncias de back-end. Se forem adicionadas mais instâncias do que as portas SNAT restantes permitem, as operações de dimensionamento dos Conjuntos de Dimensionamento de Máquinas Virtuais poderão ser bloqueadas, ou as novas VMs não receberão portas SNAT suficientes.

Calcule as portas por instância como: Number of front-end IPs * 64K / Maximum number of back-end instances.

Há outras opções que você pode usar, como implantar um recurso de Gateway da NAT do Azure anexado à sub-rede. Outra opção é usar o Firewall do Azure ou outro Dispositivo de Virtualização de Rede com uma UDR (rota definida pelo usuário) personalizada como o próximo salto pelo firewall. Essa opção é mostrada na Arquitetura de linha de base de máquina virtual em uma zona de destino do Azure.

Resolução DNS

O DNS do Azure é usado como o serviço básico para todos os casos de uso de resolução, por exemplo, resolvendo nomes de domínio totalmente qualificados (FQDN) associados às VMs de carga de trabalho. Nessa arquitetura, as VMs usam os valores DNS definidos na configuração de rede virtual, que é o DNS do Azure.

As zonas DNS privadas do Azure são usadas para resolver solicitações para os pontos de extremidade privados usados para acessar os recursos de Link Privado do Azure nomeados.

Monitoramento

Essa arquitetura tem uma pilha de monitoramento que é desacoplada do utilitário da carga de trabalho. O foco está principalmente nas fontes de dados e nos aspectos de coleta.

Métricas e logs são gerados em várias fontes de dados, fornecendo insights de observabilidade em várias altitudes:

• A infraestrutura e os componentes subjacentes são considerados, como VMs, redes virtuais e serviços de armazenamento. Os logs da plataforma do Azure fornecem informações sobre operações e atividades na plataforma do Azure.

• O nível do aplicativo fornece insights sobre o desempenho e o comportamento dos aplicativos em execução no sistema.

O espaço de trabalho do Log Analytics é o coletor de dados de monitoramento recomendado usado para coletar logs e métricas dos recursos do Azure e do Application Insights.

Esta imagem mostra a pilha de monitoramento da linha de base com componentes para coletar dados da infraestrutura e do aplicativo, coletores de dados e várias ferramentas de consumo para análise e visualização. A implementação implanta alguns componentes, como Application Insights, diagnóstico de inicialização de VM e Log Analytics. Outros componentes são descritos para mostrar as opções de extensibilidade, como painéis e alertas.

Baixe um Arquivo Visio dessa arquitetura.

Monitoramento em nível de infraestrutura

Esta tabela se vincula a logs e métricas coletados pelo Azure Monitor. Os alertas disponíveis ajudam você a resolver proativamente os problemas antes que eles afetem os usuários.

Recurso do Azure	Métricas e logs	Alertas
Gateway de Aplicativo	Descrição dos logs e das métricas do Gateway de Aplicativo	Alertas do Gateway de Aplicativo
Application Insights	API de registro em log e métricas do Application Insights	Alertas do Application Insights
Azure Bastion	Métricas do Azure Bastion
Key Vault	Métricas e descrições de logs do Cofre de chaves	Alertas do Key Vault
Standard Load Balancer	Logs e métricas do balanceador de carga	Alertas do Load Balancer
Endereço IP público	Descrição dos logs e das métricas do endereço IP público	Alertas de métricas do endereço IP público
Rede Virtual	Referência de métricas e de logs da rede virtual	Alertas da rede virtual
Máquinas Virtuais e Conjuntos de Dimensionamento de Máquinas Virtuais	Referência de métricas e de logs de VM	Alertas e tutoriais de VM
Firewall do Aplicativo Web	Descrição dos logs e das métricas do Firewall de Aplicativo Web	Alertas do Firewall de Aplicativo Web

Para obter mais informações sobre o custo da coleta de métricas e de logs, consulte Opções e cálculos de custo do Log Analytics e Preços do espaço de trabalho do Log Analytics. A natureza da carga de trabalho e a frequência e o número de métricas e logs coletados afetam muito os custos da coleta de métricas e de logs.

Máquinas virtuais

O diagnóstico de inicialização do Azure é habilitado para observar o estado das VMs durante a inicialização, coletando informações de log serial e capturas de tela. Nessa arquitetura, esses dados podem ser acessados por meio do portal do Azure e do comando vm boot-diagnostics get-boot-log da CLI do Azure. Os dados são gerenciados pelo Azure e você não tem controle nem acesso ao recurso de armazenamento subjacente. No entanto, se seus requisitos de negócios exigirem mais controle, você poderá provisionar sua própria conta de armazenamento para armazenar diagnósticos de inicialização.

Insights da VM oferece uma maneira eficiente de monitorar VMs e conjuntos de dimensionamento. Ele reúne dados de espaços de trabalho do Log Analytics e fornece pastas de trabalho predefinidas para tendências de dados de desempenho. Esses dados podem ser exibidos por VM ou agregados em várias VMs.

O Gateway de Aplicativo e o balanceador de carga interno usam investigações de integridade para detectar o status do ponto de extremidade das VMs antes de enviar o tráfego.

Rede

Nessa arquitetura, os dados de log são coletados de vários componentes de rede que participam do fluxo. Esses componentes incluem o Gateway de Aplicativo, balanceadores de carga e o Azure Bastion. Eles também incluem componentes de segurança de rede, como redes virtuais, NSGs, endereços IP públicos e Link Privado.

Discos gerenciados

As métricas de disco dependem da sua carga de trabalho, exigindo uma combinação de métricas importantes. O monitoramento deve combinar essas perspectivas para isolar problemas de taxa de transferência do sistema operacional ou do aplicativo.

• A perspectiva da plataforma do Azure representa as métricas que indicam o serviço do Azure, independentemente da carga de trabalho conectada a ele. As métricas de desempenho de disco (IOPS e taxa de transferência) podem ser exibidas individualmente ou coletivamente para todos os discos conectados à VM. Use métricas de utilização de E/S de armazenamento para solucionar problemas ou alertar sobre a possível utilização de limite no disco. Se você usar o bursting para otimização de custos, monitore as métricas de porcentagem de créditos para identificar oportunidades de otimização adicional.

• A perspectiva do SO convidado representa as métricas que o operador de carga de trabalho visualizaria, independentemente da tecnologia de disco subjacente. O VM insights é recomendado para as principais métricas em discos conectados, como o espaço lógico em disco usado e a perspectiva do kernel do sistema operacional sobre IOPS de disco e taxa de transferência.

Monitoramento em nível de aplicativo

Mesmo que a implementação de referência não faça uso dele, o Application Insights é provisionado como um APM (Gerenciamento de desempenho de aplicativos) para fins de extensibilidade. O Application Insights coleta dados de um aplicativo e os envia ao espaço de trabalho do Log Analytics. Ele também pode visualizar esses dados dos aplicativos de carga de trabalho.

A extensão de integridade do aplicativo é implantada em VMs para monitorar o estado de integridade binário de cada instância de VM no conjunto de dimensionamento e executar reparos de instância, se necessário, usando o reparo automático de instância do conjunto de dimensionamento. Ele testa o mesmo arquivo que o Gateway de Aplicativo e a investigação de integridade interno do balanceador de carga do Azure para verificar se o aplicativo está respondendo.

Gerenciamento de atualizações

As VMs precisam ser atualizadas e corrigidas regularmente para que não enfraqueçam a postura de segurança da carga de trabalho. Recomendamos avaliações automáticas e periódicas da VM para descoberta e aplicação de patches antecipadas.

Atualizações de infraestrutura

O Azure atualiza a plataforma periodicamente para aprimorar a confiabilidade, o desempenho e a segurança da infraestrutura de host para máquinas virtuais. Essas atualizações incluem a aplicação de patch de componentes de software no ambiente de hospedagem e a atualização de componentes de rede até o encerramento de hardware e muito mais. Para obter informações sobre o processo de atualização, consulte Manutenção para máquinas virtuais no Azure.

Se uma atualização não exigir uma reinicialização, a VM será pausada, enquanto o host é atualizado ou a VM é migrada ao vivo para um host já atualizado. Se a manutenção exigir uma reinicialização, você será notificado sobre a manutenção planejada. O Azure também fornece uma janela de tempo na qual você pode iniciar a manutenção, conforme sua conveniência. Para obter informações sobre a janela de automanutenção e como configurar as opções disponíveis, consulte Lidando com as notificações de manutenção planejada.

Algumas cargas de trabalho podem não tolerar nem mesmo alguns segundos de congelamento ou desconexão de uma VM para manutenção. Para obter maior controle sobre todas as atividades de manutenção, incluindo impacto zero e atualizações sem reinicialização, consulte Configurações de Manutenção. A criação de uma Configuração de Manutenção oferece a opção de ignorar todas as atualizações de plataforma e aplicar as atualizações de acordo com a sua conveniência. Quando essa configuração personalizada é definida, o Azure ignora todas as atualizações de impacto não zero, incluindo atualizações sem reinicialização. Para obter mais informações, confira Gerenciando atualizações da plataforma com as Configurações de Manutenção.

Atualizações de imagem do sistema operacional (SO)

Ao fazer atualizações do SO, tenha uma imagem de ouro testada. Considere usar a Galeria de Imagens Compartilhadas do Azure e a Galeria de Computação do Azure para publicar suas imagens personalizadas. Você deve ter um processo implementado que atualize lotes de instâncias de maneira contínua sempre que uma nova imagem for publicada pelo editor.

Desative as imagens da VM antes que elas atinjam o fim da vida útil para reduzir a área de superfície.

Seu processo de automação deve levar em conta o excesso de provisionamento com capacidade extra.

Você pode usar o Gerenciamento de Atualizações do Azure para gerenciar atualizações do sistema operacional para suas máquinas virtuais Windows e Linux no Azure. O Gerenciador de Atualizações do Azure fornece uma solução SaaS para gerenciar e controlar atualizações de software para computadores Windows e Linux em ambientes Azure, locais e multinuvem.

Aplicação de patches do SO convidado

As VMs do Azure fornecem a opção de aplicação automática de patches de convidado da VM. Quando esse serviço é habilitado, as VMs são avaliadas periodicamente e os patches disponíveis são classificados. É recomendável que o Modo de Avaliação esteja habilitado para permitir a avaliação diária de patches pendentes. A avaliação sob demanda pode ser realizada, no entanto, ela não desencadeia a aplicação de patches. Se o Modo de Avaliação não estiver habilitado, tenha maneiras manuais de detectar atualizações pendentes.

Somente os patches classificados como críticos ou de segurança são aplicados automaticamente em todas as regiões do Azure. Defina processos personalizados de gerenciamento de atualizações que apliquem outros patches.

Para governança, considere a Política do Azure Exigir a aplicação automática de patch da imagem do sistema operacional em Conjuntos de Dimensionamento de Máquinas Virtuais.

A aplicação automática de patches pode sobrecarregar o sistema e causar interrupções porque as VMs usam recursos e podem ser reinicializadas durante as atualizações. O superprovisionamento é recomendado para o gerenciamento de carga. Implante VMs em Zonas de Disponibilidade diferentes para evitar atualizações simultâneas e mantenha pelo menos duas instâncias por zona para alta disponibilidade. As VMs na mesma região podem receber patches diferentes, que devem ser reconciliados ao longo do tempo.

Esteja ciente da compensação de custos associados ao superprovisionamento.

As verificações de integridade são incluídas como parte da aplicação automática de patches de convidado da VM. Essas verificações verificam a aplicação bem-sucedida de patches e detectam problemas.

Se houver processos personalizados para aplicar patches, use repositórios privados para fontes de patch. Isso oferece melhor controle no teste dos patches para garantir que a atualização não afete negativamente o desempenho ou a segurança.

Para obter mais informações, consulte Aplicação automática de patches de convidado de VM para VMs do Azure.

Confiabilidade

Essa arquitetura usa zonas de disponibilidade como um elemento fundamental para resolver problemas de confiabilidade.

Nessa configuração, VMs individuais são vinculadas a uma única zona. Se ocorrer uma falha, essas VMs poderão ser prontamente substituídas por outras instâncias de VM usando Conjuntos de Dimensionamento de Máquinas Virtuais.

Todos os outros componentes nesta arquitetura são:

• Zona redundante, o que significa que eles são replicados em várias zonas para alta disponibilidade, como Gateway de Aplicativo ou IPs públicos.
• Resistentes à zona, o que implica que podem resistir a falhas da zona, como o Key Vault.
• Recursos regionais ou globais disponíveis entre regiões ou globalmente, como o Microsoft Entra ID.

O design da carga de trabalho deve incorporar garantias de confiabilidade no código, na infraestrutura e nas operações do aplicativo. As seções a seguir ilustram algumas estratégias para garantir que a carga de trabalho seja resiliente a falhas e possa se recuperar se houver interrupções em nível de infraestrutura.

As estratégias usadas na arquitetura são baseadas na Lista de verificação de revisão de design de confiabilidade fornecida no Azure Well-Architected Framework. As seções são anotadas com recomendações dessa lista de verificação.

Como nenhum aplicativo é implantado, a resiliência no código do aplicativo está além do escopo dessa arquitetura. Recomendamos que você revise todas as recomendações na lista de verificação e as adote em sua carga de trabalho, se aplicável.

Priorize as garantias de confiabilidade por fluxo de usuário

Na maioria dos designs, há vários fluxos de usuário, cada um com seu próprio conjunto de requisitos de negócios. Nem todos esses fluxos exigem o mais alto nível de garantias, portanto, a segmentação é recomendada como uma estratégia de confiabilidade. Cada segmento pode ser gerenciado de forma independente, garantindo que um segmento não afete outros e fornecendo o nível certo de resiliência em cada camada. Essa abordagem também torna o sistema flexível.

Nessa arquitetura, as camadas de aplicativo implementam a segmentação. Conjuntos de dimensionamento separados são provisionados para as camadas front-end e back-end. Essa separação permite o dimensionamento independente de cada camada, permitindo a implementação de padrões de design com base em seus requisitos específicos, entre outros benefícios.

Consulte o Well-Architected Framework: RE:02 - Recomendações para identificar e classificar fluxos.

Identificar os possíveis pontos de falha

Toda arquitetura é suscetível a falhas. O exercício da análise do modo de falha permite antecipar falhas e estar preparado com mitigações. Veja alguns possíveis pontos de falha nessa arquitetura:

Componente	Risco	Probabilidade	Efeito/Mitigação/Nota	Interrupção
ID do Microsoft Entra	Configuração incorreta	Médio	Os usuários de operações não conseguem entrar. Sem efeito posterior. O suporte técnico relata problema de configuração para a equipe de identidade.	Nenhum
Gateway de Aplicativo	Configuração incorreta	Médio	Configurações incorretas devem ser detectadas durante a implantação. Se esses erros acontecerem durante uma atualização de configuração, a equipe de DevOps deverá reverter as alterações. A maioria das implantações que usam a SKU v2 levam cerca de 6 minutos para serem provisionadas. No entanto, pode levar mais tempo dependendo do tipo de implantação. Por exemplo, implantações em várias zonas de disponibilidade com muitas instâncias podem levar mais de 6 minutos.	Completo
Gateway de Aplicativo	Ataque de DDoS	Médio	Potencial de interrupção. A Microsoft gerencia a proteção contra DDoS (L3 e L4). Risco potencial de efeito de ataques L7.	Completo
Conjuntos de Dimensionamento de Máquinas Virtuais	Interrupção do serviço	Baixo	Possível interrupção da carga de trabalho se houver instâncias de VM não íntegras que acionem o reparo automático. Correção dependente da Microsoft.	Interrupção potencial
Conjuntos de Dimensionamento de Máquinas Virtuais	Interrupção da zona de disponibilidade	Baixo	Nenhum efeito. Os conjuntos de dimensionamento são implantados como redundância de zona.	Nenhum

Consulte Well-Architected Framework: RE:03 - Recomendações para realizar a análise do modo de falha.

Metas de confiabilidade

Para tomar decisões de design, é importante calcular as metas de confiabilidade, como os SLOs (objetivos de nível de serviço) compostos da carga de trabalho. Isso envolve a compreensão dos SLAs (contratos de nível de serviço) fornecidos pelos serviços do Azure usados na arquitetura. Os SLOs de carga de trabalho não devem ser maiores do que os SLAs garantidos pelo Azure. Examine cuidadosamente cada componente, desde VMs e suas dependências, opções de rede e de armazenamento.

Veja um exemplo de cálculo em que o objetivo principal é fornecer um SLO composto aproximado. Embora seja uma diretriz aproximada, você deve chegar a algo semelhante. Você não deve obter um SLO composto máximo mais alto para os mesmos fluxos, a menos que faça modificações na arquitetura.

Fluxo de operação

Componente	SLO
ID do Microsoft Entra	99,99%
Azure Bastion	99.95%

SLO composto: 99,94% | Tempo de inatividade por ano: 0d 5h 15m 20s

Fluxo de usuário do aplicativo

Componente	SLO
Gateway de Aplicativo	99.95%
Azure Load Balancer (interno)	99,99%
VMs front-end usando armazenamento premium (SLO composto)	99,70%
VMs back-end usando armazenamento premium (SLO composto)	99,70%

SLO composto: 99,34% | Tempo de inatividade por ano: 2d 9h 42m 18s

No exemplo anterior, a confiabilidade das VMs e as dependências são incluídas, como discos associados a VMs. Os SLAs associados ao armazenamento em disco afetam a confiabilidade geral.

Existem alguns desafios ao calcular o SLO composto. É importante observar que diferentes níveis de serviço podem vir com SLAs diferentes, e eles geralmente incluem garantias com apoio financeiro que definem metas de confiabilidade. Por fim, pode haver componentes da arquitetura que não têm SLAs definidos. Por exemplo, em termos de rede, NICs e redes virtuais não têm seus próprios SLAs.

Os requisitos de negócios e suas metas devem ser claramente definidos e levados em consideração no cálculo. Esteja ciente dos limites de serviço e outras restrições impostas pela organização. Compartilhar sua assinatura com outras cargas de trabalho pode afetar os recursos disponíveis para suas VMs. A carga de trabalho pode ter permissão para usar um número limitado de núcleos disponíveis para as VMs. Compreender o uso de recursos de sua assinatura pode ajudar você a projetar suas VMs com mais eficiência.

Consulte Well-Architected Framework: RE:04 - Recomendações para definir metas de confiabilidade.

Redundância

Essa arquitetura usa redundância de zona para vários componentes. Cada zona é composta de um ou mais datacenters equipados com energia, resfriamento e rede independentes. Ter instâncias executadas em zonas separadas protege o aplicativo contra falhas no datacenter.

• Os Conjuntos de Dimensionamento de Máquinas Virtuais alocam um número especificado de instâncias e as distribuem uniformemente entre zonas de disponibilidade e domínios de falha. Essa distribuição é obtida por meio da capacidade de propagação máxima, que recomendamos. A disseminação de instâncias de VM entre domínios de falha garante que todas as VMs não sejam atualizadas ao mesmo tempo.

  Considere um cenário em que há três zonas de disponibilidade. Se você tiver três instâncias, cada uma será alocada para uma zona de disponibilidade diferente e colocada em um domínio de falha diferente. O Azure garante que apenas um domínio de falha seja atualizado por vez em cada zona de disponibilidade. No entanto, pode haver uma situação em que todos os três domínios de falha que hospedam suas VMs nas três zonas de disponibilidade sejam atualizados simultaneamente. Todas as zonas e domínios são afetados. Ter pelo menos duas instâncias em cada zona fornece um buffer durante as atualizações.

• Os discos gerenciados só podem ser conectados a uma VM na mesma região. A disponibilidade deles normalmente afeta a disponibilidade da VM. Para implantações de região única, os discos podem ser configurados para redundância para suportar falhas em zonas. Nessa arquitetura, os discos de dados são configurados com ZRS (armazenamento com redundância de zona) nas VMs back-end. Requer uma estratégia de recuperação para aproveitar as zonas de disponibilidade. A estratégia de recuperação é reimplantar a solução. O ideal é pré-provisionar a computação em zonas de disponibilidade alternativas prontas para se recuperar de uma falha na zona.

• Um Gateway de Aplicativo com redundância de zona ou um balanceador de carga padrão pode direcionar o tráfego para VMs entre zonas usando um único endereço IP, garantindo a continuidade mesmo se ocorrerem falhas na zona. Esses serviços usam investigações de integridade para verificar a disponibilidade da VM. Enquanto uma zona na região permanecer operacional, o roteamento continuará apesar de possíveis falhas em outras zonas. No entanto, o roteamento entre zonas pode ter maior latência em comparação com o roteamento dentro da zona.

  Todos os IPs públicos usados nessa arquitetura têm redundância de zona.

• O Azure oferece serviços resilientes à zona para melhorar a confiabilidade, como o Key Vault.

• Os recursos globais do Azure estão sempre disponíveis e podem alternar para outra região, se necessário, como o provedor de identidade fundamental, o Microsoft Entra ID.

Consulte Well-Architected Framework: RE:05 - Recomendações para projetar para fins de redundância.

Estratégia de dimensionamento

Para evitar a degradação e as falhas do nível de serviço, garanta operações de dimensionamento confiáveis. Dimensione a carga de trabalho horizontalmente (expansão), verticalmente ou use uma combinação das duas abordagens. Use o Escala automática do Azure Monitor para provisionar recursos suficientes para oferecer suporte à demanda no aplicativo sem alocar mais capacidade do que o necessário e gerar custos desnecessários.

A escala automática permite definir perfis diferentes com base em diferentes tipos de evento, como tempo, programação ou métricas. Os perfis baseados em métricas podem usar métricas internas (baseadas em host) ou métricas mais detalhadas (métricas de VM no convidado) que exigem a instalação do Agente do Azure Monitor para coletá-las. Cada perfil contém regras para expansão (aumento) e para reduzir horizontalmente (diminuição). Considere explorar todos os diferentes cenários de dimensionamento com base em perfis projetados e avalie-os quanto a possíveis condições de loop que podem causar uma série de eventos de dimensionamento opostos. O Azure Monitor tentará mitigar essa situação aguardando o período de resfriamento antes que ele seja dimensionado novamente.

Embora os Conjuntos de Dimensionamento de Máquinas Virtuais do Azure no modo Flexível ofereçam suporte a ambientes heterogêneos, não há suporte para o dimensionamento automático de vários perfis. Considere a criação de conjuntos de dimensionamento diferentes para gerenciá-los separadamente se você planeja usar a escala automática com mais de um tipo de VM.

Considere outros aspectos, como inicialização, desligamentos normais, instalação da carga de trabalho e todas as suas dependências e gerenciamento de disco ao criar ou excluir instâncias de VMs.

Cargas de trabalho com estado podem exigir gerenciamento extra de discos gerenciados que precisam permanecer além de uma instância de carga de trabalho. Projete sua carga de trabalho para gerenciamento de dados em eventos de dimensionamento para consistência, sincronização, replicação e integridade dos dados da carga de trabalho. Para esses cenários, considere adicionar discos pré-preenchidos a conjuntos de dimensionamento. Para casos de uso em que o dimensionamento é usado para evitar gargalos ao acessar dados, planeje o particionamento e a fragmentação. Para obter mais informações, confira Práticas recomendadas da escala automática.

Consulte Well-Architected Framework: RE:06 - Recomendações para projetar uma estratégia de dimensionamento confiável.

Auto-recuperação e capacidade de recuperação

O recurso Reparos automáticos de instância está habilitado nos Conjuntos de Dimensionamento de Máquinas Virtuais para automatizar a recuperação de falhas da VM. A extensão de integridade do aplicativo é implantada em VMs para oferecer suporte à detecção de VMs e aplicativos que não respondem. Para esses casos, as ações de reparo são acionadas automaticamente.

Consulte Well-Architected Framework: Recomendações para autorrecuperação e autopreservação.

Segurança

Essa arquitetura ilustra algumas das garantias de segurança fornecidas na Lista de verificação de revisão de design de segurança fornecida no Azure Well-Architected Framework. As seções são anotadas com recomendações dessa lista de verificação.

Segurança não se refere apenas a controles técnicos. Recomendamos que você siga toda a lista de verificação para entender os aspectos operacionais do pilar Segurança.

Segmentação

• Segmentação de rede. Os recursos de carga de trabalho são colocados em uma rede virtual, que fornece isolamento da Internet. Dentro da rede virtual, as sub-redes podem ser usadas como limites de confiança. Coloque os recursos relacionados necessários para lidar com uma transação em uma sub-rede. Nessa arquitetura, a rede virtual é dividida em sub-redes com base no agrupamento lógico do aplicativo e na finalidade de vários serviços do Azure usados como parte da carga de trabalho.

  A vantagem da segmentação de sub-rede é que você pode colocar controles de segurança no perímetro que controla o tráfego que entra e sai da sub-rede, restringindo assim o acesso aos recursos da carga de trabalho.

• Segmentação de identidade. Atribua funções distintas a identidades diferentes com permissões suficientes para executar suas tarefas. Essa arquitetura usa identidades gerenciadas pelo Microsoft Entra ID para segmentar o acesso aos recursos.

• Segmentação de recursos. O aplicativo é segmentado por camadas em conjuntos de dimensionamento separados, o que garante que os componentes do aplicativo não sejam colocalizados.

Consulte Well-Architected Framework: SE:04 - Recomendações para criar uma estratégia de segmentação.

Gerenciamento de identidade e de acesso

Recomendamos o Microsoft Entra ID para autenticação e autorização de usuários e serviços.

O acesso às VMs requer uma conta de usuário, controlada pela autenticação do Microsoft Entra ID e apoiada por grupos de segurança. Essa arquitetura fornece suporte implantando a extensão da autenticação do Microsoft Entra ID em todas as VMs. Recomendamos que os usuários utilizem as respectivas identidades corporativas no locatário do Microsoft Entra ID da organização. Além disso, garanta que qualquer acesso baseado na entidade de serviço não seja compartilhado entre funções.

Os recursos da carga de trabalho, como VMs, são autenticados usando as identidades gerenciadas atribuídas a outros recursos. Essas identidades, baseadas nas entidades de serviço do Microsoft Entra ID, são gerenciadas automaticamente.

Por exemplo, as extensões do Key Vault são instaladas nas VMs, que as inicializam com certificados instalados. Nessa arquitetura, as identidades gerenciadas atribuídas pelo usuário são usadas pelo Gateway de Aplicativo, VMs front-end e VMs back-end para acessar o Key Vault. Essas identidades gerenciadas são configuradas durante a implantação e usadas para autenticação no Key Vault. As políticas de acesso no Key Vault são configuradas para aceitar apenas solicitações das identidades gerenciadas anteriores.

A arquitetura de linha de base usa uma combinação de identidades gerenciadas atribuídas pelo sistema e pelo usuário. Essas identidades são necessárias para usar o Microsoft Entra ID para fins de autorização ao acessar outros recursos do Azure.

Consulte Well-Architected Framework: SE:05 - Recomendações para gerenciamento de identidade e acesso.

Controles de rede

• Tráfego de entrada. As VMs de carga de trabalho não são diretamente expostas à Internet pública. Cada VM tem um endereço IP privado. Os usuários da carga de trabalho se conectam usando o endereço IP público do Gateway de Aplicativo.

  Mais segurança é fornecida por meio do Firewall de Aplicativo Web integrado ao Gateway de Aplicativo. Ele tem regras que inspecionam o tráfego de entrada e pode tomar as medidas apropriadas. O WAF monitora vulnerabilidades do OWASP (Open Web Application Security Project) que impedem ataques conhecidos.

• Tráfego de saída. Não há controles sobre o tráfego de saída, exceto as regras NSG de saída nas sub-redes da VM. Recomendamos que todo o tráfego de saída da Internet flua por um único firewall. Esse firewall geralmente é um serviço central fornecido por uma organização. Esse caso de uso é mostrado na Arquitetura de linha de base de máquina virtual em uma zona de destino do Azure.

• Tráfego leste-oeste. O fluxo de tráfego entre as sub-redes é restrito pela aplicação de regras de segurança granulares.

  Os NSGs (grupos de segurança de rede) são colocados para restringir o tráfego entre sub-redes com base em parâmetros, como intervalo de endereços IP, portas e protocolos. Os ASGs (grupos de segurança de aplicativos) são colocados em VMs front-end e back-end. Eles são usados com NSGs para filtrar o tráfego de e para as VMs.

• Tráfego operacional. Recomendamos que o acesso operacional seguro a uma carga de trabalho seja fornecido por meio do Azure Bastion, o que elimina a necessidade de um IP público. Nessa arquitetura, essa comunicação é via SSH e é apoiada por VMs Windows e Linux. O Microsoft Entra ID é integrado ao SSH para os dois tipos de VMs usando a extensão de VM correspondente. Essa integração permite que a identidade de um operador seja autenticada e autorizada por meio do Microsoft Entra ID.

  Como alternativa, use uma VM separada como um jumpbox, implantado em sua própria sub-rede, onde você pode instalar sua opção de ferramentas de administração e de solução de problemas. O operador acessa o jumpbox por meio do host do Azure Bastion. Em seguida, entram nas VMs atrás do balanceador de carga por meio do jumpbox.

  Nessa arquitetura, o tráfego operacional é protegido usando regras NSG para restringir o tráfego, e o acesso à VM JIT (just-in-time) é habilitado nas VMs. Esse recurso do Microsoft Defender para Nuvem permite acesso temporário de entrada a portas selecionadas.

  Para aprimorar a segurança, use o PIM (Privileged Identity Management) do Microsoft Entra. O PIM é um serviço no Microsoft Entra ID que permite gerenciar, controlar e monitorar o acesso a importantes recursos na sua organização. O PIM fornece ativação de função baseada em tempo e aprovação para atenuar os riscos de permissões de acesso excessivas, desnecessárias ou que foram indevidamente utilizadas em recursos importantes.

• Conectividade privada com serviços de PaaS (plataforma como serviço). A comunicação entre as VMs e o Key Vault é realizada por Link Privado. Esse serviço requer pontos de extremidade privados, que são colocados em uma sub-rede separada.

• Proteção contra DDoS. Considere habilitar a Proteção contra DDoS do Azure nos IPs públicos expostos pelo Gateway de Aplicativo e pelo Host do Azure Bastion para detectar ameaças. A Proteção contra DDoS também fornece alertas, telemetria e análise por meio do Monitor. Para obter mais informações, confira Proteção contra DDoS do Azure: práticas recomendadas e arquiteturas de referência.

Consulte Well-Architected Framework: SE:06 - Recomendações para rede e conectividade.

Criptografia

• Dados em trânsito. O tráfego entre usuários e o IP público do Gateway de Aplicativo é criptografado usando o certificado externo. O tráfego entre o gateway de aplicativo e as VMs front-end e entre as VMs front-end e back-end é criptografado usando um certificado interno. Os dois certificados são armazenados no Key Vault:

  • app.contoso.com: um certificado externo usado por clientes e pelo Gateway de Aplicativo para tráfego seguro da Internet pública.
  • *.workload.contoso.com: um certificado curinga usado pelos componentes de infraestrutura para tráfego interno seguro.

• Dados inativos. Os dados de log são armazenados em um disco gerenciado conectado a VMs. Esses dados são criptografados automaticamente usando a criptografia fornecida pela plataforma no Azure.

Consulte Well-Architected Framework: SE:07 - Recomendações para criptografia de dados.

Gerenciamento de segredos

Baixe um Arquivo Visio dessa arquitetura.

O Key Vault fornece gerenciamento seguro de segredos, incluindo certificados TLS. Nessa arquitetura, os certificados TLS são armazenados no Key Vault e recuperados durante o processo de provisionamento pelas identidades gerenciadas do Gateway de Aplicativo e pelas VMs. Após a configuração inicial, esses recursos só acessam o Key Vault quando os certificados são atualizados.

As VMs usam a extensão de VM do Key Vault para atualizar automaticamente os certificados monitorados. Se alguma alteração for detectada no repositório de certificados local, a extensão recuperará e instalará os certificados correspondentes do Key Vault. A extensão oferece suporte aos tipos de conteúdo de certificado PKCS #12 e PEM.

Consulte Well-Architected Framework: SE:09 - Recomendações para proteger segredos de aplicativos.

Otimização de custos

Os requisitos de carga de trabalho devem ser atendidos tendo-se em mente as restrições de custo. As estratégias usadas na arquitetura são baseadas na Lista de verificação de revisão de design de Otimização de custos fornecida no Azure Well-Architected Framework. Esta seção descreve algumas opções para otimizar o custo e é anotada com recomendações dessa lista de verificação.

Custo dos componentes

Selecione imagens de VM otimizadas para a carga de trabalho em vez de usar imagens de uso geral. Nessa arquitetura, imagens de VM relativamente pequenas são escolhidas para Windows e Linux, que têm 30 GB cada. Com imagens menores, as SKUs de VM com discos também são menores, gerando custos mais baixos, consumo reduzido de recursos e tempos de implantação e inicialização mais rápidos. Um benefício é o aumento da segurança devido à área de superfície reduzida.

A implementação da rotação de logs com limites de tamanho é outra estratégia de economia de custos. Ela permite o uso de pequenos discos de dados, o que pode gerar custos mais baixos. A implementação dessa arquitetura usa discos de 4 GB.

O uso de discos do SO efêmero também pode ocasionar a redução de custos e melhorar o desempenho. Esses discos são projetados para usar recursos de VM pelos quais você já paga porque estão instalados no disco de cache provisionado com a VM. Ele elimina os custos de armazenamento associados aos discos persistentes tradicionais. Como esses discos são temporários, não há custos associados ao armazenamento de dados de longo prazo.

Consulte Well-Architected Framework: CO:07 - Recomendações para otimizar os custos dos componentes.

Custo de fluxo

Escolha recursos de computação com base no nível de importância do fluxo. Para fluxos projetados para tolerar um tamanho indeterminado, considere o uso de VMs spot com o modo de orquestração Flexível de Conjuntos de Dimensionamento de Máquinas Virtuais. Essa abordagem pode ser eficaz para hospedar fluxos de baixa prioridade em VMs de prioridade mais baixa. Essa estratégia permite a otimização de custos e, ao mesmo tempo, o cumprimento dos requisitos de diferentes fluxos.

Consulte Well-Architected Framework: CO:09 - Recomendações para otimizar os custos dos fluxos.

Custo do dimensionamento

Se o principal fator de custo for o número de instâncias, talvez seja mais econômico realizar a escalabilidade vertical aumentando o tamanho ou o desempenho das VMs. Essa abordagem pode ocasionar a redução de custos em várias áreas:

• Licenciamento de software. VMs maiores podem lidar com mais carga de trabalho, possivelmente reduzindo o número de licenças de software necessárias.
• Tempo de manutenção: VMs menores e maiores podem reduzir os custos operacionais.
• Balanceamento de carga: menos VMs podem gerar custos mais baixos para balanceamento de carga. Por exemplo, nessa arquitetura há várias camadas de balanceamento de carga, como um gateway de aplicativo na frente e um balanceador de carga interno no meio. Os custos de balanceamento de carga aumentariam se fosse necessário gerenciar um número maior de instâncias.
• Armazenamento em disco. Se houver aplicativos com estado, mais instâncias precisarão de mais discos gerenciados conectados, aumentando o custo de armazenamento.

Consulte Well-Architected Framework: CO:12 - Recomendações para otimizar os custos de dimensionamento.

Custos operacionais

A aplicação automática de patches de convidado de VM reduz a sobrecarga de aplicação manual de patches e os custos de manutenção associados. Essa ação não apenas ajuda a tornar o sistema mais seguro, mas também otimiza a alocação de recursos, contribuindo para a eficiência geral de custos.

Consulte Well-Architected Framework: CO:13 - Recomendações para otimizar o tempo do pessoal.

Implantar este cenário

Uma implantação para essa arquitetura de referência está disponível no GitHub.

Recursos relacionados

Consulte a documentação do produto para obter detalhes sobre serviços específicos do Azure:

• Máquinas Virtuais do Azure
• Conjuntos de dimensionamento de máquina virtual do Azure
• Rede Virtual do Azure
• Gateway de Aplicativo do Azure Standard_v2
• Azure Load Balancer
• Azure Key Vault
• Azure Bastion
• Application Insights
• Log Analytics

Próxima etapa

Analise as arquiteturas de referência de IaaS que mostram opções para a camada de dados:

• Aplicativo de n camadas do Windows usando o SQL Server no Azure