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.
Zona de aterrizaje multicuenta única frente a zona de aterrizaje multicuenta FAQs
Algunas preguntas frecuentes a la hora de elegir configurar una sola zona de aterrizaje multicuenta o varias zonas de aterrizaje multicuenta:
P1: ¿Puedo empezar con una sola zona de aterrizaje multicuenta y pasar a una zona de aterrizaje multicuenta si se encuentra algún límite de cuenta o restricciones empresariales?
R: Sí. Puedes elegir configurar otra landing zone multicuenta en cualquier momento:
Será necesario configurar una nueva cuenta de pagador de facturación (actualmente, AWS no admite cuentas de múltiples pagadores en una sola organización de AWS).
La creación de la base de una zona de aterrizaje multicuenta tarda hasta 2 semanas una vez que se complete el cuestionario sobre la zona de aterrizaje multicuenta.
Cada landing zone con varias cuentas supone una adición de unos 3000 USD al mes de coste de funcionamiento.
Será necesaria la integración de N/W, AD, DNS y SSO para establecer el nuevo MALZ.
Será necesario configurar cualquier instancia reservada (RIs) y planes de ahorro de costes para la nueva landing zone multicuenta (no RIs son transferibles).
La zona de aterrizaje multicuenta de AMS no admite la migración de una cuenta entre cuentas de zona de aterrizaje con varias cuentas; por ejemplo, entre organizaciones de AWS. Sin embargo, es posible mover aplicaciones de una cuenta a otra mediante métodos de migración estándar.
Q2: ¿Cuál es el enfoque de AMS respecto a la underlying/shared infraestructura y la cuantificación del riesgo updates/changes para los clientes con respecto a MALZ? Proporcione detalles sobre las garantías incluidas en el proceso. ¿Cómo se dan cuenta los clientes de que MALZ no updates/changes afectará a los clientes? ¿Hay alguna medida que el cliente deba tomar para evitar interrupciones?
R: AMS sigue una metodología de cambio estricta que utiliza herramientas internas que nos permiten definir, revisar, programar y ejecutar cambios en los entornos de los clientes.
El proceso de publicación de las actualizaciones exige la revisión del código, las pruebas de integración, el despliegue en entornos gamma y beta y un tiempo adicional de preparación y pruebas en los entornos beta y gamma antes de lanzarlas a los entornos de los clientes. Todas las versiones incluyen procedimientos de reversión y son supervisadas de cerca por el equipo de versiones y el equipo que creó y solicitó el cambio. El alcance de las versiones se limita a las pilas propiedad de AMS y aprovisionadas por esta. De media, ejecutamos al menos una versión por semana.
Además:
Se aplican los SLA de AMS. Según la descripción del servicio AMS, cualquier incidente que surja después de una actividad de mantenimiento de infraestructura compartida se regirá por el SLA correspondiente en materia de resolución o créditos.
Los clientes no requieren medidas preventivas especiales para evitar la interrupción de la infraestructura común. Los clientes tienen permisos de solo lectura en las cuentas de AWS Org o Core OU, por lo que no pueden realizar cambios destructivos en el entorno principal de MALZ. Todas las solicitudes de los clientes a la infraestructura principal requieren la revisión y aprobación de AMS.
Los clientes pueden probar ciertos cambios a nivel de la organización, por ejemplo, SCPs/Roles a nivel de cuentas individuales que no son de producción, antes de propagar los cambios a nivel de la OU de la aplicación. Está previsto en la hoja de ruta de AMS permitir el uso de varias aplicaciones OUs (segundo trimestre de 2020), lo que reduciría aún más el riesgo de realizar algunos de los cambios a nivel de la organización. El equipo de MALZ ya ha lanzado una unidad organizativa independiente para las cuentas del «modo de creación», a fin de garantizar una clara separación entre la propiedad de los clientes y unos controles separados.
La mayoría de estos cambios permiten a AMS gestionar la carga de trabajo de manera eficaz y eficiente y no afectan necesariamente a la carga de trabajo de los clientes. Cuando AMS cree que un cambio en la infraestructura compartida puede repercutir en la carga de trabajo de los clientes, opta por adaptarse al calendario de cambios de los clientes.
Recomendación de alto nivel: comience con varias zonas de destino con varias cuentas si:
Si le ayuda a lograr algún cumplimiento específico.
Si necesita usar Multi-Region.
Si tiene diferentes entornos locales ADs y redes para cargas de trabajo y para cargas de trabajo Prod/Material ajenas a ellas. Prod/Non-Material workloads, to clearly segregate b/w
