Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Construir zona de aterrizaje
AWS Transform lo guía a través del diseño y la implementación de una zona de AWS aterrizaje como parte de su proyecto de migración. Una zona de destino es un AWS entorno de varias cuentas que sirve de base para sus cargas de trabajo, ya que cuenta con límites organizativos, controles de gobierno y estructura de cuentas establecidos antes de que llegue cualquier carga de trabajo. AWS Transform analiza su inventario de migración y sus requisitos empresariales para recomendar una unidad organizativa (OU) y una estructura de cuentas, aplicar las políticas de control de servicios (SCP) recomendadas y generar la and/or implementación de la infraestructura como código (IaC). Lo que normalmente lleva semanas de planificación y configuración manuales, AWS Transform puede completarlo en una sola conversación.
El agente de la zona de aterrizaje automatiza dos fases:
-
Configuración básica: establezca la estructura principal de la zona de aterrizaje: la torre AWS de control, las unidades organizativas fundamentales y las cuentas principales.
-
Diseño de cuentas de carga de trabajo: diseñe y cree unidades organizativas y cuentas de carga de trabajo en función de las oleadas de migración, las unidades de negocio y los requisitos de separación de entornos.
AWS Transform es compatible tanto con entornos nuevos (sin zona de aterrizaje existente) como con entornos abandonados (unidades organizativas y cuentas existentes ya implementadas). En escenarios abandonados, AWS Transform detecta la estructura organizativa actual y solo recomienda los cambios necesarios para subsanar las deficiencias en relación con las AWS mejores prácticas, sin necesidad de empezar desde cero ni de realizar un análisis manual de las deficiencias.
Configuración del conector
Antes de que el agente pueda aprovisionar los recursos, debes conectarlo a la cuenta de administración de tu organización. El agente de la zona de destino necesita un Cuenta de AWS conector de destino con permisos para:
-
Configurar AWS Control Tower
-
Crea unidades organizativas y cuentas
-
Configure las políticas de control de servicios (SCP)
Cuando apruebas la solicitud del conector, concedes permisos de AWS transformación para:
-
Aprovisione y administre la infraestructura de la zona de aterrizaje en el destino Cuenta de AWS y la región. Esto incluye los permisos para los siguientes elementos, restringidos a los recursos etiquetados con
CreatedBy:AWSTransformy por,ATWorkspace:{workspace-id}cuando corresponda:-
Operaciones de bucket de S3 (crear, leer, escribir, eliminar) para los buckets que comienzan con
transform-vmware-landing-zone- -
CloudFormation despliegues de pilas y gestión de conjuntos de cambios para pilas de zonas de destino
-
AWS Operaciones de la torre de control (administrar las zonas de aterrizaje, habilitar las líneas de base y los controles)
-
AWSAdministración de organizaciones (creación y administración de unidades organizativas, creación de cuentas y traslado de cuentas)
-
Administración de políticas de control de servicios (SCP) mediante AWS Control Tower
-
AWS Gestión de artefactos de aprovisionamiento de catálogos de servicios
-
Al crear el conector, se especifica un objetivo. Región de AWS Esta región debe ser la misma que la región de su torre de control local. Para obtener más información sobre las regiones de Control Tower, consulta Cómo Regiones de AWS trabajar con AWS Control Tower.
Al inicio de la configuración de la zona de aterrizaje, AWS Transform recupera la configuración del conector y presenta el identificador de la cuenta de administración de la AWS organización y la región de destino para su confirmación. Para obtener más información, consulte AWS Transforme los conectores.
importante
Dependencia regional del centro de identidad de IAM: AWS Transform requiere el AWS IAM Identity Center (centro de identidad de IAM), lo que significa que la región del conector debe coincidir tanto con la región de origen de AWS Control Tower como con la región del centro de identidad de IAM. Si el IAM Identity Center ya está configurado en tu organización, la inicialización de AWS Control Tower fallará si el conector apunta a una región diferente. Para obtener más información, consulte las consideraciones para los clientes de IAM Identity Center en la guía del usuario de AWS Control Tower.
Configuración básica
La fase de configuración básica establece la infraestructura principal de la zona de aterrizaje mediante AWS Control Tower. Cuando AWS Control Tower configura una zona de aterrizaje, aprovisiona automáticamente un conjunto de recursos administrados en su cuenta de administración que forman la base de gobierno de toda AWS la organización:
-
Raíz: la instancia principal de nivel superior que contiene todas las unidades organizativas de tu zona de destino.
-
Unidad organizativa de seguridad: Control Tower la crea automáticamente. Contiene dos cuentas compartidas: la cuenta Log Archive (registro centralizado e inmutable de toda la actividad de la AWS API y los cambios en los recursos de la organización) y la cuenta Audit (acceso de solo lectura a todas las cuentas para revisar la seguridad y el cumplimiento). Estas cuentas no se pueden cambiar de nombre ni reemplazar después de la configuración inicial.
-
Controles obligatorios (barreras de protección): Control Tower aplica automáticamente controles preventivos y de detección en toda la organización para hacer cumplir las políticas de gobierno básicas. No se pueden desactivar.
-
Directorio del IAM Identity Center: Control Tower crea un directorio nativo de la nube con grupos preconfigurados y acceso de inicio de sesión único para los usuarios de la zona de destino. Para obtener más información, consulte IAM Identity Center. AWS
Control Tower utiliza estos recursos CloudFormation StackSets para implementar y administrar de manera uniforme en todas las cuentas y regiones de su organización. No debes modificar ni eliminar los recursos administrados de Control Tower fuera de los métodos admitidos, ya que esto puede provocar que tu zona de destino pase a un estado desconocido.
Convención de correo electrónico de cuentas
AWS requiere una dirección de correo electrónico única para cada cuenta. Estos correos electrónicos reciben notificaciones importantes para la cuenta. AWS Transform utiliza el direccionamiento adicional para generar correos electrónicos de cuenta únicos desde un único buzón.
Formato: prefix+account-name@domain
Usted proporciona un prefijo (por ejemploaws-admin) y un dominio (por ejemplo,acme.com), y AWS Transform obtiene automáticamente todos los correos electrónicos de la cuenta. Por ejemplo:
-
Cuenta de auditoría:
aws-admin+audit@acme.com -
Cuenta de Log Archive:
aws-admin+log-archive@acme.com -
Cuenta Sandbox:
aws-admin+sandbox@acme.com
En escenarios abandonados, AWS Transform inspecciona los correos electrónicos de las cuentas existentes para deducir la convención de direcciones positivas que ya está en uso y ofrece continuar con el mismo patrón.
Estructura básica recomendada
Basándose en las AWS mejores prácticas, AWS Transform recomienda la siguiente estructura básica de unidades organizativas. Puede personalizarla antes de crearla.
| OU | Finalidad | Cuentas |
|---|---|---|
| Seguridad | Registro y supervisión de auditorías centralizados. El aislamiento de estos servicios en cuentas dedicadas está diseñado para ayudar a mantener el registro de auditoría separado del de los equipos que se ocupan de la carga de trabajo. | Auditoría, archivo de registros |
| Infraestructura | Redes compartidas (Transit Gateway, VPN), DNS y servicios comunes. Se recomienda centralizarlos para ayudar a reducir la duplicación y ofrecer a su equipo de red un único lugar para administrar la conectividad. | Ninguno (creado vacío) |
| Entorno de pruebas | Experimentación por parte de los desarrolladores con los límites de gasto y el acceso restringido. Se recomienda para dar a los desarrolladores un espacio para experimentar sin poner en riesgo los recursos de producción. | Entorno de pruebas |
| Cargas de trabajo | Contiene subunidades organizativas de producción y Non-Production, opcionalmente, suboficiales reguladas. Las cuentas de carga de trabajo se diseñan en la siguiente fase en función de sus requisitos de migración. | Ninguna (se creó vacía) |
nota
La unidad organizativa de seguridad con cuentas de auditoría y archivo de registros se crea como parte de la configuración básica de Control Tower. Las unidades organizativas de infraestructura, espacio aislado y cargas de trabajo se crean por separado después de confirmar la estructura.
En escenarios abandonados, AWS Transform compara la base existente con esta estructura recomendada e informa solo de las brechas. Por ejemplo: «Su base tiene unidades organizativas de seguridad e infraestructura, pero no una unidad organizativa de entorno aislado».
Políticas de control de servicios (SCP)
Los SCP son barreras de protección de permisos a nivel de organización que establecen los permisos máximos para todas las cuentas de la organización. AWS No conceden el acceso, sino que definen límites que nadie de la cuenta puede superar, ni siquiera los administradores de la cuenta.
Como parte del despliegue de la Torre de Control, las barreras básicas se aplican automáticamente. AWS Transform también recomienda SCP adicionales diseñados para ayudar a fortalecer la posición de su organización. Estos se basan en las AWS mejores prácticas para una zona de aterrizaje mínima viable.
Los SCP se pueden aplicar a las unidades organizativas de infraestructura, sandbox y cargas de trabajo. La unidad organizativa de seguridad está gestionada por Control Tower y los SCP no pueden utilizarla como objetivo a través de esta herramienta.
importante
La unidad organizativa de seguridad es una unidad organizativa básica administrada por Control Tower. No puedes agregarle cuentas, SCP ni ningún recurso a través del agente de la zona de aterrizaje.
En escenarios abandonados, AWS Transform comprueba qué SCP ya se han aplicado y solo recomienda aquellos que podrían cubrir las brechas.
Implementación básica
Una vez finalizado el diseño de la base, usted elige cómo implementar:
-
Implemente para mí: AWS Transform implementa las unidades organizativas, las cuentas y los SCP básicos en su AWS organización.
-
Lo implementaré por mi cuenta: AWS Transform genera artefactos de infraestructura como código (IaC) para descargarlos en el formato que prefiera (consulte). Formatos IaC
-
Diseñe primero las cuentas de carga de trabajo: omita la implementación y continúe con la fase de diseño de las cuentas de carga de trabajo. Puede implementarlo todo junto más adelante.
Inicialización de la torre de control
Si AWS Transform detecta que AWS Control Tower aún no se ha inicializado en su organización, proporciona al usuario un enlace a la página de la consola de AWS Transform. Al generar la operación en el enlace, se creará una CloudFormation pila para arrancar Control Tower. El proceso creará esta pila en la CloudFormation consola para la región de destino. Una vez finalizada la creación de la pila, AWS Transform continúa con la implementación.
Diseño de cuentas de carga de trabajo
En la fase de diseño de la cuenta de carga de trabajo, AWS Transform diseña la OU y la estructura de cuentas para las cargas de trabajo de las aplicaciones en función del inventario de migración, los requisitos empresariales y las preferencias de separación de entornos.
Contexto de planificación de la migración
AWS Transform recupera los datos de la fase de planificación de la migración, incluidos los planes de oleaje, las asignaciones de servidor a aplicación y el contexto compartido. Si hay datos de planificación de la migración disponibles, AWS Transform muestra un resumen y le pide que lo confirme o lo ajuste. Si no hay datos de planificación de la migración disponibles, AWS Transform formula directamente las preguntas de descubrimiento.
Discovery
AWS Transform hace preguntas para comprender sus requisitos de carga de trabajo. Puede omitir cualquier pregunta. Los temas incluyen:
-
Número de unidades de negocio o equipos que utilizan AWS
-
La industria y cualquier marco aplicable (HIPAA, SOC2 PCI-DSS, FedRAMP)
-
Si las cargas de trabajo manejan datos confidenciales (PII, PHI, financieros)
-
Preferencias de separación de entornos (dev/test/staging/prod como cuentas separadas o compartidas)
-
Requisitos de aislamiento de cargas de trabajo
-
Las aplicaciones empresariales y sus propósitos
-
Agrupación de servidores en aplicaciones
-
Necesidades de seguimiento y asignación de costos (por unidad de negocio, proyecto, entorno)
-
Crecimiento esperado en los próximos 12 a 24 meses
-
Preferencia de estrategia de cuenta (aplicación única por cuenta, agrupada o basada en el entorno)
Estructura de carga de trabajo propuesta
Basándose en sus respuestas y en los datos de planificación de la migración, AWS Transform propone una estructura de unidades organizativas y cuentas en el marco de la unidad organizativa de cargas de trabajo. La propuesta incluye el razonamiento detrás de cada decisión de diseño.
AWS Transform sigue estos principios de diseño:
-
Todos los servidores de una oleada de migración van a la misma cuenta; las oleadas no se pueden dividir entre cuentas. Se trata de una limitación de realojamiento durante la ejecución de la oleada.
-
Si solicita entornos aislados, AWS Transform crea una Workloads/Non-Production subunidad Workloads/Production organizativa.
-
Si se identifican los marcos aplicables, AWS Transform crea una Workloads/Standard subunidad Workloads/Regulated organizativa.
-
Si varias unidades de negocio requieren un gobierno diferente, AWS Transform crea unidades organizativas específicas para cada unidad de negocio en el marco de las cargas de trabajo.
-
Las aplicaciones de datos críticos o confidenciales reciben una sola aplicación por cuenta. En este caso, es posible que se te pida que repitas tu plan de oleaje.
-
Las aplicaciones estrechamente conectadas con dependencias compartidas se agrupan en una sola cuenta.
Cada cuenta propuesta incluye: nombre, propósito, unidad organizativa de destino y unidad de negocio. AWS La transformación muestra la convención de nomenclatura que se está utilizando (por ejemplo,<business-unit>-<environment>-<workload>).
Puede revisar y modificar la estructura propuesta antes de que AWS Transform aplique los cambios. Después de la solicitud, puede iterar y realizar cambios adicionales hasta que esté satisfecho.
Configuración SCP de la carga de trabajo
Una vez creada la estructura de la carga de trabajo, AWS Transform presenta los SCP disponibles y le pregunta si desea aplicar alguno a las unidades organizativas de su carga de trabajo. Usted selecciona qué SCP desea aplicar y a qué unidades organizativas. AWS Transform aplica los SCP y muestra el árbol organizativo actualizado con una tabla resumida de los SCP.
Despliegue de cargas
Una vez finalizado el diseño de la carga de trabajo, usted elige cómo implementar:
-
Implemente para mí: AWS Transform implementa las unidades organizativas, las cuentas y los SCP de la carga de trabajo en su AWS organización.
-
Lo implementaré por mi cuenta: AWS Transform genera artefactos de IaC para descargarlos en el formato que prefiera (consulte). Formatos IaC
Formatos IaC
Si elige la implementación automática, AWS Transform genera artefactos de infraestructura como código en los siguientes formatos:
-
Kit de desarrollo de la nube de AWS (AWS CDK)— TypeScript proyecto para el despliegue programático de la infraestructura.
-
HashiCorp Terraform: genera plantillas de lenguaje HashiCorp de configuración (HCL) para administrar los recursos de la zona de aterrizaje.
-
Landing Zone Accelerator (LZA): archivos YAML de configuración basados en la versión 1.1.0 de LZA Universal Configuration. Estas plantillas aptas para empresas funcionan con el Landing Zone Accelerator activado para establecer entornos con varias cuentas. AWS AWS Los archivos generados incluyen ajustes preconfigurados para la gobernanza, la estructura organizativa y las redes que se alinean con las mejores prácticas. AWS Para obtener más información, consulte Configuración universal de LZA.
nota
Al realizar la implementación a través del canal Landing Zone Accelerator (LZA), la cuenta de AWS Transform y la instalación de LZA deben estar en la misma organización. AWS La implementación fallará si no coinciden los ID de la organización utilizados en AWS Transform y en LZA. Para obtener información sobre cómo configurar la instalación de LZA mediante Organizations, consulte Instalación basada en AWS organizaciones.
Tras seleccionar un formato, AWS Transform genera los artefactos y los pone a disposición para su descarga.
Para comprobar que el archivo descargado no está dañado ni alterado, genera y descarga una suma de comprobación y, a continuación, compárala con un hash generado localmente mediante:
openssl dgst -sha256 -binary <file.zip> | base64
Proceso de aprobación de la implementación
Las solicitudes de despliegue en la zona de destino requieren una aprobación explícita antes de su ejecución. Cuando envías una solicitud de despliegue, esta se dirige automáticamente a los aprobadores autorizados a través de la pestaña AWS Transform Aprobations.
Los aprobadores revisan las CloudFormation plantillas y las configuraciones de las zonas de destino. Solo los usuarios con el rol de administrador en AWS Transform pueden aprobar las solicitudes de implementación. Cada envío desencadena un nuevo ciclo de revisión y las implementaciones solo continúan después de recibir la confirmación.
Si un aprobador rechaza tu solicitud, ponte en contacto con él directamente para analizar las modificaciones necesarias. El sistema hace un seguimiento de todas las decisiones de aprobación con fines de auditoría y mantiene el historial de implementación.
Etiquete los recursos de la zona de aterrizaje
AWS Transform etiqueta automáticamente todos los recursos generados, "CreatedBy": "AWSTransform" junto con los identificadores de definición y ejecución, con fines de seguimiento.
Etiquetas automáticas
Todos los recursos de la zona de aterrizaje reciben las siguientes etiquetas:
-
CreatedBy— AWS Transform -
ATWorkspace— Identificador del espacio de trabajo
nota
Si su migración forma parte del programa de aceleración de la AWS migración (MAP 2.0), puede incluir la etiqueta MAP requerida: clave: map-migrated valor: migMPE_ID (donde MPE_ID es el identificador de evaluación de su cartera de migración). La etiqueta MAP se solicita durante la fase de configuración del conector. AWS Transform aplica estas etiquetas durante el despliegue de la zona de aterrizaje.
Revertir los cambios
Solo se pueden eliminar los elementos no desplegados. Una vez que se implementa una unidad organizativa o una cuenta, no se puede eliminar a través del agente de la zona de destino.
A la hora de eliminar elementos, el orden es importante: debes eliminar a los niños antes que a los padres:
-
Elimina primero las cuentas (por correo electrónico).
-
Elimina los SCP de las unidades organizativas.
-
Eliminar las unidades organizativas secundarias: una unidad organizativa no se puede eliminar si aún tiene cuentas o unidades organizativas anidadas.
Recursos relacionados
