Migracja do chmury AWS - koszty i proces krok po kroku

Migracja do chmury AWS to jedna z najczęstszych decyzji infrastrukturalnych, przed którą stają zespoły techniczne w Polsce. Nie chodzi tylko o przeniesienie serwerów - to zmiana modelu operacyjnego, struktury kosztów i sposobu tworzenia oprogramowania. Jeśli zastanawiasz się ile to kosztuje i jak wygląda proces, ten przewodnik da Ci konkretne odpowiedzi.

Ten post jest dla osób, które podejmują decyzję o migracji do chmury AWS lub już ją planują. Opisuję tu z czego składa się proces, jakie są realne koszty poszczególnych komponentów i kiedy migracja faktycznie ma sens biznesowy. 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.

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.

1. Ocena obecnego środowiska Zaczynamy od audytu. Mapujemy wszystkie aplikacje, bazy danych, integracje, zależności i przepływy danych. Identyfikujemy komponenty stanowe i bezstanowe. Dokumentujemy wymagania zgodności (compliance) i SLA. Na wyjściu dostajesz: mapę zależności, rekomendację podejścia migracyjnego (lift-and-shift vs re-platform vs re-architect) dla każdego środowiska i wstępny model kosztów. To punkt decyzji go/no-go. Faza ta trwa zazwyczaj 3-5 dni.

2. Proof of Concept i wybór architektury Dla kluczowego środowiska (workload) budujemy prototyp na AWS. Weryfikujemy wydajność, koszty i integracje w kontrolowanym środowisku. Projektujemy docelową architekturę zgodnie z AWS Well-Architected Framework. PoC eliminuje największe ryzyko: odkrycie na etapie migracji produkcji, że wybrana architektura nie spełnia wymagań. Trwa 1-2 tygodnie i daje Ci realne liczby zamiast szacunków.

3. Infrastructure as Code Całą infrastrukturę definiujemy w kodzie OpenTofu, Terraform lub Terragrunt dla środowisk izolowanych kontami AWS (multi-account). VPC, subnety, security groups, klastry ECS/EKS, bazy RDS, polityki IAM - wszystko definiujemy w kodzie, wersjonowanym w Git i odtwarzalnym. To fundament, na którym stoją pozostałe fazy. Bez IaC każda zmiana infrastruktury to ryzyko dryfu konfiguracji (IaC configuration drift) i brak audytowalności. Budujemy też pipeline CI/CD (GitHub Actions, GitLab CI) do automatycznego wdrażania zmian infrastrukturalnych.

4. Migracja etapowa Przenosimy środowisko po środowisku: najpierw dev, potem staging, na końcu produkcja. Każdy etap ma zdefiniowany plan odwrotu (rollback). Dla baz danych wybieramy strategię w zależności od wymagań SLA: okno serwisowe z pg_dump/restore lub ciągła replikacja przez AWS DMS z minimalnym przestojem (downtime). Podejście etapowe wyłapuje problemy zanim dotkną użytkowników końcowych. Widzieliśmy zespoły próbujące migracji w trybie tzw. big-bang. Problemy, które w podejściu fazowym rozwiązujesz w godziny, w takiej sytuacji mogą rozciągać się na tygodnie.

5. Walidacja i przełączenie Po migracji na staging uruchamiamy testy wydajnościowe, walidację integralności danych i testy integracyjne aplikacji. Dopiero po pozytywnej weryfikacji przełączamy DNS na produkcji. Stare środowisko utrzymujemy jako opcję rollbacku przez 1-2 tygodnie.

6. Wsparcie po migracji Pierwsze tygodnie po przełączeniu to okres stabilizacji. Monitorujemy metryki wydajnościowe, optymalizujemy koszty (right-sizing na podstawie realnego obciążenia), wdrażamy alerty i runbooki. Przekazujemy wiedzę zespołowi i dokumentujemy architekturę. Opcjonalnie oferujemy bieżącą pomoc techniczną (support retainer) na utrzymanie i rozwój infrastruktury, ale celem jest zawsze przekazanie kontroli Twojemu zespołowi z odpowiednimi narzędziami i dokumentacją. Zobacz nasze case study modernizacji po migracji, które pokazuje jak wygląda ta faza w praktyce: migracja na Graviton, wzmocnienie bezpieczeństwa i usprawnienia CI/CD.

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

Warto wiedzieć: jako AWS Advanced Tier Partner mamy dostęp do programów finansowania, które mogą pokryć znaczną część kosztów migracji. Program Migration Acceleration Program (MAP) pokrywa do 70-80% kosztów zaangażowania partnera. Program Proof of Concept (PoC) finansuje fazę prototypowania. Kwalifikacja zależy od skali migracji i obecnego środowiska. Ocenimy to na wstępnej rozmowie.

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.

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.

Migracja do chmury AWS - koszty, proces i co warto wiedzieć przed startem

Contents