Günümüz çözümlerinin çoğunlukla servis odaklı çözümler olması, bu çözümlerin barındığı ağ(network) alt yapılarının da özenle tasarlanması ve belli sınırlarının çizilmesi konularını gündeme getiriyor. Özellikle güvenlik öncelikli olarak beklenen bir kalite ölçütüyse… “Cloud” platformlar üzerinde çözümler geliştiriyorsak, platformun bu konular için sunduğu hizmetleri de kullanmak tahmin edersiniz ki oldukça önemli ve gerekli. Daha çok Azure platformunda çözümler geliştiren/sunan biri olarak bu açıdan iki hizmetten bahsetmeye çalışacağım bu yazıda; Azure’daki Private Endpoint ve Service Endpoint…

Azure üzerinde Paas(Platform as a service) şeklinde sunulan hizmetleri kullanan çözümler geliştirdiğimizde, bu servisler ile olan iletişimin belli kısıtlamalar ve sınırlar içinde olması çözümün güvenilirliği adına önemli. Belli servis erişimleri için kullanılan anahtarlar ya da kimlik bilgilerinin sızması durumunda ağ alt yapılarındaki tasarımlar ve kısıtlamalar oluşabilecek riskleri de minimuma indirgemek için oldukça değerli.

Service Endpoint

Bir Azure Virtual Network yarattığımız zaman, bu sanal ağ içerisinde olan kaynaklar; mesela bir tane sanal makine(VM) diğer Azure servisleri ile bir “Public IP” üzerinden, internete çıkarak iletişim kurar. Ama peki bunu istemezsek?

Oluşturulan sanal ağlarda(virtual network) tanımlanabilen “Service Endpoint”ler ile sanal ağ içerisinde oluşturulan kaynakların servislere erişiminin, sanal ağ tanımına göre sahip olduğu “Private Ip” ile olması mümkün olabiliyor. Bu sayede internete çıkmadan diğer Azure hizmetine erişimi sağlanabilmekte. İnternete çıkmadan Azure içindeki temel sanal ağ içinde kalarak erişimin sağlanması hem güvenlik hem de performans açısından önemli bir getiri.

“Service Endpoint”leri, ağdaki gizli kaynakların bir Azure hizmetine tanıtılması gibi düşünebiliriz. “Service Endpoint”ler sayesinde, Azure hizmeti bir ağdaki bileşeni tanımış ve ona özel bir kapı açmış gibi canlandırmak belki daha basit olacak. Azure portal üzerinden bu tanımlamaları oldukça kolay bir şekilde yapabiliyoruz.

Aşağıdaki Azure hizmetlerini bir “Service Endpoint” olarak eklemek mümkün.

  • Microsoft.AzureActiveDirectory
  • Microsoft.AzureCosmosDB
  • Microsoft.CognitiveServices
  • Microsoft.ContainerRegistry
  • Microsoft.EventHub
  • Microsoft.KeyVault
  • Microsoft.ServiceBus
  • Microsoft.Sql
    • SQL Database
    • MySQL
    • PostgreSQL
    • Synapse Analytics
  • Microsoft.Storage
  • Microsoft.Web (App Services)

Hem küçük bir ek olması, hem de daha iyi anlaşılması için; sanal ağa “Service Endpoint” tanımı yapmadan, direkt erişeceğimiz Azure hizmeti üzerinden de “Service Endpoint” aktifleştirmesini yapabiliyoruz. Zaten direkt bir hizmeti sanal ağımıza eklemek istediğimizde portal üzerinden önce sanal ağda “Service Endpoint”in aktifleştirilmesinin yapılması gerekliliğini görüyoruz.

Dan diye birden SQL Server’dan da örnek verdim ama biraz daha canlandırabilmek için örneği daha net ele alalım; bir sanal ağ içinde bir “subnet”e bağlı da bir VM olduğunu düşünelim. Bu VM’i internete açmadığımızı yani “Public IP”sinin de olmadığını düşünelim. VM içindeki uygulamamız Azure SQL veri tabanına erişmek durumunda olsun. Eğer sanal ağdaki bu ilgili “subnet”‘de Microsoft.Sql için bir “Service Endpoint” tanımı yoksa, VM içindeki uygulamamız SQL veri tabanına erişemeyecektir. Ancak “Service Endpoint” tanımladığımız zaman VM, iletişimi tamamen Azure ağ alt yapısı içinde kalacak şekilde SQL veri tabanına erişebilecektir. İnternette dolaşmadan da erişimin sağlanıyor olması veri güvenliği açısından da oldukça önemli.

Ancak burada önemli bir nokta var ki; o da Azure SQL veri tabanı hizmetine erişirken, Azure “Public DNS”si üzerinden erişim sağlanıyor. Yani küresel anlamda Azure tarafında bir DNS sorunu olursa uygulamamız veri tabanına erişemeyecektir.

Peki, Private Endpoint ne?

“Private Endpoint”, “Service Endpoint”e benzeyen bir kavram; onun bir üst versiyonu gibi ele alabiliriz. “Private Endpoint”ler Azure Private Link hizmetninin temel bir parçası. Azure Private Link‘de, sanal ağ kaynaklarının diğer servislere erişiminin yine aynı sanal ağ içinde olması sağlanıyor ama ek olarak diğer servislerin de sanal ağ içinden verilen özel bir IP ile erişilmesi sağlanıyor. Bu özel IP alabilmesi hizmeti de “Private Endpoint” olarak adlandırılıyor.

“Service Endpoint” ile bağlandığımız Azure hizmetlerinin kendi “Public IP”‘lerine erişim yapıyorduk. “Private Endpoint”de ise, Azure hizmetini kendi sanal ağımıza dâhil edebiliyoruz ve o hizmetin sanal ağ içinden bir “Private IP” almasını sağlıyoruz. Böylece, erişmek istediğimiz hizmet tamamen bizim Azure üstündeki sanal ağa ait olmuş oluyor. Ağ dışından bir erişimi engellemiş oluyor ve trafik yine sanal ağ içinde kalmış oluyor.

“Service Endpoint”lerde hatırlarsanız “Public DNS” ile erişmek istediğimiz servise erişiyorduk. “Private Endpoint”de ise, “Private DNS” ile sanal ağımızdan aldığı IP adresi ilişkilendiriliyor. Bu sayede de erişmek istediğimiz Azure servisi çözümlenebiliyor. Dolayısıyla “Service Endpoint”e göre bir tane “Private DNS” gereksinimi ortaya çıkıyor.

Sanal makinemiz içinde erişmek istediğimiz Azure hizmetine nslookup yaptığımızda; bu senaryoda erişmek istediğimiz hizmet Azure SQL Server olsun, aşağıdaki gibi bir çıktı ile karşılacağız.

Public DNS üstünden Azure SQL Server’ın IP adresi

Dikkat edersiniz ki burada erişmek istediğimiz isime karşılık bir tane “Public IP” geliyor. Yani internetteki bir Azure SQL Server hizmetine erişiyoruz. Şimdi hızlıca kullanacağımız Azure SQL Server için Azure portal üstünden nasıl “Private Endpoint” yaratıyoruz bunun üstünden de giderek biraz daha netleştirelim ve Azure SQL Server’ı sanal ağımızın içine alalım.

Direkt olarak SQL Server’ın “Security” başlığı altındaki “Private endpoint connections” başlığına tıklayarak “Private Endpoint”leri görebiliriz.


Yeni bir tane eklemek istediğimizde standart Azure kaynağı ekler gibi bir ekranla karşılacağız. Burada “Resource” ve “Configuration” başlıkları önemli olacak. Öncelikle “Resource” başlığında ilgili kaynağımızı belirtiyoruz. Bizim senaryoda SQL olduğu için tipi ve kaynağımızı ona göre seçiyoruz.


Daha sonra “Configuration” başlığı altında da hangi sanal ağ için bu “Private Endpoint”i oluşturacağımızı beliriyoruz. Burada önemli bir nokta “Private DNS” entegrasyonu. Burada Azure üzerinde bir “Private DNS” oluşturulmasını da sağlayabiliyoruz.


Bu ayarları yaptıktan sonra “Private Endpoint”i oluşturduğumuz zaman artık ağ iletişimi açısından Azure SQL Server’da bizim ağımızın içindeki bir kaynakmış gibi oluyor. Daha deminki gibi erişmek istediğimiz bu SQL Server’a VM üzerinden nslookup yaptığımızda, erişmek istediğimiz IP’nin sanal ağımızdaki bir IP olduğunu göreceğiz.

Private DNS üstünden Azure SQL Server’ın IP adresi sanal ağımızdan alınıyor

Bu bir birine benzeyen iki hizmet eğer Azure üzerinde çözüm geliştiriyorsak oldukça önemli diye düşünüyorum. Başta da söylediğim gibi “Private Endpoint”ler, “Service Endpoint”lerin üstüne eklenebilecek bir hizmet. Aralarındaki en önemli farklardan biri, “Private Endpoint”lerin ücretli olması. Sanal ağ içerisinde dolanan trafiğe göre bir ücretlendirme modeli var; GB başına $0.01 gibi bir ücret. Ama “Service Endpoint”ler tamamen ücretsiz. Diğer önemli fark da “Private Endpoint”lerin “on-premise” çözümler ile de ilişkilendirilebiliyor olması ama “Service Endpoint”de bu mümkün değil.

Azure üzerinde çözümler geliştirmeye ya da sunmaya başladıysanız ya da başlamayı düşünüyorsanız umarım bazı kavramlar için açıklayıcı bir başlangıç olur. Bir sonraki yazıda görüşmek üzere…

Mutlu geliştirmeler.