Amazon CLF-C02: Podstawowe usługi obliczeniowe — Przewodnik do nauki

By Laurynas Brazys · 29 July 2026 · #amazon #clf-c02 #certification #exam-prep #study-guide

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

Podstawowe koncepcje EC2, modele zakupowe i wzorce dostępności

Amazon EC2 to fundamentalna usługa obliczeniowa IaaS: wybierasz typy instancji pod kątem procesora, pamięci, pamięci masowej i sieci, uruchamiasz systemy operacyjne, które kontrolujesz, i opcjonalnie dołączasz woluminy Elastic Block Store (EBS) w celu uzyskania trwałej pamięci blokowej. Projektowanie pod kątem dostępności wymaga umieszczania obciążeń w wielu Strefach Dostępności (AZ) oraz, w stosownych przypadkach, w wielu Regionach. W przypadku zarządzanych relacyjnych baz danych użyj Amazon RDS Multi‑AZ w celu uzyskania synchronicznej repliki standby i automatycznego przełączania awaryjnego (failover); w celu ekstremalnego skalowania odczytu lub odtwarzania po awarii w wielu regionach (disaster recovery), rozważ Amazon Aurora Global Database. Wybór modelu zakupu instancji wpływa na kompromis między kosztem a odpornością: On-Demand zapewnia elastyczność bez zobowiązań; Reserved Instances lub Compute Savings Plans dają największe przewidywalne oszczędności przy stałym, ciągłym użytkowaniu; Spot Instances oferują najniższą cenę dla obciążeń odpornych na błędy i przerwania. Częste pułapki to poleganie na jednej Strefie Dostępności, osadzanie długoterminowych poświadczeń na instancjach oraz nadmiarowe alokowanie zasobów „na wszelki wypadek”. Używaj grup Auto Scaling z mechanizmami sprawdzania kondycji (health checks), hakami cyklu życia (lifecycle hooks) i mieszanymi politykami instancji (On-Demand + Spot), aby zrównoważyć koszty i dostępność. Decyduj między Reserved/Savings Plans a Spot, oceniając wymagany czas działania (uptime), tolerancję na przerwania i dokładność prognozowania; wybieraj między Multi‑AZ a multi‑Region na podstawie wymagań RTO/RPO i ograniczeń dotyczących opóźnień międzyregionalnych.

Zarządzane usługi kontenerowe, wsadowe i bezserwerowe: kryteria decyzyjne

AWS oferuje wiele zarządzanych platform obliczeniowych, aby dopasować je do celów architektonicznych. AWS Lambda umożliwia tworzenie sterowanych zdarzeniami, bezserwerowych funkcji z automatycznym skalowaniem i rozliczaniem co do milisekundy, co jest najlepsze dla bezstanowych, krótkotrwałych zadań. Amazon ECS zapewnia zarządzaną opcję orkiestracji kontenerów, która integruje się z Fargate w celu bezserwerowego uruchamiania kontenerów lub z EC2 dla większej kontroli. Amazon EKS uruchamia Kubernetes jako zarządzaną płaszczyznę sterowania (control plane) dla zespołów standaryzujących swoje rozwiązania na Kubernetes, z węzłami roboczymi (worker nodes) w postaci EC2 lub Fargate. AWS Batch planuje i skaluje zadania obliczeniowe wsadowe (batch) na zasobach EC2 lub Spot, optymalizując przepustowość dla zadań o wysokiej wydajności lub dużej objętości. Elastic Beanstalk to platforma aplikacyjna do wdrażania aplikacji internetowych bez zarządzania podstawową infrastrukturą; abstrahuje konfigurację EC2, autoskalowania, ELB i RDS, umożliwiając szybsze wdrożenia typu lift-and-shift. Kluczowe kryteria decyzyjne obejmują umiejętności operacyjne (doświadczenie z Kubernetes sprzyja EKS), szybkość wdrożenia (Beanstalk), przewidywalność kosztów (Fargate upraszcza, ale może kosztować więcej) oraz charakterystykę obciążenia (Lambda dla krótkich, sterowanych zdarzeniami zadań; ECS/EKS dla długo działających usług). Unikaj pułapki wyboru opcji najbogatszej w funkcje, gdy prostsza usługa zarządzana (Lambda lub Fargate) zmniejszyłaby obciążenie operacyjne i zwiększyła zwinność.

Autoskalowanie, elastyczność i strategie optymalizacji kosztów

Elastyczność to zdolność do skalowania zasobów w górę i w dół w celu dopasowania do zapotrzebowania; autoskalowanie to mechanizm, który to umożliwia. Używaj grup Auto Scaling (ASG) dla EC2, aby dodawać lub usuwać instancje w oparciu o polityki śledzenia celu (target tracking), krokowe (step) lub predykcyjne. W przypadku kontenerów używaj autoskalowania ECS lub EKS dla zadań i klastrów, a dla funkcji Lambda korzystaj z wbudowanych mechanizmów kontroli współbieżności. Projektuj architekturę pod kątem bezstanowości i eksternalizuj stan do usług zarządzanych, takich jak Amazon RDS, DynamoDB, ElastiCache lub S3, aby instancje mogły być efemeryczne. Dobieraj odpowiedni rozmiar instancji (right-sizing) poprzez regularne przeglądy, używaj monitoringu (metryki i alarmy CloudWatch) i rozważ Savings Plans lub Reserved Instances dla stałego, bazowego obciążenia, umieszczając zmienne obciążenia na instancjach Spot. Modele cenowe do rozważenia:

On-Demand: brak zobowiązań, płatność za godzinę/sekundę.
Reserved Instances / Savings Plans: 1- lub 3-letnie zobowiązanie w zamian za znaczne zniżki.
Spot Instances: największe zniżki dla obciążeń, które mogą być przerywane.
Dedicated Hosts/Instances: fizyczna izolacja dla celów zgodności (compliance), wyższy koszt. Popularne pułapki to niedoszacowanie czasu rozgrzewania (warm-up) przy autoskalowaniu, niestosowanie haków cyklu życia (lifecycle hooks) do płynnego zamykania instancji (graceful shutdown) oraz nadużywanie instancji Spot dla stanowych, krytycznych obciążeń. Stosuj wdrożenia typu blue/green lub canary dla bezpiecznych wydań oraz polityki cyklu życia (lifecycle policies) do automatyzacji kontroli kosztów nieużywanych zasobów.

Bezpieczeństwo, zgodność i narzędzia operacyjne dla zasobów obliczeniowych

Bezpieczeństwo i operacje są fundamentalne dla zasobów obliczeniowych w AWS. Zgodnie z modelem współdzielonej odpowiedzialności, AWS zabezpiecza globalną infrastrukturę i usługi zarządzane, podczas gdy klienci są odpowiedzialni za system operacyjny gościa, konfigurację aplikacji, dane i uprawnienia IAM podczas korzystania z IaaS. Unikaj osadzania długoterminowych kluczy dostępu; zamiast tego dołączaj role IAM do instancji EC2 lub używaj ról IAM dla kont usług (IRSA) w EKS, a do rotacji i centralnego zarządzania sekretami wykorzystuj AWS Secrets Manager lub Systems Manager Parameter Store (SecureString). Do celów audytu i dochodzenia włącz AWS CloudTrail, aby rejestrować aktywność API na całym koncie, i używaj AWS Config do zapisywania konfiguracji zasobów. Używaj Amazon Macie do odkrywania i klasyfikowania wrażliwych danych w S3, a IAM Access Analyzer lub S3 Access Analyzer do znajdowania zasobów udostępnionych publicznie lub między kontami. Aby uzyskać dowody zgodności, użyj AWS Artifact do pobierania raportów z audytów. Widoczność operacyjną poprawiają VPC Flow Logs dla ruchu sieciowego, AWS Personal Health Dashboard dla zdarzeń specyficznych dla konta oraz Service Health Dashboard dla globalnego statusu usług. Częste błędy praktyków obejmują pozostawianie aktywnych kluczy na koncie root, niewłączanie MFA dla użytkownika root oraz brak centralizacji tożsamości za pomocą IAM Identity Center (dawniej AWS SSO) w celu logowania jednokrotnego (SSO) opartego na SAML do zewnętrznych aplikacji.

Praktyczny problem: Scenariusz użycia

Scenariusz: Firma Acme Analytics uruchamia aplikację do przetwarzania danych na EC2 w jednej strefie dostępności (AZ) na produkcyjnym koncie AWS. Mają zadania wsadowe, które co noc przetwarzają duże wolumeny danych i chcą obniżyć koszty, zapewnić szybsze odzyskiwanie po awarii strefy AZ oraz bezpiecznie zarządzać sekretami.

Wyzwanie: Zmniejszenie kosztów zasobów obliczeniowych przy jednoczesnym zapewnieniu nocnej przepustowości zadań wsadowych i poprawie dostępności w wielu strefach AZ, bez natychmiastowej potrzeby rearchitektury całej aplikacji.

Zalecane podejście:

Zmigruj workery wsadowe do środowiska obliczeniowego AWS Batch, używając polityki instancji mieszanych (Spot + On-Demand), aby obniżyć koszty przy zachowaniu bazowej wydajności.
Skonfiguruj AWS Batch do korzystania z wielu stref AZ i włącz mechanizm ponawiania prób (Retry/RetryStrategy) z kolejkami zadań rozłożonymi na różne strefy AZ w celu zwiększenia odporności.
Zastąp osadzone poświadczenia rolami IAM dla zadań EC2/Batch i przechowuj rotowane sekrety w AWS Secrets Manager; zintegruj z IAM w celu ich automatycznego pobierania.
Wdróż alarmy CloudWatch i polityki Auto Scaling dla minimalnej floty EC2 obsługującej pozostałe komponenty stanowe oraz włącz Cross‑AZ RDS Multi‑AZ, jeśli używana jest baza danych.

Uzasadnienie: Użycie zarządzanego przetwarzania wsadowego i instancji Spot zmniejsza koszty oraz narzut operacyjny, podczas gdy dystrybucja na wiele stref AZ i wykorzystanie IAM/Secrets Manager poprawiają dostępność i bezpieczeństwo — co jest zgodne z najlepszymi praktykami elastyczności, zasady najmniejszych uprawnień i zautomatyzowanej rotacji sekretów.

← Globalna infrastruktura AWS · Wszystkie domeny · Podstawowe usługi przechowywania danych →

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