F5 und AWS: Erweiterte Application in der Cloud

Amazon Web Services (AWS) hat sich zum größten und am weitesten verbreiteten Anbieter von Public Cloud Infrastructure-as-a-Service (IaaS) entwickelt. Organisationen können jetzt ganze Application erstellen, testen und bereitstellen, ohne eine lokale Infrastruktur kaufen oder neu konfigurieren zu müssen. Applications können von erweiterten Application wie einer Web Application Firewall (WAF), SSL-Beschleunigung, inhaltsbasiertem Routing, Lastausgleich, DDoS-Minderung, Identitäts- und Zugriffsverwaltung sowie Protokollflexibilität profitieren, die diese wichtigen Applications schneller, intelligenter und sicherer machen. Bei Cloud-nativen AWS-Bereitstellungen ermöglichen F5-Lösungen eine einfache und unkomplizierte Bereitstellung dieser Application in AWS-Cloud-Umgebungen.

Als IaaS-Anbieter bietet Amazon Web Services (AWS) eine gemietete Recheninfrastruktur an, die für die Entwicklung von Applications ausreicht. Ohne Investitionen oder Wartungskosten kann eine vollständige Application entwickelt und bereitgestellt werden. AWS stellt nicht nur eine Recheninfrastruktur wie vor Ort bereit, sondern liefert auch Application , skaliert die Infrastruktur automatisch und hostet Applications an vielen Standorten. Aufgrund dieser zusätzlichen Funktionen unterscheiden sich die Best Practices für AWS von den Best Practices für ein herkömmliches Rechenzentrum. Um die Unterschiede zwischen AWS und einem herkömmlichen Rechenzentrum besser zu verstehen, ist es wichtig zu wissen, wie AWS seine Dienste bereitstellt.

Um den größtmöglichen Nutzen aus AWS zu ziehen, werfen wir einen Blick auf einige wichtige Merkmale des IaaS-Angebots, etwa geografische Verteilung, Recheninstanzen, Vernetzung und Speicherkonzepte.

Um AWS zu verstehen, beginnt man mit einer physischen Beschreibung der Ressourcenverteilung. Auf der höchsten Ebene verfügt AWS über mehrere Regionen, die jeweils ein großes geografisches Gebiet abdecken, beispielsweise den Osten der USA. Jede geografische Region enthält mehrere Verfügbarkeitszonen. Die Zonen heißen so, weil sie so konzipiert sind, dass sie voneinander vor Ausfällen isoliert sind. Ein Fehler in einer Verfügbarkeitszone (AZ) hat keine Auswirkung auf eine andere AZ innerhalb einer Region. Während jede AZ isoliert ist, sind AZs innerhalb einer Region über Netzwerkverbindungen mit geringer Latenz verbunden. Aus Verfügbarkeitsgründen gibt es Entwurfsmuster für redundante Funktionen über mehrere AZs innerhalb einer Region hinweg.

Compute-Instanzen beginnen als Software-Disk-Image, bekannt als Amazon Machine Image (AMI). Jedes AMI ist unveränderlich, d. h. es kann vom Computer, der es verwendet, nur gelesen werden. Durch das Booten einer Compute-Instanz über ein AMI wird eine laufende virtuelle Maschine in der Cloud erstellt. Die virtuellen Hardwareeigenschaften der Compute-Instanz können variieren, beispielsweise die Anzahl der für die Instanz verfügbaren CPUs und des RAM.

Jede Compute-Instanz existiert innerhalb einer Virtual Private Cloud (VPC), die in etwa einem LAN in der physischen Welt entspricht. Jede VPC ist logisch getrennt. Eine VPC kann aus mehreren Subnetzen mit implizitem Routing zwischen den Subnetzen bestehen. Öffentliche Subnetze können vom Internet aus geroutet werden, während private Subnetze nur intern verfügbar sind. Um eine vollständige Application bereitzustellen, werden eine oder mehrere Compute-Instanzen in einer VPC bereitgestellt. Die Kommunikation zwischen VPCs kann stattfinden, wenn einer Compute-Instanz oder einem Load Balancer ein DNS-Eintrag zugewiesen ist.

Wie oben erwähnt, ist jedes AMI gegenüber der Instanz, die es verwendet, unveränderlich. Für die dauerhafte Speicherung bietet AWS viele Lösungen an, vor allem Simple Storage Service (S3) und Elastic Block Storage (EBS). S3 ist ein Objektspeicherdienst, bei dem ein Objekt nach Namen gespeichert und abgerufen werden kann. Die Objektgröße kann zwischen null Byte und 5 TB liegen. Tatsächlich ist jedes AMI implizit ein S3-Objekt. Objekte können nicht geändert, sondern nur erstellt und gelöscht werden, weshalb sie sich ideal für relativ statische Inhalte wie Fotos oder Bilder virtuelle Maschine eignen.

EBS bietet Speicher, der herkömmlichem Speicher ähnlicher ist. Eine an EBS angeschlossene Compute-Instanz betrachtet EBS als herkömmliche Festplatte. An ein EBS-Volume kann jeweils nur eine laufende Instanz angehängt werden. EBS kann daher nicht für gemeinsam genutzten Speicher verwendet werden.

Neben der Bereitstellung wichtiger Infrastrukturkomponenten bietet AWS zusätzliche Dienste, die eine Skalierung von Application ermöglichen. Da AWS Infrastrukturressourcen schnell bereitstellen kann, hat Amazon Lösungen entwickelt, die eine automatische Skalierung und Lastverteilung dieser Ressourcen ermöglichen.

AWS bietet einen Elastic Load Balancing (ELB)-Dienst. Ursprünglich bezog sich ELB auf einen einfachen Lastenausgleich auf Ebene 4, der den Datenverkehr auf mehrere intakte Knoten in einem Pool verteilte. Der Pool könnte sich über mehrere Verfügbarkeitszonen erstrecken und so im Falle eines Ausfalls in einer Verfügbarkeitszone eine automatische Redundanz schaffen. Dieser Load Balancer stellt zwar einige grundlegende Funktionen der Netzwerkschicht 7 bereit, arbeitet jedoch hauptsächlich auf Schicht 4 und leitet den TCP-Verkehr einfach im Round-Robin-Verfahren an die Knoten im Pool weiter. Durch Integritätsprüfungen wird ermittelt, welche Knoten verfügbar und somit Kandidaten für den Datenverkehr sind. AWS bezeichnet diesen ersten Load Balancer jetzt als Classic Load Balancer, um ihn vom neuen Application Load Balancer (ALB) zu unterscheiden.

Da AWS über Standby-Kapazitäten verfügt, kann es die Möglichkeit bieten, Knoten innerhalb eines Pools zu skalieren. Der AWS CloudWatch-Dienst überwacht die Leistungsmetriken jedes Knotens innerhalb eines Pools. Wenn vordefinierte Schwellenwerte überschritten werden, z. B. eine CPU-Auslastung von über 60 % für 5 Minuten, wird ein weiterer Knoten bereitgestellt. Umgekehrt wird ein Knoten entfernt, wenn eine untere Schwelle überschritten wird. Der Designer kann die maximale und minimale Anzahl von Knoten in einem Pool und die Schwellenwerte bestimmen, die die Knoteninstanzierung oder Knotenentfernung auslösen. Durch die Verwendung der automatischen Skalierung hinter einem Lastenausgleich kann der Knotenpool je nach Last nach Bedarf erweitert oder verkleinert werden.

Applications verarbeiten zwar Geschäftsregeln und -logik, ihnen fehlt jedoch häufig die erforderliche Absicherung für die Bereitstellung, Verwaltung und den Betrieb in großem Maßstab in der Produktion. Mit den Lösungen von F5 können Sie Applications schneller, intelligenter und sicherer ausführen, indem Sie die in der folgenden Tabelle aufgeführten erweiterten Application bereitstellen.

Erweiterte Application von F5

Überwachung auf Anwendungsebene

• Erweiterte Application (mithilfe eines mehrstufigen Monitors)
• Mehrstufige Integritätsprüfungen (z. B. Überprüfung, ob sowohl die Datenbank als auch die Application verfügbar sind)
• Nicht-HTTP-Integritätsprüfungen (wie SIP, Microsoft Windows SQL Server und FTP)
• Fortschrittliche Algorithmen zur besseren Verteilung des Datenverkehrs auf die am besten funktionierenden Server

Globale Verfügbarkeit

• Application über einen heterogenen Mix aus verschiedenen Cloud-Anbietern oder Rechenzentren
• Integration mit erweiterten BIG-IP-Monitoren
• DNSSec-Unterstützung

Erweiterte Application ermöglichen eine höhere Leistung von Applications bei gleichzeitiger höherer Verfügbarkeit und Sicherheit. Diese Dienste können an einem strategischen Kontrollpunkt unabhängig von der jeweiligen Application vorhanden sein. Durch die Entkopplung der Dienste von der Geschäftslogik der Application können die Applications Geschäftsanforderungen erfüllen, ohne die Entwicklungsteams mit Infrastruktur-, Verwaltungs- und Leistungsproblemen zu belasten. Über einen strategischen Kontrollpunkt können zudem Governance-Fragen einheitlich und unabhängig von den einzelnen Application gehandhabt werden.

Durch die Bereitstellung einer Cloud-nativen Integration mit der AWS-Infrastruktur ermöglicht F5 Unternehmen, das Beste aus ihren AWS-Bereitstellungen herauszuholen und ihren Applications eine bessere Leistung, höhere Verfügbarkeit und stärkere Sicherheit zu verleihen. Im folgenden Abschnitt untersuchen wir, wie AWS und F5 zusammenarbeiten.

Wenn eine Serverinstanz von einem generischen Image bootet, ist es oft sinnvoll, Parameter zu ändern oder Konfigurationen festzulegen, beispielsweise den Hostnamen und die IP-Adresse. Auf Client-Rechnern werden diese Parameter über DHCP festgelegt, das Festlegen von Serverparametern über DHCP kann jedoch häufig Probleme verursachen. Über die Netzwerkeinstellungen hinaus erfordert eine bestimmte Instanz manchmal spezielle Softwarepakete oder bestimmte Softwarekonfigurationen.

Im Fall einer BIG-IP-Bereitstellung möchte ein Administrator möglicherweise die Konfiguration der einzelnen Module automatisieren, beispielsweise die virtuellen Server und Poolkonfigurationen für BIG-IP Local Traffic Manager (LTM), spezifische WAF-Konfigurationen für BIG-IP Application Security Manager oder vielleicht Firewall-Einstellungen für BIG-IP Advanced Firewall Manager. Jeder, der eine Serverinstanz installiert, hat mit den gleichen Problemen zu kämpfen: Das Basisimage erfordert eine zusätzliche Konfiguration, um ordnungsgemäß zu funktionieren.

AWS bietet zwei primäre Ansätze zum Konfigurieren einer Instanz: Erstellen eines neuen AMI oder Verwenden von Cloud-Init zum Ändern eines Servers während des Startvorgangs. Das Erstellen eines neuen AMI eignet sich besser für Änderungen, die bei mehreren Instanzen üblich sind und die wahrscheinlich nicht so oft aktualisiert werden. Im Gegensatz dazu eignet sich Cloud-Init besser für Änderungen, die weniger Instanzen betreffen und eine kürzere Lebenserwartung haben.

Bei Änderungen, die voraussichtlich über einen längeren Zeitraum bestehen bleiben – und bei Änderungen, die mehrere Instanzen betreffen – bietet es sich an, ein neues AMI zu erstellen, indem Sie eine Maschine von einem AMI booten, das der gewünschten Konfiguration ähnelt. Nachdem der Administrator die notwendigen Änderungen an der laufenden Instanz vorgenommen hat, wird die Instanz gestoppt und ein neues AMI generiert und bei AWS registriert. Bei allen zukünftigen Instanzen, die von diesem AMI gestartet werden, werden die Änderungen bereits angewendet. Da dieser Ansatz Änderungen praktisch dauerhaft macht – und da das Generieren des neuen AMI zeitaufwändig sein kann – sind in das AMI integrierte Änderungen im Allgemeinen solche, die lange bestehen bleiben und in mehreren Instanzen verwendet werden können. Ein weiterer Grund für die Verwendung von AMI besteht darin, dass es schnellere Startzeiten ermöglicht, da einige Cloud-Init-Prozesse zeitintensiv sein können.

Notwendige Änderungen, die sich nicht gut für die Integration in ein neues AMI eignen, eignen sich gut für Cloud-Init, das im Wesentlichen bei jedem Booten der Instanz ein Startskript aktiviert. Durch die Verwendung von Cloud-Init können einfache und instanzspezifische Änderungen in die Instanz eingebettet werden.

Zu den Nachteilen von Cloud-Init gehört, dass Konfigurationsänderungen, wie etwa Paketinstallationen, beim Booten ausgeführt werden müssen, wodurch der Bootvorgang länger dauert. Eine lange Startzeit hat echte Auswirkungen in Szenarien mit automatischer Skalierung, in denen eine verlängerte Startzeit die automatische Skalierung ineffektiv machen könnte. Aus diesen Gründen sollten zeitintensive Änderungen in ein neues AMI eingebunden werden, statt die Änderungen per Cloud-Init vorzunehmen.

Die Verwaltung der Konfiguration kann auch mühsam sein, wenn eine Änderung für mehrere, aber nicht für alle Instanzen verwendet werden kann. Angenommen, eine bestimmte BIG-IP-Bereitstellung wird in einer Auto-Scale-Gruppe mit einer bestimmten virtueller Server verwendet. Ein einzelnes AMI könnte für diese Maschinen dienen und ein anderes AMI könnte für andere BIG-IP-Maschinen in einer anderen Auto-Scale-Gruppe dienen. Durch die Verwendung eines einzelnen AMI für jede Auto-Scale-Gruppe wird sichergestellt, dass im Cloud-Init-Prozess nur hostspezifische Änderungen erforderlich sind. Alle für die Gruppe gemeinsamen Änderungen können in das AMI eingebettet werden. Der Nachteil dieses Ansatzes besteht darin, dass für jede für alle Maschinen gemeinsame Änderung eine Aktualisierung des AMI erforderlich ist.

Applications stellen eine Funktion bereit, im Allgemeinen für mehrere Benutzer gleichzeitig. Mit zunehmendem Erfolg der Application kann diese die Kapazität des Computers überschreiten, auf dem sie ausgeführt wird. Sobald die Application die des Computers übersteigen, müssen Optionen zur Kapazitätssteigerung geprüft werden. Es gibt drei allgemeine Ansätze zur Skalierung: Hochskalierung, Pipelining und Hochskalierung.

Die Skalierung nach oben ist die einfachste Methode zur Kapazitätssteigerung, da hierbei lediglich der vorhandene Computer durch einen schnelleren ersetzt wird. Durch die Installation eines schnelleren Computers werden alle Aspekte der Application und alle anderen Dienste auf dem Computer schneller, ohne dass Änderungen an der Application oder der Infrastruktur erforderlich sind. Der Nachteil einer Skalierung besteht darin, dass die Kosten tendenziell exponentiell mit der Leistungssteigerung ansteigen, was zu einem Punkt abnehmender Erträge führt. Sobald eine Schwelle überschritten wird, wird eine Skalierung zu kostspielig.

Pipelining ist das Ergebnis der Zerlegung der Arbeitslast in aufeinanderfolgende Schritte, ähnlich einem Fließband. Wenn verschiedene Computer unabhängig voneinander an jedem Schritt arbeiten können, lässt sich der Gesamtdurchsatz erhöhen. Allerdings erhöht Pipelining nur den Durchsatz und dies geschieht häufig auf Kosten der Latenz. Anders ausgedrückt: Pipelining kann die Gesamtleistung steigern, für einen einzelnen Benutzer oder eine einzelne Anforderung jedoch die Leistung verringern. Der andere Nachteil der Pipelining-Methode besteht darin, dass ein tiefes Verständnis des zerlegbaren Workflows und einer diesem Verständnis entsprechenden Infrastruktur erforderlich ist. Dadurch werden die Infrastrukturentscheidungen eng mit der Geschäftslogik verknüpft, was genau das Gegenteil von dem ist, was viele Organisationen versuchen.

Beim Skalieren werden die Application und der Computer in Ruhe gelassen und die Anforderungen stattdessen gleichmäßig auf einen Serverpool verteilt. Da Applications im Allgemeinen mehrere unabhängige Anforderungen gleichzeitig verarbeiten, können die Anforderungen sicher auf einen Pool identischer Application verteilt werden. Die Skalierung bietet den zusätzlichen Vorteil der Redundanz, da der Ausfall eines Poolmitglieds nicht zu einem Ausfall der gesamten Application führt. Der Nachteil der Skalierung besteht darin, dass eine komplexe Orchestrierung außerhalb der Application erforderlich ist, um sicherzustellen, dass die Anforderungen auf die Knoten im Pool verteilt werden.

AWS Auto Scale verwendet einen Scale-Out-Ansatz zur Erhöhung der Kapazität für Applications , die dies benötigen. Der CloudWatch-Dienst überwacht Knoten in einem Pool. Wenn Knoten vordefinierte Schwellenwerte überschreiten, startet CloudWatch automatisch neue Knoten oder fährt Knoten im Pool entsprechend herunter. Mit der BIG-IP-Plattform kann dieser Prozess auf zwei Arten erfolgen: durch Ändern der Anzahl der BIG-IP-Instanzen oder durch Ändern der Anzahl der Knoten in einem Pool hinter einer einzelnen BIG-IP-Instanz. Der Unterschied zwischen den beiden Ansätzen hängt davon ab, was skaliert wird: entweder die BIG-IP-Instanz oder ein Pool.

Im ersten Szenario befindet sich ein BIG-IP-Pool zwischen einem Paar ELB-Geräte. Das erste ELB-Gerät steuert die Instanziierung und Beendigung von BIG-IP-Mitgliedern, während das zweite ELB-Gerät der einzige Eintrag in einem Serverpool für jede der BIG-IP-Instanzen ist. Dieser Ansatz ist sinnvoll, wenn die BIG-IP-Instanz erweiterte Application bereitstellt, wie etwa SSL-Terminierung, oder als Web Application Firewall fungiert. Das erste ELB-Gerät führt den Lastausgleich durch und vergrößert oder verkleinert gleichzeitig den Pool entsprechend.

Im zweiten Szenario wächst und schrumpft die Anzahl der Back-End-Poolmitglieder über CloudWatch, aber die BIG-IP-Instanz führt den Lastenausgleich durch. Die BIG-IP-Instanz kommuniziert mit AWS, um Knoten zu erkennen, die zum Pool hinzugefügt oder aus dem Pool entfernt werden. Dieser Ansatz ist sinnvoll, wenn Sie erweiterte Lastausgleichsfunktionen verwenden, beispielsweise die Skriptsprache iRules, oder wenn Sie Anforderungen auf Basis von URLs oder Inhalten weiterleiten. In diesen Fällen reicht eine einzelne BIG-IP-Instanz aus, um die Last der Server im Back-End-Pool zu verwalten.

Die BIG-IP-Instanz muss in mindestens zwei Szenarien mit der AWS-Infrastruktur interagieren. Erstens erfordert eine AWS-Bereitstellung mit mehreren Zonen die Änderung der IP-Adresse hinter einer elastischen AWS-IP. Zweitens benötigt eine BIG-IP-Instanz Einblick in die Poolmitglieder, die vom AWS CloudWatch-Dienst hinzugefügt und entfernt werden, der die Server innerhalb eines Pools hoch- und herunterskaliert. Jede Interaktion mit der Infrastruktur erfolgt über API-Aufrufe und genau wie jede andere Software, die API-Aufrufe tätigt, muss sich die BIG-IP-Instanz bei AWS authentifizieren. Im Allgemeinen gibt es zwei Ansätze zur Authentifizierung bei AWS: über Anmeldeinformationen oder IAM-Rollen.

Die einfachste Methode zur Authentifizierung besteht darin, dem API-Aufruf die entsprechenden Anmeldeinformationen beizufügen. AWS-Anmeldeinformationen bestehen aus einem Zugriffsschlüssel und einem geheimen Schlüssel, die in etwa einem Benutzernamen und einem Passwort entsprechen. Der Administrator generiert die Anmeldeinformationen, die der Entwickler dann in die Application einbettet. Dadurch erhält die Application Zugriff auf die entsprechenden API-Aufrufe.

Das Einbetten von Anmeldeinformationen in eine Application ist zwar einfach, birgt jedoch Sicherheitsrisiken. Sofern der Entwickler die Anmeldeinformationen in der Application nicht sichert, können andere Personen oder Software diese abrufen und für böswillige Zwecke verwenden. Dieser Ansatz macht es außerdem schwierig, die Anmeldeinformationen zu ändern, ohne gleichzeitig die Software zu ändern. Während die Verwendung von Anmeldeinformationen für schnelle Tests ein sinnvoller Ansatz ist, sollte für eine Produktionslösung ein anderer Ansatz zur Authentifizierung verwendet werden. Aus diesem Grund wird in den Best Practices von AWS davon abgeraten, gespeicherte Anmeldeinformationen in einer Application zu verwenden.

Ein sichererer Ansatz zur Authentifizierung für API-Aufrufe ist die Verwendung von IAM-Rollen. AWS Identity and Zugriffsverwaltung (IAM) ermöglicht Benutzern die Verwaltung des Zugriffs auf die AWS-Infrastruktur. Jeder Compute-Instanz, beispielsweise einer BIG-IP-Maschine, kann eine IAM-Rolle zugewiesen werden, die einen bestimmten Satz von Funktionen autorisiert. Wenn die Instanz gestartet wird, generiert IAM einen temporären Satz Anmeldeinformationen für die Instanz. Diese Anmeldeinformationen sind gültig, solange die Instanz funktioniert, und aktivieren nur die angegebenen API-Funktionen. Bei der Konfiguration mit einer IAM-Rolle speichert die BIG-IP-Instanz keine Anmeldeinformationen, sondern hat nur Zugriff auf die erforderlichen Infrastruktur-APIs und bietet somit mehr Sicherheit als eine auf Anmeldeinformationen basierende Authentifizierung.

Wie bereits erwähnt, befinden sich AWS-Rechenzentren in geografischen Regionen, von denen jede in einer Verfügbarkeitszone (AZ) liegen kann. Jede AZ innerhalb einer Region hat nichts mit anderen AZs gemeinsam: keine gemeinsame Stromversorgung, Netzwerke oder Gebäude. Tatsächlich ist jede AZ geografisch von den anderen innerhalb einer Region getrennt. Aufgrund der Trennung zwischen den Zonen können AWS-Abonnenten sicher sein, dass ein Ereignis, das eine AZ betrifft, keine Auswirkungen auf eine andere AZ hat. Mit anderen Worten: In der Regel sollte zu jedem Zeitpunkt höchstens eine AZ innerhalb einer Region nicht verfügbar sein. Dies bedeutet, dass jeder Dienst, der über zwei oder mehr Verfügbarkeitszonen bereitgestellt wird, kontinuierlich verfügbar sein sollte.

Die BIG-IP-Plattform unterstützt Hochverfügbarkeit über AWS AZs hinweg mithilfe einer AWS Elastic IP, bei der es sich um eine IP-Adresse handelt, die nicht zwangsläufig mit einer Compute-Instanz verknüpft ist. Stattdessen kann die IP-Adresse dynamisch an eine private IP-Adresse einer laufenden Compute-Instanz weitergeleitet werden. Um eine hohe Verfügbarkeit in mehreren Zonen zu ermöglichen, werden identische Sätze von BIG-IP-Instanzen und Application jeweils in ihrer eigenen AZ platziert. Zunächst wird die elastische IP einer der BIG-IP-Instanzen zugewiesen. Von jedem Client werden Verbindungen zur elastischen IP hergestellt, die sie wiederum an die private IP-Adresse auf einer der BIG-IP-Instanzen weiterleitet. Sollte ein Fehler auftreten, übernimmt die andere BIG-IP-Instanz die Verantwortung, indem sie einen API-Aufruf an AWS sendet und die Weiterleitung der elastischen IP-Adresse an sie anfordert.

Durch die Integration mit dem ELB kann die BIG-IP-Plattform Application bereitstellen, die sich nahtlos in AWS-Funktionen wie mehrere AZs und automatisch skalierende BIG-IP-Knoten integrieren lassen.

Durch die Platzierung des ELB vor einer BIG-IP-Instanz wird die Bereitstellung über mehrere AZs hinweg vereinfacht, da der ELB den Datenverkehr nahtlos auf die einzelnen Application innerhalb jeder AZ verteilen kann, in der eine BIG-IP-Instanz Application bereitstellt. Dieser Ansatz vereinfacht den Lastenausgleich über mehrere AZs hinweg.

Wenn die Elastizität der BIG-IP-Instanzen erforderlich ist, kann ein ELB mit automatischer Skalierung einen Pool virtueller BIG-IP-Geräte automatisch hoch- und herunterskalieren und Application wie eine Web Application Firewall, Identitätsverwaltung oder SSL-Terminierung bereitstellen. Mithilfe eines ELB-Sandwichs wird der Datenverkehr zum ersten ELB weitergeleitet, der den Datenverkehr auf einen Pool von BIG-IP-Instanzen ausgleicht und automatisch skaliert. Um die Konfiguration im gesamten BIG-IP-Pool zu vereinfachen, verfügt jede BIG-IP-Instanz über eine einzelne ELB-Adresse im Serverpool. Der zweite ELB leitet den Verkehr dann an den nachgelagerten Serverpool weiter.

Verschiedene Kombinationen aus ELB- und BIG-IP-Topologien bieten automatische Skalierung, Verfügbarkeit und Application , die für einzelne dieser Topologien nicht verfügbar wären. Indem der Architekt die Vorteile sowohl der ELB- als auch der BIG-IP-Plattform nutzt, kann er das für eine bestimmte Bereitstellung erforderliche Serviceniveau bereitstellen.

Um wiederholbare und skriptbasierte Bereitstellungen zu ermöglichen, bietet AWS Cloud Formation Templates (CFTs), die sowohl die Bereitstellung als auch die laufende Verwaltung vereinfachen. Nach der Erstellung eines CFT für die gewünschte Service- oder Application kann AWS damit schnell und zuverlässig eine Application bereitstellen. CFTs sind besonders in DevOps-Umgebungen nützlich, da sie es Teams ermöglichen, einfach wiederholbare Prozesse zum Testen und für die Produktionsbereitstellung zu erstellen.

F5 unterstützt nicht nur die Verwendung von CFTs zum Bereitstellen von BIG-IP-Instanzen, sondern bietet auch mehrere Referenz-CFT-Dateien für typische BIG-IP-Bereitstellungen .

Durch Anpassen der Parameter in den Referenz-CFT-Dateien sind skriptbasierte Bereitstellungen von BIG-IP-Lösungen für verschiedene Szenarien möglich, darunter die automatische Skalierung von BIG-IP-Instanzen oder Back-End-Servern hinter BIG-IP-Instanzen sowie kompliziertere Szenarien. Durch die Automatisierung wiederholbarer Bereitstellungen innerhalb von AWS mithilfe von CFTs und F5-Lösungen können komplexe Application schnell und mit wenig Aufwand bereitgestellt werden.

Natürlich nützt Technologie wenig, wenn sie nicht voll ausgeschöpft wird. Zu diesem Zweck stellt F5 eine umfassende Dokumentation bereit. Dokumentation ist für die BIG-IP-Plattform im Allgemeinen und für die Besonderheiten einer BIG-IP-Instanz innerhalb von AWS verfügbar. Ein guter Ausgangspunkt für alle Fragen ist „Ask F5“ .

Die Registerkarte „Dokumentation“ bietet Informationen zu bestimmten BIG-IP-Modulen sowie einen ganzen Abschnitt zur AWS-Integration. Das AWS-Portal bietet eine durchsuchbare Oberfläche für Dokumentationen, Artikel, Community und Ressourcen vom Einstieg bis hin zu komplexen Bereitstellungsszenarien.

Für Fragen, die in der Dokumentation nicht beantwortet werden, steht die F5 DevCentral-Community mit Antworten und Hilfe bereit.

Der Vormarsch in Richtung öffentlicher Clouds ist keine Modeerscheinung mehr, sondern ein anhaltender Trend in der IT. Amazon Web Services ist der weltweit größte und umfassendste Anbieter öffentlicher Cloud-Dienste und bietet Unternehmen die Möglichkeit, Applications ohne lokale Ausrüstung zu erstellen, zu testen und bereitzustellen. F5 hat seine erweiterten Application als Teil des AWS-Ökosystems verfügbar gemacht und sie so konfiguriert, dass Apps in AWS-Cloud-Umgebungen schneller, intelligenter und sicherer laufen.