Compartir vía

Preguntas frecuentes sobre la zona de aterrizaje de Azure

  • Artículo

En este artículo se responden las preguntas frecuentes sobre la arquitectura de las zonas de aterrizaje de Azure.

Para ver las preguntas frecuentes sobre la implementación de la arquitectura de las zonas de aterrizaje de Azure, consulte las preguntas frecuentes sobre la implementación de la escala empresarial.

¿Qué es el acelerador de la zona de aterrizaje de Azure?

El acelerador de la zona de aterrizaje de Azure es una experiencia de implementación basada en Azure Portal. Realiza una implementación bien fundamentada basada en la arquitectura conceptual de la zona de aterrizaje de Azure.

Microsoft desarrolla activamente y mantiene los aceleradores de plataformas y aplicaciones, así como las implementaciones, en consonancia con los principios de diseño de la zona de aterrizaje de Azure y la guía del área de diseño.

Revise la guía Implementación de zonas de aterrizaje de Azure para obtener más información sobre las zonas de aterrizaje de las aplicaciones y plataformas recomendadas.

Para obtener información sobre cómo adaptar la implementación de zonas de aterrizaje de Azure para satisfacer sus necesidades, consulte Personalización de la arquitectura de la zona de aterrizaje de Azure para satisfacer los requisitos.

Sugerencia

Para solicitar una adición a la lista de aceleradores e implementaciones, genere una incidencia de GitHub en el repositorio ALZ.

¿Qué es la arquitectura conceptual de la zona de aterrizaje de Azure?

La arquitectura conceptual de la zona de aterrizaje de Azure representa las decisiones de escala y madurez. Se basa en las lecciones aprendidas y en los comentarios de los clientes que han adoptado Azure como parte de su patrimonio digital. Esta arquitectura conceptual puede ayudar a su organización a establecer una dirección para diseñar e implementar una zona de aterrizaje.

¿A qué se asigna una zona de aterrizaje en Azure en el contexto de la arquitectura de las zonas de aterrizaje de Azure?

Desde el punto de vista de las zonas de aterrizaje de Azure, las zonas de aterrizaje son suscripciones de Azure individuales.

¿Qué significa la gobernanza controlada por directivas y cómo funciona?

La gobernanza controlada por directivas es uno de los principios de diseño clave de la arquitectura de escala empresarial.

La gobernanza basada en directivas implica usar Azure Policy para reducir el tiempo necesario para realizar tareas operativas comunes y repetidas en el inquilino de Azure. Use muchos de los efectos de Azure Policy, como Append, Deny, DeployIfNotExists y Modify, para evitar el incumplimiento. Para ello, puede restringir la creación o actualización de recursos no conformes (como se indica en la definición de la directiva), o bien implementar recursos o modificar la configuración de una solicitud de creación o actualización de recursos para que sean conformes. Algunos efectos, como Audit, Disabled y AuditIfNotExists, no impiden ni llevan a cabo ninguna acción; solo auditan y notifican los casos de incumplimiento.

Algunos ejemplos de gobernanza controlada por directivas son:

  • Efecto Deny: impide que las redes se creen o se actualicen de modo que no tengan ningún grupo de seguridad de red asociado.

  • Efecto DeployIfNotExists: se crea una nueva suscripción (zona de aterrizaje) y se coloca en un grupo de administración dentro de la implementación de las zonas de aterrizaje de Azure. Azure Policy garantiza que Microsoft Defender for Cloud (anteriormente conocido como Azure Security Center) esté habilitado en la suscripción. También configura los valores de diagnóstico del registro de actividad para enviar registros al área de trabajo de Log Analytics en la suscripción de administración.

    En lugar de repetir el código o las actividades manuales cuando se crea una nueva suscripción, la definición de directiva DeployIfNotExists los implementa y configura automáticamente.

¿Qué ocurre si no podemos o aún no estamos listos para usar directivas DeployIfNotExists (DINE)?

Tenemos una página dedicada que le guía por las distintas fases y opciones que tiene para "deshabilitar" las directivas DINE o usar nuestro enfoque de tres fases para adoptarlas con el tiempo en su entorno.

Consulte la guía de Adopción de barreras de protección controladas por directivas.

¿Debemos usar Azure Policy para implementar cargas de trabajo?

En pocas palabras, no. Use Azure Policy para controlar, gobernar y mantener la conformidad de las cargas de trabajo y las zonas de aterrizaje. No está diseñado para implementar cargas de trabajo completas ni otras herramientas. Use las ofertas de Azure Portal o de infraestructura como código (plantillas de ARM, Bicep o Terraform) para implementar y administrar la carga de trabajo y obtener la autonomía que necesita.

¿Qué son las zonas de aterrizaje de Cloud Adoption Framework para Terraform (aztfmod)?

El proyecto de código abierto (OSS) de zonas de aterrizaje de Cloud Adoption Framework (también conocidas como aztfmod) es un proyecto controlado por la comunidad, cuya propiedad y mantenimiento son externos al equipo principal de zonas de aterrizaje de Azure y la organización GitHub de Azure. Si en la organización deciden usar este proyecto de OSS, se debe tener en cuenta la compatibilidad disponible, ya que esto se basa en el esfuerzo de la comunidad mediante GitHub.

¿Qué ocurre si ya tenemos recursos en nuestras zonas de aterrizaje y, posteriormente, asignamos una definición de Azure Policy que los incluye en su ámbito?

Revise las secciones siguientes de la documentación:

¿Cómo se controlan las zonas de aterrizaje de carga de trabajo de desarrollo, pruebas y producción en la arquitectura de las zonas de aterrizaje de Azure?

Para más información, consulte Administración de entornos de desarrollo de aplicaciones en zonas de aterrizaje de Azure.

¿Por qué se nos pide que especifiquemos las regiones de Azure durante la implementación del acelerador de la zona de aterrizaje de Azure y para qué se usan?

Al implementar la arquitectura de zona de aterrizaje de Azure mediante la experiencia basada en el portal del acelerador de zona de aterrizaje de Azure, seleccione una región de Azure en la que realizar la implementación. La primera pestaña, Ubicación de implementación, determina dónde se almacenan los datos de la implementación. Para más información, consulte Implementaciones de inquilino con plantillas de ARM. Algunas partes de una zona de aterrizaje se implementan globalmente, pero se realiza un seguimiento de sus metadatos de implementación en un almacén de metadatos regional. Los metadatos relativos a su implementación se almacenan en la región seleccionada en la pestaña Ubicación de implementación.

El selector de regiones de la pestaña Ubicación de implementación también se usa para seleccionar en qué región de Azure debe almacenarse cualquier recurso específico de la región, como un área de trabajo de Log Analytics y una cuenta de automatización, si es necesario.

Si implementa una topología de redes en la pestaña Topología de red y conectividad, deberá seleccionar una región de Azure en la que implementar los recursos de redes. Esta región puede ser diferente de la región seleccionada en la pestaña Ubicación de la implementación.

Para obtener más información sobre las regiones que usan los recursos de la zona de aterrizaje, consulte Regiones de zona de aterrizaje.

¿Cómo se habilitan más regiones de Azure cuando se usa la arquitectura de zona de aterrizaje de Azure?

Para comprender cómo agregar nuevas regiones a una zona de aterrizaje o cómo mover los recursos de la zona de aterrizaje a otra región, consulte Regiones de zona de aterrizaje.

¿Deberíamos crear una nueva suscripción de Azure cada vez o volver a usar las suscripciones de Azure?

¿Qué es la reutilización de suscripciones?

La reutilización de suscripciones es el proceso de volver a emitir una suscripción existente a un nuevo propietario. Debe haber un proceso para restablecer la suscripción a un estado limpio conocido y, a continuación, reasignarla a un nuevo propietario.

¿Por qué debo considerar la reutilización de suscripciones?

En general, se recomienda que los clientes adopten el principio de diseño de democratización de las suscripciones. Sin embargo, hay circunstancias específicas en las que la reutilización de suscripciones no es posible ni recomendada.

Sugerencia

Observe el vídeo de YouTube sobre el principio de diseño de democratización de las suscripciones aquí: Zonas de aterrizaje de Azure: ¿cuántas suscripciones debo usar en Azure?

Debe considerar la reutilización de suscripciones si cumple una de las siguientes circunstancias:

  • Tiene un Contrato Enterprise (EA) y tiene previsto crear más de 5000 suscripciones en una única cuenta de propietario de la cuenta EA (cuenta de facturación), incluidas las suscripciones eliminadas.
  • Tiene un Contrato de cliente de Microsoft (MCA) o Microsoft Partner Agreement MPA y tiene previsto tener más de 5.000 suscripciones activas. Para obtener más información sobre los límites de suscripción, consulte Cuentas de facturación y ámbitos en Azure Portal.
  • Es un cliente de pago por uso.
  • Utiliza un Patrocinio de Microsoft Azure.
  • Normalmente crea:
    1. Entornos efímeros de laboratorio o espacio aislado
    2. Entornos de demostración para pruebas de concepto (POC) o productos mínimos viables (MVP), incluidos proveedores de software independientes (ISV) para el acceso de prueba o demostración de los clientes
    3. Entornos de entrenamiento, como los entornos de aprendizaje de los MSP y formadores

¿Cómo reutilizo las suscripciones?

Si coincide con uno de los escenarios o consideraciones anteriores, es posible que tenga que considerar la posibilidad de reutilizar las suscripciones existentes retiradas o sin usar y reasignarlas a un nuevo propietario y propósito.

Limpieza de una suscripción antigua

Primero, debe limpiar la suscripción antigua para reutilizarla. Debe realizar las siguientes acciones en una suscripción antes de que esté lista para su reutilización:

  • Quite los grupos de recursos y los recursos contenidos.
  • Quite las asignaciones de roles, incluidas las asignaciones de roles de Privileged Identity Management (PIM), en el ámbito de la suscripción.
  • Quite las definiciones de control de acceso basado en roles personalizados (RBAC) en el ámbito de la suscripción.
  • Quite las definiciones de directiva, las iniciativas, las asignaciones y las exenciones en el ámbito de la suscripción.
  • Quite las implementaciones en el ámbito de la suscripción.
  • Quite las etiquetas en el ámbito de la suscripción.
  • Quite los bloqueos de recursos en el ámbito de la suscripción.
  • Quite los presupuestos de Microsoft Cost Management en el ámbito de la suscripción.
  • Restablezca los planes de Microsoft Defender for Cloud a los niveles gratis, a menos que los requisitos de la organización exijan que estos registros estén establecidos en los niveles de pago. Normalmente, estos requisitos se aplican mediante Azure Policy.
  • Quite el reenvío de los registros de actividad de la suscripción (configuración de diagnóstico) a áreas de trabajo de Log Analytics, Event Hubs, cuentas de almacenamiento u otros destinos admitidos, a menos que los requisitos de la organización exijan el reenvío de estos registros mientras una suscripción está activa.
  • Quite las delegaciones de Azure Lighthouse en el ámbito de la suscripción.
  • Quite los recursos ocultos de la suscripción.

Sugerencia

El uso de Get-AzResource o az resource list -o table con destino en el ámbito de la suscripción le ayudará a encontrar los recursos ocultos o restantes para quitarlos antes de la reasignación.

Reasignación de la suscripción

Puede reasignar la suscripción después de limpiar la suscripción. Estas son algunas actividades comunes que puede que quiera realizar como parte del proceso de reasignación:

  • Agregue nuevas etiquetas y establezca valores para ellas en la suscripción.
  • Agregue nuevas asignaciones de roles, o asignaciones de roles de Privileged Identity Management (PIM), en el ámbito de la suscripción para los nuevos propietarios. Normalmente, estas asignaciones serían para grupos de Microsoft Entra en lugar de usuarios individuales.
  • Coloque la suscripción en el grupo de administración deseado en función de sus requisitos de gobernanza.
  • Cree nuevos presupuestos de Microsoft Cost Management y establezca alertas para los nuevos propietarios cuando se alcancen los umbrales.
  • Establezca los planes de Microsoft Defender for Cloud en los niveles deseados. Debe aplicar esta configuración mediante Azure Policy una vez colocados en el grupo de administración correcto.
  • Configure el reenvío de los registros de actividad de la suscripción (configuración de diagnóstico) a áreas de trabajo de Log Analytics, Event Hubs, cuentas de almacenamiento u otros destinos admitidos. Debe aplicar esta configuración mediante Azure Policy una vez colocados en el grupo de administración correcto.

La zona de aterrizaje soberana es un componente de Microsoft Cloud for Sovereignty que está destinado a los clientes del sector público que necesitan controles avanzados de soberanía. Como versión personalizada de la arquitectura conceptual de la zona de aterrizaje de Azure, la zona de aterrizaje soberana alinea las funcionalidades de Azure, como la residencia del servicio, las claves administradas por el cliente, Azure Private Link y la computación confidencial. A través de esta alineación, la zona de aterrizaje soberana crea una arquitectura en la nube donde los datos y las cargas de trabajo ofrecen cifrado y protección contra amenazas de forma predeterminada.

Nota:

Microsoft Cloud for Sovereignty está orientado a las organizaciones gubernamentales con necesidades de soberanía. Debe tener en cuenta detenidamente si necesita las funcionalidades de Microsoft Cloud for Sovereignty, a continuación, considere la posibilidad de adoptar la arquitectura de la zona de aterrizaje soberana.

Para más información sobre la zona de aterrizaje soberana, consulte Consideraciones de soberanía para las zonas de aterrizaje de Azure.