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.
# Multi-Region Einsatz
Für **MultiRegion**PerRegion****Endgeräte repliziert Lambda Laufzeitartefakte in alle Zielregionen, sodass Ihre Anwendung den Datenverkehr in der Nähe von Endbenutzern bereitstellen kann. Sie verwalten die Webfunktion vollständig von der Heimatregion aus. Replizierte Ressourcen sind in Replikatregionen weder sichtbar noch änderbar.
Das folgende Diagramm zeigt, wie die Steuerungsebene in der Heimatregion eine Revision vorbereitet und deren Code und Konfiguration in eine Replikatregion repliziert, und zeigt, wie Clients Endpunkte erreichen. **MultiRegion**PerRegion**** Eine Replikatregion hat keine Steuerungsebene. Ein **MultiRegion**Endpunkt hat eine globale Domäne, die nach Latenz und nicht nach dem Zustand der Region weiterleitet. Für einen **PerRegion**Endpunkt verwalten Sie, wie Clients die regionale Domäne in jeder Region erreichen, z. B. mit Route 53-Datensätzen oder CloudFront. Sie legen den Endpunkttyp und die Regionen fest, wenn Sie den Endpunkt erstellen, und Sie können sie später nicht mehr ändern.
**Topics**
+ [Was Lambda repliziert](#web-functions-endpoint-replication-what)
+ [Sichtbarkeit von Replikaten](#web-functions-endpoint-replication-visibility)
+ [Wenn die Replikation stattfindet](#web-functions-endpoint-replication-trigger)
+ [Funktionsweise der Weiterleitung](#web-functions-endpoint-replication-routing)
+ [Replikationsfehler](#web-functions-endpoint-replication-failure)
+ [Letztendliche Datenkonsistenz](#web-functions-endpoint-replication-consistency)
## Was Lambda repliziert
Lambda repliziert Folgendes in jede Zielregion:
+ **Vorbereitetes Codeartefakt** — Das interne Laufzeitartefakt, das Lambda aus dem versionierten Amazon S3 S3-Quellobjekt ableitet.
+ **Revisionskonfiguration** — Timeout, Parallelität, Umgebungsvariablen und Laufzeiteinstellungen.
+ **Resource-based Richtlinien** — Mit der Webfunktion verknüpfte Richtlinien, die Zugriff auf die Webfunktion gewähren.
+ **Tags** — Die Tags der Webfunktion.
Kontingente für Webfunktionen gelten pro AWS-Region. Jede Zielregion erzwingt ihre eigenen Kontokontingente auf dem replizierten Endpunkt. Beispielsweise ist die Skalierung der Ausführungsumgebung in einer Replikatregion durch das vCPU-Kontingent dieser Region begrenzt. Informationen zu den Kontenkontingenten finden Sie unter. [Kontingente](web-functions-scaling.md#web-functions-scaling-quotas)
## Sichtbarkeit von Replikaten
Replizierte Ressourcen sind in **Replikatregionen nicht sichtbar**. Die Steuerungsebene für eine Webfunktion wird nur in ihrer Heimatregion bedient, sodass alle API-Anfragen an die Heimatregion gesendet werden müssen. Dies umfasst:
+ Listet Anfragen für die Webfunktion, ihre Versionen und ihre Endpunkte auf, ruft sie ab und beschreibt sie.
+ Erstellen, aktualisieren und löschen Sie Anfragen für die Funktion, die Revisionen und die Endpunktkonfiguration.
Eine API-Anfrage, die an den Endpunkt der Kontrollebene einer Replikatregion gesendet wird, schlägt fehl, unabhängig davon, wo sich der Aufrufer befindet. Die replizierten Laufzeitartefakte existieren nur für die Datenebene, um den Datenverkehr zu verarbeiten.
## Wenn die Replikation stattfindet
Die Replikation wird ausgelöst, wenn Sie einen **PerRegion**OR-Endpunkt erstellen **MultiRegion**oder aktualisieren. Insbesondere findet die Replikation statt, wenn:
+ Sie erstellen einen MultiRegion PerRegion OR-Endpunkt, dessen Revisionsgewichte auf eine Revision verweisen.
+ Sie aktualisieren die Revisionsgewichte an einem MultiRegion PerRegion OR-Endpunkt, um eine neue Revision einzubeziehen.
+ Sie aktualisieren andere Endpunkteinstellungen, z. B. `authType``scalingConfig`, oder`throttleConfig`, auf einem MultiRegion PerRegion OR-Endpunkt.
Das Erstellen einer Revision allein löst keine Replikation aus. Die Revision muss in den Revisionsgewichten eines Endpunkts enthalten sein, für den Zielregionen konfiguriert sind. Da für MultiRegion PerRegion Endpoints nur der Modus **Deaktivierte** automatische Bereitstellung verfügbar ist, ist die Replikation immer das Ergebnis einer von Ihnen vorgenommenen Endpunktänderung.
## Funktionsweise der Weiterleitung
Das Routing-Verhalten hängt vom Endpunkttyp ab:
**MultiRegion**
Lambda bietet einen einzigen globalen Domainnamen. Anfragen werden mithilfe von latenzbasiertem Routing weitergeleitet. Anfragen werden an die Region weitergeleitet, die in der Regel die niedrigste Netzwerklatenz für den Anrufer bietet, basierend auf Latenzmessungen, die Route 53 im Laufe der Zeit sammelt. Da sich die Internetlatenz ändert, garantiert Lambda nicht, dass jede Anfrage an die Region mit der niedrigsten Latenz gesendet wird. Lambda verwaltet automatisch Routen für Sie.
**PerRegion**
Lambda stellt in jeder Zielregion einen separaten regionalen Domainnamen bereit. Sie sind dafür verantwortlich, zu verwalten, wie der Traffic jede regionale Domain erreicht. Sie können beispielsweise Ihre eigene Route 53-Routing-Richtlinie konfigurieren oder eine CloudFront Verteilung vor den regionalen Domänen platzieren.
## Replikationsfehler
Die Replikation kann in einer Region aufgrund eines vorübergehenden Dienstproblems fehlschlagen. Wenn Sie Ihre Webfunktion mit einem vom Kunden verwalteten Schlüssel verschlüsseln, führt ein fehlendes Schlüsselreplikat in der Zielregion ebenfalls dazu, dass die Replikation fehlschlägt. Informationen zu den wichtigsten Anforderungen für mehrere Regionen finden Sie unter. [Konfiguration eines vom Kunden verwalteten Schlüssels](web-functions-encryption.md#web-functions-encryption-key-requirements)
Die Auswirkungen eines Replikationsfehlers hängen davon ab, ob Sie den Endpunkt erstellen oder aktualisieren. Wenn die Replikation in einer Region fehlschlägt, während Lambda den Endpunkt erstellt, wechselt der Endpunkt in den Status **Fehlgeschlagen** und kann in keiner Region aufgerufen werden. Um es erneut zu versuchen, löschen Sie den Endpunkt und erstellen Sie ihn erneut. Wenn die Replikation in einer Region während eines Endpunkt-Updates fehlschlägt, ist der Fehler auf diese Region beschränkt. Der Endpunkt bleibt aufrufbar und die anderen Regionen funktionieren weiterhin normal.
Wenn die Replikation einer neuen Version in einer Region fehlschlägt, stellt diese Region weiterhin Datenverkehr mit der vorherigen Version bereit, die erfolgreich bereitgestellt wurde. Der Endpunkt führt kein Rollback durch. Er arbeitet weiterhin mit dem letzten als funktionierend bekannten Status in jeder Region.
Sie können den Status jeder Region einsehen und den Status im `regionalEndpoints` `GetWebFunctionEndpoint` Antwortfeld aktualisieren. Der Eintrag jeder Region beinhaltet:
+ `state`und `stateReason` — Der Bereitstellungsstatus der Region während der Endpunkterstellung.
+ `updateStatus`und `updateStatusReason` — Das Ergebnis des letzten Updates (z. B. einer Revisionsbereitstellung) für diese Region.
Um einen Replikationsfehler zu beheben, beheben Sie die Ursache (erstellen Sie beispielsweise ein AWS KMS Schlüsselreplikat in der betroffenen Region). Rufen `UpdateWebFunctionEndpoint` Sie erneut auf, um ein fehlgeschlagenes Endpunkt-Update zu wiederholen, nachdem Sie die Ursache behoben haben. Sie können dieselben Einstellungen wiederholen oder nur den Funktions- und Endpunktnamen angeben. Bei beiden Anfragen wird eine neue Bereitstellung in den Zielregionen gestartet. Dies funktioniert nur, solange der Endpunkt **aktiv** ist. Wenn die Endpunkterstellung fehlgeschlagen ist, löschen Sie den Endpunkt und erstellen Sie ihn erneut.
## Letztendliche Datenkonsistenz
Die Replikation von Laufzeitartefakten ist letztendlich konsistent. Gehen Sie nicht davon aus, dass jede Region die neue Konfiguration ausführt, bis jede Region `updateStatus` in `regionalEndpoints` Berichten aufgeführt ist`Successful`.
Resource-based Nach Code- und Konfigurationsänderungen kann die Übertragung von Richtlinienänderungen beendet werden. Während des Replikationsfensters werden Anfragen in Replikatregionen möglicherweise mit der vorherigen Version der Richtlinie verglichen. Weitere Informationen finden Sie unter [Replikation und letztendliche Konsistenz](web-functions-permissions.md#web-functions-permissions-resource-policy-replication).