AWS Managed Services vs samodzielne utrzymanie - schemat decyzyjny

„Managed” w ekosystemie AWS oznacza, że Amazon przejmuje odpowiedzialność za określoną warstwę operacyjną - patching, wysoką dostępność (high availability), backup, skalowanie. Ty konfigurujesz i używasz. AWS utrzymuje.

Brzmi świetnie. Problem polega na tym, że granica odpowiedzialności (Shared Responsibility Model) przebiega inaczej dla każdej usługi, a koszty usług zarządzanych nie są zawsze niższe niż przy samodzielnym utrzymaniu.

Co AWS rozumie przez „managed”

AWS dzieli odpowiedzialność na warstwy. Im bardziej zarządzana usługa, tym mniej kontrolujesz - ale też mniej musisz utrzymywać.

Kluczowa obserwacja: nie istnieje binarne „managed vs unmanaged”. Jest spektrum. EKS to zarządzany control plane, ale worker nodes to nadal Twoje EC2 (chyba że używasz Fargate). RDS to zarządzana baza danych, ale Ty nadal odpowiadasz za query optimization, schema design i politykę retencji backupów.

Tabela decyzyjna: kiedy zarządzane, kiedy samodzielnie

Poniższa tabela obejmuje najczęściej spotykane decyzje architektoniczne przy migracji do AWS.

Bazy danych

Kiedy zarządzane wygrywa: Zespół ≤5 inżynierów, brak dedykowanego DBA, standardowy workload OLTP, potrzeba backupów spełniających wymagania audytu.

Kiedy samodzielne wygrywa: Intensywny workload OLAP wymagający strojenia, egzotyczne rozszerzenia PostgreSQL, workload wymagający kontroli nad WAL shipping, budżet poniżej $500/mo za bazę.

Kontenery i orkiestracja

Kiedy Fargate wygrywa: Proste mikroserwisy bez specjalnych wymagań sieciowych, zespoły bez doświadczenia z Kubernetes, workload z przewidywalnym obciążeniem.

Kiedy EKS samodzielnie wygrywa: GPU workload, potrzeba Spot Instances z Karpenter, niestandardowa konfiguracja sieci (service mesh, eBPF), konieczność optymalizacji kosztów poniżej $100/mo na serwis.

Kolejki i przetwarzanie zdarzeń

Kiedy zarządzane wygrywa: Prawie zawsze dla standardowych wzorców sterowanych zdarzeniami (event-driven). SQS/SNS/EventBridge to jedna z najtańszych i najbardziej niezawodnych usług AWS.

Kiedy samodzielne wygrywa: Strumieniowe przetwarzanie zdarzeń z zachowaniem kolejności i możliwością powtórzenia (Kafka), integracja z istniejącym ekosystemem on-premise, specyficzne protokoły (AMQP z RabbitMQ).

Ukryte koszty usług zarządzanych AWS

Zarządzane nie oznacza tanie. Trzy pułapki, które widzimy najczęściej:

1. Transfer danych przez NAT Gateway

Usługi zarządzane (RDS, ElastiCache, OpenSearch) umieszczone w prywatnych podsieciach wymagają NAT Gateway do komunikacji z innymi usługami AWS spoza VPC. Koszt NAT: $0.045/GB + $0.045/h.

Dla workload przetwarzającego 500 GB/mo przez NAT to dodatkowe $45/mo - często więcej niż sama usługa w niższym planie cenowym.

Rozwiązanie: VPC Endpoints (Gateway Endpoints dla S3/DynamoDB - darmowe, Interface Endpoints dla pozostałych - $0.01/GB). Szczegóły w naszym runbooku o kosztach NAT Gateway.

2. Opłaty za zapomniane snapshoty

RDS automated backups kosztują $0 do momentu, w którym przekroczysz objętość bazy. Ale ręczne snapshoty (tworzone przed maintenance, przy testach) zostają na zawsze i kosztują $0.095/GB/mo.

Typowy scenariusz: zespół tworzy 3-4 snapshoty „na wszelki wypadek” przy każdym release. Baza 200 GB × 4 snapshoty = 800 GB × $0.095 = $76/mo za zapomniane snapshoty.

3. Premium za Multi-AZ, którego nie potrzebujesz

RDS Multi-AZ podwaja koszt instancji. Dla środowiska deweloperskiego lub przedprodukcyjnego (staging) to wyrzucone pieniądze. A domyślne tutoriale AWS zawsze włączają Multi-AZ.

Sprawdź: czy Twoje bazy danych na dev/staging naprawdę potrzebują 99.95% SLA?

Kiedy samodzielne utrzymanie wygrywa - scenariusze z praktyki

Scenariusz 1: Startup z 3 inżynierami i budżetem $2000/mo

Paradoksalnie, dla bardzo małych zespołów EC2 + Docker Compose bywa prostsze do postawienia niż pełna orkiestracja usługami zarządzanymi.

Dlaczego? Bo ECS/Fargate wymaga zrozumienia task definitions, service discovery, IAM roles for tasks, ALB target groups, CloudWatch log groups. Dla 2-3 kontenerów to więcej złożoności niż docker-compose na jednym EC2.

Ale uwaga: produkcja na gołym EC2 to nie jest dobre wykorzystanie chmury. Brak autoskalowania, brak automatycznego failover, brak separacji warstw. To rozwiązanie „na start” - nie docelowe. Jeśli zespół nie ma kompetencji, żeby przejść z Docker Compose na ECS/Fargate, to sygnał, że warto zaangażować zewnętrzny zespół DevOps, który postawi architekturę prawidłowo od początku - koszt konsultacji zwróci się w unikniętych problemach przy skalowaniu.

Punkt przejścia: Gdy przekraczasz 5 serwisów lub potrzebujesz automatycznego skalowania, czas na usługi zarządzane.

Scenariusz 2: Workload AI/ML z GPU

Dla dużych wolumenów (50 000+ zapytań miesięcznie) samodzielne wnioskowanie (inference) na EKS z Karpenter i Spot GPU instances może być 60-70% tańsze niż SageMaker.

Ale dla niższych wolumenów - Bedrock wygrywa finansowo. Płacisz za token, bez kosztów stałych instancji GPU. Próg opłacalności samodzielnego wnioskowania zaczyna się dopiero przy przewidywalnym, ciągłym obciążeniu, gdzie instancja GPU jest wykorzystana >60% czasu.

# Porównanie kosztów miesięcznych (us-east-1, sierpień 2026)
# Próg opłacalności: ~50K+ zapytań/mo przy średnim rozm. kontekstu

# SageMaker ml.g5.xlarge (1x A10G, 24GB VRAM):
#   On-Demand: $1.006/h × 730h = $734/mo (stały koszt niezależnie od ruchu)

# EKS + Spot g5.xlarge:
#   Spot price avg: $0.35/h × 730h = $255/mo
#   + EKS cluster fee: $73/mo
#   = $328/mo (55% taniej, ale wymaga zespołu ops)

# Bedrock (Claude 3.5 Haiku):
#   50K zapytań × 2K tokenów input × $0.0008/1K = $80/mo
#   (brak kosztów stałych, idealne dla niskich wolumenów)

Wniosek: Bedrock dla prototypów i niskich wolumenów. EKS + Spot GPU dopiero gdy workload jest przewidywalny, ciągły i przekracza 50K zapytań miesięcznie. SageMaker to środek - wygodniejszy niż surowe EKS, droższy niż Bedrock.

Kompromis samodzielnego: Zarządzasz procesem opróżniania nodów (node draining), graceful shutdown i przełączaniem na On-Demand. Wymaga Karpenter + odpowiedniej konfiguracji obsługi przerwań (interruption handling).

Scenariusz 3: Regulacje wymagające audytu konfiguracji - niuans

Częsty mit: „RDS nie spełnia wymagań NIS2/DORA/FCA, bo nie kontroluję konfiguracji”. W rzeczywistości AWS posiada certyfikacje SOC 2, ISO 27001, jest zgodny z wymogami DORA i NIS2 na poziomie infrastruktury. RDS Parameter Groups są wersjonowane w Terraform/CloudFormation, widoczne w AWS Config i audytowalne przez AWS CloudTrail.

Samodzielne utrzymanie PostgreSQL z postgresql.conf w Git nie jest bardziej zgodne z regulacjami niż RDS - wręcz przeciwnie, bo tracisz automatyczne szyfrowanie, zarządzanie certyfikatami i wbudowany audyt dostępu.

Jedyny realny scenariusz, w którym samodzielne utrzymanie ma przewagę regulacyjną: gdy organizacja wymaga pełnej izolacji (dedicated hosts, custom HSM integration) lub korzysta z parametrów PostgreSQL niedostępnych w RDS Parameter Groups (np. shared_preload_libraries z niestandardowymi rozszerzeniami).

Kiedy zarządzane wygrywa - scenariusze z praktyki

Scenariusz 1: Zespół 10-20 osób, priorytet to szybkie dostarczenie

Każda godzina spędzona na patchowaniu PostgreSQL, konfiguracji Patroni czy debugowaniu opóźnień replikacji to godzina nie spędzona na produkcie. Dla zespołu bez dedykowanego SRE/DBA, usługi zarządzane kupują czas inżynieryjny.

Szacunek: utrzymanie samodzielnego PostgreSQL HA to ~8-12h/mo inżyniera (patching, monitoring, obsługa incydentów, upgrade). Przy stawce €100/h = €800-1200/mo ukrytego kosztu.

RDS Multi-AZ za ~$700/mo jest tańszy niż te ukryte godziny.

Scenariusz 2: Migracja lift-and-shift z wyznaczonym terminem

Przy migracji z twardym terminem (kończy się umowa z serwerownią, end-of-support) - usługi zarządzane pozwalają przenieść workload bez przeprojektowania:

1. EC2 + PostgreSQL on-premise → RDS (schema dump + DMS CDC)
2. VM z aplikacją → ECS Fargate (konteneryzacja + task definition)
3. NFS share → EFS (mount point compatibility)

Zero zmian w aplikacji. Termin dotrzymany. Optymalizacja - potem.

Dokładny proces opisujemy w przewodniku migracji do AWS.

Scenariusz 3: Wymaganie SLA 99.99%

Samodzielne zbudowanie wieloregionowego przełączenia awaryjnego bazy danych z RPO < 1s to projekt na miesiące. Aurora Global Database robi to od razu. Dla workload wymagających najwyższej dostępności, usługi zarządzane to jedyna rozsądna opcja (chyba że masz zespół 5+ SRE).

Schemat decyzyjny - 5 pytań przed wyborem

Zanim zdecydujesz, czy dla konkretnej usługi wybrać model zarządzany czy samodzielny, odpowiedz na te pytania:

1. Czy masz dedykowany zespół ops/SRE? Jeśli nie → zarządzane.
2. Czy workload wymaga niestandardowej konfiguracji niedostępnej w usłudze zarządzanej? (specjalne rozszerzenia DB, parametry jądra, nietypowa konfiguracja sieci) Jeśli tak → samodzielne.
3. Jaki jest Twój budżet vs. koszt inżyniera? Jeśli usługa zarządzana kosztuje mniej niż 10h/mo inżyniera → zarządzane.
4. Czy regulacje wymagają pełnej izolacji lub niestandardowych parametrów? Jeśli RDS + AWS Config + CloudTrail spełnia wymagania audytu (a w 95% przypadków spełnia) → zarządzane. Jeśli potrzebujesz dedicated hosts lub niestandardowych shared_preload_libraries → samodzielne.
5. Czy planujesz strategię wielochmurową lub wyjścia? Jeśli tak → samodzielne (Kubernetes, PostgreSQL) daje przenośność. Zarządzane = uzależnienie od dostawcy.

Ścieżka ewolucji: od samodzielnego do zarządzanego (i z powrotem)

Typowa ścieżka dojrzałej organizacji wygląda tak:

Faza 1 (startup): Docker Compose na EC2
  ↓ wzrost do 5+ serwisów
Faza 2 (wzrost): ECS Fargate + RDS
  ↓ wzrost do 20+ serwisów, potrzeba optymalizacji
Faza 3 (skala): EKS + Karpenter + RDS (lub Aurora)
  ↓ specjalizacja, wymagające workload
Faza 4 (optymalizacja): Mix - zarządzane tam gdzie sens,
  samodzielne tam gdzie potrzeba kontroli/oszczędności

Nie ma jednej „poprawnej” odpowiedzi. Jest odpowiedź poprawna dla Twojego etapu, zespołu i budżetu.

Nasza perspektywa

W Devopsity zarządzamy infrastrukturą klientów na obu modelach. Pomagamy wybrać, zaimplementować i - co najważniejsze - zoptymalizować koszty niezależnie od wybranej ścieżki.

Jeśli stoisz przed decyzją „zarządzane czy samodzielne” i potrzebujesz zewnętrznej perspektywy - umów się na bezpłatną konsultację. Przejdziemy przez Twój workload i zaproponujemy architekturę, która balansuje koszty, kontrolę i czas inżynieryjny.

Podsumowanie

Kluczowa zasada: usługi zarządzane kupują czas inżynieryjny kosztem kontroli i elastyczności. Samodzielne utrzymanie kupuje kontrolę kosztem czasu inżynieryjnego. Wybierz w zależności od tego, czego masz więcej - ludzi czy budżetu.