Amazon DOP-C02: Pamięć masowa, bazy danych i zarządzanie danymi — Przewodnik do nauki

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

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

Przegląd

Pamięć masowa, bazy danych i transfer danych w AWS muszą być projektowane z myślą o trwałości, dostępności, efektywności kosztowej i automatyzacji. Opanowanie klas pamięci masowej i replikacji S3, pojemności i globalnej dystrybucji DynamoDB, kontroli konfiguracji i wzorców tworzenia kopii zapasowych RDS/Aurora, buforowania w pamięci (in-memory caching), współdzielonych systemów plików oraz usług migracji danych umożliwia tworzenie niezawodnych systemów o niskim opóźnieniu, z przewidywalnym zachowaniem podczas odzyskiwania i kontrolowanymi wydatkami.

Amazon S3: klasy pamięci masowej, cykl życia, intelligent tiering i replikacja

Klasy pamięci masowej S3 dopasowują koszty do wzorców dostępu:

Standard: multi-AZ, niskie opóźnienia, brak opłat za odczyt. Domyślna dla danych „gorących” (hot data).
Intelligent-Tiering (S3 INT): multi-AZ z automatycznym przenoszeniem między warstwami Frequent Access i Infrequent Access oraz opcjonalnymi warstwami archiwalnymi. Opłata za monitorowanie i automatyzację naliczana jest za obiekt; obiekty mniejsze niż 128 KB nie są automatycznie przenoszone. Warstwy Archive Access i Deep Archive Access są opcjonalne (opt-in) z progami ostatniego dostępu; opłaty za odczyt obowiązują z warstw innych niż „frequent”.
Standard-IA i One Zone-IA: niższy koszt przechowywania z opłatami za odczyt; minimalny 30-dniowy okres przechowywania. One Zone-IA jest w jednej strefie dostępności (single-AZ) dla danych, które można odtworzyć.
Glacier Instant Retrieval: milisekundowy dostęp z ekonomiką archiwum; minimum 90 dni.
Glacier Flexible Retrieval: odczyt w czasie od minut do godzin, opcje bulk/standard/expedited; minimum 90 dni.
Glacier Deep Archive: odczyt w czasie od kilku do 12 godzin; minimum 180 dni. Wybierz najchłodniejszą możliwą warstwę, biorąc pod uwagę minimalne opłaty za okres przechowywania, opłaty za odczyt i wymagane czasy dostępu.

Polityki cyklu życia (Lifecycle policies) automatyzują przenoszenie i wygasanie obiektów przy użyciu filtrów (prefiks, tagi) w celu zapewnienia szczegółowej kontroli. Kluczowe akcje obejmują przenoszenie do warstw IA/Glacier po przekroczeniu progów braku aktywności, przenoszenie/wygasanie nieaktualnych wersji w bucketach z włączonym wersjonowaniem, wygasanie znaczników usunięcia (delete markers) oraz przerywanie niekompletnych operacji multipart upload. Cykl życia i tagowanie obiektów są kluczowe do egzekwowania retencji danych i usuwania z uzasadnieniem prawnym (defensible deletion), obok S3 Object Lock (tryby governance/compliance), gdy wymagana jest niezmienność.

Intelligent-Tiering jest idealny, gdy wzorce dostępu są nieznane lub zmienne. Zachowuje wydajność (brak opóźnień w odczycie z warstw frequent/IA), eliminuje potrzebę re-architektury, gdy wzorce się zmieniają, i może opcjonalnie automatycznie archiwizować dane w głębszych warstwach na podstawie ostatniego dostępu, zapewniając najlepsze połączenie zwinności i kontroli kosztów dla długo przechowywanych zbiorów danych ze sporadycznym dostępem.

Replikacja S3 zapewnia trwałe, asynchroniczne kopiowanie obiektów:

Wymagania: włączone wersjonowanie na źródle i w miejscu docelowym. Konfiguracja replikacji definiuje docelowy bucket/konto/Region, filtr według prefiksu/tagów, replikację metadanych (ACL, tagi, S3 Object Lock), klasę pamięci masowej oraz to, czy replikować znaczniki usunięcia i istniejące obiekty.
Same-Region Replication (SRR): zgodność z przepisami/suwerenność danych, agregacja logów, atomowe przetwarzanie między kontami.
Cross-Region Replication (CRR): odzyskiwanie po awarii (DR), redukcja opóźnień, globalna dystrybucja, zgodność z przepisami.
Obiekty szyfrowane przez KMS: rola replikacji musi mieć uprawnienia do deszyfrowania za pomocą źródłowego klucza KMS i szyfrowania za pomocą docelowego klucza KMS. Określ docelowy klucz KMS w regule replikacji w polu EncryptionConfiguration. W przypadku replikacji między kontami zaktualizuj politykę docelowego bucketa, aby zezwolić roli replikacji na zapis.
Istniejące obiekty: użyj S3 Batch Replication do uzupełnienia replikacji.
Replication Time Control (RTC): dodaje 15-minutowe SLA na ukończenie replikacji, z metrykami i powiadomieniami do monitorowania SLA. Przydatne dla zgodności z przepisami i rygorystycznych RPO.
Własność i dostęp: przy replikacji między kontami włącz opcję bucket owner preferred lub Object Ownership bucket owner enforced, aby uniknąć złożoności list ACL i zapewnić, że konto docelowe jest właścicielem replik.

Bazy danych w AWS: DynamoDB, RDS i Aurora

Tryby pojemności i skalowanie DynamoDB:

Na żądanie (On-demand): brak planowania pojemności; ceny za żądanie; idealne dla nieprzewidywalnych lub skokowych obciążeń oraz dla nowych tabel bez znanego ruchu.
Alokowany (Provisioned): ustawienie RCU/WCU z DynamoDB Application Auto Scaling na docelowe wykorzystanie; odpowiednie dla stabilnego lub przewidywalnego ruchu i kontroli kosztów.
Pojemność adaptacyjna (Adaptive capacity): automatycznie redystrybuuje przepustowość partycji do gorących kluczy, ale skrajnie gorące partycje nadal wymagają równoważenia obciążenia (np. sharding zapisu). Indeksy GSI mają oddzielną pojemność; modeluj je ostrożnie, aby uniknąć dławienia (throttlingu).
Rozmiar elementu wpływa na pojemność: 1 WCU na 1 KB zapisu; 1 RCU na 4 KB odczytu o dużej spójności (strongly consistent) lub 8 KB odczytu o spójności ostatecznej (eventually consistent).

Strumienie DynamoDB i DAX:

Strumienie (Streams) przechwytują mutacje na poziomie elementów z 24-godzinną retencją. Wybierz typy widoków, aby uwzględnić obrazy NEW/OLD. Typowe wzorce: wyzwalacze Lambda dla zapisów sterowanych zdarzeniami/CQRS, synchronizacja między tabelami i ścieżki audytowe. Kolejność jest zachowana w obrębie klucza partycji, a dostarczanie odbywa się co najmniej raz (at-least-once).
DAX to zarządzana, kompatybilna z API pamięć podręczna w pamięci operacyjnej dla DynamoDB, która drastycznie zmniejsza opóźnienie odczytu. Obsługuje odczyty o spójności ostatecznej; odczyty o dużej spójności muszą omijać DAX. Oferuje zapis typu write-through dla mutacji elementów i unieważnianie oparte na TTL. Używaj klastrów multi-AZ dla wysokiej dostępności i umieszczaj podsieci DAX blisko klientów.

Tabele globalne DynamoDB:

Replikacja multi-Region, multi-master wykorzystująca strumienie z rozwiązywaniem konfliktów typu last-writer-wins w oparciu o systemowy znacznik czasu. Projektuj tak, aby unikać jednoczesnych aktualizacji tych samych atrybutów w różnych regionach lub zaimplementuj uzgadnianie po stronie aplikacji.
Atrybut TTL jest replikowany jako normalne dane elementu; usunięcia sterowane przez TTL są przetwarzane w każdym regionie i nie są replikowane jako jawne operacje usunięcia.
Kopie zapasowe i PITR działają w zakresie jednego regionu; przywracaj do nowych tabel w każdym regionie i (opcjonalnie) utwórz je ponownie jako nową tabelę globalną.

Konfiguracja i kopie zapasowe Amazon RDS:

Grupy parametrów (Parameter groups) definiują parametry silnika. Parametry statyczne wymagają ponownego uruchomienia; parametry dynamiczne są stosowane natychmiast, jeśli są obsługiwane. Używaj grup parametrów DB dla silników na poziomie instancji i grup parametrów klastra dla Aurora.
Grupy opcji (Option groups) włączają natywne funkcje silnika (np. Oracle TDE/OEM, natywne kopie zapasowe/przywracanie SQL Server, wtyczki MySQL/MariaDB). Opcje mogą wymagać ponownego uruchomienia silnika; ostrożnie zarządzaj oknami zmian.
Automatyczne kopie zapasowe umożliwiają PITR w ramach okna retencji (do 35 dni). Przechwytują codzienne migawki i logi transakcyjne do S3; przywracanie tworzy nowe instancje.
Ręczne migawki są przechowywane do momentu usunięcia, można je kopiować między regionami i udostępniać między kontami (z poszanowaniem uprawnień klucza KMS dla zaszyfrowanych migawek). Używaj kopiowania migawek między regionami jako podstawy do odtwarzania awaryjnego (DR).

Specyfika Amazon Aurora:

Punkty końcowe: punkt końcowy klastra (writer) zawsze wskazuje na instancję główną (primary) dla operacji zapisu. Punkt końcowy odczytu (reader) równoważy obciążenie między replikami. Niestandardowe punkty końcowe mogą wybierać podzbiór replik odczytu dla warstwowych pul odczytu lub wyspecjalizowanych obciążeń. Zawsze kieruj zapisy do punktu końcowego zapisu, a odczyty do punktu końcowego odczytu lub odpowiedniego niestandardowego punktu końcowego, aby zminimalizować przerwy podczas przełączeń awaryjnych.
Serverless v2: precyzyjne, natychmiastowe skalowanie jednostek ACU bez ponownego uruchamiania. Działa w ramach klastra Aurora, obsługuje mieszane instancje serwerowe i alokowane, i jest dobrze dopasowany do nierównomiernych obciążeń, środowisk dev/test lub aplikacji wielodostępnych o nierównym zapotrzebowaniu. Zachowuje spójność połączeń lepiej niż v1 dzięki ciągłemu skalowaniu.
Klonowanie: szybkie klony typu copy-on-write w obrębie jednego regionu dla środowisk dev/test, data science lub walidacji zmian w trybie blue/green. Klony są oszczędne pod względem przestrzeni i różnią się tylko zmienionymi stronami. Można tworzyć łańcuchy klonów; usuń je po zakończeniu pracy, aby odzyskać przestrzeń dyskową.

Buforowanie i współdzielone systemy plików: ElastiCache i EFS

ElastiCache for Redis a Memcached:

Redis: zaawansowane struktury danych, replikacja, Pub/Sub, Lua, strumienie, dane geoprzestrzenne, posortowane zbiory i trwałość danych poprzez migawki; obsługuje automatyczne przełączanie awaryjne Multi-AZ i Redis Global Datastore dla replik do odczytu w innych regionach. Wybierz Redis, gdy potrzebujesz bogatych typów danych, trwałości (przywracanie z migawki) lub wysokiej dostępności z przełączaniem awaryjnym.
Memcached: prosty, wielowątkowy, bez replikacji i trwałości danych; skalowanie w poziomie poprzez sharding po stronie klienta; bezstanowy i łatwy do skalowania horyzontalnego. Wybierz Memcached do efemerycznego, czystego buforowania o bardzo wysokiej przepustowości i gdy chcesz kontrolować sharding po stronie klienta. Tryb klastra Redis i grupy replikacji:
Tryb klastra wyłączony (Cluster mode disabled): jeden shard z instancją główną (primary) i replikami; skalowanie wertykalne lub ograniczone skalowanie horyzontalne poprzez repliki do odczytu.
Tryb klastra włączony (Cluster mode enabled): sharding oparty na slotach haszujących (hash-slot sharding) na wielu shardach głównych, z których każdy ma repliki, co umożliwia niemal liniowe skalowanie w poziomie. Grupy replikacji definiują topologię primary/replica i przełączanie awaryjne Multi-AZ. Kopie zapasowe są tworzone dla każdej grupy replikacji; testuj przełączenie awaryjne, aby zweryfikować RTO.

Amazon EFS dla współdzielonych plików POSIX:

Cele montowania (Mount targets): utwórz po jednym w każdej strefie dostępności (AZ) VPC, aby zapewnić ścieżki dostępu wewnątrz AZ i dostępność. Grupy bezpieczeństwa na celach montowania kontrolują ruch NFS; użyj narzędzia pomocniczego montowania EFS (EFS mount helper) dla TLS w tranzycie i autoryzacji IAM, jeśli jest to wymagane.
Punkty dostępu (Access points): wymuszają użycie określonego katalogu głównego i tożsamości POSIX (UID/GID) dla aplikacji, umożliwiając izolację wielodostępną i proste montowanie z najmniejszymi uprawnieniami przez ECS/EKS/EC2 bez konieczności koordynowania zarządzania użytkownikami systemu operacyjnego.
Zarządzanie cyklem życia i klasy pamięci masowej: EFS Standard i Standard-IA (regionalne, multi-AZ) oraz One Zone/One Zone-IA (pojedyncza AZ). Intelligent-Tiering automatycznie przenosi pliki między klasami standard i IA w oparciu o czas ostatniego dostępu; można również ustawić jawne polityki przejścia. Wybierz warianty One Zone dla danych odtwarzalnych lub niekrytycznych, aby obniżyć koszty. Połącz z AWS Backup w celu scentralizowania polityk i tworzenia kopii zapasowych między kontami/regionami.

Migracja danych: DMS, Snowball i DataSync

AWS Database Migration Service (DMS): migracja online z minimalnym czasem przestoju przy użyciu pełnego ładowania oraz przechwytywania zmian danych (CDC). Obsługuje migracje homogeniczne i heterogeniczne dzięki wbudowanej konwersji schematu (z AWS Schema Conversion Tool dla złożonych konwersji). Używaj do migracji typu „lift-and-shift” do RDS/Aurora, do DynamoDB (poprzez mapowanie JSON) lub do ciągłej replikacji w celu odciążenia odczytów lub stopniowego przełączania. Dobieraj rozmiar instancji replikacji do szczytowych wskaźników zmian; upewnij się, że logi źródłowe (np. binlog/redo) przechowują wystarczającą historię.
AWS Snowball (Edge Storage/Compute Optimized): transfer danych offline w skali petabajtów, gdy sieci są ograniczone/drogie lub gdy trzeba szybko zasilić ogromne zbiory danych w S3/EFS. Możliwość łączenia wielu urządzeń dla obciążeń wielopetabajtowych. Używaj do początkowych masowych transferów, gromadzenia danych w lokalizacjach zdalnych/brzegowych lub migracji z ograniczonych centrów danych. Dane są szyfrowane end-to-end za pomocą KMS; śledzenie urządzeń i plomby zabezpieczające przed manipulacją wspierają łańcuch dowodowy (chain of custody).
AWS DataSync: przyspieszony transfer online dla NFS/SMB do S3/EFS/FSx oraz między usługami storage i regionami AWS. Obsługuje wykrywanie zmian przyrostowych, równoległość, kompresję, kontrolę przepustowości, harmonogramowanie i sprawdzanie integralności. Używaj do przenoszenia cyklicznych zmian (delt), w hybrydowych przepływach pracy oraz do zastępowania niestandardowych skryptów rsync zarządzaną automatyzacją. Wdróż agenta DataSync on-premise, aby uzyskać dostęp do lokalnej pamięci masowej.

Praktyczny scenariusz problemu

Shopify musi zmodernizować swój globalny potok przetwarzania mediów produktowych i dane katalogowe, jednocześnie poprawiając odporność i zmniejszając opóźnienia dla kupujących na całym świecie. Firma musi: replikować obrazy produktów między regionami i kontami z rygorystycznym RPO, zmniejszyć opóźnienia odczytu z DynamoDB w Ameryce Północnej i Europie, migrować zasoby NFS on-premise z bieżącymi zmianami oraz uprościć operacje na RDS z niezawodnymi kopiami zapasowymi.

Zaimplementuj S3 CRR z Replication Time Control z głównego bucketa z mediami w us-east-1 (konto merchandisingowe) do docelowego bucketa w eu-west-1 (konto do dostarczania treści).

Dlaczego: CRR spełnia wymogi separacji między regionami i kontami w celu zapewnienia zasady najmniejszych uprawnień i suwerenności danych. RTC zapewnia SLA na replikację wynoszące 15 minut oraz monitorowanie dla RPO na poziomie wymaganym przez regulacje. Polityka bucketa między kontami zapewnia, że rola replikacji źródłowej może zapisywać dane, a określenie docelowego klucza KMS utrzymuje domeny szyfrowania.

Zdefiniuj reguły replikacji S3 filtrowane według prefiksu i tagu, aby oddzielić oryginały, miniatury i logi, oraz włącz replikację znaczników usunięcia. Użyj S3 Batch Replication do uzupełnienia historycznych obiektów.

Dlaczego: Zakres reguł pozwala uniknąć niepotrzebnych kosztów replikacji, a replikacja znaczników usunięcia utrzymuje spójność semantyczną między regionami. Batch Replication uzupełnia historyczne braki bez potrzeby tworzenia dedykowanych skryptów.

Przekonwertuj katalog produktów i stany magazynowe na globalną tabelę DynamoDB obejmującą regiony us-east-1 i eu-west-1; przełącz tabele na pojemność na żądanie i dodaj klastry DAX w każdym regionie dla API z dużą liczbą operacji odczytu.

Dlaczego: Tabele globalne zapewniają aktywne zapisy w obu regionach (active-active) z niskimi opóźnieniami lokalnych odczytów/zapisów i ciągłą replikacją. Pojemność na żądanie eliminuje ryzyko związane z planowaniem pojemności podczas skoków ruchu. DAX redukuje opóźnienia P99 dla częstych odczytów, chroniąc DynamoDB przed nagłymi skokami dostępu.

Przenieś obciążenie relacyjne zamówień na platformę Amazon Aurora MySQL z punktami końcowymi zapisu i odczytu; dodaj mały czytnik Aurora Serverless v2 dla analityki o nieregularnym obciążeniu i włącz automatyczne kopie zapasowe z 14-dniową polityką retencji.

Dlaczego: Punkty końcowe klastra/czytnika oddzielają operacje odczytu/zapisu i minimalizują zakłócenia podczas konserwacji lub przełączania awaryjnego. Serverless v2 w opłacalny sposób absorbuje nieprzewidywalne, gwałtowne obciążenia analityczne. Automatyczne kopie zapasowe zapewniają PITR i uproszczone procesy przywracania.

Wprowadź ElastiCache for Redis (z włączonym trybem klastra) do przechowywania sesji i buforowania dostępności produktów z Multi-AZ i kopiami zapasowymi typu snapshot; ustaw TTL zgodnie z biznesowymi SLA.

Dlaczego: Struktury danych Redis i przełączanie awaryjne Multi-AZ zapewniają szybkie, stanowe sesje i unieważnianie pamięci podręcznej w czasie niemal rzeczywistym. Tryb klastra skaluje się horyzontalnie wraz ze wzrostem rozmiaru katalogu i ruchu.

Utwórz regionalny system plików EFS z celami montowania w każdej strefie dostępności aplikacji oraz punktami dostępu (Access Points) dla obciążeń wymagających współdzielonej pamięci masowej POSIX (np. procesory mediów). Włącz przejścia cyklu życia EFS do warstwy IA po 30 dniach.

Dlaczego: EFS zapewnia elastyczną, współdzieloną pamięć masową w wielu strefach dostępności; Access Points wymuszają izolację na poziomie aplikacji i tożsamości POSIX. Zarządzanie cyklem życia automatycznie obniża koszty dla rzadko używanych zasobów, które pozostają dostępne.

Zmigruj biblioteki mediów z NFS on-premise za pomocą AWS DataSync z zaplanowanymi zadaniami do nocnych synchronizacji przyrostowych do S3 i EFS.

Dlaczego: DataSync obsługuje wykrywanie zmian, równoległość, weryfikację integralności i kontrolę przepustowości lepiej niż doraźne skrypty rsync, automatyzując bieżące zmiany przy minimalnym wysiłku operacyjnym.

Przenieś historyczny katalog PostgreSQL do Aurora za pomocą AWS DMS (pełne ładowanie plus CDC) i AWS Schema Conversion Tool w razie potrzeby; przełącz się po zniwelowaniu opóźnienia CDC.

Dlaczego: DMS umożliwia migrację z niemal zerowym czasem przestoju, a ciągła replikacja zapewnia spójność danych w momencie przełączenia. SCT obsługuje konwersje specyficzne dla silnika bazy danych.

Zasiej wielopetabajtowe historyczne media do S3 za pomocą urządzeń Snowball Edge, a następnie przełącz się na DataSync dla bieżących przyrostów.

Dlaczego: Snowball przyspiesza masowy transfer początkowy bez nasycania łącz WAN; DataSync podtrzymuje ciągłe aktualizacje po zasileniu danych, z weryfikacją i harmonogramowaniem.

Ta architektura zmniejsza globalne opóźnienia odczytu, zapewnia przewidywalne RPO replikacji, upraszcza operacje na bazach relacyjnych i kopie zapasowe, centralizuje współdzieloną pamięć masową z kontrolą dostępu oraz zapewnia pragmatyczną ścieżkę od masowej migracji offline do zautomatyzowanego, przyrostowego przepływu danych.

← Architektury sterowane zdarzeniami i automatyzacja · Wszystkie domeny · Sieci i dostarczanie treści →

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