SQS Timeout z Lambda w VPC
Mam Lambdę, która musi znajdować się na VPC, aby rozmawiać z chronionymi zasobami, takimi jak RDS i AWSDocumentDB. Musi także widzieć świat zewnętrzny w przypadku niektórych wywołań interfejsów API innych firm. Aby to zrobić, użyłem kreatora VPC, aby utworzyć VPC, które zawierało zarówno publiczne, jak i prywatne podsieci. Kreator utworzył również i dołączył bramę internetową.
Następnie podłączyłem do VPC moją instancję Lambda, RDS i klaster DocumentDb. Jednak od tego czasu nie mogę rozmawiać z moimi kolejkami SQS z poziomu mojej lambdy przy użyciu NodeJS aws-sdk.
Chcę dodać, że przeczytałem i zaimplementowałem kilka punktów z: AWS Lambda: Nie można uzyskać dostępu do kolejki SQS z funkcji Lambda z dostępem do VPC, ale nadal nie mogę się połączyć.
Oto co mam:
VPC:
- VPC ma publiczne i prywatne podsieci oraz bramę IG. Użyłem kreatora, aby go stworzyć. Nie rozumiem tu zbyt wielu podstaw.
- Konfiguracja VPC (przepraszam, że to link, nie pozwala mi jeszcze na osadzenie).
- CIDR - kreator utworzył wszystkie bloki oprócz ostatniego. Nie jestem pewien, czy zrobiłem to dobrze, czy w ogóle ma to znaczenie, ponieważ kreator kazał mi utworzyć co najmniej jedną i zrobiłem to, aby uniknąć nakładania się adresów IP.
- Ponieważ jest to projekt deweloperski / prototypowy, grupa bezpieczeństwa dołączona do VPC jest „szeroko otwarta”. Wszystkie połączenia przychodzące i wychodzące są dozwolone.
- Daj mi znać, jakie inne konfiguracje VPC mają być wyświetlane, ponieważ nie wiem, co jest przydatne
Punkt końcowy usługi:
- Próbowałem utworzyć punkt końcowy usługi dla SQS zgodnie z powyższym artykułem, oto co mam: konfiguracja punktu końcowego
- Powiem więcej o tym, jak konsumuję to w sekcji Lambda.
- Punkt końcowy jest dołączony do VPC
Lambda:
- Mam Lambdę dołączoną do VPC, jak pokazano tutaj .
- Dzięki temu mogę rozmawiać z publicznymi interfejsami API innych firm i moimi chronionymi zasobami. Miałem nadzieję, że posiadanie szeroko otwartego SG nadal pozwoli mojej lambdzie na rozmowę z SQS, ale nadal upływa limit czasu.
- Nie jestem pewien, którego adresu URL użyć w mojej Lambdzie dla mojego punktu końcowego. Przykład tutaj:https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-sending-messages-from-vpc.html wygląda na to, że nadal używa regionalnego punktu końcowego.
Kod
Oto jak wygląda wywołanie SQS w moim kodzie:
-
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();
-
Doceniam każdą pomoc, proszę o informację, jakich innych informacji mogę udzielić.
Dzięki!
** Edytować **
Powinienem też wspomnieć, że aby obejść ten cały problem, zacząłem podążać drogą wykorzystania SQS jako Lambda Destination. Chociaż powoduje to wstrzyknięcie komunikatów do kolejki docelowej, prawdopodobnie nie będzie skalowane w moim przypadku użycia. W razie potrzeby mogę to rozwinąć, ponieważ nie jest to całkowicie związane z faktycznym pytaniem.
** EDYCJA 31.08.20 **
Dzięki za wszystkie odpowiedzi, była to wielka pomoc i doprowadziła mnie do rozwiązania. Powiem, że każdemu, kto znajdzie ten post, powinien najpierw obejrzeć:
https://www.youtube.com/watch?v=JcRKdEP94jM
To jest coś, co chciałbym znaleźć, zanim zacząłem to wszystko, ponieważ, chociaż jest to specjalnie ukierunkowane na zapewnienie dostępu do Internetu lambd, przechodzi przez proces mapowania IG i Nats do podsieci, co jest naprawdę miejscem, w którym źle konfigurowałem mój VPN. W tym filmie odtworzyłem cały mój VPC i łączenie kropek jest o wiele czystsze i łatwiejsze. 10/10 polecam.
Dzięki jeszcze raz!
Odpowiedzi
Moje przeczucie jest takie, że gdzieś w twojej konfiguracji sieci brakuje reguły - pakiety są porzucane albo w kierunku twojego SQS, albo w drodze powrotnej (oba wymagają przemyślenia krok po kroku).
Trzy rzeczy, które przychodzą mi do głowy:
- Routing: upewnij się, że podsieci i tabele routingu mają odpowiednie trasy, aby odebrać pakiety z powrotem do prywatnej podsieci z tej, w której znajduje się punkt końcowy SQS.
- Grupy bezpieczeństwa - przyjrzyj się uważnie każdemu zaangażowanemu SG. SQS może znajdować się na przykład w SG, który ogranicza dostęp do niego.
- Sieciowe listy ACL - są bezstanowe, więc musisz upewnić się, że obie strony są otwarte i pamiętać, że przez większość czasu będą losowe numery portów związane z powrotem do żądającego.
Powodzenia!
Funkcję AWS Lambda należy dołączyć do prywatnej podsieci w VPC.
Amazon SQS żyje w Internecie, więc funkcja Lambda potrzebuje sposobu na dostęp do punktu końcowego SQS.
Opcja 1: punkt końcowy VPC
Punkt końcowy VPC dla Amazon SQS może zapewnić bezpośrednie połączenie między VPC a punktem końcowym SQS bez konieczności dostępu do Internetu. Po utworzeniu VPC automatycznie wysyła żądania SQS przez punkt końcowy VPC. To fajna, prosta opcja.
Opcja 2: Brama NAT
Jeśli masz dodatkowe zasoby w prywatnych podsieciach, które wymagają dostępu do Internetu, możesz rozważyć umieszczenie bramy NAT w publicznej podsieci . Prywatne podsieci będą potrzebować wpisu tablicy tras, który kieruje ruch internetowy ( 0.0.0.0/0) do bramy NAT.
Obowiązują dodatkowe opłaty.
Opcja 3: Miejsce docelowe Lambda
Jeśli masz funkcję Lambda z powodzeniem komunikującą się SQS za pośrednictwem miejsca docelowego Lambda, to brzmi to jak doskonała opcja ! Nie próbowałem tego, ale wygląda na to, że usługa Lambda jest odpowiedzialna za wysyłanie wyjścia bezpośrednio do SQS, bez konieczności przechodzenia przez VPC lub Internet. Jeśli to działa, zdecydowanie zalecam dalsze korzystanie z niego. Nie widzę problemów ze skalowaniem tą metodą. Należy jednak pamiętać, że działa to tylko dla asynchronicznych wywołań Lambdy i nie będzie działać, na przykład, podczas wywoływania funkcji synchronicznie lub po naciśnięciu przycisku Test .