Virtual Private Cloud: Sicheres Netzwerk in der Cloud

Jede Anfrage, die du in einer App absendest, jedes Backup, das nachts läuft, jeder API-Aufruf zwischen zwei Microservices: Dahinter steckt ein Netzwerk, das Daten zuverlässig und sicher von A nach B bringt. In der Cloud ist dieses Netzwerk zwar unsichtbar, es entscheidet jedoch darüber, ob deine Systeme reibungslos zusammenarbeiten oder zu einer Sicherheitslücke werden. Wer eine Virtual Private Cloud aufbaut, muss verstehen, wie VPCs, Firewalls und Gateways zusammenspielen.

In diesem Artikel erklären wir die wichtigsten Netzwerk-Grundlagen in der Cloud auf verständliche Weise und zeigen, wie Unternehmen ihre Cloud-Infrastruktur sicher und leistungsfähig gestalten können.

Was ist eine Virtual Private Cloud (VPC)?

Eine Virtual Private Cloud (VPC) ist ein logisch abgeschottetes Netzwerksegment innerhalb einer größeren Cloud-Infrastruktur. Stell dir das wie ein Grundstück mit eigenem Zaun vor: Die Nachbarn nutzen dieselbe Straße, also die physische Hardware, aber ohne deine Erlaubnis kann niemand über deinen Zaun schauen oder gar hineinlaufen. Technisch gesehen erhältst du einen eigenen IP-Adressraum, eigene Routing-Regeln und die volle Kontrolle darüber, welche Systeme miteinander kommunizieren dürfen.

Bei NWS realisieren wir das auf Basis von OpenStack. Deine Cloud-Infrastruktur – von virtuellen Maschinen bis zu Kubernetes-Clustern – läuft in einem Netzwerk, das ausschließlich dir gehört. Das ist besonders für Unternehmen wichtig, die sensible Daten verarbeiten oder strenge Compliance-Vorgaben wie ISO 27001 oder die DSGVO einhalten müssen.

Der Unterschied zu einem klassischen, physischen Rechenzentrum liegt vor allem in der Flexibilität. Ein neues Subnetz, eine zusätzliche Route oder eine weitere Security Group richtest du in wenigen Minuten über die API oder das Interface ein – ganz ohne Techniker und Kabelverlegung. Gleichzeitig bleibt die Isolation genauso wirksam wie in einem physisch getrennten Netzwerk. Für dich bedeutet das: Du erhältst die Sicherheit einer dedizierten Infrastruktur, ohne auf die Geschwindigkeit der Cloud zu verzichten.

Innerhalb einer VPC erstellst du folgende Ressourcen selbst:

• IP-Adressbereiche
• Subnetze
• Routing
• Firewalls
• Internetzugänge
• VPN-Verbindungen
• Private Verbindungen

Dadurch entsteht eine abgeschottete Umgebung, die nur definierte Kommunikationswege zulässt.

Vorteile einer VPC

• vollständige Isolation von anderen Cloud-Kunden
• individuelle Netzwerkarchitektur
• bessere Sicherheitskontrolle
• flexible Skalierung
• einfache Integration mit On-Premises-Systemen

Subnetze und IP-Bereiche als Bauplan

Innerhalb deiner VPC teilst du den Adressraum in Subnetze auf, z.B. eines für die Webserver, eines für die Datenbanken und eines für interne Tools. Diese Trennung dient nicht nur der Ordnung, sondern begrenzt auch den Schaden, falls doch einmal etwas schiefgeht.

Public Subnet

Ein Public Subnet besitzt eine Verbindung zum Internet.

Typische Systeme:

• Webserver
• Reverse Proxys
• Load Balancer
• Bastion Hosts

Diese Systeme sind von außen erreichbar.

Private Subnet

Private Subnets besitzen keinen direkten Internetzugang.

Hier laufen beispielsweise:

• Datenbanken
• Kubernetes Worker Nodes
• interne APIs
• Storage-Systeme
• Backend-Services

Dadurch wird die Angriffsfläche erheblich reduziert.

Isolation zwischen Projekten und Kunden

Insbesondere bei mehreren Umgebungen, wie beispielsweise Entwicklung, Staging und Produktion, lohnt sich eine strikte Trennung auf Netzwerkebene. So verhinderst du, dass ein Testserver versehentlich mit produktiven Systemen kommuniziert. Bei einem Multi-Tenant-Setup, bei dem du mehrere Kunden auf derselben Infrastruktur bedienst, ist diese Isolation sogar Pflicht. Netzwerksegmentierung erhöht die Sicherheit. Ein zentrales Sicherheitsprinzip lautet: Nicht alle Systeme dürfen miteinander kommunizieren.

Beispiel:

• Webserver
• APIs
• Datenbanken
• Entwicklungsumgebung
• Produktionsumgebung

Jeder Bereich erhält eigene Zugriffsregeln.

Vorteile:

• kleinere Angriffsfläche
• bessere Kontrolle
• höhere Compliance
• einfachere Fehlersuche

Firewalls & Security Groups: die Türwächter deiner Cloud

Eine VPC legt fest, welche Instanzen sich grundsätzlich im selben Netzwerk befinden. Firewalls und Security Groups entscheiden hingegen, welche Geräte innerhalb dieses Netzwerks und über verschiedene Subnetze hinweg tatsächlich miteinander kommunizieren dürfen. Sie prüfen jedes Datenpaket anhand von Absender, Ziel und Port, bevor sie es durchlassen oder blockieren.

Firewalls: Die wichtigste Sicherheitsinstanz

Firewalls kontrollieren den Datenverkehr.

Sie entscheiden:

• Wer darf kommunizieren?
• Welche Ports sind geöffnet?
• Welche Protokolle sind erlaubt?
• Welche IP-Adressen besitzen Zugriff?

Moderne Cloud-Plattformen verwenden mehrere Firewall-Ebenen.

Network Firewalls

Sie arbeiten auf Netzwerkebene.

Beispiele:

• TCP
• UDP
• ICMP
• IP-Adressen
• Ports

Sie schützen komplette Netzwerke.

Host Firewalls

Zusätzlich können Betriebssysteme eigene Firewalls besitzen.

Beispiele:

• iptables
• nftables
• Windows Firewall

Diese schützen einzelne Server.

Security Groups und Access Control Lists (ACLs)

Viele Cloud-Anbieter setzen auf zwei zusätzliche Sicherheitsmechanismen.

Security Groups

Security Groups arbeiten zustandsorientiert.

Sie definieren:

• erlaubte eingehende Verbindungen
• erlaubte ausgehende Verbindungen

Sie wirken direkt auf Instanzen oder Container.

Network ACLs

ACLs arbeiten auf Subnetz-Ebene.

Sie kontrollieren:

• gesamten Netzwerkverkehr
• eingehende Pakete
• ausgehende Pakete

Sie ergänzen Security Groups.

Security Groups vs. klassische Firewall

Eine klassische Firewall sitzt in der Regel zentral am Netzwerkrand und filtert den gesamten ein- und ausgehenden Datenverkehr. Security Groups arbeiten feingranularer: Du hängst sie direkt an einzelne virtuelle Maschinen oder Dienste. So erhält dein Webserver beispielsweise eine Regel, die nur Port 443 von außen erlaubt, während dein Datenbankserver eine Regel erhält, die Verbindungen nur von den Webservern akzeptiert und sonst von niemandem. So entstehen mehrere Sicherheitsschichten übereinander, anstatt sich auf eine einzige Mauer zu verlassen.

Least-Privilege-Prinzip in der Praxis

Die wichtigste Regel beim Konfigurieren von Security Groups: Erlaube nur, was wirklich gebraucht wird. Offene Ports „für alle Fälle“ sind der häufigste Grund für spätere Sicherheitsvorfälle. Wer bei NWS eine Cloud-Infrastruktur betreibt, kann Security Groups direkt über die API oder das Interface pflegen und regelmäßig überprüfen, welche Regeln tatsächlich noch aktiv gebraucht werden.

Routing: Wie Daten ihren Weg finden

Damit Datenpakete zwischen verschiedenen Netzwerken gelangen, werden Routing-Tabellen verwendet.

Diese definieren:

• welches Ziel erreichbar ist
• über welchen Weg Pakete übertragen werden
• welche Gateways verwendet werden

Ein typischer Ablauf:

Benutzer → Load Balancer → Webserver → API → Datenbank

Jeder Schritt erfolgt über definierte Routing-Regeln.

DNS: Die Navigation im Netzwerk

Ohne DNS müssten Benutzer IP-Adressen kennen.

DNS übersetzt:

www.meinefirma.de

in

203.0.113.42

Cloud-DNS-Dienste bieten zusätzlich:

• Hochverfügbarkeit
• Geo-Routing
• Failover
• Lastverteilung

Gateways: Die Schnittstellen nach außen

Deine VPC ist zwar geschützt, aber wenn sie komplett abgeschottet ist, nützt sie niemandem etwas. Irgendwo muss der Datenverkehr hinein- und herausgelangen. Genau dafür gibt es Gateways: klar definierte und kontrollierte Übergänge zwischen deinem privaten Netzwerk und der Außenwelt.

Private Gateways und Direct Connections

Bei geschäftskritischen Anwendungen reicht eine Internetverbindung oft nicht aus.

Deshalb bieten Cloud-Anbieter private Netzwerkverbindungen.

Vorteile:

• geringere Latenz
• höhere Bandbreite
• stabile Verbindung
• keine öffentliche Internetroute

Besonders Banken, Industrie oder Gesundheitswesen setzen häufig auf diese Lösungen.

Internet- und NAT-Gateway

Ein Internet-Gateway ermöglicht es deinen Systemen, mit dem Internet zu kommunizieren, beispielsweise um Updates zu laden oder externe APIs anzusprechen. Ein NAT-Gateway übersetzt dabei private IP-Adressen in eine öffentliche Adresse, sodass interne Server ausgehend kommunizieren können, ohne selbst von außen erreichbar zu sein. Während deine Datenbank von außen nicht sichtbar sein muss, ist dies bei deinem Webserver, der Daten von einer externen API abruft, anders.

Internet Gateway

Ein Internet Gateway verbindet eine VPC mit dem öffentlichen Internet.

Ohne Internet Gateway:

• keine öffentlichen Webseiten
• keine APIs
• keine externen Benutzerzugriffe

Nur Ressourcen mit entsprechender Routing-Konfiguration können darüber kommunizieren.

NAT Gateway

Viele Server benötigen Internetzugriff, sollen aber selbst nicht erreichbar sein.

Beispiele:

• Betriebssystemupdates
• Container Images herunterladen
• Softwarepakete installieren
• Cloud APIs nutzen

Hierfür wird ein NAT Gateway eingesetzt.

Es ermöglicht:

• ausgehende Verbindungen
• keine eingehenden Verbindungen

Dadurch bleiben interne Systeme geschützt.

VPN as a Service für sichere Standortanbindung

Wenn du dein Büronetzwerk fest mit deiner Cloud-Infrastruktur verbinden möchtest, ist ein VPN-Gateway die richtige Wahl. Der Datenverkehr läuft verschlüsselt durch einen Tunnel, sodass es wirkt, als wären Büro und Cloud im selben Raum. Für Unternehmen mit mehreren Standorten oder Remote-Teams, die auf interne Systeme zugreifen müssen, ist dies oft die einfachste Lösung, um ohne öffentliche Angriffsfläche produktiv zu bleiben.

Dabei kommunizieren:

• Rechenzentrum
• Cloud
• Niederlassungen

über VPN-Verbindungen.

Typische Einsatzgebiete:

• Standortvernetzung
• Homeoffice
• hybride Cloud
• Disaster Recovery

Load Balancer als Verkehrslenker

Ein Load Balancer gehört ebenso zur Netzwerkarchitektur. Er verteilt eingehende Anfragen auf mehrere Server, sorgt für eine gleichmäßige Auslastung und übernimmt häufig direkt die Terminierung von TLS-Verbindungen. So bleibt dein System auch bei Lastspitzen erreichbar und ausfallsicher.

Vorteile:

• höhere Verfügbarkeit
• bessere Performance
• automatische Lastverteilung
• Ausfallsicherheit

Moderne Cloud-Plattformen unterstützen:

• Layer-4-Load-Balancing
• Layer-7-Load-Balancing
• SSL-Offloading
• Health Checks

Zero Trust Networking

Moderne Cloud-Sicherheit basiert zunehmend auf dem Zero-Trust-Prinzip.

Die Grundidee:

Niemandem wird automatisch vertraut, auch nicht innerhalb des eigenen Netzwerks. Jede Verbindung wird geprüft.

Typische Maßnahmen:

• Identitätsprüfung
• Multi-Faktor-Authentifizierung
• minimale Berechtigungen (Least Privilege)
• verschlüsselte Kommunikation
• kontinuierliche Überwachung

Zero Trust gewinnt besonders in Multi-Cloud- und Hybrid-Cloud-Umgebungen an Bedeutung.

Verschlüsselung während der Datenübertragung

Daten sollten nicht nur gespeichert, sondern auch während der Übertragung geschützt werden.

Gängige Verfahren:

• TLS
• HTTPS
• SSH
• IPSec
• WireGuard

Dadurch bleiben Daten auch bei einer abgefangenen Verbindung geschützt.

Monitoring des Netzwerkverkehrs

Ein sicheres Netzwerk benötigt Transparenz.

Moderne Cloud-Plattformen überwachen:

• Netzwerkverkehr
• Bandbreite
• Fehlerraten
• Latenzen
• ungewöhnliche Verbindungen
• Angriffsversuche

Tools wie Prometheus, Grafana oder OpenTelemetry unterstützen Unternehmen dabei, Probleme frühzeitig zu erkennen und ihre Infrastruktur kontinuierlich zu optimieren.

Best Practices für sichere Cloud-Netzwerke

Unternehmen sollten folgende Empfehlungen berücksichtigen:

• Ressourcen konsequent in Public- und Private-Subnets trennen.
• Firewalls nach dem Prinzip „Default Deny“ konfigurieren.
• Netzwerksegmentierung konsequent umsetzen.
• Datenübertragungen ausnahmslos verschlüsseln.
• VPN oder private Verbindungen für hybride Umgebungen einsetzen.
• Zugriffe regelmäßig überprüfen und unnötige Freigaben entfernen.
• Netzwerk-Monitoring dauerhaft etablieren.
• Zero-Trust-Prinzipien in die Netzwerkarchitektur integrieren.
• Sicherheitsrichtlinien automatisiert per Infrastructure as Code (IaC) verwalten.
• Firewall- und Routing-Regeln regelmäßig auditieren.

Typische Stolperfallen bei Cloud-Netzwerken

In der Praxis beobachten wir bei NWS immer wieder die gleichen Muster, wenn ein Cloud-Netzwerk später zum Problem wird. Diese entstehen meist nicht aus Nachlässigkeit, sondern aus Zeitdruck: Eine Regel wird schnell geöffnet, um einen Deploy-Fehler zu beheben, und bleibt dann einfach bestehen.

Ein klassisches Beispiel ist die Datenbank, die „nur kurz” von überall erreichbar gemacht wird, um ein Migrationsskript auszuführen. Wochen später weiß niemand mehr, warum diese Regel existiert, und sie wird zur offenen Tür für jeden, der danach sucht. Ähnlich häufig ist eine VPC, die zwar existiert, aber nicht weiter in Subnetze unterteilt wurde. Dann sitzen Frontend, Backend und Datenbank im selben flachen Netzwerk und eine einzelne kompromittierte Anwendung kann sich frei bewegen.

Auch beim Thema Gateways lohnt sich ein zweiter Blick. Wird jeder Dienst gebraucht, der aktuell öffentlich erreichbar ist, oder reicht ein interner Zugriff über „VPN as a Service” völlig aus? Wer sein Netzwerk regelmäßig überprüft und nicht mehr benötigte Regeln konsequent entfernt, reduziert die Angriffsfläche deutlich, ohne dabei an Funktionalität zu verlieren. Genau das ist einer der Gründe, warum viele unserer Kunden diesen Teil lieber an einen Managed Service wie MyEngineer® übergeben. So behält jemand den Überblick, auch wenn im Alltag andere Themen Vorrang haben.

Häufige Fehler bei Cloud-Netzwerken zusammengefasst

Immer wieder treten ähnliche Konfigurationsfehler auf:

• Datenbanken sind öffentlich erreichbar.
• Sicherheitsgruppen erlauben unnötig viele Ports.
• Alle Systeme befinden sich im gleichen Subnetz.
• Fehlende Netzwerksegmentierung.
• Keine Überwachung des Netzwerkverkehrs.
• Unverschlüsselte interne Kommunikation.
• Zu weit gefasste Firewall-Regeln.
• Nicht entfernte Testsysteme mit offenen Zugängen.

Diese Fehler erhöhen das Risiko von Sicherheitsvorfällen erheblich.

Zusammenspiel in der Praxis: Ein Beispiel

Stell dir ein SaaS-Unternehmen vor, das seine Anwendung in drei Umgebungen betreibt. Entwicklung, Staging und Produktion. Jede Umgebung erhält eine eigene VPC mit eigenen Subnetzen für Frontend, Backend und Datenbank. Security Groups erlauben nur die für den jeweiligen Dienst nötige Kommunikation. Über das Internet-Gateway wird eingehender Verkehr nur über den Load Balancer der Produktionsumgebung zugelassen, während alle anderen Umgebungen von außen unsichtbar bleiben. Die Entwickler greifen über ein VPN-as-a-Service sicher auf interne Tools zu, ohne dass diese öffentlich erreichbar sein müssen.

Das Ergebnis: Ein Fehler in der Staging-Umgebung kann die Produktion nicht gefährden. Trotzdem bleibt das System für Kunden jederzeit schnell erreichbar. Genau dieses Zusammenspiel aus VPC, Security Groups und Gateways ist der entscheidende Faktor zwischen einer Cloud-Infrastruktur, die „irgendwie funktioniert”, und einer, die auch im Falle eines Sicherheitsvorfalls stabil bleibt.

Fazit

Eine Virtual Private Cloud, Firewalls und Gateways sind kein jeweils getrenntes Werkzeug, sondern ein System, das zusammenwirkt. Die VPC schafft den geschützten Rahmen, Security Groups regeln die Kommunikation im Detail und Gateways steuern, was nach außen geht und was hereinkommt, kontrolliert. Wer diese drei Ebenen von Anfang an bewusst plant, spart sich im Ernstfall viel Ärger und schützt gleichzeitig die Daten seiner Kunden. Bei NWS erhältst du all dies direkt aus einer Hand auf einer deutschen Cloud-Infrastruktur, die auf modernen Open Source-Technologien basiert.

Wie ist dein Cloud-Netzwerk aktuell aufgebaut? Schau dir gern unsere Cloud-Services an oder sprich mit unserem Team über deine individuelle Netzwerkarchitektur.