AWS VPC
- Aktualisiert2026-07-09
- 3 Minute(n) Lesezeit
Eine Virtual Private Cloud (VPC) ist eine isolierte Netzwerkumgebung in AWS.
AWS VPC bietet vollständige Kontrolle über die Netzwerkkonfiguration, einschließlich:
- IP-Adressbereiche
- Subnetze
- Routing-Tabellen
- Netzwerk-Gateways
Für SystemLink Enterprise ist ein ordnungsgemäß konfigurierter VPC für Sicherheit, Skalierbarkeit und Netzwerkisolierung unerlässlich.
Konfigurieren Sie Ihren VPC, um die Rechen- und Speicherinfrastruktur in privaten Subnetzen zu isolieren, unabhängig von internetseitigen Gateways und Load Balancern. Diese Konfiguration folgt den bewährten Methoden der Cloud-Sicherheit und stellt sicher, dass sensible Workloads nicht direkt über das Internet zugänglich sind.
Eine allgemeine Beschreibung der Architektur finden Sie im AWS SystemLink Enterprise Kubernetes Architekturdiagramm.
Subnetzarchitektur
Konfigurieren Sie Ihren VPC mit öffentlichen und privaten Subnetzen, um internetorientierte Komponenten von der internen Infrastruktur zu trennen.
Verwenden Sie die folgenden Komponenten in privaten Subnetzen ohne direkten Internetzugang:
- EKS-Cluster-Knoten: Worker-Knoten, die SystemLink Enterprise-Pods hosten, einschließlich Webdiensten, Webanwendungen und unterstützender Infrastruktur.
- Datenbanken: Amazon RDS-Instanzen für PostgreSQL oder selbstverwaltete Datenbankinstanzen.
- VPC-Endpunkte für S3: Verwenden Sie VPC-Gateway-Endpunkte, um privaten Subnetzen direkten Zugriff auf Amazon S3 zu gewähren, ohne Datenverkehr über das Internet zu senden.
Stellen Sie die folgenden Komponenten in öffentlichen Subnetzen mit Internetzugang bereit:
- Application Load Balancers (ALB): Internetorientierte Load Balancer für HTTPS-Datenverkehr mit der SystemLink Webanwendung und API
- Netzwerk-Loadbalancer (NLB): TCP-Loadbalancer für Salt-Master-Verkehr (Port 4505 und 4506)
- NAT Gateways: Aktivieren Sie den ausgehenden Internetzugang für Ressourcen in privaten Subnetzen.
CIDR-Blockplanung
Planen Sie Ihre VPC-CIDR-Blöcke, um ausreichende IP-Adressen für SystemLink Enterprise und zukünftiges Wachstum sicherzustellen.
- Empfohlene VPC-Größe: /16 CIDR-Block (65.536 IP-Adressen) bietet Flexibilität bei der Skalierung
- Minimale VPC-Größe: /20 CIDR-Block (4.096 IP-Adressen) für kleinere bis mittlere Bereitstellungen
Zuweisen von Subnetzen basierend auf folgenden Überlegungen:
- Private Subnetze für EKS-Knoten: Größe basierend auf der maximal erwarteten Knotenanzahl. Jeder EKS-Knoten benötigt eine IP-Adresse vom Subnetz-CIDR.
- Private Subnetze für Pods: Wenn Sie benutzerdefinierte Netzwerke oder den benutzerdefinierten VPC-CNI-Modus verwenden, weisen Sie zusätzliche Subnetze für Pod-IP-Adressen zu. Jeder Pod benötigt seine eigene IP-Adresse.
- Beginnen Sie mit der Standard-VPC-CNI-Konfiguration, bei der Pods Knoten-Subnetze gemeinsam nutzen, es sei denn, Sie haben spezifische Anforderungen an die Netzwerkisolierung auf Pod-Ebene.
- Beobachten Sie die IP-Nutzung sorgfältig. Jeder Knoten kann je nach EC2-Instanztyp 10-100+ IP-Adressen verwenden.
- Plan für Wachstum. Stellen Sie sicher, dass die Subnetzgröße eine erhebliche Skalierung Ihrer Arbeitslast unterstützt.
- Öffentliche Subnetze: Für Load Balancer und NAT-Gateways ist eine geringere Zuweisung wie /24 ausreichend.
- Multi-AZ-Bereitstellung: Erstellen Sie Subnetzpaare (öffentlich/privat) in mindestens zwei Verfügbarkeitszonen für hohe Verfügbarkeit.
| Subnetztyp | Verfügbarkeitsbereich | CIDR-Block | Verfügbare IPs |
|---|---|---|---|
| Privat (EKS-Knoten) | us-east-1a | 10.0.0.0/19 | 8.192 |
| Privat (EKS-Knoten) | us-east-1b | 10.0.32.0/19 | 8.192 |
| Privat (Datenbanken) | us-east-1a | 10.0.64.0/24 | 256 |
| Privat (Datenbanken) | us-east-1b | 10.0.65.0/24 | 256 |
| Öffentlich | us-east-1a | 10.0.128.0/24 | 256 |
| Öffentlich | us-east-1b | 10.0.129.0/24 | 256 |
Best Practices für Sicherheit
Beachten Sie beim Konfigurieren Ihres VPCs für SystemLink Enterprise die folgenden Sicherheitsrichtlinien:
- Kein direkter Internetzugang für die Berechnung und Speicherung: Alle EKS-Knoten, Datenbanken und internen Dienste müssen sich in privaten Subnetzen ohne Internet-Gateway-Verbindung befinden.
- Datenflussisolierung: Der Internetverkehr fließt über das Internet, das öffentliche ALB/NLB, den privaten Kubernetes Ingress Controller (privates Subnetz) und dann die privaten SystemLink Dienste.
- Ausgehendes Internet über NAT: Verwenden Sie NAT-Gateways in öffentlichen Subnetzen, um ausgehenden Internetzugang für private Subnetzressourcen bereitzustellen. Stellen Sie ein NAT Gateway pro Verfügbarkeitszone bereit für eine hohe Verfügbarkeit.
- VPC-Endpunkte: Verwenden Sie VPC-Endpunkte für AWS-Dienste (S3), um Internetverbindungen zu vermeiden und Datenübertragungskosten zu reduzieren.
- Sicherheitsgruppen: Konfigurieren Sie Sicherheitsgruppen, um nur den notwendigen Datenverkehr zwischen Komponenten zuzulassen. Verwenden Sie das Prinzip der kleinsten Berechtigungen.
Hinweise zur Verfügbarkeitszone
Übertragen von SystemLink Enterprise auf mehrere Verfügbarkeitszonen für hohe Verfügbarkeit und Fehlertoleranz:
- Minimale Bereitstellung: Verwenden Sie mindestens zwei Verfügbarkeitszonen mit Subnetzpaaren in jeder Zone.
- EKS-Knotengruppen: Verteilen Sie Worker-Knoten auf Verfügbarkeitszonen.
- Database Multi-AZ: Aktivieren Sie Multi-AZ-Bereitstellungen für RDS PostgreSQL und DocumentDB.
- Load-Balancer-Verteilung: Konfigurieren Sie ALB und NLB für die Verteilung des Datenverkehrs über Subnetze in mehreren Verfügbarkeitszonen.
Verwandte Inhalte
- SystemLink Enterprise in AWS EKS
Amazon Elastic Kubernetes Service (EKS) ist ein verwalteter Kubernetes-Dienst, der die Ausführung von Kubernetes auf AWS vereinfacht, ohne dass ein eigenes Kubernetes-Steuerflugzeug installiert und betrieben werden muss.
- Öffentliche und private Subnetze
Öffentliche und private Subnetze sind grundlegende Netzwerkkonstrukte in Cloud-Umgebungen, die eine Netzwerksegmentierung und Sicherheitsisolierung ermöglichen. Zu verstehen, wie diese Subnetze ordnungsgemäß konfiguriert werden, ist unerlässlich, um SystemLink Enterprise sicher in AWS oder Azure bereitzustellen.
- Azure VNet
Ein Azure Virtual Network (VNet) ist eine isolierte Netzwerkumgebung in Azure.
- Internetorientierte Cluster
Geben Sie hier eine kurze Beschreibung Ihres Konzepts ein (optional).
- Mit dem Unternehmensnetzwerk verbundene Cluster
Eine mit dem Unternehmensnetzwerk verbundene Cluster-Bereitstellung integriert SystemLink in die private Netzwerkinfrastruktur Ihrer Organisation und gewährleistet so sicheren Zugriff sowie eine sichere Integration mit lokalen Systemen.
- Netzwerke und TLS
Hier erfahren Sie, wie Sie Netzwerk und Transport Layer Security (TLS) für SystemLink Enterprise konfigurieren.
- Hinweise zu DNS- und Netzwerksicherheit
SystemLink Enterprise wird in einem Kubernetes-Cluster gehostet. SystemLink Enterprise stellt Verbindungen zu Testsystemen her, um Daten zu Überwachungs- und Analysezwecken zu aggregieren.
- Private Zertifizierungsstellen
Wenn Sie eine private Zertifizierungsstelle (CA) verwenden, müssen Sie SystemLink Enterprise für die Verwendung der CA konfigurieren.
- Layer 7 (Application) Ingress
Layer 7 Ingress bietet HTTPS-Lastverteilung und Routing für Webdienste auf Anwendungsebene. SystemLink Enterprise verwendet Layer 7 Ingress, um HTTP-basierte Dienste über zwei separate Ingress-Endpunkte verfügbar zu machen: einen Endpunkt für die Web-UI und einen Endpunkt für den API-Zugriff.
- Layer 7 Ingress in AWS
In diesem Abschnitt wird die Layer 7 Ingress-Konfiguration mit dem AWS Application Load Balancer (ALB) für SystemLink Enterprise beschrieben, die auf Amazon EKS bereitgestellt werden. Das ALB bietet HTTPS-Lastverteilung und Routing für die SystemLink UI und API Hosts.
- Globale Ingress-Konfiguration von AWS
SystemLink Enterprise konfiguriert separate Ingress-Ressourcen für die UI-Endpunkte und API-Endpunkte. Konfigurieren Sie die folgenden Anmerkungen in Ihrer Helmkonfigurationsdatei.
- Layer 7 Ingress in Azure
Dieser Abschnitt beschreibt die Layer 7 Ingress-Konfiguration mit dem Azure Application Gateway für SystemLink Enterprise, das auf Azure Kubernetes Service (AKS) bereitgestellt wird. Das Application Gateway bietet HTTPS Lastverteilung und Routing für die SystemLink UI und API Hosts.
- Globale Ingress-Konfiguration von Azure
SystemLink Enterprise konfiguriert separate Ingress-Ressourcen für die UI-Endpunkte und API-Endpunkte. Konfigurieren Sie die folgenden Anmerkungen in Ihrer Helmkonfigurationsdatei.
- Layer 7 Ingress in Traefik
SystemLink Enterprise unterstützt das Traefik Hub API Gateway als Layer 7 Ingress Controller. Traefik Hub bietet HTTPS-Lastverteilung und -Routing für die SystemLink UI und API Hosts.
- Layer 4 (TCP) Ingress
Layer 4 Ingress bietet eine Lastverteilung auf TCP-Ebene für Dienste, die direkte TCP-Verbindungen erfordern. SystemLink Enterprise verwendet Layer 4 Ingress für den Salt Master-Dienst.
- Salt-Kommunikation in AWS aktivieren
SystemLink Enterprise verwendet Salt zur Verwaltung von Testsystemen. Salt kommuniziert mit Testsystemen über ein TCP-basiertes Protokoll auf den Ports 4505 und 4506. In diesem Abschnitt wird die Verwendung des AWS Network Load Balancer (NLB) für Layer 4 (TCP) Ingress-Verkehr mit dem Salt Master-Dienst beschrieben.
- Salt-Kommunikation in Azure aktivieren
SystemLink Enterprise verwendet Salt zur Verwaltung von Testsystemen. Salt kommuniziert mit Testsystemen über ein TCP-basiertes Protokoll auf den Ports 4505 und 4506. In diesem Abschnitt wird die Verwendung des Azure Load Balancer für Layer 4 (TCP) mit dem Salt Master-Dienst beschrieben.
- AWS SystemLink Enterprise Kubernetes Architekturdiagramm
- Was ist Amazon VPC?
- Voraussetzungen für Amazon EKS VPC und Subnetz
- SystemLink-Umgebungsarchitektur
SystemLink Enterprise ist eine Anwendung mit serviceorientierter Architektur. Von Kubernetes gehostete Microservices bilden die Architektur. SystemLink Enterprise ist skalierbar, fehlertolerant und hochverfügbar. In der folgenden Tabelle werden die wichtigsten Komponenten der SystemLink Enterprise Architektur zusammengefasst.