Migracja do chmury AWS - strategie, koszty, narzędzia i kompletny proces

Ten post jest dla CTO, liderów technicznych i architektów, którzy podejmują decyzję o migracji do chmury AWS lub już ją planują. Opisuję tu strategie migracji (7R), narzędzia AWS, jakie są realne koszty poszczególnych komponentów, proces krok po kroku i najczęstsze błędy, które powodują przekroczenia budżetów i harmonogramów. Bazuję na doświadczeniach z projektów migracyjnych, które zrealizowaliśmy dla firm z fintechu, healthcare, SaaS i e-commerce.

Czym jest migracja do chmury AWS

Migracja do chmury AWS to proces przeniesienia aplikacji, baz danych i pozostałych elementów infrastruktury z obecnego środowiska (on-premise, kolokacji, innego środowiska chmurowego, PaaS) do Amazon Web Services. Zakres prac zależy od punktu startu i celu:

• Lift-and-shift - przeniesienie aplikacji 1:1 na EC2 lub kontenery bez modyfikacji kodu. Najszybsze i najtańsze podejście, ale nie wykorzystujesz pełni możliwości chmury.
• Re-platforming - przeniesienie z adaptacją do usług zarządzanych (np. zamiana self-hosted PostgreSQL na zarządzany RDS, zamiana zadań cyklicznych (cronjobs) na EventBridge + Lambda).
• Re-architecting - przebudowa aplikacji na architekturę cloud-native: mikroserwisy, kontenery, serverless, event-driven. To największy nakład pracy, ale daje najlepsze długoterminowe efekty.

W praktyce większość projektów migracyjnych łączy te podejścia. Krytyczne aplikacje mogą wymagać zmian w architekturze, podczas gdy wewnętrzne narzędzia często wystarczy przenieść w trybie lift-and-shift.

Migracja do chmury AWS nie kończy się na uruchomieniu aplikacji. Obejmuje też budowę automatyzacji (CI/CD), monitoring, observability, polityki bezpieczeństwa i modelu operacyjnego dla zespołu, który będzie utrzymywał środowisko po migracji.

7 strategii migracji (7R)

AWS definiuje siedem strategii migracji (tzw. 7R), które określają, w jaki sposób każde środowisko przenosi się do chmury. Wybór odpowiedniej strategii dla każdej aplikacji to decyzja, która ma największy wpływ na koszt, harmonogram i wynik projektu.

Retire

Część środowisk w ogóle nie wymaga migracji. Podczas oceny często odkrywasz aplikacje, które są zbędne, nieużywane lub mogą zostać zastąpione produktem SaaS. Wycofanie ich przed migracją zmniejsza zakres i koszt. Z naszego doświadczenia 10-20% workload w typowym portfolio korporacyjnym kwalifikuje się do wycofania.

Retain

Nie wszystko powinno migrować teraz. Środowiska z kompleksowymi zależnościami, ograniczeniami regulacyjnymi lub zbliżającym się końcem życia mogą pozostać on-premise tymczasowo. Retain to nie „nigdy nie migruj” - to „nie w tej fali”. Dokumentujesz te środowiska i planujesz przyszłą ścieżkę migracji.

Rehost (lift-and-shift)

Przeniesienie aplikacji 1:1 na EC2 lub kontenery bez zmian w kodzie. Najszybsze podejście: typowa migracja w trybie rehost kończy się w dniach do tygodni na aplikację. Zyskujesz korzyści chmury (elastyczność, pay-as-you-go) natychmiast, ale nie optymalizujesz pod kątem wzorców cloud-native. Dobre dla aplikacji z 1-2 letnim pozostałym okresem życia lub gdy szybkość jest ważniejsza niż optymalizacja.

AWS Application Migration Service (MGN) automatyzuje rehost poprzez ciągłą replikację serwerów do AWS i orkiestrację przełączenia z minimalnym przestojem.

Relocate

Przeniesienie infrastruktury na poziomie hypervisora - głównie dotyczy środowisk VMware przenoszonych na VMware Cloud on AWS. Aplikacja, system operacyjny i konfiguracja pozostają identyczne. Przydatne, gdy musisz szybko opuścić centrum danych bez ingerencji w stos aplikacyjny.

Replatform

Migracja z ukierunkowanymi adaptacjami do usług zarządzanych. Przykłady: zamiana self-hosted PostgreSQL na RDS, zamiana zadań cyklicznych (cronjobs) na EventBridge + Lambda, przejście z self-managed Redis na ElastiCache. Zachowujesz architekturę aplikacji, ale zdejmujesz z siebie ciężar operacyjny.

Replatform dodaje zazwyczaj 2-4 tygodnie na workload w porównaniu z rehost, ale redukuje bieżące koszty utrzymania o 40-60%. Dla większości aplikacji o średniej złożoności to jest punkt optymalny między nakładem pracy a korzyścią.

Refactor / Re-architect

Przebudowa aplikacji na wzorce cloud-native: mikroserwisy, kontenery (ECS/EKS), serverless (Lambda), architektura event-driven (EventBridge, SQS, SNS). Najdroższe i najbardziej czasochłonne podejście, ale daje najlepsze długoterminowe rezultaty: niezależne wdrożenia, horyzontalne skalowanie, ograniczony zasięg awarii (blast radius).

Refactoring rezerwuj dla kluczowych aplikacji biznesowych, gdzie potrzebujesz możliwości, których obecna architektura nie jest w stanie dostarczyć: prawdziwe horyzontalne skalowanie, deployment wieloregionalny lub wdrożenia bez przestoju.

Repurchase

Zastąpienie samodzielnie budowanego oprogramowania komercyjnym produktem SaaS. Przykład: migracja self-hosted CRM na Salesforce lub zastąpienie własnego stacku monitoringowego przez Datadog. Aplikacja nie przenosi się do AWS - przenosi się do dostawcy. Uwzględnij repurchase w strategii migracji dla środowisk, gdzie budowanie in-house nie ma już sensu biznesowego.

Jak wybrać strategię

W praktyce większość projektów migracyjnych łączy 3-4 strategie. Typowy rozkład dla portfolio 20 aplikacji:

• Retire: 3-4 aplikacje
• Retain: 2-3 aplikacje (migracja w następnej fali)
• Rehost: 5-7 aplikacji (narzędzia wewnętrzne, systemy legacy)
• Replatform: 5-8 aplikacji (większość)
• Refactor: 2-3 aplikacje (produkty kluczowe)
• Repurchase: 1-2 aplikacje

Strategię per workload ustalamy na etapie oceny środowiska (assessment) na podstawie wartości biznesowej, złożoności technicznej, dostępności zespołu i ograniczeń czasowych.

Narzędzia migracji AWS

AWS udostępnia zestaw usług migracyjnych, z których każda obsługuje inny aspekt procesu. Znajomość dostępnych narzędzi pomaga zrozumieć, co jest zautomatyzowane, a co wymaga dodatkowych kosztów pracy na zamówienie.

AWS Migration Hub

Centralny dashboard do śledzenia postępu migracji wszystkich środowisk. Migration Hub agreguje status z innych narzędzi (MGN, DMS itp.) i zapewnia jednolity widok: które aplikacje są ocenione, w trakcie migracji lub zakończone. Jest bezpłatny - płacisz tylko za narzędzia migracyjne, które wykorzystujesz pod spodem.

Migration Hub zawiera też Strategy Recommendations: automatyczne narzędzie oceny, które analizuje serwery on-premise i sugeruje optymalną strategię migracji (rehost, replatform lub refactor) na podstawie charakterystyki aplikacji.

AWS Application Migration Service (MGN)

Główne narzędzie do migracji w trybie rehost (lift-and-shift). MGN instaluje lekki agent na serwerach źródłowych, który ciągle replikuje dane do AWS. Gdy jesteś gotowy na przełączenie, uruchamia dedykowane instancje z replikowanych danych z minimalnym przestojem (zazwyczaj minuty).

MGN zastąpił starszą usługę CloudEndure Migration i obsługuje zarówno Linux, jak i Windows. Wspiera migracje testowe (uruchom kopię bez przełączania) - możesz weryfikować przed zatwierdzeniem.

AWS Database Migration Service (DMS)

Migruje bazy danych z minimalnym przestojem dzięki ciągłej replikacji danych (CDC - Change Data Capture). DMS wspiera migracje homogeniczne (PostgreSQL → RDS PostgreSQL) i heterogeniczne (Oracle → Aurora PostgreSQL) z użyciem Schema Conversion Tool (SCT).

Kluczowa funkcjonalność: DMS utrzymuje synchronizację bazy źródłowej i docelowej podczas migracji, co pozwala walidować cel przed przełączeniem ruchu. Eliminuje to konieczność długich okien serwisowych. Dla migracji heterogenicznych należy przewidzieć 2-4 tygodnie na konwersję schematów i testy.

AWS Schema Conversion Tool (SCT)

Analizuje schemat bazy źródłowej i konwertuje go do formatu docelowego. Dla PostgreSQL-do-PostgreSQL to jest proste. Dla Oracle-do-Aurora lub SQL Server-do-PostgreSQL SCT identyfikuje konstrukcje wymagające ręcznej interwencji (procedury składowane (stored procedures), kompercyjne rozszerzenia, typy danych).

SCT generuje raport oceny pokazujący jaki procent schematu konwertuje się automatycznie, a co wymaga ręcznej refaktoryzacji. To jest krytyczny wkład dla szacowania harmonogramu i kosztów.

AWS Transfer Family

Zarządzana usługa SFTP, FTPS i FTP do migracji procesów opartych na transferze plików. Jeśli Twój system legacy opiera się na transferach plików (przetwarzanie wsadowe, integracje z partnerami), Transfer Family zapewnia zamiennik wspierany przez S3 lub EFS bez zmiany konfiguracji klientów.

Wybór odpowiedniej kombinacji narzędzi

Dla większości migracji średniej skali (5-20 aplikacji) kombinacja MGN (dla serwerów) + DMS (dla baz danych) + Migration Hub (do śledzenia) pokrywa 80% potrzeb. Pozostałe 20% to automatyzacja budowana z Terraform i pipeline CI/CD.

Dlaczego firmy migrują do AWS

Skalowalność i elastyczność

AWS pozwala skalować zasoby w górę i w dół (wertykalnie) w zależności od obciążenia. Zamiast kupować serwery na szczyt ruchu, płacisz za to, czego faktycznie używasz. ECS Fargate automatycznie skaluje kontenery (horyzontalnie) podobnie jak w ECS z EC2 - grupy skalowania (Auto Scaling Groups) dostosowują liczbę instancji do potrzeb ruchu. To szczególnie istotne dla aplikacji z sezonowym ruchem lub nieprzewidywalnymi skokami.

Optymalizacja kosztów

Paradoksalnie chmura może być droższa niż on-premise, jeśli nie zarządzasz kosztami świadomie. Ale przy prawidłowej konfiguracji (right-sizing, Reserved Instances, Savings Plans, spot instances dla środowisk tolerujących utratę pojedynczych instancji) AWS jest znacząco tańszy niż utrzymywanie własnej infrastruktury które zakłada zapas na ruch szczytowy. Dodatkowo eliminujesz koszty stałe takie jak: utrzymanie serwerowni, energia, chłodzenie, wymiana sprzętu.

Bezpieczeństwo i compliance

AWS oferuje certyfikacje, których uzyskanie na własnej infrastrukturze byłoby kosztowne i czasochłonne: SOC 2, ISO 27001, HIPAA, PCI DSS. Model shared responsibility oznacza, że AWS odpowiada za bezpieczeństwo infrastruktury fizycznej, a Ty za konfigurację na poziomie aplikacji. Usługi takie jak GuardDuty, Security Hub, WAF i KMS pozwalają na budowę bezpiecznego środowiska zgodnego z wymaganiami regulatorów.

Ekosystem usług zarządzanych

Ponad 200 usług AWS oznacza, że nie musisz budować i utrzymywać komponentów infrastrukturalnych samodzielnie. Zarządzane bazy danych (RDS, DynamoDB), kolejki (SQS), cache (ElastiCache), indeksowanie dla wyszukiwania (OpenSearch), streaming (Kinesis) - każda z tych usług to mniejsza odpowiedzialność operacyjna dla Twojego zespołu.

Jak wygląda proces migracji do AWS krok po kroku

Każda migracja do chmury AWS przebiega podobnie. Piszemy tu z perspektywy partnera AWS realizującego migrację, zazwyczaj składa się z sześciu faz. Kolejność jest ważna - pominięcie oceny środowiska lub PoC to najczęstsza przyczyna przekroczeń budżetu i harmonogramu.

Koszt migracji do chmury AWS - jakie są części składowe

Koszt migracji do chmury AWS zależy od kilku czynników: złożoności środowiska, wybranego podejścia migracyjnego, wymagań compliance i liczby środowisk. Poniżej rozbijam główne składniki kosztów bieżących po migracji.

Compute (ECS Fargate / EKS / EC2)

Compute to zazwyczaj największa pozycja na rachunku AWS. Wybór platformy wpływa bezpośrednio na koszt:

• ECS Fargate - płacisz za vCPU i pamięć per task. Typowa aplikacja webowa (0.5 vCPU, 1 GB RAM) to ~$15-25/miesiąc per task. Brak kosztów zarządzania instancjami.
• EKS - $0.10/h za klaster (~$73/miesiąc) plus koszty node’ów (EC2 lub Fargate). EKS ma sens od 10+ mikroserwisów, oraz gdy potrzebujesz ekosystemu Kubernetes z innych powodów.
• EC2 - najtańszy per-unit, ale wymaga zarządzania instancjami. M6i.large (2 vCPU, 8 GB) to ~$70/miesiąc on-demand, ~$44/miesiąc z Reserved Instance (1 rok).

Dla większości migracji rekomendujemy ECS Fargate: eliminuje zarządzanie serwerami, skaluje się automatycznie i jest prostszy operacyjnie niż EKS.

Bazy danych (RDS, DynamoDB)

• RDS PostgreSQL/MySQL - db.m6g.large (2 vCPU, 8 GB) to ~$120-140/miesiąc. Multi-AZ (dla high availability) podwaja koszt compute, ale jest wymagane dla produkcji.
• RDS Aurora - ~20% droższy od standardowego RDS, ale lepszy performance i automatyczne przełączanie (failover). Ma sens przy wymaganiach <1s failover.
• DynamoDB - model pay-per-request od $1.25 za milion zapisów. Dla aplikacji z przewidywalnym obciążeniem (provisioned capacity) jest tańszy.

Do tego dochodzi storage (GP3 SSD od $0.08/GB/miesiąc), backupy i transfer danych między AZ.

Transfer danych i networking

Transfer danych to często ukryty koszt, który zaskakuje po migracji:

• Egress (dane wychodzące z AWS do internetu) - $0.09/GB po pierwszym 1 GB. Przy 1 TB/miesiąc to ~$90.
• Transfer między AZ - $0.01/GB w każdą stronę. Niewiele per-request, ale przy dużym ruchu sumuje się do istotnych kosztów. Należy tego typu ruchu unikać.
• NAT Gateway - $0.045/h (~$33/miesiąc) plus $0.045/GB przetworzonych danych. Potrzebny, gdy prywatne subnety muszą komunikować się z internetem.

Infrastructure as Code i automatyzacja

Koszt wdrożenia IaC to jednorazowa inwestycja w projekt migracyjny:

• Budowa modułów Terraform - konfiguracja VPC, ECS, RDS, IAM, monitoring. To zazwyczaj 1-2 tygodnie pracy inżynieryjnej w zależności od złożoności przy użyciu narzędzi AI.
• Pipeline CI/CD - GitHub Actions, GitLab CI lub AWS CodePipeline. Konfiguracja budowania, testowania i wdrażania. 1-2 tygodnie.
• Bieżące utrzymanie IaC - aktualizacje providerów, nowe moduły, zmiany konfiguracji. To koszt operacyjny, ale znacząco niższy niż ręczne zarządzanie infrastrukturą.

Dofinansowanie - programy AWS MAP i PoC

Programy dofinansowania to realny sposób na obniżenie bariery wejścia. Dla firm migrujących z on-premise lub z innego środowiska chmurowego MAP może pokryć koszt konsultingu, narzędzi migracyjnych i szkolenia zespołu.

Kiedy migracja do AWS ma sens

Migracja do chmury AWS to inwestycja, która nie zawsze jest uzasadniona. Oto sytuacje, w których migracja prawie zawsze przynosi wymierne korzyści:

• Rosnące koszty infrastruktury - jeśli rachunek za hosting (Heroku, DigitalOcean, on-premise) rośnie szybciej niż przychody, AWS z prawidłową konfiguracją obniży TCO o 30-60%.
• Wymagania compliance - SOC 2, ISO 27001, HIPAA, NIS2 wymagają kontroli infrastrukturalnych (szyfrowanie at-rest i in-transit, izolacja sieciowa, audit logging), które na wielu platformach są trudne lub niemożliwe do wdrożenia.
• Potrzeba skalowania - jeśli aplikacja wymaga obsługi skoków ruchu (sezonowość, kampanie marketingowe, eventy), elastyczne skalowanie AWS eliminuje konieczność utrzymywania nadmiarowych zasobów.
• Modernizacja stacku - przejście na kontenery (ECS/EKS), serverless (Lambda), zarządzane bazy danych (RDS/Aurora) zmniejsza obciążenie operacyjne zespołu.
• Wieloregionalność - ekspansja na nowe rynki wymaga obecności w wielu regionach. AWS ma 33 regiony globalnie, w tym Europę (Frankfurt, Irlandia, Paryż, Sztokholm).

Jeśli masz małą aplikację z niskim ruchem, bez wymagań compliance i z 2-3 osobowym zespołem, rozważ, czy prostota obecnego rozwiązania nie jest warta premium. Migracja ma sens, gdy korzyści (koszt, bezpieczeństwo, skalowalność) przewyższają jednorazowy nakład.

Przeczytaj nasze case study migracji z Heroku do AWS, aby zobaczyć, jak wygląda konkretny projekt - od audytu przez migrację po efekty biznesowe.

Jeśli Twoja firma rozważa migrację z innego PaaS, zobacz też nasz post o migracji z Heroku do AWS. Opisuję tam szczegółowo mapowanie usług i typowe błędy.

Najczęstsze błędy przy migracji do chmury AWS

Po realizacji kilkudziesięciu projektów migracyjnych, to są wzorce, które konsekwentnie powodują przekroczenia harmonogramów, niespodzianki budżetowe lub niestabilność po migracji.

1. Pominięcie fazy oceny środowiska

Zespoły chcące szybko zacząć migrację często przeskakują od razu do budowy infrastruktury. Bez prawidłowej oceny odkrywasz problemy z zależnościami w trakcie migracji: usługa zależna od wewnętrznego API, którego jeszcze nie przeniosłeś, lub połączenie bazodanowe zakładające jednocyfrowy czas odpowiedzi (latency) między komponentami.

Rozwiązanie: Zainwestuj 3-5 dni w assessment. Zmapuj każdą aplikację, jej zależności, przepływy danych i wymagania SLA. Mapa zależności oszczędza tygodnie rozwiązywania problemów później.

2. Nieuwzględnienie kosztów transferu danych

Transfer danych z AWS do internetu (egress) kosztuje $0.09/GB. Zespoły, które nie modelują egress podczas planowania, dostają rachunki 2-3x wyższe niż oczekiwane. To jest szczególnie częste, gdy aplikacje komunikują się z systemami nadal działającymi on-premise lub z API zewnętrznych dostawców.

Rozwiązanie: Modeluj koszty egress podczas PoC. Używaj VPC endpoint dla ruchu do usług AWS (eliminuje opłaty NAT Gateway dla S3, DynamoDB itp.). Rozważ Savings Plans dla przewidywalnego compute i projektuj architekturę minimalizując ruch między strefami dostępności (availability zones).

3. Traktowanie chmury jak centrum danych

Wdrażanie przewymiarowanych instancji EC2, które działają 24/7 i nigdy się nie skalują - w praktyce odtwarzanie wzorców on-premise w chmurze. Płacisz ceny chmury bez korzyści chmury.

Rozwiązanie: Right-sizing od pierwszego dnia. Używaj Auto Scaling Groups. Planuj wyłączanie środowisk nieprodukcyjnych poza godzinami pracy (oszczędność 65% na dev/staging). Stosuj Savings Plans lub Reserved Instances dla bazowego obciążenia.

4. Migracja big-bang

Próba przeniesienia wszystkiego naraz w jeden weekend. Gdy coś pójdzie nie tak (a zawsze pójdzie), zasięg awarii to cały stos. Rozwiązywanie problemów jest wykładniczo trudniejsze, gdy wiele systemów zawodzi jednocześnie.

Rozwiązanie: Migruj falami. Zacznij od środowiska lub aplikacji o najniższym ryzyku, zwaliduj, potem przejdź do następnego. Każda fala buduje pewność i ujawnia nowe wzorce, które wykorzystasz ponownie.

5. Odkładanie bezpieczeństwa na później

Bezpieczeństwo dodawane jako “afterthought” prowadzi do otwartych portów w security groups, nadmiernie otwartych polityk IAM i nieszyfrowanych danych w spoczynku. Retrofitting zabezpieczeń jest 3-5x droższy niż budowanie ich prawidłowo od początku.

Rozwiązanie: Zdefiniuj podstawę (baseline) bezpieczeństwa przed migracją pierwszego środowiska lub aplikacji. Wdróż IAM least-privilege od pierwszego dnia. Szyfruj wszystko at-rest i in-transit. Włącz CloudTrail, GuardDuty i Security Hub od początku. Bezpieczeństwo jest tańsze, gdy jest wbudowane w fundament, niż gdy jest łatane post-factum.

Najczęściej zadawane pytania

Jak możemy pomóc

Zrealizowaliśmy migracje do AWS dla firm z różnych branż i punktów startowych: z Heroku, DigitalOcean, on-premise i innych operatorów chmurowych. Każdy projekt dostarczamy z pełną infrastrukturą jako kodem (Terraform), zautomatyzowanym CI/CD i dokumentacją operacyjną.

Nasze usługi migracji do chmury obejmują cały proces: od wstępnej oceny środowiska, przez PoC i budowę infrastruktury, po wsparcie po migracji. Architektura docelowa jest projektowana zgodnie z AWS Well-Architected Framework.

Planujesz migrację do AWS?

Umów bezpłatną 30-minutową rozmowę. Omówimy Twój setup i przygotujemy wstępne porównanie kosztów.

Umów rozmowę