Casos de uso reales para los modos AMS

Caso de uso 1: el imperativo empresarial de reducir los costes con una salida urgente del centro de datos: una empresa que se enfrenta a un acontecimiento empresarial convincente, como la salida de un centro de datos, está interesada en realojar sus aplicaciones locales en la nube. La mayor parte del inventario local consiste en servidores Windows y Linux con una combinación de versiones de sistemas operativos. De este modo, el cliente también quiere aprovechar los ahorros de costes que ofrece la migración a la nube y mejorar el aspecto técnico y de seguridad de sus aplicaciones. El cliente quiere avanzar con rapidez, pero aún no cuenta con la experiencia interna necesaria en operaciones en la nube. El cliente debe encontrar un equilibrio entre la refactorización, ya que una refactorización excesiva puede resultar arriesgada si se tiene en cuenta un plazo ajustado. Sin embargo, con algunas refactorizaciones, como la actualización de las versiones del sistema operativo y la optimización de las bases de datos, las aplicaciones pueden alcanzar el siguiente nivel de rendimiento. En este ejemplo, el cliente puede seleccionar el modo RFC administrado por AMS para volver a alojar la mayoría de sus aplicaciones. AMS proporciona operaciones de infraestructura y, al mismo tiempo, orienta a los equipos de operaciones del cliente sobre las mejores prácticas para operar de forma segura en la nube.

El AWS Service Catalog administrado por AMS y el modo Direct Change administrado por AMS ofrecen al cliente una flexibilidad adicional y, al mismo tiempo, logran los mismos resultados y objetivos empresariales. Además, el cliente puede utilizar la oferta Operations On Demand (OOD) de AMS para contar con ingenieros de operaciones de AMS dedicados a priorizar la ejecución de las solicitudes de cambio (). RFCs

Además de delegar las tareas operativas indiferenciadas de la infraestructura (aplicación de parches, copias de seguridad, administración de cuentas, etc.) a AMS, el cliente puede seguir centrándose en optimizar su aplicación y en ampliar sus equipos internos a las operaciones en la nube. AMS proporciona informes mensuales al cliente sobre el ahorro de costes y hace recomendaciones sobre la optimización de los recursos. En este caso de uso, si había end-of-life aplicaciones alojadas en versiones antiguas del sistema operativo, como Windows 2003 y 2008, que el cliente decidió no volver a factorizar, también se pueden migrar a AMS y alojarse en una cuenta que utilice el modo administrado por el cliente.

Caso de uso 2: creación de un lago de datos con Lambda, Glue y Athena dentro del límite seguro de AMS: una empresa busca configurar un lago de datos para satisfacer las necesidades de informes de múltiples aplicaciones en AMS. El cliente quiere usar depósitos de S3 para el almacenamiento de conjuntos de datos y AWS Athena para realizar consultas en el conjunto de datos de cada informe. S3 y AWS Athena se implementarán en cuentas administradas por AMS independientes. La cuenta de S3 también incluye otros servicios, como Glue, Lambda y Step Functions, para crear una canalización de ingesta de datos. En este caso, Glue, Lambda, Athena y Step Functions se consideran servicios de autoservicio (SSP). El cliente también implementó una EC2 instancia en la cuenta que actúa como servidor ad hoc. tooling/scripting El cliente comienza por solicitar a AMS que habilite los servicios SSP en su cuenta gestionada por AMS. AMS proporciona una función de IAM para cada servicio que el cliente puede asumir, una vez que la función se ha incorporado a la solución de federación del cliente. Para facilitar la administración, el cliente también puede combinar las políticas de las distintas funciones de IAM en una sola función personalizada, lo que reduce la necesidad de cambiar de función al trabajar entre los servicios de AWS. Una vez que la función esté habilitada en la cuenta, el cliente podrá configurar los servicios según sus necesidades. Sin embargo, el cliente debe trabajar con el sistema de gestión de cambios AMS para solicitar permisos adicionales, según su caso de uso.

Por ejemplo, para acceder a Glue Crawlers, Glue necesita permisos adicionales. También se necesitarán permisos adicionales para crear fuentes de eventos para Lambda. El cliente trabajará con AMS para actualizar las funciones de IAM y permitir el acceso entre cuentas para que Athena consulte los buckets de S3. También será necesario actualizar las funciones de servicio o las funciones vinculadas a servicios mediante la administración de cambios de AMS para que Lambda llame al servicio Step Functions y Glue para leer y escribir en todos los buckets de S3. AMS trabaja con los clientes para garantizar que se siga el modelo de acceso con menos privilegios y que los cambios de IAM solicitados no sean excesivamente permisivos y expongan el entorno a riesgos innecesarios. El equipo del lago de datos del cliente dedica tiempo a planificar todos los permisos de IAM necesarios para los servicios específicos de la arquitectura del cliente y solicita a AMS que los habilite. Esto se debe a que todos los cambios de IAM se procesan manualmente y son revisados por el equipo de seguridad de AMS. El tiempo necesario para procesar estas solicitudes debe tenerse en cuenta en el cronograma de implementación de la aplicación.

Como los servicios del SSP están operativos en la cuenta, el cliente puede solicitar asistencia e informar de problemas mediante la gestión de incidentes y las solicitudes de servicio de AMS. Sin embargo, AMS no supervisará activamente las métricas de rendimiento y simultaneidad de Lambda ni las métricas de trabajo de Glue. Es responsabilidad del cliente asegurarse de que los servicios de SSP estén habilitados para el registro y la supervisión adecuados. AMS administra completamente la EC2 instancia y el bucket de S3 de la cuenta.

Caso de uso 3: configuración rápida y flexible de una canalización de implementación de CICD en AMS: un cliente quiere configurar una canalización de CICD basada en Jenkins para implementar una canalización de código en todas las cuentas de aplicaciones de AMS. El cliente puede considerar más adecuado alojar esta canalización de CICD en el modo Direct Change (DCM) administrado por AMS o en el modo Desarrollador administrado por AMS, ya que le da la flexibilidad de configurar el servidor Jenkins con la configuración personalizada requerida EC2, con los permisos de acceso de IAM deseados CloudFormation y los depósitos S3 que alojan el repositorio de artefactos. Si bien esto también se puede hacer en el modo RFC administrado por AMS, el equipo del cliente tendría que crear varios manuales RFCs para que las funciones de IAM se basen en el conjunto de permisos aprobados menos permisivo, que AMS revisa manualmente. DCM permite a los clientes alcanzar sus objetivos operativos en AWS y, al mismo tiempo, evitar la necesidad de crear varios manuales RFCs para las funciones de IAM, cuando utilizan el modo RFC administrado por AMS, a fin de utilizar el conjunto menos permisivo de permisos aprobados, que AMS revisa manualmente. Impulsar los procesos y las herramientas de AMS requeriría tiempo y formación por parte del cliente. Al trabajar con el modo Desarrollador, el cliente puede empezar con un «rol de desarrollador» para aprovisionar la infraestructura mediante AWS nativo APIs. La forma más rápida y flexible de configurar esta canalización sería utilizar el modo AMS Managed-Developer. El modo desarrollador ofrece la forma más rápida y sencilla, al tiempo que compromete la integración operativa, mientras que el DCM es menos flexible, pero proporciona el mismo nivel de soporte operativo que el modo RFC.

Caso de uso 4, un modelo operativo personalizado dentro de la base de AMS: un cliente está pensando en dejar su centro de datos dentro de unos plazos y una de sus aplicaciones empresariales está gestionada íntegramente por un MSP externo, lo que incluye las operaciones de aplicaciones y las operaciones de infraestructura. Suponiendo que el cliente no tenga tiempo previsto para rediseñar esta aplicación de forma que pueda ser gestionada por AMS, el modo Customer Managed es una opción adecuada. El cliente puede aprovechar la configuración rápida y automática de la zona de aterrizaje gestionada por AMS. Pueden aprovechar la administración centralizada de cuentas que controla la venta y la conectividad de las cuentas a través de la cuenta de red centralizada. También simplifica su facturación al consolidar los cargos de todas las cuentas administradas por los clientes a través de la cuenta AMS Payer. El cliente tiene la flexibilidad de configurar su modelo de gestión de acceso personalizado con el MSP, de forma independiente de la gestión de acceso estándar que se utiliza en las cuentas gestionadas por AMS. De esta forma, al utilizar el modo gestionado por el cliente, puede configurar un entorno gestionado por AMS y, al mismo tiempo, cumplir con el requisito empresarial de dejar vacante su entorno local. En este caso, si el cliente también tiene aplicaciones basadas en Windows que va a migrar a la nube y decide pasarlas a una cuenta gestionada por el cliente, el cliente es responsable de crear un modelo operativo en la nube. Esto puede resultar complejo, costoso y llevar mucho tiempo, según la capacidad del cliente para transformar los procesos de TI tradicionales y capacitar a las personas. El cliente puede ahorrar tiempo y costes al «transferir» dichas cargas de trabajo a una cuenta gestionada por AMS y delegar las operaciones de infraestructura a AMS.