EC2 vs Lambda - kiedy użyć czego?

EC2 vs Lambda - dwie filozofie compute w AWS

Amazon EC2 i AWS Lambda to dwie najpopularniejsze usługi obliczeniowe w AWS, ale reprezentują fundamentalnie różne podejścia. EC2 to klasyczny serwer wirtualny - Ty zarządzasz maszyną. Lambda to serverless - AWS zarządza wszystkim, Ty piszesz tylko kod.

Wybór między nimi to jedna z pierwszych decyzji architektonicznych, które podejmujesz przy nowym projekcie. I nie ma jednej dobrej odpowiedzi - wszystko zależy od Twojego use case. W projektach, które prowadziłem, prawie zawsze kończyło się na użyciu obu usług jednocześnie. W tym artykule pokażę konkretne scenariusze, porównanie kosztów i checklist, który pomoże Ci podjąć decyzję.

Amazon EC2 - wirtualny serwer w chmurze

EC2 (Elastic Compute Cloud) to wirtualna maszyna, którą uruchamiasz w chmurze AWS. Dostajesz pełny dostęp do systemu operacyjnego - możesz zainstalować co chcesz, skonfigurować jak chcesz i masz pełną kontrolę.

Jak działa EC2?

1. Wybierasz typ instancji (vCPU, RAM, network)
2. Wybierasz AMI (obraz systemu - Amazon Linux, Ubuntu, Windows)
3. Konfigurujesz sieć (VPC, subnet, security group)
4. Uruchamiasz i łączysz się przez SSH/RDP

# Uruchomienie instancji EC2 przez AWS CLI
aws ec2 run-instances \
  --image-id ami-0c55b159cbfafe1f0 \
  --instance-type t3.micro \
  --key-name my-key \
  --security-group-ids sg-0123456789 \
  --subnet-id subnet-0123456789

Zalety EC2

• Pełna kontrola - OS, runtime, biblioteki, konfiguracja systemu
• Brak limitu czasu wykonania - proces może działać godzinami, dniami, miesiącami
• GPU i specjalistyczny hardware - instancje p5, g5, inf2 dla ML/AI
• Stateful applications - dane na dysku EBS persistują między restartami
• Przewidywalna wydajność - brak cold startów
• Reserved Instances / Savings Plans - rabaty 30-60% przy stałym obciążeniu

Wady EC2

• Musisz zarządzać serwerem - patche, aktualizacje, monitoring
• Płacisz za idle - serwer kosztuje, nawet gdy nic nie robi
• Skalowanie wymaga konfiguracji - Auto Scaling Group, Launch Template, ALB
• Odpowiedzialność za bezpieczeństwo OS - Shared Responsibility Model

AWS Lambda - serverless compute

Lambda to zupełnie inne podejście: piszesz funkcję, wgrywasz do AWS i Lambda uruchamia ją w odpowiedzi na zdarzenia (eventy). Nie masz serwera, nie martwisz się o OS, skalowanie jest automatyczne.

Jak działa Lambda?

1. Piszesz funkcję (Python, Node.js, Java, Go, .NET, Ruby)
2. Konfigurujesz trigger (API Gateway, S3, SQS, EventBridge, CloudWatch)
3. Lambda uruchamia Twoją funkcję przy każdym evencie
4. Skaluje automatycznie - od 0 do tysięcy równoległych wykonań

# Przykład funkcji Lambda (Python)
import json

def handler(event, context):
    name = event.get("name", "World")
    return {
        "statusCode": 200,
        "body": json.dumps({"message": f"Hello, {name}!"})
    }

Zalety Lambda

• Zero zarządzania serwerem - AWS patchi, aktualizuje, skaluje
• Pay-per-use - płacisz za requesty i czas wykonania, $0 za idle
• Automatyczne skalowanie - od 0 do 1 000 równoległych wykonań (domyślnie, limit można zwiększyć do 10 000+)
• Event-driven - reaguje na S3 upload, SQS message, API request, cron
• Darmowy tier - 1M requestów + 400 000 GB-sekund/miesiąc za darmo (na zawsze, szczegóły w dokumentacji Lambda)

Wady Lambda

• Cold start - pierwsze wykonanie po nieaktywności trwa dłużej (100ms-3s zależnie od runtime)
• Limit 15 minut - funkcja nie może działać dłużej
• Limit pamięci 10 GB - nie dla heavy compute
• Brak stanu - każde wykonanie jest niezależne, potrzebujesz DynamoDB/S3 na dane
• Vendor lock-in - Twoje Lambda są ściśle związane z ekosystemem AWS
• Ograniczone debugowanie - trudniej debugować niż lokalny serwer

Porównanie szczegółowe

Porównanie kosztów - konkretne scenariusze

Scenariusz 1: API obsługujące 100 000 requestów/dzień

Zwycięzca: Lambda - taniej i zero zarządzania.

Scenariusz 2: Aplikacja webowa z bazą danych, 24/7

Zwycięzca: EC2 - przy stałym ruchu EC2 (zwłaszcza z RI) jest tańsze, bez cold startów.

Scenariusz 3: Przetwarzanie plików wgrywanych do S3

Zwycięzca: Lambda - event-driven use case, EC2 marnuje zasoby.

Kiedy wybrać EC2?

• Aplikacja działa 24/7 ze stałym obciążeniem
• Potrzebujesz pełnej kontroli nad OS (custom kernel, drivers)
• Potrzebujesz GPU (ML training, video encoding)
• Procesy trwające dłużej niż 15 minut
• Potrzebujesz dużo pamięci RAM (>10 GB)
• Stateful application z danymi na dysku
• Legacy aplikacje, które trudno przerobić na serverless
• Compliance wymaga dedykowanego hosta (EC2 Dedicated Hosts)

Kiedy wybrać Lambda?

• Event-driven processing (S3 upload, SQS message, API request)
• Nieregularny ruch (spikes i okresy bez ruchu)
• Krótkie operacje (<15 minut)
• Chcesz zero zarządzania infrastrukturą
• Mikroserwisy i API
• Cron jobs (EventBridge + Lambda)
• Startup/MVP - szybko i tanio
• Przetwarzanie danych (ETL, transformacje)

Podejście hybrydowe - najczęstsze w praktyce

W realnych projektach rzadko wybierasz "albo EC2, albo Lambda". Najczęściej używasz obu:

• Główna aplikacja na EC2 (lub ECS/EKS) - obsługuje ruch webowy 24/7
• Przetwarzanie w tle na Lambda - resize zdjęć po upload, wysyłka emaili, ETL
• Cron jobs na Lambda - raporty, cleanup, scheduled tasks
• Webhooks na Lambda + API Gateway - integracje z zewnętrznymi serwisami

# Typowa architektura hybrydowa:
# EC2 (ALB) -> główna aplikacja webowa
# S3 upload -> Lambda -> resize image -> S3
# EventBridge (cron) -> Lambda -> generate report -> SES email
# API Gateway -> Lambda -> webhook handler -> SQS -> EC2 worker

Nie musisz wybierać jednego. Używaj odpowiedniego narzędzia do odpowiedniego zadania.

Cold start - jak sobie radzić?

Cold start to największy minus Lambda. Występuje, gdy AWS musi uruchomić nowe środowisko dla Twojej funkcji (nie było wykonań od jakiegoś czasu lub przychodzi więcej ruchu niż dostępne "ciepłe" instancje).

Typowe czasy cold start:

Sposoby na minimalizację cold start:

• Provisioned Concurrency - utrzymuj N "ciepłych" instancji Lambda (kosztuje extra)
• Mniejsze paczki - im mniejszy package, tym szybszy cold start
• Wybierz Python/Node.js/Go zamiast Java/.NET
• SnapStart (Java, Python, .NET) - AWS cache'uje zainicjalizowane środowisko (dla Javy bez dopłat, dla Pythona i .NET dodatkowo płatny)

Podsumowanie - decision tree

1. Czy zadanie trwa dłużej niż 15 minut? -> EC2
2. Czy potrzebujesz GPU? -> EC2
3. Czy to event-driven (reaguje na zdarzenia)? -> Lambda
4. Czy ruch jest nieregularny z okresami zero? -> Lambda
5. Czy to startup/MVP i chcesz szybko? -> Lambda
6. Czy to stały ruch 24/7? -> EC2 (taniej z RI/SP)
7. Nie wiesz? -> Zacznij od Lambda, migruj do EC2 gdy potrzeba

Następny krok

Jeśli dopiero zaczynasz z AWS, sprawdź nasz przewodnik jak zacząć z AWS.

Chcesz nauczyć się obu usług w praktyce? W naszym kursie AWS od podstaw przeprowadzi Cię przez uruchomienie EC2 i napisanie pierwszej funkcji Lambda krok po kroku.

Sprawdź też ile to kosztuje: Ile kosztuje AWS? - porównanie kosztów EC2 i Lambda w różnych scenariuszach. A jeśli chcesz poznać konteneryzację, przeczytaj Docker dla początkujących.