Optymalizacja AWS Lambda: Jak znaleźć idealną ilość pamięci RAM z aws-lambda-power-tuning

Paweł Zubkiewicz
2026/01/28
Czas czytania: 4 min.
Programowanie, Lambda, Optymalizacja kosztów

Optymalizacja AWS Lambda

Kilka lat temu nagrałem wideo o optymalizacji funkcji Lambda i od tamtej pory regularnie wracam do tego tematu. Dlaczego? Bo wybór odpowiedniej ilości pamięci RAM to jedna z tych decyzji, która może realnie wpłynąć na Twój rachunek za AWS – w jedną lub drugą stronę.

📹 Jeśli wolisz format wideo, możesz obejrzeć mój oryginalny tutorial tutaj:

Jest to wideo z mojego, już niedostępnego, szkolenia Serverless.

Problem: Dlaczego nie możemy po prostu wybrać minimalnej pamięci?

Wielu początkujących (i nie tylko!) programistów myśli następująco:

Skoro płacę za GB-sekundy, to dam 128 MB i będzie najtaniej.

Brzmi logicznie, prawda?

Otóż nie do końca.

W AWS Lambda pamięć RAM to nie tylko pamięć – to również moc procesora. Im więcej pamięci przydzielisz, tym więcej mocy obliczeniowej otrzymujesz. Oto jak to dokładnie wygląda:

Pamięć RAM	Moc procesora (vCPU)	Uwagi
128 MB - 1,728 MB	Proporcjonalnie do 1 vCPU	Moc procesora rośnie liniowo
1,769 MB - 3,008 MB	2 vCPU	Moc procesora rośnie proporcjonalnie do ilości RAM
3,009 MB - 5,307 MB	3 vCPU	Moc procesora rośnie proporcjonalnie do ilości RAM
5,308 MB - 7,076 MB	4 vCPU	Moc procesora rośnie proporcjonalnie do ilości RAM
7,077 MB - 8,845 MB	5 vCPU	Moc procesora rośnie proporcjonalnie do ilości RAM
8,846 MB - 10,240 MB	6 vCPU	Moc procesora rośnie proporcjonalnie do ilości RAM, aż do maksa

ProTip: Zauważ, że przejście z 1,728 MB na 1,769 MB daje Ci nagle drugie vCPU! Oczywiście nie całe tylko proporcjonalnie. Jednak to może być game-changer dla aplikacji wielowątkowych. 🚀

Efekt? Funkcja z 1024 MB może wykonać się 10x szybciej niż ta z 128 MB, a ponieważ płacisz za czas wykonania, może okazać się… tańsza! 🤯

Rozwiązanie: aws-lambda-power-tuning

Zamiast ręcznie testować każdą konfigurację (co jest żmudne i czasochłonne), możemy skorzystać z genialnego narzędzia open-source: aws-lambda-power-tuning. To automatyczny system oparty na AWS Step Functions, który testuje Twoją funkcję Lambda z różnymi konfiguracjami pamięci i pokazuje dokładnie, która opcja jest optymalna.

Krok 1: Wdrożenie narzędzia

Najszybszą metodą jest wykorzystanie AWS Serverless Application Repository (SAR). Wierzcie mi, to dosłownie 3 kliknięcia:

Wchodzimy do konsoli AWS Lambda
Wybieramy Create application → Browse serverless app repository
Wyszukujemy aws-lambda-power-tuning i klikamy Deploy

Boom! 💥 Narzędzie jest gotowe. W tle AWS utworzy za Ciebie maszynę stanów (State Machine) w Step Functions wraz z wszystkimi potrzebnymi funkcjami Lambda.

ProTip: Narzędzie można też wdrożyć przez AWS SAM, Terraform czy CDK – wybierz metodę, która pasuje do Twojego workflow.

Krok 2: Przygotowanie testu

Teraz najważniejsza część – konfiguracja testu. Przechodzimy do AWS Step Functions i znajdujemy naszą nowo utworzoną maszynę stanów (nazwa zaczyna się od powerTuningStateMachine).

Klikamy Start execution i podajemy parametry w formacie JSON. Oto przykładowa konfiguracja:

{
  "lambdaARN": "arn:aws:lambda:eu-central-1:123456789012:function:MojaFunkcja",
  "powerValues": [128, 256, 512, 1024, 1536, 2048, 3008],
  "num": 50,
  "payload": {
    "userId": "12345",
    "action": "process"
  },
  "strategy": "balanced"
}

Rozbijmy to na czynniki pierwsze:

lambdaARN (wymagane): ARN funkcji Lambda, którą chcesz przetestować. Znajdziesz go w konsoli Lambda.
powerValues (opcjonalne): Lista wartości pamięci do przetestowania w MB. Jeśli nie podasz, narzędzie samo dobierze sensowny zakres. Ja zwykle testuję od 128 MB do 3008 MB (przy większych wartościach różnice są mniej widoczne).
num (wymagane): Liczba wywołań dla każdej konfiguracji. Zalecam 30-100 wywołań – zbyt mało może dać nieprecyzyjne wyniki przez zimny start (cold start), zbyt dużo niepotrzebnie wydłuży test i zwiększy koszty.
payload: Dane wejściowe dla Twojej funkcji. Bardzo ważne! Użyj realistycznych danych, które odzwierciedlają typowe obciążenie w produkcji.
strategy: To mój ulubiony parametr! Możesz wybrać:
- "cost" – znajdź najtańszą opcję
- "speed" – znajdź najszybszą opcję
- "balanced" – zrównoważony kompromis (mój faworyt)

Pełna lista parametrów znajduje się tutaj.

Krok 3: Uruchomienie i obserwacja

Po kliknięciu Start execution narzędzie zaczyna swoją magię. W tle dzieje się mniej więcej to:

Inicjalizacja – przygotowanie środowiska testowego
Wielokrotne wywołania funkcji dla każdej konfiguracji pamięci
Zbieranie metryk (czas wykonania, koszt, błędy)
Analiza wyników i wygenerowanie raportu

Ważne: Testy odbywają się na Twoim koncie AWS, więc poniesiesz niewielkie koszty (zwykle kilka centów do kilku dolarów, zależnie od liczby wywołań).

Możesz obserwować postęp w czasie rzeczywistym w graficznym interfejsie Step Functions – widać dokładnie, która konfiguracja jest aktualnie testowana. To naprawdę satysfakcjonujące! 😊

Krok 4: Analiza wyników – tutaj dzieje się magia ✨

Po zakończeniu testów (zazwyczaj trwa to kilka minut), sprawdzamy sekcję Execution output. Znajdziemy tam link do wizualizacji, który wygląda mniej więcej tak:

1	https://lambda-power-tuning.show/#[wyniki-zakodowane-base64]

Wykres pokazuje dwie krzywe:

Czas wykonania (execution time) – im niżej, tym lepiej
Koszt (cost) – im niżej, tym lepiej

I tutaj często następuje moment “aha!” 💡

W moim przypadku okazało się, że funkcja z 128 MB wykonywała się przez ~800ms i kosztowała $0.0000021 za wywołanie. Ta sama funkcja z 1024 MB wykonywała się przez ~100ms i kosztowała… $0.0000017! Czyli była szybsza i tańsza jednocześnie!

Dodatkowe funkcje, które warto znać

Porównanie architektur x86 vs ARM (Graviton)

Narzędzie wspiera też porównanie różnych architektur procesorów. Procesory ARM Graviton2 mogą być do 20% tańsze przy podobnej lub lepszej wydajności. Szczegóły jak to sprawdzić podaje wideo.

Automatyzacja w CI/CD

Prawdziwa moc tego narzędzia objawia się, gdy wdrożysz je do swojego pipeline’u CI/CD. Możesz automatycznie testować optymalizację przy każdym deploy’u i być pewnym, że Twoje funkcje zawsze działają optymalnie.

Moje osobiste przemyślenia po latach używania

Nie zgaduj, testuj! Intuicja często myli się przy optymalizacji Lambda. Dane nie kłamią.
Optymalizuj regularnie. Kod się zmienia, obciążenia rosną – warto powtarzać testy co kilka miesięcy.
Zwracaj uwagę na cold starty. Czasami większa pamięć skraca również cold start, co w niektórych scenariuszach jest bezcenne.
Pamiętaj o kontekście biznesowym. Jeśli różnica w koszcie to $2/miesiąc, ale różnica w czasie wykonania to 500ms, pomyśl co jest ważniejsze dla Twoich użytkowników.

Podsumowanie

aws-lambda-power-tuning to jedno z tych narzędzi, które powinno być w arsenale każdego, kto pracuje z AWS Lambda. Automatyzuje żmudny proces optymalizacji i dostarcza konkretnych, wymiernych danych zamiast zgadywania.

Co więcej, to świetny przykład tego, jak społeczność open-source wspiera ekosystem AWS. Narzędzie jest aktywnie rozwijane i regularnie aktualizowane o nowe funkcje.

A Ty? Testujesz już swoje funkcje Lambda pod kątem optymalizacji pamięci? Jeśli nie, to teraz masz idealną okazję, żeby zacząć! 🚀

Chcesz dowiedzieć się więcej o optymalizacji w AWS? Zostaw komentarz albo daj znać, o czym powinienem napisać następnym razem!