Amazon SAA-C03: Transfer i migracja danych — Przewodnik do nauki

By Laurynas Brazys · 18 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Część AWS SAA-C03 — Kompletny przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Amazon, albo rozwiąż testy na czas na ExamRoll.io.

Dylemat: przepustowość a wysyłka fizyczna

Każda migracja zaczyna się od arytmetyki. Oblicz teoretyczny czas transferu przed wyborem narzędzia:

Transfer days = (Dataset size in bits) / (Usable bandwidth in bps × 86,400)
Usable bandwidth = Link speed × Allowed utilization %

Liczby są bezlitosne. Przy stałym transferze 100 Mb/s, przesłanie 1 TB zajmuje około 24 godzin; przy 1 Gb/s, około 2,5 godziny. Łącze 15 Mb/s z ograniczeniem do 70% wykorzystania pozwala na przesłanie zaledwie ~113 GB dziennie, więc 20 TB wymagałoby ponad 175 dni. Transfer 150 TB w ciągu nocy (10 godzin przy 80% ze 100 Mb/s) daje ~360 GB na noc, czyli 10,5 TB miesięcznie — co jest dalekie od 30-dniowego terminu. Nawet przy pełnym obciążeniu 24/7, łącze 100 Mb/s pozwala na transfer zaledwie ~1 TB dziennie, więc 150 TB wymaga minimum 150 dni. W skali petabajtów sytuacja wygląda jeszcze gorzej: łącze 500 Mb/s przy rzeczywistej wydajności zapewnia teoretyczną przepustowość na poziomie około 5,4 TB dziennie, co oznacza, że 10 PB wymagałoby ponad pięciu lat ciągłego transferu — dłużej niż trwa udostępnienie większości połączeń Direct Connect.

Rozsądna zasada ogólna:

Najczęstszą błędną odpowiedzią w scenariuszach migracyjnych jest wybór transferu przez sieć WAN, który matematycznie nie może zakończyć się w wyznaczonym oknie czasowym. Wynikająca z tego pułapka — „będziemy po prostu przesyłać dane każdej nocy przez WAN” — to nie tylko kwestia wolniejszego transferu. Zużywa to przepustowość środowiska produkcyjnego, stwarza ryzyko częściowych lub uszkodzonych transferów wymagających ponownego przesyłania i zazwyczaj kosztuje więcej po uwzględnieniu opłat za przepustowość i czasu pracy inżynierów. Opłata za urządzenie Snowball wraz z wysyłką to stały, przewidywalny koszt.

Rodzina usług Snow do masowego transferu danych w trybie offline

Urządzenia Snowball Edge występują w dwóch wariantach:

Snowcone to małe (~8 TB SSD), wzmocnione urządzenie, które można wysłać kurierem, przydatne w lokalizacjach o ograniczonej przestrzeni i z preinstalowanymi agentami DataSync do synchronizacji na brzegu sieci. Snowmobile — 45-stopowy kontener przewożący do 100 PB — był przeznaczony do ewakuacji centrów danych w skali eksabajtów, ale został wycofany w większości regionów na rzecz równoległych flot urządzeń Snowball Edge. Wybór Snowmobile dla wolumenu danych poniżej petabajta jest odpowiedzią mającą na celu zmylenie.

Wariant Compute to nie tylko większy dysk. Uruchamia lokalnie obrazy EC2 AMI, funkcje Lambda i zadania Greengrass, co czyni go właściwym wyborem, gdy dane muszą być transformowane, filtrowane lub gdy dane PII muszą zostać zredagowane przed pozyskaniem, gdy obciążenie musi zostać natychmiast wznowione w AWS po pozyskaniu, lub gdy lokalizacja jest odłączona lub ma sporadyczne połączenie z siecią (statki, zdalne kopalnie, wdrożenia taktyczne, badania w terenie). Wybierz wariant Compute Optimized, gdy wymagane jest przetwarzanie na urządzeniu; wybierz Storage Optimized, gdy zadanie polega wyłącznie na masowym kopiowaniu danych.

Każde urządzenie z rodziny Snow szyfruje dane w spoczynku (at rest) za pomocą 256-bitowego szyfrowania, używając kluczy KMS, które nigdy nie opuszczają AWS. Obudowy są zabezpieczone przed manipulacją, posiadają etykietę wysyłkową E Ink oraz sprzętowy moduł Trusted Platform Module. Dane na urządzeniu są zapisywane za pomocą klienta Snowball, punktu końcowego kompatybilnego z S3 lub montowania NFS; protokół TLS chroni dane w tranzycie podczas pozyskiwania i wymiany manifestów wysyłkowych. Po zwrocie zawartość jest pozyskiwana do S3, a urządzenie jest kryptograficznie czyszczone zgodnie ze standardem NIST 800-88.

W przypadku zadań obejmujących petabajty danych na lokalizację, wzorcem jest równoległość. Biuro z łączem o przepustowości 1–2 Gb/s nadal potrzebowałoby miesięcy ciągłego, pełnego obciążenia, aby przenieść 1 PB online; flota ~13 urządzeń Storage Optimized na lokalizację (każde po 80 TB), wysłanych równolegle, pozwala dotrzymać czterotygodniowego terminu, oszczędzając jednocześnie łącze internetowe biura. Dla zadania przeniesienia 600 TB w dwa tygodnie przy użyciu w pełni obciążonego łącza 100 Mb/s, mała, równoległa flota urządzeń jest jedyną poprawną odpowiedzią — nawet pomijając koszty, prawa fizyki sprawiają, że użycie DataSync lub nowego połączenia Direct Connect jest niemożliwe.

DataSync do transferu online, z weryfikacją i przyrostowego

DataSync jest odpowiednim narzędziem, gdy przepustowość jest wystarczająca, ale charakterystyka obciążenia — miliony małych plików, głębokie drzewa katalogów, ciągłe synchronizacje przyrostowe lub migracja między systemami plików — sparaliżowałyby proste narzędzia. Katalog z 20 milionami plików o rozmiarze 4 KB kopiowany za pomocą aws s3 cp jest ograniczany przez opóźnienie round-trip, a nie przepustowość; każda operacja PutObject wiąże się z opóźnieniem round-trip TLS/HTTP i opłatą za żądanie API. Pakowanie do archiwów działa, ale uniemożliwia adresowanie pojedynczych plików. Agent DataSync zrównolegla pracę na wielu strumieniach TCP, natywnie obsługuje metadane, weryfikuje sumy kontrolne każdego pliku end-to-end za pomocą SHA-256, transparentnie ponawia próby i raportuje do CloudWatch — osiągając do ~10 Gbps na agenta przy przewidywalnej cenie za GB.

Źródła i miejsca docelowe obejmują NFS, SMB, HDFS, samodzielnie zarządzane magazyny obiektowe, S3, EFS, FSx for Windows File Server, FSx for Lustre, FSx for OpenZFS oraz FSx for NetApp ONTAP. Transfery używają TLS 1.2 w tranzycie i mogą przechodzić przez interfejsowe punkty końcowe VPC, aby pozostać poza publicznym internetem.

Kluczowy szczegół: DataSync wymaga agenta dla lokalnych (on-premises) źródeł NFS/SMB. Agent działa jako maszyna wirtualna na VMware, Hyper-V lub KVM, na instancji EC2 lub na urządzeniu Snowcone. Przekonanie, że DataSync jest bezagentowy dla środowisk on-prem, to częsta pułapka — jest on bezagentowy tylko wtedy, gdy oba punkty końcowe są natywnymi usługami AWS.

Minimalne wdrożenie:

# Activate the on-prem agent
aws datasync create-agent \
  --activation-key ABCDE-12345-FGHIJ-67890-KLMNO \
  --agent-name onprem-nfs-agent \
  --vpc-endpoint-id vpce-0a1b2c3d

# Define source (NFS) and destination (S3)
aws datasync create-location-nfs \
  --server-hostname 10.0.5.20 \
  --subdirectory /export/video \
  --on-prem-config AgentArns=arn:aws:datasync:...:agent/agent-0abc

aws datasync create-location-s3 \
  --s3-bucket-arn arn:aws:s3:::video-archive \
  --s3-config BucketAccessRoleArn=arn:aws:iam::111122223333:role/DataSyncS3Role

# Task with bandwidth cap, verification, and a nightly schedule
aws datasync create-task \
  --source-location-arn <nfs-arn> \
  --destination-location-arn <s3-arn> \
  --options VerifyMode=POINT_IN_TIME_CONSISTENT,BytesPerSecond=104857600,PreserveDeletedFiles=PRESERVE,PosixPermissions=PRESERVE \
  --schedule ScheduleExpression="cron(0 2 * * ? *)"

Dwie funkcje operacyjne mają znaczenie. Ograniczanie przepustowości (BytesPerSecond) zapobiega nasyceniu współdzielonego łącza — co jest bezpośrednią odpowiedzią na scenariusze typu „łącze 1 Gbps współdzielone z innymi działami”. Filtrowanie i harmonogramowanie pozwalają na synchronizację poza godzinami pracy i wykluczanie plików tymczasowych. Przy łączu Direct Connect 10 Gbps, gdy użytkownicy kontynuują odczyt i zapis, kanonicznym wzorcem jest harmonogramowanie powtarzalnych zadań: pierwsze uruchomienie przenosi większość danych, kolejne przebiegi przyrostowe wychwytują zmiany (delty), a transfer 700 TB jest możliwy w znacznie mniej niż tydzień, nawet przy częściowym wykorzystaniu łącza.

Bardziej subtelna pułapka dotyczy wierności odwzorowania metadanych. DataSync zachowuje wybrany zestaw atrybutów POSIX lub SMB — UID/GID/mode/timestamps dla NFS, własność i listy DACL dla SMB — ale nie przechwytuje wszystkich autorskich atrybutów NAS. Specyficzne dla dostawcy listy ACL, atrybuty rozszerzone wykraczające poza to, co udostępnia protokół, snapshoty i metadane deduplikacji wykraczają poza jego zakres. Gdy zgodność z przepisami wymaga dokładnej repliki NAS, włączając w to funkcje specyficzne dla dostawcy, sam DataSync jest niewystarczający; wymagana jest ścieżka świadoma specyfiki NetApp, taka jak FSx for ONTAP z SnapMirror, lub migracja lift-and-shift za pomocą Storage Gateway.

DataSync uzupełnia również usługę Snowball: Snowball przenosi początkowe 150 TB, a DataSync obsługuje następnie bieżące, cotygodniowe zmiany (delty) w zestawie roboczym o wielkości 500 GB.

Storage Gateway: Prezentacja hybrydowa, nie migracja

Storage Gateway nie jest narzędziem do migracji — to hybrydowa warstwa prezentacji. Aplikacje lokalne (on-premises) nadal komunikują się przez NFS, SMB, iSCSI lub iSCSI-VTL, podczas gdy dane lądują w S3, S3 Glacier lub jako snapshoty EBS. Mylenie Storage Gateway z DataSync to częsty błąd: File Gateway nie jest zaprojektowany do szybkiego przenoszenia 70 TB, a DataSync nie udostępnia stałego zasobu (share) klientom on-prem.

File Gateway to koń pociągowy. Zapisanie pliku \\gateway\share\reports\2024\report.pdf tworzy obiekt s3://bucket/reports/2024/report.pdf — natywnie dostępny dla Athena, Lambda, EMR lub dowolnego klienta S3. To mapowanie jeden-do-jednego pliku na obiekt jest główną zaletą w porównaniu z celami backupu typu „czarna skrzynka” (black-box). Lokalne buforowanie (caching) oznacza, że gorące pliki są zwracane z prędkością sieci LAN; zimne pliki są strumieniowane z S3 na żądanie.

Pamięć podręczna (cache) jest kluczowym elementem tego urządzenia. Odczyty gorących danych są obsługiwane lokalnie; zapisy trafiają najpierw na dysk lokalny i są przesyłane asynchronicznie. Częstym błędem projektowym jest założenie, że backend w S3 oznacza, iż każdy odczyt wiąże się z opóźnieniem round-trip przez internet — tak nie jest, pod warunkiem że zestaw roboczy mieści się w pamięci podręcznej. Odwrotnie, zbyt mała pamięć podręczna powoduje ciągłe chybienia (cache misses), a obciążenie wydaje się „wolne”. Zasada ogólna: cache = 20% całkowitego zbioru danych lub 100% gorącego zestawu roboczego, w zależności od tego, która wartość jest większa.

Na szczególną uwagę zasługuje pułapka związana z wyborem między trybem Cached a Stored. Tryb Cached przechowuje główną kopię w S3, a gorące bloki lokalnie — jest to tanie i elastyczne, ale chybienie w pamięci podręcznej (cache miss) oznacza podróż round-trip przez sieć WAN. Tryb Stored przechowuje główną kopię na dysku lokalnym z asynchronicznymi snapshotami do S3 (jako snapshoty EBS) — każdy odczyt jest lokalny i ma niskie opóźnienie, ale cały zbiór danych musi zmieścić się w lokalizacji on-prem. Dla wymogu zastąpienia systemu backupu, który brzmi „lokalny dostęp do wszystkich danych, podczas gdy ich kopia zapasowa jest tworzona w AWS”, tryb Stored jest prawidłowy; tryb Cached naruszyłby ten wymóg. Wybór trybu Cached dla obciążenia, które wymaga niskiego opóźnienia dla całego zbioru danych, jest sprzeczny z założeniami projektu; wybór trybu Stored, gdy lokalizacja nie może pomieścić pełnego zbioru danych, jest z definicji niemożliwy.

Tape Gateway odpowiada na bardzo specyficzne zapotrzebowanie: wycofanie fizycznej biblioteki taśmowej przy jednoczesnym zachowaniu nienaruszonych przepływów pracy Veeam, NetBackup lub Commvault, poprzez prezentację wirtualnej biblioteki taśmowej (VTL) przez iSCSI, z danymi przenoszonymi w cyklu życia z S3 do Glacier lub Deep Archive. Jest to nieocenione, gdy retencja danych wymagana przez regulacje jest zdefiniowana w kategoriach nośników taśmowych, a istniejące oprogramowanie do backupu nie może zostać zmienione.

AWS Transfer Family

Transfer Family dostarcza w pełni zarządzane punkty końcowe SFTP, FTPS, FTP i AS2, oparte na S3 lub EFS. Propozycja wartości polega na zachowaniu umów dotyczących protokołów z partnerami: systemy dostawców, które wysyłają pliki wyłącznie przez SFTP, mogą kontynuować działanie bez zmian, podczas gdy strona odbierająca to natywne S3 — z politykami cyklu życia, wyzwalaczami Lambda i integracją z analityką.

Pułapką jest założenie, że starszy dostawca może „po prostu przełączyć się na API S3”. Wiele systemów dostawców to urządzenia (appliances), kanały HL7 ze szpitali, systemy wsadowe w bankowości czy potoki EDI B2B, których klient SFTP jest wbudowany w oprogramowanie układowe lub podpisane pliki binarne. Koszt zarządzania zmianą, przeglądu bezpieczeństwa i ponownej certyfikacji związany z ich modyfikacją często przewyższa koszt całej migracji do AWS. Transfer Family całkowicie omija ten problem. Wsparcie dla AS2 dodatkowo umożliwia obsługę obciążeń EDI z potwierdzeniami MDN oraz podpisywaniem/szyfrowaniem wiadomości w celu zapewnienia zgodności w komunikacji B2B.

Uwierzytelnianie obsługuje użytkowników zarządzanych przez usługę, AWS Directory Service (Managed Microsoft AD lub AD Connector dla lokalnego AD) lub niestandardowego dostawcę tożsamości przez API Gateway/Lambda — co pozwala, aby istniejące poświadczenia korporacyjne pozostały źródłem prawdy. Authorizer Lambda może zwracać role IAM dla poszczególnych użytkowników, mapowania katalogów domowych i polityki sesji, zapewniając izolację dla każdego dostawcy bez dedykowanej dla niego infrastruktury.

Type: AWS::Transfer::Server
Properties:
  Protocols: [SFTP]
  IdentityProviderType: AWS_DIRECTORY_SERVICE
  IdentityProviderDetails:
    DirectoryId: d-9067f4a1c2
  Domain: S3
  EndpointType: VPC
  EndpointDetails:
    VpcId: vpc-0abc123
    SubnetIds: [subnet-0a, subnet-0b]
    SecurityGroupIds: [sg-0sftp]

Amazon AppFlow

AppFlow to zarządzana warstwa integracyjna do przenoszenia danych z SaaS do AWS: Salesforce, ServiceNow, Google Analytics, Slack, Marketo, SAP OData, Zendesk i dziesiątki innych, z przepływem danych do S3, Redshift lub Snowflake. Obsługuje paginację, ekstrakcję przyrostową, mapowanie pól, filtrowanie, maskowanie i walidację bez potrzeby tworzenia ręcznie pisanego zadania ETL.

Kluczową funkcją z punktu widzenia bezpieczeństwa jest integracja z PrivateLink dla wspieranych konektorów (w szczególności Salesforce). Zamiast wychodzić do publicznego internetu, aby dotrzeć do tenanta SaaS i wrócić do AWS, przepływ danych przechodzi przez prywatny punkt końcowy VPC — eliminując ekspozycję ładunków danych na publiczny internet i upraszczając audyty dla obciążeń związanych z opieką zdrowotną, finansami i danymi osobowymi (PII). Przepływy (flows) mogą być uruchamiane według harmonogramu, wyzwalane zdarzeniami (zmianami rekordów w SaaS) lub na żądanie, i obsługują do 100 GB na jedno wykonanie przepływu.

AppFlow działa na wyższej warstwie niż DataSync czy Storage Gateway: jest to odpowiednie narzędzie, gdy źródłem jest usługa SaaS oparta na API, a nie system plików czy baza danych.

Migracja baz danych: DMS i SCT

AWS Database Migration Service replikuje dane między źródłowymi a docelowymi bazami danych, podczas gdy źródło pozostaje w pełni operacyjne. Obsługuje migracje homogeniczne (MySQL → RDS MySQL, Oracle → RDS Oracle) i heterogeniczne (Oracle → Aurora PostgreSQL, SQL Server → MySQL), a cele wykraczają poza RDS, obejmując Aurora, Redshift, S3, DynamoDB i Kinesis. Źródła obejmują Oracle, SQL Server, MySQL, PostgreSQL, MongoDB i Db2.

Zadanie (task) działa w jednym z trzech trybów:

Mechanizmem umożliwiającym przełączenie z minimalnym czasem przestoju jest Change Data Capture (CDC). Podczas trybu pełnego ładowania z CDC, DMS masowo kopiuje istniejące wiersze, jednocześnie analizując dziennik transakcji źródła — redo log w Oracle, binlog w MySQL, MS-CDC lub MS-Replication w SQL Server. Gdy pełne ładowanie się zakończy, CDC stosuje zakolejkowane zmiany i utrzymuje ciągłą aktualność celu, aż do momentu przełączenia aplikacji. Niepowodzenie włączenia CDC, gdy aplikacja musi pozostać zapisywalna, jest częstym błędem architektonicznym: tryb samego pełnego ładowania sprawia, że cel staje się nieaktualny w momencie zakończenia ładowania.

{
  "MigrationType": "full-load-and-cdc",
  "ReplicationTaskSettings": {
    "TargetMetadata": { "ParallelLoadThreads": 8 },
    "ChangeProcessingTuning": { "BatchApplyEnabled": true }
  }
}

W przypadku pracy heterogenicznej, AWS Schema Conversion Tool (lub jego chmurowy odpowiednik DMS Schema Conversion) tłumaczy DDL, procedury składowane, widoki i funkcje, oznaczając elementy wymagające ręcznych poprawek. DMS przenosi dane; SCT konwertuje schemat. Pominięcie raportu z oceny SCT to przepis na niepowodzenie migracji na trzy dni przed przełączeniem.

Wymagania wstępne i ograniczenia specyficzne dla silnika bazodanowego mogą być bardzo dotkliwe, jeśli zostaną zignorowane. Obiekty LOB w Oracle powyżej 64 KB wymagają trybu limited LOB mode ze stałym maksimum; LONG RAW ma swoje zastrzeżenia. PostgreSQL wymaga ustawienia wal_level=logical i roli replikacyjnej. MySQL wymaga logowania binarnego w formacie ROW z odpowiednim binlog_row_image i podniesionymi uprawnieniami dla CDC (REPLICATION CLIENT, REPLICATION SLAVE). Oracle Spatial, zachowania specyficzne dla RAC oraz zestawy CLR w SQL Server są często nieobsługiwane. TLS jest wymuszany między instancją replikacyjną a punktami końcowymi, z trybami SSL require, verify-ca lub verify-full.

DMS Serverless jest właściwym wyborem, gdy profil obciążenia jest nieprzewidywalny lub impulsowy — na przykład dla lokalnego systemu Oracle ze skokami obciążenia w ciągu dnia i spokojnymi nocami. Definiujesz MinCapacityUnits i MaxCapacityUnits w jednostkach DCU (DMS Capacity Units), a DMS skaluje pojemność replikacji w oparciu o obciążenie procesora i pamięci:

ReplicationConfigIdentifier: oracle-to-rds-cdc
ReplicationType: full-load-and-cdc
SourceEndpointArn: arn:aws:dms:...:endpoint:oracle-onprem
TargetEndpointArn:  arn:aws:dms:...:endpoint:rds-oracle
ComputeConfig:
  MinCapacityUnits: 4
  MaxCapacityUnits: 64
  MultiAZ: true

Częstą pułapką jest założenie, że provisionowana instancja DMS (np. dms.c5.4xlarge) będzie się automatycznie skalować. Nie będzie — instancje provisionowane to hosty EC2 o stałym rozmiarze. Jeśli przepustowość przekroczy pojemność, opóźnienie replikacji (replication lag) wzrośnie i trzeba ręcznie zmodyfikować klasę instancji, restartując zadania. Provisionowany DMS pasuje do migracji o stałym, znanym natężeniu ruchu; Serverless pasuje do tych nieprzewidywalnych.

Dla migracji 20 TB bazy MySQL z dwutygodniowym oknem czasowym i krótkim dopuszczalnym przestojem, DMS z trybem pełnego ładowania plus CDC do Aurora MySQL lub RDS MySQL jest najbardziej opłacalnym rozwiązaniem. Natywne przywracanie za pomocą mysqldump/mysqlpump wiąże się z niedopuszczalnym czasem przestoju; Snowball dodaje opóźnienia związane z wysyłką i luki w danych wynikające z pracy offline.

DMS Fleet Advisor odkrywa zasoby baz danych w środowisku on-premise, co jest przydatne do planowania fal migracji.

Migracja serwerów: AWS Application Migration Service (MGN)

AWS Application Migration Service to główna usługa do migracji typu lift-and-shift („rehosting”), która w większości przypadków zastąpiła CloudEndure Migration oraz Server Migration Service. MGN instaluje lekki agent replikacji AWS na każdym serwerze źródłowym (fizycznym, VMware, Hyper-V lub w innej chmurze). Agent wykonuje początkową migawkę na poziomie bloków do taniego obszaru przejściowego (staging area) w docelowym VPC — są to małe instancje T3 z dołączonymi woluminami EBS — a następnie w sposób ciągły i asynchroniczny replikuje zmiany na poziomie bloków. Ponieważ replikacja odbywa się na poziomie bloków i jest ciągła, przełączenie (cutover) trwa zaledwie minuty: w momencie przełączenia MGN konwertuje woluminy z obszaru przejściowego na produkcyjne instancje EC2 docelowego typu.

1. Install replication agent on each source (or use agentless for vCenter)
2. Configure launch template (instance type, subnet, IAM role, tags)
3. Run "Test" launches → validate → "Cutover" launch → decommission source

Uruchomienia testowe są kluczowe, a często pomijane. MGN uruchamia izolowane instancje testowe z bieżącego stanu replikacji, nie zakłócając trwającej replikacji. Weryfikujesz działanie aplikacji, odrzucasz test, powtarzasz proces i inicjujesz przełączenie dopiero po pomyślnym przejściu testów — przełączenie zatrzymuje replikację, uruchamia finalną instancję i oznacza falę migracji jako zakończoną.

Niewłaściwym podejściem jest ręczne eksportowanie maszyn wirtualnych do formatu OVF, przesyłanie ich za pomocą aws ec2 import-image i ponowne instalowanie aplikacji na nowo utworzonych instancjach EC2. Jest to powolne, podatne na błędy, wymaga przestoju dla każdej maszyny wirtualnej równego czasowi eksportu, nie zapewnia replikacji delta i nie oferuje możliwości przeprowadzania testów bez zakłóceń. MGN eliminuje wszystkie te problemy — serwer źródłowy działa nieprzerwanie aż do ostatniej sekundy przed przełączeniem, a rozbieżność (drift) między źródłem a celem jest praktycznie zerowa.

Ogólne wytyczne dotyczące portfolio zakładają, aby najpierw wykonać rehosting, a następnie replatforming lub refaktoryzację już wewnątrz Regionu, gdzie koszt iteracji jest niższy. Jednoczesna refaktoryzacja i migracja mnoży ryzyko bez proporcjonalnych korzyści.

Łączność hybrydowa: Direct Connect i VPN

AWS Direct Connect zapewnia dedykowane połączenie warstwy 2 z routera on-premise do lokalizacji Direct Connect, oferując stałą przepustowość (dedykowane 1, 10, 100 Gb/s; poniżej 1 Gb/s za pośrednictwem połączeń hostowanych przez partnerów) i przewidywalne opóźnienia. Wirtualne interfejsy (Virtual Interfaces) dzielą to połączenie:

• Private VIF — dostęp do pojedynczego VPC przez Virtual Private Gateway.
• Transit VIF — dostęp do wielu VPC przez Direct Connect Gateway połączony z Transit Gateway. Jest to kanoniczny wzorzec dla dużych środowisk z wieloma VPC i wieloma lokalizacjami.
• Public VIF — dostęp do publicznych punktów końcowych usług AWS (S3, DynamoDB) bez przechodzenia przez publiczny internet.

Samo połączenie DX nie jest wysoko dostępne: pojedynczy obwód w jednej lokalizacji DX zależy od pojedynczej ścieżki światłowodowej. Ważne są dwa wzorce zapewniania odporności:

1. DX + zapasowe połączenie Site-to-Site VPN przez internet to minimalny akceptowalny poziom HA. BGP obsługuje automatyczne przełączanie awaryjne (failover) z użyciem AS-path prepending, MED lub local-pref, aby w stanie stabilnym preferować DX.
2. Podwójne obwody DX w oddzielnych lokalizacjach DX to wzorzec maksymalnej odporności dla obciążeń o znaczeniu krytycznym, wymagany przez umowę SLA dla DX.

Brak zapewnienia jakiejkolwiek ścieżki zapasowej to dobrze znana pułapka: gdy DX ulegnie awarii, a nie ma połączenia VPN, aplikacje hybrydowe, zadania DataSync i transfery przez Storage Gateway zatrzymują się na czas naprawy przez operatora. Czyste połączenie VPN jest akceptowalne dla obciążeń o niższej przepustowości lub jako rozwiązanie pomostowe na czas zestawiania połączenia DX, co może trwać tygodniami.

On-prem Router ──── DX (primary, BGP MED=100) ────┐
                                                   ├── VGW/DXGW ── VPC
On-prem Router ──── VPN over Internet (backup) ────┘

# Multi-VPC access via DX Gateway
DirectConnectGateway:
  Associations:
    - TransitGateway: tgw-corp
    - VirtualPrivateGateway: vgw-prod-vpc
  AllowedPrefixes:
    - 10.0.0.0/8

Gdy wymagane jest szyfrowanie na warstwie fizycznej, należy wybrać połączenie DX z obsługą MACsec. Połączenie DX dla przepustowości, DataSync dla orkiestracji i Storage Gateway dla zapewnienia ciągłego dostępu lokalnego to kanoniczny wzorzec hybrydowy dla dużych, aktywnych zbiorów danych, które nie tolerują okien przestoju.

AWS Outposts dla infrastruktury AWS on-premise

Outposts rozszerza infrastrukturę AWS na obiekt klienta w postaci w pełni zarządzanej szafy rack (lub serwerów Outposts 1U/2U). Uruchamia lokalnie wyselekcjonowany zestaw usług — EC2, EBS, ECS, EKS, RDS, S3 on Outposts, EMR — z tymi samymi API, co w nadrzędnym Regionie. Operacje płaszczyzny sterowania (control-plane) wracają do nadrzędnego Regionu przez łącze serwisowe (service link) składające się z redundantnych, szyfrowanych tuneli; awaria sieci WAN tymczasowo uniemożliwia uruchamianie nowych instancji, ale nie zatrzymuje już działających obciążeń.

Podział współdzielonej odpowiedzialności to pułapka, w którą wpadają operatorzy. AWS dostarcza i utrzymuje sprzęt, hiperwizor oraz usługi zarządzane. Klient jest odpowiedzialny za:

• Przestrzeń fizyczną, zasilanie, chłodzenie i sieć spełniające specyfikacje Outposts (redundantne źródła zasilania, przełączniki upstream, odpowiednie listwy zasilające PDU).
• Bezpieczeństwo fizyczne obiektu.
• Konfigurację sieci lokalnej — Local Gateway (LGW) dla ruchu on-premise oraz uplink dla łącza serwisowego.
• Kwestie systemu operacyjnego i aplikacji w ramach obciążeń, dokładnie tak samo jak w Regionie.
• Odpowiednią łączność WAN z nadrzędnym Regionem.

Outposts nie eliminuje operacji — przesuwa jedynie poziom abstrakcji. Zakładanie, że AWS odpowiada za zasilanie w serwerowni lub sieć upstream, jest fundamentalnym nieporozumieniem. Nie jest to również rozwiązanie typu „uruchom dowolną usługę AWS on-premise”: lista obsługiwanych usług jest ograniczona, a usługi takie jak Route 53 czy IAM pozostają usługami regionalnymi.

W przypadku modernizacji Hadoop/Spark, gdzie dane muszą pozostać on-premise ze względów regulacyjnych, EMR on Outposts jest właściwym wzorcem — zarządzane, elastyczne klastry Spark z narzędziami z Regionu i lokalną rezydencją danych. Storage Gateway lub DataSync nie spełniają wymogu rezydencji danych, a migracja lift-and-shift do EMR w Regionie narusza zgodność z przepisami.

Dystrybucja treści do flot urządzeń brzegowych

Gdy serwery Outposts, sklepy detaliczne lub urządzenia brzegowe wielokrotnie pobierają ten sam duży ładunek — na przykład nocne wydanie oprogramowania — pobieranie go bezpośrednio z bucketu S3 w jednym regionie nasyca łącza wysyłające i wydłuża czas wdrożenia. Prawidłowym wzorcem jest CloudFront ze źródłem w S3 i podpisanymi adresami URL:

S3 bucket (ap-northeast-1)  ← Origin Access Control
        │
   CloudFront distribution (global edge PoPs)
        │
   Signed URLs (short expiry, per-server or per-release)
        │
   Edge devices download from nearest PoP

Pierwsze urządzenie w regionie rozgrzewa pamięć podręczną edge; każde kolejne urządzenie pobiera dane z opóźnieniem brzegowym. Podpisane adresy URL zapobiegają nieautoryzowanym pobraniom bez konieczności stosowania poświadczeń IAM dla każdego urządzenia, a do tego nie ma potrzeby zarządzania flotą regionalnych replik.

Dwa antywzorce, których należy unikać: hostowanie wydania na pojedynczym serwerze WWW EC2 (katastrofa pod względem skalowalności i opóźnień) oraz replikowanie bucketu S3 do każdego regionu za pomocą Cross-Region Replication tylko w celu zmniejszenia opóźnień pobierania (niepotrzebne koszty przechowywania i złożoność operacyjna, które buforowanie w CloudFront rozwiązuje za darmo).

Podsumowanie decyzyjne

← Pamięć masowa i cykl życia danych · Wszystkie domeny · Sieci i łączność →

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

Przeglądaj Amazon →