Ende Juli 2025 führte ein Nachfragespitzenanstieg in der Azure-Region „East US“ dazu, dass die verfügbaren Rechenressourcen erschöpft waren. Kunden, die versuchten, virtuelle Maschinen (VMs) zu erstellen oder zu aktualisieren, stießen auf Zuweisung fehlgeschlagen Fehler seit über einer Woche. Microsoft bestätigte, dass die VM-Pools für allgemeine Zwecke „stark ausgelastet“ waren, wodurch die Hardware über sichere Betriebsgrenzen hinaus beansprucht wurde. Das Gleiche geschah Anfang 2026 in der Region „UK South“, wo Microsoft vorübergehend keine neuen VM-Bereitstellungen für GPU- und AMD-SKUs mehr akzeptierte. Microsofts eigener Finanzvorstand wies in mehreren Gewinnkonferenzen darauf hin, dass Kapazitätsengpässe den Umsatz bremsten. Eine interne Prognose, über die später Bloomberg berichtete, zeigte, dass die Nachfrage in wichtigen US-Regionen bis mindestens Mitte 2026 das Angebot übersteigen würde.
Die meisten Strategen reagieren darauf mit Ratschlägen wie „Nutzen Sie mehrere Regionen“ und „Berücksichtigen Sie Kapazitätsreservierungen“. Dieser Rat ist nicht falsch. Er ist nur unvollständig. Die wirklich wichtigen Entscheidungen sind schwieriger als das.
Wir arbeiten jeden Monat mit IT-Entscheidungsträgern in Hunderten von Microsoft-Umgebungen zusammen. Hier erfahren Sie, was wir tatsächlich beobachten und was wir Ihrem Team raten würden.
Die beiden Fehler und was sie tatsächlich bedeuten
Wenn Azure keine VM bereitstellen kann, gibt es eine von zwei Fehlermeldungen aus. Die meisten Nutzer behandeln diese beiden Fehler gleich. Das sollten sie jedoch nicht.
AllocationFailed Das bedeutet, dass die Orchestrierungsschicht von Azure versucht hat, verfügbare Hardware in der Region zu finden, jedoch keine gefunden hat. Der spezifische Cluster, dem Ihr Abonnement in dieser Region zugeordnet ist, verfügt über keine freien Rechenressourcen, die Ihrer Anforderung entsprechen.
ZonalAllocationFailed bedeutet, dass die von Ihnen ausgewählte Verfügbarkeitszone Einschränkungen unterliegt. Hierfür gibt es eine nützliche Abhilfe: Wenn Ihre Workload eine zonenunabhängige Bereitstellung zulässt, können Sie die Zonenbindung aus Ihrer ARM-Vorlage oder Bicep-Datei entfernen, sodass der Azure-Scheduler die gesamte Region und nicht nur eine Zone durchsuchen kann. Durch diese eine Änderung konnten wir Kapazitätsengpässe beheben, die auf den ersten Blick echt erschienen.
Diese Unterscheidung ist wichtig, da die richtige Reaktion unterschiedlich ausfällt. Zuweisung fehlgeschlagen In einem wirklich ausgelasteten Bereich lässt sich das Problem oft erst lösen, wenn man in einen anderen Bereich wechselt oder eine andere VM-Größe wählt. Zonenzuweisung fehlgeschlagen können oft gelöst werden, ohne dass man den Ort wechseln muss.
Quote vs. Kapazität: Die Verwirrung, die Wochen kostet
Dies ist die mit Abstand häufigste Ursache für Support-Eskalationen, die wir in Umgebungen mit begrenzten Ressourcen beobachten. Unternehmen erhalten eine Quotenfehlermeldung, eröffnen ein Ticket, um eine Quotenerhöhung zu beantragen, Microsoft genehmigt diese, und der Fehler besteht weiterhin. Dann dreht sich das Support-Ticket zwei Wochen lang im Kreis.
Kontingent und Kapazität sind zwei getrennte Systeme.
Eine Quote ist eine Richtlinienobergrenze: die maximale Anzahl an vCPUs oder eines bestimmten VM-Typs, die Ihr Abonnement nutzen darf. Microsoft verwaltet dies auf der Ebene der Abonnementrichtlinien. Sie können Erhöhungen über das Azure-Portal beantragen; die Genehmigungen erfolgen in der Regel innerhalb von ein bis zwei Tagen.
Die Kapazität ist eine physische Gegebenheit: Es kommt darauf an, ob tatsächlich Hardware verfügbar ist, die im Rahmen Ihres Kontingents bereitgestellt werden kann. Wenn in einer Region Kapazitätsengpässe bestehen, bringt eine Erhöhung Ihres Kontingents nichts. Sie haben nun zwar die Berechtigung, eine VM bereitzustellen, die jedoch noch nicht existiert.
Wenn du auf ein Zuweisung fehlgeschlagen Fehler: Lesen Sie die Fehlerdetails sorgfältig durch. Wenn die Meldung lautet: „Wir verfügen in dieser Region nicht über ausreichende Kapazität für die angeforderte VM-Größe“, handelt es sich um ein Kapazitätsproblem und nicht um ein Kontingentproblem. Ein Ticket zur Erhöhung des Kontingents wird hier nicht helfen. Die richtigen Schritte sind: Versuchen Sie es mit einer anderen VM-Größe, wählen Sie eine andere Region oder nutzen Sie eine Kapazitätsreservierung, wenn Sie diese bestimmte SKU fest reservieren möchten.
Die „Deallocate-and-Retry“-Falle
Einer der gefährlicheren Ratschläge in den Azure-Supportforen lautet: „Geben Sie einfach Ihre VM frei und versuchen Sie, sie neu bereitzustellen.“ Dahinter steht die Theorie, dass durch die Freigabe Ihr aktueller Rechen-Slot freigewird, wodurch der Scheduler die Möglichkeit erhält, einen neuen zu finden. Manchmal funktioniert das. Wenn ein Cluster nur geringfügig ausgelastet ist und lediglich ein erneuter Versuch des Schedulers erforderlich ist, kann die Freigabe dazu führen, dass Sie auf einen weniger ausgelasteten Rechenknoten gelangen.
Wenn in einer Region tatsächlich Kapazitätsengpässe bestehen, kann dies zu einer deutlich schlechteren Situation führen. Sie haben zwar eine laufende VM erfolgreich freigegeben, können jedoch keinen Ersatz bereitstellen. Ihre Workload ist ausgefallen, und Sie verfügen nicht mehr über die Hardware, die Sie zuvor hatten.
Genau dieses Szenario haben wir während der Kapazitätsengpässe im Osten der USA erlebt. Ein Kunde hat eine VM, auf der eine SQL-Entwicklungsumgebung lief, freigegeben, um während einer geplanten Größenanpassung „einen Platz freizumachen“. Es dauerte vier Tage, bis in einer benachbarten Region eine Ersatz-VM bereitgestellt wurde. Die Lehre daraus: Geben Sie in einer Region mit begrenzten Kapazitäten nichts frei, ohne zuvor eine Alternative bereitzustellen oder eine Kapazitätsreservierung vorzunehmen.
Warum das so ist: die weniger diskutierten Faktoren
Die oberflächliche Erklärung ist einfach: Die KI-Workloads sind explosionsartig angestiegen, und Azure konnte nicht schnell genug nachziehen. Das stimmt. Aber es gibt einige Faktoren, über die kaum berichtet wird.
Die KI-Dienste von Microsoft stehen in Konkurrenz zu Ihren Workloads. Azure Copilot, die API-Infrastruktur von OpenAI und die internen KI-Tools von Microsoft laufen in denselben physischen Rechenzentren wie Ihre VMs. Als die Region „East US“ im Juli 2025 ausgelastet war, war dies zum Teil auf den Ausbau der eigenen KI-Kapazitäten von Microsoft zurückzuführen. Jeder mit einer GPU ausgestattete Server, der für Azure OpenAI vorgesehen ist, steht für Ihre VM der NC-Serie nicht zur Verfügung. Microsoft macht diese Dynamik zwar nicht öffentlich bekannt, doch die physische Infrastruktur unterscheidet nicht zwischen einer Kunden-VM und einem eigenen KI-Dienst.
Die regionale Architektur von Azure führt zu einer ungleichmäßigen Auslastung. Azure betreibt über 70 globale Regionen und bietet damit eine größere geografische Abdeckung als jeder andere Cloud-Anbieter. Der Nachteil dabei ist, dass viele einzelne Regionen relativ klein sind. Wenn die Nachfrage in einer beliebten Region wie Nord-Virginia, Großbritannien Süd oder Westeuropa sprunghaft ansteigt, können diese Regionen schneller ausgelastet sein als eine AWS-Zone vergleichbarer Größe, da pro Standort weniger physische Kapazität zur Verfügung steht. Die breite regionale Präsenz, die Azure im Hinblick auf die Datenhoheit attraktiv macht, ist auch der Grund dafür, dass bestimmte Regionen schneller an ihre Grenzen stoßen.
Kunden mit Enterprise-Agreement und Abonnements mit hohem Umsatz werden bei Kapazitätsengpässen anders behandelt als Pay-as-you-go-Konten. Microsoft veröffentlicht dies zwar nicht ausdrücklich, doch das Verhalten ist in Support-Foren gut dokumentiert und wird in Servicemitteilungen bestätigt. Wenn Ihr Unternehmen ein Pay-as-you-go-Abonnement oder eine kleine CSP-Vereinbarung nutzt, haben Sie bei der Zuteilung von Hardware eine niedrigere Priorität. Eine praktische Konsequenz: Die Umstellung auf eine EA oder die Zusammenarbeit mit einem CSP mit Direktabrechnung und höheren fest zugesagten Ausgaben kann Ihre Erfahrungen in Zeiten knapper Ressourcen erheblich verbessern. Wir haben dies aus erster Hand bei Kunden beobachtet, die über unseren Partnerkanal eine Eskalation veranlasst haben und so eine schnellere Lösung erhielten als bei direkter Kontaktaufnahme im Rahmen eines PAYG-Abonnements.
Das Problem des Zeitpunkts der Migration
Hier ist ein Szenario, das sich derzeit in Hunderten von Unternehmen abspielt: Der Support für Windows Server 2016 läuft im Januar 2027 aus. Der Support für SQL Server 2016 läuft im Juli 2026 aus. Viele Teams planen, diese Workloads als termingebundene Umstellung auf Azure zu migrieren. Dieser Plan ist sinnvoll.
Das Problem ist, dass die Migration zu Azure in einer Phase begrenzter Kapazitäten erfolgt, wobei einige der am stärksten nachgefragten VM-SKUs in einigen der am stärksten ausgelasteten Regionen zum Einsatz kommen. Wenn Sie einen „Lift-and-Shift“-Umzug von lokalen Workloads auf Azure-VMs planen, um von den kostenlosen erweiterten Sicherheitsupdates zu profitieren, müssen Sie die reale Möglichkeit einkalkulieren, dass die von Ihnen gewünschte Region und VM-SKU zu Ihrem geplanten Zeitpunkt möglicherweise nicht verfügbar sind. Unser SQL Server-Ressourcenzentrum behandelt die EOL-Planung in diesem Zusammenhang ausführlicher, doch der praktische Punkt ist einfach: Stellen Sie Ihre Azure-VMs bereit, bevor Sie Ihren Migrationszeitplan festlegen – nicht danach. Betrachten Sie die Azure-Bereitstellung als den Schritt mit der langen Vorlaufzeit, nicht die Migration selbst.
Für Unternehmen, die neben SQL Server auch das Ende des Lebenszyklus (EOL) von Windows Server verwalten, bietet unser Vergleich zwischen Windows Server 2019, 2022 und 2025 eine Entscheidungshilfe für das Betriebssystem. Beide Probleme laufen auf denselben Azure-Kapazitätspool hinaus.
Was konkret zu tun ist: eine praktische Hierarchie
1. Ermitteln Sie zunächst Ihr tatsächliches Risiko. Nicht jede Azure-Bereitstellung birgt das gleiche Risiko. Kapazitätsengpässe sind am gravierendsten bei GPU- und HPC-VM-Familien (NC-, ND- und NV-Serien), bestimmten neueren Allzweck-Familien in stark nachgefragten Regionen sowie bei allen Bereitstellungen, die an eine einzige Verfügbarkeitszone in einem überlasteten Gebiet gebunden sind. Wenn Ihre Workloads gängige VMs der Serien Dv3, Ev3 oder Bv2 in weniger ausgelasteten Regionen nutzen, ist Ihr Risiko gering. Beginnen Sie mit einer Überprüfung, welche VMs zu SKU-Familien mit Kapazitätsengpässen und zu Regionen mit Kapazitätsengpässen gehören. Azure Resource Health und der Bereich „Service Issues“ im Portal zeigen bekannte regionale Einschränkungen an, ohne dass ein Support-Ticket erforderlich ist.
2. Nutzen Sie „az vm list-skus“, bevor Sie es benötigen. Die meisten Teams stellen erst dann fest, dass eine SKU nicht verfügbar ist, wenn sie auf den Fehler stoßen. Der Azure-CLI-Befehl az vm list-skus --location eastus --resource-type virtualMachines --output table gibt den Verfügbarkeitsstatus nach SKU und Zone zurück, noch bevor Sie die Bereitstellung versuchen. Integrieren Sie diese Überprüfung in Ihre Bereitstellungspipelines. Sie sollten Fehler bereits in der Planungsphase schnell und intelligent erkennen, statt mitten in der Bereitstellung um 23 Uhr an einem Migrationsabend scheitern.
3. Überdenken Sie Kapazitätsreservierungen für SKUs mit begrenzter Verfügbarkeit. Die Standardempfehlung lautet, Kapazitätsreservierungen zu vermeiden, da diese zu On-Demand-Tarifen abgerechnet werden, unabhängig davon, ob Sie die Rechenleistung nutzen oder nicht. Diese Logik gilt, solange das Azure-Angebot unbegrenzt ist. In einer Region mit begrenzter Verfügbarkeit wird eine Kapazitätsreservierung jedoch zu einer kostengünstigen Absicherung gegen einen Bereitstellungsfehler im ungünstigsten Moment. Rechnen Sie die Zahlen für Ihre kritischen VM-SKUs durch. Wenn Sie sich einen Bereitstellungsausfall wirklich nicht leisten können, ist eine Kapazitätsreservierung zum On-Demand-Preis mit garantierter Verfügbarkeit möglicherweise der richtige Kompromiss. Die Abwägung ändert sich, wenn die Alternative ein verpasster Migrationszeitraum ist und nicht nur eine geringfügig höhere monatliche Rechnung.
4. Erstellen Sie SKU-Ersatzlisten vor dem Auftreten von Störungen, nicht erst währenddessen. Wenn eine gewünschte VM-Größe nicht verfügbar ist, warten die meisten Nutzer ab oder reichen ein Support-Ticket ein. Der bessere Ansatz besteht darin, gleichwertige SKUs im Voraus zuzuordnen und zu testen, bevor Sie sie benötigen. Ist „Standard_D8s_v5“ in der Region „East US“ nicht verfügbar? Standard_D8s_v4 oder Standard_D8as_v5 (AMD-basiert) bieten in der Regel mehr Spielraum und eine vergleichbare Leistung für allgemeine Workloads. Wir erstellen diese Substitutionslisten für Kunden vor der Bereitstellung. Mit dieser Liste lässt sich eine Region mit Einschränkungen innerhalb von 30 Minuten umleiten – statt eines mehrtägigen Vorfalls.
5. Ziehen Sie für besonders anfällige Workloads eine Migration von IaaS zu PaaS in Betracht. Reine VM-Bereitstellungen sind am stärksten von Kapazitätsengpässen betroffen, da Sie bestimmte Hardware-SKUs an bestimmten Standorten anfordern. PaaS-Dienste wie Azure Kubernetes Service, Azure App Service und Azure Batch abstrahieren die zugrunde liegende Infrastruktur und ermöglichen es dem Scheduler von Microsoft, Workloads flexibler zu verteilen. Batch-Verarbeitungsaufträge, zustandslose Anwendungsschichten und containerisierte Workloads eignen sich hierfür oft besonders gut. Das Problem der Kapazitätsengpässe verschwindet weitgehend, sobald Sie nicht mehr auf eine bestimmte VM-SKU fixiert sind. Unser Leitfaden zur Cloud-Modernisierung erläutert, wann ein Wechsel von IaaS zu PaaS über den reinen Kapazitätsaspekt hinaus sinnvoll ist.
6. Schaffen Sie echte Redundanz über mehrere Regionen hinweg, nicht nur ein dokumentiertes Failover. In den meisten DR-Plänen ist eine sekundäre Region aufgeführt. Nur wenige haben die Bereitstellung in dieser Region in letzter Zeit tatsächlich getestet. Während der Engpässe in der Region „UK South“ stellten Kunden, die auf „UK West“ umgeschaltet hatten, fest, dass auch diese Region ausgelastet war. Microsoft empfiehlt nun, „UK South“ mit „Sweden Central“ oder „Norway East“ zu kombinieren, anstatt eine andere Region in Großbritannien zu wählen. Ihre Failover-Region muss getestet werden – man darf sich nicht auf Annahmen verlassen. Unser Leitfaden zur Multi-Cloud-Strategie behandelt architektonische Entscheidungen, die die Abhängigkeit von einer einzigen Region verringern.
Der aktuelle Stand der Dinge
Azure ist nach wie vor die richtige Grundlage für die meisten Microsoft-orientierten Unternehmen. Die Kapazitätsprobleme sind zwar real, jedoch geografisch begrenzt und werden derzeit aktiv angegangen. Microsoft investiert im Jahr 2025 über 80 Milliarden US-Dollar in den Ausbau seiner Rechenzentren, hat einen Fünfjahresvertrag über Kapazitäten mit dem Nebius-Standort in New Jersey abgeschlossen und plant für 2027 die Einrichtung der Region „East US 3“.
Aber „behoben“ ist nicht dasselbe wie „jetzt nicht mehr Ihr Problem“. Wenn Sie in den nächsten 12 bis 18 Monaten eine Bereitstellung, Migration oder Skalierung planen, gehört die Kapazität in Ihr Risikoregister – was vor zwei Jahren wahrscheinlich noch nicht der Fall war. Die Teams, die damit gut umgehen, sind nicht diejenigen mit den übersichtlichsten Architekturdiagrammen. Es sind diejenigen, die ihre Bereitstellungsskripte vor dem Migrationstermin ausgeführt haben und nicht erst dann erfahren haben, was Zonenzuweisung fehlgeschlagen bedeutet, dass um 2 Uhr morgens ein Produktionsfehler aufgetreten ist.
Wenn Sie das Gefühl haben, dass Ihre Azure-Ausgaben in keinem Verhältnis zu dem stehen, was Sie tatsächlich dafür erhalten, finden Sie im Leitfaden zur Azure-Kostenoptimierung Informationen zu dem Governance-Rahmenwerk, das wir bei unseren Kunden einsetzen. Kapazitätsplanung und Kosten-Governance sind im Grunde ein und dasselbe Thema, wenn man sich näher damit befasst.
Für den breiteren Kontext der Verwaltung von Microsoft-Produktlebenszyklen – einschließlich der Frage, was passiert, wenn EOL-Fristen für On-Premise-Lösungen dazu führen, dass Workloads in eine Cloud mit begrenzten Kapazitäten verlagert werden – bietet unser Leitfaden zum Ende des Software-Lebenszyklus und zum Support eine umfassende Anleitung. Und wenn Sie ein direktes Gespräch über Ihre spezifische Umgebung und Ihre Risiken wünschen, stehen Ihnen unsere Cloud-Architekten gerne zur Verfügung – sie beschäftigen sich täglich mit solchen Themen.
