Serverless İç Servis Katmanı Seçmek

Bir serverless yapı tek takımı aştığında servisler birbirini çağırmaya başlar. Alışılmış cevap, başka bir takımın fonksiyon ARN’i üzerinde lambda:InvokeFunction yetkisi vermektir. Bu yetki, fonksiyon adını herkese açık bir sözleşmeye çevirir. Çağrılan takım artık fonksiyonu yeniden adlandıramaz, ikiye bölemez veya değiştiremez; çünkü göremediği bir repo’daki tüketiciyi bozar. Akla ilk gelen çözüm çağrılan servisi bir SDK istemci kütüphanesiyle sarmalamaktır ama işe yaramaz: bağımlılık kodda değil, IAM politikasındadır.

Bunların hepsinden önce daha zor bir soruyu cevaplayın: çağıranın cevabı gerçekten o an, o çağrının içinde alması gerekiyor mu? AWS’in kendi Lambda rehberi alternatif konusunda çok net. Anti-patterns in Lambda-based event-driven applications başlığı altında şunu yazıyor: “Lambda functions directly calling other Lambda functions is generally an anti-pattern due to cost and complexity concerns” ve yerine SQS kuyruğu ya da Step Functions öneriyor (event-driven mimariler). Aynı sayfa şunu da ekliyor: “Most Lambda invocations in production systems are asynchronous”. Serverless doğu-batı trafiğinin varsayılan şekli event’lerdir ve doğrusu da budur. Cevabı bekleyen kimse yoksa okumayı bırakın ve araya bir bus koyun.

Bu seri, o filtreden geçebilen çağrılarla ilgili. Bazılarının cevaba gerçekten ihtiyacı vardır: stok rezervasyonunun tutup tutmadığını bilmek zorunda olan bir checkout, nihai tutarlılığa tahammülü olmayan bir istek. AWS’in prescriptive guidance’ı bu noktayı kabul ediyor ve senkron çağrıların gerçek faydalarını sayıyor: öngörülebilir akış kontrolü, güçlü tutarlılık, basit hata yönetimi (senkron entegrasyon). Bu çağrılar her yapıda var. Soru bunları yapıp yapmamak değil; neyin üzerinden yapacağınız.

O trafik için bir mesh kurmazsınız; zaten elinizde olan parçalardan bir mesh oluşturursunuz. Varsayılan şu: API Gateway’de private bir REST API. Çağıranlar ona paylaşılan bir execute-api interface VPC endpoint üzerinden ulaşır. Her çağrıyı bir resource policy ve AWS_IAM yetkilendirmesi denetler. Sidecar yok, control plane yok. Bu, event’lerin alternatifi değildir. AWS’in az önce yazmamanızı söylediği direct invoke’un yerine geçen şeydir.

Bunu varsayılan yapan iki şey var ve hiçbiri kimlik değil. Sabit maliyet paylaşılıyor: tek bir interface endpoint, VPC’deki bütün private API’lere ayda onlarca dolara hizmet ediyor; asıl rakip ise servis başına faturalandırıyor. İkincisi, API Gateway bir API yönetim katmanı; yani çağrılan servis bir route’a throttle koyabiliyor, isteği bir şemaya karşı doğrulayabiliyor ve bir sözleşme yayımlayabiliyor. Argümanlar bunlar ve bu bölüm onları aşağıda VPC Lattice’e karşı tek tek kuruyor. Lattice, kimlik tarafını en az bu katman kadar iyi yapıyor. Bunu baştan net söyleyelim: bu katmanı, bir iç çağrıda route bazlı IAM yetkilendirmesi almanın tek yolu sandığınız için seçiyorsanız, yanlış sebeple seçiyorsunuz.

Takımlar arası direct invoke’un asıl bedeli

Doğrudan RequestResponse invoke, iki fonksiyon arasında hiçbir şey durmadığı için bedavaymış gibi görünür. O boşlukta dört maliyet saklıdır.

Fonksiyon adı sözleşmeye dönüşür. B takımının execution role’ü arn:aws:lambda:...:function:teamA-orders üzerinde lambda:InvokeFunction taşır. Fonksiyonu yeniden adlandırmak, iki handler’a bölmek, farklı bir compute modeline taşımak: hepsi A takımının sahibi olmadığı ve arayamadığı bir politikayı bozar.

Aynı saniyeye iki kez ödersiniz. A’dan B’ye senkron bir invoke sırasında A boşta bekler ama kendi bellek katmanından faturalanmaya devam eder. Bu bekleme B’nin tüm süresi boyunca sürer. Zinciri üç servis derinleştirin: aynı milisaniyeler üç faturaya birden düşer.

Throttling sözleşmesi yoktur. Çağrılan servis, tek bir çağırana saniyede 200 istek sınırı koyup bunu platforma uygulatamaz. Elindeki tek kaldıraç reserved concurrency’dir ve kaba bir alettir: tüm çağıranları aynı anda kısar, kendi asenkron tetikleyicileri dahil.

Telemetri fonksiyon sınırında biter. Fonksiyon bazlı metrikler vardır ama orders API’sinin bütünü için route bazlı gecikme veya hata oranı yoktur. Üstelik doğu-batı trafiği kuzey-güney trafiğiyle aynı sayıların içinde karışır.

Eski rakamlar dolaşımda olduğu için bir detayı sabitlemekte fayda var. Lambda invocation payload kotası senkron çağrılarda her iki yönde 6 MB, asenkron çağrılarda 1 MB’dır. Eski yazıların hâlâ tekrarladığı 256 KB değil (Lambda kotaları). Ayrıca direct invoke’ta retry davranışı, çağrılanın yayımladığı bir sözleşmeye göre değil, çağıranın seçtiği bir bayrağa göre değişir.

Katmanın şekli

Bu desenin merkezindeki değişiklik küçüktür: çağıranın execution role’ü, fonksiyon ARN’i üzerinde lambda:InvokeFunction yerine bir route ARN’i üzerinde execute-api:Invoke taşır. Çağrılan fonksiyonun ARN’i kendi stack’inden hiç dışarı çıkmaz.

Bu yolda iki kapı üst üste durur ve ikisinin de izin vermesi gerekir. API resource policy, API’ye hangi VPC veya VPC endpoint’in hiç erişebileceğine karar verir. Method yetkilendirmesi ise hangi IAM principal’ının hangi route’u çağırabileceğine karar verir. Üçüncü bir kapı da opsiyonel olarak var: interface endpoint’in kendisine yazılan VPC endpoint policy. O da endpoint’in hangi API’lere ulaşabileceğini sınırlar; yani platform takımı, servis takımlarının genişletemeyeceği bir sınır çizebilir. AWS bunu daha yukarıya koyuyor ve best practice olarak sayıyor: “For the most secure data perimeter, you can create a VPC endpoint policy” (private REST API’ler). 105. bölüm bunu kuruyor.

Katmanın maliyeti

Aşağıdaki fiyatlar us-east-1 liste fiyatlarıdır, 2026-07-14’te okundu. Karar vermeden önce kendi bölgeniz için yeniden hesaplayın.

Bileşen	Tarife	Kaynak
Private REST API istekleri	milyon başına $3,50 (ilk 333M/ay)	API Gateway fiyatlandırma
Interface VPC endpoint	endpoint başına AZ-saat başına $0,01	PrivateLink fiyatlandırma
PrivateLink veri işleme	GB başına $0,01 (ilk PB/ay)	PrivateLink fiyatlandırma

Sabit kısım küçük ve paylaşılıyor. İki AZ’de tek bir endpoint ayda yaklaşık $14,60 tutar (2 x $0,01 x 730 saat) ve o tek endpoint, VPC’deki her private API’ye hizmet eder. Kısmi endpoint saatleri tam saat olarak faturalanır; yani taban maliyet gerçek ama sabittir.

Değişken kısım ise kaçınılmaz bedeldir. REST, API Gateway’in en pahalı katmanıdır ve private olabilen tek katmandır. Daha ucuz HTTP API tarifesine kaçış yoktur. Tüm yapı genelinde ayda 50 milyon iç çağrıda, eskiden bedava görünen tesisat için yaklaşık $175 ödersiniz. Bu rakamı, birileri faturada bulmadan önce takıma siz söyleyin. Rakamın bir özelliğine dikkat edin: bu katmanda o 50 milyon çağrı ister tek servisten ister on iki servisten geçsin, fatura değişmez. Alternatifte durum böyle değil ve bir sonraki bölüm bunun nedenini anlatıyor.

Çağrılar takımlar arası bir sözleşme sınırıysa ödemeye değer. O $175; çağrılan servisin kendi route’una koyduğu bir throttle, şemaya karşı istek doğrulama ve dışa aktarılabilir bir sözleşme satın alır. Route bazlı yetkilendirme satın almaz, çünkü bir sonraki bölümün gösterdiği gibi alternatifte de o var. Route bazlı metrikler de bedava değil. Latency, 4XXError ve 5XXError metrikleri ancak detaylı CloudWatch metriklerini (MetricsEnabled) açtığınızda method ve resource boyutunda gelir. Bu ayar varsayılan olarak kapalıdır ve custom metric olarak faturalanır. Geniş bir yapıda maliyeti belirleyen şey kardinalitedir; ya bütçesini ayırın ya da route bazlı gecikmeyi access log’lardan okuyun. Tek bir servisin kendi sınırı içinde ise ödemeye değmez. Aynı takımın sahip olduğu, aynı pipeline ile dağıtılan ve bağımsız tüketicisi olmayan iki Lambda birbirini doğrudan çağırmaya devam etmeli. Daha iyisi: iki ayrı Lambda olmaktan vazgeçmeli.

Varsayılandan ne zaman sapılır

Herhangi bir taşıma katmanı seçmeden önce şunu sorun: çağrının cevaba ihtiyacı var mı? Çağıran, çağrılanın cevabını akış içinde beklemiyorsa EventBridge veya SQS daha ucuz, daha erişilebilir ve bağımlılığı resmileştirmek yerine tamamen kaldıran seçenektir. Bu katmana yalnızca gerçek bir istek/yanıt çağrısı aittir.

VPC Lattice tek paragrafla geçiştirilemez, çünkü bu serinin tamamına yöneltilebilecek en güçlü itiraz o ve lehindeki argüman çoğu yazının kabul ettiğinden daha iyi. Önce tam gücüyle koyalım.

Lattice, AWS’in tam da bu trafik için kurduğu servis. Lambda yerleşik bir hedef tipi. Auth policy’leri, vpc-lattice-svcs:Invoke eylemi üzerinde SigV4 ile değerlendirilen IAM policy dokümanları.

Üstünlüğünün nerede olduğunu tam yerine koymak gerekiyor, çünkü bu argümanın özensiz hâli iki yönde birden yanlış. Üstünlük route bazlı yetki değil. API Gateway bunu resource ARN’i ile ifade ediyor (.../v1/POST/orders) ve 103. bölüm tam olarak bunu kuruyor. Lattice de aynısını yapabiliyor: resource’u bir path’e daraltarak ya da RequestMethod ve RequestPath koşullarıyla. Asıl üstünlük condition setinin geri kalanı: RequestHeader, RequestQueryString, SourceVpc ve SourceVpcOwnerAccount (auth policy’ler). API Gateway’in resource policy’sinin cevap verecek bir header ya da query-string koşulu yok; execute-api’nin topu topu tek bir servis condition key’i var: viaDomainArn. Bir request header’ına göre yetkilendirmeniz gerekiyorsa ikisinden yalnızca Lattice bunu yapabiliyor. Bir kayıt: TLS passthrough listener’da Lattice de header’ları okuyamıyor. Üstelik Lattice çağırana yönetecek bir endpoint tesisatı bırakmıyor, VPC’leri doğrudan bir service network’e bağlıyor ve RAM ile hesaplar arası paylaşıyor.

O hâlde açıkça söyleyelim. Kimlik cephesinde Lattice bu katmanın gerisinde değil, önünde. Private API Gateway’i, bir iç çağrıda route bazlı IAM yetkilendirmesi almanın tek yolu olduğuna inandığınız için seçtiyseniz, var olmayan bir sebeple seçmişsiniz. AWS’in kendi çerçevesi de aynı yöne bakıyor: API Gateway’i north-south ön kapı, Lattice’i servisler arası katman olarak konumluyor (What is VPC Lattice). Bu seri o çerçeveye karşı argüman veriyor ve AWS bu ikisini karşılaştıran bir karar rehberi yayımlamış değil. Aşağıdaki argüman AWS’in değil, benim.

Argüman iki şeyden ibaret: maliyetin şekli ve API yönetimi. Bu sırayla.

Maliyetin şekli. Lattice servis başına saatte $0,025, yani ayda yaklaşık $18,25 alıyor; üstüne işlenen GB başına $0,025. İstekler servis başına saatte ilk 300.000’e kadar ücretsiz; trafik saatlere eşit dağılıyorsa bu ayda kabaca 219 milyon istek eder. Sonrası milyon başına $0,10 (VPC Lattice fiyatlandırma, 2026-07-14’te okundu). Şimdi bunu yukarıdaki rakamların karşısına koyun: tek paylaşılan endpoint için sabit $14,60 ve milyon başına $3,50. İki sabit maliyet farklı davranıyor ve bütün oyun burada. Lattice’in tabanı servis sayısıyla doğrusal büyüyor. API Gateway’in tabanı hiç büyümüyor.

Bu asimetri çoğu yapıyı, istek ücreti daha konuşulmadan karara bağlıyor:

Yapı	Private API Gateway	VPC Lattice
20 servis, her biri ayda 200k istek	yaklaşık $29	yaklaşık $365
20 servis, her biri ayda 5M istek	yaklaşık $368	yaklaşık $375
3 servis, her biri ayda 50M istek	yaklaşık $545	yaklaşık $69

Servis başına ve veri işlemeyi yok sayarsak geçiş noktası şurası: Lattice’in $18,25’i, API Gateway’in milyon başına $3,50’siyle geri ödendiği an. Bu da servis başına ayda kabaca 5,2 milyon istek. Altında private API daha ucuz ve geniş, sığ bir yapıda arada uçurum var. Üstünde Lattice hızla öne geçiyor, çünkü marjinal istek fiyatı 35 kat ucuz.

API yönetimi. Para başa baş geldiğinde bile ayakta kalan argüman bu. API Gateway, çağrılan servisin kendini savunmasına ve bir sözleşme yayımlamasına izin veriyor. Stage düzeyinde method bazlı throttling var, yani bir takım sahibi olduğu route’a tavan koyabiliyor. İstek gövdesini entegrasyon çalışmadan önce bir şemaya karşı doğruluyor. OpenAPI dokümanı dışa aktarıyor. WAF alıyor ve cache yapabiliyor. Lattice’te bunların hiçbiri yok: hiçbir türde throttling yok, istek doğrulama yok, sözleşme artefaktı yok, WAF yok, cache yok. Listener rule’ları header, method ve path eşleştiriyor; hepsi bu. Çok takımlı bir yapıda, yetkili bir çağırana hayır diyemeyen bir servis gerçek bir operasyonel boşluktur. Yetkiyi elinde tutan her takım sizi servis kotasına kadar zorlayabilir ve elinizde duracak bir kaldıraç yoktur. Bu katmanın doldurduğu boşluk tam olarak o. Önemli bir kayıt: AWS, usage plan throttling ve kotaların “are not hard limits, and are applied on a best-effort basis” olduğunu söylüyor; çağıran bazlı kotalar ise API key gerektiriyor ve AWS ayrıca API key’leri yetkilendirme için kullanmamanızı söylüyor. Savunulabilir iddia route bazlı throttling; fatura sıkılığında çağıran bazlı kota değil.

Şu durumlarda istisnaya geçin: tek bir servis ayda kabaca 5 milyon çağrıyı aşıyorsa, hedefler tamamen Lambda değilse (Lattice ECS, EKS, EC2, ALB ve IP hedeflerini kapsar), çağıran başına endpoint tesisatı kurmadan VPC’ler veya hesaplar arası keşif gerekiyorsa, ya da yetkilendirmeniz gerçekten bir header veya query-string koşuluna ihtiyaç duyuyorsa. Bu listede olmayan şeye dikkat edin: gRPC. Compute’unuz hâlâ Lambda fonksiyonlarıysa Lattice’e geçmek size gRPC kazandırmaz; nedenini 102. bölüm anlatıyor. Bir de ününe rağmen Lattice’in tamamen Lambda’lı bir yapıda size vermediği bir şey var: health check. AWS, Lambda target group’larında health check’in desteklenmediğini açıkça yazıyor.

ECS Service Connect, App Mesh’in kapandığını duyan herkesin ilk uzandığı isim. Tamamen Lambda’dan oluşan bir yapı için ise daha zayıf bir seçenek değil. Boş küme.

Service Connect katılacağınız bir ağ değil, bir ECS servisinin deployment özelliği. Data plane’i, ECS’in her task’a enjekte ettiği yönetilen bir Envoy sidecar’ı; yapılandırması bir ECS servisinin serviceConnectConfiguration alanında yaşıyor; kaydı ise hiç Route 53 kaydı üretmeyen bir Cloud Map HTTP namespace’i. Considerations sayfası kategorik (considerations): “Only the tasks that services create are supported.” ECS dışındaki uygulamalar için AWS şunu yazıyor: “can connect through the Service Connect proxy but can’t resolve Service Connect endpoint names” (Service Connect). Lambda fonksiyonunun task’ı yok, sidecar’ı yok, çözecek bir adı yok. AWS hiçbir yerde “Lambda desteklenmiyor” cümlesini kurmuyor, çünkü kurmasına gerek yok: dışlama yapısal. Lambda desteği için açılan roadmap talebi Şubat 2023’ten beri açık.

AWS yarın o desteği yayımlasa bile değişmeyecek iki şey var. Service Connect’in IAM yetkilendirmesi yok. Erişim kontrolü security group’lardan ibaret ve TLS’i peer authentication içermeyen bir şifreleme, yani mutual TLS de yok. Bu katmanı Service Connect ile takas etmek, kimlik sınırını ağ sınırıyla değiştirmek olur. Bir de asimetri tek yönlü işliyor: task role’ünde execute-api:Invoke taşıyan bir ECS task’ı, burada anlatılan private API’nin birinci sınıf çağıranıdır. Bu katman ECS istemcilerini kabul ediyor. Service Connect ise Lambda istemcilerini kabul etmiyor.

Service Connect, yapı ECS ile ECS arasında konuşuyorsa, tek Region ve tek namespace içindeyse ve kısa adlar, retry, outlier detection ile servis bazlı metrikleri kod değiştirmeden ve ek servis ücreti ödemeden istiyorsanız doğru cevaptır. AWS de onu bu şekil için öneriyor ve ECS tarafında App Mesh’in yerine geçen şey bu. Ama bu, bir Lambda’nın alabileceği bir şekil değil. Karma bir yapıda hesap yine değişiyor: Service Connect yalnızca ECS yarısını kapsar, yani iki ayrı doğu-batı mekanizması işletirsiniz. İkisini birden kapsayan tek katman Lattice, çünkü LAMBDA, INSTANCE ve IP ile birlikte yerleşik bir hedef tipi. “Hedefler tamamen Lambda değilse” kuralının Service Connect’i değil, Lattice’i işaret etmesinin asıl sebebi bu.

Lambda hedefli ALB, REST API’den istek başına daha ucuzdur ve bir sözleşme katmanı değildir. IAM yetkilendirmesi yok, route bazlı usage plan yok, üstüne kendi saatlik ve LCU faturası var. Yük dağıtır; sözleşme yayımlamaz.

Direct invoke, tek bir servisin kendi sınırı içinde, çağıran ile çağrılanın birlikte deploy edildiği yerde doğru olmaya devam eder. Takım sınırında doğru olmaktan çıkar. Kural bundan ibaret.

Ölçmeyi planladıklarım

POC dağıtılmadı; dolayısıyla bunlar sonuç değil, hedef. İlk sayı çağrı başına gateway ek yükü: route bazında, p50 ve p99’da Latency eksi IntegrationLatency. Çağrı başına verginin size ne aldığı ya da neye mal olduğu tam olarak bu. Sonra aylık fatura: istek sayısı çarpı milyon başına $3,50, artı endpoint AZ-saatleri, artı işlenen PrivateLink GB’ı. Bunu, yapının gerçek servis sayısındaki Lattice servis-saat karşılığıyla yan yana koymak gerekiyor. Sonra route bazlı 4XXError ve 5XXError oranları; direct invoke bunları hiç üretemez. Ve hepsinden önemli tek benimseme metriği: takımlar arası lambda:InvokeFunction yetkilerinin sayısı. Hedef sıfır.

Varsayılanın geçerli olduğu koşullar

Hedefleri tamamen Lambda olan, istek/yanıt çağrıları yapan ve orta hacimli, çok takımlı bir serverless yapı için doğru varsayılan şu: paylaşılan tek bir execute-api interface endpoint arkasında private bir REST API ve route bazlı AWS_IAM yetkileri. Size kazandırdığı şey kimlik değil; o alternatifte de var. Servis sayısıyla büyümeyen sabit bir maliyet ve alternatifte bulunmayan API yönetimi: çağrılanın kendi koyduğu throttle, istek doğrulama ve yayımlayabildiği bir sözleşme. Sidecar yok, control plane yok.

Filtreleri sırayla uygulayın, çünkü en çok işi ilki eliyor. Yanıtı bekleyen kimse yoksa bir event bus kullanın; bu serinin tamamı devre dışı kalır. Hedefler tamamen Lambda değilse ya da bir servis ayda kabaca 5 milyon çağrıyı aşıyorsa Lattice kazanmaya başlar. gRPC gerekiyorsa değiştirdiğiniz şey gateway değil, compute olur. Ve byte’ları hangi formatta gönderirseniz gönderin, sözleşme olarak şemayı tutun; çünkü wire format değiştiğinde hâlâ birlikte yaşayacağınız kısım o.

İlk adım geçişin kendisinden ucuz: hesabınızda bugün takımlar arası kaç tane lambda:InvokeFunction yetkisi olduğunu sayın. O sayı, taşıdığınız bağımlılığın büyüklüğüdür.

Bu, trafiği neyin üzerinden yürüteceğinize karar verir. Trafiğin ne taşıyabileceği hakkında henüz bir şey söylemez: gRPC söz konusu mu, protobuf bu taşıma katmanında hakkını veriyor mu. 102. bölüm herhangi bir şey kurulmadan önce wire format’ı karara bağlıyor.

Kaynaklar

• Event-driven architectures in Lambda - AWS’in kendi anti-pattern bölümü: “Lambda functions directly calling other Lambda functions is generally an anti-pattern”. Event’lerin neden varsayılan, bu katmanın neden istisna olduğunun kaynağı.
• Synchronous integration - AWS’in senkron çağrılar için tarafsız gerekçesi: öngörülebilir akış kontrolü, güçlü tutarlılık, basit hata yönetimi; karşısında sıkı bağlanma ve zincirleme hatalar.
• AWS Lambda quotas - Senkronda her yönde 6 MB, asenkronda 1 MB invocation payload. Eski yazıların hâlâ tekrarladığı 256 KB değil.
• Private REST APIs in API Gateway - Çok sayıda private API için tek paylaşılan endpoint ve “For the most secure data perimeter, you can create a VPC endpoint policy” best practice’i.
• Amazon API Gateway pricing - İlk 333M istek için REST milyon başına $3,50; HTTP API milyon başına $1,00. Fiyatlar 2026-07-14’te, us-east-1 için okundu.
• AWS PrivateLink pricing - Interface endpoint’ler endpoint başına AZ-saat üzerinden faturalanır, kısmi saatler tam saat sayılır; artı GB başına veri işleme.
• VPC Lattice auth policy’leri - vpc-lattice-svcs:Invoke üzerinde IAM policy’leri; RequestMethod, RequestPath, RequestHeader ve RequestQueryString condition key’leriyle. Lattice’in kimlik cephesinde bu katmanın gerisinde değil önünde olmasının sebebi.
• What is VPC Lattice - AWS’in “fully managed application networking service” tanımı ve etrafında kurulduğu ağ sahibi ile servis sahibi ayrımı.
• Amazon VPC Lattice pricing - Servis-saat başına $0,025, GB başına $0,025, saatte ilk 300.000 istek ücretsiz ve geçiş noktası hesabının dayandığı 100 servislik örnek.
• Amazon ECS Service Connect - ECS dışındaki uygulamalar “can’t resolve Service Connect endpoint names”. Tamamen Lambda’dan oluşan bir yapı için neden boş küme olduğunun kaynağı.
• ECS Service Connect considerations - “Only the tasks that services create are supported”: Lambda’nın yapısal dışlanması.