Microsoft AZ-104: Azure Yük Dengeleme ve Trafik Yönetimi — Çalışma kılavuzu

By Laurynas Brazys · 6 August 2026 · #microsoft #az-104 #certification #exam-prep #study-guide

Şunun bir parçası: Microsoft Azure Administrator Associate AZ-104 — Çalışma kılavuzu. Doğrulanmış cevaplarla şurada pratik yapın: Microsoft sınav merkezi, veya şurada süreli deneme sınavları çözün: ExamRoll.io.

Genel Bakış

Azure, trafiği dağıtmak ve korumak için katmanlı bir portföy sunar: Azure Load Balancer (Katman 4, TCP/UDP), Application Gateway (Katman 7, HTTP/S), Azure Front Door (küresel Katman 7 edge), Azure Traffic Manager (DNS tabanlı) ve Azure CDN (edge önbellekleme). Her biri, küresel DNS kararlarından ve edge POP’larından bölgesel HTTP yönlendirmesine ve özel, doğu-batı (east-west) trafiğine kadar istek yolunun belirli bir bölümünü hedefler. Ustalık, protokol ve hedef kitle için doğru hizmeti seçmekten, bunları doğru şekilde bir araya getirmekten ve güvenilir yük devretmeyi (failover) sağlayan durum yoklamalarını (health probe) ve kuralları yapılandırmaktan gelir.

Azure Load Balancer (L4): SKU’lar, yapı taşları, NAT/giden trafik ve floating IP

Standard Load Balancer, üretim ortamları için uygun, L4 seviyesinde bir yük dengeleyicidir. Bölgeye duyarlı (zone-aware)/bölge yedeklidir (zone-redundant), HA Ports’u, gelişmiş tanılama/metrikleri, varsayılan olarak güvenli (kurallar tanımlamadığınız sürece gelen trafik olmaz) yapıyı, yapılandırılabilir giden (outbound) kurallarını ve geniş arka uç (backend) ölçeğini destekler. Basic, sınırlı ölçek/özelliklere sahip ve bölge yedekliliği olmayan eski bir SKU’dur; kullanımdan kaldırılma sürecindedir ve yeni iş yükleri için seçilmemelidir.

Temel bileşenler trafiğin nasıl aktığını tanımlar:

Frontend IP: İstemcilere sunulan VIP. Harici (External) LB’ler bir Public IP veya Public IP Prefix kullanır; dahili (internal) LB’ler ise bir alt ağdan (subnet) özel bir statik IP kullanır. Standard, birden çok frontend’i ve bölge yedekli (zone-redundant) genel IP’leri destekler.
Backend pool: Aynı bölge/VNet içindeki NIC’ler, NIC’ler üzerindeki IP yapılandırmaları veya VM scale set örnekleri. Tek bir havuz (pool) birçok kurala hizmet edebilir. Standard, bir bölge içindeki bölgeler arası (cross-zone) arka uçları destekler.
Health probes: Hangi arka uç örneklerinin sağlıklı olduğunu belirler. TCP yoklamaları bir el sıkışmayı (handshake) tamamlar; HTTP/HTTPS yoklamaları bir yola (path) GET isteği yapar ve 200–399 arası yanıtları başarılı sayar. Protokolü, portu, yolu (HTTP/S için), aralığı (interval) ve sağlıksız eşiğini (bir örneği devre dışı bırakmadan önceki ardışık hata sayısı) siz kontrol edersiniz.
Load balancing rules: Bir frontend’i (IP/port/protokol) bir backend pool’a ve health probe’a bağlar. Kural ayarları arasında arka uç portu, protokol (TCP/UDP), oturum kalıcılığı (session persistence), boşta kalma zaman aşımı (idle timeout) ve Floating IP (Direct Server Return) bulunur.

Inbound NAT kuralları, belirli bir frontend portunu tek bir arka uç NIC/portuna yönlendiren VM başına çevirilerdir (örneğin, RDP veya SSH’ı yük dengeleme olmadan tek bir VM’e açmak). Health probe kullanmazlar ve ölçeklendirme (scale-out) mekanizması değildirler.

Outbound kuralları, LB’nin genel frontend’leri aracılığıyla internete bağlantı başlatan Standard Load Balancer arka uçları için SNAT davranışını tanımlar. Hangi frontend’in/frontend’lerin SNAT portları sağlayacağını ve arka uç örneği başına kaç port ayrılacağını kontrol etmenize olanak tanır, bu da yüksek eş zamanlı giden trafik durumunda SNAT port tükenmesini önlemeye yardımcı olur. Eğer alt ağa bir NAT Gateway bağlıysa, bu LB SNAT’ın önüne geçer; tutarlı ve ölçeklenebilir giden trafik için NAT Gateway’i tercih edin.

Floating IP (Direct Server Return), hedef IP/portunun uçtan uca korunması gerektiğinde kullanılan bir kural seçeneğidir. SQL Server Always On kullanılabilirlik grubu (availability group) dinleyicileri gibi kümelenmiş (clustered) senaryolar için gereklidir. SQL AG için, kümenin yoklama portuna (probe port) bir TCP yoklaması (HTTP değil) ile dahili bir Standard Load Balancer kullanın ve LB kuralında Floating IP’yi etkinleştirin; SQL bir HTTP iş yükü olmadığından 1433 portunu HTTP ile yoklamayın.

Dahili ve harici yük dengeleyiciler arasındaki seçim, hedef kitleye ve güvenlik sınırına bağlıdır. İş uygulamaları (line-of-business), veritabanları ve NVA’lar için bir VNet içinde veya özel bağlantı (VPN/ExpressRoute) aracılığıyla özel bir VIP sunarken dahili bir LB kullanın. İnternete yönelik L4 hizmetleri için harici bir LB kullanın. Dahili LB’ler için hedef alt ağda statik bir özel frontend atayın; harici LB’ler için bir Standard Public IP bağlayın ve isteğe bağlı olarak birden çok frontend kullanın.

Cross-region Load Balancer, bölgeler arasında küresel, anycast Katman 4 yük dengelemesi sağlar. Her bölgeye Standard Public Load Balancer’lar (bölgesel katman - regional tier) dağıtır ve bunların genel frontend’lerini tek bir küresel Load Balancer’ın (küresel katman - global tier) arka ucuna yerleştirirsiniz. Küresel LB, her bölgesel LB’ye durum yoklamaları kullanır ve 5’li demet (5-tuple) hashing’e dayalı akış simetrisi (flow symmetry) ile istemcileri en yakın sağlıklı bölgeye (gecikme süresine göre) yönlendirir. Yalnızca TCP/UDP’dir—TLS sonlandırma (termination) yoktur—ve bölgesel L7 ağ geçitlerini (gateway) tamamlar.

Application Gateway (L7) ve Azure Front Door (global L7)

Application Gateway, WAF özellikli bölgesel bir Katman 7 ters proxy’dir. HTTP/HTTPS’i sonlandırır, üst bilgileri ve yolları denetler ve özel veya genel arka uçlara yönlendirme yapar.

Temel Application Gateway yapıları:

Dinleyiciler (Listeners): Trafiği kabul etmek için bir ön uç IP/bağlantı noktası/ana bilgisayar adı ve SSL ayarlarını bağlar. SNI, IP başına birden çok TLS sitesini etkinleştirir. Tek site için temel dinleyicileri, ana bilgisayar tabanlı yönlendirme için çok siteli dinleyicileri ve geniş kapsam için joker karakterli ana bilgisayarları kullanın.
Yönlendirme kuralları ve HTTP ayarları: Kurallar, dinleyicileri arka uç havuzlarıyla eşler ve arka uçlara uygulanan HTTP ayarlarını (protokol, bağlantı noktası, ana bilgisayar üst bilgisi geçersiz kılma, çerez tabanlı benzeşim, bağlantı boşaltma, istek zaman aşımı) belirtir. Yönlendirme yapabilir, üst bilgileri yeniden yazabilir veya URL yolu segmentlerine göre yönlendirme yapabilirsiniz.
Arka uç havuzları (Backend pools): Hedefler NIC IP’leri, FQDN’ler, app service’ler veya VM scale set’leri olabilir. Özel sistem durumu yoklamaları (health probes) belirli yolları/ana bilgisayarları kontrol eder ve başarı durum kodlarını dikkate alır.
WAF: v2’de özel kurallar, hariç tutma listeleri ve rota başına ilişkilendirme ile algılama veya önleme modunda OWASP Core Rule Set tabanlı koruma. v2’de otomatik ölçeklendirme ve alanlar arası yedeklilik desteklenir.

Gelişmiş L7 desenleri:

URL yolu tabanlı yönlendirme: Tek bir VIP arkasında mikro servis yayılımını (fanout) etkinleştirerek /api/* yolunu mikro servislere ve /images/* yolunu statik bir kaynağa veya CDN’e yönlendirin.
Çok siteli barındırma (Multi-site hosting): SNI dinleyicileri ve ana bilgisayar üst bilgisi tabanlı kurallar kullanarak contoso.com ve fabrikam.com’u tek bir ağ geçidinde barındırın. Site başına WAF ilkeleri aracılığıyla güçlü yalıtımla birleştirme için kullanışlıdır.
SSL sonlandırma (SSL termination): Merkezi sertifika yönetimi ve WAF denetimi için ağ geçidinde TLS yükünü boşaltın. Arka uçlar şifreleme veya istemci sertifikası doğrulaması gerektirdiğinde uçtan uca TLS (yeniden şifreleme) kullanın.

Azure Front Door, anycast, bölünmüş TCP (split TCP) ve POP’tan kaynağa optimizasyon ile uçta (edge) global HTTP/HTTPS yük dengeleme ve hızlandırma sağlar. Global yönlendirme, uç WAF ve isteğe bağlı uç önbellekleme gerektiren internete yönelik uygulamalar için en iyisidir.

Global yük dengeleme: Birden çok POP’tan gelen sistem durumu yoklamalarını kullanarak kullanıcıları en düşük gecikme süresine sahip sağlıklı kaynağa yönlendirir. Kaynak grupları (Origin groups), öncelik ve gecikme tabanlı yük devretmeyi destekler ve gerekirse oturum benzeşimi (session affinity) sağlar.
WAF: Bot korumaları, özel kurallar, coğrafi/IP filtreleri, hız sınırlama (rate limiting) ve rota başına ilişkilendirme içeren yönetilen kurallar.
Önbellekleme (Caching): Front Door Standard/Premium ile uç önbellekleme entegredir; yola göre önbellekleme davranışını tanımlayın, sorgu dizesi (query-string) önbelleklemesini ve TTL’leri kontrol edin ve statik içeriği global olarak boşaltın.
Sistem durumu yoklamaları (Health probes): Çeşitli POP’lardan yapılandırılabilir yol, aralık ve protokole sahip kaynak grubu başına yoklamalar (HTTP/HTTPS). Yönlendirme kararları, sistem durumu ve gecikme süresini birleştirir.

Bölgesel L7 ihtiyaçları (özel arka uçlar, doğu-batı trafiği, karmaşık yeniden yazmalar) için Application Gateway’i ve global L7, uç güvenliği ve hızlandırma için Front Door’u kullanın. Genellikle birlikte kullanılırlar: Uçta Front Door, bölge başına Application Gateway’ler ve L4 hizmetleri için ağ geçitlerinin arkasında dahili LB’ler.

Traffic Manager (DNS tabanlı) ve Azure CDN

Traffic Manager, DNS tabanlı global trafik dağıtımıdır. Trafiği proxy’lemez; bunun yerine, ilkeye ve sistem durumuna göre bir uç noktanın DNS adını/IP’sini döndürür ve istemcilerin doğrudan bağlanmasını sağlar. Sistem durumu, dağıtılmış yoklamalardan HTTP/HTTPS/TCP uç noktalarına doğru kontrol edilir; düşük TTL’ler yük devretme gecikmesini azaltır ancak DNS sorgu hacmini artırır.

Öncelik (Priority): Aktif/pasif yük devretme. Birincil olanı başa koyun; Traffic Manager, sağlıksız olmadığı sürece ona hizmet eder, ardından bir sonraki önceliğe devreder.
Ağırlıklı (Weighted): Kademeli geçişleri veya A/B testlerini desteklemek için ağırlıklara göre dağıtın.
Performans (Performance): Kullanıcının bölgesinden uç noktaya en düşük ağ gecikmesine sahip uç noktayı seçin.
Coğrafi (Geographic): Veri egemenliği veya içerik yerelleştirmesi için kullanıcının coğrafi konumuna göre yönlendirme yapın.
Çok Değerli (Multivalue): Basit istemci tarafı yük devretmeyi desteklemek için aynı hizmet için birden çok sağlıklı uç nokta döndürün. Hibrit ilkeler için profilleri iç içe kullanabilirsiniz (örneğin, en üstte coğrafi, ardından bir coğrafya içinde ağırlıklı). Traffic Manager’ı HTTP olmayan protokoller, uç proxy’lemeden fayda görmeyen hizmetler veya heterojen uç noktalar (Azure, şirket içi, üçüncü taraf) üzerinde DNS katmanı kontrolüne ihtiyaç duyduğunuzda kullanın.

Azure CDN, kaynak yükünü ve gecikmeyi azaltmak için statik ve önbelleğe alınabilir içeriği uç POP’lara boşaltır.

Profiller (Profiles): Bir sağlayıcıya/katmana (örneğin, Microsoft, Akamai veya Verizon aileleri) bağlı bir veya daha fazla uç nokta için kapsayıcılardır. Profiller, ortamları veya maliyet merkezlerini ayırmaya yardımcı olur.
Uç Noktalar (Endpoints): Kaynak ayrıntılarını (ana bilgisayar adı, kaynak ana bilgisayar üst bilgisi, protokol/bağlantı noktası) ve uç ana bilgisayar adını tanımlayın. Farklı uygulamalar veya içerik türleri için profil başına birden çok uç noktanız olabilir.
Önbellekleme kuralları: Varsayılan ve özel kurallar TTL’leri, yol tabanlı davranışı, sorgu dizesi (query-string) işlemeyi (ilet, yoksay veya her benzersiz sorguyu önbelleğe al) ve sıkıştırmayı kontrol eder. Kısa kaynak TTL’lerine sahip varlıkların önbelleğe alınmasını zorlamak veya dinamik API’ler için önbelleğe almayı atlamak için kuralları kullanın.
Özel etki alanları (Custom domains): Kolay ana bilgisayar adlarını CDN tarafından yönetilen TLS ile eşleyin. CNAME aracılığıyla etki alanı sahipliğini doğrulayın ve yönetilen sertifikalarla HTTPS’yi etkinleştirin. Gerektiğinde coğrafi filtreleme veya kurallar motoru (rules engine) ile birleştirin.

Tasarım tercihleri, bölgeler arası entegrasyon ve durum yoklaması davranışı

Dahili ve harici yük dengeleyiciler, hedef kitleye ve rotanın erişilebilirliğine göre seçilir. Eğer tüketiciler yalnızca özel ağlar içindeyse, genel ağa maruz kalmaktan kaçınmak ve NSG denetimini basitleştirmek için dahili LB’ler kullanın. İnternet kullanıcıları veya iş ortakları için genel kullanıma açık ön uçlar (frontend) kullanın. Ölçekli giden bağlantılar için LB SNAT yerine NAT Gateway’i tercih edin; giden kuralları, LB’nin ön ucunun SNAT sağlaması gereken durumlar için ayırın.

Cross-region Load Balancer, TCP/UDP hizmetleri için aktif-aktif, küresel Katman 4 esnekliği sağlamak amacıyla bölgesel Standart Public Load Balancer’lar ile entegre olur. Bölgesel LB’lerin genel kullanıma açık ön uçlarını, küresel LB’nin arka uç havuzuna (backend pool) yerleştirin. Küresel katmandaki durum yoklamaları (health probe) bölgesel kullanılabilirliği yansıtır; yönlendirme, en düşük gecikmeye sahip sağlıklı bölgeye yönlendirir ve tüm bir bölge (veya bölgesel LB’si) sağlıksız duruma geçerse otomatik olarak yük devreder. Ayrı VIP’ler altında hem protokol desteğine (ör. Cross-region LB aracılığıyla TCP hizmetleri ve Front Door aracılığıyla HTTP/S) ihtiyaç duyduğunuzda bunu Front Door ile birleştirin.

Durum yoklamaları, yük devretme için doğruluk kaynağıdır:

TCP yoklamaları: Herhangi bir TCP hizmeti için çalışır. Tamamlanmış bir 3 yönlü el sıkışma (3-way handshake) başarıyı gösterir. SQL, SMTP veya özel TCP protokolleri için uygundur.
HTTP/HTTPS yoklamaları: Bir yola istek göndererek ve 200–399 aralığında bir yanıt bekleyerek uygulama düzeyindeki sağlığı doğrular. Ana bilgisayar/yol özelleştirmesine olanak tanır ve kısmi uygulama hatalarını ayırt edebilirler. HTTPS yoklamaları, TLS anlaşmasını doğrular ancak el sıkışmanın ötesinde sertifika geçerliliğini doğrulamaz; sanal olarak barındırılan uygulamalar için doğru ana bilgisayar başlıklarını (host header) kullanın.
Sağlıksız eşikleri: Azure Load Balancer, arka arkaya N sayıda başarısız yoklamadan sonra (yapılandırılabilir; varsayılan aralıklar yük devretmeyi hızlandırmak için kısadır) bir arka ucu (backend) kapalı olarak işaretler. Application Gateway ve Front Door, birden çok gözlem noktasından yoklama yapar ve yoklama setleri genelinde yeterli sayıda ardışık hata biriktiğinde bir kaynağı (origin) kapalı olarak kabul eder. Kurtarma, ardışık başarılar gerektirir. Hassasiyet ve kararsızlık (flapping) arasında denge kurmak için aralığı ve eşiği ayarlayın; yoklamaların hafif ve bağımlılıklardan haberdar bir uç noktaya ulaştığından emin olun.

Pratik Problem Senaryosu

Adobe’nin, dünya çapındaki kullanıcılar için sıkı güvenlik, hızlı yük devretme ve düşük gecikme süresi ile web ön uçları, mikroservisler ve bir SQL Server Always On kullanılabilirlik grubundan oluşan çok bölgeli bir SaaS’ı küresel olarak kullanıma sunması gerekiyor. Ayrıca eski, TCP tabanlı bir telemetri alım hizmetini de kullanıma sunuyorlar.

Uç noktaya (edge) bir WAF ilkesi ve www.adobe.com ile api.adobe.com için rotalarla birlikte Azure Front Door Standard’ı yerleştirin. Kaynaklar (Origin), Doğu ABD ve Batı Avrupa’daki Application Gateway’lerdir ve gecikme tabanlı yönlendirme ve öncelikli yük devretme ile gruplandırılmıştır.

Neden: Front Door, internet HTTP/S trafiğini hızlandırmak ve korumak için küresel anycast, uç WAF ve isteğe bağlı önbelleğe alma sağlar; en yakın sağlıklı bölgeyi otomatik olarak seçer.

Her bölgede WAF ile Application Gateway v2 dağıtın. Her iki ana bilgisayar adı için SNI ile çoklu site dinleyicileri (listener), mikroservislere URL yol tabanlı yönlendirme ve her hizmette /healthz adresine özel durum yoklamaları yapılandırın. Hizmet FQDN’lerine yönelik arka uç ana bilgisayarını geçersiz kılma (backend host override) ile uçtan uca SSL’i etkinleştirin.

Neden: Application Gateway, bölgesel L7 yönlendirme, uygulamaya yakın WAF denetimi, yol tabanlı dağıtım (fanout) ve rota başına ilkeler sunar; özel arka uçlara güvenli bir şekilde bağlanır ve başlık yeniden yazma/yönlendirme işlemlerini yönetir.

Her bölgede SQL AG dinleyicisi için dahili bir Standard Load Balancer dağıtın. Statik özel bir ön uç, Windows Failover Cluster yoklama portuna bir TCP durum yoklaması ve dinleyici portuna Floating IP etkinleştirilmiş bir yük dengeleme kuralı yapılandırın.

Neden: SQL dinleyicisi, doğrudan sunucu dönüşü (direct server return) ile L4 gerektirir. Floating IP, hedef semantiğini korur ve bir TCP yoklaması, AG sahipliğini doğru bir şekilde yansıtır. Bu, 1433 portunda HTTP yoklamasının geçersiz olduğu bilinen gereksinimi yansıtır.

Web statik varlıklarını, uzun bir TTL ve yeniden doğrulama ile /static/* için Azure Front Door önbelleğe alma kurallarıyla destekleyin ve ayrıca downloads.adobe.com adresindeki büyük medya indirmeleri için yola özgü önbelleğe alma ve sorgu dizesi varyasyonu ile bir Azure CDN profili ve uç noktası oluşturun.

Neden: Front Door önbelleğe alma, uç yönlendirme ile uyumlu olarak temel web statik içeriği için gecikmeyi azaltırken, özel bir CDN uç noktası indirmeler için büyük nesne teslimatını ve önbellek ilkesi bağımsızlığını optimize eder.

Eski TCP telemetri alım hizmetini her bölgede bölgesel bir Standard Public Load Balancer aracılığıyla yayımlayın, ardından bunların önüne tek bir genel VIP olarak bir Cross-region Load Balancer koyun. Her bölgesel LB’ye küresel yoklamalar yapılandırın ve gecikme tabanlı yönlendirme kullanın.

Neden: Hizmet TCP’dir, HTTP değil; Cross-region Load Balancer, otomatik yük devretme ve düşük gecikmeli bölge seçimi ile küresel aktif-aktif L4 sunar.

Yalnızca Azure dışında barındırılan harici bir iş ortağı SFTP uç noktası için, iş ortağının birincil ve Azure’da barındırılan bir yedek uç noktasını listeleyerek Öncelik (Priority) ilkesiyle Azure Traffic Manager ekleyin.

Neden: Traffic Manager DNS tabanlıdır ve harici uç noktaları içerebilir; proxy kullanmanın istenmediği HTTP olmayan ve üçüncü taraf hedefler için basit aktif/pasif yük devretme sağlar.

Uygulama alt ağlarından giden bağlantı için NAT Gateway ekleyin ve LB giden SNAT bağımlılığını kaldırın. Azure Monitor’da yoklama sonuçlarını ve LB/App Gateway/Front Door metriklerini izleyin ve kararsızlığı (flapping) ortadan kaldırmak için yoklama aralıklarını/sağlıksız eşiklerini ayarlayın.

Neden: NAT Gateway, SNAT port tükenmesi olmadan giden bağlantıyı güvenilir bir şekilde ölçeklendirir; hassas durum yoklaması ayarı, katmanlar arasında daha hızlı ve kararlı bir yük devretme davranışı sağlar.

← Azure Sanal Ağ · Tüm alanlar · Azure Depolama →

Bu soruları çözün → · ExamRoll.io’da süreli pratik →