Hono Lambdalith'ten Sonra Lambda Web Functions: Ne Değişiyor

12 Ekim 2026’da duyurulan Lambda Web Functions, bir port dinleyen Node.js uygulamasını Lambda kaynağı olarak çalıştırır. Her birinin kendi HTTPS endpoint’i vardır; tek execution environment birçok isteği eşzamanlı karşılar ve trafik yokken sıfıra iner. Hono uygulaması router tarafında az değişiklikle taşınır; çevresindeki barındırma sözleşmesi ise taşınmaz. @hono/aws-lambda adapter’ının, c.env.event okumalarının, gateway’deki route bazlı authorizer ve throttle ayarlarının ve provisioned concurrency gibi fonksiyon düzeyindeki ayarların doğrudan bir karşılığı yoktur. API Gateway arkasında sorunsuz çalışan bir Hono Lambdalith için önerim şu: onu yerinde bırakın, uygulamayı şimdiden barındırma ortamından bağımsız hale getirin ve bir bounded context’i ancak adı konmuş bir tetikleyici varsa Web Function’a taşıyın. Bu tetikleyiciler uzun istekler, streaming, I/O ağırlıklı handler’lar, sunucu tarafı render ve çok bölgeli gecikme ihtiyacıdır.

Başlangıç noktası, Tek Amaçlı Lambda’ları Hono Lambdalith’e Route Route Taşımak yazısındaki orders API’si. Özellik bir günlük ve üzerinde henüz bir proof of concept çalıştırılmadı. Aşağıdaki Web Functions bilgilerinin tamamı AWS’nin lansmanda yayımladığı dokümantasyondan geliyor; kod da AWS’nin belgelediği yapıyı izliyor.

Lambdalith Gözüyle Web Functions#

AWS artık üç Lambda biçimi tanımlıyor: Event Functions (klasik olay güdümlü model), Web Functions ve MicroVMs. Bir Web Function, değiştirilemez revision’lar (kod ve yapılandırma) ile en fazla on endpoint içerir. Endpoint; bir HTTPS alan adına, bir auth tipine, ölçekleme ve throttle ayarlarına ve trafiği bir ya da iki aktif revision’a dağıtan ağırlıklara sahiptir. Endpoint tipleri HomeRegion, MultiRegion (tek global alan adı, en iyi çaba esaslı gecikme yönlendirmesi) ve PerRegion’dır (bölge başına bir alan adı).

Bir Lambdalith’in taşınıp taşınamayacağını belirleyen kısıtlar dar ve somuttur. Runtime (yeni sekmede açılır), temel kavramlar (yeni sekmede açılır) ve HTTP (yeni sekmede açılır) sayfalarına göre:

• Yalnızca nodejs24.x runtime’ı ve yalnızca Arm64; environment başına sabit 2 vCPU ve 2 GB bellek, varsayılan 1.024 MB V8 heap ve paylaşılan 512 MB /tmp.
• Sunucu, AWS_LAMBDA_HTTP_ENDPOINT içindeki host ve portu 10 saniye içinde dinlemelidir. AWS_LAMBDA_NODEJS_ENTRYPOINT başka bir dosya göstermiyorsa giriş dosyası paket kökündeki index.js’tir; package.json içindeki main okunmaz.
• maxConcurrencyPerEnvironment 1 ile 128 arasındadır, varsayılanı 64’tür. Bu değer, Lambda’nın dinamik olarak yönettiği bir limitin üst sınırıdır; bu yüzden environment başına sürekli eşzamanlılık çoğu zaman daha düşüktür.
• İstek zaman aşımı 3 ile 900 saniye arasındadır, varsayılanı 30’dur.
• Yalnızca HTTP/1.1, istek başlığı için 128 KiB sınırı, WebSocket upgrade desteği yok ve half-duplex bir istek yolu: uygulama yanıtı yazmadan önce istek gövdesinin tamamını okur.
• Kod, versiyonlamalı bir S3 bucket’taki .zip dosyasından deploy edilir ve açılmış hali 512 MB’a kadar olabilir. Yeni revision, öncekinin ayarlarını devralmaz.
• Lansman yazısına (yeni sekmede açılır) göre ilk bölgeler US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Tokyo) ve Europe (Ireland).

Faturalandırma Event Functions’tan farklı bir şekil izler: istek sayısı, aktif CPU süresi, environment ömrü boyunca bellek ve veri transferi. Güncel ücretler fiyatlandırma sayfasında (yeni sekmede açılır).

Aynı Hono Uygulaması, Farklı Bir Giriş Dosyası#

Geliştirici rehberi (yeni sekmede açılır), Hono gibi framework’lerin “Lambda’ya özel adapter ya da sarmalayıcı olmadan” çalıştığını söylüyor. Bu, router için geçerli; uygulamanın kenarları için geçerli değil. Önceki yazıdaki src/orders/app.ts, alt uygulamalar, Zod validator’ları ve app.request() testleri olduğu gibi taşınır. Handler dosyası, Env binding’leri, scope middleware’i ve gözlemlenebilirlik middleware’i ise yeniden yazılır.

AWS’nin örnekler sayfasındaki (yeni sekmede açılır) Hono örneği @hono/node-server kullanıyor. Lambdalith’teki handler.ts, Lambda’nın verdiği adrese bağlanan bir sunucu giriş dosyasına dönüşür:

// src/orders/server.ts (bundled to index.js at the package root)
import { serve } from '@hono/node-server'
import { app } from './app'

// Lambda sets AWS_LAMBDA_HTTP_ENDPOINT as "host:port". The fallback is for local runs only.
const [host, port] = (process.env.AWS_LAMBDA_HTTP_ENDPOINT ?? 'localhost:3000').split(':')

serve({ fetch: app.fetch, hostname: host, port: Number(port) })

process.on('SIGTERM', () => {
  // Lambda allows at most 1 second here; flush anything buffered, then exit.
  process.exit(0)
})

Env tipi Lambda binding’lerini kaybeder. @hono/node-server altında { event, lambdaContext } yoktur; bu yüzden c.env.event ya da c.env.lambdaContext okuyan her kod yeni bir kaynağa ihtiyaç duyar. İstek korelasyonu, Lambda’nın her isteğe eklediği lambda-web-request-id başlığından gelir. Doğrulanmış token payload’ı gibi uygulamanın kendi ürettiği değerler Hono’nun context değişkenlerine yazılır.

// src/orders/env.ts
export type Env = {
  Variables: { jwtPayload?: Record<string, unknown> }
}

Önde bir gateway authorizer’ı yoksa JWT doğrulaması uygulamaya geçer. Hono’nun yerleşik JWK middleware’i (yeni sekmede açılır) bearer token’ı yayıncının anahtar kümesine karşı doğrular; alg seçeneği zorunludur ve kabul edilen algoritmaları listeler. Önceki yazıdaki scope kontrolü temel fikrini korur (token’ın scope ya da scp claim’ini oku); değişen tek şey claim’leri nereden okuduğudur.

// src/orders/auth.ts
import { createMiddleware } from 'hono/factory'
import { jwk } from 'hono/jwk'
import type { Env } from './env'

const issuer = process.env.JWT_ISSUER ?? ''

// Verifies signature, exp, nbf, iat, and iss; the payload lands in c.get('jwtPayload').
export const verifyJwt = jwk({
  jwks_uri: `${issuer}/.well-known/jwks.json`,
  alg: ['RS256'],
  verification: { iss: issuer },
})

export const requireScope = (scope: string) =>
  createMiddleware<Env>(async (c, next) => {
    const claims = c.get('jwtPayload') ?? {}
    const raw = claims.scope ?? claims.scp ?? ''
    const granted = Array.isArray(raw) ? raw : String(raw).split(' ')
    if (!granted.includes(scope)) {
      return c.json({ message: 'Forbidden' }, 403)
    }
    await next()
  })

CORS da tamamen uygulamaya geçer, çünkü Lambda hiçbir CORS başlığı eklemez. hono/cors tek CORS katmanı olur. Önceki yazıdaki, gateway CORS’u ile entegrasyon CORS’unun çakışmasından doğan tuzak da ortadan kalkar.

Route bazlı metrikler hâlâ gerekli, ama yeniden yazılmaları gerekiyor. EMF sayfası (yeni sekmede açılır), EMF nesnelerinin process.stdout.write ile standart çıktıya yazılması gerektiğini söylüyor. Gerekçe şu: Lambda console çıktısını kendi JSON log olayına sarar ve CloudWatch sarılmış nesneden metrik çıkarmaz. Yerleşik metriklerde revision boyutu da bulunmuyor; bu nedenle canary için sürüm bilgisi uygulamanın kendi metriklerinde yer almalı. Nesneyi isteğin içinde oluşturmak, eşzamanlı istekler arasında paylaşılan bir buffer’ı da ortadan kaldırır:

// src/orders/observe.ts
import { createMiddleware } from 'hono/factory'
import { routePath } from 'hono/route'
import type { Env } from './env'

const version = process.env.APP_VERSION ?? 'unknown'

export const observe = createMiddleware<Env>(async (c, next) => {
  const start = performance.now()
  await next()
  const route = `${c.req.method} ${routePath(c, -1)}`
  // One object per request: nothing is shared between requests in flight.
  process.stdout.write(
    JSON.stringify({
      _aws: {
        Timestamp: Date.now(),
        CloudWatchMetrics: [
          {
            Namespace: 'orders',
            Dimensions: [['route', 'version']],
            Metrics: [
              { Name: 'requests', Unit: 'Count' },
              { Name: 'faults', Unit: 'Count' },
              { Name: 'latency', Unit: 'Milliseconds' },
            ],
          },
        ],
      },
      route,
      version,
      requests: 1,
      faults: c.res.status >= 500 ? 1 : 0,
      latency: performance.now() - start,
      status: c.res.status,
      requestId: c.req.header('lambda-web-request-id'),
    }) + '\n',
  )
})

İstek kimliği düz bir alan olarak kalır. Böylece Logs Insights’ta aranabilir, ama her istek için ayrı bir metrik oluşturmaz. Önceki yazıdaki Powertools Logger ve Metrics, Web Functions dokümantasyonunda hiç geçmiyor. Bunları yeniden kullanmadan önce iki şeyi kontrol edin: Metrics çıktıyı doğrudan stdout’a mı yoksa console üzerinden mi yazıyor? Modül düzeyindeki örnekler aynı süreçteki eşzamanlı isteklerle doğru davranıyor mu?

Statik dosyalar, AWS örneğindeki gibi serveStatic ile fonksiyondan sunulabilir. Ön kapı CloudFront olduğunda bu dosyaları S3’ten CloudFront üzerinden sunmak, o trafiği fonksiyondan uzak tutar.

Barındırma Sözleşmesi, Satır Satır#

Aşağıdaki tablo, önceki yazıdaki her konuyu Web Function tarafındaki karşılığıyla eşliyor. API Gateway sütunu o yazıdaki HTTP API kurulumudur.

Konu	API Gateway arkasında Hono Lambdalith	Web Function üzerinde Hono
Router, route’lar, Zod doğrulaması, app.request() testleri	Hono	Değişmez
Adapter	@hono/aws-lambda içinden handle()	AWS_LAMBDA_HTTP_ENDPOINT üzerinde @hono/node-server içinden serve()
Environment başına istek	Tek seferde bir	maxConcurrencyPerEnvironment kadar (varsayılan 64, en fazla 128); dinamik limit daha düşük olabilir
JWT doğrulaması ve scope’lar	Route başına gateway JWT authorizer	Uygulamada ya da korunan bir ön kapıda
Route bazlı throttling	Route ayarları veya usage plan’ler	Route bazında yok; bölge başına endpoint rateLimit ve maxEnvironments
İstek doğrulaması	Hono (veya REST validator’ları)	Yalnızca Hono
İstek zaman aşımı	HttpLambdaIntegration için varsayılan 29 sn	3 ile 900 sn arası, varsayılan 30 sn
Canary	Ağırlıklı alias; HTTP API’de canary yok	Endpoint üzerinde iki revision arasında ağırlık
Sıcak kapasite	Reserved ve provisioned concurrency	Yok; her zaman sıfırdan ölçeklenir
Bellek, CPU, mimari	128 ile 10.240 MB arası, x86 veya Arm	Sabit 2 GB ve 2 vCPU, yalnızca Arm64
Runtime’lar	Tüm Lambda runtime’ları	Yalnızca nodejs24.x
Özel alan adı ve WAF	API Gateway özel alan adı, REST’te WAF	Yalnızca bir ön kapı ile (CloudFront ya da API Gateway)
Özel (private) erişim	REST private API’ler	Yok; endpoint internetten erişilebilir
Streaming	streamHandle ile Function URL’ler	Yerleşik (SSE, chunked); WebSocket yok
Yerleşik metrikler	Fonksiyon başına, gateway’de route başına	İstekler için endpoint başına, environment’lar için fonksiyon başına; route ya da revision boyutu yok
Faturalandırma	Çağrı başına süre	İstek, aktif CPU, environment ömrü boyunca bellek, veri transferi

Satırların çoğu bir sorumluluğu yapılandırmadan koda taşıyor. Scope kontrolü, CORS ve doğrulama, app.request() ile test ettiğiniz middleware’lere dönüşür. Throttling endpoint genelinde bir ayara dönüşür; kendi throttle’ına güvenen bir route bu yalıtımı kaybeder. Zaman aşımı satırı pencereyi 30 saniyenin altından 15 dakikaya kadar genişletir ve uzun süren route’ların aday olmasının ana nedeni budur. Kapasite satırları ise seçenek eksiltir: provisioned bir taban yok, bellek ayarı yok, x86 yok.

En önemli satır eşzamanlılık. Init Amortismanına Göre Kod Mimarisi yazısında modül kapsamındaki istemcilerle ilgili söylenenlerin hepsi geçerliliğini koruyor. Environment başına bir kez oluşturulan veritabanı havuzu ya da SDK istemcisi hâlâ doğru desen. Yeni tehlike, modül kapsamındaki değiştirilebilir ve isteğe özel durum. Event Function’da modül düzeyinde bir let currentUser üslup olarak yanlıştı ama pratikte güvenliydi, çünkü bir environment tek bir isteğe hizmet ediyordu. Web Function’da aynı değişkeni o event loop üzerindeki tüm aktif istekler paylaşır; varsayılan ayarla bu 64 isteğe kadar çıkar. Singleton bir logger’a eklenen istek bağlamı, bir await boyunca değiştirilen cache’ler ve istek sonunda boşaltılan metrik buffer’ları da istekler arasında aynı şekilde sızar. Hono’nun c.set ve c.get çifti her isteğe kendi kapsamını verir.

CPU ağırlıklı işin sorunu tersidir. Event Function’da uzun bir senkron döngü yalnızca bir isteği geciktiriyordu; Web Function’da o environment’taki tüm istekleri geciktirir. Böyle işleri worker_threads’e taşıyın ya da endpoint için maxConcurrencyPerEnvironment değerini düşürün.

Ön Kapı Seçimi#

Ağ yapılandırması (yeni sekmede açılır) ve endpoint erişim kontrolü (yeni sekmede açılır) sayfaları seçenekleri anlatıyor. Bir endpoint iki auth tipinden birini kullanır: IamAuth (çağıran taraf SigV4 ya da SigV4a ile imzalar) veya ApplicationManaged (kararı uygulama verir). Hangisi seçilirse seçilsin, endpoint alan adı internetten erişilebilir kalır.

ApplicationManaged ile doğrudan endpoint en basit yapıdır. Kimlik doğrulama, CORS ve kötüye kullanım koruması uygulamadadır; endpoint alan adı herkese açık URL olur. Özel alan adı yoktur. İç araçlara, önizleme ortamlarına ve uygulamanın doğruladığı token’ları taşıyan makineden makineye çağrılara uyar.

IamAuth endpoint’inin önünde Origin Access Control ile CloudFront, AWS’nin belgelediği üretim yapısıdır. OAC, lambda origin tipini ve always-amz-auth imzalama davranışını kullanır. Resource-based bir policy, cloudfront.amazonaws.com servisine aws:SourceArn ile sınırlanmış lambda:InvokeWebFunctionEndpoint yetkisi verir. CloudFront her origin isteğini imzalar. Lambda yalnızca AWS imzası olan Authorization değerlerini kaldırır; bu sayede kullanıcının kendi bearer token’ı JWK middleware’ine ulaşabilir. Ancak CloudFront, cache policy’de yer almıyorsa GET ve HEAD isteklerinde Authorization başlığını düşürür. Bu yüzden bu origin’i kullanan her behavior’da başlığı cache policy’ye ekleyin (yeni sekmede açılır). Bu behavior’larda Lambda@Edge origin-request ve origin-response tetikleyicileri desteklenmez. Bu yapı özel alan adı, WAF, önbellek ve edge’de HTTP/2 ile HTTP/3 getirir. Bedeli, yapılandırılacak ikinci bir kaynak ve tek bir kuraldır: CloudFront kullanıcının Host başlığını iletmemelidir. İletirse Lambda 404 Platform.InvalidEndpoint döner. CloudFront’un genel olarak ön kapı rolü için AWS ile Edge Computing yazısına bakabilirsiniz.

Önde API Gateway’i tutmak, gateway JWT authorizer’larını, route throttle’larını ve usage plan’leri korur. AWS’nin best practice rehberi (yeni sekmede açılır) bunu geçerli bir ön kapı olarak sayıyor, ancak IamAuth için imzalama yalnızca CloudFront OAC’de belgelenmiş durumda. Başka bir ön kapının arkasında endpoint ApplicationManaged olmalıdır. AWS’nin önerisi, endpoint doğrudan erişilebilir kaldığı için uygulamada paylaşılan bir secret ya da token doğrulamaktır. Bedeli ikinci bir ağ atlaması, döndürülmesi gereken bir secret ve istek süresini hâlâ sınırlayan gateway entegrasyon zaman aşımıdır. Bu eşleşmeyi birebir gösteren bir AWS sayfası henüz yok. Onu bir geçiş köprüsü olarak görün ve ona güvenmeden önce doğrulayın (özellikle Host başlığının Lambda’ya nasıl ulaştığını).

Bounded Context’i Tek Seferlik Geçiş Olmadan Taşımak#

Önceki yazının disiplini burada da geçerli: her seferinde küçük ve geri alınabilir bir adım, her geçişten önce de parity kontrolü. Değişen tek şey geçiş birimi: fonksiyonun yerini ön kapıdaki path alıyor. Her route için karar aşağıdaki gibi işler ve kök, Lambdalith’te kalmaktır.

1. Önce kısıtlara bakın. Reserved ya da provisioned concurrency, 2 GB’tan fazla bellek, x86 native modülleri, Node dışı bir runtime, private erişim, usage plan throttle’ları ya da lansman listesi dışında bir bölge gerektiren her route olduğu yerde kalır. Bu adım, önceki yazıdaki “tek amaçlı kalan route’lar” bölümünün karşılığıdır.

2. Uygulamayı barındırma ortamından bağımsız hale getirin. c.env.event ve c.env.lambdaContext okumalarını kaldırın, istek kimliğini başlıklardan alın ve gateway authorizer’ı hâlâ doğrularken JWK middleware’ini ekleyin. Bu aşamada kontroller çift olur ve Lambdalith bu değişikliklerin her biriyle çalışmaya devam eder. Bu yüzden altyapı değişikliğinden önce yayına girerler; taşıma hiç gerçekleşmese bile yapmaya değerler.

3. Eşzamanlılık denetimi yapın. Modül kapsamındaki let tanımlarını, await boyunca değişen cache’leri, singleton’lara eklenen istek bağlamını ve metrik buffer’larını arayın. Ardından, AWS’nin Web Functions test rehberinin (yeni sekmede açılır) önerdiği gibi, sunucuya yerelde eşzamanlı istekler gönderin.

4. Arm64 ve giriş sözleşmesi için paketleyin. Arşiv kökünde index.js üretin, ESM çıktısı için paketlenen package.json dosyasına "type": "module" ekleyin ve native bağımlılıkları linux/arm64 için derleyin. Versiyonlamalı bucket’a yükleyip nesne sürümünü kaydedin.

5. Web Function’ı Lambdalith’in yanında ayağa kaldırın. CloudFormation’da AWS::Lambda::WebFunction, AWS::Lambda::WebFunctionRevision ve AWS::Lambda::WebFunctionEndpoint kaynakları, CLI’da aws lambda-web deploy komutu var. CDK L2 construct’ı bulunmuyor; CDK kullananlar bunları L1 sınıflarıyla yazar: CfnWebFunction, CfnWebFunctionRevision ve CfnWebFunctionEndpoint. Revision’ı üretim trafiği almayan bir test endpoint’inde doğrulayın ve önceki yazının parity fixture’larını HTTP üzerinden ona karşı çalıştırın.

6. Geçişi ön kapıda path path yapın. API Gateway önde kalıyorsa, explicit bir route’un entegrasyonunu Lambda entegrasyonundan endpoint’e işaret eden bir HTTP entegrasyonuna çevirin. Bu, önceki yazıdaki “önce yönlendir, sonra sil” mekaniğinin aynısıdır ve geri dönüşü yine tek satırdır. Hedef CloudFront ise path bazlı cache behavior’lar /orders/* isteklerini Web Function origin’ine gönderirken geri kalan her şeyi mevcut origin’inde bırakabilir. İki durumda da Lambdalith’i bir gözlem süresi boyunca deploy edilmiş halde tutun.

7. Sonraki deploy’larda revision ağırlıklarını kullanın. CLI ile oluşturulan bir endpoint’i autoDeploymentMode: Disabled moduna alın. Template ile oluşturulan endpoint’ler ise RevisionWeights ile yönetilir. Ardından iki revision ile canary yapın ve hataları uygulamanın kendi metriklerindeki APP_VERSION ile ilişkilendirin. Geri dönüş revision’ını bir endpoint’e bağlı tutun; otomatik temizlik, 50’yi aşan en eski ve hiçbir yere bağlı olmayan revision’ları siler.

8. adımdaki yerel çalıştırma AWS’nin belgelediği komutu kullanır; bir yük aracı da tek süreç üzerinden eşzamanlı istek gönderir:

npx esbuild src/orders/server.ts --bundle --platform=node --format=esm --target=node24 --outfile=dist/index.js
echo '{"type":"module"}' > dist/package.json
cd dist && AWS_LAMBDA_HTTP_ENDPOINT=127.0.0.1:3000 node index.js &
sleep 2
npx autocannon -c 64 -d 10 http://127.0.0.1:3000/orders/123

64 bağlantılı bir çalıştırma, environment başına varsayılan tavanı yansıtır. İstek kapsamıyla ilgili bir hata, başka bir isteğin verisini taşıyan yanıtlar olarak ortaya çıkar. Bu yüzden betikli bir testte yanıt gövdelerini de doğrulayın; tek başına bir throughput değeri bu hatayı gizler.

Bu yolun bedeli, iki barındırma modelinin yan yana çalıştığı bir dönemdir: iki dashboard seti ve iki deploy pipeline’ı. Karşılığında, yeni platformun iyi davranmasına hiç bağlı olmayan, path bazında bir geri dönüş elde edilir.

Kalan Tek Throttle: Endpoint Ayarları#

Route bazlı throttle olmadığında koruma rolünü üç endpoint ayarı üstlenir. Ölçekleme sayfası (yeni sekmede açılır) bunu bir örnekle anlatıyor: maxEnvironments 10 ve maxConcurrencyPerEnvironment 64 olduğunda aynı anda yaklaşık 640 istek işlenebilir. İstek başına 200 ms’de bu, eşzamanlılığın sınırladığı yaklaşık 3.200 istek/saniyedir. İstek başına 10 ms’de ise 8.000’lik bir rateLimit önce devreye girer.

rateLimit (0 ile 10.000 RPS arası, sabit adımlarla: 0, 100’den 1.000’e 100’er, sonra 2.000’den 10.000’e 1.000’er) gateway throttle’ına en yakın karşılıktır ve alttaki bir veritabanını korumaya uygundur. maxEnvironments (2 ile 10.000 arası) endpoint’in ne kadar ölçekleneceğini, dolayısıyla harcamayı sınırlar. İkisi de bölge başına uygulanır; yani bir MultiRegion endpoint, hizmet verdiği her bölgede bu limiti ayrı ayrı alır. Limitlerden biri devreye girdiğinde 429 yanıtı, nedeni belirten bir lambda-web-error-type başlığı taşır. rateLimit değerini 0 yapmak 503 Platform.EndpointDisabled döndürür. AWS, 0 değerinin tüm trafiği engellediğini belgeliyor; bu yüzden bir acil durdurma anahtarı gibi çalışır. Kota sayfasına (yeni sekmede açılır) göre bölge başına hesap varsayılanları şunlardır: endpoint başına 10.000 RPS, hesap başına 100.000 RPS ve 2.000 Arm64 vCPU. Yeni hesaplar daha düşük Web Functions kotalarıyla başlar ve AWS bunları otomatik olarak yükseltir. Bu da environment başına 2 vCPU ile 1.000 environment eder.

Buradaki ödünleşim ayrıntı düzeyiyle ilgili. Gürültülü tek bir route endpoint’in tüm rateLimit bütçesini tüketebilir. Route bazında yalıtım ancak route’lar ayrı endpoint’lerde ya da path bazında throttle uygulayan bir ön kapının arkasında durursa mümkündür.

Varsayılanın Dışına Çıkmak#

Varsayılan, yerinde kalmaya yakın duruyor. Önceki yazının koruduğu gateway özelliklerinin Web Function tarafında karşılığı yok ve özellik yeni: tek runtime, beş bölge, CDK L2 yok. Üç durum cevabı değiştirir.

Sıfırdan yazılan Node.js HTTP servisleri, lansman bölgelerinden birindeyse ve engelleyici kısıtların hiçbirine takılmıyorsa, aynı Hono uygulama yapısıyla CloudFront, OAC ve IamAuth endpoint üzerinde başlayabilir. Sonradan kaldırılacak bir adapter ya da taşınacak bir gateway yapılandırması olmaz. Bedeli, auth, CORS ve route bazlı politikayı ilk günden kodda sahiplenmek ve boşta kalan dönemlerden sonra cold start’ı kabul etmektir, çünkü sıcak kapasite tabanı yoktur.

Streaming ağırlıklı ya da uzun istekli API’ler ilk taşınması gerekenlerdir. Server-sent events, chunked yanıtlar ve gateway entegrasyon penceresini aşan istekler Web Functions’a doğrudan uyar; Lambdalith’te ise bunlar için Function URL ya da ayrı bir yol gerekir. Zamanının çoğunu I/O beklemekle geçiren handler’lar da aktif CPU bazlı faturalandırmaya uyar. Fonksiyon çalışmaya başladıktan sonra metrikler sayfasındaki (yeni sekmede açılır) EnvironmentCPUTime ile EnvironmentActiveTime oranı bu payı gösterir.

Yerinde kalması gereken ekipler şunlardır: Python ya da Java kullananlar; private REST API’lere, route bazlı usage plan’lere, API key’lere veya katı sıcak kapasite garantilerine ihtiyaç duyanlar; trafiği kuyruklardan ya da stream’lerden gelenler. WebSocket ise iki seçeneğe de uymuyor; orada AWS’nin cevabı hâlâ API Gateway WebSocket API’leri. Kaç fonksiyon olması gerektiği sorusu için AWS Lambda: Tek Amaçlı Fonksiyonlar mı, Lambdalith mi? yazısına bakabilirsiniz. Üçüncü biçim olan MicroVMs, Claude Code Nerede Çalışmalı? yazısında bir sandbox seçeneği olarak geçiyor.

Dokümantasyonun Şimdiden Uyardığı Hatalar#

Aşağıdaki her madde, lansman dokümantasyonunda anlatılan bir hata biçimi ve AWS’nin işaret ettiği çözümdür.

1. localhost ya da sabit bir portu dinlemek. Sonuç Application.TimeoutListenError ya da ilk istekte 502 olur. AWS_LAMBDA_HTTP_ENDPOINT değerini ayrıştırın ve tam olarak o host ve porta bağlanın.
2. “Active” durumuna güvenmek. Aktif bir revision ya da başarılı bir endpoint güncellemesi sunucunun başladığı anlamına gelmez; Lambda sunucunun dinleyip dinlemediğini kontrol etmez. Her deploy’dan sonra smoke test yapın ve logları okuyun.
3. Yeni revision’da eksik yapılandırma. Yeni revision öncekinden hiçbir şey kopyalamaz. Yazılmayan ortam değişkenleri kaybolur, zaman aşımı 30 saniyeye döner. Revision yapılandırmasının tamamını tek bir kaynaktan üretin.
4. Modül kapsamında isteğe özel durum. O environment’taki tüm aktif istekler tarafından paylaşılır. c.set ve c.get kullanın, await üzerinden geçen oku-değiştir-yaz dizilerini koruyun.
5. EMF’yi console üzerinden yazmak. Lambda çıktıyı sarar ve CloudWatch hiçbir metrik çıkarmaz. process.stdout.write ile yazın.
6. CloudFront’tan kullanıcının Host başlığını iletmek. Lambda Host üzerinden yönlendirme yapar ve 404 Platform.InvalidEndpoint döner. AllViewerExceptHostHeader origin request policy’sini ya da açık bir izin listesini kullanın. Uygulama bearer token okuyorsa Authorization başlığını cache policy’ye de ekleyin; yoksa GET istekleri bu başlık olmadan gelir.
7. Ön kapıyı gizlilik sanmak. Herhangi bir ön kapının arkasındaki ApplicationManaged endpoint kendi alan adından erişilebilir kalır ve CloudFront ile WAF atlanabilir. OAC ile IamAuth kullanın ya da uygulamada bir origin secret doğrulayın.
8. Gövdeyi okumadan yanıt yazmak. İstek yolu half-duplex olduğu için büyük yüklemeler takılır. Önce gövdeyi tüketin.
9. x86 native modülleri. Bağımlılıkları linux/arm64 container içinde npm ci --omit=dev ile kurun.
10. İletilen başlıklara güvenmek. Lambda X-Forwarded-Host başlığını doğrulamadan iletir ve X-Forwarded-For başlığına yalnızca son atlamayı ekler. Mutlak URL’leri kontrolünüzdeki bir alan adından üretin.
11. Geri dönüş revision’ını kaybetmek. Otomatik temizlik 50’yi aşan en eski bağlantısız revision’ları siler; S3 nesne sürümünün silinmesi de revision’ı Failed durumuna geçirir. Geri dönüş hedefini bir endpoint’e bağlı ve nesne sürümünü saklı tutun.

Varsayılanın Geçerli Olduğu Sınır#

Route’ları route bazlı scope’lara, throttle’lara, usage plan’lere, private API’lere ya da provisioned concurrency’ye bağlıysa, çalışan bir Hono Lambdalith’i API Gateway üzerinde tutmak doğru seçimdir. Aynı şey lansman listesi dışındaki runtime ve bölgeler için de, tetikleyicilerden hiçbirinin olmadığı durumlar için de geçerlidir. Varsayılanın dışına çıkmak, sıfırdan yazılan Node.js servisleri için anlamlıdır. Uzun istek, streaming, I/O ağırlıklı handler, sunucu tarafı render ya da çok bölgeli gecikme ihtiyacı olan bounded context’ler için de öyle. Bunlar, tek satırlık geri dönüşü koruyan bir ön kapının arkasında path path taşınır. Her iki durumda da karşılığını veren sonraki adım, c.env.event ve c.env.lambdaContext okumalarını uygulamadan kaldırmaktır.

Kaynaklar#

• AWS Lambda Web Functions (Developer Guide) (yeni sekmede açılır) - Web Functions’a genel bakış: kullanım alanları, Node.js desteği, faturalandırma boyutları ve endpoint trafik kontrolleri.
• Announcing AWS Lambda Web Functions (AWS News Blog) (yeni sekmede açılır) - Üç Lambda biçimini, aws lambda-web deploy akışını, lansman bölgelerini ve CloudFront entegrasyonunu anlatan lansman yazısı.
• Core concepts for Web Functions (yeni sekmede açılır) - Fonksiyon, revision ve endpoint kaynak modeli, yaşam döngüsü durumları, eşzamanlılık ve zaman aşımı aralıkları.
• Lambda Web Function runtimes (yeni sekmede açılır) - nodejs24.x runtime’ı, AWS_LAMBDA_HTTP_ENDPOINT, eşzamanlılık altında Node.js çalışma modeli ve bellek varsayılanları.
• HTTP requests and responses (yeni sekmede açılır) - Desteklenen metotlar, Lambda’nın kaldırdığı ve eklediği başlıklar, istek başlığı boyut sınırı.
• Scaling behavior for Lambda Web Functions (yeni sekmede açılır) - maxEnvironments, rateLimit, dinamik environment eşzamanlılığı ve kapasite hesabı örneği.
• Lambda Web Function endpoint access control (yeni sekmede açılır) - IamAuth ve ApplicationManaged, istek imzalama ve CloudFront Origin Access Control.
• Configuring networking for Lambda Web Functions (yeni sekmede açılır) - Herkese açık endpoint’ler, CloudFront ön kapı kurulumu, CORS sorumluluğu, half-duplex istekler ve WebSocket desteğinin olmaması.
• Deployment patterns (yeni sekmede açılır) - Otomatik deploy modları, revision ağırlıkları, canary ve blue-green deploy’lar, geri dönüş komutları.
• Managing Web Function revisions (yeni sekmede açılır) - Revision özellikleri ve varsayılanları, değiştirilemezlik ve eski revision’ların otomatik temizliği.
• Using CloudWatch metrics with Lambda Web Functions (yeni sekmede açılır) - CPU ve aktif süre metrikleri dahil yerleşik metrik adları ve boyutları.
• Publishing custom metrics with the embedded metric format (yeni sekmede açılır) - EMF’nin neden console yerine standart çıktıya yazılması gerektiği ve boyut kardinalitesi önerileri.
• Web Function sample applications (yeni sekmede açılır) - Express, @hono/node-server ile Hono, server-sent events ve paketleme komutları.
• Best practices for Lambda Web Functions (yeni sekmede açılır) - Ön kapı seçenekleri, CloudFront dışındaki ön kapıların arkasında paylaşılan secret doğrulaması ve eşzamanlılık altında isteğe özel durum.
• Testing Lambda Web Functions (yeni sekmede açılır) - AWS_LAMBDA_HTTP_ENDPOINT ile yerel çalıştırma, eşzamanlı istekli entegrasyon testleri ve Arm64 paket derlemeleri.
• Troubleshooting Lambda Web Functions (yeni sekmede açılır) - lambda-web-error-type değerleri ile yaygın başlatma, paketleme ve HTTP hataları.
• Lambda quotas (yeni sekmede açılır) - Web Functions için environment, endpoint ve hesap kotaları ile Event Function limitlerinin karşılaştırması.
• AWS::Lambda::WebFunctionEndpoint (CloudFormation) (yeni sekmede açılır) - Şablonlarda endpoint kaynak özellikleri, yeniden oluşturma davranışı ve revision ağırlıkları.
• JWK Auth Middleware (Hono) (yeni sekmede açılır) - Hono’nun JWKS tabanlı token doğrulama middleware’i, zorunlu alg seçeneği ve payload erişimi.
• Restrict access to an AWS Lambda Web Function origin (CloudFront) (yeni sekmede açılır) - OAC kurulumu, Authorization için cache policy gereksinimi ve Web Function origin’lerinde Lambda@Edge sınırları.
• AWS Lambda pricing (yeni sekmede açılır) - Web Functions için güncel faturalandırma boyutları ve ücretler.