Fallstudie: Warum ich AWS Cloud Infrastructure für meine Produkte verwende

Als Plattform für den Betrieb eines komplexen und anspruchsvollen Softwareprodukts bietet AWS Flexibilität, indem Ressourcen bei Bedarf und im erforderlichen Umfang genutzt werden. Es ist auf Abruf und sofort verfügbar und ermöglicht die vollständige Kontrolle über die laufende Umgebung. Wenn Sie einem Kunden eine solche Cloud-Architekturlösung vorschlagen, hängen die bereitgestellte Infrastruktur und ihr Preis stark von den Anforderungen ab, die im Voraus eingerichtet werden müssen.

Dieser Artikel stellt eine solche Cloud-Infrastrukturarchitektur von AWS vor, die für LEVELS vorgeschlagen und implementiert wurde, ein soziales Netzwerk mit integrierter Gesichtszahlungsfunktion, das alle Vorteile findet und anwendet, die Benutzer für die Kartenprogramme, in denen sie sich befinden, Dinge, die sie besitzen, oder Orte erhalten könnten Sie leben in.

Anforderungen

Der Kunde hatte zwei Hauptanforderungen, die die vorgeschlagene Lösung erfüllen musste:

1. Sicherheit
2. Skalierbarkeit

Bei der Sicherheitsanforderung ging es vor allem darum, die Daten der Benutzer vor unbefugtem Zugriff von außen, aber auch von innen zu schützen. Bei der Skalierbarkeitsanforderung ging es um die Fähigkeit der Infrastruktur, das Produktwachstum zu unterstützen, sich automatisch an steigenden Datenverkehr und gelegentliche Spitzen anzupassen, sowie automatisches Failover und Wiederherstellung bei Serverausfällen, um potenzielle Ausfallzeiten zu minimieren.

Überblick über die AWS-Sicherheitskonzepte

Einer der Hauptvorteile der Einrichtung Ihrer eigenen AWS Cloud-Infrastruktur ist die vollständige Netzwerkisolierung und die vollständige Kontrolle über Ihre Cloud. Das ist der Hauptgrund, warum Sie sich für die Infrastructure as a Service (IaaS)-Route entscheiden würden, anstatt etwas einfachere Platform as a Service (PaaS)-Umgebungen zu betreiben, die solide Sicherheitsstandards bieten, aber nicht die vollständige, feinkörnige Kontrolle haben, die Sie bekommen Aufbau einer eigenen Cloud mit AWS.

Obwohl LEVELS ein junges Produkt war, als sie sich wegen der AWS-Beratungsdienste an Toptal wandten, waren sie bereit, sich an AWS zu binden und wussten, dass sie mit ihrer Infrastruktur Sicherheit auf dem neuesten Stand der Technik wollten, da sie sich sehr um Benutzerdaten und Datenschutz sorgen. Darüber hinaus planen sie, die Kreditkartenverarbeitung in Zukunft zu unterstützen, daher war ihnen klar, dass sie irgendwann die PCI-DSS-Konformität sicherstellen mussten.

Virtuelle private Cloud (VPC)

Sicherheit auf AWS beginnt mit der Erstellung Ihrer eigenen Amazon Virtual Private Cloud (VPC) – einem dedizierten virtuellen Netzwerk, das Ihre AWS-Ressourcen hostet und logisch von anderen virtuellen Netzwerken in der AWS Cloud isoliert ist. Die VPC erhält ihren eigenen IP-Adressbereich, vollständig konfigurierbare Subnetze, Routingtabellen, Netzwerkzugriffskontrolllisten und Sicherheitsgruppen (effektiv eine Firewall).

Bei LEVELS haben wir zunächst unsere Produktionsumgebung von Entwicklungs-, Test- und QA-Umgebungen isoliert. Die erste Idee war, jede von ihnen als ihre eigene, vollständig isolierte VPC auszuführen, wobei jede alle Dienste ausführt, die von der Anwendung benötigt werden. Nach einiger Überlegung stellte sich heraus, dass wir eine gewisse Ressourcenteilung in den drei Nicht-Produktionsumgebungen zulassen konnten, was die Kosten in gewissem Maße senkte.

Daher haben wir uns für die Produktionsumgebung als eine VPC entschieden, mit Entwicklungs-, Test- und QA-Umgebungen als einer weiteren VPC.

Zugriffsisolation auf VPC-Ebene

Das Zwei-VPC-Setup isoliert die Produktionsumgebung von den verbleibenden drei Umgebungen auf Netzwerkebene und stellt sicher, dass eine versehentliche Fehlkonfiguration der Anwendung diese Grenze nicht überschreiten kann. Selbst wenn die Konfiguration der Nicht-Produktionsumgebung fälschlicherweise auf Ressourcen der Produktionsumgebung wie Datenbanken oder Nachrichtenwarteschlangen verweisen sollte, gibt es keine Möglichkeit, darauf zuzugreifen.

Da sich Entwicklungs-, Test- und QA-Umgebungen dieselbe VPC teilen, ist ein grenzüberschreitender Zugriff im Falle einer Fehlkonfiguration möglich, aber da diese Umgebungen Testdaten verwenden, bestehen aufgrund der fehlenden Isolation keine wirklichen Sicherheitsbedenken.

Assets Store-Sicherheitsmodell

Assets werden im Objektspeicher von Amazon Simple Storage Service (S3) gespeichert. Die S3-Speicherinfrastruktur ist völlig unabhängig von VPCs und ihr Sicherheitsmodell ist anders. Der Speicher wird in separaten S3-Buckets für jede Umgebung und/oder Asset-Klassen organisiert, wobei jeder Bucket mit den entsprechenden Zugriffsrechten geschützt wird.

Mit LEVELS wurden mehrere Klassen von Assets identifiziert: Benutzer-Uploads, von LEVELS produzierte Inhalte (Werbevideos und ähnliche Inhalte), Webanwendungs- und UI-Assets (JS-Code, Symbole, Schriftarten), Anwendungs- und Infrastrukturkonfiguration und serverseitige Bereitstellungspakete.

Jeder von ihnen erhält einen separaten S3-Bucket.

Verwaltung von Anwendungsgeheimnissen

Bei AWS gibt es einen verschlüsselten AWS Systems Manager Parameter Store oder den AWS Secrets Manager , bei denen es sich um verwaltete Schlüsselwertdienste handelt, die darauf ausgelegt sind, Geheimnisse zu schützen (mehr erfahren Sie unter Linux Academy und 1Strategy).

AWS verwaltet die zugrunde liegenden Verschlüsselungsschlüssel und übernimmt die Verschlüsselung/Entschlüsselung. Auf Geheimnisse selbst können Lese- und Schreibberechtigungsrichtlinien basierend auf den Schlüsselpräfixen sowohl für die Infrastruktur als auch für die Benutzer (Server bzw. Entwickler) angewendet werden.

Server-SSH-Zugriff

SSH-Zugriff auf Server in einer vollständig automatisierten und unveränderlichen Umgebung sollte überhaupt nicht erforderlich sein. Protokolle können extrahiert und an dedizierte Protokollierungsdienste gesendet werden, die Überwachung wird auch an einen dedizierten Überwachungsdienst ausgelagert. Dennoch kann ein gelegentlicher SSH-Zugriff zur Überprüfung und Fehlerbehebung der Konfiguration erforderlich sein.

Um die Angriffsfläche der Server einzuschränken, wird der SSH-Port nicht dem öffentlichen Netzwerk ausgesetzt. Server werden über einen Bastion-Host erreicht, eine dedizierte Maschine, die einen externen SSH-Zugriff ermöglicht und zusätzlich geschützt ist, indem nur der zulässige IP-Adressbereich an der Firewall auf die Whitelist gesetzt wird. Der Zugriff wird gesteuert, indem die öffentlichen SSH-Schlüssel der Benutzer in den entsprechenden Feldern bereitgestellt werden (Passwortanmeldungen sind deaktiviert). Ein solches Setup bietet böswilligen Angreifern ein ziemlich widerstandsfähiges Tor.

Datenbankzugriff

Die gleichen oben beschriebenen Prinzipien gelten für Datenbankserver. Es kann auch gelegentlich erforderlich sein, die Daten direkt in der Datenbank zu verbinden und zu bearbeiten, obwohl dies definitiv keine empfohlene Vorgehensweise ist und ein solcher Zugriff auf die gleiche Weise geschützt werden muss, wie der SSH-Zugriff des Servers geschützt ist.

Ein ähnlicher Ansatz kann verwendet werden, indem dieselbe Bastion-Host-Infrastruktur mit SSH-Tunneling verwendet wird. Es wird ein doppelter SSH-Tunnel benötigt, einer zum Bastion-Host und über diesen ein weiterer zum Server, der Zugriff auf die Datenbank hat (Bastion-Host hat keinen Zugriff auf den Datenbankserver). Durch diesen zweiten Tunnel ist nun eine Verbindung vom Client-Rechner des Benutzers zum Datenbankserver verfügbar.

Überblick über AWS-Skalierbarkeitskonzepte

Wenn wir nur über Server sprechen, lässt sich die Skalierbarkeit mit Plattformen, die einfacher als AWS sind, ziemlich leicht erreichen. Der Hauptnachteil besteht darin, dass bestimmte Anforderungen möglicherweise von den externen Diensten der Plattform abgedeckt werden müssen, was bedeutet, dass Daten über das öffentliche Netzwerk übertragen werden und Sicherheitsgrenzen überschreiten. Um bei AWS zu bleiben, werden alle Daten privat gehalten, während die Skalierbarkeit entwickelt werden muss, um eine skalierbare, widerstandsfähige und fehlertolerante Infrastruktur zu erreichen.

Bei AWS besteht der beste Ansatz zur Skalierbarkeit darin, verwaltete AWS-Services mit Überwachung und Automatisierung zu nutzen, die sich bei Tausenden von Kunden, die die Plattform nutzen, bewährt haben. Fügen Sie Datensicherungen und Wiederherstellungsmechanismen hinzu, und Sie werden viele Bedenken vom Tisch bekommen, wenn Sie sich nur auf die Plattform selbst verlassen.

Die Auslagerung all dessen ermöglicht ein kleineres Betriebsteam, was die höheren Kosten für plattformverwaltete Dienste etwas ausgleicht. Das LEVELS-Team hat diesen Weg gerne gewählt, wo immer es möglich war.

Amazon Elastic Compute Cloud (EC2)

Sich auf eine bewährte Umgebung zu verlassen, in der EC2 -Instances ausgeführt werden, ist immer noch ein ziemlich vernünftiger Ansatz, verglichen mit dem zusätzlichen Overhead und der Komplexität des Ausführens von Containern oder den noch sehr jungen und sich schnell ändernden Architekturkonzepten des Serverless Computing.

Die Bereitstellung von EC2-Instanzen muss vollständig automatisiert werden. Die Automatisierung wird durch benutzerdefinierte AMIs für verschiedene Serverklassen und Auto Scaling-Gruppen erreicht, die sich um den Betrieb dynamischer Serverflotten kümmern, indem sie die entsprechende Anzahl laufender Serverinstanzen in der Flotte entsprechend dem aktuellen Datenverkehr halten.

Darüber hinaus ermöglicht die automatische Skalierungsfunktion das Festlegen der Unter- und Obergrenze für die Anzahl der auszuführenden EC2-Instanzen. Die untere Grenze hilft bei der Fehlertoleranz und eliminiert möglicherweise Ausfallzeiten im Falle von Instanzausfällen. Die Obergrenze hält die Kosten unter Kontrolle und lässt ein gewisses Risiko von Ausfallzeiten bei unerwarteten Extrembedingungen zu. Die automatische Skalierung skaliert dann dynamisch die Anzahl der Instanzen innerhalb dieser Grenzen.

Amazon Relational Database Service (RDS)

Das Team hat bereits Amazon RDS für MySQL ausgeführt, aber die geeignete Backup-, Fehlertoleranz- und Sicherheitsstrategie musste noch entwickelt werden. In der ersten Iteration wurde die Datenbankinstanz in jeder VPC auf einen Cluster mit zwei Instanzen aktualisiert, der als Master und als Lesereplikat konfiguriert war und automatisches Failover unterstützte.

In der nächsten Iteration, mit der Verfügbarkeit der MySQL-Engine Version 5.7, erhielt die Infrastruktur ein Upgrade auf den Amazon Aurora MySQL -Service. Obwohl vollständig verwaltet, ist Aurora keine automatisch skalierte Lösung. Es bietet eine automatische Speicherskalierung und vermeidet das Problem der Kapazitätsplanung. Ein Lösungsarchitekt muss jedoch immer noch die Größe der Recheninstanz auswählen.

Die Ausfallzeit durch Skalierung lässt sich nicht vermeiden, aber mit Hilfe der Auto-Healing-Fähigkeit auf ein Minimum reduzieren. Dank besserer Replikationsfunktionen bietet Aurora eine nahtlose Failover-Funktionalität. Die Skalierung wird ausgeführt, indem ein Read Replica mit der gewünschten Rechenleistung erstellt und dann das Failover auf diese Instanz ausgeführt wird. Alle anderen Lesereplikate werden dann ebenfalls aus dem Cluster entfernt, in der Größe angepasst und wieder in den Cluster gebracht. Es erfordert etwas manuelles Jonglieren, ist aber mehr als machbar.

Das neue Aurora Serverless-Angebot ermöglicht auch ein gewisses Maß an automatischer Skalierung der Rechenressourcen, eine Funktion, die es definitiv wert ist, in Zukunft näher betrachtet zu werden.

Verwaltete AWS-Services

Abgesehen von diesen beiden Komponenten profitiert der Rest des Systems von den automatischen Skalierungsmechanismen der vollständig verwalteten AWS-Services. Dies sind Elastic Load Balancing (ELB), Amazon Simple Queue Service (SQS), Amazon S3-Objektspeicher, AWS Lambda-Funktionen und Amazon Simple Notification Service (SNS), bei denen vom Architekten kein besonderer Skalierungsaufwand erforderlich ist.

Veränderliche vs. unveränderliche Infrastruktur

Wir erkennen zwei Ansätze für den Umgang mit der Serverinfrastruktur – eine veränderliche Infrastruktur, in der Server installiert und vor Ort kontinuierlich aktualisiert und modifiziert werden; und eine unveränderliche Infrastruktur, in der die Server nach der Bereitstellung niemals geändert werden und alle Konfigurationsänderungen oder Serveraktualisierungen durch die Bereitstellung neuer Server aus einem gemeinsamen Image oder einem Installationsskript gehandhabt werden, wodurch die alten ersetzt werden.

Mit LEVELS haben Sie die Wahl, eine unveränderliche Infrastruktur ohne In-Place-Upgrades, Konfigurationsänderungen oder Verwaltungsaktionen auszuführen. Die einzige Ausnahme sind Anwendungsbereitstellungen, die vor Ort stattfinden.

Mehr über veränderliche vs. unveränderliche Infrastruktur finden Sie im Blog von HashiCorp.

Architekturübersicht

Technisch gesehen ist LEVELS eine mobile App und eine Web-App mit dem REST-API-Backend und einigen Hintergrunddiensten – heutzutage eine eher typische Anwendung. Dazu wurde folgende Infrastruktur vorgeschlagen und konfiguriert:

Isolierung virtueller Netzwerke – Amazon VPC

Das Diagramm visualisiert eine Struktur einer Umgebung in ihrer VPC. Andere Umgebungen folgen der gleichen Struktur (wobei der Application Load Balancer (ALB) und der Amazon Aurora-Cluster von den Nicht-Produktionsumgebungen in ihrer VPC gemeinsam genutzt werden, aber die Netzwerkeinrichtung genau gleich ist).

Die VPC ist für Fehlertoleranz über vier Verfügbarkeitszonen innerhalb einer AWS-Region konfiguriert. Subnetze und Sicherheitsgruppen mit Netzwerkzugriffskontrolllisten ermöglichen die Erfüllung der Sicherheits- und Zugriffskontrollanforderungen.

Die Infrastruktur über mehrere AWS-Regionen für zusätzliche Fehlertoleranz zu verteilen, wäre in einem frühen Stadium des Geschäfts und seines Produkts zu komplex und unnötig gewesen, ist aber eine Option für die Zukunft.

Rechnen

LEVELS führt eine herkömmliche REST-API mit einigen Hintergrundarbeitern für die Anwendungslogik aus, die im Hintergrund abläuft. Beide werden als dynamische Flotten einfacher EC2-Instances ausgeführt, die durch Auto Scaling-Gruppen vollständig automatisiert sind. Der verwaltete Amazon SQS -Service wird für die Verteilung von Hintergrundaufgaben (Jobs) verwendet, sodass Sie Ihren eigenen MQ-Server nicht ausführen, warten und skalieren müssen.

Es gibt auch einige Dienstprogrammaufgaben, die keine Geschäftslogik mit dem Rest der Anwendung teilen, wie z. B. die Bildverarbeitung. Solche Arten von Aufgaben laufen auf AWS Lambda sehr gut, da Lambdas unbegrenzt horizontal skalierbar sind und im Vergleich zu Server-Workern eine unübertroffene parallele Verarbeitung bieten.

Lastenausgleich, automatische Skalierung und Fehlertoleranz

Load Balancing kann manuell über Nginx oder HAProxy erreicht werden, aber die Wahl von Amazon Elastic Load Balancing (ELB) bietet den Vorteil, dass die Load Balancing-Infrastruktur automatisch skalierbar, hochverfügbar und fehlertolerant ist.

Die Application Load Balancer (ALB)-Variante des ELB wird verwendet, wobei das HTTP-Layer-Routing am Load Balancer verfügbar ist. Neue Instanzen, die der Flotte hinzugefügt werden, werden über die Mechanismen der AWS-Plattform automatisch bei der ALB registriert. Die ALB überwacht zudem jederzeit die Verfügbarkeit der Instanzen. Es hat die Möglichkeit, die fehlerhaften Instanzen abzumelden und zu beenden, wodurch das Auto Scaling ausgelöst wird, um sie durch neue zu ersetzen. Durch dieses Zusammenspiel zwischen den beiden wird die automatische Reparatur der EC2-Flotte erreicht.

Anwendungsdatenspeicher

Der Anwendungsdatenspeicher ist ein Amazon Aurora MySQL-Cluster , der aus einer Master-Instance und einer Reihe von Read-Replica-Instances besteht. Im Falle eines Ausfalls der Masterinstanz wird eine der Read Replicas automatisch in eine neue Masterinstanz hochgestuft. Als solche konfiguriert erfüllt es die geforderte Fehlertoleranzanforderung.

Read Replicas können, wie der Name schon sagt, auch zum Verteilen der Datenbank-Clusterlast für Datenlesevorgänge verwendet werden.

Der Datenbankspeicher wird mit Aurora automatisch in 10-GB-Schritten skaliert, und Backups werden ebenfalls vollständig von AWS verwaltet und bieten standardmäßig eine Point-in-Time-Wiederherstellung. All dies reduziert den Verwaltungsaufwand für die Datenbank praktisch auf Null, außer der Skalierung der Datenbank-Rechenleistung bei Bedarf – ein Service, für den es sich lohnt, sorgenfrei zu laufen.

Aufbewahrung und Bereitstellung von Vermögenswerten

LEVELS akzeptiert von Benutzern hochgeladene Inhalte, die gespeichert werden müssen. Der Amazon S3 -Objektspeicher ist, ganz vorhersehbar, der Dienst, der sich um diese Aufgabe kümmert. Es gibt auch Anwendungsressourcen (UI-Elemente – Bilder, Symbole, Schriftarten), die der Client-App zur Verfügung gestellt werden müssen, damit sie auch im S3 gespeichert werden. S3 bietet automatische Backups der hochgeladenen Daten durch ihre interne Speicherreplikation und bietet standardmäßig Datenbeständigkeit.

Bilder, die von Benutzern hochgeladen werden, sind unterschiedlich groß und schwer, oft unnötig groß für die direkte Bereitstellung und übergewichtig, was die Mobilfunkverbindungen belastet. Die Produktion mehrerer Variationen in unterschiedlichen Größen ermöglicht die Bereitstellung optimierter Inhalte für jeden Anwendungsfall. AWS Lambda wird für diese Aufgabe sowie für die Erstellung einer Kopie der hochgeladenen Bildoriginale in einem separaten Backup-Bucket für alle Fälle genutzt.

Schließlich ist eine Browser-laufende Webanwendung auch ein Satz statischer Assets – die Continuous Integration-Build-Infrastruktur kompiliert den JavaScript-Code und speichert jeden Build ebenfalls in S3.

Sobald alle diese Assets sicher in S3 gespeichert sind, können sie direkt bereitgestellt werden, da S3 eine öffentliche HTTP-Schnittstelle bereitstellt, oder über das Amazon CloudFront CDN. CloudFront verteilt die Assets geografisch, reduziert die Latenz für die Endbenutzer und aktiviert auch die HTTPS-Unterstützung für die Bereitstellung statischer Assets.

Infrastrukturbereitstellung und -verwaltung

Die Bereitstellung der AWS-Infrastruktur ist eine Kombination aus Netzwerken, den von AWS verwalteten Ressourcen und Services und den reinen EC2-Computing-Ressourcen. Verwaltete AWS-Services werden, nun ja, verwaltet. Mit ihnen ist nicht viel zu tun, außer die entsprechende Sicherheit bereitzustellen und anzuwenden, während wir uns bei den EC2-Rechenressourcen selbst um die Konfiguration und Automatisierung kümmern müssen.

Werkzeuge

Die webbasierte AWS-Konsole macht die Verwaltung der „Legostein-ähnlichen“ AWS-Infrastruktur alles andere als trivial und wie jede manuelle Arbeit eher fehleranfällig. Aus diesem Grund ist die Verwendung eines speziellen Tools zur Automatisierung dieser Arbeit sehr wünschenswert.

Ein solches Tool ist AWS CloudFormation , das von AWS entwickelt und gepflegt wird. Eine andere ist Terraform von HashiCorp – eine etwas flexiblere Wahl, da mehrere Plattformanbieter angeboten werden, aber hier hauptsächlich aufgrund der Philosophie des unveränderlichen Infrastrukturansatzes von Terraform interessant. Ausgerichtet auf die Art und Weise, wie die LEVELS-Infrastruktur betrieben wird, erwies sich Terraform zusammen mit Packer für die Bereitstellung der Basis-AMI-Images als hervorragend geeignet.

Infrastrukturdokumentation

Ein zusätzlicher Vorteil bei einem Automatisierungstool ist, dass es keine detaillierte Infrastrukturdokumentation benötigt, die früher oder später veraltet. Das Paradigma „Infrastructure as Code“ (IaC) des Bereitstellungstools fungiert als Dokumentation, mit dem Vorteil, immer auf dem neuesten Stand der tatsächlichen Infrastruktur zu sein. Es reicht dann aus, einen Überblick auf hoher Ebene zu haben, der weniger wahrscheinlich geändert wird und relativ einfach mit den eventuellen Änderungen zu warten ist, die nebenbei dokumentiert sind.

Abschließende Gedanken

Die vorgeschlagene AWS Cloud-Infrastruktur ist eine skalierbare Lösung, die in der Lage ist, zukünftiges Produktwachstum weitgehend automatisch zu berücksichtigen. Nach fast zwei Jahren gelingt es ihm, die Betriebskosten niedrig zu halten, indem es sich auf Cloud-Automatisierung verlässt, ohne dass ein dediziertes Systembetriebsteam rund um die Uhr im Einsatz ist.

In Bezug auf die Sicherheit speichert AWS Cloud alle Daten und alle Ressourcen innerhalb eines privaten Netzwerks in derselben Cloud. Für die Übertragung über das öffentliche Netz sind niemals vertrauliche Daten erforderlich. Der externe Zugriff wird mit fein granularen Berechtigungen für die vertrauenswürdigen Supportsysteme (CI/CD, externe Überwachung oder Alarmierung) gewährt, wobei der Umfang des Zugriffs nur auf die Ressourcen beschränkt wird, die für ihre Rolle im gesamten System erforderlich sind.

Richtig aufgebaut und eingerichtet, ist ein solches System flexibel, belastbar, sicher und bereit, alle zukünftigen Anforderungen in Bezug auf die Skalierung für das Produktwachstum oder die Implementierung erweiterter Sicherheit wie PCI-DSS-Konformität zu erfüllen.

Es ist nicht unbedingt billiger als die Produktangebote von Heroku oder ähnlichen Plattformen, die gut funktionieren, solange Sie in die üblichen Nutzungsmuster passen, die von ihren Angeboten abgedeckt werden. Wenn Sie sich für AWS entscheiden, erhalten Sie mehr Kontrolle über Ihre Infrastruktur, ein zusätzliches Maß an Flexibilität bei der Auswahl der angebotenen AWS-Services und eine kundenspezifische Konfiguration mit der Möglichkeit zur Feinabstimmung der gesamten Infrastruktur.

Weiterführende Literatur im Toptal Engineering Blog:

• Machen Sie Ihre Hausaufgaben: 7 Tipps für die Prüfung zum AWS Certified Solutions Architect
• Terraform vs. CloudFormation: Der endgültige Leitfaden
• SSH-Protokollierung und Sitzungsverwaltung mit AWS SSM
• Arbeiten mit TypeScript und Jest Support: Ein AWS SAM-Tutorial