Was ist eine Virtual Private Cloud?

Eine Virtual Private Cloud (VPC) ist ein logisch iso­lier­tes Netzwerk innerhalb einer Cloud-Umgebung. Un­ter­neh­men können darin Cloud-Res­sour­cen wie virtuelle Maschinen oder Da­ten­ban­ken betreiben, ohne dass diese au­to­ma­tisch öf­fent­lich er­reich­bar sind. Auch IP-Adres­sie­rung, Subnetze, Routing, Gateways und Si­cher­heits­re­geln können selbst fest­ge­legt werden.

Was ist eine Virtual Private Cloud?

Eine Virtual Private Cloud, kurz VPC, ist ein ab­ge­schirm­tes, vir­tu­el­les Netzwerk in einer Cloud-In­fra­struk­tur. Die In­fra­struk­tur wird meist gemeinsam mit anderen Cloud-Kundinnen und -Kunden genutzt. Die VPC selbst ist jedoch logisch getrennt und stellt einen eigenen Bereich für die Cloud-Res­sour­cen eines Un­ter­neh­mens bereit.

Im Bereich der VPC lässt sich genau festlegen, wie Server, Da­ten­ban­ken, An­wen­dun­gen und weitere Cloud-Dienste mit­ein­an­der kom­mu­ni­zie­ren. Un­ter­neh­men de­fi­nie­ren dafür unter anderem IP-Adress­be­rei­che, Subnetze, Routing-Regeln, Gateways und Zu­griffs­kon­trol­len. So entsteht ein klar struk­tu­rier­ter Netz­werk­be­reich für Web­an­wen­dun­gen, Da­ten­ban­ken, hybride Um­ge­bun­gen oder ska­lier­ba­re Un­ter­neh­mens­an­wen­dun­gen.

Ver­ein­facht gesagt: Eine VPC ist ein eigener, ab­ge­grenz­ter Netz­werk­be­reich in der Cloud, in dem in­di­vi­du­ell fest­ge­legt werden kann, welche Systeme öf­fent­lich er­reich­bar sind, welche intern bleiben und wie der Da­ten­ver­kehr zwischen den einzelnen Kom­po­nen­ten fließt.

Wie funk­tio­niert eine Virtual Private Cloud?

Eine VPC funk­tio­niert ähnlich wie ein klas­si­sches Un­ter­neh­mens­netz­werk, wird jedoch voll­stän­dig virtuell in der Cloud be­reit­ge­stellt. Statt phy­si­scher Router, Switches und Firewalls kommen soft­ware­de­fi­nier­te Netz­werk­kom­po­nen­ten zum Einsatz. Un­ter­neh­men kon­fi­gu­rie­ren diese Kom­po­nen­ten über die Cloud-Plattform des je­wei­li­gen Anbieters.

Zu den wich­tigs­ten Be­stand­tei­len einer VPC gehören:

• IP-Adres­sie­rung: Der Netz­werk­be­reich wird über private IP-Adress­be­rei­che definiert, meist mithilfe von CIDR-Blöcken. Je nach Anbieter und Ar­chi­tek­tur können zu­sätz­lich IPv6-Adress­be­rei­che genutzt werden. Dafür gelten teilweise andere Regeln für Routing, öf­fent­li­che Er­reich­bar­keit und aus­ge­hen­den In­ter­net­zu­griff.
• Subnetze: Die VPC wird in kleinere Netz­werk­seg­men­te un­ter­teilt.
• Routing-Tabellen: Sie bestimmen, wohin Netz­werk­ver­kehr wei­ter­ge­lei­tet wird.
• Gateways: Sie verbinden die VPC mit dem Internet, anderen Netz­wer­ken oder lokalen Re­chen­zen­tren.
• Si­cher­heits­re­geln: Firewalls, Security Groups oder Network ACLs steuern, welcher Traffic erlaubt oder blockiert wird.
• Mo­ni­to­ring und Logs: Pro­to­kol­le helfen dabei, Netz­werk­ver­kehr zu über­wa­chen und Fehl­kon­fi­gu­ra­tio­nen zu erkennen.

IP-Adres­sie­rung als Grundlage

Beim Erstellen einer VPC wird zunächst ein IP-Adress­be­reich fest­ge­legt. Dieser Bereich bestimmt, welche privaten IP-Adressen innerhalb der VPC verwendet werden können. Üblich ist die Angabe in CIDR-Notation, zum Beispiel 10.0.0.0/16.

Die IP-Adres­sie­rung sollte sorg­fäl­tig geplant werden, denn spätere Än­de­run­gen können aufwendig sein. Wichtig ist vor allem, dass sich die IP-Bereiche nicht mit be­stehen­den Un­ter­neh­mens­netz­wer­ken, anderen VPCs oder geplanten VPN-Ver­bin­dun­gen über­schnei­den.

Public und Private Subnets

Eine VPC wird in der Regel in mehrere Subnetze un­ter­teilt. Dadurch lassen sich un­ter­schied­li­che Si­cher­heits­zo­nen aufbauen. Besonders wichtig ist die Trennung zwischen Public Subnets und Private Subnets.

Ein typisches Beispiel ist eine Web­an­wen­dung mit mehreren Ebenen: Der Load Balancer befindet sich in einem Public Subnet. Web- oder Ap­pli­ka­ti­ons­ser­ver laufen in Private Subnets. Die Datenbank wird in einem separaten Private Subnet betrieben und ist nur für aus­ge­wähl­te interne Systeme er­reich­bar.

Routing und Gateways

Routing-Tabellen legen fest, wie Da­ten­ver­kehr innerhalb der VPC und zu externen Netz­wer­ken wei­ter­ge­lei­tet wird. Dabei spielen Gateways eine zentrale Rolle.

Typische Gateway- und Ver­bin­dungs­ar­ten sind:

• Internet-Gateway: wird an die VPC an­ge­bun­den und er­mög­licht In­ter­net­kom­mu­ni­ka­ti­on für Subnetze, deren Routing-Tabelle eine ent­spre­chen­de Route enthält. Für ein­ge­hen­de Er­reich­bar­keit sind zu­sätz­lich öf­fent­li­che IP-Adressen und passende Si­cher­heits­re­geln er­for­der­lich.
• NAT-Gateway: er­mög­licht privaten Res­sour­cen aus­ge­hen­den In­ter­net­zu­griff, ohne sie direkt öf­fent­lich er­reich­bar zu machen
• VPN-Gateway: verbindet die VPC ver­schlüs­selt mit einem lokalen Un­ter­neh­mens­netz­werk
• Private Ver­bin­dung: bindet lokale Re­chen­zen­tren oder Un­ter­neh­mens­stand­or­te über eine de­di­zier­te, nicht öf­fent­li­che Ver­bin­dung an die Cloud an
• VPC-/VNet-Peering oder Transit-Dienste: verbindet mehrere VPCs, virtuelle Netzwerke oder Cloud-Um­ge­bun­gen mit­ein­an­der

Durch diese Kom­po­nen­ten lassen sich einfache Cloud-Netzwerke ebenso umsetzen wie komplexe hybride Ar­chi­tek­tu­ren mit mehreren Stand­or­ten und Cloud-Um­ge­bun­gen.

Welche Vorteile bietet eine VPC?

Eine VPC bietet vor allem mehr Kontrolle über Netz­werk­struk­tur, Zugriff und Si­cher­heit in der Cloud. Sie eignet sich deshalb besonders für pro­duk­ti­ve Workloads, sensible Daten und An­wen­dun­gen mit klaren Si­cher­heits­an­for­de­run­gen.

✓ Mehr Kontrolle über die Cloud-In­fra­struk­tur: In einer VPC bestimmen Un­ter­neh­men selbst, wie ihre Cloud-Res­sour­cen er­reich­bar sind. Sie legen fest, welche Systeme öf­fent­li­che IP-Adressen erhalten, welche nur intern kom­mu­ni­zie­ren und welche Ver­bin­dun­gen zu anderen Netz­wer­ken bestehen.

✓ Höhere Si­cher­heit durch Isolation: Eine VPC trennt die eigene Cloud-Umgebung logisch von anderen Um­ge­bun­gen. Zu­sätz­lich können Un­ter­neh­men einzelne Workloads innerhalb der VPC weiter seg­men­tie­ren, zum Beispiel nach Anwendung, Umgebung oder Schutz­be­darf.

✓ Ska­lier­bar­keit und flexible Er­wei­te­rung: Da eine VPC virtuell be­reit­ge­stellt wird, lässt sie sich flexibel erweitern. Neue Server, Da­ten­ban­ken, Container-Cluster oder Load Balancer können in be­stehen­de Subnetze in­te­griert oder in neuen Subnetzen or­ga­ni­siert werden.

✓ Grundlage für hybride IT: Viele Un­ter­neh­men betreiben nicht alle Systeme aus­schließ­lich in der Cloud. Eine VPC kann per VPN oder privater Ver­bin­dung mit lokalen Re­chen­zen­tren, Un­ter­neh­mens­stand­or­ten oder anderen Cloud-Um­ge­bun­gen verbunden werden.

Wie wird eine VPC ab­ge­si­chert?

Eine VPC ist logisch von anderen Cloud-Um­ge­bun­gen getrennt. Diese Trennung allein reicht jedoch nicht aus, um Cloud-Res­sour­cen zu­ver­läs­sig zu schützen. Sicher wird sie erst durch die richtige Kon­fi­gu­ra­ti­on, zum Beispiel durch private Subnetze, re­strik­ti­ve Firewall-Regeln, ge­schütz­te Ad­mi­nis­tra­ti­ons­zu­gän­ge und re­gel­mä­ßi­ge Prüfungen der Netz­werk­re­geln.

Zwei zentrale Si­cher­heits­me­cha­nis­men sind Network ACLs und Security Groups. Beide steuern den Netz­werk­ver­kehr, greifen aber an un­ter­schied­li­chen Stellen der VPC.

Network ACLs wirken auf Sub­netz­ebe­ne. Sie kon­trol­lie­ren den Da­ten­ver­kehr für ein ganzes Subnetz. Da Network ACLs stateless arbeiten, müssen ein­ge­hen­de und aus­ge­hen­de Regeln jeweils separat definiert werden. Eine erlaubte Anfrage bedeutet also nicht au­to­ma­tisch, dass auch die Antwort erlaubt ist.

Security Groups greifen dagegen auf Ebene einzelner Res­sour­cen, etwa bei vir­tu­el­len Maschinen oder Da­ten­ban­ken. Mit ihnen lässt sich zum Beispiel festlegen, dass nur ein be­stimm­ter Webserver auf eine Datenbank zugreifen darf. Security Groups arbeiten stateful. Das bedeutet: Wenn eine Ver­bin­dung erlaubt ist, wird der zu­ge­hö­ri­ge Antwort-Traffic au­to­ma­tisch be­rück­sich­tigt.

In der Praxis werden beide Me­cha­nis­men häufig kom­bi­niert: Security Groups schützen einzelne Res­sour­cen, Network ACLs ergänzen diese Kontrolle auf Sub­netz­ebe­ne. Beide sollten nach dem Least-Privilege-Prinzip ein­ge­rich­tet werden. Es wird also nur der Traffic erlaubt, der tat­säch­lich benötigt wird.

Worin un­ter­schei­den sich VPC, Public Cloud, Private Cloud und VPN?

VPC, VPN, Public Cloud und Private Cloud – die Begriffe werden häufig im selben Kontext verwendet, be­schrei­ben aber ganz un­ter­schied­li­che Konzepte.

Eine Public Cloud ist die über­ge­ord­ne­te Cloud-In­fra­struk­tur eines Anbieters. Sie stellt Re­chen­leis­tung, Speicher, Netzwerke und weitere Dienste für viele Kundinnen und Kunden bereit. Eine VPC ist dagegen ein iso­lier­ter Netz­werk­be­reich innerhalb dieser In­fra­struk­tur.

Eine Private Cloud wird exklusiv für eine Or­ga­ni­sa­ti­on be­reit­ge­stellt. Sie läuft entweder im eigenen Re­chen­zen­trum oder bei einem Anbieter. Eine VPC nutzt meist geteilte Public-Cloud-In­fra­struk­tur, bietet aber eine logisch getrennte Netz­werk­um­ge­bung. Eine VPC verbindet damit typische Public-Cloud-Vorteile mit stärkerer Netz­werk­kon­trol­le und logischer Isolation.

Ein VPN erfüllt hingegen eine andere Aufgabe. Es stellt eine ver­schlüs­sel­te Ver­bin­dung zu einem Netzwerk her und kann den sicheren Zugriff auf eine VPC er­mög­li­chen bzw. eine VPC mit einem lokalen Un­ter­neh­mens­netz­werk verbinden.

Für wen eignet sich eine Virtual Private Cloud?

Eine VPC eignet sich für Un­ter­neh­men, die Cloud-Res­sour­cen nicht un­struk­tu­riert betreiben möchten. Besonders relevant ist sie, wenn mehrere Systeme mit­ein­an­der kom­mu­ni­zie­ren, sensible Daten ver­ar­bei­tet werden oder lokale und cloud­ba­sier­te Systeme verbunden werden sollen.

Typische Ziel­grup­pen sind:

• KMU, die eine sichere und ska­lier­ba­re Cloud-Basis benötigen
• IT-Ab­tei­lun­gen, die Cloud-Mi­gra­tio­nen oder hybride Ar­chi­tek­tu­ren planen
• SaaS-Anbieter, die An­wen­dun­gen netz­werk­sei­tig getrennt und sicher betreiben möchten
• Ent­wick­lungs­teams, die Ent­wick­lungs-, Test- und Pro­duk­ti­ons­um­ge­bun­gen trennen wollen
• Un­ter­neh­men mit Com­pli­ance-An­for­de­run­gen, etwa aus Fi­nanz­we­sen, Ge­sund­heits­we­sen, E-Commerce oder B2B
• Managed-Service-Provider, die getrennte Kun­den­um­ge­bun­gen aufbauen müssen

Typische An­wen­dungs­fäl­le für eine VPC

Eine VPC kommt vor allem dann zum Einsatz, wenn Cloud-Res­sour­cen struk­tu­riert, sicher und kon­trol­liert be­reit­ge­stellt werden sollen. Sie hilft dabei, An­wen­dun­gen sicher zu betreiben, be­stehen­de Systeme an­zu­bin­den und ver­schie­de­ne Um­ge­bun­gen sauber von­ein­an­der zu trennen.

Welche Her­aus­for­de­run­gen gibt es bei einer VPC?

Eine VPC schafft eine sichere und flexible Grundlage, muss aber sorg­fäl­tig geplant und betrieben werden. Fehler in der Kon­fi­gu­ra­ti­on können Si­cher­heits­ri­si­ken oder Be­triebs­pro­ble­me ver­ur­sa­chen.

Typische Her­aus­for­de­run­gen sind:

• zu großzügig geöffnete Ports
• öf­fent­li­che IP-Adressen für sensible Res­sour­cen
• falsch kon­fi­gu­rier­te Routing-Tabellen
• über­schnei­den­de IP-Adress­be­rei­che
• fehlende Trennung zwischen Public und Private Subnets
• unklare Ver­ant­wort­lich­kei­ten für Firewall-Regeln
• steigende Kosten durch NAT-Gateways, Traffic, Logging oder öf­fent­li­che IP-Adressen

Eine gute Do­ku­men­ta­ti­on ist deshalb wichtig. Dazu gehören ein IP-Plan, ein Netz­werk­dia­gramm, klare Si­cher­heits­re­geln und re­gel­mä­ßi­ge Prüfungen der Kon­fi­gu­ra­ti­on.

In 5 Schritten zur eigenen VPC

Eine VPC sollte vor der Ein­rich­tung sorg­fäl­tig geplant werden. Ent­schei­dend sind vor allem die Netz­werk­struk­tur, Zu­griffs­kon­trol­len, Ver­bin­dun­gen zu anderen Systemen und der spätere Betrieb. Die folgende Check­lis­te hilft dabei, die wich­tigs­ten Ent­schei­dun­gen vor dem Aufbau einer VPC struk­tu­riert zu treffen.

Schritt 1: An­for­de­run­gen de­fi­nie­ren

Zunächst sollten Un­ter­neh­men klären, welche An­wen­dun­gen und Daten in der VPC betrieben werden. Wichtig sind auch An­for­de­run­gen an Da­ten­schutz, Ver­füg­bar­keit, Zugriff, Ska­lie­rung und Com­pli­ance.

Leit­fra­gen:

• Welche Systeme müssen öf­fent­lich er­reich­bar sein?
• Welche Res­sour­cen dürfen nur intern kom­mu­ni­zie­ren?
• Müssen lokale Netzwerke an­ge­bun­den werden?
• Welche Bereiche sollen von­ein­an­der getrennt werden?

Schritt 2: Netz­werk­struk­tur planen

An­schlie­ßend werden IP-Adres­sie­rung und Subnetze fest­ge­legt. Der CIDR-Bereich sollte genug Spielraum für spätere Er­wei­te­run­gen bieten und sich nicht mit be­stehen­den Netz­wer­ken über­schnei­den. Eine einfache Grund­struk­tur kann so aussehen:

Schritt 3: Routing und Ver­bin­dun­gen ein­rich­ten

Im nächsten Schritt werden Routing-Tabellen und Gateways kon­fi­gu­riert. Public Subnets benötigen bei Bedarf eine Route zum Internet-Gateway. Private Subnets sollten keinen direkten ein­ge­hen­den In­ter­net­zu­griff erlauben. Für aus­ge­hen­de Ver­bin­dun­gen kann ein NAT-Gateway genutzt werden. Für hybride Szenarien kommen VPN-Gateways oder private Ver­bin­dun­gen zum lokalen Netzwerk infrage.

Schritt 4: Si­cher­heits­re­geln festlegen

Si­cher­heits­re­geln sollten so re­strik­tiv wie möglich sein. Sensible Res­sour­cen wie Da­ten­ban­ken erhalten keine öf­fent­li­che IP-Adresse und sind nur für bestimmte interne Systeme er­reich­bar.

Emp­feh­lens­wert sind:

• Zugriff nach dem Least-Privilege-Prinzip
• klare Trennung zwischen Public und Private Subnets
• Security Groups für einzelne Res­sour­cen
• Network ACLs oder ver­gleich­ba­re subnetz- bzw. netz­werk­ba­sier­te Firewall-Regeln als zu­sätz­li­che Schutz­schicht
• ab­ge­si­cher­te Ad­mi­nis­tra­ti­ons­zu­gän­ge über VPN, Bastion Host oder Zero-Trust-Lösungen

Schritt 5: Mo­ni­to­ring und Betrieb or­ga­ni­sie­ren

Nach der Ein­rich­tung sollte die VPC dauerhaft überwacht werden. Flow Logs, Firewall Logs und Mo­ni­to­ring-Dienste helfen dabei, un­ge­wöhn­li­chen Traffic, Fehl­kon­fi­gu­ra­tio­nen oder un­er­war­te­te Ver­bin­dun­gen zu erkennen.

Zu­sätz­lich sollten Un­ter­neh­men Än­de­run­gen do­ku­men­tie­ren und möglichst au­to­ma­ti­siert verwalten, zum Beispiel mit In­fra­struc­tu­re as Code. So bleiben Kon­fi­gu­ra­tio­nen nach­voll­zieh­bar und kon­sis­tent.