Messaging-Latenz: AWS European Sovereign Cloud vs. Frankfurt im Test
Nicolai Lang
Ich helfe Teams, zuverlässige und kosteneffiziente Cloud-Systeme auf AWS produktionsreif umzusetzen.
Ich habe einen kleinen Latency Checker gebaut und ihn parallel in der AWS European Sovereign Cloud und in der globalen AWS eu-central-1 (Frankfurt) Region laufen lassen. Gemessen habe ich die Delivery-Latenz für EventBridge, SNS, SQS Standard und SQS FIFO.
Das Test-Setup besteht aus einer regelmäßig getriggerten Producer-Lambda, die Nachrichten mit dem aktuellen Zeitstempel über den jeweiligen Messaging-Service verschickt und einer Consumer-Lambda die diese empfängt und die verstrichene Zeit auswertet. Der Wert beinhaltet also auch das Versenden aus der Lambda über die jeweilige AWS API. Daher der Vollständigkeit halber: NodeJS 24 Runtime, 512 MB Memory. Die Consumer Lambda verwirft Metriken im Falle von Kaltstarts und schreibt ansonsten die Dauer über das Embedded Metric Format nach CloudWatch. Aufgebaut natürlich als kleines CDK Projekt und deployed in die genannten Regionen.
Die Latenzen liegen gleichauf
Bei vergleichbarer Last bewegen sich beide Regionen im selben Bereich. Zufällig ausgewählter Snapshot vom 14.06. um 04:00 UTC:
| Dienst | Sovereign Cloud | Frankfurt |
|---|---|---|
| EventBridge | 185 ms | 156 ms |
| SNS | 115 ms | 120 ms |
| SQS Standard | 49 ms | 37 ms |
| SQS FIFO | 27 ms | 28 ms |
SNS und SQS FIFO decken sich. EventBridge und SQS Standard liegen im Snapshot in der Sovereign Cloud etwas höher. Alles in allem bewegen sich die beiden Regionen aber in derselben Größenordnung.
Frankfurt drosselt bei wenig Traffic
Eine interessantere Beobachtung zeigt sich bei niedrigem Durchsatz. In beiden Regionen lief der Checker zunächst mit 10 Nachrichten pro Minute. Nach kurzer Zeit klettern die SQS-Latenzen in Frankfurt auf 350 bis 400 ms. Eine Erhöhung auf 40 Nachrichten pro Minute in Frankfurt ließ sie zurück auf rund 30 ms fallen.
Hier sieht man, dass die AWS managed Poller des Lambda Event-Source-Mapping für SQS bei geringer Last herunterskalieren und dadurch die Latenz steigt.
In der Sovereign Cloud konnte ich diesen Effekt nicht beobachten. Dort lief der Checker durchgehend mit 10 Nachrichten pro Minute, und die Latenz bleibt dauerhaft auf dem gleichen Niveau.
Fazit
Die European Sovereign Cloud hält bei der Messaging-Latenz mit Frankfurt mit. Bei niedrigem Durchsatz ist sie aktuell sogar im Vorteil, weil die Poller hier (noch) nicht gedrosselt werden. Ob das dauerhaft so bleibt, muss sich zeigen. Sollte ich eine Änderung feststellen, werde ich diesen Artikel aktualisieren.