Не удается подключить лямбда-функцию к Aurora RDS

Я использую бессерверную структуру, чтобы попытаться заставить мою лямбда-функцию перебрасывать некоторые записи в «всегда активный» экземпляр Aurora RDS. До сих пор я встречал тайм-ауты подключения при использовании пакета mysql npm и попытке подключиться к экземпляру RDS.

Вот что я проверял \ пробовал:

  • поместите лямбда-функцию в VPC в serverless.yml
  • включены 3 подсети, связанные с этим VPC, в yml
  • указал группу безопасности в servless.yml
  • проверил, что в этой сервисной группе есть правило маршрутизации aurora, которое разрешает доступ к самой сервисной группе
  • добавлены операторы ролей iam для эластичного интерфейса ec2

serverless.yml:

service: myrds

provider:
  name: aws
  runtime: nodejs10.x
  stage: ${opt:stage, 'dev'}
  region: ${opt:region, 'us-east-2'}
  iamRoleStatements:
    - Effect: "Allow"
      Action: 
        - "ec2:CreateNetworkInterface"
        - "ec2:DescribeNetworkInterfaces"
        - "ec2:DeleteNetworkInterface"
      Resource: "*"
  - Effect: "Allow"
      Action:
        - "sqs:SendMessage"
        - "sqs:GetQueueUrl"
        - "sqs:ListQueues"
      Resource:
        Fn::GetAtt: 
          - RDSQueue
          - Arn 
    - Effect: "Allow"
      Action:
        - "sqs:SendMessage"
        - "sqs:GetQueueUrl"
        - "sqs:ListQueues"
      Resource:
        Fn::GetAtt: 
          - DeadLetterQueue
          - Arn 
 functions:
   consumer:
    handler: handler.consumer
    timeout: 20
    vpc:
    securityGroupIds:
      - sg-123456
    subnetIds:
      - subnet-11111
      - subnet-22222
      - subnet-33333
    events:
      - sqs:
          arn:
            Fn::GetAtt:
              - RDSQueue
              - Arn
    environment:
      NODE_ENV: ${opt:stage, 'dev'}
  resources:
    Resources:
      RDSQueue:
        Type: 'AWS::SQS::Queue'
        Properties:
          QueueName: "RDSQueue-${opt:stage, 'dev'}"
          RedrivePolicy:
            deadLetterTargetArn:
              "Fn::GetAtt":
                - DeadLetterQueue
                - Arn
            maxReceiveCount: 3
      DeadLetterQueue:
        Type: 'AWS::SQS::Queue'
        Properties:
          QueueName: "DeadLetterQueue-${opt:stage, 'dev'}"

Что мне здесь не хватает? Время ожидания подключения истекает, когда оно запускается из очереди SQS.


comment
Вы дали разрешение лямбда на доступ к Авроре?   -  person Juned Ahsan    schedule 23.09.2019
comment
@JunedAhsan Я не видел каких-либо конкретных заявлений о полярном сиянии, если вы это имеете в виду. Я искал в SDK и в RDS не нашел ничего, что подходило бы для простого подключения и запроса. Вы это имеете в виду или говорите о другом?   -  person Ryan    schedule 23.09.2019
comment
где в вашем yml конфиг подключения к базе данных?   -  person Juned Ahsan    schedule 23.09.2019
comment
Есть ли в подсетях запись в таблице маршрутизации, указывающая на Интернет-шлюз?   -  person Joey Kilpatrick    schedule 23.09.2019
comment
@JunedAhsan он определен в файле .js, а не в yml   -  person Ryan    schedule 29.09.2019
comment
@JoeyKilpatrick нет, нет маршрутизации к интернет-шлюзу, так как это будет использоваться только для внутреннего использования, исходящий доступ не требуется.   -  person Ryan    schedule 30.09.2019


Ответы (1)


Типичная конфигурация при подключении функции AWS Lambda к базе данных Amazon RDS:

  • Лямбда-функция, подключенная к частным подсетям в VPC
  • Группа безопасности для лямбда-функции (Lambda-SG) со всем разрешенным исходящим доступом
  • Группа безопасности в базе данных RDS (RDS-SG) с правилом для входящего трафика, разрешающим трафик на соответствующий порт (например, 3306) от Lambda-SG

То есть RDS-SG конкретно ссылается на Lambda-SG во входящем правиле.

Если лямбда-функция также должна подключаться к Интернету, тогда в общедоступной подсети VPC должен быть NAT-шлюз.

person John Rotenstein    schedule 23.09.2019
comment
Мог ли я не поместить лямбда-функцию в тот же SG, что и экземпляр Aurora? - person Ryan; 30.09.2019
comment
Не существует такой концепции, как размещение ресурсов в одной группе безопасности. Скорее, ресурсы связаны с группой безопасности. Несколько ресурсов могут быть связаны с одной и той же группой безопасности, что означает, что правила применяются к каждому из этих ресурсов, но у них нет общих возможностей из-за того, что они имеют одну и ту же группу безопасности. Если два ресурса, связанные с одной и той же группой безопасности, хотят обмениваться данными, группа безопасности должна будет явно разрешить входящее соединение от себя (путем ссылки на свой собственный идентификатор). - person John Rotenstein; 01.10.2019
comment
Правильно. У меня есть в этой группе безопасности как входящие, так и исходящие соединения для этой группы безопасности, указанные для себя. Я не уверен, почему это время истекает. - person Ryan; 07.10.2019
comment
Вы можете отладить, временно открыв всю группу безопасности, чтобы убедиться, что она работает, а затем постепенно ужесточить безопасность. Если открытие группы безопасности не решает проблему, значит, вы знаете, что она вызвана чем-то другим. - person John Rotenstein; 07.10.2019
comment
Поэтому я установил группу безопасности, чтобы разрешить входящий трафик 0.0.0.0/0, но время ожидания все еще истекло. Это группа безопасности, которую RDS утверждает, что использует. - person Ryan; 07.10.2019
comment
Большой! Это значит, что проблема не связана с группами безопасности! Некоторые вещи для исследования: подключается ли функция Lambda к Aurora через частный IP-адрес (или DNS-имя преобразуется в частный адрес)? Какие-нибудь нестандартные настройки NACL? Можете ли вы подключиться к Aurora из инстанса EC2 в том же VPC? Фактически, удалось ли вам подключиться к Aurora из где угодно? - person John Rotenstein; 07.10.2019
comment
Джон, у нас есть экземпляр EB, который может подключаться так же, как и я, когда я связываю свой IP с этим SG. Я заставлю свое приложение определять имя, которое разрешает uri. Не думаю, что я заметил какие-то странные NACL, но я перепроверю их и отправлю обратно. - person Ryan; 07.10.2019
comment
Итак, я вижу два VPC в списке VPC. Я просмотрел NACL для VPC, в котором находится RDS (который также является VPC по умолчанию), и подтвердил, что рассматриваемые 3 подсети являются теми, которые определены в моем serverless.yml. Тем не менее, существует VPC, отличный от стандартного. Я выплевываю, что разрешает конечная точка, и это частный IP-адрес 172.32.x.x. Есть другие идеи? - person Ryan; 09.10.2019
comment
Я бы посоветовал: Временно установить группу безопасности, чтобы разрешить входящие сообщения от 0.0.0.0/0 или CIDR VPC. Запустите инстанс Amazon EC2 в публичной подсети того же VPC. Войдите в систему, а затем попробуйте подключиться к базе данных с помощью командной строки mysql. Если это сработает, значит, с сетью все в порядке. Затем вы можете работать над подключением лямбда-функции. - person John Rotenstein; 09.10.2019
comment
Я создал ec2, связал его с vpc по умолчанию, связал его с lambda sg. Сначала мне не удалось подключиться. Затем я добавил 0.0.0.0/0 как исходящее правило на SG. Теперь работает как на EC2, так и на лямбде! Это имеет смысл, поскольку у него другой sg, и он должен иметь возможность «протянуть руку», чтобы добраться до другого sg. Затем я обновил 0.0.0.0/0 до SG RDS SG, все еще хорошо! Если я свяжу и свою лямбду, и RDS с одним и тем же SG, какие правила исходящего трафика мне понадобятся? Я отношусь к SG как к псевдониму брандмауэра, который может связываться с одним или несколькими адресами. - person Ryan; 09.10.2019
comment
Я полагаю, что единственный раз, когда мне нужно выполнить правило для исходящего трафика, - это когда оно переходит к другому ресурсу, не связанному с этим SG? Или вам нужно отображение на себя для доступа к ресурсам внутри его SG? - person Ryan; 09.10.2019
comment
Я по-прежнему рекомендую вышеуказанный подход - один SG для функции Lambda (разрешить все исходящие) и один для RDS (разрешить входящий трафик 3306 от Lambda SG). Обычно разрешить весь исходящий трафик в группе безопасности безопасно, поскольку вы можете доверять своему собственному коду. Если вы заблокируете его, убедитесь, что он все еще может отправлять журналы в CloudWatch Logs (предположительно, порт 443). - person John Rotenstein; 09.10.2019
comment
Да, я определенно привязываю другой Sg для своих лямбда-функций, это был вопрос для моего собственного назидания. Если у меня есть SG «A» и два ресурса, связанные с «A», они не смогут общаться друг с другом, скажем, порт 22, если нет правила Innound для порта 22 (или типа SSH) и SG «A» в качестве источника И и правила исходящего трафика, разрешающего SG A в качестве пункта назначения (или 0.0.0.0/0) с типом SSH (или всем), это правильно? - person Ryan; 09.10.2019
comment
Да, это правильно. Группа безопасности применяется независимо к каждому ресурсу. - person John Rotenstein; 09.10.2019
comment
классно! Большое спасибо! - person Ryan; 09.10.2019