Wenn Azure „Keine freien Plätze“ anzeigt – Praktische Möglichkeiten, Kapazitätsengpässe zu umgehen

Praktische Möglichkeiten, Kapazitätsengpässe und Verzögerungen bei Quotenanträgen zu umgehen – und warum der richtige CSP dabei helfen kann

Es gab eine Zeit, in der die Aussage „Die Cloud ist unbegrenzt skalierbar“ wie eine universelle Konstante behandelt wurde.

Dann versetzte mir die Realität einen Schlag ins Gesicht und sagte: „Eigentlich ist diese VM-Familie in dieser Region nicht verfügbar, deine Kontingenterhöhung wurde abgelehnt, und nein, ich habe keinen voraussichtlichen Termin.“

Willkommen bei der Azure-Kapazitätsplanung im Jahr 2026.

Wenn Sie in letzter Zeit ausreichend Zeit mit der Entwicklung in Azure verbracht haben, sind Sie wahrscheinlich schon auf eine Variante desselben Problems gestoßen: Die Workloads sind fertig, die Budgets sind genehmigt, die Zeitpläne stehen fest – und dann sagt die Kapazitätsabteilung: „Oh, bless your heart.“ (Unsere Freunde aus dem Süden der USA werden das verstehen; für alle anderen: Das ist eine wirklich stilvolle Art zu sagen: „Pech gehabt, kein Platz mehr im Gasthaus.“)

Azure-Kontingente sind nach wie vor regional und dienstbezogen, und in den eigenen Leitlinien von Microsoft wird die Kontingentverwaltung weiterhin als ein pro Region und pro Dienst durchzuführender Vorgang behandelt und nicht als eine Art magischer, universeller Ressourcenpool.

Das ist kein seltener Sonderfall mehr. Es ist Teil der Diskussion über die Architektur.

Die gute Nachricht ist, dass es praktische Möglichkeiten gibt, die Probleme zu verringern oder ganz zu beseitigen. Die schlechte Nachricht ist, dass viele davon erfordern, eine äußerst unangenehme Wahrheit zu akzeptieren: Der ursprüngliche Entwurf, in den Sie sich verliebt haben, muss möglicherweise geändert werden.

Und ehrlich gesagt ist das völlig in Ordnung. Bei einer ausgereiften Cloud-Architektur geht es weniger darum, jedes Mal genau die erste Wahl zu bekommen, als vielmehr darum, Systeme aufzubauen, die auch dann noch funktionieren, wenn die Plattform sich wie ein ausgebuchtes Hotel an einem Feiertagswochenende verhält.

Kapazitätsprobleme sind die neue versteckte Abhängigkeit

Wenn Kunden heute nach einer Azure-Bereitstellung fragen, lautet eine der ersten Fragen nicht mehr nur: „Welche Größe benötigen Sie?“, sondern: „Welche Alternativen kommen für Sie in Frage?“

Denn wenn Ihre Anwendung nur auf genau einer VM-Familie, in genau einer Region und mit genau einem Bereitstellungsmodell funktioniert, haben Sie keine Cloud-Strategie entwickelt. Sie haben eine Geiselsituation geschaffen.

Die Dokumentation von Azure macht dies zwischen den Zeilen ziemlich deutlich. Die Verfügbarkeit von VM-Größen variiert je nach Region, einige Prozessorgenerationen innerhalb derselben VM-Familie unterscheiden sich je nach Region, und Microsoft weist Kunden ausdrücklich darauf hin, die Verfügbarkeit von Produkten und Größen nach Region zu prüfen, bevor sie davon ausgehen, dass die gewünschte Kapazität an ihrem gewünschten Standort vorhanden ist.

Das Ziel besteht also nicht einfach darin, „mehr Kontingente zu erhalten“. Das Ziel ist es, dem Konzept genügend Flexibilität einzubauen, damit eine Kontingentverweigerung oder ein regionaler Mangel das Projekt nicht zum Scheitern bringt.

Strategie 1: Hören Sie auf, eine VM-Familie wie einen Blutschwur zu behandeln

Eine der einfachsten Maßnahmen zur Risikominderung ist zugleich eine der wirksamsten: Man sollte sich nicht zu sehr auf eine einzige VM-Serie festlegen.

Wenn ein Kunde nach Dsv5 fragt, erkundigen wir uns sofort, ob Dsv4 akzeptabel wäre. Wenn er die D-Serie wünscht, weil diese vor drei Jahren verwendet wurde, fragen wir, ob die E-Serie möglicherweise besser auf die Arbeitslast abgestimmt ist. Wenn er auf eine bestimmte CPU-Generation fixiert ist, prüfen wir, ob er diese Generation wirklich benötigt oder ob er lediglich eine Dimensionierungsvorlage aus einer Umgebung übernommen hat, die seit der Erfindung der hässlichen Teams-Hintergründe nicht mehr hinterfragt wurde.

Dies ist von Bedeutung, da es bei der Azure-Kapazität nicht nur um die Gesamtzahl der Kerne geht. Es kommt auf die jeweilige Familie, die jeweilige Region und den jeweiligen Zeitpunkt an, zu dem Sie die Kapazität benötigen. Die Bereitschaft, zwischen Generationen oder benachbarten Serien zu wechseln, kann den Erfolg der Bereitstellung erheblich verbessern. Microsoft unterstützt nun auch flexiblere Konstrukte für VM Scale Sets, darunter „Flexible Orchestration“ und „Instance Mix“, um insbesondere den Erfolg der Bereitstellung über mehrere VM-Größen hinweg zu verbessern.

Im Klartext: Wenn die Arbeitslast gleichwertige oder nahezu gleichwertige Rechenoptionen zulässt, sollten Sie Azure mehr als eine Möglichkeit bieten, dies zu bejahen.

Das bedeutet, dass genehmigte Alternativen im Voraus dokumentiert werden müssen:

• Bevorzugt: Dsv5
• Zulässiger Ausweichwert: Dsv4
• Zweitrangige Ausweichlösung: Esv5, falls Speicherengpässe bestehen
• Vorläufiger Einsatzbereich: Fsv2 für rechenintensive Workloads, bei denen der Arbeitsspeicher nicht den Engpass darstellt

Das ist keine glamouröse Architektur. Aber genauso wenig glamourös ist es, einen Go-Live-Termin zu verpassen, weil man auf das Cloud-Äquivalent einer bestimmten Marke von Mineralwasser bestanden hat.

Strategie 2: Planen Sie regionale Flexibilität ein, bevor Sie sie benötigen

Der nächste Hebel ist die regionale Flexibilität.

Das ist nicht immer einfach, denn reale Workloads bringen Latenzanforderungen, Vorgaben zur Datenlokalisierung, Nutzerkonzentration, Präferenzen für bestimmte Regionenpaare und gelegentlich auch Führungskräfte mit sich, die darauf bestehen, dass „East US“ beruhigend klingt.

Wenn sich die Arbeitslast jedoch verlagern lässt – und sei es auch nur vorübergehend –, ist ein Wechsel der Region oft die sauberste Lösung.

Microsoft stellt weiterhin Tools und Anleitungen für den Wechsel der Region bereit, und zwar über den „Azure Resource Mover“ und entsprechende Anleitungen zur Migration, und unterscheidet dabei ausdrücklich zwischen Produktverfügbarkeit und Serviceverfügbarkeit je nach Regionstyp. Mit anderen Worten: Azure selbst weist darauf hin, dass die Wahl der Region einen wesentlichen Einfluss darauf hat, was Sie bereitstellen können. Tools wie „Azure Migrate“ und „Azure Site Recovery“ können Ihnen dabei helfen, diese Optionen einfach und kostengünstig zu prüfen – selbst wenn es nur um einen Proof of Concept geht.

Für unsere Kunden gliedern wir dies in der Regel in drei Stufen:

Stufe 1: Gleiche Zielregion, alternative Region

Wenn die Arbeitslast für eine US-Region geplant wurde, kann sie dann in einer anderen nahegelegenen US-Region ausgeführt werden, ohne dass dabei Compliance- oder Leistungsanforderungen verletzt werden?

Stufe 2: Vorübergehende regionale Entlastung

Können wir die Arbeitslast jetzt in einer anderen Region bereitstellen und sie später verlagern, sobald die gewünschte Kapazität verfügbar ist?

Stufe 3: Langfristige Neugestaltung

Sollte diese Arbeitslast überhaupt an eine bestimmte Region gebunden sein, oder sollten wir von Anfang an auf eine größere regionale Portabilität hinarbeiten?

Genau hier zeigt sich auch, wie wichtig eine gute Governance ist. Wenn die Standards für Namensgebung, Richtlinien, Vernetzung, IaC und Landing Zones klar festgelegt sind, ist die Verlagerung von Regionen zwar mühsam, aber überschaubar. Fehlt es hingegen an all dem, wird die Verlagerung von Regionen zu einem Gruppenprojekt, das an einen emotionalen Familienstreit auf einem Parkplatz erinnert.

Strategie 3: Wenn IaaS Ihnen Probleme bereitet, hören Sie auf, von IaaS zu erwarten, dass es alle Probleme löst

Eine überraschend große Anzahl von Kapazitätsproblemen bei Azure sind in Wirklichkeit Architekturprobleme, die sich als etwas anderes tarnen.

Wenn eine Arbeitslast immer noch als eine Ansammlung von VMs bereitgestellt wird, nur weil das jeder so kennt, dann können Kapazitätsengpässe schließlich dazu führen, dass man sich die sinnvollere Frage stellt: Sollte es sich dabei überhaupt noch um IaaS handeln?

Manchmal besteht die beste Lösung bei nicht verfügbarer VM-Kapazität darin, den Bedarf an VM-Kapazität zu reduzieren.

Das kann bedeuten:

• Verlagerung von Web-Ebenen von VMs auf App Service,
• die Verlagerung von Datenbanken aus selbstverwalteten VM-Bereitstellungen auf verwaltete Datenbankplattformen,
• die Verlagerung von Hintergrundprozessen in „Functions“, „Container Apps“ oder andere Plattformdienste,
• Teile einer Anwendung so umgestalten, dass nur die wirklich hartnäckigen Komponenten auf der Infrastruktur verbleiben, die Sie direkt verwalten müssen.

Das ist nicht immer möglich und sicherlich auch nicht immer schnell. Aber wenn es machbar ist, verringert PaaS Ihre Abhängigkeit von genau der Hostkapazität, die Sie ursprünglich sichern wollten. Außerdem trägt es in der Regel zur Verbesserung der Ausfallsicherheit, des Betriebs und des Lebenszyklusmanagements bei – ein netter Nebeneffekt, wenn Sie gerne mal ausschlafen möchten.

Und ja, hier steckt ein Witz darin, dass man feststellt, dass die eigene „Cloud-native-Strategie“ eigentlich aus vierzehn VMs bestand, die in einem Trenchcoat auf einem Speicher-Blob standen.

Strategie 4: Setzen Sie auf automatische Skalierung und ein „Flottenkonzept“, sofern die Arbeitslast dies zulässt

Für Workloads, die sich horizontal skalieren lassen oder Schwankungen zwischen verschiedenen Instanztypen tolerieren, bietet Ihnen das moderne Azure mehr Optionen als das alte Modell nach dem Motto „Bitte geben Sie mir 50 Exemplare genau dieser einen SKU“.

Die Azure Compute Fleet von Microsoft ist speziell darauf ausgelegt, einen beschleunigten Zugriff auf Azure-Kapazitäten in einer Region zu ermöglichen, indem VM-Größen und Preismodelle kombiniert werden, um sowohl den Preis als auch die verfügbare Kapazität zu optimieren. Ebenso sind Flexible VM Scale Sets und der Instanzmix darauf ausgelegt, das Spektrum der bereitstellbaren Kapazitäten zu erweitern, anstatt den Erfolg an eine einzige Größe zu binden.

Das löst nicht jedes Problem. Wenn Sie eine veraltete Fachanwendung betreiben, die bei Veränderungen in Panik gerät, hilft das möglicherweise nicht viel.

Bei stateless Diensten, der Stapelverarbeitung, CI/CD-Runner, Analyseknoten, Render-Workloads und anderen paralleltauglichen Konzepten kann dieser Ansatz jedoch einen echten Unterschied machen. Die Erkenntnis ist einfach: Je mehr Freiheit man der Plattform lässt, desto wahrscheinlicher ist es, dass die Plattform einen Platz für einen findet.

Strategie 5: Planen Sie eine vorübergehende Entlastung der Kapazitäten außerhalb des herkömmlichen Azure-Regionsmodells ein

Hier wird es erst richtig interessant.

Wenn die Kapazitäten in den öffentlichen Azure-Regionen knapp sind, können einige Workloads vorübergehend oder strategisch auf Hybrid- oder Multi-Cloud-Modelle verlagert werden, wobei die Azure-Governance und die betriebliche Konsistenz weiterhin gewahrt bleiben.

Die aktuelle Positionierung von Microsofts „Azure Local“ ist in diesem Zusammenhang von unmittelbarer Bedeutung. Falls Sie damit noch nicht vertraut sind: Azure Local ist eine Azure Arc-fähige Lösung für verteilte Infrastrukturen, mit der virtuelle Maschinen, Container und ausgewählte Azure-Dienste ausgeführt werden können. Im Wesentlichen handelt es sich dabei um Ihre eigene Azure-Mikroregion auf validierter Hardware, die Ihnen gehört und die Sie kontrollieren. Azure Arc unterstützt unterdessen Server, die vor Ort und in anderen Clouds betrieben werden, und bietet Ihnen damit eine Steuerungsebene, die über die nativen Azure-Regionen hinausgeht.

Das eröffnet einige praktische Möglichkeiten.

Azure Local für unterstützte Workloads

Wenn Sie über das richtige Workload-Profil und den richtigen Reifegrad im Betrieb verfügen, kann Azure Local vorübergehende oder sogar halbpermanente Kapazitätsentlastung bieten, während die Verwaltung weiterhin an den Azure-Mustern ausgerichtet bleibt. Dies kann insbesondere für verteilte Standorte, Edge-Szenarien oder Unternehmen nützlich sein, die bereits über kompatible Hardware verfügen und kurzfristig Entlastung benötigen.

Azure Arc in anderen Umgebungen

Für Workloads, die auch anderswo ausgeführt werden können, bietet Azure Arc eine Möglichkeit, die Konsistenz in Bezug auf Richtlinien, Bestandserfassung, Governance und Verwaltung über lokale Umgebungen und andere Cloud-Umgebungen hinweg zu gewährleisten. Das macht zwar nicht jede Anwendung auf magische Weise portabel, aber es sorgt dafür, dass hybride Umwege heute deutlich weniger mühsam sind als früher.

Multi-Cloud als Druckventil, nicht als Umstrukturierung

Nicht jeder Kunde benötigt eine Multi-Cloud-Strategie. Manche brauchen sie ganz und gar nicht. Andere benötigen lediglich eine Passwortrichtlinie und ein wenig Betreuung.

Eine selektive Multi-Cloud-Nutzung kann jedoch sinnvoll sein, wenn eine bestimmte unterstützte Workload durch regionale Azure-Kapazitätsengpässe blockiert wird und die geschäftlichen Auswirkungen einer Wartezeit schwerwiegender sind als der Aufwand, die Workload vorübergehend an einem anderen Ort auszuführen. Der Clou dabei ist, dies als taktisches Ventil zu betrachten und nicht als charakterliche Eigenschaft.

Denn „Wir sind Multi-Cloud“ klingt zwar beeindruckend – bis niemand mehr erklären kann, wer welche Patches installiert.

Strategie 6: Die Quotenstrategie bereits in den Versand einbauen, nicht erst nach der Ablehnungs-E-Mail

Das ist vielleicht der am wenigsten spannende Teil des Gesprächs, was natürlich bedeutet, dass er auch einer der wichtigsten ist.

Quotenanträge sollten frühzeitig gestellt werden. Die Kapazitätsprüfung sollte vor dem endgültigen Bereitstellungswochenende erfolgen. Genehmigte Alternativen sollten dokumentiert werden, bevor das Projekt davon abhängig wird. Die regionale Eignung sollte geprüft werden, bevor jemand damit beginnt, Abhängigkeiten so zu verknüpfen, als wären sie dauerhaft an einen Standort gebunden.

Die Quoten-Tools von Azure bieten nun eine zentralisierte Oberfläche unter „Meine Quoten“, über die Sie die Nutzung einsehen und Erhöhungen beantragen können. Es liegt jedoch weiterhin in Ihrer Verantwortung, zu wissen, welche Quoten von Bedeutung sind und wo Ihr Design anfällig ist.

Bei unseren Kunden gehen wir in der Regel nach einem einfachen Ablauf vor:

• Ziel-Services und SKUs nach Region überprüfen
• Überprüfen Sie vor dem Ausbau die Familien- und Regionalquoten
• Ermitteln Sie geeignete Ersatz-SKUs und Ersatzregionen
• Stellen Sie fest, ob bestimmte Komponenten als PaaS neu konzipiert werden sollten
• Richten Sie eine vorübergehende Hybrid- oder Ausweich-Hosting-Option für kritische Workloads ein
• Und dann tu erst so, als wärst du überrascht, wenn Azure wieder einen kreativen neuen Weg findet, um Schwierigkeiten zu machen

Dieser letzte Schritt ist optional, scheint aber tatsächlich vorzukommen.

Das Gespräch nach dem Motto „Unterschreib einfach eine größere Verpflichtung“

Es gibt auch einen Aspekt dieser Diskussion, der nicht gerade offen angesprochen oder dokumentiert wird.

Wenn die Kapazitäten knapp werden und die Bearbeitung von Kontingentanträgen so langsam voranschreitet wie Dachdeckerarbeiten bei der Regierung, hören Kunden manchmal eine nur allzu bekannte Botschaft: Wenn Sie bereit sind, sich zu höheren Azure-Ausgaben zu verpflichten, werden die Gespräche über Prioritäten und Zugriffsrechte in der Regel deutlich interessanter. Die MACC-Struktur von Microsoft ist ein echtes Abrechnungskonzept, das an die zugesagte Azure-Nutzung gekoppelt ist, und Microsoft positioniert sie aktiv als Möglichkeit, größere langfristige Cloud-Ausgaben zu bündeln.

Um fair zu sein: In den öffentlichen Quotenrichtlinien von Microsoft heißt es nach wie vor, dass Quotenerhöhungen über die üblichen Quoten- und Supportanfrageprozesse abgewickelt werden, wobei die Genehmigungen auf der Grundlage des angeforderten Dienstes und der Region geprüft werden. Es wird nicht öffentlich gesagt: „Unterschreiben Sie diese Verpflichtungserklärung, und Sie umgehen die Warteschlange.“

In der Praxis haben jedoch viele Kunden den Eindruck, dass das Versprechen hoher Ausgaben sie plötzlich zu einer viel interessanteren Person macht, die man gerne zurückruft.

In diesem Fall kann die Zusammenarbeit mit einem kompetenten CSP eine weitaus sinnvollere Lösung sein.

Ein guter CSP kann keine Kapazitäten aus dem Nichts zaubern, die gar nicht vorhanden sind, und wer etwas anderes behauptet, sollte wahrscheinlich auch Wunder-Vitamine aus dem Kofferraum einer Limousine verkaufen. Was ein starker CSP jedoch leisten kann, ist, viele der praktischen Ergebnisse zu erzielen, die Kunden tatsächlich anstreben, ohne dabei eine so hochgesteckte Nutzungsverpflichtung zu verlangen, die „Cloud-Flexibilität“ in einen „finanziellen Blutschwur“ verwandelt.

Das bedeutet in der Regel:

• Kunden dabei zu unterstützen, ihre Designs an die Einschränkungen bestimmter VM-Familien anzupassen, anstatt auf eine einzige perfekte SKU zu warten,
• alternative Regionen oder Architekturen zu identifizieren, in denen eine tatsächliche Bereitstellung möglich ist,
• die Arbeitslasten, soweit möglich, auf PaaS umzustellen,
• unter Nutzung von partnergesteuerten Quotenverfahren und Eskalationswegen, sofern vorhanden,
• und die Abstimmung von Reservierungen, Einsparungsstrategien und Bereitstellungsmustern auf das, was Azure heute realistisch bieten kann.

Microsoft hat zudem einige Funktionen zur Kontingentverwaltung speziell über das Partner-Ökosystem zur Verfügung gestellt, was einmal mehr verdeutlicht, dass die richtige Partnerbeziehung mehr sein kann als nur ein Mittel zur Abrechnung. Sie kann einen praktischen Vorteil bieten, wenn die Plattform zunehmend selektiver wird.

Also ja, wenn Microsoft jede Diskussion über Kapazitäten damit beenden will, dass es andeutet, eine größere Verpflichtung könnte das Leben einfacher machen, dann ist das sicherlich ein Ansatz.

Ein weiterer Ansatz besteht darin, mit einem CSP zusammenzuarbeiten, der weiß, wie man das Problem umgeht, sich wirkungsvoll für Ihre Interessen einsetzt und Sie davon abhält, sich auf ein Ausgabenziel in der Größenordnung eines kleinen Mondes einzulassen, nur um einen Rückruf zu erhalten.

Für das Umsatzteam von Microsoft ist diese Version in der Regel etwas weniger rosig.

Für den Kunden ist das in der Regel viel besser.

Entlastung ist in Sicht, nur nicht im Zeitplan Ihres Projekts

Microsoft baut die Azure-Infrastruktur in den USA weiter aus. Im Dezember 2025 gab Microsoft bekannt, dass „East US 3“ im Großraum Atlanta für Anfang 2027 geplant ist, parallel zum Ausbau von fünf bestehenden Rechenzentrumsregionen in den USA. Das ist wahr, und es sind gute Nachrichten.

Es ist auch nicht besonders hilfreich, wenn die Umstellung auf die Produktionsumgebung nächsten Monat stattfindet.

Deshalb ist „auf mehr Cloud warten“ keine Strategie.

Die regionale Expansion wirkt sich positiv auf die langfristige Entwicklung aus. Sie ersetzt jedoch nicht die Notwendigkeit einer anpassungsfähigen Architektur in der Gegenwart.

Die eigentliche Erkenntnis: Auf Optionen ausrichten

Die Kunden, die am besten mit Kapazitätsengpässen bei Azure umgehen können, sind in der Regel nicht diejenigen mit dem größten Budget oder den umfangreichsten Umgebungen.

Sie sind diejenigen, die verschiedene Optionen eingeplant haben.

Sie sind bereit, zwischen verschiedenen VM-Generationen zu wechseln. Sie wissen, wann aus der D-Serie die E-Serie werden kann. Sie wissen, wann ein regionaler Wechsel akzeptabel ist. Sie erkennen, wann IaaS PaaS weichen sollte. Sie haben einen Plan für Azure Local, Arc oder einen vorübergehenden Hybrid-Umweg parat, wenn das Unternehmen nicht darauf warten kann, dass die Kapazitäten der Public Cloud wieder verfügbar sind.

Mit anderen Worten: Sie gehen bei der Architektur so vor, als wäre das nicht ihr erstes Mal.

Denn die Cloud ist nach wie vor leistungsstark, nach wie vor flexibel und in der Regel immer noch die richtige Lösung. Es ist nur nicht mehr sicher, so zu tun, als seien die Kapazitäten unbegrenzt und jederzeit auf Abruf in jeder Form und in jeder Region verfügbar.

Manchmal hat Azure noch Platz.

Manchmal wird man bei Azure auf eine Warteliste gesetzt.

Die Organisationen, die dabei die Nase vorn haben, sind diejenigen, die für beides vorgesorgt haben.