Tanya jawab umum (FAQ) zona pendaratan Azure

Artikel ini menjawab pertanyaan umum tentang arsitektur zona pendaratan Azure.

Untuk FAQ tentang menerapkan arsitektur zona pendaratan Azure, lihat TANYA JAWAB UMUM implementasi skala perusahaan.

Apa yang dimaksud dengan akselerator zona pendaratan Azure?

Akselerator zona pendaratan Azure merupakan pengalaman penyebaran berbasis portal Microsoft Azure. Akselerator ini menyebarkan implementasi yang kukuh berdasarkan arsitektur konseptual zona pendaratan Azure.

Manakah akselerator dan implementasi yang direkomendasikan untuk zona pendaratan Azure?

Microsoft secara aktif mengembangkan dan memelihara platform dan akselerator aplikasi dan implementasi selaras dengan prinsip desain zona pendaratan Azure dan panduan area desain.

Tinjau panduan Sebarkan zona pendaratan Azure untuk mempelajari selengkapnya tentang platform dan zona pendaratan aplikasi yang direkomendasikan.

Untuk mempelajari cara menyesuaikan penyebaran zona pendaratan Azure Anda untuk memenuhi kebutuhan Anda, lihat Menyesuaikan arsitektur zona pendaratan Azure untuk memenuhi persyaratan

Tip

Untuk meminta penambahan ke daftar akselerator dan implementasi, ajukan masalah GitHub pada repositori ALZ.

Apa yang dimaksud dengan arsitektur konseptual zona pendaratan Azure?

Arsitektur konseptual zona pendaratan Azure mewakili keputusan skala dan kematangan. Hal ini didasarkan pada pelajaran yang dipetik dan umpan balik dari pelanggan yang telah mengadopsi Azure sebagai bagian dari properti digital mereka. Arsitektur konseptual ini dapat membantu organisasi Anda menetapkan arah untuk merancang dan menerapkan zona pendaratan.

Apa peta zona pendaratan ke di Azure dalam konteks arsitektur zona pendaratan Azure?

Dari sudut pandang zona pendaratan Azure, zona pendaratan adalah langganan Azure individual.

Apa yang dimaksud dengan pemerintahan yang didorong kebijakan, dan bagaimana cara kerjanya?

Pemerintahan yang didorong kebijakan adalah salah satu prinsip desain utama arsitektur skala perusahaan.

Pemerintahan yang didorong kebijakan berarti menggunakan Azure Policy untuk mengurangi waktu yang Anda butuhkan untuk tugas operasional umum dan berulang di seluruh penyewa Azure Anda. Gunakan berbagai efek Azure Policy, seperti Append, Deny, DeployIfNotExists, dan Modify, untuk mencegah ketidakpatuhan dengan membatasi sumber daya yang tidak patuh (sebagaimana didefinisikan oleh definisi kebijakan) agar tidak dibuat atau diperbarui atau dengan menyebarkan sumber daya atau memodifikasi pengaturan pembuatan sumber daya atau permintaan pembaruan untuk membuatnya patuh. Beberapa efek, seperti Audit, Disabled, dan AuditIfNotExists, tidak mencegah atau mengambil tindakan; mereka hanya mengaudit dan melaporkan ketidakpatuhan.

Beberapa contoh pemerintahan yang didorong kebijakan adalah:

• Efek Deny: Mencegah subnet dibuat atau diperbarui agar tidak memiliki Kelompok Keamanan Jaringan yang terkait dengan subnet tersebut.

• DeployIfNotExists efek: Langganan baru (zona pendaratan) dibuat dan ditempatkan ke dalam grup manajemen dalam penyebaran zona pendaratan Azure Anda. Azure Policy memastikan bahwa Microsoft Defender untuk Cloud (sebelumnya dikenal sebagai Azure Security Center) diaktifkan pada langganan. Azure Policy juga mengonfigurasi pengaturan diagnostik untuk Log Aktivitas untuk mengirim log ke ruang kerja Analitik Log di langganan Manajemen.

  Alih-alih mengulangi kode atau aktivitas manual saat langganan baru dibuat, definisi kebijakan DeployIfNotExists secara otomatis menyebarkan dan mengonfigurasinya untuk Anda.

Bagaimana jika kita belum dapat atau belum siap untuk menggunakan kebijakan DeployIfNotExists (DINE)?

Kami memiliki halaman khusus yang menelusuri berbagai fase dan opsi yang Anda miliki untuk "menonaktifkan" kebijakan DINE atau menggunakan pendekatan tiga fase kami untuk mengadopsinya dari waktu ke waktu dalam lingkungan Anda.

Lihat panduan Mengadopsi pagar pembatas yang didorong oleh kebijakan

Haruskah kita menggunakan Azure Policy untuk menyebarkan beban kerja?

Singkatnya, tidak. Gunakan Azure Policy untuk mengontrol, mengatur, dan menjaga kepatuhan beban kerja dan zona pendaratan Anda. Azure Policy tidak dirancang untuk menyebarkan seluruh beban kerja dan alat lainnya. Gunakan penawaran portal Microsoft Azure atau infrastruktur sebagai kode (Templat ARM, Bicep, Terraform) untuk menyebarkan dan mengelola beban kerja Anda dan mendapatkan otonomi yang Anda butuhkan.

Apa itu zona Cloud Adoption Framework Landing untuk Terraform (aztfmod)?

Zona pendaratan Cloud Adoption Framework sumber terbuka project (OSS) (juga dikenal sebagai aztfmod) adalah proyek berbasis komunitas yang dimiliki dan dikelola di luar tim inti zona pendaratan Azure dan organisasi Azure GitHub. Jika organisasi Anda memilih untuk menggunakan proyek OSS ini, pertimbangan harus diberikan kepada dukungan yang tersedia karena ini didorong oleh upaya komunitas melalui GitHub.

Bagaimana jika kita sudah memiliki sumber daya di zona pendaratan dan kemudian menetapkan definisi Azure Policy yang menyertakannya dalam cakupannya?

Tinjau bagian dokumentasi berikut:

• Transisi lingkungan Azure yang ada ke arsitektur konseptual zona arahan Azure - bagian "Kebijakan"
• Mulai cepat: Membuat penetapan kebijakan untuk mengidentifikasi sumber daya yang tidak patuh - bagian "Identifikasi sumber daya yang tidak patuh"

Bagaimana cara menangani zona pendaratan beban kerja "dev/test/production" di arsitektur zona pendaratan Azure?

Untuk informasi selengkapnya, lihat Mengelola lingkungan pengembangan aplikasi di zona pendaratan Azure.

Mengapa kami diminta untuk menentukan wilayah Azure selama penerapan akselerator zona pendaratan Azure dan apa kegunaan mereka?

Saat Anda menyebarkan arsitektur zona pendaratan Azure dengan menggunakan pengalaman berbasis portal akselerator zona pendaratan Azure, pilih wilayah Azure untuk disebarkan. Tab pertama, Lokasi penyebaran, menentukan tempat data penyebaran disimpan. Untuk informasi selengkapnya, lihat Penyebaran penyewa dengan templat ARM. Beberapa bagian dari zona pendaratan disebarkan secara global tetapi metadata penyebarannya dilacak di penyimpanan metadata regional. Metadata mengenai penyebaran mereka disimpan di wilayah yang dipilih pada tab Lokasi penyebaran.

Pemilih wilayah pada tab Lokasi penyebaran juga digunakan untuk memilih wilayah Azure mana sumber daya khusus wilayah mana yang harus disimpan, seperti ruang kerja Analitik Log dan akun otomatisasi, jika diperlukan.

Jika Anda menyebarkan topologi jaringan pada tab Topologi jaringan dan konektivitas , Anda perlu memilih wilayah Azure untuk menyebarkan sumber daya jaringan. Wilayah ini bisa berbeda dari wilayah yang dipilih pada tab Lokasi penyebaran.

Untuk informasi selengkapnya tentang wilayah yang digunakan sumber daya zona pendaratan, lihat Wilayah zona pendaratan.

Bagaimana cara mengaktifkan lebih banyak wilayah Azure saat menggunakan arsitektur zona pendaratan Azure?

Untuk memahami cara menambahkan wilayah baru ke zona pendaratan, atau cara memindahkan sumber daya zona pendaratan ke wilayah yang berbeda, lihat Wilayah zona pendaratan.

Haruskah kita membuat Langganan Azure baru setiap kali atau harus menggunakan kembali Langganan Azure?

Apa itu penggunaan kembali langganan?

Penggunaan kembali langganan adalah proses penerbitan kembali langganan yang sudah ada ke pemilik baru. Harus ada proses untuk mengatur ulang langganan ke status bersih yang diketahui dan kemudian ditetapkan kembali ke pemilik baru.

Mengapa saya harus mempertimbangkan untuk menggunakan kembali langganan?

Secara umum, sebaiknya pelanggan mengadopsi prinsip desain Demokratisasi Langganan. Namun, ada keadaan khusus di mana penggunaan kembali langganan tidak dimungkinkan atau disarankan.

Tip

Tonton video YouTube tentang prinsip desain Demokratisasi Langganan di sini: Zona Pendaratan Azure - Berapa banyak langganan yang harus saya gunakan di Azure?

Anda harus mempertimbangkan penggunaan kembali langganan jika Anda memenuhi salah satu keadaan berikut:

• Anda memiliki Perjanjian Enterprise (EA) dan berencana untuk membuat lebih dari 5.000 langganan pada satu Akun Pemilik Akun EA (akun penagihan), termasuk langganan yang dihapus.
• Anda memiliki Perjanjian Pelanggan Microsoft (MCA) atau Perjanjian Mitra Microsoft MPA dan berencana untuk memiliki lebih dari 5.000 langganan aktif
• Anda adalah pelanggan bayar sesuai penggunaan
• Anda menggunakan Microsoft Azure Sponsorship
• Anda biasanya membuat:
  1. Lingkungan lab atau kotak pasir Ephemeral
  2. Lingkungan demo untuk proofs-of-concept (POC) atau produk layak minimum (MVP), termasuk vendor perangkat lunak independen (ISV) untuk akses demo/uji coba pelanggan
  3. Lingkungan pelatihan, seperti lingkungan pelajar MSP/Pelatih

Bagaimana cara menggunakan kembali langganan?

Jika Anda mencocokkan salah satu skenario atau pertimbangan di atas, maka Anda mungkin perlu mempertimbangkan untuk menggunakan kembali langganan yang sudah ada yang dinonaktifkan atau tidak digunakan dan menetapkannya kembali ke pemilik dan tujuan baru.

Membersihkan langganan lama

Anda harus terlebih dahulu membersihkan langganan lama untuk digunakan kembali. Anda perlu melakukan tindakan berikut pada langganan sebelum siap digunakan kembali:

• Hapus Grup Sumber Daya dan sumber daya yang terkandung.
• Hapus Penetapan Peran, termasuk Penetapan Peran Privileged Identity Management (PIM), pada cakupan langganan.
• Hapus Definisi Kontrol Akses Berbasis Peran Kustom (RBAC), pada cakupan langganan.
• Hapus Definisi Kebijakan, Inisiatif, Penugasan, dan Pengecualian di cakupan langganan.
• Hapus penyebaran di cakupan langganan.
• Hapus tag di cakupan langganan.
• Hapus Kunci Sumber Daya apa pun di cakupan langganan.
• Hapus anggaran Microsoft Cost Management apa pun di cakupan langganan.
• Atur ulang paket Microsoft Defender untuk Cloud ke Tingkat Gratis kecuali persyaratan organisasi mengamanatkan log ini diatur ke tingkat berbayar. Anda biasanya memberlakukan persyaratan ini melalui Azure Policy.
• Hapus penerusan log aktivitas langganan (pengaturan diagnostik) ke Ruang Kerja Analitik Log, Azure Event Hubs, Akun Penyimpanan, atau tujuan lain yang didukung kecuali persyaratan organisasi mengamanatkan penerusan log ini saat langganan aktif.
• Hapus Delegasi Azure Lighthouse apa pun di cakupan langganan.
• Hapus sumber daya tersembunyi apa pun dari langganan.

Tip

Menggunakan Get-AzResource atau az resource list -o table ditargetkan pada cakupan langganan akan membantu Anda menemukan sumber daya tersembunyi atau sumber daya yang tersisa untuk dihapus sebelum menetapkan ulang.

Menetapkan ulang langganan

Anda dapat menetapkan ulang langganan setelah membersihkan langganan. Berikut adalah beberapa aktivitas umum yang mungkin ingin Anda lakukan sebagai bagian dari proses penugasan ulang:

• Tambahkan tag baru dan tetapkan nilai untuk mereka pada langganan.
• Tambahkan Penetapan Peran baru, atau Penetapan Peran Privileged Identity Management (PIM), pada cakupan langganan untuk pemilik baru. Biasanya penugasan ini adalah untuk grup Microsoft Entra alih-alih individu.
• Tempatkan langganan ke dalam Grup Manajemen yang diinginkan berdasarkan persyaratan tata kelolanya.
• Buat anggaran Microsoft Cost Management baru dan atur pemberitahuan ke pemilik baru saat ambang terpenuhi.
• Atur paket Microsoft Defender untuk Cloud ke Tingkat yang diinginkan. Anda harus menerapkan pengaturan ini melalui Azure Policy setelah ditempatkan ke dalam Grup Manajemen yang benar.
• Mengonfigurasi penerusan log aktivitas langganan (pengaturan diagnostik) ke Ruang Kerja Analitik Log, Azure Event Hubs, Akun Penyimpanan, atau tujuan lain yang didukung. Anda harus menerapkan pengaturan ini melalui Azure Policy setelah ditempatkan ke dalam Grup Manajemen yang benar.

Apa itu zona pendaratan berdaulat dan bagaimana terkait dengan arsitektur zona pendaratan Azure?

Zona pendaratan berdaulat adalah komponen Microsoft Cloud untuk Kedaulatan yang ditujukan untuk pelanggan sektor publik yang membutuhkan kontrol kedaulatan lanjutan. Sebagai versi yang disesuaikan dari arsitektur konseptual zona pendaratan Azure, zona pendaratan berdaulat menyelaraskan kemampuan Azure seperti residensi layanan, kunci yang dikelola pelanggan, Azure Private Link, dan komputasi rahasia. Melalui keselarasan ini, zona pendaratan berdaulat menciptakan arsitektur cloud di mana data dan beban kerja menawarkan enkripsi dan perlindungan dari ancaman secara default.

Catatan

Microsoft Cloud for Sovereignty berorientasi pada organisasi pemerintah dengan kebutuhan kedaulatan. Anda harus mempertimbangkan dengan cermat apakah Anda memerlukan kemampuan Microsoft Cloud for Sovereignty, dan hanya kemudian mempertimbangkan untuk mengadopsi arsitektur zona pendaratan berdaulat.

Untuk informasi selengkapnya tentang zona pendaratan berdaulat, lihat Pertimbangan kedaulatan untuk zona pendaratan Azure.