Amazon SAA-C03: Moc obliczeniowa, automatyczne skalowanie i zarządzanie instancjami — 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.

Typy instancji EC2 i obrazy AMI

Wybór odpowiedniej rodziny instancji EC2 jest podstawą dobrze zaprojektowanej warstwy obliczeniowej, ponieważ rodzina, generacja i rozmiar wspólnie określają architekturę procesora, stosunek pamięci do vCPU, przepustowość sieci i dostępne akceleratory. Ogólnego przeznaczenia (M6i, M7g, seria T) pasują do zrównoważonych warstw webowych i mieszanych obciążeń. Zoptymalizowane pod kątem obliczeń (C7i, C7gn) sprawdzają się w symulacjach ograniczonych mocą procesora, kodowaniu, przetwarzaniu wsadowym i front-endach webowych. Zoptymalizowane pod kątem pamięci (R7i, X2idn) są przeznaczone dla baz danych in-memory i pamięci podręcznych. Zoptymalizowane pod kątem przechowywania danych (I4i, D3) są przeznaczone dla NoSQL, HDFS i hurtowni danych. Akcelerowane (P5, G5, Trn1, Inf) dostarczają procesory graficzne (GPU) lub wyspecjalizowane układy ML. Instancje Graviton (z sufiksem g) zazwyczaj zapewniają o 20–40% lepszy stosunek ceny do wydajności dla obciążeń skalowalnych horyzontalnie (scale-out), które kompilują się bezproblemowo na architekturę ARM64.

Rodzina T jest typu burstable i domyślnie działa w trybie standard, w którym kredyty CPU gromadzą się w stanie bezczynności i są zużywane podczas skoków wydajności (burst); po wyczerpaniu kredytów wydajność jest dławiona do poziomu bazowego. Dla obciążeń z nieprzewidywalnymi skokami – małe warstwy webowe, środowiska deweloperskie/testowe lub środowiska Elastic Beanstalk obsługujące front-end o zmiennym obciążeniu – instancje T w trybie unlimited pozwalają instancji pożyczać kredyty i naliczają niewielką dopłatę za każdą vCPU-godzinę nadwyżki, unikając dławienia wydajności odczuwalnego przez użytkownika. Dlatego problemy ze środowiskami Beanstalk, w których występuje krótkotrwałe nasycenie CPU, zazwyczaj rozwiązuje się przez włączenie trybu unlimited, a nie przez upgrade do droższej rodziny zoptymalizowanej pod kątem obliczeń. Ważne jest, aby rezerwować serię T dla autentycznie skokowych obciążeń o niskiej średniej: stałe wysokie użycie CPU w trybie standardowym wyczerpuje kredyty w ciągu kilku minut.

Skalowanie wertykalne (przejście na większy rozmiar w ramach tej samej rodziny) jest ograniczone przez największą dostępną instancję, wymusza przerwę w działaniu na czas zmiany, wprowadza pojedynczy punkt awarii (single point of failure) i nie pozwala na rozłożenie obciążenia na wiele Stref Dostępności. Gdy obciążenie znacznie się waha, prawidłowym rozwiązaniem jest skalowanie horyzontalne za pomocą grupy Auto Scaling.

Złote obrazy AMI (Golden AMI) zawierają kod aplikacji, środowisko uruchomieniowe i zależności w migawce głównego woluminu (root snapshot), co zapewnia szybkie i deterministyczne uruchamianie – kluczowe, gdy Auto Scaling reaguje na nagły wzrost obciążenia. Uruchamianie skryptów konfiguracyjnych (bootstrapping) za pomocą user-data przy każdym starcie instancji dodaje minuty opóźnienia dokładnie w najgorszym możliwym momencie.

Wybór pamięci masowej: Instance Store vs EBS, migawki i Fast Snapshot Restore

Instancje oferują dwa rodzaje podłoża pamięci masowej: instance store (efemeryczna pamięć NVMe podłączona do fizycznego hosta) oraz Amazon EBS (sieciowa pamięć blokowa). Instance store zapewnia najniższe możliwe opóźnienia, ale jego dane są niszczone podczas zatrzymania, hibernacji, zakończenia działania instancji lub w przypadku awarii sprzętu. Traktowanie go jako trwałej pamięci masowej jest częstym i niebezpiecznym błędem – nadaje się on wyłącznie jako przestrzeń tymczasowa (scratch space), na bufory, pamięć podręczną lub dla replikowanych danych, takich jak węzeł danych HDFS, którego repliki istnieją na innych węzłach. Trwałe dane powinny być przechowywane na EBS, z kopiami zapasowymi w postaci migawek (snapshotów) przechowywanych w S3.

Migawki są przyrostowe i, po utworzeniu, niezależne, więc odtworzenie jednej z nich na nowym woluminie nigdy nie wpływa na źródło. Kanonicznym sposobem na zduplikowanie dużego produkcyjnego zbioru danych do środowiska testowego jest wykonanie migawki woluminu źródłowego i utworzenie nowych woluminów z tej migawki. Jednak woluminy odtworzone z migawek leniwie ładują bloki z S3 przy pierwszym odczycie, co powoduje znaczne opóźnienia I/O, dopóki każdy blok nie zostanie “nawodniony” (hydrated). To samo leniwe ładowanie dotyczy nowych instancji uruchamianych z obrazów AMI, których migawki głównego woluminu są duże – działają one powolnie przez kilka minut po uruchomieniu.

EBS Fast Snapshot Restore (FSR) eliminuje tę niedogodność. Włącz FSR dla migawki w tych Strefach Dostępności (AZ), w których grupa ASG uruchamia instancje, a woluminy z niej utworzone natychmiast zapewnią pełną alokowaną wydajność:

aws ec2 enable-fast-snapshot-restores \
  --availability-zones us-east-1a us-east-1b \
  --source-snapshot-ids snap-0123456789abcdef0

Jest to kluczowe, gdy zdarzenia skalowania w poziomie (scale-out) muszą dodać zasoby w ciągu sekund, a nie minut.

Ulepszona sieć z ENA i EFA

Deklarowana przepustowość sieci skaluje się wraz z rozmiarem instancji, ale jest osiągalna tylko wtedy, gdy obecny jest sterownik Elastic Network Adapter (ENA). ENA zapewnia ulepszoną sieć opartą na SR-IOV (enhanced networking), obsługując do 200 Gb/s na nowszych instancjach. Nowoczesne obrazy AMI (Amazon Linux 2, najnowsze Ubuntu, Windows) są dostarczane z włączonym ENA; zweryfikuj to za pomocą:

aws ec2 describe-instances --instance-ids i-0abc \
  --query 'Reservations[].Instances[].EnaSupport'

modinfo ena | grep version
ethtool -i eth0

Bez ENA instancje po cichu przełączają się na niższą przepustowość i wyższy jitter, co podważa każdy projekt o niskich opóźnieniach, niezależnie od wyboru grupy rozmieszczenia (placement group).

Dla operacji zbiorowych na mikrosekundową skalę – CFD, modelowanie pogody, dynamika molekularna, trenowanie dużych modeli – dodaj Elastic Fabric Adapter (EFA). EFA udostępnia transport z pominięciem systemu operacyjnego (OS-bypass) oparty na Libfabric dla MPI i NCCL, całkowicie omijając stos sieciowy jądra systemu. EFA przynosi korzyści tylko w ramach klastrowej grupy rozmieszczenia (cluster placement group) na obsługiwanych typach instancji (c7gn, hpc7a, p5) i wymaga sterownika EFA oraz kompatybilnej kompilacji MPI (Open MPI, Intel MPI) lub NCCL.

aws ec2 create-placement-group --group-name hpc-cg --strategy cluster
aws ec2 run-instances --instance-type hpc7a.96xlarge \
  --placement GroupName=hpc-cg \
  --network-interfaces InterfaceType=efa,DeviceIndex=0,SubnetId=subnet-abc

Placement Groups

Grupy rozmieszczania (Placement groups) kontrolują fizyczną topologię instancji:

Niewłaściwy wybór marnuje potencjał tej funkcji. Grupa typu cluster nie może obejmować wielu stref AZ — z założenia działa wewnątrz jednej strefy. Grupa typu spread nie może hostować stu serwerów WWW z powodu limitu siedmiu instancji na strefę AZ. Dla 40-węzłowego klastra Kafka właściwym narzędziem jest grupa typu partition, a nie spread, ponieważ dopasowuje ona rozmieszczenie replik do domen awarii (fault domains). Dla ogólnej wysokiej dostępności nie należy ograniczać grupy ASG do jednej grupy rozmieszczania w jednej strefie AZ — należy rozproszyć ASG na wiele stref AZ.

Dla analityki strumieniowej lub obciążeń MPI wymagających minimalnego opóźnienia między węzłami, prawidłową kombinacją jest grupa rozmieszczania typu cluster oraz instancje z włączonym ENA; grupa cluster minimalizuje liczbę przeskoków sieciowych, a ENA dostarcza przepustowość (w pakietach na sekundę) niezbędną do uzyskania tej korzyści z niskiego opóźnienia.

Auto Scaling Groups and Launch Templates

Grupa Auto Scaling (ASG) to jednostka wykonawcza, która utrzymuje pożądaną liczbę instancji EC2 w jednej lub wielu strefach AZ, zdefiniowaną przez trzy liczby całkowite — MinSize, DesiredCapacity, MaxSize — oraz listę podsieci. Sama grupa ASG nie opisuje, co ma być uruchamiane; za to odpowiada szablon uruchamiania (launch template), nowoczesny następca konfiguracji uruchamiania (launch configurations). Szablony uruchamiania obsługują wersjonowanie, zasady mieszanych typów instancji, łączenie instancji Spot i On-Demand, wymuszanie IMDSv2, rezerwacje pojemności oraz instancje T w trybie unlimited. Szablon uruchamiania odwołuje się do obrazu AMI, typu (lub typów) instancji, grup bezpieczeństwa, profilu instancji IAM, danych użytkownika (user data) oraz mapowań urządzeń blokowych.

Kanoniczny wzorzec dla bezstanowych aplikacji webowych to AMI + Launch Template + ASG + ALB. AMI zapewnia szybki start; ALB (lub NLB dla TCP/UDP) dystrybuuje ruch i przeprowadza kontrole stanu (health checks); ASG automatycznie rejestruje nowe instancje w grupie docelowej (target group) i kończy działanie tych, które są w złym stanie. Wdrożenie w wielu strefach AZ (minimum dwie strefy, trzy dla systemów wymagających kworum) jest obowiązkowe — grupa ASG przypisana do jednej podsieci nie przetrwa awarii strefy AZ, ponieważ sama ASG nie będzie mogła uruchomić zastępczych instancji, dopóki strefa jest niedostępna.

MyASG:
  Type: AWS::AutoScaling::AutoScalingGroup
  Properties:
    MinSize: 2
    MaxSize: 20
    DesiredCapacity: 4
    VPCZoneIdentifier: [subnet-a, subnet-b]
    TargetGroupARNs: [!Ref AppTargetGroup]
    LaunchTemplate:
      LaunchTemplateId: !Ref AppLT
      Version: !GetAtt AppLT.LatestVersionNumber
    HealthCheckType: ELB
    HealthCheckGracePeriod: 120

Scaling Policies: Target Tracking, Step, Scheduled, Predictive

Skalowanie ASG ma cztery tryby, z których każdy rozwiązuje inny problem:

• Śledzenie celu (Target tracking) wybiera metrykę i utrzymuje ją w pobliżu zadanej wartości (np. ASGAverageCPUUtilization = 50%, ALBRequestCountPerTarget = 1000). Jest to mechanizm samoregulujący — AWS zarządza alarmami i dostosowuje szybkość reakcji w miarę odchylania się metryki. Powinien to być domyślny wybór.
• Skalowanie krokowe (Step scaling) dodaje lub usuwa pojemność w stopniowanych progach, w zależności od tego, jak bardzo metryka odbiega od normy; przydatne, gdy skala reakcji musi być proporcjonalna do wagi alarmu.
• Skalowanie proste (Simple scaling) jest przestarzałe: jedna zmiana na alarm, blokuje się w okresie “cooldown” i nie powinno być wybierane w nowych projektach.
• Skalowanie zaplanowane (Scheduled scaling) zmienia wartości MinSize/DesiredCapacity/MaxSize o określonych godzinach (jak w cron).
• Skalowanie predykcyjne (Predictive scaling) wykorzystuje uczenie maszynowe na podstawie historii z maksymalnie 14 dni do prognozowania zapotrzebowania na najbliższe 48 godzin, alokując pojemność przed nadejściem wzrostu ruchu.

Skalowanie dynamiczne jest z natury reaktywne — reaguje dopiero po przekroczeniu progu metryki, a nowe instancje potrzebują kilku minut na uruchomienie, rejestrację i rozgrzanie. Dla aplikacji biznesowej, do której wszyscy użytkownicy logują się o 09:00 i doświadczają 2–3 godzin spowolnienia, podczas gdy ASG próbuje nadążyć, samo skalowanie dynamiczne jest złym rozwiązaniem. Należy zastosować warstwę akcji zaplanowanych (scheduled actions) przed szczytem, aby podnieść MinSize i DesiredCapacity zanim wzrośnie zapotrzebowanie:

ScheduledAction:
  AutoScalingGroupName: web-asg
  ScheduledActionName: pre-sale-warmup
  Recurrence: "0 8 * * *"
  MinSize: 20
  DesiredCapacity: 30
  MaxSize: 200

Następnie należy pozwolić, aby skalowanie typu target tracking zaabsorbowało pozostałą zmienność. Skalowanie predykcyjne jest właściwym wyborem, gdy kształt piku jest stabilny, ale jego dokładny czas wystąpienia zmienia się z dnia na dzień. Dla przewidywalnych wyłączeń środowisk nieprodukcyjnych (np. deweloperskich w nocy i w weekendy), akcja zaplanowana ustawiająca desired=0, min=0 w piątek wieczorem i przywracająca poprzednie wartości w poniedziałek rano jest rozwiązaniem o najmniejszym narzucie — sama grupa ASG działa jako mechanizm harmonogramu, bez potrzeby używania Lambda czy EventBridge.

Wybór metryki jest równie ważny jak wybór polityki skalowania. Skalowanie po CPU sprawdza się dla obciążeń webowych ograniczonych mocą procesora, ale dla workerów przetwarzających zadania z kolejki (np. SQS), należy skalować na podstawie głębokości kolejki, a nie użycia CPU: worker zablokowany na operacjach I/O może pokazywać 10% użycia CPU, podczas gdy w kolejce gromadzą się miliony wiadomości. Należy użyć metryki ApproximateNumberOfMessagesVisible na instancję, udostępnionej jako metryka niestandardowa lub poprzez wbudowany cel SQSQueueBacklogPerInstance:

backlog_per_instance = messages_visible / running_instances
target = acceptable_latency_seconds / avg_processing_seconds_per_msg

TargetTrackingConfiguration:
  CustomizedMetricSpecification:
    MetricName: BacklogPerInstance
    Namespace: MyApp/Scaling
    Statistic: Average
  TargetValue: 100

Podobnie, warstwy HTTP wrażliwe na opóźnienia powinny śledzić TargetResponseTime lub RequestCountPerTarget; aplikacje ograniczone przez pamięć, dysk lub opóźnienia systemów zależnych powinny publikować metrykę niestandardową, która odzwierciedla rzeczywiste wąskie gardło. Skalowanie na podstawie CPU, gdy CPU nie jest ograniczeniem, prowadzi dokładnie do scenariusza awarii, w którym instancje nigdy się nie wyskalowują, kolejki rosną w nieskończoność, a ALB zwraca błędy 5xx.

Kontrole kondycji i haki cyklu życia

Grupy ASG domyślnie używają kontroli statusu EC2, które wykrywają awarię hypervisora, ale nie awarię aplikacji. Włączenie kontroli kondycji ELB w grupie ASG deleguje decyzję o wymianie instancji do sondy na poziomie aplikacji load balancera, co jest kluczowe, gdy system operacyjny działa poprawnie, ale proces aplikacji jest zawieszony. Ustaw HealthCheckGracePeriod na wystarczająco długi czas, aby skrypty user data mogły się zakończyć; w przeciwnym razie nowe instancje będą terminowane w trakcie bootstrapu w pętli.

Wybór load balancera wpływa na znaczenie pojęcia „zdrowy”:

Aplikacja HTTP za NLB wykonującym tylko kontrole kondycji TCP będzie nadal obsługiwać ruch z instancji, która akceptuje połączenia, ale zwraca błędy 500. Przełącz się na ALB — lub skonfiguruj kontrole kondycji HTTP na NLB — aby przywrócić sensowną sygnalizację stanu.

Haki cyklu życia wstrzymują instancje w stanach Pending:Wait lub Terminating:Wait, aby zewnętrzna automatyzacja mogła zadziałać. Podczas uruchamiania hak pozwala na rejestrację w systemie zarządzania konfiguracją, rozgrzanie pamięci podręcznej lub pobranie sekretów, zanim ALB zacznie wysyłać ruch. Podczas terminacji hak pozwala na opróżnienie sesji, zrzucenie logów i wyrejestrowanie z siatki usług (service mesh). Haki emitują zdarzenia EventBridge; procedury obsługi muszą wywołać CompleteLifecycleAction, w przeciwnym razie hak przekroczy limit czasu i przejdzie do domyślnej akcji (CONTINUE lub ABANDON).

Ciepłe pule i hibernacja

Czas zimnego startu jest realnym problemem dla aplikacji, które ładują duże modele, rozgrzewają pamięć podręczną lub kompilują JIT przed rozpoczęciem obsługi ruchu. Ciepła pula to wstępnie zainicjowana rezerwa dołączona do ASG: instancje uruchamiają się, wykonują bootstrap, a następnie są zatrzymywane, pozostawiane w stanie działającym lub hibernowane, trzymane w puli do momentu, gdy ASG przeprowadzi skalowanie w górę. Pobranie instancji z puli pozwala pominąć minuty potrzebne na uruchomienie.

Hibernacja zawiesza system operacyjny na zaszyfrowanym woluminie root EBS, dzięki czemu sterta JVM, wagi modeli ML i pamięć podręczna stron systemu operacyjnego wracają po wznowieniu. Wymagania: zaszyfrowany wolumin root wystarczająco duży, aby pomieścić zawartość RAM, pamięć RAM instancji ≤ 150 GB w obsługiwanej rodzinie instancji oraz HibernationOptions.Configured = true podczas uruchamiania. Ciepła pula ze stanem PoolState: Hibernated łączy obie te cechy — instancje nie generują kosztów za moc obliczeniową, gdy są zatrzymane, i wznawiają działanie w ciągu kilku sekund z wypełnioną pamięcią. Jest to prawidłowy wzorzec, gdy aplikacja „potrzebuje dużo czasu na załadowanie danych do pamięci, zanim stanie się produktywna”.

Automatyczne odzyskiwanie dla nieskalowalnych obciążeń

Nie każde obciążenie skaluje się horyzontalnie. Starsze aplikacje z licencjami powiązanymi z adresem MAC, blokadami opartymi na plikach lub stanem sesji w pamięci bez współdzielonego magazynu nie mogą działać na więcej niż jednej instancji — uruchamianie dodatkowych węzłów powoduje uszkodzenie danych lub naruszenie licencji. Dla nich odporność na awarie pochodzi z automatycznego odzyskiwania, a nie ze skalowania w górę.

Działają dwa wzorce. Alarm CloudWatch dla metryki StatusCheckFailed_System w połączeniu z akcją odzyskiwania EC2 zachowuje ID instancji, prywatny adres IP, Elastic IP i dołączone woluminy EBS w przypadku awarii hosta podstawowego. Jeszcze prostsze rozwiązanie: grupa ASG z MinSize=MaxSize=1 obejmująca wiele Stref Dostępności (AZ) zastępuje uszkodzoną instancję i, w przeciwieństwie do akcji odzyskiwania, może przetrwać awarię całej strefy — pod warunkiem, że stan jest przechowywany poza woluminem root lub AMI można odtworzyć.

Load Balancery i umiejscowienie w podsieciach

ALB działa w warstwie 7, terminując ruch HTTP/HTTPS, oferując routing na podstawie hosta/ścieżki/nagłówka, integrację z HTTP/2, WebSockets, WAF/Cognito/OIDC. NLB działa w warstwie 4, zachowuje adres IP klienta, obsługuje statyczne adresy IP i TLS passthrough, PrivateLink oraz utrzymuje miliony połączeń na sekundę. Gateway Load Balancer wstawia urządzenia firm trzecich (zapory sieciowe, systemy IDS) w ścieżkę ruchu.

Umiejscowienie w podsieciach to miejsce, w którym architektury najczęściej zawodzą. ALB wystawiony do internetu musi być podłączony do podsieci publicznych — czyli podsieci z trasą 0.0.0.0/0 do Internet Gateway — po jednej w każdej Strefie Dostępności (AZ), w której znajdują się cele (targets). Same cele pozostają w podsieciach prywatnych. Jeśli ALB zostanie umieszczony w podsieciach prywatnych lub „publiczne” podsieci nie będą miały domyślnej trasy do IGW, klienci będą doświadczać przekroczenia limitu czasu połączenia. Osiągalność celu wymaga, aby grupa bezpieczeństwa celu zezwalała na ruch przychodzący z grupy bezpieczeństwa ALB na porcie docelowym; nie jest potrzebny NAT między ALB a celami w tej samej sieci VPC.

Client → IGW → ALB (public subnets, SG: allow 443 from 0.0.0.0/0)
              → Targets (private subnets, SG: allow 8080 from ALB-SG)

Włącz kontrole kondycji ELB w grupie ASG, aby niezdrowe cele były wymieniane, a nie tylko wyrejestrowywane. Cross-zone load balancing (domyślnie włączony w ALB, opcjonalny w NLB) wyrównuje dystrybucję żądań niezależnie od liczby instancji w każdej Strefie Dostępności. Route 53 musi wskazywać na ALB za pomocą rekordu alias (lub polityki ważonej/opóźnienia dla wielu ALB) — nigdy nie kieruj Route 53 na indywidualne adresy IP instancji EC2, ponieważ uszkodzona instancja będzie nadal otrzymywać ruch do wygaśnięcia TTL, a nowa instancja z ASG będzie miała inny adres IP.

Modele Zakupów i Floty Instancji Mieszanych

Wybór modelu zakupu to największa pojedyncza dźwignia do redukcji wydatków na EC2, niezależna od wzorca architektury.

Racjonalna strategia: obciążenie bazowe na Reserved Instances lub Savings Plan, skoki obciążenia na On-Demand, praca odporna na błędy na Spot. W ASG jest to wyrażone jako polityka instancji mieszanych (mixed-instances policy):

MixedInstancesPolicy:
  LaunchTemplate:
    LaunchTemplateSpecification:
      LaunchTemplateId: lt-0abc123
      Version: $Latest
    Overrides:
      - InstanceType: m5.large
      - InstanceType: m5a.large
      - InstanceType: m6i.large
      - InstanceType: m6a.large
  InstancesDistribution:
    OnDemandBaseCapacity: 4          # covered by Savings Plan
    OnDemandPercentageAboveBaseCapacity: 20
    SpotAllocationStrategy: price-capacity-optimized

Dywersyfikacja typów instancji pogłębia pulę Spot i redukuje skorelowane przerwania. Strategia price-capacity-optimized (lub capacity-optimized) równoważy cenę z głębokością puli, dzięki czemu instancje są mniej narażone na odzyskanie.

Instancje Spot są odpowiednie dla obciążeń bezstanowych, z możliwością checkpointingu, ponawiania prób lub horyzontalnie redundantnych: workery webowe za ALB, zadania Batch z automatycznym ponawianiem, executory Spark, runnerzy CI. Nie są one odpowiednie jako jedyna pojemność dla krytycznych, zawsze działających usług, stanowych baz danych primary lub węzłów typu leader bez ścieżki odzyskiwania — dwuminutowe powiadomienie nie gwarantuje bezpiecznego zamknięcia, a skorelowane odzyskanie całej floty określonego typu instancji jest realnym trybem awarii. Gdy wymaganie brzmi „nie może zostać przerwane”, Spot jest zdyskwalifikowany.

Odwrotną pułapką jest stosowanie RI lub Savings Plans do autentycznie zmiennych obciążeń: płacisz za godzinowe zobowiązanie niezależnie od tego, czy jest ono wykorzystywane, więc obciążenie działające 40 godzin tygodniowo w ramach 168-godzinnego zobowiązania marnuje 76% rezerwacji. Gdy problemem jest sama pojemność — a nie cena — (nagły wzrost wywołany zdarzeniem, odzyskiwanie po awarii), użyj On-Demand Capacity Reservation: gwarancji pojemności w ramach jednej Strefy Dostępności (AZ) po stawkach On-Demand, którą można połączyć z Savings Plan w celu uzyskania zniżki.

Moc Obliczeniowa Serverless: Lambda i Fargate

Serverless przenosi zarządzanie pojemnością na platformę. Lambda pasuje do zadań sterowanych zdarzeniami i krótkotrwałych: wyzwalacze S3 ObjectCreated, DynamoDB Streams, konsumenci SQS o małym wolumenie, backendy API Gateway, logika „klejąca” (glue logic). Pamięć (128 MB – 10 240 MB) przydziela CPU proporcjonalnie, więc dostrajanie pamięci w górę często zmniejsza koszt poprzez skrócenie czasu trwania. Twarde limity definiują jej zakres: maksymalny czas wykonania 15 minut, 10 GB pamięci, 10 GB w /tmp, 250 MB wdrożenia po dekompresji (lub 10 GB przez obraz kontenera), 6 MB synchronicznego payloadu. Używanie Lambdy do 30-minutowego transkodowania wideo, wielogodzinnego ETL-a lub treningu na GPU jest architektonicznie błędne — funkcja przekroczy limit czasu w trakcie pracy, a logika ponawiania prób tylko zwielokrotni marnotrawstwo. Dla ścieżek wrażliwych na opóźnienia, łagodź zimne starty (cold starts) i czas inicjalizacji ENI podłączonego do VPC za pomocą Provisioned Concurrency.

Fargate uruchamia kontenery bez zarządzania hostami EC2. Jest to właściwy wybór, gdy zadania przekraczają 15 minut, wymagają niestandardowych środowisk uruchomieniowych lub pasują do orkiestracji ECS/EKS, ale zespół nie chce zarządzać pojemnością. Fargate jest droższy za vCPU-godzinę niż EC2 Spot, więc gdy wykorzystanie w stanie ustalonym (steady-state) jest wysokie i przewidywalne, tańsza będzie mieszana ASG z instancjami Spot na ECS. Dla ruchu o charakterze skokowym lub nieprzewidywalnym, wygrywa sekundowe rozliczanie Fargate.

Do orkiestracji wielu funkcji Lambda, Step Functions jest preferowane nad łączeniem ich za pomocą SNS/SQS, ponieważ zapewnia wizualną historię wykonań, semantykę ponawiania prób, scentralizowaną obsługę błędów i trwały stan. Standardowe przepływy pracy (Standard workflows) są rozliczane za przejście stanu i mogą działać do roku; przepływy ekspresowe (Express workflows) optymalizują przetwarzanie zdarzeń o dużej objętości i krótkim czasie trwania.

Do masowego uruchamiania (fan-out) tysięcy sparametryzowanych zadań w kontenerach — genomika, Monte Carlo, ETL — AWS Batch obsługuje kolejkowanie, rozwiązywanie zależności, ponawianie prób i provisionowanie na zarządzanych instancjach EC2, Spot lub Fargate. Zadania odwołują się do definicji zadania (kontener + vCPU/pamięć + rola IAM), a Batch optymalnie rozmieszcza je (bin-packs) na instancjach o odpowiednim rozmiarze. Step Functions często orkiestruje Batch, Lambda i ECS w ramach jednej maszyny stanu.

Elastic Beanstalk

Beanstalk to zarządzana platforma PaaS, która provisionuje ALB, ASG, instancje EC2 i opcjonalnie RDS na podstawie pakietu aplikacji. Obsługuje wdrożenia typu rolling, rolling-with-additional-batch, immutable oraz blue/green z integracją z CloudWatch. Polityki skalowania są udostępniane jako opcje środowiska (metryka, progi, min/max). Ponieważ Beanstalk domyślnie używa typów instancji z możliwością burstingu, włączenie T-unlimited mode jest prostym rozwiązaniem na krótkotrwałe nasycenie CPU. Zaplanowane akcje skalowania dołącza się do ASG zarządzanego przez Beanstalk tak jak do każdego innego. Wybierz Beanstalk, gdy zespół chce standardowej topologii aplikacji webowej bez ręcznego tworzenia CloudFormation i gdy aktualizacje typu rolling oraz wersjonowane pakiety pasują do cyklu wydawniczego.

Zarządzanie flotą za pomocą Systems Manager

Wzorce oparte na SSH i serwerach bastionowych są kruche, a ich zabezpieczenie jest kosztowne. Zastępuje je usługa AWS Systems Manager. Wystarczy agent SSM (preinstalowany na Amazon Linux 2, Ubuntu, Windows) oraz profil instancji z uprawnieniem AmazonSSMManagedInstanceCore.

• Run Command wykonuje skrypty shell/PowerShell na flotach oznaczonych tagami, z skonsolidowanym wyjściem.
• Session Manager otwiera interaktywne powłoki przez API AWS — bez ruchu przychodzącego na porcie 22, bez serwera bastionowego, z pełną autoryzacją IAM i logowaniem sesji do S3 lub CloudWatch Logs.
• Patch Manager instaluje poprawki systemu operacyjnego zgodnie z harmonogramem, używając okien konserwacyjnych.

aws ssm send-command \
  --targets Key=tag:Env,Values=prod \
  --document-name AWS-RunShellScript \
  --parameters 'commands=["yum -y update"]'

Automatyzacja zaplanowanego uruchamiania i zatrzymywania

Dla nieprodukcyjnych instancji EC2 i RDS, które muszą być wyłączone poza godzinami pracy, wzorcem wymagającym niewielkiej konserwacji jest EventBridge Scheduler → Lambda. Reguła cron (cron(0 19 ? * MON-FRI *)) wywołuje funkcję Lambda, która zatrzymuje zasoby oznaczone tagami; druga reguła o 07:00 je uruchamia.

import boto3
ec2 = boto3.client('ec2'); rds = boto3.client('rds')

def handler(event, _):
    action = event['action']  # 'start' or 'stop'
    ids = [i['InstanceId'] for r in ec2.describe_instances(
        Filters=[{'Name':'tag:AutoStop','Values':['true']}]
    )['Reservations'] for i in r['Instances']]
    getattr(ec2, f'{action}_instances')(InstanceIds=ids)
    for db in rds.describe_db_instances()['DBInstances']:
        if any(t['Key']=='AutoStop' and t['Value']=='true' for t in db['TagList']):
            getattr(rds, f'{action}_db_instance')(DBInstanceIdentifier=db['DBInstanceIdentifier'])

To rozwiązanie jest bezserwerowe, nie ma floty do łatania i skaluje się na podstawie tagów. Rozwiązanie AWS Instance Scheduler działa w analogiczny sposób. Pewna subtelność: zatrzymana instancja RDS uruchamia się automatycznie po siedmiu dniach, więc harmonogram zatrzymywania musi cyklicznie ją ponownie zatrzymywać. W połączeniu z grupami ASG, których zaplanowane akcje zerują pojemność w weekendy, koszt w godzinach bezczynności zbliża się do zera.

Pułapki sieciowe związane ze skalowaniem zasobów obliczeniowych

Umiejscowienie NAT Gateway. Bramka NAT Gateway znajduje się w jednej strefie dostępności (AZ). Flota rozproszona w trzech strefach AZ, która kieruje cały ruch wychodzący przez jedną bramkę NAT w us-east-1a, płaci za transfer między strefami AZ za każdy pakiet z us-east-1b/us-east-1c i całkowicie traci ruch wychodzący, gdy us-east-1a ulegnie awarii. Prawidłowym wzorcem jest jedna bramka NAT Gateway na każdą strefę AZ, gdzie tablica routingu każdej podsieci prywatnej wskazuje na bramkę NAT w jej własnej strefie. Lokalizuje to ruch i eliminuje tryb awarii związany z pojedynczą strefą AZ.

Instancje NAT. Pojedyncza instancja NAT oparta na EC2 staje się wąskim gardłem pod względem przepustowości i liczby pakietów na sekundę (PPS) w miarę wzrostu floty i stanowi pojedynczy punkt awarii (SPOF). Zarządzane bramki NAT Gateways skalują się do 100 Gb/s na bramkę. Dla ruchu do usług AWS, punkty końcowe VPC endpoints (typu Gateway dla S3/DynamoDB, typu Interface dla pozostałych) całkowicie omijają NAT, obniżając koszty i eliminując ryzyko nasycenia podczas zdarzeń skalowania.

Często powtarzające się pułapki projektowe

• Grupy ASG w jednej strefie AZ nie przetrwają awarii strefy — zawsze dołączaj podsieci z co najmniej dwóch stref AZ (trzech dla systemów wymagających kworum) i utrzymuj MinSize ≥ 2.
• Zakładanie, że każde obciążenie skaluje się horyzontalnie. Aplikacje przechowujące stan, z jednym procesem piszącym (single-writer) lub z licencjami nieprzystosowanymi do klastrowania działają gorzej w ramach ASG. Najpierw zastosuj automatyczne odzyskiwanie lub refaktoryzację.
• Skalowanie reaktywne dla przewidywalnych szczytów obciążenia powoduje objaw „powolnego działania przez pierwsze 2–3 godziny”. Użyj skalowania zaplanowanego lub predykcyjnego, aby wstępnie „rozgrzać” zasoby.
• Skalowanie na podstawie CPU, gdy CPU nie jest ograniczeniem. Publikuj metrykę, która odzwierciedla rzeczywiste wąskie gardło — głębokość kolejki, czas odpowiedzi, liczbę połączeń.
• Simple scaling i launch configurations to przestarzałe mechanizmy — preferuj target tracking i launch templates.
• Kontrole kondycji oparte tylko na TCP dla aplikacji HTTP pozostawiają uszkodzone instancje w rotacji. Używaj kontroli HTTP (przez ALB lub kontrole NLB w trybie HTTP).
• Używanie instancji Spot dla obciążeń stanowych lub takich, które nie mogą być przerywane — Spot wymaga zadań, które można zatrzymać i wznowić (checkpointable) oraz które są zastępowalne.
• Używanie Reserved Instances lub Savings Plans dla autentycznie zmiennych obciążeń — niewykorzystane zobowiązanie to czyste marnotrawstwo; zamiast tego obniżaj koszty poprzez right-sizing i instancje Spot.
• Kierowanie ruchu z Route 53 na indywidualne adresy IP instancji EC2 — kieruj ruch na alias ALB, aby DNS odzwierciedlał zmiany we flocie.
• Traktowanie instance store jako trwałego nośnika danych — dane znikają po zatrzymaniu, zakończeniu lub awarii hosta.
• Ignorowanie opóźnień związanych z „leniwym ładowaniem” (lazy-load) po odtworzeniu migawki lub uruchomieniu AMI — włącz Fast Snapshot Restore w docelowych strefach AZ.

Wszystkie domeny · Kontenery i orkiestracja →

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

Przeglądaj Amazon →