Serverless Framework'ten CDK'ye: Önce Lambda'ları Birleştirmeli misiniz?

80 REST route’u olan tipik bir Serverless Framework servisi, şablon başına 500 kaynaklık sabit sınıra karşı yaklaşık 477 CloudFormation kaynağı taşır. Varsayılan L2 construct’larla yapılan bir CDK port’u route başına en az o kadar kaynak ürettiği için sınır, servisle birlikte CDK’ye de gelir. Bu noktada sık dile getirilen fikir, route başına fonksiyonları geçişten önce tek bir Hono Lambdalith’te birleştirmek: daha az fonksiyon, taşınacak daha az tanım. Aşağıdaki çaba modeli aksini söylüyor. Sınıra yakın tipik bir servis için bu sıra takvim süresini yaklaşık ikiye katlıyor: doğrudan, route route port için 12,5 güne karşılık tahminen 25,5 gün.

Önce birleştirmek yalnızca birleştirme beş Lambdalith kriteriyle zaten gerekçelendirilmişse kazandırıyor. O durumda da yeri IaC geçişinin öncesi: CDK’ye geçtikten sonra birleştirmek modelde yaklaşık 29,5 güne çıkıyor, yani önce birleştirmek servis başına yaklaşık 4 gün kazandırıyor. Bu, temel modelde kabaca %14; 2. Faz doğrudan yolun kendi birim maliyetleriyle fiyatlandığında %5’e kadar iniyor. Varsayılan bu yüzden route route taşımak ve fonksiyon granülaritesine dokunmamak. Agentic kodlamayla küçülen sütun iş günü sütunu; küçülmeyen sayımlar aynı yönü daha keskin gösteriyor: 5’e karşı 2 production adımı, 7’ye karşı sıfır davranış değiştiren PR.

Bu soru, sınıra yakın birkaç Serverless Framework servisi işleten ve TypeScript ile CDK’ye geçmeye zaten karar vermiş ekipleri ilgilendiriyor. Geçilip geçilmeyeceği ayrı bir karar; onu Serverless Framework mi AWS CDK mi? Geçiş Yapmalı mısınız? (Bölüm 1) yazısı ele alıyor. Üç iş sırası aşağıda adım tabloları görünür hâlde fiyatlandırılıyor; böylece tahmin başka route sayıları ve başka bir ekibin PR temposuyla yeniden hesaplanabiliyor. Modelin ardından, her yolda log geçmişine mal olan ya da stack refactor’ı engelleyen tuzaklar geliyor. Modelin rakamları birer tahmin; girdileri Serverless Framework 3.40.0 ile örnek bir servisi paketlemekten ve aws-cdk-lib 2.275.0 ile örnek bir uygulamadan synth almaktan geliyor.

Serverless Framework Şablonunda Neler Var#

Serverless Framework 3.40.0 ile örnek bir servisi (iki http fonksiyonu, bir httpApi fonksiyonu, bir SQS tüketicisi, bir DynamoDB tablosu, bir kuyruk) paketlemek 31 kaynaklı bir şablon üretiyor. Sınıra yakın bir servis için önemli olan, fonksiyon başına düşen pay:

Öğe	Şablondaki kaynaklar
http fonksiyonu başına	5: AWS::Lambda::Function, AWS::Lambda::Version (DeletionPolicy: Retain ile), AWS::Logs::LogGroup, AWS::Lambda::Permission, AWS::ApiGateway::Method; ayrıca her path segmenti için, aynı path altındaki route’ların paylaştığı bir AWS::ApiGateway::Resource
httpApi fonksiyonu başına	6: Function, Version, LogGroup, Permission, AWS::ApiGatewayV2::Integration, AWS::ApiGatewayV2::Route
SQS tüketicisi başına	4: Function, Version, LogGroup, AWS::Lambda::EventSourceMapping
Servis başına ortak	Deployment bucket’ı ve policy’si, tüm fonksiyonlar için tek bir IamRoleLambdaExecution, RestApi ve Deployment’ı, HttpApi ve stage’i

Modelde kullanılan tipik serviste 80 REST route’u, yaklaşık 25 path kaynağı, 10 HTTP dışı fonksiyon (kuyruk tüketicileri, zamanlanmış işler, stream işleyicileri), 4 durumlu (stateful) kaynak ve yaklaşık 8 ortak kaynak var: 80 × 5 + 25 + 10 × 4 + 8 + 4 = 477. Zamanlanmış bir fonksiyon 4 yerine 5 kaynak tutuyor (bir EventBridge kuralı ve onun çağırma izni); bu, toplamı en fazla birkaç kaynak oynatıyor. CloudFormation kota sayfası sınırı şablon başına 500 kaynak olarak koyuyor. 477’deki bir servisin yaklaşık dört route’luk yeri kalmış demektir.

Hiçbir şeyi birleştirmeden sayıyı rahatlatan iki kaldıraç var. Birincisi provider.versionFunctions: false: Framework her fonksiyon için bir Version oluşturmayı bırakıyor. Örnek servis bu ayarla paketlendiğinde 31 yerine 27 kaynak çıkıyor; tipik servis 477’den yaklaşık 387’ye iniyor. Yayımlanmış versiyona ihtiyaç duyan bir serviste bu ayar uygun değil: provisioned concurrency $LATEST’i hedefleyemiyor, SnapStart yayımlanmış bir versiyon istiyor, alias tabanlı canary’ler ya da CodeDeploy trafik kaydırması iki versiyon gerektiriyor. Mevcut versiyonlar hesapta kalıyor, çünkü DeletionPolicy değerleri Retain; silinene kadar hesabın kod depolama kotasından düşmeye de devam ediyorlar. İkinci kaldıraç log grubu. Lambda’nın log yapılandırması birden fazla fonksiyonun tek bir özel log grubuna yazmasına izin veriyor; Lambda dokümantasyonu bunu açıkça söylüyor: “You can configure multiple Lambda Event Functions to send logs to the same CloudWatch log group” (birden fazla Lambda Event Function’ı aynı CloudWatch log grubuna log gönderecek şekilde yapılandırılabilir). Serverless Framework v4 bunu provider.logs.lambda.logGroup seçeneğiyle sunuyor; referansına göre bu seçenek verildiğinde Framework “will not create LogGroups for any functions” (hiçbir fonksiyon için LogGroup oluşturmaz). Tipik serviste bu, şablondan yaklaşık 90 kaynak daha düşürüyor; iki kaldıraçla toplam yaklaşık 297’ye iniyor. İki uyarı var. Serverless Framework v3’te ortak log grubu seçeneği yok; disableLogs yalnızca bir fonksiyonun log grubunu kapatıyor. Ayrıca üretilen log gruplarını şablondan çıkarmak, önce korunmazlarsa onları siler; bu da aşağıdaki ilk tuzak. İki kaldıraç da CDK tarafını değiştirmiyor: aşağıdaki CDK sayıları versiyonları ve varsayılan olarak log gruplarını zaten içermiyor.

Varsayılan CDK Port’unda Kaynak Sayısı#

aws-cdk-lib 2.275.0 ile synth almak, port varsayılan L2 construct’larını kullandığında CDK tarafının route başına en az o kadar kaynak ürettiğini gösteriyor. Tek bir üst path altında üç REST route’u ve bir SQS tüketicisi olan, her fonksiyonun bir tabloya grant aldığı örnek bir uygulama 33 kaynak synth ediyor. REST route’u başına dağılım 6: Function, fonksiyona özel AWS::IAM::Role, grant’in oluşturduğu AWS::IAM::Policy, iki AWS::Lambda::Permission ve Method; path kaynakları tıpkı Serverless Framework’teki gibi paylaşılıyor. Grant alan SQS tüketicisi başına 4: Function, Role, Policy, EventSourceMapping.

Fazlalığı iki varsayılan üretiyor. LambdaIntegrationOptions.allowTestInvoke varsayılan olarak true ve CDK API referansına göre bu ayar, test-invoke-stage stage’inin handler’ı çağırabilmesi için Lambda kaynak policy’sine ikinci bir izin ekliyor. lambda.Function’ın role özelliği varsayılan olarak her fonksiyon için ayrı bir rol üretiyor ve ilk grant* çağrısı o rolün varsayılan policy’sini ayrı bir kaynak olarak oluşturuyor. Üçüncüsü isteğe bağlı. v2.200.0 ile gelen @aws-cdk/aws-lambda:useCdkManagedLogGroup bayrağının CDK feature flag listesinde önerilen değeri true; yeni bir cdk init de bu değeri yazıyor. Bayrak açıkken her fonksiyon yedinci bir kaynak ekliyor: DeletionPolicy: Retain taşıyan bir AWS::Logs::LogGroup.

Tipik servis için hesap 80 × 6 + 25 + 10 × 4 + 4 + 5 ortak API kaynağı = yaklaşık 554; yönetilen log gruplarıyla yaklaşık 644. Hiçbir fonksiyon tablo grant’i almasaydı yaklaşık 464 ile 474 arasında olurdu; kuyruk tüketicisinin event source’u rolüne kuyruk erişimini yine de veriyor. Yani varsayılan construct’larla doğrudan yol, fonksiyonlar grant aldığı anda 500’ü aşıyor ve ilk port PR’ından önce bir stack bölme tasarımına ihtiyaç duyuyor. Bölme stratejilerinin kendisi CloudFormation’un 500 Kaynak Sınırını Aşmak yazısında; burada tekrarlanmıyor. O yazıyla bir ayrım burada önemli: oradaki Strateji 0, stack’i bölmeden önce ortak rolleri, policy’leri, security group’ları ve alarmları birleştiriyor ve her fonksiyonu olduğu gibi bırakıyor. Handler’ları bir Lambdalith’te birleştirmek ise fonksiyon granülaritesini değiştiriyor; bu, kendi bedeli olan ayrı bir karar. Aynı hesap, granülarite yazısında fonksiyon sayısı sancısını IaC modülleriyle çözülecek bir araç sorunu sayan satıra da yanıt veriyor. Modüller kodu kısaltır; 500 sınırı ise şablondaki kaynakları sayar. Dolayısıyla kaldıraç stack bölme ya da kaynak kırpma.

Bir CDK port’u varsayılanları almak yerine Serverless Framework biçimini de yansıtabilir: role ile geçirilen tek ortak rol, her entegrasyonda allowTestInvoke: false, logGroup ile tek ortak log grubu. Yukarıdaki construct başına sayılardan yapılan hesaba göre (bu varyant synth edilmedi) route başına maliyet 3 kaynağa iniyor: Function, Permission, Method. Tipik servis böylece tek stack’te 300 civarına oturuyor. Bedeli IAM tarafında: ortak rol, Serverless Framework’ün varsayılan tek rol biçimini yeniden kuruyor ve fonksiyon başına en az yetkiden vazgeçiyor. Çaba modeline etkisi aşağıdaki duyarlılık satırlarında görülüyor; doğrudan yolu daha da ucuzlattığı için hükmü güçlendiriyor.

Üç Yolun PR ve İzleme Günü Cinsinden Maliyeti#

Model pull request’leri, iş günlerini ve production adımlarını sayıyor. İş günü, kodlama agent’ı olmayan bir ekibin tanıyacağı taban; bölümün son alt başlığı aynı adımları agent’lı ekip için yeniden ağırlıklandırıyor. Production adımı, trafiği ya da durumu hareket ettiren her deploy; her birinin ardından, sonraki adım başlamadan önce bir izleme süresi (soak) geliyor. Takvim günü, iş günü artı izleme günü. Bu bölümdeki her şey bir tahmin. Birim maliyetler modelin varsayımları; PR temposu farklı bir ekip, toplamları okumadan önce bunları kendi değerleriyle değiştirmeli.

Birim Maliyetler ve Tipik Servis#

• Mekanik PR (toplu IaC port’u, cutover, devreden çıkarma): 0,5 gün.
• Tasarım ya da kod biçimi PR’ı (CDK ya da Hono iskeleti, stack bölme tasarımı, eşdeğerlik fixture’larıyla toplu bir Hono route port’u, kodda yeniden kurulan gateway özellikleri): 1 gün.
• Tek istisna: deploy edilmiş bir API’ye karşı eşdeğerlik testlerini yazmak 2 gün sürüyor, çünkü fixture’lar eski ve yeni API yan yana çalışırken kuruluyor. Zaten var olan fixture’ları yeniden çalıştırmak mekanik 0,5 gün.
• Her production adımından sonra izleme: 2 gün.
• PR başına hacim: IaC port PR’ı başına 20 fonksiyon; Hono port PR’ı başına 15 route; 3 yeniden yönlendirme dalgası (trafiksiz route’lar, düşük trafikli route’lar, en yoğun birkaç route).
• Tipik servis: H = 80 HTTP route’u, E = 10 HTTP dışı fonksiyon, S = 4 durumlu kaynak, C = 8 istisna route (kendi fonksiyonunu koruyan, route’ların %10’u).

Doğrudan Yol#

Doğrudan yol tek bir şeyi, IaC aracını değiştiriyor. Her fonksiyon sınırını (route başına bir fonksiyon) ve rol kapsamını koruyor. CDK fonksiyonları eşdeğerlik testleri sırasında eskilerinin yanında çalıştığı için yeni adlar ve yeni log grupları alıyor. API CDK’de yeniden kuruluyor, eskisine karşı test ediliyor ve ardından özel alan adının mapping’i ona yönlendiriliyor.

Adım	PR	İş günü	Production adımı
CDK iskeleti, CI, stack bölme tasarımı	2	2	0
H + E = 90 fonksiyon tanımının port’u	5	2,5	0
Deploy edilmiş yeni API’ye karşı eşdeğerlik testleri	1	2	0
Durum tanımlarını hizalama, ardından stack refactor	2	1	1
Özel alan adında cutover	1	0,5	1
Serverless Framework stack’ini devreden çıkarma	1	0,5	0
Toplam	12	8,5	2, yani 12,5 takvim günü

Zayıf noktası cutover. 80 route’un tamamı özel alan adında tek seferde dönüyor. Eşdeğerlik açıkları yalnızca deploy edilmiş yeni API’ye karşı ortaya çıkıyor, çünkü bu yolda bağımsız bir test düzeneği yok.

Serverless Framework İçinde Birleştirme (Önce Hono, 1. Faz)#

1. Faz, servis hâlâ Serverless Framework’teyken HTTP route’larını tek bir Hono fonksiyonunda birleştiriyor. Bu, AWS’nin kendi rehberliğinin Event Function’lar için karşı çıktığı biçim; aşağıdaki karar bölümü o rehberliği alıntılıyor ve hangi koşullarda aşılacağını belirliyor. Catch-all route’un, yeniden yönlendirme dalgalarının ve silme adımının mekaniği Tek Amaçlı Lambda’ları Hono Lambdalith’e Route Route Taşımak yazısında CDK üzerinden gösteriliyor; sıra serverless.yml’de de aynı.

Adım	PR	İş günü	Production adımı
Hono iskeleti, catch-all route, bağımsız eşdeğerlik düzeneği	2	2	0
H - C = 72 route’un Hono’ya port’u	5	5	0
Hono’da yeniden kurulan gateway özellikleri (auth, doğrulama, route metrik boyutu)	2	2	0
Yeniden yönlendirme dalgaları	3	1,5	3
Log grubu Retain PR’ı, ardından yönlendirilen fonksiyonları silen PR	2	1	0
1. Faz toplamı	14	11,5	3, yani 17,5 takvim günü

Ekiplerin fiyatlandırmayı unuttuğu satır gateway özellikleri; bu satır yalnızca explicit Method’u catch-all lehine silinen route’lar için geçerli. O route’larda method başına istek doğrulama, method başına throttling ve API Gateway metriklerinin Resource boyutu proxy girdisinde toplanıyor; route metriğinin uygulama içinde, örneğin bir Embedded Metric Format boyutu olarak yeniden kurulması gerekiyor. Authorizer’lar istisna: REQUEST tipi bir authorizer $context.path değerini alıyor ve path’e özgü policy döndürebiliyor, yani gateway’de kalabiliyor. Explicit Method’unu koruyup Hono fonksiyonuna yönlendiren bir route ise gateway özelliklerinin tamamını koruyor; bedeli route başına bir Method kaynağı. Yukarıdaki hesapla bu bitiş durumu tipik serviste catch-all’daki yaklaşık 100 yerine 200 civarına oturuyor; sınırdan hâlâ uzak.

Küçülmüş CDK Taşıması (Önce Hono, 2. Faz)#

1. Faz’dan sonra serviste 1 + C + E = 19 fonksiyon kalıyor; bunlar varsayılan construct’larla, bölme tasarımına gerek kalmadan tek bir CDK stack’ine sığıyor.

Adım	PR	İş günü	Production adımı
CDK iskeleti ve CI	1	1	0
19 fonksiyonun ve proxy API’nin port’u	1	0,5	0
1. Faz fixture’larını HTTP üzerinden yeniden kullanan eşdeğerlik testleri	1	0,5	0
Durum tanımlarını hizalama, ardından stack refactor	2	1	1
Özel alan adında cutover	1	0,5	1
Serverless Framework stack’ini devreden çıkarma	1	0,5	0
2. Faz toplamı	7	4	2, yani 8 takvim günü

Toplamlar ve Duyarlılık#

Üçüncü yol, önce doğrudan geçip sonra CDK’de birleştirmek, doğrudan yolun ardından 1. Faz’ı CDK içinde yürütmek demek. Retain PR’ı düşüyor, çünkü CDK log grupları ya şablonun dışında ya da zaten korunmuş; silme PR’ı kalıyor. Bu da 12,5 günün üstüne 13 PR, 11 iş günü, 3 production adımı ve 17 takvim günü ediyor.

Yol	Bitiş durumu	PR	Takvim günü (tahmin)
Doğrudan	Bölünmüş stack’lerde 90 fonksiyon	12	12,5
Önce Hono (1. + 2. Faz)	Bir Hono fonksiyonu, 8 istisna, 10 HTTP dışı fonksiyon	21	25,5
Önce doğrudan, sonra CDK’de birleştirme	Önce Hono ile aynı	25	29,5

25,5 / 12,5 oranı yaklaşık 2,0; (29,5 - 25,5) / 29,5 ise yaklaşık %14. Bir ekibin tartışması muhtemel varyantlarda oran yaklaşık 1,7 ile 2,2 arasında kalıyor. Kırılgan sayı tasarruf. Bu, üç 2. Faz indiriminden (daha küçük iskelet, 90 yerine 19 fonksiyonun port’u, yazmak yerine yeniden çalıştırılan fixture’lar) oluşan 4 günlük bir kalıntı; son satır ikisini fiyatlandırıp geri alıyor:

Varyant	Doğrudan	Önce Hono	Önce doğrudan, sonra birleştirme
Temel (2 günlük izleme)	12,5	25,5	29,5
1 günlük izleme	10,5	20,5	24,5
Route’ları yeniden yazmak yerine adapter ile sarılmış handler’lar (her iki birleştirme yolunda port adımı 2 PR, 1 gün)	12,5	21,5	25,5
Tek stack’li doğrudan port (ortak rol, allowTestInvoke: false; iskelet 1 PR, 1 gün)	11,5	25,5	28,5
2. Faz doğrudan yol fiyatlarıyla (eşdeğerlik yeniden yazılıyor, 2 gün; iskelet ve CI, 2 gün)	12,5	28,0	29,5

Sıralama her satırda aynı; bu kısım bir bulgu değil, yapısal bir sonuç. Önce Hono, doğrudan yolun hiç ödemediği 72 route’luk bir port ve üç ek production adımı taşıyor; izleme süresi ne olursa olsun geride kalıyor. Satırların sınadığı şey tasarruf. Tek stack satırında yaklaşık %10, son satırda yaklaşık %5. Modeldeki iki tercih önce Hono’nun lehine. Retain, silme ve devreden çıkarma deploy’ları canlı stack güncellemeleri olduğu hâlde izleme süresi olmadan sayılıyor; üçüncü yolun bitiş durumu ise bir taban, çünkü hiçbir satır birleştirmeden sonra bölünmüş stack’leri tek stack’e indirmiyor. Modellenmeyenler: CDK öğrenme eğrisi, mühendisler arası paralel çalışma, izleme sürelerindeki olay (incident) zamanı ve bölünmüş tasarımdaki stack’ler arası başvurular. Bu sonuncusu doğrudan yolun port PR’larını tasarım sınıfına çıkarabiliyor (12,5 yerine yaklaşık 15 gün) ve tasarrufu yeniden açıyor.

Yol	Maliyet (model)	Operasyonel yük	Risk noktaları
Doğrudan	12 PR, 12,5 gün, 2 production adımı, yaklaşık 16,5 review saati	Varsayılan construct’larla stack bölme tasarımı ya da ortak rol ve kırpılmış izinlerle tek stack	Tüm route’ların özel alan adında tek seferde dönmesi; eşdeğerlik açıklarının yalnızca deploy edilmiş yeni API’ye karşı bulunması; eski stack devreden çıkarılırken korunmayan log gruplarının silinmesi
Önce Hono	21 PR, 25,5 gün, 5 production adımı, yaklaşık 47,5 review saati	Kodda yeniden kurulan gateway özellikleri; sahiplenilmesi gereken route metrik boyutu; art arda iki IaC durumu	Retain deploy’u atlanırsa kaybolan log geçmişi; catch-all’a taşınan route’larda route başına throttling ve metriklerin toplanması; 72 route’un tek fonksiyonun ölçeklenme hızını paylaşması
Önce doğrudan, sonra birleştirme	25 PR, 29,5 gün, 5 production adımı, yaklaşık 52,5 review saati	İki geçiş; 90 fonksiyon önce port edilip sonra birleştiriliyor	Yukarıdakilerin ikisi de; sonradan atılacak bir biçim için yapılmış stack bölme tasarımı

Agentic Kodlamanın Sıkıştırmadığı Şeyler#

Bir agent’ın küçülttüğü sütun iş günü sütunu. 90 tanımı, 72 route port’unu ve eşdeğerlik fixture’larını o yazıyor; mekanik olanları da bir synth diff ya da fixture tekrarı makineyle doğruluyor. Üç şey insanda kalıyor. Bir production adımını hâlâ birinin onaylaması, izlemesi ve geri almaya hazır olması gerekiyor. Davranış değiştiren bir PR’da hâlâ birinin yeni kodun eski davranış olduğuna karar vermesi gerekiyor; güvenlikle ilgili olanda bu karar daha da dikkat istiyor. Geri alınamaz bir işlem hâlâ prova istiyor. Bunları yukarıdaki adım tablolarından saymak, kodu kimin yazdığına bağlı olmayan ikinci bir karşılaştırma veriyor.

Sayım, adım tablolarından	Doğrudan	Önce Hono	Önce doğrudan, sonra birleştirme
Production adımı	2	5	5
Davranış değiştiren PR (route port’ları, kodda gateway özellikleri)	0	7	7
Bunların güvenlikle ilgili olanları (kodda yeniden kurulan auth ve doğrulama)	0	2	2
Geri alınamaz işlem (refactor çalıştırma, log grubu silme, devreden çıkarma)	2	3	3
İnsanın sahiplendiği tasarım kararı (bölme tasarımı, Hono iskeleti, istisna listesi, gateway eşlemesi)	1	3	4
İnsan review saati (tahmin, birim maliyetler aşağıda)	16,5	47,5	52,5

Review saati satırı aynı adımları iş günü yerine insan zamanıyla fiyatlandırıyor: makineyle doğrulanan mekanik PR 0,5 saat; tasarım PR’ı 2 saat; davranış değiştiren route grubu 3, güvenlikle ilgili olanı 4 saat; eşdeğerlik fixture’larını yazmak 2, yeniden çalıştırmak 0,5 saat; production adımı başına 2 saat refakat; geri alınamaz işlem başına 1 saat ek. Bu mercekte önce Hono ile doğrudan yol arasındaki oran yaklaşık 2,0’dan 2,9’a açılıyor; birleştirme sırasının tasarrufu ise 4 günden yaklaşık 5 saate, yani %10 civarına iniyor. Nedeni, 2. Faz’ı gün cinsinden ucuzlatan kalemlerin, daha az tanım port’u ve daha küçük iskeletin, agent’ın doğrudan yolda da ucuzlattığı kalemler olması. Takvim günleri bu mercekte değişmiyor, çünkü en büyük terim izleme süreleri ve kodu kimin yazdığına bağlı değiller; raporlanıyor, belirleyici değil.

Sırayı Beş Lambdalith Kriteri Belirler#

Birleştirilip birleştirilmeyeceğine geçiş değil, servis karar veriyor. AWS Lambda: Tek Amaçlı Fonksiyonlar mı, Lambdalith mi? yazısı Lambdalith’in daha iyi biçim olduğu beş kriteri ortaya koyuyor: çok sayıda düşük trafikli route; izole eşzamanlılık (concurrency) gerektiren route olmaması; route’lar arasında ortak bir IAM kapsamı; tek deploy temposu ve tek sahip; uygulama içinde yeniden kurulabilen gözlemlenebilirlik. Beşi de sağlanıyorsa birleştirme kendi başına değer ve geçişin eklediği tek soru sıra. Herhangi biri sağlanmıyorsa birleştirme, IaC aracından bağımsız olarak getirdiğinden fazlasına mal oluyor ve planın tamamı doğrudan yol.

AWS’nin kendi rehberliğini burada adlandırmak gerekiyor, çünkü uyardığı biçim tam olarak birleştirilmiş biçim. Lambda geliştirici kılavuzu anti-pattern’ları arasında “The Lambda monolith” başlığını sayıyor: “a monolithic Lambda function would handle all API Gateway routes and integrate with all necessary downstream resources” (monolitik bir Lambda fonksiyonu tüm API Gateway route’larını karşılar ve gereken tüm alt kaynaklarla bütünleşir). Altı sakınca sıralıyor (paket boyutu, en az yetki, güncelleme, bakım, kod yeniden kullanımı, test) ve tercih edilen alternatifi “mapping a single Lambda function to a single, well-defined task” (tek bir Lambda fonksiyonunu tek, iyi tanımlanmış bir göreve eşlemek) olarak veriyor. Serverless Applications Lens ekliyor: “Take advantage of Amazon API Gateway native routing functionality instead of using the routing of web frameworks” (web framework’lerinin yönlendirmesi yerine Amazon API Gateway’in yerleşik yönlendirmesinden yararlanın). İki cümle de 1. Faz’ı tarif ediyor. Beş kriter, altı sakıncanın üçünü küçülten koşullar: ortak IAM kapsamı en az yetkiye, tek deploy temposu güncellemeye, tek sahip bakıma karşılık geliyor. Paket boyutu ve test, istisna kuralındaki 1 MB bağımlılık sınırına ve bağımsız düzeneğe kalıyor. Kod yeniden kullanımı ele alınmıyor; birleştirme ona ne yardım ediyor ne zarar veriyor. AWS’nin fonksiyon türüne göre ayrılan ikinci bir konumu da var. Anti-pattern sayfası Event Function’lar için yazılmış; Lambda Web Functions dokümantasyonu ise şöyle diyor: “You can use familiar Node.js web frameworks such as Express, Hono, or React Router with no Lambda-specific adapters or wrappers” (Express, Hono ya da React Router gibi tanıdık Node.js web framework’lerini Lambda’ya özgü adapter ya da sarmalayıcı olmadan kullanabilirsiniz). API Gateway arkasındaki bir Hono uygulaması hâlâ bir Event Function; dolayısıyla 1. Faz için geçerli sayfa anti-pattern sayfası. Birleştirme, AWS’nin varsayılanının koşullu olarak aşılması; onun çürütülmesi değil.

Soru (sırayla)	Evetse	Hayırsa
Bu servis için beş Lambdalith kriterinin tamamı sağlanıyor mu?	Sonraki soru	Doğrudan yol (varsayılan)
IaC geçişi zaten planda mı?	Önce Hono, sonra CDK (modelde, sonradan birleştirmeye göre yaklaşık 4 gün, %5 ile %14 arası daha ucuz)	Birleştirmeye kendi gerekçesiyle karar verin; geçiş bunu belirlemez
Bir HTTP API servisi 300 entegrasyona yaklaşıyor mu?	Router’lar her hâlükârda zorunlu; birleştirmeyi planlayın	Değişiklik yok
Servisler fonksiyon başına rol mü kullanıyor?	IAM birleşim maliyetini birleştirme tarafına ekleyin	Ortak rol: birleştirme IAM kapsamını değiştirmez

IAM kriteri ayrı bir not hak ediyor, çünkü Serverless Framework servislerinin, granülarite yazısının varsaydığı CDK varsayılanlarından ayrıldığı yer burası. Serverless Framework dokümantasyonu varsayılanı şöyle belirtiyor: “By default, one IAM Role is shared by all the Lambda functions in your service” (varsayılan olarak servisteki tüm Lambda fonksiyonları tek bir IAM rolünü paylaşır). Bu varsayılanda kalan bir servis zaten tek rolün etki alanını taşıyor; dolayısıyla route’ları tek fonksiyonda birleştirmek IAM kapsamını genişletmiyor. Bu, bedelin sıfır olduğu anlamına gelmiyor. Ortak rol, duran bir en az yetki borcu; CDK’nin fonksiyon başına rolleriyle doğrudan yol bu borcu kapatabiliyor, birleştirme ise onu koruyor. Fonksiyon başına rol kullanan servisler ise birleştirirken IAM birleşim bedelini ödüyor ve granülarite yazısının IAM merceği olduğu gibi geçerli. v4’te bu biçim provider.iam.role.mode: perFunction ya da fonksiyon başına iam.role.statements ile geliyor; v3’te genellikle serverless-iam-roles-per-function eklentisiyle.

İki Yolda da Karşılaşılan Tuzaklar#

Aşağıdaki tuzakların her biri örnek servisi paketlemekten, örnek uygulamadan synth almaktan ya da birincil dokümantasyondan geliyor.

Fonksiyonla Birlikte Silinen Log Grupları#

Serverless Framework her fonksiyon için DeletionPolicy ve RetentionInDays içermeyen bir AWS::Logs::LogGroup üretiyor; örnek servisi paketlemek bunu doğruluyor. Bir fonksiyonu functions altından kaldırmak log grubunu da şablondan kaldırıyor ve CloudFormation onu, fonksiyonun tüm log geçmişiyle birlikte siliyor. Çözümü CloudFormation DeletionPolicy dokümantasyonu tarif ediyor: stack güncellemesinde Retain, fiziksel kaynağı koruyup CloudFormation’ın kapsamından çıkarıyor. Pratikte bu, toplu silinen her fonksiyon grubu için iki deploy demek; yukarıdaki 1. Faz tablosu bunları Retain PR’ı ve silme PR’ı olarak fiyatlandırıyor.

# serverless.yml, 2 deploy'un 1'incisi: fonksiyon giderken log grubunu koru
resources:
  extensions:
    GetOrderLogGroup:          # "getOrder" fonksiyonu için {normalizedFunctionName}LogGroup
      DeletionPolicy: Retain
      UpdateReplacePolicy: Retain
      Properties:
        RetentionInDays: 30

2. deploy, getOrder’ı functions altından ve GetOrderLogGroup extension’ını aynı commit’te kaldırıyor. Extension geride kalamaz: v3 kaynak kodunda (merge-custom-provider-resources.js) artık üretilmeyen bir kaynağı genişletmek RESOURCE_EXTENSION_NOT_EXISTING hatasıyla başarısız oluyor. Aynı dosya extension’ları Condition, CreationPolicy, DeletionPolicy, UpdatePolicy, UpdateReplacePolicy, Properties, DependsOn ve Metadata ile sınırlıyor; başka bir öznitelik RESOURCE_EXTENSION_UNSUPPORTED_ATTRIBUTE veriyor. Mantıksal ID belgelenmiş normalizasyonu izliyor: fonksiyon adındaki - Dash, _ ise Underscore oluyor ve ilk harf büyütülüyor; get-order böylece GetDashOrderLogGroup adını alıyor. UpdateReplacePolicy extension’da duruyor, çünkü DeletionPolicy bir değiştirmeyi (replacement) kapsamıyor ve LogGroupName değiştirme gerektiren bir özellik; bu yüzden Retain PR’ı ada dokunmamalı.

Aynı silme, iki yolun sonunda Serverless Framework stack’i devreden çıkarıldığında da yaşanıyor: stack’te kalan her log grubu onunla birlikte gidiyor. Refactor’dan önceki hizalama deploy’unda bu log gruplarına DeletionPolicy: Retain eklemek geçmişi koruyor ve modele PR eklemiyor.

CloudFormation Stack Refactoring’in Sınırları#

İki yol da durumlu kaynakları (tablolar, kuyruklar, bucket’lar, user pool’lar) Serverless Framework stack’inden CDK stack’ine stack refactoring ile taşıyor; böylece veri hiç yerinden oynamıyor. Stack refactoring dokümantasyonunun koyduğu kısıtlar planı biçimlendiriyor:

• Refactor kaynak oluşturamaz, silemez, yapılandırma değiştiremez; parametre, condition ya da mapping ekleyemez. Bu değişiklikler refactor’dan önce normal stack güncellemelerine gidiyor.
• CLI refactor başına en fazla 5 stack’i ele alıyor, hiçbir stack boş bırakılamıyor ve stack policy’si olan stack’ler desteklenmiyor.
• Değeri stack’ler arasında farklılaşan pseudo parametrelere (AWS::StackName gibi) başvuran kaynaklar taşınamıyor.
• Yalnızca FULLY_MUTABLE kaynak tipleri taşınıyor; o da desteklenmeyenler listesinde değillerse. Listede AWS::ApiGateway::Method, AWS::ApiGateway::BasePathMapping, AWS::Lambda::EventInvokeConfig, AWS::Route53::RecordSet ve AWS::DynamoDB::GlobalTable var; AWS::ApiGatewayV2::ApiMapping yok.

eu-central-1’de DescribeType sorgusu, olağan durumlu küme için FULLY_MUTABLE gösteriyor: DynamoDB Table, SQS Queue, S3 Bucket, Cognito UserPool ve UserPoolClient, SNS Topic, EventBridge EventBus ve Rule, Secrets Manager Secret, KMS Key ve Logs LogGroup. AWS::Lambda::Permission ise IMMUTABLE; durumsuz olduğu ve zaten yeniden oluşturulduğu için bunun önemi yok. Gateway method’ları da taşınmıyor; CDK’de yeniden oluşturuluyor. Özel alan adının mapping’i ise geçişin kendisi ve yeniden oluşturulması gerekmiyor: CloudFormation referansı AWS::ApiGateway::BasePathMapping üzerindeki RestApiId ve AWS::ApiGatewayV2::ApiMapping üzerindeki ApiId güncellemelerini “No interruption” (kesintisiz) olarak işaretliyor. Yani cutover, mapping nerede yaşıyorsa yaşasın (Serverless Framework stack’i, bir domain eklentisi ya da kendi stack’i), yerinde değiştirilen tek bir özellik. Serverless Framework stack’inde yaşayan bir mapping devreden çıkarma sırasında korunuyor ve sonra CDK’ye import ediliyor; HTTP API mapping’i refactor ile de taşınabiliyor, REST base path mapping’i taşınamıyor. İki yolun da bir cutover adımı taşımasının ve bu adımın kesinti açmamasının nedeni bu.

Paketlenen v3 şablonunda AWS::StackName başvurusu yok; fonksiyon adları <service>-<stage>-<function> biçiminde düz metin. Elle yazılmış resources yine de kontrol edilmeli: serverless package sonrası grep -c AWS::StackName .serverless/cloudformation-template-update-stack.json çalıştırın ve eşleşme varsa refactor’dan önce normal bir deploy ile düz adla değiştirin.

Refactor’la ilgili iki nokta burada test edilmedi ve sandbox’ta prova edilmeli. Serverless Framework stack’inde kalan kaynaklar, tipik olarak ortak rolün policy’si ve fonksiyon ortam değişkenleri, taşınan tabloya sık sık Ref ya da GetAtt ile başvuruyor. Tabloyu kaynak şablondan çıkarmak bu başvuruları kırıyor; bu yüzden refactor’dan önce normal bir deploy’da düz adla ya da bir export ile değiştirilmeleri gerekiyor. Ayrıca CDK şablonları bir bootstrap sürüm parametresi, bir bootstrap kuralı ve bir metadata kaynağı taşıyor; dokümantasyona göre refactor parametre ya da kaynak ekleyemiyor. Daha güvenli sıra bu yüzden hedef CDK stack’ini önce deploy edip içine refactor etmek. Bu ilk deploy tabloyu taşıyamıyor, çünkü aynı adda ikinci bir tablo hata veriyor; stack boş da olamıyor, bu yüzden bir yer tutucu kaynak gerekiyor. Refactoring dokümantasyonu bunun için bir SNS topic ya da bir wait condition öneriyor. Tablo hedef şablona refactor’ın kendisinde, bir taşıma olarak giriyor. Dokümantasyondaki --enable-stack-creation seçeneği hedef stack’i refactor’ın oluşturmasına izin veriyor; buradaki sıra onu bilerek dışarıda bırakıyor.

aws cloudformation create-stack-refactor \
  --stack-definitions \
    StackName=orders-service-prod,TemplateBody@=file://sf-without-state.json \
    StackName=orders-state-prod,TemplateBody@=file://cdk.out/OrdersStateStack.template.json \
  --resource-mappings file://resource-mapping.json

aws cloudformation describe-stack-refactor --stack-refactor-id <id>       # Status CREATE_COMPLETE olana kadar bekle
aws cloudformation list-stack-refactor-actions --stack-refactor-id <id>   # MOVE eylemlerini önizle
aws cloudformation execute-stack-refactor --stack-refactor-id <id>

cdk refactor ve Serverless Framework Kaynak Stack’i#

cdk refactor önizlemede ve --unstable=refactor bayrağının arkasında. CDK refactoring rehberi komutu, taşınan construct’ları bulmak için uygulamanın güncel kodunu deploy edilmiş durumuyla karşılaştırıyor diye tarif ediyor; başka araçların stack’leri hakkında bir şey söylemiyor. Buradaki çıkarım, Serverless Framework stack’inin o karşılaştırmanın dışında kaldığı; dolayısıyla araçlar arası taşıma için doğru araç bu komut değil. Araçlar arası taşımada kullanılacak olan, yukarıdaki düz aws cloudformation create-stack-refactor çağrısı; yanında Serverless Framework mantıksal ID’lerinden CDK ID’lerine elle yazılmış bir kaynak eşlemesi.

TableV2 Yerine Table#

Synth almak TableV2’nin, refactor dışlama listesindeki AWS::DynamoDB::GlobalTable’ı ürettiğini gösteriyor. DynamoDB global tablolar best practice sayfası da bir Table’ın CloudFormation tipini değiştirerek GlobalTable’a dönüştürülemeyeceğini, denemenin tabloyu silebileceğini belirtiyor. Aynı key şeması ve PAY_PER_REQUEST ile Table, birebir aynı Properties’i artı Retain değerli DeletionPolicy ve UpdateReplacePolicy synth ediyor. Refactor yapılandırma değiştiremediği için Serverless Framework tanımının önce, normal bir deploy’da eşleşmesi gerekiyor; farklı mantıksal ID’ler ise kaynak eşlemesine giriyor.

# serverless.yml, refactor'dan önce normal deploy: CDK'nin synth ettiğiyle eşleştir
resources:
  Resources:
    OrdersTable:
      Type: AWS::DynamoDB::Table
      DeletionPolicy: Retain
      UpdateReplacePolicy: Retain
      Properties:
        TableName: ${self:service}-${sls:stage}-orders
        BillingMode: PAY_PER_REQUEST
        AttributeDefinitions:
          - { AttributeName: pk, AttributeType: S }
          - { AttributeName: sk, AttributeType: S }
        KeySchema:
          - { AttributeName: pk, KeyType: HASH }
          - { AttributeName: sk, KeyType: RANGE }

import * as dynamodb from 'aws-cdk-lib/aws-dynamodb'

// TableV2 değil Table: TableV2, stack refactoring'in desteklemediği
// AWS::DynamoDB::GlobalTable üretir.
const orders = new dynamodb.Table(this, 'OrdersTable', {
  tableName: 'orders-service-prod-orders',
  partitionKey: { name: 'pk', type: dynamodb.AttributeType.STRING },
  sortKey: { name: 'sk', type: dynamodb.AttributeType.STRING },
  billingMode: dynamodb.BillingMode.PAY_PER_REQUEST,
})

REST ve HTTP API Olayları için Tek Hono Uygulaması#

Hem REST hem HTTP API servisleri olan bir filo iki Hono uygulamasına ihtiyaç duymuyor. Adapter @hono/aws-lambda paketi olarak geliyor (eski hono/aws-lambda import yolu kullanımdan kaldırıldı) ve handle() fonksiyonu dört olay tipini kabul ediyor: REST payload’ı (APIGatewayProxyEvent), HTTP API v2 payload’ı (APIGatewayProxyEventV2), ALB olayları ve VPC Lattice v2 olayları. Kod handle’ı @hono/aws-lambda paketinden import etmeli. Router kodu bağlantısı verilen iki Lambdalith yazısında. Burada önemli olan, 1. Faz düzeneğinin ve route port’larının API tipleri arasında yeniden kullanılabilmesi; 2. Faz’ın küçük olmasının nedenlerinden biri bu. Hono Lambdalith’ten Sonra Lambda Web Functions: Ne Değişiyor yazısı Hono uygulaması Lambda Web Functions üzerinde çalışınca nelerin değiştiğini ele alıyor; buradaki sıra sorusunu etkilemiyor.

İlk PR’dan Önce Yazılacak Karar Kuralı#

Model bir beklenti veriyor; gerçek değeri servis verecek. Kuralı ilk PR’dan önce yazmak, ikisinin sonradan birbirine uydurulmasını önlüyor.

• Servis başına: istisnalar HTTP route’larının en fazla %20’si; eşleşen hafta içi pencerelerde p90 gecikme en fazla %10 kötü, pencereler Lambda Soğuk Başlangıçlarını Bundle Boyutu Değil, Boşluk Süresi Belirler yazısındaki yöntemle. Gecikme API Gateway access log’larından ($context.path ile gruplanmış $context.integrationLatency; $context.resourcePath ve $context.routeKey yalnızca proxy’yi gösteriyor) alınıp eski route karışımına göre ağırlıklandırılıyor. Lambda REPORT satırları fonksiyon başına yazıldığı için birleştirmeden sonra route’ları ayırmıyor.
• Filo düzeyinde: birleştirme fazında production’a kaçan hata sayısı en fazla CDK fazındaki kadar; iki fazın toplam insan review saati en fazla doğrudan yol tahmini kadar. Review saati PR zaman çizelgesinden geliyor (review’a hazır olmaktan son onaya); PR’lar karışım görünsün diye mechanical, behavior ya da rework etiketini taşıyor. Takvim günleri yanında raporlanıyor, çünkü izleme süreleri onlara hâkim ve kodu kimin yazdığına bağlı değil. Model review saati kontrolünün başarısız olacağını öngörüyor (16,5’e karşı 47,5); kural yine de duruyor, çünkü geçişin sınadığı şey tahminin kendisi.
• İstisna kuralı: şunlardan biri geçerliyse route kendi fonksiyonunu koruyor: servis medyanının en az iki katı bellek ihtiyacı, bundle’a 1 MB’tan fazla ekleyen kendine özgü bağımlılıklar, başka hiçbir route’un ihtiyaç duymadığı hassas bir IAM izni ya da kendine ait bir eşzamanlılık bütçesi (reserved concurrency ya da fonksiyonun ölçeklenme hızını tüketecek büyüklükte ani yükler).
• Birim maliyetler ekibin kendi PR temposuna göre ayarlanıp iş başlamadan dondurulmuş.

Stack başına kaynak sayısı (aws cloudformation list-stack-resources çıktısı sayılarak) her yolda 450’de alarm veren bir CI kontrolüne bağlanmalı. Bölünmüş bir stack sınıra orijinali kadar hızlı geri yaklaşabilir.

Varsayılanın Geçerliliğini Yitirdiği Durumlar#

Üç durum planı değiştiriyor. İlki, beş Lambdalith kriterinin tamamının sağlandığı bir servis. Bunu birleştirin ve IaC geçişinden önce yapın; model tasarrufu servis başına yaklaşık 4 gün olarak veriyor: CDK’de sonradan birleştirmeye göre yaklaşık %14, doğrudan port zaten tek stack’e sığacak olsaydı yaklaşık %10, 2. Faz doğrudan yolun fiyatlarıyla hesaplanınca yaklaşık %5; agentic mercekte ise yaklaşık 5 review saati, %10 civarı. İkincisi, entegrasyon kotasına yaklaşan bir HTTP API servisi. API Gateway HTTP API kota sayfası “Integrations per API” (API başına entegrasyon) değerini 300 olarak listeliyor ve artırılamaz olarak işaretliyor. Fonksiyon başına bir entegrasyonla bu noktayı geçen bir servisin, IaC aracından bağımsız olarak router’lara (fonksiyon başına birden fazla route) ya da API bölmeye ihtiyacı var; açık olan yalnızca birleştirmenin zamanlaması. REST tarafında karşılık gelen kota, “Resources per API” (API başına kaynak), 300 ama artırılabilir. Belgelenmiş azaltma yolu {proxy+} path’leri, yani Lambdalith biçimi. Üçüncüsü, çok az route’u olan bir servis. Sınırın yakınında bile değildir, yollar aşağı yukarı aynı maliyettedir ve soru hiç doğmaz.

Beş kriterden herhangi birini sağlamayan ya da ekibi beş production adımını kaldıramayacak bir servis için doğrudan yol geçerli. Kaynak sayısı için rahatlama o zaman Serverless Framework v4’ün ortak log grubu ya da tek stack’li CDK biçimi. Beşini de sağlayan bir servis için önce birleştirin, sonra geçin. Her iki durumda da plan servis başına sayılarla, yukarıdaki tablolara girilmiş ekibin kendi birim maliyetleriyle ve ilk PR’dan önce yazılmış bir karar kuralıyla başlıyor. Tahminler, bir geçiş kendi rakamlarını bunlara karşı raporlayana kadar tahmin olarak kalıyor.

Kaynaklar#

• AWS CloudFormation quotas (yeni sekmede açılır) - Şablon başına 500 kaynak sınırı dahil resmi limitler.
• CloudFormation stack refactoring (yeni sekmede açılır) - Kaynakları stack’ler arasında taşıma, kısıtları, CLI akışı ve desteklenmeyen kaynak tipleri listesi.
• DeletionPolicy attribute (yeni sekmede açılır) - Retain değerinin stack’ten çıkan fiziksel kaynağı nasıl koruduğu.
• DescribeType API reference (yeni sekmede açılır) - Refactor uygunluğunu belirleyen FULLY_MUTABLE, IMMUTABLE ve NON_PROVISIONABLE provizyon tiplerinin tanımı.
• AWS CDK refactoring guide (yeni sekmede açılır) - cdk refactor komutunun ne yaptığı, önizleme durumu ve kapsamı.
• cdk refactor command reference (yeni sekmede açılır) - CDK CLI refactor komutunun seçenekleri ve gereksinimleri.
• DynamoDB global tables best practices (yeni sekmede açılır) - CloudFormation Table kaynağının tip değiştirerek neden GlobalTable olamayacağı.
• Configuring CloudWatch log groups for Lambda (yeni sekmede açılır) - Özel log grupları ve birden fazla fonksiyonun logunu tek gruba gönderme.
• Creating event-driven architectures with Lambda (yeni sekmede açılır) - “Lambda monolith” anti-pattern’ı, altı sakıncası ve tercih edilen tek görevli alternatif.
• Serverless Applications Lens: AWS Lambda (yeni sekmede açılır) - Fonksiyon içindeki web framework yönlendirmesi yerine API Gateway yönlendirmesini kullanma önerisi.
• AWS Lambda Web Functions (yeni sekmede açılır) - AWS’nin ikinci konumu: Hono gibi web framework’leri Web Functions üzerinde adapter’sız çalışıyor.
• Use API Gateway Lambda authorizers (yeni sekmede açılır) - REQUEST tipi authorizer’ın $context.path alması ve path’e özgü policy döndürebilmesi.
• AWS::ApiGateway::BasePathMapping (yeni sekmede açılır) - Özel alan adı cutover’ını yerinde değişikliğe çeviren kesintisiz RestApiId güncellemesi; AWS::ApiGatewayV2::ApiMapping için ApiId aynı şekilde belgelenmiş.
• CDK LambdaIntegrationOptions (yeni sekmede açılır) - Route başına ikinci Lambda iznini ekleyen allowTestInvoke varsayılanı.
• CDK lambda.Function (yeni sekmede açılır) - Fonksiyon başına varsayılan rol ve logGroup özelliği.
• AWS CDK feature flags (yeni sekmede açılır) - @aws-cdk/aws-lambda:useCdkManagedLogGroup bayrağı ve önerilen değeri.
• Serverless Framework: AWS Infrastructure Resources (yeni sekmede açılır) - resources.extensions, kabul ettiği öznitelikler ve üretilen mantıksal ID adları.
• Serverless Framework: IAM Permissions For Functions (yeni sekmede açılır) - Servisteki tüm fonksiyonların paylaştığı varsayılan tek rol ve fonksiyon başına roller.
• Serverless Framework: serverless.yml reference (yeni sekmede açılır) - Tek ortak log grubu için provider.logs.lambda.logGroup seçeneği.
• Serverless Framework v3 source: merge-custom-provider-resources.js (yeni sekmede açılır) - RESOURCE_EXTENSION_NOT_EXISTING hatasının ve kabul edilen extension özniteliklerinin tanımlandığı yer.
• npm’de @hono/aws-lambda (yeni sekmede açılır) - Adapter paketi, handle() giriş noktası ve hono/aws-lambda için kullanımdan kaldırma notu.
• API Gateway HTTP API quotas (yeni sekmede açılır) - API başına route ve entegrasyon sayıları, sabit 300 entegrasyon kotası dahil.
• API Gateway REST API quotas (yeni sekmede açılır) - API başına kaynak sayısı ve bunu azaltmak için {proxy+} önerisi.