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.
Zone d'atterrissage multi-comptes unique contre zone d'atterrissage multi-comptes multiple FAQs
Voici quelques questions fréquemment posées lorsque vous choisissez de configurer une seule zone d'atterrissage multi-comptes ou plusieurs zones d'atterrissage multi-comptes :
Q1 : Puis-je commencer par une seule zone d'atterrissage multi-comptes et passer à une zone d'atterrissage multi-comptes, si des limites de comptes ou des contraintes commerciales sont rencontrées ?
R : Oui. Vous pouvez choisir de configurer une autre zone de landing zone multi-comptes à tout moment :
Un nouveau compte payeur devra être configuré (actuellement, AWS ne prend pas en charge les comptes à payeurs multiples dans une seule organisation AWS).
La création de la base d'une zone d'atterrissage multi-comptes prend jusqu'à 2 semaines une fois que le questionnaire de zone d'atterrissage multi-comptes est rempli.
Chaque zone de landing zone multi-comptes représente un supplément d'environ 3 000 USD par mois de frais de fonctionnement.
L'intégration N/W, AD, DNS et SSO sera nécessaire pour établir le nouveau MALZ.
Toutes les instances réservées (RIs) et les plans de réduction des coûts devront être configurés pour la nouvelle zone d'atterrissage multi-comptes (RIs ils ne sont pas transférables).
La zone de landing multi-comptes AMS ne prend pas en charge la migration d'un compte entre des comptes de zone d'atterrissage multi-comptes, par exemple, entre AWS Orgs. Cependant, il est possible de déplacer des applications d'un compte à un autre en utilisant les méthodes de migration standard.
Q2 : Quelle est l'approche d'AMS vis-à-vis du MALZ en matière updates/changes d' underlying/shared infrastructure et de quantification des risques pour les clients ? Fournissez des détails sur les garanties incluses dans le processus. Comment les clients peuvent-ils être sûrs que MALZ n' updates/changes aura aucun impact sur les clients ? Le client doit-il prendre des mesures pour éviter toute interruption ?
R : AMS suit une méthodologie de changement stricte utilisant des outils internes qui nous permettent de définir, de revoir, de planifier et d'exécuter des modifications dans les environnements des clients.
Le processus de publication des mises à jour impose la révision du code, les tests d'intégration, le déploiement dans des environnements gamma et bêta, ainsi que des temps de cuisson et des tests supplémentaires dans les environnements bêta et gamma avant la mise à disposition des environnements clients. Toutes les versions incluent des procédures d'annulation et sont étroitement surveillées par l'équipe chargée des versions et par l'équipe qui a créé et demandé la modification. Le champ d'application des versions est limité aux piles détenues et approvisionnées par AMS. En moyenne, nous exécutons au moins une version par semaine.
En outre :
Les accords de niveau de service AMS sont applicables. Conformément à la description du service AMS, tout incident signalé à la suite d'une activité de maintenance d'infrastructure partagée respectera le SLA en vigueur en matière de résolution ou de crédits.
Aucune mesure préventive particulière n'est requise par les clients pour éviter toute perturbation de l'infrastructure commune. Les clients disposent d'autorisations en lecture seule sur les comptes AWS Org ou Core UO. Ils ne peuvent donc pas apporter de modifications destructives à l'environnement principal de MALZ. Toutes les demandes du client adressées à l'infrastructure principale doivent être examinées et approuvées par AMS.
Les clients peuvent tester certaines modifications au niveau de l'organisation, par exemple SCPs/Roles au niveau des comptes individuels non liés à la production, avant de propager les modifications au niveau de l'unité d'organisation de l'application. Cela fait partie de la feuille de route de l'AMS visant à autoriser plusieurs applications OUs (deuxième trimestre 2020), ce qui réduirait encore les risques liés à certains changements au niveau de l'organisation. L'équipe MALZ a déjà publié une unité d'organisation distincte pour les comptes « Build Mode », afin de garantir une séparation claire de la propriété des clients et des contrôles séparés.
La plupart de ces modifications permettent à AMS de gérer la charge de travail de manière efficace et efficiente et n'ont pas nécessairement d'impact sur la charge de travail des clients. Lorsque AMS estime qu'une modification de l'infrastructure partagée peut avoir un impact sur la charge de travail des clients, elle est alors alignée sur la fenêtre de modification des clients.
Recommandation de haut niveau, commencez par plusieurs zones d'atterrissage multi-comptes si :
Si cela vous aide à atteindre une conformité spécifique.
Si vous devez utiliser Multi-Region.
Si vous avez des charges de travail sur site et des réseaux différents pour les charges de travail ADs et Prod/Material non, les charges Prod/Non-Material workloads, to clearly segregate b/w de travail.
