Meilleures pratiques pour gérer et demander des augmentations de limites de service AWS

Les quotas de service AWS protègent les services contre une utilisation excessive, mais ils peuvent également stopper votre plan de mise à l'échelle au pire moment. Si votre équipe ne surveille pas les quotas avant un lancement ou un pic de trafic, vous pouvez rencontrer des limitations, des déploiements échoués ou des erreurs de capacité même si votre code d'application est sain.

Utilisez la console Service Quotas, CloudWatch et une justification commerciale claire pour gérer les limites dans le cadre de la planification normale de la capacité.

Comprendre les quotas de service AWS

Avant d'initier des demandes, il est essentiel de comprendre la nature des limites AWS. Ces limites sont généralement catégorisées en fonction des ressources (par exemple, nombre d'instances EC2), du débit (par exemple, IOPS) ou des requêtes API par seconde (RPS).

Limites souples vs. Limites dures

La plupart des quotas tombent dans l'une des deux catégories suivantes :

• Limites souples (quotas ajustables) : Ce sont la grande majorité des quotas. Ce sont des valeurs par défaut qu'AWS définit pour les nouveaux comptes et qui peuvent généralement être augmentées en soumettant une demande au support AWS, à condition qu'il y ait une justification commerciale suffisante.
• Limites dures (quotas non ajustables) : Ces limites sont dictées par la conception du service, la sécurité ou les contraintes d'infrastructure. Elles ne peuvent généralement pas être augmentées, vous devez donc trouver une solution architecturale.

Astuce : Vérifiez toujours d'abord la console AWS Service Quotas. Les limites qui y sont listées sont généralement des limites souples et constituent le moyen privilégié pour soumettre des demandes.

Limites courantes nécessitant une attention particulière

Dans les environnements hautement évolutifs, les limites suivantes sont souvent les premières à être atteintes et doivent être surveillées de près :

1. Nombre d'instances EC2 à la demande : Le nombre total de vCPU exécutés sur tous les types d'instances EC2 dans une région.
2. Nombre/taille des volumes EBS : Limites sur le nombre total ou la taille cumulée des volumes attachés.
3. Ressources VPC : Limites sur le nombre de VPC, de passerelles Internet, de passerelles NAT et d'adresses IP élastiques (EIP).
4. Limites de limitation d'API : Limites de requêtes par seconde (RPS) pour des services comme S3, DynamoDB ou les taux d'invocation Lambda.

Surveillance proactive et anticipation

Réagir à la limitation est coûteux et perturbateur. L'objectif est d'anticiper de manière proactive les dépassements de limite bien avant qu'ils n'affectent la production.

1. Utilisation de la console Service Quotas

La console AWS Service Quotas est la source faisant autorité unique pour visualiser les quotas actuels et suivre l'utilisation sur de nombreux services. Elle remplace la nécessité de vérifier les limites sur diverses consoles de services.

Étape concrète : Auditez régulièrement les quotas pour les services critiques de votre application, tels que Lambda, EC2, RDS, VPC et DynamoDB. Examinez tout quota qui augmente régulièrement ou qui est déjà proche de votre seuil d'alerte.

2. Mise en place d'alarmes CloudWatch

Pour les limites critiques, configurez des alarmes automatisées qui informent votre équipe lorsque l'utilisation approche d'un seuil dangereux.

De nombreuses métriques de ressources (comme l'utilisation des vCPU EC2, la concurrence Lambda) sont publiées dans CloudWatch. Pour les quotas directement intégrés à Service Quotas, vous pouvez créer des alarmes directement depuis la console Quotas, en les réglant généralement à 80 % d'utilisation.

# Exemple : Configuration d'une alarme à 80 % d'utilisation pour les exécutions simultanées Lambda
# (Souvent configurée via l'intégration de la console Service Quotas ou CloudFormation)

AlarmName: LambdaConcurrencyWarning
MetricName: ConcurrentExecutions
Namespace: AWS/Lambda
Statistic: Maximum
Period: 300
Threshold: [Current Limit * 0.80] 
ComparisonOperator: GreaterThanThreshold
EvaluationPeriods: 2
TreatMissingData: notBreaching

3. Prévision et planification

Alignez la gestion des quotas sur les jalons de développement et les campagnes marketing. Si un événement de mise à l'échelle majeur ou un lancement de produit est prévu, calculez la capacité maximale requise et soumettez la demande d'augmentation bien à l'avance. Certaines demandes sont traitées rapidement ; d'autres nécessitent un examen humain ou une justification supplémentaire.

La procédure efficace de demande d'augmentation de limite de service

AWS préfère que les demandes d'augmentation de limite soient soumises via la console Service Quotas, car cela automatise le routage et accélère le processus d'approbation.

Étape 1 : Soumission via la console Service Quotas (recommandé)

1. Accédez à la console AWS Service Quotas.
2. Recherchez le service spécifique (par exemple, 'Amazon EC2').
3. Cliquez sur le quota pertinent (par exemple, 'Exécution d'instances standard à la demande').
4. Cliquez sur le bouton Demander une augmentation.
5. Spécifiez la nouvelle limite souhaitée et la région.
6. Fournissez une justification détaillée (voir l'étape 3).

Si le quota n'est pas répertorié dans la console Service Quotas, vous devez soumettre la demande via le Centre de support AWS traditionnel sous le type de cas 'Augmentation de limite de service'.

Étape 2 : Informations clés à inclure dans la demande

Pour éviter des échanges aller-retour avec le support AWS, assurez-vous que votre demande est complète :

• Région AWS : Spécifiez la région exacte (par exemple, us-east-1) où l'augmentation est nécessaire.
• Nom de la limite spécifique : Fournissez le nom précis du quota (par exemple, nombre de tâches Fargate en cours d'exécution).
• Limite actuelle : (Facultatif, mais utile) Confirmez la limite existante que vous atteignez.
• Nouvelle limite demandée : Indiquez le nombre final exact dont vous avez besoin (par exemple, augmentation de 100 à 500).
• Justification commerciale : C'est l'élément le plus crucial.

Étape 3 : Rédiger une justification commerciale solide

Les ingénieurs AWS ont besoin de preuves concrètes que la limite demandée est nécessaire, durable et précise. Les demandes vagues sont souvent retardées ou refusées.

N'utilisez pas : "Nous avons besoin de plus de ressources pour les tests." Utilisez : "Nous avons besoin de 500 vCPU supplémentaires, pour un total de 750, dans eu-west-1 pour prendre en charge une nouvelle charge de travail ECS Fargate. Les tests de charge montrent un pic de demande de 100 tâches simultanées pendant le trafic de lancement. Nous avons besoin de la capacité disponible avant la fenêtre de publication prévue."

Composant de justification	Exemple de détail
Cas d'utilisation	Lancement d'une nouvelle application, intégration d'un client, promotion saisonnière, migration de base de données.
Base de calcul	Résultats de tests de charge, croissance de trafic projetée (RPS), nombre d'utilisateurs, exigences de concurrence.
Calendrier	Quand la capacité est nécessaire (par exemple, Capacité opérationnelle nécessaire d'ici le 2024-11-01).
Durée	S'agit-il d'une augmentation permanente ou d'un pic temporaire ?

Meilleures pratiques avancées et gestion du refus

Stratégies architecturales pour éviter les limites

Parfois, augmenter une limite est la bonne approche, mais souvent, le goulot d'étranglement indique une inefficacité architecturale. Envisagez ces techniques d'atténuation avant de demander des augmentations extrêmement importantes :

1. Implémentez un backoff exponentiel et de la gigue : Utilisez ce modèle pour réessayer les appels API ayant échoué (particulièrement pertinent pour les limites S3 ou DynamoDB) afin d'éviter de submerger le service et de minimiser l'impact de la limitation.
2. Optimisez le traitement par lots : Consolidez plusieurs appels API individuels en une seule opération par lots lorsque cela est pris en charge (par exemple, DynamoDB BatchWriteItem).
3. Utilisez la mise en cache : Implémentez ElastiCache ou CloudFront pour réduire le nombre de requêtes atteignant les services backend, diminuant ainsi la probabilité d'atteindre les limites RPS.

Gestion des demandes rejetées

Si AWS rejette ou réduit considérablement votre limite demandée, cela signifie généralement que la justification était insuffisante ou que la demande dépassait les paramètres de sécurité.

Plan d'action en cas de rejet :

• Ne soumettez pas à nouveau immédiatement. Examinez la raison du refus fournie par le support AWS.
• Affinez la justification : Fournissez des points de données plus spécifiques, des métriques internes et une méthodologie de calcul plus claire.
• Contactez directement le support : Si le problème est urgent ou complexe, répondez au dossier de support en demandant une explication et en proposant de planifier un appel pour examiner les exigences architecturales.

Révision post-augmentation

Après qu'une limite a été augmentée, mettez à jour vos alarmes CloudWatch pour refléter le nouveau seuil de 80 %. Obtenir l'augmentation n'est pas la fin ; une surveillance continue garantit que vous n'atteindrez pas la nouvelle limite de manière inattendue à l'avenir.

À retenir

La gestion des quotas fait partie de la planification de la capacité de production. Suivez les quotas dont votre architecture dépend, alertez avant de manquer de marge et demandez des augmentations avec les mêmes preuves que vous utiliseriez dans une revue de mise à l'échelle : utilisation actuelle, pic attendu, région, calendrier et comment vous avez calculé le nombre.