Kontenery w AWS - złoty środek między EC2 a Lambda

Masz już w głowie EC2 (pełna kontrola) i Lambda (zero zarządzania). Kontenery plasują się gdzieś pomiędzy. Dają Ci powtarzalność i przenośność aplikacji bez konieczności zarządzania całym systemem operacyjnym. W dzisiejszym świecie kontenery to standard, więc zrozumienie ich jest kluczowe.

Czym jest kontener?

Kontener to lekki, izolowany pakiet zawierający Twoją aplikację i wszystko, czego potrzebuje do działania: kod, runtime, biblioteki, zmienne środowiskowe. Kontener działa tak samo na laptopie dewelopera, na serwerze testowym i w produkcji.

💡 Analogia
Wyobraź sobie kontenery morskie. Niezależnie co jest w środku (meble, elektronika, odzież), każdy kontener ma ten sam standardowy rozmiar i pasuje na każdy statek, ciężarówkę czy pociąg. Docker container działa tak samo: pakujesz aplikację w standardowy format, a ona działa wszędzie.

Docker w pigułce

Docker to najpopularniejsza platforma kontenerowa. Kluczowe pojęcia:

  • Dockerfile - „przepis" na obraz: jakie komendy wykonać, co zainstalować
  • Docker Image - gotowy „szablon" kontenera (jak AMI dla EC2)
  • Docker Container - uruchomiona instancja obrazu
  • Docker Registry - magazyn obrazów (Docker Hub, Amazon ECR)

Amazon ECR (Elastic Container Registry)

ECR to zarządzany rejestr obrazów Docker w AWS. Przechowujesz tam swoje Docker images i pobierasz je do ECS/EKS. Pomyśl o nim jak o prywatnym Docker Hub zintegrowanym z AWS.

Amazon ECS (Elastic Container Service)

ECS to natywny orchstrator kontenerów AWS. Zarządza uruchamianiem, skalowaniem i monitorowaniem kontenerów.

  • Definiujesz Task Definition - jaki obraz, ile CPU/RAM, porty, zmienne
  • Tworzysz Service - ile kopii taska chcesz i jak skalować
  • ECS pilnuje, żeby zawsze działała pożądana liczba kontenerów

Amazon EKS (Elastic Kubernetes Service)

EKS to zarządzany Kubernetes w AWS. Kubernetes (K8s) to open-source'owy orkiestrator kontenerów stworzony przez Google, który stał się standardem branżowym.

  • Jeśli Twoja firma już używa Kubernetes (on-premises lub w innej chmurze), EKS to naturalna ścieżka migracji
  • Ogromny ekosystem narzędzi i community
  • Bardziej skomplikowany niż ECS, ale bardziej przenośny (multi-cloud)
ECS
  • Natywny dla AWS, prostszy w obsłudze
  • Głęboka integracja z serwisami AWS
  • Mniejsza krzywa uczenia się
  • Brak vendor lock-in? Raczej nie, to serwis AWS
EKS
  • Standard branżowy (Kubernetes)
  • Przenośność: ten sam K8s w AWS, Azure, GCP, on-prem
  • Większy ekosystem narzędzi
  • Stroma krzywa uczenia się

AWS Fargate - serverless containers

Zarówno ECS jak i EKS mogą uruchamiać kontenery na dwa sposoby:

  • Na EC2 - sam zarządzasz instancjami EC2, na których działają kontenery
  • Na Fargate - AWS zarządza infrastrukturą. Ty definiujesz tylko CPU i RAM dla kontenera

Fargate to „serverless dla kontenerów". Nie musisz provisionować, patchować ani skalować serwerów. Po prostu definiujesz ile zasobów potrzebuje Twój kontener i go uruchamiasz.

⚠️ Uwaga egzaminacyjna
Fargate to NIE jest osobny serwis orkiestracji. Fargate to „launch type" (tryb uruchamiania) dla ECS i EKS. Na egzaminie mogą pytać: „Co pozwala uruchamiać kontenery bez zarządzania serwerami?" Odpowiedź: Fargate (z ECS lub EKS).
🏢 Scenariusz: Migracja monolitu do mikroserwisów

Firma ma monolityczną aplikację Java na EC2. Chcą ją rozbić na mikroserwisy. Plan:

  • Każdy mikroserwis w osobnym kontenerze Docker
  • Obrazy przechowywane w Amazon ECR
  • Orkiestracja przez ECS z Fargate (nie chcą zarządzać serwerami)
  • ALB z path-based routing kieruje ruch do odpowiednich mikroserwisów

Korzyści: niezależne deploymentu serwisów, osobne skalowanie każdego, łatwiejsze debugowanie i mniejsze blast radius awarii.

Wybór modelu compute to jedno z najczęstszych pytań w architekturze AWS:

  • EC2 - pełna kontrola, legacy apps, specyficzne wymagania OS, długo działające procesy
  • Lambda - event-driven, krótkie zadania (do 15 min), niski ruch, prototypy
  • Kontenery (ECS/EKS + Fargate) - mikroserwisy, CI/CD, pełna kontrola nad runtime bez zarządzania OS, przenośność

W praktyce większość firm używa miksu. API na Lambda, core backend w kontenerach, legacy na EC2. Klucz to dopasowanie narzędzia do zadania.

📝 Na egzaminie
Na CLF-C02 musisz rozróżnić: ECS = natywny AWS, EKS = managed Kubernetes, Fargate = serverless launch type. ECR = rejestr Docker images. Kluczowe pytanie: „Jaką usługę wybrać do uruchomienia kontenerów bez zarządzania infrastrukturą?" → Fargate. Przećwicz w testach Akademii CloudManiak!
🧠 Podsumowanie
  • Kontenery = lekkie, izolowane pakiety z aplikacją i zależnościami
  • Docker = najpopularniejsza platforma kontenerowa
  • ECR = rejestr obrazów Docker w AWS
  • ECS = natywny orkiestrator kontenerów AWS
  • EKS = zarządzany Kubernetes w AWS
  • Fargate = serverless launch type (nie musisz zarządzać serwerami)
  • EC2 launch type = Ty zarządzasz instancjami EC2 pod kontenerami
🧪 Sprawdź się

Firma chce uruchamiać kontenery Docker bez zarządzania serwerami EC2. Co wybrać?

A ECS z EC2 launch type
B ECS z Fargate launch type
C Lambda z Docker image
Fargate to serverless launch type dla ECS (i EKS). AWS zarządza infrastrukturą, Ty definiujesz tylko wymagania kontenera (CPU, RAM). EC2 launch type wymaga zarządzania instancjami EC2.

Gdzie przechowujesz Docker images w ekosystemie AWS?

A Amazon S3
B AWS Lambda
C Amazon ECR (Elastic Container Registry)
Amazon ECR to zarządzany rejestr Docker images. Jest zintegrowany z ECS i EKS, wspiera skanowanie podatności obrazów i kontrolę dostępu przez IAM.

Firma używa Kubernetes on-premises i chce migrować do AWS. Który serwis jest naturalnym wyborem?

A Amazon EKS
B Amazon ECS
C AWS Lambda
EKS to zarządzany Kubernetes. Jeśli firma już używa K8s, migracja do EKS wymaga minimalnych zmian w konfiguracji. ECS jest natywny dla AWS i nie jest kompatybilny z Kubernetes.