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:

• Aplicações privadas. Esses aplicativos incluem aplicativos internos de linha de negócios ou soluções comerciais prontas para uso.
• Aplicações públicas. Esses aplicativos são voltados para a Internet. Essa arquitetura não é para 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. Esses componentes incluem componentes de computação, armazenamento, rede e 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 de estrutura bem arquitetada
▪ Diagrama de arquitetura ▪ Recursos de carga de trabalho ▪ Recursos de apoio ▪ Fluxos de usuários	▪ Opções de design de VM ▪ Discos ▪ Rede ▪ Monitorização ▪ Gerenciamento de atualizações	▪ Fiabilidade ▪ 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 listada em Recursos relacionados.

Componentes

Essa arquitetura consiste em vários serviços do Azure para recursos de carga de trabalho e recursos de suporte de carga de trabalho. Os serviços para cada um 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, uma combinação de VMs Windows e Linux é usada.

  Os Conjuntos de Dimensionamento de Máquina Virtual 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 sua 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 onde 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 monitoração de estado. As VMs back-end persistem dados para Premium_ZRS discos locais como parte de sua 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 roteia 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 Balanceador de Carga do Azure interno roteia o tráfego da camada front-end para os servidores back-end.

• O SKU padrão do Balanceador de Carga do Azure fornece acesso de saída à Internet para as VMs usando três endereços IP públicos.

• O Cofre de Chaves do Azure 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 suporte de carga de trabalho

• O Bastião do Azure fornece 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 de carga de trabalho

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

2. O Application Gateway recebe tráfego HTTPS, descriptografa dados usando um certificado externo para inspeção 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 o acesso seja monitorado. O acesso pode ser para 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 Bastião do Azure 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 do Azure ou na CLI do Azure.
2. O operador acessa o serviço Bastião do Azure 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 (SO).

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

Para obter informações sobre os SKUs de VM com suporte, consulte Tamanhos para 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 iniciar na VM sem atraso ou intervenção manual. Aqui estão as recomendações para automação:

• Extensões de máquina virtual. Essas extensões são objetos do Gerenciador de Recursos do Azure que são gerenciados por meio de sua implantação de Infraestrutura como Código (IaC). 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 que você execute os scripts por meio da Extensão de Script Personalizado do Azure.

  Aqui estão algumas outras extensões que podem ser usadas para instalar ou configurar automaticamente a funcionalidade nas VMs.

  • O Azure Monitor Agent (AMA) coleta dados de monitoramento do sistema operacional convidado e os entrega ao Azure Monitor.
  • A Extensão de Script Personalizado do Azure (Windows, Linux) Versão 2 baixa e executa scripts em máquinas virtuais (VMs) do Azure. Essa extensão é útil para automatizar a configuração pós-implantação, a instalação de software ou quaisquer outras tarefas de configuração ou gerenciamento.
  • A extensão de máquina virtual do Cofre de Chaves do Azure (Windows, Linux) fornece atualização automática de certificados armazenados em um Cofre de Chaves detectando alterações e instalando os certificados correspondentes.
  • A extensão de Integridade do Aplicativo com Conjuntos de Dimensionamento de Máquina Virtual é importante quando os Conjuntos de Dimensionamento de Máquina Virtual 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 em seu conjunto de escala e executar reparos de instância usando Reparos Automáticos de Instância.
  • O Microsoft Entra ID e o OpenSSH (Windows, Linux) integram-se com a autenticação 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 versionada 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 populares incluem Configuração de Estado Desejado para Windows, Configuração de Estado Desejado 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 projeto de automação.

Conectividade de VM

Para habilitar a comunicação privada entre uma VM e outros dispositivos em uma rede virtual específica, a placa de interface 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 é 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 é suportada pelas NICs de VM do Azure. Para obter mais informações, consulte Benefícios da rede acelerada.

Conjuntos de dimensionamento de máquina virtual com orquestração flexível

As VMs são provisionadas como parte de Conjuntos de Dimensionamento de Máquina Virtual com orquestração flexível. Os Conjuntos de Dimensionamento de Máquina Virtual 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, interfaces 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 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 escala, o Azure distribui uniformemente instâncias entre domínios de falha para resiliência contra um único problema de hardware ou 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 suportam 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 tipo de disco.

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

• Limitações de VM SKU. Os discos operam dentro da VM à qual estão conectados, que têm limites de IOPS e taxa de transferência. Verifique se o disco não limita 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 provisionamento excessivo, pois isso afeta o custo.

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

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

  A capacidade dos discos do sistema operacional 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 levar a recursos subutilizados 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 de SKU da VM e do disco gerenciado.

  Você pode ajustar o desempenho sob demanda alterando as camadas de desempenho ou usando os recursos de intermitência oferecidos em alguns SKUs de disco gerenciado.

  Embora o provisionamento excessivo reduza a necessidade de intermitência, ele pode levar à 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 consistência transacional de disco alto. Esses componentes podem se beneficiar do cache somente leitura. Componentes pesados de gravação que exigem consistência transacional de disco alto geralmente têm o cache desabilitado.

  O uso do cache de leitura-gravação pode causar perda de dados se a VM falhar e não for recomendado 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 individuais de VM 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 incorre em 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 aterrissagem 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 construções 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 levar à subutilização. É importante observar que, uma vez que a rede virtual é criada, 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-redes

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

• Uma sub-rede para hospedar o gateway de aplicativo, que serve como o proxy reverso. O Application Gateway requer uma sub-rede dedicada.
• Uma sub-rede para hospedar o balanceador de carga interno para distribuir o tráfego para VMs de 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 Bastião do Azure para facilitar o acesso operacional às VMs de carga de trabalho. Por design, o host do Bastião do Azure 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 endpoints, nós as recomendamos.

Semelhante às redes virtuais, as sub-redes devem ter o tamanho certo. Por exemplo, talvez você queira aplicar o limite máximo de VMs com suporte na 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 VM, que podem exigir endereços IP temporários. O dimensionamento correto fornece o nível desejado de segmentação, certificando-se de 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 é para o Application Gateway 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 é para acesso operacional por meio do Bastião do Azure.

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 a partir das instâncias de VM. O Load Balancer foi escolhido porque é redundante de zona.

Baixe um Arquivo Visio dessa arquitetura.

Essa configuração permite que você use o(s) IP(s) público(s) do balanceador de carga para fornecer conectividade de saída à 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. A alocação manual da porta SNAT com base no tamanho e no número de pool de back-end pode ajudar a evitar a exaustão do frontendIPConfigurations SNAT.

Recomendamos que você aloque portas com base no número máximo de instâncias de back-end. Se mais instâncias forem adicionadas do que as portas SNAT restantes permitem, as operações de dimensionamento de Conjuntos de Dimensionamento de Máquina Virtual 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 NAT do Azure anexado à sub-rede. Outra opção é usar o Firewall do Azure ou outro Dispositivo Virtual de Rede com uma rota personalizada definida pelo usuário (UDR) como o próximo salto pelo firewall. Essa opção é mostrada na arquitetura de linha de base da máquina virtual em uma zona de aterrissagem 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 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 Azure fornecem informações sobre operações e atividades na plataforma 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 Análise de Log é 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 vincula-se 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.

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

Para obter mais informações sobre o custo da coleta de métricas e logs, consulte Cálculos e opções de custo do Log Analytics e Preços para o 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 de coleta de métricas e logs.

Máquinas virtuais

O diagnóstico de inicialização do Azure está 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 get-boot-log da VM da CLI do Azure. Os dados são gerenciados pelo Azure e você não tem controle ou 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.

O VM insights oferece uma maneira eficiente de monitorar VMs e dimensionar conjuntos. 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 Application Gateway e o balanceador de carga interno usam testes 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 Bastião do Azure. 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 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 possíveis limites de 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 sistema operacional 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 dela, o Application Insights é provisionado como um APM (Application Performance Management, gerenciamento de desempenho de aplicativo) para fins de extensibilidade. O Application Insights coleta dados de um aplicativo e envia esses dados para o 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 escala e executar reparos de instância, se necessário, usando o reparo automático de instância do conjunto de escala. Ele testa o mesmo arquivo que o Gateway de Aplicativo e o teste 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 de VM para descoberta antecipada e aplicação de patches.

Atualizações de infraestrutura

O Azure atualiza sua 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 patches em componentes de software no ambiente de hospedagem, atualização de componentes de rede ou descomissionamento 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 for atualizado ou a VM será 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 Manipulando 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 atualizações sem impacto e 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 da plataforma e aplicá-las conforme 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, consulte Gerenciando atualizações de plataforma com configurações de manutenção

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

Ao fazer atualizações do sistema operacional, tenha uma imagem dourada que é 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 em vigor 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 Azure Update Management para gerenciar atualizações do sistema operacional para suas máquinas virtuais Windows e Linux no Azure.O Azure Update Manager fornece uma solução SaaS para gerenciar e controlar atualizações de software para computadores Windows e Linux em ambientes Azure, locais e multicloud.

Patch do SO convidado

As VMs do Azure fornecem a opção de aplicação automática de patches de convidado de 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 feita, no entanto, isso 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 correção automática de imagem do sistema operacional em Conjuntos de Dimensionamento de Máquina Virtual.

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 provisionamento excessivo é recomendado para o gerenciamento de carga. Implante VMs em zonas de disponibilidade diferentes para evitar atualizações simultâneas e manter 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 associada ao provisionamento excessivo.

As verificações de integridade são incluídas como parte do patch automático de convidado da VM. Essas verificações verificam o aplicativo de patch bem-sucedido 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 Patch automático 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áquina Virtual.

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 Application Gateway ou IPs públicos.
• Resilientes de zona, o que implica que podem resistir a falhas de zona, como o Cofre de Chaves.
• 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 no nível da 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 projetos, 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 projeto 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. Aqui estão alguns possíveis pontos de falha nessa arquitetura:

Componente	Risco	Probabilidade	Efeito/Mitigação/Nota	Interrupção
Microsoft Entra ID	Configuração incorreta	Médio	Os usuários de operações não conseguem entrar. Sem efeito a jusante. O suporte técnico relata o 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 disrupção. A Microsoft gerencia a proteção contra DDoS (L3 e L4). Risco potencial de efeito de ataques L7.	Completo
Conjuntos de Escala de Máquina Virtual	Interrupção do serviço	Baixo	Possível interrupção da carga de trabalho se houver instâncias de VM não íntegras que acionam o reparo automático. Dependente da Microsoft para corrigir.	Interrupção potencial
Conjuntos de Escala de Máquina Virtual	Interrupção da zona de disponibilidade	Baixo	Nenhum efeito. Os conjuntos de escala são implantados como zona redundante.	Nenhum

Consulte Well-Architected Framework: RE: 03 - Recomendações para executar 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 armazenamento.

Aqui está um exemplo de cálculo em que o objetivo principal é fornecer um SLO composto aproximado. Embora esta 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
Microsoft Entra ID	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 (internal)	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 suporte financeiro que definem metas de confiabilidade. Finalmente, 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 ajudá-lo 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. Esta distribuição é conseguida através da capacidade máxima de propagação , 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 instância 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. Sua disponibilidade normalmente afeta a disponibilidade da VM. Para implantações de região única, os discos podem ser configurados para redundância para suportar falhas zonais. Nessa arquitetura, os discos de dados são configurados com ZRS (zone-redundant storage, 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, pronto para se recuperar de uma falha zonal.

• Um Application Gateway com redundância de zona ou balanceador de carga padrão pode rotear o tráfego para VMs entre zonas usando um único endereço IP, garantindo a continuidade mesmo se ocorrerem falhas de zona. Esses serviços usam testes de integridade para verificar a disponibilidade da VM. Enquanto uma zona da região permanecer operacional, o roteamento continua 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 intrazona.

  Todos os IPs públicos usados nessa arquitetura são redundantes de zona.

• O Azure oferece serviços resilientes à zona para melhor confiabilidade, como o Cofre de Chaves.

• 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 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 (scale-out), verticalmente (scale-up) ou use uma combinação de ambas as abordagens. Use o Azure Monitor Autoscale para provisionar recursos suficientes para dar suporte à demanda em seu aplicativo sem alocar mais capacidade do que o necessário e incorrer em custos desnecessários.

O dimensionamento automático permite definir perfis diferentes com base em diferentes tipos de eventos, 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 convidadas) que exigem a instalação do Agente do Azure Monitor para coletá-las. Cada perfil contém regras para scale-out (aumento) e scale-in (diminuição). Considere explorar todos os diferentes cenários de dimensionamento com base em perfis projetados e avalie-os para possíveis condições de loop que podem causar uma série de eventos de escala 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áquina Virtual 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 escala diferentes para gerenciá-los separadamente se você planeja usar o dimensionamento automático com mais de um tipo de VM.

Considere outros aspectos, como bootstrapping, 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 monitoração de estado podem exigir gerenciamento extra para discos gerenciados que precisam viver 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 escala. 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, consulte Práticas recomendadas de dimensionamento automático.

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

Os reparos automáticos de instância estão habilitados nos Conjuntos de Dimensionamento de Máquina Virtual para automatizar a recuperação de falhas de 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 Estrutura bem arquitetada: recomendações para auto-cura 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 redes. 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 de 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 escala separados, o que garante que os componentes do aplicativo não sejam colocalizados.

Consulte o Well-Architected Framework: SE: 04 - Recomendações para construir 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 Microsoft Entra ID e apoiada por grupos de segurança. Essa arquitetura fornece suporte implantando a extensão de autenticação Microsoft Entra ID em todas as VMs. Recomendamos que os usuários humanos usem suas identidades corporativas no locatário do Microsoft Entra ID de sua organização. Além disso, certifique-se de que qualquer acesso baseado na entidade de serviço não seja compartilhado entre funções.

Os recursos de carga de trabalho, como VMs, autenticam-se usando suas 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 Cofre de Chaves são instaladas em VMs, que inicializam as VMs com certificados instalados. Nessa arquitetura, as identidades gerenciadas atribuídas pelo usuário são usadas pelo Application Gateway, VMs front-end e VMs back-end para acessar o Cofre de Chaves . Essas identidades gerenciadas são configuradas durante a implantação e usadas para autenticação no Cofre de Chaves. As políticas de acesso no Cofre de Chaves 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 a ID do Microsoft Entra para fins de autorização ao acessar outros recursos do Azure.

Consulte o 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 Application Gateway.

  Mais segurança é fornecida por meio do Web Application Firewall integrado ao Application Gateway. Ele tem regras que inspecionam o tráfego de entrada e podem tomar as medidas apropriadas. O WAF rastreia vulnerabilidades do Open Web Application Security Project (OWASP) 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 através de 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 da máquina virtual em uma zona de aterrissagem 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 grupos de segurança de aplicativos (ASG) 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 Bastião do Azure, o que elimina a necessidade de um IP público. Nessa arquitetura, essa comunicação é via SSH e é suportada por VMs Windows e Linux. O Microsoft Entra ID é integrado ao SSH para ambos os 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 uma caixa de salto, implantada em sua própria sub-rede, onde você pode instalar sua escolha de ferramentas de administração e solução de problemas. O operador acessa a caixa de salto por meio do host do Bastião do Azure. Em seguida, eles entram nas VMs atrás do balanceador de carga a partir da caixa de salto.

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

  Para maior segurança, use o Microsoft Entra Privileged Identity Management (PIM). O PIM é um serviço no Microsoft Entra ID que permite gerenciar, controlar e monitorar o acesso a recursos importantes em 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 plataforma como serviço (PaaS). A comunicação entre as VMs e o Cofre de Chaves é feita 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 Bastião do Azure para detectar ameaças. A Proteção contra DDoS também fornece alertas, telemetria e análises 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 o Well-Architected Framework: SE: 06 - Recomendações para rede e conectividade.

Criptografia

• Dados em trânsito. O tráfego de usuários 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. Ambos os certificados são armazenados no Cofre de Chaves:

  • app.contoso.com: Um certificado externo usado por clientes e pelo Application Gateway 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 Cofre de Chaves fornece gerenciamento seguro de segredos, incluindo certificados TLS. Nessa arquitetura, os certificados TLS são armazenados no Cofre de Chaves e recuperados durante o processo de provisionamento pelas identidades gerenciadas do Application Gateway e das VMs. Após a configuração inicial, esses recursos só acessam o Cofre de Chaves quando os certificados são atualizados.

As VMs usam a extensão VM do Cofre de Chaves 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 Cofre de Chaves. 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 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 Custo 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 do componente

Selecione imagens de VM otimizadas para a carga de trabalho em vez de usar imagens de uso geral. Nessa arquitetura, imagens 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, levando a 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. Ele permite o uso de pequenos discos de dados, o que pode resultar em custos mais baixos. A implementação dessa arquitetura usa discos de 4 GB.

O uso de discos Ephemeral OS também pode levar à redução de custos e melhor 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 o Well-Architected Framework: CO: 07 - Recomendações para otimizar os custos dos componentes.

Custo de fluxo

Escolha recursos de computação com base na criticidade do fluxo. Para fluxos projetados para tolerar um comprimento indeterminado, considere o uso de VMs spot com o modo de orquestração flexível de Conjuntos de Dimensionamento de Máquina Virtual. 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, atender aos requisitos de diferentes fluxos.

Consulte o Well-Architected Framework: CO: 09 - Recomendações para otimizar os custos de fluxo.

Custo de dimensionamento

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

• Licenciamento de software. VMs maiores podem lidar com mais carga de trabalho, potencialmente 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 resultar em 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 um número maior de instâncias precisasse ser gerenciado.
• Armazenamento em disco. Se houver aplicativos com monitoração de 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 o 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
• Standard_v2 do Gateway de Aplicativo do Azure
• 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 camada N do Windows usando o SQL Server no Azure