Azure Landing Zone Diyagramı: Yönetim Grupları, Abonelikler ve Hub Ağı

Çoğu Azure ortamı aynı şekilde başlar. Biri bir pilot için abonelik açar, ardından üretim için bir tane daha, sonra her ekip kendi aboneliğini alır. İki yıl sonra tenant kök grubunun altında 40 abonelik birikmiştir; üçü kendi VPN ağ geçidini çalıştırır, bir veritabanı VM'inin public IP'si vardır ve hangi politikanın nerede geçerli olduğunu kimse bilmez.

Azure landing zone, Microsoft'un bunu önlemek için sunduğu plandır. Bu yazı her parçayı bir diyagramla ele alıyor: yönetim grupları, platform ve iş yükü landing zone'ları, politika koruma bariyerleri, hub-and-spoke ile Virtual WAN karşılaştırması, kimlik ve dağıtım.

Azure landing zone nedir

Cloud Adoption Framework (CAF), Azure landing zone'u “çok abonelikli bir Azure ortamını yönetmek, güvenceye almak ve ölçeklendirmek için kanıtlanmış ve esnek bir mimari” olarak tanımlar (Microsoft Learn). İki parçadan oluşur:

• Platform landing zone: yönetim grubu hiyerarşisi ile hub ağı, loglama ve güvenlik araçları gibi paylaşılan kaynaklar. Microsoft, Microsoft Entra tenant'ı başına bir tane önerir; bunu bir platform ekibi işletir.
• İş yükü landing zone'ları: her iş yükü için bir tane; sahibi o iş yükünün ekibidir ve tüm ortamları (geliştirme, test, üretim) bir ya da daha fazla abonelik olarak barındırır. Eski dokümanlar bunlara uygulama landing zone'ları (application landing zones) der.

Temel yapı taşı aboneliktir: CAF onu bir yönetim, faturalandırma ve ölçek birimi olarak tanımlar. AWS terimleriyle abonelik kabaca bir hesaba, yönetim grubu ise bir organizasyon birimine karşılık gelir; o tarafı AWS landing zone diyagramı gösteriyor.

Yönetim grubu hiyerarşisi

Bir yönetim grubundaki politika ya da rol ataması altındaki her şeye uygulanır ve abonelik sahipleri bunu değiştiremez. Yönetim grupları dokümantasyonuna göre Azure, tenant başına 10.000 yönetim grubuna, kökün altında altı seviyeye ve her grup için tek bir üst gruba izin verir.

Varsayılan ALZ politika atamalarından alınan notlarla referans hiyerarşi:

CAF yönetim grubu rehberindeki üç kural, yeniden tasarım ihtiyacının çoğunu ortadan kaldırır:

1. Hiyerarşiyi düz tutun. Üç ya da dört seviye yeterlidir; bölgeler ya da geliştirme, test ve üretim için yönetim grubu eklemeyin.
2. Tenant kökünde değil, ara kökte atayın. Yeni abonelikler varsayılan olarak tenant kökünün altına düşer ve siz izin şartı koyana kadar her kullanıcı yönetim grubu oluşturabilir. İkisini de değiştirin ve Sandbox'ı varsayılan grup yapın.
3. İş yükü ekiplerine rolleri abonelik kapsamında verin. Platform ekipleri yönetim gruplarında rol sahibi olabilir; bu erişim just-in-time erişimle denetlenir.

İsimler değişiyor: Security 2025'te Platform'a katıldı ve en yeni CAF genel bakışı Landing zones için “Workload landing zones”, Corp için “Internal” adını kullanıyor.

Platform ve iş yükü landing zone'ları

Abonelik dağıtımında bir talep, çoğu zaman bir pull request, aboneliği Corp ya da Online altında oluşturur, rolleri ve bir bütçeyi atar, Corp için de hub'a peering ile bağlı bir spoke ekler. Microsoft, Bicep ve Terraform için abonelik dağıtım modülleri yayımlıyor.

Politika tabanlı koruma bariyerleri

Azure Policy hiyerarşiyi zorunlu kurallara dönüştürür: bir kuralı yönetim grubunda bir kez atayın, altındaki mevcut ve gelecekteki her abonelik onu devralır.

Bölge kuralları dikkat ister: yerleşik Allowed locations politikası kaynak gruplarını ve global konumunu atlar; bu yüzden onu Allowed locations for resource groups ile birlikte kullanın ve neyi engelleyeceğini görmek için DoNotEnforce modunda başlayın:

az policy assignment create \
  --name allowed-locations \
  --scope /providers/Microsoft.Management/managementGroups/contoso \
  --policy e56962a6-4747-49cd-b67b-bf8b01975c4c \
  --params '{"listOfAllowedLocations": {"value": ["westeurope", "northeurope"]}}' \
  --enforcement-mode DoNotEnforce

Zamanlama önemlidir: yeni bir atama yaklaşık beş dakikada uygulanır, bir yönetim grubuna taşınan abonelik yaklaşık 30 dakikada değerlendirilir ve tam tarama her 24 saatte bir çalışır. DeployIfNotExists ve Modify politikaları yeni ve güncellenen kaynaklara etki eder; mevcut kaynaklar için bir düzeltme görevi (remediation task) gerekir.

Ağ: hub-and-spoke ya da Virtual WAN

Paylaşılan ağın sahibi Connectivity aboneliğidir: Azure Firewall, VPN ve ExpressRoute ağ geçitleri, Bastion, özel DNS bölgeleri ve DNS Private Resolver. CAF'nin ağ topolojisi rehberi iki tasarım sunar:

Peering geçişli değildir. Bu yüzden hub sanal ağında her spoke, 0.0.0.0/0 trafiğini güvenlik duvarının özel IP'sine gönderen bir rota tablosu alır; hub tarafındaki peering gateway transit'e izin verir, spoke tarafındaki peering ise uzak ağ geçidini kullanır. Yönlendirmeyi hub-and-spoke ağ topolojisi yazısı ele alıyor. Azure Firewall Basic 250 Mbps'e, Standard 30 Gbps'e, Premium ise 100 Gbps'e kadar trafiği işler. Virtual WAN için Standard türünü seçin; Basic yalnızca siteden siteye VPN'i destekler.

DNS, ekiplerin en sık hata yaptığı yerdir. privatelink.blob.core.windows.net gibi özel DNS bölgeleri Connectivity aboneliğinde durur ve hub'a bağlanır; hub'daki DNS Private Resolver sorguları 168.63.129.16 adresindeki Azure DNS'e iletir. Şirket içi DNS sunucuları da blob.core.windows.net gibi bölgeleri bu resolver'a yönlendirir. Corp'taki bir DeployIfNotExists politikası her özel uç noktanın kaydını merkezi bölgeye yazar; böylece iş yükü ekiplerinin bu bölge üzerinde hiçbir yetkiye ihtiyacı olmaz.

Kimlik

Kimlik sınırı Microsoft Entra tenant'ıdır. CAF'nin pratik kuralları:

• İş yükü ekiplerine rolleri abonelik dağıtımı sırasında kendi aboneliklerinde verin, asla yönetim gruplarında vermeyin.
• Platform mühendislerinin Owner gibi rolleri Privileged Identity Management (PIM) üzerinden, onay ve süre sınırıyla etkinleştirmesini sağlayın.
• Azure'u yöneten herkese Koşullu Erişim uygulayın ve izlenen acil durum erişim hesapları bulundurun.
• İş yükleri hâlâ ihtiyaç duyuyorsa etki alanı denetleyicileri ya da Microsoft Entra Domain Services için Identity aboneliğini kullanın.

Dağıtım

Bu yazının yazıldığı tarihte (Kasım 2026) Microsoft, Azure Landing Zones IaC Accelerator'ı öneriyor: Azure Verified Modules (AVM) üzerine kurulu Bicep ya da Terraform. Hızlandırıcının PowerShell modülü bir GitHub ya da Azure DevOps deposunu, onay adımlı pipeline'ları ve federe kimlik bilgilerine sahip yönetilen kimlikleri hazırlar. Terraform; hiyerarşi ve politika (avm-ptn-alz), yönetim kaynakları ve her ağ tasarımı için ayrı modüller kullanır. Bicep ise şablonlardan çıkardığınız kaynakları silebilen deployment stack'leri kullanır.

Eski seçenekler emekliye ayrılıyor: caf-enterprise-scale Terraform modülü kullanımdan kaldırıldı; klasik ALZ-Bicep 16 Şubat 2026'da hızlandırıcıdan çıkarıldı ve deposu 16 Şubat 2027'de arşivlenecek. Portal tabanlı bir hızlandırıcı hâlâ mevcut, ancak kod olmadan güncellemesi zor.

Bütçeyi baştan planlayın. Hızlandırıcının senaryo sayfası, Azure Firewall'lu tek bölgeli bir hub and spoke için sabit altyapı maliyetini ayda yaklaşık 5.640 USD, küçük işletme varyantı için ise 690 USD olarak tahmin ediyor; bu varyant diğer şeylerin yanı sıra DDoS Network Protection planını kapatır (Nisan 2026 tarihli westus perakende fiyatları; trafik ve loglar hariç). Ayrıca dört platform aboneliğine, küçük işletme kurulumunda ise ikiye ihtiyacınız var.

Azure landing zone diyagramı

Nasıl okunur:

• Soldaki ağaç hiyerarşidir; oklar üst gruptan alt gruba, yani devralma yönünde ilerler.
• Politika düğümü tenant kök grubuna değil, Contoso ara köküne bağlıdır; böylece landing zone'un tamamına ulaşır, başka hiçbir yere ulaşmaz.
• Renkler sahipliği gösterir: platform için mavi, iş yükleri için yeşil, Sandbox için kehribar, kök ve emekliye ayrılan abonelikler için gri.
• Kesikli kenarlar yerleşimi gösterir: hub Connectivity aboneliğinde durur, iki spoke da abonelik dağıtımıyla Corp altına yerleştirilmiştir.
• Düz kenarlar trafik taşır: hub'a giden peering'ler ve ağ geçidinden şirket içine giden bağlantı; her spoke 0.0.0.0/0'ı 10.0.0.4 adresindeki güvenlik duvarına yönlendirir.
• Markdown bloğu temel sınırları listeler.

Azure landing zone diyagramlarını net çizmek

• Yönetişimi ve ağı iki ayrı görünüm olarak çizin; ikisini yalnızca bir aboneliğin bulunduğu yerde bağlayın.
• Her politikayı atandığı yere bağlayın; böylece okuyucular hangi iş yüklerini kısıtladığını görür.
• Her grup için bir ya da iki örnek abonelik gösterin, envanter çıkarmayın.
• Hub'a ve her spoke'a adres aralıklarını yazın; çakışmalar, inceleyenlerin ilk baktığı şeydir.
• Klasik hatalardan kaçının: geçişliymiş gibi çizilen peering, tenant kökünün altındaki iş yükleri ve yönetim grubu olarak çizilen bölgeler ya da ortamlar.

Tipli bulut düğümleri için bulut mimari diyagramlarına, Terraform ile yönetilen ortamlar için de Terraform mimari diyagramı yazısına bakın.

Archboard'da oluşturun

1. Google ya da GitHub ile giriş yapın ve bir diyagram oluşturun.
2. Bulut paketinden sekiz Bulut kaynağı düğümü ekleyin: Tenant root group, Contoso, Platform, Landing zones, Corp, Online, Sandbox ve Decommissioned. Her birinin rolünü Kaynak tipi satırına yazın ve düğümleri girintili bir ağaç olarak dizin.
3. Üst grupları alt gruplara dik açılı kenarlarla bağlayın ve dalları renklendirin: Platform için mavi, Landing zones için yeşil, Sandbox için kehribar.
4. Güvenlik paketinden Azure Policy guardrails adlı bir Politika düğümü ekleyin ve onu Contoso'ya bağlayın.
5. Hub için Ağ paketinden bir VPC düğümü ekleyin; içine ağ geçidi için bir Yönlendirici ve bir Güvenlik duvarı koyun. Spoke'lar için iki VPC düğümü daha ekleyin ve her birine rotasını gösteren birer Temel Metin satırı ekleyin.
6. Platform'dan hub'a ve Corp'tan spoke'lara kesikli kenarlar, hub'a peering kenarları ve ağ geçidinden şirket içini gösteren bir Metin etiketine bir kenar çizin.
7. Sınırları listeleyen, Temel paketinden bir Markdown bloğu ekleyin.

Landing zone'unuz Terraform'da tanımlıysa Terraform’dan diyagrama aracı dosyaları ilk taslağa dönüştürür.

Örnek 15 diyagram düğümü kullanıyor ve Free planın sınırları içinde kalıyor.

SSS

Azure landing zone nedir? İş yükleri gelmeden önce Cloud Adoption Framework önerilerine göre kurulan, çok abonelikli bir Azure ortamı: yönetim grupları, politika koruma bariyerleri, kimlik, loglama ve paylaşılan bir ağ.

Bir Azure landing zone hangi yönetim gruplarını kullanır? Tenant root group altında bir ara kök; onun altında da Platform (Management, Connectivity, Identity, Security), Landing zones (Corp, Online, Local), Sandbox ve Decommissioned.

Corp ve Online landing zone'ları arasındaki fark nedir? Corp, kurumsal ağa hub üzerinden erişen iş yüklerini barındırır; bu yüzden oradaki varsayılan politikalar public PaaS uç noktalarını ve ağ arabirimlerindeki public IP'leri reddeder. Online ise doğrudan internet erişimine ihtiyaç duyan ya da hiç sanal ağa ihtiyaç duymayan iş yüklerini barındırır.

Hub-and-spoke mı kullanmalıyım, Virtual WAN mı? Hub sanal ağı birkaç bölgeye, 30'dan az siteden siteye tünele ve yönlendirme üzerinde tam denetime uygundur; Virtual WAN ise çok sayıda bölge ve şubeye, SD-WAN'a ya da VPN'den ExpressRoute'a transite uygundur.

caf-enterprise-scale Terraform modülü hâlâ destekleniyor mu? Hayır. Kullanımdan kaldırıldı ve güncelleme almıyor. Platform landing zone'u için Azure Verified Modules'ü, genellikle IaC hızlandırıcısı üzerinden kullanın; Microsoft bir geçiş yolu belgeliyor.

Ücretsiz başlayın — tek kullanıcı, kredi kartı gerekmez.