Azure App Services - Skalierung & Kostenoptimierung

Wenn du Webanwendungen auf Azure betreibst, ist eine gute Skalierungsstrategie Pflicht. Ohne sie riskierst du entweder, dass deine App bei Lastspitzen einknickt oder dass du unnötig viel Geld für Ressourcen zahlst, die du gar nicht brauchst. In diesem Artikel schauen wir uns an, wie du mit Azure App Services richtig skalierst und dabei gleichzeitig die Kosten im Griff behältst.

Warum Skalierung wichtig ist

Skalierung sorgt für Performance und Verfügbarkeit, besonders bei Trafficspitzen, Launches oder saisonalen Schwankungen. Wenn du aber zu früh zu viel hochskalierst oder aus Bequemlichkeit alles immer auf maximal stellst, wird’s teuer. Deshalb brauchst du eine Skalierungsstrategie, die sich an deinem echten Bedarf orientiert.

Vertikal skalieren: Den richtigen App Service Plan wählen

Dein App Service Plan bestimmt, wie viel Power dir zur Verfügung steht und welche Features du nutzen kannst.

Basic ist günstig, aber eben sehr eingeschränkt, zum Beispiel ohne Autoscaling oder Reserved Instances. Der Standard Plan bringt Autoscaling und Staging Slots mit, ideal für viele Business Anwendungen. Wenn du maximale Performance brauchst oder viele parallele Instanzen betreiben willst, kommst du an Premium V2 oder V3 nicht vorbei hier bekommst du SSDs, mehr CPU, mehr RAM und die Option auf bis zu 50 Instanzen.

Wer heute einen neuen App Service erstellt, bekommt nur noch die Wahl zwischen Basic und Premium V3. Sowohl die Standard als auch Pv2 sind zwar noch verfügbar, aber nicht mehr die erste Wahl. Premium V3 ist der neue Standard und bietet die besten Features und Performance. Auch aus Kostensicht ist Premium V3 oft die bessere Wahl, da du hier mehr Leistung für dein Geld bekommst.

Am Anfang lohnt es sich, mit einem kleineren Plan zu starten und erst zu skalieren, wenn du es wirklich brauchst. Viele Anwendungen laufen problemlos auf kleinen Instanzen. Auch ist eine Skalierung von Basic nach Premium V3 jederzeit möglich.

Bedenke dabei aber, dass jede vertikale Skalierung mit einer Downtime verbunden ist, da der Wechsel mit einem Umzug auf eine neue VM hinter den Kulissen einhergeht.

Tipp: Dieser Wechsel der VM kann aber auch hilfreich sein. Wenn deine Instanz hängt oder nicht mehr reagiert, kann ein Scale Up und direkt danach ein Scale Down das Problem beheben, weil dabei die zugrunde liegende VM neu bereitgestellt wird.

resource appServicePlan 'Microsoft.Web/serverfarms@2022-03-01' = {
  name: 'my standard plan'
  location: resourceGroup().location
  sku: {
    name: 'S1' // Standard S1 Plan
    tier: 'Standard'
    capacity: 1 // Anzahl der Instanzen (kann für horizontale Skalierung erhöht werden)
  }
}

Horizontal skalieren: Mehr Instanzen bei Bedarf

Neben der Größe der Instanzen kannst du auch die Anzahl der Instanzen erhöhen. Das nennt man horizontale Skalierung. Dabei werden mehrere Instanzen deiner App parallel betrieben, um mehr Anfragen gleichzeitig verarbeiten zu können und die Ausfallsicherheit zu erhöhen.

Im Standardtarif geht das bis zu 10 Instanzen, im Premium V3 bis zu 50. Aber Achtung: Jede Instanz kostet Geld. Es macht also keinen Sinn, pauschal immer mehrere Instanzen laufen zu lassen. Stattdessen solltest du skalieren, wenn bestimmte Schwellenwerte erreicht werden, etwa bei hoher CPU Last, hohem Arbeitsspeicherverbrauch oder wenn die HTTP Queue anschwillt.

Die optimale Anzahl an Instanzen hängt maßgeblich von den nichtfunktionalen Anforderungen an die Verfügbarkeit ab. Für eine Verfügbarkeit von 99,9 % empfiehlt Microsoft mindestens drei Instanzen, bei 99,5 % reichen zwei Instanzen aus. So stellst du sicher, dass bei einem Ausfall einer Instanz die App weiterhin erreichbar bleibt und die Last gleichmäßig verteilt wird.

Auch für Features wie den Health Check, der die Verfügbarkeit überwacht und bei Problemen Instanzen neu startet, ist eine Mehrzahl an Instanzen essenziell. Mit nur einer Instanz kann es im Fehlerfall bis zu 60 Minuten dauern, bis ein automatischer Neustart erfolgt. Mit mehreren Instanzen erfolgt das Failover hingegen nahtlos und ohne längere Ausfallzeiten.

Horizontal oder vertikal skalieren – was ist sinnvoll?

Ob du horizontal (mehr Instanzen) oder vertikal (größere Instanz) skalierst, hängt von deinen Anforderungen ab. Vertikale Skalierung ist einfach umzusetzen und oft der erste Schritt, stößt aber schnell an technische und wirtschaftliche Grenzen. Horizontal zu skalieren erhöht die Ausfallsicherheit und verteilt die Last besser, ist aber komplexer und kann zusätzliche Anpassungen an deiner App erfordern (z. B. für Session-Handling oder Caching).

Faustregel:

• Vertikal skalieren, wenn deine App mehr Leistung (z.B. mehr Speicher oder CPU) braucht und keine Anpassungen am Code nötig sind.
• Horizontal skalieren, wenn du hohe Verfügbarkeit und Lastverteilung benötigst oder die vertikale Skalierung ausgereizt ist.

In der Praxis ist oft eine Kombination aus beidem optimal: Starte mit einer passenden Instanzgröße und skaliere dann bei Bedarf horizontal, um flexibel auf Lastspitzen zu reagieren.

Skalierung manuell oder automatisch?

Manuelle Skalierung funktioniert, ist aber nicht reaktiv. Du musst selbst schauen, wann du rauf oder runter skalierst. Das ist bei kleineren Apps ok, aber ab einem gewissen Punkt willst du, dass Azure das für dich übernimmt.

Mit Autoscaling kannst du regelbasiert horizontal skalieren: Skalieren, wenn CPU Auslastung länger als 5 Minuten über 70 Prozent liegt? Kein Problem. Noch besser ist es, diese Regeln mit einem Zeitplan zu kombinieren. Tagsüber mehr Instanzen, nachts runter spart Geld und hält die Performance stabil. Versuche dabei frühzeitig zu skalieren. Wer bei 100% CPU Auslastung erst skaliert, hat schon verloren.

Ganz wichtig: Setz dir klare Grenzen. Definiere eine minimale und maximale Anzahl an Instanzen. Nur hochskalieren reicht nicht. Runterskalieren muss genauso automatisch passieren. Schalte Azure Monitor ein und aktiviere Alerts, damit du sofort mitbekommst, wenn etwas aus dem Ruder läuft. Wenn deine App langfristig läuft, prüfe unbedingt, ob Reserved Instances für dich in Frage kommen. Damit kannst du bis zu 60 Prozent Kosten sparen.

Wer sich nicht mit den richtigen Schwellwerten für Metriken rumschlagen möchte, kann mittlerweile auch ein Automatic Scaling konfigurieren. Dabei übernimmt der Azure App Service basierend auf dem aktuellen HTTP Traffic, also der aktuellen Anzahl an Requests, die passende horizontale Skalierung. Hierbei definiert man nur die minimale und maximale Anzahl an Instanzen pro App Service, zwischen denen skaliert werden soll. Für alle die gerade mit einer Laststrategie anfangen, ist das definitiv eine gute Wahl.

Eine automatische vertikale Skalierung wird von Azure App Services nicht unterstützt. Zwar lassen sich mit Azure Runbooks oder Azure Functions Workarounds bauen, in der Praxis ist dies jedoch selten sinnvoll, da jeder vertikale Skalierungsvorgang mit einer Downtime verbunden ist. Daher empfiehlt es sich, vertikale Anpassungen gezielt und manuell durchzuführen.

Skalierung mit Infrastructure as Code steuern

Wenn du mit ARM, Bicep oder Terraform arbeitest, kannst du deine Skalierung komplett versionieren. Skalierungsregeln, Limits, Zeitpläne alles als Code definiert. So lässt sich alles über deinen CI/CD Prozess automatisch ausrollen. Vorteil: Du hast immer den Überblick, kannst Änderungen nachvollziehen und stellst sicher, dass alles einheitlich umgesetzt wird.

Wichtig ist hierbei auch, dass eine manuelle Skalierung nicht manuell direkt im Azure Portal passiert, sondern immer über den CI/CD Prozess. Das manuelle Skalieren im Azure Portal ist nicht nachvollziehbar. Änderungen gehen schnell verloren oder werden nicht dokumentiert, was zu Inkonsistenzen und Problemen bei der Fehlersuche führen kann. Mit Infrastructure as Code (IaC) sind alle Anpassungen versioniert, automatisiert und jederzeit reproduzierbar.

resource autoscaleSetting 'Microsoft.Insights/autoscalesettings@2022-10-01' = {
  name: 'appservice cpu autoscale'
  location: resourceGroup().location
  properties: {
    profiles: [
      {
        name: 'CPU based autoscale'
        capacity: {
          minimum: '1'
          maximum: '3'
          default: '1'
        }
        rules: [
          // Hochskalieren bei hoher CPU Last
          {
            metricTrigger: {
              metricName: 'CpuPercentage'
              metricNamespace: 'Microsoft.Web/serverfarms'
              metricResourceUri: appServicePlan.id
              timeGrain: 'PT1M'
              statistic: 'Average'
              timeWindow: 'PT5M'
              timeAggregation: 'Average'
              operator: 'GreaterThan'
              threshold: 70
              dimensions: []
            }
            scaleAction: {
              direction: 'Increase'
              type: 'ChangeCount'
              value: '1'
              cooldown: 'PT5M'
            }
          }
          // Runterskalieren bei niedriger CPU Last
          {
            metricTrigger: {
              metricName: 'CpuPercentage'
              metricNamespace: 'Microsoft.Web/serverfarms'
              metricResourceUri: appServicePlan.id
              timeGrain: 'PT1M'
              statistic: 'Average'
              timeWindow: 'PT10M'
              timeAggregation: 'Average'
              operator: 'LessThan'
              threshold: 40
              dimensions: []
            }
            scaleAction: {
              direction: 'Decrease'
              type: 'ChangeCount'
              value: '1'
              cooldown: 'PT10M'
            }
          }
        ]
      }
    ]
    enabled: true
    targetResourceUri: appServicePlan.id
  }
}

Fazit

Mit einem durchdachten Setup aus Planwahl, Autoscaling, Monitoring und IaC hast du deine Azure App Services fest im Griff. Du kannst Performance liefern, wenn sie gebraucht wird und sparst, wenn gerade wenig los ist. Das macht deine Anwendung nicht nur technisch stabil, sondern auch wirtschaftlich effizient.

Wie gehst du aktuell beim Skalieren und Optimieren deiner Azure App Services vor?

Schau gerne bei uns auf LinkedIn vorbei und diskutiere mit.