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.
Tipos de modos y cuentas en AMS
Los modos AWS Managed Services (AMS) se pueden definir como las formas de interactuar con el servicio AMS en el marco de gobierno específico de cada modo. Se anotan las diferencias de zona de aterrizaje, zona de aterrizaje multicuenta o MALZ y zona de aterrizaje de cuenta única o SALZ.
nota
Para obtener más información sobre la implementación de aplicaciones y la elección del modo AMS correcto, consulte Modos AMS y aplicaciones o cargas de trabajo.
Para ver casos de uso reales de los distintos modos, consulte Casos de uso reales de los modos AMS
La siguiente tabla proporciona descripciones de los modos por servicio AMS.
| Función AMS | Modo RFC (anteriormente modo CM estándar)/OOD * | Modo de cambio directo | AWS Service Catalog | Self-service modo aprovisionamiento/desarrollador | Gestionado por el cliente |
|---|---|---|---|---|---|
| Configuración de la zona de aterrizaje | MALZ y SALZ | MALZ y SALZ | MALZ y SALZ | ||
| Administración de cambios | Programación de cambios, revisión de los cambios manuales y registro de cambios | Igual que el modo RFC para cambios de alto riesgo, como los de IAM o los grupos de seguridad | Ninguno | ||
| Registro, supervisión, barandas y gestión de eventos | Sí (recursos compatibles) | No | |||
| Gestión de la continuidad | Sí (recursos compatibles) | No aplicable/No | No | ||
| Administración de la seguridad | Controles de seguridad a nivel de instancia y controles a nivel de cuenta | Controles a nivel de cuenta | Controles a nivel de organización de AWS | ||
| Administración de parches | Sí | No aplicable/No | No | ||
| Administración de incidentes y problemas | SLA de respuesta y resolución para los recursos compatibles con AMS | SLA de respuesta para los recursos resultantes | No | ||
| Informes | Sí | No | |||
| Gestión de solicitudes de servicio | Sí | Solo solicitudes de soporte | No | ||
* Operations On Demand (OOD) ofrece a los clientes que utilizan el modo RFC para gestionar sus cambios mediante una dotación de recursos específica. Para obtener más información, consulte el catálogo de ofertas de Operations on Demand y hable con su gerente de prestación de servicios en la nube (CSDM).
nota
Modo de aprovisionamiento de autoservicio en AMSy ambos Modo AMS Advanced Developer pueden parecer adecuados para una aplicación que tiene una arquitectura compleja basada en los servicios nativos de AWS. Al diseñar la arquitectura de las cargas de trabajo, debe hacer concesiones entre la excelencia operativa y la agilidad, en función del contexto empresarial. Esta es una buena forma de pensar en seleccionar el modo SSP o el modo Desarrollador para su aplicación. La selección también puede cambiar en función de la fase de SDLC de la aplicación. Por ejemplo: cuando la aplicación esté lista para la producción, el modo SSP puede ser una opción más adecuada debido a que las barandillas AMS son más estrictas en este modo. Las barreras se imponen en forma de controles preventivos, como el control de RFC-based cambios para las actualizaciones de IAM y los SCP a nivel de la unidad organizativa de la aplicación. Estas decisiones de negocio puede impulsar sus prioridades de diseño. Se puede optimizar para aumentar la flexibilidad de los propietarios de las aplicaciones en la fase «previa a la producción», en detrimento de la gobernanza y el soporte operativo.
Arquitectura MALZ y modos AMS asociados
La zona de aterrizaje multicuenta (MALZ) de AMS le ofrece la opción de aprovisionar automáticamente cuentas de aplicaciones (o cuentas de recursos) en las unidades organizativas (OU) predeterminadas: OU gestionada por el cliente, OU gestionada o OU de desarrollo. La infraestructura aprovisionada en las cuentas de aplicación creadas en cada una de estas OU está sujeta al modo AMS específico que ofrecen esas OU fundamentales. Es habitual encontrar una combinación de dos o más modos en la misma cuenta de aplicación. Por ejemplo: el modo RFC y el modo SSP pueden coexistir en una cuenta gestionada por AMS que aloje una arquitectura de canalización compuesta por API Gateway y Lambda para las funciones de activación, y EC2, S3 y SQS para la ingesta y la organización. En este caso, el modo SSP se aplicaría a Lambda y API Gateway.
En la figura 1, se muestra cómo se ofrecen los diferentes modos a través de las unidades organizativas fundamentales de AMS. Al solicitar una nueva cuenta de aplicación en AMS, debe seleccionar la OU de la cuenta.
Arquitectura MALZ y modos AMS asociados
.png)
AMS aprovecha las unidades organizativas fundamentales basadas en las prácticas recomendadas de AWS para gestionar las cuentas de forma lógica mediante políticas de control de servicios (SCP). Esto sirve como una forma de reforzar el marco de gobierno con cada modo de AMS. Todas las barreras de control y seguridad (en forma de SCP) que se apliquen a las unidades organizativas fundamentales también se aplican automáticamente a las unidades organizativas. custom/child Se pueden solicitar SCP adicionales para las unidades organizativas secundarias. Es importante entender que las cuentas de aplicación no son lo mismo que las de los modos. Los modos se aplican a la infraestructura aprovisionada en las cuentas y definen las responsabilidades operativas entre AMS y los clientes.
Figura 1: Arquitectura MALZ y modos AMS asociados
nota
«Restrictivo» implica que se pueden solicitar políticas personalizadas para estas unidades organizativas. AMS las aprueba caso por caso para garantizar que no interfieran en las capacidades de AMS de ofrecer la excelencia operativa. Para obtener una lista detallada de las barandillas AMS, consulte las barandillas AMS en la guía del usuario.
