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

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

AWS Lambda обеспечивает встроенную поддержку Java, Go, PowerShell, Node.js, C#, Python и Ruby, а также предоставляет API времени выполнения, с помощью которого для создания функций можно использовать любой дополнительный язык программирования. Ознакомьтесь с нашей документацией по использованию Node.js, Python, Java, Ruby, C#, Go и PowerShell.

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

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

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

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

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

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

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

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

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

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

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

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

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

AWS Lambda 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, см. в документации.

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

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

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

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

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

Provisioned Concurrency добавляет ценовой аспект Provisioned Concurrency за поддержание функций в инициализированном состоянии. Когда включена эта возможность, вы оплачиваете указанное вами количество параллельных операций за выбранный период времени. Когда выполняется функция, для которой настроены параллельные операции, вы также платите за запросы и время выполнения. Подробнее о ценах на Provisioned Concurrency см. на странице цен на 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. Подробнее об обновлении характеристик функций см. по ссылке.

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 происходит с помощью ролей IAM. При исполнении функции Lambda AWS Lambda учитывает назначенную роль, что обеспечивает владельцу аккаунта полный и надежный контроль ресурсов AWS, которые функция может использовать. Подробнее о ролях см. на странице настройки AWS Lambda.

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

Управление доступом осуществляется с помощью роли для функции Lambda. Роль, которая назначена функции Lambda, определяет и то, какие ресурсы может опрашивать AWS 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 может выполнять указанные ниже проверки подписи.

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

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

Дополнительная плата за использование подписи кода для 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 (CLI), модели бессерверных приложений 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 и их зависимостями, причем всё это не требует от разработчиков применения инструментария в ручном режиме или внесения изменений в код.

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

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

В настоящее время устойчивые функции AWS Lambda поддерживают JavaScript, TypeScript, Python и Java. Подробнее о поддерживаемых временах выполнения.

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

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

Время ожидания выполнения (до 1 года) определяет, как долго может длиться выполнение. Период хранения (до 90 дней) определяет, как долго сохраняются данные истории и контрольных точек после того, как выполнение достигнет конечного состояния. Период хранения не влияет на текущие выполнения. См. раздел Настройка устойчивых функций.

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

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

Состояние выполнения хранится во внутреннем хранилище состояний с полным управлением. Каждая операция с контрольной точкой, такая как шаг или обратный вызов, может хранить до 256 КБ данных. Это ограничение распространяется на данные, возвращаемые по итогам операции. Данные, с которыми выполняются операции в рамках данной операции, например чтение и запись больших объектов S3, не учитываются при расчете этого ограничения. Если операции необходимо вернуть большой результат, вы можете настроить в SDK пользовательские сериализаторы для переноса полезных данных в Amazon S3 или Amazon DynamoDB и передачи через контрольную точку только ссылки.

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

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