Migracja na AWS krok po kroku — praktyczny przewodnik dla firm, które nigdy tego nie robiły
Pracujesz na VPS-ie u polskiego dostawcy. Albo na serwerze dedykowanym, który ktoś kiedyś postawił i od tamtej pory nikt nie wie, co dokładnie na nim chodzi. Albo na współdzielonym hostingu, który zaczyna się dusić. I ktoś — szef, CTO, kolega z branży — powiedział, że trzeba przejść na AWS.
Ten artykuł jest dla Ciebie. Nie dla kogoś, kto zarządza flotą 200 instancji. Dla firmy, która ma jedną aplikację, jedną bazę danych, może jakiś serwer mailowy, i chce to przenieść na AWS bez rewolucji, bez miesięcznego przestoju i bez rachunku, którego nikt się nie spodziewał.
Zanim cokolwiek przeniesiesz: inwentaryzacja
Największy błąd, jaki widzimy przy migracjach, to rzucanie się do przenoszenia bez zrozumienia, co właściwie masz. Brzmi banalnie, ale w praktyce zaskakująco dużo firm nie wie dokładnie, co działa na ich serwerze.
Zanim dotkniesz konsoli AWS, odpowiedz sobie na kilka pytań:
Co chodzi na serwerze? Nie chodzi o „strona i baza". Chodzi o konkretny stos: jaki serwer HTTP (nginx, Apache), jaka wersja PHP/Node/Pythona, jaki silnik bazy (MySQL 5.7? PostgreSQL 14? MariaDB?), jakie dodatkowe serwisy (Redis, Elasticsearch, Memcached), czy są jakieś crony, skrypty, procesy w tle.
Ile danych masz? Nie „mało" albo „dużo". Konkretnie: ile waży baza danych (dump), ile ważą pliki (uploady użytkowników, assety), ile zajmuje kod. Te liczby determinują czas migracji i koszty transferu.
Jaki ruch obsługujesz? Średni i szczytowy. Ile requestów/sekundę w normalnym dniu, ile w szczycie (Black Friday, kampania reklamowa). To decyduje o doborze instancji.
Jakie masz domeny i DNS? Kto zarządza DNS-em — rejestracja domeny to jedno, ale gdzie wskazują rekordy A/CNAME? Jaki TTL mają rekordy? To wpłynie na strategię przełączania.
Czy masz backupy? I czy kiedykolwiek próbowałeś z nich odtworzyć działający system? Migracja to dobry moment, żeby się o tym przekonać.
Spisz to wszystko. Nie w głowie — na papierze, w arkuszu, gdziekolwiek. Ten dokument to Twoja mapa migracji.
Strategia: lift-and-shift czy redesign?
Są dwa podejścia do migracji i musisz świadomie wybrać jedno z nich.
Lift-and-shift — bierzesz to, co masz, i przenosisz na AWS z minimalnymi zmianami. Twój VPS staje się instancją EC2. Twoja baza danych ląduje na RDS albo na tym samym EC2. Pliki jadą na EBS. Architektura się nie zmienia, zmienia się tylko miejsce, w którym działa.
Zalety: szybko, przewidywalnie, mało co może pójść nie tak pod kątem aplikacji. Wady: nie korzystasz z tego, co AWS oferuje — skalowalność, zarządzane usługi, optymalizacja kosztów. Płacisz za EC2 chodzące 24/7, tak samo jak płaciłeś za VPS.
Redesign — przebudowujesz architekturę pod usługi AWS. Baza danych idzie na zarządzany RDS. Pliki statyczne na S3 + CloudFront. Może część logiki przechodzi na Lambda. Monitoring na CloudWatch.
Zalety: niższe koszty w dłuższym terminie, lepsza skalowalność, mniej utrzymania. Wady: więcej pracy, wymaga wiedzy o AWS, dłuższy czas migracji, ryzyko nowych bugów.
Nasza rekomendacja: Zacznij od lift-and-shift. Przejdź na AWS, ustabilizuj się, przekonaj się, że wszystko działa. Potem — w swoim tempie — optymalizuj. Nie próbuj robić obu rzeczy naraz. Migracja to wystarczająco dużo stresu bez jednoczesnej przebudowy architektury.
Krok 1: Konto AWS i podstawowa konfiguracja
Załóż konto AWS. Kilka rzeczy, które warto zrobić od razu, zanim zaczniesz stawiać serwery:
Włącz MFA na koncie root. To pierwsze, co robisz. Konto root bez MFA to otwarte drzwi. Fizyczny klucz U2F jest najlepszy, ale aplikacja TOTP (Google Authenticator, Authy) też wystarczy.
Utwórz osobnego użytkownika IAM do codziennej pracy. Nie loguj się na root do administracji. Root jest od ustawień rozliczeniowych i sytuacji awaryjnych.
Ustaw Billing Alarm. W CloudWatch ustaw alarm, który wyśle Ci maila, kiedy miesięczny rachunek przekroczy próg — np. $50, $100, cokolwiek uważasz za „muszę to sprawdzić". To ratuje przed niespodziankami.
Wybierz region: Frankfurt (eu-central-1). Dla polskiej firmy to domyślny wybór. Najbliższy pełny region, RODO-zgodny, najszersza oferta usług w Europie. O Warsaw Local Zone pisaliśmy osobno — dla większości firm Frankfurt jest właściwym miejscem.
Krok 2: Sieć (VPC)
AWS tworzy domyślne VPC w każdym regionie, ale dla produkcyjnych workloadów lepiej postawić własne. Nie dlatego, że domyślne jest złe, ale dlatego, że własne daje Ci pełną kontrolę nad adresacją i separacją.
Praktyczny setup dla typowej aplikacji:
Utwórz VPC z blokiem CIDR, np. 10.0.0.0/16. To daje 65 tysięcy adresów — więcej niż kiedykolwiek będziesz potrzebować. Utwórz dwa subnety publiczne (po jednym w każdej strefie dostępności, np. eu-central-1a i eu-central-1b) i dwa prywatne. Subnety publiczne — dla load balancerów i rzeczy, które muszą być widoczne z internetu. Subnety prywatne — dla instancji EC2 i baz danych.
Dodaj Internet Gateway i podepnij go do publicznych subnetów. Jeśli Twoje instancje w prywatnych subnetach potrzebują dostępu do internetu (np. do pobierania aktualizacji), potrzebujesz NAT Gateway — ale uwaga: to jeden z najdroższych „ukrytych" kosztów AWS. Samo istnienie NAT Gateway kosztuje ~€35/miesiąc we Frankfurcie, plus opłata za przetworzone dane. Jeśli możesz, użyj VPC Endpoints dla usług AWS (S3, DynamoDB) zamiast puszczać ruch przez NAT.
Krok 3: Baza danych
Tu masz decyzję do podjęcia: przenieść bazę na zarządzane RDS od razu, czy najpierw postawić ją na EC2 (dokładnie jak na VPS-ie) i przenieść na RDS później?
Wariant A: Od razu na RDS — rekomendowany, jeśli masz standardowe MySQL/PostgreSQL/MariaDB bez egzotycznych konfiguracji. RDS sam zarządza backupami, patching'em, failoverem. Mniej Twojej pracy, mniej ryzyka utraty danych.
Utwórz instancję RDS. Dla typowej aplikacji MŚP: db.t4g.micro (2 vCPU, 1 GB RAM) albo db.t4g.small (2 vCPU, 2 GB RAM). Single-AZ na start — Multi-AZ podwaja koszt, a dla większości małych firm nie jest konieczne od dnia pierwszego. 20–50 GB storage z gp3.
Zrób dump bazy na starym serwerze, prześlij go na instancję EC2 albo bezpośrednio na RDS przez mysql/psql klienta. Przy bazach do kilku GB to kwestia minut. Przy większych — rozważ AWS Database Migration Service (DMS), który potrafi robić migrację z minimalnym przestojem.
Wariant B: Baza na EC2 — jeśli masz niestandardową konfigurację, wtyczki, specyficzne ustawienia, które RDS nie obsługuje. Stawiasz EC2, instalujesz silnik bazy tak jak na VPS-ie, przenosisz dump. Działa identycznie, ale odpowiedzialność za backupy i patching jest po Twojej stronie.
Krok 4: Aplikacja
Teraz Twoja aplikacja. W wariancie lift-and-shift:
Uruchom instancję EC2 w prywatnym subnecie. Dla typowej aplikacji webowej t3.small (2 vCPU, 2 GB) albo t3.medium (2 vCPU, 4 GB) to dobry start. Wybierz AMI z Twoim systemem operacyjnym (Ubuntu, Amazon Linux, Debian).
Zainstaluj na niej swój stos — tak samo jak robisz to na VPS-ie. nginx, PHP-FPM, Node, Python, cokolwiek potrzebujesz. Jeśli masz skrypty provisioningowe (Ansible, skrypt bash), to dobry moment, żeby je użyć. Jeśli nie masz — to dobry moment, żeby je napisać. Ręczne stawianie serwera, którego nie potrafisz odtworzyć, to dług techniczny.
Wgraj kod aplikacji. Skonfiguruj połączenie z bazą danych (endpoint RDS zamiast localhost czy starego IP). Sprawdź, czy aplikacja działa.
Ważne: Nie dawaj tej instancji publicznego IP. Ruch z internetu powinien przechodzić przez load balancer (ALB), a instancja powinna siedzieć w prywatnym subnecie. Nawet jeśli masz jeden serwer.
Krok 5: Load Balancer i HTTPS
Postaw Application Load Balancer (ALB) w publicznych subnetach. Podepnij do niego swoją instancję EC2 jako target. Skonfiguruj listener na porcie 443 (HTTPS) z certyfikatem SSL z AWS Certificate Manager — certyfikaty ACM są darmowe i automatycznie się odnawiają. Żegnaj, ręczne odnawianie Let's Encrypt.
Dodaj redirect z HTTP (port 80) na HTTPS. Gotowe — Twoja aplikacja jest dostępna przez internet, przez ALB, z SSL-em.
ALB kosztuje ~€20–25/miesiąc (stała opłata + opłata za ruch). To koszt, którego na VPS-ie nie miałeś — ale w zamian dostajesz: automatyczny health check, możliwość dodania drugiej instancji EC2 w przyszłości bez zmiany konfiguracji, i separację ruchu publicznego od aplikacji.
Krok 6: Pliki statyczne i CDN
Jeśli Twoja aplikacja serwuje pliki statyczne (obrazki, CSS, JS, uploady użytkowników) bezpośrednio z serwera — przenieś je na S3 + CloudFront.
Utwórz bucket S3. Wrzuć tam pliki statyczne. Postaw dystrybucję CloudFront, która serwuje zawartość z bucketu. Zmień w aplikacji URL-e do statycznych zasobów, żeby wskazywały na CloudFront zamiast na serwer.
Efekt: pliki latają z edge location najbliższego użytkownikowi (w Polsce — z Warszawy), serwer aplikacyjny jest odciążony, strona ładuje się szybciej. S3 + CloudFront dla typowej aplikacji MŚP to kilka złotych miesięcznie — pomijalny koszt, duży zysk.
Uploady użytkowników to trochę więcej pracy — aplikacja musi zapisywać pliki bezpośrednio do S3 (przez AWS SDK) zamiast na lokalny dysk. To jedyna zmiana w kodzie, którą musisz zrobić w wariancie lift-and-shift, ale warto — pliki na S3 mają wbudowaną redundancję i przeżyją awarię instancji EC2.
Krok 7: DNS i przełączenie
Najtrudniejszy moment psychicznie, choć technicznie prosty.
Zanim przełączysz DNS, obniż TTL rekordów do 60 sekund — zrób to 24–48 godzin wcześniej, żeby stary TTL zdążył wygasnąć u wszystkich resolverów. Dzięki temu po przełączeniu użytkownicy trafią na nowy serwer w ciągu minuty, nie godzin.
Zmień rekord A (albo CNAME) tak, żeby wskazywał na ALB. Jeśli przenosisz DNS na Route 53 — to dobry moment. Jeśli zostawiasz DNS u obecnego dostawcy (nazwa.pl, OVH, Cloudflare) — po prostu zmień rekord.
Przez kilka godzin po przełączeniu — monitoruj. Sprawdzaj logi, czas odpowiedzi, czy baza się nie dusi, czy nie lecą 5xx. Trzymaj stary serwer włączony jeszcze przez co najmniej tydzień. Jeśli coś pójdzie nie tak, cofnięcie DNS-a to kwestia minuty.
Krok 8: Monitoring i backupy
Na VPS-ie pewnie miałeś monitoring typu „sprawdzam ręcznie, czy strona działa". Na AWS możesz to zrobić porządnie.
CloudWatch daje Ci podstawowe metryki za darmo: CPU, ruch sieciowy, stan instancji. Dodaj alarmy na CPU > 80% i na status check failed — niech lecą maile. Ustaw Log Groups w CloudWatch Logs, żeby logi aplikacji nie ginęły po restarcie instancji.
Backupy: RDS robi automatyczne snapshoty raz dziennie — upewnij się, że retencja jest ustawiona (7 dni to minimum). Dla instancji EC2 rozważ automatyczne AMI snapshoty (przez AWS Backup albo prostego crona).
Co pójdzie nie tak: lista problemów, na które się przygotuj
Nie chcemy Cię straszyć, ale chcemy, żebyś nie był zaskoczony.
Uprawnienia plików i użytkownicy. AMI na AWS mogą mieć innego domyślnego użytkownika niż Twój VPS (ec2-user, ubuntu zamiast root). Uprawnienia do plików aplikacji mogą się posypać. Sprawdź po wgraniu.
Strefy czasowe. Instancje EC2 domyślnie mają UTC. Jeśli Twoja aplikacja zależy od strefy czasowej (crony, logowanie, wyświetlanie dat) — ustaw to jawnie albo obsłuż w konfiguracji aplikacji.
Połączenie z bazą. Na VPS-ie baza była na localhost z latencją 0 ms. Na RDS jest na osobnej maszynie z latencją 1–2 ms. Dla 99% aplikacji to niezauważalne, ale jeśli Twoja aplikacja robi setki zapytań do bazy na jeden request — zmierzysz różnicę.
Limity wysyłki maili. AWS domyślnie blokuje port 25 (SMTP) na instancjach EC2, żeby ograniczyć spam. Jeśli Twoja aplikacja wysyła maile bezpośrednio z serwera — musisz przejść na SES albo zewnętrzny serwis mailowy (Mailgun, Postmark). To zazwyczaj lepsza opcja i tak.
Security Groups. AWS domyślnie blokuje cały ruch przychodzący. Musisz jawnie otworzyć porty, których potrzebujesz (80, 443 dla ALB, 22 dla SSH z Twojego IP). Nie otwieraj SSH na 0.0.0.0/0 — to zaproszenie dla botów.
Koszty transferu danych. Ruch przychodzący do AWS jest darmowy. Ruch wychodzący — płatny. Przy typowej aplikacji MŚP to grosze, ale jeśli serwujesz dużo plików (video, heavy media) — policz to wcześniej.
Ile to będzie kosztować: realistyczny rachunek
Typowa polska firma MŚP po migracji lift-and-shift, z jedną aplikacją webową:
EC2 t3.small (24/7): ~€18/miesiąc on-demand, ~€12 z Savings Plan. ALB: ~€22/miesiąc. RDS db.t4g.micro Single-AZ: ~€13/miesiąc. S3 + CloudFront: ~€3–5/miesiąc. Route 53: ~€1/miesiąc. CloudWatch (podstawowy): darmowy. NAT Gateway (jeśli potrzebny): ~€35/miesiąc.
Łącznie bez NAT: ~€55–70/miesiąc. Z NAT Gateway: ~€90–105/miesiąc.
W złotówkach to ok. 240–300 zł bez NAT, albo 385–450 zł z NAT.
Porównaj z tym, ile płacisz za obecny VPS. Jeśli Twój VPS kosztuje 50–80 zł/miesiąc, to AWS będzie droższy — ale dostajesz za to: automatyczne backupy, darmowy SSL z auto-renewal, możliwość skalowania, monitoring, i infrastrukturę, której nie musisz łatać o drugiej w nocy.
Jeśli Twój VPS kosztuje 200+ zł/miesiąc i regularnie sprawia problemy — migracja prawdopodobnie się zwróci już w pierwszym miesiącu, bo czas Twojego zespołu jest droższy niż różnica w rachunku.
Harmonogram: ile to realnie trwa
Dla typowej aplikacji (jeden serwer, jedna baza, standardowy stos):
Inwentaryzacja i planowanie: 1–2 dni. Konfiguracja konta AWS, VPC, security groups: pół dnia. Postawienie RDS i migracja bazy: pół dnia do jednego dnia. Postawienie EC2, instalacja stosu, wgranie kodu: 1 dzień. ALB, SSL, CloudFront: pół dnia. Testy: 1–2 dni. Przełączenie DNS i monitoring: 1 dzień.
Realnie: tydzień robocze pracy — niekoniecznie full-time, ale rozłożone na 5–7 dni. Jeśli robisz to pierwszy raz, dodaj bufor na naukę — dwa tygodnie to bezpieczne założenie.
Nie planuj migracji na piątek wieczorem. Nie planuj jej w szczycie sezonu. Najlepszy moment to spokojny tydzień, kiedy ruch jest niski i zespół ma czas na reagowanie.
Po migracji: co dalej
Lift-and-shift jest gotowy. Aplikacja działa na AWS. Teraz możesz — w swoim tempie — optymalizować:
Przejdź na Savings Plans albo Reserved Instances, kiedy będziesz pewien, że konfiguracja jest stabilna. Oszczędność 30–40% na EC2 i RDS.
Rozważ konteneryzację (ECS Fargate), jeśli chcesz uniezależnić się od konkretnej instancji EC2 i ułatwić deployments.
Przenieś więcej logiki na zarządzane usługi: SES zamiast własnego SMTP, ElastiCache zamiast Redis na EC2, CloudWatch Logs zamiast logów na dysku.
Ustaw auto-scaling — nawet prosty, który dodaje drugą instancję EC2 przy wysokim CPU — żeby przeżyć nieoczekiwane szczyty ruchu bez ręcznej interwencji.
Każda z tych optymalizacji to osobny, mały projekt. Żadna nie jest pilna w dniu migracji.
W Otocolobus przeprowadzamy migracje na AWS dla polskich firm — od jednoosobowych projektów po zespoły z kilkudziesięcioma mikroserwisami. Jeśli wolisz, żeby ktoś zrobił to za Ciebie (albo razem z Tobą), odezwij się. Powiemy Ci wprost, czy migracja ma sens w Twoim przypadku — i ile będzie kosztować.