Azure giriş bölgesi hakkında sık sorulan sorular (SSS)

  • Makale

Bu makalede Azure giriş bölgesi mimarisi hakkında sık sorulan sorular yanıtlanmaktadır.

Azure giriş bölgesi mimarisini uygulama hakkında SSS için bkz. Kurumsal ölçekli uygulama hakkında SSS.

Azure giriş bölgesi hızlandırıcısı nedir?

Azure giriş bölgesi hızlandırıcısı, Azure portal tabanlı bir dağıtım deneyimidir. Azure giriş bölgesi kavramsal mimarisini temel alan, fikir temelli bir uygulama dağıtır.

Microsoft, platform ve uygulama hızlandırıcılarını ve uygulamalarını Azure giriş bölgesi tasarım ilkelerine ve tasarım alanı kılavuzuna uygun olarak etkin bir şekilde geliştirir ve korur.

Önerilen platform ve uygulama giriş bölgeleri hakkında daha fazla bilgi edinmek için Azure giriş bölgelerini dağıtma kılavuzunu gözden geçirin.

Azure giriş bölgeleri dağıtımınızı gereksinimlerinizi karşılayacak şekilde uyarlamayı öğrenmek için bkz . Azure giriş bölgesi mimarisini gereksinimleri karşılayacak şekilde uyarlama

Bahşiş

Hızlandırıcı ve uygulama listesine ekleme isteğinde bulunmak için ALZ deposunda bir GitHub sorunu oluşturun.

Azure giriş bölgesi kavramsal mimarisi nedir?

Azure giriş bölgesi kavramsal mimarisi ölçek ve olgunluk kararlarını temsil eder. Dijital varlıklarının bir parçası olarak Azure'ı benimsemiş olan müşterilerden alınan dersleri ve geri bildirimleri temel alır. Bu kavramsal mimari, kuruluşunuzun giriş bölgesi tasarlamaya ve uygulamaya yönelik bir yön ayarlamanıza yardımcı olabilir.

Giriş bölgesi, Azure giriş bölgesi mimarisi bağlamında Azure'da neyle eşlenmektedir?

Azure giriş bölgesi açısından giriş bölgeleri tek tek Azure abonelikleridir.

İlke temelli idare ne anlama gelir ve nasıl çalışır?

İlke temelli idare , kurumsal ölçekli mimarinin temel tasarım ilkelerinden biridir.

İlke temelli idare, Azure kiracınızda yaygın ve yinelenen işlem görevleri için ihtiyacınız olan süreyi azaltmak için Azure İlkesi kullanmak anlamına gelir. Uyumlu olmayan kaynakların (ilke tanımı tarafından tanımlandığı gibi) oluşturulmasını veya güncelleştirilmesini kısıtlayarak ya da kaynakları dağıtarak ya da bir kaynak oluşturma veya güncelleştirme isteğinin ayarlarını değiştirerek uyumlu olmamasını önlemek için , Deny, DeployIfNotExistsve Modifygibi Appendbirçok Azure İlkesi efektini kullanın. , Disabledve AuditIfNotExistsgibi Auditbazı efektler engellemez veya eylem gerçekleştirmez; yalnızca uyumsuzlukları denetler ve raporlar.

İlke temelli idareye bazı örnekler şunlardır:

  • Deny etki: Alt ağların oluşturulmasını veya güncelleştirilmesini, bunlarla ilişkilendirilmiş Ağ Güvenlik Grubu olmayacak şekilde engeller.

  • DeployIfNotExists etki: Yeni bir abonelik (giriş bölgesi) oluşturulur ve Azure giriş bölgesi dağıtımınızdaki bir yönetim grubuna yerleştirilir. Azure İlkesi abonelikte Bulut için Microsoft Defender (eski adıyla Azure Güvenlik Merkezi) etkinleştirildiğinden emin olur. Ayrıca, Yönetim aboneliğindeki Log Analytics çalışma alanına günlük göndermek için Etkinlik Günlüğü tanılama ayarlarını yapılandırılır.

    Yeni bir abonelik oluşturulduğunda kod veya el ile gerçekleştirilen etkinlikleri yinelemek yerine ilke DeployIfNotExists tanımı bunları sizin için otomatik olarak dağıtır ve yapılandırabilir.

DeployIfNotExists (DINE) ilkelerini kullanamıyor veya henüz kullanıma hazır değilsek ne olur?

DINE ilkelerini "devre dışı bırakmanız" veya ortamınızda bunları zaman içinde benimsemek için üç aşamalı yaklaşımımızı kullanmanız gereken çeşitli aşamalarda ve seçeneklerde yol gösteren ayrılmış bir sayfamız var.

İlke temelli korumaları benimseme kılavuzuna bakın

İş yüklerini dağıtmak için Azure İlkesi mi kullanmalıyız?

Kısacası, hayır. İş yüklerinizi ve giriş bölgelerinizi denetlemek, yönetmek ve uyumlu tutmak için Azure İlkesi kullanın. tüm iş yüklerini ve diğer araçları dağıtmak için tasarlanmamıştır. İş yükünüzü dağıtmak ve yönetmek ve ihtiyacınız olan özerkliği elde etmek için Azure portalını veya kod olarak altyapı tekliflerini (ARM Şablonları, Bicep, Terraform) kullanın.

Terraform için Bulut Benimseme Çerçevesi Giriş bölgeleri (aztfmod) nedir?

Bulut Benimseme Çerçevesi giriş bölgeleri açık kaynak projesi (OSS) (aztfmod olarak da bilinir), Azure giriş bölgesi çekirdek ekibinin ve Azure GitHub kuruluşunun dışında sahip olunan ve bakımı yapılan topluluk odaklı bir projedir. Kuruluşunuz bu işletim sistemi projesini kullanmayı tercih ederse, gitHub aracılığıyla topluluk çabası tarafından yönlendirildiğinden, sağlanan desteğe dikkat edilmelidir.

Giriş bölgelerimizde zaten kaynaklarımız varsa ve daha sonra bunları kapsamına dahil eden bir Azure İlkesi tanımı atadıysak ne olur?

Aşağıdaki belge bölümlerini gözden geçirin:

Azure giriş bölgesi mimarisinde "geliştirme/test/üretim" iş yükü giriş bölgelerini nasıl işleyebiliriz?

Daha fazla bilgi için bkz . Azure giriş bölgelerinde uygulama geliştirme ortamlarını yönetme.

Azure giriş bölgesi hızlandırıcısı dağıtımı sırasında azure bölgelerini neden belirtmemiz isteniyor ve bunlar ne için kullanılıyor?

Azure giriş bölgesi hızlandırıcısı portal tabanlı deneyimi kullanarak Azure giriş bölgesi mimarisini dağıttığınızda, dağıtım için bir Azure bölgesi seçin. İlk sekme olan Dağıtım konumu, dağıtım verilerinin nerede depolandığını belirler. Daha fazla bilgi için bkz . ARM şablonlarıyla kiracı dağıtımları. Giriş bölgesinin bazı bölümleri genel olarak dağıtılır, ancak dağıtım meta verileri bölgesel meta veri deposunda izlenir. Dağıtımlarıyla ilgili meta veriler, Dağıtım konumu sekmesinde seçilen bölgede depolanır.

Dağıtım konumu sekmesindeki bölge seçici, gerekirse Log Analytics çalışma alanı ve otomasyon hesabı gibi bölgeye özgü kaynakların depolanması gereken Azure bölgesini seçmek için de kullanılır.

Ağ topolojisi ve bağlantı sekmesinde bir ağ topolojisi dağıtırsanız, ağ kaynaklarını dağıtmak için bir Azure bölgesi seçmeniz gerekir. Bu bölge, Dağıtım konumu sekmesinde seçilen bölgeden farklı olabilir.

Giriş bölgesi kaynaklarının kullandığı bölgeler hakkında daha fazla bilgi için bkz . Giriş bölgesi bölgeleri.

Azure giriş bölgesi mimarisini kullanırken daha fazla Azure bölgesini nasıl etkinleştirebiliriz?

Giriş bölgesine yeni bölgeler eklemeyi veya giriş bölgesi kaynaklarını farklı bir bölgeye taşımayı anlamak için bkz . Giriş bölgesi bölgeleri.

Her seferinde yeni bir Azure Aboneliği mi oluşturmalıyız yoksa Azure Aboneliklerini yeniden mi kullanmalıyız?

Aboneliği yeniden kullanma nedir?

Aboneliğin yeniden kullanılması, mevcut bir aboneliği yeni bir sahipe yeniden verme işlemidir. Aboneliği bilinen bir temiz duruma sıfırlama ve ardından yeni bir sahipe yeniden atama işlemi olmalıdır.

Abonelikleri neden yeniden kullanmayı düşünmeliyim?

Genel olarak, müşterilerin Abonelik Demokratikleştirme tasarım ilkesini benimsemelerini öneririz. Ancak, aboneliği yeniden kullanmanın mümkün olmadığı veya öneril olmadığı belirli durumlar vardır.

Bahşiş

Abonelik Demokratikleştirme tasarım ilkesiyle ilgili YouTube videosunu burada izleyin: Azure Giriş Bölgeleri - Azure'da kaç abonelik kullanmalıyım?

Aşağıdaki koşullardan birini karşılıyorsanız aboneliği yeniden kullanmayı düşünmelisiniz:

  • Bir Kurumsal Anlaşma (EA) var ve silinen abonelikler dahil olmak üzere tek bir EA Hesabı Sahibi Hesabında (ödeme hesabı) 5.000'den fazla abonelik oluşturmayı planlıyorsunuz.
  • Microsoft Müşteri Sözleşmesi (MCA) veya Microsoft İş Ortağı Sözleşmesi MPA'nız var ve 5.000'den fazla etkin aboneliğiniz olmasını planlıyorsunuz
  • Kullandıkça öde müşterisisiniz
  • Microsoft Azure Sponsorluğu kullanıyorsunuz
  • Yaygın olarak şunu oluşturursunuz:
    1. Kısa ömürlü laboratuvar veya korumalı alan ortamları
    2. Müşteri tanıtım/deneme erişimi için bağımsız yazılım satıcıları (ISV) dahil olmak üzere kavram kanıtı (POC) veya en düşük uygulanabilir ürünler (MVP) için tanıtım ortamları
    3. MSP'ler/Eğitmenin öğrenci ortamları gibi eğitim ortamları

Abonelikleri yeniden kullanmak Nasıl yaparım??

Yukarıdaki senaryolardan veya önemli noktalardan biriyle eşleşiyorsa, mevcut kullanımdan kaldırılmış veya kullanılmayan abonelikleri yeniden kullanmayı ve bunları yeni bir sahipe ve amaca yeniden atamayı düşünebilirsiniz.

Eski aboneliği temizleme

Yeniden kullanmak için önce eski aboneliği temizlemeniz gerekir. Yeniden kullanıma hazır olmadan önce abonelikte aşağıdaki eylemleri gerçekleştirmeniz gerekir:

  • Kaynak Gruplarını ve kapsanan kaynakları kaldırın.
  • Abonelik kapsamında Privileged Identity Management (PIM) Rol Atamaları da dahil olmak üzere Rol Atamalarını kaldırın.
  • Abonelik kapsamındaki Özel Rol Tabanlı Erişim Denetimi (RBAC) Tanımlarını kaldırın.
  • Abonelik kapsamında İlke Tanımlarını, Girişimleri, Atamaları ve Muafiyetleri kaldırın.
  • Abonelik kapsamındaki dağıtımları kaldırın.
  • Abonelik kapsamındaki etiketleri kaldırın.
  • Abonelik kapsamındaki tüm Kaynak Kilitlerini kaldırın.
  • Abonelik kapsamındaki tüm Microsoft Maliyet Yönetimi bütçelerini kaldırın.
  • Kuruluş gereksinimleri bu günlüklerin ücretli katmanlara ayarlanmasını zorunlu tutmadığı sürece Bulut için Microsoft Defender planlarını Ücretsiz Katmanlara sıfırlayın. Normalde bu gereksinimleri Azure İlkesi aracılığıyla uygularsınız.
  • Kuruluş gereksinimleri bir abonelik etkinken bu günlüklerin iletilmesi gerekmediği sürece Log Analytics Çalışma Alanları, Event Hubs, Depolama Hesabı veya diğer desteklenen hedeflere abonelik etkinlik günlüklerini (tanılama ayarları) iletmeyi kaldırın.
  • Abonelik kapsamındaki tüm Azure Lighthouse Temsilcilerini kaldırın.
  • Abonelikten tüm gizli kaynakları kaldırın.

Bahşiş

Abonelik kapsamının kullanılması Get-AzResource veya az resource list -o table hedeflenmesi, yeniden atamadan önce kaldırılacak gizli veya kalan kaynakları bulmanıza yardımcı olur.

Aboneliği yeniden atama

Aboneliği temizledikten sonra aboneliği yeniden atayabilirsiniz. Yeniden atama işleminin bir parçası olarak gerçekleştirmek isteyebileceğiniz bazı yaygın etkinlikler şunlardır:

  • Abonelikte yeni etiketler ekleyin ve bunlar için değerler ayarlayın.
  • Yeni sahipler için abonelik kapsamına yeni Rol Atamaları veya Privileged Identity Management (PIM) Rol Atamaları ekleyin. Bu atamalar genellikle kişiler yerine Microsoft Entra gruplarına yapılır.
  • aboneliği, idare gereksinimlerine göre istediğiniz Yönetim Grubuna yerleştirin.
  • Yeni Microsoft Maliyet Yönetimi bütçeleri oluşturun ve eşikler karşılandığında yeni sahiplere uyarılar ayarlayın.
  • Bulut için Microsoft Defender planlarını istenen Katmanlara ayarlayın. Doğru Yönetim Grubuna yerleştirildikten sonra Azure İlkesi aracılığıyla bu ayarı zorunlu kılmanız gerekir.
  • Log Analytics Çalışma Alanları, Event Hubs, Depolama Hesabı veya desteklenen diğer hedeflere abonelik etkinlik günlüklerini (tanılama ayarları) iletmeyi yapılandırın. Doğru Yönetim Grubuna yerleştirildikten sonra Azure İlkesi aracılığıyla bu ayarı zorunlu kılmanız gerekir.

Bağımsız giriş bölgesi, gelişmiş egemenlik denetimlerine ihtiyaç duyan kamu sektörü müşterilerine yönelik, Egemenlik için Microsoft Bulut'un bir bileşenidir. Bağımsız giriş bölgesi, Azure giriş bölgesi kavramsal mimarisinin uyarlanmış bir sürümü olarak hizmet yerleşimi, müşteri tarafından yönetilen anahtarlar, Azure Özel Bağlantı ve gizli bilgi işlem gibi Azure özelliklerini uyumlu hale getirmenizi sağlar. Bu hizalama sayesinde bağımsız giriş bölgesi, verilerin ve iş yüklerinin varsayılan olarak şifreleme ve tehditlere karşı koruma sunduğu bir bulut mimarisi oluşturur.

Dekont

Egemenlik için Microsoft Bulut, egemenlik gereksinimleri olan kamu kuruluşlarına yöneliktir. Bağımsızlık için Microsoft Bulutu özelliklerine ihtiyacınız olup olmadığını dikkatli bir şekilde düşünmeli ve ancak o zaman bağımsız giriş bölgesi mimarisini benimsemeyi düşünmelisiniz.

Bağımsız giriş bölgesi hakkında daha fazla bilgi için bkz . Azure giriş bölgeleri için egemenlik konuları.