Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Landing zone multi-akun tunggal vs. Beberapa landing zone multi-akun FAQs
Beberapa pertanyaan umum ketika memilih untuk mengatur satu landing zone multi-akun atau beberapa zona pendaratan multi-akun:
T1: Dapatkah saya memulai dengan landing zone multi-akun tunggal dan pindah ke beberapa landing zone multi-akun, jika ada batasan akun atau kendala bisnis yang ditemui?
A: Ya. Anda dapat memilih untuk mengatur landing zone multi-akun lain pada waktu tertentu:
Akun pembayar tagihan baru akan diminta untuk disiapkan (saat ini AWS tidak mendukung akun multi-pembayar dalam satu organisasi AWS).
Pembuatan basis Zona Pendaratan Multi-Akun membutuhkan waktu tunggu hingga 2 minggu setelah kuesioner landing zone multi-akun diisi.
Setiap landing zone multi-akun berarti penambahan biaya operasional ~ 3K USD/bulan.
Integrasi N/W, AD, DNS, dan SSO akan diperlukan untuk membangun MALZ baru.
Setiap Instans Cadangan (RIs), paket Penghematan Biaya akan diperlukan untuk disiapkan untuk landing zone multi-akun baru (RIs tidak dapat ditransfer).
AMS multi-account landing zone tidak mendukung migrasi akun di seluruh akun landing zone multi-akun; misalnya, di AWS Orgs. Namun, untuk memindahkan aplikasi dari satu akun ke akun lain dimungkinkan menggunakan metode migrasi standar.
T2: Apa pendekatan AMS terhadap MALZ updates/changes terhadap underlying/shared infrastruktur dan mengukur risiko bagi pelanggan? Berikan rincian tentang jaminan apa yang dibungkus ke dalam proses. Bagaimana Pelanggan merasa nyaman bahwa MALZ tidak updates/changes akan berdampak pada pelanggan? Apakah ada tindakan yang perlu dilakukan Pelanggan untuk mencegah gangguan?
J: AMS mengikuti metodologi perubahan ketat menggunakan alat internal yang memungkinkan kami untuk menentukan, meninjau, menjadwalkan, dan mengeksekusi perubahan pada lingkungan pelanggan.
Proses untuk merilis pembaruan memberlakukan tinjauan kode, pengujian integrasi, penerapan di lingkungan gamma dan beta, serta waktu pemanggangan dan pengujian tambahan di lingkungan beta dan gamma sebelum dirilis ke lingkungan pelanggan. Semua rilis mencakup prosedur rollback dan dipantau secara ketat oleh tim rilis dan tim yang membuat dan meminta perubahan. Ruang lingkup rilis terbatas pada tumpukan yang dimiliki dan disediakan oleh AMS. Rata-rata, kami mengeksekusi setidaknya satu rilis per minggu.
Selain itu:
AMS SLA berlaku. Sesuai deskripsi layanan AMS, setiap insiden yang muncul setelah aktivitas pemeliharaan infra bersama akan mematuhi SLA yang berhak untuk resolusi atau kredit.
Tidak ada tindakan pencegahan khusus yang diperlukan oleh Pelanggan untuk mencegah gangguan pada infrastruktur umum. Pelanggan memiliki izin Hanya Baca di akun AWS Org atau Core OU, sehingga pelanggan tidak dapat membuat perubahan destruktif apa pun pada env inti MALZ. Semua permintaan pelanggan terhadap infrastruktur Inti memerlukan peninjauan dan persetujuan AMS.
Pelanggan dapat menguji perubahan level Org tertentu seperti SCPs/Roles pada level akun non-prod individu sebelum menyebarkan perubahan di level App OU. Ini ada di peta jalan AMS untuk memungkinkan beberapa APP OUs (Q2 2020), yang selanjutnya akan mengurangi risiko dalam membuat beberapa perubahan tingkat ORG. Tim MALZ telah merilis OU terpisah untuk akun “Build Mode”, untuk memastikan pemisahan kepemilikan pelanggan dan kontrol terpisah yang jelas.
Sebagian besar adalah perubahan yang memungkinkan AMS untuk mengoperasikan beban kerja secara efektif dan efisien dan tidak selalu memengaruhi beban kerja pelanggan. Di mana AMS percaya perubahan infra bersama dapat berdampak pada beban kerja pelanggan, mereka kemudian diselaraskan dengan jendela perubahan pelanggan.
Rekomendasi tingkat tinggi, mulailah dengan beberapa zona pendaratan multi-akun jika:
Jika itu membantu Anda mencapai kepatuhan tertentu.
Jika Anda perlu menggunakan Multi-Region.
Jika Anda memiliki on-prem ADs dan Networks yang berbeda untuk Prod/Material vs Non-beban kerjaProd/Non-Material workloads, to clearly segregate b/w.
