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.

O exemplo de carga de trabalho assumida por essa arquitetura é um aplicativo Web multicamadas 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 Escala de Máquina Virtual do Azure. Essa arquitetura pode ser usada para estes cenários:

• Aplicações privadas. Essas aplicações incluem aplicações internas de linha de negócios ou soluções comerciais prontas para uso.
• Aplicações públicas. Estas aplicações são aplicações viradas 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 conceção	Abordagem de estrutura bem arquitetada
▪ Diagrama de arquitetura ▪ Recursos de carga de trabalho ▪ Recursos de apoio ▪ Fluxos de utilizadores	▪ Opções de design de VM ▪ Discos ▪ Ligação em rede ▪ Monitorização ▪ Gerenciamento de atualizações	▪ Fiabilidade ▪ Segurança ▪ Otimização de Custos

Arquitetura

Transfira um ficheiro do Visio desta 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 Escala 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 Azure Web Application Firewall (WAF) 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 Azure Load Balancer Standard SKU fornece acesso de saída à Internet para as 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 aplicação.

Recursos de suporte à carga de trabalho

• O Azure Bastion 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 do utilizador

Há dois tipos de usuários que interagem com os recursos da 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 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 Application Gateway 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 por 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 reparação, 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. Esta configuração garante uma gestão de acesso segura e eficiente.

1. O operador entra no portal do Azure 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 (SO).

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 suportem processadores Intel.

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

Bootstrapping

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, instalação de certificados, configuração de acesso remoto, instalação de pacotes, ajuste e proteção da configuração do sistema operacional e formatação e montagem de discos de dados. É importante automatizar o processo de inicialização tanto quanto possível, para que o aplicativo possa iniciar na VM sem demora 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 Azure Resource Manager 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 tomar medidas. 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 Personalizada 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 qualquer outra tarefa de configuração ou gerenciamento.
  • A extensão de máquina virtual do Azure Key Vault (Windows, Linux) fornece atualização automática de certificados armazenados em um Cofre de Chaves detetando alterações e instalando os certificados correspondentes.
  • A extensão de Integridade do Aplicativo com Conjuntos de Escala de Máquina Virtual é importante quando os Conjuntos de Escala 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.
  • Microsoft Entra ID e OpenSSH (Windows, Linux) integram-se com a autenticação Microsoft Entra. Agora você pode usar o Microsoft Entra ID como uma plataforma de autenticação principal e uma autoridade de certificação para SSH em uma VM 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 as políticas de Acesso Condicional.

• Configuração baseada em agente. As VMs Linux podem usar uma configuração de estado desejada 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-first para bootstrapping, mas suporta 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 experiência melhor.

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 Well-Architected Framework: RE:02 - Recomendações para projeto de automação.

Conectividade 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 dos 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 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 granulares de dimensionamento.

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 instâncias uniformemente entre domínios de falha para resiliência contra um único problema de hardware ou infraestrutura.

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

Discos

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

O Azure fornece uma variedade de opções em termos de desempenho, versatilidade e custo. Comece com SSD Premium para a maioria das cargas de trabalho de produção. A sua escolha depende do 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 IOPS e limites de 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 o componente do aplicativo de forma otimizada. Evite o provisionamento excessivo porque isso afeta os custos.

• 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 disco e SKU de VM para minimizar o impacto e o retrabalho da disponibilidade.

• Discos efémeros do SO. 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 Ephemeral OS depende do SKU VM escolhido. Verifique se o tamanho do disco da 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 fatore esses padrões na seleção de SKU de VM e disco gerenciado.

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

  Embora o excesso de provisionamento reduza a necessidade de interrupção, ele pode levar à capacidade não utilizada pela qual você está pagando. O ideal é combinar ambos os recursos para obter os melhores resultados.

• Ajuste o cache para a carga de trabalho. Configure 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 alto disco. Esses componentes podem se beneficiar do cache somente leitura. Componentes pesados de gravação que exigem consistência transacional de alto disco geralmente têm o cache desativado.

  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.

Nesta 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) é tolerante a falhas individuais de VM e ambos usam imagens pequenas (cerca de 30 GB). Esses atributos os tornam elegíveis 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 salvo nos recursos de armazenamento remoto 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 P1 SSD Premium, fornecendo uma taxa de transferência provisionada de base 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 da máquina virtual em uma zona de aterrissagem do Azure.

Rede virtual

Uma das suas decisões iniciais de layout de rede está relacionada ao intervalo de endereços de rede. Tenha em mente o crescimento previsto da rede durante a fase de planejamento de capacidade. A rede deve ser grande o suficiente para sustentar o crescimento, o que pode exigir 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 notar que, uma vez que a rede virtual é criada, o intervalo de endereços não pode ser modificado.

Nesta arquitetura, o espaço de endereçamento é 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 na funcionalidade e nos requisitos de segurança, conforme descrito aqui:

• Uma sub-rede para hospedar o gateway de aplicativo, que serve como proxy reverso. O Application Gateway requer uma sub-rede dedicada.
• Uma sub-rede para hospedar o balanceador de carga interno para distribuir 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 pelo Azure Private Link. 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 ser de tamanho correto. Por exemplo, talvez você queira aplicar o limite máximo de VMs suportadas pela 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 considerar são as atualizações do sistema operacional VM, que podem exigir endereços IP temporários. O dimensionamento correto oferece 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. O proxy reverso balanceia a carga de tráfego de entrada para os IPs privados das VMs. O outro endereço é para acesso operacional por meio do Azure Bastion.

Transfira um ficheiro do Visio desta arquitetura.

Tráfego de saída

Essa arquitetura usa o SKU Load Balancer padrão com regras de saída definidas a partir das instâncias da VM. O Load Balancer foi escolhido porque é redundante de zona.

Transfira um ficheiro do Visio desta arquitetura.

Essa configuração permite que você use o(s) IP(s) público(s) do seu 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 do pool de back-end e no número de pode ajudar a evitar o esgotamento do frontendIPConfigurations 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 do 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 de DNS

O DNS do Azure é usado como o serviço fundamental para todos os casos de uso de resolução, por exemplo, resolvendo FQDN (nomes de domínio totalmente qualificados) 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.

Monitorização

Essa arquitetura tem uma pilha de monitoramento que é dissociada do utilitário da carga de trabalho. A tónica é colocada principalmente nas fontes de dados e nos aspetos da recolha.

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 dentro da plataforma Azure.

• O nível do aplicativo fornece informações sobre o desempenho e o comportamento dos aplicativos em execução no seu 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 para a 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 representados para mostrar as opções de extensibilidade, como painéis e alertas.

Transfira um ficheiro do Visio desta arquitetura.

Monitorização ao nível da infraestrutura

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

Recurso do Azure	Métricas e registos	Alertas
Gateway de Aplicação	Descrição das métricas e logs do Application Gateway	Alertas do Application Gateway
Application Insights	API de métricas e registro em log do Application Insights	Alertas do Application Insights
Azure Bastion	Métricas do Azure Bastion
Key Vault	Métricas e descrições de logs do Key Vault	Alertas do Cofre da Chave
Balanceador de Carga Standard	Logs e métricas do balanceador de carga	Alertas do Load Balancer
Endereço IP público	Métricas de endereço IP público e descrição de logs	Alertas de métricas de endereço IP público
Rede Virtual	Referência de logs e métricas 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 de Aplicações Web	Descrição das 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 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 consideravelmente os custos de coleta de métricas e 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 boot-diagnostics 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 visualizados por VM ou agregados em várias VMs.

O Application Gateway e o balanceador de carga interno usam testes de integridade para detetar o status do ponto de extremidade das VMs antes de enviar 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 Private Link.

Discos geridos

As métricas de disco dependem da sua carga de trabalho, exigindo uma combinação de métricas-chave. O monitoramento deve combinar essas perspetivas para isolar problemas de throughput de SO ou aplicativos.

• A perspetiva 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 visualizadas individual 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 perspetiva do SO convidado representa métricas que o operador de carga de trabalho visualizaria, independentemente da tecnologia de disco subjacente. As perceções de VM são recomendadas para métricas-chave em discos conectados, como espaço lógico em disco usado e a perspetiva do kernel do sistema operacional sobre IOPS e taxa de transferência de disco.

Monitoramento no nível do aplicativo

Embora 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 aplicativos) 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 a investigação de integridade do balanceador de carga interno do Azure para verificar se o aplicativo está responsivo.

Gestão de atualizações

As VMs precisam ser atualizadas e corrigidas regularmente para não enfraquecer a postura de segurança da carga de trabalho. Recomendamos avaliações automáticas e periódicas de VM para deteção precoce 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, a atualização de componentes de rede ou a desativação 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 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 de impacto zero e sem reinicialização, consulte Configurações de manutenção. A criação de uma Configuração de Manutenção dá-lhe a opção de ignorar todas as atualizações da 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, 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 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 forma contínua cada vez que uma nova imagem é publicada pelo editor.

Desative as imagens de 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 máquinas Windows e Linux em ambientes Azure, locais e multicloud.

Aplicação de patches no SO convidado

As VMs do Azure fornecem a opção de correção automática de convidado de VM. Quando esse serviço está habilitado, as VMs são avaliadas periodicamente e os patches disponíveis são classificados. Recomenda-se que o Modo de Avaliação esteja ativado 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 ativado, tenha formas manuais de detetar atualizações pendentes.

Apenas 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 escala 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 diferentes zonas de disponibilidade para evitar atualizações simultâneas e manter pelo menos duas instâncias por zona para alta disponibilidade. VMs na mesma região podem receber patches diferentes, que devem ser reconciliados ao longo do tempo.

Esteja ciente da compensação no custo associado ao excesso de provisionamento.

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

Se houver processos personalizados para aplicar patches, use repositórios privados para fontes de patches. Isso lhe dá um 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.

Fiabilidade

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 podem 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 a zonas, o que implica que podem resistir a falhas de zona, como o Cofre de Chaves.
• Recursos regionais ou globais disponíveis em regiões ou globalmente, como o Microsoft Entra ID.

O projeto da carga de trabalho deve incorporar garantias de confiabilidade no código do aplicativo, na infraestrutura e nas operações. As seções a seguir ilustram algumas estratégias para garantir que a carga de trabalho seja resiliente a falhas e seja capaz de 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 secçõ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 da 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ários, cada um com seu próprio conjunto de requisitos de negócios. Nem todos estes fluxos requerem o mais elevado nível de garantias, pelo que a segmentação é recomendada como estratégia de fiabilidade. 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 nível. Esta abordagem também torna o sistema flexível.

Nessa arquitetura, as camadas de aplicativos implementam a segmentação. Conjuntos de escala 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 Well-Architected Framework: RE:02 - Recomendações para identificar e classificar fluxos.

Identificar os potenciais pontos de falha

Toda arquitetura é suscetível a falhas. O exercício de análise do modo de falha permite antecipar falhas e estar preparado com mitigações. Aqui estão alguns pontos de falha potenciais nesta arquitetura:

Componente	Risco	Probabilidade	Efeito/Atenuação/Nota	Indisponibilidade
Microsoft Entra ID	Configuração incorreta	Médio	Os utilizadores de operações não conseguem iniciar sessão. Sem efeito a jusante. O Help desk relata o problema de configuração para a equipe de identidade.	Nenhuma
Gateway de Aplicação	Configuração incorreta	Médio	Erros de configuração devem ser detetados 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 o SKU v2 leva cerca de 6 minutos para provisionar. 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.	Total
Gateway de Aplicação	Ataque 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.	Total
Conjuntos de Dimensionamento de Máquinas Virtuais	Falha do serviço	Baixo	Potencial interrupção da carga de trabalho se houver instâncias de VM não íntegras que acionem o reparo automático. Dependente da Microsoft para corrigir.	Potencial interrupção
Conjuntos de Dimensionamento de Máquinas Virtuais	Interrupção da zona de disponibilidade	Baixo	Nenhum efeito. Os conjuntos de escala são implantados como zona redundante.	Nenhuma

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

Objetivos de fiabilidade

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

Aqui está um exemplo de cálculo onde 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ários do aplicativo

Componente	SLO
Gateway de Aplicação	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 notar que diferentes níveis de serviço podem vir com SLAs diferentes, e estes geralmente incluem garantias apoiadas financeiramente que definem metas de confiabilidade. Finalmente, pode haver componentes da arquitetura que não tenham SLAs definidos. Por exemplo, em termos de rede, NICs e redes virtuais não têm seus próprios SLAs.

Os requisitos de negócio e as suas metas devem ser claramente definidos e tidos em conta 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 da sua assinatura pode ajudá-lo a projetar suas VMs de forma mais eficaz.

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 por um ou mais datacenters com alimentação, refrigeração e rede independentes. Ter instâncias executadas em zonas separadas protege o aplicativo contra falhas no datacenter.

• Os Conjuntos de Escala de Máquina Virtual 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. Espalhar 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 é atualizado de cada 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 anexados 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 como ZRS (armazenamento com redundância de zona) nas VMs back-end. Requer uma estratégia de recuperação para tirar proveito das zonas de disponibilidade. A estratégia de recuperação é reimplantar a solução. Idealmente, pré-provisione a computação em zonas de disponibilidade alternativas prontas para recuperação de uma falha zonal.

• Um Application Gateway com redundância de zona ou um balanceador de carga padrão pode rotear o tráfego para VMs entre zonas usando um único endereço IP, garantindo continuidade mesmo se ocorrerem falhas de zona. Esses serviços usam testes de integridade para verificar a disponibilidade da VM. Enquanto uma zona na região permanecer operacional, o roteamento continua apesar de possíveis falhas em outras zonas. No entanto, o roteamento entre zonas pode ter latência maior 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 a zonas para uma melhor fiabilidade, como o Cofre da Chave.

• 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, Microsoft Entra ID.

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

Estratégia de dimensionamento

Para evitar a degradação do nível de serviço e falhas, 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 diferentes perfis 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 convidada) que exigem a instalação do Agente de Monitor do Azure para coletá-las. Cada perfil contém regras para expansão (aumento) e expansão (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 escala opostos. O Azure Monitor tentará atenuar essa situação aguardando o período de resfriamento antes de ser dimensionado novamente.

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

Considere outros aspetos, 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 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 aos 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, consulte Práticas recomendadas de dimensionamento automático.

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

Autorrecuperação e recuperabilidade

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 dar suporte à deteçã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 secções são anotadas com recomendações dessa lista de verificação.

A segurança não se refere apenas aos controlos técnicos. Recomendamos que siga toda a lista de verificação para compreender os aspetos 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. Colocalize 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 realizar 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 Well-Architected Framework: SE:04 - Recomendações para a construção de uma estratégia de segmentação.

Gestão de identidades e acessos

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

O acesso a 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 do 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 em entidade de serviço não seja compartilhado entre funções.

Recursos de carga de trabalho, como VMs, autenticam-se usando suas identidades gerenciadas atribuídas a outros recursos. Essas identidades, baseadas em entidades de serviço do Microsoft Entra ID, são gerenciadas automaticamente.

Por exemplo, as extensões do Cofre da Chave 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 da Chave. Essas identidades gerenciadas são configuradas durante a implantação e usadas para autenticação no Cofre da Chave. As políticas de acesso no Cofre da Chave 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.

Controlos 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 através do Web Application Firewall que é integrado com o Application Gateway. Tem regras que inspecionam o tráfego de entrada e podem tomar as medidas adequadas. O WAF rastreia vulnerabilidades do Open Web Application Security Project (OWASP), prevenindo ataques conhecidos.

• Trânsito de saída. Não há controles sobre o tráfego de saída, exceto as regras NSG de saída nas sub-redes VM. Recomendamos que todo o tráfego de saída da Internet flua através de um único firewall. Este 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 Este-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 Azure Bastion, o que elimina a necessidade de um IP público. Nessa arquitetura, essa comunicação é por SSH e é suportada por VMs Windows e Linux. O Microsoft Entra ID é integrado com SSH para ambos os tipos de VMs usando a extensão VM correspondente. Essa integração permite que a identidade de um operador seja autenticada e autorizada através 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 suas ferramentas de administração e solução de problemas de sua escolha. O operador acessa a caixa de salto por meio do host do Azure Bastion. 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 reduzir os riscos de permissões de acesso excessivas, desnecessárias ou mal utilizadas em recursos que lhe interessam.

• Conectividade privada com serviços de plataforma como serviço (PaaS). A comunicação entre as VMs e o Cofre da Chave é feita por Link Privado. Este 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 Application Gateway e pelo Azure Bastion Host para detetar ameaças. A Proteção contra DDoS também fornece alertas, telemetria e análises através do Monitor. Para obter mais informações, consulte 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.

Encriptação

• Dados em trânsito. O tráfego de usuários entre usuários e o IP público do Application Gateway é 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 da Chave:

  • app.contoso.com: Um certificado externo usado por clientes e Application Gateway para tráfego público seguro da Internet.
  • *.workload.contoso.com: Um certificado curinga usado pelos componentes de infraestrutura para proteger o tráfego interno.

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

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

Gestão de segredos

Transfira um ficheiro do Visio desta arquitetura.

O Key Vault fornece gerenciamento seguro de segredos, incluindo certificados TLS. Nessa arquitetura, os certificados TLS são armazenados no Cofre da Chave 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 da Chave quando os certificados são atualizados.

As VMs usam a extensão de VM do Cofre da Chave para atualizar automaticamente os certificados monitorados. Se forem detetadas alterações no armazenamento de certificados local, a extensão recuperará e instalará os certificados correspondentes do Cofre de Chaves. A extensão suporta os 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 cumpridos 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 projeto 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 do componente

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 são de 30 GB cada. Com imagens menores, as SKUs de VM com discos também são menores, levando a custos mais baixos, consumo de recursos reduzidos e tempos de implantação e inicialização mais rápidos. Uma vantagem é a segurança reforçada devido à área de superfície reduzida.

Implementar a rotação de logs com limites de tamanho é outra estratégia de economia de custos. Permite a utilização de pequenos discos de dados, o que pode resultar em custos mais baixos. A implementação desta arquitetura utiliza discos de 4 GB.

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

Custo do 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 escala de máquina virtual. Essa abordagem pode ser eficaz para hospedar fluxos de baixa prioridade em VMs de prioridade mais baixa. Esta estratégia permite a otimização de custos e, ao mesmo tempo, atender aos requisitos de diferentes fluxos.

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

Custo de dimensionamento

Se o principal fator de custo for o número de instâncias, pode ser mais econômico aumentar a escala aumentando o tamanho ou o desempenho das VMs. Esta abordagem pode levar a economias de custos em várias áreas:

• Licenciamento de software. VMs maiores podem lidar com mais carga de trabalho, reduzindo potencialmente o número de licenças de software necessárias.
• Tempo de manutenção: Menos VMs 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 escala.

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. Esta ação não só 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.

Implementar este cenário

Está disponível uma implementação para esta arquitetura de referência 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áquinas Virtuais do Azure
• Rede Virtual do Azure
• Azure Application Gateway Standard_v2
• Balanceador de Carga do Azure
• Azure Key Vault
• Azure Bastion
• Application Insights
• Log Analytics

Próximo passo

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

• Aplicativo de camada N do Windows usando o SQL Server no Azure