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.
Types de modes et de comptes dans AMS
Les modes AWS Managed Services (AMS) peuvent être définis comme les moyens d'interagir avec le service AMS dans le cadre du cadre de gouvernance spécifique à chaque mode. Les différences de zone d'atterrissage, zone d'atterrissage multi-comptes ou MALZ et zone d'atterrissage monocompte ou SALZ sont notées.
Note
Pour plus de détails sur le déploiement d'applications et le choix du mode AMS approprié, consultez la section Modes AMS et applications ou charges de travail.
Pour les cas d'utilisation réels des différents modes, voir Cas d'utilisation réels des modes AMS
Le tableau suivant décrit les modes par service AMS.
| Fonctionnalité AMS | Mode RFC (ancien mode CM standard)/OOD * | Mode de changement direct | AWS Service Catalog | Self-service provisionnement/mode développeur | Géré par le client |
|---|---|---|---|---|---|
| Configuration de la zone d'atterrissage | MALZ et SALZ | MALZ et SALZ | MALZ et SALZ | ||
| Gestion des modifications | Planification des modifications, examen des modifications manuelles et enregistrement des modifications | Identique au mode RFC pour les modifications à haut risque telles que l'IAM ou les groupes de sécurité | Aucune | ||
| Journalisation, surveillance, garde-corps et gestion des événements | Oui (ressources prises en charge) | Non | |||
| Gestion de la continuité | Oui (ressources prises en charge) | Non applicable/Non | Non | ||
| Gestion de la sécurité | Contrôles de sécurité au niveau de l'instance et contrôles au niveau du compte | Contrôles au niveau du compte | Contrôles au niveau de l'organisation AWS | ||
| Gestion des correctifs | Oui | Non applicable/Non | Non | ||
| Gestion des incidents et des problèmes | SLA de réponse et de résolution pour les ressources prises en charge par AMS | Réponse (SLA) pour les ressources qui en résultent | Non | ||
| Génération de rapports | Oui | Non | |||
| Gestion des demandes de service | Oui | Demandes de support uniquement | Non | ||
* Operations On Demand (OOD) propose une offre aux clients utilisant le mode RFC 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
Mode de provisionnement en libre-service dans AMSet les deux Mode développeur avancé AMS peuvent sembler convenir à une application dotée d'une architecture complexe ancrée dans les services AWS natifs. Lorsque vous concevez des charges de travail, vous faites des compromis entre excellence opérationnelle et agilité, en fonction de votre contexte commercial. C'est une bonne façon de choisir le mode SSP ou le mode développeur pour votre application. La sélection peut également changer en fonction de la phase SDLC de l'application. Par exemple : lorsque l'application est prête pour la production, le mode SSP peut être une option plus appropriée en raison des barrières de sécurité AMS plus strictes dans ce mode. Les garde-fous sont appliqués sous la forme de contrôles préventifs tels que le contrôle des RFC-based modifications pour les mises à jour IAM et les SCP au niveau de l'unité d'organisation des applications. Ces décisions professionnelles peuvent orienter vos priorités en matière d’ingénierie. Vous pouvez optimiser pour accroître la flexibilité des propriétaires d'applications en phase de « pré-production » au détriment de la gouvernance et du support opérationnel.
Architecture MALZ et modes AMS associés
La zone de landing zone multi-comptes (MALZ) AMS vous donne la possibilité de provisionner automatiquement des comptes d'applications (ou des comptes de ressources) sous les unités organisationnelles (UO) par défaut : UO gérée par le client, UO gérée ou UO de développement. L'infrastructure fournie dans les comptes d'applications créés dans le cadre de chacune de ces unités d'organisation est soumise au mode AMS spécifique proposé par ces unités d'organisation fondamentales. Il est courant de trouver une combinaison de deux modes ou plus dans le même compte d'application. Par exemple : le mode RFC et le mode SSP peuvent coexister dans un compte géré AMS hébergeant une architecture de pipeline composée d'API Gateway et Lambda pour les fonctions de déclenchement, et d'EC2, S3 et SQS pour l'ingestion et l'orchestration. Dans ce cas, le mode SSP s'appliquerait à Lambda et à API Gateway.
La figure 1 montre comment les différents modes sont proposés par le biais des unités d'organisation fondamentales d'AMS. Lorsque vous demandez un nouveau compte d'application dans AMS, vous devez sélectionner l'unité d'organisation du compte.
Architecture MALZ et modes AMS associés
.png)
AMS s'appuie sur les unités d'organisation fondamentales basées sur les meilleures pratiques d'AWS afin de gérer les comptes de manière logique à l'aide des politiques de contrôle des services (SCP). Cela permet d'appliquer le cadre de gouvernance à chaque mode AMS. Toutes les barrières de gouvernance et de sécurité (sous forme de SCP) appliquées aux unités d'organisation de base sont également appliquées automatiquement aux unités d'organisation. custom/child Des SCP supplémentaires peuvent être demandés pour les unités d'organisation pour enfants. Il est important de comprendre que les comptes d'applications sont différents des modes. Les modes sont appliqués à l'infrastructure fournie dans les comptes et définissent les responsabilités opérationnelles entre AMS et les clients.
Figure 1 : Architecture MALZ et modes AMS associés
Note
Le terme « restrictif » implique que vous pouvez demander des politiques personnalisées pour ces unités d'organisation. Elles sont approuvées par AMS au cas par cas afin de garantir qu'elles n'interfèrent pas avec les capacités d'AMS à fournir une excellence opérationnelle. Pour une liste détaillée des rambardes AMS, voir Rambardes AMS dans le guide de l'utilisateur.
