Was ist Infrastructure as a Service (IaaS)?

IaaS ist ein Cloud-Modell, das grundlegende Rechenressourcen – virtuelle Maschinen, Speicher, Netzwerk – bei Bedarf vermietet und nach Verbrauch abrechnet. Die NIST-Definition zieht die Grenze präzise: Der Anbieter kontrolliert die physische Infrastruktur; Sie kontrollieren Betriebssysteme, Speicher und die deployten Anwendungen. IaaS ist die unterste Stufe der Cloud-Leiter – diejenige, die den Kauf von Servern durch deren Miete ersetzt.

Das Wichtigste in Kürze

So sieht die Arbeit mit IaaS aus

Das typische Erlebnis ist eine Maschine in Minuten – gefolgt von allem, was eine Maschine schon immer gebraucht hat:

# Minute eins: die Maschine mieten
$ cloud compute create --size medium --image ubuntu-24.04
   ✓ vm-7f3a running — 203.0.113.40

# Ab Minute zwei: alles bleibt Ihre Aufgabe
$ ssh [email protected]
$ apt update && apt upgrade          # Patches: Ihre Sache
$ apt install nginx postgresql       # Stack: Ihre Sache
$ ufw allow 443 && configure-tls…    # Sicherheit: Ihre Sache
$ crontab -e                         # Backups, Rotation, Monitoring: Ihre Sache

Dieser Tausch – Hardware in Minuten, Betrieb für immer – ist das gesamte Modell. Zum Vergleich hier dasselbe Ziel “ein laufendes Backend” am oberen Ende der Leiter, wo die Infrastruktur nie zum Vorschein kommt:

// JavaScript / Node.js — Back4app JS SDK
const note = new Parse.Object('Note');
note.set('text', 'Shipped without touching a VM');
await note.save(); // no instance sized, no OS patched, no firewall rules

// Flutter / Dart — Back4app Flutter SDK
final note = ParseObject('Note')
  ..set('text', 'Shipped without touching a VM');
await note.save(); // no instance sized, no OS patched

// iOS / Swift — Back4app Swift SDK
var note = Note()
note.text = "Shipped without touching a VM"
note.save { result in
  if case .success = result { print("saved — zero infrastructure managed") }
}

// Android / Kotlin — Back4app Android SDK
val note = ParseObject("Note").apply {
  put("text", "Shipped without touching a VM")
}
note.saveInBackground { e ->
  if (e == null) Log.d("Note", "saved — zero infrastructure managed")
}

Wer verwaltet was

Diese Aufteilung ist zugleich das Sicherheitsmodell: Der Anbieter sichert die Cloud ab, Sie sichern alles in ihr ab. Fehlkonfigurationen auf Kundenseite – offene Storage-Buckets, zu großzügige Firewall-Regeln, ungepatchte Systeme – sind die häufigste Ursache von Cloud-Sicherheitsvorfällen. Deshalb verdient der Kasten “Sie betreiben” mehr Aufmerksamkeit, als er üblicherweise bekommt.

IaaS vs. PaaS vs. BaaS vs. On-Premises

Eine Klarstellung, die in jeder “IaaS vs.”-Diskussion wiederkehrt: Serverless-Modelle sind keine vierte Spalte derselben Art – sie abstrahieren die Recheneinheit (pro Aufruf) statt der Verwaltungsebene. Deshalb kann eine Serverless-Plattform selbst auf IaaS laufen.

Typische Anwendungsfälle

• Lift-and-Shift-Migrationen. Bestehende Serveranwendungen ziehen weitgehend unverändert auf gemietete VMs um – derselbe Stack, aber keine Hardware-Erneuerungszyklen mehr.
• Eigene und historisch gewachsene Stacks. Ungewöhnliche Runtimes, lizenzierte Software oder Tuning auf Betriebssystemebene, das verwaltete Plattformen nicht zulassen.
• Regulatorisch geforderte Kontrolle. Vorgaben, die verlangen, genau zu wissen und zu konfigurieren, was unterhalb der Anwendung läuft.
• Hochleistungs- und Spezial-Workloads. GPU-Flotten, Datenverarbeitung im großen Maßstab und alles, dessen Anforderungen von der Hardware bestimmt werden.
• Disaster Recovery und Lastspitzen. Standby-Umgebungen und Reserven für Traffic-Spitzen, die als ungenutzte eigene Hardware ruinös teuer wären.

Sollten Sie auf IaaS aufbauen? Eine Entscheidungsmatrix

Das Muster, das Sie verinnerlichen sollten: Für das Umziehen bestehender Systeme ist IaaS selten falsch, für den Neustart von Standardsystemen selten richtig – ein neues App-Backend, von Hand auf VMs zusammengesetzt, bedeutet Wochen an Arbeit, die höhere Stufen noch vor der Mittagspause liefern.

Grenzen und Trade-offs

• Der Betrieb bleibt bei Ihnen. Patchen, Härten, Skalieren, Backups, Monitoring – das Betriebshandbuch bleibt vollständig bestehen; nur die Hardware darunter hat sich geändert.
• Kostenkontrolle wird zur Daueraufgabe. Ungenutzte Instanzen, überdimensionierte VMs und vergessener Speicher werden rund um die Uhr abgerechnet; Kostenmanagement wird zu einer laufenden Disziplin, die Ihr Team beherrschen muss.
• Egress ist die Ausfahrtsmaut. Daten fließen kostenlos hinein und nur gegen Gebühr wieder hinaus – ein Mechanismus, der sich mit wachsendem Datenbestand unbemerkt zu einem Vendor-Lock-in aufsummiert.
• Sicherheits-Fehlkonfiguration ist die häufigste Fehlerursache. Die Hälfte des Anbieters in der geteilten Verantwortung ist ausgezeichnet; Sicherheitsvorfälle passieren ganz überwiegend in der Hälfte des Kunden.
• Die Know-how-Steuer. Infrastruktur gut zu betreiben erfordert Menschen, die Infrastruktur gut betreiben können – eine Einstellungsanforderung, die auf keiner Preisseite mit nutzungsbasierter Abrechnung steht.

IaaS mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Im Verhältnis zu IaaS steht Back4app am anderen Ende des Tauschs: kein Zugriff auf das Betriebssystem, keine Kontrolle über die Infrastruktur – und kein Betriebshandbuch, weil der gesamte Kasten “Sie betreiben” aus dem Diagramm oben Aufgabe der Plattform ist. Teams, die für einen speziellen Workload rohe Infrastruktur brauchen, können diesen neben einem BaaS-Backend betreiben; Teams, die Standard-App-Backends bauen, können die unterste Stufe ganz überspringen. Und weil der Stack Open Source ist, bleibt der spätere Abstieg auf der Leiter – die Plattform auf IaaS unter Ihrer Kontrolle selbst zu hosten – eine echte Option und kein Neuschreiben.