REL01-BP02 Gérer les quotas de service entre les comptes et les régions - AWS Well-Architected Framework

REL01-BP02 Gérer les quotas de service entre les comptes et les régions

Si vous utilisez plusieurs comptes ou régions, demandez les quotas appropriés dans tous les environnements où vos charges de travail de production s'exécutent.

Résultat souhaité : Les services et les applications ne doivent pas être affectés par un épuisement de quota de service pour les configurations qui englobent les comptes ou les régions ou dont les conceptions de résilience s'appuient sur le basculement de zone, de région ou de compte.

Anti-modèles courants :

  • Laisser l'utilisation des ressources dans une région d'isolement se développer sans aucun mécanisme pour maintenir de la capacité dans les autres zones.

  • Définir manuellement tous les quotas de manière indépendante dans les régions d'isolement.

  • Ne pas prendre en considération l'effet des architectures de résilience (par ex., actives ou passives) dans les futurs besoins de quotas alors qu'une dégradation est observée dans la région non principale.

  • Ne pas évaluer les quotas régulièrement et ne pas apporter les changements qui s'imposent dans chaque région et chaque compte où la charge de travail s'exécute.

  • Ne pas tirer parti des modèles de demande de quota pour demander des augmentations dans plusieurs régions et comptes.

  • Ne pas mettre à jour les quotas de service pensant à tort que l'augmentation de quotas a des répercussions sur les coûts comme les demandes de réservation de capacité de calcul.

Avantages liés au respect de cette bonne pratique : Possibilité de vérifier que vous êtes en mesure de gérer votre charge actuelle dans les régions ou comptes secondaires au cas où les services régionaux viendraient à être indisponibles. Cela peut contribuer à limiter le nombre d'erreurs ou les niveaux de dégradations observés lors d'une perte de région.

Niveau de risque exposé si cette bonne pratique n'est pas respectée : élevé

Directives d'implémentation

Les quotas de service sont suivis par compte. Sauf indication contraire, chaque quota est propre à une Région AWS. En plus des environnements de production, tâchez également de gérer les quotas dans tous les autres environnements applicables de façon à ne pas entraver les tests et le développement. Pour maintenir un haut niveau de résilience, il convient d'évaluer constamment les quotas de service (que ce soit de façon automatisée ou manuelle).

Compte tenu du plus grand nombre de charges de travail englobant les régions du fait de l'implémentation de conceptions utilisant les approches Actif/Actif, Actif/Passif – Chaud, Actif/Passif – Froid et Actif/Passif – Veilleuse, il est essentiel de comprendre tous les niveaux de quota de région et de compte. Les modèles de trafic passés ne permettent pas toujours de déterminer correctement si le quota de service est bien défini.

Tout aussi important, la longueur limite des noms de quota de service n'est pas toujours identique d'une région à l'autre. Ainsi, cette valeur peut être égale à cinq dans une région et à dix dans une autre. La gestion de ces quotas doit englober tous les services, comptes et régions identiques pour offrir une résilience cohérente dans des conditions de charge.

Rapprochez toutes les différences de quota de service entre les différentes régions (région active ou région passive) et créez des processus permettant de rapprocher constamment ces différences. Les plans de test de basculements de régions passives sont rarement mis à l'échelle pour atteindre une capacité active de pointe, ce qui signifie que les exercices de simulation (« game day ») et les exercices de table (« table top ») ne permettent pas nécessairement d'identifier les différences dans les quotas de service entre les régions et donc de maintenir les limites adéquates.

La dérive de quota de service, condition où les limites de quota de service pour un quota nommé spécifique changent dans une région mais pas dans toutes, est très importante pour le suivi et l'évaluation. Il doit être envisagé de changer le quota dans les régions qui présentent du trafic ou qui pourraient potentiellement en véhiculer.

  • Sélectionnez les comptes et les régions appropriés en fonction de vos exigences de service, de latence, de réglementation et de reprise après sinistre (DR).

  • Identifiez les quotas de services dans l'ensemble des comptes, régions et zones de disponibilité appropriés. Les limites s'appliquent au compte et à la région. Ces valeurs doivent être comparées pour repérer les différences.

Étapes d'implémentation

  • Examinez les valeurs Service Quotas susceptibles d'avoir transgressé le niveau d'utilisation à risque. AWS Trusted Advisor propose des alertes pour les violations de seuil de 80 % et 90 %.

  • Examinez les valeurs de quotas de service dans les régions passives (dans une conception de type Actif/Passif). Vérifiez que la charge s'exécutera correctement dans les régions secondaires en cas de défaillance dans la région principale.

  • Automatisez l'évaluation pour identifier une éventuelle dérive de quota de service entre des régions d'un même compte et agissez en conséquence pour changer les limites.

  • Si la structure des unités d'organisation (UO) est prise en charge, les modèles de quota de service doivent être mis à jour en fonction des changements apportés aux quotas qui doivent s'appliquer à plusieurs régions et comptes.

    • Créez un modèle et associez les régions au changement de quota.

    • Examinez tous les modèles de quota de service existants pour y apporter les changements nécessaires (région, limites et comptes).

Ressources

Bonnes pratiques associées :

Documents connexes :

Vidéos connexes :

Services associés :