Abonelikle ilgili önemli noktalar ve öneriler

Abonelikler, Azure’daki bir yönetim, faturalama ve ölçek birimidir. Bunlar, büyük ölçekli Azure benimsemesi için tasarlarken kritik bir rol oynar. Bu makale, abonelik gereksinimlerini yakalamanıza ve aşağıdakilere bağlı olarak değişen kritik faktörlere göre hedef abonelikler tasarlamanıza yardımcı olur:

• Ortam türleri
• Sahiplik ve idare modelleri
• Kuruluş yapıları
• Uygulama portföyleri
• Bölgeler

Abonelikle 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 Günlükleri ç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), Azure 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 kullandığınızda, kök yönetim grubu kapsamında Microsoft Developer Network (MSDN) abonelikleri oluşturamazsınız.

  Destek için bir Azure desteği bileti gönderin.

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

Birden çok bölgeyle ilgili dikkat edilmesi gerekenler

• Ölçeklendirme veya coğrafi olağanüstü durum kurtarma için tek iş yükü düzeyinde veya genel düzeyde (farklı bölgelerdeki farklı iş yükleri) çoklu bölge yaklaşımını benimseyebilirsiniz.

• Tek bir abonelik, gereksinimlere ve mimariye bağlı olarak farklı bölgelerden kaynaklar içerebilir.

• Coğrafi olağanüstü durum kurtarma bağlamında, aynı aboneliği birincil ve ikincil bölgelerdeki kaynakları içerecek şekilde kullanabilirsiniz çünkü bunlar mantıksal olarak aynı iş yükünün bir parçasıdır.

• Maliyetleri ve kaynak kullanılabilirliğini iyileştirmek için farklı bölgelerde aynı iş yükü için farklı ortamlar dağıtabilirsiniz.

• Birden çok bölgedeki kaynakları içeren bir abonelikte, kaynakları bölgeye göre düzenlemek ve içermek için kaynak gruplarını kullanabilirsiniz.

Kota ve kapasite tasarımında dikkat edilmesi gerekenler

Azure bölgelerinin sınırlı sayıda kaynağı olabilir. Sonuç olarak, çeşitli kaynaklarla Azure benimsemeleri için kullanılabilir kapasiteyi ve SKU'ları izlemeniz gerekir.

• İş 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, yalnızca belirli bölgelerde yeni özellikler kullanılabilir olabilir. Sanal makineler (VM) gibi belirli kaynaklar için belirli SKU'ların kullanılabilirliği bir bölgeden diğerine farklılık gösterebilir.

• 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ılmayan veya kullanımdan kaldırılan abonelikleri yeniden kullanmayı göz önünde bulundurun. Daha fazla bilgi için bkz . Azure aboneliklerini oluşturma veya yeniden kullanma.

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. Kullanıcıların, hizmetlerin ve cihazların kimliğini doğrulamak için Microsoft Entra kiracısını kullanın.

Herhangi bir kullanıcı gerekli izinlere sahip olduğunda, Azure aboneliğinize bağlı Microsoft Entra kiracısını değiştirebilir. Daha fazla bilgi için bkz.

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

Azure giriş bölgeleri için, kullanıcıların abonelikleri kuruluşunuzun Microsoft Entra kiracısına aktarmasını önlemek için gereksinimleri ayarlayabilirsiniz. Daha fazla bilgi için bkz. Azure abonelik ilkelerini yönetme.

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.

• Visual Studio veya MSDN Azure abonelikleri olan kullanıcıların aboneliklerini Microsoft Entra kiracınıza veya kiracınızdan aktarmasına izin verip vermeyemeyeceğinizi düşünün.

• Yalnızca Microsoft Entra Genel Yöneticisi rolüne sahip kullanıcılar kiracı aktarım ayarlarını yapılandırabilir. İlkeyi değiştirmek için bu kullanıcıların yükseltilmiş erişimi 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 aktardığınız Azure abonelikleri, bu kiracı için varsayılan yönetim grubuna yerleştirilir.

• Kuruluşunuz onaylarsa, uygulama ekibiniz Azure aboneliklerinin bir Microsoft Entra kiracısına veya kiracısından aktarılmasına izin veren bir işlem tanımlayabilir.

Maliyet yönetimi tasarımında dikkat edilmesi gerekenler

Her büyük kurumsal kuruluşun maliyet şeffaflığını yönetme zorluğu vardır. Bu bölümde, büyük Azure ortamlarında maliyet şeffaflığı elde etmek için önemli yönleri inceler.

• Daha yüksek yoğunluk elde etmek için App Service Ortamı ve Azure Kubernetes Service (AKS) gibi geri ödeme modellerini paylaşmanız gerekebilir. Geri ödeme modelleri, paylaşılan hizmet olarak platform (PaaS) kaynaklarını etkileyebilir.

• Maliyetleri iyileştirmek için üretim dışı iş yüklerine yönelik bir kapatma zaman çizelgesi kullanın.

• Maliyetleri iyileştirmeye yönelik öneriler almak 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.

• Kullanıcıların kuruluşunuzun ortamında yetkisiz kaynakları dağıtamamalarını sağlayan ilkeyi uygulayın.

• maliyetleri gözden geçirmek ve iş yükleri için kaynakları hak etmek 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 rol ve sorumlulukları hakkında bilgilendirin.

  • Kullanıcılar kuruluşunuz içinde hareket ettiğinde ayrıcalıkların artmadığından emin olmak için Microsoft Entra Privileged Identity Management (PIM) 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ğu sağlayın ve gerektiğinde düzeltin.

• Yeni aboneliklerin gereksinimlerini tanımlarken 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ğlar ve bu da endişelerin net bir şekilde ayrılmasına olanak tanır. Geliştirme, test ve üretim ortamları gibi çeşitli 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 iş yükleri gibi güvenli iş yükleri genellikle uyumluluk elde etmek 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: Abonelikler arasında sanal ağları paylaşamazsınız, ancak bunları sanal ağ eşleme veya ExpressRoute gibi farklı teknolojilerle bağlayabilirsiniz. Yeni bir aboneliğe ihtiyacınız olup olmadığını karar verirseniz, 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. Aynı ilke kümesine ve Azure rol atamalarına sahip aboneliklerin aynı yönetim grubundan geldiğinden emin olmak için abonelikleri gruplandırın.

• Azure İzleyici Günlükleri çalışma alanları ve Otomasyon 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.

• Sanal WAN merkezi, özel 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 modelinden 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ü oluşumu değiştikçe, sabit bir mevcut 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ğinde birlikte bulunabilirken, bazıları da kendi aboneliğini gerektirebilir.

  Daha fazla bilgi için bkz . Geliştirme/test/üretim iş yükü giriş bölgelerini işleme.

Birden çok bölge önerisi

• Her bölge için yalnızca bölgeye özgü idare ve yönetim gereksinimleriniz varsa (örneğin, veri hakimiyeti veya kota sınırlarının ötesinde ölçeklendirme) ek abonelikler oluşturun.

• Ölçeklendirme birden çok bölgeye yayılan bir coğrafi olağanüstü durum kurtarma ortamı için sorun değilse, birincil ve ikincil bölge kaynakları için aynı aboneliği kullanın. İş sürekliliği ve olağanüstü durum kurtarma (BCDR) stratejisine ve benimsediğiniz araçlara bağlı olarak bazı Azure hizmetlerinin aynı aboneliği kullanması gerekebilir. Dağıtımların bağımsız olarak yönetildiği veya farklı yaşam döngülerine sahip olduğu etkin-etkin bir senaryoda, farklı abonelikler kullanmanızı öneririz.

• Kaynak grubu oluşturduğunuz bölge ve kapsanan kaynakların bölgesi, dayanıklılık ve güvenilirliği etkilemeyecek şekilde eşleşmelidir.

• Tek bir kaynak grubu farklı bölgelerden kaynaklar içermemelidir. Bu yaklaşım kaynak yönetimi ve kullanılabilirlik sorunlarına yol açabilir.

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 ulaşmadan ö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 %90 CPU kullanımı gibi kritik düzeylere yaklaşıyorsa 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

• İstek iş akışı aracılığıyla uygulama ekipleri için abonelik oluşturmayı otomatikleştirmek için abonelik aracı bir süreç oluşturun. Daha fazla bilgi için bkz . Abonelik otomatları.

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 platform operasyon ekibi üyelerini ekleyin.

  • Muaf tutulan kullanıcılar listesine cam kırılan hesaplar ekleyin.

Sonraki adım

İlke temelli korumaları benimseme