Einheit 1.2: Die kanonische geschichtete Architektur
Einführung
Es gibt eine Architekturstruktur, die in nahezu jedem regulierten Unternehmensdeployment auf IONOS CLOUD wiederkehrt, und es lohnt sich, sie als Standard zu erlernen, bevor man ein einzelnes Produkt studiert. Die darin enthaltene Entscheidung betrifft, wo Traffic den Eingang finden darf, wie weit er sich bewegen darf und was vollständig für das Internet unerreichbar bleibt. Diese Grenze auf Topologieebene richtig zu setzen, ist weitaus kostengünstiger als sie nachträglich einzuführen, da auf IONOS CLOUD die Netzwerkebene, in der eine Ressource platziert ist, das primäre Kriterium ist, das bestimmt, ob sie exponiert ist. Diese Einheit zeigt die kanonische Struktur und erklärt die zugrunde liegende Logik, damit die Produkte der einzelnen Ebenen in den Modulen 3 bis 6 jeweils einen eindeutigen Platz haben.
1. Die kanonische Struktur: Öffentliches L7, zustandslose Rechenleistung, privates L4, private Daten
Die Struktur lässt sich von oben nach unten als eine Sequenz schwindenden Vertrauens lesen.
Am Rand befindet sich ein öffentlicher Layer-7-Load Balancer. Der Managed Application Load Balancer (ALB) verteilt den eingehenden Traffic auf Anwendungsebene an Ziele basierend auf benutzerdefinierten Richtlinien und leitet anhand von Inhalten wie Host und Pfad weiter. Er ist das einzige Komponente, die dem Internet gegenüberliegen soll, und an ihm wird TLS beendet. Da er anhand von Anwendungsinhalten leitet, ist er auch der Ort, an dem anwendungsbezogene Anliegen (Pfadbasierte Routen, hostbasierte Routen) zum Ausdruck kommen.
Hinter ihm befindet sich die zustandslose Rechenstrecke: die Anwendungsserver. Diese halten keinen eigenen dauerhaften Zustand. Das ist eine bewusste Eigenschaft, kein Zufall, da es ermöglicht, die Strecke frei zu skalieren, zu ersetzen oder umzuleiten. Alles, was persistiert werden muss, wird nach unten verschoben.
Zwischen der Anwendungsebene und den von ihr abhängigen Daten befindet sich ein privater Layer-4-Load Balancer. Der Managed Network Load Balancer (NLB) arbeitet auf TCP/IP Layer 4; er verteilt jeden TCP-basierten Traffic, und seine Regeln und Health Checks sind strikt Layer 4. Privat platziert, verteilt er Verbindungen über die Knoten der Datenschicht hinweg, ohne jemals vom Internet erreichbar zu sein, und er beendet kein TLS, sodass eine Ende-zu-Ende-Verschlüsselung direkt bis zum Backend durchlaufen kann.
Unten befindet sich die ausschließlich private Datenschicht: verwaltete Datenbanken, der Cache, geteilte Speicherung. Diese werden nur über private LANs über den internen Balancer erreicht. Sie haben keinerlei öffentliche Schnittstelle.
Die Zusammensetzung, öffentliches L7 zu zustandsloser Rechenleistung zu privatem L4 zu privaten Daten, ist der idiomatische Ausdruck der Plattform für Verteidigung in der Tiefe. Jeder Schritt nach unten entfernt Erreichbarkeit: Das Internet kann mit dem ALB kommunizieren, der ALB kann mit der Anwendungsebene kommunizieren, die Anwendungsebene kann mit der Datenschicht über den NLB kommunizieren, und die Datenschicht kann mit niemandem unangemeldet kommunizieren.
Für FinCorp ist dies die Hülle, in die ihre regulierte Arbeitslast einsetzt. Der öffentliche ALB trägt kundenseitiges HTTPS und beendet TLS am EU-Rand; die zustandslosen Anwendungsserver führen die Geschäftslogik aus und externalisieren ihren Zustand; der private NLB steht vor dem relationalen Cluster und dem Cache; und die Datenbank selbst wird nie exponiert. Die Compliance-Story, die in Einheit 1.4 entwickelt wird, ist wesentlich leichter zu erfüllen, wenn die Datenschicht architektonisch nicht in der Lage ist, eine eingehende Verbindung von außerhalb des VDC anzunehmen.
2. Warum Private-by-Default und wo alles andere andockt
Das Layout wurde nicht aus ästhetischen Gründen gewählt; es ergibt sich aus dem tatsächlichen Netzwerkverhalten von IONOS CLOUD und der Art, wie dessen Schutzmechanismen greifen.
Ein LAN innerhalb eines VDC ist privat, bis es explizit mit dem Internet verbunden wird. Die Erreichbarkeit ist etwas, das man hinzufügt, nicht etwas, das man entfernt. Genau diese Eigenschaft macht Private-by-Default zum Weg des geringsten Widerstands: Bleibt eine Schicht auf einem privaten LAN, ist sie bereits unerreichbar. Die Argumentation verstärkt sich dadurch, wo die Sicherheitskontrollen von IONOS CLOUD greifen. Firewalls auf NIC-Ebene und Network Security Groups sind nur auf Server-NICs auf VDC-Ebene gebunden; sie gelten nicht für den Managed ALB oder NLB, noch für die Cluster-Abstraktion von Managed Kubernetes. Da die verwalteten Load Balancer nicht in eine Security Group eingebettet werden können, kann man sich nicht auf eine Firewall verlassen, um eine Datenbank auf einem öffentlichen Pfad auszugleichen. Die Topologie selbst, also was auf einem privaten LAN platziert ist, muss die Isolation sicherstellen. Segmentierung ist daher die tragende Kontrolle, und die Dreischicht-Aufteilung (öffentlicher Rand, private Anwendung, private Daten) ist das Minimum, das sie sauber ausdrückt.
Die gleiche Struktur nimmt den Rest der Plattform auf, ohne sich zu verändern:
- Container. Ein Node-Pool von Managed Kubernetes dockt an die LANs an wie jede andere Rechenressource und übernimmt die Rolle der zustandslosen Anwendungsschicht. Ein Manifest provisioniert keinen IONOS CLOUD Load Balancer automatisch; der öffentliche ALB und ein eventuell vorhandener privater NLB werden separat provisioniert und auf das Cluster gerichtet, sodass das Cluster in die bestehende Struktur passt, statt sie zu ersetzen.
- Dedizierte VMware (Private Cloud). Ein regulierter VMware-Workload läuft auf dem dedizierten SDDC und verbindet sich über Hybrid-Konnektivität mit dem Standard-Compute-Umfeld. Er besetzt die Compute-Schicht für Workloads, die Single-Tenant-Isolation benötigen, während der elastische Rand auf Standard-Compute verbleibt.
- KI-Dienste. Der verwaltete AI Model Hub ist eine vollständig verwaltete, öffentlich erreichbare Inferenz-API (seine OpenAI-kompatiblen und nativen Endpunkte sind internetorientiert, nicht nur für private LANs); die Anwendungsschicht ruft sie über einen ausgehenden Pfad auf, auf dieselbe Weise wie jede externe SaaS-API, während die Datensätze, auf die sie zugreift, weiterhin in Object Storage und einer verwalteten Datenbank auf der privaten Datenschicht unterhalb der Anwendungsschicht liegen können.
- Hybrid-Konnektivität. VPN- und NAT-Gateways sowie private Interconnects docken am Rand und am Egress-Pfad an und erweitern dasselbe private Gefüge auf On-Premises-Standorte, statt neue Löcher durch die Schichten zu schlagen.
Jedes spätere Modul füllt eine Bandbreite dieses Diagramms aus: Networking baut den Rand und die beiden Load Balancer, Compute baut die Anwendungsschicht, Data baut die unterste Schicht, Container und KI docken darüber und daneben an. Die Form bleibt gleich; der Inhalt ändert sich.
Entscheidungszusammenfassung
| Ebene | IONOS CLOUD-Komponente | Erreichbarkeit | Maßgebliche Regel |
|---|---|---|---|
| Öffentliche Kante | Verwalteter ALB (Layer 7) | Internetzugriff | Einziger beabsichtigter öffentlicher Einstiegspunkt; beendet TLS; leitet auf Basis des Inhalts weiter. |
| Anwendung | Zustandslose Compute-Ressource oder Kubernetes-Knotenpool | Privates LAN, erreichbar über den ALB | Hält keinen dauerhaften Zustand, sodass sie frei skaliert oder bei Ausfällen umgeleitet werden kann. |
| Internes Lastverteilung | Verwalteter NLB (Layer 4) | Nur privat | TCP-Durchleitung, keine TLS-Beendigung; niemals internetzugänglich. |
| Daten | Verwaltete Datenbanken, Cache, gemeinsamer Speicher | Nur privat, keine öffentliche Schnittstelle | Erreichbar nur über den internen Lastverteiler über private LANs. |
Verwenden Sie standardmäßig diese Struktur und begründen Sie jede Abweichung. Die Segmentierung, nicht eine Regelmenge, sichert die Datenschicht ab. Platzieren Sie eine Ebene daher nur auf einem öffentlichen LAN, wenn sie dem Internet gegenüberwirken soll.
Zusammenfassung
Die kanonische IONOS CLOUD-Unternehmensarchitektur reduziert das Vertrauen in vier Schritten: ein öffentlicher Layer-7-ALB an der Kante, eine zustandslose Berechnungsebene dahinter, ein privater Layer-4-NLB vor den Daten und eine ausschließlich private Datenebene am unteren Ende. Sie ist standardmäßig privat, da LANs bis zur Verbindung privat bleiben und die verwalteten Load Balancer nicht in einer Security Group kapselt werden können, wodurch die Topologie die eigentliche Isolationssteuerung darstellt. Container, dedizierte VMware, KI und Hybridverbindungen werden alle an diese Struktur angeschlossen, ohne sie zu verändern. Aus diesem Grund füllt jedes spätere Modul lediglich eine Ebene des gleichen Diagramms aus.
Wichtige Punkte:
- Die Standardstruktur lautet: öffentlicher L7-ALB zu zustandsloser Berechnungsebene zu privatem L4-NLB zu ausschließlich privater Datenebene, wobei jeder Abwärtsschritt die Erreichbarkeit reduziert.
- Die Standardprivatheit gilt, da ein LAN bis zu einer expliziten Verbindung mit dem Internet privat bleibt, sodass Offenlegung etwas ist, das bewusst hinzugefügt wird.
- NIC-Firewalls und NSGs sind nur an Server-NICs gebunden, nicht an den verwalteten ALB/NLB oder die Kubernetes-Cluster-Abstraktion. Daher ist die Segmentierung durch Topologie die tragende Steuerung.
- Container, dedizierte VMware, KI-Dienste und Hybrid-Konnektivität werden an dieselbe Struktur angeschlossen, statt sie zu verändern; spätere Module füllen jeweils eine Ebene aus.