Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Mode dan aplikasi AMS atau beban kerja
Pertimbangkan persyaratan operasional dan tata kelola untuk aplikasi Anda saat memilih mode yang tepat, baik dengan meminta akun aplikasi baru atau menghosting aplikasi di akun aplikasi yang ada. Pemilihan mode AMS yang sesuai untuk setiap aplikasi atau beban kerja tergantung pada faktor-faktor berikut:
Jenis fungsi siklus hidup SDLC yang akan disediakan lingkungan (misalnya, kotak pasir dengan perubahan yang tidak dimoderasi, UAT dengan beberapa perubahan yang sering, produksi dengan perubahan minimal dan sangat diatur)
Kebijakan tata kelola yang diperlukan (ditegakkan melalui SCPs di tingkat OU)
Model Operasional (jika Anda ingin memiliki tanggung jawab operasional atau ingin mengalihdayakannya ke AMS)
Hasil bisnis yang diinginkan, seperti waktu untuk beroperasi di cloud, dan biaya operasi.
catatan
Untuk deskripsi jenis mode per layanan AMS, lihat Jenis mode dan akun di AMS.
Untuk kasus penggunaan dunia nyata dari berbagai mode, lihat Kasus penggunaan dunia nyata untuk mode AMS
Tabel berikut menguraikan pertimbangan utama bagi pemilik aplikasi untuk membantu memutuskan mode AMS yang paling sesuai. Pemilik aplikasi harus menyertakan fase penilaian sebelum migrasi aplikasi untuk sepenuhnya memahami mode mana yang berlaku untuk aplikasi spesifik mereka. Contoh: Untuk aplikasi berbasis layanan cloud-native atau arsitektur tanpa server, opsi terbaik adalah mulai membangun dan mengulangi dalam mode Pengembang dan menerapkan Infrastruktur akhir sebagai Kode menggunakan mode AMS Managed — SSP. Dalam hal ini, pemfaktoran ulang ringan mungkin diperlukan untuk memastikan bahwa CloudFormation templat apa pun yang dibuat untuk penerapan otomatis memenuhi pedoman konsumsi yang ditetapkan oleh AMS. Selain itu, izin IAM apa pun harus disetujui oleh AMS Security untuk memastikan mereka mengikuti model hak istimewa paling sedikit.
Mode AMS yang dipilih untuk meng-host aplikasi, dapat membantu Anda membangun model operasi cloud yang Anda inginkan.
catatan
Lebih dari satu model operasi cloud dapat ada dalam satu Zona Pendaratan Terkelola AMS berdasarkan berbagai mode AMS yang dipilih untuk meng-host aplikasi.
| Masalah keputusan | Mode CM standar/OOD * | AWS Service Catalog | Mode Ubah Langsung | Penyediaan layanan mandiri | Mode pengembang | Pelanggan Dikelola |
|---|---|---|---|---|---|---|
| Kesiapan operasional | ||||||
| Logging, Monitoring dan Manajemen Acara | AMS bertanggung jawab atas semua infrastruktur yang dikelola | Pelanggan yang bertanggung jawab atas Layanan Penyediaan Layanan Mandiri (SSP) | Pelanggan bertanggung jawab atas sumber daya yang disediakan menggunakan peran IAM pengembang di luar sistem AMS CM | Pelanggan yang bertanggung jawab | ||
| Manajemen Kontinuitas | Tanggung jawab AMS untuk melaksanakan rencana cadangan yang dipilih oleh pelanggan | Pelanggan yang bertanggung jawab atas Layanan Penyediaan Layanan Mandiri (SSP) | Pelanggan bertanggung jawab atas sumber daya yang disediakan menggunakan peran IAM pengembang di luar sistem AMS CM | |||
| Manajemen Akses Tingkat Instans | Dikelola AMS melalui kepercayaan AD satu arah dengan domain on-prem. Memerlukan infrastruktur terkelola untuk bergabung dengan domain AMS | Tidak berlaku | Pelanggan bertanggung jawab atas sumber daya yang disediakan menggunakan peran IAM pengembang di luar sistem AMS CM | |||
| Manajemen Keamanan dan Manajemen Akses Tingkat Akun | Tanggung jawab AMS untuk semua akun terkelola | AMS bertanggung jawab atas semua akun yang dikelola | Pelanggan bertanggung jawab atas sumber daya yang disediakan menggunakan peran IAM pengembang di luar sistem AMS CM | |||
| Manajemen Patch | Tanggung jawab AMS untuk semua akun terkelola | Pelanggan yang bertanggung jawab atas Layanan Penyediaan Layanan Mandiri (SSP) | Pelanggan bertanggung jawab atas sumber daya yang disediakan menggunakan peran IAM pengembang di luar sistem AMS CM | |||
| Manajemen Perubahan | Tanggung jawab AMS untuk semua akun terkelola | Pelanggan yang bertanggung jawab atas Layanan Penyediaan Layanan Mandiri (SSP) | Pelanggan bertanggung jawab atas sumber daya yang disediakan menggunakan peran IAM pengembang di luar sistem AMS CM | |||
| Manajemen Penyediaan | Preskriptif dan standar untuk opsi penyediaan yang ditawarkan di AMS | Fleksibilitas untuk langsung menggunakan AWS service API untuk AWS Service Catalog mengikuti standar preskriptif AMS | Fleksibilitas untuk langsung menggunakan AWS service API mengikuti standar preskriptif AMS | Fleksibilitas untuk langsung menggunakan layanan AWS APIs untuk layanan SSP | Fleksibilitas untuk langsung menggunakan AWS service API untuk penyediaan | |
| Manajemen Insiden dan Audit | Tanggung jawab AMS untuk semua akun terkelola | Pelanggan bertanggung jawab atas sumber daya yang disediakan menggunakan peran IAM pengembang di luar AMS Change Management System | ||||
| GuardRails Infrastruktur Bersama (Jaringan) dan Kerangka Keamanan | Memanfaatkan Akun Inti AMS yang preskriptif dan standar | Memanfaatkan Akun Inti AMS yang fleksibel dan dipesan lebih dahulu | ||||
| Kesiapan aplikasi | ||||||
| Aplikasi refactoring | Diperlukan refactoring ringan | Diperlukan refactoring ringan (jika disediakan menggunakan AMS Standard CM) | Tidak perlu refactoring | |||
| Support untuk layanan AWS | Terbatas pada apa yang didukung oleh AMS | Tidak terbatas | ||||
| Pertimbangan bisnis | ||||||
| Saatnya kesiapan operasional | Tiga sampai enam bulan | 6 bulan+tergantung pada kompetensi operasi aplikasi pelanggan | 6-18 bulan tergantung pada infrastruktur pelanggan dan kompetensi operasi aplikasi | |||
| Biaya | $$$$ | $$$ | $$ | $ | ||
| Contoh aplikasi | Server web dengan tumpukan 3 tingkat, aplikasi dengan kepatuhan dan persyaratan peraturan | Server web menggunakan API Gateway, aplikasi kontainer yang memanfaatkan ECS/EKS | Mengiterasi/mengoptimalkan aplikasi Data Lake yang menggunakan Lambda, Glue, Athena, dll | De-sentralisasi accounts/applications seperti kotak pasir, aplikasi yang dikelola pihak ketiga | ||
* Operations On Demand (OOD) memiliki penawaran untuk pelanggan yang menggunakan mode CM Standar untuk mengelola perubahan mereka melalui sumber daya khusus. Untuk detail selengkapnya, lihat katalog penawaran Operations on Demand dan hubungi manajer pengiriman layanan cloud (CSDM) Anda.
catatan
Perbandingan harga antara mode SSP dan mode Pengembang mengasumsikan bahwa layanan AWS yang sama disediakan.
Membandingkan Mode AMS dengan tujuan bisnis dan TI
Seperti yang ditunjukkan, jika Anda mencari model tata kelola yang sangat terkontrol dan terstandarisasi untuk aplikasi Anda, maka mode Perubahan Standar yang dikelola AMS, AWS Service Catalog, atau Direct Change adalah yang paling cocok. Jika Anda memerlukan model tata kelola yang dipesan lebih dahulu dengan fokus pada inovasi aplikasi tanpa perlu kesiapan operasional, pilih mode Customer Managed. Dengan mode Customer Managed, Anda bisa membutuhkan waktu lebih lama untuk mengoperasionalkan aplikasi Anda karena Anda memikul tanggung jawab untuk menetapkan orang, proses, dan alat untuk mendukung kemampuan operasional seperti Manajemen Insiden, Manajemen Konfigurasi, Manajemen Penyediaan, Manajemen Keamanan, Manajemen Patch, dll.
