Стабильная цель вызова во время загрузки нового кода Lambda.
→Публикуйте нумерованные, неизменяемые версии; создавайте алиас, который указывает на версию. Вызывающие стороны используют ARN алиаса.
Почему: Версии — это замороженные снимки кода + конфигурации; алиасы обеспечивают косвенность, поэтому вызывающие стороны никогда не вызывают `$LATEST` напрямую.
Источник↗
Постепенное развертывание новой версии Lambda с автоматическим откатом при ошибках.
→Алиас с маршрутизацией версий по весам (например, 90/10). CodeDeploy `LambdaCanary10Percent5Minutes` или `LambdaLinear*` перенаправляет трафик и отслеживает CloudWatch alarms.
Почему: Встроенное перенаправление трафика + откат по тревоге устраняет необходимость в написании собственной логики canary.
Источник↗
Внедрение конфигурации (URL базы данных, feature flags) без повторного развертывания.
→Переменные среды Lambda. KMS-зашифрованы в состоянии покоя; для дополнительного шифрования при передаче во время извлечения используйте пользовательский CMK.
Источник↗
Совместное использование NumPy / pandas / общих runtime для многих Lambda-функций.
→Упакуйте как Lambda Layer; до 5 слоев на функцию, общий объем 250 МБ в распакованном виде. Версионированный ARN для каждого слоя.
Источник↗
Синхронная Lambda, чувствительная к задержкам — холодные старты недопустимы.
→Provisioned Concurrency для алиаса. Предварительно инициализирует N сред выполнения; оплата за ГБ-секунду.
Почему: Устраняет холодный старт с предсказуемой стоимостью. Настройте application auto-scaling на алиасе для гибкости при нагрузке.
Источник↗
Lambda на Java или Python с тяжелым init-кодом; требуется быстрый холодный старт без оплаты Provisioned Concurrency.
→Включите SnapStart на опубликованной версии. AWS делает снимок инициализированного runtime и возобновляет работу с него.
Почему: Бесплатно для Java; оплачивается за восстановление для Python/.NET. Сокращает холодные старты с секунд до <1 с без затрат на простой.
Источник↗
Lambda должна потреблять поток Kinesis / DynamoDB Stream / очередь SQS / тему MSK.
→Event source mapping (pull-based). Lambda опрашивает; размер пакета + максимальное окно пакетирования настраивают пропускную способность по сравнению с задержкой. Сбой → DLQ через On-Failure destination.
Почему: Для pull-источников сервис не может напрямую вызывать Lambda; маппинг — это адаптер опроса Lambda.
Источник↗
Асинхронная маршрутизация успеха/сбоя Lambda без Lambda DLQ.
→OnSuccess / OnFailure destinations на функции. Цели: SNS, SQS, EventBridge, другая Lambda. Включает контекст вызова.
Почему: Destinations захватывают полное событие + ответ; устаревший DLQ захватывает только полезную нагрузку события.
Источник↗
Выбрать тип API Gateway для нового REST API.
→HTTP API: дешевле, быстрее, встроенная JWT auth, проще. REST API: полные возможности (mapping templates, request validators, WAF, private endpoints, X-Ray, API caching).
Почему: По умолчанию используйте HTTP API, если не требуется функция только для REST. WebSocket APIs — отдельный продукт для stateful real-time.
Источник↗
Продвижение изменений API из dev → test → prod без переразвертывания отдельных API.
→Stages на одном API. Разверните stage для публикации; stage variables содержат значения, специфичные для среды, такие как имена алиасов Lambda.
Источник↗
Backend Lambda ожидает другой формат, чем тот, который отправляет клиент.
→Request/response mapping template (только для REST API). VTL с `$input`, `$context`, `$util` для преобразования JSON.
Почему: Mapping templates выполняются в API Gateway — без дополнительного хопа Lambda, без дополнительной задержки или стоимости.
Источник↗
Проверить пользовательский токен (не Cognito, не IAM) перед маршрутизацией запроса.
→Lambda authorizer. Тип TOKEN считывает заголовок; тип REQUEST считывает полный контекст запроса. Возвращает политику IAM + principalId. Кэшируется для каждой идентичности на срок TTL.
Источник↗
Проверить Cognito User Pool JWT при каждом запросе.
→Cognito User Pool authorizer (REST) или JWT authorizer (HTTP). API Gateway проверяет токен; Lambda не нужна.
Почему: Нативная валидация дешевле и быстрее, чем Lambda authorizer для обычных случаев JWT.
Источник↗
Регулировать/квотировать потребителя API партнера.
→Usage Plan + API Key. План привязывает ключи к stage с лимитом скорости (req/сек) + burst + квотой (req/день или месяц).
Источник↗
Уменьшить нагрузку на backend для повторяющихся GET-запросов.
→Кэш на уровне stage (REST API). TTL настраивается; ключ кэша формируется из метода + пути + выбранных query/header параметров.
Источник↗
Обновить элемент только при выполнении предусловия (например, status == "PENDING").
→PutItem/UpdateItem с `ConditionExpression`. Сбой вызывает `ConditionalCheckFailedException`.
Почему: Проверка на стороне сервера избегает read-modify-write гонок без блокировки.
Источник↗
Все или ничего для нескольких элементов DynamoDB.
→`TransactWriteItems` / `TransactGetItems`. До 100 элементов / 4 МБ; стоимость WCU/RCU в 2 раза выше, чем у обычных операций записи/чтения.
Источник↗
Увеличить счетчик без read-modify-write.
→UpdateExpression `ADD count :inc`. Сервер атомарно применяет дельту.
Источник↗
Требуется дополнительный шаблон доступа помимо первичного ключа.
→GSI: альтернативный ключ раздела + сортировки, в конечном итоге консистентный, отдельная емкость, может быть добавлен в любое время. LSI: тот же ключ раздела, альтернативный ключ сортировки, опция строгой консистентности, должен быть создан при создании таблицы.
Источник↗
Индексировать только элементы, имеющие определенный атрибут (например, только ACTIVE заказы).
→Sparse index: опустите атрибут на элементах, которые вы хотите исключить. Элементы без индексированного атрибута не появляются в GSI/LSI.
Источник↗
Пакетное чтение/запись множества элементов.
→`BatchGetItem` (до 100 элементов / 16 МБ) и `BatchWriteItem` (до 25 элементов / 16 МБ). Не атомарно; частичные сбои возвращаются в `UnprocessedItems`.
Источник↗
Предотвратить потерянные обновления от параллельных писателей.
→Атрибут версии + `ConditionExpression: version = :v`. Неудавшиеся записи повторяются путем повторного чтения.
Источник↗
Запускать последующие действия при каждом изменении DynamoDB.
→DynamoDB Streams + Lambda event source mapping. Представление потока: NEW_IMAGE / OLD_IMAGE / NEW_AND_OLD_IMAGES / KEYS_ONLY.
Источник↗
Браузер загружает/скачивает напрямую в S3 без проксирования байтов вашим сервером.
→SDK `getSignedUrl` для GET или PUT. Срок действия до 7 дней при подписании пользователем IAM (sigv4); короче для сессий, производных от роли.
Почему: Снижает нагрузку на пропускную способность вашего backend; URL является временной возможностью, ограниченной одним объектом + методом.
Источник↗
Надежная загрузка большого файла (≫100 МБ) из SDK.
→`CreateMultipartUpload` → параллельный `UploadPart` → `CompleteMultipartUpload`. Высокоуровневый менеджер передачи SDK автоматически управляет размером частей.
Почему: Требуется >5 ГБ; рекомендуется ≥100 МБ. Неудавшиеся части загружаются повторно независимо. Настройте жизненный цикл на прерывание незавершенных многочастных загрузок для освобождения хранилища.
Источник↗
Запускать код при создании/удалении объекта в S3.
→S3 Event Notifications → Lambda / SNS / SQS / EventBridge. Фильтр по префиксу и суффиксу.
Источник↗
Приложение браузера извлекает данные из S3 между источниками (`fetch('https://bucket.s3...')`); предварительный запрос CORS завершается неудачей.
→Настройте правила CORS для бакета: разрешенные источники, методы (GET/PUT), заголовки и открытые заголовки.
Источник↗
Фильтровать строки из объекта CSV/JSON/Parquet размером 50 ГБ без его скачивания.
→S3 Select с SQL. Возвращает только соответствующие строки; оплата за сканирование + возвращенные байты.
Источник↗
Вход пользователя с общедоступного мобильного/веб-клиента без отправки пароля.
→Cognito User Pool с потоком `USER_SRP_AUTH`. Клиент вычисляет SRP доказательство; backend никогда не видит пароль. Возвращает ID + access + refresh tokens.
Источник↗
Федеративному пользователю (Google/Apple/Cognito UP) требуются временные учетные данные AWS для прямого вызова AWS API из мобильного приложения.
→Cognito Identity Pool. Обменивает токен провайдера идентичности → роль IAM → временные учетные данные AWS через STS.
Почему: User Pools аутентифицируют пользователей; Identity Pools авторизуют их для ресурсов AWS.
Источник↗
Выбрать тип рабочего процесса Step Functions.
→Standard: длительный (≤1 год), ровно один раз, $0.025/1k переходов, полная история. Express: ≤5 мин, хотя бы один раз или не более одного раза, оплата за запрос + длительность; для высокопроизводительных ETL/streaming.
Источник↗
Шаг рабочего процесса завершается сбоем; требуется повторная попытка с экспоненциальной задержкой и маршрутизация в состояние восстановления.
→Массив `Retry` (на состояние, с `BackoffRate` + `MaxAttempts`) и `Catch` для маршрутизации при окончательном сбое. Сопоставление по `ErrorEquals` (например, `States.TaskFailed`, пользовательские имена ошибок).
Источник↗
Применить тот же рабочий процесс к каждому элементу в массиве, с ограничением параллелизма.
→Состояние Map с `ItemsPath` и `MaxConcurrency`. Распределенная Map обрабатывает 10k+ элементов с входными данными, поддерживаемыми S3.
Источник↗
Запускать Lambda по расписанию cron или по соответствующим входящим событиям.
→Правило EventBridge. Расписание: `rate(...)` или `cron(...)`. Шаблон: JSON-фильтр событий; сопоставление по источнику, типу детали, полям детали.
Источник↗
Маршрутизация событий из SQS / Kinesis / DynamoDB Streams / MSK к цели с опциональным фильтром + преобразованием.
→EventBridge Pipes. Source → Filter → Enrichment (Lambda/Step Functions) → Target. Lambda не требуется для простых случаев.
Источник↗
Обработка сообщений строго по порядку для каждого клиента, с дедупликацией.
→Очередь SQS FIFO. `MessageGroupId` разделяет порядок (параллелизм на группу); `MessageDeduplicationId` (или дедупликация на основе содержимого) отбрасывает дубликаты в течение 5 минут.
Источник↗
Потребитель извлекает сообщение, но аварийно завершает работу до его удаления.
→Сообщение скрывается на VisibilityTimeout секунд, затем снова появляется для повторной доставки. Настройте на самое длительное ожидаемое время обработки + буфер.
Почему: Слишком короткое → дублирующая обработка. Слишком длинное → медленное восстановление при сбое. ChangeMessageVisibility продлевает время в пути, если это необходимо.
Источник↗
Одно событие должно достичь нескольких потребителей (Lambdas / SQS queues / HTTP endpoints).
→Тема SNS с несколькими подписчиками. Политики фильтров подписки маршрутизируют только соответствующие сообщения каждому подписчику.
Источник↗
Настройка пропускной способности Kinesis Data Streams для операций записи.
→Каждый шард = 1 МБ/с или 1000 записей/с на вход, 2 МБ/с на выход. Добавьте шарды (split) или используйте режим On-Demand для автомасштабирования.
Источник↗