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 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 modes par service AMS.
| Fonctionnalité AMS | Mode RFC (ancien mode CM standard)/OOD * | Mode de changement direct | AWS Service Catalog | Provisionnement en libre-service/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 modifications basé sur le protocole RFC pour les mises à jour IAM et SCPs au niveau de l'unité d'organisation de l'application. 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 chacun de ces comptes OUs est soumise au mode AMS spécifique proposé par les comptes de base OUs. 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 EC2, et de 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 fondamentaux OUs 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 principes fondamentaux OUs basés sur les meilleures pratiques d'AWS pour gérer les comptes de manière logique à l'aide des politiques de contrôle des services (). SCPs Cela permet d'appliquer le cadre de gouvernance à chaque mode AMS. Toutes les barrières de gouvernance et de sécurité (sous forme de SCPs) appliquées aux fondamentaux sont OUs également appliquées automatiquement. custom/child OUs Un supplément SCPs peut être demandé pour l'enfant OUs. 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 derniers OUs. Elles sont approuvées par AMS afin de garantir qu'elles n'interfèrent pas avec les capacités d'AMS à fournir une excellence opérationnelle. case-by-case Pour une liste détaillée des rambardes AMS, voir Rambardes AMS dans le guide de l'utilisateur.
