Azure App Service-Pläne erklärt: Wie Preisstufen Funktionen und Ressourcen steuern

Von Mirko Peters · 2026-10-21

Erfahren Sie, wie Azure App Service-Pläne und Preisstufen Funktionen steuern, Rechenressourcen verwalten und die Skalierung von Web-Apps und APIs beeinflussen.

Automatisch mit KI aus dem Originalbeitrag übersetzt. Englisches Original lesen

Erfahren Sie, wie Azure App Service-Pläne Ihre Cloud-Ressourcen, Preise und wichtigen Funktionsgrenzen bestimmen. Sie lernen, typische Fallen zu vermeiden: volle gemeinsam genutzte Pläne, falsch verstandene CPU-Kontingente und eine Skalierung Ihrer Web-Apps und APIs, die im Produktivbetrieb weder unerwartete Ausfallzeiten noch explodierende monatliche Cloud-Kosten verursacht.

Das Wichtigste in Kürze

• Ein Azure App Service-Plan ist ein Bündel von Rechenressourcen, das Betriebssystem, Region, Maschinengröße, Instanzanzahl und Preisstufe festlegt.
• Preisstufen wirken eher als Funktionsschranken denn als einfache Größenupgrades: Benutzerdefinierte Domänen, SSL-Zertifikate, Bereitstellungsslots und automatische Skalierung sind erst ab bestimmten Stufen verfügbar.
• Alle Apps, die im selben App Service-Plan bereitgestellt werden, nutzen denselben zugrunde liegenden Rechenpool und werden stets gemeinsam skaliert.
• Die Stufen Free und Shared begrenzen die täglichen CPU-Minuten streng und bieten keine wichtigen Funktionen wie „Always On“. Sie eignen sich daher nur für einfache Testläufe.
• Produktionsworkloads benötigen mindestens die Stufe Basic, um dedizierte Maschinen, Unterstützung für benutzerdefinierte Domänen und einen Schutz vor Leerlauf-Timeouts der Anwendung zu erhalten.

Der Aufbau eines App Service-Plans

Wenn Sie Web-Anwendungen und REST-APIs in der Microsoft-Cloud bereitstellen, erstellen Sie als Erstes einen App Service-Plan. Viele Entwickler glauben irrtümlich, sie kaufen lediglich Hosting für eine einzelne Web-App. Tatsächlich ist der Plan das eigentliche Produkt, das Sie erwerben. Er stellt einen gemeinsam genutzten Pool virtueller Maschinen bereit und legt gleichzeitig fünf grundlegende Entscheidungen fest: das Betriebssystem, die Region, in der Ihr Code liegt, die physische Größe der Maschinen, die Anzahl der aktiven Instanzen und die Preisstufe.

Da mehrere Apps in einem einzigen Plan liegen können, greifen alle Anwendungen, Hintergrundaufträge, Diagnoseprotokolle und Bereitstellungsslots auf denselben Ressourcenpool zu. Die Isolation der Rechenleistung erfolgt ausschließlich auf Planebene, nicht auf Ebene der einzelnen App. Wenn Sie drei unterschiedliche Microservices oder interne Portale in einen Plan legen, verbraucht ein Traffic-Anstieg bei einer einzelnen App CPU- und Speicherressourcen, die sich auch die Nachbarn teilen. Wenn Ihr Produktivsystem daher plötzlich Zeitüberschreitungen meldet, liegt die Ursache selten an einem Fehler im Code. Meist haben Sie Ihren App Service-Plan schlicht unbemerkt überlastet.

Preisstufen als Funktionsschranken

Viele Cloud-Einsteiger betrachten die Preisleiter von App Service – von Free und Shared über Basic und Standard bis hin zu Premium und Isolated – als einfache Größenangabe, bei der Sie für eine schnellere Maschine mehr zahlen. Microsoft versteht diese Stufen jedoch in erster Linie als Funktionsschranken. Ein Aufstieg auf der Leiter weist nicht einfach nur mehr Arbeitsspeicher oder Rechenleistung zu; er schaltet vor allem die Fähigkeiten frei, die Ihre Architektur für einen professionellen Betrieb benötigt.

Beispielsweise beschränkt Sie der Tarif Free auf eine einzige App pro Plan, begrenzt die tägliche CPU-Nutzung auf sechzig Minuten, stellt ein Gigabyte Arbeitsspeicher zur Verfügung und blockiert benutzerdefinierte Domänennamen vollständig. Ihre Anwendung muss unter einer Standardadresse der Form azurewebsites.net laufen. Darüber hinaus sind Funktionen wie Bereitstellungsslots, automatische Skalierung und die entscheidende Einstellung „Always On“ (sie verhindert, dass inaktive Web-Apps heruntergefahren werden und beim Neustart Kaltstarts verursachen) erst in höheren Stufen des Tarifsystems verfügbar.

Die Fallstricke der Tarife Free und Shared verstehen

Die Tarife Free und Shared sind ausdrücklich als Testumgebungen konzipiert, nicht als produktive Umgebungen. Sechzig oder 240 Minuten tägliche CPU-Zeit klingen für einen Prototyp großzügig, doch eine stark frequentierte Webseite oder ein aggressiver Power Automate-Flow, der Ihre REST-API abfragt, kann dieses Kontingent innerhalb weniger Stunden aufbrauchen. Außerdem unterstützen diese untersten Tarife keine horizontale Skalierung auf mehrere Instanzen. Hohe Parallelität führt daher sofort zu Drosselung und fehlgeschlagenen Anfragen.

Umstieg auf dedizierte Compute-Tarife

Für alles Robuste, das Sie für einen Kunden oder ein internes Team bereitstellen, ist der Tarif Basic das absolute funktionale Minimum. Basic bietet dedizierte virtuelle Maschinen, die Integration benutzerdefinierter Domänen, verwaltete TLS/SSL-Zertifikate und die Konfigurationsoption „Always On“. Mit den Tarifen Standard und Premium erhalten Sie weitere Enterprise-Funktionen, etwa Bereitstellungsslots für Releases ohne Ausfallzeit und Regeln für die automatische horizontale Skalierung.

Vertikal oder horizontal skalieren

Für den Umgang mit Leistungsspitzen und Traffic-Schwankungen ist der grundlegende Unterschied zwischen vertikaler und horizontaler Skalierung in Azure App Service entscheidend. Diese beiden Konzepte zu verwechseln führt häufig zu Architekturproblemen und aufgeblähten Cloud-Rechnungen.

Vertikal skalieren bedeutet Wachstum in die Höhe: Sie wechseln Ihren App Service-Plan auf eine größere Maschinengröße oder einen höheren Preistarif, um mehr Rechenleistung und freigeschaltete Plattformfunktionen zu erhalten. Horizontal skalieren bedeutet Wachstum in die Breite: Sie fügen weitere identische Kopien Ihrer virtuellen Maschineninstanzen hinter demselben Endpunkt hinzu, sodass eingehende HTTP-Anfragen gleichmäßig auf einen größeren Pool verteilt werden.

Während Basic-Tarife manuelle Anpassungen der Instanzanzahl erlauben, beginnt die automatische Skalierung auf Basis von CPU-Prozentwerten oder Zeitplänen erst im Tarif Standard. Jede zusätzliche Instanz ist eine weitere physische Maschine, die Ihren Code ausführt, und wirkt sich direkt auf Ihre monatlichen Ausgaben aus. Für einen tieferen Einblick in die Verwaltung Ihrer Cloud-Workloads und die Auswahl passender Konfigurationen hören Sie sich unbedingt die vollständige Folge an. Dort erhalten Sie Expertenwissen und praxisnahe Hinweise.

Fazit

Azure App Service zu beherrschen bedeutet, über die Einfachheit des Code-Deployments hinauszublicken und die wirtschaftlichen Grundlagen von Plänen und Tarifen zu verstehen. Wenn Sie erkennen, dass Ihr Plan Ressourcenkonkurrenz, Funktionsverfügbarkeit und Skalierungsgrenzen bestimmt, können Sie belastbare Cloud-Architekturen entwerfen, die ohne unerwartete Kosten sauber skalieren. Ob Sie ein internes Tool, ein Mobile-Backend oder APIs für die Power Platform hosten: Die Wahl des richtigen Tarifs von Anfang an spart später Stunden an Refactoring. Hören Sie sich die vollständige Folge des M365 FM Podcast an, in der wir ausführlich über die Vermeidung typischer Anfängerfallen, die Verwaltung von Bereitstellungsslots und die Optimierung Ihrer Microsoft-Cloud-Umgebung sprechen.

Häufige Fragen

Was ist ein Azure App Service-Plan?

Ein Azure App Service-Plan legt die Gruppe physischer Rechenressourcen, das Betriebssystem, die Region und die Skalierungsgrenzen fest, die von einer oder mehreren Web-Apps oder APIs genutzt werden. Er bildet die Abrechnungs- und Ressourcengrenze für Ihre Cloud-Bereitstellungen.

Warum sind Funktionen an Preistarife gebunden?

Microsoft gliedert die App Service-Tarife so, dass sich gelegentliche Testumgebungen von produktiven Enterprise-Workloads unterscheiden. Funktionen wie benutzerdefinierte Domänen, Bereitstellungsslots und automatische Skalierung erfordern dedizierte Infrastruktur und Verwaltungsaufwand, der nur in kostenpflichtigen Tarifen enthalten ist.

Können mehrere Apps denselben App Service-Plan nutzen?

Ja, Sie können mehrere Web-Apps und APIs innerhalb eines einzelnen App Service-Plans betreiben. Alle Apps in diesem Plan teilen sich jedoch die zugrunde liegenden CPU- und Speicherressourcen und werden stets gemeinsam skaliert.

Was ist der Unterschied zwischen vertikaler und horizontaler Skalierung?

Skalieren bedeutet, auf eine größere Maschinengröße oder eine höhere Preisstufe zu wechseln, um mehr Leistung und Funktionen zu erhalten. Beim horizontalen Skalieren hingegen fügen Sie weitere identische Instanzen Ihrer App hinzu, um höhere Datenverkehrsaufkommen zu bewältigen.