Cloud Preise Vergleich 2025: AWS vs Azure vs Google Cloud

Cloud-Rechnungen explodieren. Ein Fortune-500-Unternehmen, das wir 2024 beraten haben, zahlte 3,2 Millionen Euro mehr als geplant — allein wegen ineffizienter Ressourcennutzung. Die Wahl des falschen Cloud-Anbieters kostet nicht nur Geld. Sie kostet Wettbewerbsfähigkeit.

Das Kernproblem: Warum Cloud-Kosten außer Kontrolle geraten

Cloud-Finanzmanagement bleibt die größte Herausforderung für IT-Führungskräfte. Laut Flexera State of the Cloud Report 2024 geben 87 % der Unternehmen Cloud-Kostenoptimierung als Top-Priorität an. Trotzdem überschreiten 76 % regelmäßig ihre Budgets.

Das Problem ist dreifach:

Versteckte Kosten werden erst bei der Rechnung sichtbar. Egress-Gebühren, NAT-Gateway-Nutzung,预留-Instances ohne Nutzung — die Liste ist endlos.

** Fehlende Visibility führt zu Schatten-IT. Geschäftsbereiche provisionieren Ressourcen ohne Abstimmung mit der zentralen IT. Das Ergebnis: Duplikate, Sicherheitslücken, Kostenlawinen.

** On-Demand-Preise sind für Produktionsworkloads wirtschaftlicher Unsinn. Wer EC2-Instanzen zum Listenpreis betreibt, verschenkt 40–70 % an Effizienz.

Ein konkretes Beispiel: Eine mittelständische Bank in Frankfurt betrieb ihre Kernanwendung auf AWS r5.4xlarge-Instanzen. Nach einem Cost Audit wechselten wir zu Savings Plans — die jährliche Rechnung sank von 840.000 € auf 512.000 €, ohne Leistungseinbußen.

Tiefe Kostenanalyse: AWS, Azure und Google Cloud 2025

Die drei großen Anbieter haben ihre Preisstrukturen 2024 und 2025 weiter ausdifferenziert. Hier ist die fundierte Gegenüberstellung:

Compute-Kosten im direkten Vergleich

Instanz-Typ	AWS ($/Std.)	Azure ($/Std.)	GCP ($/Std.)
General Purpose 4vCPU	0,192	0,195	0,190
Memory Optimized 8vCPU	0,456	0,448	0,441
Compute Optimized 8vCPU	0,362	0,358	0,350
GPU T4 (Pay-as-you-go)	3,46	3,67	3,22

Google Cloud liegt bei Compute-Instanzen meist 5–8 % unter AWS. Azure positioniert sich als Middle-of-the-Market-Option. Diese Zahlen repräsentieren On-Demand-Preise — ohne Reservierungen oder Committed Use Contracts.

Speicherpreise: Ein kritischer Unterschied

AWS S3 Standard: $0,023/GB/Monat
Azure Blob Storage (Hot): $0,0184/GB/Monat
Google Cloud Storage (Standard): $0,020/GB/Monat

Azure gewinnt bei Speicherpreisen, aber Vorsicht: Die Read/Write-Operationen kosten extra. Bei Write-heavy Workloads gleicht sich der Vorteil schnell aus.

Egress-Kosten: Der versteckte Budget-Killer

Anbieter	Erste 10 TB/Monat	10–50 TB	50–150 TB
AWS	$0,09/GB	$0,085/GB	$0,07/GB
Azure	$0,087/GB	$0,083/GB	$0,07/GB
GCP	$0,12/GB	$0,11/GB	$0,08/GB

Google Cloud hat die aggressivsten Egress-Preise. Für global verteilte Anwendungen mit hohem Datentransfer ist GCP die teuerste Wahl.

Real-World-Kostenmodell: Drei-Szenario-Analyse

Szenario: E-Commerce-Plattform mit 500.000 monatlichen aktiven Nutzern

AWS-Konfiguration:

• 20x c6i.2xlarge (Reserved 1 Jahr) = $2.432/Monat
• RDS PostgreSQL db.r6g.large (3 Availability Zones) = $892/Monat
• S3 + CloudFront = $340/Monat
• Data Transfer = $580/Monat
• Total: ~$4.244/Monat

Azure-Äquivalent:

• 20x D2s_v5 (Reserved 1 Jahr) = $2.280/Monat
• Azure Database for PostgreSQL (Business Critical) = $1.100/Monat
• Blob Storage + CDN = $390/Monat
• Data Transfer = $540/Monat
• Total: ~$4.310/Monat

GCP-Äquivalent:

• 20x n2-standard-8 (Committed Use) = $2.180/Monat
• Cloud SQL (High Availability) = $980/Monat
• Cloud Storage + Cloud CDN = $360/Monat
• Data Transfer = $720/Monat
• Total: ~$4.240/Monat

Die totals sind ähnlich. Der Teufel liegt in den Details: Support-Kosten, Compliance-Upcharges, und die spezifischen Preismechanismen jedes Anbieters.

Praktische Implementierung: So optimieren Sie Ihre Cloud-Ausgaben

Schritt 1: Baseline etablieren mit nativen Tools

Ohne Visibility keine Optimierung. Starten Sie mit den kostenlosen Bordmitteln:

# AWS: Cost Explorer aktivieren und Tagging-Strategie implementieren
aws ce get-cost-and-usage \
  --time-period Start=2024-01-01,End=2025-01-01 \
  --granularity MONTHLY \
  --metrics "BlendedCost" "UnblendedCost" "UsageQuantity"

# Azure: Cost Management API für detaillierte Analyse
az costmanagement query \
  --type actualcost \
  --timeframe MonthToDate \
  --dataset-aggregation "TotalCost"

# GCP: Billing Export zu BigQuery für SQL-basierte Analyse
bq query \
  --use_legacy_sql=false \
  'SELECT service.description, SUM(cost) as total_cost
   FROM `project.billing_data.gcp_billing_export_v1_XXXX`
   GROUP BY service.description
   ORDER BY total_cost DESC'

Schritt 2: Tagging-Strategie implementieren

Ungetaggte Ressourcen sind nicht mehr auffindbar. Ohne konsequentes Tagging ist Cost Allocation reine Spekulation.

Erstellen Sie einen Tagging-Standard und setzen Sie ihn mit Policy-as-Code durch:

# Terraform: AWS Tagging Policy mit SCPs
resource "aws_s3_bucket" "app" {
  bucket = "production-data-${var.environment}"
  
  tags = {
    Environment = "production"
    Owner       = "platform-team"
    CostCenter  = "CC-2024-Q4-001"
    Project     = "customer-portal"
    ManagedBy   = "terraform"
  }
}

# Azure Policy: Erforderliche Tags durchsetzen
resource "azurerm_policy_definition" "require_tags" {
  name         = "require-cost-center-tag"
  policy_type  = "Custom"
  mode         = "Indexed"
  display_name = "Require Cost Center Tag"
  
  policy_rule = jsonencode({
    "if" : {
      "field" : "tags.CostCenter",
      "exists" : "false"
    },
    "then" : {
      "effect" : "deny"
    }
  })
}

Schritt 3: Reserved Instances und Savings Plans strategisch einsetzen

On-Demand ist für Produktionsworkloads unwirtschaftlich. Die optimale Reserve-Strategie:

• Basis-Load (60–70 % der durchschnittlichen Nutzung): 1-Jahres Reserved oder Committed Use mit No Upfront
• Spitzen-Kapazität (30–40 %): On-Demand für Flexibilität
• Experimentelle Workloads: Spot Instances mit 60–80 % Discount

# AWS Savings Plans Recommendation abrufen
aws cost-optimization-loader get-savings-plans-recommendation \
  --payment-option NO_UPFRONT \
  --term-in-years 1 \
  --service-family Compute

# Azure Reserved VM Instances Recommendation
az vm reservation recommend \
  --subscription "subscription-id" \
  --resource-group "rg-production"

Schritt 4: Kubernetes-Kosten无处不在 optimieren

Für Container-Workloads ist Right-Sizing kritisch:

# KEDA: Kubernetes Event-driven Autoscaling für Kostenoptimierung
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: app-scaler
spec:
  scaleTargetRef:
    name: production-app
  minReplicaCount: 2
  maxReplicaCount: 20
  triggers:
  - type: prometheus
    metadata:
      serverAddress: http://prometheus:9090
      metricName: http_requests_per_second
      threshold: "100"
      query: sum(rate(http_requests_total[2m]))

Häufige Fehler: Warum Cloud-Optimierung scheitert

Fehler 1: Keine Right-Sizing-Analyse nach Migration

Nach einer Cloud-Migration werden Workloads 1:1 portiert. VM-Größen, die für On-Premise-Kapazitätsplanung überdimensioniert waren, bleiben bestehen. Das Ergebnis: 40 % überdimensionierte Instanzen.

Lösung: Nach 30 Tagen Produktivbetrieb eine Right-Sizing-Analyse mit AWS Compute Optimizer, Azure Advisor oder GCP Recommender durchführen.

Fehler 2: Multi-Cloud als Kostensenkungsstrategie missverstehen

Der Mythos: „Wir nutzen mehrere Clouds, um Preiskämpfe auszunutzen." Die Realität: Multi-Cloud verdoppelt Betriebskosten, Komplexität und Security-Overhead. Die erzielten Einsparungen werden von Management-Kosten aufgefressen.

Lösung: Multi-Cloud nur für Disaster Recovery, Compliance oder spezifische Use Cases. Nicht als primäre Kostenstrategie.

Fehler 3: Egress-Kosten unterschätzen

Engineers fokussieren auf Compute und Storage. Data Transfer wird zur bösen Überraschung. Ein einziger Data Lake mit 50 TB monatlichem Egress kann $4.500 extra kosten.

Lösung: Data Flow Diagramme erstellen, Egress-Kosten in der Architektur-Phase modellieren, CloudFront/Cloud CDN für globale Distribution nutzen.

Fehler 4: Savings Plans ohne Flexibilität kaufen

Ein Unternehmen kaufte 3-Jahres Compute Savings Plans für eine Microservices-Architektur. Sechs Monate später wurde die Architektur komplett refactored. Die nicht übertragbaren Reservierungen verloren 60 % ihres Werts.

Lösung: Mit 1-Jahres-Plänen starten. Nur den stabilen Baseline-Load committen. Flexibility behalten für agile Workloads.

Fehler 5: FinOps als einmaliges Projekt statt kontinuierlicher Prozess

Cloud-Kostenoptimierung ist kein Projekt mit Enddatum. Ohne kontinuierliche Governance driftet die Cost Discipline ab. Neue Teams provisionieren Ressourcen ohne Kontrolle. Alte Projekte werden nicht abgeräumt.

Lösung: FinOps als Team-Funktion etablieren, monatliche Cost Reviews, automatisierte Policies für Idle Resources.

Empfehlungen und konkrete nächste Schritte

Verwenden Sie AWS, wenn: Sie ein etabliertes Ökosystem benötigen, komplexe hybride Szenarien mit On-Premise abbilden müssen, oder auf über 200 spezialisierte Services zurückgreifen wollen. AWS hat die reifste Enterprise-Support-Struktur und die umfangreichste Service-Vielfalt.

Verwenden Sie Azure, wenn: Sie tief in Microsoft-Produkte integriert sind (Active Directory, Office 365, SQL Server). Azure bietet die beste Hybrid-Cloud-Experience mit exzellenter Active-Directory-Integration und günstige Speicherpreise.

Verwenden Sie Google Cloud, wenn: Sie Machine-Learning-first denken, containerbasierte Architekturen (GKE) betreiben, oder maximale Compute-Effizienz bei günstigen On-Demand-Preisen suchen. GCP ist die beste Wahl für Data-Analytics-Workloads mit BigQuery.

Unmittelbare Aktionen für die nächsten 30 Tage:

1. Exportieren Sie die letzten 3 Monate Cloud-Rechnungen in CSV
2. Identifizieren Sie die Top 10 largest Ressourcen
3. Prüfen Sie: Sind Reserved/Committed Instances möglich für diese?
4. Checken Sie auf verwaiste Snapshots, alte EBS-Volumes, ungenutzte Load Balancers
5. Etablieren Sie einen wöchentlichen 15-Minuten Cost Review mit Ihrem Team

Die richtige Cloud-Wahl hängt von Ihrem spezifischen Workload-Mix ab. Pauschale Empfehlungen sind gefährlich. Messen Sie, modellieren Sie, und committen Sie nur für stabile Baseline-Workloads.

Cloud-Kostenmanagement ist ein Marathon, kein Sprint. Die Unternehmen, die 2025 erfolgreich sind, haben FinOps als Kernkompetenz internalisiert — nicht als Kostenstelle, sondern als Wettbewerbsvorteil.