- 01Azure Landing Zone yalnız management group ağacı değildir; identity, governance, networking, monitoring, security ve platform automation kararlarını birlikte kapsar.
- 02Microsoft platform landing zone ile application landing zone katmanlarını ayırır; merkezi guardrail'ler platformda, workload kaynakları application landing zone içinde yönetilir.
- 03Küçük organizasyonların full enterprise-scale mimariyi ilk günden uygulaması şart değildir; minimum viable landing zone ile başlayıp ihtiyaç arttıkça genişlemek daha doğru olabilir.
- 04Management Group, subscription sayısı ve governance sınırları büyüdükçe değer kazanır; tek subscription ortamında aşırı hierarchy gereksiz karmaşıklık yaratabilir.
- 05Azure Policy, RBAC, logging, budget ve Infrastructure as Code landing zone baseline'ının temel parçalarıdır.
Kısaca
Azure Landing Zone, Azure ortamında kimlik, governance, subscription organizasyonu, ağ, güvenlik, logging, maliyet ve platform otomasyonu için tekrar kullanılabilir bir temel mimari kurma yaklaşımıdır. Microsoft Cloud Adoption Framework, bu yapıyı merkezi platform landing zone ile workload ekiplerinin kullandığı application landing zone katmanlarına ayırır.
Ancak küçük veya orta ölçekli bir Azure ortamında her enterprise bileşeni ilk günden kurmak zorunlu değildir. Doğru hedef, gereksiz yönetim katmanı eklemek değil; bugünkü ölçeğe uygun ama yarın büyüyebilecek bir minimum viable landing zone oluşturmaktır.
Dynamis Teknoloji'de landing zone tasarımını subscription sayısından önce şu sorularla başlatıyoruz:
- kim neyi yönetiyor?
- production ve non-production nasıl ayrılıyor?
- policy ve RBAC nereden uygulanıyor?
- network merkezi mi dağıtık mı?
- loglar ve güvenlik sinyalleri nerede toplanıyor?
- maliyet hangi workload'a ait?
- yeni subscription nasıl açılıyor ve standartlar nasıl otomatik uygulanıyor?
Azure Landing Zone nedir?
Microsoft'un güncel Cloud Adoption Framework tanımında Azure Landing Zone, çoklu subscription Azure ortamını güvenli, yönetilebilir ve ölçeklenebilir hale getirmek için kullanılan esnek referans mimaridir.
İki ana katman bulunur:
Platform landing zone
Ortak platform katmanıdır.
Tipik olarak:
- management group yapısı
- merkezi governance
- identity ve erişim modeli
- shared network
- logging/monitoring
- security baseline
- subscription vending
- ortak automation
gibi bileşenleri taşır.
Application landing zone
Workload veya uygulama ekibinin kendi kaynaklarını çalıştırdığı alandır.
Örneğin bir SaaS ürünü için:
- development
- test
- staging
- production
ortamları bir veya birden fazla subscription üzerinde application landing zone içinde konumlandırılabilir.
Platform ekibi guardrail'leri belirler; application ekibi bu sınırlar içinde kendi workload'unu yönetir.
Landing Zone yalnız management group ağacı değildir
En sık yapılan hata landing zone'u birkaç management group ve policy assignment'dan ibaret sanmaktır.
Gerçekte tasarım alanları birlikte ele alınmalıdır:
- resource organization
- identity and access
- network topology
- security
- governance
- management and monitoring
- platform automation / DevOps
- cost ownership
Microsoft'un Azure Landing Zone design areas yaklaşımı da tam olarak bu karar alanlarını ayrı ayrı değerlendirmenizi önerir.
Küçük şirket için tam enterprise Landing Zone gerekli mi?
Her zaman değil.
Microsoft, Azure Landing Zone yaklaşımının özellikle enterprise ve büyük organizasyonlar için ölçeklenebilir bir yapı sunduğunu; küçük organizasyon ve startup'ların ise aynı organizasyon seviyesine ihtiyaç duymayabileceğini belirtir.
Bu, küçük şirketin governance'a ihtiyacı olmadığı anlamına gelmez.
Küçük bir Azure ortamında bile şu başlıklar mutlaka düşünülmelidir:
- Entra ID ve RBAC
- production / non-production ayrımı
- naming ve tagging
- Azure Policy
- budget ve cost ownership
- diagnostic logging
- backup
- network segmentation
- secret management
- Infrastructure as Code
Fark, bu alanların ne kadar derin ve kaç katmanla uygulanacağıdır.
Minimum viable Landing Zone nasıl görünür?
Örneğin 1-3 subscription kullanan küçük bir yazılım şirketi için başlangıç yapısı şöyle olabilir:
Subscription yapısı
- Production
- Non-Production
- gerekirse Shared / Platform
Identity
- Entra ID group-based access
- direct user assignment yerine grup
- Owner rolünü minimumda tutma
- admin hesaplarında MFA
- kritik roller için PIM değerlendirmesi
Governance
- zorunlu tag'ler
- allowed location
- public IP kontrolü
- diagnostic settings
- resource naming standardı
Network
- prod ve non-prod ayrı VNet
- gerektiğinde merkezi hub
- private endpoint kullanım kriteri
- egress kontrolü
Monitoring
- merkezi Log Analytics workspace veya kontrollü workspace modeli
- activity log
- security alert
- backup job takibi
Cost
- subscription/workload budget
- tag tabanlı cost allocation
- anomaly review
Automation
- Terraform / Bicep
- pull request tabanlı değişiklik
- policy ve RBAC değişikliklerini kodla yönetme
Bu yapı başlangıç için yeterli olabilir. Subscription ve ekip sayısı arttıkça enterprise-scale tasarıma evrilebilir.
Management Group ne zaman gerçekten gerekir?
Azure Management Group, birden fazla subscription üzerinde ortak policy ve RBAC scope yönetmek için kullanılır.
Örnek kullanım:
- Platform
- Production
- Non-Production
- Sandbox
- Corp
- Online
gibi logical ayrımlar.
Ancak tek subscription'lı bir ortamda 7-8 katmanlı management group hierarchy kurmak operasyonel faydadan çok karmaşıklık yaratabilir.
Management group şu ihtiyaçlar arttığında daha değerlidir:
- subscription sayısı büyüyor
- farklı ekipler farklı subscription yönetiyor
- compliance politikaları ayrışıyor
- prod/non-prod guardrail'leri farklı
- shared platform resource'ları var
- delegated ownership gerekiyor
Management Group tasarımında yapılan hata: organizasyon şemasını kopyalamak
Management group ağacını şirket departman yapısına birebir çevirmek çoğu zaman kötü tasarımdır.
Çünkü organizasyon değişebilir.
Governance ise:
- security requirement
- workload type
- environment
- connectivity model
- policy boundary
üzerinden daha stabil tasarlanabilir.
Subscription neden önemli bir isolation boundary'dir?
Azure Landing Zone yaklaşımında subscription yalnız billing container değildir.
Aynı zamanda:
- quota boundary
- policy scope
- RBAC scope
- cost boundary
- workload isolation
sağlar.
Küçük ekiplerde her mikroservis için ayrı subscription gereksiz olabilir.
Ancak şu ayrımlar güçlü adaydır:
- production vs non-production
- farklı business criticality
- ayrı compliance requirement
- ayrı owner/team
- ayrı network/security boundary
Azure Policy Landing Zone'un merkezinde neden vardır?
Azure Policy, guardrail'leri manuel kontrol yerine otomatik enforcement veya audit olarak uygular.
Örnek policy kullanım alanları:
- allowed region
- mandatory tag
- public IP restriction
- diagnostic settings
- encryption requirement
- resource SKU restriction
- private link requirement
Ancak her policy doğrudan Deny olarak başlanmamalıdır.
Sağlıklı rollout:
- Audit
- Impact analizi
- Remediation
- Deny / Modify
şeklinde ilerleyebilir.
RBAC nasıl tasarlanmalı?
Azure RBAC ile kullanıcıların Azure kaynaklarında ne yapabileceği belirlenir.
Temel ilkeler:
- direct user assignment azaltın
- Entra ID group kullanın
- least privilege uygulayın
- Owner rolünü istisna haline getirin
- subscription-wide Contributor kullanımını sınırlayın
- privileged erişimde PIM değerlendirin
Microsoft'un Azure Landing Zone identity guidance'ı da platform ve workload ekiplerini policy guardrail'leri içinde ayrı sorumluluklarla konumlandırır.
Entra ID ile Landing Zone ilişkisi
Landing Zone'un kimlik katmanı Microsoft Entra ID'den bağımsız düşünülemez.
Planlayın:
- tenant ownership
- break-glass hesapları
- MFA
- Conditional Access
- admin group'ları
- workload managed identity
- service principal lifecycle
Özellikle automation için uzun ömürlü client secret yerine managed identity veya federated credential modelleri değerlendirilebilir.
Hub-spoke Landing Zone ile aynı şey değildir
Hub-spoke yalnız bir network topolojisidir.
Landing Zone ise:
- identity
- governance
- resource organization
- network
- monitoring
- security
- automation
kararlarını kapsar.
Hub-spoke şu durumlarda anlamlı olabilir:
- çok sayıda VNet
- shared firewall
- on-prem connectivity
- merkezi DNS
- ortak ingress/egress kontrolü
Ancak iki küçük VNet için zorunlu değildir.
Küçük ortamda hub-spoke ne zaman gereksizdir?
Örneğin:
- tek uygulama
- tek Region
- iki subscription
- on-prem bağlantısı yok
- birkaç private endpoint
varsa full hub-spoke mimarisi operasyon yükü yaratabilir.
Bu durumda basit VNet segmentation + peering yeterli olabilir.
Landing Zone tasarımının amacı Azure mimarisini karmaşıklaştırmak değil, kontrollü büyümeyi mümkün kılmaktır.
Shared services subscription ne zaman gerekir?
Merkezi hizmetler büyüdükçe ayrı Platform/Connectivity subscription mantıklı olabilir.
Örnekler:
- Azure Firewall
- VPN / ExpressRoute
- Private DNS
- Bastion
- Log Analytics
- central automation
Ancak birkaç shared resource için baştan ayrı 5 subscription oluşturmak zorunlu değildir.
Logging ve monitoring nasıl tasarlanmalı?
Landing Zone baseline'ında en az:
- Azure Activity Log
- resource diagnostic settings
- critical platform alerts
- Azure Monitor
- Log Analytics
planlanmalıdır.
Karar verilmesi gerekenler:
- tek workspace mi?
- workload bazlı workspace mi?
- retention ne kadar?
- kim loglara erişiyor?
- security ve operations aynı workspace'i mi kullanıyor?
Bu karar data volume ve erişim sınırlarına göre verilmelidir.
Azure Defender / Defender for Cloud
Landing Zone security baseline'ında Defender for Cloud değerlendirilmelidir.
Ancak bütün planları otomatik açmak yerine:
- workload risk
- compliance requirement
- mevcut security tool'ları
- maliyet
ile birlikte karar verilmelidir.
Naming standardı gerçekten önemli mi?
Evet.
Kaynak sayısı arttıkça tutarlı naming operasyonu ciddi kolaylaştırır.
Örnek pattern:
<company>-<workload>-<env>-<region>-<resource>
Ancak naming convention:
- Azure resource name length
- karakter kısıtları
- global uniqueness
gibi servis-specific limitleri hesaba katmalıdır.
Tagging stratejisi
Minimum tag set örneği:
- workload
- environment
- owner
- cost-center
- criticality
- data-classification
Her resource'ın 20 tag taşıması gerekmez.
Tag yalnız rapor için değil:
- cost allocation
- automation
- policy
- ownership
için kullanılmalıdır.
Azure Cost Management Landing Zone'un parçası mı?
Evet, governance açısından maliyet görünürlüğü landing zone design'ın parçasıdır.
İlk subscription'dan itibaren:
- budget
- cost alert
- owner
- workload tag
oluşturmak önemlidir.
Microsoft landing zone governance guidance'ı da maliyet takibinin ilk landing zone'dan itibaren başlamasını önerir.
Infrastructure as Code neden gerekli?
Landing Zone elle Portal üzerinden kurulabilir; fakat ölçeklendikçe drift oluşur.
IaC ile:
- management group
- policy
- RBAC
- network
- logging
- shared services
versiyonlanabilir.
Microsoft güncel Landing Zone guidance'ı platform automation ve DevOps alanında IaC ve otomasyonu temel tasarım konusu olarak ele alır.
Yaygın seçenekler:
- Azure Verified Modules
- Bicep
- Terraform
olabilir.
Landing Zone accelerator kullanmak zorunlu mu?
Hayır.
Microsoft accelerator'lar önerilen mimariye hızlı yaklaşmak için kullanılabilir.
Ancak custom build de mümkündür.
Küçük bir ortamda accelerator'ın tüm bileşenlerini doğrudan açmak yerine:
- hangi design area gerçekten gerekli?
- hangi component bugünkü ölçeğe uygun?
sorularıyla kapsam belirlemek daha doğru olabilir.
Production ve non-production ayrı subscription mı olmalı?
Çoğu production workload için güçlü bir pratiktir.
Ayrı subscription:
- RBAC
- budget
- policy
- quota
- blast radius
ayrımı sağlar.
Ancak küçük test ortamlarında her environment için ayrı subscription şart değildir.
Karar workload riskine göre verilmelidir.
Sandbox subscription neden faydalıdır?
Developer'ların production policy'lerini delmeden test yapabilmesi için sandbox kullanılabilir.
Sandbox'ta:
- düşük budget
- otomatik cleanup
- sınırlı Region
- production data yasağı
gibi kurallar uygulanabilir.
Subscription vending nedir?
Subscription vending, yeni workload için subscription açma sürecini standart ve otomatik hale getirmektir.
Örneğin yeni subscription oluşturulduğunda otomatik olarak:
- management group'a eklenir
- policy uygulanır
- RBAC group'ları atanır
- logging açılır
- budget oluşturulur
Bu yaklaşım subscription sayısı arttıkça büyük değer sağlar.
İki subscription'lı küçük bir ortamda tam vending pipeline şart olmayabilir; ancak onboarding checklist yine olmalıdır.
Azure Landing Zone ne zaman genişletilmeli?
Şu sinyaller oluştuğunda yapıyı büyütün:
- subscription sayısı artıyor
- ikinci ekip geliyor
- compliance gereksinimi geliyor
- ikinci Region açılıyor
- on-prem connectivity ekleniyor
- shared firewall gerekiyor
- platform team oluşuyor
Architecture bugünkü ihtiyacın çok önüne geçmemeli; fakat büyümeyi engelleyecek kadar da düz olmamalıdır.
Mevcut Azure ortamı sonradan Landing Zone'a geçirilebilir mi?
Evet.
Microsoft mevcut Azure footprint'inin Landing Zone reference architecture'a kademeli taşınması için transition guidance sağlar.
Bu nedenle 'ilk günden kusursuz landing zone kurmadık, artık çok geç' düşüncesi doğru değildir.
Geçiş sırasında:
- subscription hierarchy
- policy
- RBAC
- networking
- shared services
kademeli olarak standardize edilebilir.
Küçük şirket için örnek minimum mimari
Örnek:
Tenant
- tek Microsoft Entra tenant
Subscription
prodnonprod- gerektiğinde
platform
Access
- Platform Admin group
- App Team group
- ReadOnly / Auditor group
Policy
- allowed Region
- mandatory basic tags
- diagnostic settings
- public endpoint audit
Network
- prod VNet
- nonprod VNet
- private DNS ihtiyaca göre
- hub yalnız gerektiğinde
Operations
- Azure Monitor
- Log Analytics
- backup
- budget
Automation
- Terraform/Bicep repo
- PR review
Bu yapı bir enterprise reference architecture'ın küçültülmüş kopyası değildir; aynı design principles'ın daha sade uygulanmasıdır.
Orta ölçekli ortam için örnek yapı
Subscription ve workload sayısı büyüdüğünde:
Management Groups
- Platform
- Landing Zones
- Corp/Internal
- Online
- Sandbox
Platform subscriptions
- Connectivity
- Management
- Identity gerekirse
Application subscriptions
- Product A Prod
- Product A NonProd
- Product B Prod
- Product B NonProd
Bu noktada merkezi policy, subscription vending ve platform automation daha anlamlı hale gelir.
Landing Zone başarı kriterleri
Kurulum tamamlandı demek management group görünmesi değildir.
Başarı kriterleri:
- yeni subscription aynı standardı otomatik alıyor
- production resource owner belli
- policy violation görünür
- kritik loglar merkezi toplanıyor
- maliyet workload'a atanabiliyor
- privileged access kontrol altında
- network akışları dokümante
- backup sorumluluğu belli
- değişiklikler kod veya kontrollü süreçle yapılıyor
olmalıdır.
Dynamis'te Azure Landing Zone yaklaşımı
Dynamis'in Azure yönetimi hizmetinde ilk adım hazır bir enterprise template'i doğrudan deploy etmek değildir.
Önce:
- mevcut subscription sayısı
- tenant yapısı
- ekip ownership
- prod/non-prod sınırı
- compliance ihtiyacı
- network bağlantıları
- Azure Policy durumu
- RBAC
- logging
- cost ownership
- büyüme planı
çıkarılır.
Ardından ortam için minimum gerekli platform baseline belirlenir.
Küçük şirket için basit bir Landing Zone yeterliyse gereksiz management katmanı eklemeyiz. Subscription ve ekip sayısı arttıkça yapıyı Microsoft'un landing zone design areas yaklaşımına uygun biçimde genişletiriz.
Sık yapılan hatalar
Landing Zone'u management group ağacı sanmak: Identity, policy, network, monitoring ve automation birlikte tasarlanmalıdır.
Küçük ortamda enterprise yapıyı birebir kopyalamak: Operasyon yükü yaratabilir.
Management group'ları organizasyon şemasına göre kurmak: Governance boundary'lere göre tasarlayın.
Azure Policy'yi doğrudan Deny ile başlatmak: Önce audit ve impact analizi yapın.
Direct user RBAC kullanmak: Group-based access tercih edin.
Cost ownership'i sonradan düşünmek: İlk subscription'dan başlayın.
IaC olmadan sürekli Portal değişikliği yapmak: Drift ve audit problemi yaratır.
Sırada ne var
Kaynaklar
- Microsoft Cloud Adoption Framework: What is an Azure landing zone?
- Azure landing zone design areas
- Azure landing zone design principles
- Resource organization design area
- Landing zone identity and access management
- Azure governance design area
- Platform automation and DevOps design area
- Prepare your secure cloud estate
Kaynaklar
- 1.What is an Azure landing zone?Microsoft Learn · 2026-09-25
- 2.Azure landing zone design areasMicrosoft Learn · 2026-09-25
- 3.Azure landing zone design principlesMicrosoft Learn · 2026-09-25
- 4.Resource organizationMicrosoft Learn · 2026-09-25
- 5.Landing zone identity and access managementMicrosoft Learn · 2026-09-25
- 6.Azure governance design areaMicrosoft Learn · 2026-09-25
- 7.Platform automation and DevOpsMicrosoft Learn · 2026-09-25
- 8.Prepare your secure cloud estateMicrosoft Learn · 2026-09-25
Sık sorulan sorular
Azure Landing Zone nedir?
Azure Landing Zone, Azure ortamında governance, güvenlik, kimlik, ağ, yönetim ve subscription organizasyonu için tekrar kullanılabilir bir temel mimari oluşturma yaklaşımıdır. Microsoft Cloud Adoption Framework, platform landing zone ile workload/application landing zone kavramlarını ayırır. Amaç her workload'u aynı şablona zorlamak değil, ortak guardrail'leri merkezi olarak tanımlayıp workload ekiplerinin güvenli sınırlar içinde çalışmasını sağlamaktır.
Küçük bir şirket için Azure Landing Zone gerekli mi?
Her küçük ortamın enterprise-scale landing zone kurması gerekmez. Microsoft da küçük organizasyonların başlangıçta tam landing zone yaklaşımının tüm karmaşıklığından fayda görmeyebileceğini belirtir. Ancak identity, naming/tagging, subscription sınırları, Azure Policy, logging, budget ve network gibi tasarım alanları yine planlanmalıdır. Küçük ortamda sade bir minimum viable landing zone çoğu zaman daha doğru başlangıçtır.
Azure Landing Zone ile hub-spoke network aynı şey mi?
Hayır. Hub-spoke bir network topolojisidir; landing zone ise identity, subscription organization, governance, security, management, networking ve platform automation gibi daha geniş tasarım alanlarını kapsar. Hub-spoke bazı landing zone tasarımlarında kullanılabilir ancak her landing zone'un zorunlu tek network modeli değildir.
Azure Management Group ne zaman kullanılmalı?
Management Group, birden fazla subscription üzerinde ortak policy ve erişim yönetimini ölçeklemek için kullanılır. Tek veya çok az subscription bulunan küçük ortamlarda aşırı karmaşık hierarchy gereksiz olabilir. Subscription sayısı, iş birimleri, prod/non-prod ayrımı, compliance sınırları ve delegated ownership arttıkça management group yapısı daha anlamlı hale gelir.
Azure Landing Zone kurulumunda ilk hangi kontroller yapılmalı?
İlk olarak subscription ownership, Entra ID/RBAC, naming ve tagging, Azure Policy baseline, network topology, diagnostic logging/monitoring, backup/DR, budget/cost ownership ve Infrastructure as Code yaklaşımı netleştirilmelidir. Ardından workload'lar için prod/non-prod sınırları ve application landing zone modeli oluşturulabilir.