AWS Auto Scaling
AWS Auto Scaling
Automatycznie dopasowuj liczbę zasobów do aktualnego obciążenia. Oszczędzaj gdy ruch spada i skaluj gdy rośnie - bez ręcznej interwencji.
AWS Auto Scaling to serwis, który automatycznie dostosowuje liczbę zasobów do aktualnego zapotrzebowania. Gdy ruch na Twojej aplikacji rośnie, Auto Scaling dodaje instancje. Gdy ruch spada - usuwa niepotrzebne zasoby. Płacisz tylko za to, czego faktycznie potrzebujesz.
Auto Scaling obsługuje nie tylko EC2 Auto Scaling Groups, ale też Application Auto Scaling dla DynamoDB, ECS, Aurora, Lambda i wielu innych serwisów. Możesz konfigurować polityki target tracking (utrzymuj CPU na 70%), step scaling (dodaj 2 instancje gdy CPU > 80%), scheduled (skaluj o 8:00 rano) i predictive scaling (prognozuj ruch na podstawie historii).
Predictive Scaling w AWS analizuje do 14 dni historycznych danych, aby przewidzieć przyszłe obciążenie. Netflix, jeden z największych klientów AWS, używa Auto Scaling do obsługi skoków widowni - np. premier nowych sezonów seriali mogą wymagać tysięcy dodatkowych instancji w ciągu minut.
Zawsze ustawiaj min-size na co najmniej 2 instancje w różnych Availability Zones dla aplikacji produkcyjnych. Używaj target tracking zamiast step scaling - jest prostszy i lepiej się dostosowuje. Łącz predictive scaling z target tracking: predictive skaluje proaktywnie, a target tracking dopasowuje reaktywnie.
AWS Auto Scaling automatycznie dostosowuje liczbe instancji EC2 do aktualnego obciazenia. Ponizej opisujemy caly cykl - od launch template po zaawansowane polityki skalowania i warm pools.
Tworzenie Launch Template
Launch Template definiuje konfiguracje instancji: AMI, typ instancji, Key Pair, Security Groups, IAM Instance Profile, User Data, EBS volumes. Zawsze uzywaj Launch Template zamiast Launch Configuration - Template wspiera wersjonowanie, mixed instances i jest wymagany dla nowych funkcji ASG. Mozesz tworzyc nowe wersje Template bez wplywu na dzialajace instancje.
Konfiguracja Auto Scaling Group (ASG)
ASG laczy Launch Template z parametrami skalowania: min capacity (minimum instancji - nigdy ponizej), max capacity (limit gorny), desired capacity (docelowa liczba). Wybierz VPC i subnety w min. 2 Availability Zones dla wysokiej dostepnosci. ASG automatycznie rozmieszcza instancje rownomiernie miedzy AZ (AZ rebalancing). Polacz ASG z ALB/NLB przez Target Group.
Polityki skalowania (Scaling Policies)
Target Tracking - utrzymuje metryke na zadanym poziomie (np. CPU 70%). Step Scaling - rozne akcje dla roznych progow (np. +1 instancja przy 60% CPU, +3 przy 80%). Simple Scaling - dodaje/usuwa stala liczbe instancji po alarmie, ma cooldown period. Scheduled Scaling - zmienia capacity o ustalonych porach (np. wiecej instancji w godzinach szczytu). Predictive Scaling - uzywa ML do przewidywania obciazenia na podstawie historii.
Health Checks - EC2 i ELB
EC2 health check sprawdza stan maszyny wirtualnej (running vs impaired). ELB health check sprawdza czy aplikacja odpowiada na HTTP requests. Zawsze wlaczaj ELB health check - bez niego ASG nie wykryje sytuacji gdy instancja dziala, ale aplikacja sie zawiasla. Grace period (domyslnie 300s) daje czas na boot aplikacji przed pierwszym sprawdzeniem. Custom health check przez API SetInstanceHealth daje pelna kontrole.
Instance Refresh - rolling updates
Instance Refresh pozwala zaktualizowac wszystkie instancje w ASG do nowej wersji Launch Template bez downtime. Konfigurujesz: minimum healthy percentage (np. 90% - co najmniej tyle instancji musi byc healthy), warmup time (czas na rozgrzanie nowej instancji), checkpoint (pauza po wymianie okreslonego procentu instancji). ASG stopniowo terminuje stare instancje i uruchamia nowe.
Warm Pools - szybsze skalowanie
Warm Pool utrzymuje pulke pre-initialized instancji w stanie Stopped lub Running. Gdy ASG potrzebuje scale out, bierze instancje z warm pool zamiast uruchamiac od zera. To redukuje czas skalowania z minut do sekund. Konfiguruj: pool size (max liczba instancji w puli), pool state (Stopped = tansze, Running = szybsze). Warm pool jest szczegolnie przydatny gdy boot aplikacji trwa dluzej niz 2-3 minuty.
Praktyczne wskazowki dotyczace konfiguracji Auto Scaling w produkcji - od wyboru polityki skalowania po optymalizacje kosztow z wykorzystaniem Spot Instances.
Target Tracking - najlepsza polityka na start
Target Tracking to najprostsza i najczesciej wystarczajaca polityka. Ustaw ASGAverageCPUUtilization na 70% i ASG sam decyduje ile instancji dodac/usunac. Dla aplikacji webowych lepszym targetem jest ALBRequestCountPerTarget (np. 1000 requestow/instancje). Unikaj ustawiania targetu ponizej 40% - nadmiarowe instancje generuja niepotrzebne koszty. Mozesz laczyc wiele Target Tracking policies (CPU + request count).
PoczatkujacyPredictive Scaling dla przewidywalnych wzorcow
Predictive Scaling analizuje 14 dni historii metryk i przewiduje obciazenie na nastepne 48 godzin. Idealne dla: aplikacji e-commerce (wieczorne szczyty), systemow B2B (godziny pracy), cyklicznych batch jobs. Wlacz najpierw w trybie forecast-only, aby sprawdzic dokladnosc predykcji. Po walidacji przelacz na forecast-and-scale. Predictive Scaling skaluje z wyprzedzeniem - instancje sa gotowe zanim przyjdzie obciazenie.
ZaawansowanyMixed Instances Policy - Spot dla oszczednosci
Mixed Instances Policy pozwala uzyc wielu typow instancji i Spot w jednym ASG. Konfiguruj: base capacity (np. 2 On-Demand - zawsze dostepne), percentage above base as Spot (np. 80% Spot). Wybieraj min. 4-6 typow instancji w 2+ rodzinach (np. m5.large, m5a.large, m4.large, c5.large) - wiecej typow = mniejsze ryzyko Spot interruption. Capacity-optimized allocation strategy wybiera typy z najwieksza dostepnoscia.
ZaawansowanyWarm Pools dla szybszego skalowania
Jesli boot aplikacji trwa ponad 2-3 minuty (np. JVM warmup, cache loading, model loading), warm pool dramatycznie skraca czas reakcji. Instancje w stanie Stopped kosztuja tylko za EBS - daje to szybki start za minimalna cene. Uzywaj lifecycle hooks do pre-warm cache i health checkow przed dolaczeniem do ASG. Dla aplikacji ML/AI z duzymi modelami warm pool w stanie Running (platisz za instancje) jest wart kosztu.
ZaawansowanyInstance Refresh dla rolling updates
Zamiast blue/green deployment calego ASG, uzywaj Instance Refresh do stopniowej wymiany instancji. Ustaw MinHealthyPercentage na 90% (minimum 90% instancji dziala w kazdym momencie). Dodaj checkpoint po 20% wymiany - daje czas na sprawdzenie metryk. Jesli nowa wersja ma bledy, anuluj refresh - pozostale instancje zachowaja stara wersje. Lacz z CodeDeploy dla pelnej automatyzacji CI/CD.
PoczatkujacyLifecycle Hooks - graceful start i stop
Lifecycle hooks wstrzymuja instancje w stanie Pending:Wait (przy starcie) lub Terminating:Wait (przy zamykaniu). Uzywaj launch hook do: rejestracji w service discovery, pre-warm cache, uruchomienia testow smoke. Uzywaj terminate hook do: drainingu polaczen z ALB (domyslnie 300s), deregistracji z service discovery, backupu lokalnych danych. Hook timeout to max 48h - ustawiaj 5-15 minut.
ZaawansowanyScreenshoty z AWS Console
Wkrotce pojawia sie tu zrzuty ekranu pokazujace jak korzystac z AWS Auto Scaling bezposrednio w konsoli AWS.
Do czego sluzy AWS Auto Scaling?
Skalowanie aplikacji webowych
Automatycznie dodawaj instancje EC2 za load balancerem gdy ruch rośnie. W Black Friday skalujesz z 2 do 200 instancji - bez ręcznej interwencji.
Optymalizacja kosztów
Zmniejsz liczbę instancji w nocy i w weekendy gdy ruch spada. Scheduled scaling pozwala zaoszczędzić 40-60% na zasobach w godzinach poza szczytem.
Skalowanie kontenerów ECS
Application Auto Scaling automatycznie dodaje lub usuwa taski ECS/Fargate na podstawie metryki CPU, pamięci lub niestandardowej metryki CloudWatch.
Skalowanie baz danych
DynamoDB Auto Scaling dostosowuje Read/Write Capacity Units do ruchu. Aurora Auto Scaling dodaje repliki odczytu gdy obciążenie rośnie.
Co musisz wiedziec?
Auto Scaling Group (ASG)
Grupa instancji EC2 zarządzana automatycznie. Definiujesz min, max i desired capacity. ASG utrzymuje pożądaną liczbę instancji.
Target Tracking Policy
Polityka utrzymująca metrykę na określonym poziomie. Np. "utrzymuj średnie CPU na 70%" - ASG automatycznie dodaje lub usuwa instancje.
Step Scaling Policy
Polityka definiująca konkretne kroki skalowania w zależności od progu metryki. Np. "gdy CPU > 80% dodaj 2 instancje, gdy CPU > 95% dodaj 5".
Scheduled Scaling
Skalowanie według harmonogramu. Np. zwiększ capacity do 10 instancji o 8:00 rano i zmniejsz do 2 o 22:00.
Predictive Scaling
ML-based skalowanie przewidujące ruch na podstawie historycznych wzorców. Skaluje proaktywnie zanim ruch wzrośnie.
Cooldown Period
Okres oczekiwania po akcji skalowania zanim następna może nastąpić. Zapobiega oscylacjom (ciągłemu dodawaniu i usuwaniu instancji).
Architektura: Auto Scaling z multi-AZ i monitoringiem
Typowa architektura produkcyjna z Auto Scaling Group rozpietym na wiele Availability Zones. CloudWatch metryki steruja skalowaniem, ELB health checki zapewniaja dostepnosc, a SNS informuje o zmianach.
Ile kosztuje AWS Auto Scaling?
Auto Scaling
Sam serwis Auto Scaling jest bezpłatny. Płacisz za zasoby, które Auto Scaling uruchamia.
$0 za Auto Scaling - płacisz za instancje EC2, taski ECS, itp.
EC2 Instances
Opłata za instancje EC2 uruchomione przez ASG - standardowy cennik On-Demand, Spot lub Reserved.
ASG z 5x t3.medium: ~$0.0416/instancję/godz. = ~$150/mies.
CloudWatch Alarms
Opłata za alarmy CloudWatch używane przez polityki skalowania.
$0.10/alarm/miesiąc dla Standard Resolution
Przyklady AWS CLI
Utwórz Auto Scaling Group
Stwórz ASG z 2-10 instancjami i target tracking na 70% CPU
aws autoscaling create-auto-scaling-group \
--auto-scaling-group-name moja-aplikacja-asg \
--launch-template LaunchTemplateName=moj-template,Version='$Latest' \
--min-size 2 \
--max-size 10 \
--desired-capacity 2 \
--vpc-zone-identifier "subnet-abc123,subnet-def456" \
--target-group-arns arn:aws:elasticloadbalancing:eu-west-1:123456789012:targetgroup/moja-tg/abc123Dodaj politykę target tracking
Utrzymuj średnie CPU na 70% - ASG automatycznie skaluje
aws autoscaling put-scaling-policy \
--auto-scaling-group-name moja-aplikacja-asg \
--policy-name target-tracking-cpu \
--policy-type TargetTrackingScaling \
--target-tracking-configuration '{"PredefinedMetricSpecification":{"PredefinedMetricType":"ASGAverageCPUUtilization"},"TargetValue":70.0}'Ustaw scheduled scaling
Zwiększ capacity do 8 instancji w godzinach pracy (pon-pt 8:00)
aws autoscaling put-scheduled-update-group-action \
--auto-scaling-group-name moja-aplikacja-asg \
--scheduled-action-name skaluj-rano \
--recurrence "0 8 * * 1-5" \
--min-size 4 \
--max-size 10 \
--desired-capacity 8Sprawdź aktywność ASG
Wyświetl ostatnie akcje skalowania i ich status
aws autoscaling describe-scaling-activities \
--auto-scaling-group-name moja-aplikacja-asg \
--max-items 10 \
--query 'Activities[].{Time:StartTime,Status:StatusCode,Cause:Cause}' \
--output tableQuiz: AWS Auto Scaling
Sprawdz czy dobrze rozumiesz podstawy. Kliknij odpowiedz — feedback pojawi sie od razu.
1. Co to jest Target Tracking Policy?
2. Do czego służy Cooldown Period?
3. Czy AWS Auto Scaling obsługuje tylko EC2?
4. Co to jest Predictive Scaling?
Czesto uzywane razem z AWS Auto Scaling
.svg?v=1784467026){kind=icon}
Chcesz poznac AWS Auto Scaling w praktyce?
Darmowy kurs "AWS od podstaw" pokazuje jak uzywac AWS Auto Scaling krok po kroku. Teoria + praktyka od zera.