Examen Ref AZ-104 Administrador de

Microsoft Azure
Segunda edicion

Carlos Plutón

Examen Ref AZ-104 Administrador de Microsoft Azure, segunda edición

Publicado con la autorización de Microsoft Corporation por: Pearson Education, Inc.

Copyright © 2025 por Pearson Education, Inc.

Hoboken, Nueva Jersey

Reservados todos los derechos. Esta publicación está protegida por derechos de autor y se
debe obtener permiso del editor antes de cualquier reproducción prohibida, almacenamiento
en un sistema de recuperación o transmisión en cualquier forma o por cualquier medio, ya
sea electrónico, mecánico, fotocopia, grabación o similar. Para obtener información sobre
permisos, formularios de solicitud y los contactos apropiados dentro del Departamento de
Permisos y Derechos Globales de Pearson Education,
visite www.pearson.com/permissions .

No se asume ninguna responsabilidad de patente con respecto al uso de la información

contenida en este documento. Aunque se han tomado todas las precauciones en la
preparación de este libro, el editor y el autor no asumen ninguna responsabilidad por
errores u omisiones. Tampoco se asume ninguna responsabilidad por los daños resultantes
del uso de la información aquí contenida.

ISBN-13: 978-0-13-834593-8
ISBN-10: 0-13-834593-7

Número de control de la Biblioteca del Congreso: 2024935895

$PrintCode

MARCAS COMERCIALES
Microsoft y las marcas comerciales enumeradas en http://www.microsoft.com en la página
web "Marcas comerciales" son marcas comerciales del grupo de empresas Microsoft. Todas
las demás marcas son propiedad de sus respectivos dueños.

ADVERTENCIA Y DESCARGO DE RESPONSABILIDAD

Se ha hecho todo lo posible para que este libro sea lo más completo y preciso posible, pero
no implica garantía ni idoneidad. La información proporcionada es "tal cual". El autor, el
editor y Microsoft Corporation no tendrán responsabilidad ante ninguna persona o entidad
con respecto a cualquier pérdida o daño que surja de la información contenida en este libro
o del uso de los programas que lo acompañan.

VENTAS ESPECIALES

Para obtener información sobre la compra de este título en grandes cantidades o para
oportunidades de ventas especiales (que pueden incluir versiones electrónicas, diseños de
portada personalizados y contenido específico para su negocio, objetivos de capacitación,
enfoque de marketing o intereses de marca), comuníquese con nuestro departamento de
ventas corporativo. en [email protected] o (800) 382-3419.

Para consultas sobre ventas gubernamentales, comuníquese

con [email protected] .

Si tiene preguntas sobre ventas fuera de EE. UU., comuníquese con [email protected] .

Contenidos de un vistazo

1. Expresiones de gratitud
2. Sobre el Autor
3. Introducción
4. CAPÍTULO 1 Administrar identidades y gobernanza de Azure
5. CAPÍTULO 2 Implementar y gestionar el almacenamiento
6. CAPÍTULO 3 Implementar y administrar recursos informáticos de Azure
7. CAPÍTULO 4 Configurar y administrar redes virtuales
8. CAPÍTULO 5 Supervisar y realizar copias de seguridad de los recursos de Azure
9. CAPÍTULO 6 Examen Ref AZ-104 Actualizaciones del examen Administrador de
Microsoft Azure
10. Índice

Contenido

1. Introducción
1. Organización de este libro.
2. Preparándose para el examen
3. Certificaciones de Microsoft
 4. Acceda al capítulo de actualizaciones del examen y a las referencias en
línea.
5. Fe de erratas, actualizaciones y soporte para libros
6. Mantente en contacto
2. Capítulo 1 Administrar identidades y gobernanza de Azure
1. Habilidad 1.1: Administrar usuarios y grupos de Microsoft Entra
1. Crear usuarios y grupos
2. Administrar propiedades de usuarios y grupos
3. Administrar licencias en Microsoft Entra ID
4. Administrar usuarios externos
5. Configurar la unión a Microsoft Entra
6. Configurar el restablecimiento de contraseña de autoservicio
2. Habilidad 1.2: Administrar el acceso a los recursos de Azure
1. Entender cómo funciona RBAC
2. Crear un rol personalizado
3. Interpretar asignaciones de acceso
4. Administrar múltiples directorios
3. Habilidad 1.3: Administrar suscripciones y gobierno de Azure
1. Configurar políticas de Azure
2. Configurar bloqueos de recursos
3. Aplicar y administrar etiquetas en recursos
4. Administrar grupos de recursos
5. Administrar suscripciones de Azure
6. Configurar grupos de administración
7. Configurar la gestión de costes
4. Resumen del capítulo
5. Experimento mental
6. Respuestas del experimento mental
3. Capítulo 2 Implementar y gestionar el almacenamiento
1. Habilidad 2.1: Configurar el acceso al almacenamiento
1. Crear y configurar cuentas de almacenamiento
2. Configurar firewalls y redes virtuales de Azure Storage
3. Crear y utilizar tokens de firma de acceso compartido (SAS)
4. Configurar políticas de acceso almacenadas
5. Administrar claves de acceso
6. Configurar el acceso basado en identidad
2. Habilidad 2.2: Configurar y administrar cuentas de almacenamiento
1. Configurar la redundancia del almacenamiento de Azure
2. Configurar la replicación de objetos
3. Configurar el cifrado de la cuenta de almacenamiento
4. Administrar datos mediante Azure Storage Explorer
5. Administrar datos mediante AzCopy
3. Habilidad 2.3: Configurar Azure Files y Azure Blob Storage
1. Crear y configurar un recurso compartido de archivos en Azure
Storage
2. Configurar el almacenamiento de blobs de Azure
3. Configurar niveles de almacenamiento
 4. Configurar eliminación temporal, control de versiones e instantáneas
5. Configurar la administración del ciclo de vida del blob
4. Resumen del capítulo
5. Experimento mental
6. Respuestas del experimento mental
4. Capítulo 3 Implementar y administrar recursos informáticos de Azure
1. Habilidad 3.1: Automatizar la implementación de recursos
1. Interpretar una plantilla de Azure Resource Manager
2. Modificar una plantilla ARM existente
3. Implementar recursos desde una plantilla
4. Exportar una plantilla de implementación
5. Interpretar y modificar un archivo Bicep
2. Habilidad 3.2: Crear y configurar máquinas virtuales
1. Crear una máquina virtual
2. Configurar el cifrado de disco de Azure
3. Mover máquinas virtuales de un grupo de recursos o suscripción a
otro
4. Administrar tamaños de VM
5. Administrar discos de VM
6. Implementar máquinas virtuales en zonas y conjuntos de
disponibilidad
7. Implementar y configurar conjuntos de escalado de máquinas
virtuales
3. Habilidad 3.3: Aprovisionar y gestionar contenedores
1. Crear y administrar un Registro de contenedores de Azure
2. Aprovisionar un contenedor mediante Azure Container Instances
3. Aprovisionar un contenedor mediante Azure Container Apps
4. Gestionar el tamaño y el escalado de los contenedores.
4. Habilidad 3.4: Crear y configurar Azure App Service
1. Aprovisionar un plan de App Service
2. Configurar el escalado para un plan de App Service
3. Crear un servicio de aplicación
4. Asigne un nombre DNS personalizado existente a un servicio de
aplicaciones
5. Configurar certificados y TLS para un App Service
6. Configurar la copia de seguridad para un App Service
7. Configurar los ajustes de red para un App Service
8. Configurar ranuras de implementación para un App Service
5. Resumen del capítulo
6. Experimento mental
7. Respuestas del experimento mental
5. Capítulo 4 Configurar y administrar redes virtuales
1. Habilidad 4.1: Configurar y administrar redes virtuales en Azure
1. Crear y configurar redes y subredes virtuales.
2. Crear y configurar el emparejamiento de redes virtuales
3. Configurar direcciones IP públicas
4. Configurar rutas de red definidas por el usuario
 5. Solucionar problemas de conectividad de red
2. Habilidad 4.2: Configurar el acceso seguro a redes virtuales
1. Crear y configurar grupos de seguridad de red y grupos de seguridad
de aplicaciones.
2. Evaluar reglas de seguridad efectivas
3. Implementar y configurar el servicio Azure Bastion
4. Configurar puntos de conexión de servicio para servicios de Azure
5. Configurar puntos de conexión privados para servicios de Azure
3. Habilidad 4.3: Configurar la resolución de nombres y el equilibrio de carga
1. Configurar DNS de Azure
2. Configurar el equilibrio de carga
3. Solucionar problemas de equilibrio de carga
4. Resumen del capítulo
5. Experimento mental
6. Respuestas del experimento mental
6. Capítulo 5 Supervisar y realizar copias de seguridad de los recursos de Azure
1. Habilidad 5.1: Monitorear recursos en Azure
1. Interpretar métricas en Azure Monitor
2. Configurar los ajustes de registro en Azure Monitor
3. Consultar y analizar registros en Azure Monitor
4. Configurar reglas de alerta, grupos de acciones y reglas de
procesamiento de alertas en Azure Monitor
5. Configurar información sobre aplicaciones
6. Configure e interprete la supervisión de máquinas virtuales, cuentas
de almacenamiento y redes mediante Azure Monitor Insights
7. Utilice Azure Network Watcher y Connection Monitor
2. Habilidad 5.2: Implementar respaldo y recuperación
1. Crear y administrar una bóveda de Recovery Services
2. Configurar la recuperación del sitio de Azure
3. Crear una bóveda de Azure Backup
4. Crear y configurar una política de respaldo
5. Configurar y revisar informes de respaldo
3. Resumen del capítulo
4. Experimento mental
5. Respuestas del experimento mental
7. Capítulo 6 Examen Ref AZ-104 Actualizaciones del examen Administrador de
Microsoft Azure
1. El propósito de este capítulo
1. Sobre posibles actualizaciones de exámenes
2. Impacto en ti y tu plan de estudios
2. Noticias y comentarios sobre las actualizaciones de objetivos del examen.
3. Contenido técnico actualizado
4. Mapeo objetivo
8. Índice
Sobre el Autor

CHARLES PLUTA es consultor técnico y formador certificado de Microsoft (MCT),

autor de varios exámenes de certificación, guías de laboratorio y guías de aprendizaje para
varios proveedores de tecnología. Como consultor técnico, Charles ha ayudado a
organizaciones pequeñas, medianas y grandes a implementar y mantener su infraestructura
de TI. También es orador, miembro del personal o formador en varias grandes conferencias
anuales de la industria. Charles tiene una licenciatura en redes informáticas y cuenta con
más de 15 certificaciones industriales. Se propone dejar Estados Unidos para viajar a un
país diferente cada año. Cuando no trabaja o viaja, juega al billar en Augusta, Georgia.

Introducción

Algunos libros adoptan un enfoque de muy bajo nivel y le enseñan cómo utilizar clases
individuales y realizar tareas detalladas. Al igual que el examen de certificación Microsoft
AZ-104, este libro adopta un enfoque de alto nivel, basándose en su conocimiento básico de
Microsoft Azure y las acciones administrativas comunes que se deben realizar en un
entorno de Azure. Proporcionamos recorridos mediante el portal Azure; sin embargo, el
examen también puede incluir preguntas que utilizan PowerShell o la interfaz de línea de
comandos (CLI) de Azure para realizar la misma tarea. Es posible que encuentre preguntas
en el examen centradas en estas áreas adicionales que no están incluidas específicamente en
esta referencia del examen .

Este libro cubre todos los temas principales que se encuentran en el examen, pero no cubre
todas las preguntas del examen. Sólo el equipo de examen de Microsoft tiene acceso a las
preguntas del examen, y Microsoft agrega periódicamente nuevas preguntas al examen, lo
que hace imposible cubrir preguntas específicas. Debería considerar este libro como un
complemento a su experiencia relevante en el mundo real y otros materiales de estudio. Si
encuentra un tema en este libro con el que no se siente completamente cómodo, utilice la
opción “¿Necesita más revisión?” enlaces que encontrarás en el texto para encontrar más
información y tomarte el tiempo para investigar y estudiar el tema.

Organización de este libro.

Este libro está organizado según la lista de "Habilidades medidas" publicada para el
examen. La lista de "Habilidades medidas" está disponible para cada examen en el sitio
web de Microsoft Learn: microsoft.com/learn . Cada capítulo de este libro corresponde a un
área temática importante de la lista, y las tareas técnicas en cada área temática determinan
la organización de un capítulo. Si un examen cubre seis áreas temáticas principales, por
ejemplo, el libro contendrá seis capítulos.

Preparándose para el examen

Los exámenes de certificación de Microsoft son una excelente manera de desarrollar su

currículum y dejar que el mundo conozca su nivel de experiencia. Los exámenes de
certificación validan su experiencia laboral y su conocimiento del producto. Aunque no
existe un sustituto para la experiencia laboral, la preparación mediante el estudio y la
práctica práctica puede ayudarle a prepararse para el examen. Este libro no está diseñado
para enseñarle nuevas habilidades.

Le recomendamos que aumente su plan de preparación para el examen utilizando una

combinación de materiales de estudio y cursos disponibles. Por ejemplo, puede utilizar
la referencia del examen y otra guía de estudio para su preparación en casa y realizar un
curso del plan de estudios oficial de Microsoft para la experiencia en el aula. Elige la
combinación que creas que funciona mejor para ti. Obtenga más información sobre la
capacitación presencial, los cursos en línea y los eventos en vivo disponibles
en microsoft.com/learn .

Tenga en cuenta que esta referencia de examen se basa en información disponible

públicamente sobre el examen y la experiencia del autor. Para salvaguardar la integridad
del examen, los autores no tienen acceso al examen en vivo.

Certificaciones de Microsoft

Las certificaciones de Microsoft lo distinguen al demostrar su dominio de un amplio

conjunto de habilidades y experiencia con los productos y tecnologías actuales de
Microsoft. Los exámenes y las certificaciones correspondientes se desarrollan para validar
su dominio de competencias críticas mientras diseña y desarrolla, o implementa y brinda
soporte, soluciones con productos y tecnologías de Microsoft tanto en las instalaciones
como en la nube. La certificación aporta una variedad de beneficios al individuo, a los
empleadores y a las organizaciones.

Más información Todas las certificaciones de Microsoft

Para obtener información sobre las certificaciones de Microsoft, incluida una lista completa
de las certificaciones disponibles, visite microsoft.com/learn .

Acceda al capítulo de actualizaciones del examen y a las referencias en línea.

El último capítulo de este libro, " Actualizaciones del examen AZ-104 Azure
Administrator ", se utilizará para proporcionar información sobre el contenido nuevo por
cada nuevo tema del examen, el contenido que se ha eliminado de los objetivos del examen
y la asignación revisada de los objetivos del examen al contenido del capítulo. . El capítulo
estará disponible desde el enlace al final de esta sección a medida que se publiquen las
actualizaciones del examen.

A lo largo de este libro hay direcciones de páginas web que el autor ha recomendado visitar
para obtener más información. Los hemos recopilado en una lista única a la que los lectores
de la edición impresa pueden consultar mientras leen.

Las URL están organizadas por capítulo y encabezado. Cada vez que encuentre una URL
en el libro, busque el hipervínculo en la lista para ir directamente a la página web.
Descargue el capítulo de actualizaciones del examen y la lista de URL
en MicrosoftPressStore.com/ERAZ1042e/downloads .

Fe de erratas, actualizaciones y soporte para libros

Hemos hecho todo lo posible para garantizar la exactitud de este libro y su contenido
complementario. Puede acceder a las actualizaciones de este libro, en forma de una lista de
erratas enviadas y sus correcciones relacionadas, en

MicrosoftPressStore.com/ERAZ1042e/errata

Si descubre un error que aún no figura en la lista, envíenoslo a la misma página.

Para obtener información y soporte adicional sobre libros,

visite MicrosoftPressStore.com/Support .

Tenga en cuenta que el soporte de productos para software y hardware de Microsoft no se

ofrece a través de las direcciones anteriores. Para obtener ayuda con el software o hardware
de Microsoft, visite support.microsoft.com .

Mantente en contacto

¡Sigamos la conversación! Estamos en X/Twitter: twitter.com/MicrosoftPress .

Capítulo 1
Administrar identidades y gobernanza de Azure

Microsoft ha sido durante mucho tiempo líder en el espacio de la identidad. Este liderazgo
se remonta a la introducción de Active Directory (AD) con Windows 2000 incluso antes de
que existiera la nube. Microsoft pasó a la identidad en la nube con la introducción de Azure
Active Directory (Azure AD), ahora Microsoft Entra ID, que utilizan más de 5 millones de
empresas en todo el mundo. La adopción de Microsoft 365 llevó a este uso ampliado de
Entra ID. Sin embargo, estas dos tecnologías tienen propósitos muy diferentes: AD se usa
principalmente en las instalaciones y Entra ID se usa principalmente para la nube.

Microsoft ha invertido recursos para que AD y Entra ID locales funcionen juntos. El

concepto es extender la identidad local a la nube mediante la sincronización de las
identidades. Esta capacidad la proporcionan Microsoft Entra Connect y Microsoft Entra
Connect Sync. Microsoft también ha invertido en ampliar esas identidades para permitir
escenarios como el inicio de sesión único mediante el uso de Servicios de federación de
Active Directory (ADFS), que se implementa en muchas empresas grandes. (Tenga en
cuenta que Entra Connect y Entra Connect Sync no están cubiertos en el examen AZ-104).

Microsoft ha seguido avanzando desarrollando opciones para que los desarrolladores

aprovechen Entra ID para sus aplicaciones. Microsoft ofrece a los desarrolladores la
posibilidad de ampliar el proveedor de identidad de una empresa a usuarios fuera de la
organización. La primera opción se conoce como Microsoft Entra External ID. Esto permite
a los clientes iniciar sesión en aplicaciones utilizando sus cuentas de redes sociales, como
una identificación de Facebook. Una tecnología complementaria, Entra ID B2B (Business
to Business), extiende Entra ID a los socios comerciales.

Esta área del examen AZ-104 se centra en la gestión de identidades mediante Entra ID.

En la última parte de este capítulo, también aprenderá cómo administrar el control de

acceso basado en roles (RBAC) para recursos de Azure, incluidos los siguientes temas:

 Entender cómo funciona RBAC

 Crear una asignación de rol personalizada
 Proporcionar acceso a recursos de Azure mediante diferentes roles.
 Interpretar la asignación de acceso
 Administrar múltiples directorios

Finalmente, aprenderá a administrar las suscripciones de Azure y otros recursos. Esto

incluye cómo

 Configure Azure Policy para garantizar que su entorno de Azure se gobierne de

manera efectiva mientras se mantiene la agilidad de la nube.
 Aplicar gobernanza a grupos de recursos de Azure y sus recursos secundarios a
través de Azure Policy
 Crear y administrar bloqueos de recursos
  Aplicar etiquetas a recursos de Azure
 Gestionar el ciclo de vida de los recursos que residen en grupos de recursos.
 Administrar suscripciones de Azure
 Configurar grupos de administración
 Gobierna la gestión de costos a través de cuotas y etiquetas de recursos.

Al comprender los controles que están disponibles en Azure para la administración de

recursos y suscripciones, permitirá que su organización tenga éxito en todo su patrimonio
de Azure.

Habilidades cubiertas en este capítulo:

 Habilidad 1.1: Administrar usuarios y grupos de Microsoft Entra

 Habilidad 1.2: Administrar el acceso a los recursos de Azure
 Habilidad 1.3: Administrar suscripciones y gobierno de Azure

Habilidad 1.1: Administrar usuarios y grupos de Microsoft Entra

En un inquilino de Microsoft Entra, hay usuarios, grupos y dispositivos que se controlan

mediante las funciones de Entra que se analizan en esta sección. Esta sección se centra en la
administración de usuarios y grupos a lo largo de sus ciclos de vida, cómo administrar la
configuración del dispositivo, cómo realizar actualizaciones masivas para los usuarios
utilizando herramientas de automatización como PowerShell y cómo administrar cuentas de
invitados.

La última parte de esta sección analiza cómo administrar los dispositivos unidos a Entra y
cómo configurar los controles de experiencia del usuario, como el restablecimiento de
contraseña de autoservicio (SSPR).

Esta habilidad cubre cómo:

 Crear usuarios y grupos

 Administrar propiedades de usuarios y grupos
 Administrar licencias en Microsoft Entra ID
 Administrar usuarios externos
 Configurar la unión con Microsoft Entra ID
 Configurar el restablecimiento de contraseña de autoservicio

Crear usuarios y grupos

Existen principalmente dos tipos de usuarios en Entra ID: usuarios solo en la nube y
usuarios sincronizados desde un directorio local. Los usuarios exclusivos de la nube se
crean y administran exclusivamente en Entra ID, y sus atributos se pueden actualizar
directamente en Entra ID.
Puede crear usuarios solo en la nube a través de Azure Portal, Azure PowerShell, la interfaz
de línea de comandos (CLI) de Azure, el Centro de administración de Microsoft Entra o
mediante Microsoft Graph. Al crear nuevos usuarios, se le debe asignar el rol de
Administrador global o Administrador de usuarios. Consulte la Habilidad 1.2 para obtener
más detalles sobre los diversos roles y sus asignaciones.

Para crear usuarios desde Azure Portal, escriba Microsoft Entra ID en el cuadro de
búsqueda o busque Todos los servicios de Azure y seleccione Microsoft Entra ID como
usuario con derechos para crear usuarios, haga clic en Usuarios para abrir la hoja Usuarios,
haga clic en Nuevo usuario y haga clic en Crear un nuevo usuario. En la Figura 1-1 se
muestra un ejemplo de esta hoja . Tenga en cuenta que también puede invitar a usuarios
(usuarios invitados) a su directorio a través de Azure Portal.

FIGURA 1-1 Hoja Crear nuevo usuario en Azure Portal

Al crear un nuevo usuario, los campos Nombre principal de usuario (nombre de usuario),
Nombre para mostrar (el nombre y apellido del usuario) y Contraseña son obligatorios.
Puede configurar ajustes adicionales, como asignar grupos y roles específicos, bloquear
inicios de sesión desde una ubicación específica, etc.
¿Necesita más revisión? Administrar usuarios

Para obtener más información sobre la administración de cuentas de usuario,

consulte https://learn.microsoft.com/en-us/entra/fundamentals/how-to-create-delete-users .

Los grupos son grupos de objetos que facilitan la administración de las asignaciones de
roles y los permisos de acceso. Un grupo puede contener grupos, usuarios, dispositivos o
entidades de servicio. Al utilizar grupos, elimina la necesidad de asignar roles o permisos
individualmente. La creación de grupos es una experiencia similar a la creación de cuentas
de usuario y se puede realizar desde Azure Portal, Azure PowerShell, la CLI de Azure,
Microsoft Entra Admin Center y Microsoft Graph. Para crear un grupo en Azure Portal,
escriba Microsoft Entra ID en el campo Buscar o busque Todos los servicios de Azure,
seleccione Microsoft Entra ID, haga clic en Grupos para abrir la hoja Grupos y haga clic en
Nuevo grupo. La hoja Nuevo grupo se muestra en la Figura 1-2 .

FIGURA 1-2 Hoja de nuevo grupo en Azure Portal

Cuando crea un nuevo grupo, hay varios factores que dictan el tipo de grupo que se crea y
cómo se comporta ese grupo en Entra y las cargas de trabajo asociadas, como Microsoft
365.
¿Necesita más revisión? Marca de Microsoft 365

En 2020, Office 365 pasó a llamarse Microsoft 365. Puede encontrar detalles sobre cómo se
integra Microsoft 365 con Azure en https://learn.microsoft.com/en-us/microsoft-
365/enterprise/azure-integration?view=o365 -mundial .

Primero, debes seleccionar el tipo de grupo que estás creando. Tiene dos opciones:
Seguridad y Microsoft 365. Los grupos de seguridad le permiten compartir el acceso a los
recursos de Azure con un grupo de usuarios, dispositivos o entidades de servicio. Un grupo
de Microsoft 365 permite el acceso a un buzón de correo compartido, un calendario, un
sitio de SharePoint, etc. Tenga en cuenta que incluso si está creando grupos en un inquilino
de Entra que no está asociado con una suscripción de Microsoft 365, seguirá viendo la
opción para crear un grupo de Microsoft 365.

Además, el nombre del grupo es un campo obligatorio. Si bien no es obligatorio completar

una descripción de grupo, se recomienda incluir una descripción de grupo para que sea más
fácil encontrar e identificar el propósito de un grupo más adelante.

El menú desplegable Tipo de membresía ofrece tres opciones:

 Asignado Utilice esta opción para seleccionar uno o más usuarios y agregarlos al
grupo. Agregar y eliminar usuarios se realiza manualmente.
 Usuario dinámico Seleccione esta opción para utilizar reglas de grupo dinámico
para agregar y eliminar miembros automáticamente.
 Dispositivo dinámico Seleccione esta opción para utilizar reglas de grupo dinámico
para agregar y eliminar dispositivos automáticamente.

Requisito importante del grupo dinámico

Puede crear un grupo dinámico solo si tiene una licencia Microsoft Entra ID P1 o P2. De lo
contrario, la opción Tipo de membresía no está disponible y está configurada en Asignada.

Tanto para usuarios dinámicos como para grupos dinámicos basados en dispositivos, las
reglas asociadas con el grupo se evalúan de forma continua. Si un usuario o dispositivo
tiene un atributo que coincide con la regla, ese usuario o dispositivo se agrega al grupo. Si
un atributo cambia y el usuario o dispositivo ya no coincide con los criterios de membresía
del grupo, la entidad se eliminará. El procesamiento de membresía no es inmediato. Si se
produce un error al procesar una regla de membresía, aparece un error en la hoja Grupo en
Azure Portal. Siempre puede ver el estado de procesamiento actual desde la hoja Grupo.

Es importante tener en cuenta que puedes crear un grupo dinámico para usuarios o
dispositivos, pero no puedes crear ambos al mismo tiempo. Tampoco puede utilizar
atributos de usuario en una regla basada en dispositivo. Es posible cambiar el tipo de
membresía de un grupo después de su creación, lo que brinda la oportunidad de realizar la
transición de un modelo de membresía estática (o asignada) a un modelo de membresía
dinámica o viceversa.
Al crear grupos dinámicos, las reglas se pueden editar en el formato de regla simple, donde
creará la consulta y las condiciones en el generador de reglas, donde podrá crear reglas
complejas con lógica condicional. En el ejemplo que se muestra en la Figura 1-3 , se está
creando un grupo de usuarios dinámico, que actualizará automáticamente su membresía
según el atributo del departamento y su valor en Entra ID.

FIGURA 1-3 Reglas de membresía dinámica

Los grupos dinámicos requieren una licencia Entra ID Premium P1 o Premium P2.

Administrar propiedades de usuarios y grupos

A medida que se utilizan usuarios y grupos, es posible que necesiten actualizaciones de sus
atributos (o propiedades). Por ejemplo, es posible que necesite cambiar el puesto de trabajo
de un usuario o agregar o eliminar miembros de un grupo existente.

Los usuarios y grupos se pueden actualizar mediante herramientas de administración como

Azure Portal, Azure PowerShell, Azure CLI y Microsoft Graph. La Figura 1-4 muestra un
ejemplo del perfil de usuario en Azure Portal al que se puede acceder navegando hasta su
inquilino de Entra, seleccionando Usuarios, eligiendo un usuario y haciendo clic en Editar
propiedades.
FIGURA 1-4 Un perfil de usuario en Azure Portal

Los grupos se pueden administrar a través de Azure Portal navegando hasta su inquilino de
Entra, seleccionando Grupos, eligiendo un grupo específico y luego haciendo clic en
Propiedades, Miembros o Propietarios, según el tipo de actualización que desee realizar. Al
editar un grupo, no podrá cambiar el tipo de grupo (como cambiar un grupo de seguridad a
un grupo de Microsoft 365), pero podrá actualizar el nombre del grupo, la descripción del
grupo y el tipo de membresía, como se muestra. en la Figura 1-5 . Al cambiar un grupo
estático a un grupo dinámico se eliminarán todos los miembros del grupo estático y se
aplicarán reglas de membresía dinámica. Este cambio también afectará el acceso a los
recursos si el grupo estático tiene algún acceso asignado previamente para sus miembros.
FIGURA 1-5 Propiedades de grupo en Azure Portal

Los dispositivos registrados y unidos en Entra ID se pueden administrar en dos áreas en

Azure Portal:

 Busque su inquilino de Entra en Azure Portal y seleccione Dispositivos.

Descripción general es la vista predeterminada, pero también puede elegir otras
vistas, como Todos los dispositivos, Configuración del dispositivo, Claves de
BitLocker, etc.
 Abra la hoja Dispositivos para un usuario individual.

Con cualquiera de las opciones, podrá buscar dispositivos utilizando el nombre del
dispositivo como filtro, ver una descripción detallada de cualquier dispositivo registrado y
unido, y realizar tareas comunes de administración de dispositivos.

Para habilitar y deshabilitar dispositivos, debe ser administrador global, administrador de

Intune o administrador de dispositivos en la nube. Deshabilitar un dispositivo le impide
acceder a los recursos de Entra ID. Tenga en cuenta que esto no impide que el usuario
acceda a los recursos en general; solo evita que el usuario acceda a los recursos desde ese
dispositivo deshabilitado. La Figura 1-6 muestra la opción Desactivar.
FIGURA 1-6 Opción Deshabilitar en la hoja Todos los dispositivos en Azure Portal

Eliminar dispositivos es similar a habilitar o deshabilitar un dispositivo. Nuevamente, el

usuario que realiza la actualización debe ser un administrador global, un administrador de
Intune o un administrador de dispositivos en la nube. Eliminar un dispositivo evita que un
dispositivo acceda a sus recursos de Entra ID y elimina todos los detalles adjuntos al
dispositivo (incluidas las claves de BitLocker para dispositivos Windows). Eliminar un
dispositivo representa una actividad no recuperable y no se recomienda a menos que sea
necesario para una actividad como el desmantelamiento del dispositivo.

Anteriormente, Azure Portal solo era útil para actualizaciones individuales para los
usuarios, lo que significaba que había que depender de soluciones de automatización
personalizadas (principalmente usando PowerShell) para actualizar a los usuarios de forma
masiva. Gracias a las actualizaciones recientes, ahora puede realizar operaciones masivas
(como crear, invitar y eliminar usuarios en lotes) mediante Azure Portal y el centro de
administración de Entra en https://entra.microsoft.com .

Puede acceder a esta funcionalidad navegando hasta su inquilino de Entra en Azure Portal y
luego haciendo clic en Usuarios. Verá estas opciones en la parte superior de la hoja, como
se muestra en la Figura 1-7 .
FIGURA 1-7 Opciones de actualización masiva en la hoja Usuarios de Azure Portal

Al hacer clic en Creación masiva, se abre la hoja Crear usuario en masa, que se muestra
en la Figura 1-8 .

FIGURA 1-8 Hoja Creación masiva de usuarios en Azure Portal

La creación masiva de usuarios es un proceso de tres pasos:

 1. Haga clic en Descargar en la hoja Crear usuario en masa para descargar una
plantilla CSV (valores separados por comas o delimitados por comas)
(UserCreateTemplate.csv). Esta es una plantilla estándar con atributos obligatorios,
como Nombre, Nombre de usuario, Contraseña inicial y Bloquear inicio de sesión.
También puede especificar atributos opcionales como nombre, apellido, puesto de
trabajo, etc.
2. Edite el archivo CSV con valores de actualización masiva. Sólo necesita actualizar
los valores apropiados y guardar los cambios. Los valores obligatorios de muestra
ya están incluidos en la plantilla como referencia.
3. Cargue el archivo CSV actualizado y envíe la operación.

Después de enviar la operación, puede verificar el estado de la operación masiva navegando

a Resultados de la operación masiva en la sección Actividad de la hoja Usuarios
(consulte la Figura 1-9 ).

FIGURA 1-9 Hoja Resultados de operaciones masivas en Azure Portal

Administrar licencias en Microsoft Entra ID

Hay algunos tipos de licencia diferentes disponibles con Entra ID:

 Identificación de Microsoft Entra gratis

 Microsoft EntraID Premium P1
  Microsoft Entra ID Premium P2
 Gobernanza de identificación de Microsoft Entra

Tenga en cuenta que las licencias P1 o P2 se incluyen con otros paquetes y conjuntos de
licencias, como el conjunto Enterprise Mobility + Security. Para poder asignar una licencia
a una cuenta de usuario, primero deben ocurrir dos cosas.

Primero, se debe comprar la licencia y asociarla con el inquilino. Para las pequeñas y
medianas empresas, es posible que pueda hacerlo utilizando los portales de administración
de Entra o Microsoft 365. Para los proveedores de soluciones en la nube y las
organizaciones con acuerdos empresariales, lo más probable es que necesiten hablar con un
representante de cuentas para agregar las licencias a su contrato.

En segundo lugar, la cuenta de usuario a la que planea asignar una licencia debe tener
configurada su propiedad Ubicación de uso. La propiedad Ubicación de uso define el país o
región principal en el que reside o trabaja el usuario y puede determinar si ciertas funciones
de una licencia realmente se pueden utilizar.

Después de comprar las licencias y asegurarse de que sus cuentas de usuario tengan
definida su ubicación de uso, puede asociar las licencias con los usuarios o puede asignar
una licencia según la membresía del grupo. El uso de grupos dinámicos es una excelente
manera de automatizar la administración de licencias en función de las propiedades del
usuario.

Administrar usuarios externos

Para crear usuarios invitados desde Azure Portal, busque su inquilino de Entra como
usuario con derechos para crear usuarios, seleccione la hoja Usuarios, elija Nuevo usuario y
luego seleccione Invitar a usuario externo. En la Figura 1-10 se muestra un ejemplo de esta
hoja . Un usuario invitado puede ser cualquier persona invitada a colaborar con su
organización. Una vez creado, el usuario invitado debería recibir una invitación en su
buzón.
FIGURA 1-10 Hoja Invitar a un usuario externo en Azure Portal

Crear y administrar usuarios invitados es similar a crear y administrar cuentas de usuarios

normales. Los usuarios invitados pueden ser invitados al directorio, grupo o aplicación. Tan
pronto como invite al usuario invitado, esa cuenta se crea en Entra ID con el Tipo de
usuario establecido en Invitado. El usuario invitado recibirá una invitación por correo
electrónico inmediatamente después de la creación. El usuario invitado debe aceptar la
invitación junto con el proceso de consentimiento por primera vez para poder acceder a los
recursos asignados.

De forma predeterminada, todos los usuarios y administradores pueden invitar a invitados.

Puede restringir la forma en que se puede invitar a los usuarios invitados seleccionando
Administrar configuración de colaboración externa en la hoja Usuarios en Configuración de
usuario. La hoja Configuración de colaboración externa se muestra en la Figura 1-11 .
También puede acceder a esta configuración desde el inquilino de Entra haciendo clic en
Configuración de usuario a la izquierda y luego eligiendo Administrar configuración de
colaboración externa en la sección Usuarios externos.
FIGURA 1-11 Hoja Configuración de colaboración externa en Azure Portal

Cuando se agrega un usuario invitado, el estado de consentimiento del usuario invitado

(visible en PowerShell) es PendingAcceptance. Este valor se cambiará a Aceptado
inmediatamente después de que el usuario invitado acepte la invitación. El usuario invitado
aparecerá como "usuario invitado" en Azure Portal hasta que acepte la invitación.

Configurar la unión a Microsoft Entra

Microsoft Entra incluye la capacidad de administrar la identidad del dispositivo, lo que

permite el inicio de sesión único en los dispositivos y las aplicaciones y servicios
administrados a través de Entra a los que se accede desde ese dispositivo. Los dispositivos
administrados incluyen escenarios empresariales y de tipo "traiga su propio dispositivo"
(BYOD). Esto permite a los usuarios trabajar desde cualquier dispositivo, incluidos
dispositivos personales, mientras protege la propiedad intelectual corporativa con los
controles normativos y de cumplimiento necesarios.

Con Entra ID Join, puede controlar estos dispositivos, las aplicaciones instaladas y a las
que se accede desde ellos, y cómo esas aplicaciones interactúan con sus datos corporativos.

Al asociar dispositivos con Entra, tiene tres opciones: Registrar un dispositivo, Unirse a un
dispositivo y Usar unión híbrida. Registrar dispositivos sería apropiado para dispositivos
personales, mientras que unir dispositivos es útil para dispositivos de propiedad
corporativa. Los dispositivos unidos híbridos se unen a su Active Directory local y se
registran con su inquilino de Entra ID.

Cuando asocia un dispositivo con Entra ID, puede administrar la identidad de un

dispositivo implementando funciones como el inicio de sesión único (SSO) y asegurando el
acceso mediante acceso condicional. Tenga en cuenta que esta identidad se puede
administrar independientemente de la identidad de un usuario. Esto proporciona un gran
grado de flexibilidad porque los dispositivos se pueden habilitar o deshabilitar sin afectar la
cuenta de usuario. Entra ID Join es una extensión del registro del dispositivo que cambia el
estado local del dispositivo. Cuando un dispositivo está unido a Entra, los usuarios pueden
iniciar sesión en el dispositivo utilizando una cuenta organizacional en lugar de una cuenta
personal.

Además, el registro de dispositivos en Entra se puede combinar con una solución de

administración de dispositivos móviles, como Microsoft Intune, Microsoft Endpoint
Configuration Manager, Mobile Application Management (MAM) y Group Policy si está
unido de forma híbrida. Esto permite rastrear atributos adicionales del dispositivo, como la
versión del sistema operativo del dispositivo y el estado del dispositivo (incluido si el
dispositivo está rooteado o liberado) en Entra ID. Luego, esos atributos se pueden utilizar
para crear y aplicar políticas de acceso condicional, que pueden proteger aún más los datos
corporativos.

Para configurar el registro del dispositivo en Entra ID, elija Dispositivos, Configuración del
dispositivo. En la hoja Configuración del dispositivo, puede establecer la configuración
para un inquilino de Entra ID completo, como se ve en la Figura 1-12 .
FIGURA 1-12 Configurar los ajustes de registro del dispositivo

En esta hoja, puede configurar los siguientes ajustes:

 Los usuarios pueden unir dispositivos a Microsoft Entra Utilice esta

configuración para seleccionar los usuarios y grupos que pueden unir dispositivos a
Entra. Esta configuración solo se aplica a Entra Join en dispositivos con Windows
10 o Windows 11. El valor predeterminado es Todo y se puede cambiar a
Seleccionado o Ninguno.
 Administradores locales adicionales en dispositivos unidos a Microsoft
Entra Con Entra ID Premium o con la suite Enterprise Mobility + Security, puede
elegir a qué usuarios se les otorgan derechos de administrador local para el
dispositivo. A los administradores globales y al propietario del dispositivo se les
conceden derechos de administrador local de forma predeterminada. El valor
predeterminado es Ninguno y se puede cambiar a Seleccionado. Si el valor se
establece en Seleccionado, todos los usuarios agregados aquí también se agregan a
la función de Administradores de dispositivos en Entra ID.
 Los usuarios pueden registrar sus dispositivos con Microsoft Entra Permitir que
los usuarios registren sus dispositivos con Microsoft Entra (Workplace Join). La
inscripción en Microsoft Intune o Mobile Device Management para Office 365
 requiere el registro del dispositivo. Si ha configurado cualquiera de estos servicios,
se seleccionará Todos y el botón asociado con la configuración se desactivará.
 Requerir autenticación multifactor para unir dispositivos Se recomienda la
autenticación multifactor (MFA) al agregar dispositivos a Entra. Cuando se
establece en Sí, los usuarios que agregan dispositivos desde Internet deben usar
primero un segundo método de autenticación. Antes de habilitar esta configuración,
debe asegurarse de que la autenticación multifactor esté configurada para los
usuarios que pueden registrar dispositivos y que esos usuarios hayan configurado
MFA.
 Número máximo de dispositivos por usuario Esta configuración designa el
número máximo de dispositivos que un usuario individual puede tener en Entra ID.
Si se alcanza la cuota, el usuario no podrá agregar un dispositivo hasta que se
elimine uno de sus dispositivos existentes. Los valores válidos para esta
configuración son 5, 10, 20, 50, 100 e Ilimitado.

Nota Dispositivos híbridos unidos entre sí

Las configuraciones Requerir autenticación multifactor y Número máximo de dispositivos

por usuario no se aplican a los dispositivos híbridos unidos a Entra.

Una vez configurado el directorio, puede comenzar a registrar dispositivos. Para Entra Join,
existen varios requisitos para los dispositivos, incluidas las versiones de Windows. Los
requisitos para las versiones de Windows dependen del tipo de Entra Join: híbrido o no
híbrido. Entra Join no híbrido se aplica a dispositivos que no están unidos a un Active
Directory local, mientras que Entra Join híbrido se aplica a dispositivos que están unidos a
un directorio local. Para Entra Join híbrido, un administrador de TI debe realizar la unión a
Entra ID.

Para Entra Join no híbrido, los dispositivos Windows 10 y Windows 11 Professional, así
como los dispositivos Windows 10 y Windows 11 Enterprise, se pueden unir a un
directorio. Para escenarios híbridos de Entra Join, puede unir dispositivos Windows
actuales, como Windows 11 y Windows Server 2016. Además, hay soporte para una unión
híbrida con dispositivos de nivel inferior, incluidos Windows 7, Windows 8.1, Windows
Server 2008, Windows Server. 2008 R2, Windows Server 2012 y Windows Server 2012
R2.

Configurar el restablecimiento de contraseña de autoservicio

El restablecimiento de contraseña es una de las actividades que genera mayores costos para
muchas organizaciones, y muchas organizaciones cuentan con mesas de ayuda de primera
línea dedicadas a manejar dichas solicitudes. El restablecimiento de contraseña de
autoservicio (SSPR) permite a los usuarios restablecer sus propias contraseñas en Microsoft
Entra ID, incluida la capacidad de volver a escribir la contraseña en un entorno local
cuando tienen la licencia y la configuración adecuadas mediante la escritura de contraseña
y Entra Connect o Entra Connect. Sincronización. SSPR permite a los usuarios cambiar sus
contraseñas, restablecerlas cuando no pueden iniciar sesión y desbloquear sus cuentas, todo
sin la intervención de un departamento de TI.

Cada escenario anterior se dirige tanto a usuarios híbridos como solo a la nube. Además,
los requisitos de licencia varían. La Tabla 1-1 detalla cada escenario, el tipo de usuario al
que se aplica y las licencias requeridas.

TABLA 1-1 Requisitos de licencia de restablecimiento de contraseña de autoservicio

Tipo de
Guión Requisitos de licencia
usuario

Cambio de contraseña Usuario Incluido en todos los tipos

solo en la de licencia de Entra ID
nube

Restablecimiento de contraseña Usuario Microsoft 365 Empresa

solo en la Estándar, Microsoft 365
nube Empresa Premium, Entra ID
P1, Entra ID P2

Cambio de Usuario Microsoft 365 Empresa

contraseña/Desbloqueo/Restablecimiento híbrido Premium, Entrada ID P1,
Entrada ID P2

SSPR se puede habilitar a través de Azure Portal navegando hasta su inquilino de Entra y
seleccionando Restablecer contraseña. Al habilitar SSPR, puede limitar la funcionalidad a
un grupo, lo que le permitirá implementar la función en oleadas a medida que los usuarios
se incorporan al servicio. Como parte de la configuración, también seleccionará los
métodos de autenticación para SSPR: notificación de aplicación móvil, código de
aplicación móvil, correo electrónico, teléfono móvil, teléfono de oficina y/o preguntas de
seguridad (como se muestra en la Figura 1-13 ). Finalmente, utilizando la hoja Registro,
configurará opciones de registro, como si es necesario registrarse para usar SSPR y la
cantidad de días para la reconfirmación.
FIGURA 1-13 Configurar métodos de autenticación SSPR

Además, también puede controlar cómo se activan las notificaciones para los usuarios y
administradores mediante la hoja Notificaciones. Hay una opción disponible para
personalizar un enlace del servicio de asistencia técnica para notificar al administrador
directamente, que se puede configurar mediante la hoja Personalización. Si la integración
local está habilitada, también puede controlar las contraseñas de reescritura en su directorio
local y permitir a los usuarios desbloquear cuentas sin restablecer sus contraseñas mediante
la hoja Integración local.

¿Necesita más revisión? Reescritura de restablecimiento de contraseña de autoservicio

Puede encontrar detalles sobre la reescritura de autoservicio para restablecer contraseñas
utilizando el siguiente enlace: https://learn.microsoft.com/en-
us/entra/identity/authentication/concept-sspr-writeback .

Habilidad 1.2: Administrar el acceso a los recursos de Azure

El control de acceso en Microsoft Azure es una parte importante de los requisitos de

seguridad y cumplimiento de una organización. La implementación del control de acceso
basado en roles (RBAC) define los derechos de acceso a un nivel muy granular, en función
de las tareas asignadas a cada usuario o las actividades diarias que esos usuarios deben
realizar en sus roles. Esto asegura que cada persona pueda realizar la tarea que necesita
realizar.

Esta habilidad cubre cómo:

 Entender cómo funciona RBAC

 Crear un rol personalizado
 Interpretar asignaciones de acceso
 Administrar múltiples directorios

Entender cómo funciona RBAC

El control de acceso basado en roles (RBAC) facilita la administración del acceso a los
recursos de Azure por parte de entidades denominadas entidades principales de seguridad,
además de controlar qué acciones pueden realizar esas entidades. Además de determinar
quién puede hacer qué, en Azure, se puede otorgar acceso a usuarios, grupos, entidades de
servicio e identidades administradas a través de asignaciones de roles, que luego se aplican
en un ámbito, como un grupo de administración, una suscripción o un grupo de recursos. , o
incluso un recurso individual. Azure RBAC es aplicable a la administración de recursos
creados en el modelo de implementación de Azure Resource Manager (ARM).

Un rol es la definición de qué acciones están permitidas y/o denegadas. RBAC se configura
seleccionando una función y asociándola con una entidad de seguridad, como un usuario,
grupo o entidad de servicio. Luego, esta combinación de función y entidad de seguridad se
aplica a un ámbito de un grupo de administración, suscripción, grupo de recursos o recurso
específico mediante una asignación de funciones.

Azure RBAC también incluye herencia de roles, donde los recursos secundarios heredan las
asignaciones de roles de los padres. Por ejemplo, si a un usuario se le concede acceso de
lector a una suscripción, ese usuario tendrá acceso de lector a todos los grupos de recursos
y recursos de esa suscripción. Si a una identidad administrada se le otorgan derechos de
Colaborador para un único grupo de recursos, esa entidad de seguridad solo puede
interactuar con ese grupo de recursos y sus recursos secundarios, pero no puede crear
nuevos grupos de recursos ni acceder a recursos en otros grupos de recursos a menos que se
realice una asignación de roles explícita. .
Azure RBAC usa el modelo aditivo. A medida que comienza a aplicar roles a las entidades
principales de seguridad en Azure, no es raro tener asignaciones superpuestas en las que a
una entidad de seguridad se le asigna una asignación de roles diferente en el ámbito
principal y secundario. Por ejemplo, si a un usuario se le conceden derechos de
Colaborador en el ámbito del grupo de administración y luego se le conceden derechos de
Lector en una suscripción, el usuario seguirá teniendo derechos de Colaborador en toda la
suscripción junto conDerechos del contribuyente a cualquier otra suscripción bajo el grupo
de gestión. Otra forma de pensar en esto es que el derecho de acceso más privilegiado tiene
prioridad.

Antes de que una entidad de seguridad, como un usuario o un grupo, pueda interactuar con
los recursos de Azure, se le debe conceder acceso en un ámbito mediante una asignación de
roles. Una vez que se le ha concedido acceso a una entidad de seguridad, puede realizar
cualquier acción para la que tenga derecho a realizar. Siempre se recomienda proporcionar
los privilegios mínimos a un objeto o usuario para realizar las acciones necesarias. La
Figura 1-14 muestra un patrón de acceso sugerido que se adhiere a los principios de
privilegio mínimo. En este ejemplo, a un grupo de seguridad en Entra ID, llamado
Auditoría de TI, se le otorgan derechos de acceso de lector en el alcance de la suscripción,
lo que otorga a los miembros del grupo acceso de lector a todos los grupos de recursos y
recursos de la suscripción. A un grupo de seguridad llamado Administradores de
aplicaciones se le otorgan derechos de acceso de colaborador solo a grupos de recursos
seleccionados. A otro grupo de seguridad llamado Propietarios de aplicaciones también se
le otorgan derechos de acceso de propietario a grupos de recursos seleccionados. Al utilizar
múltiples grupos de seguridad y asignaciones de roles en el alcance adecuado, se puede
otorgar acceso en el futuro simplemente actualizando la membresía del grupo de seguridad
en Entra ID.

FIGURA 1-14 Asignaciones de roles de Azure RBAC

Importante uso de grupos con Azure RBAC

Las definiciones de roles RBAC están asociadas con un usuario, grupo, entidad de servicio
o identidad administrada mediante una asignación de roles. Al asignar roles a un grupo,
todos los usuarios del grupo heredarán el rol asignado. Puede asignar roles a un grupo para
una administración más sencilla y una mayor flexibilidad al aplicar RBAC a escala.

Los permisos específicos que se aplican a un recurso con RBAC se definen en una
definición de rol. Una definición de rol contiene la lista de permisos (o permisos
declarados) y esos permisos definen qué acciones se pueden o no realizar contra un tipo de
recurso, como leer, escribir o eliminar.

Las definiciones de roles, o roles, pueden ser integrados o personalizados. Hay varias
definiciones de roles integradas en Azure. Un ejemplo de función integrada es la función de
Propietario, que incluye permisos para administrar recursos, seguridad y la aplicación de
asignaciones de funciones. También hayRoles integrados con conjuntos de permisos
limitados, como un lector de datos de Storage Blob, que permite que la entidad de
seguridad asignada solo lea y enumere contenedores y blobs.

Hay muchas funciones integradas en Azure, que se pueden encontrar

en https://docs.microsoft.com/azure/role-based-access-control/built-in-roles . Microsoft
agrega nuevos roles integrados a medida que los servicios evolucionan o se introducen
nuevos servicios.

Funciones importantes de Azure y funciones de Entra ID

Las funciones de RBAC son diferentes de las funciones administrativas de Entra ID. Los
roles RBAC se usan para administrar el acceso y permitir o restringir a los usuarios los
recursos de Azure, mientras que los roles administrativos de Entra ID se usan para permitir
o restringir que los administradores realicen tareas de identidad, como crear nuevos
usuarios, restablecer las contraseñas de los usuarios, etc. Por ejemplo, un usuario al que se
le otorgan derechos de administrador global en Entra ID no tiene permisos para crear
recursos en Azure, pero puede realizar todas las tareas de identidad para un inquilino de
Entra.

Los derechos de acceso se controlan con un límite lógico conocido como alcance. Por
ejemplo, para otorgar a un usuario derechos de Colaborador sobre todos los recursos de un
grupo de recursos, el rol de Colaborador se puede asignar al grupo en el ámbito del grupo
de recursos, donde luego lo heredan todos los recursos del grupo de recursos.

Hay cuatro ámbitos en los que se puede aplicar RBAC y los ámbitos están estructurados en
una relación padre-hijo donde RBAC es heredado por cualquier ámbito secundario. El
ámbito más alto, o ámbito principal más alto, es un grupo de administración.

Consejo de examen
Los grupos de administración no se aplican en todos los escenarios y, en algunos casos, una
suscripción será el ámbito más alto con el que trabajará al aplicar asignaciones de roles.
Esto estará determinado por el sello de implementación de la zona de aterrizaje de Azure de
su organización.

Bajo el grupo de administración hay más grupos de administración y/o suscripciones; bajo
suscripciones están los grupos de recursos; y en grupos de recursos están los recursos. La
Figura 1-15 muestra una jerarquía de ejemplo con un grupo de administración principal y
dos suscripciones, cada una con un grupo de recursos y recursos secundarios. Tenga en
cuenta que también puede crear otro grupo de administración en un grupo de
administración raíz. Un inquilino de Entra ID puede admitir hasta 10 000 grupos de gestión.

Herencia importante de RBAC

El concepto de herencia RBAC es fundamental. Otorgar a un usuario acceso a la función de

Propietario en el alcance del grupo de administración le otorgará a ese usuario derechos de
Propietario sobre todos los recursos (grupos de administración, suscripciones, grupos de
recursos y recursos) bajo el grupo de administración que incluye todos los grupos de
recursos y recursos dentro. a ellos.

FIGURA 1-15 Jerarquía de alcance

Una vez que haya identificado la función, la entidad de seguridad y el ámbito en el que se
asignará la función, puede realizar la asignación. Recuerde, las entidades de seguridad no
tienen acceso a los recursos de Azure hasta que se realiza una asignación de roles, y ese
acceso se puede revocar eliminando una asignación de roles.

Límites importantes en la asignación de roles

Puede tener hasta 4000 asignaciones de roles en cada suscripción y puede tener hasta 500
asignaciones de roles por grupo de administración. Estos límites son independientes entre sí
y se han ido ajustando con el tiempo. Consulte las cuotas y límites más recientes
en https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/azure-
subscription-service-limits .

Para crear y eliminar asignaciones de roles, debe tener el permiso

Microsoft.Authorization/roleAssignments/* en el ámbito necesario. Este permiso se otorga
a través de los roles integrados de Propietario o Administrador de acceso de usuario, o
puede incluirse en roles personalizados.

Nota Asignaciones de roles de Azure

Con las asignaciones de roles de Azure, no hay forma de revocar los derechos de acceso en
un ámbito secundario mediante la aplicación de una asignación de roles más restrictiva
porque la asignación de roles se hereda del primario. Sin embargo, es posible aplicar una
asignación de denegación en un ámbito cuando se utilizan Azure Blueprints, Deployment
Stacks y bloqueos de recursos. Las asignaciones de denegación se evalúan antes de las
asignaciones de roles y se pueden usar para excluir a las entidades de servicio del acceso a
ámbitos secundarios. Para obtener más información,
consulte https://learn.microsoft.com/en-us/azure/governance/blueprints/tutorials/protect-
new-resources .

Crear un rol personalizado

Además de los roles integrados disponibles en Azure, es posible que necesite crear un rol
personalizado para proporcionar un conjunto de permisos que no están disponibles en
ninguno de los roles integrados. Se pueden crear y asignar roles personalizados a través de
Azure Portal, Azure PowerShell, la CLI de Azure y la API REST. Este capítulo cubre
principalmente cómo crear un rol personalizado mediante Azure Portal.

Roles personalizados importantes

Se pueden compartir roles personalizados entre suscripciones que confían en el mismo

directorio de Entra ID. Hay un límite de 5000 roles personalizados por directorio, aunque
Azure China operado por 21Vianet puede tener hasta 2000 roles personalizados para cada
directorio.

Hay tres formas de crear roles personalizados en Azure Portal:

 Clonar a partir de los roles integrados existentes disponibles

  Empezar desde el principio
 Comience desde un archivo JSON para definir los permisos personalizados

Para clonar una función integrada, abra la hoja Control de acceso (IAM) accediendo a una
suscripción o grupo de recursos y luego eligiendo Agregar, Agregar función personalizada,
como se muestra en la Figura 1-16 .

FIGURA 1-16 Opción Agregar función personalizada en la hoja Control de acceso (IAM)

En la hoja Crear una función personalizada, junto a Permisos de referencia, seleccione

Clonar una función. A continuación, en el menú desplegable Función a clonar, seleccione la
función deseada, como Colaborador de máquina virtual, como se muestra en la Figura 1-
17 . Puede seleccionar el rol con los permisos idénticos más cercanos de los roles
integrados.
FIGURA 1-17 Creación de un rol personalizado

Haga clic en Siguiente para abrir la pestaña Permisos, como se muestra en la Figura 1-18 .
Esta pestaña muestra todos los permisos asociados con el rol integrado que seleccionó en la
pestaña Básicos.
FIGURA 1-18 Agregar o excluir permisos al crear una función personalizada

Cuando hace clic en Agregar permisos, puede buscar entre todos los diferentes permisos
disponibles en el catálogo. Por ejemplo, escriba máquina virtual , como se muestra en la
Figura 1-19 . Puede seleccionar Microsoft Compute para acceder a las operaciones
disponibles para este proveedor de recursos.

Operaciones importantes del proveedor de ARM Resource Manager

Para explorar todas las operaciones disponibles para cada proveedor de recursos de Azure
Resource Manager, consulte https://docs.microsoft.com/en-us/azure/role-based-access-
control/resource-provider-operatives .

FIGURA 1-19 Agregar el permiso Compute de Microsoft

Una vez que seleccione Microsoft Compute, puede seleccionar permisos específicos en las
pestañas Acciones y Acciones de datos. La pestaña Acciones contiene las operaciones que
puede realizar un rol y la pestaña Acciones de datos contiene las operaciones que un rol
puede realizar en los datos dentro de un objeto. De manera similar, si desea excluir
permisos (que se muestran anteriormente en la Figura 1-18 ), las pestañas Sin acciones y
Sin acciones de datos contienen una lista de permisos que puede agregar al rol que no está
permitido realizar según la selección ( ver Figura 1-20 ).
FIGURA 1-20 Lista de permisos en la pestaña Acciones

Después de seleccionar los permisos necesarios, debe seleccionar Agregar ámbitos

asignables para definir un ámbito para este rol personalizado. El alcance se puede definir
como grupo de gestión, suscripción, grupo de recursos o nivel de recursos. La función
personalizada debe tener al menos un alcance válido asignado (consulte la Figura 1-21 ).
FIGURA 1-21 Selección de ámbitos asignables al crear un rol personalizado

Seleccione Siguiente o la pestaña JSON para mostrar el código JSON (notación de objetos
JavaScript) según la selección realizada en las pantallas anteriores. Este código se puede
descargar como un archivo .json o se puede copiar para reutilizarlo más adelante. Puede
continuar con la pestaña Revisar + Crear para crear el rol personalizado (consulte la Figura
1-22 ).
FIGURA 1-22 Vista JSON al crear un rol personalizado

Se puede acceder a los roles personalizados recién creados desde la pestaña Roles
(consulte la Figura 1-23 ). Los roles personalizados aparecen en Azure Portal con un icono
de recurso naranja.
FIGURA 1-23 Selección de roles al crear un rol personalizado

Alternativamente, los roles integrados se pueden clonar seleccionando un rol en la pestaña

Roles. Por ejemplo, puede seleccionar Colaborador de máquina virtual, hacer clic en los
puntos suspensivos (...) y luego seleccionar Clonar (consulte la Figura 1-24 ).

FIGURA 1-24 Clonación de un rol

Permiso importante requerido para crear un rol personalizado

Para crear una función personalizada, debe tener el permiso

Microsoft.Authorization/roleDefinitions/write en todos los AssignableScopes.

También puede crear una función personalizada eligiendo Empezar desde cero en Permisos
básicos. Esta opción puede llevar mucho tiempo porque necesita seleccionar todos los
permisos, uno por uno, para crear una función personalizada desde cero.

De manera similar, se pueden definir roles personalizados utilizando un archivo JSON

seleccionando Iniciar desde JSON en Permisos de referencia. El archivo JSON contiene las
definiciones de roles:

 Un nombre representado por el atributo Nombre.

 Un identificador representado por el atributo Id.
 Una descripción representada por el atributo Descripción.

Un indicador que indica si el rol es personalizado o integrado está representado por el

atributo IsCustom, que se establece en falso para los roles integrados; esto debe
establecerse en verdadero al crear roles personalizados.

Las acciones que se pueden o no realizar dentro del plano de administración de Azure están
representadas por los atributos Actions[] y NotActions[], respectivamente.

Opcionalmente, los ámbitos en los que el rol está disponible a través del atributo
AssignableScopes[].

Interpretar asignaciones de acceso

Para administrar las asignaciones de acceso (rol), puede usar Azure Portal, la CLI de Azure,
Azure PowerShell, los SDK de Azure o las API REST de Resource Manager. En la
siguiente sección se describe cómo administrar las asignaciones de roles mediante Azure
Portal.

En Azure Portal, la hoja Control de acceso (IAM) se usa para administrar el acceso a los
recursos y es donde se aplican o eliminan las asignaciones de roles. La hoja Control de
acceso (IAM) está disponible en cualquier ámbito donde se puedan realizar asignaciones de
roles (grupo de administración, suscripción, grupo de recursos y recurso). Para encontrar la
hoja Control de acceso (IAM), navegue hasta el recurso o servicio donde desea administrar
las asignaciones de roles.

En el siguiente ejemplo, la función integrada de Colaborador de máquina virtual se asignará

a un usuario en el ámbito del grupo de recursos.
En Azure Portal, navegue hasta un grupo de recursos seleccionando Grupos de recursos a la
izquierda, seleccionando un grupo de recursos y luego seleccionando la hoja Control de
acceso (IAM).

Desde la hoja de Control de acceso (IAM), puede

 Verifique los derechos de acceso efectivos para una entidad de seguridad en el

alcance actual a través de la pestaña Verificar acceso, donde también puede ver los
derechos de acceso heredados de un alcance principal.
 Edite asignaciones de roles, otorgando y revocando derechos de acceso a través de
la pestaña Asignaciones de roles
 Vea las asignaciones denegadas, que están controladas por Microsoft, a través de la
pestaña Denegar asignaciones
 Ver y administrar permisos para recursos clásicos a través de la pestaña
Administradores clásicos
 Vea los roles disponibles, tanto integrados como personalizados, a través de la
pestaña Roles

Asignaciones de denegación importantes en IAM Blades

La pestaña Denegar asignaciones de la hoja Control de acceso (IAM) no se puede utilizar

para realizar o modificar asignaciones denegadas. Las asignaciones de denegación se
establecen y controlan mediante la aplicación de un bloqueo de recursos o mediante el uso
de pilas de implementación. Para obtener más información sobre las pilas de
implementación, visite https://learn.microsoft.com/en-us/azure/azure-resource-
manager/bicep/deployment-stacks .

Para crear una asignación de roles, navegue hasta la pestaña Asignaciones de roles y haga
clic en Agregar, como se muestra en la Figura 1-25 .

FIGURA 1-25 Pestaña Asignaciones de roles en la hoja Control de acceso (IAM)

Después de hacer clic en Agregar, seleccione Agregar asignación de roles, como se muestra
en la Figura 1-26 .

FIGURA 1-26 Agregar asignación de roles

En la hoja Agregar asignación de roles, hay tres pestañas: Rol, Miembros y Revisar +
Asignar. La pestaña Rol enumera los roles como roles de función laboral o roles de
administrador privilegiados. Seleccione la función en la pestaña Función que planea asignar
y luego, en la pestaña Miembros, seleccione el usuario, grupo, entidad de seguridad o
identidad administrada a la que desea asignar la función. Haga clic en Revisar + Asignar
cuando haya terminado. La Figura 1-27 muestra un ejemplo en el que al
usuario, [email protected] , se le otorga acceso al rol de Colaborador de máquina
virtual. En el directorio de ejemplo, se devolvieron dos principales de seguridad de la lista
filtrada utilizando el término de búsqueda "Usuario" (Usuario de VM y Usuario de
demostración). Se seleccionó un único principal (usuario de demostración) (que se muestra
en Miembros seleccionados) para aplicar a la asignación de rol de colaborador de máquina
virtual.
FIGURA 1-27 Seleccionar miembros

Después de hacer clic en Revisar + Asignar, verá la asignación de roles en la pestaña

Asignaciones de roles. Para eliminar una asignación de roles, seleccione una o más
entidades principales de seguridad y haga clic en Eliminar. En la Figura 1-28 se muestra un
ejemplo .
FIGURA 1-28 Eliminar una asignación de roles

Administrar múltiples directorios

Cada inquilino (o directorio) de Entra ID se administra como un recurso independiente. No

existe una relación padre-hijo entre directorios, aunque los usuarios de un directorio pueden
ser invitados a otro directorio a través de las funciones de identidades externas de Entra.

Dado que cada inquilino es un recurso independiente, los directorios se pueden crear y
eliminar según sea necesario. Esto también significa que cada directorio puede tener
administradores y asignaciones de roles independientes. Eliminar un directorio existente
puede afectar los recursos fuera del directorio. Por ejemplo, al eliminar un directorio donde
hay usuarios externos, esos usuarios ya no podrán acceder a ninguna aplicación o recurso
que se haya compartido con ellos.

Finalmente, cada directorio también se puede sincronizar de forma independiente. Esto

significa que si tiene dos dominios locales que deben sincronizarse con dos inquilinos de
Entra ID diferentes, tiene la flexibilidad que necesita al implementar la identidad híbrida
con Entra.

Organizaciones importantes de Entra y suscripción a Azure

No existe una relación padre-hijo entre las organizaciones de Entra ID y una suscripción de
Azure. Si su suscripción se cancela o ya no es válida, aún puede acceder a su inquilino de
Entra mediante el centro de administración de Microsoft 365 o PowerShell. Además, puede
agregar otra suscripción a la organización existente más adelante.

La gestión de directorios puede incluir la eliminación de directorios o incluso de un

inquilino completo de Entra ID. Para eliminar un inquilino, se requieren derechos de
administrador global. Cuando se elimina un directorio, también se eliminan todos los
recursos u objetos dentro de ese directorio.

Hay varios requisitos previos que deben cumplirse antes de eliminar un directorio:

 No hay usuarios ni grupos existentes excepto el administrador global único.

 No hay registros de aplicaciones empresariales en el directorio.
 No hay proveedores de MFA vinculados al directorio.
 No hay suscripciones para Azure, Microsoft 365 u otros servicios Microsoft SaaS
asociados con el directorio.

Habilidad 1.3: Administrar suscripciones y gobierno de Azure

Una suscripción a Azure, que constituye el núcleo de un entorno de Azure, es un

componente fundamental de cada implementación de Azure. Cada recurso que crea en
Azure reside en una suscripción de Azure, que es un límite de facturación para los recursos
de Azure con controles de acceso basados en roles por recurso.

A medida que crea e implementa servicios en Azure, creará muchos tipos de recursos. Por
ejemplo, al crear su primera máquina virtual, también implementará muchos otros recursos,
incluidos

 Un disco para el sistema operativo.

 Una interfaz de red para la VM
 Una red virtual y una subred para que esa interfaz de red se vincule
 Un grupo de seguridad de red (en una configuración de portal predeterminada)

Es importante comprender que muchos servicios en Azure crean múltiples recursos y la

forma en que administre esos recursos dependerá de la política organizacional y el ciclo de
vida de su infraestructura hospedada en Azure.

Esta habilidad cubre cómo:

 Configurar políticas de Azure

 Configurar bloqueos de recursos
 Aplicar y administrar etiquetas en recursos
 Administrar grupos de recursos
 Administrar suscripciones de Azure
 Configurar grupos de administración
 Configurar la gestión de costes
Un recurso en Azure es una instancia de servicio único, que puede ser una máquina virtual,
una red virtual, una cuenta de almacenamiento o cualquier otro servicio de Azure
(consulte la Figura 1-29 ).

FIGURA 1-29 Recurso de Azure

Los grupos de recursos son agrupaciones lógicas de recursos o aquellas instancias de

servicio único ( Figura 1-30 ).

FIGURA 1-30 Jerarquía de Azure

Cada recurso en Azure solo puede existir en un grupo de recursos y no se puede cambiar el
nombre de los grupos de recursos. No hay limitaciones en cuanto a los tipos de recursos
que pueden estar contenidos lógicamente dentro de un grupo de recursos, ni tampoco hay
limitaciones en las regiones en las que deben residir los recursos cuando están en un grupo
de recursos.

La Figura 1-31 muestra esta jerarquía dentro de una suscripción de Azure, varios grupos de
recursos y los recursos que residen dentro de esos grupos de recursos.

FIGURA 1-31 Jerarquía de Azure

Configurar políticas de Azure

Azure Policy es un servicio de Azure que se puede usar para crear, asignar y administrar
políticas que aplican la gobernanza en su entorno de Azure. Esto incluye la aplicación de
reglas que permiten o niegan un tipo de recurso determinado, aplican etiquetas
automáticamente e incluso hacen cumplir la soberanía de los datos. Azure RBAC y Azure
Policy suelen usarse en combinación. Mientras que Azure RBAC controla el acceso de
usuarios individuales, el acceso de grupo y los derechos a sus entornos de Azure en un
ámbito específico, Azure Policy proporciona un mecanismo para expresar cómo se
gobierna el entorno para todos los usuarios en un ámbito específico, independientemente de
las asignaciones de RBAC. Otra forma de decir esto es que Azure RBAC es un mecanismo
de denegación predeterminado con un mecanismo de autorización explícito, mientras que la
política es un mecanismo de autorización predeterminado con un sistema de denegación
explícito.

Para implementar una política, primero se debe crear una definición de política. Luego, a
esa definición de política se le asigna un alcance específico mediante una asignación de
política. Recuerde que el alcance se refiere a a qué está asignada su política con alcances
válidos, un grupo de administración, una suscripción, un grupo de recursos o un recurso.
Las definiciones de políticas también se pueden empaquetar usando definiciones de
iniciativa y aplicar a un alcance usando asignaciones de iniciativa. Tanto las definiciones de
políticas como de iniciativas admiten conjuntos de parámetros, que ayudan a simplificar la
reutilización de una política en múltiples ámbitos.

Una definición de política describe el comportamiento deseado para los recursos de Azure
en el momento en que se crean o actualizan los recursos. A través de una definición de
política, usted declara qué recursos y características de recursos se consideran compatibles
dentro de su entorno de Azure y qué debe suceder cuando un recurso no cumple. Por
ejemplo, puede crear una política que establezca que solo se pueden crear recursos en las
regiones Este de EE. UU. y Oeste de EE. UU. para una suscripción completa. Si un usuario
intenta crear un recurso en el este de EE. UU. 2, Azure Policy puede denegar la creación
del recurso porque no cumple con el objetivo de cumplimiento establecido para las regiones
permitidas. En este ejemplo, la Política se utiliza para negar la creación de un recurso y
hacer cumplir los estándares organizacionales. A medida que explore más a fondo la
Política, aprenderá que la Política se puede utilizar no solo como un mecanismo de
denegación sino también como un mecanismo de auditoría y creación.

Las definiciones de políticas se crean en JSON. El esquema de Azure Policy se puede

descargar desde https://schema.management.azure.com/schemas/2020-10-
01/policyDefinition.json . Una definición de política contiene estos elementos:

 Modo
 Parámetros
 Nombre para mostrar
 Descripción
 Metadatos
 Regla de política
 Evaluación lógica
 Efecto

Nota Definición de política

Si bien no es necesario memorizar el esquema, vale la pena comprender los elementos de

una definición de política y cómo crear sus propias políticas a partir de una plantilla en
blanco cuando sea necesario. Microsoft ofrece una serie de definiciones de políticas
integradas y mantiene un repositorio de ejemplos en https://learn.microsoft.com/en-
us/azure/governance/policy/samples/ y https://github.com/Azure/ azure-
policy/tree/master/samples .

Las definiciones de políticas se pueden crear a través de Azure Portal navegando hasta el
servicio de políticas en Todos los servicios y luego eligiendo Política, Definiciones. Desde
esta hoja, puede administrar tanto las políticas integradas como cualquier política
personalizada que cree. La Figura 1-32 muestra una lista de las políticas integradas para la
suscripción seleccionada.
FIGURA 1-32 Políticas integradas de Azure

Tenga en cuenta que la política también se puede gestionar y aplicar en el ámbito del grupo
de gestión. Al asociar políticas con grupos de administración, las definiciones y
asignaciones de políticas se pueden compartir entre varias suscripciones. Esto incluye la
capacidad de monitorear el cumplimiento de múltiples suscripciones. También le permite
asegurar la gestión de la política de toda la organización en un nivel superior a una
suscripción única.

Al administrar grupos de recursos (y en muchos casos los múltiples servicios de Azure que
residen dentro de ellos), se puede usar Azure Policy con definiciones y asignaciones de
políticas para gobernar esos recursos. Las definiciones de iniciativa y las asignaciones de
iniciativas se pueden usar para gobernar esos mismos recursos, pero en lugar de aplicar
múltiples definiciones de políticas y realizar múltiples asignaciones de políticas, puede
empaquetar o agrupar múltiples definiciones en una sola iniciativa y luego asignar esa
iniciativa al alcance deseado.

El control de los grupos de recursos con Azure Policy se realiza determinando el alcance de
la asignación de políticas e iniciativas. Recuerde que Azure Policy admite varios ámbitos:

 Grupo de administración Las asignaciones con alcance en el grupo de

administración (ya sea el grupo raíz de inquilinos o un grupo secundario) se aplican
a todos los recursos secundarios en el grupo de administración, incluidos los grupos
de administración secundarios, todas las suscripciones, los grupos de recursos y los
recursos.
 Las asignaciones de suscripción con ámbito de suscripción se aplican a todos los
recursos secundarios en los recursos y grupos de recursos de la suscripción.
  Grupo de recursos Las asignaciones con alcance a un grupo de recursos se aplican
a todos los recursos secundarios del grupo de recursos.

Al crear asignaciones, también es posible configurar ámbitos excluidos. Siempre puedes

excluir un subámbito. Por ejemplo, al determinar el alcance de una asignación a un grupo
de administración, se pueden excluir todas las suscripciones, grupos de recursos o incluso
recursos que sean secundarios del grupo de administración. Al determinar el alcance de una
asignación a una suscripción, se pueden excluir los recursos y los grupos de recursos
secundarios. Al determinar el alcance de una asignación a un grupo de recursos, solo se
pueden excluir los recursos secundarios.

La flexibilidad del alcance de las políticas es una característica poderosa de Azure Policy.
Esto le permite modelar sus entornos con declaraciones enriquecidas en forma de
definiciones de políticas que se aplican exactamente según lo requieren las necesidades de
gobierno de su organización.

Imagine que tiene un entorno con los siguientes requisitos:

 Todos los recursos deben etiquetarse con la etiqueta "Entorno" y el valor

"Desarrollo/Prueba".
 Solo se pueden crear máquinas virtuales Serie A y Serie D, específicamente
máquinas virtuales Estándar A0, A1 y D2 que no son promocionales.
 Los recursos del grupo de recursos rgCoreNetwork están exentos de estas políticas.

Para modelar este entorno con Azure Policy, puede crear dos definiciones de políticas (o
usar definiciones de políticas integradas cuando corresponda), como se muestra en la Tabla
1-2 .

TABLA 1-2 Ejemplo de definiciones de Azure Policy

Campo de Efecto de la
Descripción
política política

Tipo Denegar No cree máquinas virtuales si no están en el SKU Serie

A o Serie D.

etiquetas Adjuntar Agregue el nombre de la etiqueta "Entorno" y el valor

de la etiqueta "Dev/Test" a todos los recursos.

1. En Azure Portal, busque el servicio de políticas y seleccione la hoja Definiciones.

Para reducir los gastos administrativos, se creará una nueva definición de iniciativa.
Las definiciones de iniciativas son una colección de definiciones de políticas que se
centran en el mismo objetivo. Permiten agrupar un conjunto de políticas como un
solo elemento.
2. En la hoja Definiciones, haga clic en Definición de iniciativa, como se muestra en la
Figura 1-33 .

FIGURA 1-33 Hoja Definiciones de Azure Policy

3. Escriba Cumplimiento de desarrollo/pruebas en el campo Nombre, seleccione la

Ubicación de definición y elija Crear nuevo en las opciones de Categoría.
Escriba Personalizado en el campo Categoría, como se muestra en la Figura 1-34 .
 FIGURA 1-34 Hoja Definición de la iniciativa de Azure Policy

4. En la pestaña Políticas, seleccione Agregar definiciones de políticas para agregar

definiciones de políticas integradas a la iniciativa. En este ejemplo, agregue las
siguientes políticas integradas a la definición y establezca los valores como se
indica (consulte la Figura 1-35 ):
 FIGURA 1-35 Políticas y parámetros de definición de nuevas iniciativas para
Azure Policy

1. Requerir una etiqueta y su valor en los recursos

2. SKU de tamaño de máquina virtual permitido
5. Seleccione la pestaña Parámetros de política. Se le pedirá que proporcione valores
predeterminados para las definiciones de políticas que se agregaron a la iniciativa.
En este escenario, agregue el siguiente nombre y valor de etiqueta:
0. Nombre: Medio Ambiente
1. Valor: Desarrollo/Prueba
6. En el menú desplegable SKU de tamaños permitidos, seleccione tres tamaños
disponibles para su suscripción.
7. Haga clic en Revisar + Crear para guardar la definición y poder utilizarla en una
tarea de iniciativa. Desde la página Política, busque la hoja Asignaciones y haga clic
en Asignar iniciativa (consulte la Figura 1-36 ).
 FIGURA 1-36 Hoja Asignaciones de Azure Policy

8. Para cumplir con los requisitos ambientales, establezca el Alcance de la asignación

a la suscripción de destino y configure las Exclusiones para excluir el grupo de
recursos rgCoreNetwork. Además, establezca la Definición de iniciativa en
Cumplimiento de desarrollo/pruebas y establezca el Nombre de la asignación en
Cumplimiento de desarrollo/pruebas. Por último, asegúrese de que la aplicación de
políticas esté habilitada (consulte la Figura 1-37 ). Luego haga clic en Revisar +
Crear y haga clic en Crear.
 FIGURA 1-37 Hoja Iniciativa de asignación de Azure Policy

Una vez asignadas las definiciones de políticas, ya sea mediante asignaciones de políticas o
asignaciones de iniciativas, los efectos de la política serán inmediatamente aplicables. La
evaluación de cumplimiento de políticas se realiza aproximadamente una vez cada hora, lo
que significa que es posible que no pueda ver el estado de cumplimiento de una nueva
asignación de inmediato.

El estado de cumplimiento se puede ver en la hoja Cumplimiento del servicio Azure Policy.
Puede eliminar, editar y duplicar la asignación de política haciendo clic derecho en la hoja
Cumplimiento, como se muestra en la Figura 1-38 .

FIGURA 1-38 Hoja Cumplimiento de Azure Policy

Configurar bloqueos de recursos

Los bloqueos de recursos de Azure (a veces denominados bloqueos de administración) se

utilizan para evitar la eliminación o modificación accidental de recursos. Hay dos tipos de
cerraduras:

 Los bloqueos de eliminación impiden la eliminación de un recurso. Un bloqueo de

eliminación solo evita la eliminación de un recurso y no impide la modificación de
un recurso.
 Los bloqueos de solo lectura impiden que los usuarios modifiquen un recurso, lo
que incluye actualizarlo o eliminarlo.
Tenga en cuenta que ambos tipos de bloqueos de recursos permiten a los usuarios
autorizados leer recursos; Los bloqueos de recursos se aplican a todos los usuarios y roles,
incluso a los roles personalizados y privilegiados.

Los bloqueos de recursos, independientemente del tipo, se pueden aplicar a la suscripción,

al grupo de recursos y a los ámbitos de recursos. Cuando aplica un bloqueo a un ámbito, los
recursos dentro de ese ámbito heredan el bloqueo. Esto significa que un bloqueo aplicado al
alcance del grupo de recursos se aplica a todos los recursos del grupo de recursos. Los
bloqueos de recursos se aplican a todas las instancias de servicio y recursos dentro de un
alcance.

La herencia de bloqueo se aplica a los recursos secundarios del ámbito en el que está
configurando el bloqueo. Por ejemplo, un bloqueo en un grupo de recursos se aplica a todos
los recursos del grupo. Si se aplica un bloqueo de eliminación a uno de los recursos del
grupo de recursos e intenta eliminar ese grupo de recursos, fallará. Cuando intenta eliminar
el grupo de recursos, la operación intenta eliminar primero todos los recursos subyacentes y
no podrá eliminar el recurso con un bloqueo de eliminación, por lo que la eliminación del
grupo de recursos también fallará.

Tenga en cuenta que los bloqueos de recursos se aplican al plano de administración de

Azure. Esto significa que los bloqueos de recursos no afectan la propia funcionalidad del
recurso; en cambio, restringen las interacciones con otros recursos de Azure. Por ejemplo,
un bloqueo de solo lectura aplicado a una cuenta de almacenamiento impediría que los
usuarios lean las claves de acceso. Si intenta leer o modificar el accesoclaves, la operación
fallará con el error "No se puede realizar la operación de escritura porque los siguientes
ámbitos están bloqueados", como se muestra en la Figura 1-39 .
FIGURA 1-39 Bloqueo de solo lectura aplicado a una cuenta de almacenamiento

Al crear candados, tenga cuidado porque pueden provocar resultados inesperados. Muchas
operaciones que parecen ser operaciones de lectura requieren acceso de escritura dentro del
plano de administración de Azure. Por ejemplo, el mismo bloqueo de solo lectura en una
cuenta de almacenamiento impediría que los usuarios creen nuevos contenedores de blobs
porque la acción requiere acceso de escritura.

Una vez que haya determinado el tipo de bloqueo que aplicará según sus requisitos, puede
aplicar el bloqueo a través de Azure Portal, Azure PowerShell, la CLI de Azure, las
plantillas de Resource Manager o la API REST.

Para crear un bloqueo a través de Azure Portal, busque el ámbito deseado y seleccione la
hoja Bloqueos. Desde la hoja, haga clic en Agregar para crear un nuevo candado. Asigne un
Nombre de bloqueo a la cerradura, seleccione el Tipo de cerradura y describa la cerradura
en el campo Notas, como se muestra en la Figura 1-40 .
FIGURA 1-40 Creando un candado

Aplicar y administrar etiquetas en recursos

Las etiquetas de recursos le permiten aplicar metadatos personalizados a sus recursos de

Azure para organizarlos lógicamente y crear taxonomías personalizadas. Una etiqueta es un
par de nombre y valor. Por ejemplo, supongamos que al implementar recursos en Azure,
desea realizar un seguimiento del entorno al que está asociado el recurso. Para hacer esto,
puede crear una etiqueta llamada Entorno y el valor Producción para todos los recursos en
producción. Para entornos posteriores, como entornos de desarrollo o prueba, puede utilizar
la misma etiqueta de entorno con el valor Dev/Test. Las etiquetas comunes incluyen el
entorno al que está asociado un recurso, un centro de costos o código de facturación y el
propietario del recurso.

A medida que se aplican las etiquetas, puede consultar los recursos de su suscripción
utilizando sus etiquetas e incluso puede hacerlo en todos los grupos de recursos. Esto le
permite comprender los recursos relacionados entre los grupos de recursos tanto para la
facturación como para la administración. Las etiquetas también se incluyen en los datos de
facturación de Azure Cost Management + Billing. Cost Management + Billing brinda una
visión clara de la devolución de cargo para comprender el uso y el costo de los recursos. La
Figura 1-41 muestra un ejemplo de una exportación con etiquetas de recursos de una
suscripción de Azure EA.
FIGURA 1-41 Exportación de uso detallado de Azure

Etiquetas de notas e informes de uso

Las etiquetas se deben aplicar en el alcance del recurso para que sean visibles en las
exportaciones de uso detalladas. Las etiquetas aplicadas en el ámbito del grupo de recursos
no las heredan los recursos secundarios. Esto significa que a medida que aplica etiquetas a
sus recursos en Azure, debe pensar en aplicar etiquetas a cada recurso para tener la línea de
visión más clara de su uso en función de las etiquetas de su organización.

Al planificar las etiquetas de recursos, cualquier taxonomía debe incluir una estrategia para
el etiquetado bajo demanda (o de autoservicio) y el etiquetado automático a través de Azure
Policy. En la sección " Configurar políticas de Azure ", aprendió cómo aplicar etiquetas
automáticamente mediante Azure Policy. En esta sección, aprenderá cómo crear etiquetas y
aplicarlas manualmente a los recursos.

Al planificar su taxonomía de etiquetado, tenga en cuenta las limitaciones de las etiquetas

en Azure, como se detalla en la Tabla 1-3 .

TABLA 1-3 Limitaciones de las etiquetas de Azure

LÍMITE DE
Notas
ETIQUETAS

Soporte de  No todos los tipos de recursos admiten etiquetas. Esto significa

recursos que no podrá aplicar etiquetas a todo en Azure. Por ejemplo, los
grupos de administración, las interfaces de red y las máquinas
virtuales generalizadas no admiten etiquetas. Consulte este
enlace: https://learn.microsoft.com/en-us/azure/azure-resource-
manager/management/tag-support .

Número de  La mayoría de los recursos, grupos de recursos y suscripciones

etiquetas están limitados a 50 etiquetas. Cada recurso puede tener etiquetas
diferentes. Algunos recursos, como Azure Automation, zonas
DNS y Azure CDN, están limitados a 15 etiquetas.

Nombre de  Los nombres de las etiquetas no pueden exceder los 512

etiqueta caracteres. Para las cuentas de almacenamiento, los nombres de
las etiquetas están limitados a 128 caracteres.
 LÍMITE DE
Notas
ETIQUETAS

Valor de  Los valores de etiqueta no pueden exceder los 256 caracteres.

etiqueta

Herencia de  Los recursos secundarios no heredan las etiquetas. Las etiquetas

etiquetas aplicadas a un grupo de recursos no se aplican a los recursos de
ese grupo de recursos.

Recursos  Las etiquetas no se pueden aplicar a recursos clásicos y solo están

clásicos disponibles para recursos creados en el modelo de Azure
Resource Manager.

Caracteres  Los nombres de etiquetas no pueden contener los siguientes

ilegales caracteres: <, >, %, &, \, ?, /. Además, algunos recursos, como
Azure Front Door, también restringen el uso de # o : en el nombre
de la etiqueta.

Para aplicar etiquetas a una suscripción, grupo de recursos o recurso, el usuario que aplica
la etiqueta debe tener acceso de escritura al recurso (rol de colaborador o acceso superior).

Las etiquetas se pueden crear y aplicar a recursos de Azure a través de

 El portal de Azure
 PowerShell de Azure
 La CLI de Azure
 Plantillas de administrador de recursos
 API REST del administrador de recursos

Esto significa que las etiquetas se pueden aplicar tanto de forma imperativa como
declarativa a través de plantillas de Resource Manager. Si bien esto se puede hacer a través
de Azure Portal, PowerShell, la CLI o Resource Manager, las plantillas o políticas son más
adecuadas cuando esto se hace a medida que se crean los recursos porque no desea
realizarlo manualmente para cada recurso después de la implementación.

Las etiquetas se pueden aplicar a nivel de suscripción, grupo de recursos y/o recurso. Tenga
en cuenta nuevamente que no existe herencia para las etiquetas. Si necesita que se aplique
una etiqueta a todos los recursos de un grupo de recursos, cada recurso debe etiquetarse
individualmente.
Administrar grupos de recursos

Al crear grupos de recursos, es importante que considere factores para el diseño de su grupo
de recursos:

 Un recurso puede ser miembro de un solo grupo de recursos.

 Un grupo de recursos no se puede anidar en otro grupo de recursos.
 Puede mover un recurso de un grupo de recursos a otro.
 Se puede utilizar un grupo de recursos para determinar el alcance del control de
acceso.
 Se puede utilizar un grupo de recursos para definir el alcance de la política.
 Un recurso de un grupo de recursos puede interactuar con recursos de otro grupo de
recursos.
 Un grupo de recursos se crea en una ubicación, también conocida como región de
Azure. La ubicación de un grupo de recursos especifica dónde se almacenan los
metadatos del grupo de recursos. Si tiene limitaciones de cumplimiento o
geográficas, esta es una consideración importante.
 Microsoft recomienda que todos los recursos de un grupo de recursos compartan el
mismo ciclo de vida.
 No es obligatorio que todos los recursos de Azure pertenezcan a un grupo de
recursos.
 Crear un grupo de recursos a través de Azure Portal puede ser una tarea más
sencilla. Solo necesita detalles de región o ubicación junto con un nombre de grupo
de recursos válido (consulte la Figura 1-42 ).
FIGURA 1-42 Hoja Crear un grupo de recursos

Mover recursos entre grupos de recursos

Algunos recursos de Azure se pueden mover entre grupos de recursos e incluso entre
suscripciones, pero la compatibilidad con las operaciones de movimiento varía según el
servicio. Puede encontrar una referencia de los servicios que se pueden mover
en https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/move-
support-resources . En la Figura 1-43 , la máquina virtual del grupo de recursos 2 se puede
mover al grupo de recursos 1 y también se puede mover entre suscripciones al grupo de
recursos de la suscripción 2.

Operaciones de movimiento importantes

Incluso si un recurso afirma que admite operaciones de movimiento, puede haber otros
factores que impidan que el recurso se mueva. Para obtener información sobre la
compatibilidad con operaciones de movimiento para recursos de Azure,
consulte https://learn.microsoft.com/en-us/azure/azure-resource-
manager/management/move-support-resources .

FIGURA 1-43 Diagrama de recursos en movimiento

Durante una operación de traslado, sus recursos quedarán bloqueados. Se bloquearán tanto
las operaciones de escritura como de eliminación en el recurso de Azure, pero el servicio
subyacente seguirá funcionando. Por ejemplo, si mueve una aplicación web en Azure App
Service, la aplicación seguirá atendiendo solicitudes web a los visitantes. Una operación de
traslado puede tardar hasta cuatro horas en completarse. Si la operación de movimiento
falla dentro del período de cuatro horas, Resource Manager volverá a intentar la operación
de movimiento.

Para mover recursos entre suscripciones, ambas suscripciones deben estar asociadas con el
mismo inquilino de Entra. Si las suscripciones no pertenecen al mismo inquilino, puede
actualizar la suscripción de destino para utilizar el inquilino de Entra de origen
transfiriendo la propiedad de la suscripción a otra cuenta. Tenga en cuenta que esta
operación puede tener efectos inesperados porque el inquilino de Entra asociado con una
suscripción se usa para RBAC para cualquier servicio de Azure implementado actualmente.
¿Necesita más revisión? Transferir suscripción o apuntar a un nuevo inquilino de
entrada

Para transferir la propiedad de una suscripción de Azure a otra cuenta,

consulte https://learn.microsoft.com/en-us/azure/cost-management-billing/manage/billing-
subscription-transfer .

Además, para agregar una suscripción de Azure a un nuevo inquilino de Entra,

consulte https://learn.microsoft.com/en-us/entra/fundamentals/how-subscriptions-
associated-directory .

Al mover recursos entre suscripciones, el proveedor de recursos del recurso de origen

también debe estar registrado en la suscripción de destino. Un proveedor de recursos es el
servicio subyacente que permite que ese servicio funcione y opere en su suscripción. Para
ver la lista de proveedores de recursos, navegue hasta su suscripción. En la suscripción,
seleccione Proveedores de recursoscuchilla. Esto no supone un problema al mover recursos
dentro de la misma suscripción porque el proveedor de recursos ya estará registrado.

Si mueve recursos entre suscripciones, también debe tener en cuenta las cuotas de recursos.
Por ejemplo, si está moviendo muchas máquinas virtuales, deberá asegurarse de que la
suscripción de destino tenga suficientes vCPU disponibles o la operación de movimiento
fallará. Asegúrese de validar las cuotas antes de mover un recurso.

Por último, existen limitaciones en Azure Resource Manager que afectan la cantidad de
recursos que puede mover en una sola operación. Una sola operación de movimiento en
Resource Manager no puede mover más de 800 recursos. Con esta restricción, se
recomienda dividir las operaciones grandes en lotes más pequeños. Tenga en cuenta que
incluso si mueve menos de 800 recursos en una sola solicitud de movimiento, la operación
aún puede fallar debido al tiempo de espera.

Si el recurso que está moviendo tiene recursos dependientes, todos los recursos deben estar
ubicados dentro del mismo grupo de recursos y todos deben moverse juntos. Por ejemplo,
una máquina virtual depende de la interfaz de red, los discos y posiblemente más, según la
implementación.

Una vez que haya cumplido los requisitos previos establecidos para una operación de
movimiento, estará listo para realizar la operación de movimiento. Puede mover los
recursos con Azure Portal, Azure PowerShell, la CLI de Azure o la API REST. Tenga en
cuenta que Azure realiza una validación básica antes de realizar la operación de
movimiento real, independientemente del método que se utilice. Además, puede validar la
operación de movimiento a través de la API REST con el método validarMoveResources
sin realizar realmente la operación de movimiento. Esta API valida si los recursos se
pueden mover de un grupo de recursos a otro grupo de recursos. Si la validación tiene éxito,
se devolverá un HTTP 204 y, si falla, se devolverá un HTTP 409 con un mensaje de error
en la respuesta. Este método se puede llamar con una solicitud POST para

Haga clic aquí para ver la imagen del código

https://management.azure.com/subscriptions/%7bsubscriptionId%7d/resourceGroups/%
7bsource

ResourceGroupName%7d/validateMoveResources?api-version=2021-04-01

En una solicitud POST, incluya un cuerpo de solicitud con las propiedades "recursos" y
"targetResourceGroup":

Haga clic aquí para ver la imagen del código

"resources": ["<resource-id-1>", "<resource-id-2>"],

"targetResourceGroup": "/subscriptions/<subscription-
id>/resourceGroups/<target-group>"

Si la solicitud tiene el formato correcto, la operación devolverá un resultado como el

siguiente:

Haga clic aquí para ver la imagen del código

Response Code: 202

cache-control: no-cache

pragma: no-cache

expires: -1

location: https://management.azure.com/subscriptions/<subscription-id>/

operationresults/<operation-id>?api-version=2018-02-01

retry-after: 15

...

El código de respuesta HTTP 202 muestra que la solicitud fue aceptada. El URI de
ubicación se puede usar en un GET HTTP que puede usar para verificar el estado de la
operación de larga duración para el código de estado final HTTP 204 o HTTP 409. La
Figura 1-44 muestra el resultado de una operación para validar una solicitud de movimiento
para una cuenta de Azure Automation asociada con un área de trabajo de Log Analytics.
Como se esperaba, la operación de validación devolvió un HTTP 409 porque esta solicitud
de movimiento no se puede ejecutar.
FIGURA 1-44 Respuesta de la API ValidateMoveResources

Para usar Azure Portal, busque el grupo de recursos que contiene los recursos, haga clic en
Mover y elija Mover a otro grupo de recursos o Mover a otra suscripción, como se muestra
en la Figura 1-45 .

FIGURA 1-45 Menú Mover en Azure Portal

Ahora puede seleccionar los recursos que desea mover y seleccionar el grupo de recursos
de destino. Tenga en cuenta que debe reconocer que es posible que necesite actualizar
herramientas o scripts existentes para tener en cuenta los cambios en los ID de recursos
(consulte la Figura 1-46 ).
FIGURA 1-46 Hoja Mover recursos

Eliminar grupos de recursos

En Azure, puede eliminar recursos individuales de un grupo de recursos o puede eliminar

un grupo de recursos y todos sus recursos. Al eliminar un grupo de recursos, también se
eliminan todos los recursos que contiene en una sola operación. Al eliminar grupos de
recursos, tenga cuidado porque el grupo de recursos puede contener recursos de los que
dependen otros recursos que haya implementado. Por ejemplo, si intenta eliminar una
cuenta de almacenamiento que utiliza una aplicación para almacenar datos de la aplicación,
la plataforma Azure no reconocerá esa dependencia y permitirá que se elimine la cuenta de
almacenamiento.
Para los recursos que tienen recursos dependientes, no podrá eliminar el recurso de destino
hasta que se hayan eliminado las dependencias. Por ejemplo, para eliminar un grupo de
recursos que contiene un plan de App Service, primero debe quitar o desasociar cualquier
aplicación de App Service que dependa de ese plan. En la Figura 1-47 se muestra un
ejemplo de cómo intentar eliminar un plan de App Service con asociaciones de aplicaciones
de App Service existentes .

FIGURA 1-47 Eliminar un recurso de Azure con dependencias

Para eliminar un grupo de recursos, puede usar Azure Portal, Azure PowerShell, la CLI de
Azure o la API REST.

Para eliminar un grupo de recursos en Azure Portal, busque el grupo de recursos y haga clic
en Eliminar grupo de recursos (consulte la Figura 1-48 ).

FIGURA 1-48 Opción Eliminar grupo de recursos

En ¿Está seguro de que desea eliminar [“nombre del grupo de recursos”]? cuadro de
diálogo que se abre, deberá escribir el nombre del grupo de recursos para confirmar que
desea eliminarlo. Como se muestra en la Figura 1-49 , el blade también mostrará los
recursos afectados y le advertirá que la operación es irreversible.

FIGURA 1-49 Confirmación de eliminación del grupo de recursos de Azure

Al seleccionar Eliminar, se comenzarán a eliminar recursos inmediatamente. Tenga en

cuenta que la eliminación de un grupo de recursos puede tardar varios minutos porque cada
recurso se elimina individualmente.

Administrar suscripciones de Azure

Las suscripciones de Azure incluyen controles que controlan el acceso a los recursos dentro
de una suscripción, controlan los costos mediante cuotas y etiquetado, y controlan los
recursos permitidos en un entorno con Azure Policy.

Como se mencionó anteriormente, una suscripción es una unidad lógica de servicios de

Azure vinculada a una cuenta de Azure, que es una identidad en Entra ID. Entra ID es un
proveedor de identidad para Azure y proporciona autenticación a los recursos en una
suscripción de Azure. Luego, a los propios recursos se les aplican controles de acceso
basados en roles que brindan autorización a los recursos (consulte la Figura 1-50 ).
FIGURA 1-50 Relación de suscripción de Entra ID y Azure

Hay varias formas de obtener una suscripción a Azure y una amplia gama de tipos de
suscripción (u ofertas). Algunos tipos comunes incluyen los siguientes:

 Prueba gratis
 Pago por uso/Web directo
 Suscripciones a Visual Studio/MSDN
 Revendedores de Microsoft
 Proveedor de soluciones en la nube
 Licencia abierta de Microsoft
 Acuerdos empresariales

Las capacidades de cada suscripción son similares en el sentido de que cada tipo de
suscripción le permite crear y administrar recursos. Algunos tipos de suscripción tienen
restricciones sobre los tipos de recursos y ubicaciones admitidos. Por ejemplo, las
suscripciones a Visual Studio normalmente no tienen una tarjeta de crédito asociada, lo que
le impide comprar servicios de Azure.Marketplace, como dispositivos virtuales de red. Las
suscripciones de Visual Studio para Azure solo tienen acceso a una cantidad limitada de
regiones de Azure. Las restricciones regionales para cada oferta se pueden ver
en https://azure.microsoft.com/regions/offers/ .

Asignar permisos de administrador

Azure tiene muchas funciones diferentes para administrar el acceso a los recursos de Azure.
Estos incluyen roles administrativos de suscripción clásicos como administrador de
cuentas, administrador de servicios o coadministrador, así como controles de acceso
basados en roles (RBAC) de Azure que están disponibles en Azure Resource Manager
(ARM). Tenga en cuenta que está previsto que los roles y recursos clásicos queden
obsoletos en agosto de 2024. Al administrar el acceso a las suscripciones y recursos de
Azure, se recomienda utilizar roles RBAC de Azure siempre que sea posible.

¿Necesita más revisión? Roles y relaciones

Para obtener más información sobre la correlación entre los roles de administrador de
suscripción clásicos, los roles de Azure RBAC y los roles de Entra,
consulte https://learn.microsoft.com/en-us/azure/role-based-access-control/rbac-and-
directory . -roles de administrador .

Los administradores de suscripciones clásicas tienen acceso completo a una suscripción de

Azure. Pueden administrar recursos a través de Azure Portal, las API de Resource Manager
(incluso a través de PowerShell y la CLI) y las API del modelo de implementación clásico.

De forma predeterminada, la cuenta que se utiliza para registrarse en una suscripción de

Azure se configura automáticamente como administrador de la cuenta y administrador del
servicio. Ambos están autorizados a realizar actividades de administración de
suscripciones, pero solo el administrador de la cuenta puede realizar la creación de nuevas
suscripciones de Azure y los cambios de facturación. Solo puede haber un administrador de
cuenta por cuenta y un administrador de servicio por suscripción.

Una vez creada la suscripción, se pueden agregar más coadministradores. El

coadministrador tiene el mismo nivel de acceso que el administrador del servicio, pero no
puede cambiar la asociación de suscripciones a los directorios de Azure. Puede haber hasta
200 coadministradores por suscripción.

Los usuarios asignados con los roles de administrador de servicios y coadministrador tienen
el mismo acceso que un usuario al que se le asigna el rol de propietario de RBAC de Azure
en el ámbito de la suscripción.

En Azure Portal, puede ver las asignaciones actuales para los roles de Administrador de
cuentas y Administrador de servicios buscando una suscripción en Azure Portal y
seleccionando la hoja Propiedades, como se ve en la Figura 1-51 .
FIGURA 1-51 Propiedades de suscripción de Azure

Roles RBAC de Azure integrados

Los roles de Azure RBAC son más flexibles que los roles de administrador clásicos y
permiten una administración de acceso más detallada. Azure RBAC tiene más de 70 roles
integrados, pero hay cuatro roles fundamentales, como se muestra en la Tabla 1-4 .

TABLA 1-4 Roles de RBAC de Azure

Rol RBAC de
Permisos Notas
Azure

Dueño  Acceso completo  Al administrador del servicio y a

a todos los los coadministradores se les
recursos. asigna la función de propietario
 Delegar el acceso en el ámbito de la suscripción.
a otros
 Rol RBAC de
Permisos Notas
Azure

 Se aplica a todos los tipos de

recursos.

Contribuyente  Cree y administre  Se aplica a todos los tipos de

todo tipo de recursos.
recursos de Azure
 No se puede
otorgar acceso a
otros

Lector  Ver recursos de  Se aplica a todos los tipos de

Azure recursos.

Administrador  Administrar el
de acceso de acceso de los
usuario usuarios a los
recursos de Azure

Configurar grupos de administración

Los grupos de administración también se pueden usar para aplicar Azure RBAC a una
suscripción. Al utilizar grupos de administración, puede aplicar la gobernanza de manera
consistente en todas las suscripciones, incluida la aplicación de controles RBAC comunes y
la aplicación de Azure Policy, como se analiza más adelante en este capítulo.

Dentro de los grupos de administración, las suscripciones se pueden organizar en una

jerarquía de varios niveles, lo que proporciona una serie de beneficios tangibles:

 Gastos generales reducidos No es necesario aplicar gobernanza en cada

suscripción.
 Cumplimiento Los administradores de la empresa pueden aplicar la gobernanza a
nivel del grupo de administración, fuera del control del administrador de la
suscripción, y los controles implementados en el grupo de administración se pueden
aplicar tanto a las suscripciones nuevas como a las existentes. Esto elimina
inconsistencias en la aplicación de la gobernanza, ya que los mismos controles se
aplican de la misma manera a las suscripciones deseadas.
  Informes Azure Policy proporciona informes de cumplimiento. Con los grupos de
administración, los informes pueden abarcar varias o todas las suscripciones de una
organización.

Los grupos de administración forman una jerarquía de hasta seis niveles de profundidad,
excluyendo los niveles raíz y de suscripción. Cada grupo tiene exactamente un padre y
puede tener varios hijos. En la Figura 1-52 se muestra un ejemplo de jerarquía . En dicha
jerarquía, se podría aplicar un conjunto común de políticas en el grupo de administración
raíz, que heredarían todos los grupos de administración secundarios y las suscripciones.
Luego, según sea necesario, a esos niños se les pueden aplicar controles adicionales.

FIGURA 1-52 Ejemplo de jerarquía de grupo de administración

Hay un único grupo de administración raíz en la raíz de la jerarquía. Este grupo de

administración está asociado con el inquilino de Entra que luego se asocia con una
suscripción de Azure. No se puede mover ni eliminar. Las suscripciones individuales,
incluidas las suscripciones nuevas, se agregan a un grupo de administración.

Al igual que RBAC, Azure Policy también se aplica en un ámbito específico. El ámbito
puede ser una suscripción, un grupo de recursos o un recurso individual. Por ejemplo,
cuando se aplica una política en el alcance de la suscripción, todos los grupos de recursos y
recursos de la suscripción la heredan, como se muestra en la Figura 1-53 .
FIGURA 1-53 Ejemplo de política aplicada en el ámbito de la suscripción

Los grupos de administración introducen un alcance adicional por encima de una

suscripción. Cuando se aplica en el alcance del grupo de administración, cada suscripción
del grupo de administración hereda el RBAC y las asignaciones de políticas del grupo de
administración, como se muestra en la Figura 1-54 .
FIGURA 1-54 Ejemplo de política aplicada en el ámbito del grupo de administración

Para agregar una asignación de roles a un grupo de administración, busque grupos de

administración en Azure Portal. Seleccione un grupo de administración y luego haga clic en
Detalles junto al nombre de ese grupo. Seleccione la hoja Control de acceso (IAM), haga
clic en Agregar y elija Agregar asignación de roles, tal como lo haría para una suscripción
de Azure, como se muestra en la Figura 1-55 .

FIGURA 1-55 Hoja de control de acceso (IAM) para un grupo de administración de Azure

Importantes RBAC y grupos de gestión

El RBAC aplicado a nivel del grupo de administración lo heredan todos los recursos
secundarios dentro del alcance del grupo de administración (suscripciones, grupos de
recursos y recursos). Por ejemplo, si agrega un usuario como propietario en el ámbito del
grupo de administración, ese usuario se convertirá en propietario de todas las suscripciones
asociadas con el grupo de administración y la función también la heredarán las
suscripciones de los grupos de administración secundarios.
Configurar la gestión de costes

En Azure, existen varios tipos de cuotas que se aplican a las suscripciones, incluidas las
cuotas de recursos y las cuotas de gasto. Con las cuotas (o límites) de recursos de Azure,
los administradores de Azure pueden ver el consumo y el uso actuales de los recursos
dentro de una suscripción de Azure y comprender cómo ese consumo puede verse afectado
por los límites de recursos de Azure. Los administradores también pueden solicitar
aumentos de cuota para ciertos tipos de recursos. Por ejemplo, en la mayoría de los tipos de
suscripción, la cantidad de núcleos disponibles para máquinas virtuales está limitada a 20
por región de forma predeterminada. Este límite se puede aumentar enviando una solicitud
al soporte de Microsoft. Algunas solicitudes de cuota se aprueban automáticamente en
Azure Portal y otras solicitudes requieren un ticket de soporte con justificación y
aprobación manual.

También puede configurar límites de gasto para su suscripción de Azure. Las cuotas de
gasto permiten a los administradores establecer alertas o presupuestos dentro de una
suscripción de Azure para informar a la empresa cuando su gasto en Azure haya alcanzado
un umbral determinado. Si bien un límite de recursos puede impedir que se creen recursos
(por ejemplo, no hay suficientes núcleos disponibles para elsuscripción en la región
deseada), una cuota de gasto actúa como un mecanismo de alerta y no impide que se creen
o consuman recursos. Si bien se puede generar una alerta a partir de una cuota de gasto, aún
se pueden crear y consumir recursos, lo que podría provocar que se supere la cuota de
gasto.

Las etiquetas de Azure Resource Manager permiten a los consumidores de Azure

categorizar de forma lógica los grupos de recursos de Azure y los recursos de Azure. A
medida que se etiquetan los recursos, se pueden consultar y rastrear en función de las
etiquetas asociadas. Las etiquetas son un componente crucial para implementar el
contracargo dentro de una suscripción de Azure. Por ejemplo, en organizaciones donde
varias unidades de negocios o departamentos comparten una suscripción de Azure, puede
ser necesario comprender cómo se usan los recursos para departamentos individuales y
mostrar el costo asociado con cada departamento, ya sea para facturar a ese departamento
por su consumo de Azure. (devolución de cargo) o para ayudar a ese departamento a
comprender su gasto en Azure (devolución de cargo).

Configurar cuotas de recursos

Para ver las cuotas de recursos existentes (o límites de servicio) para su suscripción de
Azure, busque la suscripción de Azure en Azure Portal y seleccione la hoja Uso + Cuotas.
Desde esta hoja, puede ver las cuotas existentes por servicio, proveedor de recursos y
ubicación. También filtra la lista por tipos de recursos que ha implementado.

Para aumentar una cuota, haga clic en Nueva solicitud de cuota, como se muestra en la
Figura 1-56 .
FIGURA 1-56 Cuotas de recursos de suscripción de Azure

Al hacer clic en Solicitar aumento se inicia el proceso para abrir una nueva solicitud de
soporte. Como parte de la solicitud, debe seleccionar el tipo de cuota (por ejemplo, núcleos
de cómputo/VM o servicio de aprendizaje automático) y proporcionar una descripción de
su solicitud.

Importante aumento de cuota

Las solicitudes de cuota que no se aprueban automáticamente requieren una solicitud de

soporte técnico a Microsoft. El soporte técnico de Microsoft debe responder a la solicitud y,
aunque la mayoría de las solicitudes se conceden, no se garantiza que se conceda un
aumento de cuota.

El consumo de recursos dentro de una suscripción frente a una cuota de recursos también se
puede ver con PowerShell. Hay varios cmdlets disponibles en el módulo de PowerShell Az
(anteriormente AzureRm) para consultar el uso de cuota por servicio. Por ejemplo, para ver
el uso actual de cuotas de vCPU, use Get-AzVMUsage y para ver el uso actual de recursos
para el servicio de almacenamiento, use Get-AzStorageUsage.

Consejo de examen
En este capítulo y en toda la referencia restante, se hace referencia a los cmdlets de
PowerShell mediante el módulo Az. Consulte https://learn.microsoft.com/en-
us/powershell/module/az.accounts/enable-azurermalias?view=azps-
11.2.0&viewFallbackFrom=azps-10.2.0 para obtener más detalles.

Configurar cuotas de centros de costos

Uno de los factores clave en la administración de una suscripción a Azure es poder

planificar e impulsar la responsabilidad organizacional sobre el gasto en Azure. Una de las
mejores formas de impulsar la responsabilidad es asegurarse de que los consumidores de
recursos de Azure comprendan su costo, incluido el uso actual y la previsión del gasto
futuro en función del consumo actual de recursos.

Los presupuestos en Azure Cost Management brindan a los clientes de Azure suscripciones
bajo muchos tipos de ofertas la capacidad de administrar costos de manera proactiva y
monitorear el gasto de Azure a lo largo del tiempo en un nivel de suscripción.

Consejo de examen

La lista completa de cuentas y ofertas admitidas para Azure Cost Management se puede
encontrar en https://learn.microsoft.com/en-us/azure/cost-management-
billing/costs/understand-cost-mgt-data .

Los presupuestos son un mecanismo de seguimiento únicamente con umbrales establecidos

y reglas de notificación. Cuando se excede un umbral presupuestario, se activa una
notificación pero los recursos continúan ejecutándose.

Para usar presupuestos con una suscripción de Azure, esa suscripción debe ser un tipo de
oferta admitida como se indicó anteriormente. Los usuarios deben tener al menos acceso de
lectura (derechos de lector) a una suscripción para ver los presupuestos y deben tener
derechos de Colaborador (o superior) para crear y administrar presupuestos. También hay
roles especializados que se pueden utilizar para otorgar a los directores acceso a los datos
de Cost Management, incluidos Cost Management Colaborador y Cost Management
Reader.

Para crear un presupuesto en Azure Portal, navegue hasta Administración de costos +

Facturación, haga clic en Administración de costos y luego haga clic en Presupuestos.

Presupuestos de suscripción de notas

De forma predeterminada, creará un presupuesto en el ámbito de la suscripción, pero

también se pueden crear presupuestos en el grupo de administración y en el ámbito del
grupo de recursos, si es necesario.
Haga clic en Agregar y, en la hoja Crear presupuesto, ingrese un nombre y un monto del
presupuesto. También puede cambiar el alcance que desee haciendo clic en Cambiar
alcance. Elija el Período de reinicio (mensual, trimestral o anual) y una Fecha de
vencimiento. Los presupuestos requieren al menos un umbral de costo (porcentaje del
presupuesto) y una dirección de correo electrónico para el destinatario de la alerta. La
Figura 1-57 muestra un ejemplo de un presupuesto mensual de $10,000.
FIGURA 1-57 Presupuestos de Azure

La Figura 1-58 muestra un umbral fijado en el 90 por ciento del presupuesto ($9,000).

FIGURA 1-58 Alertas de presupuesto de Azure

Nota Alertas de presupuesto

Las alertas de presupuesto también pueden aprovechar los mismos grupos de acciones que
admite Azure Monitor. Los grupos de acciones son una colección de preferencias de
notificación y se analizan en detalle en el Capítulo 5 , " Supervisar y verificar los recursos
de Azure ".
Una vez creados sus presupuestos, podrá verlos a través de la hoja Presupuestos. Al ver el
alcance de la suscripción, verá los presupuestos de la suscripción y de cualquier grupo de
recursos en una sola vista, como se muestra en la Figura 1-59 .

FIGURA 1-59 Presupuestos de Azure

Monitorear e informar el gasto

Si bien Azure Advisor y sus recomendaciones de costos brindan un método para monitorear
el gasto y los recursos no utilizados, Azure tiene muchas otras herramientas que pueden
ayudarlo a monitorear el costo de sus recursos e informar sobre ese costo.

Hay varias consideraciones que debe tener en cuenta al informar sobre el costo asociado
con sus recursos de Azure:

 Los servicios de Azure están disponibles para clientes en más de 140 países en todo
el mundo.
 La facturación se admite en más de 20 monedas principales.
 Las suscripciones a Azure se facturan mensualmente. Si paga con tarjeta de crédito,
tenga en cuenta que no se aceptan tarjetas prepago ni tarjetas de crédito virtuales.
 También puedes pagar Azure mediante factura mensual. Para solicitar el pago de
una factura, genere un ticket de soporte de facturación adecuado desde el portal de
administración de Azure. Procesar la solicitud demora de cinco a siete días,
dependiendo del tiempo requerido para las verificaciones de crédito necesarias. El
pago de facturas solo está disponible para clientes comerciales y, una vez que una
suscripción se ha movido al pago de facturas, no se puede volver a mover al pago
con tarjeta de crédito. Si elige el pago de factura, recibirá una factura y pagará
mediante transferencia bancaria o cheque.
 Los clientes con un Acuerdo Empresarial (EA) pueden agregar compromisos
iniciales a Azure y luego crear múltiples suscripciones según el acuerdo, que se
basan en el compromiso monetario.
 Los compromisos de EA se facturan inmediatamente y luego se consumen a
lo largo del año en función de los recursos de Azure consumidos.
 Si se excede el gasto comprometido, el gasto adicional o "excedente" se
factura a la misma tarifa de EA con descuento. La facturación por excedente
es anual si el gasto excedente es inferior al 50 por ciento del compromiso, o
trimestral si es superior al 50 por ciento.
  Los servicios de terceros de Azure Marketplace se facturan por separado con un
período de facturación, una factura por separado y un cargo de tarjeta de crédito por
separado potencialmente diferentes. Cada servicio tiene su propio modelo de
facturación, el cual será descrito en el portal de Azure al momento de la compra.
Estos van desde facturación por minuto de pago por uso hasta cargos mensuales
fijos. Algunos servicios también ofrecen un modelo de “traiga su propia licencia”,
que debe proporcionar una licencia comprada por separado antes de utilizar el
servicio.

Hay tres portales que se usan para administrar suscripciones de Azure que son relevantes
para la facturación y la administración de costos:

 El portal de EA en https://ea.azure.com . Esto está disponible solo para clientes con

un Acuerdo Enterprise y se utiliza para administrar el gasto en una o más
suscripciones.
 El portal de Azure en https://portal.azure.com . Está disponible para todas las
suscripciones e incluye Azure Cost Management.
 El portal de patrocinios de Azure en https://www.microsoftazuresponsorships.com .
Esto está disponible sólo para aquellos que tienen una suscripción de patrocinio de
Microsoft.

El portal de EA se puede utilizar para monitorear el gasto en múltiples suscripciones con la

capacidad de ver los costos de toda la organización o de la unidad de negocios. Las
organizaciones pueden ver el gasto histórico, desglosado por compromiso y el consumo
excedente o de terceros de Azure Marketplace (consulte la Figura 1-60 ). También pueden
descargar su hoja de precios actual para ver sus tasas de descuento de EA, que a menudo
difieren de los precios públicos que se muestran en el portal de Azure y en la calculadora de
precios.
FIGURA 1-60 Resumen de uso del portal Azure EA

Los clientes de EA pueden crear cuotas de gasto y establecer umbrales de notificación a

través del portal de EA. Esto se suma a las alertas de presupuesto disponibles a través de las
herramientas de facturación y administración de costos de su suscripción de Azure. Una
ventaja de utilizar el portal de EA para configurar notificaciones de gastos es que se puede
activar una alerta de cuota en función del gasto agregado en todas las suscripciones dentro
de un departamento. Se pueden asignar centros de costos a los departamentos a los que se
acumulan las cuentas y suscripciones para los clientes de EA, lo que facilita el seguimiento
de los costos por unidad de negocio y operar un modelo de devolución o contracargo.

Dentro de Azure Portal, los clientes de EA también pueden utilizar Azure Cost
Management para realizar un seguimiento de los costos de las suscripciones individuales.
Cost Management incluye funciones para realizar análisis de costos, configurar alertas y
presupuestos por suscripción, establecer recomendaciones para optimización y exportar
datos de administración de costos para realizar análisis más profundos.

El acceso al servicio Cost Management está dictado por ámbitos y puede variar según el
tipo de acuerdo o suscripción que tenga con Microsoft. Un usuario debe tener al menos
acceso de lectura a uno de los siguientes ámbitos que se muestran en la Tabla 1-5 para ver
datos en Cost Management.

TABLA 1-5 Alcances de acceso a Cost Management

Configuración
Acceso
de EA como Consolida
Alcance Definido en requerido para
requisito datos para
ver datos
previo

Cuenta de https://ea.azure.com Administrador Ninguno Todas las

facturación empresarial suscripciones
del acuerdo
empresarial.

Departamento https://ea.azure.com Administrador DA ver Todas las

del cargos suscripciones
departamento habilitados que pertenecen
a una cuenta de
inscripción
vinculada al
departamento

cuenta de https://ea.azure.com Propietario de AO ver Todas las

inscripción la cuenta cargos suscripciones
habilitados de la cuenta de
inscripción.

grupo de https://portal.azure.com Lector de AO ver Todas las

gestión gestión de cargos suscripciones
costos (o habilitados debajo del
lector) grupo de
administración
 Configuración
Acceso
de EA como Consolida
Alcance Definido en requerido para
requisito datos para
ver datos
previo

Suscripción https://portal.azure.com Lector de AO ver Todos los

gestión de cargos recursos/grupos
costos (o habilitados de recursos de
lector) la suscripción

Grupo de https://portal.azure.com Lector de AO ver Todos los

recursos gestión de cargos recursos del
costos (o habilitados grupo de
lector) recursos.

Para acceder a Cost Management en Azure Portal, vaya a Cost Management + Billing y
elija Cost Management. Finalmente, seleccione Análisis de costos, como se muestra en la
Figura 1-61 .
FIGURA 1-61 Análisis de costos de Azure Cost Management

Si tiene acceso a más de un ámbito, puede filtrar por ámbito y comenzar a interactuar con
los datos. Desde la hoja Análisis de costos, puede ver los costos totales del mes actual, ver
el presupuesto (si está disponible), establecer la granularidad (acumulado, diario o mensual)
y aplicar los filtros. Puede filtrar por ubicación, medidor, categoría de medidor,
subcategoría de medidor, recurso, nombre de grupo de recursos, tipo de recurso, nombre de
servicio, nivel de servicio, ID de suscripción, nombre de suscripción y etiqueta.

Los datos de una vista se pueden descargar desde la hoja Análisis de costos como un
archivo CSV. Cualquier filtrado que haya aplicado, incluidas las agrupaciones, se aplica al
archivo.

Resumen del capítulo

Estas son algunas de las conclusiones clave de este capítulo:

 Windows 10 se puede agregar a Entra ID como un dispositivo a administrar, lo que
permite implementaciones BYOD o solo en la nube corporativa con Entra Join.
 Entra Join permite a los administradores gestionar la identidad del dispositivo
independientemente de los usuarios. Por ejemplo, se pueden crear grupos de
seguridad dinámicos basados en los atributos del dispositivo y luego se podrían
aplicar políticas de acceso condicional a esos grupos.
 Los clientes posteriores de Windows se pueden administrar a través de Entra ID
mediante la unión híbrida de Entra.
 El acceso condicional es una característica de Entra ID que permite a los
administradores controlar el acceso a las aplicaciones en la nube mediante
comprobaciones adicionales, como la ubicación del usuario, el dispositivo desde el
que el usuario accede a la aplicación en la nube y más.
 Se pueden crear y administrar varios inquilinos de Entra a través de Azure. Esto
incluye la creación de nuevos directorios y la eliminación de directorios existentes.
 Los usuarios y grupos se pueden crear a través de Azure Portal, Azure PowerShell,
la CLI de Azure y Graph API.
 Los usuarios y grupos se pueden administrar de forma masiva con herramientas
como PowerShell.
 El autoservicio de restablecimiento de contraseñas se puede combinar con las
funciones de reescritura de contraseñas de Entra Connect y Entra Cloud Sync para
permitir a los usuarios restablecer sus contraseñas desde la nube mientras cumplen
con los estándares de contraseñas locales.
 Muchas funciones avanzadas de Entra ID requieren licencias Entra ID Premium P1
o Entra ID Premium P2. Al considerar las funciones de Entra, los administradores
deben tener en cuenta los límites de las licencias.
 Azure ofrece un rico ecosistema de controles de gobernanza con controles a nivel de
usuario y a nivel de plataforma en forma de control de acceso basado en roles
(RBAC) y Azure Policy.
 Los grupos de administración de Azure se pueden usar para controlar la política y
RBAC para múltiples suscripciones. Los grupos de administración permiten la
alineación organizativa de sus suscripciones de Azure a través de jerarquías y
agrupaciones personalizadas.
 Las etiquetas en Azure se pueden usar para organizar lógicamente los recursos por
categorías. Cada etiqueta es un par de nombre y valor. Las etiquetas se pueden
compartir entre varios recursos y aplicar con Azure Policy.
 Azure Policy es un servicio que le permite crear, administrar y aplicar políticas a
recursos de Azure a nivel de suscripción, grupo de recursos o recursos. Las políticas
imponen diferentes reglas sobre sus recursos de Azure, de modo que esos recursos
sigan cumpliendo con los estándares de su organización.
 El control de acceso basado en roles le permite otorgar acceso a usuarios, grupos y
entidades principales de servicio a los recursos de Azure en los ámbitos de
suscripción, grupo de recursos o recursos con herencia RBAC. Los tres roles
principales son Propietario, Colaborador y Lector.
 Puede crear recursos desde el portal, PowerShell, las herramientas CLI y las
plantillas de Azure Resource Manager. Debe comprender cuándo utilizar qué
herramienta y cómo configurar el recurso durante y después del aprovisionamiento.
  Un recurso es simplemente una instancia de servicio única en Azure. La mayoría de
los servicios de Azure se pueden representar como un recurso. Por ejemplo, una
instancia de aplicación web es un recurso. Un plan de App Service también es un
recurso. Incluso una instancia de SQL Database es un recurso.
 Un grupo de recursos es una agrupación lógica de recursos. Por ejemplo, un grupo
de recursos donde implementa una instancia informática de VM puede estar
compuesto por una tarjeta de interfaz de red (NIC), una máquina virtual, una red
virtual y una dirección IP pública.
 Una plantilla ARM es un archivo JSON que le permite describir de forma
declarativa un conjunto de recursos. Luego, estos recursos se pueden agregar a un
grupo de recursos nuevo o existente. Por ejemplo, una plantilla puede contener la
configuración necesaria para crear dos instancias de aplicación API, una instancia
de aplicación móvil y una instancia de Azure SQL Database.
 Una plantilla puede simplificar la orquestación porque solo necesita implementar la
plantilla para implementar todos sus recursos.
 Con una plantilla, puede configurar múltiples recursos simultáneamente y usar
variables/parámetros/funciones para crear dependencias entre recursos.

Experimento mental

En este experimento mental, aplica lo que has aprendido. Puede encontrar respuestas a estas
preguntas en la siguiente sección.

Usted es responsable de crear y realizar un seguimiento de los recursos en Azure para dos
unidades de negocio dentro de su organización: Recursos Humanos y Marketing. Su
organización tiene un Acuerdo Empresarial (EA). Cada unidad de negocio necesita
desplegar sus propios recursos. Su departamento de Finanzas debe poder comprender el
consumo de recursos de cada unidad de negocio para fines de contracargo. A Finanzas
también le gustaría poder recibir una notificación cuando se alcance un umbral monetario
definido para cada unidad de negocio.

Los recursos que implementará cada unidad de negocio provienen de un conjunto conocido
de recursos y se debe evitar que los usuarios creen recursos no aprobados. Habrá recursos
dentro de una suscripción que no se facturarán directamente a las unidades de negocio, sino
que se facturarán a TI. Estos recursos deben estar diferenciados para Finanzas.

1. ¿Cómo se asegurará de que los usuarios solo puedan crear recursos aprobados en
Azure?
2. ¿Cómo otorgará acceso para crear recursos y restringirá que los usuarios de cada
unidad de negocios afecten a las otras unidades de negocios?
3. ¿Cómo accederá Finanzas a los datos de facturación de Azure y cómo podrán saber
de dónde proviene cada costo?
4. ¿Cómo se notificará a Finanzas cuando cada unidad de negocio se acerque a su
umbral de gasto?
Respuestas del experimento mental

Esta sección contiene la solución al experimento mental del capítulo.

Para cada unidad de negocio, Recursos Humanos y Marketing, se puede crear una
suscripción independiente. Esto permitirá la separación de recursos por unidad de negocios
y permitirá informes y monitoreo de costos segregados y agregados para Finanzas a través
del portal EA.

1. Para garantizar que los usuarios solo puedan crear recursos aprobados, se deben
definir políticas que se puedan asignar a cada suscripción. Las políticas negarán la
creación de recursos no aprobados y el cumplimiento también se puede monitorear a
través de Azure Policy.
2. Cada unidad de negocio se colocará en su propia suscripción. Dentro de una
suscripción, se crearán grupos de recursos y a los usuarios se les otorgarán los
derechos adecuados en el nivel del grupo de recursos. Como los recursos
secundarios heredan RBAC, con los derechos apropiados otorgados, los usuarios
podrán crear y administrar recursos según sea necesario sin afectar a otros en la
suscripción. Esto se superpondrá con Azure Policy para garantizar que solo se
puedan crear recursos permitidos. Esto se puede ampliar aún más mediante la
creación de plantillas de Azure Resource Manager, que los usuarios de la unidad de
negocios pueden usar para implementar sus recursos con configuraciones conocidas.

Como alternativa, también puede utilizar grupos de gestión para segregar las
unidades de negocio. Aún puede usar RBAC para heredar la suscripción de acceso y
los recursos secundarios de un grupo de administración.

3. A los usuarios del departamento de Finanzas se les puede otorgar acceso al portal de
EA y/o a Azure Cost Management configurando el acceso a través de los ámbitos
requeridos. Para asegurarse de que puedan saber de dónde proviene el costo de cada
recurso, se deben aplicar etiquetas a todos los recursos utilizando una taxonomía
definida por Finanzas. Por ejemplo, "BusinessUnit" puede ser una etiqueta con los
valores permitidos "HR", "Marketing" y "IT". Esa taxonomía debe regirse a través
de Azure Policy para garantizar que todos los recursos estén etiquetados con
etiquetas obligatorias y válidas.
4. Para gestionar los umbrales, las cuotas de departamento se pueden configurar en el
portal de EA. Además, se pueden crear presupuestos en Cost Management. Los
presupuestos en Cost Management pueden proporcionar más flexibilidad, ya que se
pueden establecer múltiples umbrales de notificación y cada notificación puede
tener un receptor diferente. Esto permitiría un presupuesto único para enviar
notificaciones tanto a los propietarios de las unidades de negocio como a Finanzas.
Capitulo 2
Implementar y gestionar el almacenamiento

Implementar y administrar el almacenamiento es uno de los aspectos más importantes de la

creación o implementación de una nueva solución mediante Azure. Hay varios servicios y
funciones disponibles para su uso y cada uno tiene su propio lugar. Azure Storage es el
almacenamiento subyacente para la mayoría de los servicios de Azure. Proporciona
servicios para el almacenamiento y recuperación de blobs y archivos, y cuenta con servicios
disponibles para almacenar grandes volúmenes de datos a través de tablas. Azure Storage
incluye un servicio de mensajería rápido y confiable para desarrolladores de aplicaciones
con colas. Este capítulo analiza cómo implementar y administrar el almacenamiento con
énfasis en las cuentas de almacenamiento de Azure.

Habilidades cubiertas en este capítulo:

 Habilidad 2.1 Configurar el acceso al almacenamiento

 Habilidad 2.2: Configurar y administrar cuentas de almacenamiento
 Habilidad 2.3: Configurar Azure Files y Azure Blob Storage

Nota Objetivos del examen de Microsoft

Las secciones de este capítulo se alinean con los objetivos que se enumeran en la guía de
estudio AZ-104 de Microsoft. Sin embargo, las secciones se presentan en un orden
diseñado para ayudarle a aprender y no coinciden directamente con el orden que se presenta
en la guía de estudio. En el examen, aparecerán preguntas de diferentes secciones en orden
aleatorio. Para obtener la lista completa de objetivos, visite https://learn.microsoft.com/en-
us/credentials/certifications/resources/study-guides/az-104 .

Habilidad 2.1: Configurar el acceso al almacenamiento

Una cuenta de almacenamiento de Azure es un recurso que usted crea y que se usa para
almacenar objetos de datos como blobs, archivos, colas, tablas y discos. Los datos de una
cuenta de almacenamiento de Azure son duraderos y de alta disponibilidad, seguros,
enormemente escalables y accesibles desde cualquier parte del mundo a través de HTTP o
HTTPS.

Esta habilidad cubre cómo:

 Crear y configurar cuentas de almacenamiento

 Configurar firewalls y redes virtuales de Azure Storage
 Crear y utilizar tokens de firma de acceso compartido (SAS)
 Configurar políticas de acceso almacenadas
 Administrar claves de acceso
 Configurar el acceso basado en identidad
Crear y configurar cuentas de almacenamiento

Las cuentas de almacenamiento de Azure proporcionan un servicio de almacenamiento

basado en la nube que es altamente escalable, disponible, eficaz y duradero. Dentro de cada
cuenta de almacenamiento, se proporcionan varios servicios de almacenamiento
independientes:

 Blobs Proporciona un servicio altamente escalable para almacenar objetos de datos

arbitrarios, como texto o datos binarios.
 Tablas Proporciona un almacén de estilo NoSQL para almacenar datos
estructurados. A diferencia de una base de datos relacional, las tablas de Azure
Storage no requieren un esquema fijo, por lo que diferentes entradas en la misma
tabla pueden tener diferentes campos.
 Colas Proporciona colas de mensajes confiables entre los componentes de la
aplicación.
 Archivos Proporciona recursos compartidos de archivos administrados que pueden
usar las máquinas virtuales de Azure o los servidores locales.
 Discos Proporciona un volumen de almacenamiento persistente para Azure VM que
se puede conectar como un disco duro virtual.

Hay tres tipos de blobs de almacenamiento: blobs en bloques, blobs en anexos y blobs en
páginas. Los blobs en páginas se usan generalmente para almacenar archivos VHD al
implementar discos no administrados. (Los discos no administrados son una tecnología de
almacenamiento en disco más antigua para máquinas virtuales de Azure. Se recomiendan
los discos administrados para nuevas implementaciones).

Al crear una cuenta de almacenamiento, se deben configurar varias opciones: nivel de

rendimiento, tipo de cuenta, opción de replicación y nivel de acceso. Hay algunas
interacciones entre estas configuraciones. Por ejemplo, solo el nivel de rendimiento
Estándar le permite elegir el nivel de acceso. Las siguientes secciones describen cada una
de estas configuraciones. Luego describimos cómo crear cuentas de almacenamiento
mediante Azure Portal, PowerShell y la CLI de Azure.

Nombres de cuentas de almacenamiento

Cuando asigna un nombre a una cuenta de almacenamiento de Azure, debe recordar estos
puntos:

 El nombre de la cuenta de almacenamiento debe ser globalmente único en todos los

nombres de cuentas de almacenamiento existentes en Azure.
 El nombre debe tener entre 3 y 24 caracteres y solo puede contener letras
minúsculas y números.
Niveles de rendimiento

Al crear una cuenta de almacenamiento, debe elegir entre los niveles de rendimiento
Estándar y Premium. Esta configuración no se puede cambiar más adelante.

 Estándar Este nivel admite todos los servicios de almacenamiento: blobs, tablas,
archivos, colas y discos de máquinas virtuales de Azure no administrados. Utiliza
discos magnéticos para proporcionar un almacenamiento rentable y confiable.
 Premium Este nivel está diseñado para soportar cargas de trabajo con mayores
demandas de E/S y está respaldado por discos SSD de alto rendimiento. Las cuentas
de almacenamiento premium admiten blobs en bloques, blobs en páginas y recursos
compartidos de archivos.

Tipos de cuenta

Hay tres tipos de cuentas de almacenamiento posibles para el nivel Estándar: StorageV2 (de
uso general V2), almacenamiento (de uso general V1) y BlobStorage. Hay cuatro tipos de
cuentas de almacenamiento posibles para el nivel Premium: StorageV2 (de uso general
V2), almacenamiento (de uso general V1), BlockBlobStorage y FileStorage. La Tabla 2-
1 muestra las características de cada tipo de cuenta. Los puntos clave para recordar son

 La cuenta de Blob Storage es una cuenta de almacenamiento especializada que se

utiliza para almacenar Block Blobs y Append Blobs. No puede almacenar blobs en
páginas en estas cuentas; por lo tanto, no puede utilizarlos para discos no
administrados.
 Solo las cuentas de uso general V2 y Blob Storage admiten los niveles de acceso
frecuente, esporádico y de archivo.

TABLA 2-1 Tipos de cuentas de almacenamiento y sus funciones admitidas

V2 de V1 de Almacenamiento
Almacenamiento Almacenamiento
uso uso de blobs en
de blobs de archivos
general general bloques

Servicios Blob, Blob, Blob (solo Blob (solo Sólo archivo

soportados Archivo, Archivo, bloques en bloques en
Cola, Cola, bloque y bloque y
Tabla Tabla anexados) anexados)

Compatibilidad Sí Sí No No No
con discos no
administrados
(blobs de
páginas)
 V2 de V1 de Almacenamiento
Almacenamiento Almacenamiento
uso uso de blobs en
de blobs de archivos
general general bloques

Niveles de Prima Prima Estándar De primera De primera

rendimiento estándar estándar calidad calidad
admitidos

Niveles de Caliente, N/A Caliente, fresco, N/A N/A

acceso fresco, archivo
admitidos archivo

Opciones de LRS, LRS, LRS, GRS, RA- LRS, ZRS LRS, ZRS
replicación ZRS, GRS, GRS
GRS, RA-
RA- GRS
GRS,
GZRS,
RA-
GZRS

Las cuentas de uso general V1 y Blob Storage se pueden actualizar a una cuenta de uso
general V2. Esta operación es irreversible. No se admiten otros cambios en el tipo de
cuenta.

Nota Tipos de cuentas de almacenamiento heredadas

Las cuentas estándar de uso general V1 y Blob Storage estándar se consideran cuentas de
almacenamiento heredadas y se pueden implementar, pero Microsoft no las recomienda.
Puede encontrar más información sobre los tipos de cuentas de almacenamiento heredadas
en https://learn.microsoft.com/en-us/azure/storage/common/storage-account-
overview#legacy-storage-account-types .

Opciones de replicación

Cuando crea una cuenta de almacenamiento, también puede especificar cómo se replicarán
sus datos para lograr redundancia y resistencia a fallas. Hay cuatro opciones, como se
describe en la Tabla 2-2 .

TABLA 2-2 Opciones de replicación de cuentas de almacenamiento

Tipo de replicación Descripción

Almacenamiento Realiza tres copias sincrónicas de sus datos dentro de un único

localmente redundante centro de datos.

(LRS) Disponible para cuentas de uso general o de Blob Storage, en

los niveles de rendimiento Estándar y Premium.

Almacenamiento Realiza tres copias sincrónicas en tres zonas de disponibilidad

redundante de zona independientes dentro de una sola región.

(ZRS) Disponible solo para cuentas de almacenamiento de uso

general V2, solo en el nivel de rendimiento estándar. También
disponible para cuentas Block Blob Storage y File Storage.

Almacenamiento Esto es lo mismo que LRS (tres copias sincrónicas locales),

geográficamente más tres copias asincrónicas adicionales en una segunda región
redundante de Azure a cientos de kilómetros de distancia de la región
principal. La replicación de datos normalmente ocurre en 15
(GRS) minutos, aunque no se proporciona ningún SLA.

Disponible para cuentas de uso general o de Blob Storage, solo

en el nivel de rendimiento estándar.

Acceso de lectura al Tiene las mismas capacidades que GRS, además tiene acceso
almacenamiento de solo lectura a los datos en el centro de datos secundario.
geográficamente
redundante Disponible para cuentas de uso general o de Blob Storage, solo
en el nivel de rendimiento estándar.
(RA-GRS)

Almacenamiento con Esto es lo mismo que ZRS (tres copias sincrónicas en

redundancia de zona múltiples zonas de disponibilidad en la región seleccionada),
geográfica (GZRS) más tres copias asincrónicas adicionales en una región de
Azure diferente a cientos de millas de la región principal. La
replicación de datos normalmente ocurre en 15 minutos,
aunque no se proporciona ningún SLA.

Disponible solo para cuentas de almacenamiento de uso

general v2, solo en el nivel de rendimiento estándar.
 Tipo de replicación Descripción

Acceso de lectura al Tiene las mismas capacidades que GZRS, además tiene acceso
almacenamiento con de solo lectura a los datos en el centro de datos secundario.
redundancia de zona
geográfica Disponible solo para cuentas de almacenamiento de uso
general V2, solo en el nivel de rendimiento estándar.
(RA-GZRS)

Opciones de replicación de notas

Estas opciones de replicación controlan el nivel de durabilidad y disponibilidad de la cuenta

de almacenamiento. Cuando todo el centro de datos no está disponible, LRS sufriría una
interrupción. Si la región principal no está disponible, las opciones LRS y ZRS sufrirían
una interrupción, pero las opciones GRS y GZRS aún proporcionarían la región secundaria
que se ocupa de las solicitudes durante la interrupción. Sin embargo, no todas las opciones
de replicación están disponibles en todas las regiones. Puede encontrar regiones
compatibles con estas opciones de replicación en https://learn.microsoft.com/en-
us/azure/storage/common/storage-redundancy .

Nota Especificación de la configuración del nivel de rendimiento y replicación

Al crear una cuenta de almacenamiento a través de Azure Portal, las opciones de

replicación y nivel de rendimiento se especifican mediante configuraciones independientes.
Al crear una cuenta mediante Azure PowerShell, la CLI de Azure o mediante una plantilla,
estas configuraciones se combinan dentro de la configuración de SKU.

Por ejemplo, para especificar una cuenta de almacenamiento estándar que utiliza
almacenamiento redundante localmente mediante la CLI de Azure, use --sku
Standard_LRS.

Niveles de acceso

Azure Blob Storage admite cuatro niveles de acceso: activo, esporádico, inactivo y archivo.
Cada uno representa una compensación de disponibilidad y costo. No hay ninguna
compensación en cuanto a la durabilidad (probabilidad de pérdida de datos), que está
definida por el SKU y la replicación, no por el nivel de acceso.

Nota Solo almacenamiento de blobs

Los niveles de acceso se aplican únicamente a Block Blob Storage. No se aplican a otros
servicios de almacenamiento, incluido el almacenamiento de blobs de páginas o anexos.

Los niveles son los siguientes:

  Caliente Este nivel de acceso se utiliza para almacenar objetos a los que se accede
con frecuencia. En comparación con otros niveles, los costos de acceso a los datos
son bajos mientras que los costos de almacenamiento son más altos.
 Cool Este nivel de acceso se utiliza para almacenar grandes cantidades de datos a
los que no se accede con frecuencia y que se almacenan durante al menos 30 días.
El SLA de disponibilidad puede variar según el modelo de replicación seleccionado.
En relación con el nivel Hot, los costos de acceso a los datos son más altos y los
costos de almacenamiento son más bajos.
 Frío Este nivel de acceso se utiliza para datos a los que rara vez se accede o
modifica, pero que deben ser accesibles sin demora. Los datos de este nivel deben
almacenarse durante al menos 90 días. El modelo de precios de nivel frío tiene
costos de capacidad de almacenamiento más bajos pero costos de acceso más altos
en comparación con los niveles frío y caliente.
 Archivo Este nivel de acceso se utiliza para archivar datos para almacenamiento a
largo plazo al que se accede raramente, puede tolerar varias horas de latencia de
recuperación y permanecerá en el nivel de Archivo.durante al menos 180 días. Este
nivel es la opción más rentable para almacenar datos, pero acceder a esos datos es
más costoso que acceder a datos en otros niveles. La rehidratación del blob puede
tardar hasta 15 horas antes de que se pueda acceder al blob.

Los nuevos blobs utilizarán de forma predeterminada el nivel de acceso establecido en el

nivel de la cuenta de almacenamiento, aunque puede invalidarlo en el nivel de blob
configurando un nivel de acceso diferente, incluido el nivel de archivo.

Nota Compatibilidad del nivel de archivo

Actualmente, el nivel de archivo no es compatible con cuentas ZRS, GZRS o RA-GZRS.

Cree una cuenta de almacenamiento de Azure

Para crear una cuenta de almacenamiento mediante Azure Portal, escriba cuentas de
almacenamiento en el cuadro de búsqueda. En la hoja Cuentas de almacenamiento, haga
clic en Crear para abrir la hoja Crear una cuenta de almacenamiento (consulte la Figura 2-
1 ). Debe elegir un nombre único para la cuenta de almacenamiento. Los nombres de las
cuentas de almacenamiento deben ser únicos a nivel mundial y solo pueden contener
caracteres y dígitos en minúsculas. Seleccione la región de Azure (ubicación), el nivel de
rendimiento y el modo de replicación de la cuenta. La hoja se ajusta según la configuración
que elija para que no pueda seleccionar una combinación de funciones no admitidas.
FIGURA 2-1 Creación de una cuenta de almacenamiento de Azure mediante Azure Portal

La pestaña Avanzado de la hoja Crear una cuenta de almacenamiento se muestra en la

Figura 2-2 . Esta pestaña define configuraciones de seguridad adicionales, compatibilidad
con espacios de nombres jerárquicos y protocolos de acceso.
FIGURA 2-2 La configuración avanzada que se puede establecer al crear una cuenta de
almacenamiento de Azure mediante el portal

La pestaña Redes de la hoja Crear una cuenta de almacenamiento se muestra en la Figura 2-

3 . En esta pestaña, elija mantener el acceso a la cuenta de almacenamiento de forma
pública eligiendo Habilitar acceso público desde todas las redes o de forma privada
eligiendo Deshabilitar acceso público y usar acceso privado.
FIGURA 2-3 Las propiedades de red que se pueden configurar al crear una cuenta de
almacenamiento de Azure mediante el portal

La pestaña Protección de datos proporciona opciones para configurar la recuperación, el

seguimiento y el control de acceso de la cuenta de almacenamiento. Esto incluye opciones
de eliminación temporal, períodos de retención, control de versiones de blobs y
compatibilidad con la inmutabilidad a nivel de versión. La Figura 2-4 muestra la pestaña
Protección de datos.
FIGURA 2-4 Las propiedades de protección de datos que se pueden configurar al crear una
cuenta de almacenamiento de Azure mediante el portal

La pestaña Cifrado proporciona opciones para configurar el tipo de cifrado, compatibilidad

con claves administradas por el cliente y cifrado de infraestructura. De forma
predeterminada, las cuentas de almacenamiento se cifran mediante claves administradas por
Microsoft. Sin embargo, puede configurar claves administradas por el cliente para cifrar
datos utilizando sus propias claves. La Figura 2-5 muestra la pestaña Cifrado.
FIGURA 2-5 Las propiedades de cifrado que se pueden configurar al crear una cuenta de
almacenamiento de Azure mediante el portal

¿Necesita más revisión? Crear una cuenta de almacenamiento con PowerShell

Puede obtener más información sobre los parámetros adicionales

en https://learn.microsoft.com/en-us/powershell/module/az.storage/new-
azstorageaccount?view=azps-11.2.0 .

¿Necesita más revisión? Crear una cuenta de almacenamiento con la CLI de Azure

Puede obtener más información sobre los parámetros adicionales

en https://learn.microsoft.com/en-us/cli/azure/storage/account?view=azure-cli-latest#az-
storage-account-create .

Configurar firewalls y redes virtuales de Azure Storage

Las cuentas de almacenamiento se administran a través de Azure Resource Manager. Las

operaciones de administración se autentican y autorizan mediante Microsoft Entra ID
RBAC. Cada servicio de almacenamiento expone su propio punto de conexión utilizado
para administrar los datos en ese servicio de almacenamiento (blobs en Blob Storage,
entidades en tablas, etc.). Estos puntos de conexión específicos del servicio no se exponen a
través de Azure Resource Manager; en cambio, son (de forma predeterminada) puntos
finales con acceso a Internet.
El acceso a estos puntos de conexión de almacenamiento conectados a Internet debe estar
protegido y Azure Storage proporciona varias formas de hacerlo. En esta sección, revisará
los controles de acceso a nivel de red: el firewall de almacenamiento y los puntos finales de
servicio. En esta sección también se analizan los niveles de acceso de Blob Storage. Las
siguientes secciones describen los controles a nivel de aplicación: firmas de acceso
compartido y claves de acceso. En secciones posteriores, aprenderá sobre la replicación de
Azure Storage y cómo aprovechar la autenticación de Microsoft Entra ID para una cuenta
de almacenamiento.

Cortafuegos de almacenamiento

Con el firewall de almacenamiento, puede limitar el acceso a direcciones IP específicas o a

un rango de direcciones IP. Se aplica a todos los puntos finales de servicios de
almacenamiento (blobs, tablas, colas y archivos). Por ejemplo, al limitar el acceso al rango
de direcciones IP de su empresa, se bloqueará el acceso desde otras ubicaciones. Los puntos
de conexión de servicio se usan para restringir el acceso a subredes específicas dentro de
una red virtual de Azure.

Para configurar el firewall de almacenamiento mediante Azure Portal, abra la hoja de la

cuenta de almacenamiento y haga clic en Redes. En Acceso a la red pública, seleccione
Habilitado desde redes virtuales y direcciones IP seleccionadas para revelar la
configuración del Firewall y las redes virtuales, como se muestra en la Figura 2-6 .

Al acceder a la cuenta de almacenamiento a través de Internet, utilice el firewall de

almacenamiento para especificar las direcciones IP de origen conectadas a Internet (por
ejemplo, 32.54.231.0/24, como se muestra en la Figura 2-6 ) que realizarán las solicitudes
de almacenamiento. Se deniega todo el tráfico de Internet, excepto las direcciones IP
definidas en el firewall de almacenamiento. Puede especificar una lista de direcciones IPv4
individuales o rangos de direcciones CIDR IPv4. (La notación CIDR se explica en la
Habilidad 4.1 del Capítulo 4 , “ Configurar y administrar redes virtuales ”).
FIGURA 2-6 Configuración de un firewall de cuenta de almacenamiento y acceso al punto
final del servicio de red virtual

El firewall de almacenamiento incluye una opción para permitir el acceso desde servicios
confiables de Microsoft. Como ejemplo, estos servicios incluyen Azure Backup, Azure Site
Recovery, Azure Networking y más. Por ejemplo, permitirá el acceso al almacenamiento
para los registros de flujo de NSG si se selecciona Permitir que los servicios confiables de
Microsoft accedan a esta cuenta. Por separado, puede habilitar Permitir acceso de lectura al
registro de almacenamiento desde cualquier red o Permitir acceso de lectura a métricas de
almacenamiento desde cualquier red para permitir el acceso de solo lectura a métricas y
registros de almacenamiento.

Nota Espacio de direcciones para un firewall de almacenamiento

Al crear un firewall de almacenamiento, debe utilizar un espacio de direcciones IP públicas

de Internet. No puede utilizar IP en el espacio de direcciones IP privadas. Además, no
puede utilizar /32 o /31 como rango CIDR; debe especificar las direcciones IP individuales
para rangos individuales o pequeños.

Puntos finales de servicio de red virtual

En algunos escenarios, solo se accede a una cuenta de almacenamiento desde una red
virtual de Azure. En este caso, desde el punto de vista de la seguridad, es deseable bloquear
todo acceso a Internet. Al configurar puntos finales del servicio de red virtual para su
cuenta de almacenamiento de Azure, puede eliminar el acceso a la Internet pública y
permitir solo el tráfico desde una red virtual para mejorar la seguridad.

Otro beneficio de utilizar puntos finales de servicio es el enrutamiento optimizado. Los

puntos finales del servicio crean una ruta de red directa desde la red virtual al servicio de
almacenamiento. Si la tunelización forzada esAl usarse para forzar el tráfico de Internet a
su red local o a otro dispositivo de red, las solicitudes a Azure Storage seguirán la misma
ruta. Al utilizar puntos de conexión de servicio, puede utilizar una ruta directa a la cuenta
de almacenamiento en lugar de la ruta local, de modo que no se produzca latencia
adicional.

La configuración de puntos finales de servicio requiere dos pasos. Primero, para actualizar
la configuración de la subred, debe elegir su red virtual en la hoja Redes virtuales. Luego
seleccione Subredes a la izquierda en Configuración. Haga clic en la subred que planea
configurar para acceder a la configuración de subred. Después de seleccionar la subred
deseada, en Puntos finales de servicio, elija Microsoft.Storage en el menú desplegable
Servicios. Esto crea la ruta desde la subred al servicio de almacenamiento, pero no restringe
qué cuenta de almacenamiento puede usar la red virtual. La Figura 2-7 muestra la
configuración de la subred, incluida la configuración del punto final del servicio.
FIGURA 2-7 Configuración de una subred con un punto final de servicio para Azure
Storage

El segundo paso es configurar qué redes virtuales pueden acceder a una cuenta de
almacenamiento en particular. En la hoja de la cuenta de almacenamiento, haga clic en
Redes. En Acceso a la red pública, haga clic en Habilitado desde redes virtuales y
direcciones IP seleccionadas para revelar la configuración del Firewall y la red virtual,
como se muestra anteriormente en la Figura 2-1 . En Redes virtuales, seleccione Agregar
red virtual existente para agregar las redes y subredes virtuales que deberían tener acceso a
esta cuenta de almacenamiento.

Niveles de acceso a Blob Storage

Las cuentas de almacenamiento admiten un mecanismo de control de acceso adicional que

se limita únicamente a Blob Storage. De forma predeterminada, no se habilita ningún
acceso de lectura público para usuarios anónimos y solo los usuarios con derechos
otorgados a través de RBAC o con el nombre y la clave de la cuenta de almacenamiento
tendrán acceso a los blobs almacenados. Para habilitar el acceso de usuarios anónimos,
debe habilitar Permitir acceso anónimo a Blob (que se muestra en la Figura 2-8 ) y
configurar el nivel de acceso al contenedor (que se muestra en la Figura 2-9 ).

FIGURA 2-8 Configuración de la cuenta de almacenamiento

FIGURA 2-9 Niveles de acceso a Blob Storage

El nivel de acceso anónimo para un contenedor se puede especificar durante la creación o

modificar después de su creación. Los niveles admitidos de contenedores de blobs son los
siguientes:

 Privado Solo las entidades principales con permisos pueden acceder al contenedor
y sus blobs. Se deniega el acceso anónimo.
 Blob Sólo se puede acceder de forma anónima a los blobs dentro del contenedor.
 Se puede acceder a Container Blobs y sus contenedores de forma anónima.

Puede cambiar el nivel de acceso a través de Azure Portal, Azure PowerShell, la CLI de
Azure, mediante programación mediante la API REST o mediante Azure Storage Explorer.
El nivel de acceso se configura por separado en cada contenedor de blobs.

Un token de firma de acceso compartido (token SAS) es un parámetro de cadena de

consulta de URI que otorga acceso a contenedores, blobs, colas y/o tablas. Utilice un token
SAS para otorgar acceso a un cliente o servicio que no debería tener acceso a todo el
contenido de la cuenta de almacenamiento (y, por lo tanto, no debería tener acceso a las
claves de la cuenta de almacenamiento) pero que aún requiere autenticación segura. Al
distribuir un URI de SAS a estos clientes, puede otorgarles acceso a un recurso específico,
durante un período de tiempo específico y con un conjunto específico de permisos. Los
tokens SAS se utilizan comúnmente para leer y escribir datos en las cuentas de
almacenamiento de los usuarios. Además, los tokens SAS se utilizan ampliamente para
copiar blobs o archivos a otra cuenta de almacenamiento.

Nota: tokens SAS que utilizan HTTPS

Cuando trabaje con tokens SAS, debe utilizar únicamente el protocolo HTTPS. Dado que
los tokens SAS activos proporcionan autenticación directa a su cuenta de almacenamiento,
debe utilizar una conexión segura, como HTTPS, para distribuir los URI de los tokens SAS.

Crear y utilizar tokens de firma de acceso compartido (SAS)

Hay algunas formas diferentes de crear un token SAS. Un token SAS es una forma de
controlar de forma granular cómo un cliente puede acceder a los datos en una cuenta de
almacenamiento de Azure. También puede utilizar una SAS a nivel de cuenta para acceder
a la cuenta misma. Puede controlar muchas cosas, como a qué servicios y recursos puede
acceder el cliente, qué permiso tiene el cliente, durante cuánto tiempo es válido el token y
más.

Esta sección examina cómo crear tokens SAS utilizando varios métodos. La forma más
sencilla de crear uno es mediante Azure Portal. Busque la cuenta de almacenamiento de
Azure y abra la hoja Firma de acceso compartido (consulte la Figura 2-10 ). Puede verificar
los servicios, tipos de recursos y permisos según requisitos específicos, junto con la
duración de la validez del token SAS y las direcciones IP que brindan acceso. Por último,
tiene la opción de elegir qué clave desea utilizar como clave de firma para este token.
FIGURA 2-10 Creación de una firma de acceso compartido mediante Azure Portal

Una vez que se genera el token, aparecerá junto con la cadena de conexión y las URL de
SAS, como se muestra en la Figura 2-11 .
FIGURA 2-11 Token SAS generado con cadena de conexión y URL de SAS

Además, puede crear tokens SAS utilizando Storage Explorer o las herramientas de línea de
comandos (o mediante programación utilizando las API/SDK de REST). Para crear un
token de SAS mediante Storage Explorer, primero debe seleccionar el recurso (cuenta de
almacenamiento, contenedor, blob, etc.) para el cual se debe crear el token de SAS. Luego
haga clic derecho en el recurso y seleccione Obtener firma de acceso compartido. La Figura
2-12 muestra cómo crear un token SAS mediante Azure Storage Explorer.
FIGURA 2-12 Creación de una firma de acceso compartido mediante Azure Storage
Explorer

¿Necesita más revisión? Explorador de almacenamiento de Azure

Azure Storage Explorer es una descarga gratuita de Microsoft que permite una cómoda
gestión del almacenamiento en la nube desde su dispositivo. Obtenga más información
sobre Azure Storage Explorer en https://azure.microsoft.com/en-
us/products/storage/storage-explorer/ .

Utilice firmas de acceso compartido

Cada token de SAS es un parámetro de cadena de consulta que se puede agregar al URI
completo del blob u otro recurso de almacenamiento para el que se creó el token de SAS.
Cree el URI de SAS agregando el token de SAS al URI completo del blob u otro recurso de
almacenamiento.
El siguiente ejemplo muestra la combinación con más detalle. Supongamos que el nombre
de la cuenta de almacenamiento es examref, el nombre del contenedor de blobs es
examrefcontainer y la ruta del blob es sample-file.png. El URI completo del blob
almacenado es

Haga clic aquí para ver la imagen del código

https://examrefstorage.blob.core.windows.net/examrefcontainer/sample-file.png

El URI combinado con el token SAS generado es

Haga clic aquí para ver la imagen del código

https://examrefstorage.blob.core.windows.net/examrefcontainer/sample-
file.png?sv=2024-

01-02&ss=bfqt&srt=sco&sp=rwdlacupx&se=2024-02-02T08:50:14Z&st=2024-01-
01T00:50:14Z&spr=h

ttps&sig=65tNhZtj2lu0tih8HQtK7aEL9YCIpGGprZocXjiQ%2Fko%3D

Actualmente, la política de acceso almacenado no es compatible con SAS a nivel de cuenta.

¿Necesita más revisión? Nivel de cuenta SAS

Puede obtener más información sobre el SAS a nivel de cuenta

en https://learn.microsoft.com/en-us/rest/api/storageservices/create-account-sas .

Usar delegación de usuarios SAS

También puede crear una delegación de usuarios SAS utilizando las credenciales de
Microsoft Entra ID. La delegación de usuarios SAS solo es compatible con Blob Storage y
puede otorgar acceso a contenedores y blobs. Actualmente, SAS no es compatible con la
delegación de usuarios SAS.

¿Necesita más revisión? Delegación de Usuarios SAS

Puede obtener más información sobre la delegación de usuarios SAS

en https://learn.microsoft.com/en-us/rest/api/storageservices/create-user-delegation-sas .

Configurar políticas de acceso almacenadas

Un token SAS incorpora los parámetros de acceso (hora de inicio y finalización, permisos,
etc.) como parte del token. Los parámetros no se pueden cambiar sin generar un token
nuevo y la única forma de revocar un token existente antes de su fecha de vencimiento es
regenerar la clave de la cuenta de almacenamiento utilizada para generar el token o eliminar
el blob. En la práctica, estas limitaciones pueden dificultar la gestión de los tokens SAS
estándar.
Las políticas de acceso almacenadas permiten que los parámetros de un token SAS se
desacoplen del propio token. La política de acceso especifica la hora de inicio, la hora de
finalización y los permisos de acceso, y la política de acceso se crea independientemente de
los tokens SAS. Se generan tokens SAS que hacen referencia a la política de acceso
almacenada en lugar de incorporar los parámetros de acceso explícitamente.

Con esta disposición, los parámetros de los tokens existentes se pueden modificar
simplemente editando la política de acceso almacenada. Los tokens SAS existentes siguen
siendo válidos y utilizan los parámetros actualizados. Puede revocar el token SAS
eliminando la política de acceso, cambiándole el nombre (cambiando el identificador) o
cambiando el tiempo de vencimiento.

Nota Efecto de la política de acceso almacenado

Una política de acceso almacenada puede tardar hasta 30 segundos en surtir efecto y los
usuarios pueden ver un HTTP 403 al intentar acceder durante ese tiempo.

La Figura 2-13 muestra la creación de políticas de acceso almacenadas en Azure Portal.

FIGURA 2-13 Creación de políticas de acceso almacenadas mediante Azure Portal

La Figura 2-14 muestra las políticas de acceso almacenadas que se crean en Azure Storage
Explorer.
FIGURA 2-14 Creación de políticas de acceso almacenadas mediante Azure Storage
Explorer

Para utilizar las políticas creadas, haga referencia a ellas por su nombre al crear un token
SAS mediante Storage Explorer o al crear un token SAS mediante PowerShell o las
herramientas CLI.

Nota Políticas de acceso máximo

Puede tener un máximo de cinco políticas de acceso en un contenedor, tabla, cola o recurso
compartido de archivos.

Administrar claves de acceso

La forma más sencilla de administrar el acceso a una cuenta de almacenamiento es utilizar

claves de acceso. Con el nombre de la cuenta de almacenamiento y una clave de acceso a la
cuenta de almacenamiento de Azure, tiene acceso completo a todos los datos en todos los
servicios dentro de la cuenta de almacenamiento. Puede crear, leer, actualizar y eliminar
contenedores, blobs, tablas, colas y recursos compartidos de archivos. Además, tiene acceso
administrativo completo a todo lo que no sea la cuenta de almacenamiento. (No puede
eliminar la cuenta de almacenamiento ni cambiar la configuración de la cuenta de
almacenamiento, como su tipo).
Las aplicaciones usarán el nombre y la clave de la cuenta de almacenamiento para acceder
a Azure Storage. A veces, esto es para otorgar acceso generando un token SAS y, a veces,
es para acceso directo con el nombre y la clave.

Para acceder al nombre y la clave de la cuenta de almacenamiento, abra la cuenta de

almacenamiento desde Azure Portal y haga clic en Claves de acceso. La Figura 2-
15 muestra las claves de acceso primaria y secundaria para una cuenta de almacenamiento.

FIGURA 2-15 Claves de acceso para una cuenta de almacenamiento de Azure

Cada cuenta de almacenamiento tiene dos claves de acceso. Esto significa que puede
modificar aplicaciones para usar la segunda clave en lugar de la primera y luego regenerar
la primera clave. Esta técnica se conoce como "rotación de claves" o "rotación de claves".
Puede restablecer la clave principal sin tiempo de inactividad para las aplicaciones que
acceden directamente al almacenamiento mediante una clave de acceso.

Las claves de acceso a la cuenta de almacenamiento se pueden regenerar mediante Azure

Portal o las herramientas de línea de comandos. En PowerShell, esto se logra con el cmdlet
New-AzStorageAccountKey; Con la CLI de Azure, utilizará el comando az Storage
account key renew.
Nota Claves de acceso y tokens SAS

La regeneración de una clave de acceso a una cuenta de almacenamiento invalidará

cualquier token SAS que se haya generado con esa clave.

Administrar claves de acceso en Azure Key Vault

Es importante proteger las claves de acceso a la cuenta de almacenamiento porque brindan

acceso completo a la cuenta de almacenamiento. Azure Key Vault ayuda a proteger las
claves criptográficas y los secretos utilizados por las aplicaciones y servicios en la nube,
como claves de autenticación, claves de cuentas de almacenamiento, claves de cifrado de
datos y claves privadas de certificados.

Las claves en Azure Key Vault se pueden proteger mediante software o mediante módulos
de seguridad de hardware (HSM). Las claves HSM se pueden generar in situ o importarse.
La importación de claves a menudo se denomina "traiga su propia clave" o BYOK.

¿Necesita más revisión? Uso de claves protegidas por HSM para Azure Key Vault

Puede obtener más información sobre el escenario de traer su propia clave (BYOK)
aquí: https://learn.microsoft.com/en-us/azure/key-vault/keys/hsm-protected-keys .

Normalmente, un desarrollador realiza el acceso y el descifrado de las claves almacenadas,

aunque también se puede acceder a las claves de Key Vault desde plantillas ARM durante
la implementación.

¿Necesita más revisión? Acceso a claves cifradas desde Azure Key Vault

Puede obtener más información sobre cómo los desarrolladores recuperan y utilizan de
forma segura secretos de Azure Key Vault aquí: https://learn.microsoft.com/en-
us/azure/storage/blobs/storage-encrypt-decrypt-blobs-key-vault? tabs=roles-azure-
portal%2Cpackages-dotnetcli .

Configurar el acceso basado en identidad

La autenticación Microsoft Entra ID es beneficiosa para los clientes que desean controlar el
acceso a los datos a nivel empresarial en función de sus estándares de seguridad y
cumplimiento. La autenticación Entra ID proporciona acceso basado en identidad al
almacenamiento de Azure, además de los mecanismos de autorización de token SAS y
clave compartida existentes para Azure Storage (Blob y Queue). Los blobs, archivos y
colas de Azure son compatibles con la autenticación de Entra ID.

La autenticación de ID de Entra permite a los clientes aprovechar RBAC en Azure para

otorgar los permisos necesarios a una entidad principal de seguridad (usuarios, grupos y
aplicaciones) hasta el alcance de una cola o contenedor de blobs individual. Mientras
autentica una solicitud, Entra ID devuelve un token de OAuth 2.0 a la entidad de seguridad,
que se puede usar para la autorización en Azure Storage.

La autorización de Entra ID se puede implementar de muchas maneras, como asignando

roles RBAC a una entidad principal de seguridad (usuarios, grupos y aplicaciones),
utilizando una identidad administrada o creando firmas de acceso compartido firmadas por
credenciales de Entra ID.

Si una aplicación se ejecuta desde una entidad de Azure, como una máquina virtual de
Azure, un conjunto de escalado de máquinas virtuales o una aplicación de Azure Functions,
puede usar una identidad administrada para acceder a una cuenta de almacenamiento.

¿Necesita más revisión? Autorizar el acceso

Puede encontrar más información sobre cómo autorizar el acceso a datos con identidades
administradas para recursos de Azure en https://learn.microsoft.com/en-
us/azure/storage/blobs/authorize-access-azure-active-directory .

Roles de RBAC para blobs y colas

Hay varios roles RBAC integrados disponibles en Azure para autorizar el acceso a Blob y
Queue Storage:

 Propietario de datos de Storage Blob Establece la propiedad y administra el

control de acceso POSIX para Azure Data Lake Storage Gen2
 Colaborador de datos de Storage Blob Otorga permisos de lectura, escritura y
eliminación para Blob Storage
 Lector de datos de Storage Blob Otorga permisos de solo lectura para Blob
Storage
 Colaborador de datos de la cola de almacenamiento Otorga permisos de
lectura/escritura/eliminación para el almacenamiento de la cola
 Lector de datos de cola de almacenamiento Otorga permisos de solo lectura para
almacenamiento de cola
 Procesador de mensajes de datos de cola de almacenamiento Otorga permisos de
visualización, recuperación y eliminación de mensajes en colas
 Remitente de mensajes de datos de cola de almacenamiento Otorga permisos
para agregar mensajes a las colas
 Colaborador de datos de tabla de almacenamiento Permite acceso de lectura,
escritura y eliminación a tablas y entidades.
 Lector de datos de tablas de almacenamiento Proporciona acceso de solo lectura
a tablas y entidades.

¿Necesita más revisión? Detalles de funciones integradas

Para obtener más información sobre los roles integrados,
consulte https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-
roles#storage .

Alcance de recursos para blobs y colas

También es importante determinar el alcance del acceso de la entidad de seguridad antes de

asignar una función RBAC. Puede limitar el alcance al nivel de contenedor, cola o tabla.
Estos son los alcances válidos:

 Contenedor La asignación de roles será aplicable a nivel de contenedor. Todos los

blobs dentro del contenedor, las propiedades del contenedor y los metadatos
heredarán la asignación de roles cuando se seleccione este ámbito.
 Cola La asignación de roles será aplicable a nivel de cola. Todos los mensajes
dentro de la cola, así como las propiedades y los metadatos de la cola, heredarán la
asignación de roles cuando se seleccione este ámbito.
 Tabla La asignación de roles será aplicable a nivel de tabla. Se podrá acceder a
todas las tablas y entidades dentro de la cuenta de almacenamiento según la
asignación de roles con este alcance.
 Cuenta de almacenamiento La asignación de roles se aplicará a nivel de cuenta de
almacenamiento. Todos los contenedores, blobs, colas y mensajes dentro de la
cuenta de almacenamiento heredarán la asignación de roles cuando se seleccione
este ámbito.
 Grupo de recursos La asignación de roles será aplicable a nivel del grupo de
recursos. Todos los contenedores o colas de todas las cuentas de almacenamiento
del grupo de recursos heredarán la asignación de roles cuando se seleccione este
alcance.
 Suscripción La asignación de roles será aplicable en el nivel de suscripción. Todos
los contenedores o colas de todas las cuentas de almacenamiento de todos los
grupos de recursos de la suscripción heredarán la asignación de funciones cuando se
seleccione este ámbito.

Entra autenticación y autorización de ID en el portal de Azure

En el siguiente ejemplo, aprenderá cómo configurar el método de autenticación de Entra ID

para permitir que los usuarios accedan a los datos del blob.

En la Figura 2-16 , puede ver que el contenedor examref tiene un blob llamado
SampleFile.txt. Además, observe que el método de autenticación está actualmente
configurado como Clave de acceso.
FIGURA 2-16 La hoja Descripción general de examrefcontainer

Haga clic en Cambiar a cuenta de usuario de Microsoft Entra para cambiar el método de
autenticación. Verá un mensaje de advertencia que indica que no tiene permiso para
enumerar los datos (consulte la Figura 2-17 ).

FIGURA 2-17 Mensaje de advertencia de que no tiene permiso

Ahora asignará la función Lector de datos de Storage Blob al usuario que inició sesión en el
nivel de contenedor.

1. Abra la hoja Control de acceso (IAM) para el contenedor y seleccione Agregar,

Agregar asignación de roles.
 2. En la pestaña Función, seleccione la función Lector de datos de Storage Blob y
luego haga clic en Siguiente.
3. En la pestaña Miembros, seleccione su cuenta de usuario.
4. Haga clic en Revisar + Asignar dos veces para aplicar la asignación de roles
(consulte la Figura 2-18 ).

FIGURA 2-18 Asignación de funciones de lector de datos de Storage Blob

Ahora debería ver al usuario con la función Lector de datos de Storage Blob, que aparece
bajo el encabezado Función (consulte la Figura 2-19 ).
FIGURA 2-19 Asignaciones de roles para examrefcontainer

Si ahora navega a la hoja Descripción general de examref, verá el blob SampleFile.txt con
el método de autenticación que se muestra como Cuenta de usuario de Microsoft Entra
(consulte la Figura 2-20 ).

Nota Las funciones de RBAC entran en vigor

A veces, los roles RBAC tardan hasta cinco minutos en propagar las asignaciones de roles.

FIGURA 2-20 La hoja Descripción general de examrefcontainer

Habilidad 2.2: Configurar y administrar cuentas de almacenamiento

Las cuentas de almacenamiento de Azure incluyen varias opciones de replicación para

determinar cómo se almacenan los datos en la región principal de Azure y en la región
replicada secundaria. La cuenta de almacenamiento se puede configurar para duplicar datos
solo en la región principal o replicarlos en una región secundaria de Azure. Las cuentas de
almacenamiento también brindan opciones de cifrado para usar la clave predeterminada
administrada por Microsoft o para traer su propia clave usando Azure Key Vault. En una
parte posterior de esta habilidad, también aprenderá a utilizar herramientas como Azure
Storage Explorer y AzCopy.

Esta habilidad cubre cómo:

 Configurar la redundancia del almacenamiento de Azure

 Configurar la replicación de objetos
 Configurar el cifrado de la cuenta de almacenamiento
 Administrar datos mediante Azure Storage Explorer
 Administrar datos usando AzCopy

Configurar la redundancia del almacenamiento de Azure

Los datos de sus cuentas de almacenamiento de Azure siempre se replican para mayor
durabilidad y alta disponibilidad. Las opciones de replicación de almacenamiento
integradas se analizaron en detalle en la Tabla 2-2 . Es importante comprender cuándo se
debe utilizar cada opción de replicación y el nivel de disponibilidad que necesita para su
escenario. La Tabla 2-3 describe los escenarios y la disponibilidad esperada para cada una
de las opciones de replicación.

TABLA 2-3 Durabilidad y disponibilidad para diversas opciones de replicación

Guión LRS ZRS GRS RA-GRS

Tipos de GPv21, GPv2 GPv1, GPv2, gota GPv1, GPv2, gota

cuentas de GPv12, gota
almacenamiento
admitidas

Servidor u otra Disponible Disponible Disponible Disponible

falla dentro de
un centro de
datos
 Guión LRS ZRS GRS RA-GRS

Fallo que afecta No disponible Disponible Disponible Disponible

a todo un centro
de datos (como
un incendio)

Fallo que afecta No disponible No disponible Conmutación por Acceso de lectura

a todos los error a la región solo hasta que se
centros de datos secundaria produzca una
de una región conmutación por
(como un error
huracán
importante)

Durabilidad Al menos Al menos Al menos Al menos

diseñada 99,999999999 99,9999999999 99,99999999999999 99,99999999999999
por ciento por ciento por ciento por ciento

SLA de Al menos el Al menos el Al menos el 99,9 Al menos el 99,99

disponibilidad 99,9 por 99,9 por ciento por ciento (99 por por ciento (99,9 por
para solicitudes ciento (99 por (99 por ciento ciento para el nivel ciento para el nivel
de lectura ciento para el para el nivel de de acceso no de acceso no
nivel de acceso no disponible) disponible)
acceso no disponible)
disponible)

SLA de Al menos el Al menos el Al menos el 99,9 Al menos el 99,9

disponibilidad 99,9 por 99,9 por ciento por ciento (99 por por ciento (99 por
para solicitudes ciento (99 por (99 por ciento ciento para el nivel ciento para el nivel
de escritura ciento para el para el nivel de de acceso no de acceso no
nivel de acceso no disponible) disponible)
acceso no disponible)
disponible)

Las cuentas de almacenamiento se pueden modificar entre los modos de replicación LRS,
GRS y RA-GRS. Azure replicará los datos de forma asincrónica en segundo plano según
sea necesario.

Puede configurar el modo de replicación para una cuenta de almacenamiento después de

crearla a través de Azure Portal haciendo clic en el vínculo Redundancia en la cuenta de
almacenamiento y seleccionando una opción en el menú desplegable Redundancia
(consulte la Figura 2-21 ). Tenga en cuenta que cambiar la opción de replicación también
puede generar una diferencia de precio significativa según las opciones que seleccione.

FIGURA 2-21 La hoja Redundancia de una cuenta de almacenamiento de Azure

¿Necesita más revisión? Más ejemplos con PowerShell

Existen muchas variaciones para utilizar el servicio de copia asíncrona con PowerShell.
Para obtener más información, consulte lo siguiente: https://learn.microsoft.com/en-
us/powershell/module/az.storage/start-azstorageblobcopy?view=azps-11.2.0 .

¿Necesita más revisión? Más ejemplos con CLI

Existen muchas variaciones para usar el servicio de copia asíncrona con la CLI de Azure.
Para obtener más información, consulte https://learn.microsoft.com/en-
us/cli/azure/storage/blob/copy?view=azure-cli-latest .

Configurar la replicación de objetos

La replicación de objetos de blobs de Azure Storage proporciona una replicación

asincrónica de blobs en bloques de una cuenta de almacenamiento a otra. Los blobs se
replican según las reglas de replicación definidas.

El uso de la replicación de objetos requiere que las opciones de control de versiones de

blobs estén habilitadas para las cuentas de almacenamiento de origen y de destino. Además,
la cuenta de almacenamiento de origen debe tener habilitada la fuente de cambios de blobs.
Si estas configuraciones no están habilitadas, se habilitarán automáticamente cuando cree la
primera regla de replicación. Esta configuración podría aumentar los costos de la cuenta de
almacenamiento.
Nota Control de versiones de blobs y fuente de cambios de blobs

El control de versiones de blobs captura el estado de un blob cuando se modifica o elimina;

Azure Storage crea un nuevo identificador de versión para un blob con cada cambio. La
fuente de cambios de blobs proporciona todos los cambios con los blobs y sus metadatos en
forma de registros transaccionales.

Existen varios beneficios que puede obtener al utilizar la replicación de objetos:

 Para trabajos de procesamiento de datos de gran tamaño, puede analizar los datos en
una sola región y distribuir los resultados a regiones adicionales según sea
necesario. Esto ahorra tiempo de procesamiento y recursos informáticos para
realizar lo mismo en todas las regiones.
 Con la replicación, los usuarios también pueden leer datos de la región replicada.
Por lo tanto, puede reducir la latencia de sus solicitudes de lectura brindándoles la
flexibilidad de elegir la región más cercana para leer los datos.
 Las cargas de trabajo informáticas ahora pueden procesar los mismos conjuntos de
blobs en bloques en diferentes regiones mediante la replicación de objetos.
 Puede reducir los costos moviendo sus datos replicados al nivel de archivo mediante
políticas de administración del ciclo de vida.

Tenga en cuenta que la replicación de objetos realiza múltiples transacciones de lectura y

escritura en las cuentas de origen y de destino. Esto puede generar costos adicionales.

Para configurar las reglas de replicación de objetos, abra la cuenta de almacenamiento,

busque Replicación de objetos en Administración de datos y haga clic en Crear reglas de
replicación (consulte la Figura 2-22 ). Puede definir hasta 10 reglas de replicación por
política mediante Azure Portal, o hasta 1000 si usa JSON para cargar las reglas.
FIGURA 2-22 Opción Crear reglas de replicación en la hoja Replicación de objetos

Debe seleccionar la suscripción de destino y la cuenta de almacenamiento de destino que se

utilizarán para la replicación. También debe seleccionar los contenedores de origen y de
destino en un par. Puede limitar el alcance de la replicación con filtros especificando la
coincidencia de prefijo para los blobs. Consulte la Figura 2-23 .
FIGURA 2-23 La hoja Crear reglas de replicación con detalles del par de destino y
contenedor

También puede controlar cómo se copian los objetos en el contenedor de destino mediante
tres opciones: Todo, Sólo objetos nuevos y Personalizado. Si selecciona Todo, todos los
blobs que coincidan con los filtros se copiarán en el contenedor de destino, pero si
selecciona Solo objetos nuevos, solo los blobs recién agregados que coincidan con los
filtros se copiarán en el contenedor de destino. Si selecciona Personalizado, tendrá la
oportunidad de especificar manualmente una fecha y hora para copiar los blobs creados
más tarde, como se muestra en la Figura 2-24 .
FIGURA 2-24 Opción Copiar sobre para una regla de replicación

Una vez creada, la vista consolidada de las reglas de replicación se puede ver visitando la
hoja Replicación de objetos. También puede hacer clic derecho en una regla y seleccionar
Editar reglas o Descargar reglas, como se muestra en la Figura 2-25 . Las reglas
descargadas se pueden editar y reutilizar usando las opciones Cargar reglas de replicación
en lugar de volver a crearlas.
FIGURA 2-25 Reglas de replicación

Para comprobar el estado de replicación de un blob de origen, seleccione el blob de origen

para ver sus propiedades. La sección Replicación de objetos muestra el ID de la política de
replicación, el ID de la regla y el estado (consulte la Figura 2-26 ).
FIGURA 2-26 Estado de replicación

Existen ciertas limitaciones con la replicación de objetos blob que es fundamental revisar
antes de la implementación:

 La replicación de objetos no funciona con el nivel Archivo.

 Las instantáneas de blobs y las instantáneas inmutables no se admiten con la
replicación de objetos.
 La replicación de objetos no funciona con cuentas con un espacio de nombres
jerárquico (Azure Data Lake Storage Gen2).
 Debido a que los datos de los blobs en bloques se replican de forma asincrónica, no
existe ningún acuerdo de nivel de servicio cuando las cuentas están sincronizadas.
Sin embargo, puede comprobar el estado de replicación de un blob.
 La cuenta de origen sólo puede tener un máximo de dos cuentas de destino.
 Una vez que crea una política de replicación, el contenedor de destino es de solo
lectura y ya no puede realizar operaciones de escritura en él.

Configurar el cifrado de la cuenta de almacenamiento

Los datos de una cuenta de almacenamiento de Azure se cifran mediante cifrado AES de
256 bits y cumplen con FIPS 140-2. El cifrado en una cuenta de almacenamiento de Azure
se habilita automáticamente y no se puede deshabilitar.

De forma predeterminada, Microsoft administra las claves utilizadas para cifrar y descifrar
los datos. En este escenario, Microsoft es responsable del almacenamiento, la rotación, el
control y el alcance de las claves. Si su organización tiene requisitos comerciales o de
cumplimiento para administrar estos componentes, la cuenta de almacenamiento de Azure
se puede configurar para usar claves administradas por el cliente. Esta clave se usaría para
cifrar los datos para el almacenamiento de archivos y blobs únicamente.

El uso de claves administradas por el cliente requiere dos componentes de Azure

adicionales: Azure Key Vault y una identidad administrada. Azure Key Vault actúa como
repositorio seguro para almacenar la clave que seleccione para las operaciones de cifrado
en la cuenta de almacenamiento. La cuenta de almacenamiento usa la identidad
administrada para acceder y recuperar la clave del almacén de claves.

Para configurar el cifrado para una cuenta de almacenamiento de Azure, seleccione Cifrado
en el menú Cuenta de almacenamiento. En la pestaña Cifrado, seleccione Claves
administradas por el cliente. Esto mostrará los elementos de configuración adicionales,
donde puede seleccionar un almacén de claves, un tipo de identidad y una clave
existentes. La Figura 2-27 muestra la página Cifrado.
FIGURA 2-27 Cifrado de la cuenta de almacenamiento

Administrar datos mediante Azure Storage Explorer

Azure Storage Explorer es una aplicación multiplataforma diseñada para ayudarle a

administrar rápidamente una o más cuentas de almacenamiento de Azure. Se puede utilizar
con todos los servicios de almacenamiento: Blob Storage, Azure Tables, Queue Storage y
Azure Files. Además, Azure Storage Explorer también admite los servicios CosmosDB y
Azure Data Lake Storage.

Puede instalar Azure Storage Explorer navegando a su página de inicio

en https://azure.microsoft.com/features/storage-explorer/ y seleccionando su sistema
operativo (Windows, macOS o Linux).
Además, en Azure Portal se integra un explorador de almacenamiento basado en navegador
con una funcionalidad similar. Para acceder a él, haga clic en Explorador de
almacenamiento en la hoja Cuenta de almacenamiento.

Conecte Storage Explorer a cuentas de almacenamiento

Una vez instalado Storage Explorer, puede conectarse a Azure Storage de varias maneras
diferentes (como se muestra en la Figura 2-28 ):

 Suscripción Esta opción le permite iniciar sesión con una cuenta de trabajo o de
Microsoft y acceder a todas sus cuentas de almacenamiento a través del control de
acceso basado en roles.
 Cuenta o servicio de almacenamiento Esta opción requiere que usted tenga acceso
al nombre y la clave de la cuenta de almacenamiento. También se puede acceder a
estos valores desde Azure Portal en Claves de acceso.
 Contenedor o directorio de blobs Adjunte directamente solo al punto de conexión
del servicio de blobs para interactuar con un contenedor o directorio.
 Contenedor o directorio ADLS Gen2 Adjunte directamente solo a un contenedor
de Azure Data Lake Storage Gen2 en una cuenta de almacenamiento.
 Recurso compartido de archivos Adjunte directamente a un recurso compartido de
Azure Files que ya se haya creado en una cuenta de almacenamiento.
 Cola Adjunte directamente al extremo del servicio de cola de una cuenta de
almacenamiento existente.
 Tabla Adjunte directamente al punto final del servicio de tabla de una cuenta de
almacenamiento existente.
 Emulador de almacenamiento local Le permite conectarse al emulador de Azure
Storage local como parte del SDK de Microsoft Azure.
FIGURA 2-28 Conexión a una cuenta de almacenamiento de Azure mediante Azure
Storage Explorer

Después de conectarse, filtre qué suscripciones usar. Una vez que seleccione una
suscripción, todos los servicios admitidos dentro de la suscripción estarán disponibles. La
Figura 2-29 muestra un contenedor expandido de Azure Storage denominado examref.
FIGURA 2-29 Explorador de Azure Storage que muestra una cuenta de almacenamiento de
Azure debajo de la suscripción
Usar el Explorador de almacenamiento

Con Storage Explorer, puede administrar cada uno de los servicios de almacenamiento:
Blob Storage, Azure Tables, Queue Storage y Azure Files. La Tabla 2-4 resume las
operaciones admitidas para cada servicio.

TABLA 2-4 Operaciones del Explorador de almacenamiento

Servicio de
Operaciones soportadas
almacenamiento

Gota Contenedores de blobs Cree, cambie el nombre, copie, elimine,

controle el nivel de acceso público, administre concesiones y cree y
administre firmas de acceso compartido y políticas de acceso.

Blobs Cargue, descargue, administre carpetas, cambie el nombre y

elimine blobs, copie blobs, cree y administre instantáneas de blobs,
cambie el nivel de acceso a blobs y cree y administre firmas de
acceso compartido y directivas de acceso.

Mesa Tablas Cree, cambie el nombre, copie, elimine y cree y administre

firmas de acceso compartido y políticas de acceso.

Entidades de tabla Importar, exportar, ver, agregar, editar, eliminar

y consultar

Cola Colas Crear, eliminar y gestionar firmas de acceso compartido y

políticas de acceso

Mensajes Agregar, ver, quitar de la cola y borrar todos los mensajes

Archivos Recursos compartidos de archivos Crear, cambiar nombre; copie,

elimine, cree y administre instantáneas, conecte VM a archivos
compartidos y cree y administre firmas de acceso compartido y
políticas de acceso

Archivos Cargar carpetas o archivos, descargar carpetas o archivos,

administrar carpetas, copiar, renombrar y eliminar

En cada caso, Azure Storage Explorer proporciona una interfaz GUI intuitiva para cada
operación.
Copiar blobs de almacenamiento

El Explorador de Azure Storage se puede utilizar para copiar blobs de almacenamiento.

Para copiar entre cuentas de almacenamiento, navegue hasta la cuenta de almacenamiento
de origen, seleccione uno o más archivos y haga clic en Copiar en la barra de herramientas.
A continuación, navegue hasta la cuenta de almacenamiento de destino, expanda el
contenedor al que desea copiar y haga clic en Pegar en la barra de herramientas. En la
Figura 2-30 , el blob SampleFile.txt se copió del contenedor examref al contenedor
temporal mediante esta técnica.

FIGURA 2-30 Uso del servicio de copia de blobs asíncrono con Storage Explorer

Administrar datos mediante AzCopy

AzCopy es una utilidad de línea de comandos que puede usar para realizar transferencias
masivas de datos a gran escala hacia y desde Azure Storage. AzCopy realiza todas las
operaciones de forma asincrónica y puede ejecutarse simultáneamente. Además, también es
tolerante a fallos, por lo que si la operación se interrumpe por algún motivo, puede
reanudarse desde donde se quedó una vez que se resuelva el problema.

Con la última versión de AzCopy, puede realizar copias de seguridad incrementales de

blobs y mantenerlas sincronizadas para que contengan la misma versión de datos. AzCopy
se puede agregar a la ruta del sistema, para que pueda ejecutar AzCopy desde cualquier
carpeta de su sistema mientras lo usa en Windows PowerShell. De lo contrario, deberá
cambiar el directorio donde se almacena el ejecutable de AzCopy cada vez. Puede ver una
lista de comandos usando azcopy -h.

Nota AzCopy con Explorador de almacenamiento

Storage Explorer es una interfaz gráfica de usuario que utiliza AzCopy para realizar todas
sus operaciones de transferencia de datos en el backend.

AzCopy necesita una autenticación en Azure Storage antes de ejecutar cualquier operación
dentro de la sesión. Esto se puede lograr ejecutando el comando azcopy login e iniciando
sesión. AzCopy también admite otras autorizaciones, como entidad de servicio, token SAS,
clave de acceso, identidad administrada, etc. Por ejemplo, ejecute este comando para
autenticarse mediante la entidad de servicio:

Haga clic aquí para ver la imagen del código

azcopy login --service-principal --application-id <application-id>

--tenant-id=<tenant-id>

¿Necesita más revisión? Crear una aplicación Entra y un director de servicio

Puede encontrar instrucciones paso a paso sobre cómo conectar una aplicación Entra y una
entidad de servicio en https://learn.microsoft.com/en-us/entra/identity-platform/howto-
create-service-principal-portal .

Cargar y descargar datos usando AzCopy

Puede cargar datos en Azure Blob Storage mediante AzCopy. La única condición es que la
cuenta de almacenamiento y el contenedor de destino ya existan. En el siguiente ejemplo, el
archivo CreateUserTemplate.csv se copiará al contenedor de destino. Este ejemplo supone
que el archivo CSV está en la ubicación donde está ejecutando el comando azcopy .

Haga clic aquí para ver la imagen del código

azcopy copy "CreateUserTemplate.csv" "https://examref.blob.core.windows.net/

destcontainer/CreateUserTemplate.csv"

Si está utilizando un token SAS, la sintaxis sería

Haga clic aquí para ver la imagen del código

azcopy copy "CreateUserTemplate.csv" "https://examref.blob.core.windows.net/

destcontainer/CreateUserTemplate.csv?<sas token>"

Puede cargar varios archivos con estructuras de carpetas usando la opción --recursive=true
con AzCopy.

Haga clic aquí para ver la imagen del código

azcopy copy "CreateUserTemplate.csv" "https://examref.blob.core.windows.net/

destcontainer/CreateUserTemplate.csv?<sas token>"

También puede descargar los datos de Azure Blob Storage mediante AzCopy. En el
siguiente ejemplo, el archivo CreateUserTemplate.csv se descargará del srccontainer:

Haga clic aquí para ver la imagen del código

azcopy copy
"https://examref.blob.core.windows.net/srccontainer/CreateUserTemplate.csv "

"CreateUserTemplate.csv"
Copia de blob asíncrona

La aplicación AzCopy también se puede utilizar para copiar entre cuentas de

almacenamiento. En el siguiente ejemplo se muestra cómo copiar el blob desde el
contenedor de la cuenta de almacenamiento de origen al contenedor de la cuenta de
almacenamiento de destino mediante un token SAS:

Haga clic aquí para ver la imagen del código

AzCopy copy "https://examref.blob.core.windows.net/srccontainer/[blob-path]?<sas

token>"

"https://examrefdest.blob.core.windows.net/destcontainer/[blob-path]?<sas
token>"

¿Necesita más revisión? Copia Az

AzCopy versión 10 es multiplataforma y funciona con Windows, Linux y macOS. Para

obtener más información sobre AzCopy, consulte https://learn.microsoft.com/en-
us/azure/storage/common/storage-use-azcopy-v10 .

Sincronizar copia de blob

Puede usar el comando azcopy sync para sincronizar copias entre dos contenedores de
blobs. Este comando sincroniza el contenido de un contenedor de destino con un
contenedor de origen copiando blobs si la última hora de modificación de un blob en el
destino es anterior a la del blob correspondiente en el origen. De forma predeterminada, el
indicador recursivo es verdadero para el comando de sincronización y copia todos los
subdirectorios:

Haga clic aquí para ver la imagen del código

azcopy sync "https://examref.blob.core.windows.net/srccontainer/?<sas token>"

"https://examref.blob.core.windows.net/destcontainer/"

Nota Eliminar bandera de destino

Puede usar el indicador --delete-destination con el comando azcopy sync si desea eliminar
blobs en el destino que no existen en el origen. Se puede establecer en verdadero, falso o
aviso. El uso del mensaje le solicitará que elimine para hacerlo más seguro.

Habilidad 2.3: Configurar Azure Files y Azure Blob Storage

Azure Files es un servicio compartido de archivos totalmente administrado que ofrece

puntos de conexión para el protocolo Server Message Block (SMB), el protocolo Network
File System (NFS) y la API REST de Azure Files. Esto le permite crear uno o más archivos
compartidos en la nube (con un tamaño máximo predeterminado de 5 TiB por recurso
compartido). Puede habilitar archivos compartidos de gran tamaño para una cuenta de
almacenamiento y crear archivos compartidos de hasta 100 TiB. Además, si utiliza el SKU
Premium, obtendrá 100 TiB de forma predeterminada. Azure Files se puede usar como lo
haría con un servidor de archivos de Windows normal, como para almacenamiento
compartido o para nuevos usos, como parte de una estrategia de migración de tipo lift-and-
shift.

Esta habilidad cubre cómo:

 Cree y configure un recurso compartido de archivos en el almacenamiento de Azure

 Configurar el almacenamiento de blobs de Azure
 Configurar niveles de almacenamiento
 Configurar eliminación temporal, control de versiones e instantáneas
 Configurar la administración del ciclo de vida del blob

Crear y configurar un recurso compartido de archivos en Azure Storage

Existen varios casos de uso comunes para Azure Files. Algunos ejemplos incluyen los
siguientes:

 Migración de aplicaciones existentes que requieren un recurso compartido de

archivos para almacenamiento
 Almacenamiento compartido de archivos, como contenido web, archivos de
registro, archivos de configuración de aplicaciones o incluso medios de instalación.
 Reemplazo de un servidor de archivos existente

La Figura 2-31 muestra la jerarquía de archivos almacenados en Azure Files.

FIGURA 2-31 Entidades de Azure Files y jerarquía de relaciones

Crear un archivo compartido

Para crear un nuevo recurso compartido de archivos mediante Azure Portal, abra una cuenta
de almacenamiento de Azure, haga clic en Recursos compartidos de archivos y luego haga
clic en Compartir archivos. En la hoja Nuevo recurso compartido de archivos que se
muestra en la Figura 2-32 , debe proporcionar el nombre del recurso compartido de
archivos y el tamaño de la cuota, que puede ser un tamaño máximo de 5 TiB. Los archivos
compartidos de gran tamaño y las cuentas de almacenamiento premium admiten hasta 100
TiB.
FIGURA 2-32 Agregar un nuevo recurso compartido con Azure Files

Conéctese a Azure Files fuera de Azure

Debido a que Azure Files brinda soporte para SMB 3.0, es posible conectarse directamente
a un recurso compartido de archivos desde una computadora que se ejecuta fuera de Azure.
En este caso, recuerda abrir el puerto TCP saliente 445 en tu red local. Muchas empresas
bloquean 445 debido a la naturaleza insegura de SMB 1.0. Verifique sus conexiones de red
si tiene problemas para conectarse. Como alternativa, puede aprovechar una red privada
virtual o ExpressRoute donde el puerto 445 no se puede desbloquear. Tenga en cuenta que
Windows 7 y Windows Server 2008 R2 no son compatibles con SMB 3.0.

¿Necesita más revisión? Cómo eliminar SMB v1

Para deshabilitar SMB v1 de su entorno, puede deshabilitar la función smb1protocol.

Consulte el siguiente enlace para obtener más detalles: https://learn.microsoft.com/en-
us/windows-server/storage/file-server/troubleshoot/detect-enable-and-disable-smbv1-v2-
v3?tabs= server#cómo-eliminar-con-gracias-smb-v1-en-windows-81-windows-10-
windows-2012-r2-windows-server-2016-and-windows-server-2019 .

Conéctese y monte con el Explorador de archivos de Windows

Hay varias formas de montar un archivo compartido desde Windows. La primera es utilizar
la función Map Network Drive dentro del Explorador de archivos de Windows.

1. Abra el Explorador de archivos.

2. Haga clic derecho en Esta PC.
3. Seleccione Map Network Drive, como se muestra en la Figura 2-33 .

FIGURA 2-33 La opción Map Network Drive del menú contextual Esta PC

4. En el cuadro de diálogo Map Network Drive, especifique las siguientes opciones de

configuración, como se muestra en la Figura 2-34 :
1. Para Carpeta, ingrese \\[nombre de la cuenta de
almacenamiento].files.core.windows.net\[nombre del recurso compartido] .
2. Seleccione la opción Conectarse usando diferentes credenciales.
 FIGURA 2-34 Asignación de una unidad de red a un recurso compartido de
archivos de Azure

5. Cuando haga clic en Finalizar, se le pedirá que ingrese su nombre de usuario y

contraseña para acceder al archivo compartido, como se muestra en la Figura 2-35 .
El nombre de usuario debe tener el formato Azure\[nombre de la cuenta de
almacenamiento] y la contraseña debe ser la clave de acceso a la cuenta de
almacenamiento de Azure.
 FIGURA 2-35 Especificación de credenciales para el recurso compartido de
archivos de Azure

Conéctese y monte con el comando net use

También puede montar el recurso compartido de archivos de Azure mediante el comando

net use de Windows, como lo demuestra el siguiente ejemplo:

Haga clic aquí para ver la imagen del código

net use x \\examref.file.core.windows.net\logs /u:AZURE\examuser01

r21Dk4qgY1HpcbriySWrBxnXnbedZLmnRK3N49PfaiL1t3ragpQaIB7FqK5zbez/sMnDEzEu/dgA9Nq/
W7IF4A==
Volver a conectarse automáticamente después de reiniciar en Windows

Para hacer que el recurso compartido de archivos se vuelva a conectar automáticamente y

se asigne a la unidad después de reiniciar Windows, use el siguiente comando
(asegurándose de reemplazar los valores del marcador de posición):

Haga clic aquí para ver la imagen del código

cmdkey /add:<storage-account-name>.file.core.windows.net /user:AZURE\<storage-

account-name> /pass:<storage-account-key>

net use Z: \\\\<storage-account-name>.file.core.windows.net\\<file-share-name> /

persistent:yes
Conectar y montar desde Linux

Utilice el comando de montaje (elevado con sudo) para montar un recurso compartido de
archivos de Azure en una máquina virtual Linux. En este ejemplo, el recurso compartido de
archivos de registros se asignaría al punto de montaje /logs.

Haga clic aquí para ver la imagen del código

sudo mount -t cifs //<storage-account-name>.file.core.windows.net/logs /logs -o

vers=3.0,username=<storage-account-name>.,password=<storage-account

-key>,dir_mode=0777,file_mode=0777,sec=ntlmssp
Configurar el almacenamiento de blobs de Azure

En esta sección se describen las características clave del almacenamiento de blobs

proporcionado por cada cuenta de almacenamiento. Azure Blob Storage se utiliza para el
almacenamiento a gran escala de objetos de datos arbitrarios, como archivos multimedia,
archivos de registro, etc.

Contenedores de burbujas

La Figura 2-36 muestra el diseño del almacenamiento de blobs. Cada cuenta de

almacenamiento puede tener uno o más contenedores de blobs y todos los blobs deben
almacenarse dentro de un contenedor. Los contenedores son similares en concepto a una
carpeta en el disco de su computadora, en el sentido de que proporcionan un espacio de
almacenamiento para los datos en su cuenta de almacenamiento. Dentro de cada
contenedor, puede almacenar blobs, de la misma manera que almacenaría archivos en un
disco duro. Los blobs se pueden colocar en la raíz del contenedor u organizarse en una
jerarquía de carpetas.
FIGURA 2-36 Entidades de cuentas de almacenamiento de Azure y relaciones jerárquicas

Cada blob tiene una URL única. El formato de esta URL es https://[nombre de
cuenta].blob.core.windows.net/ [nombre del contenedor]/[ruta y nombre del blob].

Opcionalmente, puede crear un contenedor en la raíz de la cuenta de almacenamiento,

especificando el nombre especial $root para el nombre del contenedor. Puede almacenar
blobs en la raíz de la cuenta de almacenamiento y hacer referencia a ellos con direcciones
URL como https://[accountname].blob.core.windows.net/fileinroot.txt .

Tipos de manchas

Los blobs son de tres tipos y es importante comprender cuándo se debe utilizar cada tipo y
cuáles son las limitaciones de cada uno.

 Blobs en páginas Optimizados para operaciones de lectura y escritura de acceso

aleatorio. Los blobs en páginas se usan para almacenar archivos de discos virtuales
(VHD), que usan discos no administrados con máquinas virtuales de Azure. El
tamaño máximo del blob en páginas es 8 TiB.
 Blobs en bloques Optimizados para cargas y descargas eficientes, para videos,
imágenes y otros tipos de almacenamiento de archivos de uso general. El tamaño
máximo del blob en bloques depende de la versión de servicio API que se utilice,
con una capacidad máxima de aproximadamente 190 TiB.
 Agregar blobs Optimizado para operaciones de agregar. No se admite la
actualización o eliminación de bloques existentes en el blob. Se pueden agregar
hasta 50 000 bloques a cada blob anexo, y cada bloque puede tener un tamaño de
 hasta 4 MiB, lo que da un tamaño máximo de blob anexo de poco más de 195 GiB.
Los blobs en anexos se usan más comúnmente para archivos de registro.

Los blobs de los tres tipos pueden compartir un único contenedor de blobs.

Consejo de examen

El tipo de blob se establece en el momento de la creación y no se puede cambiar después

del hecho. Un problema común que puede aparecer en el examen es si un archivo .vhd se
cargó accidentalmente como un blob en bloques en lugar de un blob en páginas. Primero se
debe eliminar el blob y volver a cargarlo como un blob en páginas antes de poder montarlo
como sistema operativo o disco de datos en una máquina virtual de Azure.

¿Necesita más revisión? Tipos de manchas

Puede obtener más información sobre las complejidades de cada tipo de blob
aquí: https://learn.microsoft.com/en-us/rest/api/storageservices/understanding-block-blobs-
-append-blobs--and-page-blobs .

Administrar blobs y contenedores (portal de Azure)

Puede crear y administrar contenedores a través de Azure Portal, Azure Storage Explorer,
herramientas de almacenamiento de terceros o herramientas de línea de comandos. Para
crear un contenedor en el portal de administración de Azure, abra una cuenta de
almacenamiento seleccionando Todos los servicios, Cuentas de almacenamiento y luego
eligiendo su cuenta de almacenamiento. Dentro de la hoja de la cuenta de almacenamiento,
abra la hoja Contenedores y luego haga clic en + Contenedor. Las opciones de Nuevo
contenedor se muestran en la Figura 2-37 . Consulte la Habilidad 2.1 para obtener más
información sobre cómo configurar el nivel de acceso público.
FIGURA 2-37 Creación de un contenedor mediante el portal de administración de Azure

Una vez creado un contenedor, también puede utilizar el portal para cargar blobs en el
contenedor, como se muestra en la Figura 2-38 . Haga clic en Cargar en el contenedor y
luego busque el blob que desea cargar. Si hace clic en Avanzado, puede seleccionar el tipo
de blob (Blob, Página o Anexar), el tamaño del bloque y, opcionalmente, una carpeta en la
que se cargará el blob.
FIGURA 2-38 Carga de un blob en un contenedor de cuenta de almacenamiento

¿Necesita más revisión? Administrar el almacenamiento de blobs con PowerShell

Los cmdlets de Azure PowerShell ofrecen un amplio conjunto de capacidades para

administrar blobs en almacenamiento. Puede obtener más información sobre sus
capacidades aquí: https://learn.microsoft.com/en-us/azure/storage/blobs/storage-
quickstart-blobs-powershell .

¿Necesita más revisión? Administrar Blob Storage con la CLI de Azure

La CLI de Azure también ofrece un amplio conjunto de capacidades para administrar blobs
en almacenamiento. Puede obtener más información sobre sus capacidades
aquí: https://learn.microsoft.com/en-us/azure/storage/blobs/storage-quickstart-blobs-cli .

Administrar blobs y contenedores (Explorador de almacenamiento)

Azure Storage Explorer proporciona una funcionalidad completa para administrar datos de
almacenamiento, incluidos blobs y contenedores. Para crear un contenedor, expanda el
nodo Cuentas de almacenamiento, expanda la cuenta de almacenamiento que desea usar y
haga clic con el botón derecho en el nodo Contenedores de blobs. Elija Crear contenedor de
blobs en el menú desplegable, como se muestra en la Figura 2-39 .

FIGURA 2-39 Creación de un contenedor mediante Azure Storage Explorer

Azure Storage Explorer ofrece la posibilidad de cargar uno o varios archivos a la vez.
Utilice la característica Cargar carpeta para cargar todo el contenido de una carpeta local,
recreando la jerarquía en la cuenta de almacenamiento de Azure. La Figura 2-40 muestra
las dos opciones de carga.

FIGURA 2-40 Carga de archivos y carpetas mediante Azure Storage Explorer

$$$$$$

Configurar niveles de almacenamiento

Como se analizó en la habilidad 2.1 , Azure Blob Storage admite cuatro niveles de acceso:
activo, frío, frío y archivo. Cada uno representa una compensación de disponibilidad y
costo. No hay ninguna compensación en cuanto a la durabilidad (probabilidad de pérdida de
datos), que está definida por el SKU y la opción de replicación de la cuenta de
almacenamiento seleccionada.

Niveles a nivel de cuenta

Los blobs de la cuenta de almacenamiento pueden coexistir en tres niveles dentro de la

misma cuenta. Si algún blob no tiene un nivel asignado, deduce el nivel de acceso de la
configuración del nivel de acceso de la cuenta de forma predeterminada. En tal escenario,
verá que la propiedad del blob inferido del nivel de acceso está establecida en Inferido y la
propiedad del blob del nivel de acceso coincide con el nivel de cuenta. En Azure Portal, se
muestra la propiedad inferida del nivel de acceso, como se muestra en la Figura 2-41 .
FIGURA 2-41 Propiedad de nivel de acceso para niveles de cuenta

Nota Cambiar nivel de acceso a la cuenta

Los cambios en el nivel de acceso de la cuenta se aplican a todos los objetos inferidos del
nivel de acceso almacenados en la cuenta que no tienen un nivel explícito establecido.

Niveles a nivel de blob

A los blobs se les puede asignar el nivel de acceso deseado mientras los carga en el
contenedor (consulte la Figura 2-42 ). También puede cambiar el nivel de acceso entre los
niveles Caliente, Frío, Frío o Archivo (porque los patrones de uso cambian) sin tener que
mover datos entre cuentas. Todas las solicitudes para cambiar de nivel se realizarán
inmediatamente entre los niveles Hot y Cool. Se producirán costos de almacenamiento
adicionales al cambiar de nivel porque los datos deben leerse en el nivel actual y luego
escribirse en el nuevo nivel.

Nota Nivel de almacenamiento de archivos

Los datos en el nivel de almacenamiento de Archivo se almacenan sin conexión y se deben

rehidratar en otro nivel antes de poder acceder a ellos. Este proceso puede tardar hasta 15
horas.
FIGURA 2-42 Cambio del nivel de acceso al cargar los blobs en un contenedor

Cuando se cambia el nivel de acceso, la propiedad Última modificación del nivel de acceso
se actualizará con la hora en que se realizó el cambio más reciente en el nivel (consulte la
Figura 2-43 ).
FIGURA 2-43 Propiedad de última modificación del nivel de acceso para el blob

Cambiar el nivel de acceso

El nivel de acceso se puede cambiar a nivel de cuenta o a nivel de blob individual. A nivel
de cuenta, puede establecer el nivel de acceso en la hoja Configuración (la opción
predeterminada a menos que se le asigne explícitamente) o utilizando la nueva función
Administración del ciclo de vida. A nivel de blob individual, se puede lograr lo mismo
utilizando la opción Cambiar nivel para el blob.

Nota Cambiar el nivel de acceso

Cambiar el nivel de acceso a la cuenta o al contenedor generará cargos por cambio de nivel
para los blobs de nivel de acceso inferidos almacenados en la cuenta que no tienen un
conjunto de niveles explícito.

Para realizar un cambio a nivel de cuenta, busque la cuenta de almacenamiento, abra la hoja
Configuración y cambie el Nivel de acceso (predeterminado) a Frío o Activo (consulte la
Figura 2-44 ).
FIGURA 2-44 Cambiar el nivel de acceso

De manera similar, para realizar un cambio a nivel de blob, busque un blob, haga clic en
Cambiar nivel y seleccione el nivel de acceso en el menú. Sus opciones son Caliente, Fría,
Fría o Archivar (consulte la Figura 2-42 ).

Configurar eliminación temporal, control de versiones e instantáneas

Azure Storage ofrece varias opciones para recuperar datos que podrían eliminarse o
sobrescribirse accidentalmente. Estas opciones incluyen instantáneas, eliminación temporal
y seguimiento de versiones de blobs y archivos.
eliminación suave

El comportamiento predeterminado al eliminar un blob es que el blob se elimina y se pierde

para siempre. Con la eliminación temporal, puede recuperar sus datos cuando se eliminan
blobs o instantáneas de blobs, incluso en caso de sobrescritura. Esta característica debe
estar habilitada en la cuenta de almacenamiento de Azure y se debe establecer un período
de retención durante el cual los datos eliminados estarán disponibles (consulte la Figura 2-
45 ).

FIGURA 2-45 Habilitación de la eliminación temporal en una cuenta de almacenamiento

de Azure

Consejo de examen

El período máximo de retención para la eliminación temporal es de 365 días.

¿Necesita más revisión? Eliminación temporal de blobs de almacenamiento de Azure

Puede obtener más información sobre el uso de la eliminación temporal con Azure Blob
Storage aquí: https://learn.microsoft.com/en-us/azure/storage/blobs/soft-delete-blob-
overview .

La eliminación temporal también se puede configurar para recursos compartidos de Azure

Files basados en SMB. Funciona igual que los blobs donde los datos se pueden recuperar si
se eliminan accidentalmente. La eliminación temporal se configura en el nivel de la cuenta
de almacenamiento para todos los recursos compartidos de la cuenta. Para configurar la
eliminación temporal de Azure Files, navegue hasta la cuenta de almacenamiento y
seleccione Recursos compartidos de archivos. En la hoja Recursos compartidos de
archivos, seleccione Desactivado junto a Eliminación temporal. En el cuadro de diálogo
Eliminación temporal, establezca el interruptor en Habilitado y luego configure la política
de retención. La política de retención predeterminada es de 7 días, pero se puede configurar
de 1 a 365 días, como se muestra en la Figura 2-46 .

FIGURA 2-46 Eliminación temporal de archivos de Azure

Versionado

Una cuenta de almacenamiento de Azure proporciona dos opciones principales para realizar
un seguimiento de objetos blob: control de versiones y fuente de cambios. El control de
versiones se puede usar para conservar automáticamente las versiones anteriores de un
objeto blob. Puede elegir si desea conservar todas las versiones de un blob o, para ayudar
con la administración de los costos de almacenamiento, eliminar las versiones después de
una cantidad específica de días. El período de retención de las versiones se puede definir
entre 1 y 365 días, con el valor predeterminado establecido en 7 días.

Las fuentes de cambios de blobs mantienen un registro de todas las operaciones de

creación, modificación y eliminación de los objetos de blob en la cuenta de
almacenamiento. Puede configurar la cuenta para conservar todos los registros o
eliminarlos después de una determinada cantidad de días. Esto se puede configurar desde 1
día hasta 146.000 días, con un valor predeterminado de 7 días.

Para configurar el control de versiones y la fuente de cambios de blobs, navegue hasta la

hoja Protección de datos de una cuenta de almacenamiento. La Figura 2-47 muestra esta
hoja con los períodos de retención predeterminados configurados.

Instantáneas

Las instantáneas son opciones de restauración de un momento dado para contenedores y

recursos compartidos de archivos. Para usar instantáneas con contenedores de blobs, las
opciones de control de versiones de blobs y fuente de cambios de blobs deben estar
habilitadas. El uso de una instantánea con un contenedor de blobs revertirá todos los
objetos del contenedor a la versión o momento determinado que seleccione. Las
instantáneas para el almacenamiento de blobs se configuran en la hoja Protección de datos
de la cuenta de almacenamiento mediante la opción Habilitar restauración a un momento
determinado, que también se muestra en la Figura 2-47 .
FIGURA 2-47 Opciones de versiones de protección de datos

Las instantáneas también se pueden configurar para Azure Files en el nivel del recurso
compartido de archivos. A diferencia de los blobs, que se guardan con la cuenta de
almacenamiento, el uso de instantáneas para recursos compartidos de archivos requiere una
bóveda de Azure Recovery Services y una política de copia de seguridad para conservar los
datos de la versión anterior del archivo. Al igual que con los blobs, el uso de instantáneas
con archivos compartidos también requiere que la eliminación temporal esté habilitada para
los archivos compartidos de la cuenta.

Para configurar instantáneas en un recurso compartido de archivos, navegue hasta Recursos

compartidos de archivos desde la cuenta de almacenamiento y luego seleccione un recurso
compartido de archivos configurado. Desde el recurso compartido de archivos, seleccione
Instantáneas. Se le pedirá que configure o seleccione una bóveda de Azure Recovery
Services y la política y frecuencia de copia de seguridad asociada para los archivos, como
se muestra en la Figura 2-48 .

FIGURA 2-48 Instantáneas: recursos compartidos de archivos de Azure

Configurar la administración del ciclo de vida del blob

Azure Storage tiene una capacidad de administración del ciclo de vida, que se puede usar
para realizar la transición automática de datos a niveles de acceso más bajos según reglas
preconfiguradas. También puede eliminar los datos al final de su ciclo de vida. Estas reglas
se pueden ejecutar en la cuenta de almacenamiento una vez al día. Se pueden seleccionar
blobs y contenedores específicos mediante conjuntos de filtros.

Para configurar las reglas de administración del ciclo de vida, abra la cuenta de
almacenamiento, vaya a Administración del ciclo de vida en Administración de datos y
haga clic en Agregar una regla (consulte la Figura 2-49 ). Puede definir hasta 100 reglas.
FIGURA 2-49 Opción Agregar una regla en la hoja Administración del ciclo de vida

Puede limitar el alcance de la regla con un conjunto de filtros seleccionando Limitar blobs
con filtros, como se muestra en la Figura 2-50 . También puede seleccionar el tipo de blob
y el subtipo de blob que deberían aplicarse a esta regla. También puede seleccionar Agregar
blobs, instantáneas y versiones. Luego haga clic en Siguiente.
FIGURA 2-50 Sección de detalles para una nueva regla en Gestión del ciclo de vida

Puede configurar reglas en la página Blobs base para definir la política de ciclo de vida del
blob. Puede crear varios bloques si-entonces para definir las distintas condiciones. Por
ejemplo, puede mover datos de blobs a un almacenamiento de refrigeración si no se
modifican durante el número de días especificado. De manera similar, también puede crear
reglas para mover blobs a un almacenamiento en frío o de archivo, o eliminarlos si no se
modifican durante la cantidad de días definida. En la Figura 2-51 , la condición se creó
durante 30 días y las cuatro acciones se muestran en el menú desplegable. Haga clic en
Siguiente para configurar el conjunto de filtros.
FIGURA 2-51 Pestaña Blobs base para una regla en la hoja Administración del ciclo de
vida

En la pestaña Conjunto de filtros, puede especificar el prefijo para buscar elementos dentro
del contenedor. Debe especificar el nombre/prefijo del contenedor. Por ejemplo, puede
elegir datos/costo donde datos es el nombre del contenedor y costo es el prefijo, como se
muestra en la Figura 2-52 . También puede utilizar Blob Index Match si ha indexado los
elementos con claves y valores en sus contenedores. Puede especificar hasta 10 prefijos por
regla.
FIGURA 2-52 Conjunto de filtros para una regla en la hoja Administración del ciclo de
vida

Ahora haga clic en Agregar para crear la regla.

Una vez creada, la vista consolidada del código se puede ver en la pestaña Vista de código,
como se muestra en la Figura 2-53 .
FIGURA 2-53 Vista de código para la configuración de gestión del ciclo de vida

Nota Efecto de la gestión del ciclo de vida

La política puede tardar hasta 24 horas en entrar en vigor y luego la acción puede tardar 24
horas adicionales en ejecutarse. En general, las acciones de política tardan hasta 48 horas en
completarse una vez que se configura la administración del ciclo de vida.

Puede eliminar una regla en cualquier momento si ya no es necesaria mediante la hoja

Administración del ciclo de vida.

Resumen del capítulo

Este capítulo cubrió varios servicios clave relacionados con la implementación del
almacenamiento en Microsoft Azure. Los temas incluyeron cómo crear y administrar
cuentas de almacenamiento de Azure, Blob Storage, Azure Files, importación y exportación
de datos, Storage Explorer, AzCopy, administración del ciclo de vida y replicación de
objetos.

Estas son algunas de las conclusiones clave de este capítulo:

 Las cuentas de almacenamiento de Azure proporcionan cuatro servicios

independientes: Blob Storage, Table Storage, Queue Storage y Azure Files. Es
importante comprender los escenarios de uso de cada servicio.
 Las cuentas de almacenamiento estándar utilizan unidades magnéticas y ofrecen el
costo más bajo por GB. Este tipo de cuenta es más adecuada para aplicaciones que
requieren almacenamiento masivo o donde se accede a los datos con poca
frecuencia.
 Las cuentas de almacenamiento premium utilizan unidades de estado sólido y
ofrecen un rendimiento constante y de baja latencia. Este tipo de cuenta solo se
puede usar con discos de máquinas virtuales de Azure y es mejor para aplicaciones
con uso intensivo de E/S, como bases de datos.
 Las cuentas de almacenamiento deben especificar un modo de replicación. Las
opciones son redundancia local, redundancia de zona, redundancia geográfica,
almacenamiento con redundancia geográfica de acceso de lectura, redundancia de
zona geográfica y redundancia de zona geográfica de acceso de lectura.
 Blob Storage admite tres tipos de blobs (blobs en bloques, en páginas y en anexos)
y cuatro niveles de acceso (caliente, esporádico, frío y archivo).
 Hay tres tipos de cuentas de almacenamiento: de uso general V1, de uso general V2
y de almacenamiento de blobs. La disponibilidad de funciones varía según el tipo de
cuenta de almacenamiento. Sin embargo, la versión 1 de uso general se considera
heredada y no se recomienda.
 Azure Storage se puede administrar a través de varias herramientas directamente
desde Microsoft: Azure Portal, PowerShell, CLI, Storage Explorer y AzCopy. Es
importante saber cuándo utilizar cada herramienta.
 El acceso a las cuentas de almacenamiento se puede controlar mediante varias
técnicas. Entre ellos se encuentran la autenticación Entra ID; nombre y clave de la
cuenta de almacenamiento; SAS; SAS con política de acceso; y usar el firewall de
almacenamiento y los puntos finales del servicio de red virtual. El acceso a Blob
Storage también se puede controlar mediante el nivel de acceso público del
contenedor de almacenamiento.
 También puede usar AzCopy para copiar archivos entre cuentas de almacenamiento
o desde ubicaciones externas de acceso público a su cuenta de almacenamiento de
Azure.
 Azure Storage tiene una capacidad de administración del ciclo de vida y se puede
usar para realizar la transición automática de datos a niveles de acceso más bajos
según reglas preconfiguradas. También puede eliminar los datos al final de su ciclo
de vida. Estas reglas se pueden ejecutar en la cuenta de almacenamiento una vez al
día. Se pueden seleccionar blobs y contenedores específicos mediante conjuntos de
filtros.
 Azure Storage también proporciona capacidades de replicación de objetos de blobs
que proporcionan replicación asincrónica de blobs en bloques de una cuenta de
 almacenamiento a otra. Los blobs se replican según las reglas de replicación
definidas.
 Puede aprovechar la replicación de objetos solo cuando el control de versiones de
blobs está habilitado para las cuentas de almacenamiento de origen y de destino, y
la fuente de cambios de blobs está habilitada para la cuenta de almacenamiento de
origen.

Experimento mental

En este experimento mental, aplique lo que ha aprendido sobre este objetivo. Puede
encontrar respuestas a estas preguntas en la siguiente sección.

Se le pide que diseñe una solución de Azure Storage para una gran compañía de seguros.
La empresa quiere que se pueda acceder a los datos en función de la función de los usuarios
individuales dentro de la organización. Varios departamentos tienen conjuntos de datos
separados a los que acceden diariamente. La empresa quiere impedir que los usuarios
modifiquen los datos de otros departamentos, pero todos los usuarios deben poder acceder a
los datos de todos los departamentos.

Además, existe el requisito de almacenar esos datos para siempre con el mínimo costo
posible. Los datos rara vez se utilizan después de dos años desde la fecha de su última
modificación.

1. ¿Qué pasos debe seguir para asignar el acceso al almacenamiento según sus
departamentos?
2. ¿Qué cambios se deben realizar para seguir almacenando datos para siempre con un
costo mínimo?

Respuestas del experimento mental

Esta sección contiene la solución al experimento mental del capítulo.

Para resolver este problema, puede aprovechar varias capacidades de Azure Storage, como
la autenticación Entra con control de acceso basado en roles y administración del ciclo de
vida para el almacenamiento de blobs.

1. Cree una cuenta de almacenamiento de Azure y cree un contenedor para que cada
departamento almacene sus datos. A continuación, asigne la función Lector de datos
de Storage Blob para todos los grupos de departamentos, pero asigne la función
Colaborador de datos de Storage Blob para cada grupo de departamentos. Esto
permite a los usuarios acceder a todos los datos del departamento, pero solo pueden
modificar los datos de su departamento.
2. Cree una regla en la hoja Administración del ciclo de vida para la cuenta de
almacenamiento y seleccione la opción Aplicar regla a todos los blobs en su cuenta
de almacenamiento. Luego, agregue un bloque si-entonces para mover datos al nivel
 de archivo después de 730 días (dos años). Esto le permitirá almacenar los datos
para siempre con un costo mínimo en el nivel de archivo.

Capítulo 3
Implementar y administrar recursos informáticos de Azure

Microsoft Azure ofrece muchas funciones y servicios que se pueden utilizar para crear
soluciones ingeniosas para casi cualquier problema de TI. Algunos de los servicios más
comunes para diseñar estas soluciones son Microsoft Azure Virtual Machines (VM) y
Virtual Machine Scale Sets (VMSS). Las máquinas virtuales se encuentran entre las
opciones informáticas clave para implementar cargas de trabajo en Microsoft Azure.

La flexibilidad de las máquinas virtuales las convierte en una opción común para muchas
cargas de trabajo. Por ejemplo, puede elegir entre sistemas operativos de servidor con
varias versiones compatibles de distribuciones de Windows y Linux. Las máquinas
virtuales de Azure también le brindan control total sobre el sistema operativo junto con
opciones de configuración avanzadas para redes y almacenamiento. Además de las
capacidades de VM, los conjuntos de escalado brindan la capacidad única de escalar ciertos
tipos de cargas de trabajo para manejar grandes problemas de procesamiento y optimizan
los costos al ejecutar instancias solo cuando es necesario.

Además de esto, dispone de otros servicios informáticos para entornos de contenedores,

como Azure Kubernetes Service (AKS), Azure Container Apps (ACA) y Azure Container
Instances (ACI). Con la amplia adopción de cargas de trabajo en contenedores en muchas
empresas de TI, Microsoft está invirtiendo fuertemente en mejorar su conjunto de
productos actual para soportar cargas de trabajo basadas en contenedores. Azure también
tiene otras opciones de PaaS, como Azure App Service y sus planes de App Service para
administrar y alojar aplicaciones web.

En este capítulo, aprenderá los pormenores de la implementación y administración de estos

recursos informáticos en Azure. El capítulo cubre la creación a través de Azure Portal y las
herramientas de línea de comandos, la automatización con plantillas y las tareas de
administración principales.

Habilidades cubiertas en este capítulo:

 Habilidad 3.1: Automatizar la implementación de recursos

 Habilidad 3.2: Crear y configurar máquinas virtuales
 Habilidad 3.3: Aprovisionar y gestionar contenedores
 Habilidad 3.4: Crear y configurar Azure App Service

Nota Objetivos del examen de Microsoft

Las secciones de este capítulo se alinean con los objetivos que se enumeran en la guía de
estudio AZ-104 de Microsoft. Sin embargo, las secciones se presentan en un orden
diseñado para ayudarle a aprender y no coinciden directamente con el orden que se presenta
en la guía de estudio. En el examen, aparecerán preguntas de diferentes secciones en orden
aleatorio. Para obtener la lista completa de objetivos, visite https://learn.microsoft.com/en-
us/credentials/certifications/resources/study-guides/az-104 .

Habilidad 3.1: Automatizar la implementación de recursos

La capacidad de aprovisionar máquinas virtuales bajo demanda mediante Azure Portal es

increíblemente poderosa. Sin embargo, el verdadero poder de la nube es la capacidad de
implementar automáticamente uno o más recursos definidos en código, como un script o
una plantilla. Casos de uso como definir una configuración de aplicación e implementarla
automáticamente según demanda ayudan a los equipos a ser más ágiles al proporcionar
entornos de desarrollador, prueba o producción de manera rápida y repetible. Debido a que
la configuración se almacena como código, los cambios en la infraestructura también se
pueden rastrear en un sistema de control de versiones. En esta habilidad, aprenderá algunas
de las capacidades principales para automatizar las implementaciones de cargas de trabajo
en Azure.

Esta habilidad cubre cómo:

 Interpretar una plantilla de Azure Resource Manager (ARM)

 Modificar una plantilla ARM existente
 Implementar recursos desde una plantilla
 Exportar una plantilla de implementación
 Interpretar y modificar un archivo Bicep

Interpretar una plantilla de Azure Resource Manager

Las plantillas de Azure Resource Manager (ARM) se crean utilizando la notación de

objetos JavaScript (JSON) y brindan la capacidad de definir la configuración de recursos,
como máquinas virtuales, cuentas de almacenamiento, etc., de manera declarativa . Las
plantillas van más allá de simplemente brindar la capacidad de crear recursos; También
puede personalizar y crear dependencias entre algunos recursos, como máquinas virtuales.
Esto hace posible crear plantillas que tengan capacidades para implementaciones
orquestadas de soluciones completamente funcionales.

El equipo de Azure mantiene una lista de plantillas ARM con ejemplos para la mayoría de
los recursos. Esta lista se encuentra en https://azure.microsoft.com/resources/templates/ y
está respaldada por un repositorio de código fuente en GitHub. Si desea ir directamente al
código fuente para presentar un error, puede acceder a él
en https://github.com/Azure/azure-quickstart-templates .

La estructura básica de una plantilla de administrador de recursos tiene la mayoría de los

siguientes elementos:

Haga clic aquí para ver la imagen del código

{
 "$schema": "https://schema.management.azure.com/schemas/2019-04-
01/deploymentTemplate.

json#",

"contentVersion": "1.0.0.0",

"parameters": { },

"variables": { },

"functions": [ ],

"resources": [ ],

"outputs": { }

 $schema El archivo de esquema JSON es la referencia a la estructura estándar

definida para una plantilla ARM, que puede ayudarle a determinar cuándo hay
algún problema con su plantilla en comparación con la sintaxis del archivo de
esquema. El esquema JSON lo utilizan funciones como la finalización de código o
IntelliSense, por lo que puede realizar cambios en las plantillas fácilmente.

Para implementaciones dirigidas a grupos de recursos, utilice

Haga clic aquí para ver la imagen del código

https://schema.management.azure.com/schemas/2019-04-
01/deploymentTemplate.json#

 contentVersion Esto proporciona control de fuente para rastrear los cambios

realizados en su plantilla. Puede proporcionar cualquier valor para este elemento. Al
implementar recursos usando la plantilla, este valor se puede usar para asegurarse
de que se esté usando la plantilla correcta.
 parámetros Usando parámetros, puede definir los valores que se pasan en tiempo
de ejecución sin cambiar el archivo de plantilla exacto. Los parámetros se pueden
cambiar mediante el archivo azuredeploy.parameters.json o en el script de
PowerShell que se utiliza para implementar la plantilla. Los parámetros son
elementos clave cuando se trata de plantillas anidadas para pasar los valores de la
plantilla principal a las plantillas secundarias.
 variables Esto define los valores que se utilizan en su plantilla para simplificar el
lenguaje de la plantilla. En su mayoría, las variables son valores codificados, pero
también se pueden crear dinámicamente utilizando parámetros o funciones de
plantilla estándar.
 funciones Los usuarios pueden crear funciones que se pueden utilizar dentro de la
plantilla. Las expresiones complejas que se utilizan varias veces en la plantilla se
pueden definir como una función una vez. Debe crear su propio espacio de nombres
 y crear funciones miembro según sea necesario. No puede acceder a variables ni a
ninguna otra función definida por el usuario dentro de su función.
 recursos Contiene recursos que se implementan o actualizan en un grupo de
recursos. Puede definir la condición para controlar el aprovisionamiento de cada
recurso. Además, el dependsOnvalor determina qué recursos deben implementarse
primero antes que un recurso específico.
 salidas Aquí puede definir el tipo de valores que se devuelven después de la
implementación. Esta sección se utiliza para realizar un seguimiento de los recursos
que se están implementando o actualizando.

Definir una red virtual

Esta habilidad se centra en aprender cómo implementar máquinas virtuales Windows y

Linux. Un requisito previo para implementar una máquina virtual es tener una red
virtual. El Listado 3-1 muestra cómo definir la estructura de la red virtual utilizando varias
variables que describen el espacio de direcciones y la asignación de subred.

LISTADO 3-1 Variables para la creación de redes virtuales

Haga clic aquí para ver la imagen del código

"ExamRefRGPrefix": "10.0.0.0/16",

"ExamRefRGSubnet1Name": "FrontEndSubnet",

"ExamRefRGSubnet1Prefix": "10.0.0.0/24",

"ExamRefRGSubnet2Name": "BackEndSubnet",

"ExamRefRGSubnet2Prefix": "10.0.1.0/24",

"ExamRefRGSubnet1Ref": "[concat(variables(‘vnetId’), ‘/subnets/’,

variables(‘ExamRefRGSubnet1Name’))]",

"VNetId": "[resourceId(‘Microsoft.Network/virtualNetworks’,
variables(‘VirtualNetworkN

ame’))]",

"VirtualNetworkName": "ExamRefVNET",

Una vez definidas las variables, puede agregar el recurso de red virtual al elemento del
recurso en su plantilla. El Listado 3-2 muestra una parte de una plantilla ARM para una red
virtual denominada ExamRefVNET, con un espacio de direcciones de 10.0.0.0/16y dos
subredes: FrontEndSubnet 10.0.0.0/24y BackEndSubnet 10.0.1.0/24. Tenga en cuenta
que esto es sólo un ejemplo y no se validaría como una plantilla completa, y que la sintaxis
para leer el valor de las variables [variables(‘variablename’)]se utiliza mucho al crear
plantillas. La ubicación de la red virtual se establece en función del valor de retorno de la
función integrada resourceGroup(), que devuelve información sobre el grupo de recursos
en el que se crea o actualiza el recurso.

LISTADO 3-2 Estructura de plantilla para crear una red virtual

Haga clic aquí para ver la imagen del código

"name": "[variables(‘VirtualNetworkName’)]",

"type": "Microsoft.Network/virtualNetworks",

"location": "[resourceGroup().location]",

"apiVersion": "2023-06-01",

"dependsOn": [],

"properties": {

"addressSpace": {

"addressPrefixes": [

"[variables(‘ExamRefRGPrefix’)]"

},

"subnets": [

"name": "[variables(‘ExamRefRGSubnet1Name’)]",

"properties": {

"addressPrefix": "[variables(‘ExamRefRGSubnet1Prefix’)]"

},

"name": "[variables(‘ExamRefRGSubnet2Name’)]",

"properties": {

"addressPrefix": "[variables(‘ExamRefRGSubnet2Prefix’)]"

}
 }

}
Definir una interfaz de red

Cada máquina virtual tiene una o más interfaces de red. Para crear uno con una plantilla,
agregue una variable a la sección de variables para almacenar el nombre del recurso de la
interfaz de red como lo demuestra el siguiente fragmento:

"VMNicName": "VMNic"

El Listado 3-3 define una interfaz de red denominada WindowsVMNic. Este recurso depende
de la ExamRefVNETred virtual. Esta dependencia garantizará que la red virtual se cree antes
de la creación de la interfaz de red cuando se implemente la plantilla y es una característica
crítica de la orquestación de recursos en el orden correcto. La interfaz de red se asocia a la
subred haciendo referencia a la ExamRefRGSubnet1Refvariable.

LISTADO 3-3 Creando una interfaz de red

Haga clic aquí para ver la imagen del código

"name": "[variables(‘VMNicName’)]",

"type": "Microsoft.Network/networkInterfaces",

"location": "[resourceGroup().location]",

"apiVersion": "2023-06-01",

"dependsOn": [

"[resourceId(‘Microsoft.Network/virtualNetworks’, ‘ExamRefVNET’)]"

],

"properties": {

"ipConfigurations": [

"name": "ipconfig1",

"properties": {
 "privateIPAllocationMethod": "Dynamic",

"subnet": {

"id": "[variables(‘ExamRefRGSubnet1Ref’)]"

Consejo de examen

Para especificar una dirección IP privada estática en la sintaxis de la plantilla, especifique

una dirección de la subred asignada usando la privateIpAddresspropiedad y establezca
el privateIpAllocationmétodo en Static.

Haga clic aquí para ver la imagen del código

"privateIpAddress": "10.0.0.10",

"privateIpAllocationMethod": "Static,
Agregar una dirección IP pública

Para agregar una dirección IP pública a la máquina virtual, debe realizar varias
modificaciones. La primera es definir un parámetro que el usuario utilizará para especificar
un nombre DNS único para la IP pública. El siguiente código va en el bloque de parámetros
de una plantilla:

"VMPublicIPDnsName": {

"type": "string",

"minLength": 1

La segunda modificación es agregar el propio recurso de IP pública. Antes de agregar el

recurso, agregue una nueva variable en la sección de variables para almacenar el nombre
del recurso de IP pública.

Haga clic aquí para ver la imagen del código

 "VMPublicIPName": "VMPublicIP"

El Listado 3-4 muestra un recurso de dirección IP pública con el método de asignación de

IP pública configurado en Dynamic(también se puede configurar en Static).
La domainNameLabelpropiedad del dnsSettingselemento de dirección IP se completa con el
parámetro. Esto facilita la especificación de un valor único para la dirección en el momento
de la implementación.

LISTADO 3-4 Creando una interfaz de red

Haga clic aquí para ver la imagen del código

"name": "[variables(‘VMPublicIPName’)]",

"type": "Microsoft.Network/publicIPAddresses",

"location": "[resourceGroup().location]",

"apiVersion": "2023-06-01",

"dependsOn": [ ],

"properties": {

"publicIPAllocationMethod": "Dynamic",

"dnsSettings": {

"domainNameLabel": "[parameters(‘VMPublicIPDnsName’)]"

La siguiente modificación es actualizar el recurso de interfaz de red al que está asociada la

dirección IP pública. La interfaz de red ahora debe depender de la dirección IP pública para
garantizar que se cree antes que la interfaz de red. El siguiente ejemplo muestra la adición a
la dependsOnmatriz:

Haga clic aquí para ver la imagen del código

"dependsOn": [

"[resourceId(‘Microsoft.Network/virtualNetworks’, ‘ExamRefVNET’)]",

"[resourceId(‘Microsoft.Network/publicIPAddresses’,

variables(‘VMPublicIPName’))]"
 ],

El ipConfigurations -> propertieselemento también debe modificarse para hacer

referencia al publicIPAddressrecurso. Consulte el Listado 3-5 .

LISTADO 3-5 Configuraciones IP

Haga clic aquí para ver la imagen del código

"ipConfigurations": [

"name": "ipconfig1",

"properties": {

"privateIPAllocationMethod": "Dynamic",

"subnet": {

"id": "[variables(‘ExamRefRGSubnet1Name’)]"

},

"publicIPAddress": {

"id": "[resourceId(‘Microsoft.Network/publicIPAddresses’,

variables(‘VMPublicIPName’))]"

},

]
Definir un recurso de máquina virtual

Antes de crear el recurso de la máquina virtual, agregará varios parámetros y variables para
definir. Cada máquina virtual requiere credenciales administrativas. Para permitir que un
usuario especifique las credenciales en el momento de la implementación, agregue dos
parámetros adicionales para la cuenta de administrador y la contraseña.

"VMAdminUserName": {

"type": "string",

"minLength": 1
 },

"VMAdminPassword": {

"type": "string",

"minLength": 1

Se necesitan varias variables para definir la configuración del recurso de la máquina virtual.
Las siguientes variables definen el nombre de la VM, la imagen del sistema operativo y el
tamaño de la VM. Estos deben insertarse en la sección de variables de la plantilla.

Haga clic aquí para ver la imagen del código

"VMName": "MyVM",

"VMImagePublisher": "MicrosoftWindowsServer",

"VMImageOffer": "WindowsServer",

"VMOSVersion": "WS2019-Datacenter",

"VMOSDiskName": "VM2OSDisk",

"VMSize": "Standard_D2_v2",

"VM2ImagePublisher": "MicrosoftWindowsServer",

"VM2ImageOffer": "WindowsServer",

"VM2OSDiskName": "VM2OSDisk",

"VMSize": "Standard_D2_v2"

La VM depende de la interfaz de red. No tiene que depender de la red virtual porque la

propia interfaz de red sí la depende. Esta máquina virtual utiliza discos administrados, por
lo que no hay referencias a cuentas de almacenamiento para el archivo VHD. El Listado 3-
6 muestra un recurso de máquina virtual de muestra.

LISTADO 3-6 Recurso de máquina virtual

Haga clic aquí para ver la imagen del código

"name": "[parameters(‘VMName’)]",

"type": "Microsoft.Compute/virtualMachines",

"location": "[resourceGroup().location]",
 "apiVersion": "2023-06-01",

"dependsOn": [

"[resourceId(‘Microsoft.Network/networkInterfaces’,
variables(‘VMNicName’))]"

],

"properties": {

"hardwareProfile": {

"vmSize": "[variables(‘vmSize’)]"

},

"osProfile": {

"computerName": "[variables(‘VMName’)]",

"adminUsername": "[parameters(‘VMAdminUsername’)]",

"adminPassword": "[parameters(‘VMAdminPassword’)]"

},

"storageProfile": {

"imageReference": {

"publisher": "[variables(‘VMImagePublisher’)]",

"offer": "[variables(‘VMImageOffer’)]",

"sku": "[variables(‘VMOSVersion’)]",

"version": "latest"

},

"osDisk": {

"createOption": "FromImage"

},

"networkProfile": {

"networkInterfaces": [

{
 "id": "[resourceId(‘Microsoft.Network/networkInterfaces’,

variables(‘VMNicName’))]"

Hay varias propiedades de un recurso de máquina virtual que son críticas para su
configuración:

 hardwareProfile Este elemento es donde se establece el tamaño de la máquina

virtual. Establezca la vmSizepropiedad en el tamaño deseado, como Standard_D2_v2.
 osProfile Este elemento en un nivel básico es donde configura las
propiedades computerNamey adminUsername. La adminPasswordpropiedad es
obligatoria si no especifica una clave SSH. Este elemento también admite otras
propiedades, incluidas windowsConfiguration, linuxConfigurationy secrets.
 osProfile, windowsConfiguration Si bien el ejemplo no utiliza esta configuración,
este elemento proporciona la capacidad de establecer propiedades avanzadas en
máquinas virtuales de Windows:
 provisionVMAgent Esto está habilitado de forma predeterminada, pero
puede deshabilitarlo. Especifique si se pueden agregar extensiones.
 enableAutomaticUpdates Especifique si las actualizaciones de Windows
están habilitadas.
 timeZone Especifique la zona horaria de la máquina virtual.
 adicionalUnattendContent Pase la configuración de instalación
desatendida para obtener opciones de configuración adicionales.
 winRM Configure la comunicación remota de Windows PowerShell.
 provisionVMAgent Está habilitado de forma predeterminada, pero puede
deshabilitarlo. Especifique si se pueden agregar extensiones.
 enablePasswordAuthentication Si se establece en verdadero, debe
especificar una clave SSH.
 Ssh, publicKeys Especifique la clave pública que se utilizará para la
autenticación con la máquina virtual.
 osProfile, secrets Este elemento secretsse usa para implementar certificados que
se encuentran en Azure Key Vault.
 StorageProfile Este elemento es donde se especifica la imagen del sistema
operativo y se establece el sistema operativo y la configuración del disco de datos.
 networkProfile Este elemento es donde se especifican las interfaces de red para la
máquina virtual.

¿Necesita más revisión? Esquema de plantilla de administrador de recursos

Leer el esquema de plantilla de Azure Resource Manager es una excelente manera de
conocer las capacidades de las plantillas. El esquema de máquina virtual más reciente se
publica en https://learn.microsoft.com/en-in/azure/templates/microsoft.compute/2022-03-
01/virtualmachines .

Modificar una plantilla ARM existente

A menudo necesitarás modificar una plantilla que hayas utilizado previamente para cambiar
la configuración. Como se mencionó anteriormente, uno de los beneficios clave de usar
plantillas para describir su infraestructura (comúnmente conocida como Infraestructura
como código ) es que puede modificarla e implementarla de manera versionada. Para
adaptarse a este comportamiento, ARM admite dos modos de implementación diferentes:
completo e incremental.

¿Necesita más revisión? Infraestructura como código

Infraestructura como Código (conocida como IaC) es un modelo descriptivo para gestionar
la infraestructura. Puede encontrar más información en https://learn.microsoft.com/en-
us/devops/deliver/what-is-infrastructure-as-code .

Plantilla ARM Modo completo

En el modo Completo, Azure Resource Manager elimina los recursos que existen en el
grupo de recursos que no están en la plantilla. Esto es útil si necesita eliminar un recurso de
Azure y desea asegurarse de que su plantilla coincida con la implementación. Puede
eliminar el recurso de la plantilla, implementarlo usando el modo Completo y se eliminará.
Debería considerar el uso del parámetro What-if cuando utilice el modo Completo como
prueba antes de enviarlo para su implementación.

Nota Versión de API REST y modo de implementación

El comportamiento que se analiza aquí depende de la versión de la API REST. Si utiliza

una versión anterior a la 2019-05-10, los recursos no se eliminan. Además, puede haber
otras posibilidades, como bloqueos de recursos o políticas que impidan la eliminación de
recursos.

Plantilla ARM Modo incremental

En el modo incremental, Azure Resource Manager deja sin cambios los recursos que
existen en el grupo de recursos pero que no están en la plantilla. Actualizará los recursos en
el grupo de recursos si la configuración en la plantilla difiere de la implementada. El modo
incremental puede tener impactos no deseados en las propiedades de los recursos. Si su
plantilla no cubre todas las propiedades de un recurso, en el momento de la
implementación, las propiedades no especificadas se restablecerán a los valores
predeterminados que potencialmente pueden afectar el medio ambiente.
Incremental es el modo predeterminado para Azure Portal y cuando realiza la
implementación a través de las herramientas de línea de comandos o Visual Studio. Para
utilizar el modo Completo, debe utilizar la API REST o las herramientas de línea de
comandos con el Mode/--modeparámetro - establecido en Complete.

El siguiente ejemplo implementa una plantilla en modo Completo usando PowerShell:

Haga clic aquí para ver la imagen del código

New-AzResourceGroupDeployment `

-Mode Complete `

-Name simpleVMDeployment `

-ResourceGroupName ExamRefRG `

-TemplateFile C:\ARMTemplates\deploy.json

El siguiente ejemplo implementa una plantilla en modo Completo mediante la CLI de

Azure:

Haga clic aquí para ver la imagen del código

az group deployment create \

--name simpleVMDeployment \

--mode Complete \

--resource-group ExamRefRG \

--template-file deploy.json
Configurar una plantilla VHD

Se supone que ya conoce la estructura de la plantilla ARM. Para obtener una estructura y
sintaxis detalladas, consulte https://learn.microsoft.com/en-us/azure/azure-resource-
manager/templates/syntax .

En la storageProfilesección de un recurso de máquina virtual, puede especificar

el imageReferenceelemento que hace referencia a una imagen de Azure Marketplace:

Haga clic aquí para ver la imagen del código

"imageReference": {

"publisher": "[variables(‘VMImagePublisher’)]",

"offer": "[variables(‘VMImageOffer’)]",

"sku": "[parameters(‘VMOSVersion’)]",
 "version": "latest"

También puede especificar un VHD generalizado que haya creado previamente. Para
especificar una imagen de usuario, debe especificar la osTypepropiedad (Windows o
Linux), la URL del propio VHD y la URL donde se creará el disco en Azure Storage
( osDiskVhdName). El siguiente fragmento de código alternativo lo demuestra. (Este ejemplo
no se basa en el ejemplo anterior).

Haga clic aquí para ver la imagen del código

"storageProfile": {

"osDisk": {

"name": "[concat(variables(‘vmName’),’-osDisk’)]",

"osType": "[parameters(‘osType’)]",

"caching": "ReadWrite",

"image": {

"uri": "[parameters(‘vhdUrl’)]"

},

"vhd": {

"uri": "[variables(‘osDiskVhdName’)]"

},

"createOption": "FromImage"

A modo de contexto, se muestran los siguientes vhdUrlparámetros y

variables:osDiskVhdName

Haga clic aquí para ver la imagen del código

"vhdUrl": {

"type": "string",

"metadata": {

"description": "VHD Url..."

 }

"osDiskVhdName": "[concat(‘http://’,parameters(‘userStorageAccountName’),

‘.blob.core.windows.net/’,parameters(‘userStorageContainerName’),’/’,

parameters(‘vmName’),’osDisk.vhd’)]"

Consulte lo siguiente para ver un ejemplo de plantilla

completo: https://learn.microsoft.com/en-us/partner-center/marketplace/azure-vm-image-
test .

Implementar recursos desde una plantilla

Puede implementar plantillas mediante Azure Portal, las herramientas de línea de comandos
o directamente mediante la API REST. Comenzará implementando una plantilla que crea
una máquina virtual mediante Azure Portal. Para implementar una plantilla desde Azure
Portal, busque Implementar una plantilla personalizada . En la hoja Implementación
personalizada, elija crear su propia plantilla en el portal o seleccione una plantilla común de
la galería, como se muestra en la Figura 3-1 .
FIGURA 3-1 Opciones de implementación de plantillas

Desde allí, tiene la opción de crear su propia plantilla usando el editor en Azure Portal
(también puede pegar su propia plantilla o cargarla desde un archivo usando esta opción) o
elegir una de las plantillas más comunes. Por último, puede buscar los ejemplos existentes
en el repositorio de ejemplos de inicio rápido en GitHub y elegir uno de ellos como punto
de partida.

Haga clic en Cree su propia plantilla en el editor para pegar el código de la plantilla
directamente. Puede crear y luego implementar plantillas mediante Azure Portal para
realizar pruebas sencillas. La Figura 3-2 muestra la hoja Editar plantilla.
FIGURA 3-2 Edición de una plantilla mediante el editor de Azure Portal

Nota Validación de plantilla ARM

Cuando crea la plantilla ARM mediante el editor de Azure Portal, la validación de la

plantilla se realiza de forma predeterminada. Los parámetros, variables y recursos no se
completarán si hay errores en la plantilla, y los indicadores rojos en el margen derecho
señalarán cualquier error.

Al hacer clic en Guardar en la pestaña Seleccionar una plantilla, accederá a la pestaña

Conceptos básicos que se muestra en la Figura 3-3 , donde puede especificar el grupo de
recursos y cualquier parámetro necesario para implementar la plantilla.
FIGURA 3-3 La hoja de implementación personalizada

Nota Interfaz de usuario de plantilla ARM

Cuando crea la plantilla ARM mediante el editor de Azure Portal, la configuración que se
muestra en la Figura 3-3 , incluidos los conjuntos de parámetros y los valores, provienen de
la propia plantilla ARM. Según lo que defina en su plantilla, la pantalla se actualizará en
consecuencia .
Haga clic en Editar parámetros para editar una vista JSON de los parámetros de la plantilla,
como se muestra en la Figura 3-4 . Este archivo también se puede descargar y se utiliza
para proporcionar diferentes comportamientos para la plantilla en el momento de la
implementación sin modificar toda la plantilla.

FIGURA 3-4 Edición de parámetros de plantilla mediante Azure Portal

Ejemplos comunes de uso de un archivo de parámetros:

 Definir diferentes tamaños de instancia o SKU para recursos según el uso previsto
(instancias pequeñas para entornos de prueba, por ejemplo)
 Definir un número diferente de instancias
  Definiendo diferentes regiones
 Desafiando diferentes credenciales

Se recomienda utilizar el tipo de cadena segura para los parámetros al pasar datos
confidenciales, como contraseñas y secretos.

¿Necesita más revisión? Mejores prácticas de plantillas ARM

Las prácticas recomendadas para trabajar con plantillas ARM se pueden encontrar
en https://learn.microsoft.com/en-us/azure/azure-resource-manager/templates/best-
practices .

El último paso para crear una plantilla mediante Azure Portal es hacer clic en Revisar +
Crear. Esto validará los parámetros que ha personalizado y proporcionará un resumen de lo
que se implementará. Haga clic en Crear para activar la implementación.

Las herramientas de línea de comandos de Azure también pueden implementar recursos

mediante plantillas. Los archivos de plantilla pueden ubicarse localmente en su sistema de
archivos, acceder a ellos a través de HTTP/HTTPS o cargarse en su entorno de shell de
nube. Los modelos de implementación comunes incluyen el almacenamiento de las
plantillas en un repositorio de código fuente o una cuenta de almacenamiento de Azure para
que otros puedan implementar la plantilla fácilmente.

Consejo de examen

Los parámetros de una plantilla se pueden pasar al New-AzResourceGroupDeploymentcmdlet

utilizando el TemplateParameterObjectparámetro para valores que se definen directamente
en el script como .json. El TemplateParameterFileparámetro se puede utilizar para valores
almacenados en un archivo .json local. El TemplateParameterUriparámetro para los valores
que se almacenan en un archivo .json en un punto final HTTP.

Consejo de examen

Los parámetros de una plantilla se pueden pasar al az group deployment createcomando

usando la sección de parámetros para valores que se definen directamente en el script como
.json. El parámetro de archivo de plantilla se puede utilizar para valores almacenados en un
archivo .json local. El template-uriparámetro se puede utilizar para valores almacenados
en un archivo .json en un punto final HTTP.
Exportar una plantilla de implementación

Una implementación existente se puede exportar como una plantilla que puede usar para
regenerar el entorno o simplemente para comprender mejor cómo está configurada la
implementación. Hay dos formas de exportar una plantilla desde una implementación.

La primera forma es exportar la plantilla real utilizada por Azure Portal para la
implementación. Cuando usa Azure Portal para implementar un recurso, aún crea y envía la
plantilla ARM al servicio para su implementación. En la pestaña Revisar de la mayoría de
las implementaciones, hay una opción Descargar una plantilla para automatización, como
se muestra en la Figura 3-5 para una cuenta de almacenamiento.
FIGURA 3-5 La pestaña Revisar de una implementación con la opción de descargar la
plantilla

Este método exporta la plantilla exactamente como la personalizó en Azure Portal,

incluidos los valores de los parámetros y variables durante la ejecución original. Este
enfoque no captura ningún cambio realizado en la implementación después de su
implementación.

Al hacer clic en Descargar una plantilla para automatización, se abre la vista de

implementación de plantillas, como se muestra en la Figura 3-6 . Desde aquí, haga clic en
Descargar para descargar la plantilla localmente, haga clic en Implementar para
implementar la plantilla o haga clic en Agregar a la biblioteca para guardarla en su galería
de plantillas para su implementación posterior.

FIGURA 3-6 La vista Plantilla para una implementación

El segundo método para generar una plantilla ARM es utilizar la opción de menú Exportar
plantilla para un recurso o grupo de recursos. Genera una plantilla que representa el estado
actual del contexto que seleccionó. Es posible que el estado se haya actualizado mediante
varias plantillas, o que se haya actualizado mediante cambios desde Azure Portal o
mediante cambios a través de la API REST o la línea de comandos. Puede incluir muchos
valores codificados y no tantos parámetros como se esperaría en una plantilla diseñada para
su reutilización. Esta plantilla es útil para volver a implementarla en el mismo grupo de
recursos debido a los valores codificados. Su uso para otras implementaciones nuevas
normalmente requiere una cantidad significativa de edición para personalizar parámetros y
valores. Puede acceder a esta plantilla navegando hasta el recurso o grupo de recursos y
haciendo clic en Exportar plantilla a la izquierda, como se muestra en la Figura 3-7 .

FIGURA 3-7 La hoja Exportar plantilla de un grupo de recursos

Interpretar y modificar un archivo Bicep

Bicep es un lenguaje específico de dominio que utiliza una sintaxis declarativa fácil de leer
para implementar recursos de Azure. Bicep no reemplaza las plantillas ARM, sino que se
basa en ARM con sus características y beneficios. Bicep se integra como una extensión con
Visual Studio Code, que proporciona IntelliSense para ayudarle a crear nuevos archivos
Bicep.
Compara plantillas ARM y Bicep

Las plantillas ARM están integradas en JSON, lo que las hace detalladas y difíciles de leer.
El siguiente bloque de código de 29 líneas con comillas, corchetes y comas presenta una
plantilla ARM que implementa una cuenta de almacenamiento.

Haga clic aquí para ver la imagen del código

"$schema": "https://schema.management.azure.com/schemas/2019-04-
01/deploymentTemplate.

json#",

"contentVersion": "1.0.0.0",

"parameters": {

"location": {

"type": "string",

"defaultValue": "[resourceGroup().location]"

},

"storageAccountName": {

"type": "string",

"defaultValue": "[format('toylaunch{0}',
uniqueString(resourceGroup().id))]"

},

"resources": [

"type": "Microsoft.Storage/storageAccounts",

"apiVersion": "2021-06-01",

"name": "[parameters('storageAccountName')]",

"location": "[parameters('location')]",

"sku": {

"name": "Standard_LRS"
 },

"kind": "StorageV2",

"properties": {

"accessTier": "Hot"

Compare eso con el siguiente bloque de código de 14 líneas que representa la misma cuenta
de almacenamiento, pero como un archivo Bicep. El formato es más fácil de leer y escribir
al crear archivos para infraestructura como código (IaC) u otra automatización.

Haga clic aquí para ver la imagen del código

param location string = resourceGroup().location

param storageAccountName string = 'toylaunch${uniqueString(resourceGroup().id)}'

resource storageAccount 'Microsoft.Storage/storageAccounts@2021-06-01' = {

name: storageAccountName

location: location

sku: {

name: 'Standard_LRS'

kind: 'StorageV2'

properties: {

accessTier: 'Hot'

Los archivos Bicep todavía tienen parámetros y variables, pero también le permiten incluir
bucles, valores condicionales, alcances de implementación y más en el proceso de
implementación.
Instalar las herramientas de Bicep

Las herramientas de Bicep están disponibles como extensiones tanto en Visual Studio Code
como en Visual Studio. Con esta extensión, puede utilizar las funciones de Visual Studio
Code, como IntelliSense, para ayudar a crear sus archivos Bicep. La Figura 3-8 muestra la
extensión Bicep para Visual Studio Code.

FIGURA 3-8 La extensión Bicep para Visual Studio Code

Crear un archivo Bicep

Después de instalar la extensión Bicep para Visual Studio o Visual Studio Code, cada vez
que edite o cree un nuevo archivo con la extensión .bicep, la extensión Bicep estará
disponible para ayudarlo a crear su archivo.

Por ejemplo, para usar Bicep IntelliSense para comenzar a crear un archivo Bicep para una
cuenta de almacenamiento, simplemente escriba almacenamiento . El menú de IntelliSense
proporcionará una opción de "restauración". Seleccione el elemento "res-almacenamiento"
y presione Tab para completar automáticamente los campos obligatorios para la cuenta de
almacenamiento. Luego podría cambiar estos valores a parámetros o variables para otros
usos en el archivo. La Figura 3-9 muestra la opción IntelliSense en Visual Studio Code.
FIGURA 3-9 La opción Bicep IntelliSense para cuentas de almacenamiento

Implementar un archivo Bicep

Una vez que haya creado el archivo Bicep con los parámetros, variables, recursos y otros
componentes que pueda necesitar implementar en su suscripción de Azure, puede enviar el
archivo Bicep para su implementación. Luego, Bicep traducirá su archivo a una plantilla
ARM y enviará la plantilla para su implementación.

Puede implementar el archivo Bicep directamente desde Visual Studio o Visual Studio
Code haciendo clic derecho en el archivo .bicep, como se muestra en la Figura 3-10 . Esto
supone que está autenticado en su suscripción de Azure desde Visual Studio o Visual
Studio Code.

FIGURA 3-10 El menú contextual de Bicep con la opción Implementar archivo de Bicep

También puede implementar un archivo Bicep desde la CLI o PowerShell enviando el

archivo para su implementación. Si planea utilizar Cloud Shell, primero debe cargar el
archivo bicep en el entorno de Cloud Shell. El siguiente comando de la CLI de Azure
implementa el archivo implementar.bicep en un grupo de recursos denominado az104-rg1.

Haga clic aquí para ver la imagen del código

az deployment group create --resource-group ‘az104-rg1’ --template-file

deploy.bicep
Desde PowerShell, use el New-AzResourceGroupDeploymentcmdlet para implementar un
archivo Bicep. El siguiente comando también implementa el archivo en el mismo grupo de
recursos.

Haga clic aquí para ver la imagen del código

New-AzResourceGroupDeployment -ResourceGroupName ‘az104-rg1’ -TemplateFile

./deploy.

bicep
Habilidad 3.2: Crear y configurar máquinas virtuales

Hay varias formas de crear y configurar máquinas virtuales, según el uso previsto. La forma
más sencilla de crear una máquina virtual individual es utilizar Azure Portal. Si necesita un
aprovisionamiento automatizado (o simplemente disfruta de la línea de comandos),
AzureLos cmdlets de PowerShell y la interfaz de línea de comandos (CLI) de Azure son
una buena opción y son compatibles con múltiples plataformas. Para una automatización
más avanzada, incluso incluyendo la orquestación de múltiples máquinas virtuales, también
se pueden usar plantillas de Azure Resource Manager y archivos Bicep. Cada método tiene
sus propias capacidades y compensaciones, y es importante comprender qué herramienta se
debe utilizar en el escenario correcto. Esta sección cubre varios aspectos y características
para administrar de manera eficiente las máquinas virtuales y los recursos de soporte en un
entorno de Azure.

Esta habilidad cubre cómo:

 Crear una máquina virtual

 Configurar el cifrado de disco de Azure
 Mover máquinas virtuales de un grupo de recursos o suscripción a otro
 Administrar tamaños de VM
 Administrar discos de VM
 Implementar máquinas virtuales en zonas y conjuntos de disponibilidad
 Implementar y configurar conjuntos de escalado de máquinas virtuales

Crear una máquina virtual

Las máquinas virtuales en Azure son una de las opciones informáticas principales
disponibles y ofrecen la mayor flexibilidad y control en su entorno. Al igual que con las
máquinas virtuales locales, usted es responsable de administrar la máquina virtual, las
cuentas, la seguridad de los datos, los parches y actualizaciones, y más.

Antes de crear una VM, hay varios parámetros que debes considerar. Es posible que su
organización tenga otros requisitos comerciales o técnicos que cumplir que no se
mencionan específicamente aquí. Las consideraciones mínimas incluyen

 Nombrar los recursos de VM

 La región de Azure en la que implementar
  El tamaño y SKU de la VM.
 Cuotas o límites de suscripción
 Requisitos del sistema operativo de la máquina virtual
 Configuración de máquina virtual
 Recursos Relacionados

Cuando usa Azure Portal para implementar una máquina virtual, separa la información
requerida en una serie de pestañas en la hoja Crear una máquina virtual. Las pestañas para
crear una VM incluyen

 Lo esencial
 Discos
 Redes
 Gestión
 Supervisión
 Avanzado
 Etiquetas

Lo esencial

Para usar Azure Portal para crear una máquina virtual, busque Máquinas virtuales . En la
hoja Máquinas virtuales, seleccione Crear y luego seleccione Máquina virtual de Azure.
Aparecerá la pestaña Básicos, donde podrás configurar la siguiente información:

 Suscripción La suscripción de Azure en la que se implementará la máquina virtual.

 Grupo de recursos El grupo de recursos al que se asociará lógicamente la máquina
virtual.
 Nombre de VM El nombre del recurso de la máquina virtual.
 Región La región de Azure donde se implementará la máquina virtual.
 Opciones de disponibilidad La redundancia de destino para la VM. Estos se
analizan más adelante en esta habilidad.
 Tipo de seguridad Elija entre estándar, inicio confiable o una máquina virtual
confidencial.
 Imagen La imagen del sistema operativo que se utilizará para la máquina virtual.
 Arquitectura de VM Elija entre arquitectura de procesador Arm64 o x64.
 Ejecutar con descuento de Azure Spot Si la máquina virtual es una instancia de
Azure Spot. Las instancias de Azure Spot son menos costosas, pero Azure podría
desasignarlas. Por lo general, se utilizan en entornos informáticos de
desarrollo/prueba o sin estado.
 Tamaño El SKU de la máquina virtual, que determina las capacidades de CPU,
memoria, disco y red. El SKU es el costo principal para ejecutar la VM.
 Detalles de autenticación Nombre de usuario y contraseña o información de clave
SSH para autenticarse en la VM.
 Puertos de entrada Si el grupo de seguridad de red (NSG) predeterminado que se
crea tiene alguna regla de permiso configurada.
La Figura 3-11 muestra los campos completados para una nueva máquina virtual
denominada az104-vm1.

FIGURA 3-11 La pestaña Conceptos básicos de la hoja Crear una máquina virtual

Discos

En la pestaña Discos de la hoja Crear una máquina virtual, configure el tamaño y el

rendimiento del disco del sistema operativo, así como cualquier disco de datos que pueda
necesitar agregar a la VM. Las opciones para discos VM incluyen
  Tamaño del disco del sistema operativo La capacidad del disco del sistema
operativo.
 Tipo de disco del sistema operativo El nivel de rendimiento del disco del sistema
operativo.
 Eliminar con VM Si el disco se elimina con la VM y se recomienda para la
administración del ciclo de vida de los recursos.
 Administración de claves Cómo se almacena la clave de cifrado del disco. El
cifrado de disco se analiza más adelante en esta habilidad.
 Compatibilidad de disco Ultra Si el disco del sistema operativo utiliza un disco
Ultra para el rendimiento.
 Discos de datos Discos de datos adicionales disponibles para la máquina virtual con
sus propias configuraciones de tamaño y rendimiento.

La Figura 3-12 muestra la pestaña Discos de la hoja Crear una máquina virtual.
FIGURA 3-12 La pestaña Discos de la hoja Crear una máquina virtual

Según la SKU de VM y la región de Azure que seleccione, los discos tienen tres opciones
de rendimiento principales:

 SSD prémium
 SSD estándar
 Disco duro estándar

El disco que seleccione tendrá impactos en el rendimiento, el costo y la disponibilidad de la

máquina virtual. Por ejemplo, un HDD estándar costará menos pero tendrá menos
rendimiento y menor SLA objetivo que una VM que utilice un SSD Premium para el disco
del sistema operativo.

Redes

La pestaña Redes de la hoja Crear una máquina virtual define las opciones de conectividad
para la máquina virtual. Si ya existe una red virtual en el grupo de recursos que selecciona,
seleccionará automáticamente esa red y la primera subred de esa red para implementar la
VM. Si esta es su primera máquina virtual o red, se completará con una nueva red virtual
para crear.

Las opciones para la red de VM incluyen

 Red virtual La red a la que se asociará la NIC predeterminada de la VM.

 Subred La subred de la red a la que se asociará la NIC de la VM.
 IP pública Si la VM requiere una dirección IP pública directamente en la NIC.
 Grupo de seguridad de red de NIC El tipo de NSG asociado con la NIC, si
corresponde.
 Puertos de entrada públicos Si se agrega alguna regla de permiso al NSG durante
la implementación.
 Eliminar IP pública y NIC cuando se elimina la VM Configura la administración
del ciclo de vida de los recursos de red con la VM.
 Habilitar redes aceleradas Disponible según el SKU de la máquina virtual.
 Equilibrio de carga Si se debe integrar esta máquina virtual con una opción de
equilibrio de carga durante la implementación.

La Figura 3-13 muestra la pestaña Redes de la hoja Crear una máquina virtual.
FIGURA 3-13 La pestaña Redes de la hoja Crear una máquina virtual

Gestión

La pestaña Administración proporciona varias opciones para la administración

administrativa de la máquina virtual en Azure. Estos son elementos de configuración que lo
ayudan a administrar la máquina virtual o a lograr otros objetivos comerciales que su
organización pueda tener. Las opciones en la pestaña Administración incluyen

 Microsoft Defender para la nube Si Defender para la nube supervisa la máquina

virtual.
 Identidad Si la máquina virtual tiene asociada una identidad administrada asignada
por el sistema.
 Azure AD Si puede iniciar sesión en la máquina virtual usando Entra ID,
anteriormente Azure AD.
  Apagado automático Programe la desasignación automática de la máquina virtual
en un momento específico.
 Copia de seguridad Configure las opciones de copia de seguridad mediante Azure
Backup Center para la máquina virtual.
 Site Recovery Configure las opciones de recuperación ante desastres mediante
Azure Site Recovery.
 Actualizaciones del sistema operativo invitado Opciones de orquestación de
actualizaciones y parches en caliente para la máquina virtual.

Nota Azure AD ahora es Entra ID

Azure AD pasó a llamarse Microsoft Entra ID. Sin embargo, a partir de esta actualización,
la hoja Crear una máquina virtual todavía hace referencia a Azure AD. Tenga en cuenta que
esto debería ser Entra ID.

La Figura 3-14 muestra la pestaña Administración con algunas de las opciones disponibles.
FIGURA 3-14 La pestaña Administración de la hoja Crear una máquina virtual

Supervisión

La pestaña Monitoreo es donde puede configurar cualquier configuración de alerta y

diagnóstico para la VM durante la implementación. Las opciones para el monitoreo de VM
incluyen

 Alertas Las reglas de alerta recomendadas para una VM.

 Diagnóstico de arranque Si están habilitados y dónde almacenar los registros, si es
así.
 Diagnóstico de invitado del sistema operativo Si se deben recopilar eventos,
registros u otros seguimientos del sistema operativo y almacenarlos en una
ubicación de destino en Azure.
La Figura 3-15 muestra la pestaña Monitoreo de la hoja Crear una máquina virtual.

FIGURA 3-15 La pestaña Monitoreo de la hoja Crear una máquina virtual

Avanzado

La pestaña Avanzado proporciona opciones para personalizar aún más la VM mediante la

configuración de extensiones, aplicaciones, datos personalizados o proximidad de la VM
durante la implementación. Estas opciones son convenientes si necesita que la máquina
virtual esté disponible inmediatamente y funcione como parte de su aplicación después de
la implementación, pero requiere una mayor personalización. Las opciones incluidas en la
pestaña Avanzado son

 Extensiones Cualquier extensión de máquina virtual de Azure que se deba agregar a

la máquina virtual.
 Aplicaciones de VM Aplicaciones que ha agregado a su galería y que deben
instalarse con la VM.
  Scripts de datos personalizados , archivos de configuración u otros datos que la
máquina virtual pueda necesitar durante el aprovisionamiento para completar la
instalación o personalización de la aplicación.
 Secuencias de comandos de datos de usuario , archivos de configuración u otros
datos que estarán disponibles para la máquina virtual de manera persistente ,
incluso después de la implementación.
 Rendimiento NVMe Dependiendo del tamaño de SKU de la VM, opciones
adicionales de rendimiento del disco.
 Grupo de hosts Si la máquina virtual se ejecutará en un host dedicado de Azure.
 Grupo de reserva de capacidad Si tiene capacidad reservada en una región de
Azure específica, el grupo de capacidad al que se debe asociar la máquina virtual.
 Grupo de ubicación por proximidad Si la máquina virtual que está
implementando debe estar relativamente "cerca" de otra máquina virtual en su
entorno, agrúpela en grupos de ubicación por proximidad para minimizar la latencia
entre las máquinas virtuales.

La Figura 3-16 muestra la pestaña Avanzado de la hoja Crear una máquina virtual.
FIGURA 3-16 La pestaña Avanzado de la hoja Crear una máquina virtual

Configurar el cifrado de disco de Azure

Los discos de una máquina virtual de Azure siempre están cifrados. Sin embargo, tiene la
opción de configurar cómo se cifran los discos. De forma predeterminada, los discos
utilizan cifrado administrado por la plataforma, lo que significa que Microsoft administra la
clave de cifrado y la rotación de claves del disco. Si tiene un requisito comercial o técnico
para administrar sus propias claves de cifrado, puede integrar el cifrado con Azure Key
Vault. En esta sección, aprenderá cómo administrar Azure Disk Encryption con algunos
escenarios mediante Azure Portal. Tenga en cuenta que estos pasos se pueden realizar
mediante PowerShell o la CLI de Azure.
Nota Cargos por Azure Disk Encryption

No hay ningún cargo por cifrar discos de VM con Azure Disk Encryption, pero sí hay
cargos asociados con el uso de Azure Key Vault. Se puede acceder a los precios de Key
Vault en https://azure.microsoft.com/en-in/pricing/details/key-vault/ .

Habilite el cifrado en una máquina virtual existente

Siga estos pasos para habilitar el cifrado en una VM existente:

1. Busque el recurso de VM en Azure Portal y, en Configuración, seleccione Discos

(consulte la Figura 3-17 ).

FIGURA 3-17 Hoja Discos para una máquina virtual de Azure

2. En la barra de comandos, haga clic en Configuración adicional. Luego, haga clic en

Cifrado. En Discos para cifrar, elija Ninguno, Disco del sistema operativo o Discos
del sistema operativo y de datos, como se muestra en la Figura 3-18 . Seleccione
Disco del sistema operativo o Discos del sistema operativo y de datos para que se le
solicite Azure Key Vault.
 FIGURA 3-18 Opciones de cifrado para discos de VM de Azure

3. Cuando selecciona los discos para cifrar, aparecen opciones para Azure Key Vault.
Seleccione el almacén de claves donde creó una clave para usarla en Azure Disk
Encryption. Si no tiene un almacén de claves o una clave, también puede crearlos
directamente desde esta página, como se muestra en la Figura 3-19 .
 FIGURA 3-19 Opciones de cifrado para discos de VM de Azure

4. Clic en Guardar.
5. Haga clic en Revisar + Crear. Una vez que el almacén de claves haya pasado la
validación, haga clic en Crear. Esto lo regresará a la hoja Seleccionar clave de
Azure Key Vault.

Deshabilitar el cifrado

Para deshabilitar el cifrado para el sistema operativo y los discos de datos de una máquina
virtual existente, seleccione Ninguno en el menú Discos para cifrar, como se muestra en la
Figura 3-20 .
FIGURA 3-20 Deshabilitar el cifrado de disco

Mover máquinas virtuales de un grupo de recursos o suscripción a otro

Azure ofrece la posibilidad de mover algunos recursos de una suscripción a otra o de un

grupo de recursos a otro. Puede optar por hacer esto por motivos de gobernanza continua,
fusiones y adquisiciones, cambios en las devoluciones de cargos en facturación u otros
motivos. Dependiendo del tipo de recurso, es posible que pueda mover un solo recurso.
Para algunos recursos, como una máquina virtual, es necesario mover los recursos
relacionados, como la NIC, el disco, etc., con la VM. Los nuevos recursos netos no se crean
en la suscripción o el grupo de recursos de destino.

Siga estos pasos para mover un recurso mediante Azure Portal:

1. Desde Azure Portal, navegue hasta el grupo de recursos donde se encuentra el

recurso.
2. En la hoja Descripción general del grupo de recursos, seleccione los recursos que
planea mover seleccionando la marca de verificación de los recursos deseados.
3. En la barra de comandos, elija Mover y luego seleccione el destino: Mover a otro
grupo de recursos, Mover a otra suscripción o Mover a otra región. Para este
ejemplo, seleccione Mover a otro grupo de recursos. Dependiendo del tamaño o la
 resolución de su pantalla, Move podría estar oculto detrás de las elipses, como se
muestra en la Figura 3-21 .

FIGURA 3-21 Recursos seleccionados con el menú Mover

4. La hoja Mover recursos se abre en Azure Portal. Seleccione la pestaña Fuente +

Destino y luego seleccione el grupo de recursos de destino deseado. La Figura 3-
22 muestra az104-rg2 seleccionado como objetivo.
 FIGURA 3-22 La pestaña Origen + Destino de la hoja Mover recursos

5. Haga clic en Siguiente. En la pestaña Recursos para mover, el portal validará si los
recursos se pueden mover al grupo de recursos de destino. Dependiendo de la
opción que seleccione, estopodría fallar debido a la cuota (si se cambia a una nueva
suscripción), recursos huérfanos (si no seleccionó todos los recursos necesarios) u
otros factores. La Figura 3-23 muestra una validación exitosa.
 FIGURA 3-23 La pestaña Recursos para mover de la hoja Mover recursos

6. Haga clic en Siguiente. Acepte los términos y haga clic en Mover para comenzar a
mover los recursos, como se muestra en la Figura 3-24 .
 FIGURA 3-24 La pestaña Revisar de la hoja Mover recursos

7. Debido a que el grupo de recursos cambiará, cualquier script existente que tenga
como destino recursos en este grupo de recursos ya no funcionará hasta que se haya
actualizado. Azure Portal le solicita que confirme que conoce este cambio antes de
poder continuar con la mudanza.

Nota Cómo encontrar el ID del recurso

Puede recuperar el identificador del recurso mediante Azure Portal, PowerShell o CLI. Para
obtener el identificador del recurso desde Azure Portal, vaya al recurso y luego navegue
hasta las propiedades del recurso. Encontrará el ID del recurso en el lado derecho.

¿Necesita más revisión? Recursos compatibles para mudanzas

No todos los recursos son totalmente compatibles para moverse entre grupos de recursos y
suscripciones, y existen varias advertencias con respecto a las máquinas virtuales. Consulte
lo siguiente para obtener más detalles en https://learn.microsoft.com/en-in/azure/azure-
resource-manager/management/move-support-resources .

El proceso para mover un recurso a otra suscripción o región es similar y sigue los mismos
pasos en la hoja Mover recursos. Sin embargo, esto podría tener más impacto en los
recursos que mover grupos de recursos. Cambiar las suscripciones podría cambiar la
facturación asociada al recurso. Los cambios de región podrían afectar el precio del
recurso, así como la conectividad, ya que es posible que también sea necesario realizar
cambios de enrutamiento u otros cambios en la red.

Administrar tamaños de VM

Hay muchas situaciones en las que la cantidad de procesamiento informático que necesita
su carga de trabajo varía drásticamente de un día a otro o incluso de una hora a otra. Por
ejemplo, en muchas organizaciones, las aplicaciones de línea de negocio (LOB) se utilizan
mucho durante la semana laboral, pero los fines de semana ven poco uso real. Otros
ejemplos son las cargas de trabajo que requieren más tiempo de procesamiento debido a
eventos programados, como copias de seguridad o ventanas de mantenimiento, donde tener
más tiempo de procesamiento puede acelerar la realización de estas tareas. Azure
proporciona tamaños de máquinas virtuales especialmente diseñados. Esto significa que
cada familia está diseñada para propósitos específicos para que le resulte más fácil elegir el
tamaño de máquina virtual adecuado para la carga de trabajo adecuada.

Los diferentes tipos son

 Propósito general Este tipo de tamaño es más adecuado para entornos de desarrollo
de pequeña y mediana escala. Tiene una relación CPU-memoria equilibrada. Como
sugiere el nombre, se recomienda para uso general.
 Compute Optimized Este tipo de tamaño tiene una CPU más alta en comparación
con la memoria y se puede utilizar para cargas de trabajo con uso intensivo de CPU
en entornos de escala media. Esto es ideal para dispositivos de red o procesos por
lotes en entornos pequeños.
 Memoria optimizada Este tipo de tamaño proporciona mayor memoria en
comparación con la CPU y es ideal para servidores de bases de datos de mediana
escala. Con mucha memoria, estos tamaños se pueden usar para cachés o con
análisis de memoria.
 Almacenamiento optimizado Este tipo de tamaño ofrece un alto rendimiento del
disco y IO, lo que lo convierte en una buena opción para grandes bases de datos
transaccionales, como Cassandra, MongoDB, etc. Además, se puede utilizar para
Big Data y almacenamiento de datos.
 GPU optimizada Este tipo de tamaño proporciona a las máquinas virtuales una o
varias GPU NVIDIA. Proporciona alta computación y gráficos, que son ideales para
cargas de trabajo de visualización.
 Computación de alto rendimiento Este tipo de tamaño es capaz de manejar
procesamiento por lotes, modelado molecular y dinámica de fluidos. Este tipo de
tamaño ofrece una potencia de CPU sustancial y diversas opciones para redes
RDMA de baja latencia utilizando FDR InfiniBand y varias configuraciones de
memoria para admitir requisitos computacionales con uso intensivo de memoria.

Azure Virtual Machines hace que sea relativamente fácil cambiar el tamaño de una
máquina virtual, incluso después de haberla implementado. Hay algunas cosas a considerar
con este enfoque.
Primero, asegúrese de que la región en la que está implementada su VM admita el tamaño
de instancia al que desea cambiar la VM. En la mayoría de los casos, esto no es un
problema, pero si tiene un caso de uso donde el tamaño deseado no está en la región en la
que está implementada la VM existente, sus únicas opciones son esperar a que el tamaño
sea compatible con el región o para mover la máquina virtual existente a una región que ya
la admita. Esto puede resultar complicado porque entonces la nueva región también debe
tener las redes y otros recursos que requiere la VM.

En segundo lugar, asegúrese de que el nuevo tamaño sea compatible con el clúster de
hardware actual en el que está implementada su máquina virtual. Esto se puede determinar
viendo la hoja Tamaño en la hoja de configuración de la máquina virtual en Azure Portal de
una máquina virtual en ejecución, como se muestra en la Figura 3-25 . Si el tamaño está
disponible, puedes seleccionarlo. Cambiar el tamaño reinicia la máquina virtual.

FIGURA 3-25 Cambio del tamaño de una máquina virtual de Azure mediante Azure Portal
Si el tamaño deseado no está disponible, significa que el tamaño no está disponible en la
región o en el clúster de hardware actual. Puede ver los tamaños disponibles por región
en https://azure.microsoft.com/regions/services/ . Si necesita cambiar a un clúster de
hardware diferente, debePrimero debe desasignar la máquina virtual y, si forma parte de un
conjunto de disponibilidad, debe detener todas las instancias del conjunto de disponibilidad
al mismo tiempo. Una vez que se desasignan todas las máquinas virtuales, puede cambiar el
tamaño, lo que mueve todas las máquinas virtuales al nuevo clúster de hardware a medida
que se redimensionan y se inician. Todas las máquinas virtuales del conjunto de
disponibilidad se deben detener antes de realizar la operación de cambio de tamaño a un
tamaño que requiera hardware diferente porque todas las máquinas virtuales en ejecución
en el conjunto de disponibilidad deben usar el mismo clúster de hardware físico. Por lo
tanto, si necesita cambiar un clúster de hardware físico para cambiar el tamaño de la
máquina virtual, todas las máquinas virtuales deben detenerse y luego reiniciarse una por
una en un clúster de hardware físico diferente.

¿Necesita más revisión? Tamaños de máquinas virtuales

Hay muchas consideraciones a la hora de elegir el tamaño correcto de máquina virtual. Para
obtener más información sobre los tamaños en el contexto de las máquinas virtuales
basadas en Windows, consulte https://learn.microsoft.com/en-us/azure/virtual-
machines/sizes . Para ver la versión de Linux del artículo,
consulte https://learn.microsoft.com/en-us/azure/virtual-machines/sizes .

Administrar discos de VM

Agregar un disco de datos a una máquina virtual de Azure existente mediante Azure Portal
es casi idéntico al proceso de creación. Desde la hoja de configuración de la máquina
virtual, haga clic en Discos y luego haga clic en Crear y conectar un nuevo disco. Esta
acción abrirá la hoja que se muestra en la Figura 3-26 . Desde allí, puede elegir uno de los
discos existentes que están disponibles para adjuntar, o puede hacer clic en Adjuntar discos
existentes para adjuntar un disco que creó en otro momento.
FIGURA 3-26 Agregar un disco de datos a una máquina virtual de Azure en Azure Portal

Cuando cree el disco de datos, tendrá opciones similares a las disponibles para el disco del
sistema operativo al crear una VM. El tipo de almacenamiento se puede configurar con
varias opciones para los tipos de rendimiento Premium y Estándar, capacidad del disco,
opciones de cifrado y opciones de almacenamiento en caché del host.

Consejo de examen

Si la máquina virtual está implementada en una zona de disponibilidad y está usando

PowerShell, use el Zoneparámetro con el New-AzDiskConfigcmdlet para especificar qué
zona de disponibilidad crear el disco.

Consejo de examen

Si la máquina virtual está implementada en una zona de disponibilidad y usa la CLI de

Azure, el disco se coloca automáticamente en la misma zona que la máquina virtual.
Implementar máquinas virtuales en zonas y conjuntos de disponibilidad

La resiliencia es una parte fundamental de cualquier arquitectura de aplicaciones. Azure

proporciona varias características y capacidades para facilitar el diseño de soluciones
resilientes. La plataforma le ayuda a evitar un único punto de error a nivel de hardware
físico y proporciona técnicas para evitar el tiempo de inactividad durante las
actualizaciones del host. El uso de funciones como zonas de disponibilidad, conjuntos de
disponibilidad y equilibradores de carga le brinda las capacidades para crear sistemas
altamente resistentes y disponibles.

Zonas de disponibilidad

Las zonas de disponibilidad son unidades separadas, cada una con su propia energía,
refrigeración y redes, que brindan mayor resiliencia y protegen las aplicaciones y los datos
contra interrupciones en los centros de datos. Para garantizar la resiliencia, hay un mínimo
de tres zonas separadas en todas las regiones habilitadas. La separación física y lógica de
las zonas de disponibilidad dentro de una región protege las aplicaciones y los datos de
fallas a nivel de zona. Las zonas de disponibilidad proporcionan un tiempo de actividad
SLA del 99,99 por ciento cuando se implementan dos o más máquinas virtuales en dos o
más zonas de disponibilidad. La Figura 3-27 ilustra cómo se puede implementar una
aplicación de tres niveles con una máquina virtual de cada nivel implementada en cada una
de las tres zonas para una mayor disponibilidad.

FIGURA 3-27 Vista arquitectónica de una zona de disponibilidad

Cuando crea máquinas virtuales en tres zonas de disponibilidad, se distribuirán
automáticamente en tres zonas. Una zona representa uno o más centros de datos que
comparten energía, refrigeración y redes dentro de esa zona.

Para implementar una máquina virtual en una zona de disponibilidad, seleccione la zona
que desea usar en la pestaña Conceptos básicos de la hoja Crear una máquina virtual, como
se muestra en la Figura 3-28 .

FIGURA 3-28 Especificación de la zona de disponibilidad para una VM

Nota Zonas de disponibilidad y región de Azure

Si no puede establecer una zona de disponibilidad, probablemente haya seleccionado una

región donde las zonas de disponibilidad no están disponibles. Para obtener una lista de
todas las regiones y zonas de Azure compatibles, visite https://azure.microsoft.com/en-
us/explore/global-infrastructure/geographies .
Conjuntos de disponibilidad

La implementación de una aplicación de varios niveles en un conjunto de disponibilidad

puede proporcionar redundancia y alta disponibilidad a las máquinas virtuales. Para
proporcionar redundancia para sus máquinas virtuales, debe colocar al menos dos máquinas
virtuales en un conjunto de disponibilidad. Esta configuración garantiza que al menos una
máquina virtual esté disponible en caso de una actualización del host o de un problema con
el hardware físico en el que están alojadas las máquinas virtuales. Tener al menos dos
máquinas virtuales en un conjunto de disponibilidad es un requisito para el acuerdo de nivel
de servicio (SLA) para máquinas virtuales del 99,95 por ciento.

También puede colocar una máquina virtual de instancia única en un conjunto de

disponibilidad, pero hacerlo proporciona SLA comparativamente más bajos. Un SSD
Premium proporciona un SLA del 99,9 por ciento, mientras que el SSD estándar y el HDD
estándar proporcionan SLA del 99,5 por ciento y 95 por ciento, respectivamente.

Las máquinas virtuales deben implementarse en conjuntos de disponibilidad según su carga

de trabajo o nivel de aplicación. Por ejemplo, si está implementando una solución de tres
niveles que consta de servidores web, un nivel intermedio y un nivel de base de datos, cada
nivel tendría su propio conjunto de disponibilidad, como se ilustra en la Figura 3-29 .

FIGURA 3-29 Configuraciones de conjuntos de disponibilidad para una solución de varios

niveles

Los conjuntos de disponibilidad se pueden configurar asignando un dominio de error y un

dominio de actualización. Un dominio de falla representa un grupo de servidores que
comparten energía, refrigeración y redes, mientras que un dominio de actualización
representa un grupo de servidores que se pueden reiniciar al mismo tiempo. Cada conjunto
de disponibilidad puede tener hasta 20 dominios de actualización y 3 dominios de error.
Esto reduce el impacto en las máquinas virtuales debido a fallas de hardware físico, como
interrupciones del servidor, de la red o de energía en uno de los bastidores físicos. Es
importante comprender que el conjunto de disponibilidad debe establecerse cuando se crea
la máquina virtual.

Crear un conjunto de disponibilidad

Para crear un conjunto de disponibilidad, especifique un nombre para el conjunto de

disponibilidad que no esté en uso por ningún otro conjunto de disponibilidad dentro del
grupo de recursos, junto con la cantidad de dominios de falla y actualización, así como si
usará discos administrados con la disponibilidad. establecido o no. Para crear la
disponibilidad establecida en el momento de la creación de la máquina virtual, vaya a la
página de inicio, haga clic en Crear un recurso, busque la máquina virtual y haga clic en
Crear. Se abre la pestaña Básicos, como se muestra en la Figura 3-30 . En la página Crear
conjunto de disponibilidad, puede crear un nuevo conjunto de disponibilidad. Como se
muestra en la Figura 3-30 , puede seleccionar la cantidad de dominios de falla y actualizar
los dominios.

FIGURA 3-30 Creación de un conjunto de disponibilidad

También puede crear un conjunto de disponibilidad haciendo clic en Crear un recurso,

buscando conjunto de disponibilidad y haciendo clic en Crear. Aparece la pestaña
Conceptos básicos, donde puede seleccionar una suscripción, un grupo de recursos y una
región, y puede especificar el nombre del conjunto de disponibilidad, el dominio de error y
el dominio de actualización. En la pestaña Avanzado, puede seleccionar un grupo de
ubicación por proximidad si ya está creado. Haga clic en el botón Revisar + Crear en la
parte inferior para crear el conjunto de disponibilidad. Ahora puede colocar recursos como
máquinas virtuales en este conjunto de disponibilidad recién creado seleccionándolo en el
momento de la creación del recurso. La Figura 3-31 muestra la pestaña Conceptos básicos
de la hoja Crear conjunto de disponibilidad.

FIGURA 3-31 Creación de un conjunto de disponibilidad

Grupo de colocación de proximidad de notas

Un grupo de ubicación de proximidad es una agrupación lógica de máquinas virtuales para

reducir la latencia manteniéndolas más cerca unas de otras. Si las máquinas virtuales se
colocan en el mismo grupo de ubicación por proximidad, se ubicarán físicamente más cerca
unas de otras.

Conjuntos de disponibilidad y discos administrados

Los conjuntos de disponibilidad y los discos administrados se complementan entre sí.

Cuando la máquina virtual utiliza discos administrados y se coloca en un conjunto de
disponibilidad (conocido como conjunto de disponibilidad alineado), garantiza que los
discos de la máquina virtual se coloquen en diferentes dominios de fallas de
almacenamiento, como se muestra en la Figura 3-32 . Esta alineación garantiza que todos
los discos administrados conectados a una máquina virtual estén dentro del mismo dominio
de falla del disco administrado. La cantidad de dominios de error para un conjunto de
disponibilidad depende de la región a la que pertenece, con dos o tres dominios de error por
región.

FIGURA 3-32 Alineación de discos administrados con un conjunto de disponibilidad

¿Necesita más revisión? Comprensión de la disponibilidad en máquinas virtuales de

Azure

Puede obtener más información sobre los dominios de actualización y fallas y cómo
administrar la disponibilidad de sus máquinas virtuales de Azure
en https://learn.microsoft.com/en-us/azure/virtual-machines/availability .

Implementar y configurar conjuntos de escalado de máquinas virtuales

Un conjunto de escalado de máquinas virtuales (VMSS) es un recurso informático que

puede utilizar para implementar y administrar un conjunto de máquinas virtuales idénticas.

De forma predeterminada, un VMSS admite hasta 100 instancias. Sin embargo, es posible
crear una escala configurada hasta 1000 instancias colocando las instancias en múltiples
grupos de ubicación. Un grupo de ubicación es una construcción, como un conjunto de
disponibilidad de Azure, con sus propios dominios de error y dominios de actualización. Si
define un recuento de instancias superior a 100 en Azure Portal cuando se crea el conjunto
de escalado, Azure Portal habilitará automáticamente el conjunto de escalado para varios
grupos de ubicación. De forma predeterminada, un conjunto de escalado consta de un único
grupo de ubicación con un tamaño máximo de 100 máquinas virtuales. Si la propiedad del
conjunto de escalado llamada singlePlacementGroupestá establecida en falseo si define un
recuento de instancias superior a 100 en Azure Portal, el conjunto de escalado puede estar
compuesto por varios grupos de ubicación y tener un rango de 0 a 1000 máquinas virtuales.

El uso de varios grupos de ubicación se denomina comúnmente "conjunto a gran escala".

La singlePlacementGrouppropiedad se puede configurar mediante plantillas ARM o
herramientas de línea de comandos. Tenga en cuenta las siguientes condiciones cuando
trabaje con conjuntos de gran escala:

 Si está utilizando una imagen personalizada (no una imagen predeterminada

disponible en el mercado), su conjunto de escalado admite hasta 600 instancias en
lugar de 1000.
 La SKU básica de Azure Load Balancer puede escalarse hasta 300 instancias.
 Para un conjunto a gran escala (> 100 instancias), debe usar la SKU estándar
(admite hasta 1000 instancias) o Azure Application Gateway.

La Figura 3-33 muestra una parte del blade para crear un nuevo conjunto de escalado de
máquinas virtuales (VMSS) mediante Azure Portal. Al igual que otros recursos de Azure,
debe especificar un nombre y el grupo de recursos en el que realizar la implementación.
Todas las instancias de VMSS utilizarán la misma imagen de disco del sistema operativo
especificada aquí.
FIGURA 3-33 Creación de un conjunto de escalado de VM

Consejo de examen

Se puede implementar un conjunto de escalado en una zona de disponibilidad para

proporcionar mayor redundancia y resiliencia. Si el conjunto de escalado se crea con una
única zona de disponibilidad, todas las instancias se implementarán dentro de una única
zona. Si el conjunto de escalado se implementa en varias zonas de disponibilidad (lo que se
conoce como conjunto de escalado con redundancia de zona), según las reglas de escalado,
las instancias se pueden implementar en varias zonas si es necesario.
En la pestaña Escala, puede configurar la Política de escala como Manual o Personalizada.
Cuando configura la Política de escalado en Personalizada, ve las opciones de
configuración para establecer las reglas predeterminadas, como se muestra en la Figura 3-
34 . Aquí, puede especificar la cantidad mínima y máxima de máquinas virtuales en el
conjunto, y puede configurar las acciones para escalar horizontalmente (agregar más) o
escalar verticalmente (eliminar instancias).

FIGURA 3-34 Configuración de reglas de escalado para un conjunto de escalado de

máquinas virtuales

Durante el ciclo de vida de un conjunto de escalado de máquinas virtuales, es posible que

necesite actualizar las instancias con el modelo de conjunto de escalado más reciente. La
política de actualización de VMSS determina cómo se actualizarán las máquinas virtuales
una vez que haya una nueva actualización disponible. Hay tres opciones disponibles:
Automático, Rodante y Manual (consulte la Figura 3-35 ). Si selecciona Automático, todas
las instancias se actualizan en orden aleatorio cuando hay una actualización disponible, lo
que puede provocar tiempo de inactividad. Si selecciona Rolling, el conjunto de escalado
actualiza las máquinas virtuales en varios lotes y puede establecer un tiempo de pausa entre
dos lotes, lo que puede evitar el tiempo de inactividad total. Si la propiedad está
configurada en Manual, depende de usted revisar paso a paso y actualizar cada instancia
mediante programación mediante PowerShell con el Update-AzVmssInstancecmdlet o el az
vmss update-instancescomando de la CLI de Azure.

FIGURA 3-35 Configuración de reglas de administración para un conjunto de escalado de

máquinas virtuales

¿Necesita más revisión? Actualización de un conjunto de escalado de máquinas

virtuales

Puede obtener más información sobre la actualización de conjuntos de escalado de

máquinas virtuales en https://learn.microsoft.com/en-us/azure/virtual-machine-scale-
sets/virtual-machine-scale-sets-upgrade-scale-set .

También puede agregar una capa de monitoreo de salud a su aplicación cuando crea VMSS.
La supervisión del estado es necesaria cuando se planea utilizar infraestructura
administrada y actualizaciones automáticas del sistema operativo. En la pestaña Salud,
puede habilitar la supervisión del estado de la aplicación y configurar las opciones
eligiendo la extensión, el protocolo, el puerto y la ruta del punto final de la aplicación
(consulte la Figura 3-36 ).

FIGURA 3-36 Configuración de la supervisión del estado de un conjunto de escalado de

máquinas virtuales

Algunas opciones en la pestaña Avanzado, como Política de asignación, incluyen un

algoritmo de distribución. Además, puede seleccionar entre opciones como Extensiones,
aplicación VM y Grupo de ubicación por proximidad, como se muestra en la Figura 3-37 .
FIGURA 3-37 Configuración de reglas avanzadas para un conjunto de escalado de
máquinas virtuales

Consejo de examen

El algoritmo de distribución determina cómo se colocarán las instancias del conjunto de

escala en un dominio de falla. Con la dispersión máxima, las instancias se distribuyen en el
máximo de dominios de falla posibles para cada zona. La distribución fija restringe las
instancias a exactamente cinco dominios de falla. Si un conjunto de escalado utiliza un
algoritmo de distribución fija y hay menos de cinco dominios de error disponibles, la
implementación fallará.

¿Necesita más revisión? Conjuntos de escalado de máquinas virtuales

Puede obtener más información sobre los conjuntos de escalado de máquinas virtuales
aquí: https://learn.microsoft.com/en-us/azure/virtual-machine-scale-sets/ .

Habilidad 3.3: Aprovisionar y gestionar contenedores

Hoy en día, los contenedores se consideran la primera opción para implementaciones

instantáneas siguiendo la metodología DevOps. Con esta evolución, Microsoft también ha
dado igual o más importancia a los contenedores al diseñar características de producto para
Microsoft Azure. Se pueden ejecutar varios contenedores en un sistema operativo host
(Windows o Linux), y cada contenedor proporciona aplicaciones alojadas con un
mecanismo para utilizar CPU, memoria, almacenamiento de archivos y conexiones de red.

Aunque los contenedores no tienen sus propios sistemas operativos, por lo que pueden
implementarse y ejecutarse en cualquier lugar, la mayoría de las distribuciones incluyen la
mayoría de los componentes del sistema operativo en modo de usuario. Comparten el
sistema operativo host con otros contenedores y están aislados entre sí. Los contenedores se
utilizan ampliamente para desarrollar y empaquetar aplicaciones junto con sus
dependencias y configuraciones en una única imagen de contenedor. Las aplicaciones en
contenedores se implementarán como imágenes de contenedor en el sistema operativo host.

Al utilizar contenedores, los tiempos de implementación se acortan, el mantenimiento es

más fácil y la ampliación/incorporación es posible en segundos. Ésta es la única razón por
la que las grandes empresas están adoptando lentamente la tecnología de contenedores. Los
contenedores se pueden crear desde su repositorio de imágenes privado mediante Azure
Container Registry, Docker Hub o repositorios similares. Puede descargar imágenes,
ponerlas a disposición de los hosts de contenedores y luego implementar nuevas instancias
de contenedores en cuestión de segundos.

Los desarrolladores pueden modificarlos aún más con sus tiempos de ejecución,
complementos y su propio código, creando sus propias imágenes versionadas que se
pueden implementar instantáneamente. Esto significa que los desarrolladores son más
productivos y pueden administrar su código de forma dinámica para implementar nuevas
versiones de código rápidamente. Esto se puede integrar aún más a los peajes de CI/CD
para automatizar el flujo de implementación de un extremo a otro para aplicaciones en
contenedores.

Esta habilidad cubre cómo:

 Crear y administrar un Registro de contenedores de Azure (ACR)

 Aprovisionar un contenedor mediante Azure Container Instances (ACI)
 Aprovisionar un contenedor mediante Azure Container Apps (ACA)
 Gestionar el tamaño y el escalado de los contenedores.
Crear y administrar un Registro de contenedores de Azure

Un Azure Container Registry (ACR) es un repositorio de imágenes de contenedor basado

en Docker Registry 2.0. Puede crear una instancia de recursos ACR en su suscripción de
Azure para almacenar y administrar imágenes de contenedor y componentes relacionados.
Se puede usar una ACR con las canalizaciones de contenedores existentes o puede usar
tareas de ACR para crear nuevas imágenes de contenedores directamente en Azure.

Cuando implementas un ACR en tu suscripción, hay tres opciones de SKU para elegir:
Básico, Estándar y Premium. La Tabla 3-1 describe algunas de las principales diferencias
entre niveles.

TABLA 3-1 Niveles de Azure Container Registry

De primera
Característica Básico Estándar
calidad

Almacenamiento incluido 10GB 100 GB 500 GB

Ganchos web 2 10 500

Descargar ancho de banda 30Mbps 60Mbps 100Mbps

Replicación geográfica No No Soportado

soportado soportado

Zonas de disponibilidad No No Soportado

soportado soportado

Claves administradas por el No No Soportado

cliente soportado soportado

¿Necesita más revisión? Niveles de registro de contenedores de Azure

Esta es sólo una muestra de las diferencias entre los niveles de ACR. Para obtener una lista
completa de las diferencias de funciones, visite https://learn.microsoft.com/en-
us/azure/container-registry/container-registry-skus .

Crear un registro de contenedor de Azure

Puede usar cualquiera de las herramientas disponibles para implementar una instancia de
ACR: Azure Portal, CLI, PowerShell o API REST. También puede automatizar la
implementación utilizando plantillas ARM o archivos Bicep. Para crear una instancia desde
Azure Portal, siga estos pasos:

1. Desde Azure Portal, busque Registros de contenedores .

2. En la hoja Registros de contenedor, haga clic en Crear.
3. En la pestaña Conceptos básicos de la hoja Crear registro de contenedor, complete
los campos y luego haga clic en Siguiente. Los campos de la pestaña Conceptos
básicos, como se muestra en la Figura 3-38 , incluyen
1. Suscripción La suscripción de Azure en la que implementar el recurso.
2. Grupo de recursos El grupo de recursos lógico para el recurso.
3. Nombre de registro El nombre del recurso, que debe ser globalmente único en
todos los clientes y regiones de Azure, y solo puede contener entre 5 y 50 caracteres
alfanuméricos.
4. Ubicación La región de Azure en la que implementar el recurso.
5. Usar zonas de disponibilidad Si el ACR tiene redundancia de zona, solo está
disponible con el nivel Premium.
6. Plan de precios El nivel de servicio: Básico, Estándar o Premium.
 FIGURA 3-38 La pestaña Conceptos básicos de la hoja Crear registro de
contenedor

4. En la pestaña Redes, elija Acceso público o Acceso privado para el registro. El

acceso privado requiere la creación de una conexión de punto final privado para
ACR, pero solo está disponible para el nivel Premium. La Figura 3-39 muestra la
pestaña Redes.
 FIGURA 3-39 La pestaña Redes de la hoja Crear registro de contenedor

5. En la pestaña Cifrado, elija si desea utilizar una clave de cifrado administrada por el
cliente o aceptar la clave de plataforma predeterminada administrada por Microsoft.
Seleccionar Habilitado para la clave administrada por el cliente requiere que se cree
una clave en Azure Key Vault y que se haya creado una identidad administrada y se
le hayan otorgado permisos para acceder a la clave desde la bóveda. La Figura 3-
40 muestra la pestaña Cifrado con estas configuraciones seleccionadas.
 FIGURA 3-40 La pestaña Cifrado de la hoja Crear registro de contenedor

6. Haga clic en Revisar + Crear. Verifique que haya configurado el ACR según sea
necesario para su escenario y luego haga clic en Crear. Se enviará la
implementación y se creará una instancia de ACR en la región que seleccionó
durante la implementación.
Administrar un registro de contenedores de Azure

Después de implementar ACR, puede modificar las opciones de red, identidad y cifrado
que se configuraron durante la implementación. La única opción que no puede cambiar
después de la implementación es si el registro tiene redundancia de zona.

Empezando

Para comenzar con su nueva instancia de ACR, las acciones más comunes son iniciar
sesión y luego enviar o extraer imágenes hacia y desde el registro. Esto supone que ya tiene
Docker instalado en su máquina local para usarlo con el registro.

Para iniciar sesión en su registro, navegue hasta la hoja Claves de acceso del registro.
Marque la casilla junto a Usuario administrador para activar la cuenta de administrador
para el registro; proporcionará dos contraseñas para usar con la cuenta. La hoja Claves de
acceso se muestra en la Figura 3-41 .

FIGURA 3-41 La hoja Claves de acceso de un Registro de contenedor de Azure

Después de obtener el URI de inicio de sesión y las credenciales de la hoja Claves de

acceso, use el siguiente comando de Docker para iniciar sesión en el registro,
reemplazándolo registrynamecon el nombre de su recurso:

Haga clic aquí para ver la imagen del código

docker login registryname.azurecr.io

Después de autenticarse exitosamente, puede etiquetar una imagen y enviarla a su

repositorio usando los siguientes comandos:

Haga clic aquí para ver la imagen del código

docker tag hello-world registryname.azurecr.io/hello-world

docker push registryname.azurecr.io/hello-world

Finalmente, después de que la imagen haya sido enviada al contenedor, puedes extraerla
cuando sea necesario. Para extraer una imagen de un registro, ejecute el siguiente comando:

Haga clic aquí para ver la imagen del código

docker pull registryname.azurecr.io/hello-world

Ganchos web

Los webhooks se pueden utilizar para desencadenar eventos específicos cuando se produce
una acción en el repositorio. Esto podría ser para todos los elementos del repositorio o para
etiquetas específicas. Si ha habilitado la replicación geográfica en otra región de Azure,
también puede configurar el webhook para responder a eventos específicos basados en una
región.

Para crear un webhook desde Azure Portal, navegue hasta el registro del contenedor y
luego seleccione Webhooks. En la hoja Webhooks, haga clic en Agregar. Los elementos de
configuración de un webhook incluyen

 Nombre del webhook El nombre alfanumérico del webhook, incluidos entre 5 y 50

caracteres.
 Ubicación La región de Azure donde se implementa el webhook. Si utiliza una
réplica, seleccione la región de la instancia de réplica.
 URI de servicio El URI donde el webhook envía notificaciones POST.
 Encabezados personalizados Cualquier encabezado personalizado que deba
incluirse con la notificación POST.
 Acciones de activación Las acciones en el repositorio que deberían activar el
webhook. Estos pueden incluir insertar y eliminar tanto para imágenes como para
gráficos de Helm.
 Estado activo Si el webhook está habilitado o no.
 Alcance Etiquetas específicas a las que debe aplicarse el webhook o dejarlas en
blanco para aplicarlas a todos los elementos del repositorio.

La Figura 3-42 muestra un webhook de muestra en proceso de creación.

FIGURA 3-42 La hoja Crear webhook para un registro de contenedor de Azure

GEO-Replicaciones

Si tiene requisitos comerciales o técnicos de que las imágenes del repositorio se repliquen
en otra región de Azure, debe implementar ACR en el nivel Premium. Esto le permitirá
seleccionar regiones de Azure adicionales para replicar los datos.

Para habilitar la replicación, navegue hasta la instancia de ACR en su suscripción y

seleccione Replicaciones geográficas. Se mostrará un mapa mundial con iconos
seleccionables, como se muestra en la Figura 3-43 . Seleccione un icono de región en el
mapa para abrir la hoja Crear replicación.
FIGURA 3-43 La hoja Replicaciones geográficas de un registro de contenedor de Azure

Aprovisionar un contenedor mediante Azure Container Instances

Azure Container Instances (ACI) proporciona una forma de implementar contenedores

aislados de forma rápida y sencilla sin preocuparse por la infraestructura backend. Se usa
ampliamente para hacer girar contenedores rápidamente para actividades como
automatización de tareas, creación de trabajos, etc.

Hay varias formas de crear ACI. Puede usar Azure Portal, PowerShell, CLI de Azure,
plantillas ARM o archivos Bicep.

Crear ACI

Para crear instancias de contenedor de Azure desde Azure Portal, busque Instancias de
contenedor . En la hoja Instancias de contenedor, seleccione Crear.

Como se muestra en la Figura 3-44 , puede completar los detalles, como suscripción, grupo
de recursos, región, etc. Elija la fuente de imagen para su instancia de contenedor. Puede
seleccionar la imagen disponible mediante QuickStart Images, Azure Container Registry
(ACR) o el registro de Docker Hub.
FIGURA 3-44 Pestaña Conceptos básicos de la hoja Crear instancia de contenedor

En la pestaña Redes, establezca el Tipo de red en Pública, Privada o Ninguna (consulte la

Figura 3-45 ). Si elige Público, se le pedirá que proporcione una etiqueta de nombre DNS
para su IP pública. También puede seleccionar los puertos para sus instancias de
contenedor.
FIGURA 3-45 Pestaña Redes para la hoja Crear instancia de contenedor

En la pestaña Avanzado, defina la Política de reinicio para sus contenedores. La política de

reinicio determina cuándo se reiniciará el contenedor. Puede elegir Si falla, Siempre o
Nunca (consulte la Figura 3-46 ). Elegir Siempre significa que sus contenedores se
reiniciarán independientemente de cómo se detengan. Elegir Al fallar significa que sus
contenedores se reinician solo si fallaron antes, y elegir Nunca significa que sus
contenedores nunca se reinician.
FIGURA 3-46 Pestaña Avanzado de la hoja Crear instancia de contenedor

Una vez creada la instancia de contenedor, la página de descripción general de Azure

Container Instance será similar a la que se muestra en la Figura 3-47 .
FIGURA 3-47 Instancias de contenedor de Azure en Azure Portal

Conéctese a ACI

Para revisar eventos, propiedades y registros de contenedores, haga clic en Contenedores en

Configuración, como se muestra en la Figura 3-48 .
FIGURA 3-48 Hoja de contenedores para ACI

Puede conectarse a contenedores directamente desde Azure Portal, como se muestra en

la Figura 3-49 . Puede elegir entre entornos de shell (bash y sh) para comenzar a interactuar
con los contenedores.
FIGURA 3-49 Instancias de contenedor de Azure en Azure Portal

Tenga en cuenta que también puede usar Azure PowerShell y la CLI para interactuar con
los contenedores.

Aprovisionar un contenedor mediante Azure Container Apps

Azure Container Apps (ACA) es un servicio PaaS de Azure creado sobre Kubernetes para
proporcionar una plataforma de contenedores sin servidor. Sin embargo, a diferencia de
Azure Kubernetes Services u otras plataformas basadas en Kubernetes, usted no puede ver
ni administrar los nodos subyacentes. Como servicio PaaS, Azure administra los nodos, la
orquestación y otros componentes de la infraestructura. Debido a esto, no se puede acceder
a las API de Kubernetes subyacentes ni al plano de control cuando se utiliza ACA.

ACA tiene varios Kubernetes y herramientas de código abierto integradas directamente en

el servicio, como Dapr, KEDA y envoy. Puede implementar sus aplicaciones y
microservicios estilo Kubernetes y desarrollarlos mediante el descubrimiento de servicios y
la división del tráfico, así como trabajos que pueden ser bajo demanda, programados o
controlados por eventos.

Crear una instancia de ACA

Puede usar cualquiera de las herramientas disponibles para implementar una instancia de
ACA, incluidos Azure Portal, PowerShell, CLI, plantillas ARM y archivos Bicep. Para
crear una instancia de ACA mediante Azure Portal, siga estos pasos:

1. Desde Azure Portal, busque Azure Container Apps .

2. En la hoja Azure Container Apps, seleccione Crear.
3. En la hoja Crear aplicación contenedor, complete los campos obligatorios:
1. Suscripción La suscripción de Azure en la que implementar el recurso.
2. Grupo de recursos El grupo de recursos lógico en el que se debe implementar el
recurso.
3. Nombre de la aplicación del contenedor El nombre de la instancia del recurso
ACA.
4. Región La región de Azure donde se implementa la instancia de ACA.
5. Entorno de aplicaciones de contenedor El entorno informático administrado para
la instancia de ACA.

La Figura 3-50 muestra la pestaña Conceptos básicos de la hoja Crear aplicación

contenedor que contiene estos campos.
FIGURA 3-50 Hoja Crear aplicación de contenedor

4. En la pestaña Conceptos básicos, para Entorno de aplicaciones de contenedor, haga

clic en Crear nuevo. La instancia de ACA requiere un entorno para ejecutarse. El entorno
define la computación para la instancia de ACA y si la instancia abarca zonas de
disponibilidad.
5. En la hoja Crear entorno de aplicaciones de contenedor, se pueden configurar las
opciones Tipo de entorno y Redundancia de zona. Para Tipo de entorno, elija Perfiles de
carga de trabajo o Solo consumo.
1. Perfiles de carga de trabajo Le permite utilizar computación basada en el
consumo, así como perfiles de hardware definidos que proporcionan costos predictivos y
rendimiento conocido.
2. Solo consumo Proporciona un entorno de aplicaciones sin servidor con opciones de
escalamiento donde paga solo por lo que usa.

La Figura 3-51 muestra la pestaña Conceptos básicos de la hoja Crear entorno de

aplicaciones de contenedor.
FIGURA 3-51 Crear entorno de aplicaciones de contenedor

6. En la hoja Crear entorno de aplicaciones de contenedor, seleccione la pestaña

Perfiles de carga de trabajo y luego haga clic en Agregar perfil de carga de trabajo. Tenga
en cuenta que esta pestaña no está disponible si selecciona Solo consumo en la pestaña
Básicos. Los perfiles de carga de trabajo son cantidades dedicadas de CPU y memoria que
se asignan a la instancia de ACA.
7. En la hoja Agregar perfil de carga de trabajo, seleccione Elegir un tamaño. La
Figura 3-52 muestra los perfiles de carga de trabajo predefinidos.

FIGURA 3-52 Tamaños de perfil de carga de trabajo

8. Si es necesario, ajuste el rango de instancias de escalado automático para el perfil de

carga de trabajo. Esto se puede ajustar de 0 a 20. Sin embargo, no se recomienda establecer
el extremo inferior del rango por debajo de 3 para lograr resiliencia. La Figura 3-53 muestra
la hoja Agregar perfil de carga de trabajo completa.
 FIGURA 3-53 Agregar perfil de carga de trabajo

9. Haga clic en Agregar para agregar el perfil al entorno de aplicaciones de contenedor

y volver a la hoja Crear entorno de aplicaciones de contenedor.
10. Seleccione la pestaña Monitoreo. ACA se puede configurar para enviar registros de
aplicaciones a un área de trabajo de Log Analytics, Azure Monitor, o para no guardar
registros, como se muestra en la Figura 3-54 .
 FIGURA 3-54 Pestaña Supervisión de la hoja Crear entorno de aplicaciones de
contenedor

11. En la hoja Crear entorno de aplicaciones de contenedor, haga clic en la pestaña

Redes. Puede configurar la instancia de ACA para que se integre con una red virtual o para
que sea una instancia independiente con una dirección IP pública. La Figura 3-55 muestra
la pestaña Redes con una nueva red virtual configurada.
 FIGURA 3-55 Opciones de red del entorno de aplicaciones de contenedor

12. Haga clic en Crear para crear el entorno ACA y regresar a la hoja Crear aplicación
contenedor.
13. En la hoja Crear aplicación contenedor, haga clic en la pestaña Contenedor. Aquí es
donde puede definir la imagen que se debe usar con el contenedor. De forma
predeterminada, se selecciona Usar imagen de inicio rápido y proporciona un contenedor de
muestra de "hola mundo". Anule la selección de esta opción para mostrar las opciones para
usar una imagen almacenada en Azure Container Registry, Docker Hub u otro registro. La
Figura 3-56 muestra la pestaña Contenedor con Usar imagen de inicio rápido
deseleccionada.
 FIGURA 3-56 Contenedores

La pestaña Enlaces se puede utilizar para conectar complementos para que se ejecuten en el
mismo entorno que su contenedor. Al momento de escribir este artículo, los complementos
disponibles se muestran en la Figura 3-57 e incluyen

 Redis
 mariadb
 PostgreSQL
 kafka
 Qdrant
 milvus
 Weavitae
FIGURA 3-57 Fijaciones para contenedores

14. Haga clic en Revisar + Crear y luego haga clic en Crear para crear la instancia de
ACA.

Conéctate a ACA

Después de implementar la instancia de ACA en su suscripción, recibirá una URL de

aplicación para el entorno del contenedor. La URL se encuentra en la hoja Descripción
general del recurso, como se muestra en la Figura 3-58 . Al hacer clic en la URL se
mostrará lo que se está ejecutando en el contenedor.
FIGURA 3-58 Descripción general de la aplicación Azure Container

Desde Azure Portal y otras herramientas, puede administrar varios aspectos de la instancia,
incluidos

 Autenticación Agregue un proveedor de identidad de Microsoft o de terceros para

administrar el flujo de autenticación de la aplicación.
 Secretos Secretos del par clave/valor a los que la aplicación necesita acceder dentro
del contenedor.
 Ingreso Determine si el contenedor acepta el tráfico de ingreso y el tipo y modo de
certificado que se usará en caso afirmativo.
 Implementación continua Integre la instancia con GitHub y/o Azure Container
Registry para el aprovisionamiento automático.
 Dapr Habilite Dapr en el entorno para llamadas de servicio a servicio en su entorno
de contenedor.
 Consola Acceso directo a la consola a un contenedor mediante las opciones de
shell bash o sh .
 Flujo de registros Vea el flujo de registros del contenedor directamente desde
Azure Portal.

La instancia de ACA también admite componentes comunes de Azure, como etiquetado,

bloqueos, métricas, alertas, configuraciones de diagnóstico y más.

Para conectarse a la consola de un contenedor, desde la instancia de ACA, seleccione

Consola. Puede elegir conectarse a una réplica y un contenedor específicos, así como
usar sh o bash , como se muestra en la Figura 3-59 .
FIGURA 3-59 Consola de la aplicación de contenedor de Azure

Gestionar el tamaño y el escalado de los contenedores.

El tamaño y la escala de sus contenedores dependerán del servicio o plataforma que elija
para su implementación.

Instancias de contenedor de Azure

ACI no proporciona ninguna orquestación adicional, escalamiento ni complementos

extensos que estén disponibles en otros entornos de contenedores. ACI está diseñado para
usarse para necesidades de contenedores rápidos y livianos donde se pueden crear y
desasignar contenedores fácilmente.

El tamaño de una instancia de ACI se produce durante la implementación cuando

selecciona las opciones de computación, memoria y GPU. Si necesita más computación,
simplemente implemente más instancias utilizando herramientas de automatización como
plantillas ARM o archivos Bicep. La Figura 3-60 muestra las opciones de tamaño para una
instancia de ACI durante la implementación. Los valores disponibles pueden depender de
su cuota de suscripción, región de Azure y tipo de sistema operativo de contenedor.
FIGURA 3-60 Tamaño de instancia de contenedor de Azure
Aplicaciones de contenedor de Azure

En comparación con ACI, Azure Container Apps ofrece más opciones de escala y tamaño.
En primer lugar, al crear el entorno ACA, usted elige entre utilizar un modelo de solo
consumo o perfiles de consumo y carga de trabajo. La opción de solo consumo factura solo
por lo que usa la aplicación contenedora, mientras que los perfiles de carga de trabajo
requieren CPU y memoria dedicadas que se asignan a un contenedor, por lo que usted paga
por ello incluso si no se usa por completo.

Después de implementar una ACA, puede escalar la réplica a la que está asociado un
contenedor para proporcionarle más recursos. Para configurar esto, navegue hasta la
instancia de ACA y luego seleccione la hoja Escalar y réplicas, como se muestra en la
Figura 3-61 .

FIGURA 3-61 Escala y réplicas de aplicaciones de contenedores de Azure

Para modificar la configuración de escala de la réplica, haga clic en Editar e implementar.

En la página Contenedor de la página Crear e implementar nueva revisión, puede
implementar imágenes de contenedor adicionales en la réplica, como se muestra en la
Figura 3-62 .
FIGURA 3-62 Pestaña Contenedor de la hoja Crear e implementar nueva revisión

Cuando agrega una nueva aplicación o contenedor de inicio , parte de las opciones de
configuración incluyen los núcleos de CPU y la memoria que se asignarán al contenedor.
Estas columnas también se muestran en la Figura 3-62 .

Para modificar la cantidad mínima y máxima de réplicas utilizadas para alimentar los
contenedores, seleccione la pestaña Escala. En la pestaña Escala, puede controlar los
límites de escalado automático, así como reglas de escala adicionales para determinar
cuándo o cómo se escala la réplica. Las réplicas se pueden configurar en un rango de 0 a
300, como se muestra en la Figura 3-63 .
FIGURA 3-63 Pestaña Escala de la hoja Crear e implementar nueva revisión

Para agregar reglas de escala, haga clic en Agregar. En la hoja Agregar regla de escala,
puede crear reglas de escala basadas en las siguientes opciones, como se muestra en la
Figura 3-64 :

 Escalado HTTP Escala la instancia cuando el número de solicitudes simultáneas

alcanza el umbral definido.
 Azure Queue escala la instancia cuando una cola alcanza el umbral de longitud
definido.
 Personalizado Autenticar y configurar metadatos adicionales para una métrica de
escala personalizada.
FIGURA 3-64 Agregar regla de escala

Habilidad 3.4: Crear y configurar Azure App Service

Azure App Service es una plataforma para desarrollar una aplicación en Azure sin
preocuparse por la infraestructura de back-end requerida. No es necesario crear, configurar
ni mantener una máquina virtual paraAloje sus aplicaciones si está utilizando una
aplicación web creada con App Service. Además, Azure le brinda flexibilidad para elegir el
lenguaje de código, como ASP.NET, PHP, Node.js, Python, etc. Para crear y mantener su
código, aún puede aprovechar los entornos de desarrollo comunes, como Visual Studio o
GitHub.

Esta habilidad cubre cómo:

 Aprovisionar un plan de App Service

 Configurar el escalado para un plan de App Service
 Crear un servicio de aplicación
 Asigne un nombre DNS personalizado existente a un servicio de aplicaciones
 Configurar certificados y TLS para un App Service
 Configurar la copia de seguridad para un App Service
 Configurar los ajustes de red para un App Service
 Configurar ranuras de implementación para un App Service

Aprovisionar un plan de App Service

Cuando implementa un App Service, en realidad se ejecuta en un plan de App Service. Un

plan de App Service ofrece recursos informáticos a la aplicación para su ejecución. Este
plan de App Service también se puede compartir con varias aplicaciones web.

Los planes de App Service tienen algunos niveles de precios que definen las características,
junto con el costo de cada una de ellas. Principalmente, existen tres categorías principales:

 Desarrollo/Prueba (Gratis, Compartido, Básico) Ejecuta una aplicación en la

misma máquina virtual de Azure que las aplicaciones de otros clientes. No puede
ampliarse.
 Producción (Estándar, Premium, Premium V2, Premium V3) Ejecuta una
aplicación en el hardware asignado. Puede escalar hacia arriba y hacia abajo o hacia
adentro y hacia afuera según el nivel definido.
 Aislado Ejecuta una aplicación en máquinas virtuales de Azure dedicadas con redes
virtuales de Azure dedicadas. Proporciona las máximas capacidades de
escalamiento.

Para crear un plan de App Service desde Azure Portal, busque planes de App Service . En
la hoja Planes de App Service, haga clic en Crear. Además del nombre de la suscripción y
el grupo de recursos, debe especificar un nombre del plan de App Service junto con el
sistema operativo (consulte la Figura 3-65 ). También debe seleccionar un Plan de precios
(SKU) apropiado según los requisitos de la aplicación.

FIGURA 3-65 Pestaña Conceptos básicos de la hoja Crear plan de App Service

Haga clic en Explorar planes de precios para ver los niveles de precios, como se muestra
en la Figura 3-66 . Es importante revisar las funciones y el hardware proporcionados antes
de seleccionar los niveles.
FIGURA 3-66 Seleccionar plan de precios de servicio de aplicaciones

Nota Niveles de precios para planes de servicio de APP

Elegir un nivel de precios adecuado según sus necesidades es fundamental. Consulte esta
página para encontrar todas las capacidades y límites para cada nivel de
precios: https://learn.microsoft.com/en-us/azure/azure-resource-
manager/management/azure-subscription-service-limits#app- límites de servicio .

Configurar el escalado para un plan de App Service

Puede escalar un plan de App Service ampliando o reduciendo el nivel, o ampliando (o

ampliando) a más (o menos) instancias. La ampliación cambia el nivel de precios que ha
seleccionado para el plan, junto con la computación, la memoria, el almacenamiento y otras
características que se incluyen en el nuevo nivel. El escalamiento horizontal multiplica la
cantidad de instancias que el plan tiene asociadas. Esto efectivamente duplica, triplica, etc.,
la cantidad de computación y memoria detrás del plan, dependiendo de cuántas instancias
se haya escalado.

Para escalar un plan de App Service, navegue hasta el plan desde Azure Portal.

Para ampliar, seleccione la hoja Ampliar (plan App Service).

La interfaz de usuario es similar a la que ve cuando implementa un App Service. Puede
seleccionar el nivel deseado, como se muestra en la Figura 3-67 .

FIGURA 3-67 Plan de servicio de aplicaciones ampliado

El escalamiento horizontal proporciona computación y memoria adicionales para las

aplicaciones web asociadas con el plan de App Service, de manera similar a la forma en
que un conjunto de escalado de máquinas virtuales puede escalarse para proporcionar más
nodos de computación. Para escalar horizontalmente un plan de App Service, seleccione la
hoja Escalamiento horizontal (plan de App Service).

Hay tres opciones para configurar el escalado de instancias, como se muestra en la Figura
3-68 :

 Manual Especifique manualmente el recuento de instancias y permanecerá estático

hasta que se modifique nuevamente.
 Automático Permita que Azure administre el escalado según el tráfico, pero puede
establecer un recuento máximo de instancias para la administración de costos.
 Basado en reglas Requiere que cree reglas para determinar cuándo y cómo ampliar
(más capacidad) o ampliar (menos capacidad). Se pueden crear reglas basadas en
métricas comunes de App Service, como ancho de banda, solicitudes, errores y más.
FIGURA 3-68 Plan de servicio de aplicaciones de escalamiento horizontal

Nota Métodos de escalamiento horizontal

Al momento de escribir este artículo, el método de escala automática está en versión

preliminar. Este tema puede incluirse o no en el examen, y los servicios en vista previa
podrían cambiar antes de estar disponibles de forma generalizada.

Crear un servicio de aplicación

App Service es un servicio de hospedaje que le permite crear e implementar sus

aplicaciones para ejecutarlas en Windows, Linux o su contenedor Docker en una
infraestructura administrada. También puedes elegir el lenguaje de programación con el que
te gustaría construir tu código. Actualmente, App Service es compatible con entornos
Windows y Linux. Además, App Service puede alojar sus contenedores Docker que se
ejecutan en Linux o Windows y ofrece capacidades adicionales, como escalado automático,
equilibrio de carga, seguridad, monitoreo y similares.

Con App Service, es fácil adquirir capacidades de DevOps, como la integración de CI/CD
con varias plataformas, como Azure DevOps, GitHub, Docker Hub u otras fuentes.
Además, App Service tiene amplias capacidades de supervisión mediante el uso de
Application Insights y Azure Monitor.
Para crear una aplicación web, desde la página de inicio de Azure Portal, busque App
Services . En la página Servicios de aplicaciones, seleccione Crear, aplicación web.
Además de seleccionar el nombre de la suscripción y el grupo de recursos, seleccione
Detalles específicos de la aplicación web. Puede elegir publicar su código o publicar un
contenedor Docker, como se muestra en la Figura 3-69 . También deberá seleccionar o
crear un nuevo plan de App Service, que se analiza anteriormente en esta habilidad.

FIGURA 3-69 Pestaña Conceptos básicos en la hoja Crear aplicación web

Si elige publicar su código, debe seleccionar una opción en el menú desplegable Runtime
Stack y seleccionar el sistema operativo (ya sea Windows o Linux) para ejecutar el código
de su aplicación. Al momento de escribir este artículo, las pilas de tiempo de ejecución
admitidas para un App Service incluyen
  .NETO
 Java
 Nodo
 PHP
 Pitón

Si elige publicar un contenedor Docker, seleccione el sistema operativo compatible (ya sea
Windows o Linux) para ejecutar su contenedor, como se muestra en la Figura 3-70 . Deberá
seleccionar la imagen del contenedor en la página de Docker.

FIGURA 3-70 Opciones de Docker Container para la hoja Crear aplicación web

Debe elegir Single Container o Docker Compose (Vista previa). Desde la configuración de
Fuente de imagen, usted elige de dónde extraer las imágenes (consulte la Figura 3-71 ). Sus
opciones son Plantillas QuickStart (solo aplicables para la opción Contenedor único), Azure
Container Registry, Docker Hub o cualquier otro registro privado.

FIGURA 3-71 Opciones de Docker para crear una aplicación web

Nota Web APP para Contenedores

Cuando implementa contenedores Docker en un App Service, se conoce como aplicación

web para contenedores.

En la pestaña Monitoreo, puede habilitar Application Insights para su aplicación o

contenedores. Esto le permite monitorear de cerca su aplicación web con métricas de
rendimiento. Application Insights es un recurso independiente que tiene su propia
administración y facturación. En la Figura 3-72 se muestra la creación de un recurso de
Application Insights con App Service .
FIGURA 3-72 Opciones de monitoreo para una aplicación web

Asigne un nombre DNS personalizado existente a un servicio de aplicaciones

De forma predeterminada, un App Service crea una entrada DNS para el nombre del
recurso de App Service con el dominio azurewebsites.net . Por
ejemplo, examrefaz104.azurewebsites.net . La mayoría de las organizaciones prefieren
utilizar sus propios nombres de dominio personalizados por motivos de seguridad,
reconocimiento de marca, facilidad de uso y más. Para agregar un dominio personalizado a
un App Service, navegue hasta la hoja Dominios personalizados de su recurso de App
Service, como se muestra en la Figura 3-73 .
FIGURA 3-73 Dominios personalizados de App Service

Si usted o su organización ya tienen un dominio personalizado, haga clic en Agregar

dominio personalizado. Si aún no posee un nombre de dominio registrado, puede adquirir
uno a través de un socio de Microsoft directamente desde Azure Portal. Para este ejemplo,
se concentrará en agregar un dominio que ya se compró.

Para agregar un dominio existente a un App Service, primero debe verificar que realmente
es propietario del dominio que está intentando agregar. Esta medida de seguridad evita que
otros Servicios de aplicaciones intenten suplantar su aplicación web.

La hoja Agregar dominio personalizado, que se muestra en la Figura 3-74 , proporciona

estas opciones:

 Proveedor de dominio Especifique si compró el dominio a través de App Service o

a través de un tercero.
 Certificado TLS/SSL Especifique si desea utilizar un certificado administrado de
App Service o agregar un certificado más adelante. Hablaremos de los certificados
más adelante en esta habilidad.
 Dominio El dominio personalizado que está agregando a App Service.
 Validación de dominio Los registros DNS necesarios para validar que usted es
propietario del dominio.

Para completar la validación del dominio, agregue los registros DNS que se presentan a sus
registros DNS públicos. En el caso que se muestra en la Figura 3-74 , App Service requiere
que un CNAME para app1.hugelab.net apunte a examrefaz104.azurewebsites.net . Además,
un registro TXT llamado asuid.app1 requiere que se agregue una cadena de clave específica
para el valor de texto. El tipo de registros que debe crear depende del dominio, pero
normalmente son tipos de registros CNAME, A y TXT.

FIGURA 3-74 Agregar dominio personalizado

Después de haber agregado los registros DNS, haga clic en Validar. El servicio verificará el
DNS público para verificar que haya agregado los registros. Si tiene éxito, las filas
requeridas mostrarán marcas de verificación y recibirá una nota de que pasó la validación,
como se muestra en la Figura 3-75 .
FIGURA 3-75 Validación de dominio

Para completar el proceso, haga clic en Agregar para asociar el dominio personalizado con
App Service. El dominio personalizado se agregará al App Service y responderá cuando
acceda al servicio mediante la nueva URL. Al agregar el dominio sin configurar TLS/SSL,
recibirá un error que indica que el dominio no está seguro y no tiene ningún enlace, como
se muestra en la Figura 3-76 . Esto es lo que se espera. Los certificados para aplicaciones
de App Service se analizan más adelante en esta habilidad.
FIGURA 3-76 Dominio personalizado recién agregado

Configurar certificados y TLS para un App Service

App Services puede utilizar certificados junto con dominios personalizados para ayudar a
proteger y brindar confianza a los usuarios y servicios que accederán al recurso. Hay tres
métodos admitidos para usar certificados con App Service:

 Certificados administrados Los certificados administrados se incluyen con un App

Service y son administrados por Digicert, pero tienen restricciones adicionales.
 Certificados de clave privada Si ya tiene su propio certificado, puede cargar el
certificado de clave privada .pfx para que App Service lo utilice.
 Certificados de clave pública Cargue certificados públicos .cer para que los utilice
App Service.

Para administrar los certificados de un App Service, navegue hasta App Service y abra la
hoja Certificados, como se muestra en la Figura 3-77 .
FIGURA 3-77 Certificados de App Service

Certificados gestionados

Los certificados administrados son certificados gratuitos disponibles para un App Service y
están completamente administrados por Microsoft, pero son emitidos por Digicert. Los
certificados administrados son fáciles de obtener, pero tienen algunos requisitos previos y
limitaciones que se deben tener en cuenta. Para crear un certificado gratuito, el plan de App
Service al que está asociada la aplicación web no puede estar en el nivel gratuito.

Si planea usar un dominio personalizado con un certificado administrado, el dominio ya

debe estar agregado a App Service. La adición de un dominio personalizado a un App
Service se analizó anteriormente en esta habilidad. Además, si planea utilizar un dominio
raíz, la configuración de App Service no puede incluir ninguna restricción de IP. La
aplicación debe ser accesible desde internet para procesar la creación y renovación del
certificado.

Los certificados gratuitos también tienen las siguientes restricciones:

  No se pueden utilizar comodines en el certificado.
 No se puede utilizar como certificado de cliente.
 No se puede utilizar con DNS privado.
 No se puede exportar desde App Service.
 Solo admite caracteres alfanuméricos, guiones y puntos.
 Los nombres de dominio personalizados no pueden exceder los 64 caracteres.

Para agregar un certificado administrado a su App Service, navegue hasta la hoja

Certificados de App Service. En la pestaña Certificados administrados, que se muestra en la
Figura 3-77 , haga clic en Agregar.

En la hoja Agregar certificado administrado de App Service, seleccione el dominio

personalizado que agregó anteriormente en el menú desplegable Dominio personalizado.
Especifique un nombre descriptivo para el certificado y luego haga clic en Validar.

Si App Service pasa la validación, como se muestra en la Figura 3-78 , haga clic en
Agregar para generar el certificado y agregarlo a App Service. Este proceso podría tardar
hasta 10 minutos en completarse.

FIGURA 3-78 Agregar un certificado administrado

Certificados de clave privada

Los certificados de clave privada son certificados .pfx que recibió de su autoridad de
certificación (CA) o de un proveedor externo de confianza. Puede cargar estos certificados
directamente en un App Service o cargarlos en un almacén de claves de Azure que se puede
integrar con un App Service.

Los certificados privados deben estar protegidos con contraseña, estar cifrados mediante
triple DES, tener al menos 2048 bits y contener todos los certificados intermedios y raíz de
la cadena de certificados. Si planea utilizar el certificado con un dominio personalizado, el
certificado debe contener un atributo de uso de clave extendida para la autenticación del
servidor.

Para agregar un certificado de clave privada a un App Service, navegue hasta la hoja
Certificados de App Service y seleccione la pestaña Traiga su propio certificado (.pfx). En
esta pestaña, haga clic en Agregar certificado.

En la hoja Agregar certificado de clave privada, hay tres opciones en el menú desplegable
Fuente:

 Importar desde App Service Esto se puede utilizar si cargó previamente un

certificado.
 Cargar certificado (.pfx) Seleccione esta opción si planea cargar el certificado
directamente en App Service.
 Importar desde Azure Key Vault Seleccione esta opción si ha cargado el
certificado en Azure Key Vault y planea apuntar App Service a Key Vault para
obtener el certificado.

Si selecciona Cargar certificado (.pfx), se le solicitará información para cargar el

certificado, incluida

 Archivo de certificado PFX

 Contraseña del certificado
 Nombre descriptivo del certificado

Complete los campos y luego haga clic en Validar, como se muestra en la Figura 3-79 .
Una vez completada la validación, haga clic en Agregar para cargar el certificado en App
Service.
FIGURA 3-79 Agregar un certificado de clave privada

Para administrar el dominio y el certificado por separado, debe asociar el certificado con el
dominio agregando enlaces al dominio. Para agregar enlaces, navegue hasta App Service y
luego seleccione Dominios personalizados. En la hoja Dominios personalizados, seleccione
Agregar enlaces para el dominio que agregó y para el que tiene un certificado (consulte
la Figura 3-76 ).

En la hoja Agregar enlace TLS/SSL, que se muestra en la Figura 3-80 , en el menú

desplegable Certificado, seleccione el certificado que cargó en App Service; luego haga clic
en Agregar. El certificado se asociará con el dominio personalizado.
FIGURA 3-80 Agregar enlace TLS/SSL

Certificados de clave pública

Los certificados de clave pública se pueden cargar directamente en un App Service y deben
estar en un formato de archivo .cer sin una clave privada. En la pestaña Certificados de
clave pública de la hoja Certificados, haga clic en Agregar certificado. Se le pedirá que
cargue el archivo .cer y proporcione un nombre descriptivo, como se muestra en la Figura
3-81 . Haga clic en Agregar para cargar el certificado.
FIGURA 3-81 Agregar un certificado de clave pública

Configurar la copia de seguridad para un App Service

La mayoría de los planes de App Service incluyen una función de copia de seguridad
automática que se puede personalizar aún más para crear copias de seguridad de su
aplicación web. Los niveles del plan Free y Shared App Service no incluyen copias de
seguridad. Las copias de seguridad automáticas se realizan cada hora y tienen una escala
móvil de retención de 30 días:

 Las copias de seguridad cada hora se mantienen durante los tres días más recientes.
 Los días 4 a 14 conservan las copias de seguridad cada tres horas.
 Los días 15 a 30 conservan cada sexta hora de copias de seguridad.

¿Necesita más revisión? Copias de seguridad automáticas versus personalizadas

App Services puede utilizar copias de seguridad automáticas o personalizadas. Para obtener
una lista completa de las diferencias de funciones entre automático y personalizado,
visite https://learn.microsoft.com/en-us/azure/app-service/manage-
backup?tabs=portal#automatic-vs-custom-backups .

Si necesita modificar la sincronización, la retención, las copias de seguridad parciales y

más, personalice la copia de seguridad para App Service. Para personalizar la copia de
seguridad, navegue hasta el recurso de App Service y seleccione la hoja Copias de
seguridad. Se mostrarán las copias de seguridad automáticas cada hora, como se muestra
en la Figura 3-82 , con una opción en cada fila para restaurar desde esa copia de seguridad.
Alternativamente, puede hacer clic en Configurar copias de seguridad personalizadas en el
menú superior.
FIGURA 3-82 Copias de seguridad de App Service

Las copias de seguridad personalizadas requieren que especifique una cuenta de

almacenamiento y un contenedor de blobs para almacenar las copias de seguridad. Como
parte de la programación, puede especificar la copia de seguridad cada hora o diariamente a
una hora específica, así como conservar la copia de seguridad. La retención se puede
configurar como un valor entre 0 y 60, donde el cero representa el almacenamiento de la
copia de seguridad de forma indefinida. La Figura 3-83 muestra la página de configuración
de copia de seguridad personalizada.
FIGURA 3-83 Copias de seguridad personalizadas de App Service
Configurar los ajustes de red para un App Service

De forma predeterminada, App Services incluye una URL de acceso público y el acceso a
la red pública está habilitado sin restricciones. Sin embargo, la mayoría de las
organizaciones tendrán una política de seguridad o cumplimiento que requiere que todo el
tráfico entrante sea inspeccionado primero por un firewall de aplicaciones web (WAF), o
puede requerir que todo el tráfico entrante se origine desde una red específica.

Para lograr esto, modifique la configuración de red del App Service. Desde Azure Portal,
navegue hasta App Service y luego seleccione la hoja Redes, como se muestra en la Figura
3-84 .

FIGURA 3-84 Redes de App Service

Configuración del tráfico entrante

De forma predeterminada, se puede acceder a un punto final público de App Service desde
cualquier lugar de Internet sin restricciones de acceso. Si su organización necesita
modificar ese comportamiento, haga clic en Habilitado sin restricciones de acceso.

En la página Restricciones de acceso, puede modificar la red entrante para que responda
solo desde redes virtuales y/o direcciones IP específicas, o para deshabilitar completamente
el acceso entrante, como se muestra en la Figura 3-85 .

FIGURA 3-85 Redes de App Service

Si selecciona Habilitado desde redes virtuales y direcciones IP seleccionadas, puede crear

reglas individuales que permitan o rechacen direcciones IP específicas. También hay un
campo Acción de regla no coincidente para permitir o denegar el tráfico que no coincida
explícitamente con ninguna de las reglas que configure.
En la página Restricciones de acceso, haga clic en Agregar. La página Agregar regla tiene
los siguientes campos:

 Nombre El nombre para mostrar de la regla.

 Acción Si se debe permitir o denegar el tráfico que coincida
 Prioridad La prioridad de la regla para el procesamiento.
 Descripción Una descripción de la regla para la documentación interna.
 Escriba El origen del tráfico: IPv4, IPv6, una red virtual o etiqueta de servicio de
Azure.
 Bloque de dirección IP Cuando se selecciona IPv4, la notación CIDR de las
direcciones a configurar
 X-Forwarded-Host Cualquier nombre de host que deba reenviarse al App Service
 X-Forwarded-For La dirección IP a reenviar para comunicarse
 X-Azure-FDID Una puerta frontal opcional o un ID de proxy inverso
 X-FD-HealthProbe El ID de la sonda de estado que se utilizará con un proxy
inverso

La Figura 3-86 muestra la página Agregar regla configurada para permitir el tráfico desde
la red 10.0.0.0/16.
FIGURA 3-86 Agregar regla de tráfico entrante

Configuración del tráfico saliente

Se puede integrar un App Service con una red virtual de Azure para permitir que la
aplicación realice conexiones salientes a máquinas virtuales u otros puntos finales en una
red virtual. La red virtual y App Service deben estar en la misma región de Azure para
poder integrarse. La integración de un App Service con una red virtual permite que el App
Service

 Acceda a recursos en la red virtual integrada y otras redes virtuales que estén
emparejadas con la red integrada.
 Acceda a recursos que utilizan servicios o puntos finales privados.
 Acceda a recursos a través de circuitos ExpressRoute o túneles VPN.
 Fuerce el tráfico saliente de túnel a través de un firewall u otro dispositivo de red.

Para configurar la integración de red virtual para un App Service, navegue hasta la hoja
Redes de App Service. En Configuración del tráfico saliente, haga clic en No configurado
junto a Integración de red virtual (consulte la Figura 3-84 ).

Se mostrará la hoja Integración de red virtual. Seleccione Agregar integración de red

virtual. En la hoja Agregar integración de red virtual, seleccione la suscripción, la red
virtual y la subred específica con la que integrar App Service, como se muestra en la Figura
3-87 .
FIGURA 3-87 Agregar integración de red virtual

Configurar ranuras de implementación para un App Service

Los espacios de implementación son versiones activas y accesibles de su aplicación web

que se ejecutan en el mismo plan de App Service, pero cada una tiene su propio nombre de
host y se puede configurar por separado. Puede configurar un espacio de producción donde
se alojan los usuarios y las conexiones activos, así como espacios de desarrollo, canario,
aceptación de usuarios u otros espacios. Cada ranura puede tener sus propios elementos de
configuración, como cadenas de conexión y variables de entorno. Esto facilita la realización
de pruebas A/B o azul/verde para nuevas versiones de su aplicación.

La cantidad de espacios y las características específicas dependen del nivel del plan de App
Service que haya configurado. Para agregar una ranura a su App Service, navegue hasta el
recurso y luego seleccione la hoja Ranuras de implementación, como se muestra en la
Figura 3-88 .
FIGURA 3-88 Hoja Ranuras de implementación de App Service

Para agregar una ranura, haga clic en Agregar ranura. Se le pedirá que proporcione un
nombre para la ranura y especifique si desea clonar la configuración de una ranura
existente. La clonación proporciona un método sencillo para copiar variables de entorno y
otras configuraciones de una ranura a una ranura nueva para minimizar los cambios que
deben realizarse.

Cuando agregue la ranura, aparecerá en la hoja Ranuras de implementación. La ranura

tendrá su propia URL a la que se podrá acceder y puede tener un conjunto de código
completamente diferente implementado en la ranura. Cada ranura puede tener sus propias
opciones de implementación, como la implementación automática desde una rama
específica en un repositorio.

La Figura 3-88 también muestra una columna para % de tráfico. De forma predeterminada,
el espacio de producción recibe todo el tráfico destinado a App Service. Cuando agrega
espacios de implementación, puede configurar un porcentaje específico de nuevas
solicitudes que se enviarán al espacio. Esto le permite probar la última versión de su
aplicación "en producción" con usuarios reales, incluso si es solo el 1% de su tráfico total.

Cuando esté listo para mover una versión de una aplicación de una ranura a otra, como por
ejemplo de la etapa de preparación a la producción, puede intercambiar las ranuras
fácilmente. Esto le pedirá que copie algunos cambios de configuración entre entornos o que
los deje como están. La Figura 3-89 muestra la página de intercambio con los cambios de
origen, destino y configuración.
FIGURA 3-89 Ranuras de intercambio de App Service

Resumen del capítulo

Este capítulo se centró en gran medida en la creación y configuración de máquinas virtuales

en Azure, así como en implementaciones automatizadas utilizando plantillas de Azure
Resource Manager e incluso herramientas de línea de comandos. El capítulo concluyó
centrándose en los servicios de contenedores, como ACI y ACA, seguidos de Azure App
Service y App Service Plans. Estas son algunas de las conclusiones clave.

 Cada familia informática está optimizada para cargas de trabajo generales o

específicas. Debes optimizar tu VM eligiendo el tamaño más apropiado.
 Puede crear máquinas virtuales desde Azure Portal, PowerShell, la CLI, plantillas
de Azure Resource Manager o archivos Bicep. Debe comprender cuándo utilizar
 qué herramienta y cómo configurar el recurso de la máquina virtual durante y
después del aprovisionamiento. Por ejemplo, los conjuntos de disponibilidad solo se
pueden configurar en el momento del aprovisionamiento, pero los discos de datos se
pueden agregar en cualquier momento.
 Puede conectarse a máquinas virtuales de Azure mediante una dirección IP pública
o una dirección IP privada con RDP, SSH o incluso PowerShell. Para conectarse a
una máquina virtual mediante una IP privada, también debe habilitar la conectividad
como de sitio a sitio, punto a sitio o ExpressRoute.
 Un método común para solucionar problemas de máquinas virtuales con
conectividad RDP/SSH o problemas de aplicaciones inexplicables es volver a
implementar la máquina virtual. Volver a implementar mueve la máquina virtual a
un nodo de Azure diferente.
 El almacenamiento de VM viene en HDD estándar, SSD estándar, SSD Premium y
Ultimate SSD en versión preliminar. Es importante comprender qué nivel elegir
para la planificación de capacidad y rendimiento.
 Las zonas de disponibilidad proporcionan alta disponibilidad en los centros de datos
dentro de una región de Azure. Los conjuntos de disponibilidad proporcionan alta
disponibilidad dentro de un único centro de datos.
 Los discos administrados brindan más disponibilidad que los discos no
administrados al alinearse con conjuntos de disponibilidad y proporcionar
almacenamiento en unidades de almacenamiento redundantes.
 Los conjuntos de escalado de máquinas virtuales (VMSS) pueden escalar hasta
1000 instancias. Debe asegurarse de crear el VMSS configurado para conjuntos de
gran escala si tiene intención de superar las 100 instancias. También hay varios
otros límites a considerar. Con una imagen personalizada, solo puede crear hasta
300 instancias. Para escalar por encima de 100 instancias, debe usar la SKU
estándar de Azure Load Balancer o Azure App Gateway.
 Las plantillas de Azure Resource Manager se crean mediante JSON y le permiten
definir la configuración de recursos, como máquinas virtuales, cuentas de
almacenamiento, etc., de forma declarativa.
 Azure Container Registry es un repositorio para almacenar imágenes de
contenedores.
 Azure Container Instances es una forma de implementar contenedores aislados de
una manera mucho más rápida y sencilla sin preocuparse por la infraestructura
backend.
 Azure Container Apps es un servicio PaaS creado en Kubernetes, pero no
proporciona acceso a la API de Kubernetes ni a los nodos de control.
 App Service es un servicio de hospedaje que le permite crear e implementar sus
aplicaciones para ejecutarlas en Windows, Linux o un contenedor Docker en una
infraestructura administrada. También puedes elegir el lenguaje de programación
con el que te gustaría construir tu código.
 Un plan App Service ofrece recursos informáticos a la aplicación web para su
ejecución. Este plan de App Service también se puede compartir con varias
aplicaciones web.
Experimento mental

En este experimento mental, aplique lo que ha aprendido en este capítulo. Puede encontrar
respuestas a estas preguntas en la siguiente sección, "Respuestas del experimento".

escenario 1

Usted es el administrador de TI de Contoso y tiene la tarea de migrar una granja de

servidores web y una base de datos existentes a Microsoft Azure. La aplicación web está
escrita en PHP y se implementa en 20 servidores físicos que ejecutan RedHat para el
sistema operativo y Apache para el servidor web. El backend consta de dos servidores
físicos que ejecutan MySQL en una configuración activa/pasiva.

La solución debe brindar la capacidad de escalar al menos a tantos servidores web como la
solución existente e idealmente la cantidad de instancias de servidor web debería ajustarse
automáticamente según la demanda. Se debe poder acceder a todos los servidores en la
misma red, de modo que el administrador pueda conectarse fácilmente a ellos usando SSH
desde un jumpbox (una máquina virtual que está expuesta a una IP pública y se usa para
conectarse a otras máquinas virtuales en la red usando IP privadas internamente) para
administrar las máquinas virtuales.

Responda las siguientes preguntas para su gerente:

1. ¿Qué opción informática sería ideal para los servidores web?

2. ¿Cómo se deben configurar los servidores para alta disponibilidad?
3. ¿Cuál sería la configuración de almacenamiento recomendada para los servidores
web? ¿Qué pasa con los servidores de bases de datos?

Escenario 2

Usted es el arquitecto de soluciones de Contoso y debe diseñar una solución basada en

Python para hospedar una aplicación web en Microsoft Azure. Los usuarios deben poder
acceder a esta aplicación desde múltiples ubicaciones y la aplicación debe estar disponible
las 24 horas. Además, la aplicación debe implementarse con capacidades DevOps, como
implementación continua, administración de paquetes y similares.

Además, no desea administrar la infraestructura y desea evitar la administración tanto como

sea posible. No desea administrar Windows y las actualizaciones de software usted mismo.

Responda las siguientes preguntas sobre su solución:

1. ¿Qué opción informática sería ideal para alojar esta aplicación web?
2. ¿Cómo evitarás gestionar la infraestructura?
3. ¿Cómo se asegurará de que su aplicación tenga alta disponibilidad?
Respuestas del experimento mental

Esta sección contiene la solución al experimento mental del capítulo.

escenario 1

1. Los servidores web funcionarían mejor si se implementaran en un conjunto de

escalado de máquinas virtuales (VMSS), debido a los requisitos de conectividad
SSH. El escalado debe configurarse en el VMSS para abordar el requisito de
aumentar o reducir automáticamente el número de instancias según la demanda
(CPU) utilizada en los servidores web.
2. Los servidores web deben implementarse en su propio conjunto de disponibilidad o
zona de disponibilidad si está disponible dentro de la región. El nivel de base de
datos también debe implementarse en su propio conjunto de disponibilidad o zona
de disponibilidad.
3. Es probable que los servidores web no requieran mucha E/S, por lo que el SSD
estándar debería ser apropiado. Es probable que los servidores de bases de datos
requieran un uso intensivo de E/S, por lo que Premium SSD es el enfoque
recomendado. Para minimizar la sobrecarga de administración y garantizar que la
planificación de la capacidad de almacenamiento se realice correctamente, se deben
utilizar discos administrados en ambos casos.

Escenario 2

1. Azure App Service será el más adecuado para este conjunto de requisitos. Debe
implementar una aplicación web Python en App Service en Linux.
2. Azure App Service es una solución PaaS, por lo que una infraestructura
administrada alojará su aplicación. No necesita preocuparse por las máquinas
virtuales en las que se implementa la aplicación. No se requieren esfuerzos
administrativos adicionales para administrar Windows y las actualizaciones de
software.
3. Azure App Service proporciona una disponibilidad del 99,95 por ciento para el
nivel Básico (o superior). También debe considerar el uso del escalado automático
según el uso anterior del capítulo para que aún pueda aceptar tráfico durante las
horas pico de carga de trabajo.

Capítulo 4
Configurar y administrar redes virtuales

Una red virtual de Azure (o VNet) proporciona la base de la infraestructura de red de

Azure. Las máquinas virtuales están conectadas a redes virtuales. Esta conexión
proporciona conectividad entrante y saliente a otras máquinas virtuales, redes locales e
Internet. Azure proporciona muchas características de red que resultarán familiares para
aquellos que ya tienen experiencia en redes, como las capacidades para controlar qué flujos
de red están permitidos y controlar el enrutamiento de la red. Estas características permiten
que las implementaciones de Azure implementen arquitecturas de red familiares, como la
segmentación de red entre capas de una aplicación de N niveles.

Este capítulo se centra en las capacidades principales que le permiten conectar sus
máquinas virtuales de Azure de manera flexible y segura.

Habilidades cubiertas en este capítulo:

 Habilidad 4.1: Configurar y administrar redes virtuales en Azure

 Habilidad 4.2: Configurar el acceso seguro a redes virtuales
 Habilidad 4.3: Configurar la resolución de nombres y el equilibrio de carga

Nota Objetivos del examen de Microsoft

Las secciones de este capítulo se alinean con los objetivos que se enumeran en la guía de
estudio AZ-104 de Microsoft. Sin embargo, las secciones se presentan en un orden
diseñado para ayudarle a aprender y no coinciden directamente con el orden que se presenta
en la guía de estudio. En el examen, aparecerán preguntas de diferentes secciones en orden
aleatorio. Para obtener la lista completa de objetivos, visite https://learn.microsoft.com/en-
us/credentials/certifications/resources/study-guides/az-104 .

Habilidad 4.1: Configurar y administrar redes virtuales en Azure

Las redes virtuales de Azure (VNet) forman la base de la infraestructura de redes de Azure.
Cada VNet define un espacio de direcciones de red, que comprende uno o más rangos de
direcciones IP. Este espacio de red luego se divide en subredes. Las direcciones IP para
máquinas virtuales, así como algunos otros servicios, como un equilibrador de carga interno
de Azure, se asignan desde estas subredes.Para cada subred, usted define qué flujos de red
están permitidos (usando grupos de seguridad de red) y qué rutas de red deben tomarse
(usando rutas definidas por el usuario). Puede utilizar estas funciones juntas para
implementar muchas topologías de red comunes, como una DMZ que contiene un
dispositivo de seguridad de red o una arquitectura de aplicaciones de varios niveles con
comunicaciones restringidas entre niveles de aplicaciones.

Esta habilidad cubre cómo:

 Crear y configurar redes y subredes virtuales.

 Crear y configurar el emparejamiento de redes virtuales
 Configurar direcciones IP públicas
 Configurar rutas de red definidas por el usuario
 Solucionar problemas de conectividad de red
Crear y configurar redes y subredes virtuales.

Una VNet es un recurso de Azure que define el espacio de direcciones, las subredes y la
conectividad para los recursos de Azure. Cuando crea una VNet, la configuración más
importante es el rango (o rangos) de IP que utilizará la VNet.

Los rangos de IP se definen utilizando la notación de enrutamiento entre dominios sin

clases (CIDR). Por ejemplo, el rango 10.5.0.0/16 representa todos los rangos de IP que
comienzan con 10.5. El /16 representa la máscara de bits e indica que los primeros 16 bits
son los mismos para cada IP en el rango de direcciones. Cada red virtual puede utilizar un
único rango de IP o varios rangos de IP separados.

Nota Notación CIDR

Debe comprender la notación CIDR para trabajar eficazmente con redes virtuales en Azure.
Hay muchas buenas explicaciones que se pueden encontrar en línea. Por ejemplo,
consulte https://devblogs.microsoft.com/premier-developer/understanding-cidr-notation-
when-designing-azure-virtual-networks-and-subnets/ .

Nota Rangos de IP de la red virtual

Normalmente es una buena idea planificar el espacio de su red con antelación.

Normalmente, desea evitar la creación de superposiciones con otras redes virtuales o con
entornos locales porque cualquier superposición le impedirá conectar estas redes más
adelante.

Se recomienda que los rangos de IP de su VNet se tomen de los rangos de direcciones

privadas definidos en RFC 1918:

 10.0.0.0–10.255.255.255 (10.0.0.0/8)
 172.16.0.0–172.31.255.255 (172.16.0.0/12)
 192.168.0.0– 192.168.255.255 (192.168.0.0/16)

También puede utilizar rangos de IP públicos direccionables por Internet en su red virtual.
Sin embargo, esto no se recomienda porque las direcciones dentro de su VNet tendrán
prioridad y las máquinas virtuales en su VNet ya no podrán acceder a las direcciones de
Internet correspondientes.

Además, hay una pequeña cantidad de rangos de IP que no puede usar porque están
reservados por la plataforma Azure:

 169.254.0.0/16 (Enlace local)

 168.63.129.16/32 (DNS proporcionado por Azure)
Subredes

La integración de recursos de Azure en una red virtual requiere una subred. Las subredes se
utilizan para dividir el espacio IP de VNet. Diferentes subredes pueden tener diferentes
reglas de enrutamiento y seguridad de red, por lo que las aplicaciones y los niveles de
aplicaciones se pueden aislar y se pueden controlar los flujos de red entre ellos. Por
ejemplo, considere una arquitectura de aplicación típica de tres niveles que comprende un
nivel web, un nivel de aplicación y un nivel de base de datos. Al implementar cada nivel
como una subred separada, puede controlar con precisión qué flujos de red están permitidos
entre niveles y desde Internet.

Requisitos importantes de subred

El nombre de una subred debe ser único dentro de esa VNet. No puede cambiar el nombre
de la subred una vez creada. Cada subred también debe definir un único rango de red (en
formato CIDR). Este rango debe estar contenido dentro de los rangos de IP definidos por la
VNet. Solo se pueden asignar direcciones IP dentro de las subredes a máquinas virtuales y
otros recursos. Las subredes no tienen que abarcar todo el espacio de direcciones de la red
virtual; Las subredes pueden ser un subconjunto, dejando espacio no utilizado para futuras
expansiones.

Azure reserva algunas direcciones IP de cada subred. Al igual que las redes IP estándar,
Azure reserva la primera y la última dirección IP en cada subred para la identificación y
transmisión de la red. Además, reserva otras tres direcciones al inicio del rango de servicios
internos de Azure, para un total de cinco direcciones IP inutilizables.

Debe definir una subred al crear una red virtual mediante Azure Portal. Las redes virtuales
normalmente pueden tener varias subredes y usted puede agregar nuevas subredes a su red
virtual en cualquier momento.

No puede cambiar el rango de direcciones si ya hay recursos asociados o implementados en

la subred. Si desea realizar un cambio en el rango de direcciones de una subred, primero
debe eliminar todos los objetos de esa subred. Si la subred está vacía, puede cambiar el
rango de direcciones a cualquier rango que esté dentro del espacio de direcciones de la
VNet y que no esté asignado a ninguna otra subred.

Las subredes se pueden eliminar de las redes virtuales solo si están vacías. Una vez que se
elimina una subred, las direcciones que formaban parte de ese rango de direcciones se
liberan y están disponibles nuevamente para su uso dentro de las nuevas subredes que cree.

Configuraciones de red virtual adicionales

Hasta ahora, esta sección se ha centrado en las configuraciones más importantes de cada
VNet y subred: los rangos de direcciones IP. Hay algunas configuraciones y características
adicionales de redes virtuales y subredes que se deben tener en cuenta. La Tabla 4-
1 proporciona un resumen de algunas configuraciones admitidas por las redes virtuales.
TABLA 4-1 Propiedades de una red virtual

Propiedad Descripción

Nombre El nombre de la VNet debe ser único dentro del grupo de recursos,
tener entre 2 y 64 caracteres y puede contener letras (sin distinguir
entre mayúsculas y minúsculas), números, guiones bajos, puntos o
guiones. Debe comenzar con una letra o número y terminar con una
letra, número o guión bajo.

Ubicación Cada VNet está vinculada a una única región de Azure y solo puede ser
utilizada por recursos (como máquinas virtuales) en la misma región.

Espacio de Una variedad de rangos de direcciones IP disponibles para uso de

dirección subredes.

Configuración Contiene una serie de servidores DNS. Si se especifica, estos servidores

de DNS DNS se configuran en máquinas virtuales de la red virtual en lugar de
los servidores DNS proporcionados por Azure.

Subredes La lista de subredes configuradas para esta VNet.

Miradas La lista de emparejamientos configurados para esta red virtual. Los

emparejamientos se utilizan para crear conectividad de red entre redes
virtuales independientes.

La Tabla 4-2 proporciona un resumen de las configuraciones admitidas por las subredes de
redes virtuales.

TABLA 4-2 Configuración de una subred de red virtual

Propiedad Descripción

Nombre El nombre de la subred debe ser único dentro de la VNet. Debe tener
entre 2 y 80 caracteres y puede contener letras (sin distinguir entre
mayúsculas y minúsculas), números, guiones bajos, puntos o guiones.
Debe comenzar con una letra o un número y debe terminar con una
letra, un número o un guión bajo.
 Propiedad Descripción

Rango de El rango de direcciones IP para una subred, especificado en notación

direcciones CIDR. Todas las subredes deben ubicarse dentro del espacio de
direcciones de VNet y no pueden superponerse.

Grupo de Referencia al grupo de seguridad de red (NSG) para la subred. Los

seguridad de red NSG se pueden asociar a una subred y se utilizan para controlar qué
flujos de tráfico entrante y saliente están permitidos.

Tabla de rutas Tabla de rutas aplicada a la subred y utilizada para anular las rutas
predeterminadas del sistema. Se utilizan para enviar tráfico a redes de
destino que son diferentes a las rutas que Azure usa de forma
predeterminada.

Puntos finales de Una serie de puntos finales de servicio para esta subred. Los puntos de
servicio (y conexión de servicio proporcionan una ruta directa a varios servicios
políticas) PaaS de Azure (como Azure Storage), sin necesidad de un punto de
conexión con acceso a Internet. Las políticas de puntos finales de
servicio brindan un mayor control sobre a qué instancias de esos
servicios se puede acceder.

Delegaciones Una serie de referencias a delegaciones en la subred. Las delegaciones

permiten que ciertos servicios de Azure utilicen subredes, que luego
implementarán recursos administrados (como una Instancia
administrada de Azure SQL Database) en la subred. El acceso a estos
recursos es privado y puede controlarse mediante NSG. Las
delegaciones también admiten el acceso hacia y desde las redes
locales cuando se utilizan redes híbridas.

Cree una red virtual y subredes mediante Azure Portal

Para crear una nueva VNet mediante Azure Portal, busque redes virtuales . En la hoja
Redes virtuales, haga clic en Crear.

Se abre la hoja Crear red virtual. Aquí puede proporcionar información de configuración
sobre la red virtual. Este blade requiere las siguientes entradas, como se muestra en la
Figura 4-1 :
FIGURA 4-1 Pestaña Conceptos básicos de la hoja Crear red virtual

 Suscripción en la que se crea la VNet

 El grupo de recursos donde se crea la VNet
 Nombre de la red virtual
 La ubicación de VNet

Los siguientes valores se establecen automáticamente, aunque puede anularlos según sea
necesario:

 Espacio de direcciones que se utilizará para la red virtual mediante notación CIDR
 Nombre de subred para la primera subred en la VNet
 El rango de direcciones de la primera subred.

En la pestaña Seguridad, puede habilitar servicios de seguridad comunes para la red virtual,
incluidos
  Azure Bastion Proporciona conectividad RDP y SSH segura a las máquinas
virtuales de la red virtual.
 Azure Firewall Proporciona un firewall administrado de capa 7 en la red virtual.
 Protección de red Azure DDoS Esto proporciona una mitigación mejorada de
ataques DDoS con ajuste adaptativo, telemetría y notificaciones para ataques DDoS.

En la pestaña Direcciones IP, puede proporcionar espacios de direcciones para usar en la

red virtual mediante notación CIDR. Al crear una VNet mediante Azure Portal, puede
especificar varios rangos de direcciones IP y puede especificar una o más subredes
(consulte la Figura 4-2 ). Cuando crea una subred, también puede crear los puntos finales
de servicio si desea utilizar cualquiera de los servicios de Azure.
FIGURA 4-2 Definir subredes al crear una red virtual

Una vez que la red virtual haya completado el aprovisionamiento, revise la configuración
mediante Azure Portal. Observe que la subred Subnet0 se ha creado como parte de las
entradas que se muestran en la Figura 4-3 .
FIGURA 4-3 Subredes para la red virtual ExamRef-VNet

Para crear otra subred en VNet, haga clic en Subred en la hoja Subredes y complete los
siguientes campos, como se muestra en la Figura 4-4 :
FIGURA 4-4 Blade Agregar subred

 Nombre (de la subred)

 Rango de direcciones de subred (bloque CIDR)
 Puerta de enlace NAT
 Grupo de seguridad de red (si corresponde)
 Tabla de rutas (si existe)
 Puntos finales de servicio
 Delegación de subred
Crear y configurar el emparejamiento de redes virtuales

El emparejamiento de VNet permite que los recursos de dos redes virtuales independientes
se comuniquen directamente mediante sus direcciones IP privadas. Las redes virtuales
pueden estar en la misma región de Azure o en regiones de Azure independientes. El
emparejamiento entre redes virtuales en diferentes regiones se denomina emparejamiento
de redes virtuales globales. En todos los casos, el tráfico entre redes virtuales emparejadas
viaja a través de la infraestructura troncal de Microsoft, no a través de la Internet pública.
Las redes virtuales emparejadas deben tener espacios de direcciones IP que no se
superpongan.

Nota Interconexión de red virtual

Puede emparejar redes virtuales en diferentes suscripciones, incluso si esas suscripciones

están bajo diferentes inquilinos de Microsoft Entra.

Nota Requisitos y restricciones de emparejamiento

Hay algunos requisitos y restricciones que se deben tener en cuenta al emparejar las redes
virtuales, que se encuentran aquí: https://learn.microsoft.com/en-us/azure/virtual-
network/virtual-network-manage-peering?tabs =portal-de-interconexión#requisitos-y-
restricciones . El emparejamiento de VNet proporciona un rendimiento de red entre
recursos similar al rendimiento que tendrían si estuvieran ubicados en una única VNet
grande dentro de la misma región. No se impone ningún límite de ancho de banda a las
redes virtuales emparejadas. Los únicos límites son los de las propias máquinas virtuales,
según la serie y el tamaño de las máquinas virtuales.

Límites de emparejamiento de notas

Tenga en cuenta el límite de 500 conexiones de intercambio de tráfico por red virtual. Este
es un límite estricto.

El emparejamiento de dos redes virtuales proporciona conectividad entre las dos redes
virtuales sin necesidad de una VPN ni una puerta de enlace de red virtual. Esto evita el
costo, las limitaciones de rendimiento, la latencia adicional y la complejidad adicional
asociada con el uso de puertas de enlace de VNet, aunque puede usar puertas de enlace de
VNet para conectarse a redes locales mediante el tránsito de puerta de enlace.

Tenga en cuenta las limitaciones de emparejamiento global con el nivel básico en Load
Balancer

El emparejamiento global no se puede utilizar para acceder a la IP de front-end de un

equilibrador de carga interno básico de Azure en la red virtual remota. En estos casos, se
debe utilizar una VPN de VNet a VNet. Esta limitación no se aplica al nivel estándar de
Azure Load Balancer.
No hay restricciones en la conectividad entre las VNet emparejadas, por lo que los recursos
de las VNet emparejadas pueden comunicarse entre sí como si estuvieran en la misma
VNet. Además, la VirtualNetworketiqueta de servicio (descrita en la Habilidad 4.2 ) abarca
el espacio de direcciones de ambas redes interconectadas.

Alternativamente, puede limitar la conectividad usando la opción Permitir acceso a la red

virtual; no hay conectividad saliente automática entre redes virtuales emparejadas y
elVirtualNetwork La etiqueta de servicio no incluye el espacio de direcciones de la red
virtual emparejada. En este caso, usted controla la conectividad entre redes virtuales
emparejadas mediante grupos de seguridad de red.

En la Figura 4-5 se muestra un ejemplo sencillo de emparejamiento de VNet . Esto muestra

dos redes virtuales que se han conectado mediante el emparejamiento de redes virtuales.
Esto permite (por ejemplo), que la máquina virtual WEB1 en VNetA se conecte a la base
de datos MYSQL1 en VNetB.

FIGURA 4-5 Interconexión de VNet entre dos redes virtuales

Una vez establecido el emparejamiento, el tráfico entre máquinas virtuales se enruta a

través de la infraestructura troncal de Microsoft. El tráfico no pasa a través de la Internet
pública, incluso cuando se utiliza el emparejamiento de VNet global para conectar redes
virtuales en diferentes regiones de Azure.

Si bien el emparejamiento de VNet global permite una conectividad abierta entre máquinas
virtuales a través de VNets en diferentes regiones de Azure, una VM solo puede conectarse
a la dirección IP de front-end de un Azure Load Balancer interno básico en la misma
región.
Es importante comprender que el emparejamiento de VNet es una relación uno a uno entre
dos redes virtuales. Para crear conectividad entre tres redes virtuales (VNetA, VNetB y
VNetC), los tres pares deben estar emparejados (VNetA a VNetB; VNetB a VNetC; y
VNetA a VNetC). Esto se ilustra en la Figura 4-6 .

FIGURA 4-6 Los emparejamientos de VNet no tienen una relación transitiva

Encadenamiento de servicios y redes radiales

Una forma común de reducir la duplicación de recursos es utilizar una topología de red
radial. En este enfoque, los recursos compartidos (como controladores de dominio,
servidores DNS, sistemas de monitoreo, etc.) se implementan en una red virtual central
dedicada. Se accede a estos servicios desde múltiples aplicaciones, cada una implementada
en sus propias redes virtuales radiales independientes.

Como se analizó anteriormente en esta habilidad, el emparejamiento de VNet no es

transitivo. Esto significa que no hay conectividad automática entre radios en una topología
de centro y radios. Cuando se requiere dicha conectividad, un enfoque es implementar
emparejamientos de VNet adicionales entre radios. Sin embargo, con una gran cantidad de
radios, esto puede volverse difícil de manejar rápidamente.

Un enfoque alternativo es implementar un dispositivo virtual de red (NVA) en el

concentrador a través de rutas definidas por el usuario (UDR) para enrutar el tráfico entre
radios a través de la NVA. Esto se conoce como encadenamiento de servicios y permite la
comunicación de voz a voz sin necesidad de emparejamientos de VNet adicionales, como
se ilustra en la Figura 4-7 .

FIGURA 4-7 El encadenamiento de servicios permite el uso de servicios comunes entre

pares de redes virtuales

Para transitar el tráfico de una VNet radial a otra VNet radial a través de una NVA en la
VNet central, los emparejamientos de VNet deben configurarse correctamente. De forma
predeterminada, una conexión de intercambio de tráfico solo aceptará tráfico que se origine
en la red virtual a la que está conectada. Este no será el caso paratráfico reenviado entre
redes virtuales radiales a través de una NVA en una red virtual central. Para permitir dicho
tráfico, la configuración Permitir tráfico reenviado debe estar habilitada para esos
emparejamientos de VNet.

Puertas de enlace de red virtual compartidas

Suponga que desea que dos VNet emparejadas, denominadas VNet-A y VNet-B, envíen
tráfico a una red externa a través de una puerta de enlace de red virtual. En lugar de
implementar dos puertas de enlace de red virtual, es mucho más sencillo y rentable para
ambas redes virtuales compartir una única puerta de enlace. Esto se puede lograr con
peering local o global.
Supongamos que la puerta de enlace de la red virtual se implementa en VNet-A, lo que
permite que VNet-A se comunique con la red externa. De forma predeterminada, solo el
tráfico que se origina en VNet-A puede usar esta puerta de enlace y la red externa solo
puede conectarse a máquinas virtuales en VNet-A. Para permitir la conectividad entre
VNet-B y la red externa, se deben configurar las siguientes opciones:

 Habilite VNet-B para usar la puerta de enlace remota de VNet-A. Esta

configuración debe estar habilitada en la conexión de intercambio de tráfico de
VNET-B a VNET-A. Esto informa a VNET-B de la disponibilidad de la puerta de
enlace en VNET-A. Tenga en cuenta que para habilitar esta configuración, VNET-B
no puede tener su propia puerta de enlace de red virtual.
 Permitir que la puerta de enlace en VNet-A reenvíe tráfico a VNet-B Esta
opción debe estar habilitada en la conexión de intercambio de tráfico de VNET-A a
VNET-B. Esto permite que el tráfico de VNET-B utilice la puerta de enlace de
VNET-A para enviar tráfico a la red externa. El tránsito de puerta de enlace se
puede utilizar para S2S, P2S y VNet a VNet.

Tenga en cuenta que en este caso, no se requiere la opción de emparejamiento Permitir que
VNet-B reciba tráfico reenviado desde VNet-A.

Crear un emparejamiento de VNet mediante Azure Portal

Para crear una conexión de intercambio de tráfico entre dos redes virtuales, las redes
virtuales ya deben haberse creado y no deben tener espacios de direcciones superpuestos.

Para crear un nuevo emparejamiento de VNet desde VNet-hub a VNet-spoke, conéctese a

Azure Portal y busque VNet-hub. En Configuración, haga clic en Emparejamientos y luego
haga clic en Agregar para abrir la hoja Agregar emparejamiento. Utilice los siguientes
pasos para configurar una conexión de intercambio de tráfico estándar, como se muestra
en la Figura 4-8 :
FIGURA 4-8 Agregar emparejamiento desde VNet-hub a VNet-spoke mediante Azure
Portal
1. En Esta red virtual, elija un nombre para el emparejamiento de VNet-hub a VNet-
spoke. Este ejemplo utiliza "centro a radio".
2. En esta red virtual, seleccione Permitir puerta de enlace en 'Vnet-hub' para reenviar
tráfico a la red virtual emparejada.
3. En Red virtual remota, puede elegir Administrador de recursos o Clásico. En este
ejemplo, elija Administrador de recursos.
4. Seleccione la suscripción para VNet-spoke en el menú desplegable Suscripción.
5. En el menú desplegable Red virtual, elija VNet-spoke.
6. En Red virtual remota, escriba radio a concentrador para Peering Link.
7. En Red virtual, seleccione Habilitar 'Vnet-spoke' para usar la puerta de enlace
remota 'Vnet-hub'.

Nota ID de recurso conocido

Como alternativa, en lugar de ingresar un nombre, puede especificar la VNet del

mismo nivel seleccionando la casilla de verificación Conozco mi ID de recurso e
ingresando el ID del recurso de la VNet del mismo nivel.

8. Haga clic en Agregar para crear el emparejamiento entre VNet-hub y VNet-spoke.

Una vez que el emparejamiento haya completado el aprovisionamiento, aparecerá
en Azure Portal con el estado de emparejamiento Conectado a la red del mismo
nivel VNet-spoke, como se muestra en la Figura 4-9 .

FIGURA 4-9 Emparejamiento de centro a radio que se muestra como Conectado en

Azure Portal
 9. Si regresa a la hoja de intercambio de tráfico de VNet-spoke, verá que el estado de
intercambio de tráfico de VNet2 a VNet1 es Conectado.

Ahora, VNet-hub y VNet-spoke están interconectados y las máquinas virtuales en estas

redes pueden comunicarse entre sí como si se tratara de una única red virtual.

Configurar direcciones IP públicas

Asociar una dirección IP pública con una interfaz de red crea un punto final con acceso a
Internet, lo que permite que su máquina virtual reciba tráfico de red directamente desde
Internet.

Una dirección IP pública es un recurso de Azure independiente. Esto contrasta con una
dirección IP privada que existe sólo como una colección de configuraciones en otro
recurso, como una interfaz de red o un equilibrador de carga.

Para asociar una dirección IP pública con una máquina virtual, la configuración IP de la
interfaz de red debe actualizarse para contener una referencia al recurso de dirección IP
pública. Como recurso independiente, las direcciones IP públicas se pueden crear y
eliminar de forma independiente, así como moverlas de una máquina virtual a otra.

Niveles de precios Básico vs Estándar

Las direcciones IP públicas están disponibles en dos niveles de precios (o SKU): Básico o
Estándar. Todas las direcciones IP públicas creadas antes de la introducción de estos
niveles se asignan al nivel Básico.

Nota Direcciones IP básicas

Las direcciones IP públicas de SKU básico no se pueden crear después del 31 de marzo de
2025 y se retirarán en septiembre de 2025. Es posible que el examen AZ-104 tenga
preguntas relacionadas con las direcciones IP públicas de SKU básico hasta entonces. Para
obtener más información, visite https://azure.microsoft.com/en-us/updates/upgrade-to-
standard-sku-public-ip-addresses-in-azure-by-30-september-2025-basic-sku -será-
jubilado/ .

Las direcciones IP públicas de nivel estándar admiten la implementación con redundancia

de zona, lo que le permite utilizar zonas de disponibilidad para proteger sus
implementaciones contra posibles interrupciones causadas por fallas a nivel del centro de
datos (como incendios, cortes de energía o fallas de enfriamiento). Hay otras diferencias
importantes entre los dos niveles, como se resume en la Tabla 4-3 .

TABLA 4-3 Comparación de los niveles Básico y Estándar de direcciones IP públicas

 Característica Nivel Básico Nivel estándar

Método de Admite métodos de asignación Solo admite asignación estática.

asignación tanto estáticos como dinámicos.

Restricciones Abierto de forma Cerrado de forma predeterminada

de tráfico predeterminada para el tráfico para el tráfico entrante. Utilice NSG
entrante. Utilice NSG para para permitir el tráfico entrante y
restringir el tráfico entrante o restringir el tráfico saliente.
saliente.

Redundancia No tiene redundancia de zona y Tiene redundancia de zona de

no admite zonas de forma predeterminada o, en su
disponibilidad. lugar, se puede asignar a una zona
de disponibilidad específica.

Prefijos de IP No admite prefijos de IP Admite prefijos de IP públicos, lo

públicos públicos (se analiza más que permite asignar direcciones IP
adelante). desde un bloque de direcciones IP
contiguas.

Asignación de dirección IP pública

Al igual que con las direcciones IP privadas, las direcciones IP públicas admiten la
asignación de IP tanto dinámica como estática. El nivel Básico admite la asignación tanto
estática como dinámica, siendo la dinámica la predeterminada. El nivel Estándar solo
admite la asignación estática.

Bajo la asignación dinámica, una dirección IP real se asigna al recurso de dirección IP

pública solo cuando el recurso está en uso, es decir, cuando está asociado con un recurso
como una máquina virtual en ejecución. Si la máquina virtual se detiene (desasigna) o
elimina, la dirección IP asignada al recurso de dirección IP pública se libera y se devuelve
al grupo de direcciones IP disponibles administradas por Azure. Cuando reinicie la
máquina virtual, lo más probable es que se asigne una dirección IP diferente.

Si desea conservar la dirección IP, el recurso de dirección IP pública debe configurarse para
utilizar la asignación de IP estática. Se asignará una dirección IP inmediatamente (si aún no
se asignó una dinámicamente). Esta dirección IP nunca cambiará, independientemente de si
la máquina virtual asociada se detiene o elimina.

Normalmente, las direcciones IP públicas estáticas se utilizan en escenarios donde una

dependencia está definida por una dirección IP particular. Por ejemplo, las direcciones IP
estáticas se utilizan habitualmente en los siguientes escenarios:
  Donde las reglas del firewall especifican una dirección IP
 Dónde sería necesario actualizar un registro DNS cuando cambia una dirección IP
 Cuando la dirección IP de origen se utiliza como forma (débil) de autenticación de
la fuente de tráfico
 Cuando un certificado SSL especifica una dirección IP explícita en lugar de un
nombre de dominio

Con direcciones IP privadas, la asignación estática le permite especificar la dirección IP

que se utilizará del rango de direcciones de subred disponibles. Por el contrario, la
asignación estática de direcciones IP públicas no le permite especificar qué dirección IP
pública utilizar. Azure asigna la dirección IP de un grupo de direcciones IP en la región de
Azure donde se encuentra el recurso.

Prefijos de direcciones IP públicas

Cuando se utilizan varias direcciones IP públicas, puede resultar conveniente tener todas las
direcciones IP asignadas desde un único rango o prefijo de IP. Por ejemplo, al configurar
reglas de firewall, esto le permite configurar una única regla para el prefijo, en lugar de
reglas separadas para cada dirección IP.

Para admitir este escenario, Azure le permite reservar un prefijo de dirección IP pública.
Los recursos de direcciones IP públicas asociados con ese prefijo tendrán sus direcciones IP
asignadas desde ese rango, en lugar de desde el grupo de Azure de uso general.

Al crear un prefijo, especifique el nombre del recurso del prefijo, el tamaño de la subred
(por ejemplo, /28 para 16 direcciones IP) y la región de Azure donde se asignarán las
direcciones IP.

Una vez creado el prefijo, se pueden crear direcciones IP públicas individuales asociadas
con este prefijo. Tenga en cuenta que solo las direcciones IP públicas de nivel estándar
admiten la asignación desde un prefijo y, por lo tanto, solo se admite la asignación estática.
La dirección IP asignada a estos recursos se tomará del rango de prefijos; no puede
especificar una dirección IP específica del rango.

Beneficios y limitaciones de los prefijos de notas

Consulte los siguientes enlaces a los beneficios y limitaciones de los prefijos de direcciones
IP públicas:

 Beneficios: https://learn.microsoft.com/en-us/azure/virtual-network/ip-
services/public-ip-address-prefix#benefits
 Restricciones: https://learn.microsoft.com/en-us/azure/virtual-network/ip-
services/public-ip-address-prefix#constraints
Etiquetas DNS

El sistema de nombres de dominio (DNS) se puede utilizar para crear una asignación de un
nombre de dominio a una dirección IP, de modo que pueda hacer referencia a los puntos
finales de direcciones IP utilizando un nombre de dominio en lugar de utilizar la dirección
IP asignada directamente.

Hay cuatro formas de configurar una etiqueta DNS para una dirección IP pública de Azure:

1. Especificando la propiedad de etiqueta de nombre DNS del recurso de dirección IP

pública
2. Creando un DNS Aregistro en Azure DNS o un servicio DNS de terceros que aloja un
dominio DNS
3. Creando un DNS CNAMEregistro en Azure DNS o un servicio DNS de terceros que
aloja un dominio DNS
4. Creando un registro de alias en Azure DNS

Especificar la propiedad de la etiqueta del nombre DNS

Con esta opción, especifica la parte más a la izquierda de la etiqueta DNS como una
propiedad en el recurso de dirección IP pública. Azure proporciona el sufijo DNS, que
tendrá el formato <región>.cloudapp.azure.com . La etiqueta DNS que proporciona se
concatena con este sufijo para formar el nombre de dominio completo (FQDN), que se
puede utilizar para buscar la dirección IP mediante una consulta DNS.

Por ejemplo, si su dirección IP pública está implementada en la región central de EE. UU. y
especifica la etiqueta DNS contoso-app, el FQDN será contoso-
app.centralus.cloudapp.azure.com .

La principal limitación de este enfoque es que el sufijo DNS se toma de un dominio DNS
proporcionado por Azure. No admite el uso de su propio dominio personalizado,
como contoso.com . Para solucionar esto, deberá utilizar uno de los otros enfoques.

Crear un registro DNS A

En este enfoque, ya habrá alojado su dominio personalizado en Azure DNS o en un servicio

DNS de terceros. Al utilizar su servicio de alojamiento, puede crear una entrada DNS en la
asignación de su dominio personalizado a su recurso de dirección IP pública. Si utiliza un
registro DNS A, que se asigna directamente a una dirección IP, deberá actualizar el registro
DNS si cambia la dirección IP asignada. Para evitar esto, utilice una asignación de IP
estática en lugar de dinámica.

Crear un registro CNAME DNS

En este enfoque, comienza creando una etiqueta DNS para su dirección IP pública. Luego,
crea un registro CNAME en su dominio personalizado, que asigna el nombre de dominio
elegido al nombre DNS proporcionado por Azure. Por ejemplo, puede
asignar www.contoso.com a contoso-app.centralus.cloudapp.azure.com . Este enfoque tiene
la ventaja de evitar la necesidad de una asignación de IP estática porque la entrada DNS
proporcionada por Azure se actualiza automáticamente si cambia la dirección IP asignada.
Sin embargo, la desventaja de este enfoque es que el sistema de nombres de dominio no
admite registros CNAME en la raíz de un dominio DNS, lo que significa que si bien puede
crear un registro CNAME para www.contoso.com , no puede crear uno
para contoso.com. (sin el “www”).

Crear un registro de alias

En este enfoque, su dominio personalizado debe estar hospedado en Azure DNS. Luego
puede crear un registro de alias, que funciona igual que un registro A, excepto que en lugar
de especificar explícitamente el valor de la dirección IP asignada en el registro DNS,
simplemente hace referencia al recurso de dirección IP pública. La dirección IP asignada se
toma de este recurso y se configura automáticamente en su registro de alias DNS. Con los
registros de alias, el registro DNS se actualiza automáticamente si la dirección IP asignada
cambia, evitando la necesidad de una asignación de IP estática.

Conexiones salientes a Internet

Cuando se asigna una dirección IP pública a la interfaz de red de una máquina virtual, el
tráfico saliente a Internet se enrutará a través de esa dirección IP. El destinatario verá su
dirección IP pública como la dirección IP de origen para la conexión.

Sin embargo, la máquina virtual en sí no ve la dirección IP pública en su configuración de

red; solo ve la dirección IP privada. El tráfico sale de la máquina virtual a través de la
dirección IP privada y la traducción de la dirección de red de origen (SNAT) se utiliza para
asignar el tráfico saliente desde la dirección IP privada a la dirección IP pública.

Tenga en cuenta que, históricamente, no se requiere una dirección IP pública para el tráfico
de Internet saliente. Incluso sin una dirección IP pública asignada, las máquinas virtuales
aún pueden realizar conexiones salientes a Internet. En este caso, SNAT se utiliza para
asignar la dirección IP privada a una dirección IP con acceso a Internet. Sin embargo, a
partir de septiembre de 2025, el acceso saliente predeterminado estará deshabilitado para
las nuevas redes virtuales y requerirá una puerta de enlace NAT u otro dispositivo saliente.

¿Necesita más revisión? Acceso saliente predeterminado

Para obtener más información sobre el acceso saliente predeterminado,

visite https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/default-
outbound-access .
Cree una dirección IP pública mediante Azure Portal

Crear una nueva dirección IP pública es un proceso sencillo mediante Azure Portal.
Busque direcciones IP públicas y luego haga clic en Crear. Como todos los recursos en
Azure, se requerirán algunos detalles, incluido el nombre del recurso, el SKU (o nivel de
precios), la versión de IP, el tiempo de espera de inactividad, la suscripción, el grupo de
recursos y la ubicación/región. Para el SKU Básico, también especifica la versión de IP y la
asignación estática o dinámica. Para la SKU estándar, elija entre implementación con
redundancia de zona o una zona de disponibilidad específica.

La ubicación es fundamental porque una dirección IP debe estar en la misma

ubicación/región que la máquina virtual u otro recurso que la utilizará. La Figura 4-
10 muestra la hoja Crear dirección IP pública.
FIGURA 4-10 Creación de una dirección IP pública en Azure Portal
Configurar rutas de red definidas por el usuario

Las rutas de red controlan cómo se enruta el tráfico en su red. Azure proporciona
enrutamiento predeterminado para escenarios comunes, con la capacidad de configurar sus
propias rutas de red cuando sea necesario.

Rutas del sistema

Las máquinas virtuales de Azure en la misma red virtual pueden comunicarse

automáticamente entre sí y con Internet sin ningún cambio explícito en la configuración,
incluso cuando se encuentran en subredes diferentes. Este también es el caso de la
comunicación desde las máquinas virtuales a su red local cuando se ha establecido una
conexión híbrida de Azure a su centro de datos.

Esta facilidad de configuración es posible gracias a lo que se conoce como rutas del
sistema, que definen cómo fluye el tráfico IP en las redes virtuales de Azure. Las siguientes
son las rutas predeterminadas del sistema que Azure usará y le proporcionará:

 Dentro de la misma subred

 De una subred a otra dentro de una VNet
 VM a Internet
 Una VNet a otra VNet a través de una puerta de enlace VPN (opcional)
 Una VNet a otra VNet a través del emparejamiento de VNet (opcional)
 Una VNet a su red local a través de una puerta de enlace VPN o ExpressRoute
(opcional)
 Punto final de VirtualNetworkService (opcional)

La Figura 4-11 muestra un ejemplo de cómo estas rutas del sistema facilitan su puesta en
funcionamiento. Las rutas del sistema proporcionan los escenarios más típicos de forma
predeterminada, sin que usted tenga que realizar ninguna configuración de enrutamiento.
FIGURA 4-11 Aplicación de N niveles implementada en Azure VNet mediante rutas del
sistema

Rutas definidas por el usuario

En algunos casos, querrá configurar el enrutamiento de paquetes de manera diferente a lo

que proporcionan las rutas predeterminadas del sistema. Uno de estos escenarios es cuando
desea enviar tráfico a través de un dispositivo virtual de red, como un equilibrador de carga,
un firewall o un enrutador de terceros implementado en su red virtual desde Azure
Marketplace.

Para que esto sea posible, cree lo que se conoce como rutas definidas por el usuario (UDR).
La UDR se implementa mediante la creación de un recurso de tabla de rutas. Dentro de la
tabla de rutas, se configuran varias rutas. Cada ruta especifica el rango de IP de destino (en
notación CIDR) y la dirección IP del siguiente salto. Se admiten una variedad de tipos
diferentes de siguiente salto:

 Dispositivo virtual Una máquina virtual que ejecuta una aplicación de red, como
un equilibrador de carga o un firewall. Con este tipo de siguiente salto, también
especifica la dirección IP del dispositivo, que puede ser una máquina virtual o un
equilibrador de carga interno para dispositivos virtuales de alta disponibilidad.
 Puerta de enlace de red virtual Se utiliza para enrutar el tráfico a una puerta de
enlace VPN (pero no a una puerta de enlace ExpressRoute, que usa BGP para rutas
 personalizadas). Debido a que solo puede haber una puerta de enlace VPN asociada
con una red virtual, no se le solicita que especifique el recurso de puerta de enlace
real.
 Red virtual Se utiliza para enrutar el tráfico dentro de la VNet.
 Internet Se utiliza para enrutar una dirección IP específica o un prefijo a Internet.
 Ninguno Se utiliza para descartar todo el tráfico enviado a una dirección IP o
prefijo determinado.

Luego, esta tabla de rutas se asocia con una o más subredes. El tráfico que se origina en la
subred cuyo destino coincide con el rango de IP de destino de una regla de tabla de
enrutamiento se enrutará a la dirección IP del siguiente salto correspondiente. El servicio
que se ejecuta en esta dirección IP es responsable de todo el enrutamiento posterior.

Tablas de rutas de notas

Puede tener varias tablas de rutas y la misma tabla de rutas puede estar asociada a una o
más subredes. Cada subred sólo puede asociarse a una única tabla de rutas. Todas las
máquinas virtuales de una subred utilizan la tabla de rutas asociada a esa subred.

La Figura 4-12 muestra una UDR que se creó para dirigir el tráfico saliente a través de un
dispositivo virtual. En este caso, el dispositivo es un firewall que se ejecuta como una
máquina virtual en Azure en la subred DMZ.
FIGURA 4-12 Aplicación de N niveles implementada con un firewall usando rutas
definidas por el usuario

El mismo dispositivo también se puede utilizar para filtrar el tráfico entre las subredes de
aplicaciones y datos. En la Figura 4-13 se muestra un ejemplo de tabla de rutas que
implementa este diseño .
FIGURA 4-13 Reglas de la tabla de rutas que fuerzan el tráfico de red a través de un
firewall

Nota Subredes dedicadas para dispositivos de red

No aplique una tabla de rutas a una subred si la tabla de rutas contiene una regla con una
dirección de siguiente salto dentro de esa subred. Hacerlo podría crear un bucle de
enrutamiento. Por este motivo, los dispositivos de red virtuales deben implementarse en
subredes dedicadas, separadas de los recursos que se enrutan a través de ese dispositivo.

reenvío de IP

Las rutas definidas por el usuario (UDR) cambian las rutas predeterminadas del sistema que
Azure crea para usted en una red virtual de Azure. En el escenario del dispositivo virtual,
las UDR reenvían el tráfico a un dispositivo virtual, como un firewall, que se ejecuta como
una máquina virtual de Azure.

De forma predeterminada, una máquina virtual en Azure no aceptará un paquete de red

dirigido a una dirección IP diferente. Para que se permita que ese tráfico pase a ese
dispositivo virtual, debe habilitar el reenvío de IP en la interfaz de red de la máquina
virtual. Esta configuración normalmente no implica ningún cambio en Azure UDR o VNet,
pero según el escenario, es posible que deba realizar algunos cambios de configuración en
el sistema operativo de la máquina virtual para permitir que esto funcione correctamente.

El reenvío de IP se puede habilitar en una interfaz de red mediante Azure Portal,

PowerShell o la CLI de Azure. En la Figura 4-14 , se selecciona Habilitar reenvío de IP
para la interfaz de red de la máquina virtual NGFW1. Esta máquina virtual ahora puede
aceptar y enviar paquetes que originalmente no estaban destinados a esta máquina virtual.
FIGURA 4-14 Reenvío de IP habilitado en la interfaz de red

Cómo se aplican las rutas

Un paquete de red determinado puede coincidir con varias reglas de la tabla de rutas. Al
diseñar e implementar rutas personalizadas, es importante comprender las reglas de
prioridad que aplica Azure.

Si varias rutas contienen el mismo prefijo de dirección, Azure selecciona el tipo de ruta en
función de las siguientes prioridades:

1. Rutas definidas por el usuario

2. Rutas del sistema para el tráfico en una red virtual, a través de un emparejamiento
de red virtual o hacia un punto final de servicio de red virtual
3. Rutas BGP
4. Otras rutas del sistema

Dentro de una única tabla de rutas, un paquete de red determinado puede coincidir con
múltiples reglas de enrutamiento. No existe un orden de precedencia explícito en las reglas
de una tabla de rutas. En cambio, se le da prioridad a la regla con la coincidencia más
específica con la dirección IP de destino. Si una dirección IP coincide con dos reglas, se
utiliza el algoritmo de coincidencia de prefijo más largo para seleccionar la ruta.

Por ejemplo, si una tabla de rutas contiene una regla para el prefijo 10.10.0.0/16 y otra regla
para 10.10.30.0/28, cualquier tráfico a la dirección IP 10.10.30.4 se comparará con la
segunda regla con preferencia a la primera.

Al solucionar problemas de red, puede resultar útil tener una visión más profunda de
exactamente qué rutas se están aplicando a una interfaz de red determinada. Al utilizar la
función Rutas efectivas de cada interfaz de red, puede ver los detalles completos de cada
ruta de red aplicada a esa interfaz de red, lo que le brinda una visión completa de cómo se
enrutará cada conexión saliente según la dirección IP de destino.
Túnel forzado

Un caso especial es cuando las rutas se configuran con el prefijo IP de destino 0.0.0.0/0.
Dadas las reglas de precedencia descritas anteriormente, esta ruta controla el tráfico
destinado a cualquier dirección IP que no esté cubierta por ninguna otra regla.

De forma predeterminada, Azure implementa una ruta del sistema que dirige todo el tráfico
que coincide con 0.0.0.0/0 (y que no coincide con ninguna otra ruta) a Internet. Si anula
esta ruta, este tráfico se dirige al siguiente salto que especifique. Al utilizar una puerta de
enlace VPN como siguiente salto, puede dirigir todo el tráfico vinculado a Internet a través
de su conexión VPN a un dispositivo de seguridad de red local. Esto se conoce como túnel
forzado .

Configurar rutas definidas por el usuario mediante Azure Portal

Para configurar rutas definidas por el usuario, primero cree un recurso de tabla de rutas.
Desde Azure Portal, busque tablas de rutas. En la hoja Tablas de rutas, haga clic en Crear
para abrir la hoja Crear tabla de rutas, como se muestra en la Figura 4-15 . Seleccione
opciones en los menús desplegables Suscripción y Grupo de recursos, ingrese un nombre
para la tabla de rutas y especifique la región de la tabla de rutas, que debe ser la misma
región de Azure que usan las subredes con esta tabla de rutas.
FIGURA 4-15 La hoja Crear tabla de rutas en Azure Portal

Una vez creada la tabla de rutas, el siguiente paso es definir las rutas. Abra la hoja Tabla de
rutas y, en Configuración, haga clic en Rutas para abrir la lista de rutas en la tabla de rutas.
Luego haga clic en Agregar para abrir la hoja Agregar ruta, como se muestra en la Figura 4-
16 .
FIGURA 4-16 La hoja Agregar ruta en Azure Portal

Repita este proceso para cada ruta personalizada en la tabla de rutas.

El último paso es especificar a qué subredes se debe asociar esta tabla de rutas. Esto se
puede configurar desde la subred o desde la tabla de rutas. En el último caso, desde la hoja
Tabla de rutas, en Configuración, haga clic en Subredes para abrir la lista de subredes
asociadas con la tabla de rutas. Haga clic en Asociar para abrir la hoja Asociar subred,
como se muestra en la Figura 4-17 .
FIGURA 4-17 La hoja Asociar subred para una tabla de rutas en Azure Portal

Para ver las rutas efectivas para una interfaz de red determinada, navegue hasta la hoja de
interfaz de red en Azure Portal y luego haga clic en Rutas efectivas para abrir la hoja Rutas
efectivas, como se muestra en la Figura 4-18 .

FIGURA 4-18 La lista de rutas efectivas para la interfaz de red examref913

Solucionar problemas de conectividad de red

Azure proporciona varias herramientas integradas para solucionar problemas de

conectividad de red, y la mayoría de ellas están disponibles a través de Network Watcher.
Esta sección se centra en dos de las herramientas de Network Watcher que pueden ayudarle
a solucionar problemas de conectividad de red.

Solucionar problemas de conexión

La solución de problemas de conexión es una característica de Network Watcher diseñada

para probar la conectividad entre una máquina virtual de Azure o una App Gateway y otro
punto final, ya sea otra máquina virtual de Azure o un punto final arbitrario de Internet o
intranet. Esta herramienta de diagnóstico puede identificar una variedad de problemas,
incluidos problemas de VM invitada, como configuración del firewall invitado, poca
memoria o CPU alta; Problemas de configuración de Azure, como grupos de seguridad de
red que bloquean el tráfico; o problemas de ruta que desvían el tráfico. También puede
diagnosticar otros problemas de red, como fallas de DNS.

Para usar la solución de problemas de conexión desde Azure Portal, abra Network Watcher
y luego haga clic en Solucionar problemas de conexión. Especifique la máquina virtual de
origen y luego el destino, ya sea como otra máquina virtual o proporcionando un URI,
FQDN o dirección IPv4. Especifique el protocolo a utilizar (ya sea TCP o ICMP). Para
TCP, puede especificar el puerto de destino y, en Configuración avanzada, el puerto de
origen. En la Figura 4-19 se muestra un ejemplo de configuración .
FIGURA 4-19 Configuración de solución de problemas de conexión de Network Watcher

La prueba tarda unos minutos en ejecutarse. Al finalizar, los resultados se mostrarán en la

parte inferior de la página. En la Figura 4-20 se muestra un resultado de ejemplo .
FIGURA 4-20 Resultados de la solución de problemas de conexión de Network Watcher

La solución de problemas de conexión también está disponible a través de PowerShell

mediante el Test-AzNetworkWatcherConnectivitycmdlet y mediante la CLI de Azure
mediante el az network watcher test-connectivitycomando Azure Network Watcher.

Monitor de conexión

Connection Monitor en Network Watcher es similar a Connection Troubleshoot en el

sentido de que utiliza el mismo mecanismo para probar la conexión entre una máquina
virtual de Azure o App Gateway y otro punto final. La diferencia es que Connection
Monitor proporciona un monitoreo continuo de la conexión, mientras que Connection
Troubleshoot proporciona solo una prueba en un momento dado.

Los datos de Connection Monitor aparecen en Azure Monitor. Los gráficos muestran
métricas clave, como el tiempo de ida y vuelta y los fallos de la sonda. Azure Monitor
también se puede usar para configurar alertas, activadas por fallas de conexión o una caída
en el rendimiento.

Para usar Connection Monitor a través de Azure Portal, abra Network Watcher y haga clic
en Connection Monitor. Se muestra una lista de conexiones monitoreadas activas. Haga clic
en Crear para crear una nueva conexión monitoreada y luego complete la configuración de
la conexión. La configuración es casi la misma que para Solucionar problemas de conexión.
Además, deberá especificar el intervalo de sondeo en segundos. En la Figura 4-21 se
muestra un ejemplo .
FIGURA 4-21 Configuración del monitor de conexión de Network Watcher

La conexión monitoreada aparecerá en la hoja Connection Monitor dentro de Network

Watcher. Haga clic en una conexión monitoreada para abrir el panel de resultados, como se
muestra en la Figura 4-22 . El gráfico muestra el tiempo promedio de ida y vuelta y el
porcentaje de fallas de la sonda. Haga clic en el gráfico para ver los datos en Azure
Monitor. Desde allí, puede configurar alertas basadas en estas métricas que superen los
umbrales que usted defina. La tabla debajo del gráfico muestra el estado actual de la
conexión; Al hacer clic en cada línea se proporcionan más detalles sobre el estado, que es
similar a cómo se muestran los resultados de la solución de problemas de conexión.
FIGURA 4-22 Estado del monitor de conexión de Network Watcher

Habilidad 4.2: Configurar el acceso seguro a redes virtuales

Los grupos de seguridad de red (NSG) controlan qué flujos de red están permitidos dentro y
fuera de sus redes virtuales y máquinas virtuales. Cada NSG contiene listas de reglas de
entrada y salida, que le brindan un control detallado sobre exactamente qué flujos de red
están permitidos o denegados. Combine esto con el uso de puntos de conexión privados y
de servicio, que brindan conectividad a los servicios PaaS de Azure directamente desde su
red virtual, y tendrá las herramientas que necesita para configurar una conectividad privada
y segura desde sus máquinas virtuales a los servicios de Azure.

Esta habilidad cubre cómo:

  Crear y configurar grupos de seguridad de red y grupos de seguridad de
aplicaciones.
 Evaluar reglas de seguridad efectivas
 Implementar y configurar el servicio Azure Bastion
 Configurar puntos de conexión de servicio para servicios de Azure
 Configurar puntos de conexión privados para servicios de Azure

Crear y configurar grupos de seguridad de red y grupos de seguridad de aplicaciones.

Un grupo de seguridad de red (NSG) es un recurso independiente de Azure que actúa como
filtro de red. Cada NSG contiene una lista de reglas de seguridad. Se utilizan para permitir
o denegar el tráfico de red entrante o saliente, según las propiedades de ese tráfico, como el
protocolo, la dirección IP y el puerto. Cuando aplica el NSG, se asocia con una subred o
con una interfaz de red de VM específica.

reglas del GSN

Las reglas del NSG definen qué flujos de tráfico permite o deniega el NSG. La Tabla 4-
4 describe las propiedades de una regla NSG.

TABLA 4-4 Propiedades NSG

Propiedad Descripción Restricciones Consideraciones

Nombre El nombre de Debe ser único dentro de la Puede tener varias

la regla. región. reglas dentro de un
NSG, así que asegúrese
Debe terminar con una letra, de seguir una
número o guión bajo. convención de
nomenclatura que le
No puede exceder los 80 permita identificar el
caracteres. propósito de cada regla.

Protocolo El protocolo de TCP, UDP o *. El uso de * como

red al que se protocolo incluye
aplica la regla. ICMP, así como TCP y
UDP. En Azure Portal,
seleccione ‘Any’en
lugar de ‘*’.

Rango(s) Rango(s) de Número de puerto único del Los puertos de origen

de puertos puertos de 1 al 65535; un rango de pueden ser efímeros,
de origen origen que puertos (ejemplo: 1–65535); por lo que, a menos que
Propiedad Descripción Restricciones Consideraciones

deben coincidir una lista de puertos o rangos su programa cliente

con la regla. de puertos; o *(para todos esté usando un puerto
los puertos). específico, use * en la
mayoría de los casos.

Intente reducir la
cantidad de reglas
especificando varios
puertos o rangos de
puertos en una sola
regla.

Rango de Rango(s) de Número de puerto único del Intente reducir la

puertos de puertos de 1 al 65535, rango de puertos cantidad de reglas
destino destino que (como 1–65535), una lista de especificando varios
deben coincidir puertos o rangos de puertos, puertos o rangos de
con la regla. o *(para todos los puertos). puertos en una sola
regla.

Prefijo(s) Prefijos de Dirección IP única Considere la

de dirección de (como 10.10.10.10), subred posibilidad de utilizar
dirección origen o IP (como 192.168.1.0/24), rangos, etiquetas de
de origen etiquetas de una etiqueta de servicio, una servicio y listas para
servicio que lista de las anteriores reducir la cantidad de
coincidan con o *(para todas las reglas.
la regla. direcciones).
Las direcciones IP de
las máquinas virtuales
de Azure también se
pueden especificar
implícitamente
mediante grupos de
seguridad de
aplicaciones.

Prefijo(s) Prefijos de Dirección IP única Considere el uso de

de dirección de (como 10.10.10.10); subred rangos, etiquetas
dirección destino o IP (como 192.168.1.0/24); predeterminadas y
de destino etiquetas de una etiqueta de servicio; una listas para reducir la
servicio que lista de los anteriores; cantidad de reglas.
 Propiedad Descripción Restricciones Consideraciones

coincidan con o *(para todas las Las direcciones IP de

la regla. direcciones). las máquinas virtuales
de Azure también se
pueden especificar
implícitamente
mediante grupos de
seguridad de
aplicaciones.

Dirección Dirección del Entrante o saliente. Las reglas de entrada y

tráfico que salida se procesan por
coincida con la separado, según la
regla. dirección del tráfico.

Prioridad Las reglas se Número único entre 100 y Considere la

verifican en 4096. La unicidad se da posibilidad de crear
orden de únicamente dentro de este reglas y aumentar las
prioridad. Una NSG. prioridades en 100 para
vez que se cada regla para dejar
encuentra una espacio para nuevas
regla reglas que pueda crear
coincidente, no en el futuro.
se prueban más
reglas.

Acción Tipo de acción Permitir o negar. Tenga en cuenta que si

a aplicar si la no se encuentra una
regla coincide. regla de permiso para
un paquete, el paquete
se descarta.

Nota Prioridad de la regla NSG

Las reglas del NSG se aplican en función de su prioridad. Los valores de prioridad
comienzan desde 100 y llegan a 4096 (y de 65001 a 65003 para las reglas
predeterminadas). Las reglas se leerán y aplicarán comenzando con 100 y seguidas por 101,
102, etc. Cuando se encuentra una regla que coincide con el tráfico bajo consideración, se
aplica la regla y se detiene todo procesamiento posterior; las reglas posteriores se ignoran.

Por ejemplo, supongamos que tiene una regla entrante que permite el tráfico TCP en
cualquier puerto con una prioridad de 250 y otra que niega el tráfico TCP en el puerto 80
con una prioridad de 125. Se denegaría una conexión TCP entrante en el puerto 80, ya que
la regla de denegación La regla tiene un valor de prioridad más bajo y se aplicaría antes de
que se considere la regla de permiso.

Etiquetas de servicio

Se accede a muchos servicios de Azure a través de puntos finales conectados a Internet.

Estos puntos de conexión pueden cambiar con el tiempo, por ejemplo, a medida que se
crean nuevas regiones de Azure. Esto dificulta el uso de reglas NSG para controlar el
acceso a esos servicios: es difícil identificar la lista de rangos de IP a usar y aún más difícil
mantener la lista actualizada.

Para solucionar este problema, Azure proporciona etiquetas de servicio . Estos son accesos
directos definidos por la plataforma que se asignan a los rangos de IP de varios servicios de
Azure. Los rangos de IP asociados con cada etiqueta de servicio se actualizan
automáticamente cada vez que cambian las direcciones IP utilizadas por el servicio.

Las etiquetas de servicio se utilizan en las reglas de NSG como una forma rápida y
confiable de crear reglas que controlen el tráfico a cada servicio. Normalmente, se usan en
reglas de salida para controlar a qué otros servicios de Azure pueden o no acceder las
máquinas virtuales de una red virtual.

Tenga en cuenta que las etiquetas de servicio controlan el acceso al servicio, pero no a un
recurso específico dentro de ese servicio. Por ejemplo, se podría usar una etiqueta de
servicio en una regla de NSG que permita que una máquina virtual se conecte a Azure
Storage. Esta regla no puede controlar qué cuenta de Azure Storage intentará usar la
máquina virtual.

Se proporcionan etiquetas de servicio para más de 60 servicios de Azure y la lista sigue

creciendo. Estas son algunas de las etiquetas de servicio más utilizadas.

 VirtualNetwork Controla el acceso al espacio de direcciones de la red virtual

donde está asignado el NSG. Se refiere a toda la red virtual (no solo a la subred),
además de todas las redes virtuales conectadas y cualquier espacio de direcciones
local conectado mediante VPN de sitio a sitio o ExpressRoute. Tenga en cuenta que
el espacio de direcciones de red de redes virtuales emparejadas solo se incluye si
la Allow Virtual Network Accesspropiedad está configurada en Enabled.
 Internet Indica el espacio público de direcciones de Internet. Esto incluye los
rangos de direcciones IP de Azure con acceso a Internet que se usan para
direcciones IP públicas y servicios de la plataforma Azure.
 AzureCloud Indica el espacio de IP pública del centro de datos de Azure. Esta
etiqueta de servicio puede tener como ámbito una región de Azure específica, por
ejemplo, especificando AzureCloud.EastUs.
 AzureLoadBalancer Indica las direcciones IP donde se originarán las sondas de
estado de Azure Load Balancer. Se debe permitir el tráfico desde estas direcciones
para cualquier máquina virtual con equilibrio de carga. Tenga en cuenta que esta
 etiqueta de servicio no se puede utilizar para controlar el tráfico que llega a través
del Load Balancer desde ningún otro lugar. Este tráfico se puede filtrar utilizando la
IP de origen de origen, que no se modifica cuando pasa por Azure Load Balancer.
 AzureTrafficManager Realiza una función similar para Azure Traffic Manager. Se
utiliza para permitir el tráfico desde las direcciones IP de origen de las sondas de
estado de Traffic Manager.
 Almacenamiento Representa las direcciones IP utilizadas por el servicio Azure
Storage. Al igual que con la etiqueta de servicio en la nube de Azure, la etiqueta de
servicio de almacenamiento puede tener un ámbito regional. Por ejemplo, puede
especificar Storage.WestUSpermitir el acceso solo a cuentas de almacenamiento en
la región Oeste de EE. UU.
 Sql Representa las direcciones IP utilizadas por Azure Database para MySQL,
Azure Database para PostgreSQL y Azure Synapse Analytics. Esta etiqueta de
servicio también puede tener como ámbito una región específica.

Reglas predeterminadas

Todos los GSN tienen un conjunto de reglas predeterminadas. No puede agregar, editar ni
eliminar estas reglas predeterminadas. Sin embargo, dado que tienen la prioridad más baja
posible, otras reglas que usted cree pueden anularlas.

Las reglas predeterminadas permiten y no permiten el tráfico de la siguiente manera:

 Red virtual El tráfico que se origina y termina en una red virtual está permitido
tanto en dirección entrante como saliente.
 Se permite el tráfico saliente de Internet , pero el tráfico entrante está bloqueado.
 Equilibrador de carga Permite que Azure Load Balancer analice el estado de sus
máquinas virtuales e instancias de rol. Si no utiliza un conjunto con equilibrio de
carga, puede anular esta regla.

Nota Tráfico del equilibrador de carga

La regla predeterminada de Load Balancer utiliza la AzureLoadBalanceretiqueta de

servicio. Esto se aplica solo a los sondeos de estado de Azure Load Balancer, que se
originan en el equilibrador de carga. No se aplica al tráfico recibido a través del
balanceador de carga, que conserva sus direcciones IP y puertos de origen originales.

La Tabla 4-5 muestra las reglas de entrada predeterminadas para cada NSG.

TABLA 4-5 Reglas de entrada predeterminadas

 Puerto de Puerto de
Nombre Prioridad Fuente Destino Protoco
origen destino

PermitirVNetInBound 65000 Red Virtual Cualquier Red Cualquier Cualqui

Virtual

AllowAzureLoad 65001 Equilibrador Cualquier Cualquier Cualquier Cualqui

BalancerInBound de carga de
Azure

Denegar todo incluido 65500 Cualquier Cualquier Cualquier Cualquier Cualqui

La Tabla 4-6 muestra las reglas de salida predeterminadas para cada NSG.

TABLA 4-6 Reglas de salida predeterminadas

Puerto de Puerto de
Nombre Prioridad Fuente Destino Protocolo Acce
origen destino

PermitirVNet 65000 Red Cualquier Red Cualquier Cualquier Perm

virtual virtual
Saliente

Permitir 65001 Cualquier Cualquier Internet Cualquier Cualquier Perm

Internet

Saliente

Denegar todo 65500 Cualquier Cualquier Cualquier Cualquier Cualquier Dene

saliente

Grupos de seguridad de aplicaciones

Como ha visto, las reglas de NSG son como las reglas de firewall tradicionales y se definen
mediante bloques de IP de origen y destino. Le permiten segmentar el tráfico de su red en
niveles de aplicaciones, que se segmentan en subredes separadas.

Esto crea algunos desafíos de gestión:

 Los bloques de IP para cada subred deben planificarse cuidadosamente con

antelación. Para garantizar que se puedan agregar servidores adicionales en el
 futuro, cada subred debe ser más grande de lo que realmente necesita, lo que resulta
en un uso ineficiente del espacio IP.
 Si crea una subred demasiado pequeña y se queda sin espacio, reconfigurar la red
para liberar espacio adicional puede llevar mucho tiempo, especialmente sin tiempo
de inactividad de la aplicación.
 Cada subred requiere un NSG independiente, lo que dificulta obtener una imagen
general del tráfico permitido y bloqueado a nivel de aplicación.

Los grupos de seguridad de aplicaciones (ASG) abordan estos desafíos ofreciendo un

enfoque alternativo a la segmentación de la red. Puede usarlos para segmentar su aplicación
en niveles separados y controlan estrictamente los flujos de red permitidos entre niveles.
Sin embargo, los ASG no requieren que asocie cada nivel con una subred separada, por lo
que todos los desafíos asociados con la planificación y administración de subredes
desaparecen. Con los ASG, usted define explícitamente (en lugar de implícitamente) a qué
nivel de aplicación pertenece cada VM, según la subred en la que se ha ubicado la VM.
Todas las máquinas virtuales se pueden colocar en una única subred y se utiliza un único
NSG para definir todos los flujos de red permitidos entre los niveles de aplicación. Debido
a que se utiliza una única subred, el espacio IP se puede administrar de manera mucho más
flexible y, debido a que hay un único NSG con reglas que hacen referencia a niveles de
aplicación nombrados, las reglas de red son más fáciles de entender y se pueden administrar
todas en un solo lugar.

La Figura 4-23 muestra una arquitectura de aplicación estándar de tres niveles con
servidores web, servidores de aplicaciones y servidores de bases de datos. Estos servidores
se han agrupado asociando cada servidor con el grupo de seguridad de aplicaciones
adecuado. Todos los servidores se colocan en la misma subred sin tener que pensar en
cómo se subdivide el espacio de la red. Un único grupo de seguridad de red contiene reglas
que definen los flujos de tráfico permitidos entre niveles de aplicación.

FIGURA 4-23 Uso de grupos de seguridad de aplicaciones para simplificar la

administración de subredes y NSG
Los grupos de seguridad de aplicaciones le permiten configurar la seguridad de la red como
una extensión natural de la estructura de una aplicación, de modo que pueda agrupar
máquinas virtuales y definir la red.políticas de seguridad basadas en esos grupos. Puede
reutilizar su política de seguridad a escala sin el mantenimiento manual de direcciones IP
explícitas. La plataforma maneja la complejidad de las direcciones IP explícitas y múltiples
conjuntos de reglas, lo que le permite centrarse en su lógica empresarial.

Configurar grupos de seguridad de aplicaciones es sencillo:

1. Primero, cree un recurso de grupo de seguridad de aplicaciones para cada grupo de

servidores. Este recurso no tiene propiedades aparte de su nombre, grupo de
recursos y ubicación.
2. A continuación, asocie la interfaz de red de cada VM con el grupo de seguridad de
aplicaciones adecuado. Esto define a qué grupo (o grupos) pertenece cada VM.
3. Finalmente, defina las reglas de su grupo de seguridad de red utilizando nombres de
grupos de seguridad de aplicaciones en lugar de rangos de IP explícitos. Esto es
similar a cómo se configuran las reglas mediante etiquetas de servicio con nombre.

Crear un NSG mediante Azure Portal

Para crear un NSG mediante Azure Portal, siga estos pasos:

1. Busque grupos de seguridad de red . En la hoja Grupos de seguridad de red, haga

clic en Crear.
2. En la hoja Crear grupo de seguridad de red, proporcione un nombre, la suscripción
donde se encuentran sus recursos, el grupo de recursos para el NSG y la ubicación.
(La ubicación debe ser la misma que la de los recursos a los que desea aplicar el
NSG). En la Figura 4-24 , se creará el NSG para permitir el tráfico HTTP en la
subred de aplicaciones y se denominará AppsNSG.
 FIGURA 4-24 Creación de un grupo de seguridad de red mediante Azure Portal

3. Una vez creado el NSG, abra la hoja Descripción general del NSG, como se muestra
en la Figura 4-25 . Aquí verá que se creó el NSG, pero no hay reglas de seguridad
de entrada o salida más allá de las reglas predeterminadas.
 FIGURA 4-25 La hoja Descripción general de NSG, que muestra las reglas de
seguridad de entrada y salida

4. Cree la regla entrante para el tráfico HTTP y HTTPS: en el área Configuración de la

izquierda, haga clic en Reglas de seguridad entrante y luego haga clic en Agregar
para abrir la hoja Agregar regla de seguridad entrante. Tenga en cuenta que puede
elegir el modo Básico o Avanzado, según el nivel de control requerido.
5. Para permitir el tráfico HTTP/HTTPS en los puertos 80 y 443, complete los campos
como se muestra aquí y en la Figura 4-26 :
 FIGURA 4-26 Agregar una regla entrante para permitir el tráfico HTTP

1. Fuente Cualquiera
2. Rangos de puertos de origen *
3. Etiqueta de servicio de destino
4. Etiqueta de servicio de destino VirtualNetwork
5. Rangos de Puertos de Destino 80,443
6. Protocolo TCP
7. Acción Permitir
8. Prioridad 100
9. Nombre Allow_HTTP_HTTPS
10. Descripción Permitir tráfico entrante HTTP y HTTPS en los puertos 80 y 443
6. Cuando haya completado los campos, haga clic en Agregar para crear la regla NSG.

Nota Aplicación de NSG a redes virtuales

Los rangos de IP de destino se refieren a la VNet, lo que permite que el NSG se

aplique a cualquier subred en cualquier VNet y evita acoplar el NSG a un rango de
IP específico. Sólo se permitirá el tráfico a aquellas subredes donde se aplica el
NSG.

7. Una vez guardada la regla de entrada, aparecerá en Azure Portal. Revise su regla
para asegurarse de que se haya creado correctamente.

Asociar NSG a una subred o interfaz de red

Los NSG se usan para definir las reglas sobre cómo se filtra el tráfico para las
implementaciones de IaaS en Azure. Ha aprendido a crear recursos NSG y definir las reglas
de NSG. Sin embargo, estos NSG, por sí solos, no son efectivos hasta que se asocian con
un recurso en Azure.

Los NSG se pueden asociar con tarjetas de interfaz de red (NIC), que están asociadas a las
máquinas virtuales, o se pueden asociar con una subred. Cada NIC o subred solo se puede
asociar con un único NSG. Sin embargo, un único NSG se puede asociar con varias NIC
y/o subredes.

Cuando un NSG está asociado con una NIC, se aplica a todas las configuraciones de IP en
esa NIC. El NSG debe permitir todo el tráfico entrante y saliente hacia y desde la NIC. Es
posible tener una máquina virtual con múltiples NIC y puede asociar el mismo NSG o uno
diferente a cada interfaz de red.

Alternativamente, los NSG se pueden asociar con una subred; en ese caso, se aplican a todo
el tráfico hacia y desde los recursos en esa subred. Este enfoque resulta útil cuando se
aplica la misma regla en varias máquinas virtuales.

Tenga en cuenta cómo se aplican los NSG

Microsoft no recomienda implementar NSG en subredes y NIC dentro de la misma subred.

Sin embargo, aunque Microsoft no lo recomienda, esta configuración es compatible y es
importante comprender cómo se aplican los NSG cuando se implementan de esta manera.
Para el tráfico entrante, primero se aplica el NSG en la subred, seguido por el NSG en la
NIC. El tráfico fluye sólo si ambos NSG permiten el paso del tráfico.

Para el tráfico saliente, la secuencia se invierte. Primero, se aplica el NSG en la NIC,

seguido por el NSG en la subred. Nuevamente, el tráfico fluye sólo si ambos GSN permiten
el paso del tráfico.

En todos los casos, las reglas dentro de cada NSG se aplican en orden de prioridad, siendo
aplicable primero la primera regla coincidente.

Ha visto cómo crear un NSG y cómo agregar una regla entrante para el tráfico HTTP y
HTTPS. Sin embargo, a menos que el NSG se haya asociado con subredes o NIC, esa regla
no está en vigor.

La siguiente tarea será asociar una regla con la subred de Aplicaciones. Puede utilizar la
hoja NSG o la hoja de subred de la red virtual para esta tarea. Este ejemplo utiliza el
primero.

En la hoja NSG de Azure Portal, haga clic en Subredes para mostrar la lista de subredes
actualmente asociadas con el NSG, que debería estar vacía en esta etapa. Haga clic en
Asociar para abrir la hoja Asociar subred. El portal de Azure solicitará dos configuraciones:
la red virtual y la subred. Tenga en cuenta que solo puede seleccionar redes virtuales en la
misma región de Azure que el NSG. En la Figura 4-27 , se seleccionó vnet-eastus-1 en el
menú desplegable Red virtual y snet-eastus-1 en el menú desplegable Subred.

FIGURA 4-27 Se han seleccionado la red virtual ExamRef-VNet y la subred de

aplicaciones
Después de guardarlas, las reglas del NSG se aplican a todas las interfaces de red asociadas
con esta subred. Esto permitirá el tráfico TCP entrante en los puertos 80 y 443 para todas
las máquinas virtuales que estén conectadas a esta subred. Por supuesto, para que responda,
necesita tener una VM de servidor web configurada y escuchando en los puertos 80 o 443.

Crear y configurar un grupo de seguridad de aplicaciones

Los grupos de seguridad de aplicaciones (ASG) son objetos independientes que se crean en
su suscripción de Azure. Puede pensar en un ASG como un objeto de grupo en un sistema
de identidad: los miembros del grupo tienen los permisos y el acceso asignados al grupo.
Los ASG funcionan de manera similar: agrega NIC al grupo y luego crea reglas de NSG
que se aplican al ASG. Luego, a cualquier interfaz de red que sea miembro del ASG se le
aplicarán las reglas del NSG.

Para crear un ASG, haga lo siguiente:

1. Desde Azure Portal, busque Grupos de seguridad de aplicaciones .

2. En la hoja ASG, haga clic en Crear.
3. En la hoja Crear un grupo de seguridad de aplicaciones, complete los campos
obligatorios: suscripción, grupo de recursos, nombre y región.
4. Haga clic en Revisar + Crear y luego haga clic en Crear. En la Figura 4-28 se
muestra un ejemplo .
FIGURA 4-28 Creación de un nuevo ASG denominado asg-webtier

Después de crear un ASG, el siguiente paso lógico es asociar interfaces de red con el grupo.
Esta acción se realiza desde el objeto de la máquina virtual que tiene la NIC asociada. Para
agregar la NIC a un ASG, navegue hasta una máquina virtual.

1. En el objeto VM, haga clic en Redes.

2. En la hoja VM Networking, asegúrese de que la NIC que desea configurar esté
seleccionada y luego haga clic en la pestaña Grupos de seguridad de aplicaciones,
como se muestra en la Figura 4-29 .

FIGURA 4-29 La hoja de red de una máquina virtual

3. En la pestaña Grupos de seguridad de aplicaciones, haga clic en Configurar los

grupos de seguridad de aplicaciones.
4. En la hoja Configurar los grupos de seguridad de aplicaciones, seleccione el ASG
que ha creado en el menú desplegable Grupos de seguridad de aplicaciones, como
se muestra en la Figura 4-30 . Luego haga clic en Guardar.
 FIGURA 4-30 Configurar la hoja Grupos de seguridad de aplicaciones

Una vez que haya creado un ASG y le haya agregado una o más interfaces de red, puede
utilizar el ASG como parte de una regla de NSG. Para hacerlo, seleccione Grupo de
seguridad de aplicaciones como Tipo de destino. Luego, en el menú Grupos de seguridad
de aplicaciones de destino, seleccione el ASG que creó. En la Figura 4-31 se muestra un
ejemplo de modificación de la regla que se creó anteriormente en esta habilidad .

FIGURA 4-31 Uso de un ASG como parte de una regla NSG

Evaluar reglas de seguridad efectivas

Al solucionar problemas de redes, puede resultar útil tener una visión más profunda de
cómo se aplican exactamente los NSG. Cuando las reglas de NSG se definen mediante
etiquetas de servicio y grupos de seguridad de aplicaciones, en lugar de prefijos o
direcciones IP explícitas, a veces no queda claro si un flujo en particular coincide con una
regla en particular.

La vista Reglas de seguridad efectivas está diseñada para proporcionar esta información.
Puede profundizar en cada regla de NSG y ver la lista exacta de prefijos de IP de origen y
destino que se han aplicado, independientemente de cómo se definió la regla de NSG.

Para acceder a la vista Reglas de seguridad efectivas, su máquina virtual debe estar
ejecutándose porque los datos se toman directamente de la configuración de la VM en
ejecución.

Usando Azure Portal, abra la hoja Máquina virtual y luego haga clic en Redes. Esto
mostrará la configuración de red, incluidas las reglas de NSG y un conveniente botón
Agregar regla de puerto de entrada. Cerca de la parte superior de esta hoja, haga clic en
Reglas de seguridad efectivas, como se muestra en la Figura 4-32 , para abrir la hoja Reglas
de seguridad efectivas.

FIGURA 4-32 Hoja de redes de la máquina virtual de Azure

La hoja Reglas de seguridad efectivas (consulte la Figura 4-33 ) es muy similar a la hoja
Redes que se muestra en la Figura 4-32 . Muestra el nombre de la interfaz de red y los NSG
asociados, junto con una lista de reglas de NSG.
FIGURA 4-33 Hoja Reglas de seguridad efectivas de la máquina virtual de Azure

La diferencia queda clara cuando hace clic en una de las reglas de NSG, que muestra los
prefijos de dirección IP de origen y destino exactos utilizados por esa regla. Por ejemplo,
en la Figura 4-34 , puede ver la lista exacta de prefijos de direcciones IP utilizados para la
regla Allow_HTTP_HTTPS.
FIGURA 4-34 Hoja Reglas de seguridad efectivas que muestra los prefijos de direcciones
de Internet

Con la lista exacta de prefijos de direcciones para cada regla de NSG, puede investigar
problemas de red sin temor a ninguna ambigüedad sobre cómo se definen las reglas de
NSG.

Implementar y configurar el servicio Azure Bastion

Generalmente, se conecta a máquinas virtuales remotas con RDP o SSH. Para hacerlo,
necesita asignar una dirección IP pública (con el puerto RDP/SSH expuesto) a la VM a la
que está intentando conectarse, o necesita aprovisionar un servidor de salto adicional,
asignarle una dirección IP pública. salte el servidor y luego conéctese a las otras máquinas
virtuales utilizando direcciones IP privadas internamente.

También puede intentar implementar grupos de seguridad de red (NSG) para restringir las
direcciones IP de origen y los puertos permitidos para el tráfico de su red. Aún así, está
exponiendo los puertos RDP/SSH a los servidores de origen a través de Internet, lo que
podría ser una posible amenaza a la seguridad.

Para superar este problema, Microsoft ha creado un servicio PaaS administrado llamado
Azure Bastion para proporcionar conexiones seguras a máquinas virtuales de Azure
utilizando el canal SSL a través de un navegador directamente sin utilizar ningún cliente
externo. Este servicio le ayuda a limitar amenazas como el escaneo de puertos y otro
malware.

Nota Regiones de Azure Bastion

El servicio Azure Bastion solo está disponible en regiones seleccionadas de todo el mundo.
Puede encontrar las regiones admitidas en https://learn.microsoft.com/en-
us/azure/bastion/bastion-faq .

El servicio Azure Bastion se aprovisiona dentro de una red virtual dentro de una subred
independiente denominada AzureBastionSubnet. Si tiene varias redes virtuales en su
entorno, puede implementar el servicio una vez en una red virtual central y acceder a las
máquinas virtuales en otras redes virtuales que estén emparejadas con el concentrador. Si
las redes virtuales no están emparejadas, cada red virtual necesitará su propio servicio y
subred Bastion.

En el siguiente ejemplo, se supone que ya creó la red virtual Exam-Ref-VNet con una
subred denominada AzureBastionSubnet y con un prefijo de al menos /27. Consulte la
Habilidad 4.1 para obtener instrucciones detalladas sobre cómo crear una red y una subred
virtuales.

Para crear un servicio Bastion mediante Azure Portal, siga estos pasos:

1. Busque Bastión . En la hoja Bastión, haga clic en Crear.

2. En la hoja Crear un bastión, proporcione un nombre, la suscripción donde se
encuentran sus recursos, el grupo de recursos para el bastión y la región (seleccione
la región admitida).
3. También debe seleccionar la red virtual y la subred y crear una dirección IP pública,
como se muestra en la Figura 4-35 .
 FIGURA 4-35 Creación de un bastión

4. Una vez creada, aparecerá la hoja de descripción general de Bastion-eus-vnet, como

se muestra en la Figura 4-36 .
 FIGURA 4-36 Hoja de descripción general del recurso Bastion

5. Para probar este Bastión, busque la hoja de descripción general de su VM, haga clic
en Conectar y haga clic en la pestaña Bastión, como se muestra en la Figura 4-37 .

FIGURA 4-37 Conexión a una máquina virtual mediante Azure Bastion

 6. Proporcione las credenciales y haga clic en Conectar. Se le redirigirá a la sesión del
navegador interactivo de la máquina virtual a través de Bastion, como se muestra
en la Figura 4-38 .

FIGURA 4-38 Administrar una VM usando Bastion

¿Necesita más revisión? Implementar Azure Bastion mediante PowerShell o CLI

Azure Bastion se puede implementar mediante PowerShell o CLI mediante la siguiente

documentación:

 PowerShell: https://learn.microsoft.com/en-us/azure/bastion/bastion-create-host-
powershell
 CLI: https://learn.microsoft.com/en-us/azure/bastion/create-host-cli
Configurar puntos de conexión de servicio para servicios de Azure

De forma predeterminada en Azure, se puede acceder a los servicios PaaS mediante un

punto de conexión público que se resuelve en una dirección IP pública. Cuando una
máquina virtual en una subred accede a este servicio, por ejemplo, una cuenta de
almacenamiento, la red y el enrutamiento de la máquina virtual traducen la IP de origen a la
IP de la VNet o la puerta de enlace NAT en la red virtual a medida que el tráfico sale de la
red. Esto significa que si capturara el paquete antes del servicio PaaS, la IP de origen sería
una dirección IP pública de la VNet. Si una segunda máquina virtual en la misma red
virtual tuviera acceso a la cuenta de almacenamiento, también tendría la dirección IP
pública como IP de origen.

Un punto final de servicio cambia dos cosas sobre cómo una VM puede acceder a un
servicio PaaS, como una cuenta de almacenamiento. En primer lugar, el enrutamiento se
optimiza para garantizar que se utilice la red troncal de Microsoft para comunicarse desde
la VNet al servicio. En segundo lugar, la VNet no traduce la dirección IP del paquete de la
VM. Esto significa que la IP de origen de la solicitud muestra la dirección IP privada de la
VM que intenta acceder al servicio. Sin embargo, el servicio sigue utilizando el punto final
público y la dirección IP pública que se asignaron, en este caso a la cuenta de
almacenamiento.

Los puntos finales de servicio se crean en el nivel de subred de una red virtual.
Supongamos que tiene dos máquinas virtuales: VM1 y VM2, que existen en dos subredes:
Subred1 y Subred2. Subnet1 tiene un punto final de servicio para almacenamiento. Subnet2
no tiene ningún punto final de servicio definido. Si VM2 intenta acceder a una cuenta de
almacenamiento, la dirección IP de origen será una dirección IP pública. Si VM1 intenta
acceder a la misma cuenta de almacenamiento, la dirección IP de origen será la dirección IP
privada de VM1.

1. Se puede configurar un punto final de servicio desde la subred de una red virtual.
Para configurar un punto final de servicio, navegue hasta su VNet y luego haga clic
en Subredes.
2. Seleccione el nombre de la subred para modificar sus propiedades.
3. En el menú desplegable Servicios, seleccione los servicios en los que desea habilitar
un punto final de servicio. La Figura 4-39 muestra un nuevo punto final de servicio
para el almacenamiento que se está creando para la subred0 de la red virtual vnet-
hub.
 FIGURA 4-39 Creación de un punto final de servicio

4. Clic en Guardar. El proceso puede tardar unos minutos en reflejarse en el

enrutamiento y el seguimiento de paquetes.

Configurar puntos de conexión privados para servicios de Azure

Los puntos finales privados llevan el concepto de puntos finales de servicio un paso más
allá. En el mismo escenario de una máquina virtual en la subred0 que intenta comunicarse
con una cuenta de almacenamiento, además de usar una dirección IP privada como
dirección IP de origen, la dirección IP de destino también será privada. Los puntos finales
privados crean una interfaz de red dedicada para el recurso de servicio PaaS específico para
el que lo crea y hacen que esa interfaz sea accesible desde la subred que configura.

En este ejemplo, supongamos que crea un punto de conexión privado para el

almacenamiento de blobs en la cuenta de almacenamiento. Puede crear ese punto final
privado en la misma subred, subnet0, a la que está asociada la VM. La NIC de máquina
virtual podría tener una dirección IP de 10.0.0.4/24 y el punto de conexión privado para el
almacenamiento de blobs podría ser 10.0.0.5/24. Cuando la máquina virtual se conecta al
punto de conexión del almacenamiento de blobs, el nombre DNS se resuelve desde la red
virtual a la dirección IP privada del punto de conexión privado. Por lo tanto, toda
comunicación utiliza direcciones IP privadas como origen y destino.

Normalmente, puede crear un punto de conexión privado directamente desde el recurso en

el que desea configurarlo o desde el Centro de vínculo privado. Para crear un punto de
conexión privado para el almacenamiento de blobs, siga estos pasos:

1. Desde Azure Portal, busque Puntos de conexión privados .

2. En la hoja Puntos de conexión privados, haga clic en Crear.
3. En la pestaña Conceptos básicos de la hoja Crear un punto de conexión privado,
seleccione su suscripción, grupo de recursos y región. Luego proporcione un
nombre para el punto final, como "pe-blobstorage1". La interfaz de red debe
completarse automáticamente con un nombre basado en el nombre del recurso. La
Figura 4-40 muestra la pestaña Básicos.

FIGURA 4-40 La pestaña Conceptos básicos de la hoja Crear un punto final

privado

4. Haga clic en Siguiente: Recurso.

5. En la pestaña Recurso, seleccione el recurso de Azure PaaS para el que desea crear
el punto de conexión privado. En este ejemplo, seleccione
Microsoft.Storage/storageAccounts como tipo de recurso, una cuenta de
almacenamiento como recurso y blob como subrecurso de destino, como se muestra
en la Figura 4-41 .
 FIGURA 4-41 La pestaña Recursos de la hoja Crear un punto final privado

6. Haga clic en Siguiente: Red virtual.

7. En la pestaña Red virtual, seleccione la VNet y la subred a las que desea asociar el
punto de conexión privado. En el ejemplo que se muestra aquí, se selecciona vnet-
hub paraVNet y subnet0 como subred. De forma predeterminada, se asignará
dinámicamente una dirección IP al punto final privado, como se muestra en la
Figura 4-42 .
 FIGURA 4-42 La pestaña Red virtual de la hoja Crear un punto final privado

8. Haga clic en Siguiente: DNS.

9. En la pestaña DNS, elija si desea integrar la interfaz de red del punto final privado
con una zona DNS. Esto se recomienda para que la dirección IP privada se resuelva
al acceder a la cuenta de almacenamiento, como se muestra en la Figura 4-43 .
 FIGURA 4-43 La pestaña DNS de la hoja Crear un punto final privado

10. Acepte los valores predeterminados restantes en las pestañas Etiquetas y Revisar +
Crear para crear el punto final privado. Una vez creado el punto final privado, puede
ver la dirección IP privada asociada con la interfaz de red del punto final privado,
como se muestra en la Figura 4-44 .
 FIGURA 4-44 Recurso de punto final privado

Habilidad 4.3: Configurar la resolución de nombres y el equilibrio de carga

Los humanos trabajan con nombres, pero las computadoras prefieren las direcciones IP.
Básicamente, DNS consiste en asignar nombres a direcciones IP, haciendo posible la
creación de redes basadas en nombres en lugar de IP. Simplificando un poco, un cliente
realiza una consulta DNS que contiene un nombre de dominio y recibe una respuesta que
contiene la dirección IP de ese nombre.

Casi dondequiera que mire, verá escenarios de DNS. Desde navegar por la web hasta
aplicaciones de teléfonos inteligentes, dispositivos IoT y búsquedas de bases de datos
dentro de una aplicación, DNS está en todas partes. Debido a que el DNS es tan universal,
es especialmente importante que los servicios DNS ofrezcan una disponibilidad
excepcionalmente alta y una latencia baja porque los efectos de las fallas o retrasos del
DNS serán generalizados.

Azure DNS proporciona un servicio DNS de alto rendimiento y alta disponibilidad en

Azure. Se puede utilizar para dos escenarios DNS separados:

 Proporcionar resolución de nombres en Internet para un dominio DNS público

alojando la zona DNS correspondiente
 Proporcionar resolución de nombres interna entre máquinas virtuales dentro o entre
redes virtuales
Además, con Azure, puede controlar qué servidores DNS están configurados en sus
máquinas virtuales, de modo que pueda usar sus propios servidores DNS en lugar del
servicio proporcionado por Azure.

Esta habilidad también analizará el equilibrio de carga. El equilibrio de carga es uno de los
requisitos cruciales del diseño de una red. Azure ofrece varias opciones para diseñar
soluciones de equilibrio de carga. En esta sección, aprenderá cómo configurar
balanceadores de carga en Azure.

Azure Load Balancer es un servicio de equilibrio de carga totalmente administrado que se

utiliza para distribuir el tráfico entrante a través de un grupo de servidores back-end que se
ejecutan en una red virtual de Azure. Puede recibir tráfico en puntos finales conectados a
Internet o a intranet y admite tráfico UDP y TCP.

Azure Load Balancer opera en la capa de transporte (capa 4 de OSI) para enrutar
conexiones entrantes y salientes a nivel de paquete. No finaliza las conexiones TCP y, por
lo tanto, no tiene visibilidad de las construcciones a nivel de aplicación. Por ejemplo, no
puede admitir la descarga de SSL, el enrutamiento basado en rutas URL o la afinidad de
sesión basada en cookies.

Azure Load Balancer proporciona baja latencia y alto rendimiento, escalando a millones de
flujos de red. También admite la conmutación por error automática entre servidores back-
end en función de sondeos de estado y permite aplicaciones de alta disponibilidad.

Esta habilidad cubre cómo:

 Configurar DNS de Azure

 Configurar el equilibrio de carga
 Solucionar problemas de equilibrio de carga

Configurar DNS de Azure

Esta sección describe cómo se configura Azure DNS para hospedar dominios conectados a
Internet. Comenzamos con un resumen de cómo funciona el sistema de nombres de
dominio porque comprender DNS es un requisito previo para comprender Azure DNS.

Cómo funciona el DNS

Para comprender adecuadamente los diversos servicios y funciones de DNS disponibles en

Azure, primero es necesario comprender cómo funciona el sistema de nombres de dominio.
En particular, es importante comprender las diferentes funciones que desempeñan los
servidores DNS recursivos y autoritativos, y cómo se enruta una consulta DNS a los
servidores de nombres DNS correctos mediante la delegación de DNS.

Primero, es importante comprender la distinción entre un nombre de dominio y una zona

DNS. El sistema de nombres de dominio conectado a Internet es una única jerarquía de
nombres global. Un nombre de dominio es sólo un nombre dentro de esa jerarquía. Ser
propietario de un nombre de dominio le otorga el derecho legal de controlar los registros
DNS dentro de ese nombre y cualquier subdominio de ese nombre.

Compra un nombre de dominio de un registrador de nombres de dominio. Luego, el

registrador le permite controlar qué servidores de nombres (NS) reciben las consultas DNS
para ese dominio, permitiéndole configurar los registros NS para el dominio.

Una zona DNS es la representación de un nombre de dominio en un servidor DNS

autorizado. Contiene la colección de registros DNS para un nombre de dominio
determinado. El servicio que aloja elLa zona DNS le permite administrar los registros DNS
dentro de la zona y aloja los datos en servidores de nombres autorizados, que responden
consultas DNS con respuestas DNS basadas en los registros DNS configurados.

En Azure, puede comprar nombres de dominio mediante el servicio App Service Domains.
El alojamiento de la zona DNS lo proporciona Azure DNS.

La configuración de DNS en el dispositivo del usuario apunta a un servidor DNS recursivo,

también conocido a veces como servicio DNS local (o LDNS) o simplemente como
solucionador de DNS. El servicio DNS recursivo normalmente lo aloja su empresa (si está
en el trabajo) o su ISP (si está en casa). También hay disponibles servicios DNS recursivos
públicos, como el servicio DNS público de Google (8.8.8.8). El servicio DNS recursivo no
aloja ningún registro DNS, pero permite que su dispositivo descargue la mayor parte del
trabajo asociado con la resolución de consultas DNS.

Para comprender la función de los servidores DNS recursivos y autoritativos, considere la

Figura 4-45 , que describe el proceso de resolución de DNS para una única consulta de
DNS, www.contoso.com .
FIGURA 4-45 El proceso de resolución de DNS

Este proceso de resolución se describe aquí:

1. Su PC realiza una consulta DNS a su servidor DNS recursivo configurado

localmente. Esta consulta es simplemente un paquete enviado a través del puerto
UDP 53, aunque también se puede utilizar TCP (normalmente cuando las respuestas
son demasiado grandes para caber en un paquete UDP).
2. Supongamos que el servidor DNS recursivo acaba de encenderse, por lo que no hay
nada en su caché. Pasa la consulta a uno de los servidores de nombres raíz (las
direcciones de los servidores de nombres raíz están preconfiguradas). Los
servidores de nombres raíz son servidores de nombres autorizados: alojan los
registros DNS reales para la zona raíz. Una zona es simplemente los datos que
representan un nodo en la jerarquía DNS.
3. Los servidores de nombres raíz no saben nada acerca de la zona DNS de
contoso.com . Sin embargo, sí saben dónde se puede encontrar la zona de
comunicaciones. Entonces, devuelven un registro DNS de tipo NS, que le dice al
servidor DNS recursivo dónde encontrar la zona de comunicaciones.
4. El servidor recursivo vuelve a intentarlo, esta vez llamando a los servidores de
nombres de comunicaciones. Nuevamente, estos son servidores de nombres
autorizados, esta vez para la zona de comunicaciones.
5. Estos servidores de nombres no reconocen “ www.contoso.com ”, pero tienen
registros NS que definen dónde se puede encontrar la zona DNS de contoso.com .
6. El servidor recursivo vuelve a intentarlo, esta vez llamando a los servidores de
nombres autorizados de contoso.com .
7. Estos servidores tienen autoridad para la zona DNS de contoso.com . Y hay un
registro en estos servidores que coincide con el nombre del registro www. El
 servidor reconoce el nombre de la consulta www.contoso.com y devuelve
la Arespuesta del registro que asigna este nombre a una dirección IP.
8. El servidor recursivo luego devuelve este resultado al cliente.

El servidor DNS recursivo también puede seguir una cadena de CNAMEregistros (que asignan
un nombre DNS a otro nombre). Y el servidor DNS recursivo también almacena en caché
las respuestas que recibe, para poder responder más rápidamente la próxima vez. La
duración del caché está determinada por la propiedad TTL (tiempo de vida) de cada registro
DNS.

El sistema de nombres de dominio es un sistema distribuido, donde un conjunto de

servidores puede remitir consultas a otro conjunto utilizando registros NS. El proceso que
acaba de ver para asignar un nombre de consulta a un resultado (quizás a través de una
larga cadena de servidores DNS autorizados) se llama resolución de nombres DNS .

Los registros NS indican a los clientes en Internet dónde encontrar los servidores de
nombres para una zona DNS determinada. Los registros NS para una zona DNS se
configuran en la zona principal y una copia de los registros también está presente en la zona
secundaria. Configurar estos registros NS se llama delegar un dominio DNS.

Un nombre de dominio completo (FQDN) es un nombre de dominio que contiene todos los
componentes hasta la zona raíz. Estrictamente hablando, un nombre completo termina con
a “.”(por ejemplo, www-dot-contoso-dot-com-DOT), que representa la zona raíz, aunque
por convención, a menudo se omite el punto final.

El DNS inverso es la capacidad de asignar una dirección IP a un nombre (a diferencia de

asignar un nombre a una dirección IP, que es lo que proporciona el DNS normal). Algunas
aplicaciones utilizan DNS inverso como forma débil de autenticación. Por ejemplo, se
utiliza habitualmente en algoritmos de puntuación de spam de correo electrónico.

Las búsquedas de DNS inversas utilizan una jerarquía de DNS que es completamente
independiente de las búsquedas directas. La búsqueda inversa de " www.contoso.com " no
se encuentra en la zona contoso.com . En cambio, se encuentra en una jerarquía de zonas
DNS separada basada en direcciones IP invertidas. Por ejemplo, supongamos que
" www.contoso.com " se resuelve en la dirección IP 1.2.3.4. Normalmente, la búsqueda
inversa de la dirección IP 1.2.3.4 será un registro denominado 4 en la zona DNS 3.2.1.in-
addr.arpa, lo que dará un FQDN de 4.3.2.1.in-addr.arpa (observe la dirección IP invertida).
DIRECCIÓN.)

Las zonas de búsqueda de DNS inversa están controladas por quien posee la subred IP. La
zona de búsqueda de DNS inversa para un bloque de IP de su propiedad se puede hospedar
en Azure DNS. Las direcciones IP públicas en Azure residen en bloques de IP propiedad de
Microsoft, lo que significa que las búsquedas de DNS inversas utilizan zonas de búsqueda
de DNS inversas administradas por Microsoft.
No hay nada en el sistema de nombres de dominio que garantice que la búsqueda inversa se
asigne al mismo nombre que se utilizó en la búsqueda directa. Esto se logra simplemente
mediante la configuración correcta en las zonas de búsqueda directa e inversa.

Servicios DNS en Azure

Hay varios servicios y características relacionados con DNS en Azure. En la siguiente lista
se ofrece una descripción general de cada uno. Los primeros tres elementos son servicios de
Azure, que usted consume creando recursos específicos del servicio por los que se le
facturará. Los tres elementos restantes son características de Azure, que se configuran
mediante ajustes en otros tipos de recursos, como una red virtual, una dirección IP pública
o una interfaz de red.

 Azure DNS le permite alojar sus dominios DNS en Azure. Proporciona la

capacidad de crear y administrar registros DNS para su dominio y proporciona
servidores de nombres que responden a las consultas DNS para su dominio de otros
usuarios en Internet. Azure DNS también admite zonas DNS privadas, que se usan
para la resolución de nombres basada en intranet para búsquedas de VM a VM,
incluida la compatibilidad con algunos escenarios no admitidos por el servicio DNS
proporcionado por Azure, que se cubrirán en breve.
 Azure Traffic Manager Un servicio DNS inteligente que utiliza DNS para
implementar la gestión del tráfico global. Mientras que Azure DNS siempre
proporciona la misma respuesta de DNS a cualquier consulta de DNS determinada,
en Azure Traffic Manager la misma consulta puede dar lugar a una de varias
respuestas posibles, dependiendo de una serie de factores que usted controle, como
dónde se encuentra el usuario final o cuál de sus puntos finales de servicio está
disponible actualmente. Esto le permite enrutar el tráfico de forma inteligente entre
regiones de Azure o entre implementaciones de Azure e implementaciones locales.
Comprender Traffic Manager está más allá del alcance del examen AZ-104.
 Dominios de App Service Este servicio se utiliza para comprar nombres de
dominio, que luego se pueden hospedar en Azure DNS. Este servicio está integrado
con Azure App Service, pero se puede utilizar para cualquier registro de dominio,
incluso si no se utiliza App Service.
 DNS proporcionado por Azure A veces llamado DNS interno, permite que las
máquinas virtuales de su red virtual se encuentren entre sí mediante consultas de
DNS basadas en el nombre de host de cada máquina virtual. Las consultas DNS son
internas (privadas) de la red virtual.
 DNS recursivo Un servicio proporcionado por Azure para la resolución de nombres
DNS desde sus máquinas virtuales de Azure u otros servicios de Azure. También
puede configurar sus máquinas virtuales para que utilicen su propio servidor DNS.
A esto a veces se le llama informalmente "traiga su propio DNS". Esto es común al
unir sus máquinas virtuales a un controlador de dominio.
 DNS inverso Proporciona la capacidad de configurar la búsqueda de DNS inverso
para una dirección IP pública asignada por Azure. (Las zonas de búsqueda de DNS
inversa para los bloques de IP que posee se pueden hospedar en Azure DNS).
Crear y delegar una zona DNS en Azure DNS

Una zona DNS es un recurso en Azure DNS. La creación de un recurso de zona DNS
asigna servidores de nombres DNS autorizados para alojar los registros DNS de esa zona.
Luego, se puede usar Azure DNS para administrar esos registros DNS. Las consultas DNS
dirigidas a esos servidores de nombres DNS reciben una respuesta DNS basada en los
registros DNS configurados en ese momento.

No es necesario que sea propietario del nombre de dominio correspondiente antes de crear
una zona DNS en Azure DNS. Puede crear una zona DNS con cualquier nombre, excepto
los nombres en el sufijo públicolista (ver https://publicsuffix.org/ ). También puede crear
más de un recurso de zona DNS con el mismo nombre de zona DNS, siempre que estén en
grupos de recursos diferentes. En este caso, las zonas DNS se asignarán a servidores de
nombres DNS separados, para que no surja ningún conflicto.

Puede probar sus registros DNS dirigiendo las consultas DNS directamente a los servidores
de nombres DNS asignados para su zona. Sin embargo, para uso general, su zona DNS
debe ser delegada desde la zona principal. Esto requiere que usted sea propietario del
nombre de dominio correspondiente.

Antes de poder delegar su zona DNS a Azure DNS, primero necesita conocer los nombres
de los servidores de nombres asignados a su zona. Estos se pueden obtener mediante Azure
Portal, PowerShell o CLI después de que se haya creado el recurso de zona DNS. No puede
predecir de antemano qué grupo de servidores de nombres se asignará a su zona DNS. Debe
crear la zona DNS y luego verificar.

Los servidores de nombres asignados varían entre zonas, por lo que si está configurando
varias zonas en Azure DNS, debe verificar los servidores de nombres en cada una. No
asuma que los servidores de nombres serán los mismos en todas sus zonas.

Cada registrador de nombres de dominio tiene su propia herramienta de administración de

DNS que le permite configurar los registros del servidor de nombres (NS) para un dominio.
En la página de administración de DNS del registrador, edite los registros NS y
reemplácelos con los que Azure DNS asignó.

Al delegar un dominio a Azure DNS, debe usar los nombres del servidor de nombres
proporcionados por Azure DNS. Siempre debes utilizar los cuatro nombres de servidor de
nombres, independientemente del nombre de tu dominio. La delegación de dominio no
requiere que el nombre del servidor de nombres coincida con su nombre de dominio.

Nota Delegación de zonas DNS a Azure DNS

Al delegar un dominio en Azure DNS, no utilice registros adhesivos de DNS para apuntar
directamente a las direcciones IP del servidor de nombres de Azure DNS. Un registro
adhesivo es un registro de servidor DNS que no tiene autoridad para la zona y se utiliza
para evitar una condición de dependencias imposibles para una zona DNS. Estas
direcciones IP podrían cambiar en el futuro. Las delegaciones que utilizan nombres de
servidores de nombres en su propia zona (a veces denominados servidores de nombres
personalizados) no se admiten actualmente en Azure DNS.

Azure DNS trata las zonas secundarias como zonas completamente separadas. Por lo tanto,
delegar una zona secundaria sigue el mismo proceso que delegar la zona principal:

1. Cree el recurso de la zona secundaria.

2. Identifique los servidores de nombres para la zona secundaria. Estos serán
diferentes de los servidores de nombres asignados a la zona principal.
3. Cree registros NS en la zona principal para delegar la zona secundaria. El nombre
de los registros NS debe ser el nombre de la zona secundaria (excluyendo el sufijo
del nombre de la zona principal) y los RDATA en los registros NS deben ser los
servidores de nombres de la zona secundaria.

Nota Delegación de zonas DNS secundarias a Azure DNS

Cuando delega una zona secundaria, todos los servidores de nombres existentes en la zona
principal que coincidan con el nombre de la zona secundaria quedarán ocultos. Aún los
verá en Azure Portal, pero no se resolverán desde los servidores de nombres porque la
delegación a la zona secundaria tendrá prioridad. Para evitar este problema, antes de
delegar la zona secundaria, verifique si hay registros que estarán ocultos y duplíquelos en la
zona secundaria. Esto se aplica a cualquier servicio DNS, no solo a Azure DNS.

Administrar registros DNS en Azure DNS

Cada registro en el sistema de nombres de dominio incluye las siguientes propiedades:

 Nombre El nombre del registro DNS se combina con el nombre de la zona DNS
para formar el nombre de dominio completo (FQDN). Por ejemplo, el registro
"www" en la zona " contoso.com " corresponde al FQDN " www.contoso.com ".
 Tipo El tipo de registro DNS determina qué datos están asociados con el registro y
para qué se utiliza. En la Tabla 4-7 se proporciona una lista de los tipos de registros
admitidos por Azure DNS .
 TTL La propiedad Tiempo de vida (TTL) indica a los servidores DNS recursivos
durante cuánto tiempo se debe almacenar en caché un registro DNS.
 RDATA Los datos devueltos para cada registro DNS. El tipo de datos devueltos
depende del tipo de registro DNS. Por ejemplo, un registro A devolverá una
dirección IPv4, mientras que un registro CNAME devolverá otro nombre de
dominio.

La colección de registros en una zona DNS con el mismo nombre y el mismo tipo se
denomina conjunto de registros de recursos . (Estas colecciones también se denominan
"RRSets" y "conjuntos de registros" en Azure DNS). Los registros en Azure DNS se
administran mediante conjuntos de registros. Los conjuntos de registros son un recurso
secundario de la zona DNS y pueden contener hasta 20 registros DNS individuales. El
nombre, el tipo y el TTL se configuran en el conjunto de registros, y RDATA se configura
en cada registro DNS dentro del conjunto de registros.

Para crear un conjunto de registros DNS en la raíz (o vértice ) de una zona DNS, utilice el
nombre del conjunto de registros @. Por ejemplo, el conjunto de registros nombrado @en la
zona contoso.com se resolverá en las consultas de " contoso.com ". También puede utilizar
un asterisco ( *)en el nombre del conjunto de registros para crear registros comodín (sujeto
a las reglas de coincidencia de comodines DNS).

Azure DNS admite todos los tipos de registros DNS utilizados habitualmente. La lista
completa de tipos de registros admitidos, junto con una descripción de cada uno, se
proporciona en la Tabla 4-7 .

TABLA 4-7 Tipos de registros DNS en Azure DNS

Tipo de
Observaciones
registro DNS

A Se utiliza para asignar un nombre a una dirección IPv4.

AAAAA Se utiliza para asignar un nombre a una dirección IPv6.

CAA Se utiliza para especificar qué autoridades certificadoras pueden emitir

certificados para un dominio. Tenga en cuenta que CAAlos registros no están
disponibles actualmente en Azure Portal, por lo que deben configurarse
mediante la CLI de Azure o Azure PowerShell.

CNOMBRE Proporciona una asignación de un nombre DNS a otro. Los estándares

DNS no permiten CNAMEregistros en el vértice de la zona. Además, no
puede crear un CNAMEregistro con el mismo nombre que un registro de
cualquier otro tipo de registro, y CNAMElos conjuntos de registros solo
admiten un único registro DNS en lugar de una lista de registros. Estas son
restricciones de DNS RFC, no limitaciones de Azure DNS.

MX Se utiliza para la configuración del servidor de correo.

NS Los estándares DNS requieren un registro NS establecido en el vértice de

la zona que contiene los servidores de nombres para la zona DNS. Esto se
crea para usted cuando se crea la zona DNS. Se puede editar, por ejemplo,
para agregar registros adicionales cuando se aloja conjuntamente una zona
DNS con más de un proveedor, pero no se puede eliminar.
 Tipo de
Observaciones
registro DNS

Puede crear conjuntos de registros NS adicionales para delegar zonas

secundarias.

PTR Se utiliza para búsquedas de DNS inversas en zonas de búsqueda inversa.

SOA Se requiere un registro SOA en el vértice de cada zona. Esto se crea y

elimina con el recurso de la zona DNS.

SRV Los registros SRV se utilizan para el descubrimiento de servicios para una
amplia gama de servicios, desde Kerberos hasta Minecraft y el protocolo
de inicio de sesión utilizado para la telefonía por Internet.

Tenga en cuenta que los parámetros Servicey Protocolse especifican como

parte del nombre del conjunto de registros,
como _service._protocol.media.contoso.com . Algunos servicios DNS le
solicitan que ingrese estos valores por separado y luego los combinen para
formar el nombre del conjunto de registros. Con Azure DNS, debe
especificarlos como parte del nombre del conjunto de registros, pero no se
ingresan por separado.

TXT Se utiliza para una amplia gama de aplicaciones, incluido el marco de

políticas del remitente (SPF) de correo electrónico.

Nota Registros SPF

Los registros del Marco de políticas del remitente (SPF) se utilizan para identificar
servidores de correo legítimos para un dominio y ayudar a prevenir el spam. El tipo de
registro SPF quedó obsoleto por RFC7208, que establece que el tipo de registro TXT debe
usarse para registros SPF.

Registros de alias

Azure DNS ofrece integración con otros servicios alojados en Azure mediante registros de
alias.

Con los registros DNS convencionales, usted especifica explícitamente el destino, como la
dirección IP de un registro A. Si la dirección IP cambia, deberá actualizar el registro DNS
en consecuencia.
Con registros de alias , puede definir el destino del registro DNS implícitamente haciendo
referencia a otro recurso de Azure. El valor del registro DNS se completa automáticamente
según el recurso al que hace referencia y se actualiza automáticamente si ese recurso
cambia.

Los registros de alias pueden hacer referencia a tres tipos de recursos diferentes:

 Una A o AAAA. Estos registros pueden hacer referencia a una dirección IP pública,
de tipo IPv4 o IPv6, respectivamente.
 A, AAAA o CNAME Estos registros pueden hacer referencia a un perfil de Traffic
Manager. Esto expone la resolución de nombres dinámica y administrada por el
tráfico de Traffic Manager directamente dentro de un registro en su dominio DNS.
Antes de esta función, tenías que crear un CNAME.registro de su dominio a un
registro en el dominio Trafficmanager.net proporcionado por Azure Traffic
Manager.
 Un A, AAAA o CNAME. Estos registros también pueden hacer referencia a otro
registro en la misma zona DNS. Esto le permite crear registros sincronizados con
facilidad.

Los registros de alias son una forma muy útil de abordar una serie de escenarios.

 En primer lugar, los registros de alias evitan registros DNS huérfanos. Un problema
común con los sistemas DNS es que los registros no se limpian cuando se eliminan
los servicios a los que hacen referencia. El registro DNS queda pendiente. Con los
registros de alias, el registro DNS ya no se resuelve una vez que se elimina el
servicio subyacente.
 En segundo lugar, como ya se ha comentado, al actualizarse automáticamente
cuando cambian los recursos subyacentes, los registros de alias reducen la
sobrecarga de gestión y le ayudan a evitar el tiempo de inactividad accidental de la
aplicación.
 En tercer lugar, debido a que los registros de alias le permiten evitar el uso de un
registro CNAME cuando usa un nombre de dominio personalizado con Azure
Traffic Manager, puede implementar un registro administrado por tráfico en la
cúspide de su dominio.

Cree zonas DNS y registros DNS mediante Azure Portal

Para crear una zona DNS, desde Azure Portal, busque Zona DNS. En la hoja Zonas DNS,
haga clic en Crear para abrir la hoja Crear zona DNS. Especifique el nombre de dominio
DNS como nombre de recurso de la zona DNS y seleccione su grupo de recursos, como se
muestra en la Figura 4-46 .
FIGURA 4-46 Creación de una zona DNS mediante Azure Portal

Nota Zonas DNS y región de Azure

Al crear una zona DNS, el campo de ubicación solo especifica la ubicación del grupo de
recursos. No se aplica al recurso de la zona DNS en sí, que es global en lugar de regional.

Una vez que se haya creado la zona DNS, abra la hoja de la zona DNS. Los servidores de
nombres DNS de Azure asignados a la zona se enumeran en Aspectos esenciales, como se
resalta en la Figura 4-47 .
FIGURA 4-47 Hoja de zona DNS, que muestra los servidores de nombres DNS de Azure
asignados a esta zona

Para configurar la delegación DNS para la zona DNS, estos servidores de nombres deben
aparecer en los registros NS correspondientes en la zona principal. Si el nombre de dominio
se compró utilizando el servicio Azure App Service Domains, esto se hará
automáticamente. De lo contrario, esto debe configurarse en el registrador DNS donde se
compró el nombre de dominio.

Para crear un registro DNS en un nuevo conjunto de registros, haga clic en +Conjunto de
registros para abrir la hoja Agregar conjunto de registros. Si existe un registro con el mismo
nombre y tipo que el registro que desea crear, debe hacer clic en el conjunto de registros
existente y agregar el nuevo registro allí. Para crear un par de registros A con el nombre
"www" (que proporciona el nombre de dominio completo " www.hugelab.net "), utilice los
siguientes valores, como se muestra en la Figura 4-48 .
FIGURA 4-48 La hoja Agregar conjunto de registros

 Nombre www
 Escribe un
 Conjunto de registros de alias No.
 TTL 1 hora (o elige tu propio valor)
 Direcciones IP Ingrese un registro de direcciones IP, una para cada registro DNS en
el conjunto de registros.

Supongamos que ahora desea crear un registro DNS en el vértice de la zona (de modo que
el nombre de dominio completo sea simplemente el nombre de la zona DNS
“ hugelab.net ”), que apunte a una dirección IP pública asignada dinámicamente. Haga clic
en +Conjunto de registros nuevamente y complete la hoja Agregar conjunto de registros
con las siguientes configuraciones, como se muestra en la Figura 4-49 :
FIGURA 4-49 La hoja Agregar conjunto de registros para un conjunto de registros de alias

 Nombre @ (Esta es una convención DNS para registros en el vértice de la zona).

 Escribe un
 Conjunto de registros de alias Sí
 Elija Suscripción Elija la suscripción que contiene la dirección IP pública
 Recurso de Azure Elija el recurso de dirección IP pública
 TT 1 hora (o elige tu propio valor)

Configurar ajustes de DNS personalizados

Cuando una máquina virtual se conecta a una red virtual, recibe su dirección IP a través de
DHCP. Como parte de ese intercambio de DHCP, la configuración de DNS también se
configura en la VM. De forma predeterminada, las máquinas virtuales están configuradas
para usar servidores DNS recursivos en Azure. Estos proporcionan resolución de nombres
para dominios alojados en Internet, además de resolución de nombres privada de VM a VM
dentro de una red virtual.
El nombre de host de la VM se utiliza para crear una asignación de registro DNS a la
dirección IP privada de la VM. Usted especifica el nombre de host, que es simplemente el
nombre de la máquina virtual, cuando crea la máquina virtual. Azure especifica el sufijo
DNS mediante un valor que es exclusivo de la red virtual. Estos sufijos terminan
en internal.cloudapp.net . El nombre de host y el sufijo DNS juntos forman el nombre de
dominio completo único.

La resolución de nombres para estos registros DNS es privada: solo se pueden resolver
desde dentro de la red virtual. El sufijo DNS se configura como un sufijo de búsqueda
dentro de cada VM, por lo que los nombres se pueden resolver entre VM dentro de la red
virtual utilizando únicamente el nombre de host.

Este servicio DNS integrado utiliza la dirección IP 168.63.129.16. Esta es una dirección IP
estática especial que la plataforma reserva para este propósito. Esta IP proporciona tanto el
servicio DNS autorizado para DNS proporcionado por Azure como el servicio DNS
recursivo de Azure, que se usa para resolver nombres DNS de Internet desde máquinas
virtuales de Azure. Esta IP también se usa para otras cosas, como problemas de salud de
Azure Load Balancer, mensajes de latido para roles PaaS, etc.

Traiga su propio DNS

Alternativamente, puede configurar sus propios ajustes de DNS, que se configurarán

durante el intercambio de DHCP en las máquinas virtuales. Esto le permite especificar sus
propios servidores DNS, ya sea en Azure o ejecutándose localmente. Con sus propios
servidores DNS, puede admitir cualquier escenario de DNS, incluidos los escenarios no
admitidos por el servicio proporcionado por Azure. Los escenarios de ejemplo que
requieren el uso de sus propios servidores DNS incluyen la resolución de nombres entre
máquinas virtuales en diferentes redes virtuales, la resolución de nombres entre recursos
locales y máquinas virtuales de Azure, la búsqueda DNS inversa de direcciones IP internas
y la resolución de nombres para dominios que no tienen acceso a Internet. , como dominios
asociados con Active Directory.

No debe especificar su propia configuración de DNS dentro de la propia máquina virtual

porque la plataforma desconoce la configuración que ha elegido. En cambio, Azure
proporciona opciones de configuración dentrola configuración de la red virtual. Estas
configuraciones del servidor DNS están en el nivel de la red virtual y se aplican a todas las
máquinas virtuales de la red virtual.

También puede especificar la configuración del servidor DNS específica de la VM dentro

de cada interfaz de red. Esto tiene prioridad sobre la configuración a nivel de red virtual.
Cuando se implementan varias máquinas virtuales en un conjunto de disponibilidad y se
configuran servidores DNS en la interfaz de red, todas las máquinas virtuales del conjunto
de disponibilidad se actualizan. Los servidores DNS aplicados son la unión de los
servidores DNS a nivel de interfaz de red de todo el conjunto de disponibilidad.

Nota Configuración del servidor de nombres DNS

Las configuraciones de DNS personalizadas se pueden configurar en el nivel de VNet y en
el nivel de interfaz de red, pero no en el nivel de subred. Para utilizar configuraciones
específicas para una subred individual, debe configurar esas configuraciones en cada
interfaz de red en la subred.

Puede utilizar esta configuración de DNS para dirigir las consultas de DNS de sus
máquinas virtuales a cualquier servidor DNS que elija. Pueden apuntar a direcciones IP de
servidores locales, como un controlador de dominio de Active Directory o un dispositivo de
red, un servicio DNS que se ejecuta en una máquina virtual de Azure o cualquier otro lugar
de Internet.

Si utiliza sus propios servidores DNS, esos servidores deberán ofrecer un servicio DNS
recursivo; de lo contrario, se interrumpirá la resolución de nombres para los dominios de
Internet desde sus máquinas virtuales. Si apunta la configuración de DNS directamente a un
servicio DNS recursivo basado en Internet, como Google 8.8.8.8, no podrá realizar
búsquedas de VM a VM.

Nota Reinicie las máquinas virtuales al cambiar la configuración de DNS

Si realiza cambios en la configuración de DNS a nivel de red virtual, todas las máquinas
virtuales afectadas deben reiniciarse para retomar la nueva configuración. Si realiza
cambios en la configuración de DNS en el nivel de la interfaz de red, la máquina virtual
afectada (o las máquinas virtuales del conjunto de disponibilidad, si se usan) se reiniciarán
automáticamente para seleccionar la nueva configuración.

Un desafío al utilizar sus propios servidores DNS es que necesita registrar cada VM en su
servicio DNS. Para hacer esto, puede configurar el servicio DNS para aceptar consultas de
DNS dinámico, que la VM enviará cuando se inicie. Esto permite que las máquinas
virtuales se registren automáticamente en el servidor DNS. Un problema con este enfoque
es que el sufijo DNS en la consulta DNS dinámica debe coincidir con el nombre de la zona
DNS configurada en el servidor DNS, y Azure no admite la configuración del sufijo DNS a
través de la configuración de la plataforma Azure. Como solución alternativa, puede
configurar usted mismo el sufijo DNS correcto dentro de cada máquina virtual mediante un
script de inicio.

Configurar ajustes de DNS personalizados mediante el portal de Azure

Para configurar los servidores DNS en una VNet, abra la hoja de red virtual y luego haga
clic en Servidores DNS en Configuración a la izquierda, como se ve en la Figura 4-50 .
Luego puede ingresar los servidores DNS que desea que use esta VM. Después de guardar
los cambios, debe reiniciar las máquinas virtuales en la VNet para recoger los cambios.
FIGURA 4-50 Servidores DNS personalizados para una red virtual configurada mediante
Azure Portal

Los pasos para configurar los servidores DNS en una VM individual son similares a los que
se muestran en la Figura 4-50 . Abra la hoja para la interfaz de red de la máquina virtual y
luego haga clic en Servidores DNS en Configuración. Luego puede ingresar los servidores
DNS que desea que use esta VM. Tenga en cuenta que las máquinas virtuales en un
conjunto de disponibilidad adoptarán la unión de servidores DNS de las interfaces de red en
todo el conjunto de disponibilidad. Después de guardar los cambios, su máquina virtual (o
máquinas virtuales en el conjunto de disponibilidad) se reiniciará automáticamente para
recoger los cambios.

Configurar zonas DNS privadas

Además de admitir dominios DNS conectados a Internet, Azure DNS también admite
dominios DNS privados. Esto proporciona un enfoque alternativo para la resolución de
nombres dentro y entre redes virtuales.

Al usar zonas DNS privadas, puede usar sus propios nombres de dominio personalizados
(incluido el sufijo DNS, en lugar del sufijo DNS proporcionado por Azure) sin la
sobrecarga ni la complejidad de ejecutar sus propios servidores DNS.

El servicio admite el registro automático de máquinas virtuales en la zona privada, pero

solo desde una única red virtual, denominada VNet de registro. Esto debe registrarse en la
zona DNS antes de crear cualquier máquina virtual.

Si desea resolver nombres de máquinas virtuales de varias redes virtuales, las máquinas
virtuales de cualquier otra red deben registrarse en el servicio manualmente (o mediante
una automatización personalizada). La resolución de nombres entre redes virtuales es
independiente de la conectividad entre redes virtuales, por lo que no es necesario emparejar
sus redes virtuales ni configurar una conexión de red virtual a red virtual.

Las redes virtuales que admiten la resolución de nombres se denominan redes virtuales de
resolución . El nombre de la zona no está registrado en las máquinas virtuales como sufijo
de búsqueda de DNS, por lo que deberá registrarlo usted mismo o utilizar nombres de
dominio completos en sus consultas de DNS.

Para crear una zona DNS privada desde Azure Portal, busque Zonas DNS privadas. En la
página Zonas DNS privadas, haga clic en Crear para abrir la hoja Crear zona DNS privada.
Especifique el nombre de dominio DNS como nombre de recurso de la zona DNS y
seleccione su grupo de recursos, como se muestra en la Figura 4-51 .

FIGURA 4-51 Creación de una zona DNS privada mediante Azure Portal

Con una zona DNS privada, puede crear vínculos de red virtual haciendo clic en Vínculos
de red virtual y luego haciendo clic en Agregar, como se muestra en la Figura 4-52 .
FIGURA 4-52 Enlaces de red virtual para una zona DNS privada

Solo necesita completar los campos Nombre del enlace, Suscripción y Nombre de la red
virtual, como se muestra en la Figura 4-53 . También puede seleccionar la casilla de
verificación Habilitar registro automático, queautomatizar la creación de registros DNS en
la zona DNS privada para las máquinas virtuales que están conectadas a la red virtual.
FIGURA 4-53 Agregar un enlace de red virtual para una zona DNS privada

Una vez creado, aparece un enlace de red virtual a la derecha.

Configurar el equilibrio de carga

El equilibrio de carga es uno de los requisitos cruciales del diseño de redes. Azure ofrece
varias opciones para diseñar soluciones de equilibrio de carga. En esta sección, aprenderá
cómo configurar Azure Application Gateway y diferentes equilibradores de carga en Azure.

Equilibrador de carga de Azure

La implementación de Azure Load Balancer implica la configuración coordinada de varios

grupos de configuraciones. Estas configuraciones funcionan juntas para definir el
comportamiento general del Load Balancer.
Niveles de balanceador de carga básico y estándar

Azure Load Balancer está disponible en dos niveles de precios (SKU): Básico y Estándar.
Estos niveles ofrecen diferentes niveles de escala, características y precios. La Tabla 4-
8 proporciona una comparación de las principales diferencias de características entre los
niveles Básico y Estándar.

TABLA 4-8 Niveles de balanceador de carga estándar y básico

Característica Estándar Básico

Zonas de Admite implementaciones de zona No soportado

disponibilidad específica o redundante de zona,
incluido el equilibrio de carga entre
zonas

Grupos de Hasta 5000 servidores, cualquier Hasta 300 configuraciones IP

backend combinación de máquinas virtuales,
conjuntos de disponibilidad y Deben ser máquinas virtuales
conjuntos de escalado de máquinas en el mismo conjunto de
virtuales, en la misma red virtual disponibilidad o un único
conjunto de escalado de
máquinas virtuales.

Sondas de TCP, HTTP, HTTPS TCP, HTTP

salud

Diagnóstico Métricas enriquecidas a través de No soportado

Azure Monitor, incluidos contadores
de bytes y paquetes, estado de la sonda
de estado, intentos de conexión, estado
de la conexión saliente y más.

Seguridad Flujos entrantes cerrados por defecto Abierto por defecto

Flujos entrantes permitidos en la lista Opcionalmente, puede

blanca mediante grupos de seguridad restringir los flujos mediante
de red grupos de seguridad de red.

Conectividad Admite múltiples direcciones IP IP saliente única

saliente salientes que se pueden configurar
mediante reglas de salida No configurable
 Característica Estándar Básico

Otras Admite puertos HA, reinicio de TCP N/A

características en caso de tiempo de inactividad y
operaciones de administración más
rápidas

Precios Según el número de reglas y datos Gratis

procesados

SLA Disponibilidad del 99,99 por ciento Ninguno

para una ruta de datos con dos
máquinas virtuales en buen estado

Nota SKU del equilibrador de carga

Al momento de escribir este artículo, los balanceadores de carga de SKU básicos se

retirarán en septiembre de 2025, y las nuevas implementaciones estarán restringidas
después de marzo de 2025. Es posible que este tema aún esté incluido en el examen AZ-
104 hasta entonces. Para obtener más información, visite https://azure.microsoft.com/en-
us/updates/azure-basic-load-balancer-will-be-retired-on-30-september-2025-upgrade-to-
standard-load -equilibrador/ .

Configuración IP frontal

Azure Load Balancer admite dos modos: Internal Load Balancer y Public Load Balancer.
En cada caso, la configuración IP del front-end define el punto final en el que el
equilibrador de carga recibe el tráfico entrante:

 Equilibrador de carga interno Se utiliza para equilibrar la carga del tráfico de

aplicaciones orientadas a la intranet o entre niveles de aplicaciones. La
configuración de IP de la interfaz hace referencia a una subred y una dirección IP de
esa subred se asigna mediante una asignación dinámica o estática al equilibrador de
carga.
 Balanceador de carga público Se utiliza para equilibrar la carga del tráfico de
aplicaciones orientadas a Internet. La configuración de IP de la interfaz hace
referencia a un recurso de dirección IP pública independiente, que se utiliza para
recibir tráfico entrante.

Cuando se utiliza con máquinas virtuales IaaS, cada equilibrador de carga puede admitir
múltiples configuraciones de IP de front-end. Por lo tanto, puede recibir tráfico en múltiples
direcciones IP para equilibrar la carga del tráfico para múltiples aplicaciones. Sin embargo,
todas las configuraciones de frontend deben ser del mismo tipo: interna o pública.
Un equilibrador de carga público debe estar asociado con un recurso de dirección IP
pública. Si el balanceador de carga usa el plan de tarifa Estándar, la dirección IP pública
también debe usar el plan de tarifa Estándar. Los balanceadores de carga de nivel estándar
admiten opciones de implementación tanto específicas de zona como redundantes de zona.
La elección de la opción de implementación se toma de la dirección IP pública asociada, en
lugar de estar explícitamente en las propiedades del balanceador de carga.

Configuración de back-end

El grupo de back-end define los servidores de back-end sobre los cuales el equilibrador de
carga distribuirá el tráfico entrante.

Cuando se utiliza un equilibrador de carga de nivel básico, este grupo de back-end debe
comprender una única máquina virtual, máquinas virtuales en el mismo conjunto de
disponibilidad o un conjunto de escalado de VM. Si utiliza un conjunto de escalado de VM,
el tráfico se distribuirá a todas las máquinas virtuales del conjunto de escalado de VM. No
puede distribuir el tráfico a varias máquinas virtuales a menos que sean miembros del
mismo conjunto de disponibilidad o conjunto de escalado de VM.

Con un balanceador de carga de nivel estándar, estas restricciones desaparecen. Los grupos
de back-end pueden comprender una combinación de máquinas virtuales en conjuntos de
disponibilidad y conjuntos de escalado de VM.

Sondas de salud

Azure Load Balancer admite el sondeo continuo del estado de las instancias del grupo
back-end para determinar qué instancias están en buen estado y pueden recibir tráfico. El
equilibrador de carga dejará de enviar flujos de tráfico a cualquier instancia del grupo de
back-end que se determine que no está en buen estado. Las instancias en mal estado
continúan recibiendo sondeos de estado, por lo que el balanceador de carga puede reanudar
el envío de tráfico a esa instancia una vez que vuelva a un estado saludable.

Azure Load Balancer admite tres tipos de sondeos de estado:

 Las sondas TCP intentan iniciar una conexión completando un protocolo de enlace
TCP de tres vías (SYN, SYN-ACK, ACK). Si tiene éxito, la conexión se cierra con
un protocolo de enlace de cuatro vías (FIN, ACK, FIN y ACK).
 Las sondas HTTP emiten un GET HTTP con una ruta especificada.
 Las sondas HTTPS son similares a las sondas HTTP, excepto que se utiliza un
contenedor TLS/SSL. Las sondas HTTPS solo se admiten en el balanceador de
carga de nivel estándar.

Los tres tipos de sonda también deben especificar el puerto de la sonda o el intervalo. El
intervalo mínimo de sonda tiene una duración de cinco segundos y el umbral mínimo de
falla de sonda consecutiva es de dos segundos. Para las sondas HTTP y HTTPs, también se
debe proporcionar la ruta de la sonda.
Un punto final se marca como incorrecto si

 Solo para sondeos HTTP o HTTPS, el punto final devuelve un código de estado
HTTP distinto de 200 OK.
 El punto final de la sonda cierra la conexión mediante un restablecimiento de TCP.
 El punto final de la sonda no responde a una cantidad consecutiva de solicitudes
durante el período de tiempo de espera. La cantidad de solicitudes fallidas
necesarias para marcar el punto final en mal estado es configurable.

La configuración de una página de verificación de estado dedicada, como /healthcheck.php,

permite que cada servidor backend implemente una lógica de aplicación personalizada para
determinar si está en buen estado. Verificar la disponibilidad de una base de datos back-end
es un ejemplo de esto.

Al configurar grupos de seguridad de red (NSG) para servidores back-end, es importante

permitir tanto el tráfico entrante como el tráfico de sondeo. Azure Load Balancer no
modifica la dirección IP de origen del tráfico entrante, por lo que las reglas de tráfico
entrante se deben configurar como si el balanceador de carga no estuviera en uso. Para
incluir en la lista blanca el tráfico de sonda entrante, permita el tráfico que se origina desde
la AzureLoadBalanceretiqueta de servicio.

Configurar reglas de equilibrio de carga

Las reglas de equilibrio de carga se utilizan para conectar la configuración IP del front-end
al grupo de servidores back-end y a una sonda de estado. Con Azure Load Balancer, no hay
una configuración de HTTP de back-end independiente; cualquier configuración HTTP
adicional se define directamente dentro de la propia regla de equilibrio de carga. Estos
incluyen puertos frontend y back-end, tiempo de espera de inactividad, protocolo (TCP o
UDP) y versión de IP (IPv4 o IPv6).

Con la regla de equilibrio de carga, también puede configurar cómo se distribuyen las
conexiones entrantes entre instancias de back-end. Hay tres opciones:

 Ninguno El tráfico se distribuye en función de un hash de 5 tuplas de IP de origen,

IP de destino, puerto de origen, puerto de destino y protocolo. Esta es la opción por
defecto.
 El tráfico de IP de origen se distribuye basándose únicamente en un hash de 2
tuplas de IP de origen y destino.
 El tráfico de IP y protocolo de origen se distribuye en función de un hash de 3
tuplas de IP de origen, IP de destino y protocolo.

Con la opción predeterminada, las nuevas sesiones TCP de un cliente determinado pueden
enrutarse a un punto final de back-end diferente porque el puerto de origen habrá cambiado.
Al excluir el puerto de origen del algoritmo de equilibrio de carga, las opciones IP de
origen y Protocolo IP de origen proporcionan asignaciones consistentes entre el cliente y
los servidores back-end individuales a través de conexiones separadas. Esto es útil en
aplicaciones donde el tráfico entre el cliente y el servidor utiliza más de una conexión o
protocolo. Algunos ejemplos son las cargas de medios que utilizan tanto una sesión TCP
para controlar y monitorear la carga, como también paquetes UDP para cargar los datos de
medios.

Reglas NAT entrantes

Azure Load Balancer se puede configurar para distribuir el tráfico entrante entre un grupo
de servidores back-end. Otro escenario común es cuando se debe realizar una conexión a un
back-end específico.servidor a través de la interfaz del balanceador de carga. Esto es útil
para obtener acceso a un servidor específico, como cuando se diagnostica un problema sin
exponer un nuevo punto final en ese servidor.

La conectividad directa a servidores individuales se logra creando una asignación de

puertos desde el frontend a un servidor backend específico. Esta asignación también se
conoce como regla NAT entrante . Cada regla NAT entrante especifica una dirección IP de
front-end, un puerto de front-end, un protocolo (TCP o UDP), un servidor de back-end y un
puerto de back-end. Una vez habilitado, el tráfico recibido por la IP de front-end en el
puerto de front-end designado se dirige al servidor de back-end y al puerto especificados.

Configuración del grupo de seguridad de red

El último paso en la configuración de Azure Load Balancer es garantizar que los grupos de
seguridad de red (NSG) estén configurados correctamente. Estos NSG se pueden asociar
con la subred que contiene las máquinas virtuales de back-end o con sus interfaces de red.
Se requieren dos reglas de seguridad entrante.

En primer lugar, una regla de entrada debe permitir el tráfico desde los usuarios finales a
los servidores back-end. Aunque el tráfico pasa a través del equilibrador de carga, esto no
cambia la IP de origen del tráfico entrante, por lo que la regla debe hacer referencia a la
dirección IP de origen y al rango de puertos del usuario final.

Una segunda regla entrante debe permitir el tráfico que se origina en la sonda de estado del
balanceador de carga. Las direcciones IP desde las que se originan las sondas de estado se
definen en la AzureLoadBalanceretiqueta de servicio, que debe usarse para definir el rango
de direcciones IP de origen para esta regla.

Nota Balanceador de carga y grupos de seguridad de red

Los balanceadores de carga de nivel estándar utilizan direcciones IP públicas de nivel

estándar, que están cerradas al tráfico entrante de forma predeterminada. Cuando se utiliza
un balanceador de carga de nivel estándar, el tráfico debe aprobarse mediante NSG. Por el
contrario, cuando se utilizan balanceadores de carga de nivel básico, el
tráfico debe aprobarse mediante NSG, pero también fluirá si no se utilizan NSG.
Configurar un equilibrador de carga de Azure

Como se analizó anteriormente, tanto los balanceadores de carga internos como los
públicos implican la configuración coordinada de varios grupos de configuraciones. Estas
configuraciones funcionan juntas para definir el comportamiento general del equilibrador
de carga.

Para usar Azure Load Balancer, el administrador primero debe aprovisionar el recurso, que
incluye la configuración de IP del front-end. Una vez completado este paso, puede crear el
grupo de back-end, las sondas de salud y, finalmente, la regla de equilibrio de carga.

Para crear el equilibrador de carga en Azure Portal, busque Load Balancer . En la hoja
Equilibradores de carga, haga clic en Crear. Esto abrirá la hoja Crear equilibrador de carga,
como se muestra en la Figura 4-54 . Complete los campos:
FIGURA 4-54 Creación de un equilibrador de carga público con Azure Portal

 Nombre Proporcione un nombre para el recurso del equilibrador de carga.

 SKU Seleccione el nivel de precios: Básico, Estándar o Gateway.
 Escriba Elija Público o Interno.
 Nivel Especifique si el equilibrador de carga es regional o global.
 Suscripción, grupo de recursos y ubicación Especifique según sea necesario.
Haga clic en Siguiente: Configuración de IP frontend. En esta pestaña, haga clic en Agregar
una configuración IP de frontend para configurar la dirección IP de frontend, dependiendo
de si el equilibrador de carga está configurado para ser un dispositivo público o interno.
Para balanceadores de carga públicos, cree y asocie la dirección IP pública aquí. Para los
balanceadores de carga internos, seleccione la red virtual y la subred donde colocar el
balanceador de carga. La Figura 4-55 muestra la configuración de IP de la interfaz pública
y la Figura 4-56 muestra la configuración de IP de la interfaz interna.

FIGURA 4-55 Configuración IP de la interfaz pública

FIGURA 4-56 Configuración IP de la interfaz interna

Haga clic en Siguiente: Grupos de backend. En la pestaña Grupos de backend, haga clic en
Agregar un grupo de backend. Un grupo de back-end es el objetivo del tráfico entrante. La
Figura 4-57 muestra la hoja Agregar grupo de backend utilizando una dirección IP para el
recurso de backend.
FIGURA 4-57 Direcciones IP del grupo de back-end

Después de configurar las pestañas Conceptos básicos, Configuración de IP frontend y

Grupo de backend, puede crear el equilibrador de carga. Opcionalmente, también puede
configurar reglas de entrada y salida durante la creación, pero también se pueden agregar
después de la implementación. Haga clic en Revisar + Crear y luego haga clic en Crear para
implementar el equilibrador de carga.

Para crear una sonda de estado, navegue hasta la hoja Load Balancer y elija Sondas de
salud, Agregar. Esto abre la hoja Agregar sonda de estado, como se muestra en la Figura 4-
58 . Especifique el nombre de la sonda de estado, junto con el protocolo, el puerto, el
intervalo de sonda y el umbral de errores de sonda consecutivos.
FIGURA 4-58 Creación de una sonda de estado en Azure Load Balancer

El último paso es configurar una regla de equilibrio de carga, que vincula la configuración
de IP del front-end con el grupo de back-end, especificando la sonda de estado y otras
configuraciones de equilibrio de carga. En la hoja Equilibrador de carga, elija Reglas de
equilibrio de carga, Agregar. Esto abre la hoja Agregar regla de equilibrio de carga, como
se muestra en la Figura 4-59 . Elija la configuración de IP de front-end, el grupo de back-
end y la sonda de estado seleccionada anteriormente. Para el tráfico HTTP, seleccione TCP
y especifique el puerto 80 tanto para el puerto frontend como para el backend. Seleccione
Ninguno para Persistencia de sesión y deje el valor de Tiempo de espera de inactividad
predeterminado de 4 minutos.
FIGURA 4-59 Creación de una regla de equilibrio de carga en Azure Load Balancer

Nota IP flotante

La última configuración, IP flotante (retorno directo al servidor), se recomienda solo

cuando se equilibra la carga del tráfico para un oyente del grupo de disponibilidad Always
On de SQL Server. Para otros escenarios, la configuración de IP flotante debe dejarse
desactivada.
El último paso es garantizar que los NSG estén configurados para permitir el tráfico
entrante y el tráfico de sondeo de estado. Una vez implementado esto, si las máquinas
virtuales agregadas al grupo de back-end están configuradas con un servidor web, debería
poder conectarse a la dirección IP pública del equilibrador de carga y ver la página web.

Solucionar problemas de equilibrio de carga

Los balanceadores de carga de nivel básico y estándar también admiten registros de

diagnóstico adicionales para permitir escenarios de solución de problemas comunes. Estos
registros son diferentes entre los niveles Básico y Estándar.

El equilibrador de carga de nivel básico no proporciona ninguna configuración de

diagnóstico para configurar. Si necesita capturar métricas relacionadas con un balanceador
de carga, debe usar un balanceador de carga de nivel Estándar. Las métricas disponibles
incluyen recuento de bytes, recuento de paquetes, estado de la sonda de salud, recuento
SYN (para nuevas conexiones) y más. Azure Monitor admite gráficos y alertas basados en
estas métricas. Además, se exponen como métricas multidimensionales , lo que significa
que se pueden crear gráficos y alertas utilizando vistas filtradas.

Para habilitar los registros del equilibrador de carga, abra la hoja Equilibrador de carga en
Azure Portal, haga clic en Registros de diagnóstico y haga clic en Agregar configuración de
diagnóstico para abrir la hoja Configuración de diagnóstico, como se muestra en la Figura
4-60 .
FIGURA 4-60 Configuración de registros de diagnóstico en un equilibrador de carga

Una vez que haya configurado los registros de diagnóstico, se pueden descargar para
analizarlos sin conexión o analizarlos mediante Log Analytics.

Resumen del capítulo

Este capítulo cubrió muchas de las funciones de red avanzadas disponibles en Azure. Estas
son algunas de las conclusiones clave de este capítulo:

 Las redes virtuales de Azure (VNet) son redes aisladas que utilizan un espacio de
direcciones IP privado.
 Las redes virtuales se dividen en subredes para que pueda aislar cargas de trabajo.
 Azure reserva las primeras cuatro y la última dirección IP de cada subred. Por lo
tanto, la primera dirección IP asignada a las máquinas virtuales suele ser la
dirección IP .4.
 Las direcciones IP privadas para una VM se asignan desde una subred y se
configuran como ajustes en la configuración IP de un recurso de interfaz de red.
 Una máquina virtual se puede asociar con una o más interfaces de red y cada
interfaz de red puede contener múltiples configuraciones de IP.
 Las direcciones IP privadas admiten dos métodos de asignación: dinámica o
estática. Las direcciones IP dinámicas se liberan cuando la VM se detiene (se
desasigna).
 Las direcciones IP públicas se administran como un recurso independiente, que se
puede asociar con una configuración IP de interfaz de red.
 Las direcciones IP públicas admiten dos niveles de precios (SKU). El nivel Básico
admite asignaciones dinámicas y estáticas y proporciona conectividad abierta (que
se puede restringir mediante NSG). El nivel Estándar admite implementaciones con
redundancia de zona, utiliza solo asignación estática y está cerrado de forma
predeterminada (el acceso se habilita mediante NSG).
 Las rutas definidas por el usuario (UDR) cambian el comportamiento
predeterminado de las subredes para que pueda dirigir el tráfico saliente a otras
ubicaciones. Normalmente, el tráfico se envía a través de un dispositivo virtual,
como un firewall.
 Si se utiliza una UDR para enviar tráfico a un dispositivo virtual, el reenvío de IP
debe estar habilitado en la NIC de la máquina virtual del dispositivo virtual.
 Enrutar el tráfico de Internet saliente a través de una conexión VPN a un dispositivo
de seguridad de red se conoce como túnel forzado.
 Se pueden revisar las rutas efectivas para cada interfaz de red para ayudar a
diagnosticar problemas de enrutamiento.
 Las VNet se pueden conectar mediante emparejamiento de VNet o conexiones VPN
de VNet a VNet.
 Para conectar dos redes virtuales, deben tener espacios de direcciones IP que no se
superpongan.
 Las redes virtuales se pueden conectar mediante el emparejamiento de VNet. Esto
se admite tanto dentro de una región como entre regiones.
 De forma predeterminada, las redes virtuales emparejadas aparecen y funcionan
como una única red. Existe una opción para limitar la conectividad, en cuyo caso se
deben usar reglas de NSG para definir las conexiones permitidas.
 El emparejamiento de VNet permite que las máquinas virtuales se vean entre sí
como una red, pero sus relaciones no son transitivas. Si VNetA y VNetB están
emparejados y VNetB y VNetC están emparejados, VNetA y VNetC no están
emparejados.
 Un enfoque común es utilizar una arquitectura de red radial, en la que cada
aplicación utiliza redes virtuales radiales separadas, emparejadas con una red virtual
central que contiene un dispositivo virtual de red (NVA). Las conexiones de
intercambio de tráfico deben habilitar Permitir tráfico reenviado.
 El uso del emparejamiento de VNet para proporcionar acceso a una VNet central
que contiene servicios compartidos, como controladores de dominio de Active
Directory, se conoce como encadenamiento de servicios.
 Azure DNS proporciona un servicio DNS autorizado para hospedar dominios
conectados a Internet.
 Las zonas DNS en Azure DNS se deben delegar desde el dominio principal. Para
ello, configure registros NS adecuados en el dominio principal, apuntando a los
servidores de nombres asignados por Azure DNS.
 Los registros DNS en Azure DNS se administran mediante conjuntos de registros,
que son la colección de registros con el mismo nombre y el mismo tipo.
 Los registros DNS en el vértice de la zona utilizan el nombre de registro @. No
puede crear registros con el tipo de registro CNAME en el vértice de la zona.
 Los registros de alias de Azure DNS permiten que los registros DNS hagan
referencia a otros recursos de Azure, como una dirección IP pública.
 Los archivos de zona DNS son un formato estándar que se utiliza para transferir
registros DNS entre sistemas DNS. Los archivos de zona DNS solo se pueden
importar o exportar desde Azure DNS mediante la CLI de Azure.
 El DNS proporcionado por Azure, también conocido como DNS interno,
proporciona búsquedas de DNS de máquina virtual a máquina virtual dentro de una
red virtual.
 Alternativamente, un cliente puede implementar sus propios servidores DNS, que se
pueden configurar en el nivel de VNet o de interfaz de red.
 Azure DNS también admite zonas DNS privadas, que también se pueden usar para
habilitar búsquedas de DNS de máquina virtual a máquina virtual.
 Los grupos de seguridad de red se utilizan para crear reglas de firewall para
controlar los flujos de red.
 Los NSG se pueden aplicar a nivel de subred o en interfaces de red de VM
individuales.
 Cada NSG incluye una lista de reglas predeterminadas, que se pueden anular
mediante reglas definidas por el usuario. Las reglas se aplican en orden de prioridad
(el procesamiento se detiene en la primera regla que coincida con el tráfico en
cuestión).
 Los rangos de direcciones IP de origen y destino en las reglas de NSG se pueden
especificar explícitamente mediante rangos CIDR.
 Los rangos de direcciones IP también se pueden especificar mediante etiquetas de
servicio que son accesos directos a la plataforma para los rangos de IP de los
servicios clave de Azure. Las etiquetas de servicio más utilizadas incluyen
VirtualNetwork, Internet, Azure Cloud, Storage y SQL.
 Los rangos de direcciones IP también se pueden especificar mediante grupos de
seguridad de aplicaciones (ASG). Al utilizar ASG, las reglas de NSG se definirán
para grupos de máquinas virtuales sin necesidad de asignar las máquinas virtuales
en subredes separadas.
 Las herramientas para ayudar a identificar las reglas de NSG requeridas incluyen el
mapa de servicios y los registros de flujo de NSG.
 Se pueden revisar reglas de seguridad efectivas para cada interfaz de red, de modo
que pueda ver los rangos de IP exactos utilizados por cada etiqueta de servicio y
ASG.
 El servicio Azure Bastion se aprovisiona dentro de una red virtual dentro de una
subred independiente denominada AzureBastionSubnet. Si tiene varias redes
virtuales en su entorno, deberá implementar Azure Bastion para cada red virtual por
separado.
 Azure Load Balancer (ALB) es un servicio de equilibrio de carga de alto
rendimiento y totalmente administrado para el tráfico TCP y UDP. Opera en la capa
de transporte (OSI Layer 4). A diferencia de App Gateway, no tiene visibilidad del
tráfico a nivel de aplicación.
 ALB se puede implementar con una dirección IP de interfaz pública (Internet) o
privada (intranet).
  ALB viene en dos niveles de precios (SKU): Básico o Estándar. El nivel Estándar
admite zonas de disponibilidad, grupos de back-end más grandes y flexibles y una
serie de otras características. El nivel Básico es gratuito.
 Una configuración de equilibrio de carga de ALB comprende la configuración de IP
de front-end, el grupo de back-end, las sondas de estado y la regla de equilibrio de
carga.
 ALB también admite el reenvío de puertos mediante reglas NAT entrantes. Esto
asigna un puerto de front-end específico a un puerto de back-end específico en un
servidor de back-end específico.
 Utilice la solución de problemas de conexión para probar la conectividad entre dos
máquinas virtuales de Azure o entre una máquina virtual y un punto de conexión
externo arbitrario.
 Connection Monitor permite la supervisión de la conexión a largo plazo mediante
diagnósticos similares a los utilizados por Connection Troubleshoot.

Experimento mental

En este experimento mental, aplique lo que ha aprendido sobre este objetivo. Puede
encontrar respuestas a estas preguntas en la siguiente sección.

Su empresa, Contoso, quiere actualizar y migrar una aplicación de recursos humanos

existente a Azure. La arquitectura de la aplicación consta de dos servidores web y un nivel
de base de datos implementado mediante tres servidores en un grupo de disponibilidad
permanente de SQL Server. La aplicación web utiliza un estado de sesión en memoria que
requiere que cada usuario sea enrutado consistentemente a la misma instancia del servidor
web. La aplicación debe ser accesible únicamente desde la intranet de la empresa y no
expuesta a Internet.

Además, Contoso ya ha migrado varias otras aplicaciones a Azure. Sin embargo, una
revisión financiera reciente destacó el aumento del gasto en Azure y su gerente identificó la
duplicación de componentes de infraestructura (como máquinas virtuales de controlador de
dominio) en cada aplicación migrada como un área potencial donde se pueden lograr
ahorros.Cada una de estas aplicaciones es administrada por un equipo independiente y el
equipo debe tener acceso administrativo únicamente a su aplicación.

1. ¿Cómo se debe equilibrar la carga del nivel de la base de datos?

2. ¿Cómo se puede restringir el tráfico de red entre niveles de aplicaciones y evitar que
los usos locales tengan acceso directo al nivel de base de datos?
3. ¿Cómo se debe integrar la aplicación en la intranet de la empresa, evitando exponer
un punto final de Internet?
4. ¿Cómo se pueden reducir los costos consolidando componentes duplicados?
5. ¿Cómo mantiene su diseño la separación administrativa entre aplicaciones?

Respuestas del experimento mental

Esta sección contiene la solución al experimento mental del capítulo.

 1. El nivel de la base de datos debe tener equilibrio de carga mediante Azure Load
Balancer. El equilibrador de carga se configurará únicamente con una dirección IP
interna (intranet). Debido a que el equilibrador de carga se utiliza como escucha de
grupo de disponibilidad siempre activo de SQL Server, la opción IP flotante
(retorno directo al servidor) debe estar habilitada.
2. Se deben utilizar grupos de seguridad de red para restringir el tráfico entrante y
saliente para las subredes utilizadas por cada nivel de aplicación. Opcionalmente, se
pueden utilizar grupos de seguridad de aplicaciones para simplificar la
administración de direcciones IP y reducir la cantidad de subredes y NSG
necesarios.
3. La conectividad entre la aplicación y la red local se puede lograr de dos maneras. La
opción más sencilla es establecer una VPN de sitio a sitio entre la red local y la red
virtual de Azure. Esto crea un túnel cifrado (a través de Internet) que une las dos
redes. Se requiere un dispositivo VPN local compatible con una dirección IPv4
estática con acceso a Internet, junto con una puerta de enlace VPN en Azure
(alojada en una subred de puerta de enlace dedicada). Como alternativa, se puede
utilizar una conexión ExpressRoute. Esto proporciona una conexión más confiable y
consistente a través de una conexión dedicada de un proveedor de conectividad. En
este caso, se usa una puerta de enlace ExpressRoute para conectar el circuito
ExpressRoute a la red virtual de Azure.
4. Se debe crear una VNet dedicada para contener servicios comunes (como servidores
Active Directory), que son consumidos por múltiples aplicaciones. Cada aplicación
debe permanecer en su propia VNet, que solo debe contener componentes
específicos de la aplicación. Las redes virtuales de aplicaciones se deben emparejar
con la red virtual de servicios compartidos, en una configuración radial (con la red
virtual de servicios compartidos como centro). Este emparejamiento dará a las
aplicaciones acceso de red a los componentes compartidos.
5. Dado que cada aplicación conserva su propia VNet que contiene todos los
componentes específicos de la aplicación, los propietarios de la aplicación no
pierden aislamiento ni control. Estos componentes de la aplicación pueden incluso
implementarse en suscripciones separadas, lo que simplifica el acceso y la
facturación separados según roles. El emparejamiento de redes virtuales de
Resource Manager se admite a través de límites de suscripción.

Capítulo 5
Supervisar y realizar copias de seguridad de los recursos de Azure

Cuando comience a implementar servicios en sus suscripciones de Azure, deberá decidir

cómo se supervisará el entorno. Para hacerlo, debe pensar en todos los servicios de su
implementación. Lo más probable es que tenga implementados varios servicios, incluidos
servicios de infraestructura como servicio (por ejemplo, máquinas virtuales), que incluyen
computación, almacenamiento y redes. E incluso sin los servicios implementados hoy, con
el tiempo, es posible que tenga servicios de plataforma como servicio para alojar
aplicaciones. También utilizará los servicios que impulsan sus máquinas virtuales de
maneras más significativas, como la implementación de configuraciones avanzadas en
Azure Storage y Azure Identity.
Deberá tener en cuenta todos estos servicios (junto con la propia plataforma Azure) en su
estrategia de monitoreo. Esto incluye toda su infraestructura, aplicaciones y redes.

Al desarrollar una estrategia de monitoreo proactivo, podrá comprender el funcionamiento

de su entorno a nivel de componente, incluido el estado y el gasto de los recursos.
Implementar una estrategia sólida lo ayudará a aumentar su tiempo de actividad a través de
notificaciones proactivas, para que pueda resolver problemas antes de que se conviertan en
problemas y optimizar sus recursos para un rendimiento óptimo, aumentando su retorno de
la inversión con los servicios que implemente.

A medida que desarrolla su estrategia, hay tres áreas que debe considerar:

 Visibilidad de los servicios y la plataforma Azure Se trata de comprender cómo

se está desempeñando una aplicación o un conjunto de servicios en todos los
ámbitos. Deberá comprender qué métricas necesita monitorear y cómo se puede
actuar en consecuencia en Azure a través de alertas y visualizaciones en paneles.
 Conocimientos más profundos sobre las aplicaciones. Esto es particularmente
cierto con los mapas de servicios o dependencias y el seguimiento avanzado.
Incluso puede utilizar estos conocimientos para impulsar la automatización y las
correcciones dentro de sus entornos.
 Optimización de recursos Debe comprender qué métricas son importantes no solo
para el estado de sus aplicaciones, sino también para los efectos en los usuarios o
sistemas que consumen esas aplicaciones. Al utilizar la visibilidad y la información
que extrae de la plataforma Azure, puede correlacionar directamente los efectos de
las correcciones en su entorno.

Azure incluye varios servicios que desempeñan funciones específicas de supervisión y

optimización. Es fundamental que comprenda tanto las capacidades de supervisión listas
para usar de Azure como las capacidades de supervisión específicas del escenario dentro de
la plataforma. Esta sección se centrará en la supervisión y optimización listas para usar a
través de Azure Monitor, así comocomo supervisión específica del escenario con registros
de Azure Monitor y datos de registro almacenados en Log Analytics.

Azure Backup es otro servicio crítico que permite una recuperación ante desastres
simplificada para máquinas virtuales al garantizar que los datos estén respaldados de forma
segura y fácilmente restaurables. En este capítulo, también revisará cómo implementar y
administrar soluciones de respaldo y recuperación de Azure con énfasis en Azure Backup
Service y Azure Site Recovery.

Habilidades cubiertas en este capítulo:

 Habilidad 5.1: Monitorear recursos en Azure

 Habilidad 5.2: Implementar respaldo y recuperación
Habilidad 5.1: Monitorear recursos en Azure

Azure Monitor maximiza la disponibilidad y el rendimiento de sus aplicaciones al ofrecer

una solución integral para recopilar, analizar y actuar en función de la telemetría desde sus
entornos locales y en la nube. Le ayuda a comprender el rendimiento de sus aplicaciones e
identifica de forma proactiva los problemas que las afectan y los recursos de los que
dependen. La página de inicio de Azure Monitor proporciona un punto de partida para
configurar otros servicios de supervisión más específicos, como Application Insights,
Network Watcher, Log Analytics, Management Solutions, etc. La Figura 5-1 muestra
algunas de las diversas fuentes de datos y cómo se recopilan, ya sea como datos métricos o
de registro. Varios servicios de Azure consumen, visualizan o actúan sobre los datos.

FIGURA 5-1 Orígenes de datos de Azure Monitor para datos de registros y métricas y las
formas en que puede actuar sobre los datos

¿Necesita más revisión? monitor azul

Para obtener más información sobre las capacidades de Azure Monitor,

consulte https://learn.microsoft.com/en-us/azure/azure-monitor/overview .

¿Necesita más revisión? Servicio administrado de Azure Monitor para Prometheus

El servicio administrado de Azure Monitor para Prometheus proporciona capacidades para

monitorear sus entornos de contenedores. Puede obtener más información sobre las nuevas
capacidades en https://learn.microsoft.com/en-us/azure/azure-
monitor/containers/container-insights-overview .

¿Necesita más revisión? Azure Monitor para máquinas virtuales

Azure Monitor para VM proporciona capacidades para monitorear sus máquinas virtuales y
conjuntos de escalado de máquinas virtuales. Puede obtener más información sobre las
nuevas capacidades en https://learn.microsoft.com/en-us/azure/azure-
monitor/vm/vminsights-overview .

Azure Monitor le ayuda a realizar un seguimiento del rendimiento, mantener la seguridad e

identificar tendencias mediante la ingesta de métricas y telemetría de múltiples áreas,
incluidas las aplicaciones y los sistemas operativos de las máquinas virtuales. También
puede consultar sus recursos de Azure (que emiten contadores de rendimiento), sus
suscripciones de Azure, el inquilino de Entra y los orígenes personalizados de eventos.

Los datos de sus recursos de Azure se incorporan a métricas almacenadas en la plataforma

de Azure y a las que puede acceder el servicio de monitor, o como registros en un área de
trabajo de Log Analytics en su suscripción de Azure.

Análisis de registros importantes

Log Analytics debe habilitarse y configurarse antes de poder extraer información o crear
visualizaciones que dependan de esos datos.

La comparación de métricas y registros muestra algunos diferenciadores clave:

 Retención La mayoría de las métricas se conservan durante 93 días dentro del

servicio de Azure, mientras que los registros almacenados en Log Analytics se
pueden conservar hasta por dos años. Sin embargo, las consultas de métricas solo
pueden abarcar hasta 30 días. También existen oportunidades para conservar
métricas a largo plazo almacenándolas en Log Analytics.
 Propiedades Las métricas tienen un conjunto fijo de propiedades (o atributos).
Estos son tiempo, tipo, recurso, valor y dimensiones (opcional). Los registros tienen
diferentes propiedades para cada tipo de registro e incluso admiten tipos de datos
enriquecidos, como fecha y hora.
 Las métricas de disponibilidad de datos se recopilan a lo largo del tiempo (como
una vez por minuto) y están disponibles para consulta inmediata. Los registros a
menudo se recopilan después de haber sido activados por un evento (como cuando
un evento se escribe en un registro de aplicación) y su procesamiento puede tomar
algún tiempo antes de que estén disponibles para su consulta. Si bien ambos ofrecen
capacidades de consulta casi en tiempo real, las métricas generalmente se usarán
para alertas rápidas y los registros para análisis más complejos.

Una vez que se recopilan los datos, Azure Monitor proporciona "un panel único" o punto de
entrada para interactuar con sus métricas y registros. Las interacciones pueden incluir
consultas y alertas, creación de visualizaciones y paneles, o incluso respuestas
automatizadas basadas en telemetría para funcionalidad, como el escalado automático en
máquinas virtuales.

Los datos almacenados en Log Analytics también se pueden consultar directamente a través
de un área de trabajo de Log Analytics, donde tendrá acceso a las mismas interfaces de
consulta que a través de Azure Monitor, pero también podrá realizar personalizaciones en la
configuración del área de trabajo y acceder a espacios de trabajo específicos. soluciones,
incluidas visualizaciones y consultas.

Todos los datos a los que puede acceder a través de Azure Monitor se pueden usar para
crear alertas dentro de Azure Monitor con reglas de alerta. Las reglas de alerta se crean en
función de los recursos o tipos de recursos de destino, como máquinas virtuales, cuentas de
almacenamiento e incluso servicios PaaS y sus condiciones personalizadas. Las alertas le
notifican de forma proactiva sobre el estado de los recursos que implementa en Azure. No
está limitado a notificaciones; Las reglas de alerta aprovechan los grupos de acciones para
que pueda incluso implementar la automatización basada en una condición de alerta.

Esta habilidad cubre cómo:

 Interpretar métricas en Azure Monitor

 Configurar los ajustes de registro en Azure Monitor
 Consultar y analizar registros en Azure Monitor
 Configurar reglas de alerta, grupos de acciones y reglas de procesamiento de alertas
en Azure Monitor
 Configurar información sobre aplicaciones
 Configure e interprete la supervisión de máquinas virtuales, cuentas de
almacenamiento y redes mediante Azure Monitor Insights.
 Utilice Azure Network Watcher y Connection Monitor

Interpretar métricas en Azure Monitor

Recuerde que las métricas son los valores numéricos que generan los recursos y servicios
dentro de Azure. Las métricas están disponibles para varios recursos de Azure, pero no
todos los recursos admiten métricas en este momento.

Las métricas incluyen métricas de plataforma, que son creadas por recursos de Azure y
están disponibles en Azure Monitor para consultas y alertas. También puede consultar las
métricas de la aplicación desde Application Insights si el servicio está habilitado y ha
instrumentado sus aplicaciones, independientemente de si esa aplicación está alojada en una
máquina virtual o incluso en un servicio PaaS, como Azure App Service. Cuando utiliza un
servicio PaaS como App Service, puede recuperar algunos datos sin instrumentación
adicional. Las máquinas virtuales en Azure también pueden enviar métricas personalizadas
al servicio de monitorización mediante la extensión de diagnóstico de Windows en
servidores Windows y con el agente InfluxData Telegraf en máquinas virtuales Linux.
También existe la oportunidad de impulsar métricas personalizadas de otras fuentes a través
de una API REST.

La Figura 5-2 muestra un ejemplo de un gráfico de métricas que muestra la latencia de un

extremo a otro para una cuenta de almacenamiento.
FIGURA 5-2 Métricas de Azure

Valores numéricos importantes en Azure

Esta sección solo hace referencia a los valores numéricos que generan los recursos en
Azure, no a los registros ni a los valores basados en texto, como el valor de un registro de
eventos que se puede almacenar en una cuenta de almacenamiento o en un área de trabajo
de Log Analytics.

Las métricas de Azure se recopilan a intervalos de un minuto (a menos que se especifique

lo contrario) y se identifican mediante un nombre de métrica y un espacio de nombres (o
categoría). La mayoría de las métricas de Azure se conservan durante 93 días en Azure
Monitor, pero existen excepciones notables que se enumeran a continuación:

Métricas del sistema operativo invitado

 Métricas clásicas del sistema operativo invitado

 Recopilado a través de extensiones de diagnóstico y enviado a una cuenta de
almacenamiento de Azure.
  Plazo de conservación de 14 días.
 Métricas del sistema operativo invitado enviadas a métricas de Azure Monitor
 Supervisado por extensiones de diagnóstico de Windows o el agente
InfluxData Telegraf y enrutado a un receptor de datos de Azure Monitor.
 Plazo de conservación de 93 días.
 Métricas del sistema operativo invitado recopiladas por el agente de Log Analytics
 Recopilado por el agente de Log Analytics y enviado a un área de trabajo de
Log Analytics.
 Plazo de conservación de 31 días. Este período de conservación podrá
ampliarse hasta dos años.
 Métricas basadas en registros de información de aplicaciones
 Las métricas basadas en registros se traducen en consultas de registros.
 Plazo de conservación de 90 días.

Consejo de examen

Para una retención a más largo plazo, opcionalmente se pueden enviar métricas a Azure
Storage para recursos seleccionados y retenerlas hasta la política de retención configurada o
los límites de almacenamiento de la cuenta. También se pueden enviar a Log Analytics con
un período de retención predeterminado de 31 días.

A medida que se recopilan métricas, cada métrica tiene las siguientes propiedades:

 La hora en que se recopiló el valor.

 El tipo de medida que representa el valor.
 El recurso con el que está asociado el valor.
 El valor en si

Las métricas pueden ser unidimensionales o multidimensionales con hasta 10 dimensiones.

Se puede considerar una métrica adimensional como el nombre de la métrica, y el servicio
Monitor recopila el valor de la salida de la métrica a lo largo del tiempo. Una métrica
multidimensional (tanto de un recurso de Azure como de una métrica personalizada)
incluye el nombre de la métrica y un par de nombre-valor adicional con datos adicionales.
Por ejemplo, imagine una cuenta de almacenamiento con varios contenedores de blobs
donde necesita realizar un seguimiento del consumo de almacenamiento por contenedor.
Una métrica no dimensional proporcionaría solo el almacenamiento consumido total para el
punto de conexión del blob en la cuenta de almacenamiento, mientras que una métrica
multidimensional proporcionaría el consumo por contenedor, ya que tiene los datos
adicionales almacenados en el registro de métrica.

Para interactuar con métricas desde Azure Portal, busque Monitor . Luego, en la hoja
Monitor, haga clic en Métricas para abrir la hoja Métricas. Se le presentará un gráfico en
blanco. Puede seleccionar el alcance y las métricas requeridas para personalizar el gráfico
de métricas según sea necesario, como se muestra en la Figura 5-3 .
FIGURA 5-3 Métricas de Azure Seleccione una hoja de ámbito

Para comenzar a completar el gráfico, debe seleccionar una métrica. Para seleccionar una
métrica, debe seleccionar una suscripción y un grupo de recursos. Opcionalmente, también
puede filtrar por tipo de recurso. Cuando selecciona un recurso, puede seleccionar un
espacio de nombres (o categoría) de métrica, una métrica y una agregación, si corresponde.
Por ejemplo, para ver la métrica de ingreso para una cuenta de almacenamiento, seleccione
la cuenta de almacenamiento en el menú desplegable Alcance, elija Cuenta en el menú
desplegable Espacio de nombres de métrica, elija Ingreso en el menú desplegable Métrica y
elija Suma de el menú desplegable Agregación, como se muestra en la Figura 5-4 .
FIGURA 5-4 Selección de métricas de Azure

Puede agregar varias métricas al gráfico e incluso puede combinar recursos, espacios de
nombres, métricas y agregaciones, como se muestra en la Figura 5-5 .

FIGURA 5-5 Selección de múltiples métricas de Azure para un recurso

El gráfico se representará a medida que complete cada selección de recursos. El período de

la consulta se puede cambiar hasta los límites de retención del servicio de métricas y el
gráfico se puede representar como un gráfico de líneas (predeterminado), un gráfico de
áreas, un gráfico de barras, un gráfico de dispersión o una cuadrícula. En la Figura 5-6 se
muestra un ejemplo de un gráfico de líneas .
FIGURA 5-6 Gráfico de líneas de métricas de Azure

Tenga en cuenta que no está limitado a registrar recursos de la misma suscripción. Puede
seleccionar métricas para recursos de cualquier tipo disponible en todas las suscripciones a
las que tiene acceso.

Desde la hoja Métricas, también puede crear una nueva regla de alerta basada en la consulta
de métrica que se visualiza. Si necesita realizar un análisis más profundo, puede exportar
los datos métricos sin procesar a Excel.

Nota Paneles de Azure

Cada gráfico o visualización que cree en Azure Monitor también se puede anclar a un panel
de Azure. Puede tener varios paneles en Azure e incluso puede compartir un panel con otras
personas de su organización.
Tampoco está limitado a crear un solo gráfico. Haga clic en Agregar gráfico en el
Explorador de métricas para apilar varios gráficos, de modo que los gráficos existentes se
puedan clonar y luego personalizar.

Nota Métricas y tiempos de respuesta visual

Si está evaluando una aplicación web, es posible que desee utilizar varios gráficos para los
tiempos de respuesta de visualización (en milisegundos) y el tamaño de la respuesta (en
kilobytes). Esto es especialmente útil cuando trabaja con métricas que tienen diferentes
unidades de medida o cuando la escala de las métricas que está evaluando varía
ampliamente.

Configurar los ajustes de registro en Azure Monitor

Log Analytics le ayuda a recopilar, correlacionar, buscar y actuar sobre los datos de registro
y rendimiento generados por sistemas operativos, aplicaciones y servicios de Azure. Le
brinda información operativa mediante búsquedas y visualizaciones enriquecidas. Log
Analytics proporciona un único panel para interactuar con los datos de toda la plataforma y
las cargas de trabajo que aloja en ella, incluidos los servidores Linux y Windows. Además,
Log Analytics se puede utilizar con otros proveedores de nube.

Los registros se recopilan y agregan en un área de trabajo de Log Analytics. Los registros
también se pueden consultar y visualizar a través de Log Analytics o Azure Monitor. Un
espacio de trabajo es un recurso de Azure, lo que significa que RBAC se puede aplicar para
obtener acceso granular al servicio y a los datos almacenados en él. Esto también significa
que los espacios de trabajo pueden estar en regiones que cumplan con los requisitos
normativos, el aislamiento de datos y el alcance de su organización. Puede crear múltiples
espacios de trabajo en una sola suscripción.

Implementar el espacio de trabajo de Log Analytics

Puede crear un área de trabajo a través de Azure Portal, Azure PowerShell, la CLI de Azure
y plantillas ARM. Para crear un área de trabajo a través de Azure Portal, busque el área de
trabajo de Log Analytics . Haga clic en Crear para abrir la hoja Crear área de trabajo de
Log Analytics.

Para configurar un espacio de trabajo, deberá proporcionar lo siguiente (consulte la Figura

5-7 ):
FIGURA 5-7 Configuración del área de trabajo de Log Analytics

 Un nombre para el espacio de trabajo.

 La suscripción a la que estará asociado el espacio de trabajo
 Un grupo de recursos
 Una localización

Nota Precios de Log Analytics

Los detalles sobre los precios de Log Analytics se pueden encontrar

en https://azure.microsoft.com/pricing/details/monitor/ . Esta página también incluye los
detalles de precios de otros servicios relacionados con Azure Monitor, como Application
Insights y Alert Rules.

Tenga en cuenta que Log Analytics no está disponible en todas las regiones. Para
seleccionar una región adecuada, consulte la documentación de Productos de Azure por
región en https://azure.microsoft.com/global-infrastructure/services/ .

Para seleccionar el nivel de precios adecuado, revise la documentación de precios

en https://azure.microsoft.com/pricing/details/monitor/ . Un nuevo espacio de trabajo
tendrá de forma predeterminada el nivel gratuito, que incluye 5 GB de almacenamiento de
registros por mes (31 días) con precios por GB y cargos por GB para almacenamiento y
retención adicionales.

Después de aprovisionar un espacio de trabajo, debe habilitar la recopilación de datos y

configurar los registros de recursos y de inquilinos para almacenar sus registros dentro del
servicio.

Para recopilar datos de eventos y rendimiento de máquinas Windows y Linux, abra el

espacio de trabajo y configure los agentes y las reglas de recopilación de datos, como se
muestra en la Figura 5-8 . En la hoja Agentes, puede obtener el ID del espacio de trabajo, la
clave principal y la clave secundaria para asociar máquinas con el servicio a través del
agente de supervisión. Puede utilizar esta información al incorporar clientes manualmente
al espacio de trabajo.
FIGURA 5-8 Agentes del área de trabajo de Log Analytics

Haga clic en Reglas de recopilación de datos para configurar los registros de eventos de
Windows, los contadores de rendimiento de Windows, los contadores de rendimiento de
Linux, Syslog, los registros de IIS, los campos personalizados y los registros
personalizados. Para crear una nueva regla de recopilación de datos, haga clic en Crear. La
pestaña Conceptos básicos de la hoja Crear regla de recopilación de datos incluye los
siguientes campos, como se muestra en la Figura 5-9 :
FIGURA 5-9 Pestaña Conceptos básicos en la hoja Crear regla de recopilación de datos

 Nombre de regla El nombre para mostrar de la regla.

 Suscripción La suscripción de Azure para crear la regla en
 Grupo de recursos El grupo lógico del recurso.
 Región La región en la que se crea la regla.
 Tipo de plataforma Si la regla es compatible con Windows, Linux o todas las
plataformas

Haga clic en Siguiente: Recursos para pasar a la pestaña Recursos. Esta pestaña es donde
define las máquinas virtuales de origen de las que recopilar registros y métricas. Para
máquinas virtuales de Azure, conjuntos de escalado y máquinas habilitadas para Arc que
puedan estar ejecutándose en otro lugar, el Agente de Azure Monitor se instalará en la
máquina virtual. Para máquinas virtuales o máquinas cliente no conectadas, el cliente del
Agente de Azure Monitor deberá estar instalado en las máquinas virtuales de destino.
En la pestaña Recursos, haga clic en Agregar recursos. Coloque una marca de verificación
junto a las máquinas virtuales para las que desea habilitar la recopilación de datos y luego
haga clic en Aplicar, como se muestra en la Figura 5-10 .

FIGURA 5-10 Agregar recursos

Haga clic en Siguiente: Recoger y entregar para pasar a la pestaña Recoger y entregar. En
esta pestaña, configure las fuentes de datos a recopilar. Las opciones disponibles aquí
dependen del tipo de plataforma que se seleccionó en la pestaña Básicos. Haga clic en
Agregar origen de datos para agregar un origen y un destino para la regla, como se muestra
en la Figura 5-11 .
FIGURA 5-11 Agregar una fuente de datos

Haga clic en la pestaña Destino. De forma predeterminada, las métricas o registros

seleccionados se enviarán a los registros de Azure Monitor. Verifique que los datos se
envíen al área de trabajo de Log Analytics que creó, como se muestra en la Figura 5-12 .
FIGURA 5-12 Agregar un destino de fuente de datos

Haga clic en Agregar fuente de datos y luego complete la hoja Crear regla de recopilación
de datos para crear la regla.

Para que el agente envíe telemetría, también debe asegurarse de que los puertos requeridos
estén disponibles y que los URI requeridos estén en la lista blanca. El agente utiliza el
puerto 443 para todas las comunicaciones salientes. Los URI necesarios para
implementaciones típicas de Azure se muestran en la Tabla 5-1 . Los despliegues en nubes
soberanas y gubernamentales requerirán cambios adicionales.

TABLA 5-1 Puertos y protocolos del agente de Azure Monitor

Omitir la
Recurso del agente Puertos Dirección inspección
HTTPS

global.handler.control.monitor.azure.com Puerto saliente Sí

443
 Omitir la
Recurso del agente Puertos Dirección inspección
HTTPS

<nombre-región-máquina- Puerto saliente Sí

virtual> .handler.control.monitor.azure.com 443

<log-analytics-workspace- Puerto saliente Sí

id> .ods.opinsights.azure.com 443

administración.azure.com Puerto saliente Sí

443

<nombre-región-máquina- Puerto saliente Sí

virtual> .monitoring.azure.com 443

Configurar ajustes de diagnóstico

Si bien los recursos que implementa en Azure crean métricas automáticamente, muchos de
ellos también ofrecen registros de diagnóstico más completos, que se pueden configurar
para enviar sus datos de registro a otra ubicación, como una cuenta de almacenamiento o un
área de trabajo de Log Analytics. Además de los registros de recursos, también existen
servicios a nivel de inquilino, como Microsoft Entra ID, que existen fuera de una
suscripción de la que es posible que necesite recopilar datos de registro.

Los registros de diagnóstico son un tipo de datos de registro. También hay datos de registro
dentro del registro de actividad de Azure y hay datos de registro que se pueden obtener de
máquinas virtuales con el uso de agentes de diagnóstico que son independientes de los
registros de diagnóstico asociados con un servicio de nivel de inquilino o un recurso de
Azure. Es importante comprender las diferencias entre los tipos de datos de registro que
están disponibles y dónde se pueden almacenar esos datos de registro.

Los registros importantes de recursos e inquilinos son registros de diagnóstico

Tanto los registros de recursos como los registros de inquilinos se consideran registros de
diagnóstico. Los registros de diagnóstico que configura para un servicio de inquilino o un
recurso son independientes del registro de actividad de Azure y la telemetría de invitados
obtenidos con agentes de diagnóstico.

El registro de actividad de Azure muestra datos en el nivel de suscripción y puede ser útil
para comprender las acciones que ocurren dentro de su entorno en relación con las API de
ARM. Por ejemplo, cuando se envía una nueva implementación, los eventos asociados con
esa implementación (como la hora en que se envió, los recursos que se crearon y el usuario
que envió la solicitud) se rastrean en el registro de actividad. Sin embargo, en el nivel de
suscripción, te falta algunaregistros a nivel de recursos. Por ejemplo, el registro de
actividad puede mostrar cuándo se creó un grupo de seguridad de red (o NSG), pero no
puede mostrar cuándo se aplicó una regla de NSG al tráfico sujeto al NSG, como cuando se
bloquea un puerto o protocolo. Los registros de diagnóstico proporcionan esta
funcionalidad.

Nota Eventos retenidos durante 90 días

Los eventos en el registro de actividad se conservan durante 90 días. Puede conservar los
datos durante un período más largo enviando los registros a Azure Storage o a un área de
trabajo de Log Analytics.

Será necesario habilitar los registros de diagnóstico para cada recurso del que desee
recopilar telemetría adicional. Tenga en cuenta que las métricas son específicas de los
recursos y se capturan automáticamente, por lo que solo necesita habilitar los registros de
diagnóstico para capturar datos de registro o enviar métricas a otro servicio.

Soporte importante para registros de diagnóstico

No todos los tipos de recursos de Azure admiten registros de diagnóstico. Puede encontrar
una lista completa de servicios que admiten registros y sus esquemas de registro específicos
del servicio en https://learn.microsoft.com/azure/azure-monitor/essentials/resource-logs-
schema .

Para habilitar los registros de diagnóstico a través de Azure Portal, puede buscar el recurso
para crear la configuración. El método alternativo y recomendado es buscar la hoja
Configuración de diagnóstico de Azure Monitor. Desde esta hoja, puede ver todos los tipos
de recursos elegibles para registros de diagnóstico y ver el estado (habilitado o
deshabilitado) para la recopilación de registros en cada recurso. Además, puede filtrar por
suscripción, grupo de recursos, tipo de recurso y recurso. En la Figura 5-13 se muestra un
ejemplo .
FIGURA 5-13 Configuración de diagnóstico de Azure Monitor

Para habilitar la configuración de diagnóstico, haga clic en un recurso con el estado

Desactivado. En la hoja Configuración de diagnóstico, haga clic en Agregar configuración
de diagnóstico. Especifique el nombre de la configuración de diagnóstico y seleccione los
registros requeridos, como se muestra en la Figura 5-14 .
FIGURA 5-14 Configuración de diagnóstico de Azure Monitor para un recurso

Nota Registros de diagnóstico

Cada recurso o servicio de inquilino para el que habilita los registros de diagnóstico tiene
diferentes controles (o configuraciones). Por ejemplo, no todos los recursos admiten una
política de retención en la configuración de diagnóstico y no todos los recursos admiten el
envío de datos de métricas a otra ubicación.

Al configurar los ajustes de diagnóstico, usted selecciona dónde se envían los registros (y
opcionalmente las métricas). Puede elegir entre estas ubicaciones válidas para enviar datos:
Archivar en una cuenta de almacenamiento, Transmitir a un centro de eventos o Enviar a
Log Analytics (consulte la Figura 5-14 ). A medida que seleccione cada ubicación, se
requerirá configuración adicional. Por ejemplo, para archivar en una cuenta de
almacenamiento, deberá seleccionar una cuenta de almacenamiento existente o crear una
nueva cuenta de almacenamiento.

Para los registros de diagnóstico que admiten la retención con almacenamiento, puede
seleccionar un período de retención en días. Un período de retención de cero días significa
que los registros se conservarán para siempre. Cualquier número entre 1 y 365 es válido
para el número de días. Si establece el período de retención y solo seleccionó un centro de
eventos o un área de trabajo de Log Analytics (pero no seleccionó una cuenta de
almacenamiento), se ignorará la configuración de retención.

A medida que configura cada recurso o servicio, puede enviar los datos desde múltiples
fuentes de registro al mismo destino. Por ejemplo, puede enviar los registros de diagnóstico
desde un servicio de inquilino como Microsoft Entra ID a un área de trabajo de Log
Analytics y puede enviar los registros de diagnóstico desde un recurso como un grupo de
seguridad de red al mismo espacio de trabajo de Log Analytics.

La configuración puede tardar varios minutos en aparecer en la lista de configuraciones del

recurso. Tenga en cuenta que aunque se haya configurado la configuración, los datos de
diagnóstico no se recopilarán hasta que se genere un nuevo evento.

Todas estas configuraciones se pueden configurar a través de Azure Portal, Azure

PowerShell, la CLI de Azure o mediante la API REST de Azure Monitor.

Consejo de examen

La extensión de Azure Diagnostics también se puede configurar a través de plantillas de

administrador de recursos y herramientas de línea de comandos especificando un archivo de
configuración. Para el examen, debe conocer el esquema de esta configuración y cómo
aplicarla utilizando herramientas automatizadas. Puede obtener más información sobre el
esquema de Azure Diagnostics en https://learn.microsoft.com/azure/azure-
monitor/agents/diagnostics-extension-versions .

Consultar y analizar registros en Azure Monitor

Como se mencionó anteriormente, Azure Monitor almacena y muestra dos tipos de datos:
métricas y registros. Las métricas son valores numéricos, como contadores de rendimiento,
mientras que los registros pueden ser datos numéricos o texto. Por ejemplo, el texto
completo de una excepción que se genera en una aplicación o incluso el texto de un registro
de aplicación desde un servidor Windows o Linux es un ejemplo.

Crear una consulta

Una vez que se haya configurado el espacio de trabajo y se hayan incorporado los registros
de inquilinos, los registros de recursos y las máquinas, puede comenzar a analizar y
visualizar datos. Para interactuar con los datos en Log Analytics, se utilizan consultas de
registro, que se utilizan para

 Realizar análisis interactivos de datos de registro a través de Azure Portal en Azure

Monitor y un área de trabajo de Log Analytics.
 Cree reglas de alerta personalizadas basadas en los registros de un espacio de
trabajo
  Genere visualizaciones que se puedan compartir a través de paneles de Azure.
 Exporte conjuntos de datos personalizados a Excel o Power BI
 Realice una automatización basada en datos de registro con PowerShell o la CLI de
Azure

¿Necesita más revisión? Uso de consultas de registro

Para obtener más información sobre todas las formas en que se pueden utilizar las consultas
de registro, consulte la documentación en https://learn.microsoft.com/azure/azure-
monitor/logs/log-query-overview#where-log-queries-are -usado .

El lenguaje de consulta utilizado por Log Analytics se llama Kusto Query Language
(KQL). Las consultas KQL se utilizan para generar solicitudes de solo lectura para procesar
datos y devolver resultados. Esto significa que los registros almacenados en Log Analytics
son inmutables y solo se eliminan de un área de trabajo basadaen la configuración de
retención. Las consultas se crean en texto sin formato y el esquema utilizado por Log
Analytics es similar al utilizado por SQL, con bases de datos y tablas compuestas de
columnas y filas. En cada tabla, los datos se organizan en columnas con diferentes tipos de
datos, como lo indican los iconos junto al nombre de la columna. Los tipos de datos de
columna incluyen texto, números y fecha y hora.

Las consultas creadas en Log Analytics pueden adoptar muchas formas, desde consultas
básicas hasta consultas muy avanzadas con múltiples agregados y resúmenes. Las consultas
se pueden utilizar para buscar términos, identificar tendencias, analizar patrones y
proporcionar muchos otros conocimientos. Consultas de tablas de búsqueda; pueden
comenzar con un nombre de tabla o un comando de búsqueda que defina el alcance. El
carácter de barra vertical (|) separa los comandos y puede agregar tantos comandos como
sea necesario.

En el siguiente ejemplo, se consulta la tabla Heartbeat para resumir el recuento de

computadoras (por IP) y por un valor de tiempo ( TimeGenerated) para representar un
gráfico que rastrea la cantidad de computadoras que informan un espacio de trabajo cada
hora.

Haga clic aquí para ver la imagen del código

// Chart the number of reporting computers each hour

Heartbeat

| summarize dcount(ComputerIP) by bin(TimeGenerated, 1h)

| render timechart

Para ejecutar esta consulta, vaya a Azure Monitor y haga clic en Registros para abrir la
interfaz de consulta. Esta consulta no devolverá datos si no tiene ninguna máquina virtual
implementada y en ejecución. Esas máquinas también deben estar asociadas con el área de
trabajo de Log Analytics que está consultando.
La consulta anterior es una consulta basada en tablas. Las consultas siempre comienzan con
un alcance, ya sea una tabla o una consulta basada en búsqueda. Las consultas de Kusto
distinguen entre mayúsculas y minúsculas. Normalmente, las palabras clave del idioma se
escriben en minúsculas. Cuando utilice los nombres de tablas y columnas en consultas,
asegúrese de utilizar el caso correcto. Las consultas basadas en tablas se dirigen a una sola
tabla en un área de trabajo (o base de datos) de Log Analytics, mientras que las consultas
basadas en búsquedas se dirigen a todas las tablas de forma predeterminada.

Las consultas basadas en tablas comienzan determinando el alcance de la consulta y, por lo

tanto, tienden a ser muy eficientes y, en general, más rápidas que las consultas de búsqueda.
Las consultas de búsqueda son menos estructuradas por naturaleza, lo que las convierte en
la mejor opción cuando se busca un valor específico en columnas o tablas. En otras
palabras, una búsqueda puede escanear todas las columnas de una tabla o de todas las tablas
de un espacio de trabajo completo en busca del valor definido.

La cantidad de datos que se procesan mediante una consulta puede ser enorme, por lo que
estas consultas pueden tardar más en completarse y pueden devolver grandes conjuntos de
resultados que están limitados por el servicio Log Analytics a 10 000 resultados.

Para crear consultas en Azure Portal, vaya a Azure Monitor y abra la hoja Registros. Desde
esta hoja, puede acceder a todas las suscripciones y espacios de trabajo desde los que tiene
derechos para leer. Azure Monitor ofrece muchas consultas de ejemplo sobre latidos,
rendimiento y uso en sus máquinas y servicios rastreados en Log Analytics (consulte la
Figura 5-15 ).
FIGURA 5-15 Registros de Azure Monitor

Seleccione una consulta y haga clic en Cargar en el editor para abrir un editor con vista
previa de la consulta, como se muestra en la Figura 5-16 .

FIGURA 5-16 Editor de consultas con consulta de ejemplo

Guardar una consulta en el panel

Además de las consultas de muestra, puede explorar el esquema del espacio de trabajo
seleccionado actualmente. Esto es útil para determinar el caso adecuado para los nombres
de tablas y columnas porque KQL es un lenguaje de consulta que distingue entre
mayúsculas y minúsculas. Puede guardar consultas creadas para más adelante o marcarlas
como favoritas para poder recuperarlas más tarde utilizando el explorador de consultas
(consulte la Figura 5-17 ).
FIGURA 5-17 Guardar una consulta o marcarla como favorita

Interpretar gráficas

En el explorador de consultas, también puede generar cuadros y gráficos basados en las

consultas de registro. En la sección de resultados, haga clic en Gráfico para ver la
representación gráfica de los resultados de la consulta. Puede elegir una opción de
visualización entre varias categorías (desde columna, gráfico de barras, línea, circular o
área). Para una de las consultas de muestra, el gráfico de barras apiladas se muestra en la
Figura 5-18 .

FIGURA 5-18 Gráfico de barras apiladas

También puede ajustar la consulta y el tipo de gráfico. Por ejemplo, en la Figura 5-19 se
muestra un gráfico circular de anillos .
FIGURA 5-19 Gráfico circular de anillos

Configurar reglas de alerta, grupos de acciones y reglas de procesamiento de alertas en Azure

Monitor

Las alertas le notifican de forma proactiva cuando se encuentran condiciones importantes

en sus datos de monitoreo para que pueda identificar y abordar problemas antes de que los
usuarios de su sistema los noten.

Azure Monitor brinda una experiencia de alerta unificada a Azure, con un único panel para
interactuar con métricas, el registro de actividad, Log Analytics, estado de servicios y
recursos, e información específica del servicio que proporciona paneles listos para usar con
visualizaciones. y consultas para

 Aplicaciones personalizadas con Application Insights

 Maquinas virtuales
 Cuentas de almacenamiento
 Contenedores
 Redes
 Bóvedas de claves
Puede elegir entre múltiples opciones de notificación, incluyendo

 Correo electrónico
 SMS
 Notificaciones push a la aplicación móvil de Azure
 Voz
 Integración con servicios de automatización.

Las alertas que se generan dentro de Azure Monitor pueden invocar runbooks de Azure
Automation, aplicaciones lógicas, funciones de Azure e incluso generar incidentes en
herramientas de administración de servicios de TI de terceros, como ServiceNow.

Crear y probar alertas

Para crear una regla de alerta, abra la hoja Alertas (haga clic en Alertas desde la hoja
Configuración de recursos de Azure o busque Azure Monitor en Azure Portal), haga clic en
Crear y luego haga clic en Reglas de alerta, como se muestra en la Figura 5-20 .

FIGURA 5-20 La hoja Alertas dentro de Azure Monitor

Las alertas en Azure Monitor se centran en reglas de alerta. Las reglas de alerta contienen
los siguientes componentes:

 Un recurso de destino (o tipo de recurso)

 Lógica condicional para la alerta con criterios basados en las señales disponibles
para el recurso objetivo
 Un grupo de acciones, o qué debería suceder cuando se cumple la condición de la
regla de alerta
 Un nombre y una descripción para la regla de alerta.

Nota Reglas de alerta de Azure Monitor

Las reglas de alerta en Azure Monitor no son lo mismo que las alertas. Son los criterios
utilizados para evaluar cuándo se debe generar una alerta. Se genera una alerta en función
de la regla y luego se actúa sobre las alertas por separado, incluso manteniendo su propio
estado (como Nuevo o Cerrado).

Haga clic en Seleccionar alcance para elegir el objetivo de la alerta, lo que determina las
señales disponibles, como se muestra en la Figura 5-21 .

FIGURA 5-21 Crear una regla de alerta

El recurso de destino define el alcance y las señales disponibles para la alerta. Un recurso
de destino es un recurso de Azure que genera señales (como métricas o el registro de
actividad), como una máquina virtual o una cuenta de almacenamiento. Los tipos de señales
disponibles para el monitoreo varían según el objetivo seleccionado (u objetivos, ya que
puede seleccionar más de un objetivo). Los tipos de señal disponibles son los siguientes:

 Métrica
 Registrar consultas de búsqueda
 Registros de actividad

El siguiente paso es configurar los criterios de alerta seleccionando la señal en el menú

desplegable, como se muestra en la Figura 5-22 .
FIGURA 5-22 Condiciones de las reglas de alerta de Azure Monitor

Puede seleccionar la señal de las señales disponibles para el objetivo y definir la prueba
lógica que se aplicará a los datos de la señal. Por ejemplo, para una máquina virtual, puede
usar la métrica Porcentaje de CPU para generar una alerta basada en un umbral
personalizado para el uso de CPU, como se muestra en la Figura 5-23 . Las condiciones de
la lógica de alerta son diferentes para las señales del registro de actividad o las señales
métricas.
FIGURA 5-23 Condición de alerta de Azure Monitor

Configure una o más condiciones para la regla de alerta. Una vez definidas las condiciones,
haga clic en Seleccionar grupo de acciones, como se muestra en la Figura 5-24 . Un grupo
de acciones es una colección de acciones que deberían ocurrir en respuesta a la activación
de una alerta.
FIGURA 5-24 Grupos de acciones de Azure Monitor

Seleccione el grupo de acciones existente si ya tiene uno. De lo contrario, haga clic en

Crear grupo de acciones para crear un nuevo grupo de acciones, como se muestra en la
Figura 5-25 .
FIGURA 5-25 Crear un grupo de acciones

Nota Grupos de acción

Los grupos de acciones son recursos separados y son independientes de la regla de alerta.
Esto significa que se puede utilizar el mismo grupo de acciones en varias reglas de alerta.

Al crear un nuevo grupo de acciones, defina el nombre del grupo de acciones, el nombre
para mostrar, la suscripción y el grupo de recursos en el que se creará el grupo de acciones
(consulte la Figura 5-25 ).

En la siguiente pestaña, puede configurar las notificaciones. Seleccione Correo

electrónico/Mensaje SMS/Push/Voz en el menú desplegable Tipo de notificación y luego
configure los campos deseados en la configuración de notificación, como se muestra en la
Figura 5-26 .
FIGURA 5-26 Hoja de notificaciones de la hoja Crear grupo de acción

Además de enviar notificaciones por correo electrónico, puedes ejecutar las siguientes
acciones:

 Runbook Un conjunto de código de PowerShell que se ejecuta en el servicio Azure

Automation. Consulte lo siguiente para obtener más información sobre el uso de
Azure Automation con alertas en https://learn.microsoft.com/en-
us/azure/automation/automation-create-alert-triggered-runbook .
 Aplicaciones de funciones Una aplicación de funciones es un conjunto de código
que se ejecuta bajo demanda y puede responder a alertas. Esta funcionalidad
requiere la versión 2 de Function Apps y el valor de
la AzureWebJobsSecretStorageTypeconfiguración de la aplicación debe establecerse
en files.
 ITSM Puede tener hasta 10 acciones del Administrador de servicios de TI (ITSM)
con una conexión ITSM. Actualmente se admiten los siguientes proveedores de
ITSM: ServiceNow, System Center Service Manager, Provance y Cherwell.
 Centro de eventos Agregue o edite una acción del Centro de eventos para un
espacio de nombres que ya existe en una de sus suscripciones de Azure.
 Aplicaciones lógicas Una aplicación lógica proporciona un diseñador visual para
modelar y automatizar su proceso como una serie de pasos conocidos como flujo de
trabajo. Hay muchos conectores en todo elnube y local para integrarse rápidamente
entre servicios y protocolos. Cuando se activa una alerta, la aplicación lógica puede
tomar los datos de notificación y usarlos con cualquiera de los conectores para
corregir la alerta o iniciar otros servicios.
  Webhook Enruta una notificación de alerta de Azure a otros sistemas para realizar
posprocesamiento o acciones personalizadas. Por ejemplo, puede utilizar un
webhook en una alerta para enrutarla a servicios que envían mensajes de texto,
registran errores, notifican a un equipo a través de servicios de chat/mensajería o
realizan cualquier otra acción.
 Webhook seguro Utiliza Microsoft Entra ID para autenticar la conexión del
webhook.

Puede configurar las acciones anteriores para el grupo de acciones en la siguiente pestaña.
Seleccione entre las opciones disponibles en el menú desplegable Tipo de acción, como se
muestra en la Figura 5-27 .

FIGURA 5-27 Pestaña Acciones de la hoja Crear grupo de acciones

Una vez creado el grupo de acciones, especifique los detalles restantes de la regla de alerta,
como el nombre de la regla de alerta, la descripción, el grupo de recursos para guardar la
alerta, la gravedad y si se debe habilitar la alerta al momento de su creación (consulte la
Figura 5-28 ).

FIGURA 5-28 Detalles de la regla de alerta del grupo de acciones

Ver alertas en Azure Monitor

Una vez creada una regla de alerta, puede administrar la regla de alerta y el grupo de
acciones a través de Azure Monitor desde la hoja Alertas haciendo clic en Administrar
reglas de alerta. Las alertas se pueden administrar a través de múltiples suscripciones y se
pueden filtrar por grupo de recursos, tipo de recurso, tipo de señal y estado (consulte la
Figura 5-29 ).
FIGURA 5-29 Detalles de la regla de alerta de nueva acción de Azure Monitor

Las reglas de alerta no generan alertas de inmediato y las alertas de métricas pueden tardar
hasta 10 minutos. Cuando se generen alertas, se distribuirán en función de las acciones
definidas en el grupo de acciones. Por ejemplo, cuando se envía un correo electrónico, los
usuarios definidos recibirán un mensaje con los detalles de la alerta y un vínculo para ver la
alerta en Azure Portal, como se muestra en la Figura 5-30 .

FIGURA 5-30 Correo electrónico de notificación de alerta de Azure Monitor

Reglas de alerta de notas

Puede habilitar y deshabilitar reglas de alerta según sea necesario para cumplir con sus
requisitos.
Cuando una alerta se resuelve según el estado de la condición del monitor y se cambia a
Resuelta, también se envían notificaciones.

Analizar alertas entre suscripciones

Cuando se crea una regla de alerta, la regla de alerta apunta a recursos en una única
suscripción y las alertas que se generan en función de las reglas de alerta se asocian con la
suscripción desde la que se generan. Los operadores de Azure no están limitados a ver
alertas de una sola suscripción a través de Azure Monitor, que nuevamente proporciona un
panel único no solo para administrar reglas de alerta en múltiples suscripciones, sino
también para administrar las alertas generadas.

Recuerde que las reglas de alerta y los grupos de acciones son entidades separadas. Las
alertas que se generan según la lógica condicional de una regla de alerta también son
entidades independientes. Esto significa que se gestionan independientemente de las reglas
de alerta y mantienen su propio estado.

Las alertas pueden tener uno de tres estados:

 Nueva La alerta es nueva y no ha sido revisada.

 Reconocido Un administrador está tomando medidas sobre el problema que generó
la alerta.
 Cerrado El problema que generó la alerta se resolvió y la alerta se marcó como
cerrada.

El estado de una alerta lo actualiza el usuario que interactúa con la alerta y la plataforma
Azure no lo actualiza automáticamente.

Nota Estado de alerta

El estado de alerta no es lo mismo que la condición del monitor de una alerta. Cuando la
plataforma Azure genera una alerta basada en una regla de alerta, la condición del monitor
de la alerta se establece en activada y cuando la condición subyacente desaparece, la
condición del monitor se establece en resuelta.

A medida que se generan las alertas, aparecen en la hoja Alertas de Azure Monitor. Desde
la hoja Alertas, puede ver alertas para todas las suscripciones y profundizar en una o más
suscripciones, grupos de recursos y recursos específicos. Además, puede filtrar por rango
de tiempo eligiendo Última hora, Últimas 24 horas, Últimos 7 días o Últimos 30 días en el
menú desplegable (consulte la Figura 5-31 ).
FIGURA 5-31 Panel de alertas de Azure Monitor

La vista de esta página se puede filtrar a través de los menús desplegables de la página.
También puede filtrar, ordenar y editar las columnas que se muestran con las siguientes
limitaciones:

 Cuando filtra por suscripción, está limitado a seleccionar un máximo de cinco

suscripciones.
 Al filtrar por grupo de recursos, solo puede seleccionar un grupo de recursos a la
vez.
 El filtro Tipo de recurso es dinámico y se basa en la selección del grupo de recursos.
No podrá seleccionar tipos de recursos que no estén implementados en el grupo de
recursos seleccionado con el que está filtrando.
 El filtro Rango de tiempo muestra solo las alertas activadas dentro del período de
tiempo seleccionado. Los valores admitidos son la última hora, las últimas 24 horas,
los últimos 7 días y los últimos 30 días.

Al seleccionar una alerta se abrirán los detalles de la alerta (consulte la Figura 5-32 ).
Desde esta hoja, puede ver el historial de alertas, incluidos los cambios para monitorear el
estado de condición. Aquí también es donde puede modificar el estado de alerta a Nuevo,
Reconocido o Cerrado. Si se cambia el estado de una alerta, ese cambio se incluye en el
historial de alertas para fines de auditoría.
FIGURA 5-32 Detalles de alerta de Azure Monitor
Configurar información sobre aplicaciones

Application Insights se utiliza para el desarrollo y como solución de monitoreo de

producción. Funciona instalando un paquete en su aplicación, que puede proporcionar una
vista más interna de lo que sucede con su código. Sus datos incluyen tiempos de respuesta
de dependencias, seguimientos de excepciones, instantáneas de depuración y perfiles de
ejecución. Proporciona poderosas herramientas inteligentes para analizar toda esta
telemetría para ayudarlo a depurar una aplicación y comprender qué están haciendo los
usuarios con ella. Puede saber si un aumento en los tiempos de respuesta se debe a algo en
una aplicación o a un problema de recursos externos. Application Insights proporciona un
valor significativamente mayor cuando su aplicación está instrumentada para emitir eventos
personalizados e información de excepciones.

Para crear un recurso de Application Insights, abra Azure Monitor, haga clic en
Aplicaciones a la izquierda (en Insights) y luego haga clic en Crear aplicaciones de
Application Insight, como se muestra en la Figura 5-33 .

FIGURA 5-33 Creación de aplicaciones de Application Insights

En la pestaña Conceptos básicos, seleccione la suscripción, el grupo de recursos, la región,

el modo de recurso y el área de trabajo de Log Analytics y especifique el nombre
(consulte la Figura 5-34 ).
FIGURA 5-34 Pestaña Conceptos básicos de la hoja Application Insights

Application Insights proporciona un panel completo que describe todos los aspectos de la
carga de trabajo de su aplicación, como se muestra en la Figura 5-35 . El panel muestra la
aplicación.rendimiento, uso, diagnóstico y otros datos de la aplicación. El panel se puede
personalizar según sus preferencias.
FIGURA 5-35 Panel de control de Application Insights

¿Necesita más revisión? Información sobre la aplicación

Puede obtener más información sobre Application Insights, incluidos ejemplos para emitir
telemetría personalizada, en https://learn.microsoft.com/azure/azure-monitor/app/app-
insights-overview .
Configure e interprete la supervisión de máquinas virtuales, cuentas de almacenamiento y redes
mediante Azure Monitor Insights

El conjunto de características de Azure Monitor incluye Insights. Al momento de escribir

este artículo, existen más de 20 tipos de servicios que ofrecen diferentes conocimientos,
incluidos procesamiento, almacenamiento, redes, bases de datos y más.

Información sobre máquinas virtuales

La información sobre máquinas virtuales ayuda a monitorear el rendimiento y el estado de

sus máquinas virtuales y conjuntos de escalado de máquinas virtuales. Los conocimientos y
los datos recopilados pueden ayudarle a solucionar problemas, ver tendencias en los
registros ymétricas y crear alertas. Para configurar VM Insights desde Azure Portal,
busque Monitor . En la hoja Monitor, en Insights, haga clic en Máquinas virtuales. El panel
de información de VM se muestra en la Figura 5-36 .

FIGURA 5-36 Información sobre máquinas virtuales

En el panel de VM Insights, haga clic en Configurar Insights o haga clic en la pestaña

Descripción general. Si anteriormente habilitó las reglas de recopilación de datos u otras
funciones de Monitor, es posible que sus máquinas virtuales ya estén monitoreadas. De lo
contrario, aparecerán en la pestaña No monitoreado. La Figura 3-37 muestra la descripción
general de VM Insights en la pestaña Monitoreado.

FIGURA 5-37 Descripción general de la información sobre máquinas virtuales

La pestaña Rendimiento de VM Insights muestra algunos de los gráficos principales de las

VM. Esto incluye la utilización de la CPU, la memoria disponible, los bytes enviados y
recibidos y el porcentaje de espacio utilizado en el disco lógico. La Figura 5-38 muestra
una parte de la pestaña Rendimiento.
FIGURA 5-38 Rendimiento de conocimientos de VM

Información sobre la cuenta de almacenamiento

La información de la cuenta de almacenamiento utiliza un libro de trabajo de Monitor para

mostrar algunas métricas generales para las cuentas de almacenamiento de la suscripción.
Estas métricas incluyen la cantidad de transacciones en la cuenta, un cronograma de las
transacciones, la latencia de un extremo a otro, la latencia del servidor y los errores del
cliente. La Figura 5-39 muestra la descripción general de la cuenta de almacenamiento.
FIGURA 5-39 Información sobre la cuenta de almacenamiento

Información sobre la red

La información sobre la red resume el estado, la conectividad y el tráfico de la red para el

entorno. Esto incluye el estado de las interfaces de red, los grupos de seguridad de la red,
las direcciones IP públicas y las redes virtuales. La Figura 5-40 muestra la pestaña Estado
de la red de la hoja Redes en Azure Monitor.
FIGURA 5-40 Información sobre la red

Utilice Azure Network Watcher y Connection Monitor

Network Watcher proporciona un centro central para una amplia gama de herramientas de
diagnóstico y monitoreo de red. Estas herramientas son valiosas en una amplia gama de
escenarios de solución de problemas de red y también brindan acceso a otras herramientas
enumeradas en esta sección de habilidades, como Network Performance Monitor y
Connection Monitor.

Nota Monitor de conexión

La lista de objetivos para el examen AZ-104 incluye Connection Monitor con Network
Watcher. Sin embargo, el Monitor de conexión y la Solución de problemas de conexión se
trataron en el Capítulo 4 , Habilidad 4.1 y se omitirán aquí.
Implementar Network Watcher

Network Watcher está habilitado como una instancia única por región de Azure. No se
implementa como un recurso convencional de Azure, aunque aparece como un recurso en
un grupo de recursos.

Cualquier suscripción que contenga un recurso de red virtual tendrá automáticamente

habilitado Network Watcher. De lo contrario, se puede habilitar a través del portal de
Azure, eligiendo Todos los servicios, Network Watcher. También puede ver el estado de
Network Watcher por región. Network Watcher también se puede implementar a través de
la línea de comandos (usando el New-AzNetworkWatchercmdlet o los az network watcher
configurecomandos), que a diferencia de Azure Portal, proporciona control sobre el grupo
de recursos utilizado.

Algunas de las herramientas de Network Watcher requieren que la extensión VM de

Network Watcher esté instalada en la VM que se está monitoreando. Esta extensión está
disponible para máquinas virtuales Windows y Linux. Se instala automáticamente cuando
se utiliza Network Watcher a través de Azure Portal.

Verificar flujo de IP

La herramienta IP Flow Verify proporciona una forma rápida y sencilla de probar si un

determinado flujo de red podrá entrar o salir de una máquina virtual de Azure. Informará si
el tráfico solicitado está permitido o bloqueado y, en este último caso, qué regla NSG está
bloqueando el flujo. Es una herramienta útil para verificar que los NSG estén configurados
correctamente.

Funciona simulando el flujo de paquetes solicitado a través de los NSG aplicados a la VM.
Por este motivo, la máquina virtual debe estar en estado de ejecución.

Para usar IP Flow Verify a través de Azure Portal, abra Network Watcher y haga clic en IP
Flow Verify. Seleccione la VM y la NIC para verificar y especifique el protocolo, la
dirección y las direcciones IP y los puertos remotos y locales, como se muestra en la Figura
5-41 .
FIGURA 5-41 Verificación del flujo de IP de Network Watcher

IP Flow Verify también se puede usar desde PowerShell, usando el Test-

AzNetworkWatcherIPFlowcmdlet, o la CLI de Azure, usando el az network watcher test-
ip-flowcomando.

Siguiente salto

La herramienta Next Hop proporciona una forma útil de comprender cómo se dirige el
tráfico saliente de una máquina virtual. Para un flujo saliente determinado, muestra la
dirección IP y el tipo del siguiente salto, así como el ID de la tabla de rutas de cualquier
ruta definida por el usuario vigente. Los posibles tipos de próximos saltos son

 Internet
 Dispositivo virtual
 Puerta de enlace de red virtual
 Red Virtual
  Emparejamiento de red virtual
 Punto final del servicio de red virtual
 Ninguno (esto se utiliza para rutas definidas por el usuario)

Para usar Next Hop a través de Azure Portal, abra Network Watcher y haga clic en Next
Hop. Seleccione la máquina virtual de origen, la NIC, la dirección IP y la dirección de
destino, como se muestra en la Figura 5-42 . El destino puede ser cualquier dirección IP, ya
sea en la red interna o en Internet.

FIGURA 5-42 Próximo salto de Network Watcher

Next Hop también se puede usar desde PowerShell usando el Get-

AzNetworkWatcherNextHopcmdlet o la CLI de Azure usando el az network watcher show-
next-hopcomando.
Captura de paquetes

La herramienta Packet Capture captura paquetes de red que entran o salen de sus máquinas
virtuales. Es una poderosa herramienta para diagnósticos profundos de redes.

Puede capturar todos los paquetes o un subconjunto filtrado según el protocolo y las
direcciones IP y puertos locales y remotos. También puede especificar el tamaño máximo
de paquete y de captura general, y un límite de tiempo (las capturas comienzan casi
inmediatamente una vez configuradas).

Las capturas de paquetes se almacenan como un archivo en la máquina virtual o en una

cuenta de almacenamiento de Azure, en cuyo caso los NSG deben permitir el acceso desde
la máquina virtual a Azure Storage. Estas capturas están en un formato estándar y se
pueden analizar fuera de línea utilizando herramientas comunes como WireShark o
Microsoft Message Analyzer.

Para utilizar la herramienta Captura de paquetes, abra Network Watcher y haga clic en
Captura de paquetes, Agregar. Seleccione la máquina virtual, asigne un nombre a la captura
y especifique el destino, el tamaño total y del paquete, el límite de tiempo y los filtros.
En la Figura 5-43 se muestra un ejemplo .
FIGURA 5-43 Captura de paquetes de Network Watcher

Topología de la red

La vista de topología de red en Network Watcher proporciona una vista esquemática de los
recursos en su red virtual. No es una herramienta de diagnóstico o alerta. Es una forma
rápida y sencilla de revisar los recursos de su red y comprobar manualmente si hay alguna
configuración incorrecta.
Una limitación de la herramienta es que solo muestra la topología dentro de una única red
virtual. Se admiten todos los tipos de recursos de red comunes, aunque para las puertas de
enlace de aplicaciones, solo se muestra el grupo de backend conectado a la interfaz de red.

Para ver la topología de la red a través de Azure Portal, abra Network Watcher y haga clic
en Topología. Seleccione el grupo de recursos y la red virtual y se mostrará la topología.

En la Figura 5-44 se ofrece un ejemplo de topología .

FIGURA 5-44 Visualización de la topología de la red en Network Watcher

Los datos de topología subyacente se pueden descargar en formato JSON a través de Azure
PowerShell o la CLI de Azure, mediante el Get-AzNetworkWatcherTopologycmdlet o el az
network watcher show-topologycomando, respectivamente.
Habilidad 5.2: Implementar respaldo y recuperación

Azure Backup es un servicio que le permite realizar copias de seguridad de servidores

locales, máquinas virtuales basadas en la nube y cargas de trabajo virtualizadas, como SQL
Server y SharePoint, en Microsoft Azure. También admite copias de seguridad de archivos
compartidos de Azure Storage.

Azure Site Recovery es una herramienta de continuidad empresarial/recuperación ante

desastres que ayuda a replicar recursos. Los recursos de origen pueden ser locales, en otra
nube o en Azure. Usted crea una política de replicación para definir cómo desea que se
repliquen los recursos.

Esta habilidad cubre cómo:

 Crear y administrar una bóveda de Recovery Services

 Configurar la recuperación del sitio de Azure
 Crear una bóveda de Azure Backup
 Crear y configurar una política de respaldo
 Configurar y revisar informes de respaldo

Crear y administrar una bóveda de Recovery Services

Dentro de Azure, se aprovisiona un único recurso para Azure Backup o Azure Site
Recovery. Este recurso se denomina almacén de Recovery Services . También es el recurso
que se utiliza para la configuración y gestión tanto de Backup como de Site Recovery.

Crear una bóveda de servicios de recuperación

Para crear un almacén de Recovery Services desde Azure Portal, siga estos pasos:

1. Desde Azure Portal, busque almacenes de Recovery Services .

2. En la hoja Bóvedas de Site Recovery, haga clic en Crear.
3. Ingrese el nombre del almacén y elija el grupo de recursos donde reside o cree un
nuevo grupo de recursos.
4. Luego elija la región donde desea crear el recurso, como se muestra en la Figura 5-
45 .
 FIGURA 5-45 Conceptos básicos del almacén de Recovery Services

5. Haga clic en Siguiente: Redundancia. Puede configurar dos opciones en la pestaña

Redundancia, como se muestra en la Figura 5-46 :
 FIGURA 5-46 Redundancia de la bóveda de servicios de recuperación

1. Redundancia de almacenamiento de respaldo Elija si los datos almacenados en la

bóveda se replican de forma local, redundante de zona o con redundancia geográfica.
2. Restauración entre regiones Seleccione si las restauraciones pueden realizarse
entre regiones.
6. Haga clic en Siguiente: Propiedades de la bóveda. Luego especifique si la
inmutabilidad está habilitada para la bóveda. La inmutabilidad del almacén
garantiza que se creen puntos de restauración del almacén para evitar que los
elementos se eliminen antes de tiempo.
7. Haga clic en Siguiente: Redes. Elija si desea que la bóveda sea accesible desde
Internet desde todas las redes o si desea utilizar un punto final privado y denegar el
acceso público.
8. Haga clic en Siguiente: Cifrado de copia de seguridad. Elija si desea usar la clave
predeterminada administrada por Microsoft para cifrar los elementos de copia de
seguridad o usar una clave administrada por el cliente desde un almacén de claves
de Azure.
9. Haga clic en Revisar + Crear y luego haga clic en Crear.

Utilice la eliminación temporal para recuperar máquinas virtuales de Azure

El comportamiento predeterminado cuando elimina una copia de seguridad es que la copia

de seguridad se elimina y se pierde para siempre. Cuando la eliminación temporal está
habilitada, puede guardar y recuperar sus datos cuando se eliminan los datos de respaldo,
incluso en caso de sobrescritura. Esta característica debe estar habilitada en el almacén de
Recovery Services. Elija Propiedades, Configuración de seguridad para ver las opciones de
eliminación temporal (consulte la Figura 5-47 ). Cuando utiliza la eliminación temporal, los
datos de la copia de seguridad se conservan durante 14 días después de la eliminación.
FIGURA 5-47 Habilitación de la eliminación temporal para una bóveda de Recovery
Services

¿Necesita más revisión? Eliminación temporal para copia de seguridad de máquinas

virtuales de Azure

Puede obtener más información sobre el uso de la eliminación temporal con Azure VM
Backup en https://learn.microsoft.com/azure/backup/backup-azure-security-feature-
cloud?tabs=azure-portal#soft-delete .

Si la opción de eliminación temporal está habilitada, puede eliminar los datos de la copia de
seguridad haciendo clic en Detener copia de seguridad y luego haciendo clic en Eliminar
datos de copia de seguridad. Se le pedirá que proporcione un motivo para eliminar los datos
de la copia de seguridad que se almacenarán con el registro de actividad de la eliminación.
Una vez eliminado, aparecerá el elemento de copia de seguridad eliminado temporalmente,
como se muestra en la Figura 5-48 .
FIGURA 5-48 Elemento de copia de seguridad habilitado para eliminación temporal
después de la eliminación

Puede hacer clic en Recuperar en cualquier momento dentro de los 14 días posteriores al
período de retención (consulte la Figura 5-49 ). Una vez que se restauren los datos, puede
hacer clic en Reanudar copia de seguridad nuevamente.
FIGURA 5-49 Opción de recuperación para ExamRef-VM eliminadas temporalmente

Configurar la recuperación del sitio de Azure

Cada organización tendrá sus propios planes de continuidad del negocio y recuperación
ante desastres (BCDR) para manejar circunstancias impredecibles con interrupciones
inesperadas que se produzcan. El servicio Azure Site Recovery le permite replicar,
conmutar por error y conmutar por recuperación máquinas virtuales según sea necesario. La
solución Azure Site Recovery aborda estos principales escenarios de replicación:

 Máquinas virtuales de Azure de una región a otra

 Máquinas virtuales locales (VMware, Hyper-V y servidores físicos) para Azure
 Máquinas virtuales locales a otro sitio

Supongamos que necesita replicar máquinas virtuales de Azure de una región a otra, por
ejemplo. Primero, necesitaría crear una bóveda de Recovery Services. Como práctica
recomendada, siempre debe validar la preparación de la suscripción de destino
comprobando la SKU de VM adecuada y la disponibilidad de las funciones principales.
También debe tener en cuenta las regiones que está utilizando. Para la recuperación entre
regiones, el almacén y el grupo de recursos en el que se implementa el almacén deben estar
en una región diferente a las máquinas virtuales que está replicando.

Para entornos empresariales, también debería considerar incluir en la lista de direcciones

URL permitidas la conectividad saliente con los recursos de Azure necesarios y las reglas
de NSG basadas en etiquetas de servicio. También necesitará derechos mínimos de
colaborador de Site Recovery para configurar la replicación y derechos de operador de Site
Recovery para ejecutar las operaciones de conmutación por error y conmutación por
recuperación.

Para habilitar la replicación desde una máquina virtual de origen, siga estos pasos:

1. Abra la bóveda de Recovery Services y haga clic en Site Recovery.

2. En la hoja Site Recovery, en Máquinas virtuales de Azure, haga clic en Habilitar
replicación.
3. En la pestaña Fuente, proporcione los detalles de la fuente, como la ubicación, el
modelo de implementación, la suscripción y el grupo de recursos de origen, como se
muestra en la Figura 5-50 .

FIGURA 5-50 Configuración de origen al habilitar la replicación

4. En la siguiente pestaña, seleccione la máquina virtual de origen para la replicación
(consulte la Figura 5-51 ).

FIGURA 5-51 Selección de VM de origen al habilitar la replicación

5. A continuación, debe configurar los ajustes del entorno de destino, como se muestra
en la Figura 5-52 . La configuración de objetivos incluye
 FIGURA 5-52 Configuración de destino para la replicación

1. Ubicación de destino La región de Azure de destino, diferente de la de origen

2. Suscripción de destino si planea recuperar las máquinas en una suscripción
diferente
3. Grupo de recursos de destino El grupo de recursos del objeto VM después de la
recuperación.
4. Red virtual de conmutación por error La red virtual en la región de destino a la
que se debe asociar la máquina virtual.
5. Subred de conmutación por error La subred dentro de la red virtual a la que se
debe asociar la NIC de VM.
6. Almacenamiento Opciones de almacenamiento en disco administrado, rotación de
discos y caché de disco para cada máquina virtual que se replica
7. Opciones de disponibilidad Conjunto de disponibilidad objetivo, zona de
disponibilidad y/o grupos de ubicación de proximidad después de la recuperación
8. Reserva de capacidad Asegúrese de que la VM tenga una asignación de capacidad
garantizada después de la replicación.
6. En la pestaña Administrar, configure la política de replicación que se utiliza.
También puede definir grupos de replicación si un clúster de máquinas que ejecutan
la misma carga de trabajo necesita coherencia entre las máquinas virtuales, como se
muestra en la Figura 5-53 .
 FIGURA 5-53 Configurar la política de replicación

7. Finalmente, haga clic en Habilitar replicación (consulte la Figura 5-54 ).

 FIGURA 5-54 Revisión de todas las configuraciones de Habilitar replicación

Puede realizar un seguimiento del progreso de la replicación seleccionando Trabajos de Site

Recovery (consulte la Figura 5-55 ). Se necesita un tiempo para completar la replicación y
sincronización. No puede continuar con más pasos sin replicar la máquina virtual.
FIGURA 5-55 Trabajos de recuperación del sitio

Una vez replicada, puede ver la máquina virtual de origen enumerada en la bóveda de
Recovery Services en Elementos replicados. La descripción general se muestra en la Figura
5-56 .
FIGURA 5-56 Elementos replicados

Una vez completada la replicación, es hora de probar la conmutación por error:

1. En la hoja Elementos replicados, seleccione la máquina virtual. En la barra de

comandos, haga clic en Probar conmutación por error (consulte la Figura 5-57 ).

FIGURA 5-57 Prueba de conmutación por error en la hoja Elementos replicados

2. En la hoja Probar conmutación por error, seleccione un punto de recuperación en el

menú desplegable Elegir un punto de recuperación y elija una red virtual en el menú
desplegable Red virtual de Azure, como se muestra en la Figura 5-58 . Luego, haga
clic en Probar conmutación por error.
 FIGURA 5-58 Pruebe la hoja de conmutación por error

3. Puede realizar un seguimiento del progreso de la conmutación por error de prueba

mediante trabajos de Site Recovery, como se muestra en la Figura 5-59 . Ahora
podrá ver la máquina virtual de prueba creada en el grupo de recursos de destino.
 FIGURA 5-59 Trabajos de prueba de conmutación por error

4. Puede eliminar la máquina virtual de prueba después de verificar la máquina virtual

y los detalles de la red. Para eliminar la máquina virtual y otros recursos, haga clic
en Limpieza de prueba de conmutación por error, como se muestra en la Figura 5-
60 .

FIGURA 5-60 Conmutación por error de prueba de limpieza

5. Ahora puede ejecutar una conmutación por error real. Haga clic en Conmutación
por error en la barra de comandos.
6. En el blade de conmutación por error, seleccione el punto de recuperación y
verifique la dirección de la conmutación por error, como se muestra en la Figura 5-
61 . Haga clic en Conmutación por error.

FIGURA 5-61 Blade de conmutación por error

7. Puede realizar un seguimiento del progreso de la conmutación por error siguiendo

los trabajos de recuperación del sitio (consulte la Figura 5-62 ). Se creará una
máquina virtual de Azure de destino con la misma configuración y parámetros de
destino proporcionados anteriormente.
 FIGURA 5-62 Conmutación por error completada

8. Debe validar iniciando sesión en la VM.

9. Haga clic en Confirmar para completar el proceso de conmutación por error.
10. También debería considerar proteger su VM nuevamente haciendo clic en Volver a
proteger, lo que revertirá el proceso (consulte la Figura 5-63 ).

FIGURA 5-63 Opción de volver a proteger

¿Necesita más revisión? Escenarios de recuperación del sitio

Obtenga información sobre la recuperación del sitio de VMware en Azure

en https://learn.microsoft.com/azure/site-recovery/tutorial-prepare-azure . Obtenga
 información sobre la recuperación del sitio de la máquina virtual Hyper-V en Azure
en https://learn.microsoft.com/azure/site-recovery/tutorial-prepare-azure-for-
hyper .

11. Una vez que la máquina virtual esté protegida nuevamente, puede realizar una
conmutación por recuperación para volver al estado original. De manera similar,
puede utilizar Site Recovery para otros escenarios.

¿Necesita más revisión? Migración a Azure

Si desea migrar una carga de trabajo local a Azure,

consulte https://learn.microsoft.com/azure/migrate/migrate-services-overview .

Crear una bóveda de Azure Backup

El servicio Azure Backup se puede utilizar para realizar copias de seguridad y restaurar
varios recursos locales y en la nube. La bóveda de Recovery Services se utiliza para
habilitar Azure Backup y configurar las políticas de copia de seguridad.

Para cargas de trabajo de Azure, el servicio Azure Backup puede realizar copias de
seguridad de los siguientes recursos:

 Maquinas virtuales
 Bases de datos de SAP HANA que se ejecutan en una máquina virtual de Azure
 recurso compartido de archivos de Azure
 Bases de datos de SQL Server que se ejecutan en una máquina virtual de Azure

Cuando realiza una copia de seguridad de una máquina virtual de Azure, puede restaurar
una máquina virtual completa o puede restaurar archivos individuales desde la máquina
virtual, y es bastante fácil de configurar. Para hacer una copia de seguridad de una máquina
virtual en Azure con Azure Backup, abra el almacén de Recovery Services y haga clic en
Copia de seguridad en Introducción. Desde ¿Dónde está funcionando su carga de trabajo?
menú desplegable, seleccione Azure y en ¿Qué desea respaldar? menú desplegable,
seleccione Máquina virtual. Después de realizar estas selecciones, haga clic en Copia de
seguridad, como se muestra en la Figura 5-64 .
FIGURA 5-64 Configuración de Azure Backup para proteger máquinas virtuales

En la hoja Configurar copia de seguridad, primero seleccione si desea realizar una copia de
seguridad utilizando un tipo de política Estándar o Mejorada. Las políticas estándar se
utilizan para copias de seguridad simples de máquinas virtuales de lanzamiento no
confiables o máquinas virtuales que no utilizan discos Ultra o discos Premium SSD v2,
cualquiera de los cuales requiere Mejorado. Después de seleccionar el tipo, seleccione la
política específica que coincida con ese tipo o elija la política predeterminada. Finalmente,
haga clic en Agregar para agregar la VM a la configuración de respaldo. En la Figura 5-
65 se muestra una configuración completa utilizando una política estándar para VM1 .
FIGURA 5-65 Configuración de Azure Backup

Una vez seleccionadas las máquinas virtuales, haga clic en Habilitar copia de seguridad.

Nota Protección de máquinas virtuales de Azure y tipo de redundancia de

almacenamiento en Vault

Al proteger máquinas virtuales IaaS mediante Azure Backup, solo las máquinas virtuales de
la misma región que el almacén de Recovery Services están disponibles para realizar copias
de seguridad. Debido a esto, se recomienda elegir almacenamiento con redundancia
geográfica o almacenamiento con redundancia geográfica con acceso de lectura para
asociarlo con la bóveda de Recovery Services. Esto garantiza que si una interrupción
regional afecta el acceso a la máquina virtual, haya una copia replicada de la copia de
seguridad en otra región.
Al hacer clic en Habilitar copia de seguridad, en segundo plano, el controlador de tejido de
Azure implementa automáticamente la extensión VMSnapshot(para Windows) o (para
Linux) en las máquinas virtuales. VMSnapshotLinuxEsto hace posibles las copias de
seguridad basadas en instantáneas, lo que significa que primero se toma una instantánea de
la máquina virtual y luego esta instantánea se transmite al almacenamiento de Azure
asociado con la bóveda de Recovery Services. La copia de seguridad inicial no se realiza
hasta el día/hora configurado en la política de copia de seguridad, aunque se puede iniciar
una copia de seguridad ad hoc en cualquier momento. Para hacerlo, navegue hasta la
sección Elementos protegidos de las propiedades del almacén de Recovery Services, haga
clic en Elementos de copia de seguridad y haga clic en Máquina virtual de Azure en Tipo
de administración de copia de seguridad. Las máquinas virtuales que están habilitadas para
realizar copias de seguridad se enumeran aquí. Para comenzar una copia de seguridad ad
hoc, haga clic con el botón derecho en una máquina virtual y seleccione Copia de seguridad
ahora, como se muestra en la Figura 5-66 .

FIGURA 5-66 Inicio de una copia de seguridad ad hoc

Azure Backup también admite directamente la capacidad de realizar copias de seguridad y

restaurar datos de Azure Files, bases de datos de SQL Server y bases de datos de SAP
HANA en máquinas virtuales de Azure. Es una buena idea tener un conocimiento básico de
las capacidades porque pueden aparecer en el examen.

¿Necesita más revisión? Azure Files y SQL Server en una máquina virtual de Azure

Cada tipo específico de almacenamiento tiene capacidades diferentes cuando se integra con
Azure Backup. Conozca más sobre cada servicio:

 Archivos de Azure: https://learn.microsoft.com/azure/backup/backup-azure-

files?tabs=backup-center
 SQL Server en máquinas virtuales de
Azure: https://learn.microsoft.com/azure/backup/backup-azure-sql-database
  SAP HANA en máquinas virtuales de
Azure: https://learn.microsoft.com/azure/backup/sap-hana-database-about .

Después de realizar una copia de seguridad de una máquina virtual con Azure Backup,
existen dos métodos para restaurar datos: restaurar la máquina virtual y recuperar archivos.

Para restaurar un punto de recuperación como una nueva máquina virtual, abra la bóveda de
Recovery Services, haga clic en Elementos de copia de seguridad, haga clic en Máquina
virtual de Azure y luego haga clic en la máquina virtual que desea restaurar de la lista. Verá
una lista de todos los puntos de restauración disponibles para restauración, como se muestra
en la Figura 5-67 .

FIGURA 5-67 Puntos de restauración disponibles para una máquina virtual.

Haga clic derecho en el punto de restauración deseado y seleccione Restaurar VM, o haga
clic en Restaurar VM en la parte superior de la página (consulte la Figura 5-67 ).

Luego puede restaurar en una nueva máquina virtual seleccionando Crear nuevo, o puede
restaurar sobre una máquina virtual existente seleccionando Reemplazar existente.
La Figura 5-68 muestra la hoja Restaurar máquina virtual con Crear nuevo seleccionado.
Aquí puede especificar el nombre de la máquina virtual, el grupo de recursos, la red virtual,
la subred y la cuenta de almacenamiento.

FIGURA 5-68 Restaurar en una nueva máquina virtual

Si solo necesita acceder a los archivos desde la máquina virtual, haga clic en Recuperación
de archivos en la parte superior de la página que se muestra anteriormente en la Figura 5-
66 . Desde allí, puede seleccionar el punto de recuperación y luego descargar un script que
montará el punto de recuperación seleccionado en otra computadora como discos locales
(consulte la Figura 5-69 ). Los discos permanecerán montados durante 12 horas para que
puedas recuperar los datos necesarios.

FIGURA 5-69 Restaurar en una nueva máquina virtual

Consejo de examen

Para restaurar una máquina virtual que tiene discos cifrados, también debe proporcionar
acceso al servicio Azure Backup al almacén de claves que contiene las claves.
Consulte https://learn.microsoft.com/azure/backup/backup-azure-vms-encryption .

¿Necesita más revisión? Más detalles sobre la restauración de máquinas virtuales y

archivos

Puede obtener más información sobre cómo recuperar máquinas virtuales con el servicio
Azure Backup en https://learn.microsoft.com/azure/backup/backup-azure-arm-restore-
vms .
Para obtener más información sobre la recuperación a nivel de archivos,
consulte https://learn.microsoft.com/azure/backup/backup-azure-restore-files-from-vm .

Crear y configurar una política de respaldo

Puede editar una política, asociar más máquinas virtuales a una política y eliminar políticas
innecesarias para cumplir con los requisitos de cumplimiento.

Para ver sus políticas de respaldo actuales en Azure Portal, abra la hoja del almacén de
Recovery Services y luego haga clic en Políticas de respaldo, como se muestra en la Figura
5-70 . Haga clic en una política existente para ver los detalles de la política o haga clic en
Agregar para crear una nueva política.

FIGURA 5-70 Políticas de respaldo en la bóveda de Recovery Services

Puede crear cinco tipos diferentes de políticas desde esta vista, como se muestra en la
Figura 5-71 :
FIGURA 5-71 Opciones de política de respaldo disponibles en Azure Portal

 Máquina virtual de Azure Especifique la frecuencia de la copia de seguridad, el

período de retención y el punto de copia de seguridad en una programación
semanal, mensual y anual.
 Recursos compartidos de archivos de Azure Programe una copia de seguridad
diaria para un recurso compartido de archivos de Azure.
 SQL Server en Azure VM Utilice tecnología de copia de seguridad específica de
SQL Server, como copias de seguridad completas, diferenciales y de registros, con
una programación asociada para cada opción. Además, puede habilitar la
compresión de copia de seguridad de SQL.
 SAP HANA en Azure VM (base de datos a través de Backint) Utilice SAP
HANA: tecnología de respaldo específica, como respaldo completo, diferencial y de
registros con un cronograma asociado para cada opción.
 SAP HANA en Azure VM (instancia de base de datos mediante
instantánea) Utilice una instantánea para realizar una copia de seguridad de una
instancia de SAP HANA.

Definir políticas de respaldo

Una política de Azure Backup define la frecuencia con la que se realizan las copias de
seguridad y durante cuánto tiempo se conservan. La política predeterminada realiza una
copia de seguridad diaria a las 05:30 p.m. UTC y retiene las copias de seguridad durante 30
días. Puede definir políticas de copia de seguridad personalizadas. En el menú desplegable
Frecuencia, puede elegir entre las opciones Diaria, Semanal, Mensual y Anual. En la Figura
5-72 , se configura una política de respaldo personalizada.
FIGURA 5-72 Configuración de una política de respaldo personalizada

Implementar políticas de respaldo

Para implementar una política de respaldo, abra la política en Azure Portal y haga clic en
Elementos asociados, como se muestra en la Figura 5-73 .
FIGURA 5-73 Elementos asociados en la hoja Modificar política

La hoja Elementos asociados en la Figura 5-74 muestra todos los recursos actualmente
asociados con la política.

FIGURA 5-74 La hoja Elementos asociados para la política de respaldo

Al hacer clic en Agregar, se abrirá la hoja Objetivo de copia de seguridad, donde puede
agregar otras máquinas virtuales o recursos compartidos de archivos para realizar una copia
de seguridad utilizando los objetivos definidos en la política.

Configurar y revisar informes de respaldo

Con los informes de Azure Backup, puede visualizar datos en sus almacenes de Recovery
Services y suscripciones de Azure para proporcionar información sobre su actividad de
respaldo. Actualmente, esta solución de informes es ampliamente compatible con
escenarios de copia de seguridad de máquinas virtuales de Azure y copias de seguridad de
archivos y carpetas cuando se utiliza el agente MARS (Microsoft Azure Recovery
Services). Para conocer otros escenarios admitidos,
consulte https://learn.microsoft.com/azure/backup/configure-reports?tabs=recovery-
services-vaults#supported-scenarios .

Para configurar los informes de respaldo, debe crear o usar un área de trabajo de Log
Analytics existente para almacenar los datos de los informes de respaldo. Además, necesita
una bóveda de Recovery Services, que registre todas las operaciones de copia de seguridad
como datos de diagnóstico. Crear una bóveda de Recovery Services esdiscutido
anteriormente en la Habilidad 5.2 de este capítulo (consulte “ Crear una bóveda de
Recovery Services ”). Para configurar los diagnósticos para Recovery Service Vault, abra
Recovery Services Vault y luego elija Configuración de diagnóstico, Agregar configuración
de diagnóstico (consulte la Figura 5-75 ).
FIGURA 5-75 Configuración de diagnóstico para la bóveda de Azure Recovery Services

En este ejemplo, se eligieron categorías de registros como se muestra en la Figura 5-76 y

los datos se configuraron para enviarse al área de trabajo de Log Analytics con la
configuración de retención predeterminada de 30 días. Si desea conservar datos durante
más de 30 días, debe actualizar la configuración de Retención en el espacio de trabajo de
Log Analytics.
FIGURA 5-76 Configuración de diagnóstico para la bóveda de Azure Recovery Services

Una vez configuradas las configuraciones de diagnóstico, puede ver los datos del informe
de respaldo en la bóveda de Recovery Services haciendo clic en Informes de respaldo en
Administrar, como se muestra en la Figura 5-77 .
FIGURA 5-77 Informes de copia de seguridad para la bóveda de Azure Recovery

Resumen del capítulo

Estas son algunas de las conclusiones clave de este capítulo:

 Azure Monitor es un panel único para acceder a métricas de Azure, registros de

diagnóstico de recursos y inquilinos, Log Analytics, estado del servicio y alertas.
 Puede configurar alertas basadas en alertas de métricas (capturadas de Métricas de
Azure Monitor) para alertas de registro de actividad que pueden proporcionar
notificaciones por correo electrónico, webhook, SMS, aplicaciones lógicas o incluso
un runbook de Azure Automation.
 Azure Log Analytics puede consolidar datos de máquinas de cargas de trabajo
locales y basadas en la nube, y estos datos se indexan y clasifican para una
búsqueda rápida. Los datos se pueden recopilar tanto de máquinas con Windows
como con Linux.
 Azure Log Analytics tiene muchas soluciones de administración que ayudan a los
administradores a obtener valor de los datos complejos de las máquinas. Estas
soluciones contienen visualizaciones y consultas prediseñadas que ayudan a obtener
información rápidamente.
  Las consultas en Log Analytics se pueden guardar para un acceso rápido y
visualizarse y compartirse mediante paneles de Azure. Para analizar datos fuera de
Log Analytics, puede exportar los datos a Excel y Power BI.
 Network Watcher contiene un conjunto de herramientas que se pueden utilizar para
ayudar a monitorear las conexiones de red y los flujos de tráfico.
 El servicio Azure Backup puede realizar copias de seguridad y restaurar una
máquina virtual completa. También puede usarlo para restaurar archivos desde un
punto de recuperación sin recrear toda la máquina virtual.
 Azure Backup se puede utilizar para proteger archivos y carpetas, aplicaciones y
máquinas virtuales IaaS. Este servicio de protección de datos basado en la nube
ayuda a las organizaciones al proporcionar copias de seguridad externas de
servidores locales y protección de cargas de trabajo de máquinas virtuales que ya
han trasladado a la nube.
 Los datos de copia de seguridad se conservan durante 14 días después de la
eliminación cuando habilita la función de eliminación temporal.
 Se utiliza una bóveda de Recovery Services para configurar y administrar Backup y
Site Recovery.
 Una política de Azure Backup define la frecuencia con la que se realizan las copias
de seguridad y durante cuánto tiempo se conservan.
 El servicio Azure Site Recovery nos permite replicar, conmutar por error y
conmutar por recuperación máquinas virtuales según sea necesario.
 Los almacenes de Recovery Services pueden usar configuraciones de diagnóstico
para habilitar informes de respaldo detallados almacenados en Log Analytics.

Experimento mental

En este experimento mental, aplica lo que has aprendido. Puede encontrar respuestas a estas
preguntas en la siguiente sección.

Usted es el administrador de Trey Research Pharmaceuticals. Como líder en el diseño y

fabricación de tratamientos de vanguardia para pacientes con cáncer, Trey Research
necesita garantizar que los datos de los usuarios dentro de la organización estén protegidos,
ya que manejan datos confidenciales y no pueden soportar ninguna pérdida de datos. Los
usuarios tienen sus propias máquinas virtuales asignadas en Azure que se implementan en
la región central de Canadá.

Trey Research debe garantizar que la solución de respaldo tenga las siguientes
características:

1. Se debe realizar una copia de seguridad de todos los datos de los usuarios
diariamente a las 6 p. m., hora del este. Los datos deben conservarse durante un año
a partir de la fecha en que se realiza la copia de seguridad. ¿Qué se debe configurar
con Azure Backup para facilitar este requisito?
2. Si los datos de respaldo de algún usuario se eliminan accidentalmente, deberían
poder restaurarlos dentro de dos semanas. ¿Qué configuración permite la
recuperación de elementos eliminados accidentalmente?
 3. Los usuarios deberían poder restaurar sus máquinas virtuales, así como archivos y
carpetas a partir de los datos de la copia de seguridad. ¿Qué características de Azure
Backup proporcionan esta funcionalidad?

Respuestas del experimento mental

Esta sección contiene las respuestas al experimento mental del capítulo.

1. Cree una política de respaldo con el cronograma para ejecutar el respaldo a las 6 p.
m., hora del este, con la retención de puntos de respaldo diarios durante 365 días.
2. Habilite la función de eliminación temporal en Configuración de seguridad
visitando las Propiedades de la bóveda de Recovery Services.
3. Aproveche las opciones Restaurar VM y Recuperación de archivos para restaurar la
VM y restaurar archivos y carpetas, respectivamente.

Capítulo 6
Exam Ref AZ-104 Actualizaciones del examen Administrador de Microsoft Azure
El propósito de este capítulo

En todos los demás capítulos, el contenido debe permanecer sin cambios a lo largo de esta
edición del libro. Sin embargo, este capítulo cambiará con el tiempo, con un PDF
actualizado publicado en línea para que pueda ver la última versión del capítulo, incluso
después de comprar este libro.

¿Por qué necesitamos un capítulo que se actualice con el tiempo? Por tres razones.

1. Para agregar más contenido técnico al libro antes de que llegue el momento de
reemplazar la edición actual del libro con la próxima edición. Este capítulo incluirá
contenido tecnológico adicional y posiblemente archivos PDF adicionales que
contengan más contenido.
2. Comunicarle detalles sobre la próxima versión del examen, informarle sobre
nuestros planes de publicación para esa edición y ayudarlo a comprender lo que eso
significa para usted.
3. Proporcionar una correlación precisa de los objetivos actuales del examen con el
contenido de los capítulos existentes. Si bien los objetivos del examen evolucionan
y se actualizan y los productos cambian de nombre, gran parte del contenido de este
libro seguirá siendo preciso y relevante. Además de cubrir cualquier brecha de
contenido que aparezca a través de adiciones a los objetivos, este capítulo
proporcionará notas explicativas sobre cómo los nuevos objetivos se relacionan con
el texto actual.

Después de la publicación inicial de este libro, Microsoft Press proporcionará

actualizaciones complementarias como descargas digitales para actualizaciones menores de
exámenes. Si un examen tiene cambios importantes o acumula suficientes cambios
menores, anunciaremos una nueva edición. Haremos todo lo posible para brindarle
actualizaciones de forma gratuita antes de lanzar una nueva edición. Sin embargo, si las
actualizaciones son lo suficientemente importantes entre ediciones, podemos publicarlas
como un libro electrónico independiente de bajo precio.

Si producimos una versión actualizada gratuita de este capítulo, puede acceder a ella en la
página del producto del libro. Simplemente
visite MicrosoftPressStore.com/ERAZ1042e/downloads para ver y descargar el material
actualizado.

Sobre posibles actualizaciones de exámenes

Microsoft revisa el contenido del examen periódicamente para garantizar que se alinee con
la tecnología y el rol laboral asociado con el examen. Esto incluye, entre otros, la
incorporación de funcionalidades y características relacionadas con cambios tecnológicos,
el cambio de habilidades necesarias para el éxito en un puesto de trabajo y revisiones de los
nombres de los productos. Microsoft actualiza la página de detalles del examen para
notificar a los candidatos cuando se producen cambios. Si ha registrado este libro y se
produce una actualización de este capítulo, Microsoft Press le notificará cuando el capítulo
actualizado esté disponible.

Impacto en ti y tu plan de estudios

La información de Microsoft le ayuda a planificar, pero también significa que el examen

puede cambiar antes de que apruebe el examen actual. Eso le afecta a usted y afecta la
forma en que le entregamos este libro. Este capítulo nos brinda una manera de comunicar
en detalle esos cambios a medida que ocurren. Pero también deberías vigilar otros espacios.

Para obtener noticias, marque y consulte estos sitios:

 Microsoft Learn : consulte la fuente principal para obtener información

actualizada: microsoft.com/learn . Asegúrese de registrarse para recibir
notificaciones automáticas en esa página.
 Microsoft Press : encuentre información sobre productos, ofertas, descuentos y
descargas gratuitas: microsoftpressstore.com . Asegúrese de registrar los productos
adquiridos.

A medida que surjan cambios, actualizaremos este capítulo con más detalles sobre el
examen y el contenido del libro. En ese momento, publicaremos una versión actualizada de
este capítulo, enumerando nuestros planes de contenido. Ese detalle probablemente incluirá
lo siguiente:

 Se eliminó el contenido, por lo que si planea realizar la nueva versión del examen,
puede ignorar esas secciones cuando estudie.
 Nuevo contenido planeado relacionado con nuevos temas de exámenes, para que
sepas lo que viene
El resto del capítulo muestra el nuevo contenido que puede cambiar con el tiempo.

Noticias y comentarios sobre las actualizaciones de objetivos del examen.

La Guía de estudio oficial de Microsoft actual para el examen AZ-104 Administrador de

Microsoft Azure se encuentra en https://learn.microsoft.com/en-
us/credentials/certifications/resources/study-guides/az-104 . Esta página tiene la versión
más reciente del dominio objetivo del examen.

Esta declaración se actualizó por última vez en octubre de 2023, antes de la publicación
del examen Ref AZ-104 Administrador de Microsoft Azure .

Esta versión de este capítulo no tiene noticias que compartir sobre la próxima versión del
examen.

Contenido técnico actualizado

La versión actual de este capítulo no tiene contenido técnico adicional.

Mapeo objetivo

Esta referencia de examen está estructurada por los autores en función de los temas y
tecnologías cubiertos en el examen y no está estructurada en función del orden específico
de los temas en los objetivos del examen. La siguiente tabla asigna la versión actual de los
objetivos del examen al contenido del capítulo, lo que le permite ubicar dónde tiene
cobertura un elemento específico del objetivo del examen sin tener que consultar el índice.

TABLA 6.1 Objetivos del examen asignados a capítulos.

Objetivo del examen Capítulo

Administrar identidades y gobernanza de Azure

Administrar usuarios y grupos de Microsoft Entra 1

 Crear usuarios y grupos

 Administrar propiedades de usuarios y grupos
 Administrar licencias en Microsoft Entra ID
 Administrar usuarios externos
 Configurar la unión con Microsoft Entra ID
 Configurar el restablecimiento de contraseña de autoservicio
(SSPR)
 Objetivo del examen Capítulo

Administrar el acceso a los recursos de Azure 1

 Entender cómo funciona RBAC

 Crear un rol personalizado
 Interpretar asignaciones de acceso
 Administrar múltiples directorios

Administrar suscripciones y gobernanza de Azure 1

 Configurar políticas de Azure

 Configurar bloqueos de recursos
 Aplicar y administrar etiquetas en recursos
 Administrar grupos de recursos Administrar suscripciones de Azure
 Configurar grupos de administración
 Configurar la gestión de costes

Implementar y gestionar el almacenamiento

Configurar el acceso al almacenamiento 2

 Crear y configurar cuentas de almacenamiento

 Configurar firewalls y redes virtuales de Azure Storage
 Crear y utilizar tokens de firma de acceso compartido (SAS)
 Configurar políticas de acceso almacenadas
 Administrar claves de acceso
 Configurar el acceso basado en identidad

Configurar y administrar cuentas de almacenamiento 2

 Configurar la redundancia del almacenamiento de Azure

 Configurar la replicación de objetos
 Configurar el cifrado de la cuenta de almacenamiento
 Administrar datos mediante Azure Storage Explorer
 Administrar datos mediante AzCopy

Configurar Azure Files y Azure Blob Storage 2

 Objetivo del examen Capítulo

 Cree y configure un recurso compartido de archivos en el

almacenamiento de Azure
 Configurar el almacenamiento de blobs de Azure
 Configurar niveles de almacenamiento
 Configurar eliminación temporal, control de versiones e
instantáneas
 Configurar la administración del ciclo de vida del blob

Implementar y administrar recursos informáticos de Azure

Automatizar la implementación de recursos 3

 Interpretar una plantilla de Azure Resource Manager (ARM)

 Modificar una plantilla ARM existente
 Implementar recursos desde una plantilla
 Exportar una plantilla de implementación
 Interpretar y modificar un archivo Bicep

Crear y configurar máquinas virtuales. 3

 Crear una máquina virtual

 Configurar el cifrado de disco de Azure
 Mover máquinas virtuales de un grupo de recursos o suscripción a
otro
 Administrar tamaños de VM
 Administrar discos de VM
 Implementar máquinas virtuales en zonas y conjuntos de
disponibilidad
 Implementar y configurar conjuntos de escalado de máquinas
virtuales

Aprovisionar y gestionar contenedores 3

 Crear y administrar un Registro de contenedores de Azure (ACR)

 Aprovisionar un contenedor mediante Azure Container Instances
(ACI)
 Aprovisionar un contenedor mediante Azure Container Apps
(ACA)
 Objetivo del examen Capítulo

 Gestionar el tamaño y el escalado de los contenedores.

Crear y configurar el servicio de aplicaciones de Azure 3

 Aprovisionar un plan de App Service

 Configurar el escalado para un plan de App Service
 Crear un servicio de aplicación
 Asigne un nombre DNS personalizado existente a un servicio de
aplicaciones
 Configurar certificados y TLS para un App Service
 Configurar la copia de seguridad para un App Service
 Configurar los ajustes de red para un App Service
 Configurar ranuras de implementación para un App Service

Configurar y administrar redes virtuales

Configurar y administrar redes virtuales en Azure 4

 Crear y configurar redes y subredes virtuales.

 Crear y configurar el emparejamiento de redes virtuales
 Configurar direcciones IP públicas
 Configurar rutas de red definidas por el usuario
 Solucionar problemas de conectividad de red

Configurar el acceso seguro a redes virtuales 4

 Crear y configurar grupos de seguridad de red y grupos de

seguridad de aplicaciones.
 Evaluar reglas de seguridad efectivas
 Implementar y configurar el servicio Azure Bastion
 Configurar puntos de conexión de servicio para servicios de Azure
 Configurar puntos de conexión privados para servicios de Azure

Configurar la resolución de nombres y el equilibrio de carga 4

 Configurar DNS de Azure

 Configurar el equilibrio de carga
 Objetivo del examen Capítulo

 Solucionar problemas de equilibrio de carga

Supervisar y realizar copias de seguridad de los recursos de Azure

Supervisar recursos en Azure 5

 Interpretar métricas en Azure Monitor

 Configurar los ajustes de registro en Azure Monitor
 Consultar y analizar registros en Azure Monitor
 Configurar reglas de alerta, grupos de acciones y reglas de
procesamiento de alertas en Azure Monitor
 Configurar información sobre aplicaciones
 Configure e interprete la supervisión de máquinas virtuales, cuentas
de almacenamiento y redes mediante Azure Monitor Insights.
 Utilice Azure Network Watcher y Connection Monitor

Implementar respaldo y recuperación

 Crear y administrar una bóveda de Recovery Services

 Configurar la recuperación del sitio de Azure
 Crear una bóveda de Azure Backup
 Crear y configurar una política de respaldo
 Configurar y revisar informes de respaldo