Grundlagen der Cloud-Vernetzung

Eine Cloud-Anwendung braucht neben Computern auch ein Netzwerk. Ein virtuelles Netzwerk ist ein per Software definiertes privates Netzwerk. Du wählst seine Adressen und Verbindungen, ohne Switches oder Kabel zu installieren. Getrennte Netzwerke können den Produktionsbetrieb von Tests trennen.

Lies die Adressen

AWS nennt sein Netzwerk Amazon VPC; Microsoft verwendet Azure Virtual Network oder VNet; Google Cloud verwendet VPC-Netzwerk. Eine AWS-VPC oder ein Azure-VNet hat einen übergeordneten Adressbereich. Seine Subnetze beziehen daraus kleinere Bereiche. Eine Google-Cloud-VPC hat keinen übergeordneten Bereich: Jedes Subnetz erhält einen eigenen.

Die Schreibweise 10.0.0.0/16 ist CIDR-Notation. Die Zahl nach dem Schrägstrich gibt die Anzahl der festgelegten führenden Adressbits an. Eine kleinere Zahl bedeutet einen größeren Bereich. Dieses /16 umfasst 10.0.0.0 bis 10.0.255.255: 65.536 Adressen. Die privaten Blöcke sind 10.0.0.0/8, 172.16.0.0/12 und 192.168.0.0/16. Das öffentliche Internet routet diese privaten Adressen nicht.

Ein Subnetz stellt einem Teil eines Netzwerks Adressen bereit. Beispielsweise umfasst 10.0.3.0/24 die Adressen 10.0.3.0 bis 10.0.3.255. Eine Datenbank darin könnte 10.0.3.20 erhalten. Getrennte Web-, Anwendungs- und Datenbanksubnetze ermöglichen Teams, unterschiedliche Routen und Sicherheitsregeln anzuwenden. Subnetzbereiche in einem Netzwerk dürfen sich nicht überschneiden. Anbieter reservieren Adressen für Netzwerkdienste: AWS und Azure reservieren fünf pro Subnetz; Google Cloud reserviert vier in einem primären Subnetzbereich. Ein Subnetz mit 256 Adressen lässt daher bei AWS oder Azure 251 Adressen übrig.

Platziere Ressourcen über Zonen hinweg

Betrachte einen AWS-Shop, der 10.0.0.0/16 nutzt. In Zone A platziert er Webserver in 10.0.1.0/24, Anwendungsserver in 10.0.2.0/24 und seine Datenbank in 10.0.3.0/24. Um bei einem Zonenausfall weiterarbeiten zu können, wiederholt er die Ebenen in Zone B mit 10.0.11.0/24, 10.0.12.0/24 und 10.0.13.0/24. Die Subnetze trennen Rollen; die Nutzung von zwei Zonen trennt Ausfallorte. Mehrere Subnetze allein in einer Zone würden das nicht leisten.

Verbinde Netzwerke bewusst

Virtuelle Netzwerke bieten logische Isolation von anderen Kunden und Netzwerken. Kommunikation benötigt einen Netzwerkpfad und eine Berechtigung. Eine Peering-Verbindung ermöglicht zwei Netzwerken, über private Adressen über das Netzwerk des Anbieters zu kommunizieren. Peering kann Regionen sowie Konto-, Abonnement- oder Projektgrenzen überschreiten, aber die Adressbereiche dürfen sich nicht überschneiden.

Prüfe die Bereiche von Büros und Partnern, bevor du Cloud-Bereiche wählst. Wenn sowohl ein Büro als auch eine VPC 10.0.0.0/16 nutzen, könnte ein Ziel wie 10.0.3.20 zu beiden Seiten gehören. Die Wahl von 10.1.0.0/16 für die Cloud vermeidet diesen Konflikt. Einen Adressplan nach der Bereitstellung von Servern zu korrigieren, kann deren Betrieb stören.

Peering ist nicht transitiv. Wenn A mit B und B mit C über Peering verbunden ist, benötigt A weiterhin eine eigene Verbindung zu C. Außerdem verschlüsselt ein privater Pfad keine Daten: Nutze dafür Verschlüsselung. Das Erstellen des virtuellen Netzwerks selbst ist bei diesen Anbietern kostenlos; für Gateways, öffentliche IPv4-Adressen und Datenübertragung können Kosten anfallen.

Eine Zieladresse gibt einem Netzwerk an, wohin Datenverkehr gelangen soll. Eine Routingtabelle sagt ihm, wohin es diesen Datenverkehr als Nächstes senden soll. Das Routing stellt einen Pfad bereit; Sicherheitsregeln entscheiden, ob Datenverkehr ihn nutzen darf.

Wähle die passende Route

Jede Route ordnet einem Zielbereich ein Ziel zu. Eine lokale Route verbindet Subnetze innerhalb desselben virtuellen Netzwerks. Die IPv4-Standardroute 0.0.0.0/0 passt zu jeder Adresse, aber eine spezifischere passende Route hat Vorrang. Eine größere Präfixzahl nach dem Schrägstrich bedeutet einen spezifischeren Bereich.

Angenommen, ein AWS-Anwendungssubnetz nutzt diese Routen:

Eine Anfrage von 10.0.2.15 an die Datenbank 10.0.3.20 passt zu beiden Bereichen. Das /16 ist spezifischer als /0, daher bleibt die Anfrage lokal. Eine Anfrage an den Aktualisierungsserver 203.0.113.50 passt nur zur Standardroute und geht an das NAT-Gateway. Sicherheitsregeln müssen jede Verbindung erlauben.

Erlaube öffentlichen Zugriff bewusst

Bei AWS verbindet ein Internetgateway eine VPC mit dem Internet. Ein Subnetz mit einer Standardroute zu diesem Gateway ist ein öffentliches Subnetz. Sein Adressbereich kann dennoch ein privater Bereich wie 10.0.1.0/24 sein. „Öffentlich“ beschreibt sein Routing, nicht die Schreibweise seiner Adressen.

Um einen Server aus dem Internet zu erreichen, müssen drei Dinge zusammenkommen: ein Internetpfad, eine öffentliche IP-Adresse auf dem Server oder einem vorgeschalteten Load Balancer und Sicherheitsregeln, die die Verbindung erlauben. Ein AWS-Subnetz kann öffentlich sein, während ein bestimmter Server darin keinen direkten öffentlichen Zugriff hat.

Azure und Google Cloud stellen integrierte Internetpfade bereit, ohne dass du ein Internetgateway wie bei AWS erstellen musst. Ihre Sicherheitsregeln und öffentlichen Adressen sind weiterhin relevant. Ein privates Subnetz im allgemeinen Sinn bietet Internetnutzern keinen direkten Pfad zu seinen Ressourcen. Das macht es für Datenbanken und interne Anwendungsserver nützlich.

Gib privaten Servern ausgehenden Zugriff

Ein NAT-Gateway ermöglicht einem privaten Server, eine Internetverbindung aufzubauen. Es ersetzt die private Quelladresse durch eine öffentliche Adresse, verfolgt die Verbindung und liefert die Antwort an den richtigen Server. Es nimmt keine neue Verbindung an, die ein Internetnutzer zu diesem privaten Server aufbaut.

Bei AWS befindet sich ein öffentliches NAT-Gateway in einem öffentlichen Subnetz. Die Standardroute des privaten Anwendungssubnetzes verweist darauf, und das Subnetz des NAT-Gateways hat eine Route zum Internetgateway. Die Anwendung kann Aktualisierungen abrufen, während ihr Datenbanksubnetz mit nur einer lokalen Route keinen Internetpfad hat. Azure NAT Gateway wird einem Subnetz zugeordnet; Google Cloud bietet Cloud NAT. Für NAT-Dienste fallen Kosten für Laufzeit und Datenverarbeitung an.

Prüfe die Standardeinstellungen des Anbieters

Die Subnetze einer AWS-Standard-VPC sind öffentlich und weisen neuen Instanzen normalerweise öffentliche Adressen zu. Einer selbst erstellten VPC musst du ein Internetgateway hinzufügen. Reservierte statische öffentliche Adressen bleiben gleich; AWS nennt eine solche Adresse Elastic IP. Automatisch zugewiesene Adressen können sich nach dem Stoppen und Starten einer Maschine ändern. Seit Februar 2024 berechnet AWS jede öffentliche IPv4-Adresse, auch genutzte.

Azure verwendet „privates Subnetz“ speziell für ein Subnetz mit abgeschaltetem ausgehendem Standardzugriff. Es benötigt eine ausdrücklich eingerichtete Methode für ausgehenden Zugriff, etwa NAT oder eine zugewiesene öffentliche IP-Adresse. Diese Einstellung allein blockiert keinen eingehenden Datenverkehr. Das Portal erstellt standardmäßig private Subnetze. Bei der nach dem 31. März 2026 veröffentlichten API-Version erhalten auch neue virtuelle Netzwerke standardmäßig private Subnetze; frühere API-Versionen behalten das alte Verhalten bei, und bestehende Netzwerke bleiben unverändert.

Ein verwalteter Dienst kann außerhalb deines virtuellen Netzwerks laufen. Ein Endpunkt ist die Adresse, über die Clients ihn erreichen, normalerweise über einen DNS-Namen. Der Netzwerkpfad des Endpunkts und die Datenberechtigungen des Dienstes lösen unterschiedliche Aufgaben.

Unterscheide öffentliche Erreichbarkeit und Datenzugriff

Ein öffentlicher Endpunkt wird in eine öffentliche IP-Adresse aufgelöst. Clients im Internet können versuchen, sich zu verbinden, aber dadurch werden die gespeicherten Daten nicht öffentlich. Zugangsdaten und Berechtigungen steuern normalerweise den Zugriff. Einige Dienste erlauben bei entsprechender Konfiguration auch anonymen Zugriff; ein Berechtigungsfehler beim Objektspeicher kann Dateien offenlegen.

Nutze für Dienstdatenverkehr HTTPS, das TLS-Verschlüsselung verwendet. Schreibe HTTPS vor, wo es unterstützt wird, und beschränke, welche Adressen oder Netzwerke sich verbinden dürfen. Öffentliche Erreichbarkeit, Zugriffsberechtigung und Verschlüsselung sind separate Einstellungen. Eine autorisierte Anwendung kann einen öffentlichen Endpunkt sicher nutzen, während ein schlecht konfigurierter Dienst auch in einem privaten Netzwerk Daten preisgeben kann.

Füge eine private Adresse hinzu

Ein privater Endpunkt gibt einem unterstützten Dienst eine private Adresse innerhalb deines Netzwerks. Der Anbieter erstellt eine Netzwerkschnittstelle in einem Subnetz, und der Datenverkehr zu dieser Adresse bleibt in seinem Netzwerk.

Auch Bürosysteme können private Endpunkte über ein VPN oder eine dedizierte Verbindung erreichen. Über Peering verbundene Netzwerke können sie erreichen, wenn Routing, DNS und Sicherheitseinstellungen den Pfad unterstützen.

Sorge dafür, dass der Dienstname den Endpunkt findet

Anwendungen verbinden sich gewöhnlich über einen Dienstnamen und nicht über eine fest eingetragene IP-Adresse. Privates DNS sorgt dafür, dass dieser Name innerhalb des Netzwerks in die private Adresse des Endpunkts aufgelöst wird. Ein interner Client könnte beispielsweise den Namen seines Speicherdienstes in 10.0.2.40 auflösen. Externe Clients können weiterhin die öffentliche Adresse erhalten.

Das Erstellen des Endpunkts allein ändert nicht die DNS-Antwort für jeden Client. Löst ein interner Client weiterhin die öffentliche Adresse auf, nutzt er weiterhin den öffentlichen Pfad. Verknüpfe die private DNS-Zone mit dem Netzwerk und richte DNS-Weiterleitung für lokale Clients ein. Um privaten Zugriff vorzuschreiben, deaktiviere oder beschränke zusätzlich den öffentlichen Endpunkt des Dienstes. Beim Erstellen eines privaten Endpunkts bleiben die Einstellungen für den öffentlichen Zugriff bestehen.

Erkenne verwandte Optionen

Ein AWS-Gateway-Endpunkt erreicht S3 oder DynamoDB über einen Routingtabelleneintrag. Er erstellt nicht die private Netzwerkschnittstelle eines Schnittstellenendpunkts, und es fällt keine zusätzliche Endpunktgebühr an. Ein Azure-Dienstendpunkt kennzeichnet ein zugelassenes Subnetz und leitet dessen Dienstdatenverkehr über das Microsoft-Netzwerk, aber der Dienst hat weiterhin eine öffentliche IP-Adresse. Private Google Access ermöglicht Maschinen mit internen Adressen den Zugriff auf Google-APIs und -Dienste.

Betrachte einen Analyseserver, der täglich 500 GB aus einem regionalen Objektspeicher liest. Werden diese Lesezugriffe über NAT gesendet, verarbeitet der NAT-Dienst alle 500 GB. Bei AWS leitet ein geeigneter S3-Gateway-Endpunkt diesen Dienstdatenverkehr über die Endpunktroute, ohne zusätzliche Gateway-Endpunktgebühr. Schnittstellen- und private Endpunkte haben eigene Gebühren; vergleiche daher den gesamten Pfad und seine Kosten. Der Endpunkt verändert die Konnektivität; TLS sorgt weiterhin für die Verschlüsselung bei der Übertragung.

Ein Server kann eine Route zu einem anderen Netzwerk haben und dessen Datenverkehr trotzdem abweisen. Eine Sicherheitsgruppe dient als virtuelle Firewall für Ressourcen. Eingehende Regeln steuern Datenverkehr zu einer Ressource; ausgehende Regeln steuern Datenverkehr, der sie verlässt.

Lies eine Regel

Lies bei TCP oder UDP Protokoll, Port und Quelle oder Ziel zusammen. Die Regel „TCP 443 von 198.51.100.7/32 zulassen“ erlaubt HTTPS-Datenverkehr von einer Adresse. Die Quelle 0.0.0.0/0 bedeutet jede IPv4-Adresse. Eine eingehende Quelle kann auch eine Sicherheitsgruppe bezeichnen, sodass der Zugriff der Rolle eines Servers folgt, wenn sich seine IP-Adresse ändert.

Nützliche Ports sind SSH 22, RDP 3389, HTTP 80, HTTPS 443, DNS 53, MySQL 3306, PostgreSQL 5432 und Microsoft SQL Server 1433. ICMP, das von Ping genutzt wird, hat Nachrichtentypen statt TCP- oder UDP-Ports.

Verstehe zustandsbehaftete Filterung

Ein zustandsbehafteter Filter merkt sich erlaubte Verbindungen. Erlaubt eine eingehende Regel eine neue HTTPS-Verbindung, dürfen Antworten ohne separate ausgehende Regel wieder hinaus. Das erlaubt dem Server nicht, beliebige unabhängige ausgehende Verbindungen aufzubauen. Neue Verbindungen benötigen weiterhin eine eigene Erlaubnis.

AWS-Sicherheitsgruppen werden Netzwerkschnittstellen zugeordnet. Mehrere Ressourcen können eine Gruppe teilen, und eine Ressource kann mehrere Gruppen haben. Ihre Zulassungsregeln werden kombiniert: Datenverkehr wird durchgelassen, wenn eine anwendbare Regel ihn erlaubt. Die Regelreihenfolge hat keine Wirkung, und es gibt keine ausdrückliche Verweigerungsregel, die eine weit gefasste Zulassung aufheben könnte. Eine neu erstellte Gruppe erlaubt keinen eingehenden Datenverkehr und lässt ausgehenden Datenverkehr zu, bis sie geändert wird.

Baue eine Kette zugelassener Rollen auf

Gib bei einer Anwendung mit drei Ebenen jeder Ebene nur die benötigten eingehenden Verbindungen:

1. Der Load Balancer erlaubt TCP 443 von Internetnutzern.
2. Die Webserver erlauben TCP 443 aus der Gruppe des Load Balancers. Die Verwaltung über TCP 22 ist auf die Büroadresse des Administrators beschränkt.
3. Die MySQL-Datenbank erlaubt TCP 3306 aus der Webserver-Gruppe.

Wenn ein Ersatz-Webserver der Webserver-Gruppe beitritt, erhält er den vorgesehenen Datenbankzugriff ohne neue adressbasierte Regel. Eine direkte Internetanfrage an die Datenbank scheitert, weil ihre Quelle nicht erlaubt ist. Erlaubt jedoch eine zweite zugeordnete Gruppe denselben Datenbankport weit gefasst, gilt diese weit gefasste Berechtigung weiterhin; in der ersten Gruppe gibt es keine engere Verweigerung, die sie aufhebt.

Vergleiche Filter der Anbieter

Eine Azure-Netzwerksicherheitsgruppe, kurz NSG, kann einem Subnetz, einer Netzwerkschnittstelle oder beidem zugeordnet werden. Benutzerdefinierte Prioritäten reichen von 100 bis 4096 und stehen vor den integrierten Standardregeln mit 65000, 65001 und 65500. Die eingehenden Standardregeln erlauben Datenverkehr innerhalb des virtuellen Netzwerks und vom Azure-Load-Balancer und verweigern dann anderen eingehenden Datenverkehr. Google Cloud wählt Zielmaschinen anhand von Tags oder Dienstkonten aus; seine impliziten Regeln verweigern eingehenden und erlauben ausgehenden Datenverkehr.

Wende das Prinzip der geringsten Rechte an: Erlaube nur die benötigten Ports für die kleinstmögliche sinnvolle Auswahl an Quellen. SSH oder RDP für das gesamte Internet zu öffnen, setzt administrative Anmeldedienste automatisierten Angriffen aus. Verwaltete Zugriffsoptionen sind unter anderem AWS Systems Manager Session Manager, Azure Bastion und Google Cloud Identity-Aware Proxy. Ein Portfilter kann einen Angriff innerhalb erlaubten HTTPS-Datenverkehrs nicht erkennen; Anwendungsschutz und Anmeldekontrollen schützen diese Ebene.

Eine AWS-Netzwerkzugriffskontrollliste, kurz Netzwerk-ACL, filtert Datenverkehr, der eine Subnetzgrenze überschreitet. Sie gilt für jede Ressource in diesem Subnetz. Jedes Subnetz hat eine Netzwerk-ACL, und dieselbe ACL kann mehrere Subnetze bedienen.

Verfolge die erste passende Regel

Netzwerk-ACL-Regeln können Datenverkehr zulassen oder verweigern. AWS prüft sie beginnend mit der niedrigsten Regelnummer und stoppt beim ersten Treffer. Eine abschließende *-Regel verweigert Datenverkehr, auf den keine Regel passt. Die Standard-ACL der VPC erlaubt eingehenden und ausgehenden Datenverkehr; eine neu erstellte benutzerdefinierte ACL verweigert Datenverkehr, bis du Zulassungsregeln hinzufügst.

Angenommen, Regel 100 erlaubt TCP 443 von jeder IPv4-Adresse, während Regel 110 Datenverkehr von 203.0.113.0/24 verweigert. Eine Anfrage von 203.0.113.77 an Port 443 passt zuerst zu Regel 100 und wird durchgelassen. Die spätere Verweigerung kommt nie zum Zug. Verschiebe diese Verweigerung auf Regel 90, um den Bereich vor der weit gefassten HTTPS-Zulassung zu blockieren.

Verfolge die Antwort als separates Paket

Eine ACL ist zustandslos: Sie merkt sich nicht, dass eine Verbindung erlaubt wurde. Eine Webanfrage nutzt den Zielport 443 des Servers, aber die Antwort geht an den temporären oder ephemeren Port des Clients zurück. Das kann eine hohe Nummer wie 50432 sein.

Für eine Website mit funktionierender Route und Sicherheitsgruppe gilt:

1. Ein Client sendet eine Anfrage von seinem temporären Port an Serverport 443.
2. Die Subnetz-ACL lässt das eingehende Paket über ihre HTTPS-Regel zu.
3. Der Server antwortet an den temporären Port des Clients.
4. Die ausgehende ACL prüft diesen Zielport unabhängig davon.

Eine ausgehende Regel, die nur Zielport 443 erlaubt, deckt diese Antwort nicht ab. Die Antwort benötigt eine ausgehende Zulassung, die ihren Zielport einschließt; TCP 1024–65535 ist ein häufig verwendeter breiter ephemerer Bereich. Der erforderliche Bereich hängt von den unterstützten Clients und dem unterstützten Datenverkehr ab. Die Berechtigung einer zustandsbehafteten Sicherheitsgruppe umgeht nicht die separate Entscheidung der ACL.

Vergleiche die beiden AWS-Schichten

Eingehender Internetverkehr muss beide Schichten passieren. Datenverkehr zwischen zwei Ressourcen im selben Subnetz überschreitet die Subnetzgrenze nicht, sodass die ACL dieses Subnetzes ihn nicht filtert. Die Sicherheitsgruppen der Ressourcen gelten weiterhin.

Nutze unabhängige Schichten

Gestaffelte Verteidigung begrenzt den Schaden durch eine einzelne fehlerhafte Einstellung. Sicherheitsgruppen geben jeder Anwendungsrolle präzise Berechtigungen. ACLs ergänzen Leitplanken für das gesamte Subnetz, etwa indem sie einen bekannten bösartigen Bereich verweigern. Betriebssystem-Firewalls, verwaltete Netzwerkfirewalls, Web Application Firewalls, TLS und Identitätsprüfungen schützen andere Teile des Pfads. Datenflussprotokolle zeichnen zugelassene und abgelehnte Netzwerkflüsse auf; Amazon Inspector hilft, Schwachstellen in Workloads und unbeabsichtigte Erreichbarkeit zu erkennen.

Azure hat keine separate Netzwerk-ACL wie AWS: Subnetz- und Schnittstellen-NSGs stellen diese Schichten bereit, und beide sind zustandsbehaftet. Für eingehenden Azure-Datenverkehr müssen zuerst die Subnetz-NSG und dann die Schnittstellen-NSG ihn erlauben. Google Cloud nutzt zustandsbehaftete VPC-Firewallregeln und umfassendere Firewallrichtlinien, darunter Organisations- und Ordnerrichtlinien.

Menschen merken sich Namen wie www.example.com; Computer senden Datenverkehr an IP-Adressen. DNS verbindet beides. Cloud-Anbieter hosten Einträge über Amazon Route 53, Azure DNS und Google Cloud DNS.

Verfolge eine Namensabfrage

Ein Client fragt einen Resolver nach einer Adresse. Hat der Resolver keine zwischengespeicherte Antwort, fragt er einen Root-Server, wo er die Server für .com findet. Diese Server nennen die autoritativen Nameserver der Domain. Ein autoritativer Server enthält die Einträge der Domain und gibt die Antwort zurück, die der Resolver für spätere Clients zwischenspeichert. Route 53 weist einer öffentlichen gehosteten Zone vier autoritative Nameserver zu. Der Client verbindet sich dann mit der zurückgegebenen Adresse. DNS überträgt nicht den Anwendungsdatenverkehr der Website.

Eine Zone ist die verwaltete Sammlung von Einträgen für eine Domain. Um die öffentliche Zone eines neuen Anbieters zu nutzen, trage dessen Nameserver beim Domain-Registrar ein. Das Hosting einer Zone und die Registrierung einer Domain sind separate Dienste: Route 53 bietet beides an, während Azure DNS Zonen hostet, ohne Domainregistrierungen zu verkaufen.

Wähle den Eintrag

Der Zonen-Apex ist die reine Domain, etwa example.com. Ein standardmäßiger CNAME kann dort nicht stehen, weil der Apex auch NS- und SOA-Einträge benötigt. Alias-Einträge von Route 53 und Alias-Eintragssätze von Azure können unterstützte Apex-Einträge auf Cloud-Ressourcen verweisen lassen und Änderungen ihrer Adressen nachvollziehen.

Berücksichtige zwischengespeicherte Antworten

Die TTL oder Gültigkeitsdauer eines Eintrags gibt an, wie viele Sekunden ein Resolver die Antwort zwischenspeichern darf. Angenommen, ein Resolver speichert um 9:55 Uhr eine Antwort mit einer TTL von 3.600 Sekunden zwischen. Wird der Eintrag um 10:00 Uhr geändert, löscht das diese Kopie nicht: Sie kann bis 10:55 Uhr gültig bleiben. Senke eine TTL mindestens eine alte TTL vor einem geplanten Wechsel auf 300 Sekunden, damit die alten langlebigen Kopien Zeit haben abzulaufen. Eine Senkung zum Zeitpunkt des Wechsels kann bereits zwischengespeicherte Kopien nicht verkürzen.

DNS-Routingrichtlinien beeinflussen die Antworten auf Abfragen. Einfaches Routing gibt eine einfache Antwort. Gewichtetes Routing gibt Antworten in gewählten Anteilen, etwa 90 % für die aktuelle Version und 10 % für eine neue Version; Latenz-Routing bevorzugt die niedrigste gemessene Latenz; Geolokalisierungs-Routing wählt nach dem Standort des Nutzers; Failover-Routing wechselt von einem primären zu einem Standby-Endpunkt, wenn Zustandsprüfungen einen Ausfall zeigen. Jeder Route-53-Prüfer sendet normalerweise alle 30 Sekunden eine Zustandsprüfung. Azure Traffic Manager und Google Cloud DNS bieten ebenfalls DNS-basierte Routingoptionen.

Bei einem Shop mit einem primären Standort in Frankfurt und einem Standby in Irland führt eine fehlgeschlagene Zustandsprüfung des primären Standorts dazu, dass neue Antworten auf den Standby verweisen. Bereits zwischengespeicherte Antworten bleiben bis zu ihrem Ablauf bestehen; eine kurze TTL wie 60 Sekunden verringert diese Verzögerung. Auch gewichtetes Routing verteilt DNS-Antworten, keine genauen Anzahlen von Nutzern oder Anwendungsanfragen: Eine zwischengespeicherte Antwort kann viele Nutzer bedienen. Ein Load Balancer wirkt auf eingehenden Datenverkehr auf einer anderen Ebene.

Löse interne Namen auf

Eine private DNS-Zone liefert Antworten an verknüpfte virtuelle Netzwerke. Sie kann db.internal.example.com einer privaten Datenbankadresse zuordnen oder einen Dienstnamen an einen privaten Endpunkt leiten. Lokale Clients benötigen einen geeigneten DNS-Weiterleitungspfad über ihr VPN oder ihre dedizierte Verbindung, etwa über Route 53 Resolver-Endpunkte oder Azure DNS Private Resolver. Ein funktionierender Netzwerktunnel allein teilt einem Büro-Resolver nicht mit, wo er nach den privaten Namen der Cloud fragen muss.

Route 53 und Azure DNS veröffentlichen für ihre DNS-Dienste SLAs mit 100 % Verfügbarkeit. Ein SLA ist eine vertragliche Dienstzusage; eine zwischengespeicherte Antwort kann dennoch auf einen Anwendungsserver verweisen, der nicht verfügbar ist.

Ein Content Delivery Network, kurz CDN, hält temporäre Kopien von Inhalten in der Nähe der Nutzer bereit. Sein Ursprung enthält die Originaldateien oder erzeugt die Antworten der Anwendung. Amazon CloudFront, Azure Front Door und Google Cloud CDN bieten diesen Dienst über Edge-Standorte auf der ganzen Welt an.

Verfolge eine Anfrage

Der Browser löst den CDN-Namen auf und verbindet sich mit einem nahe gelegenen Edge-Standort. CloudFront kann Nutzer über DNS-Antworten lenken; Azure Front Door und Google Cloud CDN nutzen Anycast-Adressierung. Dabei kündigen mehrere Standorte dieselbe IP-Adresse an, und das Routing führt Nutzer zu einem nahe gelegenen Standort. Ein Edge-Standort ist keine vollständige Cloud-Region, und Anbieter betreiben viel mehr Edge-Standorte als Regionen.

Ein Cache-Treffer entsteht, wenn der Edge-Standort eine aktuelle, nutzbare Kopie hat und ausliefert. Bei einem Cache-Fehltreffer holt der Edge-Standort den Inhalt vom Ursprung, gibt ihn zurück und kann ihn für spätere Anfragen zwischenspeichern. Bilder, Skripte, Stylesheets, Downloads und Videos eignen sich oft gut, weil viele Nutzer dieselben Inhalte anfragen.

Miss den Nutzen

Bei Anfragen über große Entfernungen dauert jeder Netzwerkhin- und -rückweg länger. Eine in Sydney aufgerufene Seite benötigt vier aufeinanderfolgende Hin- und Rückwege zu ihrem Ursprung in Frankfurt. Bei 250 ms pro Hin- und Rückweg wartet sie dafür 1.000 ms. Bei einem Edge-Standort in Sydney mit 15 ms pro Hin- und Rückweg dauern die vier Wege 60 ms. Dieses Beispiel misst die Verzögerung durch die Hin- und Rückwege, nicht die vollständige Ladezeit der Seite.

Die Cache-Trefferquote ist:

Bei 9.200 Treffern unter 10.000 Anfragen beträgt die Quote 92 %. In diesem einfachen Beispiel erreichen die 800 Fehltreffer den Ursprung. Eine hohe Trefferquote verringert die Arbeit am Ursprung und die von dort gesendeten Daten. Das hilft bei einem plötzlichen Anstieg der Besucherzahlen.

Steuere die Aktualität

Eine CDN-TTL steuert, wie lange Inhalte wiederverwendet werden können. Der Ursprung kann Cache-Control: max-age=86400 senden und damit die Zwischenspeicherung für einen Tag erlauben; alternativ können CDN-Einstellungen die Gültigkeitsdauer steuern. Eine Datei am Ursprung zu ändern, ersetzt aktuelle zwischengespeicherte Kopien nicht sofort.

Um eine dringende Korrektur zu veröffentlichen, invalidiere den zwischengespeicherten Pfad. Eine andere Möglichkeit ist, einen neuen Dateinamen wie app.v2.js zu veröffentlichen und die Seite so zu ändern, dass sie diesen anfragt. Der neue Name bezeichnet ein anderes Objekt. Verhindere, dass personalisierte Seiten wie eine Kontoseite oder ein Warenkorb als öffentlich zwischengespeicherte Inhalte geteilt werden. Auch wenn eine Antwort nicht zwischengespeichert werden kann, kann der Edge-Standort die Bereitstellung verbessern, indem er TLS in der Nähe beendet und Verbindungen zum Ursprung wiederverwendet.

Unterscheide Zwischenspeicherung von anderen Netzwerkdiensten

Load Balancer können regional oder global sein. Global Accelerator stellt feste Anycast-Adressen bereit und kann sich für Spiele- oder Sprachdatenverkehr eignen, der nicht von der Zwischenspeicherung von Webinhalten profitiert.

Der Edge-Standort kann auch HTTPS-Zertifikate und Regeln einer Web Application Firewall anwenden. Sein großes Netzwerk fängt viele DDoS-Angriffe ab; CloudFront enthält AWS Shield Standard. Einschränkungen am Ursprung, etwa die Ursprung-Zugriffssteuerung von CloudFront für S3, können verhindern, dass Nutzer das CDN umgehen. Kosten richten sich hauptsächlich nach den ausgelieferten Daten und der Anzahl der Anfragen. Nutzer, die sich bereits nahe am Ursprung befinden, oder Anwendungen mit fast ausschließlich einzigartigen Antworten profitieren weniger von der Zwischenspeicherung. Edge-Kopien sind temporär und können aus dem Cache entfernt werden, daher benötigt der Ursprung weiterhin eigenen zuverlässigen Speicher und eine Datensicherung.

Ein Büro muss möglicherweise eine Anwendung unter einer privaten Cloud-Adresse nutzen. Ein hybrides Netzwerk verbindet lokale Netzwerke mit Cloud-Netzwerken. Ein VPN, ein virtuelles privates Netzwerk, überträgt diesen Datenverkehr in einem verschlüsselten Tunnel über das öffentliche Internet.

Wähle, was verbunden wird

Ein Site-to-Site-VPN verbindet ein ganzes Büro- oder Rechenzentrumsnetzwerk. Ein VPN-fähiger Router oder eine Firewall übernimmt den Tunnel für diesen Standort. Ein Point-to-Site-VPN oder Client-VPN verbindet ein einzelnes Gerät, auf dem Clientsoftware läuft. AWS Client VPN und Point-to-Site-Verbindungen von Azure VPN Gateway unterstützen Nutzer an entfernten Standorten.

Site-to-Site-VPNs nutzen IPsec. Die Tunnelenden authentifizieren sich gegenseitig, häufig mit einem gemeinsamen Schlüssel oder Zertifikaten. Mithilfe von IKE vereinbaren sie Verschlüsselungsschlüssel; IPsec schützt anschließend Pakete im Tunnel. Ein VPN nutzt einen gemeinsam genutzten Internetpfad, auch wenn seine Inhalte verschlüsselt sind.

Bestimme beide Enden

Bei AWS wird ein virtuelles privates Gateway einer VPC zugeordnet; ein Transit-Gateway kann mehrere VPCs bedienen. Azure stellt sein VPN-Gateway in einem dedizierten Subnetz namens GatewaySubnet bereit. Google Cloud bietet HA-VPN-Gateways an. Im Büro bildet ein Router oder eine Firewall mit öffentlicher Adresse das andere Ende; AWS nennt dieses Gerät Kunden-Gateway-Gerät.

Die Gateways benötigen auch Routen. Diese können statisch eingerichtet oder über BGP gelernt werden. BGP ermöglicht Routern, die für sie erreichbaren Adressbereiche auszutauschen. Ein verschlüsselter Tunnel ohne die richtigen Routen bietet einer Anwendung keinen nutzbaren durchgehenden Pfad.

Verfolge eine private Anfrage

Betrachte ein Büro, das 192.168.10.0/24 nutzt, und eine AWS-VPC mit 10.0.0.0/16:

1. Das Team erstellt das Cloud-Gateway und konfiguriert den Bürorouter für das VPN.
2. Die Büroroute für 10.0.0.0/16 verweist in den Tunnel.
3. Die Cloud-Route für 192.168.10.0/24 verweist durch das VPN-Gateway zurück.
4. Die Sicherheitsgruppe der Anwendung erlaubt den benötigten Datenverkehr aus dem Büro.

Das Bürogerät 192.168.10.25 kann sich nun mit der Anwendung 10.0.2.15 verbinden. Sein Datenverkehr wird zwischen den VPN-Enden verschlüsselt. Die überschneidungsfreien Bereiche ermöglichen jeder Seite, lokale von entfernten Zielen zu unterscheiden. Private Dienstnamen benötigen zusätzlich DNS-Weiterleitung; der Tunnel richtet diese nicht automatisch ein.

Beseitige Single Points of Failure

Eine AWS-Site-to-Site-VPN-Verbindung stellt zwei Tunnel zu verschiedenen AWS-Endpunkten bereit. Konfiguriere beide, damit einer bei Wartung oder Ausfall den Datenverkehr übernehmen kann. Azure unterstützt Aktiv-Aktiv-Gateways. Google Cloud HA VPN kann bei der erforderlichen redundanten Tunnelkonfiguration über beide Schnittstellen ein SLA mit 99,99 % Verfügbarkeit bieten. Ein zweiter Bürorouter und ein zweiter Internetanbieter schützen vor Ausfällen, die zwei cloudseitige Tunnel allein nicht beheben können.

VPNs lassen sich mit vorhandenem Internetzugang gewöhnlich innerhalb von Stunden einrichten. Zu den Kosten gehören hauptsächlich Verbindungszeit und Datenübertragung. Internetauslastung und Entfernung beeinflussen Latenz und Datendurchsatz; ein standardmäßiger AWS-Tunnel unterstützt bis zu 1,25 Gbps, nicht eine garantierte dauerhafte Übertragungsrate. Ein VPN bietet häufig zunächst Zugriff, während eine dedizierte Leitung eingerichtet wird, und bleibt später als verschlüsselter Ausweichpfad bestehen. Eine öffentliche Website, die bereits für Internetnutzer bestimmt ist, benötigt für diese Besucher kein Site-to-Site-VPN.

Einige Organisationen benötigen eine Cloud-Verbindung mit gleichmäßigerer Leistung, als ein Internetpfad bietet. Eine dedizierte private Verbindung verbindet das Netzwerk der Organisation mit dem Anbieter, ohne das öffentliche Internet zu durchqueren. Die Dienste heißen AWS Direct Connect, Azure ExpressRoute und Google Cloud Interconnect.

Verfolge den physischen Pfad

Cloud-Anbieter treffen Kunden und Telekommunikationsnetze in Colocation-Rechenzentren, in denen viele Netzwerke Geräte betreiben. Steht der Router des Kunden bereits dort, verbindet eine Querverbindung, ein kurzes physisches Kabel, ihn mit den Geräten des Anbieters. Andernfalls verlängert ein Telekommunikations- oder Verbindungspartner eine Leitung vom Büro oder Rechenzentrum bis zu diesem Verbindungspunkt.

Der Kauf des cloudseitigen Ports macht die Verbindung zu dieser Einrichtung nicht überflüssig. Die Installation kann eine Autorisierungserklärung, die Bestellung einer Querverbindung, eine Telekommunikationsleitung und abgestimmte Tests umfassen. Rechne mit wochenlanger Vorbereitung. Kosten können für den Port, den Dienst des Partners, die Telekommunikationsleitung und übertragene Daten anfallen.

Stimme den Dienst auf die Kapazität ab

Ein dedizierter Port ist mit großen festen Kapazitäten erhältlich. AWS Direct Connect bietet dedizierte Verbindungen mit 1, 10, 100 und 400 Gbps. Von Partnern bereitgestellte Optionen wie gehostete AWS-Verbindungen und Google Partner Interconnect bieten kleinere Kapazitätsstufen ab etwa 50 Mbps. ExpressRoute wird häufig über einen Verbindungsanbieter bereitgestellt.

Eine gehostete Verbindung mit 50 Mbps hat weniger Kapazität als ein standardmäßiger AWS-VPN-Tunnel mit einer Grenze von 1,25 Gbps. Das Wort „dediziert“ beschreibt die Art der Verbindung; es verspricht nicht, bei der Bandbreite jedes VPN zu übertreffen. Vergleiche die tatsächlich gekaufte Kapazität und den gemessenen Datendurchsatz.

Unterscheide Privatheit und Verschlüsselung

Die Umgehung des gemeinsam genutzten Internets verbessert die Gleichmäßigkeit der Leistung und bietet einen privaten Pfad. Leitungen mit hoher Kapazität unterstützen große regelmäßige Übertragungen, und private Pfade können Anforderungen erfüllen, nach denen Datenverkehr nicht über das öffentliche Internet laufen darf. Für ausgehende Datenübertragung von AWS über Direct Connect gelten außerdem niedrigere Gebühren pro Gigabyte als für ausgehende Internetübertragung, wobei feste Leitungskosten weiterhin ins Gewicht fallen.

Eine private Leitung ist standardmäßig nicht verschlüsselt. Wenn Vertraulichkeit Verschlüsselung erfordert, wähle ein geeignetes Verfahren: TLS in den Anwendungen, ein IPsec-VPN über die private Verbindung oder MACsec auf unterstützten dedizierten Ports. TLS schützt Anwendungssitzungen; IPsec schützt getunnelten IP-Datenverkehr; MACsec verschlüsselt Frames auf unterstützten Verbindungen. Eine Anforderung an einen privaten Pfad und eine Anforderung an verschlüsselten Datenverkehr müssen jeweils erfüllt werden.

Plane für einen Verbindungsausfall

Eine einzelne physische Leitung kann durch ein durchtrenntes Kabel, einen Routerausfall oder den Ausfall einer Einrichtung ausfallen. Eine ExpressRoute-Leitung hat zwei Verbindungen zu zwei Microsoft-Edge-Routern, aber kritische Workloads profitieren weiterhin von Verbindungen über zwei Standorte. Bei zwei Verbindungen über dieselbe Einrichtung bleibt diese ein gemeinsamer Ausfallpunkt.

Ein Site-to-Site-VPN kann eine kostengünstigere Ausweichlösung bieten, falls die private Verbindung ausfällt. Seine Routen und Berechtigungen müssen bereitstehen, und sein geringerer oder stärker schwankender Datendurchsatz muss für den wesentlichen Datenverkehr ausreichen. Der Internetpfad der Ausweichlösung erfüllt möglicherweise keine strenge Anforderung, dass Datenverkehr jederzeit außerhalb des Internets bleiben muss; sowohl Verfügbarkeits- als auch Pfadanforderungen beeinflussen die Wahl.

Dedizierte Verbindungen erreichen Ressourcen virtueller Netzwerke über private Adressen. Mit zusätzlicher Konfiguration können sie auch unterstützte öffentliche Cloud-Dienste erreichen, etwa über eine öffentliche virtuelle AWS-Schnittstelle oder ExpressRoute Microsoft Peering. Sie sind Netzwerkverbindungen zur Cloud; die vorhandenen Server der Organisation bleiben an ihrem Standort.

Die Wahl einer Verbindung beginnt mit den Aufgaben, die sie unterstützen muss. Bestimme, wer Zugriff braucht, wie viele Daten übertragen werden, welche Frist und Gleichmäßigkeit gelten, wann die Verbindung eingerichtet sein muss, welche Sicherheitsanforderungen bestehen und welche Folgen ein Ausfall hat. Unterschiedliche Antworten führen zu unterschiedlichen Verbindungen.

Grenzen die Auswahl ein

Ein Unternehmen mit 40 Bürobeschäftigten und einer Frist bis nächste Woche kann mit einem Site-to-Site-VPN beginnen. Für 300 Beschäftigte, die getrennt voneinander im Homeoffice arbeiten, gibt ein Client-VPN jedem Gerät Zugriff auf interne Werkzeuge. Für eine Bank, die täglich Terabyte überträgt, können dedizierte Verbindungen über unterschiedliche Standorte und Verschlüsselung gerechtfertigt sein. Ein Hersteller, der auf eine Leitung wartet, kann zunächst ein VPN nutzen und es als Ausweichlösung behalten.

Prüfe das Übertragungszeitfenster

Bandbreite ist die Kapazität einer Verbindung; Datendurchsatz ist die tatsächlich erreichte Rate. Latenz ist die Verzögerung für einen Weg. Eine Verbindung mit hoher Bandbreite kann eine große Datei schnell übertragen, während eine große Entfernung dennoch jeden Hin- und Rückweg verlangsamt.

Verwende dezimale Dateneinheiten: 1 GB ist eine Milliarde Byte und 1 TB ist eine Billion Byte. Jedes Byte enthält 8 Bit. Gib Datenmenge und Rate in zueinander passenden Bit-Einheiten an:

Eine Datensicherung von 2 TB enthält 16 Billionen Bit. Bei effektiv 500 Mbps dividiere durch 500 Millionen Bit pro Sekunde, um 32.000 Sekunden zu erhalten, etwa 8,9 Stunden. Damit wird ein Zeitfenster von 8 Stunden überschritten. Bei dauerhaft 10 Gbps ergibt die Rechnung 1.600 Sekunden, etwa 27 Minuten. Nutze für eine praxisnahe Schätzung den effektiven Datendurchsatz; eine beworbene Portgeschwindigkeit allein berücksichtigt weder Protokoll-Overhead noch konkurrierende Nutzung oder einen langsamen Quelldatenträger.

Bei einer ungewöhnlich großen einmaligen Migration kann ein Netzwerk selbst bei voller Auslastung zu lange brauchen. Die Übertragung von 500 TB über 1 Gbps dauert 4.000.000 Sekunden, etwa 46 Tage. Physische Übertragungsdienste wie Azure Data Box können große Datenmengen durch den Versand eines befüllten Geräts transportieren. Vergleiche den gesamten Migrationszeitplan, nicht nur die Netzwerkübertragung.

Prüfe Sicherheit und Verhalten bei Ausfällen

Ein VPN bietet verschlüsselten Transport über das Internet. Eine dedizierte Verbindung bietet einen privaten Pfad und benötigt zusätzliche Verschlüsselung, wenn diese vorgeschrieben ist. Eine Anforderung an beide Eigenschaften verlangt beide Maßnahmen. Fällt eine dedizierte Verbindung aus, stellt ein VPN als Ausweichlösung einen Pfad wieder her, überträgt aber möglicherweise nicht dieselbe Datenmenge innerhalb des ursprünglichen Zeitfensters. Entscheide, welche Anwendungen weiterlaufen müssen und was die Ausweichlösung übertragen kann.

Prüfe unabhängig vom Transport überschneidungsfreie Adressbereiche, Routen in beide Richtungen, Firewallberechtigungen für Ressourcen und DNS-Weiterleitung für private Namen. Eine größere Leitung kann keinen Adresskonflikt und keine fehlende Rückroute beheben. Ebenso kann ein funktionierender Tunnel einen privaten Namen ohne den passenden Resolver-Pfad nicht auflösen.

Verknüpfe für die endgültige Entscheidung jede Wahl mit einem genannten Bedarf. „VPN, weil das Büro morgen privaten Zugriff benötigt und der Datenverkehr mäßig ist“ ist eine brauchbare Erklärung. „Dediziert, weil es schneller ist“ lässt die gekaufte Kapazität, das Übertragungszeitfenster, die Vorlaufzeit und den Ausfallplan außer Acht.