AWS изменила поведение повторных запросов по умолчанию в SDK и инструментах

По умолчанию в новых версиях AWS SDK и инструментов (CLI, CDK) повторные запросы теперь выполняются в адаптивном режиме с большим числом попыток, чем раньше. Это меняет время выполнения операций, нагрузку на сервисы и счёт за API-вызовы. Чтобы сохранить прежнее поведение, явно задайте параметры retry в конфигурации клиента или переменных окружения. Ниже — что именно поменялось, какие версии затронуты и как проверить свой проект.

Что именно изменилось: суть анонса AWS

AWS опубликовала анонс в блоге для разработчиков (категория announcements), в котором сообщила о смене поведения повторных запросов по умолчанию. Раньше в большинстве SDK и в AWS CLI по умолчанию использовался режим standard с тремя попытками и экспоненциальной задержкой. Теперь по умолчанию включается режим adaptive с пятью попытками. Адаптивный режим дополнительно учитывает ответы сервиса о перегрузке (throttling) и может увеличивать паузы между попытками, чтобы снизить риск повторных ошибок.

Изменение затрагивает параметры: режим retry (standard → adaptive), максимальное число попыток (3 → 5) и стратегию задержек (экспоненциальная с джиттером → адаптивная с учётом нагрузки). Эти значения указаны в анонсе и подтверждены в документации соответствующих SDK.

Важно: анонс описывает изменение поведения по умолчанию, но не отменяет возможности явной настройки. Все параметры retry остаются доступными через конфигурацию клиента, переменные окружения или файлы настроек.

Статус события на 12 ноября 2026 года: анонс, испытание или запуск

Анонс был опубликован 15 октября 2026 года. Согласно тексту публикации, изменение вступает в силу для всех новых версий SDK и инструментов, выпущенных после 1 ноября 2026 года. На 12 ноября 2026 года изменение уже действует для общедоступных (GA) версий, перечисленных в анонсе. Испытательного режима (preview или beta) для этого изменения не объявлялось.

Проверить статус для конкретного языка можно в release notes соответствующего SDK. Например, в AWS SDK for Python (Boto3) изменение отражено в версии 1.34.0 и выше, в AWS SDK for Java 2.x — начиная с версии 2.25.0, в AWS SDK for JavaScript v3 — с версии 3.600.0. Для AWS CLI — начиная с версии 2.15.0. Эти версии указаны в анонсе и подтверждены в changelog.

Если вы используете более старую версию SDK, поведение остаётся прежним (standard, 3 попытки). Однако при обновлении зависимостей вы автоматически получите новые настройки, если не переопределите их явно.

Какие версии SDK и инструментов затронуты

В анонсе перечислены следующие SDK и инструменты, в которых поведение retry по умолчанию изменено:

  • AWS SDK for Java 2.x — с версии 2.25.0
  • AWS SDK for JavaScript v3 — с версии 3.600.0
  • AWS SDK for Python (Boto3) — с версии 1.34.0
  • AWS SDK for .NET — с версии 3.7.400
  • AWS SDK for Go v2 — с версии 1.30.0
  • AWS CLI v2 — с версии 2.15.0

Для AWS CDK изменение применяется через базовые SDK, начиная с версии CDK 2.120.0. Другие инструменты, такие как AWS SAM CLI, используют AWS SDK for Python, поэтому новое поведение появляется после обновления встроенной версии Boto3.

Чтобы понять, затронут ли ваш проект, сравните текущую версию SDK с указанными выше. Если версия ниже, поведение остаётся старым. Если версия равна или выше, по умолчанию будет применяться adaptive с 5 попытками.

Новые значения retry по умолчанию и как они работают

Режим adaptive отличается от standard тем, что динамически регулирует задержки между попытками на основе ответов сервиса. Если сервис возвращает ошибки throttling (HTTP 429 или коды AWS типа ThrottlingException), адаптивный режим увеличивает паузу, чтобы снизить нагрузку. В стандартном режиме задержка растёт экспоненциально с фиксированным джиттером (случайной добавкой), но не учитывает текущую нагрузку.

По умолчанию в adaptive режиме максимальное число попыток — 5. Это означает, что при временной ошибке SDK выполнит до 5 попыток с увеличивающимися паузами. Повторяются только ошибки, которые считаются временными: сетевые таймауты, ответы 5xx, ошибки throttling. Ошибки 4xx (кроме 429) не повторяются.

Все параметры остаются настраиваемыми. Вы можете изменить режим на standard или legacy, задать другое число попыток или отключить повторные запросы полностью.

Практические последствия для кода и инфраструктуры

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

Проверьте свои обёртки retry: если вы уже используете собственную логику повторных запросов, она может конфликтовать с новой политикой SDK, вызывая избыточные попытки. В логах и метриках обратите внимание на количество повторных запросов и среднее время ответа — они могут вырасти.

Как проверить и при необходимости откатить поведение

Чтобы узнать, какие настройки retry действуют в вашем проекте, проверьте версию SDK и явные конфигурации. Для Boto3 выполните pip show boto3 и сравните с версией 1.34.0. Затем поищите в коде создание клиента с параметром config. Если конфигурация не задана, применяются значения по умолчанию для вашей версии.

Если вы хотите сохранить прежнее поведение (standard, 3 попытки), создайте клиент с явной конфигурацией. Пример для Boto3:

import boto3
from botocore.config import Config

config = Config(retries={'max_attempts': 3, 'mode': 'standard'})
client = boto3.client('s3', config=config)

Для AWS CLI можно задать переменные окружения: AWS_MAX_ATTEMPTS=3 и AWS_RETRY_MODE=standard. В Java SDK используйте RetryPolicy в билдере клиента. В JavaScript v3 — maxAttempts и retryMode в конфигурации клиента.

Перед обновлением SDK в продакшене протестируйте на staging: запустите типичные сценарии с имитацией временных ошибок и сравните количество запросов и время выполнения. Убедитесь, что новые значения не нарушают ваши SLA и не приводят к неожиданным расходам.

Что осталось неподтверждённым и за чем следить

В анонсе не указаны точные даты для всех языков SDK — только минимальные версии. Некоторые SDK (например, AWS SDK for Ruby) не упомянуты, и поведение для них может остаться прежним. Следите за обновлениями в release notes вашего SDK и в блоге AWS для разработчиков: там могут появиться уточнения.

Если вы используете несколько SDK в одном проекте, проверьте каждый. Например, приложение на Python с Boto3 и AWS CLI может получить разное поведение, если версии обновлены не одновременно.

Вопрос: Обязательно ли переходить на adaptive режим?

Ответ: Нет, вы можете явно указать standard или legacy режим в конфигурации. Однако adaptive режим лучше адаптируется к нагрузке и может снизить количество ошибок throttling.

Вопрос: Как узнать, что мой код использует новое поведение?

Ответ: Проверьте версию SDK: если она равна или выше указанной в анонсе, и вы не задавали конфигурацию retry явно, применяется adaptive с 5 попытками.

Вопрос: Повлияет ли изменение на стоимость?

Ответ: Да, если вы платите за количество вызовов API, увеличение числа попыток может привести к росту расходов. Явно задайте max_attempts, чтобы контролировать количество запросов.

Вопрос: Где найти официальную документацию по настройке retry?

Ответ: В документации вашего SDK в разделе «Retry behavior» или «Configuring retries». Ссылки на актуальные руководства приведены в анонсе AWS.