Preguntas frecuentes sobre la zona de aterrizaje de Azure (P+F)

Las preguntas más frecuentes sobre la arquitectura de zona de aterrizaje de Azure se responden en este artículo.

Para obtener respuestas a preguntas frecuentes sobre la implementación de la arquitectura de zona de aterrizaje de Azure, consulte Preguntas más frecuentes sobre la implementación a escala empresarial.

¿Cuál es el acelerador del portal de zona de aterrizaje de Azure?

El acelerador del portal de la zona de aterrizaje de Azure es una experiencia de implementación basada en el Azure portal. Implementa una implementación predefinida basada en la arquitectura de referencia de zona de inicio de Azure.

¿Cuáles son los aceleradores e implementaciones recomendados para Azure zonas de aterrizaje?

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

Revise la guía de Deploy Azure landing zones para obtener más información sobre las zonas de aterrizaje de aplicación y plataforma recomendadas.

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

¿Cuál es la arquitectura de referencia de zona de aterrizaje Azure?

La arquitectura de referencia de zona de aterrizaje Azure representa decisiones de escala y madurez. Se basa en las lecciones aprendidas y los comentarios de los clientes que adoptaron 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 zonas de aterrizaje de Azure?

Desde la perspectiva de una zona de aterrizaje de Azure, las zonas de aterrizaje son suscripciones individuales de Azure.

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

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

La gobernanza impulsada por políticas significa usar Azure Policy para reducir el tiempo necesario para las tareas operativas comunes y repetitivas en tu inquilino de Azure. Use muchos de los efectos Azure Policy, por ejemplo, Append, Deny, DeployIfNotExists y Modify, para evitar el incumplimiento al restringir los recursos no compatibles (tal como se define en la definición de directiva) desde la creación o actualización de recursos o mediante la implementación o modificación de recursos o la modificación de una solicitud de creación o actualización de recursos para que sean compatibles. Algunos efectos, como Audit, Disabledy AuditIfNotExists, no impiden ni toman medidas; solo auditan e informan sobre el incumplimiento.

Algunos ejemplos de gobernanza controlada por directivas son:

• Deny efecto: impide que las subredes se creen o actualicen para que no tengan asociados grupos de seguridad de red.

• DeployIfNotExists efecto: se crea una nueva suscripción (zona de aterrizaje) y se coloca en un grupo de administración dentro de la implementación de la zona de aterrizaje de Azure. Azure Policy garantiza que Microsoft Defender for Cloud esté habilitado en la suscripción. También configura las opciones de diagnóstico para que el registro de actividad envíe registros al área de trabajo de Log Analytics en la suscripción de administración.

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

¿Qué ocurre si aún no podemos o 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 inhabilitar las políticas de DINE o para usar nuestro enfoque de tres fases con el fin de adoptarlas con el tiempo dentro de su entorno.

Consulte las instrucciones sobre la adopción de barreras de protección impulsadas por directivas.

¿Deberíamos usar Azure Policy para implementar cargas de trabajo?

En resumen, no. Use Azure Policy para controlar, controlar y mantener las cargas de trabajo y las zonas de aterrizaje conformes. No está diseñado para implementar cargas de trabajo completas y otras herramientas. Utilice el portal de Azure o las soluciones de infraestructura como código (plantillas de ARM, Bicep, Terraform) para implementar y administrar su carga de trabajo y obtener la autonomía que necesita.

Zonas de aterrizaje del Cloud Adoption Framework para Terraform (aztfmod)

Las zonas de aterrizaje del Cloud Adoption Framework proyecto de código abierto (OSS) (también conocido como aztfmod) es un proyecto dirigido por la comunidad que pertenece a y se mantiene fuera del equipo central de la zona de aterrizaje de Azure y la organización de GitHub de Azure. Si su organización decide usar este proyecto de sistema operativo, se debe tener en cuenta la compatibilidad disponible, ya que esto se basa en el esfuerzo de la comunidad a través de GitHub.

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

Revise las secciones de documentación siguientes:

• Migrar los entornos de Azure existentes a la arquitectura de referencia de zona de inicio de Azure: la sección "Directiva"
• Inicio rápido: Creación de una asignación de directiva para identificar recursos no compatibles: sección "Identificación de recursos no compatibles"

¿Necesito una zona de aterrizaje de IA dedicada o independiente?

No, no necesita una zona de aterrizaje de IA independiente. En su lugar, puede usar la arquitectura de zona de aterrizaje de Azure existente para implementar cargas de trabajo de IA. Consulte las instrucciones y la explicación en AI en las zonas de aterrizaje de Azure.

¿Cómo gestionamos las zonas de aterrizaje de carga de trabajo para desarrollo/pruebas/producción en la arquitectura de zona de aterrizaje de Azure?

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

¿Por qué se pide que especifique las regiones de Azure durante la implementación de la arquitectura de referencia de la zona de aterrizaje de Azure y para qué se usan?

Al implementar la arquitectura de zona de aterrizaje de Azure a través de la experiencia del portal basada en la arquitectura de referencia de la zona de aterrizaje de Azure, seleccione una región de Azure para implementar. La primera pestaña, Ubicación de implementación, determina dónde se almacenan los datos de implementación. Para obtener más información, consulte Desplegues de entornos 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 relacionados con 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 Ubicación de implementación también se usa para seleccionar en qué región de Azure se deben almacenar los recursos específicos de la región, como un espacio de trabajo de Log Analytics, si es necesario.

Si implementa una topología de red en la pestaña Red y conectividad, debe seleccionar una región de Azure para implementar los recursos de red. Esta región puede ser diferente de la región seleccionada en la pestaña Ubicación de implementación .

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

¿Cómo podemos habilitar más regiones de Azure cuando usamos la arquitectura de zona de aterrizaje de Azure?

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

¿Deberíamos crear una nueva suscripción Azure cada vez o deberíamos volver a usar Azure Suscripciones?

¿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, reasignarse 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 la suscripción. Sin embargo, hay circunstancias específicas en las que la reutilización de suscripciones no es posible ni recomendada.

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

• Tiene un Acuerdo Empresarial (EA) y tiene previsto crear más de 5000 suscripciones en una sola cuenta de Propietario de Cuenta EA (cuenta de facturación), incluidas las suscripciones que se hayan eliminado.
• Tiene una Contrato de cliente de Microsoft (MCA) o Microsoft Partner Agreement MPA y tiene previsto tener más de 5000 suscripciones activas. Para obtener más información sobre los límites de suscripción, consulte Cuentas de facturación y ámbitos en el portal de Azure.
• Es un cliente de pago por uso.
• Utilizas un patrocinio de Microsoft Azure.
• Normalmente crea:
  1. Entornos de laboratorio o sandbox efímero
  2. Entornos de demostración para pruebas de concepto (POC) o productos viables mínimos (MVP), incluidos proveedores de software independientes (ISV) para el acceso de demostración o prueba de clientes
  3. Entornos de entrenamiento, como los entornos de aprendizaje de MSP/Trainer

¿Cómo se reutilizan 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 la suscripción antigua

Primero debe limpiar la suscripción anterior para su reutilización. 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.
• Eliminar asignaciones de roles, incluyendo las correspondientes a Privileged Identity Management (PIM), desde el ámbito de la suscripción.
• Elimine las definiciones de control de acceso basado en roles personalizados (RBAC) en el nivel de 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.
• Elimine 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 Microsoft Defender for Cloud planes a niveles gratis a menos que los requisitos de la organización exijan que estos registros se establezcan en los niveles de pago. Normalmente, aplica estos requisitos a través de Azure Policy.
• Retire el reenvío de registros de actividad de suscripción (configuración de diagnóstico) a Log Analytics Workspaces, Event Hubs, Cuenta de Almacenamiento u otros destinos soportados, a menos que los requisitos de la organización exijan el reenvío de estos registros mientras una suscripción esté activa.
• Elimine las delegaciones de Azure Lighthouse en el alcance de la suscripción.
• Quite los recursos ocultos de la suscripció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 desee realizar como parte del proceso de reasignación:

• Agregue nuevas etiquetas y establezca valores para ellos en la suscripción.
• Agregue nuevas asignaciones de roles o asignaciones de roles de Gestión de Identidades Privilegiadas (PIM) en el ámbito de la suscripción para los nuevos propietarios. Normalmente, estas asignaciones serían a grupos de Microsoft Entra en lugar de a individuos.
• 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 en los nuevos propietarios cuando se cumplan los umbrales.
• Establezca los planes de protección de Microsoft Defender for Cloud en los niveles deseados. Debe aplicar esta configuración a través de Azure Policy una vez colocado en el grupo de administración correcto.
• Configurar el reenvío de registros de actividad de suscripción (configuraciones de diagnóstico) a áreas de trabajo de Log Analytics, Centros de eventos, Cuenta de Almacenamiento u otros destinos admitidos. Debe aplicar esta configuración a través de Azure Policy una vez colocado en el grupo de administración correcto.

¿Qué es una zona de aterrizaje soberana y cómo está relacionada con la arquitectura de la zona de aterrizaje de Azure?

La zona de aterrizaje soberana es un componente de Microsoft nube soberana que está pensada para los clientes del sector público que necesitan controles avanzados de soberanía. Como versión personalizada de la arquitectura de referencia de la zona de aterrizaje de Azure, la zona de aterrizaje soberana se alinea con las funcionalidades de Azure, como la residencia de servicios, 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.

Para obtener más información sobre la zona de aterrizaje soberana, consulte Zona de aterrizaje soberana (SLZ).