AWS Solutions Architect · Lekcja

Filary optymalizacji kosztów i zrównoważonego rozwoju

Filary optymalizacji kosztów i zrównoważonego rozwoju to bezpłatna lekcja AWS Solutions Architect na CoddyKit. To lekcja 3 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej AWS Solutions Architect, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs AWS Solutions Architect zawiera 4 lekcji w sumie.

Omówienie filaru optymalizacji kosztów

Filar optymalizacji kosztów koncentruje się na unikaniu niepotrzebnych wydatków i uzyskiwaniu jak największej wartości z wydatków na AWS. Często jest to filar o najbardziej bezpośrednim wpływie, ponieważ zasoby chmurowe łatwo nadmiernie przydzielić. Kluczowe zasady projektowania: wdrożenie zarządzania finansami w chmurze — traktowanie kosztu jako kluczowej metryki. Przyjęcie modelu konsumpcyjnego — płacenie wyłącznie za wykorzystywane zasoby. Pomiar ogólnej efektywności — śledzenie kosztu przypadającego na jednostkę wartości biznesowej. Ograniczenie wydatków na niezróżnicowaną pracę operacyjną — używanie usług zarządzanych zamiast samodzielnego zarządzania infrastrukturą.

# Cost Optimisation pillars:
# 1. Expenditure awareness  - visibility into what you spend
# 2. Cost-effective resources - right instance types, storage classes
# 3. Matching supply to demand - auto scaling, spot instances
# 4. Optimising over time - regularly review and adjust

# Example: undifferentiated heavy lifting
# Instead of managing your own Redis: use ElastiCache
# Instead of managing Kubernetes: use EKS or Fargate
# Managed services reduce operational overhead AND cost

Dobór odpowiedniej wielkości zasobów

Dobór odpowiedniej wielkości zasobów to działanie optymalizujące koszty o największym wpływie — polega na identyfikowaniu i eliminowaniu nadmiernie przydzielonych zasobów. Częstym wzorcem jest uruchamianie dużych instancji podczas początkowej konfiguracji i późniejsze niepoddawanie ich ponownej ocenie. AWS Compute Optimizer analizuje wskaźniki wykorzystania i rekomenduje optymalny typ instancji. Typowy wynik analizy: instancja m5.4xlarge wykorzystująca 5% CPU powinna zostać zastąpiona przez t3.medium, co pozwala obniżyć koszt obliczeń o 80%. Dobór odpowiedniej wielkości zasobów dotyczy EC2, Lambda (pamięci), RDS i woluminów EBS.

# Get Compute Optimizer recommendations for all EC2
aws compute-optimizer get-ec2-instance-recommendations \
  --filters Name=finding,Values=Overprovisioned

# Response includes:
# currentInstanceType: m5.4xlarge
# recommendedInstanceType: t3.large
# estimatedMonthlySavings: $280
# performanceRisk: VeryLow

# Also check EBS volumes:
aws compute-optimizer get-ebs-volume-recommendations \
  --filters Name=finding,Values=Overprovisioned

Optymalizacja modeli zakupowych

W przypadku obciążeń o stałym poziomie wykorzystania ceny On-Demand są najwyższe. Znaczne oszczędności można uzyskać dzięki: Reserved Instances (1 lub 3 lata) — do 72% oszczędności w przypadku przewidywalnych obciążeń. Savings Plans — elastyczne zobowiązanie (do 66% oszczędności), które można stosować w różnych rodzinach instancji i regionach. Spot Instances — do 90% oszczędności w przypadku obciążeń, które mogą zostać przerwane (przetwarzanie wsadowe, CI/CD, aplikacje bezstanowe). Typowa flota zoptymalizowana kosztowo łączy wszystkie trzy opcje: Savings Plans dla bazowego poziomu wykorzystania, Spot dla dodatkowego obciążenia, a On-Demand w szczególnych przypadkach.

# Purchasing model comparison:
# On-Demand:       $0.192/hr (m5.large)   No commitment
# 1yr Reserved:    $0.114/hr              $0.78/hr effective
# 3yr Reserved:    $0.074/hr              Highest savings
# Compute SP:      ~$0.128/hr             Flexible family/region
# Spot:            $0.05-0.08/hr          Interruptible

# Savings Plans cover:
# - Compute Savings Plans: EC2 + Lambda + Fargate
# - EC2 Instance Savings Plans: specific family in one region

Spot Instances na potrzeby optymalizacji kosztów

Spot Instances wykorzystują niewykorzystaną moc obliczeniową AWS z rabatem sięgającym 90%, ale mogą zostać przerwane z 2-minutowym ostrzeżeniem, gdy AWS będzie potrzebować tej mocy. Spot sprawdza się w przypadku: przetwarzania wsadowego (z punktami kontrolnymi i możliwością wznowienia), agentów kompilacji CI/CD, bezstanowych serwerów internetowych (za ALB; ELB kieruje ruch z pominięciem przerwanych instancji) oraz węzłów roboczych EMR i EKS. Należy używać Spot Fleet lub ASG z wieloma typami instancji i strefami AZ, aby rozłożyć obciążenie między pule i zmniejszyć ryzyko przerwania.

# ASG with mixed instances (On-Demand + Spot)
aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name my-mixed-asg \
  --mixed-instances-policy '{
    "LaunchTemplate": {"LaunchTemplateSpecification":{"LaunchTemplateId":"lt-12345","Version":"$Latest"},"Overrides":[{"InstanceType":"m5.large"},{"InstanceType":"m5a.large"},{"InstanceType":"m4.large"}]},
    "InstancesDistribution": {
      "OnDemandPercentageAboveBaseCapacity": 20,
      "SpotAllocationStrategy": "capacity-optimized"
    }
  }' \
  --min-size 2 --max-size 20 --desired-capacity 5

Optymalizacja kosztów pamięci masowej S3

Koszty pamięci masowej S3 można znacznie obniżyć, używając odpowiedniej klasy pamięci masowej i automatyzując przejścia między klasami. S3 Intelligent-Tiering automatycznie przenosi obiekty między warstwami dostępu na podstawie wzorców dostępu — jest idealne, gdy wzorce dostępu są nieznane. Reguły cyklu życia przenoszą obiekty zgodnie z harmonogramem: ze Standard → Standard-IA po 30 dniach → Glacier po 90 dniach → Deep Archive po 180 dniach. Warto również rozważyć użycie S3 Select w celu pobierania tylko potrzebnego podzbioru danych obiektu, co ogranicza koszty transferu danych i przetwarzania.

# S3 lifecycle policy for cost optimisation
aws s3api put-bucket-lifecycle-configuration \
  --bucket my-data-bucket \
  --lifecycle-configuration '{
    "Rules": [{
      "ID": "auto-archive",
      "Status": "Enabled",
      "Transitions": [
        {"Days": 30, "StorageClass": "STANDARD_IA"},
        {"Days": 90, "StorageClass": "GLACIER_IR"},
        {"Days": 365, "StorageClass": "DEEP_ARCHIVE"}
      ]
    }]
  }'

Tagowanie i alokacja kosztów

Bez odpowiedniego tagowania nie da się ustalić, ile wydaje każdy zespół lub projekt. Cost Allocation Tags umożliwiają rozbicie kosztów według zespołu, projektu, środowiska lub dowolnego zdefiniowanego wymiaru. Należy aktywować tagi w konsoli rozliczeń, a następnie użyć AWS Cost Explorer do filtrowania i grupowania kosztów według tagów. Tagowanie można wymusić za pomocą Tag Policies w AWS Organizations, a do wykrywania otagowanych zasobów można użyć reguł AWS Config. Umożliwia to showback (widoczność kosztów) i chargeback (przypisywanie kosztów) poszczególnym zespołom.

# Enforce required tags with Config rule
aws configservice put-config-rule \
  --config-rule '{
    "ConfigRuleName": "required-tags",
    "Source": {"Owner":"AWS","SourceIdentifier":"REQUIRED_TAGS"},
    "InputParameters": "{\"tag1Key\":\"Project\",\"tag2Key\":\"Environment\",\"tag3Key\":\"Owner\"}"
  }'

# Query cost by tag in Cost Explorer
aws ce get-cost-and-usage \
  --time-period Start=2026-06-01,End=2026-06-30 \
  --granularity MONTHLY \
  --group-by Type=TAG,Key=Project

Wprowadzenie do filaru zrównoważonego rozwoju

Filar Sustainability (dodany w 2021 roku) koncentruje się na minimalizowaniu wpływu obciążeń chmurowych na środowisko poprzez zmniejszanie zużycia energii i zwiększanie efektywności. Zasady projektowe: Understand your impact — mierz ślad węglowy swoich obciążeń. Establish sustainability goals. Maximise utilisation — dobieraj odpowiednią wielkość zasobów, aby unikać bezczynnych zasobów. Anticipate and adopt more efficient hardware — używaj najnowszych generacji instancji. Use managed services — AWS prowadzi centra danych efektywniej niż większość organizacji.

# Sustainability improvement areas:
# 1. Right-size instances (reduce idle energy use)
# 2. Use Graviton (ARM) instances: 60% less energy than x86
# 3. Use Spot instances: uses otherwise idle capacity
# 4. Use managed services: AWS optimises their utilisation
# 5. Use serverless: no idle servers
# 6. Move to S3/EFS instead of EC2 instance storage
# 7. Implement data lifecycle (don't store forever)

AWS Graviton na rzecz zrównoważonego rozwoju i oszczędności

Procesory AWS Graviton (oparte na ARM) zapewniają do 60% większą efektywność energetyczną i o 20–40% lepszy stosunek ceny do wydajności w porównaniu z instancjami x86. Instancje Graviton3/4 (rodziny c7g, m7g, r7g, t4g) są dostępne dla większości obciążeń EC2, Lambda i Fargate. Przejście z x86 na Graviton jednocześnie wspiera filary Sustainability i Cost Optimisation — oznacza mniejsze zużycie energii na obliczenie i niższe ceny instancji. Większość obciążeń (Linux, aplikacje kontenerowe, JVM) można zmigrować przy minimalnych zmianach.

# Compare: m5.large (x86) vs m7g.large (Graviton3)
# m5.large:  $0.096/hr, 2 vCPU, 8 GB
# m7g.large: $0.0808/hr, 2 vCPU, 8 GB
# Savings: ~16% cheaper + 40% better performance

# Switch Lambda function to Graviton (arm64)
aws lambda update-function-configuration \
  --function-name my-function \
  --architectures arm64

# Lambda arm64 is 20% cheaper than x86
# Most Python, Node.js, Java functions work unchanged

Eliminowanie bezczynnych zasobów

Głównym źródłem niepotrzebnych kosztów i marnowania energii są bezczynne zasoby — instancje EC2 utrzymujące wykorzystanie procesora na poziomie 1%, niepodłączone woluminy EBS, nieużywane elastyczne adresy IP oraz zapomniane środowiska deweloperskie i testowe działające przez całą dobę. Należy wdrożyć harmonogram zatrzymywania i uruchamiania środowisk nieprodukcyjnych, używając reguł EventBridge i automatyzacji Systems Manager — zatrzymywać instancje deweloperskie o 18:00 i uruchamiać je o 8:00. Używaj AWS Trusted Advisor i Cost Explorer do identyfikowania bezczynnych instancji, nieużywanych woluminów EBS i niedostatecznie wykorzystywanych Reserved Instances.

# EventBridge + SSM to stop dev instances nights/weekends
aws events put-rule \
  --name stop-dev-instances \
  --schedule-expression 'cron(0 22 ? * MON-FRI *)'

aws events put-targets \
  --rule stop-dev-instances \
  --targets '[{
    "Id": "StopDevInstances",
    "Arn": "arn:aws:ssm:us-east-1::automation-definition/AWS-StopEC2Instance",
    "RoleArn": "arn:aws:iam::123:role/EventBridgeRole",
    "Input": "{\"InstanceId\":[\"i-dev1\",\"i-dev2\"]}"
  }]'

Cykl życia danych na rzecz zrównoważonego rozwoju

Przechowywanie danych bezterminowo powoduje niepotrzebne zużycie energii. Filar Sustainability zaleca wdrożenie zasad cyklu życia danych, które automatycznie usuwają lub archiwizują dane, gdy nie są już potrzebne. Używaj reguł cyklu życia S3 z datami wygaśnięcia, aby usuwać obiekty po upływie okresu przechowywania. Używaj DynamoDB TTL, aby automatycznie wygaszać stare rekordy. Używaj zasad przechowywania dzienników CloudWatch Logs, aby usuwać grupy dzienników po określonym czasie. Usuwanie zbędnych danych ogranicza zarówno koszty pamięci masowej, jak i energię potrzebną do ich przechowywania i chłodzenia.

# DynamoDB TTL for session data
# Add ttl attribute to items (Unix epoch timestamp)
aws dynamodb update-time-to-live \
  --table-name UserSessions \
  --time-to-live-specification Enabled=true,AttributeName=expiresAt

# Item will be deleted automatically after expiresAt timestamp
# Example: {'userId': 'u1', 'expiresAt': 1750000000}

# CloudWatch Logs: set 30-day retention
aws logs put-retention-policy \
  --log-group-name /aws/lambda/my-function \
  --retention-in-days 30

Optymalizacja kosztów a pozostałe filary

Optymalizacja kosztów czasami koliduje z innymi filarami. Multi-AZ RDS podwaja koszt bazy danych, ale jest wymagane przez filar Reliability. Replikacja między regionami zwiększa niezawodność, ale podnosi koszty pamięci masowej i transferu. Aktywne-aktywne środowisko wieloregionowe zmniejsza opóźnienia (Performance Efficiency), ale kosztuje 2–3 razy więcej. Well-Architected Framework nie nakazuje zawsze wybierać najtańszej opcji — zaleca świadome podejmowanie kompromisów między filarami i dokumentowanie uzasadnienia. Egzamin sprawdza umiejętność wybrania rozwiązania najbardziej efektywnego kosztowo, które nadal spełnia określone wymagania.

# Cost vs reliability trade-off example:
# Single-AZ RDS: $100/month, no HA
# Multi-AZ RDS:  $200/month, automated failover

# Decision: if database failure = $10,000/hour of revenue loss
# Even 1 event/year justifies Multi-AZ
# ($10,000 expected loss > $1,200/year extra cost)

# SAA-C03 exam approach:
# Meet the stated requirements FIRST
# Then choose the cheapest option that meets them

Szybkie sprawdzenie

Sprawdź swoją znajomość zagadnień AWS Solutions Architect (SAA-C03) z tej lekcji.

Podsumowanie lekcji

W tej lekcji poznali Państwo następujące zagadnienia: Cost Optimisation obejmuje dobór odpowiedniej wielkości zasobów, modele zakupowe (Reserved/Savings Plans/Spot) oraz zarządzanie cyklem życia S3, Sustainability koncentruje się na maksymalizacji wykorzystania zasobów, używaniu instancji Graviton i wdrażaniu zasad cyklu życia danych, a kompromisy kosztowe z innymi filarami należy podejmować świadomie, na podstawie wymagań biznesowych. Tagi kosztów umożliwiają showback i chargeback między zespołami. Następnie omówimy Well-Architected Tool i proces przeglądu.

Często zadawane pytania

Czy lekcja „Filary optymalizacji kosztów i zrównoważonego rozwoju” jest bezpłatna?

Tak — pełny tekst „Filary optymalizacji kosztów i zrównoważonego rozwoju” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu AWS Solutions Architect, przejdź na CoddyKit PRO. Kurs AWS Solutions Architect zawiera 4 lekcji w sumie.

Co nauczysz się w „Filary optymalizacji kosztów i zrównoważonego rozwoju”?

Uwzględniać świadomość wydatków, dopasowanie rozmiaru zasobów i wybór modelu cenowego; minimalizować infrastrukturę oraz poprawiać efektywność energetyczną na rzecz zrównoważonego rozwoju. Ćwiczysz AWS Solutions Architect z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć AWS Solutions Architect?

Nie wymagamy żadnego doświadczenia. AWS Solutions Architect w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 3 z 4.

Ile czasu zajmuje lekcja „Filary optymalizacji kosztów i zrównoważonego rozwoju”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji AWS Solutions Architect?

Tak. Każda lekcja AWS Solutions Architect zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

Filary doskonałości operacyjnej i bezpieczeństwa
Filary niezawodności i efektywności wydajnościowej
Filary optymalizacji kosztów i zrównoważonego rozwoju
AWS Well-Architected Tool i proces przeglądu

← Powrót do AWS Solutions Architect