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.
# Komponenten der Lösung
## Wartezimmer, öffentlich und privat APIs
Der Hauptzweck der Virtual Waiting Room AWS On-Lösung besteht darin, die Generierung von JSON Web Tokens (JWT) für Kunden auf kontrollierte Weise zu kontrollieren, um zu verhindern, dass neue Benutzer die Zielwebsite überlasten. JWTs Sie können für den Schutz von Websites verwendet werden, indem der Zugriff auf Webseiten verhindert wird, bis das Wartezimmer-Token abgerufen wurde, und auch für die API-Zugriffsautorisierung.
Die Kernvorlage installiert eine öffentliche API und eine private (IAM-autorisierte) API, die für die meisten virtuellen Warteraum-Operationen verwendet werden. AWS Die öffentliche API ist mit einer CloudFront Distribution mit mehreren Caching-Richtlinien konfiguriert, die auf dem API-Pfad basieren. Eine DynamoDB-Tabelle und ein EventBridge Event-Bus werden erstellt. Die Vorlage fügt eine neue VPC mit zwei Availability Zones (AZs), einen Elasticache-Cluster (Redis OSS) in beiden und mehrere AZs Lambda-Funktionen hinzu. Lambda-Funktionen, die mit Elasticache (Redis OSS) interagieren, verfügen über Netzwerkschnittstellen innerhalb der VPC, und alle anderen Lambda-Funktionen verfügen über Standard-Netzwerkkonnektivität. Der Kern APIs ist die unterste Interaktionsebene mit der Lösung. Andere Lambda-Funktionen, die Amazon Elastic Compute Cloud (Amazon EC2) -Instance und Container können als Erweiterungen fungieren und den Kern aufrufen, APIs um Warteräume einzurichten, den Eingangsverkehr zu kontrollieren und auf Ereignisse zu reagieren, die von der Lösung generiert werden.
Darüber hinaus erzeugt der Core-Stack einen Alarm für alle seine Lambda-Funktionsfehler und Drosselungsbedingungen sowie Alarme für jede API-Gateway-Bereitstellung für die 4XX- und 5XX-Statuscodes.
![\[Virtueller Warteraum im Diagramm der AWS öffentlichen und privaten Komponenten APIs\]](http://docs.aws.amazon.com/de_de/solutions/latest/virtual-waiting-room-on-aws/images/virtual-waiting-room-public-private-api-component.png)
1. CloudFront Die Distribution liefert öffentliche API-Aufrufe für den Client und speichert die Ergebnisse gegebenenfalls im Cache.
1. Die öffentliche API von Amazon API Gateway verarbeitet Warteschlangenanfragen aus dem virtuellen Warteraum, verfolgt die Warteschlangenposition und unterstützt die Validierung von Token, die den Zugriff auf die Zielwebsite ermöglichen.
1. Die SQS-Warteschlange reguliert den Verkehr zu der AWS Lambda Funktion, die die Warteschlangennachrichten verarbeitet.
1. Die `AssignQueueNum` Lambda-Funktion validiert jede Nachricht in ihrem empfangenen Batch, erhöht den Warteschlangenzähler in Elasticache (Redis OSS) und speichert jede Anfrage in Elasticache (Redis OSS) mit der zugehörigen Warteschlangenposition.
1. Die `GetPublicKey` Lambda-Funktion ruft den Wert des öffentlichen Schlüssels aus Secrets Manager ab.
1. Die `GenerateToken` Lambda-Funktion generiert ein JWT für eine gültige Anfrage, deren Transaktion am Zielstandort abgeschlossen werden durfte. Sie schreibt ein Ereignis in den benutzerdefinierten Event-Bus des Wartezimmers, dass ein Token generiert wurde. Wenn zuvor ein Token für diese Anfrage generiert wurde, wird kein neues Token generiert.
1. Die `GetQueueNumber` Lambda-Funktion ruft die numerische Position des Clients in der Warteschlange von Elasticache (Redis OSS) ab und gibt sie zurück.
1. Die `GetServingNumber` Lambda-Funktion ruft die Nummer, die derzeit vom Wartezimmer bedient wird, von Elasticache (Redis OSS) ab und gibt sie zurück.
1. Die `GetWaitingNum` Lambda-Funktion gibt die Nummer zurück, die sich derzeit im Wartezimmer befindet und für die noch kein Token ausgestellt wurde.
1. VPC-Endpunkte ermöglichen es Lambda-Funktionen in der VPC, mit Diensten innerhalb der Lösung zu kommunizieren.
1. Der Elasticache-Cluster (Redis OSS) speichert alle Anfragen zum Betreten des Warteraums mit einer gültigen Event-ID. Es speichert auch mehrere Zähler wie die Anzahl der Anfragen in der Warteschlange, die Anzahl der aktuell bearbeiteten Anfragen, die Anzahl der generierten Token, die Anzahl der abgeschlossenen Sitzungen und die Anzahl der abgebrochenen Sitzungen.
1. Private API-Ressourcen von API Gateway zur Unterstützung administrativer Funktionen. Die privaten APIs sind AWS IAM-authentifiziert.
1. Die `GetExpiredTokens` Lambda-Funktion gibt eine Liste von Anfragen IDs mit abgelaufenen Tokens zurück.
1. Die `AuthGenerateToken` Lambda-Funktion generiert ein Token für eine gültige Anfrage, die ihre Transaktion auf der Ziel-Site abschließen durfte. Der Aussteller und die Gültigkeitsdauer eines Tokens, die ursprünglich während der Core-Stack-Bereitstellung festgelegt wurden, können außer Kraft gesetzt werden. Es schreibt ein Ereignis in den benutzerdefinierten Event-Bus des Warteraums, dass ein Token generiert wurde. Wenn für diese Anfrage bereits ein Token generiert wurde, wird kein neues Token generiert.
1. Die `IncrementServingCounter` Lambda-Funktion erhöht den in Elasticache (Redis OSS) gespeicherten Bedienzähler des Wartezimmers, wenn er um einen Wert erhöht wird.
1. Die `GetNumActiveTokens` Lambda-Funktion fragt DynamoDB nach der Anzahl der Token ab, die noch nicht abgelaufen sind, nicht zum Abschluss der Transaktion verwendet wurden und nicht als verlassen markiert wurden.
1. Die `ResetState` Lambda-Funktion setzt alle in Elasticache (Redis OSS) gespeicherten Zähler zurück. Außerdem werden die ,- und `ServingCounterIssuedAt` DynamoDB-Tabellen `TokenTable` gelöscht und neu erstellt. `QueuePositionEntryTime` Darüber hinaus führt es eine Cache-Invalidierung durch. CloudFront
1. Die `UpdateSession` Lambda-Funktion aktualisiert den Status einer Sitzung (Token), die in der `TokenTable` DynamoDB-Tabelle gespeichert ist. Der Sitzungsstatus wird mit einer Ganzzahl angegeben. Sitzungen, die auf den Status gesetzt wurden, bedeuten abgeschlossen und `1` `-1` bedeutet, dass sie aufgegeben wurden. Es schreibt ein Ereignis in den benutzerdefinierten Event-Bus des Wartezimmers, dass eine Sitzung aktualisiert wurde.
1. In der `TokenTable` DynamoDB-Tabelle werden Token-Daten gespeichert.
1. In der `QueuePositionEntryTime` DynamoDB-Tabelle werden Daten zur Warteschlangenposition und zur Eintrittszeit gespeichert.
1. In der `ServingCounterIssuedAt` DynamoDB-Tabelle werden Aktualisierungen des Serving-Counter gespeichert.
1. Die `GetQueuePositionExpireTime` Lambda-Funktion wird aufgerufen, wenn der Client die Ablaufzeit der verbleibenden Warteschlangenposition anfordert.
1. Die `SetMaxQueuePositionExpired` Lambda-Funktion legt die maximale Warteschlangenposition fest, die abgelaufen ist, entsprechend den `ServingCounterIssuedAt` Tabellenwerten. Sie wird jede Minute ausgeführt, wenn der `IncrSvcOnQueuePositionExpiry` Parameter `true` während der Core-Stack-Bereitstellung auf eingestellt ist.
1. Die `GenerateEvents` Lambda-Funktion schreibt verschiedene Metriken für den Warteraum in den benutzerdefinierten Event-Bus des Wartezimmers. Sie wird jede Minute ausgeführt, wenn der Parameter Enable Events Generation `true` während der Core-Stack-Bereitstellung auf gesetzt ist.
1. AWS Secrets Manager speichert Schlüssel für Token-Operationen und andere sensible Daten.
1. Der EventBridge benutzerdefinierte Amazon Event Bus empfängt jedes Mal ein Ereignis, wenn ein Token generiert und eine Sitzung in der `TokenTable` DynamoDB-Tabelle aktualisiert wird. Es empfängt auch Ereignisse, wenn der Serving-Zähler im `SetMaxQueuePositionExpired` Lambda bewegt wird. Es wird mit verschiedenen Metriken für den Warteraum beschrieben, sofern es während der Core-Stack-Bereitstellung aktiviert wird.
1. Die CloudWatch Amazon-Ereignisregel wird erstellt, wenn der Parameter Enable Events Generation während der Core-Stack-Bereitstellung auf true gesetzt ist. Diese Ereignisregel initiiert jede Minute die `GenerateEvents` Lambda-Funktion.
## Authorizers
Die Lösung umfasst einen API Gateway Lambda Authorizer-Stack. Der Stack besteht aus einer IAM-Rolle und einer Lambda-Funktion. Die `APIGatewayAuthorizer` Lambda-Funktion ist ein Autorisierer für API Gateway, der die Signatur und die Ansprüche eines vom Virtual Waiting Room auf AWS der API ausgegebenen Tokens validieren kann. Die im Stack enthaltene Lambda-Funktion kann zum Schutz der Cloud verwendet werden, APIs bis ein Benutzer den Wartebereich durchquert hat und ein Zugriffstoken erhält. Der Autorisierer ruft den öffentlichen Schlüssel und die Konfiguration automatisch von der Kern-API ab und speichert sie im Cache, um das Token zu verifizieren. Es kann ohne Änderungen verwendet und in jeder AWS Region installiert werden, die dies unterstützt. AWS Lambda
## OpenID-Adapter
Der [OpenID-Adapter-Stack](https://github.com/aws-solutions/aws-virtual-waiting-room/blob/main/docs/developer-guide.md#open-id-adapter) stellt ein API Gateway und Lambda-Funktionen bereit, die als OpenID-Identitätsanbieter fungieren. Der OpenID-Adapter bietet eine Reihe von OIDC-kompatiblen Modulen APIs , die mit vorhandener Webhosting-Software, die OIDC-Identitätsanbieter unterstützt, wie AWS Elastic Load Balancers WordPress, oder als föderierter Identitätsanbieter für Amazon Cognito oder ähnliche Dienste verwendet werden können. Der Adapter ermöglicht es einem Kunden, den Warteraum im Authn/AuthZ-Flow zu nutzen, wenn er off-the-shelf Webhosting-Software mit eingeschränkten Integrationsoptionen verwendet. Der Stack installiert auch eine CloudFront Distribution mit einem Amazon S3 S3-Bucket als Ursprung und einem weiteren S3-Bucket für die Protokollierung von Anfragen. Der OpenID-Adapter stellt eine Beispielseite für einen Warteraum bereit, die der im Wartezimmer-Beispielstapel bereitgestellten Seite ähnelt, aber für einen OpenID-Authentifizierungsablauf konzipiert ist. Bei der Authentifizierung müssen Sie sich eine Position in der Warteschlange im Wartezimmer sichern und warten, bis die Servierposition gleich oder größer als die Warteschlangenposition des Kunden ist. Die OpenID-Warteraum-Seite leitet zurück zur Ziel-Site, die die OpenID-API verwendet, um die Token-Erfassung und die Sitzungskonfiguration für den Client abzuschließen. Die API-Endpunkte dieser Lösung sind direkt der offiziellen OpenID Connect 1.0-Flow-Spezifikation zugeordnet. name-for-name Einzelheiten finden Sie unter [OpenID Connect Core 1.0-Authentifizierung](https://openid.net/specs/openid-connect-core-1_0.html#Authentication).
![\[AWS Komponentendiagramm des OpenID-Adapters für virtuelle Wartezimmer\]](http://docs.aws.amazon.com/de_de/solutions/latest/virtual-waiting-room-on-aws/images/virtual-waiting-room-openid-adaptor-component.png)
1. CloudFront Die Verteilung stellt dem Benutzer den Inhalt des S3-Buckets zur Verfügung.
1. Der S3-Bucket hostet Beispielseiten für Wartezimmer.
1. Die Amazon API Gateway API bietet eine Reihe von OIDC-kompatiblen APIs APIs, die mit vorhandener Webhosting-Software verwendet werden können, die die Lambda-Autorisierungsfunktion des OIDC-Identitätsanbieters unterstützt.
1. Die `APIHandler` Lambda-Funktion verarbeitet Anfragen für alle API-Gateway-Ressourcenpfade. Verschiedene Python-Funktionen innerhalb desselben Moduls werden jedem API-Pfad zugeordnet. Beispielsweise wird der `/authorize` Ressourcenpfad in API Gateway `authorize()` innerhalb der Lambda-Funktion aufgerufen.
1. OIDC-Einstellungen werden im Secrets Manager gespeichert.
## Beispiele für Einlassstrategien
Inlet-Strategien legen fest, wann der Servierzähler der Lösung weiterentwickelt werden sollte, um mehr Benutzer am Zielstandort unterzubringen. Weitere konzeptionelle Informationen zu Strategien für den Zutritt in Wartezimmer finden Sie unter [Überlegungen zum Design](design-considerations.md).
Die Lösung bietet zwei Strategien für den Probeneingang: *MaxSize*und *Periodisch*.
![\[AWS Komponentendiagramm der Strategien für den Eintritt in virtuelle Wartezimmer\]](http://docs.aws.amazon.com/de_de/solutions/latest/virtual-waiting-room-on-aws/images/virtual-waiting-room-inlet-strategies-component.png)
Strategie-Option „Max. Größe“:
1. Ein Kunde gibt eine Amazon SNS SNS-Benachrichtigung aus, die die `MaxSizeInlet` Lambda-Funktion aufruft, um den Bereitstellungszähler basierend auf der Nachrichtennutzlast zu erhöhen.
1. Die `MaxSizeInlet` Lambda-Funktion erwartet den Empfang einer Nachricht, dass sie bestimmt, um wie viel der Serving-Zähler erhöht werden soll.
Strategieoption „Periodischer Eingang“:
1. Eine CloudWatch Regel ruft jede Minute eine Lambda-Funktion auf, um den Servierzähler um eine feste Menge zu erhöhen.
1. Die `PeriodicInlet` Lambda-Funktion erhöht den Leistungszähler um die angegebene Größe, wenn die Zeit zwischen der angegebenen Start- und Endzeit liegt. Optional überprüft sie einen CloudWatch Alarm und führt, falls der Alarm aktiv ist, die Erhöhung `OK` durch, andernfalls überspringt sie sie.
## Beispiel für ein Wartezimmer
Der Musterwarteraum lässt sich zusätzlich zum benutzerdefinierten Authorizer APIs in den öffentlichen und privaten Bereich integrieren, um zu demonstrieren, dass die end-to-end Wartezimmerlösung auf ein Minimum beschränkt ist. Die Hauptwebseite wird in einem S3-Bucket gespeichert und als Quelle für CloudFront verwendet. Sie führt den Benutzer durch die folgenden Schritte:
1. Stellen Sie sich im Wartezimmer in die Warteschlange, um die Website zu betreten.
1. Ermitteln Sie die Position des Kunden in der Schlange.
1. Besorgen Sie sich die Servierposition des Wartezimmers.
1. Besorgen Sie sich ein Token-Set, sobald die Servierposition der Position des Kunden entspricht oder größer ist.
1. Verwenden Sie das Token, um eine API aufzurufen, die durch den Lambda-Authorizer geschützt ist.
![\[Beispiel für ein virtuelles Wartezimmer: Komponentendiagramm für einen Eventstandort\]](http://docs.aws.amazon.com/de_de/solutions/latest/virtual-waiting-room-on-aws/images/virtual-waiting-room-sample-event-site-component.png)
1. Der S3-Bucket hostet den Beispielinhalt für den Warteraum und das Control Panel.
1. CloudFront Die Verteilung stellt dem Benutzer den Inhalt des S3-Buckets zur Verfügung.
1. Beispiel für eine API Gateway Gateway-Bereitstellung mit Einkaufsähnlichen Ressourcenpfaden wie und. `/search` `/checkout` Diese API wird vom Stack installiert und mit dem Token-Authorizer konfiguriert. Es ist als Beispiel für eine einfache Möglichkeit gedacht, eine API mit dem Wartezimmer zu schützen. Anfragen, die ein gültiges Token vorlegen, werden an das Lambda weitergeleitet, andernfalls wird ein Fehler zurückgegeben. Die API enthält keine andere Funktionalität als die Antwort der angehängten Lambda-Funktion.