SQS Timeout von Lambda innerhalb von VPC
Ich habe ein Lambda, das sich auf einer VPC befinden muss, um mit geschützten Ressourcen wie RDS und AWSDocumentDB zu kommunizieren. Es muss auch in der Lage sein, die Außenwelt für einige Aufrufe von APIs von Drittanbietern zu sehen. Zu diesem Zweck habe ich mit dem VPC-Assistenten eine VPC erstellt, die sowohl öffentliche als auch private Subnetze enthält. Der Assistent hat auch ein Internet-Gateway erstellt und angeschlossen.
Danach habe ich meine Lambda, RDS-Instanz und den DocumentDb-Cluster an die VPC angeschlossen. Seitdem konnte ich jedoch mit dem NodeJS aws-sdk nicht mehr mit meinen SQS-Warteschlangen aus meinem Lambda heraus kommunizieren.
Ich möchte hinzufügen, dass ich einige Punkte gelesen und implementiert habe von: AWS Lambda: Ich kann nicht über eine Lambda-Funktion mit VPC-Zugriff auf die SQS-Warteschlange zugreifen, kann jedoch immer noch keine Verbindung herstellen.
Folgendes habe ich:
VPC:
- VPC verfügt über öffentliche und private Subnetze sowie ein IG-Gateway. Ich habe den Assistenten verwendet, um es zu erstellen. Ich verstehe hier nicht viel von den Grundlagen.
- VPC-Konfiguration (Entschuldigung, es ist ein Link, ich kann ihn noch nicht einbetten.)
- CIDRs - der Assistent hat alle bis auf den letzten Block erstellt. Ich bin mir nicht sicher, ob ich dies richtig gemacht habe oder ob es überhaupt wichtig ist, da der Assistent mich dazu gebracht hat, mindestens eine zu erstellen, und ich habe dies getan, um IP-Überlappungen zu vermeiden.
- Da es sich um ein Entwicklungs- / Prototypprojekt handelt, ist die an die VPC angeschlossene Sicherheitsgruppe "weit offen". Alle eingehenden und ausgehenden sind erlaubt.
- Lassen Sie mich wissen, welche andere VPC-Konfiguration angezeigt werden soll, da ich nicht sicher bin, was nützlich ist
Service-Endpunkt:
- Ich habe versucht, einen Service-Endpunkt für SQS gemäß dem oben verlinkten Artikel zu erstellen. Folgendes habe ich: Endpunktkonfiguration
- Ich werde im Abschnitt Lambda mehr darüber sprechen, wie ich das konsumiere.
- Der Endpunkt ist an die VPC angeschlossen
Lambda:
- Ich habe den Lambda wie hier gezeigt an die VPC angeschlossen .
- Auf diese Weise kann ich mit öffentlichen APIs von Drittanbietern und meinen geschützten Ressourcen sprechen. Ich hatte die Hoffnung, dass mein Lambda mit einer weit geöffneten SG immer noch mit SQS sprechen kann, aber das Timing läuft weiter.
- Ich bin mir nicht sicher, welche URL ich in meinem Lambda für meinen Endpunkt verwenden soll. Das Beispiel hier:https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-sending-messages-from-vpc.html Es sieht so aus, als würde immer noch der regionale Endpunkt verwendet.
Code
So sieht der SQS-Aufruf in meinem Code aus:
-
const {SQS} = require('aws-sdk'); // Constructor Init const sqs = new SQS({ apiVersion: '2012-11-05', endpoint: 'https://sqs.us-west-2.amazonaws.com', // not sure if this is 'invoking' the vpc endpoint or not region: 'us-west-2' }); // Send message await sqs.sendMessage({ MessageBody: 'Test body', QueueUrl: 'https://sqs.us-west-2.amazonaws.com/<rest of URI>', MessageAttributes: {...someAttrs} }).promise();
-
Schätzen Sie jede Hilfe, bitte lassen Sie mich wissen, welche anderen Informationen ich bereitstellen kann.
Vielen Dank!
** Bearbeiten **
Ich sollte auch erwähnen, dass ich, um dieses ganze Problem zu umgehen, begann, SQS als Lambda-Ziel zu verwenden. Dies fügt zwar Nachrichten in die Zielwarteschlange ein, lässt sich jedoch wahrscheinlich nicht mit meinem Anwendungsfall skalieren. Ich kann bei Bedarf weiter darauf eingehen, da es für die eigentliche Frage nicht ganz relevant ist.
** EDIT 31.08.20 **
Vielen Dank für alle Antworten, es war eine große Hilfe und brachte mich zu einer Lösung. Ich werde sagen, dass jeder, der diesen Beitrag findet, zuerst zuschauen muss:
https://www.youtube.com/watch?v=JcRKdEP94jM
Ich wünschte, ich hätte dies gefunden, bevor ich mit all dem angefangen habe, da es zwar speziell darauf abzielt, Lambdas Internetzugang zu gewähren, aber den Prozess der Zuordnung von IGs und Nats zu Subnetzen durchläuft, bei dem ich meinen VPC wirklich falsch konfiguriert habe. Mit diesem Video habe ich meine gesamte VPC neu erstellt und es ist so viel sauberer und einfacher, die Punkte zu verbinden. 10/10 empfehlen.
Danke noch einmal!
Antworten
Meine Vermutung in diesem Fall ist, dass irgendwo in Ihrer Netzwerkkonfiguration eine Regel fehlt - Pakete werden entweder in Richtung Ihres SQS oder auf dem Rückweg abgelegt (beide müssen Hop für Hop durchdacht werden).
Die drei Dinge, die mir in den Sinn kommen:
- Routing: Stellen Sie sicher, dass die Subnetze und Routing-Tabellen über geeignete Routen verfügen, um Pakete von dem SQS-Endpunkt zurück in Ihr privates Subnetz zu bringen.
- Sicherheitsgruppen - Sehen Sie sich jede betroffene SG genau an. Der SQS kann sich beispielsweise in einem SG befinden, der den Zugriff darauf einschränkt.
- Netzwerk-ACLs - Diese sind zustandslos. Sie müssen daher sicherstellen, dass beide Seiten geöffnet sind, und sich daran erinnern, dass die meiste Zeit zufällige Portnummern an den Anforderer zurückgegeben werden.
Viel Glück!
Die AWS Lambda-Funktion sollte an ein privates Subnetz in der VPC angeschlossen sein.
Amazon SQS lebt im Internet, daher benötigt die Lambda-Funktion eine Möglichkeit, auf den SQS-Endpunkt zuzugreifen.
Option 1: VPC-Endpunkt
Ein VPC-Endpunkt für Amazon SQS kann eine direkte Verbindung zwischen einer VPC und dem SQS-Endpunkt herstellen, ohne dass ein Internetzugang erforderlich ist. Nach der Erstellung sendet die VPC automatisch SQS-Anforderungen über den VPC-Endpunkt. Dies ist eine schöne, einfache Option.
Option 2: NAT-Gateway
Wenn Sie über zusätzliche Ressourcen in den privaten Subnetzen verfügen, für die ein Internetzugang erforderlich ist, können Sie ein NAT-Gateway in einem öffentlichen Subnetz platzieren . Die privaten Subnetze benötigen einen Routentabelleneintrag, der den internetgebundenen Verkehr ( 0.0.0.0/0) zum NAT-Gateway leitet .
Es fallen zusätzliche Gebühren an.
Option 3: Lambda-Ziel
Wenn die Lambda-Funktion das SQS erfolgreich über ein Lambda-Ziel kommuniziert, ist dies eine hervorragende Option ! Ich habe es nicht ausprobiert, aber es scheint, dass der Lambda-Dienst dafür verantwortlich ist, die Ausgabe direkt an SQS zu senden, ohne die VPC oder das Internet durchlaufen zu müssen. Wenn dies funktioniert, empfehle ich dringend, es weiter zu verwenden. Mit dieser Methode sehe ich keine Skalierungsprobleme. Beachten Sie jedoch, dass dies nur für asynchrone Aufrufe von Lambda funktioniert und beispielsweise nicht funktioniert, wenn Sie die Funktion synchron aufrufen oder die Test- Taste drücken.