Cas d'utilisation réels des modes AMS

Cas d'utilisation 1 : il est impératif pour l'entreprise de réduire ses coûts en quittant son centre de données dans des délais serrés : une entreprise confrontée à un événement commercial important, tel que la sortie d'un centre de données, souhaite réhéberger ses applications sur site dans le cloud. La majeure partie de l'inventaire sur site se compose de serveurs Windows et Linux avec une combinaison de versions de systèmes d'exploitation. Ce faisant, le client souhaite également tirer parti des économies qu'offre le passage au cloud et améliorer le niveau technique et de sécurité de ses applications. Le client souhaite agir rapidement mais ne dispose pas encore de l'expertise interne en matière d'opérations cloud. Le client doit trouver un équilibre entre le refactoring, car trop de refactoring peut être risqué par rapport à un calendrier serré. Cependant, grâce à certaines refactorisations, telles que la mise à jour des versions du système d'exploitation et l'optimisation des bases de données, les applications peuvent atteindre un niveau de performance supérieur. Dans cet exemple, le client peut sélectionner le mode RFC géré par AMS pour réhéberger la plupart de ses applications. AMS assure les opérations d'infrastructure, tout en guidant les équipes opérationnelles des clients sur les meilleures pratiques en matière de sécurité des opérations dans le cloud.

AWS Service Catalog géré par AMS et le mode Direct Change géré par AMS offrent au client une flexibilité supplémentaire tout en obtenant les mêmes résultats et objectifs commerciaux. En outre, le client peut utiliser l'offre AMS Operations On Demand (OOD) pour disposer d'ingénieurs d'exploitation AMS dédiés chargés de prioriser l'exécution des demandes de changement (RFCs).

Tout en déléguant les tâches opérationnelles indifférenciées de l'infrastructure (correctifs, sauvegardes, gestion des comptes, etc.) à AMS, le client peut continuer à se concentrer sur l'optimisation de son application et renforcer ses équipes internes sur les opérations cloud. AMS fournit des rapports mensuels au client sur les économies de coûts et formule des recommandations sur l'optimisation des ressources. Dans ce cas d'utilisation, si le client a décidé de ne pas refactoriser certaines end-of-life applications hébergées sur des versions de système d'exploitation existantes telles que Windows 2003 et 2008, elles peuvent également être migrées vers AMS et hébergées sur un compte utilisant le mode géré par le client.

Cas d'utilisation 2, création d'un lac de données avec Lambda, Glue et Athena dans les limites sécurisées d'AMS : une entreprise cherche à configurer un lac de données pour répondre aux besoins de reporting de plusieurs applications dans AMS. Le client souhaite utiliser des compartiments S3 pour le stockage des ensembles de données et AWS Athena pour interroger l'ensemble de données pour chaque rapport. S3 et AWS Athena seront déployés dans des comptes gérés AMS distincts. Le compte S3 propose également d'autres services tels que Glue, Lambda et Step Functions pour créer un pipeline d'ingestion de données. Glue, Lambda, Athena et Step Functions sont considérés comme des services Self-Service Provisioning (SSP) dans ce cas. Le client a également déployé une EC2 instance dans le compte qui fait office de tooling/scripting serveur ad hoc. Le client commence par demander à AMS d'activer les services SSP sur son compte AMS Managed. AMS fournit un rôle IAM pour chaque service que le client peut assumer, une fois le rôle intégré à la solution de fédération du client. Pour faciliter la gestion, le client peut également combiner les politiques relatives aux différents rôles IAM en un seul rôle personnalisé, ce qui évite d'avoir à changer de rôle lorsqu'il travaille entre les services AWS. Une fois le rôle activé dans le compte, le client peut configurer les services selon ses besoins. Cependant, le client doit utiliser le système de gestion des modifications AMS pour demander des autorisations supplémentaires, en fonction de son cas d'utilisation.

Par exemple, pour accéder à Glue Crawlers, Glue a besoin d'autorisations supplémentaires. Des autorisations supplémentaires seront également nécessaires pour créer des sources d'événements pour Lambda. Le client travaillera avec AMS pour mettre à jour les rôles IAM afin de permettre à Athena d'accéder à plusieurs comptes pour interroger les compartiments S3. Des mises à jour des rôles de service ou des rôles liés à un service seront également nécessaires par le biais de la gestion des modifications d'AMS pour que Lambda appelle le service Step Functions et pour Glue pour lire et écrire dans tous les compartiments S3. AMS travaille avec ses clients pour s'assurer que le modèle d'accès avec le moindre privilège est respecté et que les modifications IAM demandées ne sont pas trop permissives et n'exposent pas l'environnement à des risques inutiles. L'équipe du lac de données du client passe du temps à planifier toutes les autorisations IAM nécessaires pour les services spécifiques à l'architecture du client et demande à AMS de les activer. En effet, toutes les modifications IAM sont traitées manuellement et examinées par l'équipe de sécurité AMS. Le temps nécessaire au traitement de ces demandes doit être pris en compte dans le calendrier de déploiement de l'application.

Les services SSP étant opérationnels sur le compte, le client peut demander de l'assistance et signaler les problèmes via la gestion des incidents et les demandes de service AMS. Toutefois, AMS ne surveillera pas activement les indicateurs de performance et de simultanéité pour Lambda, ni les indicateurs de travail pour Glue. Il est de la responsabilité du client de s'assurer que la journalisation et la surveillance appropriées sont activées pour les services SSP. L' EC2 instance et le compartiment S3 du compte sont entièrement gérés par AMS.

Cas d'utilisation 3, configuration rapide et flexible d'un pipeline de déploiement CICD dans AMS : un client cherche à configurer un pipeline CICD basé sur Jenkins pour déployer un pipeline de code sur tous les comptes d'applications dans AMS. Le client trouvera peut-être qu'il est préférable d'héberger ce pipeline CICD en mode Direct Change (DCM) géré par AMS ou en mode développeur géré par AMS, car cela lui permet de configurer le serveur Jenkins avec la configuration personnalisée requise EC2, avec les autorisations d'accès IAM souhaitées CloudFormation et les compartiments S3 hébergeant le référentiel d'artefacts. Bien que cela puisse également être fait en mode RFC géré par AMS, l'équipe client devra créer plusieurs manuels RFCs pour que les rôles IAM puissent itérer sur l'ensemble d'autorisations approuvées le moins permissif, qui sont examinées manuellement par AMS. DCM permet aux clients d'atteindre leurs objectifs opérationnels sur AWS tout en évitant de devoir créer plusieurs manuels RFCs pour les rôles IAM, lors de l'utilisation du mode RFC géré par AMS, afin d'itérer sur l'ensemble d'autorisations approuvées le moins permissif, qui sont examinées manuellement par AMS. Cela nécessiterait du temps et de la formation de la part du client pour accélérer les processus et les outils AMS. En mode développeur, le client peut commencer par un « rôle de développeur » pour provisionner l'infrastructure à l'aide d'AWS natif APIs. Le moyen le plus rapide et le plus flexible de configurer ce pipeline serait d'utiliser le mode AMS Managed-Developer. Le mode développeur est le moyen le plus rapide et le plus simple, tout en compromettant l'intégration opérationnelle, tandis que le DCM est moins flexible mais fournit le même niveau de support opérationnel que le mode RFC.

Cas d'utilisation 4, modèle d'exploitation sur mesure au sein de la base AMS : un client souhaite quitter son centre de données dans les délais et l'une de ses applications d'entreprise est entièrement gérée par un MSP tiers, y compris les opérations d'application et les opérations d'infrastructure. En supposant que le client n'ait pas le temps de refactoriser cette application afin qu'elle puisse être exploitée par AMS, le mode géré par le client est une option appropriée. Le client peut profiter de la configuration automatisée et rapide de la zone d'atterrissage gérée par AMS. Ils peuvent tirer parti de la gestion centralisée des comptes qui contrôle la distribution automatique des comptes et la connectivité via le compte réseau centralisé. Cela simplifie également leur facturation en consolidant les frais de tous les comptes gérés par le client via le compte AMS Payer. Le client dispose de la flexibilité nécessaire pour configurer son modèle de gestion des accès sur mesure avec le MSP, indépendamment de la gestion d'accès standard utilisée pour les comptes gérés par AMS. Ainsi, en utilisant le mode géré par le client, ils peuvent configurer un environnement géré AMS tout en répondant à leurs besoins commerciaux en matière de libération de leur environnement sur site. Dans ce cas, si le client possède également des applications Windows qu'il migre vers le cloud et qu'il choisit de les déplacer vers un compte géré par le client, il est responsable de la création d'un modèle d'exploitation cloud. Cela peut être complexe, coûteux et chronophage selon la capacité du client à transformer les processus informatiques traditionnels et à former le personnel. Le client peut économiser du temps et de l'argent en « transférant » ces charges de travail vers un compte géré par AMS et en déléguant les opérations d'infrastructure à AMS.