Amazon SAP-C02: Moc obliczeniowa i Auto Scaling — Przewodnik do nauki

By Laurynas Brazys · 31 July 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

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

Wzorce obliczeniowe serverless, ograniczenia Lambda i projektowanie sterowane zdarzeniami

Architektura bezserwerowa (serverless) redukuje obciążenie operacyjne, ale wymaga wzorców architektonicznych, które uwzględniają współbieżność, stan i ograniczenia systemów podrzędnych. Lambda doskonale nadaje się do krótkotrwałych zadań sterowanych zdarzeniami, backendów API za pośrednictwem API Gateway lub ALB oraz asynchronicznego przetwarzania z użyciem SQS lub SNS. Użyj Step Functions do orkiestracji długotrwałych przepływów pracy oraz DynamoDB lub RDS Proxy do dostępu do baz danych, aby łagodzić tzw. burze połączeń (connection storms). Należy pamiętać o narzucie związanym z zimnym startem (cold-start) Lambdy w VPC, spowodowanym tworzeniem ENI; można go złagodzić za pomocą provisioned concurrency dla punktów końcowych wrażliwych na opóźnienia lub użyć VPC endpoints i RDS Proxy do ograniczenia liczby połączeń. Zaimplementuj wzorzec fan-out/fan-in za pomocą SNS + SQS lub Kinesis/MKS do uporządkowanego przetwarzania strumieniowego; użyj kolejek typu dead-letter (DLQ) w SQS i idempotentnych handlerów do zarządzania ponownymi próbami i duplikatami. Limity współbieżności, reserved concurrency i throttling powinny być zaplanowane, aby unikać kaskadowych awarii; projektuj z uwzględnieniem mechanizmu backpressure, używając ograniczników (throttles), ponownych prób z jitterem i wyłączników awaryjnych (circuit breakers) w API Gateway lub niestandardowych. Kompromisy między kosztem a wydajnością są jasne: Lambda jest opłacalna dla nieregularnych, krótkotrwałych zadań, podczas gdy Fargate lub EC2 są lepsze dla zadań o stałym, wysokim zużyciu CPU lub długo działających. Częste pułapki to poleganie na synchronicznych ponownych próbach, które przeciążają systemy podrzędne, przechowywanie stanu w lokalnym katalogu /tmp z oczekiwaniem na jego trwałość oraz niezapewnienie zasobów (provisioning) na zimne starty w przepływach krytycznych pod względem opóźnień.

Praktyczny problem: Migracja contact center firmy NovaTel Enterprise

Scenariusz: NovaTel Enterprise prowadzi hybrydowe contact center z routingiem połączeń on-premises i połączeniem Direct Connect do AWS. Uruchamiają brokery sesji na EC2 w dwóch Strefach Dostępności (Availability Zones) i chcą przeprowadzić migrację do zarządzanego przez AWS contact center o wysokiej dostępności i przewidywalnym opóźnieniu między lokalną centralą PBX a usługami w chmurze.

Wyzwanie: Potrzebują połączenia o niskim opóźnieniu dla ruchu SIP, skalowalnej warstwy obliczeniowej do obsługi głosu, która toleruje przerwy w działaniu instancji Spot, oraz strategii odtwarzania po awarii (DR) obejmującej wiele Regionów bez zwiększania złożoności operacyjnej.

Zalecane podejście:

1. Uruchomienie Amazon Connect dla funkcjonalności contact center i użycie Site-to-Site VPN lub Direct Connect z AWS Transit Gateway do zapewnienia trunkingu SIP o niskim opóźnieniu, zakończonego na NLB z TLS passthrough przed brokerami sesji.
2. Uruchomienie komponentów przetwarzających sesje jako mieszanej grupy Auto Scaling Group z szablonami uruchamiania (launch templates) wykorzystującymi zoptymalizowane pod kątem pojemności instancje Spot z rezerwowym przejściem na On-Demand, oraz użycie Placement Groups (typu spread) do izolacji awarii krytycznych brokerów.
3. Dla stanowych mediów połączeń wymagających efemerycznej pamięci masowej o niskim opóźnieniu, użyj instancji z instance store (Nitro) do buforowania mediów i replikuj metadane sesji do DynamoDB lub ElastiCache z replikacją multi-AZ; wykorzystaj RDS (Multi-AZ) lub Aurora Global DB dla trwałych danych z replikami do odczytu w innych Regionach na potrzeby DR.
4. Zaimplementuj lifecycle hooks i warm pools, aby zminimalizować zimny start brokerów, ważony failover w Route 53 dla DR między Regionami, oraz CloudWatch + SNS/SQS do alertów i zautomatyzowanych procedur przełączania awaryjnego (failover runbooks).

Uzasadnienie: Użycie zarządzanych usług contact center zmniejsza obciążenie operacyjne, podczas gdy mieszane grupy ASG z instancjami Spot optymalizują koszty; izolowanie efemerycznych mediów na instance stores zachowuje wydajność, a trwała replikacja stanu do DynamoDB/ElastiCache oraz multi-AZ RDS/Aurora zapewnia odporność na awarie i szybkie przełączanie awaryjne, zgodnie z najlepszymi praktykami profesjonalnej architektury.

← Bezpieczeństwo · Wszystkie domeny · Pamięć masowa i zarządzanie danymi →

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

Przeglądaj Amazon →