Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Modes AMS et applications ou charges de travail
Tenez compte des exigences opérationnelles et de gouvernance de vos applications lorsque vous sélectionnez le bon mode, soit en demandant un nouveau compte d'application, soit en hébergeant l'application dans un compte d'application existant. La sélection du mode AMS approprié pour chaque application ou charge de travail dépend des facteurs suivants :
Le type de fonction de cycle de vie du SDLC que l'environnement fournira (par exemple, sandbox avec des modifications non modérées, UAT avec des modifications fréquentes, production avec des modifications minimes et hautement réglementée)
Les politiques de gouvernance nécessaires (appliquées SCPs au niveau de l'UO)
Modèle opérationnel (si vous souhaitez assumer la responsabilité opérationnelle ou si vous souhaitez l'externaliser à AMS)
Les résultats commerciaux souhaités, tels que le temps nécessaire pour opérer dans le cloud et le coût des opérations.
Note
Pour une description des types de mode par service AMS, voir Types de modes et de comptes dans AMS.
Pour des cas d'utilisation réels des différents modes, voir Cas d'utilisation réels des modes AMS
Le tableau suivant décrit les principales considérations à prendre en compte par les propriétaires d'applications pour les aider à choisir le mode AMS le plus approprié. Les propriétaires d'applications doivent prévoir une phase d'évaluation avant la migration des applications afin de bien comprendre quel mode s'applique à leur application spécifique. Exemple : pour les applications basées sur des services cloud natifs ou sur une architecture sans serveur, la meilleure option pourrait être de commencer à créer et à itérer en mode développeur et de déployer l'infrastructure finale sous forme de code à l'aide du mode AMS Managed — SSP. Dans ce cas, une légère refactorisation peut être nécessaire pour garantir que tous les CloudFormation modèles créés pour un déploiement automatisé respectent les directives d'ingestion établies par AMS. En outre, toutes les autorisations IAM doivent être approuvées par AMS Security afin de garantir qu'elles respectent le modèle du moindre privilège.
Le mode AMS sélectionné pour héberger l'application peut vous aider à élaborer le modèle d'exploitation cloud que vous souhaitez.
Note
Plusieurs modèles d'exploitation cloud peuvent exister dans une seule zone d'accueil gérée par AMS en fonction des différents modes AMS sélectionnés pour héberger les applications.
| Problèmes de décision | Mode CM standard/OOD * | AWS Service Catalog | Mode de changement direct | Provisionnement en libre-service | Mode développeur | Géré par le client |
|---|---|---|---|---|---|---|
| État de préparation opérationnelle | ||||||
| Journalisation, surveillance et gestion des événements | AMS est responsable de toutes les infrastructures gérées | Client responsable des services fournis en libre-service (SSP) | Client responsable des ressources mises à disposition à l'aide du rôle de développeur IAM en dehors du système AMS CM | Client responsable | ||
| Gestion de la continuité | Responsabilité d'AMS d'exécuter le plan de sauvegarde sélectionné par le client | Client responsable des services fournis en libre-service (SSP) | Client responsable des ressources mises à disposition à l'aide du rôle de développeur IAM en dehors du système AMS CM | |||
| Gestion de l'accès au niveau de l'instance | Géré par AMS via AD Trust unidirectionnel avec domaine sur site. Nécessite une infrastructure gérée pour rejoindre le domaine AMS | Ne s’applique pas | Client responsable des ressources mises à disposition à l'aide du rôle de développeur IAM en dehors du système AMS CM | |||
| Gestion de la sécurité et gestion de l'accès au niveau du compte | Responsabilité d'AMS pour tous les comptes gérés | AMS est responsable de tous les comptes gérés | Client responsable des ressources mises à disposition à l'aide du rôle de développeur IAM en dehors du système AMS CM | |||
| Gestion des correctifs | Responsabilité d'AMS pour tous les comptes gérés | Client responsable des services fournis en libre-service (SSP) | Client responsable des ressources mises à disposition à l'aide du rôle de développeur IAM en dehors du système AMS CM | |||
| Gestion des modifications | Responsabilité d'AMS pour tous les comptes gérés | Client responsable des services fournis en libre-service (SSP) | Client responsable des ressources mises à disposition à l'aide du rôle de développeur IAM en dehors du système AMS CM | |||
| Gestion du provisionnement | Prescriptif et standardisé pour les options de provisionnement proposées dans AMS | Flexibilité permettant d'utiliser directement l'API de service AWS pour AWS Service Catalog conformément aux normes prescriptives AMS | Flexibilité permettant d'utiliser directement l'API de service AWS conformément aux normes prescriptives AMS | Flexibilité permettant d'utiliser directement le service AWS APIs pour les services SSP | Flexibilité permettant d'utiliser directement l'API de service AWS pour le provisionnement | |
| Gestion des incidents et audit | AMS est responsable de tous les comptes gérés | Client responsable des ressources mises à disposition à l'aide du rôle de développeur IAM en dehors du système de gestion des modifications AMS | ||||
| GuardRails et infrastructure partagée (réseau) et cadre de sécurité | Utilisation prescriptive et standardisée des comptes AMS Core | Flexible et sur mesure en tirant parti des comptes AMS Core | ||||
| Préparation à l'application | ||||||
| Refactorisation des applications | Une légère refactorisation est nécessaire | Une légère refactorisation est nécessaire (si le provisionnement est effectué à l'aide d'AMS Standard CM) | Pas besoin de refactorisation | |||
| Support pour les services AWS | Limité à ce qui est pris en charge par AMS | Non limité | ||||
| Considérations commerciales | ||||||
| Délai de préparation opérationnelle | Trois à six mois | 6 mois ou plus selon les compétences opérationnelles des applications du client | 6 à 18 mois en fonction de l'infrastructure du client et des compétences opérationnelles des applications | |||
| Coûts | $$$$ | $$$ | $$ | $ | ||
| Exemples d'applications | Serveur Web avec pile à 3 niveaux, applications conformes aux exigences réglementaires | Serveur Web utilisant API Gateway, application conteneurisée utilisant ECS/EKS | Itération/optimisation sur une application Data Lake utilisant Lambda, Glue, Athena, etc. | Décentralisation, accounts/applications comme le bac à sable ou les applications gérées par des tiers | ||
* Operations On Demand (OOD) propose une offre aux clients utilisant le mode CM standard pour gérer leurs modifications grâce à des ressources dédiées. Pour plus de détails, consultez le catalogue d'offres Operations on Demand et adressez-vous à votre responsable de prestation de services cloud (CSDM).
Note
La comparaison des prix entre le mode SSP et le mode développeur suppose que les mêmes services AWS sont fournis.
Comparaison des modes AMS avec les objectifs commerciaux et informatiques
Comme indiqué, si vous recherchez un modèle de gouvernance hautement contrôlé et standardisé pour vos applications, les modes Standard Change, AWS Service Catalog ou Direct Change gérés par AMS sont les meilleurs choix. Si vous avez besoin d'un modèle de gouvernance sur mesure axé sur l'innovation des applications sans avoir besoin de préparation opérationnelle, sélectionnez le mode géré par le client. Avec le mode géré par le client, la mise en œuvre de vos applications peut prendre plus de temps, car il vous incombe de définir les personnes, les processus et les outils nécessaires pour soutenir les capacités opérationnelles telles que la gestion des incidents, la gestion des configurations, la gestion du provisionnement, la gestion de la sécurité, la gestion des correctifs, etc.
