Wissensprüfung - Best-Practice-Architektur
Eine FinCorp-Stufe muss sich unter variabler Last automatisch horizontal skalieren. Ein Architekt konfiguriert eine VM Auto Scaling-Gruppe mit einem Skalierungsschwellenwert für das Hochskalieren bei 70 % CPU und einem Schwellenwert für das Runterskalieren bei 50 % CPU, in der Erwartung, dass der 20-Punkte-Bereich die Gruppe stabil hält. Die Plattform lehnt die Richtlinie ab. Welche Regel wurde verletzt, und welches ist das korrekte Designprinzip?
VM Auto Scaling erzwingt eine obligatorische Mindestabstand von 40 Prozentpunkten zwischen den Schwellenwerten für das Runterskalieren und das Hochskalieren. Dieser Totbereich ist die primäre Maßnahme gegen Flapping: Ohne ihn könnte ein verrauschtes Messwertergebnis beide Schwellenwerte in schneller Folge überschreiten und die Gruppe dazu zwingen, sich hochzuskalieren und unmittelbar darauf wieder runterzuskalieren. Ein Abstand von 20 Punkten liegt unter der Untergrenze und wird abgelehnt. Der Dienst unterstützt fünf Metriken (Durchschnitt der CPU-Auslastung sowie eingehende und ausgehende Netzwerk-Bytes und -Pakete), daher ist die Metrikwahl nicht das Problem, und der Schwellenwert für das Hochskalieren liegt korrekt über dem Schwellenwert für das Runterskalieren.
Ein Architekt hat ein funktional vollständiges Design für die regulierte, containerbasierte Verarbeitung von FinCorp erstellt, das auf Managed Kubernetes ausgeführt wird, und wendet nun den Filter für Souveränität und Attestierung an. Die Workload erfordert vertraglich die Abdeckung durch BSI C5. Was zeigt der Filter, und was ist die richtige Schlussfolgerung?
Dies ist der zweite Kompositionsfehler: Eine funktional korrekte Wahl, die außerhalb des erforderlichen Attestierungsbereichs liegt. Der Filter wird zuletzt angewendet, auf ein Design, das bereits funktional vollständig ist, da Compliance die Auswahl einengt, statt sie zu begründen. C5 deckt genau Compute Engine, Cloud Cubes und Object Storage ab. Managed Kubernetes liegt im Bereich von IT-Grundschutz, aber nicht in C5, und die beiden Bereiche sind nicht austauschbar. Eine Workload, die vertraglich C5 erfordert, wird daher auf einen C5-abgedeckten Dienst wie Compute Engine verschoben. Die Wahl war technisch nicht falsch. Sie war falsch im Hinblick auf den Bereichsfilter, und eine bestehende Attestierung legitimiert niemals eine plattformweite Aussage.
In der Referenzarchitektur ist der Anfragepfad bewusst geschichtet: ein öffentlicher Balancer an der Kante und ein privater Balancer vor der Datenschicht. Ein Ingenieur schlägt vor, an beiden Positionen einen einzelnen Layer-4-NLB zu verwenden, um zu standardisieren, und schlägt vor, jeden verwalteten Balancer in einer Network Security Group für die Filterung einzubetten. Warum lehnt das Referenzdesign beide Vorschläge ab?
Die beiden Balancerebenen existieren aus zwei verschiedenen Gründen. Der öffentliche Layer-7-ALB terminiert TLS und routet basierend auf Content, wo Routinglogik wichtig ist; der private Layer-4-NLB lässt TCP schnell durch, wo dies nicht der Fall ist, und lässt das Zertifikat auf dem Backend. Die Standardisierung auf eine Schicht verwirft den Grund, aus dem jede Schicht gewählt wurde. Unabhängig davon akzeptiert weder der verwaltete Balancer eine Network Security Group noch eine IP-Allowlist, daher hat das Anhängen einer NSG an einen verwalteten Balancer keinen Effekt; die Filterung gehört auf die Ziel-NICs, und die Sicherheit der Datenschicht resultiert daraus, dass sie sich in einem privaten LAN befindet, nicht aus einer Balancer-Ebenen-Firewall. DNS steuert neue Verbindungen, ist aber kein Load Balancer und wendet keine NSG an, und Cloud DNS bietet keinen nativen Health-Check-basierten Failover.
Der Abschlussaufbau (Capstone Build) verknüpft die modulbezogenen Komponenten zu einem einzigen VDC. Ein Team provisioniert Ressourcen in dieser Reihenfolge: Es erstellt zuerst den privaten Layer-4 NLB, dann die Server der Daten-Schicht, die er bedienen soll, anschließend ein NAT Gateway, und erwartet, dass private Workloads das Internet erreichen, sobald das NAT Gateway existiert. Welche Bewertung ihrer Reihenfolge ist korrekt?
Ein integrierter Aufbau ist ein Abhängigkeitsgraph, der von unten nach oben aufgelöst wird, und keine Checkliste, die die Plattform neu sortiert. Ein Layer-4 NLB, der auf Ziele zeigt, die noch nicht existieren, hat nichts zum Routen, daher müssen die Server der Daten-Schicht vor der Erstellung des NLB provisioniert werden. Das NAT Gateway erzeugt auch mit einer reservierten öffentlichen IP und einer SNAT-Regel keinen Ausgang, bis der Standard-Route (0.0.0.0/0) des privaten LANs auf es umgeleitet wird; diese Routing-Änderung ist der Schritt, den Teams vergessen, und die Plattform führt sie nicht automatisch durch. Die korrekte Reihenfolge über den gesamten Aufbau hinweg lautet: Netzwerk-Substrat, dann Compute, dann die Daten-Schicht, dann die Balancer, dann die Container-Plattform, dann die Hybrid-Kante.
Der Auditor von FinCorp bittet den Architekten, servicebezogen darzulegen, welche BSI-Anerkennung jede Komponente des deployed Designs abdeckt. Der Architekt muss präzise antworten, anstatt zu behaupten, dass die Plattform zertifiziert ist. Welche Aussage widerspiegelt die korrekte servicebezogene Compliance-Zuordnung?
Compliance auf IONOS CLOUD ist pro Dienst und pro deutschem Rechenzentrumsstandort abgegrenzt, niemals plattformweit. Daher muss die Antwort den Dienst, die Qualifikation und den Standort benennen, anstatt eine pauschale Zertifizierung zu behaupten. C5 (eine Type 1 Attestation) deckt genau Compute Engine, Cloud Cubes und Object Storage ab. IT-Grundschutz (ein ISO 27001 Zertifikat) deckt genau Compute Engine, Object Storage, Backup und Managed Kubernetes ab. Die beiden Bereiche weichen ab: Cubes sind in C5, aber nicht in IT-Grundschutz, während Managed Kubernetes und Backup in IT-Grundschutz, aber nicht in C5 sind. Die relationalen und Cache Engines sowie die verwalteten Load Balancer fallen unter keines der beiden, und der regulierte dedizierte VMware Kern ist eigenen Attestationen zugeordnet, nicht der plattformweiten C5.