AWS Lambda: Tek Amaçlı Fonksiyonlar mı, Lambdalith mi?

Problem#

Bir ekip AWS Lambda üzerinde HTTP API kurarken, erken alınan bir karar sonrasında gelen her şeyin şeklini sessizce belirler: kaç fonksiyon deploy edileceği. Tutorial’lar bir route’u bir fonksiyona eşler, ekipler de bunu kopyalar ve servis başına 60 fonksiyona ulaşır; her birinin kendi IAM rolü, bundling yapılandırması ve dağılmış bir template’in bir dilimi vardır. Konsolidasyon tepkisi buna bir “Lambdalith” ile yanıt verir: servis başına tek fonksiyon, içinde in-process bir router çalıştırır. Benim duruşum bu tepkinin tam tersi. Varsayılan olarak single-purpose fonksiyonlar seçin (route başına bir, event başına bir) ve single-domain Lambdalith’i bir başlangıç noktası değil, hak ettiğiniz bir konsolidasyon olarak görün. Önce spektrum gelir, sonra bu spektrumda nereye yerleşeceğinizi belirleyen platform güçleri (cold start, concurrency, IAM, observability).

Karar kolayca yanlış verilir çünkü single-purpose aleyhine sayılan maliyetler gürültülüdür, konsolidasyonun maliyetleri ise sessiz. Fonksiyon sprawl’ı konsolunuzda ilk gün görünür. Bir Lambdalith’in yarattığı paylaşılan concurrency havuzu ise yalnızca production’da bir route ısındığında görünür. Bu yüzden naif okuma birleştirmeyi destekler; oysa doğrusu tam tersidir.

Burada işin çoğunu yapan tek bir ayrım var. “Single responsibility” bir kod ilkesidir: her handler’ı odaklı tutun. “Kaç fonksiyon deploy edileceği” ise deploy birimleriyle ilgili bir topoloji kararıdır. Bunlar birbirinden bağımsız. Bir Lambdalith, router’ının arkasında kusursuz biçimde single-responsibility handler’lar tutarken tek bir deploy birimi olabilir; bir single-purpose fonksiyon ise karmakarışık bir god-handler tutabilir. Her zaman single-responsibility kod istersiniz, varsayılan olarak da single-purpose deploy birimleri. İkisini karıştırmak, “AWS artık monolit’leri onaylıyor” argümanını olduğundan güçlü gösteren şeydir. Onları ayrı tutun, gerilimin çoğu çözülür.

Granülerlik Spektrumu#

Granülerlik tek bir eksen üzerindedir; en çok fonksiyondan en aza doğru. Onu üç adlandırılmış nokta sabitler.

• Single-purpose (nano-fonksiyon): route veya aksiyon başına bir Lambda. POST /orders ve GET /orders/{id} ayrı fonksiyonlardır. Maksimum izolasyon, maksimum sayı. Varsayılan budur.
• Single-scope: resource veya özellik başına bir Lambda. Tüm /orders/* tek bir fonksiyonda yaşar. Daha ılımlı konsolidasyon; bir orta yol.
• Single-domain (Lambdalith): bounded context başına bir Lambda; API Gateway veya ALB proxy entegrasyonu arkasında in-process bir HTTP router (Hono, Fastify, Express veya AWS Lambda Web Adapter aracılığıyla herhangi bir framework) çalıştırır. En az fonksiyon; hak edilmiş istisna.

Bu konudaki en yetkili iki kaynak da single-purpose’u ilke düzeyinde destekler. AWS Well-Architected Serverless Lens bunu doğrudan söyler: “Speedy, simple, singular: Functions are concise, short, single-purpose.” Yan Cui aynı sorunun analizinde “having many single-purposed functions is clearly the better way to go” sonucuna varır; keşfedilebilirlik, debugging ve ekip ölçeklenmesi açısından. Fonksiyon sayısı itirazının fonksiyonları birleştirerek değil, tooling ve isimlendirme kurallarıyla çözüldüğünü savunur. Yazısı Lambdalith teriminden ve bugünkü tooling’in çoğundan önce gelir; akıl yürütmesi hâlâ geçerli. Bunun sizin servisinizde de geçerli olup olmadığına dört platform gücü karar verir: cold start, concurrency, IAM ve observability.

Asıl örnek varsayılanın kendisidir: bir handler, bir iş, sıkıca scope’lanmış.

// src/orders/create.ts - bir fonksiyon, bir is
import type { APIGatewayProxyHandlerV2 } from "aws-lambda";

export const handler: APIGatewayProxyHandlerV2 = async (event) => {
  const body = JSON.parse(event.body ?? "{}");
  // ...siparisi olustur
  return { statusCode: 201, body: JSON.stringify(body) };
};
// IaC'de bu fonksiyon tam olarak Orders tablosuna scope'lanmis bir rol,
// kendi concurrency kontrolunu ve kendi metric ile alarm'larini bedavaya alir.

Argümanın tamamı o “bedavaya” sözcüğünde. Aşağıdaki her güç, ayrı deploy ederek elde ettiğiniz ve birleştirerek kaybettiğiniz bir özelliktir.

Lens 1: Cold Start ve Trafik Dağılımı#

En yaygın Lambdalith lehine iddia şudur: “daha az fonksiyon, daha az cold start.” Bir gerçek gibi söylendiğinde yanlıştır; asıl ilişki trafik dağılımıyla ilgilidir.

Lambda her eşzamanlı istek için ayrı bir execution environment sağlar ve yeni bir environment başlatması gerektiğinde bir cold start yaşar. Yani bir fonksiyon, hesabınızdaki toplam fonksiyon sayısıyla değil, kendi eşzamanlı trafiğiyle orantılı olarak sıcak kalır. On düşük trafikli route’u tek bir fonksiyonda birleştirmek onların trafiğini yoğunlaştırır ki bu o tek fonksiyonun sıcaklığını artırabilir. Ama bu trafik dağılımının bir sonucudur, konsolidasyonun size verdiği bedava bir azalma değil. Anlamlı ve istikrarlı trafik taşıyan bir single-purpose fonksiyon, hiçbir birleştirme olmadan kendi sıcak environment’larını korur. Dolayısıyla doğru ifade dardır: konsolidasyon, tek başına sıcak kalamayacak kadar sessiz route’lar için sıcaklığı iyileştirebilir; bu da onu ileride istisnaya giren gerçek bir girdi yapar.

Bu lens gündeme geldiğinde iki sınır önemli. Birincisi, INIT süresi için yayımlanmış bir AWS hedefi yoktur. AWS’in belgelediği şey, INIT fazının 10 saniyeyle sınırlı olduğu ve bitmezse Lambda’nın yapılandırılmış fonksiyon timeout’u altında ilk çağrıda INIT’i tekrar denediğidir (10 saniyelik sınır provisioned concurrency veya SnapStart için geçerli değildir). Sıkça tekrarlanan “500 ms’nin altında” rakamı bir AWS sayısı değil, topluluk çerçevesidir. İkincisi, daha büyük bir Lambdalith paketinin bireysel bir cold start’ı anlamlı biçimde kötüleştirip kötüleştirmediği makul ama AWS’in ölçmediği bir konudur ve tree-shaking ile bundling bunun çoğunu düzleştirir; bunu ölçülmüş bir ceza olarak değil, niteliksel bir trade-off olarak tartın.

Cold start burada yalnızca granülerlik kararının bir girdisi olarak yer alıyor. SnapStart, provisioned concurrency ve paket-init taktikleri için AWS Lambda cold start optimizasyonu yazısına bakın.

Lens 2: Concurrency ve Noisy Neighbor#

Bu, single-purpose varsayılanı için en güçlü tek argümandır ve dayanağı belgelenmiş bir platform mekanizmasıdır.

Bir Lambdalith, hizmet verdiği her route üzerinde tek bir fonksiyonun concurrency’sini paylaşır. Lambda bir fonksiyonu, reserved concurrency limitine ulaştığında ya da hesap bölgesel tavanına çarptığında throttle eder (varsayılan olarak 1.000 eşzamanlı yürütme; yükseltebileceğiniz soft bir limit). Ayrıca concurrency kotasının on katı kadar bir istek-oranı limiti vardır, yani varsayılanda saniyede 10.000 istek; bu, 100 ms’nin altındaki handler’lar için önemlidir. Bunları bir araya koyun: bir Lambdalith içinde, sıcak bir route üzerindeki trafik patlaması fonksiyonun paylaşılan havuzunu tüketir ve oluşan throttle’lar tüm fonksiyona iner. Yavaş bir checkout route’u, aynı router’ın arkasında bulunan bir health check’i throttle edebilir. Noisy neighbor problemi budur ve Lambdalith bunu yapısı gereği yaratır.

Single-purpose fonksiyonlar her route’u kendi concurrency kontrol birimi yapar. Bu otomatik izolasyon değildir: varsayılan olarak her fonksiyon aynı bölgesel reserved-olmayan havuzdan çeker, dolayısıyla bir patlama yine de hesap concurrency’sini tüketip kardeş fonksiyonları throttle edebilir. Fark kontrol noktasındadır. Route başına bir fonksiyonla, herhangi bir route’a kendi reserved concurrency’sini verip gürültülü bir route’u sınırlayabilir ya da sakin olana kendi tabanını garantileyebilirsiniz. Bir Lambdalith içinde bunu yapamazsınız, çünkü her route tek bir fonksiyonun concurrency’sini paylaşır ve birim fonksiyondur; uzanacağınız route başına bir düğme yoktur. Bir Lambdalith içinde bir route’u izole etmenin tek yolu onu kendi fonksiyonuna geri çıkarmaktır. Buna karşılık, single-purpose’un yarattığı sprawl, IaC modülleri ve isimlendirme kurallarıyla çözdüğünüz bir tooling problemidir. Trade’in bir tarafı birleştirerek kaybettiğiniz bir kontrol noktasıdır; diğeri ise sıradan bir bakım yükü.

Bu iki ayar sık karıştırıldığı için kısa bir not. Reserved ve provisioned concurrency birbirinin yerine geçen değil, tamamlayıcıdır ve ikisi de fonksiyon başına yapılandırılır. Reserved concurrency bir fonksiyonun maksimum eşzamanlı örnek sayısını belirler, o kapasiteyi hesap havuzundan ayırır ve ek ücret taşımaz; fonksiyon o reserved limite ulaştığında throttle edilir. Provisioned concurrency environment’ları önceden başlatır, böylece provisioned sayı içinde cold start olmaz ve bir örnek hiç istek işlemese bile Lambda o başlatma için ücret keser. Granülerlik için yük taşıyan nokta: bu kontroller fonksiyon başına olduğundan, kendi ölçeklenme bütçesine ihtiyaç duyan her route’un kendi fonksiyonu olmalıdır. Konsolidasyon route başına ölçeklenme kontrolünü feda eder.

Lens 3: IAM Blast Radius#

Bir single-purpose fonksiyon, tam olarak o tek handler’ın dokunduğu şeye scope’lanmış bir IAM rolü alır. Sipariş oluşturan fonksiyon Orders tablosuna yazabilir, başka hiçbir şeye değil. Bu, platformun sunduğu en ince taneli least privilege’dır ve nasıl olsa bir rol ekleyeceğiniz için bedava sayılır.

Bir Lambdalith, route’larının gerektirdiği her iznin birleşimine ihtiyaç duyar. Bounded context üç tablo okuyor, ikisine yazıyor, bir topic’e publish ediyor ve bir secret okuyorsa, tek rol bunların hepsini tutar ve her route bu tam set ile çalışır. Bir bug’ın ya da ele geçirilmiş bir bağımlılığın blast radius’u, mevcut isteğin ihtiyaç duyduğu tek izin değil, birleşimdir. Bunu kod içi yetkilendirme kontrolleriyle daraltabilirsiniz, ama bu, platformun uyguladığı bir garantiyi yazmak, test etmek ve doğru tutmak zorunda olduğunuz uygulama mantığına taşır.

Bu lens konsolidasyonun fiyatını belirler. Birleştirme, route’lar gerçekten bir IAM scope’unu paylaştığında kabul edilebilir; öyle ki birleşim her route’tan tek başına yalnızca biraz daha geniştir. Paylaşmadıklarında konsolidasyon fazladan yetki verir ve bu fazla yetki, route’lar bir fonksiyonu paylaştığı sürece kalıcıdır.

Lens 4: Hazır Gelen ve Yeniden Kurulan Observability#

Fonksiyon başına CloudWatch metric’leri otomatiktir. Invocation, error, duration, throttle ve concurrency, hiçbir enstrümantasyon olmadan fonksiyona göre ayrılmış olarak gelir. Single-purpose fonksiyonlarla bu ayrım route başınadır; yani p50, p95 ve p99 latency, error oranı ve throttle sayısı, hiçbir çaba olmadan tam route’a atfedilmiş durumdadır.

Bir Lambdalith her route’u tek bir fonksiyonun metric’lerinde birleştirir. p99’daki bir patlama size domain’in yavaş olduğunu söyler, hangi route’un olduğunu değil. Route başına granülerliği geri kazanmak için eşleşen route’u yapılandırılmış-log ya da Embedded Metric Format boyutu olarak yayar ve route başına görünümü oradan yeniden kurarsınız. Powertools for AWS Lambda bunu yapmanın yerleşik yoludur. Bu tamamen yapılabilir, ama artık bakımı size ait bir uygulama kodudur. Konsolide ediyorsanız route boyutunu ilk gün ekleyin; eksik olduğunu bir incident’in ortasında fark etmek en kötüsüdür.

Lambdalith Lehine En Güçlü Argüman#

Konsolidasyon argümanı boş değil ve en güçlü hâli adil bir değerlendirmeyi hak ediyor. Fonksiyon sprawl’ı gerçektir: servis başına 60 fonksiyon, 60 rol, 60 log group ve okuması ile üzerinde akıl yürütmesi gerçekten daha zor bir template demektir. Route’lar arası refactor’lar birçok deploy birimine dokunur. Ayrıca AWS’in kendisi Lambda Web Adapter’ı gönderir; normal bir Express, Fastify, Koa veya Next.js uygulamasını handler imzasına yeniden yazmadan Lambda içinde çalıştırmanızı sağlayan AWS-bakımlı bir extension. Adapter, Lambda invoke’unu web sunucunuza giden bir localhost HTTP isteğine çevirir. Bu, Lambdalith’in onaylanmış bir pattern olduğuna dair güçlü bir sinyaldir.

İstisna haklı olduğunda şekli şudur. Tek bir fonksiyonun arkasındaki in-process router:

// src/orders/handler.ts - tum Orders domain'i icin tek fonksiyon (ISTISNA)
import { Hono } from "hono";
import { handle } from "hono/aws-lambda";

const app = new Hono();
app.get("/orders/:id", (c) => c.json({ id: c.req.param("id") }));
app.post("/orders", async (c) => c.json(await c.req.json(), 201));

export const handler = handle(app); // her Orders route'u icin tek Lambda handler

API Gateway tarafında, ANY metoduyla tek bir greedy {proxy+} resource her path ve metodu bu tek fonksiyona iletir. Lambda Web Adapter, mevcut web sunucunuzu adapter katmanının arkasında değiştirmeden çalıştırarak aynı hedefe yeniden yazmadan ulaşır.

Ama o sinyalin aslında ne dediğini okuyun. Web Adapter Lambdalith’i bir seçenek olarak onaylar; onu varsayılan yapmaz. AWS’in web framework’lerini Lambda’da çalıştıran bir araç göndermesi, AWS’in kendi Well-Architected rehberinden “Functions are concise, short, single-purpose” ifadesini geri çekmesi değildir. İkisi de doğru olabilir: single-purpose varsayılandır ve Lambdalith, hak ettiğinizde meşru ve desteklenen bir seçimdir. Ve sprawl şikâyeti, dürüstçe incelendiğinde, bir tooling problemidir. Bir isimlendirme kuralıyla yeniden kullanılabilir bir IaC modülü üzerinden tanımlanan altmış fonksiyon, altmış kez örneklenen tek bir modüldür. Sprawl, kontrol ettiğiniz tooling ile çözülür. Birleştirerek vazgeçtiğiniz şey (route başına concurrency kontrolü, IAM, metric’ler, tek birimlik bir deploy blast radius’u) yapısaldır ve ne kadar kod yazarsanız yazın yeniden yaratılamaz.

Konsolidasyonun geri tepme biçimi öngörülebilirdir. Bir ekip, fonksiyon sayısını azaltmak için cohesive bir context’i tek bir Lambdalith’te birleştirir ve bir route bursty trafik almaya başlayana kadar her şey temiz görünür. O route paylaşılan havuzu tüketir, kardeş route’lar throttle olmaya başlar ve fonksiyon başına metric’ler, sonradan bir route boyutu eklenene kadar nedenin hangi route olduğunu söyleyemez. Bunda egzotik hiçbir şey yoktur; concurrency ve observability lens’leri tam mekanizmanın öngördüğü gibi birlikte gelir. Çözüm, sıcak route’u reserved concurrency ile kendi fonksiyonuna geri çekmektir; yani: o route için varsayılan doğruydu ve birleştirme, problemi içerecek olan sınırı sessizce kaldırmıştı.

Lambdalith İçin İstisna Koşulları#

Single-domain Lambdalith’e yalnızca cohesive bir bounded context için bunların her biri sağlandığında başvurun. Biri bile sağlanmıyorsa single-purpose’da kalın; çoğu sağlanır ama bir iki route izolasyona ihtiyaç duyarsa, o route’ları kendi fonksiyonları olarak tutun ve geri kalanını bir Lambdalith arkasına koyun (bir hibrit).

• Çok sayıda düşük trafikli route. Context’te bireysel fonksiyonları nadiren sıcak kalacak route’lar var; trafiklerini yoğunlaştırmak gerçek bir sıcaklık kazancı sağlıyor.
• Hiçbir route izole concurrency’ye ihtiyaç duymaz. Reserved ve provisioned concurrency fonksiyon başına olduğundan, kendi ölçeklenme bütçesine ihtiyaç duyan her route kendi fonksiyonu olarak kalmalı. Birleştirdiğiniz her route için paylaşılan bir havuz kabul edilebilir olmalı.
• Ortak bir IAM scope. Birleştirme anlamlı biçimde fazla yetki vermez; izinlerin birleşimi her route’tan tek başına yalnızca biraz daha geniştir, böylece least privilege domain düzeyinde korunur.
• Tek deploy cadence ve owner. Hiçbir route diğerlerinden çok daha sık değişmez ya da farklı bir ekibe ait değildir; tüm domain’lik bir deploy blast radius’u kabul edilebilir.
• Yeniden kurulabilir observability. Bedava fonksiyon başına metric’leri kaybetmeyi kabul edersiniz ve route başına p50/p95/p99 ile throttle sayılarını geri kazanmak için eşleşen route’u yapılandırılmış-log veya EMF boyutu olarak yayarsınız.

Single-scope (resource ailesi başına bir fonksiyon) bu istisnanın daha ılımlı hâlidir. Bir resource ailesi gerçekten tek bir deploy biriminden fayda görüyorsa ama tam bounded-context Lambdalith çektiğiniz sıkıntının gerektirdiğinden fazla birleştirme demekse bunu tercih edin.

Bu fonksiyonlarda yaşayan kod için, single-purpose ya da Lambdalith fark etmeksizin, iki bakım notu: modüler AWS SDK v3’ü (@aws-sdk/*) kullanın, çünkü SDK v2 2025-09-08’de end-of-support’a ulaştı, ve güncel bir runtime hedefleyin (nodejs24.x, Lambda’da güncel Node LTS’dir). İkisi de granülerlik seçiminize bağlı değil, ama ikisi de birçok fonksiyon boyunca onunla birlikte birikir. Topolojiden bağımsız olarak zarar veren handler-içi alışkanlıklar için AWS Lambda anti-pattern’leri, geliştiricilerin monolit’lerden getirdikleri yazısına bakın.

Kapanış#

Varsayılan olarak single-purpose Lambda fonksiyonları seçin, route başına bir ve event başına bir, ve handler kodunuzu topolojiden bağımsız olarak single-responsibility tutun. Single-purpose’un sağladığı şey yapısaldır ve birleştirdikten sonra geri takılamaz; konsolidasyonu savunan fonksiyon sayısı acısı ise IaC modülleri ve isimlendirme kurallarıyla çözebileceğiniz bir tooling problemidir. Bu varsayılan, ancak cohesive bir context’in sprawl’ı kanıtlandığında ve yukarıdaki beş istisna koşulu birlikte sağlandığında geçerliliğini yitirir; bunun altındaki her durumda izolasyona ihtiyaç duyan route’ları kendi fonksiyonlarında tutun ve yalnızca geri kalanını birleştirin.

Bir şeyi birleştirmeden önce, aday context’inizin bu beşten hangilerini gerçekten sağladığını yazıya dökün.

Kaynaklar#

• Understanding Lambda function scaling (yeni sekmede açılır) - AWS concurrency rehberi: 1.000 hesap varsayılanı, reserved ile provisioned (ikisi de fonksiyon başına), reserved için ek ücret yok, reserved limite ulaşıldığında throttling ve istek-oranı kuralı.
• Configuring provisioned concurrency (yeni sekmede açılır) - Bir provisioned örnek hiç istek işlemese bile Lambda’nın başlatma için ücret kestiğini belirten AWS dokümantasyonu.
• Lambda quotas (yeni sekmede açılır) - Hesap bölgesel concurrency varsayılanı (1.000, soft ve yükseltilebilir) ve ilgili limitler için AWS referansı.
• Understanding the Lambda execution environment lifecycle (yeni sekmede açılır) - INIT fazının 10 saniyelik sınırı, ilk çağrıda tekrar deneme, cold-start tanımı ve istek başına environment sağlama üzerine AWS dokümantasyonu.
• Lambda runtimes (yeni sekmede açılır) - nodejs24.x dâhil desteklenen runtime’ların AWS listesi ve deprecation politikası.
• Well-Architected Serverless Applications Lens: design principles (yeni sekmede açılır) - “Functions are concise, short, single-purpose” ve “think concurrent requests, not total requests” için AWS kaynağı.
• Set up Lambda proxy integrations in API Gateway (yeni sekmede açılır) - Greedy {proxy+} resource ve tüm path’leri tek bir backend’e yönlendiren tek bir ANY metodu için AWS rehberi, Lambdalith’in ön kapısı.
• AWS Lambda Web Adapter (yeni sekmede açılır) - Express, Fastify, Next.js, Flask ve FastAPI’yi tek fonksiyonda değiştirmeden çalıştıran AWS-bakımlı extension, AWS’in Lambdalith’i onayladığının sinyali.
• Hono on AWS Lambda (yeni sekmede açılır) - TypeScript Lambdalith için in-process router; hono/aws-lambda’dan handle(app).
• Few monolithic functions or many single-purposed functions? (yeni sekmede açılır) - Yan Cui’nin keşfedilebilirlik, debugging ve ekip ölçeklenmesi için single-purpose lehine vardığı analiz (Lambdalith teriminden önce gelir).
• Announcing end-of-support for AWS SDK for JavaScript v2 (yeni sekmede açılır) - v2 maintenance mode (2024-09-08) ve end-of-support (2025-09-08) için AWS duyurusu, v3 önerir.
• Powertools for AWS Lambda (TypeScript) (yeni sekmede açılır) - Yerleşik yapılandırılmış logging, tracing ve metric’ler, bir Lambdalith içinde route başına observability’yi geri kazanmanın pratik yolu.