Tempo limite SQS do Lambda dentro de VPC
Tenho um Lambda que precisa estar em um VPC para se comunicar com recursos protegidos como RDS e AWSDocumentDB. Ele também precisa ser capaz de ver o mundo externo para algumas chamadas para APIs de terceiros. Para fazer isso, usei o assistente de VPC para criar uma VPC que tinha sub-redes públicas e privadas. O assistente também criou e anexou um Gateway de Internet.
Depois disso, anexei meu Lambda, instância RDS e cluster DocumentDb ao VPC. Desde então, no entanto, não consigo falar com minhas filas SQS de dentro de meu lambda usando o NodeJS aws-sdk.
Quero acrescentar que li e implementei alguns pontos de: AWS Lambda: Não é possível acessar a fila SQS de uma função Lambda com acesso VPC, no entanto, ainda não consigo me conectar.
Aqui está o que tenho:
VPC:
- O VPC tem sub-redes públicas e privadas e um IG Gateway. Usei o assistente para criá-lo. Eu não entendo muito dos fundamentos aqui.
- Configuração de VPC (desculpe, é um link, ainda não me permite incorporar.)
- CIDRs - o assistente criou todos, exceto o último bloco. Não tenho certeza se fiz isso direito ou se isso importa, pois o assistente me fez criar pelo menos um e fiz isso para evitar sobreposição de IP.
- Como este é um projeto dev / prototype, o grupo de segurança anexado ao VPC está 'totalmente aberto'. Todas as entradas e saídas são permitidas.
- Deixe-me saber qual outra configuração VPC mostrar, pois não tenho certeza do que é útil
Terminal de serviço:
- Tentei criar um ponto de extremidade de serviço para SQS de acordo com o artigo vinculado acima, aqui está o que eu tenho: configuração de ponto de extremidade
- Vou falar mais sobre como estou consumindo isso na seção Lambda.
- O endpoint é anexado ao VPC
Lambda:
- Tenho o Lambda anexado ao VPC, conforme mostrado aqui .
- Isso me permite falar com APIs públicas de terceiros e meus recursos protegidos. Era minha esperança que ter um SG aberto ainda permitisse que meu lambda falasse com o SQS, mas continua expirando.
- Não tenho certeza de qual url usar em meu Lambda para meu endpoint. O exemplo aqui:https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-sending-messages-from-vpc.html parece que ainda usa o endpoint regional.
Código
Esta é a aparência da invocação SQS de dentro do meu código:
-
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();
-
Agradecemos qualquer ajuda, por favor, deixe-me saber quais outras informações eu posso fornecer.
Obrigado!
** Editar **
Devo também mencionar que, para contornar todo esse problema, comecei a usar o SQS como um destino Lambda. Embora isso injete mensagens na fila de destino, provavelmente não será escalonado com meu caso de uso. Posso elaborar mais sobre isso, se necessário, pois não é totalmente pertinente à questão real.
** EDITAR 31/08/20 **
Obrigado por todas as respostas, foi uma grande ajuda e me levou a uma resolução. Direi que para quem encontrar esta postagem deve primeiro assistir:
https://www.youtube.com/watch?v=JcRKdEP94jM
Isso é algo que eu gostaria de ter encontrado antes de começar tudo isso porque, embora seja especificamente voltado para fornecer acesso à Internet de lambdas, ele passa pelo processo de mapeamento de IGs e Nats para sub-redes que é realmente onde eu estava configurando incorretamente meu vpc. Com este vídeo, recriei todo o meu VPC e ficou muito mais limpo e fácil de conectar os pontos. 10/10, recomendo.
Obrigado novamente!
Respostas
Meu palpite sobre este aqui é que há uma regra faltando em algum lugar na configuração da sua rede - pacotes sendo descartados em direção ao seu SQS ou no caminho de volta (ambos precisam ser pensados salto a salto).
As três coisas que vêm à mente:
- Roteamento: Certifique-se de que as sub-redes e as tabelas de roteamento tenham rotas apropriadas para obter os pacotes de volta para sua sub-rede privada de onde está o ponto de extremidade SQS.
- Grupos de segurança - observe cuidadosamente cada SG envolvido. O SQS pode estar em um SG que restringe o acesso a ele, por exemplo.
- ACLs de rede - são sem estado, portanto, você precisará garantir que ambos os lados estejam abertos e lembre-se de que, na maioria das vezes, haverá números de porta aleatórios envolvidos na volta ao solicitante.
Boa sorte!
A função AWS Lambda deve ser anexada a uma sub-rede privada no VPC.
O Amazon SQS reside na Internet, portanto, a função Lambda precisa de uma maneira de acessar o endpoint SQS.
Opção 1: VPC Endpoint
Um VPC Endpoint para Amazon SQS pode fornecer um link direto entre um VPC e o endpoint SQS, sem exigir acesso à Internet. Depois de criado, o VPC enviará automaticamente solicitações SQS no VPC Endpoint. Esta é uma opção simples e agradável.
Opção 2: Gateway NAT
Se você tiver recursos adicionais na (s) sub-rede (s) privada (s) que requerem acesso à Internet, você pode considerar a colocação de um Gateway NAT em uma sub-rede pública . As sub-redes privadas precisarão de uma entrada na Tabela de Rotas que direcione o tráfego vinculado à Internet ( 0.0.0.0/0) para o Gateway NAT.
Aplicam-se custos adicionais.
Opção 3: destino lambda
Se você tiver a função Lambda comunicando com sucesso o SQS através de um destino Lambda, então esta parece uma excelente opção ! Ainda não tentei, mas parece que o serviço Lambda é responsável por enviar a saída diretamente para o SQS, sem ter que passar pelo VPC ou pela Internet. Se estiver funcionando, recomendo enfaticamente que continue usando. Não percebo nenhum problema de escala ao usar este método. No entanto, observe que ele só funciona para chamadas assíncronas para Lambda e não funcionará, por exemplo, ao invocar a função de forma síncrona ou pressionando o botão Test .