AWS Well-Architected Review - jak się przygotować i co naprawdę sprawdzamy

Czym jest AWS Well-Architected Review

WAFR to ustrukturyzowany przegląd architektury chmurowej AWS oparty na 6 filarach:

1. Doskonałość operacyjna - jak zarządzasz i monitorujesz systemy
2. Bezpieczeństwo - ochrona danych, uprawnień i infrastruktury
3. Niezawodność - odporność na awarie, odtwarzanie po incydentach
4. Wydajność - efektywne wykorzystanie zasobów obliczeniowych
5. Optymalizacja kosztów - eliminacja marnotrawstwa, dopasowanie wydatków do wartości
6. Zrównoważony rozwój - minimalizacja wpływu na środowisko

Przegląd prowadzi certyfikowany partner AWS (jak Devopsity - jesteśmy w programie od 2024). Wyniki trafiają do AWS Well-Architected Tool, gdzie AWS je widzi i na ich podstawie oferuje zachęty (aktualnie 10% zniżki na nowe lub zmodyfikowane zasoby powiązane z naprawami).

Problem z „typowym” WAFR

Powiedzmy wprost: wiele przeglądów Well-Architected w branży to teatr. Oto dlaczego:

Przegląd na 2-3 godziny. Partner przechodzi przez kwestionariusz w ekspresowym tempie, zaznacza odpowiedzi w narzędziu i generuje raport. Zero głębi, zero kontekstu biznesowego.

Nacisk na liczbę HRI, nie na wpływ. Do końca 2025 AWS oferował kupon $5000 na naprawy, jeśli remediacja wykazała ≥45% naprawionych elementów wysokiego ryzyka. To stworzyło patologię: partnerzy i klienci optymalizowali pod liczbę rozwiązanych HRI (aby dostać kupon), nie pod realne ryzyka i potrzeby.

Raport bez wykonalnych rekomendacji. „Zalecamy wdrożenie Multi-AZ” - bez kontekstu, czy to ma sens dla środowiska deweloperskiego za $200/miesiąc.

Brak połączenia z biznesem. Standardowy WAFR pyta o techniczne best practices, ale nie wiąże ich z priorytetami biznesowymi: co jest krytyczne dla przychodów, co blokuje zgodność regulacyjną, co generuje największy koszt.

Jak powinien wyglądać porządny WAFR

Przygotowanie (przed przeglądem)

Zanim partner pojawi się na pierwszym spotkaniu, powinien znać:

Od Ciebie:

• Architektura - diagram infrastruktury i/lub aplikacji (nawet rysowany na serwetce), lista kluczowych serwisów AWS, ilość środowisk
• Priorytety - co jest ważniejsze: koszt, bezpieczeństwo, niezawodność? Gdzie boli najbardziej?
• Kontekst regulacyjny - czy podlegasz SOC 2, ISO 27001, RODO, NIS2, PCI DSS?
• Planowane zmiany - migracja, skalowanie, nowy produkt? To zmienia perspektywę przeglądu

Dokumenty do przygotowania:

• Dostęp do kont AWS (read-only IAM role wystarczy do przeglądu)
• Lista osób do wywiadów (architekt, ops/SRE, bezpieczeństwo, finanse)
• Istniejąca dokumentacja architektury (jeśli jest)
• Ostatni rachunek AWS (12 miesięcy Cost Explorer export - idealnie)

Przebieg przeglądu

Co dostaniesz na wyjściu

1. Raport z priorytetyzowanymi wynikami - każdy element z oceną wpływu biznesowego i pracochłonności naprawy
2. Aktualizacja AWS WA Tool - wyniki zarejestrowane oficjalnie, widoczne dla AWS
3. Plan naprawczy - top 5-10 wykrytych problemów z konkretnymi krokami do wykonania
4. Kwalifikacja do 10% zniżki - po wdrożeniu napraw, AWS oferuje zniżkę na powiązane zasoby

Gdzie standardowy WAFR nie wystarcza

Standardowy przegląd pokrywa zakres - 6 filarów, setki pytań, ogólny obraz. Ale dla większości organizacji problemem nie jest „brak wiedzy o wszystkim” - jest głębokość w jednym lub kilku konkretnych obszarzach.

Typowe sytuacje:

• CTO mówi: „rachunek za AWS rośnie o 20% kwartalnie i nikt nie wie dlaczego” - potrzebuje pogłębionej analizy kosztowej, nie ogólnego filaru Cost Optimisation
• Zespół przygotowuje się do ruchu 10x na Black Friday - potrzebuje pełnej analizy niezawodności i gotowości do skali, nie pytania „czy macie Multi-AZ?”
• Firma przechodzi audyt SOC 2 za 3 miesiące - potrzebuje szczegółowej analizy bezpieczeństwa z mapowaniem na kontrole, nie listy HRI

Dlatego rozszerzamy standardowy WAFR o pogłębione przeglądy tematyczne - skupione na jednym lub kilku obszarach, ale dużo głębsze niż standardowy filar.

Pogłębiony przegląd FinOps - gdy rachunek jest problemem numer jeden

Standardowy filar Cost Optimisation pyta: „czy używacie Savings Plans?”, „czy monitorujecie nieużywane zasoby?”. To ważne pytania, ale nie dają odpowiedzi na pytanie: gdzie dokładnie uciekają pieniądze i dlaczego.

Nasz pogłębiony przegląd FinOps obejmuje:

Analiza rachunku (nie tylko Cost Explorer)

# Eksport szczegółowego billing za 12 miesięcy
aws ce get-cost-and-usage \
  --time-period Start=2025-06-01,End=2026-06-01 \
  --granularity MONTHLY \
  --metrics BlendedCost UnblendedCost \
  --group-by Type=DIMENSION,Key=SERVICE \
  --output json > billing-12mo.json

# Identyfikacja top 5 usług rosnących najszybciej
jq '.ResultsByTime | map(.Groups[] | {service: .Keys[0], cost: .Metrics.BlendedCost.Amount}) | group_by(.service) | map({service: .[0].service, costs: map(.cost | tonumber)})' billing-12mo.json

Mapowanie kosztów na intencje biznesowe

Każda złotówka wydana na AWS powinien dać się powiązać z wartością biznesową. Tworzymy mapę:

Architekturalne źródła nadmiernych kosztów

Nie szukamy tylko przewymiarowanych instancji. Szukamy wzorców architektonicznych generujących nieproporcjonalny koszt:

• Transfer danych przez NAT Gateway zamiast VPC Endpoints
• Retencja logów w CloudWatch zamiast S3 + Athena
• Bazy danych Multi-AZ na środowiskach nieprodukcyjnych
• Brak Spot Instances na workload tolerujących przerwania
• Savings Plans kupione na złe typy instancji lub regiony

Efekt: nie „zaoszczędź 5% przez right-sizing”, ale „zaoszczędź 30-40% przez zmianę wzorców architektonicznych”.

Więcej o podejściu FinOps w naszym przewodniku wdrażania modelu showback.

Pogłębiony przegląd niezawodności - gotowość produkcyjna do skali

Standardowy filar Reliability pyta: „czy macie kopie zapasowe?”, „czy testujecie odtwarzanie?”. Nasz pogłębiony przegląd idzie dalej:

Identyfikacja pojedynczych punktów awarii (SPOF)

Mapujemy każdy element architektury pod kątem: co się stanie, jeśli to przestanie działać?

Self-hosted vs zarządzane - przegląd decyzji

Dla każdego komponentu self-hosted oceniamy: czy samodzielne utrzymanie jest uzasadnione, czy tylko historyczne? Typowe znaleziska:

• Self-hosted Redis → ElastiCache (HA + backup za $50/mo więcej, ale bez ryzyka SPOF)
• Self-hosted Jenkins → GitHub Actions (zero utrzymania, auto-skalowanie)
• Self-hosted Prometheus → Grafana Cloud (bez OOM, bez storage management)

Szczegółowe porównanie zarządzanych vs samodzielnych usług opisujemy w naszym przewodniku po usługach zarządzanych AWS.

Testy obciążeniowe - nie „czy”, ale „jak”

Nie pytamy „czy robicie testy obciążeniowe?”. Pytamy:

• Jaki jest oczekiwany ruch na Black Friday / peak season?
• Czy architektura skaluje się liniowo czy ma próg wytrzymałości?
• Gdzie jest wąskie gardło: baza, compute, sieć, rate limit API?
• Czy mieliście już incydent wydajnościowy? Co było przyczyną?

Pogłębiony przegląd bezpieczeństwa - governance, sieć, dane

Standardowy filar Security pyta: „czy szyfrujecie dane?”, „czy macie MFA?”. Nasz pogłębiony przegląd obejmuje:

Governance na poziomie organizacji

• AWS Organizations - struktura kont, polityki SCP, separacja środowisk
• IAM Identity Center (SSO) - konfiguracja, przypisania, compliance z zasadą least privilege
• Config Rules i conformance packs - automatyczne wykrywanie odchyleń
• CloudTrail - centralny logging, analiza dostępów, wykrywanie anomalii

Bezpieczeństwo sieci

• VPC design: segmentacja, Security Groups, NACLs, reguły ingress/egress
• Dostęp publiczny: które zasoby są wystawione na internet i czy powinny być?
• Połączenia wychodzące: czy ruch wychodzący jest kontrolowany i monitorowany?

Ochrona danych

• Szyfrowanie w spoczynku (at rest) i w tranzycie (in transit)
• Zarządzanie kluczami (KMS): polityki rotacji, dostępu, audytu
• Klasyfikacja danych: co jest wrażliwe, gdzie się znajduje, kto ma dostęp

Gotowość do audytu zgodności (compliance)

Jeśli przygotowujesz się do SOC 2, ISO 27001, NIS2 lub DORA - mapujemy wykryte problemy bezpośrednio na wymagane kontrole:

Jak wybrać zakres przeglądu

Nie każda organizacja potrzebuje pogłębionego przeglądu we wszystkich trzech obszarach jednocześnie. Wybierz na podstawie bieżącej sytuacji:

Co dalej po przeglądzie

Przegląd bez działania to strata czasu. Oto jak zapewniamy, że wyniki przełożą się na realne zmiany:

1. Natychmiastowe naprawy (tydzień 1-2) - top 3-5 HRI, które możemy naprawić od razu (np. wyłączenie Multi-AZ na staging, dodanie VPC Endpoints, włączenie KMS rotation)
2. Plan naprawczy na 30-60-90 dni - pozostałe wykryte problemy z harmonogramem i przypisanym właścicielem
3. Milestone w AWS WA Tool - po każdej partii napraw tworzymy milestone, dokumentujący postęp
4. Kwalifikacja do zniżki - AWS oferuje 10% zniżki na zasoby bezpośrednio powiązane z naprawami. Śledzimy to za Ciebie
5. Następny cykl - WAFR to nie jednorazowa akcja. Rekomendujemy kolejny przegląd za 3-6 miesięcy

Nasza perspektywa

W Devopsity przeprowadzamy przeglądy Well-Architected od 2024 roku. Widzimy, że standardowy WAFR daje wartość jako punkt wyjścia - ale prawdziwa zmiana przychodzi z pogłębionych przeglądów skupionych na konkretnym bólu: kosztach, niezawodności lub bezpieczeństwie.

Jeśli Twoje środowisko AWS wymaga przeglądu - czy to standardowego WAFR, czy pogłębionego w konkretnym obszarze - sprawdź naszą usługę Well-Architected Review lub umów się na bezpłatną konsultację.