Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Optimalisasi biaya
Optimalisasi biaya berfokus pada menghindari biaya yang tidak dibutuhkan. Topik utama termasuk memahami dan mengendalikan di mana uang dihabiskan, dan memilih jumlah jenis sumber daya yang paling tepat dan benar. Analisis pengeluaran dari waktu ke waktu dan penskalaan untuk memenuhi kebutuhan bisnis. Sumber daya AppStream 2.0 berikut dikenakan pay-as-you-go biaya:
-
Instans armada yang Selalu Aktif
-
Instans armada On-Demand
-
On-Demand menghentikan biaya instans
-
Instans image builder
-
Biaya pengguna
Untuk informasi harga saat ini, lihat situs AWS web untuk harga Amazon AppStream 2.0
Merancang penerapan AppStream 2.0 yang hemat biaya
Langkah pertama dalam perencanaan dan desain penerapan AppStream 2.0 adalah menggunakan alat penetapan harga sederhana
Pelanggan menyukai model harga AppStream 2.0 yang hanya membayar untuk contoh yang mereka sediakan untuk memenuhi kebutuhan streaming pengguna mereka. Model ini berbeda dari lingkungan streaming aplikasi yang ada. Ini biasanya didasarkan pada penyediaan untuk kapasitas puncak, bahkan pada malam hari, akhir pekan, dan hari libur, ketika beban lebih rendah. Alat Harga Amazon AppStream 2.0 hanya memberikan perkiraan biaya AWS Anda yang terkait dengan penggunaan AppStream 2.0, dan tidak termasuk pajak apa pun yang mungkin berlaku. Biaya aktual Anda bergantung pada berbagai faktor, termasuk penggunaan layanan AWS Anda yang sebenarnya.
Alat Harga AppStream 2.0 disediakan sebagai spreadsheet Microsoft Excel atau OpenOffice Calc yang memungkinkan Anda memasukkan informasi dasar tentang armada Anda, kemudian memberikan perkiraan biaya untuk lingkungan AppStream 2.0 untuk armada sesuai permintaan dan selalu aktif berdasarkan pola penggunaan Anda. Anda dapat mensimulasikan biaya berdasarkan tren penggunaan historis atau yang diantisipasi. Armada elastis membebaskan administrator dari kebutuhan untuk memprediksi penggunaan, membuat, memelihara kebijakan penskalaan dan gambar dengan memiliki fitur-fitur ini bawaan. Armada elastis dan instans yang menjalankan Amazon Linux 2 (semua jenis armada) ditagih untuk durasi sesi streaming, dalam hitungan detik, dengan minimal 15 menit.
Mengoptimalkan biaya dengan pilihan jenis instans
Untuk instance armada dan pembuat gambar, ada berbagai jenis dan jenis instans berbeda yang tersedia yang Anda pilih untuk aplikasi Anda.
Pengujian pengguna akhir — Langkah selanjutnya adalah meluncurkan armada AppStream 2.0 ke sekelompok pengguna pilot untuk pengujian guna memvalidasi pilihan jenis instans kami. Penting untuk meminta pengguna pilot untuk menguji semua alur kerja reguler dan berat mereka untuk menangkap metrik di sekitar memori, CPU, dan grafik sehingga Anda dapat menangkap metrik kinerja dasar. Grup percontohan harus berisi berbagai peran pengguna yang menggunakan aplikasi untuk memastikan Anda mengujinya dari beberapa pengalaman pengguna. Pengujian penerimaan pengguna memungkinkan Anda mengumpulkan umpan balik tentang pengalaman sesi streaming. Saat membuat atau memperbarui tumpukan, ada opsi untuk menggunakan URL umpan balik khusus. Pengguna diarahkan ke URL ini setelah mereka memilih tautan Kirim Umpan Balik untuk mengirimkan umpan balik tentang pengalaman streaming aplikasi mereka. Jika ada hambatan kinerja, gunakan metrik kinerja Windows untuk menganalisis kendala sumber daya. Misalnya, jika tipe instance armada saat ini stream.standard.medium menunjukkan batasan sumber daya, maka tingkatkan jenis instance ke stream.standard.large. Sebaliknya, jika metrik kinerja menunjukkan tingkat penggunaan sumber daya yang kurang tinggi, pertimbangkan untuk menurunkan jenis instans.
Mengoptimalkan biaya dengan pilihan tipe armada
Saat membuat armada AppStream 2.0 baru, pengembang harus memilih jenis armada Always- On atau On-Demand. Saat memilih jenis instans dari perspektif harga, penting untuk memahami bagaimana AppStream 2.0 mengelola instance armada. Untuk armada Always-On, instance armada tetap dalam kondisi berjalan. Oleh karena itu, ketika pengguna mencoba melakukan streaming sesi, instance armada selalu siap untuk memulai sesi streaming.
Untuk armada On-Demand, setelah instance armada diluncurkan, mereka disimpan dalam keadaan berhenti. Biaya instans berhenti lebih rendah daripada biaya instans berjalan, yang dapat membantu mengurangi biaya. Instance armada On-Demand harus dimulai dari status berhenti. Pengguna harus menunggu sekitar dua menit agar sesi streaming mereka tersedia.
Armada elastis adalah kandidat yang baik untuk aplikasi yang mandiri dan dapat diinstal ke hard drive virtual yang disimpan dalam bucket Amazon Simple Storage Service (Amazon S3). Armada elastis selanjutnya dapat mengurangi biaya untuk beberapa kasus penggunaan karena tagihan per detik yang dibebankan hanya selama durasi streaming. Tarif adalah fungsi dari jenis dan ukuran instans dan sistem operasi yang Anda pilih saat membuat armada.
Jika pengguna akhir membutuhkan instance armada selama jam kerja, lebih baik menyimpan sesi streaming yang sama. Ini karena instans armada dibebankan per jam, dan setiap kali sesi streaming baru dimulai, itu menimbulkan biaya instans armada lain.
Tabel 10 - AppStream 2.0 perbandingan tipe armada
Jenis armada |
Keuntungan |
Pertimbangan |
---|---|---|
Selalu Aktif |
Kurang waktu tunggu untuk sesi streaming |
Pengguna membayar biaya instans per jam karena tidak ada opsi untuk menyimpan instance dalam status berhenti. |
Sesuai Permintaan |
Penghematan biaya karena instans tetap dalam keadaan berhenti |
Waktu tunggu yang lebih lama untuk sesi streaming |
Elastis |
Penagihan per detik mungkin berguna untuk kasus penggunaan yang memiliki pola penggunaan sporadis untuk aplikasi yang dapat diinstal pada hard disk virtual |
Karena ukuran hard disk virtual aplikasi menjadi lebih besar, waktu yang dibutuhkan untuk memasangnya ke instance streaming bisa lama |
AppStream 2.0 memantau pemanfaatan armada Anda dan melakukan penyesuaian otomatis pada kapasitas armada untuk memenuhi permintaan pengguna Anda dengan biaya serendah mungkin. Penyesuaian kapasitas dibuat berdasarkan kebijakan penskalaan yang Anda tentukan, baik berdasarkan pemanfaatan saat ini atau berdasarkan jadwal. Tinjau metrik penggunaan armada secara berkala untuk memvalidasi bahwa kebijakan penskalaan armada tidak memiliki kapasitas cadangan tingkat tinggi.
Kebijakan penskalaan
Fleet Auto Scaling memungkinkan Anda untuk mengoptimalkan sumber daya armada dengan tidak harus melakukan terlalu banyak sumber daya menunggu pengguna untuk login. Administrator dapat menyesuaikan ukuran armada berdasarkan berbagai pemanfaatan agar sesuai dengan permintaan pengguna. Gunakan CloudWatch AppStream 2.0 Fleet Metrics atau alat pemantauan pihak ketiga untuk mempelajari aktivitas pengguna dan mengonfigurasi kebijakan penskalaan untuk memperluas atau mengecilkan armada AppStream 2.0 berdasarkan penggunaan yang diharapkan. Log pengguna adalah mekanisme penting untuk mendapatkan pemahaman tentang penggunaan nyata. Wawasan ini dapat digunakan untuk mengubah ukuran armada secara dinamis berdasarkan Auto Scaling.
Dalam banyak kasus, armada AppStream 2.0 dibuat berdasarkan jumlah maksimum pengguna dan tidak disesuaikan untuk waktu yang berbeda dalam sehari dan minggu seperti malam dan akhir pekan. Sering kali, jumlah pengguna bersamaan dari aplikasi streaming kurang dari jumlah total pengguna terutama ketika pengguna memiliki fleksibilitas untuk bekerja dari jarak jauh. Penting untuk mempertimbangkan faktor-faktor ini saat memproyeksikan pola penggunaan. Melebih-lebihkan menyebabkan penyediaan berlebih dari AppStream 2.0 instans yang mengakibatkan biaya tambahan. Untuk mendapatkan konfigurasi yang optimal, Anda mungkin perlu menggabungkan satu atau beberapa kebijakan penskalaan terjadwal dengan kebijakan skala keluar.
Untuk mempelajari selengkapnya tentang penerapan Kebijakan Penskalaan, tinjau Penskalaan armada Amazon AppStream 2.0 Anda
Biaya pengguna
Biaya pengguna dibebankan per pengguna, per bulan di masing-masing Wilayah AWS tempat pengguna melakukan streaming aplikasi dari AppStream 2.0 instance armada. Alih-alih menghasilkan ID pengguna yang berbeda, memiliki ID pengguna yang konsisten untuk pengguna AppStream 2.0. Biaya pengguna tidak dikenakan biaya saat menghubungkan ke pembuat gambar.
Sekolah, universitas, dan lembaga publik tertentu mungkin memenuhi syarat untuk mengurangi biaya pengguna Microsoft RDS SAL sebesar $0,44 per pengguna per bulan. Untuk persyaratan kualifikasi, lihat Persyaratan dan Dokumen Lisensi Microsoft
Jika Anda memiliki Microsoft License Mobility, Anda mungkin memenuhi syarat untuk membawa Lisensi Akses Klien Microsoft RDS (CAL) Anda sendiri dan menggunakannya dengan Amazon 2.0. AppStream Jika Anda ditanggung oleh lisensi Anda sendiri, Anda tidak akan dikenakan biaya pengguna bulanan. Untuk informasi selengkapnya tentang apakah Anda dapat menggunakan lisensi Microsoft RDS CAL yang ada dengan Amazon AppStream 2.0, lihat panduan Mobilitas AWS Lisensi
Penggunaan Image Builder
AppStream 2.0 Instans Image Builder dikenakan biaya per jam. Biaya instans Image Builder mencakup komputasi, penyimpanan, dan lalu lintas jaringan apa pun yang digunakan oleh protokol streaming. Semua instance Image Builder yang sedang berjalan dikenakan biaya instans berjalan yang berlaku. Biaya ini didasarkan pada jenis dan ukuran instans, bahkan ketika tidak ada administrator yang terhubung.
Sebagai praktik terbaik untuk mengoptimalkan biaya, matikan instance Image Builder saat tidak digunakan. CloudWatch Aturan acara dapat digunakan untuk menjadwalkan pekerjaan sehari-hari, seperti menjalankan fungsi Lambda untuk menghentikan instance pembuat gambar.
Anda dapat menyimpan gambar AppStream 2.0 Anda up-to-date dengan menggunakan pembaruan gambar AppStream 2.0 terkelola. Metode pembaruan ini menyediakan pembaruan sistem operasi Windows terbaru dan pembaruan driver, dan perangkat lunak agen AppStream 2.0 terbaru. Saat menggunakan metode ini untuk memperbarui gambar, Image Builder secara otomatis dimulai, dan dihentikan, sebagai bagian dari proses layanan terkelola.