10 najczęstszych błędów na AWS i jak ich uniknąć

Błędy, które widzę u każdego klienta

Po latach pracy z AWS widzę pewien wzorzec: te same błędy powtarzają się w 90% kont. Niektóre kosztują kilkaset złotych miesięcznie. Inne - wyciek danych firmowych do internetu. Zebrałem 10 najczęstszych i do każdego dodałem konkretne rozwiązanie.

Błąd #1: Używanie root account na co dzień

Root account to konto z pełnymi uprawnieniami - może usunąć WSZYSTKO, zmienić billing, zamknąć konto. Logowanie się na root do codziennej pracy to jak chodzenie z kluczami do sejfu w kieszeni na basenie.

Rozwiązanie

1. Włącz MFA na root account (hardware key lub aplikacja TOTP)
2. Utwórz osobne konto IAM z uprawnieniami administratora
3. Używaj root TYLKO do zadań wymagających root (zmiana planu support, zamknięcie konta)
4. Zapisz hasło root w bezpiecznym miejscu (np. menedżer haseł) i nie loguj się na co dzień

# Sprawdź czy MFA jest włączone na root
aws iam get-account-summary --query 'SummaryMap.AccountMFAEnabled'
# Powinno zwrócić 1

Błąd #2: Publiczny S3 bucket z danymi klientów

Domyślnie S3 buckety są prywatne. Ale jedna zła konfiguracja i dane trafiają do Google. Co miesiąc media donoszą o kolejnym wycieku przez publiczny bucket - dane medyczne, finansowe, osobowe.

Rozwiązanie

1. Włącz S3 Block Public Access na poziomie konta (nie tylko bucketa)
2. Używaj presigned URLs zamiast publicznego dostępu do plików
3. Skonfiguruj IAM Access Analyzer (w konsoli S3 widoczny jako Access Analyzer for S3) - wykrywa publicznie dostępne zasoby

# Zablokuj publiczny dostęp na poziomie CAŁEGO konta
aws s3control put-public-access-block \
  --account-id 123456789012 \
  --public-access-block-configuration \
    BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

# Sprawdź obecny status
aws s3control get-public-access-block --account-id 123456789012

Więcej o bezpiecznym korzystaniu z S3 w praktycznym poradniku S3.

Błąd #3: Brak alarmu na koszty (Budget Alert)

Bez alarmu na koszty dowiadujesz się o problemie gdy przychodzi faktura. A wtedy jest za późno - pieniądze już poszły. Typowy scenariusz: ktoś zostawił uruchomioną instancję GPU (p3.2xlarge) przez weekend. Koszt: ~$300.

Rozwiązanie

1. Utwórz AWS Budget z alertem na 80% planowanego budżetu
2. Dodaj alarm CloudWatch na EstimatedCharges (UWAGA: tylko region us-east-1 i najpierw włącz opcję Receive Billing Alerts w ustawieniach Billing, inaczej metryka nie istnieje)
3. Włącz Cost Anomaly Detection - AWS sam wykrywa nietypowe skoki

# Utwórz budget $50/mc z alertem na 80%
aws budgets create-budget \
  --account-id 123456789012 \
  --budget '{
    "BudgetName": "MonthlyBudget",
    "BudgetLimit": {"Amount": "50", "Unit": "USD"},
    "TimeUnit": "MONTHLY",
    "BudgetType": "COST"
  }' \
  --notifications-with-subscribers '[{
    "Notification": {
      "NotificationType": "ACTUAL",
      "ComparisonOperator": "GREATER_THAN",
      "Threshold": 80,
      "ThresholdType": "PERCENTAGE"
    },
    "Subscribers": [{
      "SubscriptionType": "EMAIL",
      "Address": "[email protected]"
    }]
  }]'

Szczegółowy przewodnik po kosztach AWS w artykule o cenniku.

Błąd #4: Hardkodowane AWS credentials w kodzie

Klucze AWS (Access Key ID + Secret Access Key) w kodzie źródłowym, w pliku .env commitowanym do Git, albo wklejone w Slack. Git pamięta wszystko - nawet usunięty commit z kluczami można odzyskać.

Rozwiązanie

• EC2/ECS: IAM Role przypisana do instancji/taska (zero kluczy w kodzie)
• Lambda: IAM Execution Role (automatyczne, zero konfiguracji)
• CI/CD: OIDC federation (opisane w artykule o CI/CD)
• Lokalne dev: aws configure z profilem, nigdy w kodzie
• Sekrety aplikacyjne: AWS Secrets Manager lub Parameter Store

# Sprawdź czy masz stare, nierotowane klucze
aws iam list-access-keys --user-name mojeimie
# Jeśli CreateDate jest starsze niż 90 dni - rotuj!

# Rotacja klucza (limit: max 2 klucze na użytkownika)
aws iam create-access-key --user-name mojeimie
# Zaktualizuj wszędzie gdzie używasz, potem dezaktywuj stary (odwracalne)
aws iam update-access-key --user-name mojeimie --access-key-id STARY_KLUCZ --status Inactive
# Gdy wszystko działa - dopiero usuń
aws iam delete-access-key --user-name mojeimie --access-key-id STARY_KLUCZ

# git-secrets - blokuje commit z kluczami AWS
# brew install git-secrets  (macOS)
git secrets --install
git secrets --register-aws

Błąd #5: Zbyt duże instancje EC2 (overprovisioning)

Typowa sytuacja: "nie wiem ile potrzebuję, wezmę m5.xlarge dla pewności". W efekcie instancja używa 5-15% CPU i marnujesz $100/mc. Pomnóż przez 10 instancji i 12 miesięcy.

Rozwiązanie

1. Zacznij od mniejszej instancji i monitoruj metryki
2. Sprawdzaj AWS Compute Optimizer - darmowa rekomendacja right-sizing
3. Użyj Reserved Instances lub Savings Plans dla stałych workloadów (do 72% taniej)
4. Rozważ Spot Instances dla batch jobs (do 90% taniej)

# Sprawdź rekomendacje Compute Optimizer
aws compute-optimizer get-ec2-instance-recommendations \
  --instance-arns arn:aws:ec2:eu-central-1:123456789:instance/i-0abc123

# Sprawdź średnie CPU za ostatni tydzień
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-0abc123 \
  --start-time $(date -u -d "-7 days" +%Y-%m-%dT%H:%M:%S) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
  --period 3600 \
  --statistics Average

Więcej o typach instancji i optymalizacji w poradniku EC2.

Błąd #6: Brak tagowania zasobów

Bez tagów nie wiesz: kto to stworzył, do jakiego projektu należy, czy można to usunąć. Za 6 miesięcy masz 50 "orphaned" zasobów, które nikt nie chce usunąć "bo może coś robią".

Rozwiązanie

Minimum obowiązkowych tagów:

# Wymuś tagowanie przez AWS Organizations - SCP
{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "RequireTags",
    "Effect": "Deny",
    "Action": ["ec2:RunInstances", "rds:CreateDBInstance"],
    "Resource": "*",
    "Condition": {
      "Null": {
        "aws:RequestTag/Environment": "true",
        "aws:RequestTag/Project": "true"
      }
    }
  }]
}

# Znajdź niezatagowane instancje EC2
aws ec2 describe-instances \
  --filters "Name=tag-key,Values=Environment" \
  --query "Reservations[].Instances[].InstanceId" \
  --output text
# Porównaj z pełną listą aby znaleźć brakujące

Błąd #7: Security Groups z regułą 0.0.0.0/0 na SSH/RDP

Otwarcie portu 22 (SSH) lub 3389 (RDP) na cały świat (0.0.0.0/0) to jak zostawienie otwartych drzwi z karteczką "wejdźcie". Boty skanują każdy publiczny IP na te porty - jeśli masz słabe hasło, to kwestia godzin.

Rozwiązanie

• Używaj AWS Systems Manager Session Manager zamiast SSH (zero otwartych portów)
• Jeśli musisz SSH - ogranicz do swojego IP: twoj.ip/32
• Używaj EC2 Instance Connect - tymczasowe klucze SSH (60 sekund ważności)
• Nigdy nie otwieraj RDP/SSH na 0.0.0.0/0, nawet "na chwilę"

# Znajdź Security Groups z otwartym SSH na świat
aws ec2 describe-security-groups \
  --filters \
    Name=ip-permission.from-port,Values=22 \
    Name=ip-permission.to-port,Values=22 \
    Name=ip-permission.cidr,Values=0.0.0.0/0 \
  --query "SecurityGroups[].{ID:GroupId,Name:GroupName}"

# Połącz się przez Session Manager (zero otwartych portów)
aws ssm start-session --target i-0abc123

Pełny poradnik bezpieczeństwa w artykule o IAM.

Błąd #8: Brak retencji na CloudWatch Logs

Domyślnie CloudWatch Logs przechowuje logi na zawsze. Na zawsze = koszty rosną w nieskończoność. Po roku masz terabajty logów, z których 99% nigdy nie przeczytasz. Koszt storage: $0.03/GB/mc.

Rozwiązanie

# Sprawdź retencję na wszystkich log grupach
aws logs describe-log-groups \
  --query "logGroups[?!retentionInDays].{Name:logGroupName,Size:storedBytes}" \
  --output table

# Ustaw retencję 30 dni na wszystkich grupach bez retencji
for group in $(aws logs describe-log-groups \
  --query "logGroups[?!retentionInDays].logGroupName" --output text); do
  aws logs put-retention-policy \
    --log-group-name "$group" \
    --retention-in-days 30
  echo "Set 30d retention on: $group"
done

Rekomendacja: dev = 7 dni, staging = 14 dni, produkcja = 30-90 dni. Jeśli potrzebujesz archiwum - eksportuj do S3 Glacier ($0.004/GB/mc).

Błąd #9: Brak Multi-AZ na produkcji

Single-AZ deployment to jeden serwer w jednym data center. Gdy ta AZ ma problem (a to się zdarza), Twoja aplikacja pada. Multi-AZ to redundancja, która kosztuje więcej, ale pozwala Ci spać spokojnie.

Rozwiązanie

• RDS: włącz Multi-AZ (automatyczny failover w ~60-120s)
• EC2: Auto Scaling Group z instancjami w minimum 2 AZ
• ALB: automatycznie multi-AZ (wystarczy dodać subnety z różnych AZ)
• DynamoDB: automatycznie multi-AZ (zero konfiguracji)
• S3: automatycznie multi-AZ (dane w minimum 3 AZ)

# Sprawdź czy RDS jest Multi-AZ
aws rds describe-db-instances \
  --query "DBInstances[].{ID:DBInstanceIdentifier,MultiAZ:MultiAZ,AZ:AvailabilityZone}"

# Włącz Multi-AZ na istniejącej instancji
aws rds modify-db-instance \
  --db-instance-identifier moja-apka-db \
  --multi-az \
  --apply-immediately

Architekturę multi-AZ opisałem szczegółowo w artykule o architekturze webowej.

Błąd #10: Ignorowanie AWS Trusted Advisor i Security Hub

AWS daje Ci darmowe narzędzia, które wykrywają 80% problemów z tej listy. Trusted Advisor sprawdza bezpieczeństwo, koszty, wydajność, limity. Security Hub agreguje znaleziska z GuardDuty, Inspector, Config (uwaga: od 2025 ta klasyczna wersja usługi widnieje w konsoli jako Security Hub CSPM). Większość ludzi ich nie włącza.

Rozwiązanie

1. Wejdź w Trusted Advisor i napraw wszystkie czerwone flagi (free tier ma 7 core checks)
2. Włącz Security Hub z AWS Foundational Security Best Practices standard
3. Włącz GuardDuty - wykrywa podejrzaną aktywność (crypto mining, unauthorized access)
4. Przeglądaj wyniki raz w tygodniu (15 minut na naprawienie znalezisk)

# Włącz GuardDuty
aws guardduty create-detector --enable

# Włącz Security Hub
aws securityhub enable-security-hub \
  --enable-default-standards

# Sprawdź findings
aws securityhub get-findings \
  --filters '{"SeverityLabel":[{"Value":"CRITICAL","Comparison":"EQUALS"}]}' \
  --max-items 10

Checklist - szybki audit Twojego konta AWS

Przejdź tę listę punkt po punkcie. Każde "NIE" to tykająca bomba:

FAQ - najczęstsze pytania o błędy na AWS

Co dalej?

1. Przejdź checklist wyżej i napraw wszystkie "NIE" - zacznij od MFA i budget alert.
2. Przeczytaj poradnik IAM aby zrozumieć model uprawnień AWS.
3. Skonfiguruj CloudWatch alarmy na kluczowe metryki.
4. Włącz GuardDuty i Security Hub - to Twoi automatyczni audytorzy.
5. Zaplanuj przegląd bezpieczeństwa raz w miesiącu (30 minut wystarczy).

Bezpieczeństwo i dobre praktyki to nie jednorazowy projekt - to nawyk. 15 minut tygodniowo na przegląd Trusted Advisor to lepsza inwestycja niż 15 godzin na naprawianie incydentu.