Microsoft’un GA olarak belgelediği standard service endpoint, Azure Storage ve Azure SQL Database erişimi için üçüncü bir ağ seçeneği açtı. Bu seçeneği ücretsiz basic service endpoint’in yeni adı sanırsanız faturada VNet başına saatlik kalemle karşılaşırsınız. Private endpoint sanırsanız daha ciddi bir hata yaparsınız: Kaynağınıza özel IP üzerinden erişim sağlamış olmazsınız.
Birden çok VNet’teki VM’lerin PaaS kaynaklarına erişimini tasarlarken önce public endpoint politikanıza ve şirket içi erişim ihtiyacınıza bakın. Ardından basic modelin kaynak başına kurallarını, standard modelin ortak ağ tanıtıcısını ve private endpoint’in DNS yükünü karşılaştırıp maliyet hesabına geçelim.
Basic service endpoint ne zaman yeter?
Basic service endpoint bir subnet’ten Azure hizmetine doğrudan erişim sağlar. Hizmet tarafında o subnet için VNet kuralı tanımlarsınız. Azure Storage’a erişecek iki subnet’iniz varsa storage account’un Networking ayarına iki ayrı VNet kuralı eklersiniz. Kural sayısı yönetilebilir kaldığı sürece bu basitlik avantaj, endpoint için ayrıca saatlik ücret de yok.
Yalnız DNS hala hizmetin public IP adresine çözülür. Trafiğin Azure omurgası üzerinden gitmesi, hizmetin public endpoint’inin ortadan kalktığı anlamına gelmez. Şirket içindeki bir istemci de VPN açtığı için service endpoint’i kendi subnet’indeymiş gibi kullanamaz. Public erişimi tümden kapatma şartınız varsa basic modeli eleyin.
Projelerimde ağ değişikliğinden önce VM, NIC, public IP ve VNet bağlarını ayrı ayrı envantere çıkarırım. Abonelikler arası kaynak taşıma deneyimimde de bu bağlantılara bakmak gerekiyordu. Service endpoint kararında aynı alışkanlık işe yarıyor: Hangi VM’nin hangi subnet’ten hangi kaynağa gittiğini bilmiyorsanız ücretsiz seçeneğin kural yükünü de doğru ölçemezsiniz.
Standard modelin ortak tanıtıcısı ne işe yarıyor?
Microsoft Learn’ün GA olarak tanımladığı standard service endpoint, subnet’teki service endpoint’e bir public IP’yi network identifier olarak bağlar. Bu IP, VM’ye takılan public IP ya da dışarı çıkan paketleri taşıyan NAT Gateway adresi değildir. Yönlendirme kararı için kullanılmaz. Hizmet, subnet’ten gelen trafiği bu adresten tanır. Böylece birden çok subnet tek bir tanıtıcı altında toplanır.
Tanıma tek başına izin sayılmaz. PaaS kaynağını network security perimeter ile ilişkilendirip tanıtıcıyla eşleşen inbound allow kuralını kurmanız gerekir. Portal kurulum rehberi subnet’te network identifier seçimini ve perimeter kuralını ayrı adımlar olarak gösteriyor. Public IP adı görünüyor diye trafiğin internete yönlendirildiğini düşünmeyin. Adres burada yalnızca perimeter kuralının eşleştirdiği kaynak kimliği.
Aynı network identifier, aynı tenant ve bölgedeki birden fazla VNet’te, farklı aboneliklerde bile kullanılabilir. Çok sayıda subnet’in erişim kuralını tek tek güncellemek yerine ortak tanıtıcıyı perimeter kuralında kullanırsınız. Büyük kurulumdaki bakım farkı buradan çıkar.
Destek listesinde Azure Key Vault ve Azure Cosmos DB de var. Yine de public endpoint kontrollü erişime açık kalır, private IP kazanmazsınız. Azure SQL Database için standard endpoint ile bölgeler arası erişim desteği de yok. Diğer hizmetlerin davranışını SQL’e genellemeyin.
App Service için statik outbound IP yazımda allowlist’e giren çıkış adreslerini yönetmenin ne kadar iş çıkarabildiğini anlatmıştım. Oradaki NAT Gateway IP’si gerçekten çıkış trafiğiyle ilişkilidir. Standard service endpoint’in public IP’si ise trafiği taşımaz. Benzer görünen iki public IP alanını aynı ağ çizimine bakmadan eşitlemek kolay, yanlış güvenlik kararı da tam oradan çıkıyor.
Bir geçiş daha yapacaksanız bakım penceresini düşünün. Microsoft’un standard endpoint açıklaması, mevcut service endpoint’e network identifier eklemenin veya onu değiştirmenin aktif bağlantıları sıfırlayabildiğini söylüyor. Önce hangi uygulamanın bağlantısının kesilebileceğini not alın, sonra ayarı değiştirin.
Özel IP gerekiyorsa private endpoint
Private endpoint, VNet içinde private IP’li bir ağ arayüzü oluşturur. Kaynağa subnet’inizden aldığı özel adres üzerinden ulaşırsınız. Şirket içindeki istemciler de uygun ağ ve DNS düzeniyle VPN veya ExpressRoute üzerinden bu adrese erişebilir. Basic ve standard service endpoint bu şirket içi ihtiyacı aynı biçimde karşılamaz.
Endpoint’i kurunca isim çözümlemesini de düzeltmek gerekir. Private endpoint DNS yapılandırmasını kontrol edin ki istemci hizmet adını private IP’ye çözebilsin; aksi halde istek beklediğiniz adrese gitmeyebilir. Private endpoint oluşturmak kaynağın public network access ayarını kendiliğinden kapatmaz. Kurulum sonrası bu ayarı ayrıca doğrulayın.
Endpoint başına saatlik ücret ve işlenen veri bedeli ödersiniz, DNS kayıtlarını da yaşatırsınız. Karşılığında private bağlantı gereksinimini karşılarsınız. Portalda endpoint Succeeded görünse bile nslookup hizmet adını hala public IP’ye çözüyorsa trafik private endpoint’e gitmez.
Fatura hesabını hangi sırayla yapıyorum?
İlk kontrolüm public endpoint’e izin verilip verilmediği. Politika private erişim istiyorsa ücret kıyasından önce private endpoint masaya gelir. Şirket içi istemcinin erişimi gerekiyorsa da aynı sonuca varırım. Public endpoint kontrollü biçimde kullanılabiliyorsa subnet ve VNet sayısına, kaynaklardaki kural yüküne bakarım. Birkaç subnet için basic modelin ücretsiz oluşu güçlü bir neden.
Kural sayısı büyüdüğünde standard modelin ortak tanıtıcısı iş yükünü azaltabilir, ama fiyat kalemlerini karıştırmayın. Basic service endpoint ek endpoint ücreti getirmez, standard service endpoint ise ücretli bir seçenektir ve faturası VNet başına saatlik işler; private endpoint için endpoint başına saatlik ve işlenen GB üzerinden ücret ödersiniz. Bir IP’yi on VNet’te paylaşmak faturayı bir VNet’e indirmez. Bölge ve teklif değiştiği için sabit tutar vermek yerine güncel Azure fiyat hesaplayıcısıyla kendi topolojinizi girin.
Lisans maliyetini sorguladığım SQL Server enabled by Arc yazısındaki disiplin burada da geçerli: Mevcut ücretsiz seçenek işinizi görüyorsa yeni saatlik kalemi neden açtığınızı açıklayabilmelisiniz. SQL Server lisansı ile Azure SQL Database ağ ücreti farklı kalemler. Ben bu örnekte yalnızca fatura gelmeden önce hesabı görünür kılma alışkanlığından söz ediyorum.
Erişim modelini seçmeden önce
- Public endpoint yasaksa veya şirket içinden özel erişim gerekiyorsa private endpoint’i ve DNS düzenini planlayın.
- Az sayıda subnet’in VNet kurallarını rahatça yönetiyorsanız basic service endpoint’i bırakmak için acele etmeyin.
- Çok VNet’in kural yükü büyüdüyse standard modelin perimeter kurallarını ve VNet başına ücretini birlikte hesaplayın.
Seçtiğiniz modelde hizmet adının hangi IP’ye çözüldüğünü, hangi subnet’in erişebildiğini ve faturayı hangi satırın büyüttüğünü aynı ağ çiziminde gösterebilmelisiniz.
Sizin ortamınızda kararı zorlaştıran subnet sayısı mı, public erişim politikası mı? Yorumlarda konuşalım.
