Cloud-Kosten sind Architektur: Azure-Entscheidungen mit Preiswirkung

19.7.2026 · 3 Min. Lesezeit

Nicht Kapazität, sondern deine Architektur treibt die Rechnung. So verankerst du Kosten als Anforderung, wählst passende Azure-Preismodelle, beherrschst Egress und nutzt FinOps-Guardrails praktisch.

Eine halbtransparente stilisierte Cloud-Box schwebt links oberhalb einer neonbeleuchteten futuristischen Stadt, aus ihr strömen neonblaue und magentafarbene Leitungen zu kleineren Serviceknoten und einem Cluster aus Geldsymbolen; nasse Straßen spiegeln silhouettierte Serverracks, skalierbare Kacheln und dünne leuchtende Diagramm-Overlays visualisieren Kostenflüsse und Architekturentscheidungen.

Warum Kosten früh in die Architektur gehören

In der Cloud entstehen Ausgaben durch Architekturentscheidungen: Dienstauswahl, Datenwege, Resilienz- und Skalierungsmodelle. Kosten sind damit eine nicht‑funktionale Anforderung (nicht-funktionale Anforderung (NFA)), die du im Entwurf explizit machst. Dokumentiere Annahmen, Grenzen und Trade-offs, statt sie später teuer zu korrigieren.

Azure-Preismodelle bewusst kombinieren

Verbrauchsbasiert (Pay‑as‑you‑go): Du zahlst, was du nutzt. Gut für variable Last, Vorproduktion und kurzlebige Projekte.
Verpflichtungsbasiert: Azure‑Reservierungen und der Azure‑Sparplan für Compute senken Tarife bei vorhersehbarer, konsistenter Nutzung – passend für Grundlasten in Produktion. Spitzen weiter verbrauchsorientiert auffangen.
Azure Hybrid Benefit: Vorhandene Windows Server-, SQL Server- sowie RHEL/SLES‑Lizenzen anrechnen, optional mit Reservierungen/Sparplänen kombinieren.
Abrechnung und Währung: Azure kalkuliert global in US‑Dollar; abgerechnet wird in USD und bei Bedarf in lokale Währungen umgerechnet. Plane Wechselkursrisiken ein.

Architekturstellen mit größtem Preiseinfluss

Dienstebenen (SKUs) und Features: Manche Funktionen gibt es nur in höheren SKUs. Prüfe Featurebedarf vs. Preis, bevor du hochstufst.
Resilienz an Zielgrößen ausrichten: Richte Verfügbarkeitszonen und regionales Failover an Recovery Time Objective (RTO) und Recovery Point Objective (RPO) aus – statt pauschal „maximal sicher“.
Migration und Right‑Sizing: Nutze Bewertungsdaten (CPU, RAM, IOPS, Nutzungsmuster) für die Erst‑SKU und passe nach Tests laufend an.

Datenwege, Replikation und Egress im Blick

Egress kostet: Ausgehender Internet‑Traffic und Transfer zwischen Zonen/Regionen verursachen Gebühren. Platziere Workloads nahe bei Konsumenten, minimiere Cross‑Region‑Pfade und vermeide unnötige Zonen‑Quertraffic‑Muster.
Replikation bewusst wählen: Regionsübergreifende Replikation erhöht Speicher‑ und Übertragungskosten. Entscheide aktiv/aktiv vs. aktiv/passiv anhand von RTO/RPO und Anforderungen an Datenresidenz.

Azure Functions: Kostenmechanik verstehen

Azure Functions hat verschiedene Hosting-/Abrechnungsmodelle mit unterschiedlichen Kostenprofilen:

Flex Consumption
- On‑Demand: Abrechnung für Ausführungszeit (GB‑Sekunden) und Ausführungen, mit monatlichen Freikontingenten.
- Always Ready: Vorgeheizte Instanzen mit Abrechnung für Baseline‑Speicher, Ausführungszeit und Ausführungen – ohne Freikontingente.
Sparplan für Compute: Kann sich lohnen, wenn eine planbare Grundnutzung besteht.

Praxisleitfaden:

Stark schwankend und ereignisgetrieben → On‑Demand im Flex‑Tarif bevorzugen.
Latenz‑kritische Pfade mit konstantem Durchsatz → Always‑Ready‑Instanzen erwägen und Sparplan kalkulieren.

Freimengen und konkrete Preise prüfst du immer aktuell auf der Functions‑Preisseite.

FinOps-Guardrails und Governance

Kosten als NFA verankern: Halte Lastprofile, Skalierungsregeln, Redundanzlevel, Datenwege und Egress‑Annahmen in deinen Architekturentscheidungen fest.
Tarife aktiv managen: PAYG für unklare/variable Last; Grundlast mit Reservierung/Sparplan absichern; Azure Hybrid Benefit nutzen, wenn Lizenzen vorhanden sind. Preisniveaus und regionale Verfügbarkeiten regelmäßig überprüfen.
Transparenz schaffen: Tagging‑Standards (z. B. costCenter, environment, application) und eine klare Ressourcenhierarchie etablieren, damit Kosten zuordenbar sind.
Budgets und Warnungen: Richte pro Subscription/Umgebung Budgets und Alerts ein, um Ausgaben laufend zu überwachen.
Environments differenzieren: In Nicht‑Produktivumgebungen außerhalb der Kernzeiten stoppen oder auf Null skalieren; Produktions‑, Vorproduktions‑ und DR‑Umgebungen jeweils passend zu Verfügbarkeit, Betriebszeiten und Sicherheit auslegen.

Praktischer Start: Monatsbudget per CLI

Das folgende Snippet ist illustrativ und orientiert sich an der aktuellen Azure CLI‑Referenz. Prüfe die Parameter in deiner Umgebung.

# Monatsbudget mit Betrag, Start- und Enddatum
subscriptionId="<SUBSCRIPTION_ID>"
budgetName="prd-app-budget"
amount=5000
startDate="2026-08-01"
endDate="2027-08-01"

az account set --subscription "$subscriptionId"

az consumption budget create \
  --amount "$amount" \
  --time-grain monthly \
  --budget-name "$budgetName" \
  --category cost \
  --start-date "$startDate" \
  --end-date "$endDate"

Hinweis: Die Befehlsgruppe „az consumption“ ist in der Vorschau. Prüfe Status und Parameter vor Automatisierung.

Fazit

Wenn du Kosten als Entwurfsgröße behandelst, triffst du Architekturentscheidungen bewusster: Preismodelle passend zur Last, Resilienz an RTO/RPO, Datenwege ohne teure Egress‑Pfadabhängigkeiten. Mit Tagging, Budgets und regelmäßigen Preis‑Reviews vermeidest du Überraschungen, ohne die Architektur zu überfrachten.