FAQ Amazon EBS

T: Apakah volume Amazon EBS dan panjang ID snapshot berubah pada tahun 2018?

Ya, silakan kunjungi halaman FAQ EC2 untuk detail selengkapnya.

T: Apa yang akan terjadi pada data saya saat instans Amazon EC2 dihentikan?

Berbeda dengan data yang disimpan di penyimpanan instans lokal (yang hanya bertahan selama instans aktif), data yang disimpan di volume Amazon EBS dapat bertahan secara independen selama masa pakai instans. Oleh karena itu, kami menyarankan agar Anda menggunakan penyimpanan instans lokal hanya untuk data sementara. Untuk data yang membutuhkan tingkat ketahanan yang lebih tinggi, sebaiknya gunakan volume Amazon EBS atau cadangkan data ke Amazon S3. Jika menggunakan volume Amazon EBS sebagai partisi root, Anda akan perlu mengatur tanda Hapus pada tanda penghentian menjadi "Tidak" jika Anda ingin volume Amazon EBS bertahan di luar masa pakai instans.

T: Performa seperti apa yang dapat saya harapkan dari volume Amazon EBS?

Amazon EBS menyediakan tujuh tipe volume: SSD IOPS yang Tersedia (io2 Block Express, io2, dan io1), SSD Tujuan Umum (gp3 dan gp2), HDD yang Dioptimalkan Throughput (st1) dan Cold HDD (sc1). Tipe volume ini berbeda dalam hal karakteristik performa dan harga, yang memungkinkan Anda menyesuaikan performa penyimpanan dan biaya dengan kebutuhan aplikasi. Latensi rata-rata antara instans EC2 dan EBS adalah satu digit milidetik. Untuk informasi performa selengkapnya, lihat halaman detail produk EBS. Untuk informasi selengkapnya tentang panduan kinerja Amazon EBS, lihat Meningkatkan Kinerja EBS.

T: Tipe volume mana yang harus saya pilih?

Amazon EBS mencakup dua kategori penyimpanan utama: penyimpanan yang didukung SSD untuk beban kerja transaksional (utamanya performa bergantung pada IOPS, latensi, serta ketahanan) dan penyimpanan yang didukung HDD untuk beban kerja throughput (utamanya performa bergantung pada throughput yang diukur dalam MB/dtk). Volume yang didukung SSD dirancang untuk beban kerja basis data intensif IOPS transaksional, volume boot, dan beban kerja yang memerlukan IOPS tinggi. Volume yang didukung SSD mencakup SSD IOPS yang Tersedia (io1 dan io2) dan SSD Tujuan Umum (gp3 dan gp2). Baik io2 dan io2 Block Express dari volume SSD IOPS yang Tersedia didesain untuk memberikan daya tahan 100X dari 99,999% sehingga ideal untuk aplikasi yang penting untuk bisnis yang membutuhkan waktu aktif lebih tinggi. gp3 adalah generasi terbaru dari volume SSD Tujuan Umum yang memberikan keseimbangan harga dan performa yang tepat untuk sebagian besar aplikasi yang tidak memerlukan performa IOPS tertinggi atau daya tahan 99,999%. Volume yang didukung HDD dirancang untuk beban kerja intensif throughput dan big-data, ukuran I/O yang besar, dan pola I/O berurutan. Volume yang didukung HDD mencakup Throughput Optimized HDD (st1) dan Cold HDD (sc1).

T: Karena io2 memberikan daya tahan volume yang lebih tinggi, haruskah saya tetap mengambil snapshot dan berencana untuk mereplikasi volume io2 di seluruh Zona Ketersediaan (AZ) untuk daya yang tahan tinggi?

Daya tahan volume tinggi, snapshot, serta volume replikasi di seluruh AZ melindungi dari berbagai tipe kegagalan, dan pelanggan dapat memilih untuk menggunakan satu, dua, atau semua pendekatan ini berdasarkan persyaratan daya tahan data mereka. Daya tahan volume yang lebih tinggi mengurangi kemungkinan kehilangan salinan utama data Anda. Snapshot melindungi dari kejadian kegagalan volume yang tidak diharapkan. Volume replikasi di seluruh AZ melindungi dari kegagalan tingkat AZ dan juga memberikan pemulihan yang lebih cepat jika terjadi kegagalan.

T: Bagaimana cara memodifikasi kapasitas, performa, atau tipe volume EBS yang ada?

Mengubah konfigurasi volume itu mudah. Fitur Volume Elastis memungkinkan Anda meningkatkan kapasitas, menyesuaikan performa, atau mengubah tipe volume dengan satu panggilan CLI, panggilan API, atau beberapa klik konsol. Untuk informasi selengkapnya tentang Volume Elastis, lihat dokumentasi Volume Elastis.

T: Apakah Volume Standar EBS masih tersedia?

Volume Standar EBS telah diubah namanya menjadi volume EBS Magnetic. Setiap volume yang ada tidak akan berubah sebagai akibat dari hal ini dan tidak ada perbedaan fungsional dalam penawaran EBS Magnetic dibandingkan dengan Standar EBS. Nama penawaran ini diubah untuk menghindari kebingungan dengan tipe volume SSD Tujuan Umum (gp2) kami yang merupakan tipe volume default yang kami sarankan.

T: Apakah volume SSD IOPS yang Tersedia (io2 Block Express, io2, dan io1) tersedia untuk semua tipe instans Amazon EC2?

Volume io1 SSD IOPS yang Tersedia tersedia untuk semua Tipe Instans Amazon EC2, sedangkan volume io2 SSD IOPS yang Tersedia tersedia pada semua tipe Instans EC2, kecuali R5b. Volume io2 Block Express saat ini hanya tersedia pada instans R5b. Gunakan instans EC2 yang dioptimalkan EBS untuk menghasilkan IOPS yang konsisten dan dapat diprediksi pada volume io2 dan io1. Instans yang dioptimalkan EBS menghasilkan throughput khusus antara Amazon EC2 dan Amazon EBS, dengan opsi antara 62,5 MB/dtk dan 7.500 MB/dtk tergantung pada tipe instans yang digunakan. Untuk mencapai batas 64.000 IOPS dan 1.000 MB/dtk throughput, volume harus dilampirkan ke instans EC2 yang berbasis Nitro System.

T: Tingkat konsistensi performa apa yang mungkin bisa saya dapatkan dari volume SSD IOPS yang Tersedia (io2 dan io1) milik saya?

Ketika dilampirkan ke instans yang dioptimalkan EBS, volume SSD IOPS yang Tersedia (io2 dan io1) didesain untuk menyediakan 10% performa IOPS yang tersedia dari 99,9% waktu selama tahun tertentu. Tingkat performa yang tepat bergantung pada persyaratan I/O aplikasi Anda.

T: Tingkat latensi performa apa yang mungkin bisa saya dapatkan dari volume SSD IOPS yang Tersedia (io2 dan io1) milik saya?

Saat dilampirkan ke instans yang dioptimalkan EBS, volume IOPS yang tersedia dapat mencapai latensi satu digit milidetik. Tingkat performa yang tepat bergantung pada persyaratan I/O aplikasi Anda.

T: Apakah ukuran I/O aplikasi baca dan tulis saya memengaruhi tingkat IOPS yang saya dapatkan dari volume SSD IOPS yang Tersedia (io2 dan io1)

Ya, akan memengaruhi. Saat Anda menyediakan IOPS untuk volume io2 atau io1, tingkat IOPS yang Anda dapatkan tergantung pada ukuran I/O aplikasi baca dan tulis Anda. Volume IOPS yang Tersedia memiliki ukuran I/O dasar sebesar 16KB. Jadi, jika Anda telah menyediakan volume dengan 40.000 IOPS untuk ukuran I/O 16KB, itu akan mencapai hingga 40.000 IOPS pada ukuran tersebut. Jika ukuran I/O ditingkatkan menjadi 32 KB, maka Anda akan mencapai hingga 20.000 IOPS, dan seterusnya. Untuk detail selengkapnya, silakan kunjungi dokumentasi teknis pada volume IOPS yang Tersedia. Anda dapat menggunakan Amazon CloudWatch untuk memantau ukuran throughput dan I/O.

T: Faktor apa saja yang dapat memengaruhi konsistensi performa yang akan saya lihat pada volume SSD IOPS yang Tersedia (io2 dan io1)?

Volume IOPS yang Tersedia (io2 dan io1) yang terlampir pada instans yang dioptimalkan EBS didesain untuk menawarkan performa konsisten, yang menyediakan 10% performa IOPS yang tersedia dari 99,9% waktu selama tahun tertentu. Untuk konsistensi performa maksimum dengan volume baru yang dibuat dari snapshot, kami sarankan untuk mengaktifkan Fast Snapshot Restore (FSR) pada snapshot Anda. Volume EBS yang dipulihkan dari snapshot yang diaktifkan FSR secara langsung menerima performa penuhnya.

Faktor lain yang dapat memengaruhi performa Anda adalah jika aplikasi tidak mengirim cukup permintaan I/O. Hal ini dapat dipantau dengan melihat kedalaman antrean volume Anda. Kedalaman antrean adalah jumlah permintaan I/O yang tertunda dari aplikasi ke volume Anda. Untuk konsistensi maksimum, volume IOPS yang Tersedia harus mempertahankan kedalaman antrean rata-rata (dibulatkan ke bilangan bulat terdekat) dari satu untuk setiap 1000 IOPS yang Tersedia dalam satu menit. Misalnya, untuk volume yang disediakan dengan 3000 IOPS, rata-rata kedalaman antrean harus 3. Untuk informasi selengkapnya tentang cara memastikan performa volume yang konsisten, lihat Meningkatkan Performa EBS.

T: Tingkat konsistensi performa apa yang mungkin bisa saya dapatkan dari volume yang didukung HDD milik saya?

Ketika dilampirkan ke instans yang dioptimalkan EBS, volume HDD yang Dioptimalkan Throughput (st1) dan Cold HDD (sc1) didesain untuk menyediakan 10% performa throughput yang diharapkan dari 99% waktu selama tahun tertentu. Performa yang tepat bergantung pada persyaratan I/O aplikasi dan performa instans EC2 Anda.

T: Apakah ukuran I/O aplikasi baca dan tulis memengaruhi tingkat throughput yang saya dapatkan dari volume yang didukung HDD milik saya?

Ya. Tingkat throughput yang Anda dapatkan bergantung pada ukuran I/O aplikasi baca dan tulis Anda. Proses volume yang didukung HDD membaca dan menulis dalam ukuran I/O 1MB. I/O berurutan digabungkan dan diproses sebagai unit 1 MB sementara setiap I/O yang tidak berurutan diproses sebagai 1MB bahkan jika I/O yang sebenarnya berukuran lebih kecil. Oleh karena itu, saat beban kerja transaksional dengan IOS kecil dan acak, seperti basis data, tidak akan beperforma baik pada volume yang didukung HDD, I/O berurutan dan I/O yang berukuran besar akan mencapai performa st1 dan sc1 yang diiklankan untuk periode yang lebih lama.

T: Faktor apa yang dapat memengaruhi konsistensi performa volume yang didukung HDD milik saya?

Volume HDD yang Dioptimalkan Throughput (st1) dan Cold HDD (sc1) yang dilampirkan ke instans yang dioptimalkan EBS didesain untuk menawarkan performa konsisten, yang menyediakan 10% performa throughput yang diharapkan dari 99% waktu pada tahun tertentu. Ada beberapa faktor yang dapat memengaruhi tingkat konsistensi yang Anda temui. Misalnya, keseimbangan relatif antara operasi I/O acak dan berurutan pada volume dapat memengaruhi performa Anda. Terlalu banyak operasi I/O kecil yang acak akan dengan cepat menghabiskan kredit I/O Anda dan menurunkan performa ke tingkat dasar. Tingkat throughput Anda mungkin juga lebih rendah tergantung pada instans yang dipilih. Meskipun st1 dapat mendorong throughput hingga 500 MB/dtk, performa akan dibatasi oleh batas tingkat instans terpisah untuk lalu lintas EBS. Faktor lain adalah mengambil snapshot yang akan menurunkan performa tulis yang diharapkan ke tingkat dasar hingga snapshot selesai. Ini khusus untuk st1 dan sc1.

Performa Anda juga dapat terpengaruh jika aplikasi tidak mengirimkan permintaan I/O yang cukup. Hal ini dapat dipantau dengan melihat kedalaman antrean volume dan ukuran I/O Anda. Kedalaman antrean adalah jumlah permintaan I/O yang tertunda dari aplikasi ke volume Anda. Untuk konsistensi maksimum, volume yang didukung HDD harus mempertahankan kedalaman antrean rata-rata (dibulatkan ke bilangan bulat terdekat) dari empat atau lebih untuk setiap 1 MB I/O berurutan. Untuk informasi selengkapnya tentang cara memastikan performa volume yang konsisten, lihat Meningkatkan Performa EBS.

T: Dapatkah saya menggabungkan beberapa volume untuk mendapatkan performa yang lebih baik?

Ya. Anda dapat menggabungkan beberapa volume untuk mencapai hingga 260.000 IOPS atau 60.000 Mbps (atau 7500 MB/dtk) saat dilampirkan ke instans EC2 yang lebih besar. Namun, performa untuk st1 dan sc1 diskalakan secara linier dengan ukuran volume sehingga mungkin tidak ada banyak manfaat dari menggabungkan volume ini.

T: Bagaimana cara Amazon EBS menangani masalah seperti pertikaian penyimpanan?

EBS adalah layanan penyimpanan blok multi-penyewa. Kami menggunakan pembatasan tingkat sebagai mekanisme untuk menghindari pertikaian sumber daya. Hal ini dimulai dengan menetapkan kriteria performa untuk volume – tipe volume kami (gp2, PIOPS, st1, dan sc1) semuanya telah menentukan karakteristik performa dalam hal IOPS dan throughput. Langkah selanjutnya adalah menentukan performa pada tingkat instans. Setiap instans yang Dioptimalkan EBS telah menentukan performa (throughput dan IOPS) untuk sekumpulan volume EBS yang dilampirkan ke instans. Oleh karena itu, pelanggan dapat mengukur instans dan volume untuk mendapatkan tingkat performa yang diinginkan. Selain itu, pelanggan dapat menggunakan metrik yang kami laporkan untuk mengamati performa tingkat instans dan tingkat volume. Mereka dapat mengatur alarm untuk menentukan jika apa yang mereka lihat tidak sesuai dengan performa yang diharapkan – metrik juga dapat membantu menentukan jika pelanggan dikonfigurasi pada tipe instans yang tepat atau tidak dengan jumlah performa yang tepat pada tingkat volume. Di akhir EBS, kami menggunakan performa yang dikonfigurasi untuk menginformasikan cara mengalokasikan instans yang sesuai dan infrastruktur EBS untuk mendukung volume. Dengan mengalokasikan infrastruktur secara tepat, kami menghindari pertikaian sumber daya. Selain itu, kami terus memantau infrastruktur. Pemantauan ini memungkinkan kami untuk mendeteksi kegagalan infrastruktur (atau kegagalan infrastruktur yang akan segera terjadi) dan oleh karena itu, memungkinkan kami untuk memindahkan volume secara proaktif ke perangkat keras yang berfungsi saat infrastruktur yang mendasarinya diperbaiki atau diganti (sebagaimana mestinya).

T: Tingkat konsistensi performa apa yang mungkin bisa saya dapatkan dari volume SSD Tujuan Umum (gp3 dan gp2) milik saya?

Ketika dilampirkan ke instans yang dioptimalkan EBS, volume SSD Tujuan Umum (gp3 dan gp2) didesain untuk menyediakan 10% performa IOPS yang tersedia dari 99% waktu selama tahun tertentu. Tingkat performa yang tepat bergantung pada persyaratan I/O aplikasi Anda.

T: Tingkat latensi performa apa yang mungkin bisa saya dapatkan dari volume SSD Tujuan Umum (gp3 dan gp2) milik saya?

Saat dilampirkan ke instans yang dioptimalkan EBS, volume SSD Tujuan Umum (gp3 dan gp2) dapat mencapai latensi satu digit milidetik. Tingkat performa yang tepat bergantung pada persyaratan I/O aplikasi Anda.

T: Apakah volume SSD Tujuan Umum (gp3) memiliki lonjakan?

Tidak. Semua volume SSD Tujuan Umum (gp3) mencakup 3.000 IOPS dan 125 MB/dtk performa yang konsisten tanpa biaya tambahan. Volume dapat mempertahankan 3.000 IOPS penuh dan 125 MB/dtk tanpa batas waktu.

T: Bagaimana cara kerja lonjakan pada volume SSD Tujuan Umum (gp2)?

Volume SSD Tujuan Umum (gp2) yang berada di bawah 1.000 GB menerima performa IOPS lonjakan hingga 3.000 IOPS untuk setidaknya 30 menit performa yang berkelanjutan. Selain itu, volume gp2 memberikan performa yang konsisten sebesar 3 IOPS per GB yang disediakan. Misalnya, volume 500 GB mampu mendorong 1.500 IOPS secara konsisten, dan melonjak menjadi 3.000 IOPS selama 60 menit (3.000 IOPS * 60 detik * 30 menit/1.500 IOPS/60 detik).

T. Apa perbedaan antara io2 dan io2 Block Express?

Volume io2 menawarkan penyimpanan blok performa tinggi untuk semua instans EC2. Untuk aplikasi yang membutuhkan performa lebih tinggi, Anda dapat melampirkan volume io2 ke tipe instans R5b yang berjalan pada Block Express dan memberikan performa 4x lebih tinggi daripada io2. Hal ini akan memungkinkan Anda mencapai kapasitas hingga 64 TiB, 256.000 IOPS, dan throughput 4.000 MB/dtk dari volume io2 tunggal bersama dengan latensi IO rata-rata sub-milidetik.

T. Apa itu Block Express EBS?

Block Express adalah generasi selanjutnya dari arsitektur server penyimpanan Amazon EBS yang dibuat khusus untuk memberikan tingkat performa tertinggi dengan latensi submilidetik untuk penyimpanan blok pada skala cloud. Block Express melakukan ini dengan menggunakan Scalable Reliable Datagrams (SRD), protokol jaringan latensi rendah performa tinggi, untuk berkomunikasi dengan instans EC2 berbasis Nitro System. SRD adalah antarmuka jaringan performa tinggi dan latensi rendah yang juga digunakan untuk komunikasi antarinstans di Elastic Fabric Adapter (EFA) untuk beban Komputasi Performa Tinggi (HPC) dan Machine Learning (ML). Selain itu, Block Express menawarkan perangkat lunak modular dan blok bangunan perangkat keras yang dapat dirakit dengan berbagai cara sehingga memberikan fleksibilitas untuk mendesain dan memberikan performa yang ditingkatkan serta fitur baru dengan lebih cepat.

T. Beban kerja apa yang cocok untuk io2 Block Express?

io2 Block Express cocok untuk beban kerja intensif performa dan kapasitas yang mendapat manfaat dari latensi yang lebih rendah, IOPS yang lebih tinggi, throughput yang lebih tinggi, atau kapasitas yang lebih besar dalam satu volume. Beban kerja ini termasuk basis data relasional dan NoSQL seperti SAP HANA, Oracle, MS SQL, PostgreSQL, MySQL, MongoDB, Cassandra, serta beban kerja operasi bisnis penting seperti SAP Business Suite, NetWeaver, Oracle eBusiness, PeopleSoft, Siebel, dan beban kerja ERP seperti Infor LN serta Infor M3.

T. Bagaimana saya tahu jika volume io2 berjalan pada Blok Express?

Jika volume io2 dilampirkan ke instans R5b maka volume tersebut berjalan di Block Express, yang menawarkan latensi sub-milidetik serta kemampuan untuk mendorong hingga 256.000 IOPS dan 4.000 MB/dtk throughput, serta hingga 64 TiB dalam ukuran untuk satu volume. Volume io2 yang dilampirkan ke semua instans lain tidak berjalan di Block Express dan menawarkan latensi satu digit milidetik serta kemampuan untuk mendorong hingga 64K IOPS dan 1 GBP /dtk throughput, serta hingga 16 TiB dalam ukuran untuk satu volume.

T: Bagaimana cara menggunakan API langsung EBS untuk Snapshot?

Fitur ini dapat digunakan melalui API berikut, yang dapat dipanggil menggunakan AWS CLI atau melalui AWS SDK.

• Mencantumkan blok Snapshot: Operasi API ListSnapshotBlocks mengembalikan indeks blok dan token blok untuk blok dalam snapshot tertentu.
  
• Mencantumkan Blok yang Berubah: Operasi API ListChangedBlocks mengembalikan indeks blok dan token blok untuk blok yang berbeda antara dua snapshot tertentu dari silsilah volume/snapshot yang sama.
  
• Dapatkan Blok Snapshot: Operasi API GetSnapshotBlock mengembalikan data dalam blok untuk ID snapshot, indeks blok, dan token blok yang ditentukan.
  
• Mulai Snapshot: Operasi StartSnapshot akan memulai snapshot, baik sebagai snapshot tambahan dari yang sudah ada atau sebagai snapshot baru. Snapshot awal tetap berada dalam status tertunda hingga diselesaikan dengan menggunakan tindakan CompleteSnapshot.
• Menempatkan Blok Snapshot: Operasi PutSnapshot menambahkan data dalam bentuk blok individu ke snapshot awal yang berada dalam status tertunda. Anda harus menentukan checksum SHA256 yang dikodekan Base64 untuk blok data yang ditransmisikan. Layanan memvalidasi checksum setelah transmisi selesai. Permintaan akan gagal jika checksum yang dihitung oleh layanan tidak sesuai dengan yang Anda tentukan.
• Menyelesaikan Snapshot: Operasi CompleteSnapshot menyelesaikan snapshot awal yang berada dalam status tertunda. Kemudian snapshot berubah ke status selesai.

T: Berapa ukuran blok yang didukung oleh API GetSnapshotBlock dan PutSnapshotBlock?

API GetSnapshotBlock dan PutSnapshotBlock mendukung ukuran blok 512Kib.

T: Apakah saya dapat mengakses snapshot menggunakan API Amazon S3 reguler?

Tidak, snapshot hanya tersedia melalui API Amazon EC2.

T: Apakah volume perlu dilepaskan untuk dapat mengambil snapshot?

Tidak, snapshot bisa diselesaikan secara real time sementara volume melekat dan aktif digunakan. Namun, snapshot hanya menangkap data yang telah ditulis ke volume Amazon EBS Anda, yang dapat mengecualikan data yang telah di-cache secara lokal oleh aplikasi atau OS. Untuk memastikan snapshot yang konsisten pada volume yang dilampirkan ke instans, kami sarankan untuk memisahkan volume dengan sempurna, mengeluarkan perintah snapshot, dan kemudian melampirkan kembali volume. Untuk volume Amazon EBS yang berperan sebagai perangkat akar, disarankan untuk mematikan mesin untuk mengambil snapshot yang bersih.

T: Apakah perlu waktu lebih lama untuk mengambil snapshot seluruh volume 16 TB dibandingkan dengan seluruh volume 1 TB?

Secara desain, Snapshot EBS dari seluruh volume 16 TB harus memakan waktu tidak lebih lama dari waktu yang diperlukan untuk mengambil snapshot seluruh volume 1 TB. Namun, waktu aktual yang dibutuhkan untuk membuat snapshot tergantung pada beberapa faktor termasuk jumlah data yang telah berubah sejak snapshot terakhir dari volume EBS.

T: Apakah snapshot memiliki versi? Apakah saya dapat membaca snapshot lama untuk melakukan pemulihan titik waktu?

Tiap snapshot diberi pengidentifikasi yang unik, dan pelanggan dapat membuat volume berdasarkan pada snapshot yang ada.

T: Bagaimana cara menemukan snapshot Amazon EBS yang telah dibagikan dengan saya?

Anda dapat menemukan snapshot yang dibagikan kepada Anda dengan memilih Snapshot Pribadi dari daftar di bagian Snapshot Konsol Manajemen AWS. Bagian ini mencantumkan snapshot yang Anda miliki dan snapshot yang dibagikan dengan Anda.

T: Bagaimana cara menemukan snapshot Amazon EBS yang dibagikan secara global?

Anda dapat menemukan snapshot yang dibagikan secara global dengan memilih Snapshot Publik dari daftar di bagian Snapshot Konsol Manajemen AWS.

T: Bagaimana cara menemukan daftar set data publik Amazon yang disimpan di Snapshot Amazon EBS?

Anda dapat menggunakan Konsol Manajemen AWS untuk menemukan set data publik yang disimpan sebagai Snapshot Amazon. Masuk ke konsol, pilih Layanan Amazon EC2, pilih Snapshot dan kemudian filter pada Snapshot Publik. Semua informasi tentang set data Publik tersedia di pusat sumber daya Set Data Publik AWS.

Saat mengaktifkan FSR pada snapshot bersama, Anda akan ditagih dengan tarif FSR standar (lihat halaman harga). Perhatikan bahwa hanya akun Anda yang akan ditagih untuk FSR dari snapshot bersama. Pemilik snapshot tidak akan ditagih saat Anda mengaktifkan FSR pada snapshot bersama.

T: Apa yang akan terjadi pada FSR untuk snapshot bersama ketika pemilik snapshot berhenti membagikan snapshot atau menghapusnya?

Ketika pemilik snapshot bersama Anda menghapus snapshot tersebut, atau berhenti berbagi snapshot dengan mencabut izin untuk membuat volume dari snapshot ini, FSR untuk snapshot bersama Anda secara otomatis dinonaktifkan dan penagihan FSR untuk snapshot akan dihentikan.

T: Apa itu Arsip Snapshot EBS?

Arsip Snapshot EBS adalah tingkat biaya penyimpanan yang lebih rendah yang menyimpan salinan lengkap dari Snapshot EBS titik waktu Anda. Tidak seperti Snapshot EBS dari volume yang merupakan tambahan, arsip snapshot menjadi “lengkap” karena berisi semua blok yang ditulis ke dalam volume pada saat snapshot diambil. Untuk membuat kembali volume dari Arsip Snapshot EBS, Anda dapat mengembalikan Snapshot EBS ke tingkat standar, lalu membuat volume EBS dari snapshot yang dipulihkan.

T: Mengapa saya harus menggunakan Arsip Snapshot EBS?

Anda harus menggunakan Arsip Snapshot EBS jika Anda ingin mempertahankan salinan lengkap data snapshot untuk kebutuhan retensi data jangka panjang (> 90 hari) guna memenuhi kebijakan bisnis dan persyaratan kepatuhan. Anda juga dapat menghemat biaya snapshot dengan memindahkan snapshot dari tingkat standar ke tingkat Arsip Snapshot EBS, jika pengurangan di tingkat standar lebih dari 25% dari ukuran snapshot lengkap Anda.

Anda harus mempertimbangkan untuk menggunakan Arsip Snapshot EBS dalam skenario berikut:

1. Volume Anda memiliki satu snapshot di tingkat Standar Snapshot EBS dan Anda tidak berencana untuk mengambil snapshot tambahan untuk volume tersebut. Dalam hal ini, ukuran snapshot tambahan setara dengan ukuran arsip lengkap.
2. Anda harus menyimpan snapshot lengkap untuk kebijakan bisnis atau alasan kepatuhan. Arsip Snapshot EBS menyimpan snapshot lengkap tanpa referensi mundur ke snapshot lain.
3. Anda ingin mengarsipkan snapshot secara bulanan, triwulanan, atau tahunan untuk menghemat biaya. Anda perlu memastikan bahwa Anda mendapatkan pengurangan biaya penyimpanan saat snapshot yang ada di tingkat Standar Snapshot EBS tambahan diarsipkan sebagai snapshot lengkap di tingkat Arsip Snapshot EBS.
   

T: Snapshot mana di tingkat Standar Snapshot EBS yang akan mendapat manfaat dari penggunaan Arsip Snapshot EBS untuk penghematan biaya?

T: Apa itu Keranjang Sampah untuk Snapshot EBS?

Keranjang Sampah untuk Snapshot EBS merupakan sebuah kemampuan untuk memulihkan Snapshot EBS yang dihapus, melindungi pelanggan dari penghapusan yang tidak disengaja. Ketika snapshot dihapus di akun pelanggan yang telah memilih untuk menggunakan Keranjang Sampah, snapshot secara otomatis dipindah ke Keranjang Sampah tempat snapshot akan tetap di sana selama durasi yang ditentukan pelanggan sebelum dihapus secara permanen.

T: Mengapa saya harus menggunakan Keranjang Sampah?

Keranjang Sampah memberi Anda cara sederhana dan hemat biaya untuk pulih dari penghapusan snapshot yang tidak disengaja. Keranjang Sampah sangat berharga untuk data aplikasi yang penting untuk misi dan penting untuk bisnis yang ingin Anda lindungi dari penghapusan yang tidak disengaja oleh pengguna.

T: Bagaimana cara memulai dengan Keranjang Sampah?

Untuk setiap akun AWS, Anda dapat mengaktifkan Keranjang Sampah dengan membuat satu atau beberapa aturan retensi untuk mengatur periode retensi snapshot. Setelah aturan retensi dikonfigurasi, snapshot yang dihapus akan mulai pindah ke Keranjang Sampah dan tetap di sana selama periode retensi yang ditentukan. Anda dapat memulihkan snapshot dari Keranjang Sampah kapan saja sebelum berakhirnya periode retensi. Keranjang Sampah dapat diakses melalui Konsol Manajemen AWS, AWS Command Line Interface (CLI), atau AWS SDK.

Untuk informasi selengkapnya, silakan lihat pada dokumentasi teknis.

T: Bagaimana harga snapshot yang ada di Keranjang Sampah?

Snapshot yang ada di Keranjang Sampah ditagih dengan tarif yang sama dengan Snapshot Amazon EBS. Untuk detail selengkapnya, silakan lihat https://aws.amazon.com/ebs/pricing/

T: Apakah saya bisa mendapatkan penagihan dan penggunaan Keranjang Sampah dari Cost Explorer?

Ya, Anda dapat mengakses penagihan dan penggunaan dengan menggunakan Cost Explorer. Anda dapat menggunakan tanda “aws:recycle-bin:resource-in-bin” untuk memperkirakan biaya snapshot yang ada di Keranjang Sampah.

T: Apa itu enkripsi Amazon EBS?

Enkripsi Amazon EBS menawarkan enkripsi volume data EBS, volume boot, dan snapshot yang lancar, tanpa perlu membuat dan memelihara infrastruktur manajemen kunci yang aman. Enkripsi EBS memungkinkan keamanan data diam dengan mengenkripsi data menggunakan kunci yang dikelola Amazon atau kunci yang Anda buat dan kelola menggunakan AWS Key Management Service (KMS). Selain itu, enkripsi terjadi pada server yang meng-host instans EC2, yang memberikan enkripsi data ketika beralih di antara instans EC2 dan penyimpanan EBS. Untuk informasi selengkapnya, lihat enkripsi Amazon EBS di Panduan Pengguna Amazon EC2.

T: Apa itu AWS Key Management Service (KMS)?

AWS KMS merupakan layanan terkelola yang memudahkan untuk membuat dan mengontrol kunci enkripsi yang digunakan untuk mengenkripsi data Anda. AWS Key Management Service terintegrasi dengan layanan AWS lainnya termasuk Amazon EBS, Amazon S3, dan Amazon Redshift sehingga memudahkan enkripsi data dengan kunci enkripsi yang Anda kelola. AWS Key Management Service juga terintegrasi dengan AWS CloudTrail untuk menyediakan log untuk semua penggunaan kunci Anda untuk membantu memenuhi kebutuhan peraturan dan kepatuhan. Untuk mempelajari selengkapnya tentang KMS, kunjungi halaman produk AWS Key Management Service.

T: Mengapa saya harus menggunakan enkripsi EBS?

Anda dapat menggunakan enkripsi Amazon EBS untuk memenuhi persyaratan kepatuhan keamanan dan enkripsi untuk enkripsi data diam di cloud. Memasangkan enkripsi dengan kebijakan kontrol akses IAM yang ada akan meningkatkan strategi pertahanan mendalam perusahaan Anda.

T: Bagaimana cara kunci enkripsi Amazon EBS saya dikelola?

Enkripsi Amazon EBS menangani manajemen kunci untuk Anda. Setiap volume yang baru dibuat mendapatkan kunci AES 256-bit yang unik; Volume yang dibuat dari snapshot terenkripsi akan membagikan kunci tersebut. Kunci ini dilindungi oleh infrastruktur manajemen kunci milik kami sendiri, yang menerapkan kontrol keamanan logis dan fisik kuat untuk mencegah akses yang tidak sah. Data dan kunci terkait milik Anda dienkripsi menggunakan algoritma AES-256 standar industri.

T: Apakah enkripsi EBS mendukung volume boot?

Ya.

T: Dapatkah saya membuat volume data terenkripsi pada saat peluncuran instans?

Ya, menggunakan kunci utama pelanggan (CMK) yang dikelola AWS atau dikelola pelanggan. Anda dapat menentukan detail volume dan enkripsi melalui panggilan API RunInstances dengan parameter BlockDeviceMapping atau melalui Wizard Peluncuran di Konsol EC2.

T: Dapatkah saya membuat volume data terenkripsi tambahan pada saat peluncuran instans yang bukan merupakan bagian dari AMI?

Ya, Anda dapat membuat volume data terenkripsi dengan enkripsi CMK default atau kustom pada saat peluncuran instans. Anda dapat menentukan detail volume dan enkripsi melalui objek BlockDeviceMapping dalam panggilan API RunInstances atau melalui Wizard Peluncuran di Konsol EC2.

T: Dapatkah saya meluncurkan instans EBS terenkripsi dari AMI yang tidak terenkripsi?

Ya. Lihat dokumentasi teknis untuk detailnya.

T: Dapatkah saya membagikan snapshot dan AMI terenkripsi dengan akun lain?

Ya. Anda dapat membagikan snapshot dan AMI terenkripsi menggunakan kunci utama pelanggan (CMK) yang dikelola pelanggan dengan akun AWS lainnya. Lihat dokumentasi teknis untuk detailnya.

T: Dapatkah saya memastikan bahwa semua volume baru yang dibuat selalu dienkripsi?

Ya, Anda dapat mengaktifkan enkripsi EBS secara default dengan satu pengaturan per wilayah. Hal ini memastikan bahwa semua volume yang baru selalu dienkripsi. Lihat dokumentasi teknis untuk detail selengkapnya. 

T: Apakah saya akan ditagih untuk IOPS yang disediakan pada volume IOPS yang Tersedia ketika terputus dari instans?

Ya, Anda akan ditagih untuk IOPS yang disediakan saat terputus dari sebuah instans. Ketika volume terlepas, sebaiknya Anda mempertimbangkan untuk membuat snapshot dan menghapus volume untuk mengurangi biaya. Untuk informasi selengkapnya, lihat pemeriksaan optimasi biaya "Volume Amazon EBS yang Kurang Dimanfaatkan" di Trusted Advisor. Item ini memeriksa konfigurasi volume Amazon Elastic Block Store (Amazon EBS) Anda dan memberi peringatan saat volume terlihat kurang digunakan.

T: Apakah harga tersebut sudah termasuk pajak?

Kecuali dinyatakan lain, harga tersebut tidak termasuk pajak dan beban biaya yang berlaku, termasuk PPN dan pajak penjualan yang berlaku. Untuk pelanggan dengan alamat tagihan Jepang, penggunaan layanan AWS tunduk pada Pajak Konsumsi Jepang. Pelajari selengkapnya.

T: Apakah ada biaya tambahan untuk mengaktifkan Multi-Lampiran?

Tidak. Multi-Lampiran dapat diaktifkan pada volume io1 IOPS yang Tersedia EBS dan akan ada biaya untuk penyimpanan (GB-Bulan) serta IOPS (IOPS-Bulan) yang disediakan.

T: Dapatkah saya melakukan boot instans EC2 menggunakan volume yang diaktifkan Multi-Lampiran?

Tidak.

T: Apa yang akan terjadi jika semua instans terlampir saya tidak memiliki kumpulan tanda ‘deleteOnTermination’

Perilaku deleteOnTermination volume ditentukan oleh konfigurasi instans terlampir terakhir yang dihentikan. Untuk memastikan penghapusan yang dapat diprediksi pada perilaku penghentian, aktifkan atau nonaktifkan 'deleteOnTermination' untuk semua instans yang dilampirkan volume.

Jika Anda ingin volume dihapus saat instans terlampir dihentikan, aktifkan ‘deleteOnTermination’ untuk semua instans yang dilampirkan volume. Jika Anda ingin mempertahankan volume setelah instans terlampir dihentikan, nonaktifkan ‘deleteOnTermination’ untuk semua instans terlampir. Untuk informasi selengkapnya, lihat dokumentasi teknis Multi-Lampiran.

T: Apakah aplikasi saya dapat menggunakan Multi-Lampiran?

Jika aplikasi Anda tidak memerlukan koordinasi lapisan penyimpanan operasi tulis, seperti aplikasi hanya-baca atau memberlakukan pagar IO tingkat aplikasi, maka aplikasi Anda dapat menggunakan Multi-Lampiran.