Вопросы и ответы по AWS Lambda

Код, запускаемый в AWS Lambda, загружается в качестве функции Lambda. Каждая функция имеет соответствующую информацию о конфигурации, например название, описание, точку входа и требования к ресурсам. Код должен быть написан без сохранения состояния, то есть не должен зависеть от конкретной вычислительной инфраструктуры. Доступ к локальной файловой системе, дочерние процессы и подобные артефакты не могут храниться дольше, чем исполняется сам запрос, поэтому все постоянные состояния должны храниться в Amazon S3, Amazon DynamoDB, Amazon EFS или любом другом доступном через Интернет сервисе хранилища. Функции Lambda могут включать в себя библиотеки, в том числе встроенные.

В целях повышения производительности (чтобы не создавать новые копии инстансов) инстансы функций в AWS Lambda могут сохраняться для обработки дальнейших запросов. Подробнее о том, как Lambda повторно использует инстансы функций, см. в нашей документации. В коде необходимо учитывать, что это случается не всегда.

Вы можете предоставить каждой функции Lambda собственное краткосрочное хранилище размером от 512 МБ до 10 240 МБ с шагом в 1 МБ. Временное хранилище доступно в каталоге /tmp каждой функции.

Каждая функция имеет доступ к 512 МБ хранилища без дополнительной платы. Когда вы выделяете для своих функций более 512 МБ краткосрочной памяти, с вас взимается плата в зависимости от указанного размера хранилища и времени выполнения функции, измеряемого с шагом в 1 мс. Для сравнения: в регионе Восток США (Огайо) цена на краткосрочное хранение для AWS Fargate составляет 0,000111 USD за 1 ГБ в час или 0,08 USD за 1 ГБ в месяц. Цена на том хранилища Amazon EBS gp3 в регионе Восток США (Огайо) составляет 0,08 USD за 1 ГБ в месяц. Цена на краткосрочное хранение AWS Lambda составляет 0,0000000309 USD за 1 ГБ в секунду или 0,000111 USD за 1 ГБ в час и 0,08 USD за 1 ГБ в месяц. Подробнее см. в разделе Цены на AWS Lambda.

Вы можете настроить для каждой функции Lambda краткосрочное хранилище размером от 512 МБ до 10 240 МБ с шагом в 1 МБ с помощью консоли AWS Lambda, API AWS Lambda или шаблона AWS CloudFormation во время создания или обновления функции.

Да. Все данные, которые хранятся в краткосрочном хранилище, шифруются во время хранения с использованием ключа, управляемого AWS.

Для отслеживания использования краткосрочного хранилища AWS Lambda можно использовать метрики AWS CloudWatch Lambda Insight. Дополнительную информацию см. в документации AWS CloudWatch Lambda Insights.

Если вашему приложению требуется надежное постоянное хранилище, воспользуйтесь Amazon S3 или Amazon EFS. Если вашему приложению требуется хранить данные, которые нужны коду для выполнения отдельной функции, воспользуйтесь краткосрочным хранилищем AWS Lambda как временным кэшем. Дополнительную информацию см. в разделе Выбор хранилища данных AWS Lambda для веб-приложений.

Да. Однако, если вашему приложению требуется постоянное хранилище, воспользуйтесь Amazon EFS или Amazon S3. Когда для функции Lambda включена функция Provisioned Concurrency, код инициализации вашей функции выполняется во время распределения ресурсов, а также каждые несколько часов по мере утилизации инстансов вашей функции. Вы можете просмотреть время инициализации в журналах и маршрутах после обработки запроса инстансом. Однако плата за инициализацию взимается, даже если инстанс ни разу не обрабатывает запрос. Это поведение при инициализации Provisioned Concurrency может повлиять на взаимодействие вашей функции с данными, которые хранятся в краткосрочном хранилище, даже если ваша функция не обрабатывает запросы. Чтобы узнать больше о Provisioned Concurrency, см. соответствующую документацию.

Вы можете настроить для каждой функции Lambda краткосрочное хранилище размером от 512 МБ до 10 240 МБ с шагом в 1 МБ с помощью консоли AWS Lambda, API AWS Lambda или шаблона AWS CloudFormation во время создания или обновления функции.

Да. Все данные, которые хранятся в краткосрочном хранилище, шифруются во время хранения с использованием ключа, управляемого AWS.

Для отслеживания использования краткосрочного хранилища AWS Lambda можно использовать метрики AWS CloudWatch Lambda Insight. Дополнительную информацию см. в документации AWS CloudWatch Lambda Insights.

Использование функций без сохранения состояния позволяет AWS Lambda быстро запускать нужное количество копий функции для масштабирования в соответствии со скоростью входящих событий. Так как модель программирования AWS Lambda не сохраняет состояния, код может получать доступ к данным с фиксацией состояния с помощью вызова других веб-сервисов, например Amazon S3 или Amazon DynamoDB.

Да. AWS Lambda позволяет использовать стандартные возможности языка программирования и операционной системы, такие как создание дополнительных потоков и процессов. Выделенные для функции Lambda ресурсы (в том числе память, время исполнения, дисковое пространство и использование сети) должны быть распределены среди всех используемых потоков / процессов. Запуск процессов можно осуществлять с помощью любого языка, поддерживаемого Amazon Linux.

Команда разработчиков Lambda пыталась свести к минимуму количество ограничений на стандартные действия языков программирования и операционной системы, но все же несколько действий отключены: AWS Lambda блокирует входящие сетевые подключения, а для исходящих подключений поддерживаются только сокеты TCP/IP и UDP/IP; кроме того, заблокированы системные вызовы ptrace (отладка). В целях борьбы со спамом также заблокирован трафик через TCP-порт 25.

При использовании Node.js или Python можно написать код функции с помощью редактора кода в консоли AWS Lambda, который позволяет создавать и тестировать функции, а также просматривать результаты их исполнения в надежной среде, похожей на IDE. Чтобы начать работу, перейдите в консоль.

Вы также можете заархивировать код (и любые зависимые библиотеки) в формат ZIP и загрузить архив с локального компьютера, используя консоль AWS Lambda, либо указать местоположение этого файла ZIP в Amazon S3. Размер загрузок не должен превышать 50 МБ (в сжатом виде). Для создания и развертывания функций Lambda на Java можно использовать подключаемый модуль AWS Eclipse. Для создания и развертывания функций Lambda на C# и Node.js можно использовать подключаемый модуль Visual Studio.

Вы можете заархивировать код (и любые зависимые библиотеки) в формат ZIP и загрузить архив с локального компьютера, используя AWS CLI, либо указать местоположение этого файла ZIP в Amazon S3. Размер загрузок не должен превышать 50 МБ (в сжатом виде). Чтобы начать работу, перейдите на страницу Руководство по началу работы с Lambda.

Да. Переменные среды можно просто создавать и изменять в консоли AWS Lambda, с помощью интерфейса командной строки или SDK. Подробнее о переменных среды см. в документации.

Для конфиденциальной информации, например паролей к базам данных, рекомендуется использовать шифрование на стороне клиента с помощью сервиса управления ключами AWS и хранить полученные значения в виде зашифрованного текста в переменных среды. Для расшифровки этих значений необходимо будет включить алгоритм расшифровки в код функции AWS Lambda.

Вы можете настроить и защитить ресурсы, связанные с функцией Lambda, с помощью API или консоли Lambda. Дополнительную информацию об этом вы можете найти в документации.

Да, любой код (платформы, пакеты SDK, библиотеки и т. д.) можно упаковать как уровень Lambda и использовать его с множеством функций, а также управлять им.

AWS Lambda автоматически выполняет мониторинг функции Lambda от имени пользователя, в режиме реального времени отправляя в Amazon CloudWatch соответствующие метрики, в том числе общее количество запросов, использованный ресурс параллельного исполнения на уровнях аккаунтов и функций, задержку, частоту возникновения ошибок и количество запросов, пропущенных вследствие ограничений. Просматривать статистику для каждой функции Lambda можно в консоли Amazon CloudWatch или консоли AWS Lambda. В функциях Lambda также можно использовать сторонние API для мониторинга.
 

Подробную информацию см. на странице Устранение неисправностей в метриках CloudWatch. Стандартная плата за использование AWS Lambda включает работу со встроенными метриками.

AWS Lambda автоматически интегрируется с сервисом Amazon CloudWatch Logs, создавая группу журналов для каждой функции Lambda и собирая информацию о базовом жизненном цикле приложения, включая записи о ресурсах, использованных при каждом запуске функции. Можно без труда вставить в код дополнительные операторы для сохранения в журнале. В функциях Lambda можно также использовать сторонние API для ведения журналов. Подробную информацию см. на странице Устранение неисправностей функций Lambda. Использование логов Amazon CloudWatch оплачивается отдельно.

Масштабировать функцию Lambda нет необходимости – AWS Lambda обеспечивает масштабирование автоматически. Каждый раз, получая оповещение о событии для функции, AWS Lambda быстро выделяет свободные вычислительные ресурсы и запускает код. Поскольку код не требует сохранения состояний, AWS Lambda может создавать необходимое количество копий функции без долгих процедур развертывания или задержек на настройку. Принципиальных ограничений на масштабирование функций не существует. AWS Lambda динамически распределяет ресурсы таким образом, чтобы они соответствовали количеству входящих событий.

В модели ресурсов AWS Lambda можно выбрать нужный для функции объем памяти, в соответствии с которым назначается мощность ЦПУ и другие ресурсы. Например, при выборе 256 МБ памяти функции Lambda назначается примерно в два раза больше мощности ЦПУ, чем для запрашиваемой памяти 128 МБ, и в два раза меньше, чем при выборе 512 МБ. Подробнее об этом см. в документации по конфигурированию функций.

Объем памяти можно выбрать в диапазоне от 128 МБ до 10 240 МБ.

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

Функции AWS Lambda можно настроить на время исполнения до 15 минут при каждом запуске. Можно также указать любое значение тайм‑аута в интервале от 1 секунды до 15 минут.

Работа AWS Lambda оплачивается только по факту использования. Подробнее см. на странице цен на AWS Lambda.

Да. Помимо экономии на использовании сервисов Amazon EC2 и AWS Fargate можно сократить расходы на AWS Lambda, используя тарифные планы Compute Savings Plans. Тарифные планы Compute Savings Plans позволяют получить скидку до 17 % на Duration, Provisioned Concurrency и Duration (Provisioned Concurrency). Тарифные планы Compute Savings Plans не предусматривают скидку на Requests при использовании Lambda. Тем не менее если вы используете тарифные планы Compute Savings Plans, вы можете пользоваться Requests по обычным расценкам.

Да. По умолчанию каждой функции AWS Lambda соответствует одна текущая версия кода. Клиенты функции Lambda могут вызывать конкретную версию или получать последний вариант. Подробнее см. в документации по управлению версиями функций Lambda.

Время развертывания зависит от размера кода, но обычно функции AWS Lambda готовы для вызова уже в течение нескольких секунд после загрузки.

Да. Вы можете добавить в код собственную копию библиотеки (включая AWS SDK) вместо версии, предоставляемой AWS Lambda по умолчанию.

AWS Lambda предоставляет уровни сниженных цен для ежемесячной продолжительности использования функций по требованию, превышающей определенные пороговые значения. Многоуровневое ценообразование предусмотрено для функций, выполняемых как на основе архитектуры x86, так и на основе архитектуры Arm. Ценовые уровни Lambda применяются к общей ежемесячной продолжительности использования функций по требованию, работающих на той же инфраструктуре (x86 или Arm соответственно), в одном регионе и в пределах аккаунта. Если у вас включена консолидированная оплата в Организациях AWS, ценовые уровни применяются к общей ежемесячной продолжительности использования функций, работающих на той же инфраструктуре, в одном регионе и в пределах аккаунтов организации. Например, если вы используете функции Lambda для x86 в регионе Восток США (Огайо), то с вас будет взиматься плата в размере 0,0000166667 USD за каждую гигабайт-секунду и первые 6 миллиардов ГБ-секунд в месяц, 0,0000150000 USD за каждую гигабайт-секунду и следующие 9 миллиардов ГБ-секунд в месяц и 0,0000133334 USD за каждую гигабайт-секунду и более 15 миллиардов ГБ-секунд в месяц. Оплата запросов, Provisioned Concurrency и продолжительность использования функции Provisioned Concurrency остаются без изменений. Дополнительную информацию см. в разделе Цены на AWS Lambda.

Да. Счет за использование Lambda, которое покрывается вашим почасовым планом экономии, выставляется по соответствующему тарифу CSP с учетом скидки. Остальное использование, которое не покрывается данным обязательством, будет оплачиваться по тарифу, соответствующему уровню, в который попадает ваша ежемесячная совокупная продолжительность функций.

Источник события – это сервис AWS или созданное разработчиком приложение, создающее события, которые запускают функцию AWS Lambda. Некоторые сервисы (например, Amazon S3) отправляют такие события в Lambda, напрямую вызывая функцию в облаке. Lambda также может опрашивать ресурсы в других сервисах, не посылающих события в Lambda. Например, Lambda может получать записи из потока Amazon Kinesis или очереди Amazon SQS и исполнять функцию Lambda для каждого полученного сообщения. Многие другие сервисы, например AWS CloudTrail, также могут выступать как источники событий путем входа в Amazon S3 и использования уведомлений корзины S3 в качестве триггеров функций AWS Lambda.

Полный перечень источников событий см. в нашей документации.

События передаются в функцию Lambda в качестве входного параметра события. Для источников событий, в которых события возникают пакетами (например, Amazon SQS, Amazon Kinesis или Amazon DynamoDB Streams), параметр события может содержать множество событий в одном вызове, основываясь на размере запрашиваемого пакета. Подробнее об уведомлениях о событиях в Amazon S3 см. в разделе Настройка уведомлений о событиях в Amazon S3. Подробнее о потоках Amazon DynamoDB см. в Руководстве для разработчиков потоков DynamoDB. Подробнее о вызове функций Lambda с помощью Amazon SNS см. в Руководстве для разработчиков Amazon SNS. Подробнее о событиях Amazon Cognito см. на странице Amazon Cognito. Подробнее о журналах AWS CloudTrail и аудите вызовов API в сервисах AWS см. на странице AWS CloudTrail.

В консоли AWS Lambda можно выбрать функцию и связать ее с уведомлениями от нужной корзины Amazon S3. Как вариант, можно использовать консоль Amazon S3 и настроить в ней отправление уведомлений нужной корзины в функцию AWS Lambda. Аналогичные функциональные возможности доступны в AWS SDK и интерфейсе командной строки.

Можно активировать функцию Lambda в ответ на обновление таблицы DynamoDB, подписав эту функцию Lambda на поток DynamoDB Streams, связанный с таблицей. Связать поток DynamoDB Streams с функцией Lambda можно в консоли Amazon DynamoDB, консоли AWS Lambda или посредством API registerEventSource сервиса Lambda.

В консоли AWS Lambda можно выбрать функцию Lambda и связать ее с потоком Amazon Kinesis, принадлежащим тому же аккаунту. Аналогичные функциональные возможности доступны в AWS SDK и интерфейсе командной строки.

Записи из потоков Amazon Kinesis Streams и DynamoDB Streams, переданные в функцию AWS Lambda, строго упорядочены по сегментам. Это означает, что, если вы поместите две записи в один сегмент, Lambda гарантирует, что функция Lambda будет успешно вызвана для первой записи, а потом будет вызвана для второй записи. Если вызов для одной записи превышает время ожидания, пропускается или возникают любые другие ошибки, Lambda будет повторно вызывать функцию, пока это не удастся (или пока не истечет срок действия записи, равный 24 часам), прежде чем перейти к следующей записи. Упорядочение записей в разных сегментах не гарантируется, при этом обработка каждого сегмента происходит параллельно.

AWS Lambda позволяет в одном логическом разделе, например в сегменте, за короткий промежуток времени до 15 минут выполнить агрегирование по времени (например, количество, максимальное значение, сумма, среднее значение и т. д.) для данных в Amazon Kinesis или Потоках Amazon DynamoDB. Благодаря этому можно легко настроить простую аналитику для вашего событийного приложения без добавления архитектурной сложности, поскольку правила бизнеса и логику аналитики можно разместить в одной функции. С помощью Lambda агрегирование происходит максимум за 15 минут в переворачивающемся окне на основе временной отметки события. Аналитика данных Amazon Kinesis Data Analytics позволяет создавать более сложные аналитические приложения, которые поддерживают гибкие варианты обработки данных и надежную отказоустойчивость с однократной обработкой без дублирования, а также аналитику, которую можно выполнить для всего потока данных в нескольких логических разделах. С помощью KDA данные можно анализировать в нескольких типах окон агрегирования (переворачивающееся окно, колеблющееся окно, скользящее окно, окно сеанса), используя время события или время обработки.
 

	AWS Lambda	Amazon KDA
Переворачивающееся окно	Да	Да
Колеблющееся окно	Нет	Да
Скользящее окно	Нет	Да
Окно сеанса	Нет	Да
Обогащение	Нет	Да
Совместные таблицы входящих и ссылочных данных	Нет	Да
Разделение входящего потока	Нет	Да
Строго однократная обработка	Нет	Да
Окно максимального времени	15 минут	Без ограничений
Охват агрегирования	Раздел/сегмент	Поток
Временная семантика	Время наступления события	Время наступления события, время обработки

В консоли AWS Lambda можно выбрать функцию Lambda и связать ее с темой Amazon SNS. Аналогичные функциональные возможности доступны в AWS SDK и интерфейсе командной строки.

В консоли Amazon SES можно задать свое правило обработки входящей почты для доставки сообщений сервисом Amazon SES в адрес функции AWS Lambda. Эти же функциональные возможности доступны посредством AWS SDK и интерфейса командной строки.

Сначала настройте предупреждение для отправки уведомлений посредством Amazon SNS. Затем в консоли AWS Lambda выберите функцию Lambda и свяжите ее с темой Amazon SNS. Подробнее о настройке предупреждений Amazon CloudWatch см. в Руководстве для разработчиков Amazon CloudWatch.

В консоли AWS Lambda можно выбрать функцию, которая будет запускаться при синхронизации любых наборов данных, связанных с пулом идентификационных данных Amazon Cognito. Аналогичные функциональные возможности доступны в AWS SDK и интерфейсе командной строки. Более подробную информацию об использовании Amazon Cognito для общего доступа и синхронизации данных между устройствами пользователя см. на странице Amazon Cognito.

Функцию Lambda можно вызвать с помощью специального события, используя в AWS Lambda API invoke. Вызывать функцию может только владелец функции или другой аккаунт AWS, которому владелец предоставил соответствующее разрешение. Подробнее см. в Руководстве для разработчиков Lambda.

AWS Lambda обеспечивает обработку события за миллисекунды. Задержка будет немного больше, если функция Lambda была недавно создана, обновлена или долгое время не использовалась.

Нужно загрузить соответствующий код для исполнения AWS Lambda, а затем вызвать его из соответствующего мобильного приложения, используя SDK AWS Lambda, включенный в пакет SDK AWS Mobile. Сервис позволяет совершать двусторонние (синхронные) вызовы для получения или проверки данных в режиме реального времени, а также асинхронные вызовы. Можно также настроить специальный API с помощью Amazon API Gateway и вызывать свои функции Lambda с помощью любого клиента, совместимого с API REST. Подробнее о мобильном SDK AWS см. на странице AWS мобильный SDK. Подробнее об API-шлюзе Amazon см. на странице API-шлюз Amazon.

Вызывать функции AWS Lambda можно через HTTPS, определив пользовательский API RESTful с помощью Amazon API Gateway. Это создаст адрес обращения к функции, готовый отвечать на такие вызовы REST, как GET, PUT и POST. Ознакомьтесь с дополнительной информацией об использовании AWS Lambda с Amazon API Gateway.

При вызове через SDK AWS Mobile функции AWS Lambda автоматически получают данные об устройстве и приложении, осуществившем вызов, через «контекстный» объект.

При использовании приложением идентификации Amazon Cognito авторизация конечных пользователей может выполняться с использованием различных публичных сервисов, таких как Amazon, Facebook, Google и других, совместимых с OpenID. Идентификация пользователя затем происходит автоматически и в защищенном виде передается в функцию Lambda в качестве Amazon Cognito ID, что позволяет функции получить доступ к данным пользователя в Amazon Cognito, или же в качестве ключа для хранения и получения данных в Amazon DynamoDB или других веб-сервисах.

AWS Lambda интегрирована с пакетом Alexa Skills Kit – набором API для самостоятельного использования, инструментов, документации и примеров кода, которые позволяют просто создавать функциональные возможности голосового управления («навыки») для Alexa. Требуется просто загрузить код функции Lambda для создаваемого навыка Alexa, а AWS Lambda сделает все остальное, выполняя код в ответ на голосовое взаимодействие Alexa и автоматически управляя вычислительными ресурсами в аккаунте клиента. Дополнительную информацию см. в документации Alexa Skills Kit.

Для уведомлений корзины Amazon S3 и специальных событий при возникновении ошибки, описанной в коде, или в случае превышения лимитов ресурсов или сервиса AWS Lambda попытается исполнить функцию трижды. Когда AWS Lambda опрашивает последовательные источники событий, такие как потоки Amazon DynamoDB Streams и Amazon Kinesis Streams, при ошибке кода разработчика Lambda продолжает попытки исполнения до тех пор, пока не истечет срок действия данных. Отслеживать ход работы можно в консоли Amazon Kinesis и Amazon DynamoDB, а также через метрики Amazon CloudWatch, которые AWS Lambda создает для соответствующей функции. Можно также настроить предупреждения Amazon CloudWatch на основе количества ошибок или пропусков выполнения.

Приложения на основе Lambda (называемые также бессерверными приложениями) состоят из функций, запускаемых событиями. Обычное бессерверное приложение состоит из одной или нескольких функций, запускаемых событиями, такими как оповещения о загрузке объекта в Amazon S3, Amazon SNS или действия API. Эти функции могут быть автономными или использовать в работе другие ресурсы, такие как таблицы DynamoDB или корзины Amazon S3. Большинство базовых бессерверных приложений представляют собой одну функцию.

Выполнять развертывание бессерверных приложений и управлять ими можно с помощью AWS Serverless Application Model (AWS SAM). AWS SAM – это спецификация, в которой предписаны правила создания бессерверных приложений на AWS. Эта спецификация совпадет с синтаксисом, используемым в настоящее время сервисом AWS CloudFormation, и поддерживается по умолчанию в AWS CloudFormation в качестве набора типов ресурсов (называемых «бессерверными ресурсами»). Такие ресурсы облегчают клиентам AWS использование CloudFormation для настройки и развертывания бессерверных приложений с помощью существующих API CloudFormation.

Можно выбрать приложения из коллекции бессерверных приложений, опубликованных разработчиками, компаниями и партнерами сообщества AWS, воспользовавшись репозиторием бессерверных приложений AWS. Выбрав подходящее приложение, его настройку и развертывание можно выполнить прямо из консоли Lambda.

Процесс выпуска бессерверного приложения можно автоматизировать с помощью AWS CodePipeline и AWS CodeDeploy. CodePipeline – это сервис непрерывной доставки, который позволяет моделировать, визуализировать и автоматизировать действия, необходимые для выпуска бессерверных приложений. CodeDeploy предоставляет механизм для автоматизации развертывания приложений на основе Lambda. CodeDeploy позволяет организовать развертывание в соответствии с общепринятыми передовыми методологиями, такими как канареечное и линейное развертывание, и помогает задать необходимые ограничения для проверки того, что вновь развернутый код является безопасным, стабильным и полностью готовым к выпуску в производство.
 

Подробнее о непрерывной интеграции и непрерывном развертывании (CI/CD) бессерверного ПО см. в документации.

Чтобы начать работу, откройте консоль AWS Lambda и загрузите одну из наших схем. В пакете, который вы загрузите, будет содержаться файл AWS SAM (который определяет ресурсы AWS в приложении), а также файл ZIP (который включает в себя код функции). После этого можно будет применить команды AWS CloudFormation для упаковки и развертывания загруженного бессерверного приложения. Подробнее см. в документации.

Для координации вызовов различных функций AWS Lambda в определенном порядке можно использовать сервис AWS Step Functions. С его помощью можно последовательно вызывать несколько функций Lambda, передавая результат одних на вход другим, и/или вызывать функции параллельно. В процессе выполнения функций Step Functions будет автоматически следить за поддержанием состояния.

Можно включить отслеживание используемых функций Lambda с помощью AWS X‑Ray, добавив разрешения X‑Ray для роли, исполняющей функции Lambda, и изменив в нужных функциях параметр tracing mode на active. Когда для функции Lambda включен сервис X‑Ray, AWS Lambda передает в X‑Ray информацию об отслеживании расхода ресурсов сервиса Lambda при вызове функции. Это позволит получать такие аналитические данные, как расход ресурсов Lambda, время инициализации и время исполнения функции. Кроме того, можно включить SDK X‑Ray в свой пакет развертывания Lambda, чтобы создавать собственные сегменты отслеживания, добавлять комментарии к своим отслеживаниям или просматривать отслеживаемые сегменты для нисходящих вызовов, поступающих из функции Lambda. Пакеты SDK X‑Ray в настоящее время доступны для Node.js и Java. Подробнее см. в разделе Устранение неисправностей в приложениях на базе Lambda. Использование AWS X-Ray оплачивается отдельно.

Да. Можно создавать безопасные бессерверные приложения с высокой степенью масштабируемости на основе Lambda, которые подключаются к реляционным базам данных с помощью прокси-сервера Amazon RDS. Это прокси-сервер с высоким уровнем доступности, который одновременно управляет тысячами подключений к реляционным базам данных. На данный момент RDS Proxy поддерживает базы данных MySQL и Aurora. Начать использовать RDS Proxy можно с помощью консоли Amazon RDS или консоли AWS Lambda. Бессерверные приложения, которые используют полностью управляемые пулы подключений со стороны прокси-сервера RDS, оплачиваются в соответствии с ценами на прокси-сервер RDS.

Спецификация поставляется с открытым исходным кодом по лицензии Apache 2.0, которая позволяет пользователям заимствовать и включать AWS SAM в инструменты создания, развертывания, мониторинга и управления с лицензией, позволяющей использовать их в коммерческих целях. Репозиторий AWS SAM на GitHub доступен по ссылке.

AWS Lambda теперь позволяет упаковывать и развертывать функции в виде образа контейнера. Клиенты могут создавать приложения, используя гибкость и привычные инструменты для работы с контейнерами, а также адаптивность и простоту использования AWS Lambda.

Можно начать с предоставленных AWS базовых образов для Lambda или использовать один из предпочтительных образов сообщества или частных корпоративных образов. Затем просто используйте Docker CLI, чтобы создать образ, загрузите его в Amazon ECR, после чего создайте функцию, используя все знакомые интерфейсы и инструменты Lambda, такие как Консоль управления AWS, CLI AWS, AWS SDK, AWS SAM и AWS CloudFormation.

В дополнение к предоставленным в Lambda образам можно развертывать сторонние базовые образы Linux (например, Alpine или Debian). AWS Lambda будет поддерживать все образы на основе таких форматов манифеста образов: Docker Image Manifest V2 Schema 2 (используется с Docker версии 1.10 и новее) или Open Container Initiative (OCI) Spec (версии 1.0 и выше). Lambda поддерживает образы размером до 10 ГБ.

Клиенты могут расширить множество базовых образов, предоставляемых AWS Lambda, а также использовать предпочтительные образы на базе Linux размером до 10 ГБ.

Можно использовать любые контейнерные инструменты, если они поддерживают один из таких форматов манифеста образов контейнера: Docker Image Manifest V2 Schema 2 (используется с Docker версии 1.10 и новее) или Open Container Initiative (OCI) Specifications (версии 1.0 и выше). Например, можно использовать встроенные контейнерные инструменты (такие как docker run, docker compose, Buildah и Packer), чтобы определить свои функции как образ контейнера и развернуть в Lambda.

С функциями, развернутыми как образы контейнеров, можно использовать все существующие возможности AWS Lambda, кроме уровней Lambda и подписания кода. После развертывания AWS Lambda будет рассматривать образ как неизменяемый. Клиенты могут использовать уровни контейнера в процессе сборки, чтобы включить зависимости.

В настоящий момент нет. После развертывания в AWS Lambda образ станет неизменяемым. Сервис не будет исправлять и обновлять образ. Однако AWS Lambda опубликует специальные базовые образы для всех поддерживаемых сред выполнения, основанных на управляемой среде Lambda. Такие опубликованные образы будут исправляться и обновляться наряду с обновлениями управляемых сред выполнения AWS Lambda. Можно извлечь и использовать последний базовый образ из DockerHub или Amazon ECR Public, заново создать образ контейнера и развернуть его в AWS Lambda через Amazon ECR. Это позволяет создавать и тестировать обновленные образы и среды выполнения перед их развертыванием в рабочей среде.

Существует три главных отличия между функциями, созданными с использованием архивов в формате ZIP, и образами контейнеров.

1. Максимальный размер пакета кода функций, созданных с помощью архивов в формате ZIP, в распакованном виде составляет 250 МБ, а максимальный размер образа функций, созданных с использованием образов контейнеров, – 10 ГБ. 
2. Lambda использует Amazon ECR как базовое хранилище кода для функций, определенных как образы контейнеров, поэтому функцию невозможно применить, когда базовый образ удален из ECR. 
3. Чтобы обеспечить новейшую безопасность во время исполнения и исправление ошибок, для ZIP-функции применяются автоматические исправления. Функции, определенные как образы контейнеров, являются неизменяемыми, и клиенты несут ответственность за компоненты, упакованные в их функции. Клиенты могут использовать предоставленные AWS базовые образы, которые AWS регулярно обновляет для обеспечения безопасности и исправления ошибок, используя при этом последние доступные исправления.

Нет. AWS Lambda гарантирует, что профили производительности для функций, упакованных как образы контейнеров и как ZIP-архивы, одинаковы, включая обычное время запуска менее секунды.

AWS Lambda не взимает дополнительную плату за упаковывание и развертывание функций в виде образов контейнеров. Когда вызывается функция, развернутая как образ контейнера, взимается обычная плата за запросы и время выполнения. Подробнее см. в разделеЦены на AWS Lambda. С вас будет взиматься плата за хранение образов контейнеров в Amazon ECR по стандартным ценам ECR. Подробнее см. в разделе Цены на Amazon ECR.

Эмулятор интерфейса среды выполнения Lambda — это прокси-сервер для API среды выполнения Lambda, с помощью которого клиенты могут локально тестировать свою функцию Lambda, упакованную в виде образа контейнера. Это облегченный веб-сервер, который преобразует HTTP-запросы в события JSON и эмулирует Runtime API в Lambda. С его помощью можно локально тестировать функции, используя знакомые инструменты, такие как cURL и Docker CLI (при тестировании функций, упакованных как образы контейнеров). Кроме того, он упрощает запуск приложения во время использования дополнительных вычислительных сервисов. Эмулятор интерфейса среды выполнения Lambda можно включить в образ контейнера, чтобы он изначально принимал HTTP-запросы вместо событий JSON, необходимых для развертывания в Lambda. Этот компонент не эмулирует оркестратор Lambda или конфигурации безопасности и аутентификации. Эмулятор интерфейса среды выполнения распространяется с открытым исходным кодом на GitHub. Для начала работы его можно загрузить и установить на локальный компьютер.

Runtime API в Lambda во время работы сервиса Lambda принимает события JSON и возвращает ответы. Эмулятор интерфейса среды выполнения Lambda позволяет функции, упакованной в виде образа контейнера, принимать HTTP-запросы во время локального тестирования с помощью таких инструментов, как cURL, и локально отображать их для функции через тот же интерфейс. Это позволяет использовать команду docker run или docker-compose up для локального тестирования приложения Lambda.

Эмулятор можно использовать, чтобы проверить, совместим ли код функции со средой Lambda, работает ли успешно и обеспечивает ли ожидаемый результат. Например, можно имитировать тестовые события из разных источников событий. Кроме того, можно использовать его для тестирования расширений и агентов, встроенных в образ контейнера, на соответствие API расширений для Lambda.

Клиенты могут добавить эмулятор интерфейса среды выполнения в качестве точки входа к образу контейнера или упаковать его в качестве сопутствующего элемента, чтобы гарантировать, что образ контейнера теперь принимает HTTP-запросы вместо событий JSON. Это упрощает внесение изменений, необходимых для запуска образа контейнера в дополнительных вычислительных сервисах. Клиенты несут ответственность за соблюдение всех рекомендаций по безопасности, производительности и параллельности для выбранной среды. Эмулятор интерфейса времени исполнения предварительно упакован в образы, предоставленные AWS Lambda, и по умолчанию доступен в AWS SAM CLI. Поставщики базовых образов могут использовать документацию, чтобы обеспечить одинаковую среду взаимодействия для своих базовых образов.

Контейнерное приложение можно развернуть в AWS Lambda, если оно соответствует указанным ниже требованиям.

1. Образ контейнера должен внедрять Runtime API в Lambda. У нас есть набор пакетов программного обеспечения с открытым исходным кодом (клиенты интерфейса среды выполнения), которые реализуют Runtime API в Lambda, что позволяет легко расширять предпочтительные базовые образы для обеспечения совместимости с Lambda.
2. Образ контейнера должен иметь возможность работать в файловой системе, доступной только для чтения. Ваш код функции может получить доступ к доступному для записи хранилищу каталога /tmp размером 512 МБ. Если используется образ, которому требуется доступный для записи корневой каталог, настройте его для записи в каталог /tmp.
3. Пользователь Lambda по умолчанию может читать файлы, необходимые для выполнения кода функции. Lambda определяет пользователя Linux по умолчанию с наименее привилегированными разрешениями, который выполняет рекомендации по безопасности. Вам необходимо убедиться, что код приложения не полагается на файлы, выполнение которых ограничено другими пользователями Linux.
4. Это образ контейнера на базе Linux.

AWS SnapStart позволяет повысить производительность запуска приложений, чувствительных к задержкам, с нескольких секунд до долей секунды. SnapStart работает путем создания снимка состояния инициализированной памяти (и диска) функции и кэширования этого снимка состояния для доступа с малой задержкой. При последующем вызове функции сервис Lambda возобновляет среды выполнения на основе этого предварительно инициализированного снимка состояния, а не инициализирует их с нуля, что снижает задержку при запуске. Для повышения стабильности работы сервис Lambda сохраняет кэшированные копии снимка состояния и автоматически применяет к ним обновления программного обеспечения, такие как обновления среды выполнения и исправления уязвимостей.

Lambda SnapStart – простая конфигурация функционального уровня, которую можно настроить для новых и существующих функций с помощью API Lambda, Консоли управления AWS, интерфейса командной строки AWS (CLI), AWS SDK, Комплекта для облачной разработки AWS (CDK), AWS CloudFormation и модели бессерверных приложений AWS (SAM). Если вы настроите Lambda SnapStart, то получите преимущества высокой производительности при запуске всех публикуемых версий функций. Дополнительную информацию о Lambda SnapStart см. в документации.

Lambda SnapStart позволяет оптимизировать производительность и ускорить время запуска функций посредством уменьшения переменной задержки, возникающей вследствие выполнения одноразового кода инициализации. Несмотря на то, что функция Lambda SnapStart позволяет уменьшить задержку при запуске, она работает на основе принципа «разумных усилий» и не гарантирует устранение «холодных» запусков. Если у вашего приложения имеются строгие требования касательно задержки и времени запуска, которое должно составлять не более ста миллисекунд, мы рекомендуем вам использовать PC.

Lambda SnapStart поддерживает несколько сред выполнения, включая Java 11 (и более новые версии), Python 3.12 (и более новые версии) и .NET 8 (и более новые версии). Поддержка будущих версий сред выполнения будет добавлена после их выпуска. Полный перечень сред выполнения, которые поддерживает Lambda, см. в документации.

Нет. Lambda SnapStart и PC нельзя активировать в одной и той же функции одновременно.

Да. Вы можете настроить доступ к ресурсам в виртуальном частном облаке (VPC) для функции Lambda SnapStart. Дополнительную информацию о том, как настроить VPC для своей функции, см. в документации по Lambda.

Да. Lambda SnapStart можно предоставить для функций, выполняемых как на основе архитектуры x86, так и на основе архитектуры Arm.

Нет. На данный момент нельзя активировать Lambda SnapStart с Amazon EFS.

Нет. На данный момент нельзя активировать Lambda SnapStart с краткосрочным хранилищем (/tmp) с объемом памяти более 512 МБ.

Да. Если ваш код подразумевает уникальность состояния, вам нужно оценить его устойчивость к операциям снимков состояния (таким как клонирование и восстановление). Подробные сведения об аспектах уникальности в снимках состояния виртуальных машин при использовании Lambda SnapStart см. в документации и блоге.

Да. Вы можете реализовать собственную программную логику перед созданием снимка состояния (установкой контрольных точек) и после его восстановления с помощью хуков сред выполнения. Дополнительную информацию см. в документации по Lambda SnapStart.

Да, с вас будет взиматься плата за кэширование снимка состояния в течение периода действия функциональной версии (не менее 3 часов, а затем с расчетом за каждую миллисекунду). Цена зависит от объема оперативной памяти, выделенной для функции. Кроме того, плата взимается каждый раз, когда Lambda возобновляет работу среды выполнения, восстанавливая снимок состояния. Стоимость зависит от объема памяти, выделяемой для выполнения функции. Подробная информация о ценах на SnapStart доступна на странице цен на AWS Lambda.

Цены на SnapStart не распространяются на поддерживаемые управляемые среды выполнения Java, которые могут кэшировать снимок состояния только на срок до 14 дней.

Как и в случае со всеми функциями Lambda, для функций SnapStart плата начисляется за продолжительность выполнения. Для функций, использующих SnapStart, продолжительность включает время загрузки среды выполнения, любой код, выполняемый в обработчике среды выполнения, и код инициализации, выполняемый при создании копий снимков состояния для обеспечения устойчивости.

При использовании Lambda SnapStart для Python и .NET снимки состояния функций остаются активными до тех пор, пока активна функция. В случае функций Java срок действия снимка состояния, связанного с опубликованной функцией, истекает, если он находится в неактивном состоянии на протяжении 14 дней.

Снимки состояния зашифровываются по умолчанию с помощью уникальных ключей Сервиса управления ключами AWS (KMS), которые находятся в собственности и под управлением сервиса Lambda. Клиенты также могут зашифровать снимки состояния с помощью ключей KMS, которые им принадлежат и полностью ими управляются.

Максимально допустимая продолжительность инициализации для Lambda SnapStart будет соответствовать длительности времени ожидания выполнения, которую вы настроили для своей функции. Максимальный лимит для настраиваемого времени ожидания выполнения функции составляет 15 минут.

Provisioned Concurrency позволяет лучше контролировать производительность бессерверных приложений. Когда эта возможность включена, функции находятся в инициализированном состоянии и готовы к быстрому реагированию в пределах ста миллисекунд

Параллельные операции для функции можно настроить в Консоли управления AWS, с помощью Lambda API, интерфейса командной строки AWS и AWS CloudFormation. Provisioned Concurrency проще всего использовать с помощью AWS Auto Scaling. Auto Scaling можно использовать для настройки расписаний. Кроме того, Auto Scaling автоматически регулирует уровень Provisioned Concurrency в режиме реального времени по мере изменения требований. Чтобы узнать больше о Provisioned Concurrency, см. документацию.

Для использования Provisioned Concurrency не требуется вносить изменения в код. Эта возможность эффективно работает со всеми существующими функциями и средами выполнения. При использовании Provisioned Concurrency в модели вызовов и выполнения Lambda нет никаких изменений.

Provisioned Concurrency добавляет ценовой аспект Provisioned Concurrency за поддержание функций в инициализированном состоянии. Когда включена эта возможность, вы оплачиваете указанное вами количество параллельных операций за выбранный период времени. Когда выполняется функция, для которой настроены параллельные операции, вы также платите за запросы и время выполнения. Подробнее о ценах на Provisioned Concurrency см. на странице Цены на AWS Lambda.

Provisioned Concurrency – оптимальный выбор для создания приложений, которые чувствительны к задержкам, например серверной части мобильных и интернет-приложений, синхронно вызываемых API и интерактивных микросервисов. Количество параллельных операций легко настраивается в зависимости от уникальных требований вашего приложения. Во время повышения активности можно увеличить количество параллельных операций, а во время ее снижения – уменьшить или выключить эту возможность.

Если количество параллельных операций функции достигает заданного уровня, то задержка и масштаб ее последующих вызовов будут такими же, как и у обычных функций Lambda. Масштабирование функции можно ограничить определенным уровнем. В этом случае функция не превысит заданный уровень Provisioned Concurrency. Этот механизм позволяет избежать нежелательных колебаний в работе приложения, когда спрос превышает ожидаемое количество операций.

AWS Lambda позволяет запускать функции на процессорах x86 или Arm. Процессоры AWS Graviton2 созданы по оригинальной разработке Amazon Web Services с использованием 64-битных ядер Arm Neoverse, чтобы обеспечить оптимальное соотношение цены и качества для облачных нагрузок. Клиенты получают те же преимущества AWS Lambda: запуск кода без подготовки или управления серверами, автоматическое масштабирование, высокая доступность и оплата только за используемые ресурсы.

Функции AWS Lambda на базе Graviton2, использующие архитектуру процессора на базе Arm от AWS, обеспечивают на 34 % более высокую производительность различных бессерверных рабочих нагрузок (веб- и мобильные серверы, обработка данных и потоковая обработка), чем функции на процессорах x86. Функции Graviton2 дают меньшую задержку, производительность на 19 % выше, сниженную на 20 % стоимость и наибольшую энергоэффективность, доступную в AWS. Благодаря этому они используются для критически важных бессерверных приложений. Клиенты могут выбрать Graviton2 в качестве целевого процессора как для существующих, так и для новых функций. Функции, работающие на Graviton2, можно развертывать как zip-файлы или как образы контейнеров.

Вы можете настроить запуск функций на Graviton2 с помощью консоли управления AWS, API AWS Lambda, интерфейса командной строки AWS CLI и AWS CloudFormation, установив для функции флажок архитектуры «arm64».

Между функциями на базе x86 и Arm нет никакой разницы. Просто загрузите zip-файл, образ контейнера или код через консоль управления AWS, и AWS Lambda автоматически запустит код при срабатывании триггера, не требуя предоставления инфраструктуры или управления ею.

Приложение может содержать функции, работающие на обеих архитектурах. AWS Lambda позволяет изменять архитектуру («x86_64» или «arm64») текущей версии функции. Но как только будет создана определенная версия функции, архитектуру изменить невозможно.

Интерпретируемые языки, такие как Python, Java и Node, обычно не требуют перекомпиляции, если код не ссылается на библиотеки со специфичными для архитектуры компонентами. В таких случаях потребуется предоставить библиотеки, предназначенные для arm64. Подробнее см. на странице Начало работы с AWS Graviton. Для неинтерпретируемых языков потребуется компиляция кода для arm64. Более современные компиляторы будут создавать код, скомпилированный для arm64, а вам потребуется развернуть его для тестирования в среде на базе arm. Подробнее об использовании функций Lambda с Graviton2 см. в документации.

Нет. Каждая версия функции может использовать только один образ контейнера.

Да. Уровни и расширения можно нацелить на совместимые архитектуры «x86_64» или «arm64». По умолчанию, архитектурой для функций и уровней является «x86_64».

После запуска клиенты могут использовать Python, Node.js, Java, Ruby, .Net Core, настраиваемую среду выполнения (provided.al2) и образы на базе OCI. Подробнее см. в статье о среде выполнения AWS Lambda.

Функции AWS Lambda на базе процессоров Graviton2 на 20 % дешевле функций Lambda на базе x86. Уровень бесплатного пользования можно использовать для работы функций AWS Lambda на базе архитектур x86 и Arm.

Каждая рабочая нагрузка уникальна, и мы рекомендуем клиентам протестировать функции и определить, видят ли они разницу в соотношении цены и производительности. Для этого можно использовать инструмент AWS Lambda Power Tuning. При тестировании рабочих нагрузок на возможное улучшение соотношения цены и производительности мы предлагаем начинать с веб- и мобильных серверов, обработки данных и потоковой обработки.

Amazon Elastic File System (Amazon EFS) для AWS Lambda позволяет клиентам безопасно считывать, записывать и сохранять большие объемы данных практически в любом масштабе, используя полностью управляемую эластичную файловую систему NFS, которую можно масштабировать по требованию без необходимости самостоятельно выделять ресурсы или управлять ими. Ранее для загрузки данных объемом до 512 МБ из S3 или баз данных в локальное временное хранилище разработчикам приходилось добавлять соответствующий код в свои функции. С EFS для Lambda писать код для загрузки данных во временное хранилище и их последующей обработки не требуется.

Разработчики могут без труда подключить существующую файловую систему EFS к функции Lambda через точку доступа EFS, используя консоль сервиса, интерфейс командной строки или SDK. При первом вызове функции файловая система автоматически подключается и становится доступной для кода функции. Подробнее см. в документации.

Да. Целевые точки подключения для Amazon EFS связаны с подсетью в VPC. Для функции AWS Lambda необходимо настроить доступ к этому облаку VPC.

EFS для Lambda идеально подходит для создания приложений машинного обучения, загрузки крупных справочных файлов или моделей, обработки или резервного копирования больших объемов данных, размещения веб‑контента или разработки внутренних систем сборки. Клиенты также могут использовать EFS для Lambda в целях сохранения состояния между вызовами в архитектуре микросервисов с фиксацией состояния, в рабочем процессе Step Functions или для обмена файлами между бессерверными приложениями и приложениями на основе инстансов или контейнеров.

Да. При передаче данных используется стандартный отраслевой протокол Transport Layer Security (TLS) 1.2 для шифрования данных, которыми обмениваются функции AWS Lambda и файловые системы EFS.

Клиенты могут настроить Amazon EFS для шифрования данных при хранении. Шифрование при хранении обеспечивает прозрачное шифрование данных при записи и прозрачное дешифрование во время чтения; изменения в код приложений вносить не требуется. Ключи шифрования управляются сервисом AWS Key Management Service (KMS), что исключает необходимость создания и поддержки собственной инфраструктуры безопасного управления ключами.

Дополнительная плата за использование Amazon EFS для AWS Lambda не начисляется. Клиенты оплачивают стандартную стоимость AWS Lambda и Amazon EFS. Если функции Lambda и EFS используются в одной зоне доступности, плата за передачу данных не взимается. Однако если используется пиринговое подключение VPC для доступа к нескольким аккаунтам, плата за передачу данных будет начисляться. Подробнее см. на странице расценок.

Нет. Каждая функция Lambda может иметь доступ только к одной файловой системе EFS.

Да. Amazon EFS поддерживает работу с функциями Lambda, контейнерами ECS и Fargate, а также инстансами EC2. Файловая система может находиться в совместном доступе, а для разделения прав доступа каждой функции, контейнера или инстанса можно использовать политики IAM и точки доступа Access Point.  

Да. Функции Lambda можно настроить с помощью URL-адреса функции – встроенного адреса HTTPS, который вызывается через браузер, Curl и любой HTTP клиента. URL-адреса функции позволяют с легкостью начать создание функций, доступных по протоколу HTTPS.

Вы можете настроить URL-адрес функции в консоли управления AWS, AWS Lambda API, AWS CLI, AWS CloudFormation и AWS Serverless Application Model. URL-адреса функции можно включить в последней ($LATEST) неквалифицированной версии функции или в любом псевдониме функции. Подробнее о настройке URL-адреса функции см. в документации.

Безопасность URL-адресов функции Lambda по умолчанию обеспечивается за счет авторизации IAM. При желании можно отключить авторизацию IAM для создания публичного адреса или внедрения пользовательской авторизации в бизнес-логику функции.

Вызвать функцию можно с помощью интернет-браузера, перейдя по URL-адресу Lambda, кода клиентского приложения, используя библиотеку HTTP, или командной строки, используя Curl.

Да. Вы можете настроить взаимодействие URL-адресов функции Lambda с версиями и псевдонимами. Если псевдоним не выбран, URL по умолчанию указывает на последний ($LATEST). В качестве цели URL-адресов функции нельзя выбрать отдельную версию функции.

URL-адреса функции в настоящий момент не поддерживают пользовательские имена доменов. Чтобы использовать пользовательский домен с URL функции, необходимо создать базу раздачи Amazon CloudFront и CNAME и сопоставить пользовательский домен с именем базы раздачи Amazon CloudFront. Затем обозначить доменное имя базы раздачи CloudFront, чтобы выполнить перенаправление к URL-адресу функции, выступающему источником.

Да, URL-адреса функции Lambda можно использовать для вызова функции в VPC.

Дополнительная плата за использование URL-адресов отсутствует. Вы платите стандартную цену за AWS Lambda. Подробнее см. на странице Цены на AWS Lambda.

С Lambda@Edge можно запускать код в местоположениях AWS по всему миру без выделения серверов и управления ими и обеспечивать ответ на запросы конечных пользователей с минимальной сетевой задержкой. Сервис позволяет загрузить код Node.js или Python в AWS Lambda и настроить вызов конкретной функции в ответ на запросы сервиса Amazon CloudFront (т. е. при получении запроса пользователя, при перенаправлении запроса серверу‑источнику, при возврате запроса от сервера‑источника, а также непосредственно перед отправкой ответа конечному пользователю). После этого код готов к исполнению в местоположениях AWS во всем мире при каждом получении запроса на контент. При этом код будет масштабироваться вместе с объемом запросов CloudFront по всему миру. Подробнее см. в нашей документации.

Чтобы использовать Lambda@Edge, достаточно загрузить свой код в AWS Lambda и настроить вызов функции в ответ на запросы Amazon CloudFront. Код должен соответствовать лимитам сервиса Lambda@Edge. Lambda@Edge поддерживает для глобального вызова на основе событий CloudFront код Node.js и Python. Подробнее см. в нашей документации.

Lambda@Edge оптимизирован для чувствительных к задержкам приложений, конечные пользователи которых располагаются по всему миру. Вся информация, необходимая для принятия решения, должна быть доступна на стороне CloudFront в рамках функции и запроса. Например, если требуется принять решение о доставке контента на основании ряда характеристик пользователя (местоположение, устройство и т. д.), теперь это можно сделать ближе к пользователям, без отправки информации на централизованный сервер.

Да, существующие функции Lambda можно связывать с событиями CloudFront для вызова в глобальном режиме, если функция удовлетворяет требованиям и лимитам сервиса Lambda@Edge. Подробнее об обновлении характеристик функций см. по ссылке.

Функции могут быть автоматически запущены в ответ на следующие события Amazon CloudFront.

• Запрос пользователя. Это событие возникает, когда конечный пользователь или устройство в Интернете отправляет в CloudFront запрос HTTP(S), который поступает в ближайшее к пользователю периферийное местоположение.
• Ответ посетителю. Это событие возникает, когда сервер CloudFront в периферийном местоположении готов ответить конечному пользователю или устройству, сделавшему запрос.
• Запрос источника. Это событие возникает, когда в кэше периферийного сервера CloudFront отсутствует запрошенный объект и запрос посетителя перенаправляется на веб‑сервер источника (например, Amazon EC2, Application Load Balancer или Amazon S3).
• Ответ источника. Это событие возникает, когда сервер CloudFront в периферийном местоположении получает ответ от веб‑сервера источника.

Разница в том, что API Gateway и Lambda являются региональными сервисами. Использование Lambda@Edge и Amazon CloudFront позволяет исполнять логику программы в нескольких местоположениях AWS в зависимости от местонахождения конечных пользователей.

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

Да. При обновлении функции Lambda возникает краткий промежуток времени (обычно меньше минуты), когда запросы обрабатываются только старой или новой версией функции.

AWS Lambda обеспечивает параллельный запуск множества инстансов для работы функций. Однако в AWS Lambda существует защитное ограничение по умолчанию на количество одновременных исполнений на аккаунт в регионе (перейдите по этой ссылке, чтобы получить информацию о защитных ограничениях по умолчанию). Можно также контролировать максимальное число параллельных исполнений для отдельных функций AWS Lambda, что позволяет зарезервировать часть связанного с аккаунтом лимита параллельного исполнения для критически важных функций. Кроме того, это позволяет ограничить интенсивность трафика к ресурсам дальнейшей обработки.

Если вы хотите отправить запрос на увеличение лимита одновременных исполнений, используйте квоты на обслуживание.

В случае превышения ограничения одновременных исполнений синхронно вызываемые функции AWS Lambda возвращаются с ошибкой регулирования (код ошибки 429). Функции Lambda, вызываемые асинхронно, на протяжении 15–30 минут могут поглощать значительные объемы трафика, после чего входящие события будут отклоняться и пропускаться. Если функция Lambda вызвана в ответ на события Amazon S3, отклоненные события AWS Lambda могут быть сохранены и отправлены из Amazon S3 повторно в течение 24 часов. События из потоков Amazon Kinesis Streams и Amazon DynamoDB Streams вызываются повторно до тех пор, пока функция Lambda не будет исполнена успешно или пока не истечет срок действия данных. Amazon Kinesis и потоки Amazon DynamoDB сохраняют данные на протяжении 24 часов.

Максимальные ограничения одновременных исполнений по умолчанию применяются на уровне учетной записи. Однако вы также можете установить ограничения на отдельные функции (см. статью о параллельном резервировании).

Каждая синхронно вызываемая функция Lambda может масштабироваться со скоростью до 1000 одновременных исполнений каждые 10 секунд. Хотя скорость масштабирования Lambda подходит для большинства примеров использования, она особенно подходит для сценариев с предсказуемыми или непредсказуемыми всплесками трафика. Например, обработка данных в соответствии с SLA требует предсказуемого, но быстрого масштабирования для удовлетворения спроса на обработку. Аналогичным образом, публикация последних новостей или мгновенные продажи могут привести к непредсказуемому росту трафика за короткий период времени. Скорость масштабирования Lambda позволяет упростить такие примеры использования без дополнительных конфигураций или инструментов. Кроме того, ограничение параллельного масштабирования – это ограничение на уровне функций. Это означает, что каждая функция в вашем аккаунте масштабируется независимо от других.

При возникновении сбоя синхронно вызываемые функции Lambda ответят с ошибкой исключения. Функции Lambda, запускаемые асинхронно, вызываются повторно не менее трех раз. События из потоков Amazon Kinesis Streams и Amazon DynamoDB Streams вызываются повторно до тех пор, пока функция Lambda не будет исполнена успешно или пока не истечет срок действия данных. Потоки Kinesis и DynamoDB хранят данные не менее суток.

В качестве очереди необрабатываемых сообщений можно настроить очередь Amazon SQS или тему Amazon SNS.

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

Назначение разрешений для функции Lambda происходит с помощью ролей IAM. При исполнении функции Lambda AWS Lambda учитывает назначенную роль, что обеспечивает владельцу аккаунта полный и надежный контроль ресурсов AWS, которые функция может использовать. Подробнее о ролях см. на странице Настройка AWS Lambda.

При настройке корзины Amazon S3 для отправки сообщений в функцию AWS Lambda создается правило политики ресурсов, разрешающее доступ. Подробнее о политиках ресурсов и контроле доступа к функциям Lambda см. в Руководстве для разработчиков Lambda.

Управление доступом осуществляется с помощью роли для функции Lambda. Роль, которая назначена функции Lambda, определяет и то, какие ресурсы может опрашивать AWS Lambda. Подробнее см. в Руководстве для разработчиков Lambda.

Контроль доступа можно задать с помощью роли для функции Lambda или параметров политики ресурсов в самой очереди. При существовании обеих политик будет применяться более строгая.

Чтобы получить доступ к ресурсам VPC можно включить функции Lambda, указав подсеть и группу безопасности в конфигурации функций. Функции Lambda, настроенные на доступ к ресурсам в конкретном облаке VPC, по умолчанию не будут иметь доступа к Интернету. Чтобы предоставить им доступ, используйте интернет-шлюзы. По умолчанию функции Lambda взаимодействуют с ресурсами VPC с двумя стеками по протоколу IPv4. Можно настроить функции для доступа к ресурсам VPC с двумя стеками по протоколу IPv6. Дополнительные сведения о функциях Lambda, настроенных в VPC, см. в разделе Частные сети Lambda с VPC.

Подписание кода для AWS Lambda предлагает средства контроля доверия и целостности, которые позволяют обеспечить развертывание в ваших функциях Lambda только неизменного кода от подтвержденных разработчиков. Для цифровой подписи артефактов кода и настройки функций Lambda с целью проверки подписей при развертывании можно использовать AWS Signer — полностью управляемый сервис подписи кода. В настоящее время подписание кода для AWS Lambda доступно только для функций, упакованных в виде ZIP-архивов.

Артефакты кода с цифровой подписью можно создавать с помощью профиля подписи через консоль AWS Signer, Signer API, SAM CLI или AWS CLI. Подробнее см. в документации по AWS Signer.

Чтобы включить подписание кода, можно создать конфигурацию подписания кода через Консоль управления AWS, Lambda API, AWS CLI, AWS CloudFormation и AWS SAM. Конфигурация подписания кода помогает задать утвержденные профили подписи и указать, что делать в случае сбоя проверки подписи – предупреждать или отклонять развертывания. Конфигурации подписания кода можно прикрепить к отдельным функциям Lambda, чтобы включить возможность подписания кода. Теперь такие функции начинают проверку подписей при развертывании.

При развертывании AWS Lambda может выполнять указанные ниже проверки подписи:

• Поврежденная подпись: это происходит, если артефакт кода изменен после подписания.
• Несоответствующая подпись: это происходит, если артефакт кода подписан с помощью неподтвержденного профиля подписи.
• Подпись с истекшим сроком действия: это происходит, если подпись применяется после установленной даты окончания.
• Отозванная подпись: это происходит, если владелец профиля подписи отзывает задания подписи.

Подробнее см. в документации по AWS Lambda.

Да, подписание кода можно включить для существующих функций, прикрепив к функции конфигурацию подписания кода. Это можно сделать с помощью консоли AWS Lambda, Lambda API, AWS CLI, AWS CloudFormation и AWS SAM.

Дополнительная плата за использование подписания кода для AWS Lambda не взимается. Вы платите стандартную цену за AWS Lambda. Подробнее см. на странице расценок.

Чтобы по умолчанию упростить и расширить возможности ведения журнала, AWS Lambda предлагает расширенные средства управления, такие как возможность встроенного сбора журналов функций Lambda в структурированном формате JSON, управление фильтрацией журналов функций Lambda на уровне журналов без внесения изменений в код и настройку группы журналов Amazon CloudWatch, в которую их отправляет Lambda.

Журналы функций Lambda можно записывать в структурированном формате JSON, не используя собственные библиотеки журналов. Структурированные журналы JSON упрощают поиск, фильтрацию и анализ больших объемов записей журнала. Можно управлять фильтрацией журналов функций Lambda на уровне журналов без внесения изменений в код, что позволяет выбрать требуемый уровень детализации ведения журнала для функций Lambda, не просматривая большие объемы журналов при отладке и устранении ошибок. Также можно указать, в какую группу журналов Amazon CloudWatch Lambda будет их отправлять, что упростит объединение журналов нескольких функций приложения в одном месте. Затем можно применять политики безопасности, управления и хранения к журналам на уровне приложения, а не по отдельности к каждой функции.

Указать расширенные средства управления для ведения журналов для функций Lambda можно с помощью AWS Lambda API, консоли AWS Lambda, интерфейса командной строки AWS, модели бессерверных приложений AWS (SAM) и AWS CloudFormation. Чтобы узнать больше, ознакомьтесь с публикацией в блоге о запуске расширенных средств для ведения журналов или с Руководством для разработчиков Lambda.

Да, вы можете использовать собственные библиотеки журналов для создания журналов Lambda в структурированном формате JSON. Чтобы обеспечить бесперебойную работу ваших библиотек журналов со встроенной функцией структурированного ведения журнала в формате JSON в Lambda, Lambda не будет дважды кодировать журналы, созданные вашей функцией и уже закодированные в формате JSON. Для записи журналов Lambda в структурированном формате JSON также можно использовать библиотеку Powertools для AWS Lambda.

Дополнительная плата за использование расширенных средств управления для ведения журналов в Lambda не взимается. Плата в Журналах Amazon CloudWatch будет по-прежнему взиматься за прием и хранение журналов Lambda. Подробные сведения о ценах на журналы см. на странице цен CloudWatch.

Отслеживание состояния приложений CloudWatch — это решение для мониторинга производительности приложений (APM), которое позволяет разработчикам и операторам легко отслеживать работоспособность и производительность бессерверных приложений, созданных с помощью Lambda. Функция отслеживания состояния приложений включает готовые стандартизированные панели для мониторинга критически важных метрик приложений, связанных отслеживаний и взаимодействия между функциями Lambda и их зависимостями, причем всё это не требует от разработчиков применения инструментария в ручном режиме или внесения изменений в код.

Вы можете одним щелчком мыши включить отслеживание состояния приложений для функции в разделе «Инструменты мониторинга и эксплуатации» на вкладке «Конфигурация» в консоли Lambda. Включив отслеживание состояния приложений, можно просматривать готовые информационные панели, карту сервисов и многое другое, а также анализировать производительность и работоспособность бессерверных приложений в консоли CloudWatch. Более подробные сведения можно найти в Руководстве для разработчиков Lambda и Руководстве для разработчиков по отслеживанию состояния приложений. Посетите страницу цен на CloudWatch, чтобы узнать больше о том, как взимается плата за использование отслеживания состояния приложений с функциями Lambda.

CloudWatch Logs Live Tail — это интерактивная функция потоковой передачи и анализа журналов, которая обеспечивает визуализацию журналов в реальном времени, позволяя упростить разработку и отладку функций Lambda. Благодаря ей разработчики могут оперативно тестировать и проверять изменения кода и конфигурации в реальном времени, ускоряя цикл «создание-тестирование-развертывание» (также именуемый «внутренний цикл разработки») при создании приложений с помощью Lambda. Кроме того, применение Live Tail позволяет операторам и специалистам DevOps более эффективно обнаруживать и отлаживать сбои и критические ошибки в коде функций Lambda, сокращая среднее время восстановления (MTTR) после устранения возникших в этих функциях ошибок.

Чтобы использовать Live Tail для функции Lambda, откройте консоль Lambda и нажмите кнопку «Открыть CloudWatch Live Tail» в редакторе кода. Дополнительные сведения см. в Руководстве для разработчиков Lambda. Посетите страницу цен на CloudWatch, чтобы узнать больше о том, как взимается плата за использование Live Tail с функциями Lambda.

Для компиляции функции Lambda можно использовать стандартные инструменты, такие как Maven или Gradle. Процесс сборки будет аналогичен процессу сборки, который используется при компиляции любого кода Java, зависимого от AWS SDK. Запустите инструмент компиляции Java для своих файлов с исходным кодом и включите в путь к классам пакет AWS SDK 1.9 или новее с переходными зависимостями. Подробнее см. в документации.

Lambda предоставляет сборку openjdk 1.8 для Amazon Linux.

Да. Можно использовать как пакеты NPM, так и специальные пакеты. Подробнее см. здесь.

Да. Встроенная изолированная среда Lambda позволяет пакетно запускать скрипты («сценарии оболочки»), другие языки выполнения, сервисные программы и выполняемые файлы. Подробнее см. здесь.

Да. Любой статически связанный встроенный модуль может быть включен в загружаемый файл ZIP, как и динамически связанные модули, в сборку которых включено указание rpath на корневую директорию функции Lambda. Подробнее см. здесь.

Да. Вы можете использовать команду child_process для Node.js, чтобы исполнить бинарный файл, включенный в функцию, или любой исполняемый файл в Amazon Linux, видимый для функции. Как вариант, несколько пакетов NPM могут существовать в качестве упакованных бинарных файлов командной строки, например node‑ffmpeg. Подробнее см. здесь.

Чтобы выполнить развертывание кода функции Lambda, написанного на Node.js, просто упакуйте свой код JavaScript и зависимые библиотеки в формат ZIP. Вы можете загрузить ZIP-файл со своего локального компьютера либо указать местоположение этого ZIP-файла в Amazon S3. Подробнее см. в документации.

Да. С помощью системы управления пакетами pip можно установить любые нужные пакеты Python.

Функцию Lambda на C# можно создать с помощью среды разработки Visual Studio, выбрав команду «Publish to AWS Lambda» в обозревателе решений. Можно также выполнить команду «dotnet lambda publish» непосредственно с помощью интерфейса командной строки dotnet с установленным пакетом [# Lambda CLI tools patch]. В результате будет создан пакет ZIP с исходным кодом на C# вместе со всеми зависимостями NuGet, а также опубликованной сборкой DLL, а затем выполнена его автоматическая загрузка в AWS Lambda с использованием параметра среды выполнения «dotnetcore1.0»

Пакет развертывания PowerShell на Lambda – это файл ZIP, который содержит скрипт PowerShell, модули PowerShell, необходимые для данного скрипта, а также сборки, требуемые для размещения среды PowerShell Core. Чтобы создать пакет развертывания PowerShell на Lambda, используйте модуль PowerShell AWSLambdaPSCore, который можно установить из галереи PowerShell.

Загрузите исполняемый артефакт Go в виде файла ZIP с помощью интерфейса командной строки AWS или консоли Lambda и выберите среду выполнения go1.x. При работе с Lambda для создания и упаковки кода можно использовать встроенные инструменты Go. Подробнее см. в документации. 

Чтобы выполнить развертывание функции Lambda, написанной на Ruby, упакуйте код и гемы Ruby в файл ZIP. Вы можете загрузить ZIP-файл со своего локального компьютера либо указать местоположение этого ZIP-файла в Amazon S3.

Список поддерживаемых версий см. по ссылке.

Нет. Для всех пользователей сервиса AWS Lambda предлагает одну версию операционной системы и среды выполнения соответствующего языка. В Lambda можно использовать собственную среду выполнения для языка программирования.

Сервис AWS Lambda интегрирован с AWS CloudTrail. AWS CloudTrail может записывать информацию об использовании API аккаунтом в файлы журналов и отправлять их в корзину Amazon S3, принадлежащую пользователю.

Для координации вызова различных функций Lambda можно использовать сервис Amazon Step Functions. С его помощью можно вызывать несколько функций Lambda последовательно, передавая результат исполнения одних функций на вход другим, или параллельно. Подробнее см. в документации.

Да, AWS Lambda поддерживает набор инструкций Advanced Vector Extensions 2 (AVX2). Подробнее о том, как скомпилировать код приложения, чтобы повысить производительность этого набора инструкций, см. в документации для разработчиков AWS Lambda.