Amazon SAA-C03: Pamięć masowa i cykl życia 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.

Klasy pamięci masowej S3 a spektrum kosztów i opóźnień

Klasy pamięci masowej S3 tworzą spektrum, w którym opóźnienie odczytu, minimalny czas przechowywania i opłaty za odczyt za GB są wymieniane na koszt przechowywania za GB. Prawidłowy wybór to najważniejszy czynnik optymalizacji kosztów w przypadku obiektowej pamięci masowej.

S3 Standard jest domyślną klasą: trwałość na poziomie „jedenastu dziewiątek” w co najmniej trzech Strefach Dostępności (AZ), milisekundowe opóźnienie, brak opłaty za odczyt, najwyższa cena za GB. Standard-IA i One Zone-IA obniżają koszt przechowywania o około 40–50%, ale dodają opłatę za odczyt za GB, minimalny 30-dniowy okres rozliczeniowy oraz minimalny rozmiar obiektu 128 KB (mniejsze obiekty są rozliczane jakby miały 128 KB, co niweluje oszczędności). One Zone-IA dodatkowo obniża koszty, przechowując dane w jednej Strefie Dostępności — jest to odpowiednie tylko dla odtwarzalnych kopii zapasowych, dla których utrata pojedynczej strefy AZ jest akceptowalna.

S3 Intelligent-Tiering to właściwy wybór, gdy wzorce dostępu są nieznane, nieprzewidywalne lub zmieniające się w obrębie dużego zbioru danych. Automatycznie migruje obiekty między warstwami dla danych z częstym dostępem (frequent), rzadkim dostępem (infrequent), natychmiastowym dostępem archiwalnym (archive-instant), archiwalnym (archive) i głęboko archiwalnym (deep-archive) na podstawie obserwowanego dostępu, pobierając niewielką opłatę za monitorowanie każdego obiektu. Ponieważ nie ma opłat za odczyt między warstwami frequent i infrequent oraz nie ma minimalnego czasu przechowywania, jest to najbezpieczniejszy domyślny wybór dla jezior danych (data lakes) i mieszanych obciążeń z obiektami ≥128 KB. Jest to zły wybór, gdy już wiesz, że obiekty są stale „gorące” (dodatkowy koszt monitorowania) lub stale „zimne” przez dekadę (Deep Archive jest znacznie tańszy).

Glacier Instant Retrieval zapewnia milisekundowy dostęp w cenach archiwalnych dla danych, do których dostęp uzyskuje się kwartalnie lub rzadziej — obrazy medyczne, pliki PDF związane ze zgodnością, które muszą być dostępne natychmiast na żądanie. Glacier Flexible Retrieval oferuje odczyt w ciągu minut do godzin. Glacier Deep Archive to najtańsza warstwa w AWS, kosztująca około 1 USD/TB/miesiąc, ze standardowym czasem odczytu 12 godzin (lub 48 godzin w trybie bulk) i minimum 180 dniami przechowywania — właściwe rozwiązanie dla 7–10-letniej retencji danych wymaganej przepisami i jako zamiennik dla taśm magnetycznych.

Dwie główne pułapki kosztowe to przeciwstawne błędy. Wybór klasy Standard dla długoterminowych, rzadko odczytywanych danych to marnowanie pieniędzy, ponieważ Standard nie oferuje niższej ceny za przechowywanie „zimnych” danych — zbiór danych o wielkości 5 TB przechowywany przez lata w klasie Standard kosztuje kilka razy więcej niż te same dane w Deep Archive. Odwrotnie, przenoszenie zupełnie nowych obiektów od razu do Standard-IA lub Glacier to pułapka, ponieważ minimalne opłaty za 30/90/180 dni plus opłaty za odczyt przewyższają oszczędności, gdy obiekty są jeszcze „gorące”. Glacier Flexible lub Deep Archive są również całkowicie niekompatybilne z jakimkolwiek obciążeniem, które oczekuje synchronicznego odczytu — użytkownik czekający na odpowiedź HTTP GET nie może tolerować SLA odczytu wynoszącego od minut do 12 godzin. Glacier Instant Retrieval to jedyna warstwa Glacier kompatybilna z natychmiastowym dostępem.

Zasady cyklu życia i obsługa wersji

Konfiguracja cyklu życia to deklaratywny plik JSON/YAML dołączony do bucketa, który przenosi lub wygasza obiekty na podstawie ich wieku, tagu lub prefiksu. Przeniesienia są oceniane raz dziennie i uruchamiane dopiero po osiągnięciu określonego wieku — przeniesienie z Days: 30 oznacza, że przez pierwsze 30 dni obowiązują stawki klasy Standard. Przeniesienia muszą następować do coraz „zimniejszych” warstw, a obiekty mniejsze niż 128 KB nie są przenoszone ze Standard do IA, ponieważ narzut na pojedynczy obiekt przewyższa oszczędności; najpierw należy skonsolidować małe obiekty za pomocą tar/zip lub S3 Batch Operations.

Kanononiczna zasada dla obciążenia, w którym dane są „gorące” przez 30 dni, a następnie „zimne”, wymagające natychmiastowego dostępu przez cały czas, przechowywane przez cztery lata, z zachowaniem odpowiedniej higieny:

Rules:
  - ID: archive-and-clean
    Status: Enabled
    Transitions:
      - Days: 30
        StorageClass: STANDARD_IA
      - Days: 180
        StorageClass: DEEP_ARCHIVE
    NoncurrentVersionTransitions:
      - NoncurrentDays: 30
        StorageClass: GLACIER
    NoncurrentVersionExpiration:
      NoncurrentDays: 365
    Expiration:
      Days: 1460
    AbortIncompleteMultipartUpload:
      DaysAfterInitiation: 7

Częsta pułapka związana z obsługą wersji: w buckecie z włączonym wersjonowaniem, zasada cyklu życia, która wygasza bieżące obiekty, jedynie wstawia znaczniki usunięcia (delete markers); poprzednie wersje gromadzą się po cichu i nadal generują koszty. Wersje niebieżące wymagają własnych, jawnie zdefiniowanych reguł NoncurrentVersionTransitions i NoncurrentVersionExpiration. Podobnie, zawsze należy dołączać regułę AbortIncompleteMultipartUpload — osierocone części wieloczęściowego przesyłania są niewidoczne na liście w konsoli i generują koszty przechowywania w nieskończoność.

Dla mieszanych wzorców — na przykład telemetria IoT, która jest „gorąca” na potrzeby treningu ML przez pierwszy miesiąc, następnie odpytywana kwartalnie przez rok, a na końcu archiwizowana — właściwym rozwiązaniem jest S3 Intelligent-Tiering na pierwszy rok (pozwalając tej klasie na automatyczną optymalizację między okresami intensywnego treningu a dniami bezczynności), a następnie zaplanowane przeniesienie do Deep Archive po 365 dniach.

Wersjonowanie, MFA Delete i Object Lock

Po włączeniu, wersjonowanie może być jedynie zawieszone; nie można go wyłączyć. Każda operacja PUT tworzy nowy identyfikator wersji; DELETE wstawia znacznik usunięcia (delete marker) zamiast usuwać dane. Wersjonowanie chroni przed przypadkowym nadpisaniem, ale nie jest niezmiennością (immutability): każdy podmiot (principal) z uprawnieniem s3:DeleteObjectVersion może trwale usunąć określoną wersję. MFA Delete dodaje wymóg, aby konto root przedstawiło token MFA w celu trwałego usunięcia wersji lub zmiany stanu wersjonowania — zamyka to lukę przypadkowego usunięcia dla cennych bucketów, ale nadal nie zapobiega zniszczeniu danych przez upoważnionego aktora.

Prawdziwa niezmienność wymaga S3 Object Lock, który z kolei wymaga wersjonowania i generalnie musi być włączony podczas tworzenia bucketa. Posiada dwa tryby, które są często mylone:

Retencję można zastosować dla pojedynczego obiektu (Retain-Until-Date) lub poprzez Legal Hold, który nie ma daty wygaśnięcia. Dla dokumentacji księgowej wymagającej jednego roku w warstwie ‘hot’, dziewięciu lat w archiwum i braku możliwości usunięcia przez dziesięć lat, prawidłowym wzorcem jest Object Lock w trybie Compliance z dziesięcioletnią retencją, połączony z przejściem cyklu życia (lifecycle transition) do Deep Archive po 365 dniach. Tryb Governance nie jest akceptowalnym substytutem dla wymogów prawnych — regulator nie zaakceptuje wyjaśnienia „ktoś z uprawnieniami mógł to usunąć” jako niezmienności.

Aby zastosować retencję do istniejącego zbioru plików PDF w jednym zadaniu, użyj S3 Batch Operations sterowanego przez manifest S3 Inventory. Batch Operations to zarządzalna odpowiedź na mutacje na dużą skalę — retencja, tagowanie, ponowne szyfrowanie przez PUT-copy, wywoływanie funkcji Lambda — na miliardach kluczy; ręcznie pisane skrypty iteracyjne nie są właściwym wzorcem.

Szyfrowanie: SSE-S3, SSE-KMS i Bucket Keys

Każdy bucket ma domyślne szyfrowanie. SSE-S3 (AES-256, klucze zarządzane przez S3) jest darmowe i nie wymaga administracji kluczami. SSE-KMS używa klucza głównego klienta (customer master key) z KMS, co umożliwia ścieżki audytu w CloudTrail dla każdego klucza, polityki dostępu do kluczy oparte na IAM oraz kontrolę rotacji kluczy — kosztem opłat za API KMS i, co ważniejsze, dławienia żądań (throttling) do KMS, które może stać się wąskim gardłem dla obciążeń o wysokiej przepustowości odczytu. Wybierz SSE-KMS, gdy faktycznie potrzebujesz tych mechanizmów kontroli (atestacja regulacyjna, podział obowiązków, udostępnianie kluczy między kontami). Ustawianie domyślnie SSE-KMS „na wszelki wypadek” dodaje niepotrzebne koszty i złożoność, gdy SSE-S3 spełnia wymagania.

S3 Bucket Keys rozwiązują problem kosztów żądań do KMS przy użyciu SSE-KMS. S3 generuje krótkotrwały klucz na poziomie bucketa z klucza CMK i lokalnie wyprowadza klucze danych dla poszczególnych obiektów, unikając wywołania GenerateDataKey/Decrypt w KMS dla każdego obiektu i redukując koszty żądań do KMS nawet o 99%:

"ServerSideEncryptionConfiguration": {
  "Rules": [{
    "ApplyServerSideEncryptionByDefault": {
      "SSEAlgorithm": "aws:kms",
      "KMSMasterKeyID": "arn:aws:kms:..."
    },
    "BucketKeyEnabled": true
  }]
}

Przełączenie się na SSE-S3 w celu „uniknięcia kosztów KMS” jest niewłaściwym obejściem, gdy wymagania narzucają użycie KMS — Bucket Keys spełniają zarówno cele zgodności, jak i kosztowe, bez rezygnacji z KMS.

Włączenie domyślnego szyfrowania bucketa zapewnia, że wszystkie przyszłe uploady są szyfrowane (niezaszyfrowane operacje PUT są transparentnie szyfrowane). Aby wprost odrzucać niezaszyfrowane operacje PUT, należy zablokować zapisy, którym brakuje nagłówka:

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::my-bucket/*",
  "Condition": {
    "StringNotEquals": {
      "s3:x-amz-server-side-encryption": "AES256"
    }
  }
}

Domyślne szyfrowanie nie ma wpływu na istniejące, niezaszyfrowane obiekty. Zaszyfruj je ponownie za pomocą S3 Inventory + Batch Operations, uruchamiając zadanie Copy, które nadpisuje każdy klucz w miejscu — jest to standardowy wzorzec masowego ponownego szyfrowania.

Doraźne szyfrowanie po stronie klienta (client-side) jest gorsze niż domyślne szyfrowanie z KMS: rozprasza zarządzanie kluczami po zespołach aplikacyjnych, nie może być centralnie audytowane przez zdarzenia KMS w CloudTrail i nie może wykorzystywać Bucket Keys.

Replikacja międzyregionalna i klucze wieloregionalne KMS

Cross-Region Replication (CRR) asynchronicznie kopiuje obiekty do bucketa w innym Regionie w celach zgodności, odtwarzania po awarii (DR) lub zmniejszenia opóźnień (latency). Same-Region Replication (SRR) służy do separacji w celach zgodności, agregacji logów i kopiowania między kontami. Oba mechanizmy wymagają włączonego wersjonowania na buckecie źródłowym i docelowym oraz roli IAM, którą przyjmuje bucket źródłowy. CRR to niewymagające dużego wysiłku rozwiązanie, gdy bucket musi być lustrzaną kopią w innym Regionie — tworzenie skryptów z aws s3 sync, podpinanie funkcji Lambda pod zdarzenia ObjectCreated lub uruchamianie zaplanowanych zadań kopiowania wsadowego wprowadza dodatkowy narzut operacyjny, warunki wyścigu (race conditions) i ciche awarie. Ani CRR, ani SRR domyślnie nie replikują istniejących obiektów; do uzupełnienia danych historycznych (backfill) użyj S3 Batch Replication.

Interakcje z szyfrowaniem to obszar, w którym projekty często zawodzą:

• Obiekty z SSE-S3 replikują się transparentnie.
• Obiekty z SSE-KMS nie są domyślnie replikowane — musisz jawnie wyrazić na to zgodę, określić docelowy klucz KMS w Regionie docelowym i nadać roli replikacji uprawnienie kms:Decrypt do klucza źródłowego oraz kms:Encrypt do klucza docelowego. Klucz jednorregionalny (single-Region) nie może szyfrować obiektów w innym Regionie.
• Obiekty szyfrowane po stronie klienta replikują się jako nieprzezroczysty szyfrogram (ciphertext); Region docelowy nic nie zyskuje, chyba że materiał klucza klienta jest tam dostępny.

Historyczne trudności związane z zarządzaniem dwoma niezależnymi kluczami CMK zostały rozwiązane przez klucze wieloregionalne AWS KMS (multi-Region keys), które udostępniają ten sam materiał klucza i identyfikator klucza (z prefiksem Regionu) w wielu Regionach. Zreplikowany obiekt może być następnie odszyfrowany w Regionie docelowym bez wywołań KMS między regionami i bez ponownego opakowywania (re-wrapping) klucza danych. Jest to kanoniczny wzorzec dla szyfrowanych, replikowanych bucketów, które muszą pozostać użyteczne w przypadku awarii regionalnej (Regional failover).

Udostępnianie snapshotów i obiektów między kontami przy użyciu klucza KMS zarządzanego przez klienta (customer-managed) wymaga, aby podmioty (principals) na koncie docelowym posiadały uprawnienia kms:Decrypt, kms:CreateGrant, kms:DescribeKey i kms:ReEncrypt* do klucza źródłowego za pośrednictwem polityki klucza (key policy), a także odpowiadające im uprawnienia IAM. Klucze zarządzane przez AWS (np. aws/ebs, aws/s3) nie mogą być udostępniane między kontami, dlatego klucze zarządzane przez klienta są obowiązkowe w przepływach pracy obejmujących wiele kont.

Block Public Access i Ograniczanie Dostępu do CloudFront

S3 Block Public Access (BPA) ma cztery ustawienia — blokuj nowe publiczne listy ACL, ignoruj istniejące publiczne listy ACL, blokuj nowe publiczne polityki zasobnika, ograniczaj publiczne polityki zasobnika — konfigurowalne na poziomie zasobnika i, co ważniejsze, na poziomie konta. BPA na poziomie konta ma pierwszeństwo przed każdą polityką zasobnika, która przyznawałaby publiczny dostęp, i jest właściwym mechanizmem kontrolnym dla zasady „żaden obiekt na tym koncie nie może być publiczny”. Polityki na poziomie zasobnika same w sobie są kruche: nowy zasobnik może zostać uruchomiony bez polityki; BPA na poziomie konta zapewnia domyślne bezpieczeństwo (fail-closed).

Aby uniemożliwić administratorowi na koncie członkowskim wyłączenie BPA, zastosuj warstwę Service Control Policy na poziomie jednostki organizacyjnej (OU) lub roota w Organizations:

{
  "Effect": "Deny",
  "Action": "s3:PutAccountPublicAccessBlock",
  "Resource": "*",
  "Condition": {
    "Bool": { "aws:PrincipalIsAWSService": "false" }
  }
}

Aby udostępniać zawartość S3 wyłącznie przez CloudFront, dołącz Origin Access Control (OAC) — nowoczesny zamiennik przestarzałego OAI — do dystrybucji i ogranicz politykę zasobnika do ARN dystrybucji:

{
  "Effect": "Allow",
  "Principal": { "Service": "cloudfront.amazonaws.com" },
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket/*",
  "Condition": {
    "StringEquals": {
      "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/E123"
    }
  }
}

BPA pozostaje włączone na zasobniku. Dla ograniczonego czasowo dostępu do prywatnych obiektów przez określonego użytkownika (wygasanie wysyłania/pobierania), wygeneruj presigned URL, którego osadzony podpis dziedziczy uprawnienia podmiotu podpisującego (signing principal).

Prywatne Ścieżki Sieciowe: Gateway Endpoints

Ruch z EC2 do S3 wewnątrz VPC nie używa automatycznie prywatnej sieci szkieletowej AWS. Bez konfiguracji, wywołania API S3 są rozwiązywane do publicznych punktów końcowych i przechodzą przez bramę internetową lub bramę NAT, co generuje opłaty za przetwarzanie danych NAT i naraża ruch na dostęp z internetu. Bramkowy punkt końcowy VPC (gateway VPC endpoint) dla S3 (i DynamoDB) jest darmowy, dodawany jako trasa z listą prefiksów w określonych tabelach routingu i utrzymuje ruch w sieci AWS. Istnieją również interfejsowe punkty końcowe (PrivateLink) dla S3, które są płatne i przydatne, gdy dostęp pochodzi ze środowiska on-premises przez Direct Connect. Połącz punkt końcowy z warunkiem aws:SourceVpce w polityce zasobnika, aby wymusić dostęp do zasobnika tylko z zatwierdzonych punktów końcowych VPC — jest to standardowy wzorzec dla obciążeń podlegających regulacjom.

Object Lambda do Transformacji w Locie

S3 Object Lambda wstawia funkcję Lambda w ścieżkę żądań GET/HEAD/LIST, dzięki czemu obiekt zwracany do klienta jest transformowany w czasie odczytu. Pozwala to uniknąć duplikowania danych dla każdego wariantu (zredagowany, o zmienionym rozmiarze, przeformatowany) i utrzymuje jedno źródło prawdy w bazowym zasobniku. Typowe zastosowania: redakcja danych PII dla analityków w porównaniu z pełnymi danymi dla audytorów, dodawanie znaków wodnych do obrazów dla poszczególnych użytkowników, konwersja XML na JSON dla starszych klientów. Polityki IAM i zasobnika nadal kontrolują dostęp do bazowego obiektu; funkcja Lambda widzi tylko to, na co pozwala jej rola wykonawcza (execution role).

Powiadomienia o Zdarzeniach

S3 emituje zdarzenia (s3:ObjectCreated:*, s3:ObjectRemoved:*, zdarzenia replikacji i cyklu życia) do Lambda, SQS, SNS lub EventBridge. EventBridge jest preferowany, gdy potrzebujesz wielu celów, filtrowania na podstawie metadanych obiektu lub routingu między kontami; bezpośrednie powiadomienia są prostsze i tańsze dla potoków z jednym celem, takich jak generowanie miniatur po przesłaniu pliku. Powiadomienia mają gwarancję dostarczenia co najmniej raz (at-least-once), więc konsumenci muszą być idempotentni.

Optymalizacja Przepustowości: Multipart Upload i Transfer Acceleration

Dla obiektów powyżej 100 MB najlepszą praktyką jest multipart upload; powyżej 5 GB jest on obowiązkowy. Części są przesyłane równolegle, nieudane części są ponawiane niezależnie, a przepustowość skaluje się wraz ze współbieżnością. Żądania GET z zakresem bajtów (byte-range GETs) dają równoważną równoległość przy pobieraniu. Jak wspomniano, zawsze dołączaj regułę cyklu życia AbortIncompleteMultipartUpload, aby uniknąć naliczania opłat za osierocone części.

S3 Transfer Acceleration kieruje wysyłanie plików przez najbliższą lokalizację krawędziową CloudFront, korzystając z sieci szkieletowej AWS — używaj tej funkcji dla globalnie rozproszonych klientów przesyłających dane do jednego zasobnika. Do pobierania plików, umieść CloudFront przed S3, aby buforować zawartość w lokalizacjach krawędziowych. Transfer Acceleration jest zorientowany na wysyłanie; CloudFront jest zorientowany na pobieranie; rozwiązują one powiązane, ale odrębne problemy.

EBS: Rodzaje woluminów, szyfrowanie i migawki

Woluminy EBS to urządzenia blokowe o zasięgu Strefy Dostępności (AZ), podłączane do pojedynczej instancji EC2. gp3 to domyślny dysk SSD ogólnego przeznaczenia; jego kluczową przewagą nad gp2 jest to, że IOPS (do 16 000) i przepustowość (do 1000 MiB/s) są provisionowane niezależnie od pojemności, co eliminuje antywzorzec gp2 polegający na nadmiarowym provisionowaniu przestrzeni dyskowej tylko w celu osiągnięcia docelowej wydajności. io2 Block Express dostarcza do 256 000 IOPS z opóźnieniem poniżej milisekundy dla baz danych wrażliwych na opóźnienia. st1 i sc1 to dyski HDD przeznaczone dla obciążeń sekwencyjnych zorientowanych na przepustowość oraz dla danych zimnych (cold workloads). Opcja Multi-Attach dla io1/io2 istnieje, ale jest ograniczona do 16 instancji w tej samej Strefie Dostępności (AZ), które korzystają z systemu plików obsługującego klastry — jest to wąski wyjątek, a nie ogólny wzorzec „współdzielonego EBS”. Próba szerokiego podłączania woluminu EBS do wielu instancji (np. za load balancerem) jest błędem kategorialnym, który prowadzi dokładnie do objawu „niektóre dokumenty są widoczne po odświeżeniu, a inne nie”, ponieważ każdy wolumin jest prywatnym urządzeniem blokowym.

Woluminy EBS są szyfrowane w spoczynku (at rest) za pomocą AES-256 przy użyciu kluczy danych opakowanych przez KMS. Szyfrowanie jest transparentne — nie ma wpływu na wydajność ani nie wymaga zmian w aplikacji. Gdy wolumin jest zaszyfrowany, pochodne migawki i woluminy również są szyfrowane; nie można cofnąć szyfrowania w miejscu. Włącz domyślne szyfrowanie EBS dla każdego Regionu, aby każdy nowy wolumin i migawka były szyfrowane, niezależnie od tego, czy deweloper o tym pamięta:

aws ec2 enable-ebs-encryption-by-default --region us-east-1
aws ec2 modify-ebs-default-kms-key-id \
  --kms-key-id arn:aws:kms:us-east-1:111122223333:key/abcd-...

Istniejące niezaszyfrowane woluminy nie są szyfrowane wstecznie — naprawa wymaga wykonania migawki, skopiowania jej z włączonym szyfrowaniem i utworzenia nowego woluminu z zaszyfrowanej migawki.

Migawki to przyrostowe kopie zapasowe na poziomie bloków, przechowywane na infrastrukturze zarządzanej przez S3 — ale nie są darmowe (płacisz za przechowywane zmienione bloki), nie znikają po usunięciu woluminu źródłowego i nie są usuwane, gdy obraz AMI, który się do nich odwołuje, zostanie wyrejestrowany. Przenoś je do warstwy EBS Snapshots Archive (75% taniej, przywracanie w 24–72 godziny) za pomocą aws ec2 modify-snapshot-tier, Amazon Data Lifecycle Manager (DLM) lub AWS Backup. Fast Snapshot Restore (FSR) wstępnie „rozgrzewa” migawkę w określonych Strefach Dostępności (AZ), aby instancje z niej uruchamiane od razu dostarczały pełną wydajność — włącz tę opcję dla obrazów AMI używanych przez grupy autoskalujące, które muszą obsługiwać szybkie skalowanie w poziomie.

Recycle Bin (Kosz) przechwytuje usunięte migawki EBS i obrazy AMI, przechowując je przez określony czas (od 1 dnia do 1 roku), w którym można je przywrócić. Bez niego usunięcie migawki jest natychmiastowe i trwałe:

aws rbin create-rule \
  --retention-period RetentionPeriodValue=30,RetentionPeriodUnit=DAYS \
  --resource-type EBS_SNAPSHOT \
  --description "30-day snapshot recovery"

Poleganie wyłącznie na codziennych migawkach EBS w celu długoterminowego przechowywania danych na potrzeby zgodności (compliance) to częsty błąd architektoniczny — ceny migawek są bliższe przechowywaniu typu „warm”, a ich archiwizacja wymaga jawnych działań.

Amazon EFS: Współdzielony POSIX dla flot Linux

EFS to w pełni zarządzany, elastyczny, zgodny z POSIX system plików NFSv4.1, który można jednocześnie zamontować z tysięcy klientów EC2, ECS, EKS lub Lambda w wielu Strefach Dostępności (AZ) w jednym Regionie, a także z hostów on-premises za pośrednictwem Direct Connect lub VPN. Jego definiującą cechą jest to, że ten sam system plików, z identycznymi uchwytami plików (file handles) i semantyką na poziomie bajtów, jest widoczny dla każdego klienta w tym samym czasie. Dlatego EFS jest właściwym rozwiązaniem, gdy flota instancji Linux za load balancerem musi współdzielić wspólny zbiór plików — np. pliki przesyłane przez użytkowników, pliki konfiguracyjne, czy współdzielone katalogi domowe.

Punkty montowania (mount targets) znajdują się w każdej podsieci w Strefie Dostępności (AZ), którą skonfigurujesz. Narzędzie pomocnicze amazon-efs-utils umożliwia szyfrowanie TLS w tranzycie oraz autoryzację montowania za pomocą IAM:

sudo mount -t efs -o tls,iam fs-0123456789abcdef0:/ /mnt/shared

Klasy pamięci masowej EFS obejmują dwa wymiary. Zarządzanie cyklem życia (Lifecycle management) przenosi pliki, do których nie było dostępu przez 7–90 dni, z klasy Standard do Infrequent Access, a opcjonalnie do Archive, obniżając koszt przechowywania nawet o 92%; Intelligent-Tiering przywraca je po uzyskaniu dostępu. Klasy One Zone przechowują dane w jednej Strefie Dostępności (AZ) za cenę niższą o ~47% — jest to odpowiednie dla środowisk deweloperskich/testowych lub danych odtwarzalnych, ale nigdy dla danych, których utrata podczas awarii AZ jest niedopuszczalna. Optymalizacją kosztów dla obciążenia już działającego na EFS Standard-IA jest przejście na EFS One Zone-IA bez żadnych zmian w aplikacji.

Wydajność ma dwa niezależne pokrętła. Tryb wydajności (Performance mode) (ustawiany przy tworzeniu): General Purpose ma najniższe opóźnienia i jest odpowiedni dla obsługi stron internetowych z dużą ilością metadanych; Max I/O to przestarzała opcja zastąpiona przez Elastic. Tryb przepustowości (Throughput mode): Bursting skaluje się wraz z rozmiarem (50 KB/s na GB jako linia bazowa, z kredytami burst, gdy zużycie jest poniżej linii bazowej), Provisioned pozwala płacić za stałą przepustowość w MB/s niezależnie od rozmiaru, a Elastic — obecny domyślny tryb — automatycznie skaluje się do 10+ GB/s bez konieczności planowania pojemności. Mały system plików pod stałym obciążeniem może wyczerpać kredyty burst i zostać zdławiony do niskiej linii bazowej, dlatego obciążenia o dużej intensywności I/O i małej powierzchni dyskowej muszą używać trybu Elastic lub Provisioned.

EFS nie jest substytutem dla pamięci masowej blokowej o wysokiej liczbie IOPS. Każda operacja I/O w EFS to wywołanie NFS RPC przez sieć, więc obciążenia typu log transakcyjny, z jednym procesem piszącym i wymagające opóźnień poniżej milisekundy, powinny być umieszczane na EBS io2 Block Express — pojedynczy wolumin dostarcza 256 000 IOPS z opóźnieniem poniżej milisekundy, czego EFS nie jest w stanie dorównać w przeliczeniu na pojedynczą operację. EFS jest również rażąco drogi dla danych zimnych w porównaniu z Deep Archive; przechowywanie danych na potrzeby zgodności (compliance) na EFS „bo tak jest łatwiej” jest nie do obrony.

FSx: Windows, Lustre, ONTAP, OpenZFS

FSx to rodzina zarządzanych systemów plików, dobieranych w zależności od protokołu i obciążenia roboczego:

FSx for Windows File Server dostarcza natywny protokół SMB 2.0/3.1.1 z listami ACL NTFS, przestrzeniami nazw DFS, kopiami w tle (shadow copies) i Kerberos przez Active Directory. Wdrożenie Multi-AZ umieszcza aktywny serwer plików w jednej strefie dostępności (AZ) z synchronicznie replikowanym serwerem zapasowym (standby) w innej, udostępniając pojedynczą nazwę DNS do przełączania awaryjnego (failover). Integracja z AD jest obowiązkowa: FSx musi dołączyć do AWS Managed Microsoft AD lub osiągalnego, samodzielnie zarządzanego AD, a klienci uwierzytelniają się jako użytkownicy domenowi na podstawie domenowych identyfikatorów SID. Pominięcie AD lub skierowanie klientów na system plików w niezaufanym lesie (forest) bez relacji zaufania między lasami (cross-forest trust) powoduje klasyczny objaw „odmowa dostępu, mimo że udział jest widoczny”. FSx for Windows to idealny cel dla migracji typu lift-and-shift udziałów plików Windows.

FSx for Lustre to równoległy system plików POSIX przeznaczony do HPC, trenowania ML, EDA i genomiki — obsługuje tysiące klientów, przepustowość setek GB/s i metadane z opóźnieniami poniżej milisekundy. Jego kluczową funkcją w AWS jest powiązanie repozytorium danych (data repository association) z S3: klucze obiektów pojawiają się jako pliki w przestrzeni nazw Lustre i są ładowane leniwie (lazily loaded) przy pierwszym dostępie (lub ładowane z góry za pomocą hsm_restore); nowe/zmodyfikowane pliki są eksportowane z powrotem do S3 zgodnie z harmonogramem lub na żądanie. Kanononiczny wzorzec dla HPC wygląda następująco:

1. Skopiuj zbiory danych on-premise do S3 (za pomocą DataSync lub Storage Gateway).
2. Utwórz system plików Lustre połączony z tym bucketem.
3. Zamontuj na wszystkich instancjach roboczych Spot; odczytuj dane wejściowe i zapisuj wyjściowe z pełną prędkością (line rate).
4. Wyeksportuj wyniki do S3, które pozostaje trwałym, długoterminowym repozytorium.
5. Usuń system plików Lustre po zakończeniu zadania.

Wdrożenia Lustre typu Scratch nie mają replikacji i tracą dane w przypadku awarii sprzętu — są najtańsze i najszybsze, odpowiednie dla tymczasowych danych zadań. Wdrożenia typu Persistent replikują dane w obrębie jednej strefy AZ w celu zapewnienia wyższej trwałości. Przepustowość jest alokowana w MB/s na TiB (50/125/250/500/1000), co oddziela pojemność od wydajności.

FSx for NetApp ONTAP to odpowiedź wieloprotokołowa: NFS, SMB i iSCSI jednocześnie na tych samych danych, z migawkami (snapshots), replikacją SnapMirror, klonami FlexClone i deduplikacją. Wybierz ONTAP, gdy konsolidujesz mieszane udziały Linux NFS i Windows SMB wymagające dostępu międzyprotokołowego z redundancją Multi-AZ, lub gdy migrujesz z lokalnego środowiska NetApp on-premise. FSx for OpenZFS wypełnia niszę dla obciążeń linuksowych, które potrzebują funkcji ZFS (migawki, klony) przez NFS. Nie myl wieloprotokołowej siły ONTAP z innymi wariantami.

Zły wybór prowadzi do prostej porażki: EBS dla współdzielonego obciążenia, EFS dla udziału Windows SMB czy Lustre dla zintegrowanego z AD udziału Windows to wszystko niedopasowania — w pierwszej kolejności dopasuj protokół i wzorzec dostępu.

Storage Gateway: Dostęp hybrydowy

Storage Gateway prezentuje pamięć masową w chmurze tak, jakby była lokalna. Różni się to od DataSync, który przenosi dane.

Dla aplikacji renderingowej, która przeniosła swoją bibliotekę mediów do S3, ale nadal potrzebuje niskoopoźnieniowych odczytów on-premise, odpowiednia będzie S3 File Gateway — dostęp NFS/SMB, lokalna pamięć podręczna, zimne obiekty pobierane z S3 na żądanie. FSx File Gateway to rozwiązanie dla oddziałów firmy: pamięć podręczna SMB o prędkości sieci LAN dla centralnego udziału FSx w chmurze, a nie rozwiązanie do współdzielonego dostępu pomiędzy instancjami EC2 (które powinny montować FSx bezpośrednio). Volume Gateway stosuje się, gdy obciążenie robocze używa blokowego protokołu iSCSI zamiast semantyki plików. Tape Gateway zastępuje fizyczne biblioteki taśmowe w ramach istniejącego oprogramowania do tworzenia kopii zapasowych.

Transfer i migracja danych

AWS DataSync to oparta na agencie usługa do migracji online dla NFS, SMB, HDFS i magazynów obiektów do S3, EFS lub FSx — do 10 razy szybsza niż narzędzia open-source, z szyfrowaniem, weryfikacją integralności, harmonogramowaniem i zachowaniem metadanych POSIX oraz list ACL NTFS. W przypadku migracji SMB na dużą skalę, z milionami małych plików i głębokimi hierarchiami, rozwiązaniem o najmniejszym narzucie jest DataSync do FSx for Windows: protokół SMB jest zachowany, listy ACL/znaczniki czasu pozostają nienaruszone, przepustowość dla małych plików jest obsługiwana przez transfery równoległe, bez zmian w aplikacji. Migracja takiego zbioru danych bezpośrednio do S3 to pułapka — magazyn obiektów słabo radzi sobie z listowaniem małych plików w głębokich prefiksach, a klienci SMB nie mogą montować bucketów.

AWS Snow Family to fizyczne urządzenia do transferu offline: Snowcone (do 8 TB, wzmocniony do zastosowań brzegowych), Snowball Edge (do ~80 TB użytecznej pojemności, z opcjami obliczeniowymi) i Snowmobile (skala eksabajtowa). Zasada ogólna: jeśli transfer sieciowy trwałby dłużej niż tydzień, Snowball jest tańszy i szybszy.

AWS Transfer Family udostępnia protokoły SFTP, FTPS, FTP i AS2, których zapleczem jest S3 lub EFS — to właściwa odpowiedź, gdy partnerzy zewnętrzni muszą nadal używać standardowych protokołów transferu plików.

AWS Backup, kopia międzyregionowa i Vault Lock

AWS Backup centralizuje zasady dla usług EBS, EFS, FSx, RDS, DynamoDB, S3 i innych. Plan kopii zapasowych definiuje harmonogram, retencję w warstwie ciepłej (warm), przeniesienie do warstwy zimnej (cold storage) oraz akcje kopiowania między regionami i kontami:

BackupPlan:
  Rules:
    - RuleName: DailyWithDRCopy
      TargetBackupVault: prod-vault
      ScheduleExpression: "cron(0 5 * * ? *)"
      Lifecycle:
        MoveToColdStorageAfterDays: 30
        DeleteAfterDays: 2555        # 7 years
      CopyActions:
        - DestinationBackupVaultArn: arn:aws:backup:eu-west-1:...:backup-vault:dr-vault
          Lifecycle:
            MoveToColdStorageAfterDays: 30
            DeleteAfterDays: 2555

Przeniesienie do warstwy zimnej wymaga co najmniej 90 dni retencji w warstwie ciepłej oraz co najmniej 90 dni w warstwie zimnej; błędnie skonfigurowane cykle życia są odrzucane. Dla rzeczywistej, wieloletniej retencji wymaganej przepisami, połącz go z AWS Backup Vault Lock (WORM), który uniemożliwia nawet administratorom skracanie okresu retencji — spełniając wymogi SEC 17a-4 i podobnych regulacji. Kopia międzyregionowa odpowiada na potrzeby regionalnego DR (Disaster Recovery); kopia międzykontowa adresuje scenariusze ransomware i zagrożeń wewnętrznych poprzez izolowanie kopii zapasowych od zasięgu rażenia (blast radius) konta produkcyjnego.

Ściąga do wyboru usług

← Architektury bezserwerowe i sterowane zdarzeniami · Wszystkie domeny · Transfer i migracja danych →

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

Przeglądaj Amazon →