İki ay önce bir ödeme şirketinin mimari toplantısındayız. Sektör fintech, regülasyon BDDK, yük dakikada 3000 istek civarı. Backend’de iki monolit ve dört mikroservis var; partner entegrasyonları arttıkça “her partnera farklı API key, farklı rate limit, farklı IP whitelist” derdi başlamış. Mühendislik ekibi her partner için kod değişikliği yapıyor. Üç haftada bir yangın çıkıyor.
Tam Azure API Management (APIM) noktası. Bu yazıda APIM’i sahadan baktığımız haliyle anlatıyorum — pazarlama broşüründen değil. Hangi senaryoda gerçek değer üretir, hangisinde sadece pahalı bir reverse proxy olur, hangi tier’ı ne zaman seçersiniz, en sık karşılaştığımız üç hatalı kullanım nedir.
APIM aslında ne yapar?
İki cümleyle: Backend API’lerinizin önüne girer ve tek bir kapı olur. Bu kapıda authentication, rate limiting, transformation, logging, mock yanıtlar, caching, partner-bazlı politikalar — hepsi tek bir yerde tanımlanır. Backend’iniz bu işlerle ilgilenmez.
Üç ana bileşen üzerine kurulu:
- Gateway: Trafiği işleyen runtime. İstek gelir, politika çalışır, backend’e gider, dönüş tekrar politika çalışır, istemciye döner.
- Geliştirici Portalı: Partner ve iç geliştiriciler için self-service kapısı. “Şu API’yi nasıl çağırıyorum, key nasıl alırım, hangi rate limit var” sorularına cevap verir.
- Yönetim Düzlemi: Azure Portal veya REST API ile politikaları, ürünleri, kullanıcıları yönetirsiniz.
Saha kuralı: APIM’i “acaba lazım mı” diye değerlendirirken üç kriter sorun. Birden fazla backend‘iniz var mı? Birden fazla istemci tipi (mobil, web, partner, B2B) var mı? Backend’ten bağımsız politika değişikliği ihtiyacınız oluşuyor mu? İkisi evet ise APIM’i konuşalım.
Tier seçimi: Sahada görünen bütçe ve performans gerçekleri
APIM’in tier seçenekleri Microsoft’un sayfasında listelenmiş ama sahada baktığımız asıl tablo farklı. İşte üç yıllık deneyimimizden çıkardığımız kullanım kılavuzu:
| Tier | Aylık (TL) | Tipik kullanım | Uyarılar |
|---|---|---|---|
| Consumption | ~0–4.000 | Düşük trafik, serverless, prototip | Cold start var, VNet bağlantı sınırlı |
| Basic v2 | ~5.500 | Tek bölge, orta yük | Self-hosted gateway yok |
| Standard v2 | ~12.000 | Üretim, VNet entegrasyon | Çoğu kurumun başlangıç noktası |
| Premium | ~85.000+ | Çoklu bölge, multi-region failover, en yüksek SLA | Gerçekten gerek olmadan girmeyin |
Pratikte gördüğüm karar matrisi:
- Trafiğiniz dakikada 100 isteğin altında ve VNet’e bağlamak gerekmiyorsa → Consumption. Kullandıkça öde.
- Üretim, tek bölge, VNet ihtiyacı var, partner sayısı 50’nin altında → Standard v2.
- Multi-region active-active gerek, SLA %99.95’in üzerinde isteniyor → Premium. Ama önce gerçekten ihtiyacınız var mı tartışın. Pek çok proje bunu “olur ya” diye seçiyor, ay sonu fatura yakıyor.
JWT Validation: BDDK ve KVKK için pratik politika
Türkiye’de finans, sigorta ve kamu sektöründe API’lerin kimlik doğrulaması artık standart olarak Azure AD (Entra ID) ya da kurumun kendi OAuth2 sunucusuyla yapılıyor. APIM bu işi politika düzeyinde yapıyor; backend’inizin JWT bilmesine gerek kalmıyor.
<policies>
<inbound>
<base />
<validate-jwt header-name="Authorization" failed-validation-httpcode="401"
failed-validation-error-message="Yetkilendirme reddedildi"
require-expiration-time="true"
require-scheme="Bearer"
require-signed-tokens="true">
<openid-config url="https://login.microsoftonline.com/{tenant-id}/v2.0/.well-known/openid-configuration" />
<required-claims>
<claim name="aud" match="any">
<value>api://payments-prod</value>
</claim>
<claim name="scp" match="any">
<value>payments.read</value>
<value>payments.write</value>
</claim>
</required-claims>
</validate-jwt>
<rate-limit-by-key calls="60" renewal-period="60"
counter-key="@(context.Subscription.Id)" />
<ip-filter action="allow">
<address-range from="185.122.0.0" to="185.122.255.255" />
</ip-filter>
</inbound>
<backend>
<forward-request />
</backend>
</policies>
Bu politika tek bir API’de bütün BDDK kapısını kapatıyor. JWT geçerli mi, scope doğru mu, partnerin IP’si beyaz listede mi, dakikada 60 istekten fazla atıyor mu — hepsi kontrol ediliyor. Bunu her mikroservise yazmak yerine APIM’de bir kez yazıyorsunuz.
Rate limiting: Üç pratik desen
Çoğu ekip rate limiting’i “100 req/dk” gibi sabit bir sayı koyup unutuyor. Sahada işe yarayan üç desen var:
Desen 1: Subscription başına
Her partnerın bir Subscription Key’i var, ona göre limit. Kurumsal API tarafında %80 senaryosu bu.
Desen 2: Kullanıcı başına
JWT’den kullanıcı ID’si çıkar, ona göre limit. B2C senaryolarında: “bir kullanıcı dakikada 30 sipariş atamaz” gibi iş kurallarını burada kuruyorsunuz.
<rate-limit-by-key calls="30" renewal-period="60"
counter-key="@(context.Request.Headers.GetValueOrDefault("X-User-Id", "anon"))" />
Desen 3: Endpoint başına
“/api/payment” yavaş, “/api/lookup” hızlı. Endpoint bazında ayrı limit koyabilirsiniz. Yangın anlarında kritik endpoint’ler korunmuş olur.
Geliştirici Portalı: Kime, Nasıl Açılır?
Buradaki en sık hata: “Portal’ı kuralım, herkes görsün”. Hayır. Geliştirici portalı bir ürün gibi tasarlanmalı.
İki kullanım şekli var:
İç ekip portalı
Sadece kurum içinden erişim. Azure AD ile entegre, otomatik onboarding. Her yeni geliştirici şirkete katıldığında portal’a gelir, mevcut tüm API’leri görür, key talep eder, deneme isteklerini Try-It panelinde atar. Bu kullanım Türkiye’de en sık görülen yapı. Onboarding süresini günlerden saatlere indiriyor.
Partner portalı
Dış partnerlara açık. Burada sözleşmeli partnerlık modeli kuruyorsunuz: partner kayıt olur, ticari ekibimiz onaylar, sonra erişim açılır. Self-service ama denetimli. APIM portal’ında “products” yapısı tam bunun için var: “Bronze partner ürünü” 1000 req/saat, “Gold partner ürünü” 10000 req/saat. Partner bir ürüne abone olur, otomatik o limit ile çalışır.
Sahada gördüğüm bir başka pratik kullanım: portal’ı ürünlü kılmak. “Free tier”, “Starter”, “Business” planları, otomatik faturalama (Stripe entegrasyonu) — APIM portalı tam bunun için yapılmış. SaaS modeli düşünüyorsanız 2 ay sonra zaten ihtiyaç duyacaksınız.
Sahada en sık üç hatalı kullanım
1. APIM’i sadece reverse proxy olarak kullanmak
Tek bir backend, tek bir istemci, basit pass-through. Bu senaryoda APIM koymak “tank ile ekmek almak”. Application Gateway, Front Door veya basit bir nginx daha doğru. APIM’in değer önerisi politika ve portal tarafında; bunlardan yararlanmıyorsanız fazladan katman.
2. Cache politikasını rastgele eklemek
Cache eklemek pek tatlı görünür ama veriyi sürekli değişen endpoint’lerde cache yapmak büyük problem yaratır. “5 dakika cache yeter” denir, üç gün sonra finans ekibi yanlış raporu görür. Cache eklemeden önce: endpoint idempotent mi, veri ne sıklıkta değişiyor, kullanıcı için cache invalidation mekanizmamız var mı — sorulmalı.
3. Politikayı portalden tıklayarak değiştirmek
Production politikalarını portal’dan değiştirmek kâbus. Versiyon kontrolü yok, kim değiştirdi belli değil, geri alınamaz. APIM’in kendi REST API’si var; politikalarınızı Git’te tutun, CI/CD ile deploy edin. Bicep modülü ile bütün APIM tanımı kod halinde versiyonlanır:
az deployment group create
--resource-group rg-apim-prod
--template-file infra/apim-policies.bicep
--parameters env=prod
Ne zaman APIM kullanmamalıyım?
Şu üç durumda APIM gereksizdir:
- Tek backend, tek istemci, tek partner. Karmaşıklığa değmez.
- Çok düşük trafik (ayda toplam 100K istek altı), basit auth. Bir Function App + Easy Auth daha mantıklı.
- API gateway olarak Kubernetes’in kendi Ingress’ini kullanıyorsanız ve dış partner yoksa. Ingress + Cert-Manager + Auth gateway pattern’i ile aynı işi yapıyor zaten.
Maliyet hesabı: Sahada bir örnek
Geçen yıl sigorta sektöründen bir müşterimizin APIM kararı şu hesabın sonunda alındı. Karşılaştırdığımız iki seçenek:
| Kalem | APIM ile (Standard v2) | APIM olmadan (her servis kendi yapsın) |
|---|---|---|
| Aylık altyapı | ~12.000 TL | ~3.000 TL |
| Geliştirme zamanı (auth + rate limit + log) | 0 (politika) | 240 saat (her servis için) |
| Partner onboarding | ~2 saat (portalden) | ~3 gün (kod + deploy + doc) |
| Politika değişikliği | 15 dakika | Her servis için PR + deploy |
Aylık altyapı 9.000 TL daha pahalı ama partner onboarding’inde harcanan saatler 6 ay sonunda 4-5 partnera dağıldığında bütün maliyeti çıkardı.
Sık Sorulan Sorular
APIM’i Application Gateway veya Front Door yerine mi kullanırım?
Hayır, üçü farklı işler. Application Gateway L7 load balancing + WAF; Front Door global DNS + CDN + WAF; APIM ise API-specific gateway (politika, portal, geliştirici deneyimi). Çoğu mimaride üçü birlikte: Front Door → APIM → Backend.
APIM-Premium SLA’sı ne kadar?
Tek bölge için %99.9, çoklu bölge active-active için %99.95. Bunu yazılı garanti olarak alıyorsanız Premium tier şart, başka tier’lar bu SLA’yı sağlamıyor.
JWT validation politikasını her API’de tekrar yazmam mı gerek?
Hayır. APIM’de “All APIs” seviyesinde politika tanımlayıp tüm API’leri kapsayacak şekilde uygulayabilirsiniz. Override gerekirse spesifik API’de geçersiz kılarsınız.
Self-hosted gateway nedir, ne işe yarar?
APIM gateway runtime’ını kendi altyapınızda (on-prem, başka cloud, edge) çalıştırmak için Microsoft’un sunduğu Docker container. Hibrit senaryolarda backend’i Azure’a taşıyamıyorsanız gateway’i de yerinde çalıştırırsınız ama kontrol düzlemi Azure’da kalır.
Türkiye’den partner onboarding ne kadar sürer?
İyi tasarlanmış bir portal ile 2 saat — partner kayıt olur, sözleşme onayı, key oluşturulur, dokümanlardan integration yapar. Manuel süreçle 3-5 gün sürüyor genelde.
Sonuç
Azure API Management bir API stratejisi aracıdır. Tek başına teknolojik bir karar değil; ürün, partner, geliştirici deneyimi, regülasyon ve operasyonel disiplinin kesiştiği bir karardır. Doğru senaryoda kuruma 6 ayda kendi parasını çıkarır; yanlış senaryoda her ay para yakar.
APIM’i değerlendirme aşamasında olan ekipler için CloudSpark olarak ücretsiz 2 saatlik bir saha değerlendirmesi sunuyoruz: mevcut backend topolojinizi, partner sayınızı ve büyüme planınızı masaya yatırıp size uygun tier ve mimari önerisi çıkarıyoruz. İletişim sayfasından ulaşın.
