AWS публикует SLA по актуальности версий Aurora и RDS

Каждый, кто хотя бы раз пытался запланировать мажорное обновление Postgres на платёжной платформе, знает: настоящее узкое место — не команда pg_upgrade. Это календарь. Продуктовая команда ждёт новой функции, безопасники хотят закрыть CVE, а AWS никогда официально не сообщал, когда версия фактически появится в консоли. На этой неделе всё изменилось.

AWS опубликовал временны́е рамки актуальности версий для Aurora и RDS по PostgreSQL, MySQL и MariaDB. Впервые у технических лидов появились задокументированные окна, которые можно включить в роадмап без оговорок.

Что произошло

Как сообщает Amazon Web Services (AWS), компания публикует целевые окна для новых мажорных и минорных версий на перспективу. Цифры достаточно конкретны для планирования и достаточно различны, чтобы объяснить, почему обновления Aurora всегда ощущались медленнее, чем у RDS.

Начнём с RDS. Минорные версии RDS для PostgreSQL выходят в течение 7 дней после релиза сообщества. Минорные версии RDS для MySQL и MariaDB — в течение 30 дней. Мажорные версии RDS для PostgreSQL появляются в течение 30 дней после релиза <major>.1 от сообщества. Мажорные версии RDS для MariaDB выходят в течение 3 месяцев после первого патч-релиза сообщества. Мажорные версии RDS для MySQL — в течение 6 месяцев после <major>.1 сообщества, и только для Oracle MySQL LTS.

Aurora работает медленнее — намеренно. Минорные версии Aurora PostgreSQL выходят в течение 3 месяцев после релиза сообщества. Мажорные версии Aurora PostgreSQL — в течение 8 месяцев после <major>.1. Минорные версии Aurora MySQL — в течение 3 месяцев. Мажорные версии Aurora MySQL — в течение 12 месяцев после <major>.1. LTS-релизы Aurora на каждый мажор выходят в течение 12 месяцев после GA мажорной версии Aurora на обоих движках.

AWS также разъяснил точки отсчёта. Продакшн-релизы Postgres на AWS, как правило, основаны на <major>.1 сообщества, который обычно выходит примерно через три месяца после начального мажора. Сроки MariaDB отсчитываются от первого патч-релиза сообщества. Сроки MySQL применяются только к Oracle MySQL LTS, отсчёт ведётся от <major>.1.

Компания также напомнила о сопутствующем инструментарии: автоматические обновления минорных версий в maintenance-окнах, политики развёртывания обновлений через AWS Organizations, RDS Database Preview для раннего тестирования, Blue/Green Deployments для переключения и Amazon RDS Extended Support для нагрузок, вышедших за пределы поддержки сообщества.

Техническая составляющая

Разрыв между сроками RDS и Aurora — это и есть интересная инженерная история. AWS объясняет его двумя факторами: особенностями разработки в upstream-сообществах и тем, что Aurora добавляет под капотом движка.

PostgreSQL и MariaDB разрабатываются открыто. AWS может получать коммиты, запускать валидацию и собирать внутренние билды задолго до GA в сообществе. Коммиты MySQL, по словам AWS, становятся доступны ближе к публичному релизу, что сжимает окно предварительной валидации. Это одно объясняет, почему минорные версии RDS для PostgreSQL выходят за неделю, а минорные для MySQL — за полный месяц.

Aurora — совсем другая история. Он заменяет движок хранилища сообщества распределённым слоем хранения и добавляет Global Database и serverless-возможности. Каждую новую версию движка необходимо повторно валидировать на этом субстрате. Read-реплики, log shipping, восстановление после сбоев и пути масштабирования serverless — всё это должно продолжать работать. Именно поэтому минорная версия Aurora PostgreSQL выходит за 3 месяца, тогда как RDS справляется за 7 дней, а мажорные версии Aurora MySQL получают 12 месяцев против 6 у RDS MySQL.

Якорь <major>.1 — ещё один важный момент. Postgres 18.0 — не то, что первым появляется на AWS. Первым выходит Postgres 18.1, примерно через три месяца, когда первая волна продакшн-багов всплывёт и будет исправлена. Если вы знакомы с release notes Postgres, то знаете, что .1 обычно закрывает существенные граничные случаи. AWS кодифицирует операционное предпочтение, которого давно придерживаются опытные DBA: не запускать .0 ни на чём, что разбудит вас ночью.

Моя оценка: AWS признаёт, что его версионный каденс всегда был скрытым входным параметром для планирования мощностей, и наконец начинает обращаться с ним именно так. Публикация SLA полезнее, чем его сокращение.

Кто пострадает

Неудобный вывод: команды, стандартизировавшиеся на Aurora ради «полностью управляемого» подхода, теперь видят задокументированные задержки, которых у клиентов RDS нет. Если вы работаете на Aurora PostgreSQL и в минорной версии сообщества появился критический CVE, вы ждёте до 3 месяцев. Клиенты RDS для PostgreSQL ждут максимум 7 дней. Для безопасности-чувствительных нагрузок это не погрешность округления.

Платформы iGaming ощущают это острее всего. Регуляторы в ряде юрисдикций ЕС ожидают своевременного закрытия известных уязвимостей. Трёхмесячное окно для минорных версий Aurora означает, что вам нужна история о компенсирующих мерах, либо вы переносите патч-чувствительные нагрузки обратно на RDS. В моей практике инциденты, связанные с задержкой патчинга БД, чаще обнаруживают аудиторы, чем атакующие, — но случается и то, и другое.

Финтех-компании, использующие Aurora MySQL для учётных систем, получают самую жёсткую цифру: 12 месяцев на мажорную версию. Это полный годовой цикл планирования. Если Oracle MySQL LTS выпускает мажор с функцией, на которую вы рассчитывали в Q1, а вы работаете на Aurora MySQL, — почти наверняка вы не получите её в Q1. Команды, с которыми я работал, как правило, недооценивают эту задержку вдвое.

Ad-tech-компании, использующие Aurora ради serverless-масштабирования, должны обратить внимание на LTS. Двенадцатимесячное окно LTS на каждый мажор в Aurora позволяет зафиксировать стабильный минор и синхронизировать мажорные обновления с собственным release-треком, а не гнаться за каденсом сообщества. Это правильная позиция для высоконагруженной аналитики, где смена движка причиняет больше боли, чем отсутствие новых функций.

Магазины MariaDB, преимущественно мигрирующие с self-hosted на RDS, получают чистую сделку: 30 дней на минор, 3 месяца на мажор с первого патча. Жаловаться не на что.

Руководство для инженерных команд

Сделайте это в ближайшие две недели.

Первое: сопоставьте текущие версии движков с опубликованными временны́ми рамками. Определите каждую базу данных, отстающую более чем на один минорный релиз, и рассчитайте, когда следующий релиз сообщества реально появится на AWS. Внесите эти даты в тот же календарь, что и продуктовый роадмап. Если ваш флот Aurora PostgreSQL отстаёт более чем на два минорных релиза — это проблема управления, а не техническая.

Второе: включите автоматическое обновление минорных версий для всего, что не является системой уровня Tier 0. Семидневное окно RDS Postgres бесполезно, если патчи лежат неприменёнными, потому что никто не хочет брать ответственность за maintenance-окно. Дополните это политиками развёртывания обновлений AWS Organizations, чтобы dev и test принимали риск до продакшна.

Третье: сделайте Blue/Green Deployments стандартным путём для мажорных обновлений. Переключение с минимальным даунтаймом — это разница между обновлением во вторник днём и ночным военным советом в выходные. Дополните это инструментацией OpenTelemetry на стороне приложения, чтобы сравнивать задержку запросов между blue и green перед переключением трафика.

Четвёртое: используйте RDS Database Preview для тестирования мажорных версий. Возможность поработать с новым мажором PostgreSQL или MySQL в непродакшн-среде до GA на Aurora даёт команде разработки месяцы на выявление критических изменений в планировщиках запросов, совместимости расширений и поведении драйверов.

Пятое: если вы приближаетесь к окончанию поддержки сообщества, используйте Amazon RDS Extended Support для выигрыша времени. Не делайте из него постоянное место жительства. Относитесь к нему как к взлётно-посадочной полосе, чтобы завершить уже запланированное обновление.

Ключевые выводы

• Минорные версии RDS для PostgreSQL выходят в течение 7 дней после релиза сообщества. Минорные версии Aurora PostgreSQL занимают до 3 месяцев. Планируйте патчинг безопасности с учётом более медленного срока.
• Мажорные версии Aurora отстают от RDS намеренно — из-за распределённого хранилища, Global Database и serverless-слоёв, требующих повторной валидации при каждом релизе.
• Сроки для Postgres и MariaDB отсчитываются от первого патч-релиза, а не от .0. AWS закрепляет инстинкт «никогда не запускать dot-zero» как политику.
• LTS-релизы Aurora в течение 12 месяцев после GA мажорной версии дают командам, ориентированным на стабильность, задокументированный многолетний базис. Используйте это, если смена движка причиняет больше боли, чем отсутствие новых функций.
• Включите автоматические обновления минорных версий, перейдите на Blue/Green для мажоров, используйте RDS Database Preview и Extended Support как тактические инструменты, а не постоянные решения.