Od sierpnia RDS dolicza opłatę za MySQL 8.0

Standardowe wsparcie MySQL 8.0 na RDS skończyło się 31 lipca 2026. Od 1 sierpnia AWS dolicza opłatę za Extended Support do każdej takiej bazy, która ma to ustawienie włączone. API, CLI i Terraform włączają je domyślnie, a w konsoli trzeba je zaznaczyć. Na rachunkach za sierpień i wrzesień ta pozycja już jest.

Jeśli masz bazę MySQL 8.0, przenieś ją na 8.4, która ma standardowe wsparcie do 31 lipca 2029. Aurora MySQL 3, zgodna z 8.0, ma standardowe wsparcie do 30 kwietnia 2028, więc za nią na razie nie dopłacasz.

Ile kosztuje Extended Support

We Frankfurcie cennik AWS na dzień 6 października 2026 podaje 0,122 USD za vCPU na godzinę przez pierwsze dwa lata, czyli około 89 USD miesięcznie za każdy vCPU. Od 1 sierpnia 2028 stawka rośnie do 0,244 USD. Baza Multi-AZ ma zapasową kopię w drugiej strefie, a AWS liczy opłatę także za tę kopię, więc płacisz dwa razy tyle.

Weźmy bazę db.m6g.large w Multi-AZ, z 2 vCPU. Sama instancja kosztuje we Frankfurcie około 264 USD miesięcznie, a Extended Support dokłada do tego 356 USD. Za sierpień i wrzesień AWS doliczył już do takiej bazy około 714 USD.

Rezerwacja instancji tej dopłaty nie obniży, bo rabaty Reserved Instances nie obejmują Extended Support.

Gdzie to widać na rachunku

Extended Support jest osobną pozycją na rachunku, obok godzin instancji i dysku. W Cost Explorer wpisz w filtrze Usage Type słowo ExtendedSupport i zaznacz wszystkie wyniki. Dla MySQL 8.0 we Frankfurcie typ użycia to EUC1-ExtendedSupport:Yr1-Yr2:MySQL8.0.

Ten filtr pokaże też bazy na starszych wersjach. Za MySQL 5.7 AWS liczy stawkę trzeciego roku od 1 marca 2026. Eksport z Cost Explorer pogrupowany po typie użycia możesz też wczytać do analizy CSV, która wypisze największe pozycje rachunku.

Za które bazy płacisz, sprawdzisz tym poleceniem, osobno w każdym regionie:

aws rds describe-db-instances --region eu-central-1 \
  --query "DBInstances[?Engine=='mysql'].[
    DBInstanceIdentifier,
    EngineVersion, MultiAZ,
    EngineLifecycleSupport]" \
  --output table

Każdy wiersz z wersją 8.0.x i wartością open-source-rds-extended-support w ostatniej kolumnie to baza, za którą płacisz Extended Support.

Wyłączenie opłaty oznacza upgrade

Ustawienie EngineLifecycleSupport można zmienić w każdej chwili. Jeśli jednak wyłączysz Extended Support w bazie 8.0, RDS sam podniesie ją do następnej wspieranej wersji, czyli do 8.4, niezależnie od tego, czy sprawdziłeś na niej aplikację. Opłata kończy się, gdy baza przejdzie na wspieraną wersję. Ten sam mechanizm opisałem przy PostgreSQL 14, gdzie termin dopiero nadchodzi.

Jak przejść na 8.4

Celem jest 8.4, bo nowsze wersje MySQL są na RDS tylko w Database Preview, którego AWS nie pozwala używać na produkcji.

AWS zaleca blue/green deployment. RDS stawia wtedy kopię bazy i replikuje do niej zmiany z produkcji, a Ty podnosisz kopię do 8.4 i testujesz na niej aplikację. Kopia jest tylko do odczytu i niech tak zostanie, bo zapisy na niej psują replikację i mogą trafić na produkcję po przełączeniu. Testy z zapisem rób na bazie odtworzonej ze snapshotu.

Samo przełączenie trwa zwykle poniżej minuty. Stara baza zostaje potem pod nazwą …-old1, nadal na 8.0, i AWS liczy za nią instancję oraz Extended Support. Usuń ją, gdy nie będziesz już potrzebować drogi powrotu.

Upgrade w miejscu trwa około 10 minut, a baza jest w tym czasie niedostępna. Dokumentacja nie opisuje powrotu do 8.0 po udanym upgradzie.

Na kopii przeczytaj PrePatchCompatibility.log. RDS sprawdza zgodność przed upgradem i jeśli coś znajdzie, przerywa go, zanim zatrzyma bazę. Potem sprawdź zmiany, które AWS wymienia w ogłoszeniu MySQL 8.4 na RDS:

• Nowe konta dostają w 8.4 domyślnie plugin caching_sha2_password, a istniejące zostają przy mysql_native_password. Sprawdź, czy aplikacja połączy się kontem założonym po upgradzie.
• Parametr restrict_fk_on_non_standard_key jest domyślnie włączony i nie pozwala tworzyć kluczy obcych opartych na nieunikalnych albo częściowych kluczach. Sprawdź, czy migracje schematu takich nie zakładają.
• Stare polecenia replikacji kończą się w 8.4 błędem składni, więc w skryptach i monitoringu zamień SHOW MASTER STATUS na SHOW BINARY LOG STATUS.
• Porównaj czas najcięższych zapytań, bo 8.4 zmienia domyślne parametry InnoDB.

Kiedy się tym zająć

Najlepiej jeszcze w październiku 2026. Na przykładowej db.m6g.large każdy miesiąc zwłoki kosztuje około 356 USD. Jeśli na koncie jest kilka baz 8.0, zacznij od tej, która ma najwięcej vCPU, licząc kopię Multi-AZ, bo opłata rośnie razem z nimi.

Bazę na Aurorze MySQL 3 przenieś w 2027 roku na Aurorę MySQL 8.4, przed terminem 30 kwietnia 2028.