Вопросы и ответы по AWS 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.

Для отслеживания использования краткосрочного хранилища 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, см. соответствующую документацию.

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

При использовании 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 оплачивается отдельно.

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

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

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

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

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

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

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

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

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

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

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. Для начала работы его можно загрузить и установить на локальный компьютер.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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