WAF-Muster auf reale Architekturen anwenden

Die Anwendung von WAF-Mustern auf reale Architekturen ist keine theoretische Übung – sie erfordert, jede Designentscheidung anhand der fünf Säulen zu bewerten und fundierte Abwägungen zu treffen. Ein guter Ausgangspunkt ist das Architekturdiagramm: Verfolgen Sie den Weg einer Benutzeranforderung durch jede Komponente und fragen Sie sich bei jedem Übergang, was passiert, wenn diese Komponente ausfällt, welche Kosten entstehen und wie sie abgesichert ist.

Betrachten Sie eine traditionelle monolithische Webanwendung: eine einzelne VM, auf der Webserver und Datenbank gemeinsam hinter einer öffentlichen IP-Adresse ausgeführt werden. Gemessen an den WAF-Säulen schneidet sie bei allen fünf schlecht ab: keine Redundanz (Zuverlässigkeit), Datenbank auf demselben Host wie die Webschicht (Sicherheit), ständig aktive VM unabhängig vom Datenverkehr (Kosten), kein CI/CD (herausragende Betriebsabläufe) und ausschließlich vertikale Skalierung (Leistungseffizienz).

Um das Säule Zuverlässigkeit zu erfüllen, verteilen Sie die Webebene auf mehrere VMs in unterschiedlichen Verfügbarkeitszonen, sichern Sie die Datenbank mit Geo-Replikation in eine sekundäre Region ab und schalten Sie einen Azure Load Balancer davor. Dadurch wird der Single Point of Failure beseitigt, und die Anwendung kann einen Ausfall einer Zone oder Region ohne manuellen Eingriff überstehen.

Für die Säule Sicherheit trennen Sie Webebene und Datenbank in unterschiedliche Subnetze und verwenden NSG-Regeln, die nur Verbindungen von der Webebene zum Datenbankport zulassen. Speichern Sie die Verbindungszeichenfolge der Datenbank in Azure Key Vault und verwenden Sie für die Web-App eine verwaltete Identität, um sie zur Laufzeit abzurufen. Dadurch werden fest codierte Anmeldedaten aus Anwendungscode und Konfigurationsdateien entfernt.

Für die Kostenoptimierung ersetzen Sie ständig laufende VMs durch ein Virtual Machine Scale Set, das während Nebenzeiten verkleinert wird. Prüfen Sie bei der Datenbank, ob ein verwalteter PaaS-Dienst wie Azure SQL Database mit einer passenden DTU-Ebene kostengünstiger ist als eine vollständige VM mit SQL Server. Kaufen Sie Reserved Instances für jede Basiskapazität, die Sie 12 Monate im Voraus zuverlässig vorhersagen können.

Verbessern Sie die Operational Excellence, indem Sie die gesamte Infrastruktur als Bicep- oder ARM-Vorlagen definieren und in der Versionsverwaltung speichern. Erstellen Sie in Azure Pipelines oder GitHub Actions eine CI/CD-Pipeline, die Änderungen an der Infrastruktur und am Anwendungscode automatisch bereitstellt. Fügen Sie vor der Bereitstellung in der Produktion Bereitstellungs-Gates hinzu – automatisierte Smoke-Tests und eine manuelle Genehmigung.

Führen Sie für die Leistungseffizienz Azure Cache for Redis vor der Datenbank ein, um häufig gelesene Abfragen zwischenzuspeichern und die Datenbanklast zu reduzieren. Stellen Sie statische Ressourcen wie Bilder, CSS und JavaScript über Azure CDN bereit, damit sie weltweit von Edge-Knoten in der Nähe der Benutzer ausgeliefert werden. Führen Sie nach jeder Änderung Lasttests durch, um zu bestätigen, dass die Verbesserungen messbar sind.

Jede architektonische Änderung bringt einen Kompromiss mit sich. Eine Architektur mit mehreren Zonen verbessert beispielsweise die Zuverlässigkeit, erhöht aber die Kosten (zwei Zonen = zwei VMs). Das Hinzufügen eines Redis-Caches verbessert die Leistung, erhöht jedoch die betriebliche Komplexität (ein weiterer Dienst, der überwacht und gewartet werden muss). Eine gute Architekturdokumentation hält diese Kompromisse ausdrücklich fest, damit zukünftige Architektinnen und Architekten verstehen, warum Entscheidungen getroffen wurden.

Versuchen Sie nicht, durch eine einzige Neugestaltung Perfektion zu erreichen – dieser Ansatz ist teuer, riskant und langsam. Übernehmen Sie stattdessen einen iterativen Verbesserungszyklus: Führen Sie eine Well-Architected Review durch, ermitteln Sie die drei wirkungsvollsten Probleme, beheben Sie sie, messen Sie die Verbesserung und wiederholen Sie den Vorgang. Dieser Ansatz stimmt architektonische Verbesserungen auf die agile Bereitstellung ab und macht den Fortschritt für Stakeholder in jedem Sprint sichtbar.

Microsoft veröffentlicht Referenzarchitekturen für gängige Workload-Muster im Azure Architecture Center. Dazu gehören Architekturen für Webanwendungen, Microservices unter AKS, Datenanalysepipelines und viele weitere. Jede Referenzarchitektur wurde bereits anhand der WAF-Säulen bewertet und enthält Hinweise zu den Kompromissen, die für das jeweilige Muster eingegangen wurden.

Verwenden Sie Architecture Decision Records (ADRs), um wichtige architektonische Entscheidungen, den Kontext ihrer Entstehung, die berücksichtigten Alternativen und die Auswirkungen auf die WAF-Säulen zu dokumentieren. In der Versionsverwaltung neben der Codebasis gespeicherte ADRs schaffen eine prüfbare Historie und helfen neuen Teammitgliedern zu verstehen, warum die Architektur so aufgebaut ist.

Testen Sie Ihr Verständnis der Konzepte von Microsoft Azure Fundamentals (AZ-900) aus dieser Lektion.

In dieser Lektion haben Sie gelernt: WAF-Muster werden angewendet, indem jede architektonische Entscheidung anhand aller fünf Säulen bewertet wird; Verbesserungen können iterativ umgesetzt werden, indem mit den Problemen mit der größten Wirkung begonnen wird; und Kompromisse müssen dokumentiert werden, damit zukünftige Architektinnen und Architekten die Entscheidungsgründe verstehen. Als Nächstes beschäftigen wir uns mit Azure-SLAs und der Berechnung zusammengesetzter SLAs für Architekturen mit mehreren Diensten.