Amazon SAP-C02: Migracja i modernizacja — Przewodnik do nauki

By Laurynas Brazys · 31 July 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

Część AWS Solutions Architect Professional SAP-C02 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Amazon, albo rozwiąż testy na czas na ExamRoll.io.

Strategia i planowanie migracji

Skuteczna migracja zaczyna się od zdyscyplinowanego procesu discovery, mapowania zależności i priorytetyzacji opartej na ryzyku. Użyj AWS Application Discovery Service i AWS Migration Hub do inwentaryzacji serwerów, zbierania metryk wydajności i wizualizacji zależności aplikacji; uzupełnij te dane bezagentową analizą przepływu sieciowego i danymi z systemów zarządzania konfiguracją, aby znaleźć ukryte połączenia stanowe. Przełóż wyniki procesu discovery na decyzje dotyczące landing zone: wybierz strategię kont za pomocą AWS Control Tower i Organizations, zdefiniuj topologię sieci z Transit Gateway i zwymiaruj docelowe zasoby obliczeniowe, korzystając z Compute Optimizer i zaleceń dotyczących right-sizingu. Strategia przełączenia (cutover) powinna być wybierana dla każdej aplikacji indywidualnie: big-bang dla małych systemów o niskim ryzyku; fazowa lub falowa (wave-based) dla kluczowych systemów biznesowych; blue/green lub canary dla usług skierowanych do klienta w celu minimalizacji wpływu na użytkowników. Podczas planowania przełączenia weź pod uwagę okna synchronizacji danych, wartości TTL w DNS, ograniczenia przepustowości oraz ograniczenia regulacyjne. Częste pułapki to niedoszacowanie czasu i kosztów transferu danych, traktowanie strategii lift-and-shift jako stanu docelowego, zaniedbanie przenośności licencji i brak planu awaryjnego wycofania zmian (rollback). Kryteria decyzyjne często wymagają kompromisu między kosztem a nakładem pracy operacyjnej i odpornością: usługi zarządzane (RDS/Aurora, DocumentDB) zwiększają przewidywalność OPEX i odporność, ale mogą wymagać zmian w schemacie; replatforming do ofert zarządzanych zmniejsza obciążenie operacyjne kosztem złożoności migracji.

Narzędzia do migracji lift-and-shift i migracji danych

W celu szybkiego rehostingu, usługa AWS Application Migration Service (MGN) automatyzuje replikację na poziomie blokowym z serwerów VMware, Hyper-V i fizycznych do EC2, minimalizując czas przełączenia i zachowując konfiguracje na poziomie systemu operacyjnego. Migracja dużych wolumenów danych lub migracja offline może wymagać użycia AWS Snow Family lub DataSync dla plików i obciążeń POSIX/NFS, podczas gdy Amazon S3 Transfer Acceleration i Direct Connect przyspieszają transfer obiektów i transfer masowy. Migracja baz danych opiera się na AWS Database Migration Service (DMS) w przypadku migracji homogenicznych lub heterogenicznych, w parze z Schema Conversion Tool (SCT), gdy wymagane są zmiany strukturalne. Należy pamiętać o ograniczeniach DMS: zachowanie MongoDB jako źródła/celu ma ograniczenia dotyczące wersji i funkcji, obsługi dużych obiektów (LOB) oraz potencjalnego opóźnienia replikacji podczas CDC (Change Data Capture). Projektuj z myślą o integralności danych: weryfikuj za pomocą sum kontrolnych, wykonaj pełne załadowanie danych (full load) plus CDC w celu minimalizacji przestojów i zaplanuj przełączenie w oknach o małym natężeniu ruchu. Kompromisy projektowe dotyczą szybkości w porównaniu z wiernością odwzorowania: MGN lub rehosting minimalizuje zmiany w aplikacji, ale utrwala przestarzałe modele operacyjne; replatforming redukuje długoterminowe obciążenie operacyjne, ale wymaga refaktoryzacji i testowania. Częste pułapki to zaniedbanie bezpieczeństwa punktów końcowych (endpoint security), niewystarczająca walidacja przed przełączeniem i zakładanie identycznej liczby IOPS/przepustowości w pamięci masowej w chmurze.

Modernizacja: kontenery, serverless i wzorce refaktoryzacji

Opcje modernizacji obejmują zarówno replatforming do orkiestracji kontenerów, jak i pełną refaktoryzację do architektury serverless. Wybierz Amazon ECS on Fargate dla szybkich wdrożeń skonteneryzowanych z minimalnym zarządzaniem infrastrukturą, lub Amazon EKS dla natywnych obciążeń Kubernetes wymagających przenośności i złożonej orkiestracji. Dla mikroserwisów sterowanych zdarzeniami, połącz AWS Lambda z API Gateway, EventBridge i Step Functions, aby zredukować obciążenie operacyjne i skalować się per żądanie. Usługi danych powinny być przenoszone w kierunku zarządzanych backendów: Amazon RDS/Aurora dla relacyjnych baz danych, Amazon DynamoDB lub Amazon DocumentDB dla baz NoSQL/dokumentowych, oraz ElastiCache dla buforowania o niskiej latencji. Kompromisy zależą od złożoności operacyjnej w porównaniu z kosztem i przewidywalnością wydajności: EKS oferuje kontrolę i przenośność przy wyższym koszcie operacyjnym; Fargate upraszcza operacje, ale może być droższy przy dużej skali. Architektura serverless oferuje efektywność kosztową dla nieregularnych obciążeń (spiky workloads), ale wprowadza problemy z zimnymi startami (cold starts), limitami współbieżności i wyzwaniami związanymi z obserwowalnością (observability). Częste pułapki architektoniczne to przenoszenie monolitów do kontenerów bez dekompozycji komponentów stanowych, niewystarczające wykorzystanie CI/CD i IaC (CloudFormation, CDK, Terraform) do zarządzania wdrożeniami oraz ignorowanie zasady najmniejszych uprawnień (least privilege) w IAM dla ról zadań (task roles) i ról wykonawczych Lambda (Lambda execution roles).

Przełączenie, sieci hybrydowe i operacje po migracji

Pomyślne przełączenie zależy od integracji sieci hybrydowej i tożsamości, a także od solidnej obserwowalności i planów wycofania zmian (rollback). W celu hybrydowego rozwiązywania nazw DNS między VPC a lokalnym Active Directory, wdróż punkty końcowe (endpoints) przychodzące i wychodzące Amazon Route 53 Resolver lub użyj AD Connector/Managed Microsoft AD do dołączania instancji EC2 z systemem Windows do domeny. Opcje łączności sieciowej obejmują AWS Direct Connect i Transit Gateway dla skalowalnych topologii wielokontowych; wybierz Direct Connect, gdy liczy się przewidywalna przepustowość i niższe koszty transferu wychodzącego (egress), a Transit Gateway, aby uprościć łączność typu wiele-do-wielu między VPC a środowiskiem on-premise. Operacje po migracji muszą obejmować monitorowanie (CloudWatch, X-Ray), scentralizowane logowanie i analizę (CloudWatch Logs, Kinesis Firehose do scentralizowanego konta), strategie tworzenia kopii zapasowych i snapshotów międzyregionowych (AWS Backup, cross-region snapshot copy) oraz bazowe standardy bezpieczeństwa (baselines) egzekwowane za pomocą AWS Config i polityk granicnych IAM (boundary policies). Częste pułapki to brak obniżenia wartości TTL DNS przed przełączeniem, nietestowanie integracji z AD na dużą skalę oraz niedostateczne zapewnienie przepustowości Transit Gateway lub brak konfiguracji propagacji tras. Kryteria decyzyjne to odporność w stosunku do kosztów: architektury aktywne-aktywne (active-active) w wielu regionach zwiększają dostępność, ale zwielokrotniają koszty i złożoność replikacji; architektury aktywne-pasywne (active-passive) upraszczają koszty, ale wydłużają RTO.

Problem praktyczny: Scenariusz użycia

Scenariusz: Acme Energy, globalna firma badawcza, posiada istniejące środowisko AWS z wieloma kontami w ramach AWS Organizations oraz lokalne centrum danych połączone za pomocą prywatnego łącza Direct Connect. Firma musi zmigrować zestaw serwerów symulacyjnych z systemem Linux, zestaw replik MongoDB oraz udziały plików z nocnymi obrazami do AWS z minimalnymi zakłóceniami.

Wyzwanie: Zmniejszenie obciążenia operacyjnego i umożliwienie elastycznego skalowania, przy jednoczesnym zapewnieniu nie więcej niż dwóch godzin przestoju podczas przełączenia dla symulacji oraz zerowej utraty danych dla zestawu replik MongoDB i przyjmowania nocnych obrazów.

Zalecane podejście:

1. Wdróż agentów AWS Application Migration Service (MGN) w celu replikacji serwerów symulacyjnych na dedykowane konto migracyjne; skonfiguruj ciągłą replikację na poziomie bloków z niskim RPO i zaplanuj etapową falę przełączenia, zaczynając od węzłów niekrytycznych.
2. Użyj AWS DMS z MongoDB jako źródłem i Amazon DocumentDB (z kompatybilnością z MongoDB) jako celem, przeprowadź pełne ładowanie (full load) oraz CDC, a następnie zweryfikuj spójność na poziomie dokumentów za pomocą sum kontrolnych i równoległych replik do odczytu w celach weryfikacyjnych.
3. Zmigruj nocne obrazy za pomocą AWS DataSync do bucketu Amazon S3 z zastosowaniem reguł cyklu życia S3 Lifecycle; udostępnij Amazon FSx for Lustre lub Amazon EFS dla obciążeń opartych na POSIX, które wymagają semantyki NFS, i przetestuj wydajność odczytu/zapisu pod szczytowym obciążeniem.
4. Zorganizuj przełączenie, obniżając wartości TTL w Route 53, używając ważonego routingu (weighted routing) w Route 53 do przełączania ruchu w trybie blue/green i sfinalizuj zamianę DNS po pomyślnych testach dymnych (smoke tests); wymuś stosowanie ról IAM i włącz CloudWatch X-Ray, scentralizowane logi CloudWatch Logs oraz AWS Backup do tworzenia snapshotów.

Uzasadnienie: Takie podejście minimalizuje przestoje dzięki etapowej replikacji i CDC, zmniejsza obciążenie operacyjne poprzez zastosowanie usług zarządzanych (DocumentDB, S3, DataSync) oraz zapewnia bezpieczne punkty przywracania (rollback) i obserwowalność w celu weryfikacji poprawności przed ostatecznym przełączeniem — co jest zgodne z najlepszymi praktykami profesjonalnej architektury w zakresie migracji i modernizacji.

← Bazy danych i analityka · Wszystkie domeny · Odporność →

Przećwicz te pytania → · Testy na czas na ExamRoll.io →

Przeglądaj Amazon →