Bewährte Verfahren für die Handhabung und Beantragung von AWS-Service-Limit-Erhöhungen
Überwachen Sie AWS-Service-Kontingente, planen Sie die Kapazität frühzeitig und reichen Sie klare Kontingenterhöhungsanträge ein, bevor Drosselungen die Produktion beeinträchtigen.
Bewährte Verfahren für die Handhabung und Beantragung von AWS-Service-Limit-Erhöhungen
AWS-Service-Kontingente schützen Dienste vor übermäßiger Nutzung, können aber auch Ihren Skalierungsplan im ungünstigsten Moment stoppen. Wenn Ihr Team Kontingente vor einem Launch oder Verkehrsspitzen nicht überwacht, können Drosselungen, fehlgeschlagene Bereitstellungen oder Kapazitätsfehler auftreten, selbst wenn Ihr Anwendungscode fehlerfrei ist.
Verwenden Sie die Service Quotas-Konsole, CloudWatch und eine klare geschäftliche Begründung, um Limits als Teil der normalen Kapazitätsplanung zu verwalten.
Grundlegendes zu AWS-Service-Kontingenten
Bevor Sie Anträge stellen, ist es wichtig, die Art der AWS-Limits zu verstehen. Diese Limits werden in der Regel nach Ressourcen (z. B. Anzahl der EC2-Instanzen), Durchsatz (z. B. IOPS) oder API-Anfragen pro Sekunde (RPS) kategorisiert.
Weiche Limits vs. Harte Limits
Die meisten Kontingente fallen in eine von zwei Kategorien:
- Weiche Limits (Anpassbare Kontingente): Dies sind die überwiegende Mehrheit der Kontingente. Es sind Standardwerte, die AWS für neue Konten festlegt und die in der Regel durch Einreichen eines Antrags beim AWS-Support erhöht werden können, sofern eine ausreichende geschäftliche Begründung vorliegt.
- Harte Limits (Nicht anpassbare Kontingente): Diese Limits werden durch das Servicedesign, Sicherheits- oder Infrastrukturbeschränkungen vorgegeben. Sie können in der Regel nicht erhöht werden, sodass Sie eine architektonische Problemumgehung benötigen.
Tipp: Überprüfen Sie immer zuerst die AWS Service Quotas-Konsole. Die dort aufgeführten Limits sind in der Regel weiche Limits und die bevorzugte Methode zur Einreichung von Anträgen.
Häufige Limits, die Aufmerksamkeit erfordern
In hoch skalierbaren Umgebungen werden die folgenden Limits oft zuerst erreicht und sollten genau überwacht werden:
- EC2-On-Demand-Instanzanzahl: Die Gesamtzahl der vCPUs, die über alle EC2-Instanztypen in einer Region ausgeführt werden.
- EBS-Volumenanzahl/-größe: Limits für die Gesamtzahl oder die kumulative Größe der angehängten Volumes.
- VPC-Ressourcen: Limits für die Anzahl der VPCs, Internet-Gateways, NAT-Gateways und elastischen IPs (EIPs).
- API-Drosselungslimits: Limits für Anfragen pro Sekunde (RPS) für Dienste wie S3, DynamoDB oder Lambda-Aufrufraten.
Proaktive Überwachung und Vorhersage
Auf Drosselung zu reagieren ist teuer und störend. Das Ziel ist es, Limitverletzungen proaktiv vorherzusehen, lange bevor sie die Produktion beeinträchtigen.
1. Nutzung der Service Quotas-Konsole
Die AWS Service Quotas-Konsole ist die einzige autoritative Quelle für die Anzeige aktueller Kontingente und die Verfolgung der Nutzung über viele Dienste hinweg. Sie ersetzt die Notwendigkeit, Limits in verschiedenen Servicekonsolen zu überprüfen.
Handlungsschritt: Überprüfen Sie regelmäßig die Kontingente für Dienste, die für Ihre Anwendung kritisch sind, wie Lambda, EC2, RDS, VPC und DynamoDB. Untersuchen Sie jedes Kontingent, das stetig ansteigt oder sich bereits Ihrem Alarmgrenzwert nähert.
2. Implementierung von CloudWatch-Alarmen
Richten Sie für kritische Limits automatisierte Alarme ein, die Ihr Team benachrichtigen, wenn sich die Nutzung einem gefährlichen Schwellenwert nähert.
Viele Ressourcenmetriken (wie EC2-vCPU-Nutzung, Lambda-Gleichzeitigkeit) werden in CloudWatch veröffentlicht. Für Kontingente, die direkt in Service Quotas integriert sind, können Sie direkt aus der Quotas-Konsole Alarme erstellen, die in der Regel bei 80 % Auslastung eingestellt werden.
# Beispiel: Einrichtung eines 80%-Auslastungsalarms für gleichzeitige Lambda-Ausführungen
# (Wird oft über die Service Quotas-Konsolenintegration oder CloudFormation konfiguriert)
AlarmName: LambdaConcurrencyWarning
MetricName: ConcurrentExecutions
Namespace: AWS/Lambda
Statistic: Maximum
Period: 300
Threshold: [Aktuelles Limit * 0,80]
ComparisonOperator: GreaterThanThreshold
EvaluationPeriods: 2
TreatMissingData: notBreaching
3. Prognose und Planung
Stimmen Sie die Kontingentverwaltung mit Entwicklungsmeilensteinen und Marketingkampagnen ab. Wenn ein großes Skalierungsereignis oder ein Produktstart geplant ist, berechnen Sie die maximal erforderliche Kapazität und reichen Sie den Erhöhungsantrag rechtzeitig ein. Einige Anträge werden schnell bearbeitet; andere erfordern eine manuelle Überprüfung oder zusätzliche Begründung.
Das effiziente Verfahren zur Beantragung einer Service-Limit-Erhöhung
AWS bevorzugt, dass Anträge auf Limiterhöhung über die Service Quotas-Konsole eingereicht werden, da dies die Weiterleitung automatisiert und den Genehmigungsprozess beschleunigt.
Schritt 1: Einreichung über die Service Quotas-Konsole (Empfohlen)
- Navigieren Sie zur AWS Service Quotas-Konsole.
- Suchen Sie nach dem spezifischen Dienst (z. B. 'Amazon EC2').
- Klicken Sie auf das relevante Kontingent (z. B. 'Running On-Demand All Standard Instances').
- Klicken Sie auf die Schaltfläche Erhöhung anfordern.
- Geben Sie das neue gewünschte Limit und die Region an.
- Geben Sie eine detaillierte Begründung an (siehe Schritt 3).
Wenn das Kontingent nicht in der Service Quotas-Konsole aufgeführt ist, müssen Sie den Antrag über das traditionelle AWS Support Center mit dem Falltyp 'Service Limit Increase' einreichen.
Schritt 2: Wichtige Informationen, die in den Antrag aufgenommen werden sollten
Um Hin- und Her-Kommunikation mit dem AWS-Support zu vermeiden, stellen Sie sicher, dass Ihr Antrag umfassend ist:
- AWS-Region: Geben Sie die genaue Region an (z. B.
us-east-1), in der die Erhöhung benötigt wird. - Spezifischer Limitname: Geben Sie den genauen Namen des Kontingents an (z. B. Anzahl der laufenden Fargate-Aufgaben).
- Aktuelles Limit: (Optional, aber hilfreich) Bestätigen Sie das bestehende Limit, das Sie erreichen.
- Angefordertes neues Limit: Geben Sie die genaue Endzahl an, die Sie benötigen (z. B. Erhöhung von 100 auf 500).
- Geschäftliche Begründung: Dies ist das wichtigste Element.
Schritt 3: Erstellen einer starken geschäftlichen Begründung
AWS-Ingenieure benötigen konkrete Beweise dafür, dass das angeforderte Limit notwendig, nachhaltig und genau ist. Vage Anträge werden oft verzögert oder abgelehnt.
Nicht verwenden: "Wir brauchen mehr Ressourcen zum Testen."
Verwenden: "Wir benötigen 500 zusätzliche vCPUs, insgesamt 750, in eu-west-1, um eine neue ECS-Fargate-Workload zu unterstützen. Auslastungstests zeigen eine Spitzennachfrage von 100 gleichzeitigen Aufgaben während des Launch-Verkehrs. Wir benötigen die Kapazität vor dem geplanten Veröffentlichungsfenster."
| Begründungskomponente | Beispiel Detail |
|---|---|
| Anwendungsfall | Neue Anwendungseinführung, Kunden-Onboarding, saisonale Aktion, Datenbankmigration. |
| Berechnungsgrundlage | Ergebnisse von Auslastungstests, prognostiziertes Verkehrswachstum (RPS), Anzahl der Benutzer, Gleichzeitigkeitsanforderungen. |
| Zeitplan | Wann die Kapazität benötigt wird (z. B. Kapazität muss bis 2024-11-01 betriebsbereit sein). |
| Dauer | Handelt es sich um eine dauerhafte Erhöhung oder einen vorübergehenden Spitzenwert? |
Fortgeschrittene bewährte Verfahren und Umgang mit Ablehnungen
Architekturstrategien zur Vermeidung von Limits
Manchmal ist die Erhöhung eines Limits der richtige Ansatz, aber oft weist der Engpass auf eine architektonische Ineffizienz hin. Ziehen Sie diese Minderungstechniken in Betracht, bevor Sie extrem große Erhöhungen beantragen:
- Implementieren Sie exponentielles Backoff und Jitter: Verwenden Sie dieses Muster für wiederholte fehlgeschlagene API-Aufrufe (besonders relevant für S3- oder DynamoDB-Limits), um eine Überlastung des Dienstes zu verhindern und die Auswirkungen der Drosselung zu minimieren.
- Optimieren Sie die Batch-Verarbeitung: Fassen Sie mehrere einzelne API-Aufrufe in einzelnen Batch-Operationen zusammen, wo dies unterstützt wird (z. B. DynamoDB BatchWriteItem).
- Nutzen Sie Caching: Implementieren Sie ElastiCache oder CloudFront, um die Anzahl der Anfragen zu reduzieren, die Backend-Dienste erreichen, und verringern Sie so die Wahrscheinlichkeit, RPS-Limits zu erreichen.
Umgang mit abgelehnten Anträgen
Wenn AWS Ihr angefordertes Limit ablehnt oder erheblich reduziert, bedeutet dies in der Regel, dass die Begründung unzureichend war oder die Anfrage die Sicherheitsparameter überschritten hat.
Aktionsplan bei Ablehnung:
- Reichen Sie nicht sofort einen neuen Antrag ein. Überprüfen Sie den Ablehnungsgrund, den der AWS-Support angegeben hat.
- Verfeinern Sie die Begründung: Geben Sie spezifischere Datenpunkte, interne Metriken und eine klarere Berechnungsmethodik an.
- Kontaktieren Sie den Support direkt: Wenn das Problem dringend oder komplex ist, antworten Sie auf den Support-Fall, bitten Sie um eine Erklärung und bieten Sie an, einen Anruf zu vereinbaren, um die architektonischen Anforderungen zu überprüfen.
Überprüfung nach der Erhöhung
Nachdem ein Limit erhöht wurde, aktualisieren Sie Ihre CloudWatch-Alarme, um den neuen 80%-Schwellenwert widerzuspiegeln. Die bloße Erhöhung ist nicht das Ende; eine kontinuierliche Überwachung stellt sicher, dass Sie das neue Limit in Zukunft nicht unerwartet erreichen.
Fazit
Die Kontingentverwaltung ist Teil der Produktionskapazitätsplanung. Verfolgen Sie die Kontingente, von denen Ihre Architektur abhängt, alarmieren Sie, bevor Ihnen der Spielraum ausgeht, und beantragen Sie Erhöhungen mit denselben Nachweisen, die Sie auch in einer Skalierungsüberprüfung verwenden würden: aktuelle Nutzung, erwarteter Spitzenwert, Region, Zeitplan und wie Sie die Zahl berechnet haben.