Arquitectura de línea de base de Azure Virtual Machines

En este artículo se proporciona una arquitectura de referencia fundamental para una carga de trabajo implementada en Azure Virtual Machines.

La carga de trabajo de ejemplo que asume esta arquitectura es una aplicación web de varios niveles accesible desde Internet que se implementa en conjuntos independientes de máquinas virtuales (VM). Las máquinas virtuales se aprovisionan como parte de las implementaciones de Azure Virtual Machine Scale Sets. Esta arquitectura se puede usar para estos escenarios:

• Aplicaciones privadas. Estas aplicaciones incluyen aplicaciones internas de línea de negocio o soluciones comerciales fuera de la plataforma.
• Aplicaciones públicas. Estas aplicaciones son aplicaciones accesibles desde Internet. Esta arquitectura no es para el proceso de alto rendimiento, cargas de trabajo críticas, aplicaciones muy afectadas por la latencia u otros casos de uso especializados.

El enfoque principal de esta arquitectura no es la aplicación. En su lugar, en este artículo se proporcionan instrucciones para configurar e implementar los componentes de infraestructura con los que interactúa la aplicación. Estos componentes incluyen componentes de proceso, almacenamiento, redes y supervisión.

Esta arquitectura actúa como punto de partida para una carga de trabajo hospedada en infraestructura como servicio (IaaS). El nivel de datos se excluye intencionadamente de esta guía para mantener el enfoque en la infraestructura de proceso.

Diseño del artículo

Arquitectura	Decisión de diseño	Enfoque de marco de buena arquitectura
▪ Diagrama de la arquitectura ▪ Recursos de carga de trabajo ▪ Recursos auxiliares ▪ Flujos de usuario	▪ Opciones de diseño de máquina virtual ▪ Discos ▪ Redes ▪ Supervisión ▪ Administración de actualizaciones	▪ Confiabilidad ▪ Seguridad ▪ Optimización de costos

Arquitectura

Descargue un archivo Visio de esta arquitectura.

Para obtener información sobre estos recursos, consulte la documentación del producto de Azure que se muestra en Recursos relacionados.

Componentes

Esta arquitectura consta de varios servicios de Azure para los recursos de carga de trabajo y los recursos auxiliares de carga de trabajo. Los servicios de cada uno y sus roles se describen en las secciones siguientes.

Recursos de carga de trabajo

• Azure Virtual Machines actúa como recurso de proceso para la aplicación y se distribuye entre zonas de disponibilidad. Con fines ilustrativos, se usa una combinación de máquinas virtuales Windows y Linux.

  Azure Virtual Machine Scale Sets en modo de orquestación flexible se usa para aprovisionar y administrar las máquinas virtuales.

  La aplicación de ejemplo se puede representar en dos niveles, cada una que requiere su propio proceso.

  • El front-end ejecuta el servidor web y recibe solicitudes de usuario.
  • El back-end ejecuta otro servidor web que actúa como una API web que expone un único punto de conexión donde se ejecuta la lógica de negocios.

  Las máquinas virtuales de front-end tienen discos de datos (Premium_LRS) conectados, que se podrían usar para implementar una aplicación sin estado. Las máquinas virtuales de back-end conservan los datos en discos locales de Premium_ZRS como parte de su operación. Este diseño se puede extender para incluir un nivel de base de datos para almacenar el estado del proceso front-end y back-end. Ese nivel está fuera del ámbito de esta arquitectura.

• Azure Virtual Network proporciona una red privada para todos los recursos de carga de trabajo. La red se segmenta en subredes, que sirven como límites de aislamiento.

• Azure Application Gateway es el único punto de entrada que enruta las solicitudes a los servidores front-end. La SKU seleccionada incluye Azure Web Application Firewall (WAF) integrado para mayor seguridad.

• Azure Load Balancer interno enruta el tráfico desde el nivel front-end a los servidores back-end.

• La SKU estándar de Azure Load Balancer proporciona acceso saliente a Internet a las máquinas virtuales mediante tres direcciones IP públicas.

• Azure Key Vault almacena los certificados usados para la comunicación de la seguridad de la capa de transporte (TLS) de un extremo a otro. También se puede usar para secretos de aplicación.

Recursos auxiliares de carga de trabajo

• Azure Bastion proporciona acceso operativo a las máquinas virtuales a través de protocolos seguros.

• Application Insights recopila registros y métricas de la aplicación. Dado que la aplicación no es el foco de esta arquitectura, la recopilación de registros no se muestra en la implementación.

• Log Analytics es el receptor de datos de supervisión que recopila registros y métricas de los recursos de Azure y Application Insights. Una cuenta de almacenamiento se aprovisiona como parte del área de trabajo.

Flujos de usuario

Hay dos tipos de usuarios que interactúan con los recursos de carga de trabajo: el usuario y el operador de carga de trabajo. Los flujos de estos usuarios se muestran en el diagrama de arquitectura anterior.

Usuario de carga de trabajo

1. El usuario accede al sitio web mediante la dirección IP pública expuesta de Application Gateway.

2. Application Gateway recibe tráfico HTTPS, descifra datos mediante un certificado externo para la inspección de WAF y lo vuelve a cifrar mediante el certificado comodín interno para el transporte al front-end.

3. Application Gateway equilibra el tráfico entre las máquinas virtuales de front-end y reenvía la solicitud a una máquina virtual de front-end.

4. La máquina virtual de front-end seleccionada se comunica con una máquina virtual de back-end mediante la dirección IP privada del equilibrador de carga, no la dirección IP de ninguna máquina virtual individual. Esta comunicación también se cifra mediante el certificado comodín interno.

5. La máquina virtual de back-end descifra la solicitud mediante el certificado interno. Una vez que el back-end procesa la solicitud, devuelve el resultado al front-end, que devuelve el resultado a la puerta de enlace de aplicaciones y, por último, devuelve el resultado al usuario.

Operador

Las máquinas virtuales de esta arquitectura pueden requerir acceso directo por parte de los operadores, pero se recomienda que el acceso remoto se minimice a través de la automatización y que se supervise el acceso. El acceso puede ser para situaciones de corrección de interrupción, solución de problemas o parte de un proceso de implementación automatizada. Esta arquitectura no tiene direcciones IP públicas para el acceso al plano de control. Azure Bastion actúa como puerta de enlace sin servidor, lo que permite que las operaciones accedan a las máquinas virtuales a través de SSH o RDP. Esta configuración garantiza una administración de acceso segura y eficaz.

1. El operador inicia sesión en Azure Portal o en la CLI de Azure.
2. El operador accede al servicio Azure Bastion y se conecta de forma remota a la máquina virtual deseada.

Opciones de diseño de máquina virtual

Al seleccionar SKU, es importante tener una expectativa de rendimiento de línea de base. Varias características influyen en el proceso de toma de decisiones, entre las que se incluyen:

• Operaciones de entrada/salida de CPU, memoria y disco por segundo (IOPS).
• Arquitectura de procesadores.
• Tamaño de imagen del sistema operativo.

Por ejemplo, si va a migrar una carga de trabajo desde un entorno local que requiere máquinas de procesador Intel, elija SKU de máquina virtual que admitan procesadores Intel.

Para obtener información sobre las SKU de máquina virtual admitidas, consulte Tamaños de máquinas virtuales en Azure.

Arranque

Las máquinas virtuales a menudo deben arrancarse, que es un proceso en el que las máquinas virtuales están preparadas y optimizadas para ejecutar la aplicación. Entre las tareas comunes de arranque se incluyen, la instalación de certificados, la configuración del acceso remoto, la instalación de paquetes, la optimización y la protección de la configuración del sistema operativo, así como el formato y el montaje de discos de datos. Es importante automatizar el proceso de arranque tanto como sea posible, de modo que la aplicación pueda iniciarse en la máquina virtual sin demora ni intervención manual. Estas son las recomendaciones para la automatización:

• Extensiones de máquina virtual. Estas extensiones son objetos de Azure Resource Manager que se administran a través de la implementación de infraestructura como código (IaC). De este modo, cualquier error se notifica como una implementación con errores en la que puede realizar acciones. Si no hay una extensión para las necesidades de arranque, cree scripts personalizados. Se recomienda ejecutar los scripts a través de la extensión de script personalizado de Azure.

  Estas son algunas otras extensiones que se pueden usar para instalar o configurar automáticamente la funcionalidad en las máquinas virtuales.

  • El agente de Azure Monitor (AMA) recopila datos de supervisión del sistema operativo invitado y los entrega a Azure Monitor.
  • La versión 2 de Extensión de script personalizado de Azure (Windows, Linux) descarga y ejecuta scripts en máquinas virtuales (VM) de Azure. Esta extensión es útil para automatizar la configuración posterior a la implementación, la instalación de software o cualquier otra tarea de configuración o administración.
  • La extensión de máquina virtual de Azure Key Vault (Windows, Linux) proporciona una actualización automática de los certificados almacenados en un almacén de claves mediante la detección de cambios e instalación de los certificados correspondientes.
  • La extensión de estado de la aplicación con virtual Machine Scale Sets es importante cuando Azure Virtual Machine Scale Sets realiza actualizaciones graduales automáticas. Azure se basa en la supervisión del estado de las instancias individuales para realizar las actualizaciones. También puede usar la extensión para supervisar el estado de la aplicación de cada instancia de su conjunto de escalado y realizar reparaciones de instancias mediante reparaciones de instancias automáticas.
  • Microsoft Entra ID y OpenSSH (Windows, Linux) se integran con la autenticación de Microsoft Entra. Ahora puede usar Microsoft Entra ID como plataforma de autenticación principal y una autoridad de certificación para conectarse mediante SSH en una VM Linux mediante Microsoft Entra ID y la autenticación basada en certificados de OpenSSH. Esta funcionalidad le permite administrar el acceso a las máquinas virtuales con el control de acceso basado en roles (RBAC) de Azure y las directivas de acceso condicional.

• Configuración basada en agente. Las máquinas virtuales Linux pueden usar una configuración de estado deseado nativa ligera disponible a través de cloud-init en varias imágenes de máquina virtual proporcionadas por Azure. La configuración se especifica y se versiona con los artefactos de IaC. Una solución de administración de configuración propia es otra opción. La mayoría de las soluciones siguen un enfoque declarativo primero para arrancar, pero admiten scripts personalizados para obtener flexibilidad. Entre las opciones más populares se incluyen Desired State Configuration para Windows, Desired State Configuration para Linux, Ansible, Chef, Puppet y otros. Todas estas soluciones de configuración se pueden emparejar con extensiones de máquina virtual para una mejor experiencia de ambos.

En la implementación de referencia, todo el arranque se realiza a través de extensiones de máquina virtual y scripts personalizados, incluido un script personalizado para automatizar el formato y el montaje del disco de datos.

Consulte Marco de buena arquitectura: RE:02 - Recomendaciones para el diseño de automatización.

Conectividad de máquina virtual

Para habilitar la comunicación privada entre una máquina virtual y otros dispositivos de una red virtual determinada, la tarjeta de interfaz de red (NIC) de la máquina virtual está conectada a una de las subredes de la red virtual. Si necesita varios adaptadores de red para la máquina virtual, tenga en cuenta que hay un número máximo definido para cada tamaño de máquina virtual.

Si la carga de trabajo necesita una comunicación de baja latencia entre las máquinas virtuales de la red virtual, considere la posibilidad de redes aceleradas, que son compatibles con las NIC de máquina virtual de Azure. Para obtener más información, consulte Ventajas de las redes aceleradas.

Virtual Machine Scale Sets con orquestación flexible

Las máquinas virtuales se aprovisionan como parte de Virtual Machine Scale Sets con orquestación flexible. Virtual Machine Scale Sets son son agrupaciones lógicas de máquinas virtuales que se usan para satisfacer las necesidades empresariales. Los tipos de máquinas virtuales de una agrupación pueden ser idénticos o diferentes. Permiten administrar el ciclo de vida de las máquinas, las interfaces de red y los discos mediante las API y comandos estándar de máquina virtual de Azure.

El modo de orquestación flexible facilita las operaciones a escala y ayuda con decisiones de escalado granular.

La configuración del dominio de error es necesaria para limitar el efecto de errores de hardware físico, interrupciones de red o interrupciones de alimentación. Con los conjuntos de escalado, Azure distribuye las instancias uniformemente entre dominios de error para lograr resistencia frente a un único problema de hardware o infraestructura.

Se recomienda descargar la asignación de dominios de error a Azure para la propagación máxima de instancias, lo que mejora la resistencia y la disponibilidad.

Discos

Para ejecutar los componentes del sistema operativo y de la aplicación, los discos de almacenamiento se conectan a la máquina virtual. Considere la posibilidad de usar discos efímeros para el sistema operativo y los discos administrados para el almacenamiento de datos.

Azure proporciona una variedad de opciones en términos de rendimiento, versatilidad y costo. Comience con SSD Premium para la mayoría de las cargas de trabajo de producción. La elección depende de la SKU de máquina virtual. Las SKU que admiten SSD Premium contienen una s en el nombre del recurso, por ejemplo, Dsv4 , pero no Dv4.

Para obtener más información sobre las opciones de disco con métricas como capacidad, IOPS y rendimiento, consulte Comparación de tipos de disco.

Tenga en cuenta las características de disco y las expectativas de rendimiento al seleccionar un disco.

• Limitaciones de SKU de la máquina virtual. Los discos funcionan dentro de la máquina virtual a la que están conectados, que tienen límites de IOPS y rendimiento. Asegúrese de que el disco no limita los límites de la máquina virtual y viceversa. Seleccione el tamaño del disco, el rendimiento y las funcionalidades de máquina virtual (núcleo, CPU, memoria) que ejecutan el componente de aplicación de forma óptima. Evite el sobreaprovisionamiento porque afecta al costo.

• Cambios de configuración. Puede cambiar algunas configuraciones de rendimiento y capacidad de disco mientras se ejecuta una máquina virtual. Sin embargo, muchos cambios pueden requerir volver a aprovisionar y volver a generar contenido de disco, lo que afecta a la disponibilidad de la carga de trabajo. Por lo tanto, planee cuidadosamente la selección de discos y SKU de máquina virtual para minimizar el impacto en la disponibilidad y el reproceso.

• Discos de sistema operativo efímeros Aprovisione discos del sistema operativo como discos efímeros. Use discos administrados solo si es necesario conservar los archivos del sistema operativo. Evite usar discos efímeros para almacenar los componentes y el estado de la aplicación.

  La capacidad de los discos del sistema operativo efímeros depende de la SKU de máquina virtual elegida. Asegúrese de que el tamaño del disco de imagen del sistema operativo sea menor que la memoria caché disponible de la SKU o el disco temporal. Puede usar el espacio restante para el almacenamiento temporal.

• Rendimiento de disco. El aprovisionamiento previo del espacio en disco basado en la carga máxima es común, pero puede provocar recursos infrautilizados porque la mayoría de las cargas de trabajo no admiten la carga máxima.

  Supervise los patrones de uso de la carga de trabajo, tenga en cuenta los picos o las operaciones sostenidas de lectura elevada y tenga en cuenta estos patrones en la máquina virtual y la selección de SKU del disco administrado.

  Puede ajustar el rendimiento a petición cambiando los niveles de rendimiento o utilizando las características de expansión que se ofrecen en algunas SKU de disco administrado.

  Aunque el sobreaprovisionamiento reduce la necesidad de expansión, puede dar lugar a una capacidad sin usar que paga. Lo ideal es que combine ambas características para obtener resultados óptimos.

• Ajuste del almacenamiento en caché de la carga de trabajo. Configure las opciones de caché para todos los discos en función del uso de componentes de la aplicación.

  Los componentes que realizan principalmente operaciones de lectura no requieren coherencia transaccional de disco elevado. Esos componentes pueden beneficiarse del almacenamiento en caché de solo lectura. Los componentes con mucha actividad de escritura que requieren coherencia transaccional de disco elevado suelen tener deshabilitado el almacenamiento en caché.

  El uso del almacenamiento en caché de lectura y escritura podría provocar la pérdida de datos si la máquina virtual se bloquea y no se recomienda para la mayoría de los escenarios de disco de datos.

En esta arquitectura:

• Los discos del sistema operativo de todas las máquinas virtuales son efímeros y se encuentran en el disco de caché.

  La aplicación de carga de trabajo en el front-end (Linux) y el back-end (Windows Server) son tolerantes a errores de máquina virtual individuales y usan imágenes pequeñas (alrededor de 30 GB). Estos atributos los convierten en aptos para usar discos de sistema operativo efímeros creados como parte del almacenamiento local de la máquina virtual (partición de caché) en lugar del disco del sistema operativo persistente que se guarda en recursos remotos de Azure Storage. Esta situación no supone ningún costo de almacenamiento para los discos del sistema operativo y también mejora el rendimiento al proporcionar latencias más bajas y reducir el tiempo de implementación de la máquina virtual.

• Cada máquina virtual tiene su propio disco administrado SSD P1 Premium, lo que proporciona un rendimiento aprovisionado base adecuado para la carga de trabajo.

Diseño de red

Esta arquitectura implementa la carga de trabajo en una sola red virtual. Los controles de red son una parte importante de esta arquitectura y se describen en la sección Seguridad.

Este diseño se puede integrar con una topología empresarial. Ese ejemplo se muestra en la Arquitectura de línea de base de máquina virtual en una zona de aterrizaje de Azure.

Red virtual

Una de las decisiones de diseño de red iniciales se relaciona con el intervalo de direcciones de red. Tenga en cuenta el crecimiento previsto de la red durante la fase de planeamiento de la capacidad. La red debe ser lo suficientemente grande como para mantener el crecimiento, lo que podría necesitar construcciones de red adicionales. Por ejemplo, la red virtual debe tener la capacidad de dar cabida a las otras máquinas virtuales resultantes de una operación de escalado.

Elija también el tamaño correcto del espacio de direcciones. Una red virtual excesivamente grande puede provocar una infrautilización. Es importante tener en cuenta que una vez creada la red virtual, no se puede modificar el intervalo de direcciones.

En esta arquitectura, el espacio de direcciones se establece en /21, una decisión basada en el crecimiento proyectado.

Consideraciones de subredes

Dentro de la red virtual, las subredes se dividen en función de los requisitos de funcionalidad y seguridad, como se describe aquí:

• Una subred para hospedar la puerta de enlace de aplicaciones, que actúa como proxy inverso. Application Gateway requiere una subred dedicada.
• Una subred para hospedar el equilibrador de carga interno para distribuir el tráfico a máquinas virtuales de back-end.
• Subredes para hospedar las máquinas virtuales de carga de trabajo, una para front-end y otra para back-end. Estas subredes se crean según los niveles de la aplicación.
• Una subred del host de Azure Bastion para facilitar el acceso operativo a las máquinas virtuales de carga de trabajo. Por diseño, el host de Azure Bastion necesita una subred dedicada.
• Una subred para hospedar puntos de conexión privados creados para acceder a otros recursos de Azure a través de Azure Private Link. Aunque las subredes dedicadas no son obligatorias para estos puntos de conexión, se recomiendan.

De forma similar a las redes virtuales, las subredes deben tener un tamaño correcto. Por ejemplo, es posible que quiera aplicar el límite máximo de máquinas virtuales admitidas por la orquestación flexible para satisfacer las necesidades de escalado de la aplicación. Las subredes de carga de trabajo deben ser capaces de adaptar ese límite.

Otro caso de uso que se debe tener en cuenta son las actualizaciones del sistema operativo de máquina virtual, lo que podría requerir direcciones IP temporales. El ajuste de tamaño correcto proporciona el nivel deseado de segmentación asegurándose de que se agrupan recursos similares para que se puedan aplicar reglas de seguridad significativas a través de grupos de seguridad de red (NSG) a los límites de subred. Para obtener más información, consulte Seguridad: Segmentación.

Tráfico de entrada

Se usan dos direcciones IP públicas para los flujos de entrada. Una dirección es para Application Gateway que actúa como proxy inverso. Los usuarios se conectan con esa dirección IP pública. El proxy inverso equilibra la carga del tráfico de entrada a las direcciones IP privadas de las máquinas virtuales. La otra dirección es para el acceso operativo a través de Azure Bastion.

Descargue un archivo Visio de esta arquitectura.

Tráfico de salida

Esta arquitectura usa Load Balancer de SKU estándar con reglas de salida definidas desde las instancias de máquina virtual. Se eligió Load Balancer porque es redundante de zona.

Descargue un archivo Visio de esta arquitectura.

Esta configuración permite usar las direcciones IP públicas del equilibrador de carga para proporcionar conectividad de Internet de salida para las máquinas virtuales. Las reglas de salida permiten definir explícitamente los puertos de traducción de direcciones de red de origen (SNAT). Las reglas permiten escalar y ajustar esta capacidad a través de la asignación manual de puertos. La asignación manual de los puertos SNAT en función del tamaño del grupo de back-end y el número de frontendIPConfigurations puede ayudar a evitar el agotamiento de SNAT.

Se recomienda asignar puertos en función del número máximo de instancias de back-end. Si se agregan más instancias que los puertos SNAT restantes permitidos, es posible que se bloqueen las operaciones de escalado de Virtual Machine Scale Sets o que las nuevas máquinas virtuales no reciban suficientes puertos SNAT.

Calcula los puertos por instancia de la siguiente manera: Number of front-end IPs * 64K / Maximum number of back-end instances

Hay otras opciones que puede usar, como la implementación de un recurso de Azure NAT Gateway asociado a la subred. Otra opción es usar Azure Firewall u otra aplicación virtual de red con una ruta personalizada definida por el usuario (UDR) como próximo salto a través del firewall. Esta opción se muestra en la Arquitectura de línea de base de máquina virtual en una zona de aterrizaje de Azure.

Resolución DNS

Azure DNS se usa como servicio fundamental para todos los casos de uso de resolución, por ejemplo, la resolución de nombres de dominio completos (FQDN) asociados a las máquinas virtuales de carga de trabajo. En esta arquitectura, las máquinas virtuales usan los valores DNS establecidos en la configuración de red virtual, que es Azure DNS.

Las zonas de DNS privado de Azure se usan para resolver solicitudes a los puntos de conexión privados que se usan para acceder a los recursos de Private Link con nombre.

Supervisión

Esta arquitectura tiene una pila de supervisión que se desacopla de la utilidad de la carga de trabajo. El enfoque se centra principalmente en los orígenes de datos y los aspectos de la recopilación.

Las métricas y los registros se generan en varios orígenes de datos, lo que proporciona información de observabilidad a varias altitudes:

• La infraestructura y los componentes subyacentes se consideran, como máquinas virtuales, redes virtuales y servicios de almacenamiento. Los registros de la plataforma Azure proporcionan información sobre las operaciones y actividades dentro de la plataforma Azure.

• El nivel de aplicación proporciona información sobre el rendimiento y el comportamiento de las aplicaciones que se ejecutan en el sistema.

El área de trabajo de Log Analytics es el receptor de datos de supervisión recomendado que se usa para recopilar registros y métricas de los recursos de Azure y Application Insights.

En esta imagen se muestra la pila de supervisión de la línea de base con componentes para recopilar datos de la infraestructura y la aplicación, los receptores de datos y varias herramientas de consumo para el análisis y la visualización. La implementación implementa algunos componentes, como Application Insights, diagnósticos de arranque de máquina virtual y Log Analytics. Se muestran otros componentes para mostrar las opciones de extensibilidad, como paneles y alertas.

Descargue un archivo Visio de esta arquitectura.

Supervisión en el nivel de infraestructura

Esta tabla se vincula a registros y métricas recopilados por Azure Monitor. Las alertas disponibles le ayudan a solucionar de forma proactiva los problemas antes de que afecten a los usuarios.

Recurso de Azure	Métricas y registros	Alertas
Application Gateway	Descripción de las métricas y los registros de Application Gateway	Alertas de Application Gateway
Application Insights	API de registro y métricas de Application Insights	alertas de Application Insights
Azure Bastion	Métricas de Azure Bastion
Key Vault	Descripciones de métricas y registros de Key Vault	Alertas de Key Vault
Standard Load Balancer	Registros y métricas de Load Balancer	Alertas de Load Balancer
Dirección IP pública	Descripción de las métricas y los registros de direcciones IP públicas	Alertas de métricas de direcciones IP públicas
Virtual Network	Referencia de registros y métricas de red virtual	Alertas de red virtual
Virtual Machines y Virtual Machine Scale Sets	Referencia de métricas y registros de máquinas virtuales	Alertas y tutoriales de máquinas virtuales
Firewall de aplicaciones web	Descripción de las métricas y los registros de Web Application Firewall	Alertas de Web Application Firewall

Para obtener más información sobre el costo de la recopilación de métricas y registros, consulte Cálculos y opciones de costos de Log Analytics y Precios del área de trabajo de Log Analytics. La naturaleza de la carga de trabajo y la frecuencia y el número de métricas y registros recopilados afectan considerablemente a los costos de recopilación de métricas y registros.

Máquinas virtuales

Los diagnósticos de arranque de Azure están habilitados para observar el estado de las máquinas virtuales durante el arranque mediante la recopilación de información de registro serie y capturas de pantallas. En esta arquitectura, se puede acceder a los datos a través de Azure Portal y el comando boot-diagnostics get-boot-log de máquina virtual de la CLI de Azure. Azure administra los datos y no tiene control ni acceso al recurso de almacenamiento subyacente. Sin embargo, si los requisitos empresariales exigen más control, puede aprovisionar su propia cuenta de almacenamiento para almacenar los diagnósticos de arranque.

VM Insights ofrece una manera eficaz de supervisar máquinas virtuales y conjuntos de escalado. Recopila datos de áreas de trabajo de Log Analytics y proporciona libros predefinidos para tendencias de datos de rendimiento. Estos datos se pueden ver por máquina virtual o agregados en varias máquinas virtuales.

Application Gateway y el equilibrador de carga interno usan sondeos de estado para detectar el estado del punto de conexión de las máquinas virtuales antes de enviar tráfico.

Redes

En esta arquitectura, los datos de registro se recopilan de varios componentes de red que participan en el flujo. Estos componentes incluyen Application Gateway, equilibradores de carga y Azure Bastion. También incluyen componentes de seguridad de red, como redes virtuales, grupos de seguridad de red, direcciones IP públicas y Private Link.

Discos administrados

Las métricas de disco dependen de la carga de trabajo, lo que requiere una combinación de métricas clave. La supervisión debe combinar estas perspectivas para aislar los problemas de rendimiento del sistema operativo o de la aplicación.

• La perspectiva de la plataforma Azure representa las métricas que indican el servicio de Azure, independientemente de la carga de trabajo conectada a ella. Las métricas de rendimiento de disco (IOPS y rendimiento) se pueden ver individual o colectivamente para todos los discos conectados a máquinas virtuales. Use las métricas de uso de E/S de almacenamiento para solucionar problemas o avisar sobre el posible límite de disco. Si usa la expansión para la optimización de costos, supervise las métricas de porcentaje de créditos para identificar oportunidades de optimización adicional.

• La perspectiva del sistema operativo invitado representa las métricas que el operador de carga de trabajo vería, independientemente de la tecnología de disco subyacente. Se recomienda VM Insights para métricas clave en discos conectados, como el espacio en disco lógico usado y la perspectiva del kernel del sistema operativo en IOPS de disco y rendimiento.

Supervisión en el nivel de aplicación

Aunque la implementación de referencia no hace uso de ella, Application Insights se aprovisiona como Application Performance Management (APM) con fines de extensibilidad. Application Insights recopila datos de una aplicación y los envía al área de trabajo de Log Analytics. También puede visualizar esos datos de las aplicaciones de carga de trabajo.

La extensión de estado de la aplicación se implementa en máquinas virtuales para supervisar el estado de mantenimiento binario de cada instancia de máquina virtual del conjunto de escalado y realizar reparaciones de instancia si es necesario mediante la reparación automática de instancias del conjunto de escalado. Comprueba el mismo archivo que Application Gateway y el sondeo de estado interno de Azure Load Balancer para comprobar si la aplicación responde.

Administración de actualizaciones

Las máquinas virtuales deben actualizarse y se les deben aplicar revisiones periódicamente para que no debiliten la posición de seguridad de la carga de trabajo. Se recomiendan evaluaciones automáticas y periódicas de máquinas virtuales para la detección temprana y la aplicación de revisiones.

Actualizaciones de infraestructura

Azure actualiza periódicamente su plataforma para mejorar la confiabilidad, el rendimiento y la seguridad de la infraestructura de host para las máquinas virtuales. Estas actualizaciones incluyen la aplicación de revisiones a componentes de software en el entorno de hospedaje, la actualización de los componentes de red o la retirada de hardware. Para más información sobre el proceso de actualización, consulte Mantenimiento de máquinas virtuales en Azure.

Si una actualización no requiere un reinicio, la máquina virtual se pone en pausa mientras se actualiza el host, o bien se migra directamente a un host ya actualizado. Si el mantenimiento requiere un reinicio, se notifica al usuario el mantenimiento planeado. Azure también proporciona una ventana de tiempo en la que puede iniciar el mantenimiento, según su conveniencia. Para obtener información sobre la ventana de mantenimiento automático y sobre cómo configurar las opciones disponibles, consulte Control de las notificaciones de mantenimiento planeado.

Es posible que algunas cargas de trabajo no toleren ni siquiera unos segundos de congelación o desconexión de una máquina virtual para su mantenimiento. Para un mayor control sobre todas las actividades de mantenimiento, incluidas las actualizaciones sin impacto y sin reinicio, consulte Configuraciones de mantenimiento. La creación de una configuración de mantenimiento ofrece la opción de omitir todas las actualizaciones de la plataforma y aplicarlas a la hora que le convenga. Cuando se establece esta configuración personalizada, Azure omite todas las actualizaciones sin impacto, incluidas las actualizaciones sin reinicio. Para obtener más información, consulte Administración de las actualizaciones de la plataforma con configuraciones de mantenimiento.

Actualizaciones de imágenes del sistema operativo (SO)

Al realizar actualizaciones del sistema operativo, tiene una imagen maestra que se prueba. Considere la posibilidad de usar Azure Shared Image Gallery y Azure Compute Gallery para publicar imágenes personalizadas. Debe contar con un proceso que actualice los lotes de instancias de forma gradual cada vez que el editor publique una nueva imagen.

Retire las imágenes de máquina virtual antes de llegar a su fin de ciclo de vida para reducir el área expuesta.

El proceso de automatización debe tener en cuenta el sobreaprovisionamiento con capacidad adicional.

Puede usar Azure Update Management para administrar las actualizaciones del sistema operativo para las máquinas virtuales Windows y Linux en Azure. Azure Update Manager proporciona una solución SaaS para administrar y controlar las actualizaciones de software en máquinas Windows y Linux en entornos locales y multinube de Azure.

Revisiones del SO invitado

Las máquinas virtuales de Azure proporcionan la opción de aplicación automática de revisiones a invitado de máquina virtual. Cuando este servicio está habilitado, las máquinas virtuales se evalúan periódicamente y las revisiones disponibles se clasifican. Se recomienda que el modo de evaluación esté habilitado para permitir la evaluación diaria para las revisiones pendientes. Sin embargo, se puede realizar una evaluación a petición que no desencadene la aplicación de revisiones. Si el modo de evaluación no está habilitado, tiene formas manuales de detectar actualizaciones pendientes.

Solo las revisiones que se clasifican como críticas o de seguridad se aplican automáticamente en todas las regiones de Azure. Defina procesos de administración de actualizaciones personalizados que apliquen otras revisiones.

Para la gobernanza, considere la posibilidad de Exigir la aplicación automática de revisiones de imágenes del sistema operativo en Virtual Machine Scale Sets Azure Policy.

La aplicación automática de parches puede suponer una carga para el sistema y puede ser perjudicial porque las máquinas virtuales utilizan recursos y pueden reiniciarse durante las actualizaciones. Se recomienda sobreaprovisionar para la administración de carga. Implemente máquinas virtuales en diferentes zonas de disponibilidad para evitar actualizaciones simultáneas y mantener al menos dos instancias por zona para lograr una alta disponibilidad. Las máquinas virtuales de la misma región pueden recibir revisiones diferentes, que deben conciliarse con el tiempo.

Tenga en cuenta la compensación del costo asociado con el sobreaprovisionamiento.

Las comprobaciones de estado se incluyen como parte de la aplicación automática de revisiones a invitado de máquina virtual. Estas comprobaciones verifican la aplicación correcta de las revisiones y detectan problemas.

Si hay procesos personalizados para aplicar revisiones, use repositorios privados para orígenes de revisión. Así podrá controlar mejor la prueba de las revisiones para asegurarse de que la actualización no afecta negativamente al rendimiento ni a la seguridad.

Para obtener más información, consulte Aplicación de revisiones automática a invitados de máquina virtual para máquinas virtuales de Azure.

Confiabilidad

Esta arquitectura usa zonas de disponibilidad como un elemento fundamental para abordar los problemas de confiabilidad.

En esta configuración, las máquinas virtuales individuales están vinculadas a una sola zona. Si se produce un error, estas máquinas virtuales se pueden reemplazar fácilmente por otras instancias de máquina virtual mediante Virtual Machine Scale Sets.

Todos los demás componentes de esta arquitectura son:

• Con redundancia de zona, lo que significa que se replican en varias zonas para lograr una alta disponibilidad, como Application Gateway o direcciones IP públicas.
• Resistentes a la zona, lo que implica que pueden resistir errores de zona, como Key Vault.
• Recursos regionales o globales que están disponibles entre regiones o globalmente, como Microsoft Entra ID.

El diseño de la carga de trabajo debe incorporar garantías de confiabilidad en el código de la aplicación, la infraestructura y las operaciones. En las secciones siguientes se muestran algunas estrategias para asegurarse de que la carga de trabajo es resistente a errores y puede recuperarse si hay interrupciones en el nivel de infraestructura.

Las estrategias usadas en la arquitectura se basan en la lista de comprobación de revisión de diseño de confiabilidad indicada en el Marco de buena arquitectura de Azure. Las secciones se anotan con recomendaciones de esa lista de comprobación.

Dado que no se implementa ninguna aplicación, la resistencia en el código de aplicación está fuera del ámbito de esta arquitectura. Se recomienda revisar todas las recomendaciones de la lista de comprobación y adoptarlas en la carga de trabajo, si procede.

Priorizar las garantías de confiabilidad por flujo de usuario

En la mayoría de los diseños, hay varios flujos de usuario, cada uno con su propio conjunto de requisitos empresariales. No todos estos flujos requieren el mayor nivel de garantías, por lo que se recomienda la segmentación como estrategia de confiabilidad. Cada segmento se puede administrar de forma independiente, lo que garantiza que un segmento no afecte a otros y proporcione el nivel adecuado de resistencia en cada nivel. Este enfoque también hace que el sistema sea flexible.

En esta arquitectura, los niveles de aplicación implementan la segmentación. Los conjuntos de escalado independientes se aprovisionan para los niveles front-end y back-end. Esta separación permite el escalado independiente de cada nivel, lo que permite la implementación de patrones de diseño en función de sus requisitos específicos, entre otras ventajas.

Consulte Marco de buena arquitectura: RE:02 - Recomendaciones para identificar y clasificar flujos.

Identificar los posibles puntos de error

Cada arquitectura es susceptible a errores. El ejercicio del análisis del modo de error le permite prever errores y prepararse con mitigaciones. Estos son algunos posibles puntos de error en esta arquitectura:

Componente	Riesgo	Probabilidad	Efecto/Mitigación/Nota	Interrupción
Microsoft Entra ID	Error de configuración	Media	Los usuarios de operaciones no pueden iniciar sesión. Sin efecto de bajada. El departamento de soporte técnico informa del problema de configuración al equipo de identidades.	None
Application Gateway	Error de configuración	Media	Se deben detectar errores de configuración durante la implementación. Si estos errores se producen durante una actualización de configuración, el equipo de DevOps debe revertir los cambios. La mayoría de las implementaciones que usan la SKU v2 tardan aproximadamente 6 minutos en aprovisionarse. Sin embargo, pueden tardar más tiempo en función del tipo de implementación. Por ejemplo, las implementaciones en varias zonas de disponibilidad con muchas instancias pueden tardar más de 6 minutos.	Completo
Application Gateway	Ataques de denegación de servicio distribuido	Media	Potencial de interrupción. Microsoft administra la protección contra DDoS (L3 y L4). Riesgo potencial de efecto de ataques L7.	Completo
Conjuntos de escalado de máquina virtual	Interrupción del servicio	Bajo	Posible interrupción de la carga de trabajo si hay instancias de máquina virtual incorrectas que desencadenan una reparación automática. Depende de Microsoft para corregirlo.	Posible interrupción
Conjuntos de escalado de máquina virtual	Interrupción de la zona de disponibilidad	Bajo	Ningún efecto. Los conjuntos de escalado se implementan como redundantes de zona.	None

Consulte Marco de buena arquitectura: RE:03 - Recomendaciones para realizar el análisis del modo de error.

Objetivos de confiabilidad

Para tomar decisiones de diseño, es importante calcular los objetivos de confiabilidad, como los objetivos compuestos de nivel de servicio (SLO) de la carga de trabajo. Esto implica comprender los acuerdos de nivel de servicio (SLA) proporcionados por los servicios de Azure usados en la arquitectura. Los SLO de carga de trabajo no deben ser superiores a los acuerdos de nivel de servicio garantizados por Azure. Examine cuidadosamente cada componente, desde máquinas virtuales y sus dependencias, redes y opciones de almacenamiento.

Este es un cálculo de ejemplo en el que el objetivo principal es proporcionar un SLO compuesto aproximado. Aunque esta es una guía aproximada, debe llegar a algo similar. No debe obtener un SLO compuesto mayor para los mismos flujos a menos que realice modificaciones en la arquitectura.

Flujo de operación

Componente	SLO
Microsoft Entra ID	99,99 %
Azure Bastion	99,95 %

SLO compuesto: 99,94 % | Tiempo de inactividad por año: 0d 5h 15m 20s

Flujo de usuario de la aplicación

Componente	SLO
Application Gateway	99,95 %
Azure Load Balancer (interno)	99,99 %
Máquinas virtuales de front-end con Premium Storage (SLO compuesto)	99.70%
Máquinas virtuales de back-end con Premium Storage (SLO compuesto)	99.70%

SLO compuesto: 99,34 % | Tiempo de inactividad por año: 2d 9h 42m 18s

En el ejemplo anterior, se incluyen la confiabilidad de las máquinas virtuales y las dependencias, como los discos asociados a las máquinas virtuales. Los SLA asociados con el almacenamiento en disco afectan a la confiabilidad general.

Hay algunos desafíos al calcular el SLO compuesto. Es importante tener en cuenta que los distintos niveles de servicio pueden incluir acuerdos de nivel de servicio diferentes y, a menudo, incluyen garantías respaldadas financieramente que establecen objetivos de confiabilidad. Por último, puede haber componentes de la arquitectura que no tengan acuerdos de nivel de servicio definidos. Por ejemplo, en términos de redes, las NIC y las redes virtuales no tienen sus propios SLA.

Los requisitos empresariales y sus objetivos deben definirse y tenerse en cuenta claramente en el cálculo. Tenga en cuenta los límites de servicio y otras restricciones impuestas por la organización. Compartir la suscripción con otras cargas de trabajo podría afectar a los recursos disponibles para las máquinas virtuales. Es posible que la carga de trabajo pueda usar un número limitado de núcleos disponibles para las máquinas virtuales. Comprender el uso de recursos de la suscripción puede ayudarle a diseñar las máquinas virtuales de forma más eficaz.

Consulte Marco de buena arquitectura: RE:04 - Recomendaciones para definir los objetivos de confiabilidad.

Redundancia

Esta arquitectura usa redundancia de zona para varios componentes. Cada zona de disponibilidad consta de uno o varios centros de datos con alimentación, refrigeración y redes independientes. El hecho de que las instancias se ejecuten en zonas independientes protege la aplicación frente a errores del centro de datos.

• Virtual Machine Scale Sets asigna un número especificado de instancias y las distribuye uniformemente entre zonas de disponibilidad y dominios de error. Esta distribución se logra a través de la capacidad de propagación máxima, que se recomienda. La propagación de instancias de máquina virtual entre dominios de error garantiza que todas las máquinas virtuales no se actualicen al mismo tiempo.

  Supongamos que hay un escenario en el que hay tres zonas de disponibilidad. Si tiene tres instancias, cada instancia se asigna a una zona de disponibilidad diferente y se coloca en un dominio de error diferente. Azure garantiza que solo se actualice un dominio de error a la vez en cada zona de disponibilidad. Sin embargo, podría darse una situación en la que los tres dominios de error que hospedan las máquinas virtuales en las tres zonas de disponibilidad se actualicen simultáneamente. Todas las zonas y dominios se ven afectados. Tener al menos dos instancias en cada zona proporciona un búfer durante las actualizaciones.

• Los discos administrados solo se pueden conectar a una máquina virtual de la misma región. Su disponibilidad suele afectar a la disponibilidad de la máquina virtual. En el caso de las implementaciones de una sola región, los discos se pueden configurar para que la redundancia resista errores de zona. En esta arquitectura, los discos de datos se configuran con almacenamiento con redundancia de zona (ZRS) en las máquinas virtuales de back-end. Requiere una estrategia de recuperación para aprovechar las ventajas de las zonas de disponibilidad. La estrategia de recuperación consiste en volver a implementar la solución. Lo ideal es aprovisionar previamente el proceso en zonas de disponibilidad alternativas listas para recuperarse de un error de zona.

• Una instancia de Application Gateway con redundancia de zona o un equilibrador de carga estándar pueden enrutar el tráfico a las máquinas virtuales entre zonas mediante una sola dirección IP, lo que garantiza la continuidad incluso si se producen errores de zona. Estos servicios usan sondeos de estado para comprobar la disponibilidad de las máquinas virtuales. Siempre que una zona de la región permanezca operativa, el enrutamiento continúa a pesar de posibles errores en otras zonas. Sin embargo, el enrutamiento entre zonas podría tener una mayor latencia en comparación con el enrutamiento dentro de la zona.

  Todas las direcciones IP públicas usadas en esta arquitectura tienen redundancia de zona.

• Azure ofrece servicios resistentes a zonas para mejorar la confiabilidad, como Key Vault.

• Los recursos globales de Azure siempre están disponibles y pueden cambiar a otra región si es necesario, como el proveedor de identidades fundamentales, Microsoft Entra ID.

Consulte Marco de buena arquitectura: RE:05 - Recomendaciones para diseñar la redundancia.

Estrategia de escalado

Para evitar la degradación del nivel de servicio y los errores, garantice la fiabilidad de las operaciones de escalado. Escale la carga de trabajo horizontalmente (escalado horizontal), verticalmente (escalado vertical) o use una combinación de ambos enfoques. Use el escalado automático de Azure Monitor para aprovisionar suficientes recursos para satisfacer la demanda de la aplicación sin asignar más capacidad de la necesaria ni incurrir en costos innecesarios.

El escalado automático permite definir diferentes perfiles en función de diferentes tipos de eventos, como la hora, la programación o las métricas. Los perfiles basados en métricas pueden usar métricas integradas (basadas en host) o métricas más detalladas (métricas de máquinas virtuales invitadas) que requieren la instalación del agente de Azure Monitor para recopilarlas. Cada perfil contiene reglas para el escalado horizontal (aumento) y el escalado horizontal (disminución). Considere la posibilidad de explorar todos los diferentes escenarios de escalado basados en perfiles diseñados y evaluarlos para detectar posibles condiciones de bucle que pueden provocar una serie de eventos de escalado opuestos. Azure Monitor intentará mitigar esta situación esperando el período de reescalado antes de que se vuelva a escalar.

Aunque Azure Virtual Machine Scale Sets en modo flexible admiten entornos heterogéneos, no se admite el escalado automático de varios perfiles. Considere la posibilidad de crear diferentes conjuntos de escalado para administrarlos por separado si planea usar el escalado automático con más de un tipo de máquina virtual.

Tenga en cuenta otros aspectos, como el arranque, los apagados correctos, la instalación de la carga de trabajo y todas sus dependencias y la administración de discos al crear o eliminar instancias de máquinas virtuales.

Las cargas de trabajo con estado pueden requerir una administración adicional para los discos administrados que necesitan vivir más allá de una instancia de carga de trabajo. Diseñe la carga de trabajo para la administración de datos en eventos de escalado teniendo en cuenta la coherencia, sincronización, replicación e integridad de los datos de la carga de trabajo. En esos escenarios, considere la posibilidad de agregar discos rellenados previamente a conjuntos de escalado. En los casos de uso en los que se usa el escalado para evitar cuellos de botella al acceder a los datos, planee la creación de particiones y el particionamiento. Para más información, consulte los procedimientos recomendados del escalado automático.

Consulte Marco de buena arquitectura: RE:06 - Recomendaciones para diseñar una estrategia de escalado confiable.

Recuperación automática y capacidad de recuperación

Las reparaciones automáticas de instancias están habilitadas en Virtual Machine Scale Sets para automatizar la recuperación de errores de máquina virtual. La extensión de estado de la aplicación se implementa en máquinas virtuales para admitir la detección de máquinas virtuales y aplicaciones que no responden. En esos casos, las acciones de reparación se desencadenan automáticamente.

Consulte Marco de buena arquitectura: Recomendaciones para la recuperación automática y la conservación automática.

Seguridad

Esta arquitectura muestra algunas de las garantías de seguridad indicadas en la lista de comprobación de revisión de diseño de seguridad indicada en el Marco de buena arquitectura de Azure. Las secciones se anotan con recomendaciones de esa lista de comprobación.

La seguridad no solo hace referencia a controles técnicos. Se recomienda seguir toda la lista de comprobación para comprender los aspectos operativos del pilar de seguridad.

Segmentación

• Segmentación de red. Los recursos de carga de trabajo se colocan en una red virtual, lo que proporciona aislamiento de Internet. Dentro de la red virtual, las subredes se pueden usar como límites de confianza. Colocar los recursos relacionados necesarios para controlar una transacción en una subred. En esta arquitectura, la red virtual se divide en subredes basadas en la agrupación lógica de la aplicación y el propósito de varios servicios de Azure que se usan como parte de la carga de trabajo.

  La ventaja de la segmentación de subred es que puede colocar controles de seguridad en el perímetro que controla el tráfico que fluye y sale de la subred, lo que restringe el acceso a los recursos de carga de trabajo.

• Segmentación de identidad. Asigne roles distintos a diferentes identidades con permisos suficientes para realizar su tarea. Esta arquitectura usa identidades administradas por Microsoft Entra ID para segmentar el acceso a los recursos.

• Segmentación de recursos. La aplicación se segmenta por niveles en conjuntos de escalado independientes, lo que garantiza que los componentes de la aplicación no estén colocados.

Consulte Marco de buena arquitectura: SE:04 - Recomendaciones para crear una estrategia de segmentación.

Administración de identidades y acceso

Se recomienda Microsoft Entra ID para la autenticación y autorización de los usuarios y servicios.

El acceso a las máquinas virtuales requiere una cuenta de usuario, controlada por la autenticación de Microsoft Entra ID y respaldada por grupos de seguridad. Esta arquitectura proporciona compatibilidad mediante la implementación de la extensión de autenticación de Microsoft Entra ID en todas las máquinas virtuales. Se recomienda que los usuarios utilicen sus identidades corporativas en el inquilino de Microsoft Entra ID de su organización. Además, asegúrese de que cualquier acceso basado en la entidad de servicio no se comparta entre funciones.

Los recursos de carga de trabajo, como las máquinas virtuales, se autentican a sí mismos mediante sus identidades administradas asignadas a otros recursos. Estas identidades, basadas en entidades de servicio de Microsoft Entra ID, se administran automáticamente.

Por ejemplo, las extensiones de Key Vault se instalan en máquinas virtuales, que arrancan las máquinas virtuales con certificados implementados. En esta arquitectura, las identidades administradas asignadas por el usuario se utilizan en Application Gateway, máquinas virtuales front-end y máquinas virtuales de back-end para acceder a Key Vault. Esas identidades administradas se configuran durante la implementación y se usan para autenticarse en Key Vault. Las directivas de acceso en Key Vault están configuradas para aceptar solo solicitudes de las identidades administradas anteriores.

La arquitectura de línea de base usa una combinación de identidades administradas asignadas por el sistema y asignadas por el usuario. Estas identidades son necesarias para usar Microsoft Entra ID con fines de autorización al acceder a otros recursos de Azure.

Consulte Marco de buena arquitectura: SE:05 - Recomendaciones para la administración de identidad y acceso.

Controles de red

• Tráfico de entrada. Las máquinas virtuales de carga de trabajo no se exponen directamente a la red pública de Internet. Cada una de ellas tiene una dirección IP privada. Los usuarios de carga de trabajo se conectan mediante la dirección IP pública de Application Gateway.

  Se proporciona más seguridad a través del Web Application Firewall que se integra con Application Gateway. Tiene reglas que inspeccionan el tráfico entrante y pueden tomar las medidas adecuadas. WAF realiza un seguimiento de las vulnerabilidades de Open Web Application Security Project (OWASP) que impiden ataques conocidos.

• Tráfico de salida. No hay controles en el tráfico saliente, excepto las reglas de NSG salientes en las subredes de máquina virtual. Se recomienda que todo el tráfico saliente de Internet fluya a través de un único firewall. Este firewall suele ser un servicio central proporcionado por una organización. Ese caso de uso se muestra en la Arquitectura de línea de base de máquina virtual en una zona de aterrizaje de Azure.

• Tráfico horizontal de derecha a izquierda. El flujo de tráfico entre las subredes está restringido mediante la aplicación de reglas de seguridad granular.

  Los grupos de seguridad de red (NSG) se colocan para restringir el tráfico entre subredes en función de parámetros como el intervalo de direcciones IP, los puertos y los protocolos. Los grupos de seguridad de aplicaciones (ASG) se colocan en máquinas virtuales front-end y back-end. Se usan con grupos de seguridad de red para filtrar el tráfico hacia y desde las máquinas virtuales.

• Tráfico operativo. Se recomienda proporcionar acceso operativo seguro a una carga de trabajo a través de Azure Bastion, lo que elimina la necesidad de una dirección IP pública. En esta arquitectura, esa comunicación se realiza a través de SSH y es compatible con las máquinas virtuales Windows y Linux. Microsoft Entra ID se integra con SSH para ambos tipos de máquinas virtuales mediante la extensión de máquina virtual correspondiente. Esa integración permite que la identidad de un operador se autentique y autorice a través de Microsoft Entra ID.

  Como alternativa, use una máquina virtual independiente como jump box, implementada en su propia subred, donde puede instalar su elección de herramientas de administración y solución de problemas. El operador accede al jump box a través del host de Azure Bastion. A continuación, inician sesión en las máquinas virtuales detrás del equilibrador de carga desde el jump box.

  En esta arquitectura, el tráfico operativo está protegido mediante reglas de NSG para restringir el tráfico y el acceso a máquinas virtuales Just-In-Time (JIT) está habilitado en las máquinas virtuales. Esta característica de Microsoft Defender for Cloud permite el acceso de entrada temporal a los puertos seleccionados.

  Para mejorar la seguridad, use Microsoft Entra Privileged Identity Management (PIM). PIM es un servicio de Microsoft Entra ID que le permite administrar, controlar y supervisar el acceso a recursos importantes de la organización. PIM proporciona activación de rol basada en tiempo y en aprobación para mitigar los riesgos de tener unos permisos de acceso excesivos, innecesarios o mal utilizados en los recursos que le interesan.

• Conectividad privada a servicios de plataforma como servicio (PaaS). La comunicación entre las máquinas virtuales y Key Vault se realiza a través de Private Link. Este servicio requiere puntos de conexión privados, que se colocan en una subred independiente.

• DDoS Protection. Considere la posibilidad de habilitar Azure DDoS Protection en las direcciones IP públicas expuestas por Application Gateway y el host de Azure Bastion para detectar amenazas. DDoS Protection también proporciona alertas, datos de telemetría y análisis a través de Monitor. Para más información, consulte Azure DDoS Protection: procedimientos recomendados y arquitecturas de referencia.

Consulte Marco de buena arquitectura: SE:06 - Recomendaciones para redes y conectividad.

Cifrado

• Datos en tránsito. El tráfico de usuario entre los usuarios y la dirección IP pública de Application Gateway se cifra mediante el certificado externo. El tráfico entre la puerta de enlace de aplicaciones y las máquinas virtuales de front-end y entre las máquinas virtuales de front-end y back-end se cifra mediante un certificado interno. Ambos certificados se almacenan en Key Vault:

  • app.contoso.com: un certificado externo que usan los clientes y Application Gateway para proteger el tráfico público de Internet.
  • *.workload.contoso.com: un certificado comodín usado por los componentes de infraestructura para proteger el tráfico interno.

• Datos en reposo. Los datos de registro se almacenan en un disco administrado conectado a máquinas virtuales. Esos datos se cifran automáticamente mediante el cifrado proporcionado por la plataforma en Azure.

Consulte Marco de buena arquitectura: SE:07 : Recomendaciones para el cifrado de datos.

Administración de secretos

Descargue un archivo Visio de esta arquitectura.

Key Vault proporciona una administración segura de secretos, incluidos los certificados TLS. En esta arquitectura, los certificados TLS se almacenan en Key Vault y se recuperan durante el proceso de aprovisionamiento mediante las identidades administradas de Application Gateway y las máquinas virtuales. Después de la configuración inicial, estos recursos solo acceden a Key Vault cuando se actualizan los certificados.

Las máquinas virtuales usan la extensión de máquina virtual de Key Vault para actualizar automáticamente los certificados supervisados. Si se detectan cambios en el almacén de certificados local, la extensión recupera e instala los certificados correspondientes de Key Vault. La extensión admite tipos de contenido de certificado PKCS #12 y PEM.

Consulte Marco de buena arquitectura: SE:09 : Recomendaciones para proteger los secretos de aplicación.

Optimización de costos

Los requisitos de carga de trabajo deben cumplirse teniendo en cuenta las restricciones de costos. Las estrategias usadas en la arquitectura se basan en la lista de comprobación de revisión de diseño de optimización de costos indicada en el Marco de buena arquitectura de Azure. En esta sección se describen algunas opciones para optimizar el costo y se anota con recomendaciones de esa lista de comprobación.

Costo de componentes

Seleccione imágenes de máquina virtual optimizadas para la carga de trabajo en lugar de usar imágenes de uso general. En esta arquitectura, se eligen imágenes de máquina virtual relativamente pequeñas para Windows y Linux, que son de 30 GB cada una. Con imágenes más pequeñas, las SKU de máquina virtual con discos también son más pequeñas, lo que conduce a menores costos, a un menor consumo de recursos y a tiempos de implementación y arranque más rápidos. Una ventaja es una seguridad mejorada debido al área expuesta reducida.

La implementación de la rotación de registros con límites de tamaño es otra estrategia de ahorro de costos. Permite el uso de discos de datos pequeños, lo que puede dar lugar a menores costos. La implementación de esta arquitectura usa discos de 4 GB.

El uso de discos del sistema operativo efímeros también puede provocar un ahorro de costos y un rendimiento mejorado. Estos discos están diseñados para usar recursos de máquina virtual que ya paga porque están instalados en el disco de caché aprovisionado con la máquina virtual. Elimina los costos de almacenamiento asociados a los discos persistentes tradicionales. Dado que estos discos son temporales, no hay costos asociados con el almacenamiento de datos a largo plazo.

Consulte Marco de buena arquitectura: CO:07 - Recomendaciones para optimizar los costos de los componentes.

Costo de flujos

Elija los recursos de proceso en función de la importancia crítica del flujo. En el caso de los flujos diseñados para tolerar una longitud indeterminada, considere la posibilidad de usar máquinas virtuales de acceso puntual con el modo de orquestación flexible de Virtual Machine Scale Sets. Este enfoque puede ser eficaz para hospedar flujos de prioridad baja en máquinas virtuales de prioridad inferior. Esta estrategia permite la optimización de costos, a la vez que cumple los requisitos de diferentes flujos.

Consulte Marco de buena arquitectura: CO:09 - Recomendaciones para optimizar los costos de los flujos.

Costo de escalado

Si el controlador de costos principal es el número de instancias, puede ser más rentable escalar verticalmente aumentando el tamaño o el rendimiento de las máquinas virtuales. Este enfoque puede dar lugar a un ahorro de costos en varias áreas:

• Licencias de software. Las máquinas virtuales más grandes pueden controlar más cargas de trabajo, lo que podría reducir el número de licencias de software necesarias.
• Tiempo de mantenimiento: menos máquinas virtuales más grandes pueden reducir los costos operativos.
• Equilibrio de carga: menos máquinas virtuales pueden dar lugar a costos más bajos para el equilibrio de carga. Por ejemplo, en esta arquitectura hay varias capas de equilibrio de carga, como una puerta de enlace de aplicaciones en el frente y un equilibrador de carga interno en el centro. Los costos de equilibrio de carga aumentarían si es necesario administrar un mayor número de instancias.
• Disk storage. Si hay aplicaciones con estado, más instancias necesitan más discos administrados conectados, lo que aumenta el costo de almacenamiento.

Consulte Marco de buena arquitectura: CO:12 - Recomendaciones para optimizar los costos de escalado.

Costos operativos

La aplicación automática de revisiones a invitados de máquina virtual reduce la sobrecarga de la aplicación de revisiones manuales y los costos de mantenimiento asociados. Esta acción no solo ayuda a que el sistema sea más seguro, sino que también optimiza la asignación de recursos, lo que contribuye a la eficiencia global de los costos.

Consulte Marco de buena arquitectura: CO:13 - Recomendaciones para optimizar el tiempo del personal.

Implementación de este escenario

Hay disponible una implementación de esta arquitectura de referencia en GitHub.

Recursos relacionados

Consulte la documentación del producto para obtener más información sobre servicios específicos de Azure:

• Azure Virtual Machines
• Azure Virtual Machine Scale Sets
• Azure Virtual Network
• Standard_v2 de Azure Application Gateway
• Equilibrador de carga de Azure
• Azure Key Vault
• Azure Bastion
• Application Insights
• Log Analytics

Paso siguiente

Revise las arquitecturas de referencia de IaaS que muestran las opciones del nivel de datos:

• Aplicación Windows de n niveles que usan SQL Server en Azure