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.

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

Технічна анатомія

Різниця між часовими рамками RDS і Aurora — ось цікава інженерна історія. AWS пояснює це двома чинниками: підходом до розробки у спільнотах верхнього рівня та тим, що Aurora додає під рушій.

PostgreSQL і MariaDB розробляються відкрито. AWS може отримувати коміти, запускати валідацію і готувати внутрішні збірки задовго до GA спільноти. Коміти MySQL, за словами AWS, стають доступними ближче до публічного релізу, що стискає вікно попередньої GA-валідації. Саме це пояснює, чому мінорні версії RDS для PostgreSQL виходять за тиждень, тоді як мінорні версії RDS для MySQL отримують повний місяць.

Aurora — зовсім інша річ. Він замінює рушій сховища спільноти розподіленим шаром зберігання і додає можливості Global Database та serverless. Кожна нова версія рушія має бути повторно валідована на цьому субстраті. Всі шляхи — read-репліки, пересилання журналів, відновлення після збоїв і масштабування serverless — мають продовжувати працювати. Саме тому Aurora PostgreSQL потребує 3 місяці для мінору, який RDS випускає за 7 днів, і чому мажорні версії Aurora MySQL отримують 12 місяців проти 6 місяців у RDS MySQL.

Прив'язка до <major>.1 — ще один момент, що заслуговує на розуміння. Postgres 18.0 — не те, що з'являється на AWS першим. Першим виходить Postgres 18.1, приблизно через три місяці, після того як початкова порція виробничих помилок виявляється і виправляється. Якщо ви знайомі з примітками до релізів 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. Вікно 12 місяців на LTS-мажор у Aurora означає, що можна зафіксувати стабільний мінор і синхронізувати мажорні оновлення з власним релізним потоком, а не гнатися за каденцією спільноти. Це правильна позиція для високопропускної аналітики, де ротація рушія завдає більше болю, ніж відсутність нових функцій.

Магазини MariaDB, здебільшого колишні self-hosted користувачі, що переходять на RDS, отримують чисту угоду: 30-денні мінори, 3-місячні мажори від першого патча. Нема на що скаржитись.

Сценарій дій для інженерних команд

Зробіть це протягом наступних двох тижнів.

По-перше, порівняйте поточні версії рушіїв із опублікованими часовими рамками. Визначте кожну базу даних, що відстає більш ніж на одну мінорну версію, і розрахуйте, коли наступний реліз спільноти реально з'явиться на AWS. Внесіть ці дати в той самий календар, що і дорожня карта продукту. Якщо ваш флот Aurora PostgreSQL відстає більш ніж на дві мінорні версії — це проблема управління, а не технічна.

По-друге, увімкніть автоматичне оновлення мінорних версій для всього, що не є системою доходів Tier 0. Семиденне вікно RDS Postgres марне, якщо патчі залишаються незастосованими, бо ніхто не хоче брати на себе відповідальність за вікно обслуговування. Поєднайте це з політиками розгортання оновлень AWS Organizations, щоб dev і test середовища поглинали ризик перед production.

По-третє, прийміть Blue/Green Deployments як стандартний шлях для мажорних оновлень. Переключення з мінімальним простоєм — це різниця між оновленням у вівторок вдень і нічною кризою у вихідні. Поєднайте це з інструментацією OpenTelemetry на стороні застосунку, щоб порівняти затримку запитів між blue і green середовищами перед переключенням трафіку.

По-четверте, використовуйте RDS Database Preview для тестування мажорних версій. Отримання доступу до нового мажору PostgreSQL або MySQL у не-production середовищі до його 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 мажорної версії Aurora дають командам, що прагнуть стабільності, задокументовану багаторічну базу. Використовуйте її, якщо ротація рушія завдає більше болю, ніж відсутність нових функцій.
• Увімкніть автоматичні мінорні оновлення, прийміть Blue/Green для мажорів, використовуйте RDS Database Preview та Extended Support як тактичні інструменти, а не постійні рішення.