Dieses Whitepaper dient nur als historische Referenz. Einige Inhalte sind möglicherweise veraltet und einige Links sind möglicherweise nicht verfügbar.
Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Beispiele für Architekturmuster
Sie können beliebte Architekturmuster mit API Gateway und AWS Lambda als Logikebene implementieren. Dieses Whitepaper enthält die beliebtesten Architekturmuster, die AWS Lambda basierte Logikstufen nutzen:
+ **Mobiles Backend —** Eine mobile Anwendung kommuniziert mit API Gateway und Lambda, um auf Anwendungsdaten zuzugreifen. Dieses Muster kann auf generische HTTPS-Clients ausgedehnt werden, die keine serverlosen AWS-Ressourcen zum Hosten von Ressourcen auf Präsentationsebene verwenden (z. B. Desktop-Clients, Webserver EC2, auf denen ausgeführt wird usw.).
+ **Einseitige Anwendung** — Eine einseitige Anwendung, die in Amazon S3 gehostet wird und mit API Gateway CloudFront kommuniziert und auf Anwendungsdaten AWS Lambda zugreift.
+ **Webanwendung** — Die Webanwendung ist ein ereignisgesteuertes Allzweck-Back-End für Webanwendungen, das AWS Lambda mit API Gateway für seine Geschäftslogik verwendet wird. Es verwendet auch DynamoDB als Datenbank und Amazon Cognito für die Benutzerverwaltung. Alle statischen Inhalte werden mit Amplify gehostet.
Zusätzlich zu diesen beiden Mustern wird in diesem Whitepaper die Anwendbarkeit von Lambda und API Gateway auf eine allgemeine Microservice-Architektur erörtert. Eine Microservice-Architektur ist ein beliebtes Muster, obwohl es sich nicht um eine dreistufige Standardarchitektur handelt, bei der Anwendungskomponenten entkoppelt und als zustandslose, individuelle Funktionseinheiten bereitgestellt werden, die miteinander kommunizieren.
# Mobiles Backend
![\[Architekturmuster für serverloses mobiles Backend\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/serverless-multi-tier-architectures-api-gateway-lambda/images/arch-pattern-serverless-mobile-backend.png)
*Architekturmuster für serverloses mobiles Backend*
*Tabelle 1: Komponenten der Stufe „Mobiles Backend“*
| Stufe | Komponenten |
| --- | --- |
| Präsentation | Mobile Anwendung, die auf einem Benutzergerät ausgeführt wird. |
| Logic (Logik) | Amazon API Gateway mit AWS Lambda. Diese Architektur zeigt drei exponierte Dienste (`/tickets``/shows`, und`/info`). API Gateway Gateway-Endpunkte werden durch [Amazon Cognito Cognito-Benutzerpools](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-identity-pools.html) gesichert. Bei dieser Methode melden sich Benutzer Amazon Cognito Cognito-Benutzerpools an (falls erforderlich mit einem verbundenen Drittanbieter) und erhalten Zugriffs- und ID-Tokens, die zur Autorisierung von API Gateway Gateway-Aufrufen verwendet werden. Jeder Lambda-Funktion wird ihre eigene Identity and Access Management (IAM) -Rolle zugewiesen, um Zugriff auf die entsprechende Datenquelle zu gewähren. |
| Daten | DynamoDB wird für die `/tickets` UND-Services verwendet. `/shows` Amazon RDS wird für den `/info` Service verwendet. Diese Lambda-Funktion ruft Amazon RDS-Anmeldeinformationen von AWS Secrets Manager ab und verwendet eine elastic network interface, um auf das private Subnetz zuzugreifen. |
# Einseitige Anwendung
![\[AWS architecture diagram showing interactions between services like CloudFront, S3, Lambda, and DynamoDB.\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/serverless-multi-tier-architectures-api-gateway-lambda/images/single-page-application.png)
*Architekturmuster für serverlose einseitige Anwendungen*
*Tabelle 2: Einseitige Anwendungskomponenten*
| Stufe | Komponenten |
| --- | --- |
| Präsentation | Statischer Webseiteninhalt, gehostet in Amazon S3, vertrieben von CloudFront. AWS Certificate Manager ermöglicht die Verwendung eines benutzerdefinierten SSL/TLS-Zertifikats. |
| Logic (Logik) | API Gateway mit AWS Lambda. Diese Architektur zeigt drei exponierte Dienste (`/tickets``/shows`, und`/info`). API Gateway Gateway-Endpunkte werden durch einen Lambda-Authorizer gesichert. Bei dieser Methode melden sich Benutzer über einen externen Identitätsanbieter an und erhalten Zugriffs- und ID-Token. Diese Token sind in API-Gateway-Aufrufen enthalten, und der Lambda-Autorisierer validiert diese Token und generiert eine IAM-Richtlinie mit API-Initiierungsberechtigungen. Jeder Lambda-Funktion wird eine eigene IAM-Rolle zugewiesen, um Zugriff auf die entsprechende Datenquelle zu gewähren. |
| Daten | Amazon DynamoDB wird für die Dienste `/tickets` und `/shows` verwendet. Amazon ElastiCache wird vom `/shows` Service verwendet, um die Datenbankleistung zu verbessern. Cachefehler werden an DynamoDB gesendet. Amazon S3 wird verwendet, um statische Inhalte zu hosten, die von der verwendet werden`/info service`. |
# Webanwendung
![\[AWS Cloud architecture diagram showing client interaction with various AWS-Services.\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/serverless-multi-tier-architectures-api-gateway-lambda/images/web-application.png)
*Architekturmuster für Webanwendungen*
*Tabelle 3: Komponenten der Webanwendung*
| Stufe | Komponenten |
| --- | --- |
| Präsentation | Die Frontend-Anwendung besteht aus allen statischen Inhalten (HTML, CSS JavaScript und Bilder), die von React-Dienstprogrammen wie create-react-app generiert werden. Amazon CloudFront hostet all diese Objekte. Wenn die Webanwendung verwendet wird, lädt sie alle Ressourcen in den Browser herunter und wird von dort aus ausgeführt. Die Webanwendung stellt eine Verbindung zum Backend her und ruft die auf APIs. |
| Logic (Logik) | Die Logikschicht wird mithilfe von Lambda-Funktionen erstellt, die von API Gateway REST unterstützt werden. APIs Diese Architektur zeigt mehrere exponierte Dienste. Es gibt mehrere verschiedene Lambda-Funktionen, von denen jede einen anderen Aspekt der Anwendung behandelt. Die Lambda-Funktionen befinden sich hinter API Gateway und sind über API-URL-Pfade zugänglich. Die Benutzerauthentifizierung wird mithilfe von Amazon Cognito Cognito-Benutzerpools oder Verbundbenutzeranbietern abgewickelt. API Gateway verwendet die sofort einsatzbereite Integration mit Amazon Cognito. Erst nachdem ein Benutzer authentifiziert wurde, erhält der Client ein JSON-Web-Token (JWT), das er dann bei den API-Aufrufen verwenden sollte. Jeder Lambda-Funktion wird eine eigene IAM-Rolle zugewiesen, um Zugriff auf die entsprechende Datenquelle zu gewähren. |
| Daten | In diesem speziellen Beispiel wird DynamoDB für die Datenspeicherung verwendet, aber je nach Anwendungsfall und Nutzungsszenario können auch andere speziell entwickelte Amazon-Datenbank- oder Speicherdienste verwendet werden. |
# Microservices mit Lambda
![\[AWS Cloud architecture with API Gateways and Lambda functions across two accounts.\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/serverless-multi-tier-architectures-api-gateway-lambda/images/microservices-with-lambda.png)
*Architekturmuster für Microservices mit Lambda*
Das Mikroservice-Architekturmuster ist nicht an die typische dreistufige Architektur gebunden. Dieses beliebte Muster kann jedoch erhebliche Vorteile aus der Verwendung serverloser Ressourcen ziehen.
In dieser Architektur sind die einzelnen Anwendungskomponenten entkoppelt und werden unabhängig voneinander bereitgestellt und betrieben. Eine API, die mit Amazon API Gateway erstellt wurde, und Funktionen, die anschließend von gestartet werden AWS Lambda, sind alles, was Sie benötigen, um einen Microservice zu erstellen. Ihr Team kann diese Services nutzen, um Ihre Umgebung zu entkoppeln und zu fragmentieren, bis die gewünschte Granularität erreicht ist.
Im Allgemeinen kann eine Microservices-Umgebung zu den folgenden Schwierigkeiten führen: wiederholter Mehraufwand für die Erstellung jedes neuen Microservices, Probleme bei der Optimierung der Serverdichte und -auslastung, Komplexität der gleichzeitigen Ausführung mehrerer Versionen mehrerer Microservices und Zunahme von clientseitigen Codeanforderungen für die Integration in viele separate Dienste.
Wenn Sie Microservices mithilfe serverloser Ressourcen erstellen, ist es weniger schwierig, diese Probleme zu lösen, und in einigen Fällen verschwinden sie einfach. Das serverlose Microservices-Muster senkt die Barriere für die Erstellung jedes nachfolgenden Microservices (API Gateway ermöglicht sogar das Klonen vorhandener APIs und die Verwendung von Lambda-Funktionen in anderen Konten). Die Optimierung der Serverauslastung ist bei diesem Muster nicht mehr relevant. Schließlich bietet Amazon API Gateway programmgesteuert generierte Clients SDKs in einer Reihe gängiger Sprachen, um den Integrationsaufwand zu reduzieren.