Предоставление доступа к функции Lambda через HTTP API

Введение

Странице состояния нужна HTTP-конечная точка, сообщающая об исправности приложения. Вы подключите предоставленный обработчик Lambda к HTTP API, отправите запросы, диагностируете его разрешение вызова и удалите свои ресурсы.

Выполните Запуск функции Lambda с событием JSON и Настройка и диагностика функции Lambda, включая их предварительные работы по ролям и журналам. Эта свежая среда предоставляет обработчик и роль выполнения.

Связь с сертификацией

Эта лабораторная работа помогает на практике изучить следующие темы экзаменов.

Solutions Architect – Associate (SAA-C03) · Задача 2.1: Маршруты HTTP API, интеграция Lambda и разрешения вызова.
Developer – Associate (DVA-C02) · Задача 1.1, Задача 1.2: Маршруты HTTP API, интеграция Lambda и разрешения вызова.
DevOps Engineer – Professional (DOP-C02) · Задача 3.2: Базовая практика: Маршруты HTTP API, интеграция Lambda и разрешения вызова.

Разверните функцию состояния

На этом шаге вы упакуете предоставленный обработчик состояния и развернёте функцию, способную отвечать на HTTP-событие.

Перейдите в подготовленную рабочую папку:

cd /home/labex/project

Откройте AWS View рядом с Terminal, чтобы наблюдать те же состояния функции, API и журналов, что и в командах. Изначально существуют только независимые эталонные журналы; сохраните их.

Прочитайте предоставленное приложение перед упаковкой:

cat app.py

Обработчик получает событие, записывает эти входные данные в журнал и возвращает прокси-ответ с statusCode, headers и строкой JSON в body. Формат полезной нагрузки HTTP 2.0 помещает параметры запроса URL в queryStringParameters. Необязательный параметр name меняет приветствие. RELEASE_LABEL — настройка среды, возвращаемая вместе с ним.

Используйте zip, чтобы поместить app.py в корень архива развёртывания:

zip health.zip app.py

Прочитайте ARN подготовленной роли в переменную оболочки. --query выбирает одно поле ответа, а --output text делает его пригодным для следующей команды:

ROLE_ARN=$(aws iam get-role --role-name labex-a01-execution --query 'Role.Arn' --output text)

Разверните app.handler с Python 3.12 и подготовленной ролью выполнения. fileb:// загружает байты Zip. Карта JSON Variables использует тот же формат, что и работа по конфигурации Lambda. Её строковое значение обозначает первый выпуск:

aws lambda create-function \
  --function-name labex-a01-health \
  --runtime python3.12 \
  --role "$ROLE_ARN" \
  --handler app.handler \
  --timeout 5 \
  --environment '{"Variables":{"RELEASE_LABEL":"initial"}}' \
  --zip-file fileb://health.zip \
  --query '{Name:FunctionName,Handler:Handler,Runtime:Runtime}'

Ответ должен указывать labex-a01-health, app.handler и python3.12. Откройте AWS View и изучите карточку Function. Одна развёрнутая функция ещё не предоставляет HTTP-маршрут; карточка HTTP APIs остаётся пустой.

Подключите HTTP-маршрут и отправьте запрос

На этом шаге вы свяжете HTTP-запрос с развёрнутой функцией. Amazon API Gateway предоставляет HTTP-вход. Маршрут выбирает серверную интеграцию для метода и пути, например GET /health.

Создайте HTTP API и сохраните сгенерированный идентификатор в переменной оболочки. Подстановка команды $(...) получает выбранный идентификатор API вместо его вывода:

API_ID=$(aws apigatewayv2 create-api --name labex-a01 --protocol-type HTTP --query ApiId --output text)

Запишите этот идентификатор для списка своих ресурсов. Перенаправление > записывает значение в файл:

printf '%s\n' "$API_ID" > api-id.txt

Стадия — точка входа развёртывания API. У стадии $default нет сегмента имени стадии в URL. --auto-deploy автоматически применяет изменения. Одинарные кавычки сохраняют буквальный знак доллара:

aws apigatewayv2 create-stage --api-id "$API_ID" --stage-name '$default' --auto-deploy --query '{Stage:StageName,AutoDeploy:AutoDeploy}'

Прочитайте ARN развёрнутой функции, затем создайте интеграцию AWS_PROXY. Интеграции Lambda используют POST для вызова серверной части, хотя входящий клиентский маршрут ниже использует GET. Формат полезной нагрузки 2.0 соответствует предоставленному обработчику:

FUNCTION_ARN=$(aws lambda get-function-configuration --function-name labex-a01-health --query FunctionArn --output text)

INTEGRATION_ID=$(aws apigatewayv2 create-integration --api-id "$API_ID" --integration-type AWS_PROXY --integration-method POST --integration-uri "$FUNCTION_ARN" --payload-format-version 2.0 --query IntegrationId --output text)

Ключ маршрута объединяет HTTP-метод клиента с путём. Его цель указывает на только что созданную интеграцию:

aws apigatewayv2 create-route \
  --api-id "$API_ID" \
  --route-key 'GET /health' \
  --target "integrations/$INTEGRATION_ID" \
  --authorization-type NONE \
  --query '{Route:RouteKey,Authorization:AuthorizationType}'

Этот общедоступный маршрут состояния использует NONE; вход в приложение будет изучен позднее. Роль выполнения управляет возможностями кода функции, а политика ресурса функции — тем, кто может её вызвать. API Gateway всё ещё нужно точное разрешение вызова.

Прочитайте идентификатор выбранного аккаунта и сформируйте ARN источника для маршрута GET /health стадии по умолчанию этого API. Экранированный знак доллара сохраняет $default буквально внутри строки с подстановками:

ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)

SOURCE_ARN="arn:aws:execute-api:us-east-1:$ACCOUNT_ID:$API_ID/\$default/GET/health"

Дайте разрешение вызова функции только этому маршруту API:

aws lambda add-permission \
  --function-name labex-a01-health \
  --statement-id ApiHealth \
  --action lambda:InvokeFunction \
  --principal apigateway.amazonaws.com \
  --source-account "$ACCOUNT_ID" \
  --source-arn "$SOURCE_ARN" \
  --query Statement \
  --output text

Для HTTP-запросов в этой рабочей среде используйте подготовленный адрес API со своим сгенерированным идентификатором. Это вход API рабочей среды, а не публичное имя хоста AWS:

API_URL="http://127.0.0.1:8081/api/$API_ID"

Официальная Console показывает те же идентификатор API, стадию $default и настройку Auto deploy. Её Invoke URL — конечная точка AWS; в этой работе продолжайте использовать API_URL рабочей среды выше.

Официальная API Gateway Console показывает сведения API и URL вызова стадии по умолчанию

Источник: AWS API Gateway.

curl -i показывает HTTP-заголовки и тело ответа. Параметр запроса URL становится частью фактического события Lambda:

curl -i "$API_URL/health?name=Maya"

Ожидайте HTTP 200 и это тело JSON:

{"healthy": true, "message": "Hello, Maya", "release": "initial"}

Вернитесь в AWS View. Карточка HTTP APIs должна показывать GET /health, NONE и $default · AutoDeploy true. Карточка CloudWatch Logs должна показывать фактический маршрут, статус и ответ. Нажмите Show logs и найдите queryStringParameters с name: Maya. Это ручное наблюдение связывает HTTP-запрос с входными данными развёрнутой функции; проверка оценивает удалённую конфигурацию и фактическое выполнение.

HTTP-маршрут состояния и его ответ Lambda в AWS View

Этот пример показывает настроенный маршрут и успешный ответ Maya / initial. Ваш сгенерированный идентификатор API и отпечаток кода будут отличаться.

Маршрут состояния выбирает интеграцию Lambda для запроса.

Диагностируйте разрешение вызова и выпустите новую редакцию

На этом шаге вы увидите нарушенную границу вызова, восстановите точное разрешение и проверите изменённую настройку функции.

Удалите инструкцию политики по её идентификатору. При этом API, интеграция и роль выполнения сохраняются:

aws lambda remove-permission --function-name labex-a01-health --statement-id ApiHealth

Отправьте ещё один запрос при отсутствии разрешения:

curl -i "$API_URL/health?name=Noah"

Ожидайте HTTP 502 с Invocation permission denied. Развёртывание API и настройка маршрута сами по себе не дают разрешения вызова Lambda. В AWS View существующий успешный вызов сохраняется; этот отклонённый запрос не запустил обработчик. Вручную сравните журналы до и после запроса. Автоматическая проверка не выводит факт прошлого отказа из окончательной восстановленной политики.

Восстановите то же разрешение, ограниченное аккаунтом и маршрутом:

aws lambda add-permission \
  --function-name labex-a01-health \
  --statement-id ApiHealth \
  --action lambda:InvokeFunction \
  --principal apigateway.amazonaws.com \
  --source-account "$ACCOUNT_ID" \
  --source-arn "$SOURCE_ARN" \
  --query Statement \
  --output text

Измените среду функции, обозначив готовый выпуск. Обработчик читает эту настройку при выполнении:

aws lambda update-function-configuration --function-name labex-a01-health --environment '{"Variables":{"RELEASE_LABEL":"ready"}}' --query 'Environment.Variables'

Маршрут по-прежнему указывает на ту же функцию. Отправьте запрос с другим значением параметра:

curl -i "$API_URL/health?name=Noah"

Ожидайте HTTP 200 и ответ, вычисленный из нового параметра запроса и среды:

{"healthy": true, "message": "Hello, Noah", "release": "ready"}

В AWS View изучите последний ответ и разверните его журналы. Подтвердите, что входные данные содержат Noah, а тело — ready. Прежний ответ Maya должен оставаться доступным. Эти разные результаты показывают, что интеграция запускает развёрнутую функцию, а не возвращает одно фиксированное сообщение состояния.

Удалите свои API и функцию

На этом шаге вы удалите созданные ресурсы и докажете сохранность независимых эталонных журналов.

Ваш список ресурсов состоит из идентификатора API в api-id.txt, labex-a01-health и /aws/lambda/labex-a01-health. API владеет своим маршрутом, интеграцией и стадией по умолчанию. Сначала удалите API, чтобы он не мог получать новые запросы:

aws apigatewayv2 delete-api --api-id "$API_ID"

Удалите функцию и её политику вызова:

aws lambda delete-function --function-name labex-a01-health

Группы журналов Lambda имеют собственный жизненный цикл. Удалите только группу этой функции:

aws logs delete-log-group --log-group-name /aws/lambda/labex-a01-health

Успешно прочитайте списки собственными средствами сервисов; ошибки запросов не доказывают удаление:

aws apigatewayv2 get-apis --query 'Items[].Name'

aws lambda list-functions --query 'Functions[].FunctionName'

Оба списка должны быть пустыми. Прочитайте оставшиеся группы журналов:

aws logs describe-log-groups --query 'logGroups[].logGroupName'

Должна остаться только /labex/labex-a01-reference. Сохраните её и подготовленную роль выполнения. В AWS View подтвердите, что карточки API, Function и вызовов пусты, а Reference logs всё ещё показывает INFO platform reference keep unchanged.

Резюме

Вы развернули обработчик состояния Python, подключили маршрут HTTP API через интеграцию payload 2.0 и включили его стадию по умолчанию. Вы ограничили разрешение API на вызов Lambda, диагностировали его удаление и наблюдали разные ответы из фактических параметров запроса и настроек функции. В завершение вы удалили свои API, функцию и группу журналов, сохранив независимые ресурсы.