Délai d'expiration SQS de Lambda dans VPC

Question

J'ai un Lambda qui doit être sur un VPC pour parler à des ressources protégées telles que RDS et AWSDocumentDB. Il doit également être capable de voir le monde extérieur pour certains appels vers des API tierces. Pour ce faire, j'ai utilisé l'assistant VPC pour créer un VPC comportant à la fois des sous-réseaux publics et privés. L'assistant a également créé et attaché une passerelle Internet.

Après cela, j'ai attaché mon Lambda, mon instance RDS et mon cluster DocumentDb au VPC. Depuis lors, cependant, je n'ai pas pu parler à mes files d'attente SQS depuis mon lambda en utilisant le NodeJS aws-sdk.

Je veux ajouter que j'ai lu et mis en œuvre certains points de: AWS Lambda: impossible d'accéder à la file d'attente SQS à partir d'une fonction Lambda avec accès au VPC, mais je ne parviens toujours pas à me connecter.

Voici ce que j'ai:

1. VPC:

   • Le VPC a des sous-réseaux publics et privés et une passerelle IG. J'ai utilisé l'assistant pour le créer. Je ne comprends pas grand-chose des fondements ici.
   • VPC Config (désolé, c'est un lien, il ne me permettra pas encore de l'intégrer.)
   • CIDR - l'assistant a créé tout sauf le dernier bloc. Je ne sais pas si j'ai bien fait ou si cela compte, car l'assistant m'a fait en créer au moins un et je l'ai fait pour éviter le chevauchement d'adresses IP.
   • Comme il s'agit d'un projet de développement / prototype, le groupe de sécurité attaché au VPC est «grand ouvert». Tout entrant et sortant est autorisé.
   • Faites-moi savoir quelle autre configuration VPC afficher car je ne suis pas sûr de ce qui est utile

2. Point de terminaison de service:

   • J'ai essayé de créer un point de terminaison de service pour SQS par l'article lié ci-dessus, voici ce que j'ai: configuration de point de terminaison
   • Je parlerai plus en détail de la façon dont je consomme cela dans la section Lambda.
   • Le point de terminaison est attaché au VPC

3. Lambda:

   • J'ai le Lambda attaché au VPC comme indiqué ici .
   • Cela me permet de parler aux API publiques tierces et à mes ressources protégées. J'espérais qu'avoir une SG largement ouverte permettrait toujours à mon lambda de parler à SQS, mais cela n'arrête pas de tourner.
   • Je ne sais pas quelle URL utiliser dans mon Lambda pour mon point de terminaison. L'exemple ici:https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-sending-messages-from-vpc.html semble qu'il utilise toujours le point de terminaison régional.

4. Code

   • Voici à quoi ressemble l'invocation SQS à partir de mon code:

     • 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();
       
       
       
       

J'apprécie toute aide, s'il vous plaît laissez-moi savoir quelles autres informations je peux fournir.

Merci!

** Éditer **

Je dois également mentionner que pour contourner tout ce problème, j'ai commencé à utiliser SQS comme destination Lambda. Bien que cela injecte des messages dans la file d'attente cible, il ne sera probablement pas mis à l'échelle avec mon cas d'utilisation. Je peux développer cela plus en détail si nécessaire, car cela n'est pas totalement pertinent pour la question réelle.

** MODIFIER LE 31/08/20 **

Merci pour toutes les réponses, cela a été d'une grande aide et m'a amené à une résolution. Je dirai que quiconque trouve ce message doit d'abord regarder:

https://www.youtube.com/watch?v=JcRKdEP94jM

C'est quelque chose que j'aimerais trouver avant de commencer tout cela car, bien qu'il vise spécifiquement à donner un accès Internet lambdas, cela passe par le processus de mappage d'IG et de Nats sur des sous-réseaux, ce qui est vraiment l'endroit où j'ai mal configuré mon vpc. Avec cette vidéo, je suis allé recréer tout mon VPC et il est tellement plus propre et plus facile de relier les points. 10/10 recommandent.

Merci encore!

Answer 1

Mon intuition à ce sujet est qu'il y a une règle manquante quelque part dans votre configuration réseau - les paquets sont abandonnés soit vers votre SQS, soit sur le chemin du retour (les deux doivent être réfléchis saut par point).

Les trois choses qui me viennent à l'esprit:

1. Routage: assurez-vous que les sous-réseaux et les tables de routage ont des routes appropriées pour récupérer les paquets vers votre sous-réseau privé à partir de celui où se trouve le point de terminaison SQS.
2. Groupes de sécurité - Regardez attentivement chaque SG impliqué. Le SQS peut être dans un SG qui en restreint l'accès, par exemple.
3. ACL réseau - elles sont sans état, vous devrez donc vous assurer que les deux côtés sont ouverts, et rappelez-vous que la plupart du temps, il y aura des numéros de port aléatoires qui retournent au demandeur.

Bonne chance!

Answer 2

La fonction AWS Lambda doit être attachée à un sous-réseau privé dans le VPC.

Amazon SQS vit sur Internet, la fonction Lambda a donc besoin d'un moyen d'accéder au point de terminaison SQS.

Option 1: point de terminaison VPC

Un point de terminaison VPC pour Amazon SQS peut fournir un lien direct entre un VPC et le point de terminaison SQS, sans nécessiter un accès Internet. Une fois créé, le VPC enverra automatiquement des demandes SQS à travers le point de terminaison du VPC. C'est une option simple et agréable.

Option 2: passerelle NAT

Si vous disposez de ressources supplémentaires dans le ou les sous-réseaux privés qui nécessitent un accès Internet, vous pouvez envisager de placer une passerelle NAT dans un sous-réseau public . Le ou les sous-réseaux privés auront besoin d'une entrée de table de routage qui dirige le trafic Internet ( 0.0.0.0/0) vers la passerelle NAT.

Des frais supplémentaires s'appliquent.

Option 3: Destination Lambda

Si la fonction Lambda communique avec succès le SQS via une destination Lambda, cela semble être une excellente option ! Je ne l'ai pas essayé, mais il semble que le service Lambda soit responsable d'envoyer la sortie directement à SQS, sans avoir à traverser le VPC ou Internet. Si cela fonctionne, je recommande vivement de continuer à l'utiliser. Je ne perçois aucun problème de mise à l'échelle avec cette méthode. Cependant, veuillez noter que cela ne fonctionne que pour les appels asynchrones à Lambda et ne fonctionnera pas, par exemple, lors de l'appel de la fonction de manière synchrone ou en appuyant sur le bouton Test .