Migracja Azure do AWS z AWS Transform

AWS Transform konwertuje teraz kod Azure SDK na AWS SDK dla aplikacji .NET - czyli dokładnie tę żmudną robotę, która kiedyś oznaczała ręczne przepisywanie wywołań w całej bazie kodu. To realnie przydatne. Ale konwersja SDK to jeden wycinek przeniesienia z Azure do AWS, a nie całość. W tym artykule omawiamy, co dokładnie AWS Transform konwertuje, co zostawia Tobie (dane, architektura, testy i decyzja, co w ogóle przenosić) oraz gdzie to pasuje w realnej migracji.

Jeśli utrzymujesz .NET na Azure i rozważasz przejście do AWS, ogłoszenie z października 2026 warto zrozumieć precyzyjnie, bo łatwo odczytać “konwersję kodu Azure do AWS” jako “migrację Azure do AWS”. To nie to samo, a znajomość różnicy jest tym, co utrzymuje re-platforming w harmonogramie.

Co AWS Transform faktycznie konwertuje

AWS Transform osiągnął ogólną dostępność dla konwersji kodu aplikacji z Azure SDK na AWS SDK, nakierowanej na natywne dla chmury aplikacje .NET z Microsoft Azure. Agent modernizacji .NET w AWS Transform identyfikuje kod usług Azure w Twoim źródle i konwertuje go na równoważny kod usług AWS.

Przebieg to wykryj → oceń → zaplanuj → konwertuj → zweryfikuj: AWS Transform wykrywa Azure SDK w przesłanym źródle, przedstawia opcje konwersji w raporcie oceny i planie modernizacji, pozwala je zaakceptować lub dostosować przed uruchomieniem, a następnie konwertuje zidentyfikowane wywołania na odpowiedniki AWS SDK i weryfikuje, że zmiany zostały wprowadzone do przekształconego kodu.

Usługa Azure (źródło)	Usługa AWS (cel)	Status
Azure Functions	AWS Lambda	GA
Azure Blob Storage	Amazon S3	GA
Azure Queue Storage	Amazon SQS	GA
Azure Cosmos DB	Amazon DynamoDB	Preview

Przykład podany przez AWS: serverless’owa funkcja Azure Functions korzystająca z Azure Cosmos DB może zostać przekonwertowana na funkcję AWS Lambda korzystającą z Amazon DynamoDB. (Dostępne w ośmiu regionach AWS według stanu na październik 2026, w tym N. Virginia, Frankfurt i Londyn - aktualną listę sprawdź w ogłoszeniu AWS.)

Co faktycznie oszczędza

Trzeba przyznać, że to usuwa realną i żmudną pracę:

Koniec ręcznego przepisywania wywołań SDK w całej bazie kodu. Znalezienie każdego wywołania Azure SDK i spójna zamiana na odpowiednik AWS to dokładnie ten rodzaj powtarzalnej zmiany, która ręcznie jest wolna i podatna na błędy, a dobrze nadaje się do automatyzacji.
Ocena pokazuje, co jest konwertowalne zanim się zobowiążesz, więc nie odkrywasz niespodzianek w połowie refaktoryzacji.
Przeglądasz i dostosowujesz plan, zamiast akceptować niekontrolowany rewrite - zachowujesz kontrolę nad tym, co się zmienia.

Dla zespołu z dużą ilością kodu .NET na Azure to dni lub tygodnie mechanicznej refaktoryzacji zdjęte ze stołu. To prawdziwy akcelerator.

Planujesz przejście z Azure do AWS i nie wiesz, co da się zautomatyzować?

Umów bezpłatną rozmowę 30 min

Czego nie robi

To część, która liczy się przy planowaniu. AWS Transform konwertuje wywołania SDK. Migracja to znacznie więcej niż wywołania SDK.

AWS Transform pokrywa	Ty (i Twój plan migracji) nadal odpowiadasz za
Przepisanie wywołań Azure SDK na wywołania AWS SDK w kodzie .NET	Decyzję, co w ogóle przenieść, przebudować lub wycofać
Mapowanie Functions/Blob/Queue (i Cosmos w preview) na odpowiedniki AWS	Migrację danych - kopia Blob do S3, a zwłaszcza przeniesienie Cosmos do DynamoDB to osobne zadania
Oznaczenie konwertowalnego kodu w raporcie oceny	Architekturę, sieć, landing zone i projekt IAM na AWS
Weryfikację, że przekonwertowany kod się kompiluje i zawiera zmiany	Testy end-to-end, że aplikacja nadal działa poprawnie pod obciążeniem

Dwa zastrzeżenia warte wyraźnego podkreślenia:

Dane to nie kod. Konwersja wywołania SDK Cosmos DB na wywołanie DynamoDB nie przenosi Twoich danych, a Cosmos i DynamoDB mają bardzo różne modele danych. Konwersja SDK to łatwa część; przeprojektowanie modelu danych i migracja danych to część trudna - a konwersja Cosmos do DynamoDB jest wciąż w preview.
Weryfikacja to nie testy. AWS Transform weryfikuje, że przekonwertowane zmiany zostały wprowadzone do kodu. To nie to samo, co udowodnienie, że aplikacja wciąż działa właściwie na produkcji - to Twoja strategia testów i ona nie znika.

Gdzie to pasuje w realnej migracji Azure do AWS

Traktuj AWS Transform jako akcelerator wewnątrz kroku re-platformingu, a nie zamiennik migracji. W podejściu fazowym, które opisujemy w przewodniku o kosztach i procesie migracji do chmury, sekwencja to z grubsza: ocena → projekt docelowego środowiska AWS (landing zone, sieć, IAM) → re-platforming/refaktoryzacja → migracja danych → testy → przełączenie. AWS Transform mieści się w kroku re-platformingu i przyspiesza go. Nie usuwa kroków po obu jego stronach - decyzji projektowych przed i migracji danych oraz testów po.

To ustawia też realistyczne oczekiwania co do kosztu i harmonogramu. Tańsza konwersja kodu nie czyni tańszą migracji danych, testów ani prac nad landing zone - więc budżetuj całe przeniesienie, a nie tylko wycinek, który automatyzuje narzędzie. Nasze zestawienie kosztów migracji do AWS pokazuje, gdzie leży prawdziwy wydatek.

Kiedy warto zaangażować partnera

Decyzja, co przenieść. Nie wszystko powinno zostać przeniesione jeden do jednego; część lepiej przebudować, skonsolidować lub wycofać. Ten triaż decyduje, czy migracja się uda, czy zacznie dryfować.
Przeprojektowanie modelu danych. Cosmos DB do DynamoDB (albo dowolna zmiana magazynu danych) to problem architektoniczny, nie problem SDK. Właściwe zaprojektowanie wzorców dostępu i kluczy z góry oszczędza kosztownych poprawek.
Landing zone, sieć i IAM na AWS. Środowisko docelowe trzeba zaprojektować i zabezpieczyć, zanim trafią do niego aplikacje.
Strategia testów i przełączenie. Udowodnienie zachowania i zaplanowanie bezpiecznego przełączenia to różnica między migracją a awarią.
Finansowanie. Przeniesienia z Azure do AWS mogą kwalifikować się do finansowania w ramach AWS Migration Acceleration Program (MAP). Jak działa migracja z partnerem i finansowanie, opisujemy w artykule jak wybrać partnera do migracji AWS.

FAQ

Czy AWS Transform migruje całą moją aplikację Azure do AWS? Nie. AWS Transform konwertuje kod Azure SDK na kod AWS SDK w aplikacjach .NET. Nie migruje Twoich danych, nie projektuje architektury AWS i nie testuje aplikacji. Automatyzuje jeden wycinek (przepisanie wywołań SDK) większej migracji.

Co AWS Transform konwertuje? Dla aplikacji .NET konwertuje Azure Functions na AWS Lambda, Azure Blob Storage na Amazon S3 i Azure Queue Storage na Amazon SQS, a konwersja Azure Cosmos DB na Amazon DynamoDB jest dostępna w preview. Wykrywa Azure SDK w źródle, proponuje konwersje w raporcie oceny i konwertuje je po przejrzeniu planu.

Czy migruje też moje dane? Nie. Migracja danych to osobne zadanie. Kopia Blob do S3, a zwłaszcza przeniesienie Cosmos do DynamoDB (różne modele danych), trzeba zaplanować i wykonać osobno - konwersja SDK zmienia tylko kod, który rozmawia z danymi.

Czy konwersja Azure Cosmos DB do DynamoDB jest gotowa na produkcję? Jest w preview według stanu na październik 2026. Traktuj ją jako coś do oceny i pamiętaj, że trudniejszą częścią jest przeprojektowanie modelu danych, a nie samo wywołanie SDK - Cosmos i DynamoDB modelują dane bardzo różnie.

Co jest wspierane - dowolny język lub obciążenie? Celuje w natywne dla chmury aplikacje .NET z Microsoft Azure korzystające z Azure SDK. To konwersja wywołań SDK, więc kod, który nie używa Azure SDK, oraz obciążenia inne niż .NET są poza zakresem.

Jak dużą część migracji Azure do AWS to faktycznie pokrywa? Warstwę wywołań SDK. Projekt architektury i landing zone, migracja danych, IAM i sieć, testy end-to-end oraz decyzja, co przenieść, pozostają - a to większość wysiłku i większość ryzyka.

Podsumowanie

AWS Transform konwertuje kod Azure SDK na AWS SDK dla aplikacji .NET - Functions na Lambda, Blob na S3, Queue na SQS, a Cosmos na DynamoDB w preview. To prawdziwy akcelerator, który usuwa mechaniczną refaktoryzację.
Konwertuje kod, nie migracje. Migracja danych, architektura, landing zone, IAM i testy wciąż są Twoje - a przeprojektowanie modelu danych Cosmos do DynamoDB to trudna część, której narzędzie za Ciebie nie zrobi.
Wstaw to w krok re-platformingu i budżetuj całe przeniesienie. Tańsza konwersja kodu nie czyni tańszą reszty.

Jeśli planujesz migrację Azure do AWS i chcesz wiedzieć, co faktycznie da się zautomatyzować, a co wymaga planu, zajrzyj do naszego przewodnika po migracji do chmury albo napisz do nas bezpośrednio.

Przenosisz obciążenia .NET z Azure do AWS?

Umów bezpłatną 30-minutową rozmowę. Pomagamy zespołom określić, co przenieść, zaprojektować docelowe środowisko AWS, zaplanować migrację danych i testy, których AWS Transform nie pokrywa, oraz sprawdzić, czy przeniesienie kwalifikuje się do finansowania MAP.

Umów rozmowę