Abonelikle ilgili önemli noktalar ve öneriler

Abonelikler, Azure içindeki bir yönetim, faturalama ve ölçek birimidir. Bunlar, büyük ölçekli Azure benimsemesi için tasarım yaparken kritik bir rol oynar. Bu makale, abonelik gereksinimlerini yakalamanıza ve aşağıdakilere dayalı kritik faktörlere göre hedef abonelikler tasarlamanıza yardımcı olabilir:

• ortam türü
• sahiplik ve idare modeli
• kuruluş yapısı
• uygulama portföyleri

Bahşiş

Bu konuyu yeni bir YouTube videosunda ele aldık: Azure Giriş Bölgeleri - Azure'da kaç abonelik kullanmalıyım?

Dekont

Azure portalındaki Faturalama hesapları ve kapsamları bölümünde belirtildiği gibi abonelik sınırlarını gözden geçirmeniz gerekir. Bu kılavuz öncelikli olarak Kurumsal Anlaşma, Microsoft Müşteri Sözleşmesi (Enterprise) veya Microsoft İş Ortağı Sözleşmesi (CSP) kullanan müşterilere yöneliktir.

Aboneliklerle ilgili dikkat edilmesi gerekenler

Aşağıdaki bölümlerde Azure aboneliklerini planlamanıza ve oluşturmanıza yardımcı olacak önemli noktalar yer almaktadır.

Kuruluş ve idare tasarımında dikkat edilmesi gerekenler

• Abonelikler, Azure İlkesi atamaları için sınırlar görevi görür.

  • Örneğin, Ödeme Kartı Sektörü (PCI) iş yükleri gibi güvenli iş yükleri genellikle uyumluluk elde etmek için başka ilkeler gerektirir. PCI uyumluluğu gerektiren iş yüklerini harmanlama amacıyla bir yönetim grubu kullanmak yerine, birkaç aboneliği olan çok fazla yönetim grubuna sahip olmadan bir abonelikle aynı yalıtımı elde edebilirsiniz.

    • Aynı iş yükü arketipinin birçok aboneliğini gruplandırmanız gerekiyorsa, bunları bir yönetim grubu altında oluşturun.

• Abonelikler, bileşen iş yüklerinin platform abonelik sınırları içinde ölçeklenebilmesi için bir ölçek birimi görevi görür. İş yüklerinizi tasarlarken abonelik kaynak sınırlarını dikkate almayı unutmayın.

• Abonelikler, idare ve yalıtım için endişeleri açıkça ayıran bir yönetim sınırı sağlar.

• Gerektiğinde yönetim (izleme), bağlantı ve kimlik için ayrı platform abonelikleri oluşturun.

  • Azure İzleyici Log Analytics çalışma alanları ve Azure Otomasyonu runbook'ları gibi genel yönetim özelliklerini desteklemek için platform yönetim grubunuzda ayrılmış bir yönetim aboneliği oluşturun.
    • Gerektiğinde Windows Server Active Directory etki alanı denetleyicilerini barındırmak için platform yönetim grubunuzda ayrılmış bir kimlik aboneliği oluşturun.
    • Bir Azure Sanal WAN merkezi, özel Etki Alanı Adı Sistemi (DNS), ExpressRoute bağlantı hattı ve diğer ağ kaynaklarını barındırmak için platform yönetim grubunuzda ayrılmış bir bağlantı aboneliği oluşturun. Ayrılmış abonelik, tüm temel ağ kaynaklarınızın birlikte faturalanmasını ve diğer iş yüklerinden yalıtılmasını sağlar.
    • Abonelikleri, iş gereksinimlerinize ve önceliklerinize uygun, demokratik bir yönetim birimi olarak kullanın.

• Microsoft Entra kiracılarını yalnızca Kurumsal Anlaşma kayıt abonelikleriyle sınırlamak için el ile işlemleri kullanın. El ile bir işlem kullanmak, kök yönetim grubu kapsamında Microsoft Developer Network aboneliklerinin oluşturulmasını engeller.

  • Destek için bir Azure Destek bileti gönderin.

• Azure faturalama teklifleri arasındaki abonelik aktarımları için bkz. Azure aboneliği ve rezervasyon aktarım hub'ı .

Kota ve kapasite tasarımında dikkat edilmesi gerekenler

Azure bölgelerinin sınırlı sayıda kaynağı olabilir. Sonuç olarak, çok sayıda kaynak içeren Azure benimsemeleri için kullanılabilir kapasite ve SKU'lar izlenmelidir.

• İş yüklerinizin gerektirdiği her hizmet için Azure platformundaki sınırları ve kotaları göz önünde bulundurun.

• Seçtiğiniz Azure bölgelerinde gerekli SKU'ların kullanılabilirliğini göz önünde bulundurun. Örneğin, yeni özellikler yalnızca belirli bölgelerde kullanılabilir. VM'ler gibi belirli kaynaklar için belirli SKU'ların kullanılabilirliği bir bölgeden diğerine farklı olabilir.

• Abonelik kotalarının kapasite garantisi olmadığını ve bölge bazında uygulandığını göz önünde bulundurun.

  • Sanal makine kapasitesi rezervasyonları için bkz . İsteğe bağlı kapasite rezervasyonu.

• Kullanım dışı veya kullanımdan kaldırılmış abonelikleri, Her seferinde yeni bir Azure Aboneliği oluşturmalı mı yoksa Azure Aboneliklerini yeniden kullanmalı mıydık? - Azure giriş bölgeleri hakkında SSS bölümündeki yönergelere göre yeniden kullanmayı göz önünde bulundurun.

Kiracı aktarım kısıtlaması tasarımında dikkat edilmesi gerekenler

Her Azure aboneliği, Azure aboneliğiniz için kimlik sağlayıcısı (IdP) işlevi gören tek bir Microsoft Entra kiracısına bağlanır. Microsoft Entra kiracısı kullanıcıların, hizmetlerin ve cihazların kimliğini doğrulamak için kullanılır.

Azure aboneliğinize bağlı Microsoft Entra kiracısı, gerekli izinlere sahip herhangi bir kullanıcı tarafından değiştirilebilir. Bu işlem aşağıdaki makalelerde ayrıntılı olarak anlatılır:

• Microsoft Entra kiracınıza Azure aboneliğini ilişkilendirme veya ekleme
• Azure aboneliğini farklı bir Microsoft Entra dizinine aktarma

Dekont

Azure Bulut Çözümü Sağlayıcısı (CSP) abonelikleri için başka bir Microsoft Entra kiracısına aktarma desteklenmez.

Azure giriş bölgeleriyle, kullanıcıların abonelikleri kuruluşunuzun Microsoft Entra kiracısına aktarmasını önlemek için gereksinimleri ayarlayabilirsiniz. Azure abonelik ilkelerini yönetme bölümündeki işlemi gözden geçirin.

Muaf tutulan kullanıcıların listesini sağlayarak abonelik ilkenizi yapılandırın. Muaf tutulan kullanıcıların ilkede ayarlanan kısıtlamaları atlamasına izin verilir.

Önemli

Muaf tutulan kullanıcılar listesi bir Azure İlkesi değildir.

• Visual Studio/MSDN Azure aboneliklerine sahip kullanıcıların aboneliklerini Microsoft Entra kiracınıza veya kiracınızdan aktarmasına izin verilip verilmeyeceğini göz önünde bulundurun.

• Kiracı aktarım ayarları yalnızca Microsoft Entra Global Yönetici istrator rolü atanmış kullanıcılar tarafından yapılandırılabilir. Bu kullanıcılar ve ilkeyi değiştirmek için yükseltilmiş erişime sahip olmalıdır.

  • Tek tek kullanıcı hesaplarını Microsoft Entra grupları olarak değil, yalnızca muaf kullanıcılar olarak belirtebilirsiniz.

• Azure erişimi olan tüm kullanıcılar, Microsoft Entra kiracınız için tanımlanan ilkeyi görüntüleyebilir.

  • Kullanıcılar muaf tutulan kullanıcılar listenizi görüntüleyemez.

  • Kullanıcılar Microsoft Entra kiracınızdaki genel yöneticileri görüntüleyebilir.

• Bir Microsoft Entra kiracısına aktarılan Azure abonelikleri, bu kiracı için varsayılan yönetim grubuna yerleştirilir.

• Kuruluşunuz tarafından onaylanırsa, uygulama ekibiniz Azure aboneliklerinin bir Microsoft Entra kiracısına veya kiracısından aktarılmasına izin veren bir süreç tanımlayabilir.

Maliyet yönetimi tasarımında dikkat edilmesi gerekenleri belirleme

Maliyet şeffaflığı, her büyük kuruluş kuruluşunun karşılaştığı kritik bir yönetim zorluğudur. Makalenin bu bölümünde, büyük Azure ortamlarında maliyet şeffaflığı sağlamanın temel yönleri inceleniyor.

• daha yüksek yoğunluk elde etmek için Azure Uygulaması Hizmet Ortamı ve Azure Kubernetes Service gibi geri ödeme modellerinin paylaşılması gerekebilir. Hizmet olarak paylaşılan platform (PaaS) kaynakları Geri ödeme modellerinden etkilenebilir.

• Maliyetleri iyileştirmek için üretim dışı iş yükleri için kapatma zamanlaması kullanın.

• Maliyetleri iyileştirmeye yönelik önerileri denetlemek için Azure Danışmanı'na bakın.

• Maliyetin kuruluşunuz genelinde daha iyi dağıtılması için bir geri ödeme modeli oluşturun.

• Kuruluşunuzun ortamında dağıtılmak üzere yetkilendirilmemiş kaynakların dağıtımını önlemek için ilke uygulayın.

• İş yükleri için maliyet ve doğru boyut kaynaklarını gözden geçirmek için düzenli bir zamanlama ve tempo oluşturun.

Abonelik önerileri

Aşağıdaki bölümlerde Azure aboneliklerini planlamanıza ve oluşturmanıza yardımcı olacak öneriler yer almaktadır.

Kuruluş ve idare önerileri

• Abonelikleri iş gereksinimlerinize ve önceliklerinize uygun bir yönetim birimi olarak değerlendirin.

• Abonelik sahiplerini rollerini ve sorumluluklarını fark etmelerini sağlayın.

  • Kullanıcılar kuruluşunuz içinde ilerledikçe ayrıcalıkların artmadığından emin olmak için Microsoft Entra Privileged Identity Management için üç aylık veya yıllık erişim gözden geçirmesi yapın.
  • Bütçe harcamalarının ve kaynaklarının tüm sahipliğini alın.
  • İlke uyumluluğunu sağlayın ve gerektiğinde düzeltin.

• Yeni aboneliklerin gereksinimlerini belirlerken aşağıdaki ilkelere başvurun:

  • Ölçek sınırları: Abonelikler, bileşen iş yüklerinin platform abonelik sınırları içinde ölçeklendirilmesi için bir ölçek birimi görevi görür. Yüksek performanslı bilgi işlem, IoT ve SAP gibi büyük özel iş yükleri, bu sınırlara karşı çalışmamak için ayrı abonelikler kullanmalıdır.
  • Yönetim sınırı: Abonelikler, idare ve yalıtım için bir yönetim sınırı sağlayarak endişelerin net bir şekilde ayrılmasına olanak sağlar. Geliştirme, test ve üretim gibi farklı ortamlar genellikle yönetim perspektifinden kaldırılır.
  • İlke sınırı: Abonelikler, Azure İlkesi atamaları için bir sınır görevi görür. Örneğin, PCI gibi güvenli iş yükleri genellikle uyumluluk sağlamak için başka ilkeler gerektirir. Ayrı bir abonelik kullanıyorsanız diğer ek yük dikkate alınmaz. Geliştirme ortamları, üretim ortamlarından daha rahat ilke gereksinimlerine sahiptir.
  • Hedef ağ topolojisi: Sanal ağları abonelikler arasında paylaşamazsınız, ancak bunları sanal ağ eşleme veya Azure ExpressRoute gibi farklı teknolojilerle bağlayabilirsiniz. Yeni bir aboneliğe ihtiyacınız olup olmadığını belirlerken, hangi iş yüklerinin birbiriyle iletişim kurması gerektiğini göz önünde bulundurun.

• Abonelikleri, yönetim grubu yapınızla ve ilke gereksinimlerinizle uyumlu yönetim grupları altında gruplandırma. Abonelikleri gruplandırma, aynı ilke kümesine ve Azure rol atamalarına sahip aboneliklerin tümünün bir yönetim grubundan gelmesini sağlar.

• Azure İzleyici Log Analytics çalışma alanları ve Azure Otomasyonu runbook'ları gibi genel yönetim özelliklerini desteklemek için yönetim grubunuzda Platform ayrılmış bir yönetim aboneliği oluşturun.

• Gerektiğinde Windows Server Active Directory etki alanı denetleyicilerini barındırmak için yönetim grubunuzda Platform ayrılmış bir kimlik aboneliği oluşturun.

• Bir Azure Sanal WAN merkezi, özel Etki Alanı Adı Sistemi (DNS), ExpressRoute bağlantı hattı ve diğer ağ kaynaklarını barındırmak için yönetim grubunuzda Platform ayrılmış bir bağlantı aboneliği oluşturun. Ayrılmış abonelik, tüm temel ağ kaynaklarınızın birlikte faturalanmasını ve diğer iş yüklerinden yalıtılmasını sağlar.

• Katı bir abonelik modeli kullanmaktan kaçının. Bunun yerine, kuruluşunuz genelinde abonelikleri gruplandırmak için bir dizi esnek ölçüt kullanın. Bu esneklik, kuruluşunuzun yapısı ve iş yükü bileşimi değiştikçe, sabit bir abonelik kümesi kullanmak yerine yeni abonelik grupları oluşturabilmenizi sağlar. Bir boyut abonelikler için tümüne uymaz ve bir iş birimi için çalışan şeyler başka bir iş birimi için çalışmayabilir. Bazı uygulamalar aynı giriş bölgesi aboneliği içinde bir arada bulunabilirken, diğerleri kendi aboneliklerini gerektirebilir.

  • Daha fazla bilgi için bkz. Azure giriş bölgesi mimarisinde "geliştirme/test/üretim" iş yükü giriş bölgelerini nasıl işleyebiliriz?

Kota ve kapasite önerileri

• Abonelikleri ölçek birimi olarak kullanın ve kaynakları ve abonelikleri gerektiği gibi ölçeklendirin. İş yükünüz daha sonra Azure platformunda abonelik sınırlarına girmeden ölçeği genişletme için gerekli kaynakları kullanabilir.

• Bazı bölgelerde kapasiteyi yönetmek için kapasite rezervasyonlarını kullanın. Daha sonra iş yükünüz belirli bir bölgedeki yüksek talep kaynakları için gerekli kapasiteye sahip olabilir.

• Kullanılan kapasite düzeylerini izlemek için özel görünümlere sahip bir pano oluşturun ve kapasite kritik düzeylere yaklaşıyorsa (yüzde 90 CPU kullanımı) uyarılar ayarlayın.

• Abonelik sağlama kapsamında kota artışları için destek istekleri (örneğin, bir abonelik içindeki toplam kullanılabilir VM çekirdeği için) yükseltin. İş yükleriniz varsayılan sınırları aşmadan önce kota sınırlarınızın ayarlandığından emin olun.

• Gerekli hizmetlerin ve özelliklerin seçtiğiniz dağıtım bölgelerinde kullanılabilir olduğundan emin olun.

Otomasyon önerileri

• Abonelik otomatında açıklandığı gibi bir istek iş akışı aracılığıyla uygulama ekipleri için Abonelik oluşturma işlemini otomatikleştirmek için bir Abonelik satış süreci oluşturun.

Kiracı aktarımı kısıtlama önerileri

• Kullanıcıların Azure aboneliklerini Microsoft Entra kiracınıza veya kiracınızdan aktarmasını önlemek için aşağıdaki ayarları yapılandırın:

  • Microsoft Entra dizininden çıkan Aboneliği olarak Permit no oneayarlayın.

  • Microsoft Entra dizinine giren Aboneliği olarak Permit no oneayarlayın.

• Muaf tutulan kullanıcıların sınırlı bir listesini yapılandırın.

  • Azure PlatformOps (platform işlemleri) ekibi üyelerini dahil edin.
  • Muaf tutulan kullanıcılar listesine cam kırılan hesaplar ekleyin.

Sonraki adımlar

İlke temelli korumaları benimseme