TL;DR: Amazon Linux 2 osiąga End of Life 30 czerwca 2026 roku. Po tej dacie AWS przestaje wydawać łatki bezpieczeństwa, aktualizacje pakietów i świadczyć wsparcie techniczne. Jeśli Twoja migracja nie jest jeszcze w toku — okno na zaplanowane, spokojne przejście właśnie się domyka.
Spis treści
- Co to znaczy End of Life (EOL)?
- Amazon Linux 2 EOL — kluczowe daty i fakty
- Co konkretnie przestaje działać po 30 czerwca 2026?
- Kogo dotyczy EOL Amazon Linux 2?
- Ścieżki migracji — jakie masz opcje?
- Amazon Linux 2023 — naturalna ścieżka migracji AWS
- Red Hat Enterprise Linux (RHEL) na AWS
- Rocky Linux i AlmaLinux — alternatywy open-source
- Ubuntu i Debian na AWS
- Różnice techniczne: AL2 vs AL2023
- Jak zaplanować migrację krok po kroku?
- Pułapki migracji — czego unikać
- Co jeśli nie zdążysz przed deadline’m? Extended Support
- Wpływ EOL na konkretne usługi AWS
- FAQ — najczęściej zadawane pytania
1. Co to znaczy End of Life (EOL)?
End of Life (koniec życia produktu) to formalna data, po której producent oprogramowania zaprzestaje aktywnego wsparcia dla danej wersji. W praktyce EOL oznacza zatrzymanie:
- Aktualizacji bezpieczeństwa — nowe podatności (CVE) w systemie operacyjnym i pakietach nie są już łatane przez producenta
- Bugfixów — błędy w oprogramowaniu nie są naprawiane
- Wsparcia technicznego — zgłoszenia do supportu nie są obsługiwane dla tej wersji
- Nowych funkcjonalności — brak nowych pakietów i usprawnień
- Certyfikacji zgodności — system stopniowo wypada z wymagań compliance (PCI DSS, HIPAA, SOC 2, ISO 27001)
EOL to nie jest awaria — system nadal działa. Problem polega na tym, że przestaje być bezpieczny w przewidywalnym czasie, bo każda nowa podatność odkryta po tej dacie pozostaje niezałatana na zawsze, chyba że skorzystasz z zewnętrznego extended support lub zmigrujesz.
Różnica między EOL a EOS
Warto znać rozróżnienie stosowane przez różnych producentów:
- End of Life (EOL) — całkowite zakończenie wszelkiego wsparcia
- End of Standard Support (EOS) — koniec wsparcia aktywnego; czasem następuje po nim faza „maintenance” z ograniczonymi aktualizacjami
- End of Extended Support — koniec opcjonalnego, płatnego przedłużenia wsparcia
W przypadku Amazon Linux 2 AWS używa terminu End of Life na oznaczenie daty 30 czerwca 2026 — po której nie będą wydawane żadne aktualizacje bezpieczeństwa ani bugfixy dla pakietów core.
2. Amazon Linux 2 EOL — kluczowe daty i fakty
Amazon Linux 2 osiągnie End of Life 30 czerwca 2026 roku. Od tej chwili nie będzie już otrzymywać aktualizacji ani wsparcia ze strony AWS.
Oś czasu
| Data | Zdarzenie |
|---|---|
| 2017 | Premiera Amazon Linux 2 |
| 2023 (pierwotnie) | Pierwotna data EOL — przesunięta przez AWS |
| Styczeń 2026 | AWS Batch zmienia domyślny AMI dla nowych środowisk ECS z AL2 na AL2023 |
| 30 czerwca 2026 | Oficjalne EOL Amazon Linux 2 — koniec aktualizacji bezpieczeństwa i bugfixów |
| 30 czerwca 2026 | ECS kończy publikowanie nowych AMI zoptymalizowanych dla AL2 |
| 30 czerwca 2026 | AWS Batch: nowe środowiska ECS z AMI AL2 zostają zablokowane |
| Czerwiec 2029 | Planowany EOL Amazon Linux 2023 |
AMI oznacza Amazon Machine Image. To jest gotowy obraz systemu operacyjnego i jego konfiguracji, z którego uruchamiasz instancję EC2 w AWS. Można go porównać do szablonu maszyny wirtualnej w Proxmoxie lub VMware.
Warto odnotować, że AWS już kilkakrotnie przesuwał datę końca wsparcia. Wszyscy wydają się wiedzieć, że muszą się przenieść, ale wiele organizacji nadal odkłada to na później, mając ważniejsze sprawy na głowie. Tym razem jednak termin jest ostateczny.
Dlaczego teraz jest naprawdę ostatni moment?
Migracja krytycznych workloadów biznesowych do wspieranego systemu operacyjnego wymaga realnego czasu. Legacy runtimes, wymagania compliance i ograniczone okna zmian wpływają na to, jak szybko możesz się przenieść.
3. Co konkretnie przestaje działać po 30 czerwca 2026?
Na poziomie systemu operacyjnego
Po tej dacie AWS nie będzie wydawać żadnych nowych aktualizacji pakietów ani łatek bezpieczeństwa dla pakietów core AL2. Systemy nadal działające na AL2 po 30 czerwca 2026 roku będą stopniowo akumulować niezałatane podatności.
Na poziomie usług AWS
Amazon ECS: Po tej dacie wersja agenta Amazon ECS jest zamrożona i nowe AMI zoptymalizowane dla ECS z Amazon Linux 2 są publikowane tylko wtedy, gdy zaktualizuje się źródłowe AMI Amazon Linux 2. Pełne End of Life następuje 30 czerwca 2026, po czym nie będą już publikowane żadne AMI ECS-optimized dla Amazon Linux 2.
Amazon EKS: Amazon EKS Kubernetes version 1.32 była ostatnią wersją obsługującą AMI AL2. Aby zachować zgodność z najnowszymi wersjami Kubernetes, AWS zaleca migrację do AL2023 lub Bottlerocket, które domyślnie włączają cgroupv2.
AWS Batch: Począwszy od stycznia 2026 roku, AWS Batch zmienił domyślny AMI dla nowych środowisk Amazon ECS compute z Amazon Linux 2 na Amazon Linux 2023.
AWS Neuron (ML/AI): Niektóre runtimes, np. AWS Neuron, nie obsługują już AL2 w nowszych wersjach, wymuszając użycie AL2023 lub innego systemu.
Na poziomie bezpieczeństwa i compliance
Systemy z niezałatanymi podatnościami naruszają wymagania większości standardów bezpieczeństwa. PCI DSS, HIPAA, SOC 2 i ISO 27001 wymagają regularnego stosowania poprawek bezpieczeństwa. Organizacje regulowane mogą stanąć przed problemem nieprzejścia audytów przy utrzymywaniu infrastruktury opartej na systemie bez aktywnego wsparcia.
4. Kogo dotyczy EOL Amazon Linux 2?
Dla wielu firm Amazon Linux 2 nie jest kwestią peryferyjną, lecz częścią produkcyjnych środowisk AWS. Dystrybucja była zoptymalizowana do użytku na Amazon EC2, ściśle zintegrowana z usługami AWS i przez lata stosowana jako oczywista baza dla wirtualnych maszyn, kontenerów i wewnętrznych platform. To właśnie to powszechne użycie sprawia, że koniec wsparcia jest tak uciążliwy. To, co na papierze wygląda jak normalna data cyklu życia, może w praktyce jednocześnie dotknąć AMI, automatyzację, procesy bezpieczeństwa, wymagania compliance i środowiska aplikacji.
Konkretne środowiska, których dotyczy EOL:
- Instancje EC2 uruchomione na AMI Amazon Linux 2
- Kontenery Docker oparte na obrazach
amazonlinux:2 - Klastry ECS używające AMI zoptymalizowanych dla AL2
- Klastry EKS (do Kubernetes 1.32 włącznie)
- Środowiska AWS Batch oparte na AL2 AMI
- Elastic Beanstalk z platformami opartymi na AL2
- Lambda z custom runtimes na AL2
- CodeBuild z obrazami build środowisk AL2
- AWS AppStream 2.0 z flotami AL2
5. Ścieżki migracji — jakie masz opcje?
Organizacje stojące przed EOL Amazon Linux 2 mają kilka ścieżek. Wybór zależy od struktury infrastruktury, wymagań compliance, budżetu i horyzontów czasowych.
Opcja A: Amazon Linux 2023 (AL2023) — rekomendacja AWS
Naturalna ścieżka dla organizacji działających wyłącznie na AWS. AL2023 to oficjalny następca AL2, wciąż rozwijany przez AWS.
Opcja B: Red Hat Enterprise Linux (RHEL) — standaryzacja platformy
Opcja dla organizacji szukających spójnej bazy Linux działającej jednocześnie w AWS, on-premise i innych chmurach.
Opcja C: Rocky Linux lub AlmaLinux — open-source alternatywa RHEL-compatible
Bezpłatne dystrybucje kompatybilne binarnie z RHEL, dobre dla organizacji z ograniczonym budżetem na licencje.
Opcja D: Ubuntu Server LTS — szeroki ekosystem
Dobrze wspierana alternatywa z długim LTS i szeroką bazą pakietów.
Opcja E: Extended Support (tymczasowe rozwiązanie)
Zewnętrzne wsparcie bezpieczeństwa (np. TuxCare) dla organizacji, które nie zdążą zmigrować przed deadline’m.
6. Amazon Linux 2023 — naturalna ścieżka migracji AWS
Amazon Linux 2 osiąga End of Life 30 czerwca 2026. Większość zespołów korzystających z AL2 będzie patrzeć na AL2023 jako naturalnego następcę i dla niektórych workloadów jest to właściwy wybór. Kolejna właściwa platforma zależy jednak od tego, dlaczego w pierwszej kolejności byłeś na AL2, i warto zbadać tę kwestię przed zobowiązaniem się do jakiejkolwiek ścieżki.
Co to jest Amazon Linux 2023?
AWS ogłosił Amazon Linux 2023 jako następcę Amazon Linux 2. Używa on Fedory jako upstreamu i osiągnął GA (General Availability) w marcu 2023 roku. Każde wydanie główne jest wspierane przez Standard Support przez 2 lata, po czym następuje faza maintenance przez 3 lata.
AL2023 jest wspierany do czerwca 2029 roku.
Kluczowe różnice techniczne: AL2 vs AL2023
Package Manager: Amazon Linux 2 używa yum, podczas gdy Amazon Linux 2023 używa DNF. DNF oferuje lepsze rozwiązywanie zależności i szybszą instalację pakietów.
| Aspekt | Amazon Linux 2 | Amazon Linux 2023 |
|---|---|---|
| Upstream | Red Hat Enterprise Linux (RHEL) | Fedora |
| Package manager | yum | DNF |
| Kernel | 4.14 / 5.10 | 6.1 / 6.12 |
| SELinux | Opcjonalny | Domyślnie permissive mode |
| IMDSv2 | Opcjonalny | Domyślnie wymagany |
| 32-bit apps | Obsługiwane | Brak wsparcia |
| EPEL | Kompatybilny | Niekompatybilny |
| amazon-linux-extras | Dostępne | Usunięte |
| EOL | 30 czerwca 2026 | Czerwiec 2029 |
| Boot mode | Legacy BIOS | UEFI |
Uwaga: migracja do AL2023 to nie jest „zamiana AMI”
Przejście nie jest kosmetyczną aktualizacją pakietów, lecz przejściem platformy. Ktokolwiek dostosował skrypty, obrazy bazowe, procesy CI/CD lub wyjątki bezpieczeństwa do Amazon Linux 2 przez lata, nie powinien oczekiwać, że wymiana nazwy AMI wykona całą pracę.
Szczególnie ważne punkty:
Amazon Linux 2023 usuwa mechanizm amazon-linux-extras, na którym wiele zespołów polegało. Usuwa też kompatybilność z EPEL, eliminuje obsługę aplikacji 32-bitowych i przechodzi z kernela 5.10 na kernel 6.1. Te różnice mogą wpływać na dostępność pakietów i wymagać dostosowania konfiguracji.
Zalety AL2023
Amazon Linux 2023 zapewnia podejście bezpieczne-domyślnie z wstępnie skonfigurowanymi politykami bezpieczeństwa, SELinux w trybie permissive, IMDSv2-only mode włączonym domyślnie, zoptymalizowanymi czasami boot i ulepszone zarządzanie pakietami dla lepszego bezpieczeństwa i wydajności.
7. Red Hat Enterprise Linux (RHEL) na AWS
RHEL to opcja dla organizacji, które chcą ujednolicić infrastrukturę Linux ponad granicami chmur.
Argument za RHEL: spójność operacyjna
Dla wielu organizacji standaryzacja na RHEL jest odpowiedzią na pytanie o ujednolicenie platformy. Wartość nie leży w żadnej pojedynczej funkcji — lecz w spójności na całej powierzchni operacyjnej. RHEL daje Twoim zespołom to samo środowisko w AWS, Azure, Google Cloud, serwerach on-premise i deploymentach edge, co przekłada się na: jeden zestaw umiejętności i procesów operacyjnych niezależnie od miejsca uruchomienia workloadu; jeden model patchowania i cyklu życia, którego zespół uczy się raz i stosuje wszędzie; mniej niespodzianek gdy workloady przemieszczają się między środowiskami; wspólną podstawę, która sprawia, że troubleshooting między środowiskami jest szybszy i bardziej przewidywalny.
Cykl życia RHEL
10-letni cykl życia RHEL, z opcjonalnym extended support, daje zespołom infrastrukturalnym przewidywalne horyzonty planowania. Aktualne oferty RHEL 9 i RHEL 10 zapewniają wsparcie odpowiednio do 2032 i 2035 roku. Kompatybilność ABI (Application Binary Interface) między głównymi wersjami sprawia, że przyszłe modernizacje/aktualizacje są mniej destrukcyjne.
RHEL na AWS — integracja z platformą
Obrazy Red Hat Enterprise Linux dla AWS są wspólnie projektowane i walidowane z AWS. Rezultatem jest system operacyjny, który wydaje się natywny dla platformy: ustawienia wydajnościowe dostrojone dla najpopularniejszych instancji EC2; wstępnie zintegrowane narzędzia AWS, w tym AWS CLI i CloudWatch; domyślny tryb boot UEFI; pełne wsparcie dla image mode, umożliwiające zarządzanie systemem przez te same przepływy kontenerowe co aplikacje.
Bezpieczeństwo i compliance z RHEL
RHEL zapewnia zaufany, security-focused łańcuch dostaw oprogramowania domyślnie. Wymagania compliance, w tym FIPS 140-3 i Common Criteria, są obsługiwane out of the box, co upraszcza pracę audytową i certyfikacyjną dla regulowanych branż. Łatki bezpieczeństwa są dostarczane według przewidywalnych harmonogramów z jasną komunikacją.
Ponadto RHEL zawiera dziś wsparcie dla post-quantum cryptography (PQC), co jest istotne wobec finalizacji standardów NIST w 2024 roku i coraz powszechniejszych wymagań quantum-safe w regulowanych branżach.
Dla kogo RHEL?
RHEL jest szczególnie wartościowy dla:
- Organizacji z hybrydową infrastrukturą (AWS + on-premise + inne chmury)
- Branż regulowanych (finanse, healthcare, sektor publiczny)
- Firm wymagających formalnego wsparcia enterprise z SLA
- Środowisk z rygorystycznymi wymaganiami compliance (FIPS, Common Criteria)
8. Rocky Linux i AlmaLinux — alternatywy open-source
Obie dystrybucje są binarnymi kompatybilnymi alternatywami RHEL, tworzonymi przez społeczność i dostępnymi bezpłatnie.
Rocky Linux
Rocky Linux 9 jest wspierany do maja 2032 roku. Dystrybucja jest prowadzona przez CIQ (firmę założoną przez twórcę CentOS) i cieszy się dużym zaufaniem społeczności enterprise Linux. Dostępna na AWS Marketplace.
AlmaLinux
AlmaLinux to kolejna dystrybucja RHEL-compatible z długoterminowym wsparciem. Wspierana przez CloudLinux, dostępna bezpłatnie z opcjonalnym płatnym wsparciem.
Kiedy wybrać Rocky/AlmaLinux zamiast RHEL?
- Gdy budżet nie pozwala na subskrypcje RHEL
- Gdy nie potrzebujesz formalnego enterprise support z SLA
- Gdy wystarczy binary compatibility z RHEL (te same pakiety RPM)
- Gdy chcesz mieć opcję migracji do RHEL w przyszłości bez przebudowy infrastruktury
9. Ubuntu i Debian na AWS
Ubuntu Server LTS (Long Term Support) to popularna alternatywa, zwłaszcza wśród deweloperów i startupów.
- Ubuntu 22.04 LTS — wsparcie do 2027 (standard) / 2032 (ESM)
- Ubuntu 24.04 LTS — wsparcie do 2029 (standard) / 2034 (ESM)
Ubuntu oferuje szeroką bazę pakietów (apt/dpkg), silną obecność w kontenerach i dobre wsparcie na AWS. Minusem jest inna filozofia zarządzania pakietami niż w AL2 (RPM → DEB), co wymaga dostosowania skryptów i automatyzacji.
10. Różnice techniczne: AL2 vs AL2023 — szczegółowy przegląd
Package management
AL2 używał yum (bazującego na Python 2). AL2023 przechodzi na dnf — nowocześniejszy menedżer pakietów z lepszym rozwiązywaniem zależności, modularną obsługą pakietów i trybem versionlock.
Ważna zmiana: AL2023 stosuje locked repositories — AMI są „zablokowane” na konkretnej wersji repozytorium, co chroni przed niezamierzonymi aktualizacjami łamiącymi zmiany. To inne podejście niż w AL2, gdzie yum update zawsze pobierał najnowsze wersje.
Kernel
Obrazy AMI Amazon Linux 2 bazują na kernelach Linux 4.14 i 5.10, podczas gdy Amazon Linux 2023 używa kernela Linux 6.1 i 6.12.
Kernel 6.x przynosi między innymi pełną obsługę cgroupv2, co jest wymagane przez nowsze wersje Kubernetes.
Bezpieczeństwo
AL2023 wprowadza kilka istotnych domyślnych zmian bezpieczeństwa:
- SELinux w trybie permissive domyślnie (w AL2 był wyłączony lub enforce opcjonalnie)
- IMDSv2 wymagane domyślnie — zapobiega atakom SSRF na metadata endpoint
- FIPS 140-3 dostępny out of the box
- Brak obsługi starszych algorytmów kryptograficznych (MD5, SHA-1 w wielu kontekstach)
Usunięte funkcje
amazon-linux-extras— popularne źródło nowszych wersji PHP, Python, MariaDB w AL2- Obsługa aplikacji 32-bitowych
- Kompatybilność z EPEL (Extra Packages for Enterprise Linux)
- Starsze protokoły TLS (TLS 1.0, 1.1)
11. Jak zaplanować migrację krok po kroku?
Krok 1: Zbierz niezbędne informacje
Zanim cokolwiek zmienisz, musisz wiedzieć, co migrujesz. Zbierz:
- Wszystkie instancje EC2 z AMI Amazon Linux 2 (AWS Systems Manager Inventory, AWS Config, lub tag-based discovery)
- Obrazy Docker bazujące na
amazonlinux:2 - Klastry ECS i EKS z węzłami AL2
- Pipeline’y CI/CD budujące na obrazach AL2 (CodeBuild, GitHub Actions, GitLab CI)
- Lambda functions z custom runtimes opartymi na AL2
- AMI w EC2 Image Builder zbudowane na AL2
Narzędzia pomocne w inwentaryzacji:
- AWS Systems Manager Inventory — automatyczna inwentaryzacja instancji EC2
- AWS Config — reguły do wykrywania instancji z określonymi AMI
- AWS Trusted Advisor — alerty dotyczące zbliżającego się EOL
- Lansweeper — zewnętrzne narzędzie z gotowymi raportami OS lifecycle
Krok 2: Kategoryzacja workloadów
Nie wszystkie aplikacje migrują tak samo. Podziel workloady na kategorie:
Prosta podmiana AMI (low risk):
- Stateless aplikacje webowe bez zależności od specyficznych pakietów AL2
- Kontenery, które i tak są izolowane od OS hosta
- Środowiska deweloperskie i testowe
Migracja wymagająca testów (medium risk):
- Aplikacje korzystające z
amazon-linux-extras - Serwisy używające specyficznych wersji pakietów dostępnych tylko w AL2
- Środowiska z niestandardową konfiguracją SELinux
- Skrypty inicjalizujące (user-data) z komendami yum
Migracja złożona (high risk):
- Aplikacje z zależnościami od bibliotek 32-bitowych
- Systemy korzystające z EPEL
- Legacy code Python 2 lub inne starsze runtimes
- Systemy z ograniczonymi oknami serwisowymi (critical production)
Krok 3: Wybór docelowej dystrybucji
Na podstawie kategoryzacji i wymagań (compliance, wielochmurowe środowisko, budżet) wybierz ścieżkę migracji:
- AL2023 → jeśli pozostajesz wyłącznie w AWS i chcesz minimalnego ryzyka
- RHEL → jeśli masz środowisko hybrydowe lub regulowane wymagania enterprise
- Rocky Linux / AlmaLinux → jeśli potrzebujesz RHEL-compatibility bez kosztów licencji
- Ubuntu LTS → jeśli Twój team ma doświadczenie z Debianem i nie używasz RPM-specyficznych rozwiązań
Krok 4: Budowanie nowych AMI i obrazów bazowych
Dla EC2: Nie ma miejsca na in-place upgrade z AL2 do AL2023 — konieczne jest zbudowanie nowych AMI. Użyj EC2 Image Builder lub Packer do automatyzacji.
Dla kontenerów: Zaktualizuj FROM w Dockerfile:
# Przed
FROM amazonlinux:2
# Po (AL2023)
FROM amazonlinux:2023
# Po (RHEL UBI)
FROM registry.access.redhat.com/ubi9/ubi
Weryfikacja pakietów: Przed budowaniem nowych obrazów sprawdź dostępność wszystkich zależności w docelowym repozytori. Szczególną uwagę zwróć na pakiety instalowane wcześniej przez amazon-linux-extras.
Krok 5: Dostosowanie automatyzacji i konfiguracji
Zaktualizuj:
- User-data scripts — zamień
yumnadnf, sprawdź dostępność pakietów - Ansible playbooks — moduł
yummożna zamienić nadnflub użyćpackage(abstraction) - Terraform/CDK — zaktualizuj odwołania do AMI ID i filtrów
- CI/CD pipelines — zaktualizuj obrazy build environment
- Monitoring i alerting — sprawdź kompatybilność agentów (CloudWatch Agent, Datadog, itp.)
Krok 6: Testowanie
Wdróż nowe środowisko staging i przeprowadź:
- Testy funkcjonalne aplikacji
- Testy wydajnościowe (porównanie z AL2 baseline)
- Testy bezpieczeństwa (zmiana SELinux i IMDSv2 może wpłynąć na zachowanie)
- Testy zgodności (aplikacje korzystające z metadanych EC2 mogą wymagać aktualizacji dla IMDSv2)
- Testy automatyzacji (czy skrypty inicjalizacyjne działają poprawnie?)
Krok 7: Migracja produkcji — podejście blue/green
Definicja: Blue‑green deployment w chmurze to po prostu strategia wdrożeń, w której istnieją dwie równoległe wersje tego samego środowiska: jedna obsługuje ruch użytkowników (np. blue), druga jest gotowa w odwodzie (np. green). Nową wersję aplikacji wdraża się na środowisko nieaktywne, testuje, a następnie przełącza ruch tak, aby użytkownicy zaczęli korzystać z nowej wersji. Poprzednia wersja pozostaje nienaruszona przez jakiś czas, co umożliwia szybki rollback.
Dla krytycznych środowisk produkcyjnych zalecanym podejściem jest blue/green deployment:
- Zbuduj nowy stos (green) z docelową dystrybucją
- Uruchom obie wersje równolegle
- Stopniowo przenoś ruch (np. 10% → 50% → 100%)
- Monitoruj przez zdefiniowany okres
- Wycofaj stary stos (blue) po potwierdzeniu stabilności
Krok 8: Walidacja i zamknięcie AL2
Po pomyślnej migracji:
- Potwierdź brak instancji EC2 z AMI AL2 w produkcji
- Potwierdź brak obrazów Docker
FROM amazonlinux:2w aktywnych pipeline’ach - Zaktualizuj dokumentację infrastruktury
- Zarchiwizuj stare AMI zgodnie z polityką retencji
12. Pułapki migracji — czego unikać
Pułapka 1: Zakładanie, że to „tylko zmiana AMI”
To najczęstszy błąd. Zmiana dystrybucji Linuxa to zmiana platformy — wpływa na zarządzanie pakietami, domyślne ustawienia bezpieczeństwa, dostępne wersje bibliotek i zachowanie systemu. Każda warstwa automatyzacji zbudowana na AL2 wymaga przeglądu.
Pułapka 2: Brak inwentaryzacji przed migracją
Organizacje często odkrywają zapomniane instancje AL2 podczas pośpiesznej migracji. Systematyczna inwentaryzacja przed startem projektu eliminuje niespodzianki.
Pułapka 3: Zignorowanie zmiany IMDSv2
AL2023 domyślnie wymaga IMDSv2 dla metadanych instancji EC2. Aplikacje i skrypty korzystające ze starego IMDSv1 endpoint (http://169.254.169.254/latest/meta-data/ bez tokenu) przestaną działać. Sprawdź każdą aplikację korzystającą z metadanych instancji.
Pułapka 4: Brak alternatywy dla amazon-linux-extras
W AL2 amazon-linux-extras install php8.1 lub amazon-linux-extras install mariadb10.5 było powszechnym sposobem instalacji nowszych wersji pakietów. W AL2023 ten mechanizm nie istnieje — sprawdź, jakie wersje pakietów są dostępne w standardowym repozytorium AL2023 i czy to wystarczy.
Pułapka 5: Zbyt krótki harmonogram
To, co na papierze wygląda jak normalna data cyklu życia, może w praktyce jednocześnie dotknąć AMI, automatyzację, procesy bezpieczeństwa, wymagania compliance i środowiska uruchomieniowe aplikacji. Realistycznie oceń czas potrzebny na każdy workload.
Pułapka 6: Migracja bez testów wydajnościowych
Kernel 6.x w AL2023 różni się od 5.10 w AL2. Dla workloadów wrażliwych na wydajność (bazy danych, high-throughput serwisy) przeprowadź benchmarki przed migracją produkcji.
13. Co jeśli nie zdążysz przed deadline’m? Extended Support
Jeśli Twój zespół nie może zakończyć migracji do Amazon Linux 2023 przed 30 czerwca 2026, nie musisz wybierać między pośpiesznym przejściem a „niezałatanymi systemami”. TuxCare’s Endless Lifecycle Support dla Amazon Linux 2 zapewnia kontynuację pokrycia bezpieczeństwa z łatkami krytycznych i wysokiej ważności CVE, definicjami OVAL gotowymi na compliance i opcjonalnym patchowaniem kernela bez restartu przez KernelCare. Pozwala to na stabilizację środowiska podczas migracji w harmonogramie, który faktycznie jest wykonalny.
Extended support to rozwiązanie tymczasowe — daje czas na przeprowadzenie migracji bez naruszania compliance, ale nie zastępuje migracji do wspieranej platformy.
Dostępne opcje Extended Support dla AL2:
- TuxCare Endless Lifecycle Support — łatki bezpieczeństwa (krytyczne i wysokiej ważności CVE), OVAL definitions, opcjonalny KernelCare
- OpenLogic — enterprise support dla end-of-life dystrybucji
- Własne wewnętrzne backporting — możliwe, ale kosztowne i wymagające specjalistycznej wiedzy
14. Wpływ EOL na konkretne usługi AWS
Amazon EKS
Kubernetes community przeniosło wsparcie dla cgroupv1 (używanego przez AL2) do trybu maintenance. Oznacza to, że nie będą dodawane nowe funkcje, a jedynie krytyczne poprawki bezpieczeństwa i główne błędy. Wszelkie funkcje Kubernetes opierające się na cgroupv2, takie jak MemoryQoS i ulepszona izolacja zasobów, nie są dostępne na AL2.
Rekomendacja dla EKS: migruj węzły do AL2023 lub Bottlerocket (specjalnie zoptymalizowanego dla kontenerów systemu od AWS).
Amazon ECS
Po dacie EOL wersja agenta Amazon ECS jest zamrożona. Nowe AMI ECS-optimized dla AL2 nie są już publikowane.
Dla istniejących klastrów ECS: aktualizuj grupy Auto Scaling do AMI opartych na AL2023.
AWS Elastic Beanstalk
Elastic Beanstalk platformy oparte na AL2 nie będą otrzymywać aktualizacji po EOL. AWS będzie publikować nowe wersje platform jedynie dla AL2023.
AWS Lambda
Lambda runtimes zarządzane przez AWS (Python, Node.js, Java, etc.) nie są bezpośrednio dotknięte — AWS zarządza OS pod spodem. Dotyczy to jedynie custom runtimes opartych na AL2.
AWS AppStream 2.0
Amazon AppStream 2.0 zakończyło wsparcie dla Amazon Linux 2 15 kwietnia 2026. Istniejącym użytkownikom AL2 na flotach Always-On i On-Demand zaleca się rozpoczęcie planowania migracji workloadów do RHEL 8 lub Rocky Linux 8.
15. FAQ — najczęściej zadawane pytania
Czy moje instancje EC2 z AL2 przestaną działać po 30 czerwca 2026?
Nie. Instancje będą nadal działać — EOL nie wyłącza systemów. Problem polega na tym, że przestają otrzymywać łatki bezpieczeństwa, co stopniowo zwiększa ryzyko bezpieczeństwa i może naruszać wymagania compliance.
Czy jest możliwy in-place upgrade z AL2 do AL2023?
Nie. AWS nie oferuje oficjalnego upgrade path między AL2 a AL2023. Migracja wymaga zbudowania nowych instancji/AMI i przeniesienia aplikacji. To istotna różnica w porównaniu np. z upgradami RHEL, gdzie in-place upgrade jest wspierany.
Jak długo AL2023 będzie wspierany?
Data końca wsparcia AL2023 to czerwiec 2029, co zostało potwierdzone w dokumentacji Amazon Linux 2023 FAQs.
Czy moje obrazy Docker z FROM amazonlinux:2 będą działać?
Obrazy Docker nadal będą uruchamialne, ale nie będą otrzymywać aktualizacji bezpieczeństwa dla warstwy OS. Dla produkcyjnych środowisk migracja do amazonlinux:2023 lub innego wspieranego obrazu bazowego jest zalecana.
Czy mogę korzystać z RHEL na AWS na tych samych zasadach co AL2?
Tak. Red Hat i AWS współpracują przy udostępnianiu RHEL przez AWS Marketplace i konsolę AWS, z elastycznymi opcjami zakupu, które mogą być dopasowane do istniejących zobowiązań wydatków AWS.
Co z Amazon Linux 1 (oryginalny Amazon Linux)?
Amazon Linux 1 osiągnął EOL wcześniej i od dawna nie jest wspierany. Jeśli jeszcze gdzieś go używasz — to pilniejszy priorytet niż AL2.
Czy AWS oferuje narzędzia pomocne przy migracji?
AWS udostępnia oficjalny migration guide z AL2 do AL2023, dokumentację porównawczą obu systemów, EC2 Image Builder do automatyzacji budowania nowych AMI oraz AWS Systems Manager do inwentaryzacji i zarządzania patchami.
Jak Kubernetes jest powiązany z EOL AL2?
Amazon EKS Kubernetes version 1.32 była ostatnią wersją obsługującą AMI AL2. Nowsze wersje Kubernetes wymagają AL2023 lub Bottlerocket ze względu na cgroupv2.
Podsumowanie — czego wymaga od Ciebie EOL Amazon Linux 2?
End of Life Amazon Linux 2 30 czerwca 2026 to twarda granica bez dalszych przesunięć. Jeśli Twoja migracja nie jest już w toku, okno na przemyślane przejście zamiast reaktywnego działania się zawęża.
Plan działania na teraz:
- Zinwentaryzuj wszystkie zasoby działające na AL2 (EC2, kontenery, ECS, EKS, Lambda custom runtimes, pipeline’y CI/CD)
- Oceń każdy workload pod kątem złożoności migracji i ryzyka
- Wybierz docelową platformę (AL2023, RHEL, Rocky Linux, Ubuntu LTS)
- Zbuduj nowe AMI i obrazy bazowe
- Przetestuj gruntownie przed migracją produkcji
- Zmigruj etapami, zaczynając od prostszych workloadów
- Jeśli potrzebujesz więcej czasu — rozważ Extended Support jako mostek
Termin EOL tworzy użyteczny organizacyjny impet. Generuje wyrównanie i uzasadnienie budżetowe dla pracy infrastrukturalnej, która w innym przypadku mogłaby konkurować z projektami o wyższej widoczności. Organizacje, które najsprawniej przechodzą przez te przejścia, to zazwyczaj te, które traktują deadline jako okazję do strategicznego działania, a nie jedynie do dotarcia do mety w pośpiechu.
Zasoby i linki
- AWS: Amazon Linux 2 FAQ — aws.amazon.com/amazon-linux-2/faqs/
- AWS: Migracja z AL2 do AL2023 — docs.aws.amazon.com/linux/al2023/ug/compare-al2-to-al2023.html
- Red Hat: RHEL dla AWS — redhat.com/en/products/trials/cloud-marketplace/aws-rhel
- Red Hat Blog: Planning your path from AL2 — redhat.com/en/blog/planning-your-path-forward-amazon-linux-2-why-consistency-ultimate-upgrade
- Rocky Linux — rockylinux.org
- AlmaLinux — almalinux.org
- TuxCare Endless Lifecycle Support — tuxcare.com/endless-lifecycle-support/amazon-linux-eol-support/
- endoflife.date: Amazon Linux — endoflife.date/amazon-linux
Artykuł powstał na podstawie oficjalnej dokumentacji AWS, bloga Red Hat i innych źródeł publicznych. Daty i szczegóły mogą ulec zmianie — zawsze weryfikuj aktualne informacje w oficjalnych dokumentach AWS.
