NGINXaaS for Azure ermöglicht Unternehmen die sichere Bereitstellung leistungsstarker Anwendungen in der Cloud. Der vollständig verwaltete, auf NGINX Plus basierende Dienst ist seit Januar 2023 allgemein verfügbar. Seit seiner Einführung entwickeln wir NGINXaaS for Azure kontinuierlich weiter und ergänzen den Dienst um neue Funktionen.
In diesem Blog stellen wir einige der neuesten Leistungs- und Sicherheitsfunktionen vor, mit denen Sie von weiteren Vorteilen von NGINX Plus profitieren können, ohne eigene NGINX Plus-Instanzen bereitstellen, warten und aktualisieren zu müssen. Allgemeine Informationen zu NGINXaaS for Azure und seinen umfassenden Funktionen finden Sie unter „Cloud-Migrationen mit F5 NGINXaaS for Azure vereinfachen und beschleunigen“.
Abbildung 1: Überblick über NGINXaaS for Azure
Absicherung des Upstream-Datenverkehrs mit mTLS
Während Reverse-Proxys SSL/TLS benötigen, um den clientseitigen Datenverkehr im öffentlichen Internet zu verschlüsseln, ist Mutual TLS (mTLS) für die Authentifizierung und die Gewährleistung der Vertraulichkeit auf Serverseite unerlässlich. Mit dem Übergang zu Zero Trust muss außerdem überprüft werden, dass der Datenverkehr zu Upstream-Servern weder verändert noch abgefangen wurde.
Abbildung 2: mTLS mit NGINXaaS
NGINXaaS for Azure unterstützt jetzt NGINX-Direktiven, um Upstream-Datenverkehr abzusichern und dafür SSL/TLS-Zertifikate zu verwenden. Mit diesen Direktiven können Sie den Upstream-Datenverkehr nicht nur über mTLS verschlüsseln, sondern auch überprüfen, ob die Upstream-Server ein gültiges Zertifikat einer vertrauenswürdigen Zertifizierungsstelle vorlegen.
Zertifikatsrotation
Ein wesentlicher Aspekt (im wahrsten Sinne des Wortes) bei der Verwendung von TLS-Zertifikaten mit NGINXaaS for Azure ist die sichere Verwaltung dieser Zertifikate mithilfe von Azure Key Vault (AKV). AKV schützt sensibles kryptografisches Material und ermöglicht NGINXaaS for Azure die Verwendung dieser Zertifikate, während eine versehentliche oder beabsichtigte Offenlegung des Schlüsselmaterials über das Azure-Portal verhindert wird.
Abbildung 3: Zertifikatsrotation mit Azure Key Vault
NGINXaaS for Azure kann jetzt Zertifikate automatisch rotieren und sie in Ihren NGINX-Bereitstellungen austauschen, sobald sie in AKV aktualisiert werden. Neue Zertifikatversionen werden innerhalb von vier Stunden in Ihre Bereitstellungen übernommen.
HTTP/2-Proxy (und zusätzliche Protokolloptionen)
Schließen Sie die Augen und denken Sie zurück an das Jahr 1997. Wir sangen „Tubthumping“ von Chumbawamba mit, trugen unsere JNCO-Jeans (oder Modrobes, falls hier Landsleute aus Kanada mitlesen), und HTTP/1.1 wurde veröffentlicht. Damals gingen die meisten Endnutzer über ein Einwahlmodem ins Internet, Webseiten enthielten nur wenige Dutzend Elemente, und für die Nutzererfahrung war die Bandbreite ein weitaus wichtigeres Thema als die Latenz.
Fünfundzwanzig Jahre später nutzt ein beträchtlicher Teil der Webanwendungen immer noch HTTP/1.1 zur Bereitstellung von Inhalten. Das kann problematisch sein. HTTP/1.1 funktioniert zwar nach wie vor, ermöglicht jedoch pro Verbindung jeweils nur die Übertragung einer einzigen Ressource. Moderne Webanwendungen hingegen senden mitunter Hunderte von Anfragen, um eine Benutzeroberfläche zu aktualisieren.
Obwohl den meisten Nutzern heute erheblich mehr Bandbreite zur Verfügung steht, hat sich die Geschwindigkeit der Datenübertragung (begrenzt durch die fundamentale Lichtgeschwindigkeit) nicht im gleichen Maße erhöht. Daher kann sich die kumulierte Latenz all dieser Anfragen erheblich auf die wahrgenommene Leistung Ihrer Anwendung auswirken. Moderne Browser öffnen mehrere TCP-Verbindungen zum selben Server, doch die Anfragen über diese Verbindungen werden weiterhin nacheinander verarbeitet. Das bedeutet, dass eine langsame Ressource alle nachfolgenden Ressourcen verzögern kann.
Sehen Sie sich die Startseite von F5 an, wenn sie ausschließlich über HTTP/1.1 geladen wird:
Abbildung 4: Zugriff auf F5.com über HTTP/1.1
Sehen Sie all diese grauen Balken? Das ist wertvolle Zeit, die der Browser verschwendet, während er auf den Aufbau einer Sitzung wartet, durch eine einzelne langsame Ressource blockiert wird oder darauf wartet, dass eine neue TCP-Verbindung verfügbar wird.
Aktivieren wir HTTP/2 und versuchen es erneut:
Abbildung 5: Dieselbe Anfrage, jedoch mit HTTP/2
Viel besser. Es gibt zwar immer noch einige langsame Ressourcen, aber sie halten andere Anfragen nicht auf, und es geht deutlich weniger Zeit durch Warteschlangenverzögerungen verloren. HTTP/2 behält die Semantik bei, die Webbrowser und Server bereits von HTTP/1.1 kennen, und ergänzt sie um neue Funktionen, die einige Ursachen für eine als schlecht wahrgenommene Anwendungsleistung beheben (z. B. die Priorisierung von Anfragen, die Komprimierung von Headern und das Multiplexing von Anfragen).
Angesichts dieses deutlichen Unterschieds unterstützt NGINXaaS for Azure jetzt die Bereitstellung von Clientanfragen über HTTP/2. Clientseitige Verbindungen werden eher durch längere Roundtrip-Zeiten beeinträchtigt. Daher können Sie diesen Datenverkehr mit den latenzreduzierenden Vorteilen von HTTP/2 bereitstellen, ohne Änderungen an Ihren Upstream-Servern vorzunehmen.
Auch wenn manche in der Webanwendungsbranche es vielleicht nicht wahrhaben wollen, ist uns durchaus bewusst, dass Ihnen neben HTTP noch weitere Protokolloptionen zur Verfügung stehen. Aus diesem Grund ist nun auch das NGINX-gRPC-Modul in NGINXaaS for Azure verfügbar. Es bietet mehrere Konfigurationsanweisungen für die Verarbeitung von gRPC-Datenverkehr, darunter Fehlerabfangung, Header-Manipulation und mehr.
Für Nicht-HTTP-/gRPC-Datenverkehr ist das Stream-Modul jetzt in NGINXaaS for Azure verfügbar. Dieses Modul unterstützt Proxying und Lastverteilung für TCP- und UDP-Datenverkehr.
Unterstützung für Lastverteilung auf Layer 4 und Layer 7
NGINXaaS for Azure kann jetzt sowohl als cloudnativer Layer-4-TCP/UDP- als auch als Layer-7-HTTP/HTTP-Load-Balancer fungieren. Warum ist das wichtig? Anstatt zwei verschiedene Dienste oder Load-Balancer bereitzustellen, können Sie mit NGINXaaS for Azure einen einzigen Load-Balancer bereitstellen und so konfigurieren, dass er gleichzeitig auf beiden Schichten arbeitet. Dadurch vereinfachen Sie Ihre Cloud-Architektur und senken Ihre Kosten.
Weitere Informationen zur Konfiguration finden Sie hier.
Höhere Kapazität (bis zu 160 NCUs)
NGINXaaS for Azure ist ein verbrauchsbasierter Dienst, dessen Nutzung stündlich erfasst und monatlich in NGINX Capacity Units (NCUs) abgerechnet wird. Vor Kurzem haben wir diese Bereitstellungskapazität von 80 NCUs auf 160 NCUs verdoppelt. Kunden können ein kleineres System mit 20 NCUs bereitstellen und es bei steigender Auslastung auf bis zu 160 NCUs skalieren. Darüber hinaus haben Kunden die Möglichkeit, von Anfang an bis zu 160 NCUs bereitzustellen.
Hinzufügen von NGINX Plus-Direktiven
Um eine einfache Lift-and-Shift-Konfiguration beim Wechsel von einer lokalen Umgebung zu einem vollständig verwalteten Cloud-Angebot zu ermöglichen, haben wir zahlreiche NGINX Plus-Direktiven hinzugefügt. Eine Übersicht über alle von uns in NGINXaaS for Azure unterstützten NGINX Plus-Direktiven finden Sie hier.
Legen Sie noch heute los
Wir verbessern und erweitern kontinuierlich die Möglichkeiten, wie Sie Technologien von NGINX und F5 nutzen können, um jede Anwendung und API überall abzusichern, bereitzustellen und zu optimieren. Dank der zuvor genannten und weiterer neuer Funktionen von NGINXaaS for Azure können mehr Azure-Benutzer zahlreiche Anwendungs- und API-Probleme mit der Leistungsfähigkeit von NGINX Plus lösen, ohne den Aufwand für die Verwaltung einer zusätzlichen VM- oder Container-Infrastruktur.
Wenn Sie mehr über NGINXaaS for Azure erfahren möchten, empfehlen wir Ihnen, die Produktdokumentation zu lesen. Wenn Sie NGINXaaS for Azure ausprobieren möchten, besuchen Sie bitte den Azure Marketplace oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen.
Über den Autor
Ähnliche Blogbeiträge
Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln
Beim NGINX Sprint 2022 besinnen wir uns auf unsere Open-Source-Wurzeln. Erfahren Sie mehr über die Initiativen, die wir im kommenden Jahr verfolgen, und teilen Sie uns mit, was Sie sich wünschen.
Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen
Ein Ingress-Controller kann eines der leistungsstärksten Tools in Ihrem Kubernetes-Stack sein. Erfahren Sie, wie Sie Ihre Ingress-Anforderungen ermitteln, um die beste Option auszuwählen.
Bereitstellung des NGINX Ingress Controllers auf Amazon EKS: So haben wir getestet
Wir haben kürzlich den Lösungsleitfaden zum NGINX Ingress Controller um Empfehlungen zur Dimensionierung für Amazon Elastic Kubernetes Service (EKS) ergänzt. In diesem Blogbeitrag erläutern wir, wie wir diese Empfehlungen erarbeitet haben, und stellen Ihnen alle Informationen zur Verfügung, die Sie benötigen, um selbst ähnliche Tests durchzuführen.
Protokollierung des Datenverkehrs zwischen NGINX und Upstream-Servern bei CDN77
Bei der Fehlersuche bei Datenverkehrsproblemen zwischen NGINX und Upstream-Servern konnte CDN77 die benötigten Daten nur aus dem Fehlerprotokoll mit aktivierter Debug-Ausgabe beziehen, was die Leistung beeinträchtigt und riesige Dateien erzeugt. Daher entwickelte das Team ein neues benutzerdefiniertes Modul, das ausschließlich die benötigten Daten protokolliert.
Ankündigung von NGINX Plus R16
NGINX Plus R16 ist eine einheitliche, elastische Ingress- und Egress-Schicht für Anwendungen, die die Funktionen eines Load Balancers, API-Gateways und einer WAF vereint und neue Features wie clusterfähige Ratenbegrenzung, Schlüssel-Wert-Speicher, „Random with Two Choices“, verbessertes UDP-Load-Balancing und vieles mehr bietet.
5 Gründe für den Umstieg auf softwarebasiertes Load Balancing
Entdecken Sie fünf Gründe für den Wechsel zu einem softwarebasierten Load Balancer wie NGINX Plus, darunter Kosteneinsparungen, die Einführung von DevOps und eine einheitliche Lösung für alle Umgebungen.