Выполнение не удалось из-за ошибки конфигурации: недопустимые разрешения для лямбда-функции

У вас может быть проблема в конфигурации разрешений, поэтому API не может вызвать вашу лямбду. попробуйте явно добавить в файл template.yaml invoke разрешение на лямбду из apigateway в виде principal вот пример ниже:

  ConfigLambdaPermission:
    Type: "AWS::Lambda::Permission"
    DependsOn:
    - MyApiName
    - MyLambdaFunctionName
    Properties:
      Action: lambda:InvokeFunction
      FunctionName: !Ref MyLambdaFunctionName
      Principal: apigateway.amazonaws.com

Вот проблема, о которой сообщалось в SAM github repo для полной справки и здесь это пример проекта hello SAM

Если вы хотите добавить разрешение AWS CLI для тестирования, вы можете использовать aws lambda add-permission. посетите официальный сайт документации, чтобы узнать больше Детали.

У меня была аналогичная проблема - я удалил, а затем переустановил лямбда-функцию. Мой API-шлюз все еще указывал на старый, поэтому мне пришлось зайти в API-шлюз и изменить свои методы ресурсов, чтобы изменить параметр Integration Request, чтобы он указывал на новый (может показаться, что он указывает на правильный, но не не в моем случае)

У меня была такая же проблема, но я выполнял развертывание через Terraform. После предложения другого пользователя я повторно выбрал свою лямбда-функцию в части интеграции API-шлюза, а затем проверил, что изменилось в моих разрешениях на лямбда-выражение. Оказывается, мне нужно было добавить «*» там, где я помещал имя сцены в разделе source_arn триггера API Gateway в моем ресурсе Lambda. Не уверен, как SAM сравнивается с Terraform, но, возможно, вы можете изменить сценическое имя или просто попробовать этот метод устранения неполадок, который я пробовал.

Моя публикация SO: AWS API Шлюз и функция Lambda, развернутые через terraform - Выполнение не удалось из-за ошибки конфигурации: недопустимые разрешения для функции Lambda

Та же ошибка, и решение было простым: очистить и снова применить сопоставление лямбда-функции в настройках интеграции API-шлюза.

Мое отображение выглядит так: MyFunction-894AR653OJX:test где test - это псевдоним, указывающий на правильную версию моей лямбды.

Проблема была вызвана удалением теста ALIAS на лямбда-выражении и его воссозданием в другой версии (после публикации). Кажется, что шлюз API внутренне все еще связан со "старым" ALIAS экземпляром. Можно было ожидать, что матч проводится исключительно по названию ...

Бонус: значит, через консоль AWS вы не можете переместить этот АЛИАС, но вы можете сделать это через интерфейс командной строки AWS, используя следующую команду:

aws lambda --profile <YOUR_PROFILE> update-alias --function-name <FUNCTION_NAME> --name <ALIAS_NAME> --function-version <VERSION_NUMBER>

Я была такая же проблема. Сначала я изменил интеграцию на mock, т.е. отключил тип интеграции от Lambda, а затем после одного развертывания снова установил тип интеграции на lambda. После этого он работал безупречно.

Я надеюсь, что это помогает.

У меня была такая же проблема, поэтому я удалил, затем создал стек, и он сработал.

Столкнувшись с той же проблемой, я понял, что проблема заключается в следующем: API-шлюз не может вызвать лямбда-функцию, так как я не видел журналов CloudWatch для лямбда-функции.

Итак, сначала я прошел через консоль шлюза API и в разделе Запрос на интеграцию дал полный ARN для лямбда-функции. и он начал работать.

Во-вторых, через CloudFormation

x-amazon-apigateway-integration:
        credentials:
          Fn::Sub: "${ApiGatewayLambdaRole.Arn}"
        type: "aws"
        uri:
          Fn::Sub: "arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${lambda_function.Arn}/invocations"

У меня была аналогичная проблема, и я использовал Terraform. Ему нужна политика с "POST" в ней. По какой-то причине политика / * / (подстановочный знак) не сработала?

Вот политика и пример terraform, которые я использовал для решения проблемы.

Большое спасибо всем вышеперечисленным.

Вот как выглядела моя политика JSON-функции Lambda и ее терраформа:

    {
      "Version": "2012-10-17",
      "Id": "default",
      "Statement": [
        {
          "Sid": "AllowAPIGatewayInvoke",
          "Effect": "Allow",
          "Principal": {
            "Service": "apigateway.amazonaws.com"
          },
          "Action": "lambda:InvokeFunction",
          "Resource": "arn:aws:lambda:us-east-1:999999999999:function:MY-APP",
          "Condition": {
            "ArnLike": {
              "AWS:SourceArn": "arn:aws:execute-api:us-east-1:999999999999:d85kyq3jx3/test/*/MY-APP"
            }
          }
        },
        {
          "Sid": "e841fc76-c755-43b5-bd2c-53edf052cb3e",
          "Effect": "Allow",
          "Principal": {
            "Service": "apigateway.amazonaws.com"
          },
          "Action": "lambda:InvokeFunction",
          "Resource": "arn:aws:lambda:us-east-1:999999999999:function:MY-APP",
          "Condition": {
            "ArnLike": {
              "AWS:SourceArn": "arn:aws:execute-api:us-east-1:999999999999:d85kyq3jx3/*/POST/MY-APP"
            }
          }
        }
      ]
    }

    add in a terraform like this:


    //************************************************
    // allows you to read in the ARN and parse out needed info, like region, and account
    //************************************************
    data "aws_arn" "api_gw_deployment_arn" {
        arn = aws_api_gateway_deployment.MY-APP_deployment.execution_arn 
    }

    //************************************************
    // Add in this to support API GW testing in AWS Console.
    //************************************************
    resource "aws_lambda_permission" "apigw-post" {
        statement_id  = "AllowAPIGatewayInvokePOST"
        action        = "lambda:InvokeFunction"
        //function_name = aws_lambda_function.lambda-MY-APP.arn
        function_name = module.lambda.function_name
        principal     = "apigateway.amazonaws.com"

        // "arn:aws:execute-api:us-east-1:473097069755:708lig5xuc/dev/POST1/cloudability-church-ws"
        source_arn = "arn:aws:execute-api:${data.aws_arn.api_gw_deployment_arn.region}:${data.aws_arn.api_gw_deployment_arn.account}:${aws_api_gateway_deployment.MY-APP_deployment.rest_api_id}/*/POST/${var.api_gateway_root_path}"
    }

В документации для разрешений лямбда-ресурсов AWS показано 3 уровня доступа, которые можно фильтровать или использовать подстановочные знаки, / * / * / *, что задокументировано как $ stage / $ method / $ path. Однако их пример и большинство примеров в Интернете используют только 2 уровня, и я бился головой о стену, используя 3 только для получения доступа запрещен. Я переключился на 2 уровня, и лямбда создала триггер. Будем надеяться, что это спасет кого-нибудь от удара компьютера об стену.