Azure Local anlatırken zaman zaman karşıma çıkan bir soru var: “Azure Local zaten on-premises çalışıyor, internet bağlantısını kesersek ne olur?”
Bu sorunun cevabı aslında Azure Local’ın connected ve disconnected mimarileri arasındaki temel farkı ortaya koyuyor.
Standart Azure Local mimarisinde VM’leriniz, veriniz, Storage Spaces Direct, Hyper-V ve fiziksel altyapınız kendi veri merkezinizde çalışıyor. Ancak control plane Azure’da. Deployment, lifecycle management, governance ve yönetim işlemlerinin önemli bir bölümü Azure servisleri üzerinden gerçekleştiriliyor. Microsoft connected Azure Local’ın geçici bağlantı problemlerinde workload’ları çalıştırmaya devam ettiğini, ancak sistemin Azure ile en az 30 günde bir başarılı şekilde senkronize olması gerektiğini belirtiyor.
Dolayısıyla Azure Local’ın internet bağlantısını kesmek ile Azure Local Disconnected Operations kullanmak aynı şey değil.
Disconnected Operations tarafında asıl değişen workload’un nerede çalıştığı değil, Azure control plane’in nerede çalıştığı.
Microsoft bu modelde Azure control plane’in gerekli bileşenlerini müşterinin kendi ortamına getiriyor. Azure portal, Azure Resource Manager, subscription, resource group, RBAC ve managed identity gibi Azure’dan alıştığımız kavramların bir bölümü public Azure bağlantısı olmadan lokal olarak çalışabiliyor. Sistem sürekli Azure veya internet bağlantısına ihtiyaç duymuyor; update, servicing ve onboarding işlemleri de offline veya staged workflow’larla gerçekleştiriliyor.
Bence Disconnected Operations’ı anlamanın en doğru yolu da buradan başlamak.
Bu özellik “Azure Local internet olmadan da çalışıyor” özelliği değil.
Daha doğru tanım, Azure’ın belirli control plane yeteneklerinin müşterinin kendi veri merkezinde çalıştırıldığı ayrı bir private cloud operasyon modeli.
Connected Azure Local ile arasındaki gerçek fark
Standart connected Azure Local ortamında basitleştirirsek yapı şöyle:
Azure
|
| Control plane / Management
|
Azure Local
|
+-- VM
+-- Storage
+-- Network
+-- DataWorkload ve veri lokal ama yönetim katmanının önemli bölümü Azure’da.
Disconnected Operations tarafında ise model değişiyor:
Müşteri ortamı
|
+-- Local Azure Control Plane
| |
| +-- Azure Portal
| +-- Azure Resource Manager
| +-- RBAC
| +-- Subscription / Resource Groups
| +-- Managed Identity
|
+-- Azure Local
|
+-- VM
+-- Containers
+-- Storage
+-- NetworkBu ortamın günlük çalışması için Azure public cloud’a sürekli bağlantı gerekmiyor. Identity, monitoring, access control ve lifecycle işlemlerinin desteklenen bölümleri lokal ortamda yürütülüyor.
Bunun operasyonel karşılığı oldukça büyük.
Normal Azure Local’da portal üzerinden bir VM oluşturduğunuzda ARM request Azure’daki control plane tarafından işleniyor ve Azure Arc üzerinden lokal altyapıya ulaşıyor.
Disconnected modelde ise request’in işlendiği control plane de sizin ortamınızda.
Bu nedenle Azure portal benzeri yönetim deneyimini, ARM modelini ve Azure CLI yaklaşımını internet erişimi olmayan bir veri merkezinde kullanabiliyorsunuz.
Microsoft Architecture Center da iki modeli tam olarak bu şekilde ayırıyor: connected Azure Local’da control plane Azure’da bulunurken, disconnected operations modelinde uzun süreli veya kalıcı bağlantısız çalışma için local control plane kullanılıyor.
Neden böyle bir şeye ihtiyaç var?
Çoğu kurumsal müşteri için açıkçası yok.
Bunu özellikle söylemek gerekiyor.
Bir banka, üretim şirketi veya standart kurumsal veri merkezi internete kontrollü outbound erişim sağlayabiliyorsa connected Azure Local genellikle çok daha sade bir operasyon modeli.
Disconnected Operations’ın hedeflediği problem farklı.
Savunma sanayi ortamını düşünelim.
Sınıflandırılmış workload’ların bulunduğu bir network fiziksel olarak internete çıkamıyor olabilir.
Bir askeri tesis veya saha operasyonu olabilir.
Enerji üretim tesisi veya kritik altyapı olabilir.
Regülasyon nedeniyle sadece verinin değil, management plane’in de ülke veya kurum sınırları içerisinde kalması gerekebilir.
Ya da coğrafi olarak public cloud bağlantısının güvenilir olmadığı bir lokasyonda çalışıyor olabilirsiniz.
Microsoft da Disconnected Operations’ı özellikle sovereign, classified, regulated ve edge ortamları için konumlandırıyor. Güncel uygunluk kriterlerinde sadece teknik ihtiyaç yeterli görülmüyor; public Azure bağlantısı olmadan çalışmayı gerektiren belgelenmiş bir iş veya regülasyon ihtiyacı, uygun Microsoft anlaşması, destek modeli, operasyonel yetkinlik, önceden planlanmış kapasite ve desteklenen donanım da gerekiyor.
Dolayısıyla bunu “daha güvenli olduğu için disconnected kuralım” şeklinde değerlendirmek bana göre doğru değil.
Disconnected olmak kendi başına güvenlik mimarisi değildir.
Tam tersine Azure’ın yönettiği bazı operasyonların sorumluluğunu kendi veri merkezinize aldığınız için sizin yönetmeniz gereken altyapı büyüyor.
Control plane artık sizin altyapınızın bir parçası
Disconnected Operations’ın maliyet ve kapasite planlamasında en önemli farklarından biri dedicated management cluster gerektirmesi.
Microsoft güncel eligibility kriterlerinde gerekli Azure Local infrastructure component’lerini barındırmak için ayrı bir management cluster istiyor.
Bu kritik bir detay.
Standart connected Azure Local projesinde dört node’lu workload cluster tasarlayıp sizing çalışmasını buna göre yapabilirsiniz.
Disconnected ortamda ise sadece workload cluster’ını hesaplamak yeterli değil.
Local control plane de CPU, memory, storage ve network tüketiyor.
Üstelik bu control plane artık sizin availability tasarımınızın da bir parçası.
Public Azure’daki portal veya ARM servisinin yüksek erişilebilirliğini Microsoft yönetirken disconnected ortamda local control plane’in çalıştığı altyapıyı siz işletiyorsunuz.
Bunun sonucu olarak backup, restore, certificate lifecycle, update, monitoring ve disaster recovery gibi başlıklar sadece workload cluster için değil management plane için de düşünülmek zorunda.
Microsoft’un 2603 ve 2604 güncellemelerinde Disconnected Operations için BCDR restore mekanizmaları, client certificate rotation ve management operasyonlarına yönelik geliştirmeler eklemesi de bu ihtiyacın doğal sonucu. 2604 ile workload cluster tarafında 64 node desteği de eklenmiş durumda.
Yani local control plane’i “kurulum sırasında kullanılan birkaç management VM” gibi düşünmemek gerekiyor.
Bu, platformun kendisinin bir parçası.
Bütün Azure servisleri lokal ortama gelmiyor
Disconnected Operations konusunda bence en önemli yanlış beklenti burada oluşabilir.
Local control plane var diye Azure’daki bütün servislerin veri merkezinize geldiğini düşünmeyin.
Microsoft açık şekilde subset of cloud capabilities ifadesini kullanıyor.
Desteklenen temel yetenekler arasında Azure portal deneyimi, Azure Resource Manager, subscriptions, resource groups, ARM templates, Azure CLI, RBAC, system-assigned managed identity, Arc-enabled Servers, Azure Local VM yönetimi ve Azure Local device management bulunuyor. Kubernetes tarafında da destek var ancak bazı yetenekler halen Preview durumunda.
Bu ayrım önemli.
Örneğin AKS enabled by Azure Arc, Disconnected Operations üzerinde çalışabiliyor fakat Microsoft’un güncel dokümantasyonunda bu özellik hala Preview olarak belirtiliyor. Üstelik connected AKS ile bire bir aynı özellik setine sahip değil.
Güncel sınırlamalar arasında Windows node pool desteğinin bulunmaması, Microsoft Entra ID entegrasyonunun desteklenmemesi, GPU desteğinin bulunmaması ve bazı network kaynaklarının yalnızca CLI üzerinden oluşturulabilmesi gibi farklar var.
Dolayısıyla bir disconnected projesine başlamadan önce yapılması gereken ilk işlerden biri workload inventory çıkarmak.
“Biz Azure kullanıyoruz” yeterli bilgi değil.
Hangi Azure servislerini kullanıyorsunuz?
VM mi?
Kubernetes mi?
Key Vault mu?
Container Registry mi?
Policy mi?
AI servisleri mi?
Bu servislerin disconnected implementation’ı var mı?
Varsa GA mı Preview mı?
Connected sürümle aynı feature set’ine sahip mi?
Bunları tek tek kontrol etmek gerekiyor.
Disconnected Azure Local’ı public Azure’ın lokal kopyası olarak düşünürseniz projenin ilerleyen aşamasında mutlaka sürpriz yaşarsınız.
Identity konusu da değişiyor
Public Azure tarafında yönetim modelinin merkezinde Microsoft Entra ID bulunuyor.
Disconnected ortamda ise public cloud identity’ye sürekli bağımlı olamazsınız. Çünkü zaten tasarımın amacı public Azure bağlantısı olmadan çalışabilmek.
Bu nedenle identity ve access control lokal operasyon modelinin bir parçası haline geliyor. Microsoft Disconnected Operations dokümantasyonu identity, monitoring ve access control işlemlerinin desteklenen on-premises entegrasyonlar üzerinden lokal olarak gerçekleştirildiğini belirtiyor. Azure Resource Manager tarafında ise RBAC ve managed identity modeli korunuyor.
Bence bu mimarinin güzel taraflarından biri burada.
Disconnected olduk diye klasik “her şeyi lokal administrator hesabıyla yönetelim” modeline geri dönmüyoruz.
Resource group var.
Subscription var.
RBAC var.
Managed identity var.
ARM var.
Yani Azure’ın resource governance yaklaşımının önemli bir bölümü lokal control plane içerisinde devam ediyor.
Bu özellikle büyük private cloud ortamlarında önemli.
Çünkü 1000 VM bulunan disconnected bir altyapıyı klasik Hyper-V Manager mantığıyla yönetmek ile ARM resource model üzerinden yönetmek aynı şey değil.
Azure Local’ın disconnected taraftaki asıl değerlerinden biri bana göre tam olarak bu operasyon modelini koruması.
PKI artık çok daha kritik
Control plane lokal ortama geldiğinde sertifika altyapısı da doğal olarak tasarımın önemli bir parçası oluyor.
Disconnected Operations için Microsoft ayrı PKI gereksinimleri tanımlıyor. Local endpoint’lerin güvenli şekilde yayınlanması, identity entegrasyonu ve servisler arasındaki TLS iletişimi için certificate lifecycle’ın doğru tasarlanması gerekiyor. Microsoft Ağustos 2026’da PKI gereksinimleri ve certificate renewal süreçleri için güncel dokümantasyonu ayrıca yayımladı.
Bunun sahadaki karşılığı şu:
Connected ortamda Azure tarafındaki pek çok certificate lifecycle işlemini düşünmezsiniz.
Disconnected ortamda ise kendi PKI’nız, root CA trust, certificate issuance ve renewal süreçleriniz platformun çalışmasının doğrudan parçası haline geliyor.
Bu nedenle PKI ekibini proje bittiğinde değil, tasarım aşamasında masaya oturtmak gerekiyor.
Bir sertifikanın süresinin dolması klasik bir web sitesinde kullanıcıya certificate warning gösterebilir.
Local control plane içerisinde süresi dolan yanlış bir sertifika ise management fonksiyonlarını etkileyebilir.
Microsoft’un 2603 sonrasında client certificate rotation ve 2606 ile certificate renewal dokümantasyonunu geliştirmiş olması da lifecycle’ın ne kadar önemli olduğunu gösteriyor.
Update yapmak için internet gerekmiyor ama update ortadan kalkmıyor
Disconnected ortamlarla ilgili bir diğer yanlış düşünce de şu olabilir:
“İnternete bağlı değil, update etmeye gerek yok.”
Tam tersine.
Security update, Azure Local platform update, OEM firmware ve driver lifecycle devam ediyor.
Sadece update’in sisteme ulaşma yöntemi değişiyor.
Microsoft Disconnected Operations için update ve servicing işlemlerini offline veya staged workflow’larla gerçekleştiriyor.
Bu noktada version compatibility özellikle önemli.
Microsoft’un güncel compatibility tablosunda Disconnected Operations control plane build’i ile Azure Local build’i arasında desteklenen eşleşmeler açıkça tanımlanıyor. Eylül 2026 itibarıyla tabloda 2608 Disconnected Operations build’i, Azure Local 2608 ile eşleştirilmiş durumda. Microsoft ayrıca Azure Local sürümünün hiçbir zaman Disconnected Operations control plane sürümünden daha yeni olamayacağını özellikle belirtiyor.
Bu tek cümle operasyon açısından oldukça önemli.
Connected ortamda Azure portal size update geldiğini gösterir ve lifecycle manager üzerinden süreci yönetirsiniz.
Disconnected ortamda ise update paketlerinin kontrollü olarak ortama alınması, versiyon uyumluluğunun kontrol edilmesi ve doğru sırayla uygulanması gerekiyor.
Örneğin Azure Local workload cluster’ınızı 2608’e geçirip local control plane’i 2606’da bırakamazsınız.
Dolayısıyla burada change management çok daha önemli hale geliyor.
Ben disconnected ortamda update sürecini normal bir Windows patch operasyonu gibi değil, platform lifecycle operasyonu olarak değerlendirirdim.
Air-gapped ile disconnected aynı şey mi?
Burada terminolojiyi de doğru kullanmak gerekiyor.
Disconnected Operations internet veya Azure public cloud bağlantısı olmadan çalışabiliyor.
Ama bu, bütün mimarinin fiziksel olarak tek bir izole network segmentinden oluşması gerektiği anlamına gelmiyor.
Microsoft aynı disconnected control plane’in birden fazla site arasında paylaşılabileceğini de belirtiyor. Böyle bir yapıda siteler arasındaki private network bağlantısını müşteri tasarlıyor ve işletiyor.
Örneğin Ankara ve İstanbul’da iki ayrı veri merkeziniz olduğunu düşünelim.
İki lokasyonun da internete çıkışı olmayabilir fakat aralarında MPLS veya özel WAN bağlantısı bulunabilir.
Disconnected control plane bu private network üzerinden birden fazla siteyi yönetebilir.
Dolayısıyla disconnected demek, Azure Public Cloud bağlantısı yok demek. Mutlaka, Hiçbir başka network bağlantısı yok demek değil.
Gerçek air-gapped ortamlar tabii ki mümkün ama bunun fiziksel ve operasyonel tasarımı ayrı konu.
Bu ayrım özellikle büyük kamu ve savunma projelerinde önemli.
Kapasite planlamasını daha dikkatli yapmak gerekiyor
Connected Azure Local’da kapasite bittiğinde yeni node satın alıp cluster’ı genişletebilirsiniz.
Disconnected ortamda da scale mümkün ama procurement ve capacity planning tarafında daha dikkatli olmak gerekiyor.
Microsoft’un eligibility kriterlerinde workload ve kapasitenin donanım satın alınmadan önce planlanmasını özellikle istemesinin nedeni de bu.
Çünkü sadece workload compute kapasitesini hesaplamıyorsunuz.
Management cluster var.
Local control plane var.
Container registry gibi lokal servisler olabilir.
Kubernetes olabilir.
AI workload’u olabilir.
Update staging için kapasite gerekebilir.
Backup ve restore altyapısı var.
Bunların hepsi aynı fiziksel sınırlar içerisinde.
Public cloud’da kapasite gerektiğinde birkaç dakika içerisinde yeni VM oluşturmak ile disconnected private cloud’da yeni fiziksel node satın almak aynı operasyon değil.
Bu nedenle üç-beş yıllık büyüme planı burada connected ortama göre daha önemli hale geliyor.
Disconnected Operations artık Preview değil
Serinin ilk makalelerini hazırlarken bu konuyu anlatırken özellikle Preview durumuna dikkat etmek gerekiyordu.
Bu artık değişti.
Microsoft, Azure Local 2602 ile Disconnected Operations’ı General Availability durumuna getirdi.
Sonraki sürümlerde de platform hızlı şekilde geliştirilmeye devam etti.
2603 ile certificate rotation ve BCDR restore tarafında geliştirmeler geldi.
2604 ile workload cluster’larda 64 node desteği, performans ve security geliştirmeleri eklendi.
2605 ile infrastructure hardening, diagnostics, scalability ve reliability geliştirildi.
2606 ile security/quality geliştirmeleri ve certificate renewal dokümantasyonu geldi. Microsoft’un güncel acquisition tablosunda ise 2608 build’i de desteklenen sürümler arasında bulunuyor.
Ancak burada GA olan ana platform ile üzerinde çalışan bütün servislerin GA durumunu birbirine karıştırmamak gerekiyor.
Örneğin biraz önce söylediğim gibi AKS on Azure Local Disconnected Operations halen Preview.
Dolayısıyla ürünün kendisinin GA olması her workload’un aynı support seviyesinde olduğu anlamına gelmiyor.
Bu ayrımı özellikle production tasarımında mutlaka kontrol etmek gerekiyor.
Disconnected Operations hangi müşteriye mantıklı?
Ben bir Azure Local projesinde şu sırayla düşünürdüm.
Eğer Azure public cloud’a kontrollü bağlantı sağlayabiliyorsam connected Azure Local kullanırım.
Çünkü daha basit.
Control plane’i Microsoft işletiyor.
Azure servisleri daha geniş.
Lifecycle daha kolay.
Merkezi monitoring ve governance imkanları daha fazla.
Disconnected Operations’ı ise gerçek bir teknik veya regülasyon gereksinimi varsa değerlendiririm.
Veri değil, management plane de kurum sınırları içerisinde kalmak zorundaysa.
Public cloud bağlantısı yasaksa.
Sistem uzun süre veya kalıcı olarak internet erişimi olmadan çalışacaksa.
Sovereign veya classified workload varsa.
Operasyonun dış bağlantıdan bağımsız devam etmesi gerekiyorsa.
O zaman Disconnected Operations çok güçlü bir seçenek haline geliyor.
Microsoft’un 2026’daki Sovereign Private Cloud yatırımlarında Azure Local’ı bu kadar merkeze koymasının nedeni de bu. Microsoft özellikle savunma, kamu, enerji ve kritik altyapı gibi ortamlarda AI ve diğer workload’ların tamamen disconnected çalışabilmesini Azure Local üzerinden genişletiyor.
Ama bunu sadece “internet yokken Azure çalıştırıyoruz” diye anlatmak bana göre teknolojinin asıl farkını kaçırmak olur.
Asıl önemli olan internet bağlantısının olmaması değil.
Azure resource modelinin, control plane’in ve operasyon yaklaşımının müşterinin kendi fiziksel sınırlarının içine taşınması.
Bu da beraberinde başka bir sorumluluk getiriyor.
Control plane artık sizdeyse onun availability’si de sizde.
PKI sizde.
Update süreci sizde.
Capacity planning sizde.
Backup ve restore sizde.
Network sizde.
Security operasyonu sizde.
Yani daha fazla kontrol aynı zamanda daha fazla operasyonel sorumluluk demek.
Bu nedenle Azure Local Disconnected Operations’ı klasik HCI projesinden çok, kurum içerisinde işletilen bir private cloud projesi olarak değerlendirmek bana göre daha doğru.
Bir sonraki makalede tam olarak bu control plane’in başka bir tarafına geçeceğim. Azure Local Automation: Portal, Azure CLI, ARM, Bicep ve Terraform başlığı altında portalda yaptığımız işlemlerin arkasında hangi resource modelinin bulunduğunu, Azure Local VM ve altyapı kaynaklarını kod ile nasıl oluşturabileceğimizi ve özellikle çok sayıda lokasyonu olan yapılarda Infrastructure as Code yaklaşımının neden önemli hale geldiğini inceleyeceğiz.