FAQ Amazon RDS

Anda dapat menganggap instans DB sebagai lingkungan basis data dalam cloud dengan sumber daya komputasi dan penyimpanan yang Anda tentukan. Anda dapat membuat dan menghapus instans DB, menentukan/menyempurnakan atribut infrastruktur instans DB, serta mengontrol akses dan keamanan melalui Konsol Manajemen AWS, API Amazon RDS, serta AWS Command Line Interface. Anda dapat menjalankan satu atau beberapa instans DB, dan setiap instans DB dapat mendukung satu atau beberapa basis data atau skema basis data, tergantung pada tipe mesin.

Instans DB mudah dibuat menggunakan Konsol Manajemen AWS, API Amazon RDS, atau AWS Command Line Interface. Untuk meluncurkan instans DB menggunakan Konsol Manajemen AWS, klik "RDS" lalu tombol “Luncurkan Instans DB” pada tab Instans. Dari sana, Anda dapat menentukan parameter untuk instans DB Anda termasuk mesin dan versi DB, model lisensi, tipe instans, tipe dan jumlah penyimpanan, serta kredensial pengguna primer.

Anda juga memiliki kemampuan untuk mengubah kebijakan penyimpanan cadangan instans DB Anda, periode cadangan pilihan, dan periode pemeliharaan terjadwal. Selain itu, Anda dapat membuat instans DB menggunakan API CreateDBInstance atau perintah create-db-instance.

Setelah instans DB tersedia, Anda dapat mengambil kembali titik akhirnya melalui deskripsi instans DB di Konsol Manajemen AWS, API DescribeDBInstances, atau perintah describe-db-instances. Dengan menggunakan titik akhir ini, Anda dapat membangun string koneksi yang diperlukan untuk terhubung langsung dengan instans DB menggunakan alat atau bahasa pemrograman basis data favorit Anda. Untuk mengizinkan permintaan jaringan ke instans DB yang berjalan, Anda perlu mengotorisasi akses. Untuk penjelasan mendetail tentang cara membuat string koneksi Anda dan memulai, lihat Panduan Memulai kami.

Secara default, pelanggan diizinkan memiliki hingga total 40 instans DB Amazon RDS. Dari 40 instans DB tersebut, maksimal 10 di antaranya dapat berupa instans DB RDS for Oracle atau RDS for SQL Server dalam model “Termasuk Lisensi”. Ke-40 instans tersebut dapat digunakan untuk Amazon Aurora, RDS for PostgreSQL, RDS for MySQL, RDS for MariaDB, dan RDS for Oracle dalam model Bawa Lisensi Anda Sendiri (BYOL). Perhatikan bahwa RDS for SQL Server memiliki batasan hingga 100 basis data dalam instans DB tunggal. Untuk mempelajari selengkapnya, lihat Panduan Pengguna Amazon RDS for SQL Server

• RDS untuk Amazon Aurora: Tidak ada batasan yang dikenakan oleh perangkat lunak
• RDS untuk MySQL: Tidak ada batasan yang dikenakan oleh perangkat lunak
• RDS untuk MariaDB: Tidak ada batasan yang dikenakan oleh perangkat lunak
• RDS untuk Oracle: 1 basis data per instans; tidak ada batasan jumlah skema per basis data yang dikenakan oleh perangkat lunak
• RDS untuk SQL Server: Hingga 100 basis data per instans
• RDS untuk PostgreSQL: Tidak ada batasan yang dikenakan oleh perangkat lunak
• RDS for Db2: Hingga 8 basis data per instans

Berikut ini adalah beberapa cara untuk mengimpor data ke Amazon RDS:

• MySQL: pemanfaatan mysqldump atau mysqlimport
• Oracle: Data Pump, impor/ekspor, atau Pemuat SQL
• SQL Server: Wizard Impor/Ekspor, file cadangan penuh (.bak), atau Program Salin Massal (BCP)
• PostgreSQL: pg_dump

Untuk informasi selengkapnya tentang impor dan ekspor data, lihat Panduan Impor Data untuk MySQL, Panduan Impor Data untuk Oracle, Panduan Impor Data untuk SQL Server, Panduan Impor Data untuk PostgreSQL, atau Panduan Impor Data untuk Db2.

Selain itu, AWS Database Migration Service dapat membantu Anda memigrasikan basis data ke AWS dengan aman

Jendela pemeliharaan Amazon RDS merupakan kesempatan Anda untuk mengontrol kapan modifikasi instans DB, pemutakhiran versi mesin basis data, dan patching perangkat lunak terjadi, apabila diminta atau diperlukan. Jika pemeliharaan dijadwalkan untuk minggu tertentu, pemeliharaan akan dimulai selama periode pemeliharaan yang Anda identifikasi.

Kejadian pemeliharaan yang memerlukan Amazon RDS untuk membuat instans DB Anda offline adalah menyesuaikan skala operasi komputasi (yang biasanya hanya memerlukan beberapa menit dari awal hingga selesai), pemutakhiran versi mesin database, dan memerlukan penerapan patch perangkat lunak. Penerapan patch perangkat lunak yang diperlukan dijadwalkan otomatis hanya untuk patch yang terkait keamanan dan ketahanan. Penerapan patch seperti itu jarang terjadi (biasanya setiap beberapa bulan sekali) dan jarang memerlukan lebih dari sebagian kecil dari periode pemeliharaan Anda.

Jika Anda tidak menentukan jendela pemeliharaan mingguan pilihan saat membuat instans DB, nilai default yang akan ditetapkan adalah 30 menit. Jika ingin mengubah sendiri waktu pemeliharaan dilakukan, Anda dapat melakukannya dengan mengubah instans DB di Konsol Manajemen AWS, API ModifyDBInstance, atau perintah modify-db-instance. Setiap instans DB Anda dapat memiliki periode pemeliharaan pilihan yang berbeda, jika Anda memilih demikian.

Menjalankan instans DB Anda sebagai Penerapan Multi-AZ dapat mengurangi pengaruh kejadian pemeliharaan lebih jauh. Lihat Panduan Pengguna Amazon RDS untuk informasi selengkapnya tentang operasi pemeliharaan.

Untuk basis data produksi, kami menyarankan agar Anda mengaktifkan Pemantauan yang Ditingkatkan, yang memberikan akses ke lebih dari 50 CPU, memori, sistem file, dan metrik I/O disk. Anda dapat mengaktifkan fitur ini dengan basis per instans dan Anda dapat memilih perinciannya (hingga ke 1 detik). Tingkat pemakaian CPU yang tinggi dapat mengurangi performa kueri dan dalam hal ini Anda mungkin ingin mempertimbangkan penskalaan kelas instans DB Anda. Untuk informasi selengkapnya tentang pemantauan instans DB Anda, lihat Panduan Pengguna Amazon RDS.

Jika menggunakan RDS for MySQL atau MariaDB, Anda dapat mengakses log kueri lambat untuk basis data guna menentukan keberadaan kueri SQL yang berjalan lambat, dan jika ada, apa karakteristik performa masing-masing. Anda dapat mengatur Parameter DB "slow_query_log" dan tabel kueri mysql.slow_log untuk meninjau kueri SQL yang berjalan lambat. Lihat Panduan Pengguna Amazon RDS untuk mempelajari selengkapnya.

Jika Anda menggunakan RDS untuk Oracle, Anda dapat menggunakan jejak data file Oracle untuk mengidentifikasi kueri yang lambat. Untuk informasi selengkapnya tentang mengakses data file jejak, lihat Panduan Pengguna Amazon RDS. 

Jika Anda menggunakan RDS untuk SQL Server, Anda dapat menggunakan jejak SQL Server sisi klien untuk mengidentifikasi kueri yang lambat. Untuk informasi tentang mengakses data file jejak sisi server, lihat Panduan Pengguna Amazon RDS.

Untuk daftar versi mesin database yang didukung, silakan lihat dokumentasi untuk masing-masing mesin:

• Amazon Aurora
• Amazon RDS for PostgreSQL
• Amazon RDS for MySQL
• Amazon RDS for MariaDB
• Amazon RDS for SQL Server
• Amazon RDS for Oracle
• Amazon RDS for Db2

Lihat halaman FAQ masing-masing mesin basis data Amazon RDS untuk spesifikasi penomoran versi:

• Amazon RDS for MySQL
• Amazon RDS for MariaDB
• Amazon RDS for PostgreSQL
• Amazon RDS untuk Oracle
• Amazon RDS for SQL Server
• Amazon Aurora

Seiring waktu, Amazon RDS menambahkan dukungan untuk versi mesin basis data utama dan minor. Jumlah versi baru yang didukung akan berbeda-beda berdasarkan frekuensi dan konten rilisan serta patch dari vendor atau organisasi pengembangan mesin dan hasil pemeriksaan menyeluruh dari rilisan dan patch ini oleh tim teknisi basis data kami. Namun, sebagai panduan umum, kami bertujuan untuk mendukung versi mesin baru dalam waktu 5 bulan dari ketersediaan mesin secara umum.

Anda dapat menentukan versi apa pun yang didukung saat ini (utama dan minor) saat membuat instans DB baru melalui operasi Luncurkan Instans DB di Konsol Manajemen AWS atau API CreateDBInstance. Harap perhatikan bahwa tidak semua versi mesin database tersedia di setiap region AWS.

Amazon RDS berusaha untuk menjaga pembaruan instans basis data Anda dengan memberikan versi terbaru dari mesin basis data yang didukung. Setelah versi mesin database baru dirilis oleh vendor atau perusahaan pengembang, maka akan diuji secara menyeluruh oleh tim teknik database kami sebelum tersedia di Amazon RDS.

Kami merekomendasikan Anda untuk terus memutakhirkan instans basis data ke versi minor terbaru karena versi tersebut berisi perbaikan keamanan dan fungsionalitas terbaru. Tidak seperti pada versi mayor, pemutakhiran versi minor hanya menyertakan perubahan database yang kompatibel ke belakang dengan versi minor sebelumnya (dari versi mayor yang sama) dari mesin database. 

Jika versi minor baru tidak memiliki perbaikan yang akan menguntungkan pelanggan Amazon RDS, kami mungkin memilih untuk tidak menyediakannya di Amazon RDS. Segera setelah versi minor baru tersedia di Amazon RDS, kami akan mengaturnya untuk menjadi versi minor yang dipilih untuk instans DB baru. 

Untuk secara manual memutakhirkan instans basis data ke versi mesin yang didukung, gunakan perintah Ubah Instans DB pada Konsol Manajemen AWS atau API ModifyDBInstance dan atur parameter Versi Mesin DB ke versi yang diinginkan. Secara default, pemutakhiran akan diterapkan selama jendela pemeliharaan Anda berikutnya. Anda juga dapat memilih untuk segera melakukan pemutakhiran dengan memilih opsi Terapkan Segera di API konsol.

Jika kami menentukan bahwa terdapat perbaikan bug yang signifikan dalam versi minor mesin yang baru dibandingkan dengan versi minor yang dirilis sebelumnya, kami akan menjadwalkan pemutakhiran otomatis untuk instans DB yang memiliki pengaturan Pemutakhiran Versi Minor Otomatis ke “Ya”. Pemutakhiran ini akan dijadwalkan dilakukan selama periode pemeliharaan yang ditentukan pelanggan.

Kami menjadwalkannya agar Anda dapat membuat rencana seputar hal ini, karena diperlukan waktu henti untuk memutakhirkan versi mesin DB, bahkan untuk instans Multi-AZ. Jika Anda ingin menonaktifkan pemutakhiran otomatis versi minor, Anda dapat melakukannya dengan mengatur pengaturan Pemutakhiran Versi Minor Otomatis ke “Tidak”.

Dalam kasus RDS untuk Oracle dan RDS for SQL Server, jika pemutakhiran ke versi minor berikutnya memerlukan perubahan ke edisi berbeda, kami mungkin tidak akan menjadwalkan pemutakhiran otomatis meskipun Anda mengaktifkan pengaturan Pemutakhiran Versi Minor Otomatis. Penentuan apakah akan menjadwalkan pemutakhiran otomatis dalam situasi semacam itu akan dilakukan berdasarkan kasus per kasus.

Karena pemutakhiran versi mayor melibatkan beberapa risiko kompatibilitas, maka pemutakhiran tidak akan terjadi secara otomatis dan harus dimulai oleh Anda (kecuali dalam kasus penolakan versi mayor, lihat di bawah). Untuk informasi selengkapnya tentang pemutakhiran instans DB ke versi mesin DB baru, lihat Panduan Pengguna Amazon RDS.

Ya. Anda dapat melakukannya dengan membuat snapshot instans DB Anda yang sudah ada, memulihkan snapshot DB untuk membuat instans DB baru, kemudian memulai pemutakhiran versi untuk instans DB baru. Anda kemudian dapat bereksperimen dengan aman pada salinan pemutakhiran instans DB Anda sebelum memutuskan apakah akan meningkatkan instans DB asli Anda atau tidak.

Untuk informasi selengkapnya tentang pemulihan snapshot DB, lihat Panduan Pengguna Amazon RDS.

• Kami bermaksud untuk mendukung rilisan versi mayor (misalnya, MySQL 5.6, PostgreSQL 9.6) setidaknya selama 3 tahun setelah versi tersebut mulai didukung oleh Amazon RDS.
• Kami bermaksud untuk mendukung versi minor (misalnya, MySQL 5.6.37, PostgreSQL 9.6.1) setidaknya selama 1 tahun setelah versi tersebut mulai didukung oleh Amazon RDS.

Kami akan menghentikan versi mesin mayor atau minor secara berkala. Versi mayor tersedia setidaknya hingga akhir masa pakai komunitas untuk versi komunitas yang sesuai, atau versi tersebut tidak lagi menerima perbaikan perangkat lunak atau pembaruan keamanan. Untuk versi minor, adalah ketika versi minor memiliki bug yang signifikan atau masalah keamanan yang telah diselesaikan dalam versi minor selanjutnya.

Meskipun kami berusaha keras untuk memenuhi panduan ini, dalam beberapa kasus kami mungkin menghentikan penggunaan versi mayor atau minor tertentu dengan lebih cepat, seperti pada saat terdapat masalah keamanan. Dalam kasus di mana hal tersebut tidak mungkin terjadi, Amazon RDS akan secara otomatis memutakhirkan mesin database Anda untuk mengatasi masalah ini. Keadaan khusus dapat menentukan jadwal yang berbeda tergantung pada masalah yang sedang dibahas.

Ketika versi minor dari mesin basis data tidak lagi digunakan di Amazon RDS, kami akan memberi waktu tiga (3) bulan setelah pengumuman sebelum memulai pemutakhiran otomatis. Di akhir periode ini, semua instans yang masih menjalankan versi minor yang sudah tidak digunakan akan dijadwalkan untuk pemutakhiran otomatis ke versi minor terbaru yang didukung selama periode pemeliharaan terjadwal.

Ketika versi mayor dari mesin basis data tidak lagi digunakan di Amazon RDS, kami akan memberikan minimal waktu enam (6) bulan setelah pengumuman penghentian penggunaan agar Anda dapat memulai peningkatan ke versi mayor yang didukung. Di akhir periode ini, pemutakhiran otomatis ke versi mayor selanjutnya akan diterapkan untuk instans apa pun yang masih menjalankan versi mayor yang sudah tidak digunakan selama jadwal periode pemeliharaan.

Dalam beberapa kasus, kami dapat menghentikan versi mayor atau minor tertentu tanpa pemberitahuan sebelumnya, seperti saat kami menemukan versi tidak memenuhi kualitas tinggi, performa, atau bilah keamanan kami. Jika kasus seperti itu tidak mungkin terjadi, Amazon RDS akan menghentikan pembuatan instans dan klaster basis data baru dengan versi ini. Pelanggan yang ada mungkin terus dapat menjalankan basis data mereka. Keadaan khusus dapat menentukan jadwal yang berbeda tergantung pada masalah yang sedang dibahas.

Anda hanya perlu membayar yang Anda gunakan dan tidak ada biaya minimum atau biaya penyiapan. Anda ditagih berdasarkan:

• Jam instans DB – Berdasarkan kelas (misalnya, db.t2.micro, db.m4.large) instans DB yang dipakai. Jam instans DB sebagian yang digunakan ditagihkan dalam peningkatan satu detik dengan biaya minimum 10 menit setelah perubahan status yang dapat ditagih, seperti membuat, memulai, atau memodifikasi kelas instans DB. Untuk detail tambahan, baca pengumuman hal-hal terbaru dari kami.
• Penyimpanan (per GB per bulan) – Kapasitas penyimpanan yang telah Anda sediakan untuk instans DB. Jika Anda menskalakan kapasitas penyimpanan yang diberikan dalam bulan ini, akan diterapkan sistem pro-rata pada tagihan Anda.
• Permintaan I/O per bulan – Jumlah total permintaan I/O penyimpanan yang Anda miliki (hanya untuk Amazon RDS Magnetic Storage dan Amazon Aurora)
• IOPS yang Tersedia per bulan – Tarif IOPS yang Tersedia, terlepas dari IOPS yang digunakan (hanya untuk penyimpanan IOPS yang Tersedia (SSD) Amazon RDS)
• Penyimpanan Cadangan – Penyimpanan cadangan adalah penyimpanan yang terkait dengan pencadangan database otomatis Anda dan snapshot database mana pun yang dimulai oleh pelanggan. Meningkatkan periode penyimpanan cadangan Anda atau mengambil snapshot DB meningkatkan penyimpanan cadangan yang digunakan oleh database Anda.
• Transfer data – Transfer data internet masuk dan keluar dari instans DB Anda.

Untuk informasi harga Amazon RDS, kunjungi bagian harga di halaman produk Amazon RDS.

Penagihan dimulai untuk instans DB segera setelah instans DB tersedia. Penagihan berlanjut hingga instans DB berakhir, yang akan terjadi saat penghapusan atau jika instans mengalami kegagalan.

Jam instans DB ditagih untuk setiap jam saat instans DB Anda berjalan dalam status tersedia. Jika tidak ingin dikenai biaya lagi untuk instans DB, Anda harus menghentikan atau menghapus instans tersebut agar tidak ditagih atas jam instans tambahan. Jam instans DB sebagian yang digunakan ditagihkan dalam peningkatan satu detik dengan biaya minimum 10 menit setelah perubahan status yang dapat ditagih, seperti membuat, memulai, atau memodifikasi kelas instans DB.

Ketika instans database dihentikan, Anda akan ditagih untuk penyimpanan yang disediakan (termasuk IOPS Tersedia) dan penyimpanan cadangan (termasuk snapshot manual dan cadangan otomatis dalam periode penyimpanan yang ditentukan), tetapi tidak untuk jam instans DB.

Penyimpanan cadangan gratis disediakan maksimal sejumlah total penyimpanan basis data yang disediakan akun Anda di seluruh wilayah. Misalnya, jika Anda memiliki instans DB MySQL dengan penyimpanan yang disediakan sebesar 100 GB selama sebulan dan instans DB PostgreSQL dengan penyimpanan yang disediakan sebesar 150 GB selama sebulan, keduanya di wilayah yang sama serta akun yang sama, kami akan menyediakan penyimpanan cadangan sebesar 250 GB di akun dan wilayah ini tanpa biaya tambahan. Anda hanya akan dikenai biaya untuk penyimpanan cadangan yang melebihi jumlah ini.

Setiap hari, total penyimpanan basis data yang disediakan akun Anda di wilayah tersebut dibandingkan dengan total penyimpanan cadangan di wilayah tersebut, dan hanya kelebihan penyimpanan cadangan yang dikenai biaya. Misalnya, jika memiliki kelebihan penyimpanan cadangan sebesar tepat 10 GB setiap hari, Anda akan dikenai biaya penyimpanan cadangan sebesar 10 GB-bulan untuk bulan tersebut. Atau, jika Anda memiliki penyimpanan yang disediakan sebesar 300 GB setiap hari, dan penyimpanan cadangan sebesar 500 GB setiap hari, tetapi hanya untuk setengah bulan, maka Anda hanya akan dikenai biaya untuk penyimpanan cadangan sebesar 100 GB-bulan (bukan 200 GB-bulan), karena biaya dihitung setiap hari (proporsional), dan cadangan tidak ada untuk seluruh bulan. Perhatikan bahwa penyimpanan cadangan gratis bersifat spesifik untuk akun dan wilayah tertentu.

Ukuran cadangan berbanding lurus dengan jumlah data pada instans Anda. Misalnya, jika Anda memiliki instans DB dengan penyimpanan yang disediakan sebesar 100 GB, tetapi hanya menyimpan 5 GB data di dalamnya, cadangan pertama Anda hanya akan berukuran sekitar 5 GB (bukan 100 GB). Pencadangan berikutnya bersifat inkremental dan hanya akan menyimpan data yang diubah pada instans DB Anda. Perhatikan bahwa ukuran penyimpanan cadangan tidak ditampilkan di Konsol RDS atau dalam respons API DescribeDBSnapshots.

Penyimpanan yang disediakan untuk instans DB Anda untuk data primer berlokasi di satu Availability Zone. Ketika basis data Anda dicadangkan, data cadangan (termasuk log transaksi) akan direplikasi secara geo-redundan di banyak Zona Ketersediaan untuk memberikan tingkat ketahanan data yang lebih tinggi. Harga penyimpanan cadangan di luar alokasi gratis Anda merefleksikan replikasi ekstra ini yang terjadi untuk memaksimalkan ketahanan cadangan kritis Anda.

Jika Anda menetapkan bahwa instans DB seharusnya adalah deployment Multi-AZ, Anda akan ditagih berdasarkan harga Multi-AZ yang diposting di halaman harga Amazon RDS. Penagihan Multi-AZ berdasarkan pada:

• Jam instans DB Multi-AZ – Berdasarkan kelas (misalnya, db.t2.micro, db.m4.large) instans DB yang digunakan. Adapun deployment standar dalam satu Zona Ketersediaan, jam instans DB Sebagian ditagih dalam peningkatan satu detik dengan biaya minimum 10 menit setelah perubahan status yang dapat ditagih, seperti membuat, memulai, atau mengubah kelas instans DB. Jika Anda mengonversi penerapan instans DB Anda dari standar ke Multi-AZ dalam jam tertentu, Anda akan dikenakan tarif yang berlaku untuk jam tersebut.
• Penyimpanan yang disediakan (untuk instans DB Multi-AZ) – Jika Anda mengonversi penerapan antara standar dan Multi-AZ dalam jam tertentu, Anda akan dikenakan tarif yang lebih tinggi dari tarif penyimpanan yang berlaku untuk jam tersebut.
• Permintaan I/O per bulan – Jumlah total permintaan I/O penyimpanan yang Anda miliki. Penerapan Multi-AZ menggunakan volume permintaan I/O yang lebih besar dari penerapan instans DB standar, tergantung pada rasio tulis/baca database Anda. Penggunaan tulis I/O yang terkait dengan pembaruan database akan berlipat ganda karena Amazon RDS secara tersinkron mereplikasi data Anda ke instans DB standby. Penggunaan baca I/O akan tetap sama.
• Penyimpanan Cadangan – Penggunaan penyimpanan cadangan Anda tidak akan berubah, baik instans DB Anda standar maupun penerapan Multi-AZ. Cadangan hanya akan diambil dari standby Anda untuk menghindari penangguhan I/O pada primer instans DB.
• Transfer data – Anda tidak dikenakan biaya untuk transfer data yang terjadi pada saat mereplikasi data antara primer dan standby Anda. Transfer data internet masuk dan keluar dari instans DB Anda dikenakan biaya yang sama dengan penerapan standar.

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 lebih lanjut.

Penawaran AWS Tingkat Gratis untuk Amazon RDS menyediakan instans DB Mikro AZ Tunggal yang menjalankan MySQL, MariaDB, PostgreSQL, dan SQL Server Express Edition secara gratis. Tingkat penggunaan gratis dibatasi pada 750 jam instans per bulan. Pelanggan juga menerima 20 GB penyimpanan database General Purpose (SSD) dan 20 GB penyimpanan cadangan gratis per bulan.

Akun AWS baru menerima akses AWS Tingkat Gratis selama 12 bulan. Silakan lihat FAQ AWS Tingkat Gratis untuk informasi selengkapnya.

Ya. Anda dapat menjalankan lebih dari satu instans DB Micro AZ Tunggal secara bersamaan dan memenuhi syarat untuk penggunaan yang dihitung berdasarkan AWS Tingkat Gratis untuk Amazon RDS. Namun, jika penggunaan melebihi 750 jam instans di seluruh instans DB Micro AZ Tunggal Amazon RDS dan di seluruh wilayah dan mesin basis data yang memenuhi syarat, akan ditagih dengan harga standar Amazon RDS.

Contoh: jika Anda menjalankan dua instans DB Micro AZ Tunggal selama masing-masing 400 jam dalam satu bulan, Anda akan mengakumulasikan 800 jam instans penggunaan, 750 jam dari akumulasi tersebut gratis. Anda akan ditagih untuk 50 jam sisanya dengan harga standar Amazon RDS.

Tidak. Pelanggan dengan akses ke AWS Tingkat Gratis dapat menggunakan hingga 750 jam instans dari instans Micro yang menjalankan MySQL, PostgreSQL, atau SQL Server Express Edition. Penggunaan apa pun yang melebihi 750 jam instans di seluruh instans DB Micro AZ Tunggal Amazon RDS dan di seluruh wilayah serta mesin basis data yang memenuhi syarat, akan ditagih dengan harga standar Amazon RDS.

Anda akan ditagih dengan harga standar Amazon RDS untuk jam instans yang melampaui apa yang diberikan oleh Tingkat Gratis. Lihat halaman harga Amazon RDS untuk detailnya.

Instans terpesan Amazon RDS memberi Anda opsi untuk memesan instans DB dengan jangka waktu satu atau tiga tahun dan, sebagai gantinya, Anda akan menerima diskon yang signifikan dibandingkan dengan harga instans sesuai permintaan untuk instans DB tersebut. Ada tiga opsi pembayaran RI – Tanpa Biaya Didepan, Biaya Didepan Sebagian, Semua Didepan – yang memungkinkan Anda menyeimbangkan jumlah yang Anda bayar didepan dengan harga per jam yang efektif.

Secara fungsional, instans terpesan dan instans DB sesuai permintaan masih sama persis. Satu-satunya perbedaan adalah cara penagihan instans DB Anda. Dengan Instans Terpesan, Anda membeli reservasi untuk satu atau tiga tahun dan menerima tarif penggunaan efektif per jam yang lebih rendah (dibandingkan dengan instans DB sesuai permintaan) selama jangka waktu tersebut. Kecuali Anda membeli instans cadangan di suatu Region, semua instans DB akan ditagih dengan tarif per jam pesanan.

Anda dapat membeli instans cadangan di bagian "Instans Cadangan" Konsol Manajemen AWS untuk Amazon RDS. Selain itu, Anda dapat menggunakan API Amazon RDS atau AWS Command Line Interface guna mendaftar reservasi yang tersedia untuk dibeli, lalu membeli reservasi instans DB.

Setelah Anda melakukan pembelian pencadangan, penggunaan instans DB terpesan tidak berbeda dengan instans DB Sesuai Permintaan. Luncurkan instans DB menggunakan kelas, mesin, dan wilayah instans yang sama dengan yang Anda buat untuk reservasi. Selama pembelian pencadangan Anda aktif, Amazon RDS akan menerapkan pengurangan tarif per jam bagi Anda untuk instans DB yang baru.

Instans cadangan Amazon RDS dibeli untuk Wilayah, bukan untuk Availability Zone tertentu. Karena RI tidak spesifik untuk suatu Availability Zone Ketersediaan, maka RI bukanlah pencadangan kapasitas. Ini berarti bahwa meskipun kapasitas terbatas dalam satu Zona Ketersediaan, cadangan masih dapat dibeli di Region dan potongan harga akan berlaku untuk penggunaan yang cocok dalam Zona Ketersediaan mana pun dalam Region tersebut.

Anda dapat membeli hingga 40 instans DB cadangan. Jika Anda ingin menjalankan lebih dari 40 instans DB, lengkapi formulir permintaan Instans DB Amazon RDS.

Cukup beli rerservasi instans DB dengan kelas instans DB, mesin DB, opsi Multi-AZ dan Model Lisensi yang sama dalam Wilayah yang sama seperti instans DB yang sedang Anda jalankan saat ini dan ingin Anda cadangkan. Jika pembelian pencadangan berhasil, Amazon RDS akan secara otomatis menerapkan biaya baru penggunaan per jam Anda ke instans DB yang sudah ada.

Perubahan harga yang berkaitan dengan instans terpesan diaktifkan setelah permintaan Anda diterima dan saat otorisasi pembayaran diproses. Ada dapat mengikuti status reservasi di halaman Aktivitas Akun AWS atau menggunakan API DescribeReservedDBInstances atau perintah describe-reserved-db-instances. Jika pembayaran satu kali tidak berhasil diotorisasi sampai periode penagihan selanjutnya, potongan harga tidak akan berlaku.

Ketika jangka waktu pencadangan Anda berakhir, instans cadangan Anda akan kembali ke tarif penggunaan per jam Pesanan yang sesuai untuk kelas dan Region instans DB Anda.

Operasi Amazon RDS untuk membuat, mengubah, dan menghapus instans DB tidak berbeda antara instans sesuai permintaan dan cadangan. Saat menghitung tagihan Anda, sistem kami akan secara otomatis menerapkan Pencadangan Anda sedemikian rupa sehingga semua instans DB yang memenuhi syarat dibebankan tarif instans DB per jam yang lebih rendah.

Setiap reservasi terkait dengan seperangkat atribut berikut: mesin DB, kelas instans DB, opsi deployment Multi-AZ, model lisensi, dan Wilayah.

Rerservasi untuk mesin dan model lisensi DB yang memenuhi syarat untuk fleksibilitas ukuran (MySQL, MariaDB, PostgreSQL, Amazon Aurora atau Oracle "Bawa Lisesnsi Anda Sendiri") akan secara otomatis berlaku untuk instans DB ukuran apa pun yang sedang berjalan dalam keluarga instans yang sama (misalnya M4, T2, atau R3) untuk mesin basis data dan Wilayah yang sama. Selain itu, pencadangan juga akan berlaku untuk instans DB yang berjalan di opsi penerapan Single-AZ maupun Multi-AZ.

Contoh, misalkan Anda membeli pencadangan db.m4.2xlarge MySQL. Jika Anda memutuskan untuk menaikkan skala instans DB yang berjalan menjadi a db.m4.4xlarge, tarif potongan harga untuk RI ini akan mencakup 1/2 dari penggunaan instans DB yang lebih besar.

Jika Anda menjalankan mesin atau model lisensi mesin DB yang tidak memenuhi syarat untuk fleksibilitas ukuran (Microsoft SQL Server atau Oracle "License Included"), masing-masing pencadangan hanya dapat diterapkan ke instans DB dengan atribut yang sama selama jangka waktunya. Jika Anda memutuskan untuk memodifikasi salah satu atribut instans DB Anda yang sedang berjalan sebelum akhir jangka waktu pencadangan, tarif penggunaan per jam Anda untuk instans DB tersebut akan kembali ke tarif per jam pesanan.

Untuk detail selengkapnya tentang fleksibilitas ukuran, lihat Panduan Pengguna Amazon RDS.

Masing-masing instans cadangan terkait dengan Wilayah tertentu, yang tetap untuk masa berlaku pencadangan dan tidak dapat diubah. Namun, setiap pencadangan dapat digunakan di AZ mana pun yang tersedia dalam Region terkait.

Ya. Ketika Anda membeli instans cadangan, Anda dapat memilih opsi Multi-AZ di konfigurasi instans DB yang tersedia untuk pembelian. Selain itu, jika Anda menggunakan mesin DB dan model lisensi yang mendukung fleksibilitas ukuran instans terpesan, instans terpesan Multi-AZ akan mencakup penggunaan untuk dua instans DB AZ Tunggal.

Reservasi instans DB dapat diterapkan ke replika baca, selama kelas dan Wilayah instans DB sama. Saat menghitung tagihan Anda, sistem kami akan secara otomatis menerapkan Pencadangan Anda sedemikian rupa sehingga semua instans DB yang memenuhi syarat dibebankan tarif instans cadangan per jam yang lebih rendah.

Tidak, Anda tidak dapat membatalkan instans DB cadangan Anda dan pembayaran satu kali (jika berlaku) tidak dapat dikembalikan. Anda akan terus membayar untuk setiap jam selama jangka waktu instans DB Cadangan Anda, terlepas dari penggunaan oleh Anda.

Ketika Anda membeli RI dengan opsi pembayaran Semua Biaya di Muka, Anda membayar untuk seluruh jangka waktu RI dalam satu pembayaran di muka. Anda dapat memilih untuk tidak membayar apa pun di muka dengan memilih opsi Tanpa Biaya di Muka. Seluruh nilai RI Tanpa Biaya di Muka tersebar di setiap jam dalam jangka waktu dan Anda akan ditagih untuk setiap jam dalam jangka waktu tersebut, terlepas dari penggunaannya. Opsi pembayaran Sebagian di Muka merupakan penggabungan opsi Semua Biaya di Muka dan Tanpa Biaya di Muka. Anda melakukan pembayaran kecil di muka, dan Anda ditagih tarif per jam yang rendah untuk setiap jam dalam jangka waktu terlepas dari penggunaan.

Untuk memilih kelas dan kapasitas penyimpanan instans DB awal, Anda akan menilai kebutuhan komputasi, memori, serta penyimpanan aplikasi. Untuk informasi tentang kelas instans DB yang tersedia, lihat Panduan Pengguna Amazon RDS.

Anda dapat menskalakan sumber daya komputasi dan kapasitas penyimpanan yang dialokasikan untuk instans DB dengan Konsol Manajemen AWS (memilih instans DB yang diinginkan dan mengeklik tombol Modifikasi), API Amazon RDS, atau AWS Command Line Interface. Memori dan sumber daya CPU dimodifikasi dengan cara mengubah kelas instans DB Anda, dan penyimpanan yang tersedia diubah ketika Anda memodifikasi alokasi penyimpanan. 

Harap perhatikan bahwa ketika Anda memodifikasi kelas atau penyimpanan yang dialokasikan Instans DB Anda, perubahan yang Anda minta akan diterapkan selama periode pemeliharaan yang ditentukan. Cara lainnya, Anda dapat menggunakan bendera "terapkan segera" untuk segera menerapkan permintaan penskalaan Anda. Ingat bahwa perubahan sistem yang tertunda lainnya juga akan diterapkan.

Beberapa RDS untuk instans SQL Server mungkin tidak layak untuk penyimpanan yang dikembangkan. Lihat FAQ RDS for SQL Server untuk informasi selengkapnya.

Amazon RDS menggunakan volume EBS untuk penyimpanan log dan database. Tergantung ukuran penyimpanan yang diminta, Amazon RDS secara otomatis terbagi di beberapa volume EBS untuk meningkatkan kinerja IOPS. Untuk MySQL dan Oracle, untuk instans DB yang sudah ada, Anda dapat melihat beberapa penyempurnaan kapasitas I/O jika menaikkan skala penyimpanan. Anda dapat menskalakan kapasitas penyimpanan yang dialokasikan ke instans DB menggunakan Konsol Manajemen AWS, API ModifyDBInstance, atau perintah modify-db-instance.

Untuk informasi selengkapnya, lihat Penyimpanan untuk Amazon RDS.

Kapasitas penyimpanan yang dialokasikan untuk instans DB Anda dapat ditingkatkan ketika menjaga ketersediaan instans DB. Namun, saat Anda memutuskan untuk menaikkan atau menurunkan skala sumber daya komputasi yang tersedia untuk instans DB, basis data Anda untuk sementara tidak akan tersedia saat kelas instans DB diubah. Periode ketidaktersediaan ini biasanya hanya berlangsung beberapa menit, dan akan terjadi selama periode pemeliharaan untuk Instans DB, kecuali Anda menetapkan bahwa perubahan harus segera diterapkan.

Amazon RDS mendukung variasi kelas instans DB dan alokasi penyimpanan untuk memenuhi kebutuhan aplikasi yang berbeda. Jika aplikasi memerlukan sumber daya yang lebih besar dari kelas instans DB terbesar atau penyimpanan yang lebih banyak dari alokasi maksimal, Anda dapat mengimplementasikan partisi, dan menyebarkan data di beberapa instans DB.

Penyimpanan Tujuan Umum (SSD) Amazon RDS cocok untuk berbagai beban kerja basis data yang memiliki persyaratan I/O moderat. Dengan dasar 3 IOPS/GB dan kemampuan untuk mencapai hingga 3.000 IOPS, opsi penyimpanan ini memberikan kinerja yang dapat diprediksi untuk memenuhi kebutuhan sebagian besar aplikasi.

Penyimpanan IOPS yang Tersedia (SSD) Amazon RDS adalah opsi penyimpanan dengan dukungan SSD yang didesain untuk memberikan performa I/O yang cepat, dapat diprediksi, dan konsisten. Dengan Penyimpanan IOPS yang Tersedia (SSD) Amazon RDS, Anda dapat menentukan tarif IOPS ketika membuat instans DB, dan Amazon RDS menyediakan IOPS tersebut untuk masa berlaku instans DB. Penyimpanan IOPS yang Tersedia (SSD) Amazon RDS dioptimalkan untuk beban kerja basis data I/O-intensif dan transaksional (OLTP). Untuk detail selengkapnya, lihat Panduan Pengguna Amazon RDS.

Amazon RDS Magnetic Storage berguna untuk beban kerja basis data kecil di mana data jarang diakses. Penyimpanan magnetik tidak disarankan untuk instans database produksi.

Pilih jenis penyimpanan yang paling cocok dengan beban kerja Anda.

• Beban kerja OLTP performa tinggi: Penyimpanan IOPS yang Tersedia (SSD) Amazon RDS
• Beban kerja database dengan persyaratan I/O sedang: Penyimpanan General Purpose (SSD) Amazon RDS

IOPS yang didukung oleh Amazon RDS bervariasi berdasarkan mesin database. Untuk detail selengkapnya, lihat Panduan Pengguna Amazon RDS.

Amazon RDS menyediakan dua metode berbeda untuk membuat cadangan serta memulihkan pencadangan otomatis dan snapshot basis data (Snapshot DB) instans DB Anda.

Fitur pencadangan otomatis Amazon RDS memungkinkan pemulihan titik waktu instans DB Anda. Ketika cadangan otomatis diaktifkan untuk Instans DB Anda, Amazon RDS secara otomatis melakukan pengambilan snapshot harian data secara penuh (selama periode cadangan pilihan Anda) dan menangkap log transaksi (ketika pembaruan ke Instans DB dibuat). Saat Anda memulai pemulihan titik waktu, log transaksi diterapkan ke cadangan harian yang paling tepat untuk memulihkan instans DB ke waktu tertentu yang Anda minta. 

Amazon RDS menyimpan cadangan dari Instans DB untuk periode waktu terbatas yang ditentukan oleh pengguna yang disebut periode penyimpanan, yang secara default adalah 7 hari tetapi dapat diatur hingga 35 hari. Anda dapat memulai pemulihan titik waktu dan menentukan setiap detik selama periode penyimpanan Anda, hingga Waktu Pemulihan Terkini. Anda dapat menggunakan API DescribeDBInstances untuk mengembalikan waktu pemulihan terbaru bagi instans DB Anda, yang biasanya berlangsung dalam lima menit terakhir. 

Cara lainnya, Anda dapat menemukan Waktu Pemulihan Terkini untuk instans DB dengan memilihnya di Konsol Manajemen AWS dan mencari tab “Deskripsi” di panel bawah Konsol.

Snapshot DB dimulai oleh pengguna dan memungkinkan Anda mencadangkan instans DB dalam keadaan yang diketahui sesering yang diinginkan, lalu mengembalikan ke keadaan tertentu tersebut kapan pun. Snapshot DB dapat dibuat dengan Konsol Manajemen AWS, API CreateDBSnapshot, atau perintah buat-snapshot-db, dan disimpan hingga Anda menghapusnya secara eksplisit.

Snapshot yang dilakukan oleh Amazon RDS untuk mengaktifkan pencadangan otomatis tersedia untuk Anda salin (menggunakan konsol AWS atau perintah copy-db-snapshot) atau untuk fungsionalitas pemulihan snapshot. Anda dapat mengidentifikasinya menggunakan Jenis Snapshot "otomatis". Selain itu, Anda dapat mengidentifikasi waktu di mana snapshot telah diambil dengan melihat kolom "Waktu Pembuatan Snapshot". 

Cara lainnya, pengenal snapshot "otomatis" juga berisi waktu (dalam UTC) saat snapshot diambil.

Harap diingat: Ketika Anda melakukan operasi pemulihan ke titik waktu atau dari Snapshot DB, Instans DB baru dibuat dengan endpoint yang baru (Instans DB lama dapat dihapus jika diinginkan). Hal ini dilakukan untuk memungkinkan Anda membuat beberapa Instans DB dari Snapshot DB atau titik waktu spesifik.

Secara default, Amazon RDS mengaktifkan pencadangan otomatis untuk Instans DB Anda dengan periode retensi 7 hari. Jika ingin mengubah periode retensi pencadangan, Anda dapat melakukannya menggunakan Konsol RDS, API CreateDBInstance (saat membuat instans DB baru), atau API ModifyDBInstance (untuk instans yang ada). Anda dapat menggunakan metode ini untuk mengubah parameter RetentionPeriod ke jumlah berapa pun mulai dari 0 (yang akan menonaktifkan pencadangan otomatis) hingga jumlah hari yang diinginkan, maksimal 35. Nilai tidak dapat diatur ke 0 jika instans DB merupakan sumber untuk Replika Baca. Untuk informasi selengkapnya tentang pencadangan otomatis, lihat Panduan Pengguna Amazon RDS.

Periode cadangan yang diinginkan adalah periode waktu yang ditentukan pengguna selama instans DB Anda dicadangkan. Amazon RDS menggunakan cadangan data periodik yang berkaitan dengan log transaksi untuk memungkinkan Anda memulihkan Instans DB Anda ke detik mana pun selama periode penyimpanan, hingga LatestRestorableTime (biasanya hingga beberapa menit terakhir). Selama periode pencadangan, I/O penyimpanan mungkin ditangguhkan sesaat ketika proses pencadangan dimulai (biasanya dalam beberapa detik) dan Anda mungkin mengalami periode singkat peningkatan latensi. Tidak ada penangguhan I/O untuk penerapan DB Multi-AZ, karena cadangan diambil dari standby.

Snapshot DB Amazon RDS dan cadangan otomatis disimpan di S3.

Anda dapat menggunakan Konsol Manajemen AWS, API ModifyDBInstance, atau perintah ubah-instans-db untuk mengatur periode waktu penyimpanan cadangan otomatis Anda dengan mengubah parameter RetentionPeriod. Jika Anda ingin menonaktifkan cadangan otomatis seluruhnya, Anda dapat melakukannya dengan mengatur periode penyimpanan ke 0 (tidak disarankan). Anda dapat mengelola Snapshot DB buatan pengguna melalui bagian “Snapshot” Konsol Amazon RDS. Atau, Anda dapat melihat daftar Snapshot DB buatan pengguna untuk Instans DB tertentu menggunakan API DescribeDBSnapshots atau perintah describe-db-snapshots dan menghapus snapshot dengan API DeleteDBSnapshot atau perintah delete-db-snapshot.

Hal yang normal untuk memiliki lebih banyak 1 atau 2 snapshot DB otomatis daripada jumlah hari dalam periode penyimpanan Anda. Satu snapshot otomatis ekstra disimpan untuk memastikan kemampuan melakukan pemulihan titik waktu kapan pun selama periode penyimpanan.

Contohnya, jika periode pencadangan Anda diatur ke 1 hari, Anda akan memerlukan 2 snapshot otomatis untuk mendukung pemulihan dalam 24 jam sebelumnya. Anda juga mungkin melihat snapshot otomatis tambahan karena snapshot otomatis baru selalu dibuat sebelum snapshot otomatis paling lama dihapus.

Ketika Anda menghapus instans DB, Anda dapat membuat snapshot DB terakhir saat penghapusan; jika Anda melakukannya, Anda dapat menggunakan snapshot DB ini untuk memulihkan instans DB yang dihapus di kemudian hari. Amazon RDS menyimpan snapshot DB buatan pengguna terakhir ini bersama dengan semua snapshot DB yang dibuat secara manual setelah instans DB dihapus. Lihat halaman harga untuk detail biaya penyimpanan cadangan.

Cadangan otomatis dihapus ketika instans DB dihapus. Hanya Snapshot DB yang dibuat secara manual yang disimpan setelah Instans DB dihapus.

Amazon VPC memungkinkan Anda membuat lingkungan jaringan virtual di bagian AWS cloud yang privat dan terisolasi, di mana Anda dapat melakukan kontrol penuh atas beberapa aspek, seperti rentang alamat IP privat, subnet, tabel perutean, serta gateway jaringan. Dengan Amazon VPC, Anda dapat menentukan topologi jaringan virtual dan menyesuaikan konfigurasi jaringan agar mirip dengan jaringan IP tradisional yang mungkin Anda operasikan di pusat data Anda sendiri.

Salah satu cara Anda dapat memanfaatkan VPC adalah ketika Anda ingin menjalankan aplikasi web publik sekaligus masih mempertahankan server backend yang tidak dapat diakses publik di subnet privat. Anda dapat membuat subnet publik untuk server web yang memiliki akses ke Internet, dan menempatkan Instans DB Amazon RDS backend dalam subnet privat tanpa akses Internet. Untuk informasi selengkapnya tentang Amazon VPC, lihat Panduan Pengguna Amazon Virtual Private Cloud.

Jika akun AWS Anda dibuat sebelum 04-12-2013, Anda mungkin dapat menjalankan Amazon RDS di lingkungan Amazon Elastic Compute Cloud (EC2)-Classic. Fungsionalitas dasar Amazon RDS adalah sama terlepas dari apakah yang digunakan adalah EC2-Classic atau EC2-VPC. Amazon RDS mengelola cadangan, patching perangkat lunak, deteksi kegagalan otomatis, replika baca, dan pemulihan, baik ketika Instans DB Anda di-deploy di dalam atau di luar VPC. Untuk informasi selengkapnya tentang perbedaan antara EC2-Classic dan EC2-VPC, lihat dokumentasi EC2.

Grup Subnet DB adalah kumpulan subnet yang mungkin ingin Anda tetapkan untuk Instans DB Amazon RDS dalam VPC. Setiap Grup Subnet DB harus memiliki setidaknya satu subnet untuk setiap Zona Ketersediaan di Wilayah yang diberikan. Ketika membuat Instans DB di VPC, Anda perlu memilih Grup Subnet DB. Amazon RDS kemudian menggunakan Grup Subnet DB tersebut dan Availability Zone yang Anda pilih untuk memilih subnet dan alamat IP dalam subnet tersebut. Amazon RDS membuat dan menghubungkan Elastic Network Interface ke Instans DB Anda dengan alamat IP tersebut.

Perhatikan bahwa kami sangat merekomendasikan agar Anda menggunakan Nama DNS untuk terhubung dengan Instans DB karena alamat IP dasar dapat berubah (misalnya, selama failover).

Untuk deployment Multi-AZ, menentukan subnet untuk semua Zona Ketersediaan di Wilayah akan mengizinkan Amazon RDS untuk membuat standby baru dalam Zona Ketersediaan lain jika diperlukan. Anda perlu melakukan ini bahkan untuk penerapan Single-AZ, jika Anda ingin mengonversikannya ke penerapan Multi-AZ di beberapa titik.

Untuk prosedur yang memandu Anda dalam proses ini, lihat Membuat Instans DB di VPC di Panduan Pengguna Amazon RDS.

Kunjungi bagian Grup Keamanan pada Panduan Pengguna Amazon RDS untuk mempelajari perbedaan cara mengontrol akses ke Instans DB Anda.

Instans DB yang di-deploy dalam VPC dapat diakses oleh Instans EC2 yang di-deploy dalam VPC yang sama. Jika Instans EC2 diterapkan dalam subnet dengan Elastic IP terkait, Anda dapat mengakses Instans EC2 melalui internet. Instans DB yang di-deploy dalam VPC dapat diakses dari Internet atau dari Instans EC2 di luar VPC melalui VPN atau host bastion yang dapat Anda luncurkan di subnet publik, atau menggunakan opsi Dapat Diakses Publik dari Amazon RDS:

• Untuk menggunakan host bastion, Anda perlu menyiapkan subnet publik dengan instans EC2 yang bertindak sebagai Bastion SSH. Subnet publik ini harus memiliki gateway internet dan peraturan perutean yang memungkinkan lalu lintas untuk diarahkan melalui host SSH, yang kemudian harus meneruskan permintaan ke alamat IP privat dari instans DB Amazon RDS Anda.
• Untuk menggunakan konektivitas publik, cukup buat instans DB Anda dengan mengatur opsi yang Dapat Diakses Publik ke ya. Dengan Dapat Diakses Publik yang aktif, Instans DB dalam VPC akan sepenuhnya dapat diakses dari luar VPC secara default. Ini berarti Anda tidak perlu mengonfigurasi VPN atau host bastion untuk mengizinkan akses ke instans Anda.

Anda juga dapat mengatur Gateway VPN yang memperpanjang jaringan perusahaan ke VPC Anda dan mengizinkan akses ke instans DB Amazon RDS dalam VPC tersebut. Lihat Panduan Pengguna Amazon VPC untuk detail selengkapnya.

Kami sangat menyarankan Anda menggunakan Nama DNS agar dapat terhubung dengan Instans DB Anda karena alamat IP dasar dapat berubah (misalnya selama failover).

Jika instans DB Anda tidak berada di dalam VPC, Anda dapat menggunakan AWS Management Console untuk dengan mudah memindahkan instans DB ke VPC. Lihat Panduan Pengguna Amazon RDS untuk detail selengkapnya. Anda juga dapat mengambil snapshot Instans DB di luar VPC dan mengembalikannya ke VPC dengan menentukan Grup Subnet DB yang ingin digunakan. Selain itu, Anda juga dapat melakukan operasi “Pulihkan ke Titik Waktu”.

Migrasi Instans DB dari dalam ke luar VPC tidak didukung. Untuk alasan keamanan, Snapshot DB dari Instans DB di dalam VPC tidak dapat dikembalikan ke luar VPC. Hal yang sama berlaku dengan fungsi “Kembalikan ke Titik Waktu”. 

Anda bertanggung jawab untuk memodifikasi tabel perutean dan ACL jaringan dalam VPC untuk memastikan bahwa instans DB Anda dapat dijangkau dari instans klien di VPC. Untuk deployment Multi-AZ, setelah failover, instans EC2 dan Instans DB Amazon RDS klien Anda mungkin berada di Zona Ketersediaan yang berbeda. Anda harus mengonfigurasi ACL jaringan untuk memastikan bahwa komunikasi antar-AZ dimungkinkan.

Grup Subnet DB yang sudah ada dapat diperbarui untuk menambah subnet, baik untuk Availability Zone yang sudah ada maupun Availability Zone baru yang ditambahkan sejak pembuatan Instans DB. Menghapus subnet dari Grup Subnet DB yang sudah ada dapat menyebabkan ketidaktersediaan instans jika instan tersebut berjalan di AZ tertentu yang dihapus dari grup subnet. Lihat Panduan Pengguna Amazon RDS untuk informasi selengkapnya.

Untuk mulai menggunakan Amazon RDS Anda akan memerlukan akun developer AWS. Jika Anda tidak memiliki akun sebelum daftar ke Amazon RDS, Anda akan diminta untuk membuat akun ketika Anda memulai proses pendaftaran. Akun pengguna primer berbeda dari akun developer AWS dan digunakan hanya dalam konteks Amazon RDS untuk mengontrol akses ke Instans DB Anda. Akun pengguna primer adalah akun pengguna basis data asli yang dapat Anda gunakan untuk terhubung ke Instans DB Anda. 

Anda dapat menentukan nama pengguna primer dan kata sandi yang ingin Anda kaitkan dengan masing-masing Instans DB ketika Anda membuat Instans DB. Setelah Anda membuat Instans DB, Anda dapat terhubung ke basis data menggunakan kredensial pengguna primer. Kemudian, Anda juga mungkin ingin membuat akun pengguna tambahan sehingga Anda dapat membatasi siapa yang dapat mengakses Instans DB Anda.

Untuk MySQL, hak istimewa default untuk pengguna primer meliputi: opsi buat, drop, referensi, peristiwa, ubah, hapus, indeks, sisipkan, pilih, perbarui, buat tabel sementara, kunci tabel, memicu, buat tampilan, tampilkan tampilan, ubah rutinitas, buat rutinitas, eksekusi, picu, buat pengguna, proses, tunjukkan basis data, dan izinkan.

Untuk Oracle, pengguna primer diberikan peran "dba". Pengguna primer menerima sebagian besar hak istimewa yang terkait dengan peran tersebut. Lihat Panduan Pengguna Amazon RDS untuk daftar hak istimewa terbatas dan alternatif yang terkait guna melakukan tugas administratif yang mungkin memerlukan hak istimewa ini.

Untuk SQL Server, pengguna yang membuat database diberikan peran "db_owner". Lihat Panduan Pengguna Amazon RDS untuk daftar hak istimewa terbatas dan alternatif yang terkait guna melakukan tugas administratif yang mungkin memerlukan hak istimewa ini.

Tidak, semuanya bekerja dengan cara yang Anda ketahui ketika menggunakan database relasional yang Anda kelola sendiri.

Ya. Anda harus dengan sengaja mengaktifkan kemampuan untuk mengakses basis data melalui internet dengan mengonfigurasi Grup Keamanan. Anda dapat melakukan otorisasi akses hanya untuk IP spesifik, rentang IP, atau subnet yang terkait dengan server di pusat data Anda sendiri.

Ya, opsi ini didukung untuk semua mesin Amazon RDS. Amazon RDS menghasilkan sertifikat SSL/TLS untuk setiap Instans DB. Setelah koneksi terenkripsi terjalin, data yang ditransfer antara Instans DB dan aplikasi Anda akan dienkripsi selama transfer.

Walau SSL menawarkan manfaat keamanan, perlu diketahui bahwa enkripsi SSL/TLS merupakan operasi komputasi yang intensif dan akan meningkatkan latensi koneksi database Anda. Dukungan SSL/TLS dalam Amazon RDS adalah untuk mengenkripsi koneksi antara aplikasi dan Instans DB Anda; sehingga tidak boleh diandalkan untuk mengautentikasi Instans DB itu sendiri.

Untuk detail pembuatan koneksi terenkripsi dengan Amazon RDS, kunjungi Panduan Pengguna MySQL, Panduan Pengguna MariaDB,Panduan Pengguna PostgreSQL, atau Panduan Pengguna Oracle Amazon RDS. Untuk mempelajari selengkapnya tentang cara kerja SSL/TLS dengan mesin ini, Anda dapat melihat langsung ke dokumentasi MySQL, dokumentasi MariaDB, dokumentasi SQL Server MSDN, dokumentasi PostgreSQL, atau Dokumentasi Oracle.

Amazon RDS mendukung enkripsi saat diam untuk semua mesin basis data, dengan kunci yang Anda kelola menggunakan AWS Key Management Service (KMS). Pada instans basis data yang berjalan dengan enkripsi Amazon RDS, data yang disimpan saat diam di penyimpanan dasar dienkripsi, begitu juga cadangan otomatis, replika baca, dan snapshotnya. Enkripsi dan dekripsi ditangani secara transparan. Untuk informasi selengkapnya tentang penggunaan KMS dengan Amazon RDS, lihat Panduan Pengguna Amazon RDS.

Anda juga dapat menambahkan enkripsi ke instans DB atau klaster DB yang sebelumnya tidak terenkripsi dengan membuat snapshot DB lalu membuat salinan snapshot tersebut dan menentukan kunci enkripsi KMS. Kemudian Anda dapat mengembalikan instans DB atau klaster DB yang terenkripsi menggunakan snapshot terenkripsi.

Amazon RDS for Oracle dan SQL Server mendukung teknologi Enkripsi Data Transparan (TDE) dari mesin tersebut. Untuk informasi selengkapnya, lihat Panduan Pengguna Amazon RDS untuk Oracle dan SQL Server.

Anda dapat mengontrol tindakan yang dapat diambil oleh pengguna dan grup AWS IAM pada sumber daya Amazon RDS. Hal ini dapat dilakukan dengan mereferensikan sumber daya Amazon RDS di kebijakan AWS IAM yang Anda terapkan ke pengguna dan grup. Sumber daya Amazon RDS yang dapat direferensikan dalam kebijakan AWS IAM meliputi instans DB, snapshot DB, replika baca, grup keamanan DB, grup opsi DB, grup parameter DB, langganan peristiwa, dan grup subnet DB. 

Selain itu, Anda dapat memberi tanda pada sumber daya ini untuk menambahkan metadata tambahan ke sumber daya Anda. Dengan menggunakan tag, Anda dapat mengategorikan sumber daya (misalnya, Instans DB "Pengembangan", Instans DB "Produksi", dan Instans DB "Uji"), serta menulis kebijakan AWS IAM yang mencantumkan izin (yaitu tindakan) yang dapat diambil untuk sumber daya dengan tanda yang sama. Untuk informasi selengkapnya, lihat Penandaan Sumber Daya Amazon RDS.

Ya. AWS CloudTrail adalah layanan web yang merekam panggilan API AWS untuk akun Anda dan mengirimkan file log kepada Anda. Riwayat panggilan API AWS yang dihasilkan oleh CloudTrail memungkinkan analisis keamanan, pelacakan perubahan sumber daya, dan audit kepatuhan. 

Ya, semua mesin basis data Amazon RDS memenuhi syarat HIPAA, sehingga Anda dapat menggunakannya untuk membuat aplikasi yang sesuai dengan HIPAA dan menyimpan informasi terkait kesehatan, termasuk informasi kesehatan yang dilindungi (PHI) di bawah Business Associate Agreement (BAA) dengan AWS.

Jika Anda telah memiliki BAA yang telah dilaksanakan, tidak ada tindakan yang perlu dilakukan untuk mulai menggunakan layanan ini di akun yang dicakup oleh BAA Anda. Jika Anda tidak memiliki BAA yang telah dijalankan dengan AWS, atau memiliki pertanyaan lain tentang aplikasi yang sesuai dengan HIPAA pada AWS, silakan hubungi manajer akun kami.

Secara default, Amazon RDS memilih parameter konfigurasi optimal untuk Instans DB Anda dengan mempertimbangkan kelas instans dan kapasitas penyimpanan. Namun, jika Anda ingin mengubahnya, Anda dapat melakukannya dengan AWS Management Console, API Amazon RDS, atau AWS Command Line Interface. Perhatikan bahwa mengubah parameter konfigurasi dari nilai yang direkomendasikan dapat menimbulkan akibat yang tidak diinginkan, mulai dari penurunan performa hingga kerusakan sistem, dan hanya boleh dilakukan oleh pengguna tingkat lanjut yang siap menanggung risiko ini.

Grup parameter database (Grup Parameter DB) bertindak sebagai “kontainer” untuk nilai konfigurasi mesin yang dapat diterapkan ke satu atau beberapa Instans DB. Jika Anda membuat Instans DB tanpa menentukan Grup Parameter DB, Grup Parameter DB default akan digunakan. Grup default ini berisi default mesin dan default sistem Amazon RDS yang dioptimalkan untuk Instans DB yang Anda jalankan.

Namun, jika Anda ingin Instans DB Anda berjalan dengan nilai konfigurasi mesin yang Anda tentukan secara khusus, Anda cukup membuat Grup Parameter DB baru, memodifikasi parameter yang diinginkan, dan memodifikasi Instans DB untuk menggunakan Grup Parameter DB yang baru. Setelah terhubung, semua Instans DB yang menggunakan Grup Parameter DB tertentu mendapatkan semua pembaruan parameter untuk Grup Parameter DB tersebut.

Untuk informasi selengkapnya tentang mengonfigurasi Grup Parameter DB, silakan baca Panduan Pengguna Amazon RDS.

Anda dapat menggunakan AWS Config untuk terus mencatat perubahan konfigurasi untuk Instans DB, Grup Subnet DB, Snapshot DB, Grup Keamanan DB, dan Langganan Peristiwa Amazon RDS, serta menerima notifikasi perubahan melalui Amazon Simple Notification Service (SNS). Anda juga dapat membuat Peraturan AWS Config untuk mengevaluasi apakah sumber daya Amazon RDS ini memiliki konfigurasi yang diinginkan.

Ketika membuat atau memodifikasi instans DB Anda untuk dijalankan sebagai deployment Multi-AZ, Amazon RDS secara otomatis menyediakan dan mempertahankan replika “standby” yang sinkron di Zona Ketersediaan yang berbeda. Pembaruan untuk Instans DB Anda direplikasi secara sinkronis di Zona Ketersediaan ke standby untuk menjaga agar tetap sinkron dan melindungi pembaruan terkini basis data Anda dari kegagalan instans DB. 

Selama jenis pemeliharaan terencana tertentu, atau dalam hal yang tidak mungkin terjadi kegagalan instans DB atau Kegagalan Availability Zone, Amazon RDS akan secara otomatis mengalami failover ke standby sehingga Anda dapat melanjutkan database tulis dan baca segera setelah standby dipromosikan. Karena catatan nama untuk instans DB Anda tetap sama, aplikasi Anda dapat melanjutkan operasi basis data tanpa perlu intervensi administratif manual. Dengan deployment Multi-AZ, replikasi menjadi transparan. Anda tidak berinteraksi langsung dengan standby, dan tidak dapat digunakan untuk melayani lalu lintas baca. Informasi selengkapnya tentang deployment Multi-AZ ada di Panduan Pengguna Amazon RDS.

Zona Ketersediaan adalah lokasi yang berbeda dalam suatu Wilayah yang dirancang untuk diisolasi dari kegagalan di Zona Ketersediaan lainnya. Setiap Availability Zone berjalan di infrastruktur independen dan jauh secara fisik, dan dibuat agar dapat sangat diandalkan. Titik kegagalan umum seperti generator dan peralatan pendingin tidak dibagikan di Zona Ketersediaan. Selain itu, Zona Ketersediaan terpisah secara fisik, sehingga bencana alam yang sangat tidak biasa seperti kebakaran, tornado, atau banjir hanya akan memengaruhi satu Zona Ketersediaan. Zona Ketersediaan dalam Region yang sama mendapat manfaat dari konektivitas jaringan rendah latensi.

Ketika Anda menjalankan instans DB sebagai penerapan Multi-AZ, “primer” melayani tulis dan baca database. Selain itu, Amazon RDS menyediakan dan mempertahankan “standby” di belakang layar, yang merupakan replika terbaru dari primer. Standby “promoted”dalam skenario failover. Setelah failover, standby menjadi primer dan menerima operasi database Anda. Anda tidak berinteraksi secara langsung dengan standby (misalnya untuk operasi baca) dalam hal apa pun sebelum promosi. Jika Anda tertarik dengan penskalaan lalu lintas baca di luar batasan kapasitas dari satu instans DB, lihat FAQ di Replika Baca.

Manfaat utama menjalankan instans DB Anda sebagai penerapan Multi-AZ adalah peningkatan ketahanan dan ketersediaan database. Peningkatan ketersediaan dan toleransi kesalahan yang ditawarkan oleh penerapan Multi-AZ membuatnya cocok untuk lingkungan produksi.
 

Menjalankan instans DB Anda sebagai penerapan Multi-AZ akan melindungi data Anda dari kejadian tidak mungkin dari kegagalan komponen instans DB atau hilangnya ketersediaan dalam satu Availability Zone. Contohnya, jika volume penyimpanan pada primer Anda gagal, Amazon RDS secara otomatis memulai failover ke standby, di mana semua pembaruan database Anda lengkap. Hal ini memberikan ketahanan data tambahan relatif terhadap penerapan standar dalam AZ tunggal, di mana operasi pemulihan yang dimulai pengguna akan diperlukan dan pembaruan yang terjadi setelah waktu restorasi terakhir (biasanya dalam lima menit terakhir) tidak akan tersedia.

Anda juga mendapatkan manfaat dari ketersediaan database yang meningkat ketika menjalankan instans DB Anda sebagai penerapan Multi-AZ. Jika kegagalan Availability Zone atau kegagalan instans DB terjadi, pengaruh ketersediaan Anda terbatas pada waktu yang diperlukan untuk menyelesaikan failover otomatis. Manfaat ketersediaan Multi-AZ juga diperpanjang ke pemeliharaan terencana.

Contohnya, dengan cadangan otomatis, aktivitas I/O tidak lagi ditangguhkan pada akun primer Anda selama periode cadangan yang Anda pilih, karena cadangan diambil dari standby. Dalam hal patching atau penskalaan kelas instans DB, operasi ini terjadi lebih dahulu pada standby sebelum failover otomatis. Hasilnya, pengaruh ketersediaan Anda terbatas pada waktu yang diperlukan untuk menyelesaikan failover otomatis.

Manfaat lain yang tersirat dari menjalankan instans DB Anda sebagai penerapan Multi-AZ adalah bahwa failover instans DB dilakukan otomatis dan tidak memerlukan administrasi. Dalam konteks Amazon RDS, hal ini berarti Anda tidak diminta untuk memonitor kejadian instans DB dan memulai pemulihan instans DB manual (melalui API RestoreDBInstanceToPointInTime atau RestoreDBInstanceFromSnapshot) jika terjadi kegagalan Zona Ketersediaan atau kegagalan instans DB.

Anda dapat mengamati latensi tinggi relatif terhadap penerapan instans DB standar dalam satu Zona Ketersediaan sebagai hasil dari replikasi data sinkronis yang dilakukan untuk Anda.

Tidak, standby Multi-AZ tidak dapat melayani permintaan operasi baca. Penerapan Multi-AZ dirancang untuk memberikan peningkatan ketersediaan dan ketahanan database, bukan untuk manfaat penskalaan baca. Karena itu, fitur ini menggunakan replikasi sinkronis antara primer dan standby. Implementasi kami memastikan bahwa primer dan standby selalu tersinkron, tetapi menghalangi penggunaan standby untuk operasi baca atau tulis. Jika Anda tertarik dengan solusi penskalaan baca, lihat FAQ pada Replika Baca.

Untuk membuat deployment instans DB Multi-AZ, cukup klik opsi “Ya” untuk “Deployment Multi-AZ” saat meluncurkan Instans DB dengan Konsol Manajemen AWS.

Atau, jika Anda menggunakan API Amazon RDS, Anda akan memanggil API CreateDBInstance dan mengatur parameter “Multi-AZ” ke nilai “benar”. Untuk mengonversi instans DB standar (AZ tunggal) yang sudah ada, modifikasi instans DB di Konsol Manajemen AWS atau gunakan API ModifyDBInstance dan atur parameter Multi-AZ ke benar.

Untuk mesin basis data RDS for PostgreSQL, RDS for MySQL, RDS for MariaDB, RDS for SQL Server, RDS for Oracle, dan RDS for Db2, saat Anda memilih untuk mengonversi instans Amazon RDS dari AZ Tunggal ke Multi-AZ, hal-hal berikut akan terjadi:

• Snapshot instans primer Anda diambil.
• Instans standby baru dibuat di Availability Zone yang berbeda dari snapshot.
• Replikasi sinkronis dikonfigurasi antara instans primer dan standby.

Dengan demikian, seharusnya tidak ada waktu henti yang terjadi ketika instans dikonversi dari Single-AZ ke Multi-AZ. Namun, Anda mungkin melihat latensi yang meningkat saat data pada standby ditangkap untuk disesuaikan dengan primer.

Amazon RDS mendeteksi dan pulih secara otomatis dari skenario kegagalan paling umum untuk penerapan Multi-AZ sehingga Anda dapat melanjutkan operasi database sesegera mungkin tanpa intervensi administratif. Amazon RDS secara otomatis melakukan failover jika terjadi hal-hal berikut:

• Kehilangan ketersediaan dalam Zona Ketersediaan primer
• Kehilangan konektivitas jaringan ke primer
• Kegagalan unit komputasi pada primer
• Kegagalan penyimpanan pada primer

Catatan: Ketika operasi seperti penskalaan instans DB atau pemutakhiran sistem seperti patching OS dimulai untuk deployment Multi-AZ, untuk peningkatan ketersediaan, operasi tersebut diterapkan terlebih dahulu pada standby sebelum failover otomatis. Hasilnya, pengaruh ketersediaan Anda terbatas hanya pada waktu yang diperlukan untuk menyelesaikan failover otomatis. Perhatikan bahwa deployment Multi-AZ Amazon RDS tidak secara otomatis melakukan failover dalam merespons operasi basis data seperti kueri yang berjalan lama, kemacetan atau kesalahan kerusakan basis data.

Ya, Amazon RDS akan memancarkan kejadian instans DB untuk memberi tahu Anda bahwa failover otomatis terjadi. Anda dapat mengklik bagian “Kejadian” pada Konsol Amazon RDS atau menggunakan API DescribeEvents untuk mengembalikan informasi mengenai kejadian yang berkaitan dengan instans DB Anda. Anda juga dapat menggunakan Amazon RDS Event Notifications untuk mendapatkan notifikasi saat terjadi peristiwa DB tertentu.

Failover secara otomatis ditangani oleh Amazon RDS sehingga Anda dapat melanjutkan operasi database sesegera mungkin tanpa intervensi administratif. Ketika melakukan failover, Amazon RDS hanya membalikkan catatan nama resmi (CNAME) bagi instans DB Anda untuk menunjuk standby, yang pada saatnya dipromosikan untuk menjadi primer baru. Kami menyarankan Anda untuk mengikuti praktik terbaik dan mengimplementasikan percobaan ulang koneksi database di lapisan aplikasi.

Failover, seperti yang ditentukan oleh interval antara deteksi kegagalan pada primer dan kembalinya transaksi pada standby, biasanya selesai dalam satu hingga dua menit. Waktu failover juga dapat dipengaruhi oleh apakah transaksi besar yang tidak terikat harus dipulihkan; penggunaan jenis database yang cukup besar direkomendasikan dengan Multi-AZ untuk mendapatkan hasil terbaik. AWS juga merekomendasikan penggunaan IOPS Tersedia dengan instans Multi-AZ, untuk kinerja throughput yang cepat, dapat diprediksi, dan konsisten.

Amazon RDS akan secara otomatis melakukan failover tanpa intervensi pengguna pada variasi kondisi kegagalan. Selain itu, Amazon RDS memberikan opsi untuk memulai failover ketika melakukan boot ulang instans Anda. Anda dapat mengakses fitur ini melalui AWS Management Console atau dengan menggunakan panggilan API RebootDBInstance.

Dengan penerapan Multi-AZ, Anda cukup menyetel parameter “Multi-AZ” menjadi "true". Pembuatan standby, replikasi sinkronis, dan failover seluruhnya ditangani secara otomatis. Hal ini berarti Anda tidak dapat memilih Availability Zone tempat standby Anda diterapkan atau mengubah jumlah standby yang tersedia (Amazon RDS memberikan satu standby khusus untuk setiap primer instans DB). Standby juga tidak dapat dikonfigurasi untuk menerima aktivitas baca database. Pelajari selengkapnya tentang konfigurasi Multi-AZ

Ya. Standby Anda secara otomatis disediakan dalam Zona Ketersediaan yang berbeda dari Wilayah yang sama dengan primer instans DB Anda.

Ya, Anda dapat memperoleh visibilitas tentang lokasi primer saat ini menggunakan Konsol Manajemen AWS atau API DescribeDBInstances.

Availability Zone direkayasa untuk menyediakan konektivitas jaringan latensi rendah ke Availability Zone lainnya di Wilayah yang sama. Selain itu, Anda mungkin ingin mempertimbangkan untuk membuat arsitektur aplikasi Anda dan sumber daya AWS lainnya dengan redundansi di beberapa Availability Zone sehingga aplikasi Anda akan dapat tahan apabila terjadi kegagalan Availability Zone. Penerapan Multi-AZ menjawab kebutuhan ini untuk tingkat database tanpa administrasi di pihak Anda.

Anda berinteraksi dengan fungsi cadangan otomatis dan Snapshot DB dengan cara yang sama baik ketika Anda menjalankan penerapan standar dalam penerapan Single-AZ atau Multi-AZ. Jika Anda menjalankan penerapan Multi-AZ, cadangan otomatis dan Snapshot DB hanya diambil dari standby untuk menghindari penangguhan I/O pada primer. Harap dicatat bahwa Anda mungkin mengalami peningkatan latensi I/O (biasanya berlangsung beberapa menit) selama pencadangan untuk penerapan Single-AZ dan Multi-AZ.

Memulai operasi pemulihan (pemulihan atau pengembalian titik waktu dari Snapshot DB) juga bekerja sama dengan penerapan Multi-AZ sebagai penerapan standar, Single-AZ. Penerapan instans DB baru dapat dibuat dengan API RestoreDBInstanceFromSnapshot atau RestoreDBInstanceToPointInTime. Penerapan instans DB baru ini dapat berupa standar atau Multi-AZ, terlepas apakah pencadangan sumber dimulai pada penerapan standar atau Multi-AZ.

Replika baca memudahkan pemanfaatan fungsi replikasi bawaan mesin yang didukung untuk penskalaan ke luar secara elastis melampaui batasan kapasitas dari suatu Instans DB tunggal untuk beban kerja basis data dengan volume baca yang besar.

Anda dapat membuat replika baca dengan beberapa klik di Konsol Manajemen AWS atau menggunakan API CreateDBInstanceReadReplica. Setelah replika baca dibuat, pembaruan database pada Instans DB sumber akan direplikasi menggunakan replika asinkron asli yang didukung oleh mesin. Anda dapat membuat beberapa replika baca untuk Instans DB sumber tertentu dan mendistribusikan lalu lintas baca aplikasi Anda di antaranya.

Karena replika baca menggunakan replikasi bawaan mesin yang didukung, ia bergantung pada kekuatan dan keterbatasannya. Secara khusus, pembaruan diterapkan pada replika baca Anda setelah terjadi pada instans DB sumber, dan lag replikasi dapat bervariasi secara signifikan. Replika baca dapat dikaitkan dengan deployment Multi-AZ untuk mendapatkan manfaat penskalaan baca selain peningkatan ketersediaan tulis dan ketahanan data yang disediakan oleh deployment Multi-AZ.

Ada berbagai skenario yang mana menerapkan satu atau beberapa replika baca untuk instans DB sumber tertentu mungkin terasa masuk akal. Alasan umum untuk menerapkan replika baca meliputi:

• Penskalaan di luar komputasi atau kapasitas I/O dari suatu instans DB tunggal untuk beban kerja database baca yang besar. Lalu lintas baca berlebih ini dapat diarahkan ke satu atau beberapa replika baca.
• Melayani lalu lintas baca ketika instans DB sumber tidak tersedia. Jika Instans DB sumber Anda tidak dapat mengambil permintaan I/O (misalnya karena penangguhan I/O untuk cadangan atau pemeliharaan terjadwal), Anda dapat mengarahkan lalu lintas baca ke replika baca Anda. Untuk kasus penggunaan ini, perlu diingat bahwa data pada replika baca mungkin “usang” karena Instans DB sumber tidak tersedia.
• Pelaporan bisnis atau skenario pergudangan data. Anda mungkin ingin kueri pelaporan bisnis dijalankan terhadap replika baca, bukan Instans DB produksi primer Anda.
• Anda dapat menggunakan replika baca untuk pemulihan bencana instans DB sumber, di Wilayah AWS yang sama atau di Wilayah lainnya.

Ya. Aktifkan cadangan otomatis pada Instans DB sumber Anda sebelum menambahkan replika baca, dengan mengatur periode retensi cadangan ke nilai selain 0. Cadangan harus tetap diaktifkan agar replika baca dapat bekerja.

Amazon Aurora: Semua klaster DB.

Amazon RDS for MySQL: Semua instans DB mendukung pembuatan replika baca. Cadangan otomatis harus dan tetap diaktifkan pada instans DB sumber untuk operasi replika baca. Cadangan otomatis pada replika hanya didukung untuk replika baca Amazon RDS yang menjalankan MySQL 5.6 dan setelahnya, bukan 5.5.

Amazon RDS for PostgreSQL: Instans DB dengan PostgreSQL versi 9.3.5 atau yang lebih baru mendukung pembuatan replika baca. Instans PostgreSQL yang sudah ada sebelum versi 9.3.5 perlu dimutakhirkan ke PostgreSQL versi 9.3.5 agar dapat memanfaatkan replika baca Amazon RDS.

Amazon RDS for MariaDB: Semua Instans DB mendukung pembuatan replika baca. Cadangan otomatis harus dan tetap diaktifkan pada Instans DB sumber untuk operasi replika baca.

Amazon RDS for Oracle: Mendukung Oracle versi 12.1.0.2.v12 dan yang lebih tinggi dan semua versi 12.2 menggunakan model Bawa Lisensi Anda Sendiri dengan Edisi Korporasi Basis Data Oracle dan berlisensi untuk Opsi Penjaga Data Aktif.

Amazon RDS for SQL Server: Replika baca didukung di Edisi Korporasi dalam konfigurasi Multi-AZ ketika teknologi replikasi yang mendasarinya menggunakan grup ketersediaan Selalu Aktif untuk SQL Server versi 2016 dan 2017.

Anda dapat membuat replika baca dalam hitungan menit menggunakan API CreateDBInstanceReadReplica standar atau beberapa klik pada Konsol Manajemen AWS. Ketika membuat replika baca, Anda dapat mengidentifikasinya sebagai replika baca dengan menentukan SourceDBInstanceIdentifier. SourceDBInstanceIdentifier adalah Pengidentifikasi Instans DB untuk Instans DB “sumber” yang ingin Anda replikasi. Untuk Instans DB standar, Anda juga dapat menentukan Availability Zone, kelas instans DB, dan periode pemeliharaan yang diinginkan. Versi mesin (Mis. PostgreSQL 9.3.5) dan alokasi penyimpanan replika baca diberikan dari instans DB sumber. 

Ketika Anda memulai pembuatan replika baca, Amazon RDS mengambil snapshot instans DB sumber Anda dan memulai replikasi. Hasilnya, Anda akan mengalami penangguhan I/O sesaat pada instans DB sumber Anda ketika snapshot terjadi. Penangguhan I/O biasanya terjadi dalam waktu satu menit, dan akan dihindari jika instans DB sumber adalah deployment Multi-AZ (jika deployment Multi-AZ, snapshot diambil dari standby).

Amazon RDS juga sedang mengerjakan optimasi (akan segera dirilis) sehingga jika Anda membuat beberapa Replika Baca dalam jangka waktu 30 menit, semuanya akan menggunakan snapshot sumber yang sama untuk meminimalkan dampak I/O (“mengejar” replikasi untuk setiap Replika Baca akan dimulai setelah pembuatan).

Anda dapat terhubung ke replika baca sama seperti Anda akan terhubung ke instans DB standar, menggunakan API DescribeDBInstance atau Konsol Manajemen AWS untuk mengambil titik akhir untuk replika baca Anda. Jika Anda memiliki beberapa replika baca, semua tergantung pada aplikasi Anda untuk menentukan bagaimana lalu lintas baca akan didistribusikan di antara mereka.

Amazon RDS for MySQL, MariaDB, dan PostgreSQL memungkinkan Anda membuat hingga 15 replika baca untuk instans DB sumber tertentu. Amazon RDS for Oracle dan SQL Server memungkinkan Anda untuk membuat hingga 5 replika baca untuk instans DB sumber tertentu.

Ya, Amazon RDS (kecuali RDS untuk SQL Server) mendukung replika baca antarwilayah. Jumlah waktu antara ketika data ditulis ke instans DB sumber dan ketika tersedia dalam replika baca akan bergantung pada latensi jaringan antara dua wilayah tersebut.

Tidak. Replika baca di Amazon RDS for MySQL, MariaDB, PostgreSQL, Oracle, dan SQL Server diimplementasikan menggunakan replikasi asinkron native dari mesin-mesin tersebut. Amazon Aurora menggunakan mekanisme replikasi yang berbeda namun tetap asinkron.

Jika Anda ingin menggunakan replikasi untuk meningkatkan ketersediaan tulis database dan melindungi pembaruan database terkini terhadap berbagai kondisi kegagalan, kami merekomendasikan agar Anda menjalankan instans DB sebagai penerapan Multi-AZ. Dengan Replika Baca Amazon RDS, yang menerapkan replikasi asli asinkron yang didukung oleh mesin, penulisan database terjadi pada replika baca setelah terjadi pada instans DB sumber, dan “lag” replikasi ini dapat bervariasi secara signifikan. 

Sebaliknya, replikasi yang digunakan oleh penerapan Multi-AZ bersifat sinkronis, yang berarti bahwa semua penulisan database terjadi bersamaan pada primer dan standby. Hal ini melindungi pembaruan database terbaru Anda, karena harus tersedia pada standby jika failover diperlukan. 

Selain itu, dengan penerapan Multi-AZ, replikasi dikelola penuh. Amazon RDS secara otomatis memantau kondisi kegagalan instans DB atau kegagalan Availability Zone dan menginisiasi failover otomatis ke standby (atau ke replika baca untuk Amazon Aurora) jika terjadi pemadaman.

Ya. Karena instans DB Multi-AZ memenuhi kebutuhan yang berbeda dari replika baca, masuk akal untuk menghubungkan keduanya untuk penerapan produksi dan untuk mengaitkan Replika Baca dengan Penerapan Instans DB Multi-AZ. “Sumber” Instans DB-Multi AZ memberikan ketersediaan tulis dan ketahanan data yang ditingkatkan, dan replika baca yang terkait akan meningkatkan skalabilitas lalu lintas baca.

Ya. Amazon RDS for MySQL, MariaDB, PostgreSQL, and Oracle allow you to enable Multi-AZ configuration on read replicas to support disaster recovery and minimize downtime from engine upgrades.

Jika failover Multi-AZ terjadi, replika baca yang terkait dan tersedia akan melanjutkan replikasi secara otomatis setelah failover selesai (memperoleh pembaruan dari primer yang baru dipromosikan).

Amazon Aurora, Amazon RDS for MySQL, dan MariaDB: Anda dapat membuat tiga tingkatan replika baca. Replika baca tingkat kedua dari replika baca tingkat pertama yang ada dan replika tingkat ketiga dari replika baca tingkat kedua. Dengan membuat replika baca tingkat kedua dan ketiga, Anda akan dapat memindahkan beberapa beban replikasi dari instans basis data utama ke tingkat Replika Baca yang berbeda berdasarkan kebutuhan aplikasi.

Harap diperhatikan bahwa Replika Baca tingkat kedua mungkin tertinggal lebih jauh di belakang primer karena latensi replikasi tambahan yang diperkenalkan sebagai transaksi direplikasi dari primer ke replika tingkat pertama lalu ke replika tingkat kedua. Demikian pula, replika tingkat ketiga mungkin tertinggal dari replika baca tingkat kedua.

Amazon RDS for Oracle dan Amazon RDS for SQL Server: Replika Baca dari Replika Baca saat ini tidak didukung.

Replika baca dirancang untuk melayani lalu lintas baca. Namun, mungkin ada kasus penggunaan saat pengguna lanjutan ingin menyelesaikan pernyataan SQL Bahasa Definisi Data (DDL) terhadap replika baca. Contohnya mungkin termasuk menambahkan indeks basis data ke replika baca yang digunakan untuk pelaporan bisnis, tanpa menambahkan indeks yang sama ke instans DB sumber yang sesuai.

Amazon RDS for MySQL dapat dikonfigurasi untuk mengizinkan pernyataan SQL DDL terhadap replika baca. Jika Anda ingin mengaktifkan operasi selain baca untuk replika baca yang disediakan, ubah grup parameter DB yang aktif untuk replika baca, atur parameter “read_only” ke “0.”

Amazon RDS for PostgreSQL saat ini tidak mendukung eksekusi pernyataan SQL DDL terhadap replika baca.

Ya. Lihat Panduan Pengguna Amazon RDS untuk detail selengkapnya.

Pembaruan instans DB sumber akan secara otomatis direplikasi ke replika baca apa pun yang terkait. Namun, dengan teknologi replikasi asinkron mesin yang didukung, replika baca dapat tertinggal dari instans DB sumber untuk berbagai alasan. Alasan yang umum termasuk:

• Volume tulis I/O ke instans DB sumber melebihi tingkat di mana perubahan dapat diterapkan ke replika baca (masalah ini sangat mungkin muncul jika kapasitas komputasi replika baca lebih sedikit dari Instans DB sumber)
• Transaksi yang kompleks atau berlangsung lama ke Instans DB sumber menahan replikasi ke replika baca
• Partisi atau latensi jaringan antara instans DB sumber dan replika baca

Replika Baca bergantung pada kekuatan dan kelemahan replikasi asli dari mesin yang didukung. Jika Anda menggunakan Replika Baca, Anda harus menyadari potensi lag antara Replika Baca dan Instans DB sumbernya, atau “inkonsistensi”.

Anda dapat menggunakan API DescribeDBInstances standar untuk mengembalikan daftar semua Instans DB yang telah di-deploy (termasuk Replika Baca), atau cukup klik tab "Instans" pada Konsol Amazon RDS.

Amazon RDS memungkinkan Anda mendapatkan visibilitas mengenai sejauh mana replika baca tertinggal dari instans DB sumbernya. Jumlah detik ketertinggalan replika baca dari yang utama dipublikasikan sebagai metrik Amazon CloudWatch ("Ketertinggalan Replika") yang tersedia melalui Konsol Manajemen AWS atau API Amazon CloudWatch.

Untuk Amazon RDS for MySQL, sumber informasi ini sama dengan yang ditampilkan dengan mengeluarkan perintah MySQL "Tampilkan Status Replika" terhadap replika baca. Untuk Amazon RDS for PostgreSQL, Anda dapat menggunakan tampilan pg_stat_replication pada instans DB sumber untuk menjelajahi metrik replikasi.

Amazon RDS memantau status replikasi dari Replika Baca Anda dan memperbarui kolom Status Replikasi di Konsol Manajemen AWS menjadi "Kesalahan" jika replikasi berhenti karena alasan apa pun (misal, mencoba kueri DML pada replika yang bertentangan dengan pembaruan yang dibuat pada instans basis data primer dapat menyebabkan kesalahan replikasi). Anda dapat meninjau detail kesalahan terkait yang dibuat oleh mesin MySQL dengan melihat kolom Kesalahan Replikasi dan mengambil tindakan yang tepat untuk memulihkannya. Anda dapat mempelajari selengkapnya tentang pemecahan masalah replikasi di bagian Memecahkan Masalah Replika Baca pada Panduan Pengguna untuk Amazon RDS for MySQL atau PostgreSQL. 

Jika kesalahan replikasi telah diperbaiki, Status Replikasi berubah menjadi Replikasi.

Agar replikasi berfungsi secara efektif, kami merekomendasikan replika baca memiliki sumber daya komputasi dan penyimpanan yang sama banyak atau lebih banyak sebagai instans DB sumber masing-masing. Jika tidak, lag replikasi cenderung meningkat atau replika baca Anda mungkin kehabisan ruang untuk menyimpan pembaruan yang direplikasi.

Anda dapat menghapus replika baca dengan beberapa langkah dari Konsol Manajemen AWS atau dengan meneruskan pengidentifikasi Instans DB ke API DeleteDBInstance. 

Replika Amazon Aurora akan tetap aktif dan terus menerima lalu lintas baca bahkan setelah Instans DB sumbernya yang sesuai telah dihapus. Salah satu replika dalam klaster akan secara otomatis dipromosikan sebagai primer baru, dan akan mulai menerima lalu lintas tulis.

Replika baca Amazon RDS for MySQL atau MariaDB akan tetap aktif dan terus menerima lalu lintas baca bahkan setelah instans DB sumbernya yang sesuai telah dihapus. Jika Anda ingin menghapus Replika Baca selain instans DB sumber, Anda harus secara eksplisit melakukannya menggunakan API DeleteDBInstance atau AWS Management Console.

Jika Anda menghapus Instans DB Amazon RDS for PostgreSQL yang telah memiliki replika baca, semua Replika Baca akan dipromosikan ke Instans DB mandiri dan akan dapat menerima lalu lintas baca dan tulis. Instans DB yang baru dipromosikan akan beroperasi secara independen satu sama lain. Jika ingin menghapus Instans DB ini selain Instans DB sumber aslinya, Anda harus secara eksplisit melakukannya menggunakan API DeleteDBInstance atau AWS Management Console.

Replika baca ditagih sebagai Instans DB standar dan memiliki tarif yang sama. Sama seperti instans DB standar, tarif per “jam Instans DB” untuk replika baca ditentukan oleh kelas instans DB dari replika baca; lihat halaman harga untuk harga terbaru. Anda tidak akan dikenakan biaya untuk transfer data yang dilakukan dalam mereplikasi data antara instans DB sumber dan replika baca Anda dalam Wilayah AWS yang sama.

Tagihan untuk replika dimulai segera setelah replika baca berhasil dibuat. (yaitu saat status tercantum “aktif”). Replika baca akan terus ditagih dengan tarif per jam instans DB Amazon RDS standar hingga Anda mengeluarkan perintah untuk menghapusnya.

Pemantauan yang Ditingkatkan untuk Amazon RDS memberikan visibilitas yang lebih dalam tentang kondisi instans Amazon RDS Anda. Cukup aktifkan opsi “Pemantauan yang Ditingkatkan” untuk Instans DB Amazon RDS Anda serta atur perincian, dan Pemantauan yang Ditingkatkan akan mengumpulkan metrik sistem operasi penting serta informasi proses, dengan perincian yang ditentukan.

Untuk tingkat diagnostik serta visualisasi yang lebih dalam pada muatan basis data, dan periode retensi data yang lebih lama, Anda dapat mencoba Wawasan Performa.

Pemantauan yang Ditingkatkan menangkap metrik tingkat sistem instans Amazon RDS antara lain seperti CPU, memori, sistem file, dan I/O disk. Daftar lengkap metrik dapat ditemukan di dokumentasi.

Pemantauan yang Ditingkatkan mendukung semua mesin basis data Amazon RDS.

Pemantauan yang Ditingkatkan mendukung semua tipe instans kecuali t1.micro dan m1.small. Perangkat lunak menggunakan sejumlah kecil CPU memori, dan I/O dan untuk pemantauan tujuan umum, kami merekomendasikan agar melakukan switching ke perincian yang lebih tinggi untuk instans medium atau yang lebih besar. Untuk Instans DB non-produksi, pengaturan default untuk Pemantauan yang Ditingkatkan adalah “off”, dan Anda dapat memilih untuk membiarkannya tidak aktif atau mengubah perinciannya ketika aktif.

Anda dapat melihat semua metrik sistem dan informasi proses untuk Instans DB Amazon RDS Anda dalam format grafis pada konsol. Anda dapat mengelola metrik mana yang ingin Anda pantau untuk setiap Instans dan mengustomisasi dasbor seuai permintaan Anda.

Tidak. Anda dapat mengatur perincian yang berbeda untuk setiap Instans DB di akun Amazon RDS Anda. Anda juga dapat memilih instans yang diinginkan untuk mengaktifkan Pemantauan yang Ditingkatkan serta memodifikasi perincian instans apa pun kapan saja Anda inginkan.

Anda dapat melihat nilai performa untuk semua metrik hingga 1 jam ke belakang, dengan perincian hingga 1 detik berdasarkan pengaturan Anda.

Metrik dari Pemantauan yang Ditingkatkan Amazon RDS dikirimkan ke akun CloudWatch Logs Anda. Anda dapat membuat filter metrik di CloudWatch dari CloudWatch Logs dan menampilkan grafiknya pada dasbor CloudWatch. Untuk detail selengkapnya, kunjungi halaman Amazon CloudWatch.

Anda harus menggunakan CloudWatch jika ingin melihat riwayat data selain yang tersedia di dasbor konsol Amazon RDS. Anda dapat memantau instans Amazon RDS Anda di CloudWatch untuk mendiagnosis kondisi dari seluruh tumpukan AWS Anda di satu lokasi. Saat ini, CloudWatch mendukung perincian hingga 1 menit dan nilai akan dirata-ratakan untuk perincian yang kurang dari itu.

Ya. Anda dapat membuat alarm di CloudWatch yang mengirimkan notifikasi ketika alarm mengubah status. Alarm mengawasi satu metrik selama periode waktu yang Anda tentukan, dan melakukan satu atau beberapa tindakan berdasarkan nilai metrik yang relatif terhadap ambang batas yang ditentukan selama beberapa periode waktu. Untuk detail selengkapnya tentang alarm CloudWatch, kunjungi Panduan Developer Amazon CloudWatch.

Pemantauan yang Ditingkatkan Amazon RDS memberikan set metrik yang dibentuk sebagai muatan JSON yang dikirimkan ke akun CloudWatch Logs Anda. Muatan JSON dikirimkan pada perincian yang terakhir dikonfigurasi untuk instans Amazon RDS.

Ada dua cara Anda dapat menggunakan metrik melalui dasbor atau aplikasi pihak ketiga. Alat pemantauan dapat menggunakan Langganan Log CloudWatch guna menyiapkan umpan mendekati waktu nyata untuk metrik. Atau, Anda dapat menggunakan filter di CloudWatch Logs untuk menjembatani metrik di seluruh CloudWatch dan mengintegrasikan aplikasi Anda dengan CloudWatch. Kunjungi Dokumentasi Amazon CloudWatch untuk detail selengkapnya.

Karena Pemantauan yang Ditingkatkan mengirimkan payload JSON ke dalam log di akun CloudWatch Logs Anda, Anda dapat mengontrol periode penyimpanan seperti halnya aliran CloudWatch Logs lainnya. Periode penyimpanan default yang dikonfigurasi untuk Pemantauan yang Ditingkatkan di CloudWatch Logs adalah 30 hari. Untuk detail tentang cara mengubah pengaturan retensi, kunjungi Panduan Developer Amazon CloudWatch.

Karena metrik dicatat ke CloudWatch Logs, tagihan Anda akan didasarkan pada transfer data CloudWatch Logs dan tingkat penyimpanan setelah Anda melebihi tingkat gratis CloudWatch Logs. Detail harga dapat ditemukan di sini. Jumlah informasi yang ditransfer untuk instans Amazon RDS berbanding lurus dengan perincian yang ditetapkan untuk fitur Pemantauan yang Ditingkatkan. Administrator dapat mengatur perincian yang berbeda untuk instans yang berbeda di akun mereka untuk mengelola biaya.

Perkiraan volume data yang dicatat ke CloudWatch Logs oleh Pemantauan yang Ditingkatkan untuk suatu instans adalah seperti yang ditunjukkan di bawah ini:

Proksi Amazon RDS adalah fitur proksi basis data terkelola penuh dengan ketersediaan tinggi untuk Amazon RDS. RDS Proxy membuat aplikasi lebih dapat diskalakan, lebih tahan terhadap kegagalan database, dan lebih aman.

Amazon RDS Proxy adalah fitur proksi basis data terkelola penuh, sangat tersedia, dan mudah digunakan dari Amazon RDS yang memungkinkan aplikasi Anda untuk: 1) meningkatkan skalabilitas dengan menyatukan dan membagikan koneksi basis data; 2) meningkatkan ketersediaan dengan mengurangi jumlah failover basis data hingga 66% dan mempertahankan koneksi aplikasi selama failover; dan 3) meningkatkan keamanan dengan secara opsional memperkuat autentikasi AWS IAM ke basis data dan menyimpan kredensial secara aman di AWS Secrets Manager.

Tergantung beban kerja Anda, Amazon RDS Proxy dapat menambahkan rata-rata 5 milidetik latensi jaringan ke kueri atau waktu respons transaksi. Jika aplikasi Anda tidak dapat menolerir 5 milidetik latensi atau tidak memerlukan manajemen koneksi dan fitur-fitur lainnya yang diaktifkan oleh RDS Proxy, Anda mungkin ingin agar aplikasi Anda terhubung secara langsung ke titik akhir basis data.

Proksi Amazon RDS mentransformasikan pendekatan Anda untuk membangun aplikasi nirserver modern yang memanfaatkan daya dan kesederhanaan basis data relasional. Pertama, RDS Proxy mengaktifkan aplikasi nirserver untuk menskalakan secara efisien dengan menyatukan dan menggunakan kembali koneksi basis data. Kedua, dengan RDS Proxy, Anda tidak perlu lagi menangani kredensial database di kode Lambda Anda. Anda dapat menggunakan peran eksekusi IAM yang dihubungkan dengan fungsi Lambda Anda untuk mengautentikasi dengan RDS Proxy dan database Anda. Ketiga, Anda tidak perlu mengelola infratruktur atau kode baru apa pun untuk memanfaatkan potensi penuh aplikasi tanpa server yang didukung oleh database relasional. Proksi RDS dikelola secara penuh dan menskalakan kapasitasnya secara otomatis berdasarkan permintaan aplikasi Anda.

Proksi RDS tersedia untuk Amazon Aurora dengan kompatibilitas MySQL, Amazon Aurora dengan kompatibilitas PostgreSQL, Amazon RDS for MariaDB, Amazon RDS for MySQL, Amazon RDS for PostgreSQL, dan Amazon RDS for SQL Server. Untuk daftar versi mesin yang didukung, lihat Panduan Pengguna Amazon Aurora atau Panduan Pengguna Amazon RDS.

Anda dapat mengaktifkan Amazon RDS Proxy untuk basis data Amazon RDS Anda hanya dengan beberapa klik di konsol Amazon RDS. Selagi mengaktifkan Proxy RDS, Anda menetapkan VPC dan subnet tempat proxy RDS yang ingin Anda akses. Sebagai pengguna Lambda, Anda dapat mengaktifkan Amazon RDS Proxy untuk basis data Amazon RDS dan menyiapkan fungsi Lambda untuk mengaksesnya hanya dengan beberapa klik di konsol Lambda.

Ya. Anda dapat menggunakan API Amazon RDS Proxy untuk membuat proksi lalu menetapkan kelompok target untuk menghubungkan proksi dengan instans atau klaster database khusus. Misalnya:

aws rds create-db-proxy 
        --db-proxy-name '…' 
        --engine-family <mysql|postgresql>       
        --auth [{}, {}] 
        --role-arn '…'
        --subnet-ids {}
        --require-tls <true|false>
        --tags {}
aws rds register-db-proxy-targets 
        --target-group-name '…'
        --db-cluster-identifier  '…'
        --db-instance-identifier '…'

Ekstensi Bahasa Tepercaya (TLE) untuk PostgreSQL memungkinkan para developer untuk membangun ekstensi PostgreSQL performa tinggi dan menjalankannya dengan aman di Amazon Aurora dan Amazon RDS. Dengan demikian, TLE akan meningkatkan waktu Anda untuk memasarkan dan menghilangkan beban yang ditempatkan pada administrator basis data untuk menyertifikasi kode kustom dan pihak ketiga untuk digunakan dalam beban kerja basis data produksi. Anda dapat melanjutkan segera setelah memutuskan bahwa ekstensi telah memenuhi kebutuhan Anda. Dengan TLE, vendor perangkat lunak independen (ISV) dapat menyediakan ekstensi PostgreSQL baru untuk pelanggan yang berjalan di Aurora dan Amazon RDS.

Ekstensi PostgreSQL dijalankan dalam ruang proses yang sama untuk performa tinggi. Namun, ekstensi mungkin memiliki cacat perangkat lunak yang dapat merusak basis data.

TLE for PostgreSQL menawarkan beberapa lapisan perlindungan untuk memitigasi risiko ini. TLE didesain untuk membatasi akses ke sumber daya sistem. Peran rds_superuser dapat menentukan orang-orang yang diizinkan untuk menginstal ekstensi tertentu. Namun, perubahan ini hanya dapat dilakukan melalui API TLE. TLE dirancang untuk membatasi dampak cacat ekstensi ke koneksi basis data tunggal. Selain perlindungan ini, TLE didesain untuk memberikan kontrol online yang terperinci kepada DBA dalam peran rds_superuser atas siapa yang dapat menginstal ekstensi dan mereka dapat membuat model izin untuk menjalankannya.

Hanya pengguna dengan hak istimewa yang cukup yang dapat menjalankan dan membuat menggunakan perintah “CREATE EXTENSION” pada ekstensi TLE. DBA juga dapat memiliki daftar “hook PostgreSQL” yang diizinkan yang diperlukan untuk ekstensi lebih canggih yang memodifikasi perilaku internal basis data dan biasanya memerlukan hak istimewa yang lebih tinggi.

TLE for PostgreSQL tersedia untuk Amazon Aurora PostgreSQL-Compatible Edition serta Amazon RDS on PostgreSQL pada versi 14.5 dan yang lebih tinggi. TLE diimplementasikan sebagai ekstensi PostgreSQL itu sendiri dan Anda dapat mengaktifkannya dari peran rds_superuser yang mirip dengan ekstensi lain yang didukung pada Aurora dan Amazon RDS.

Anda dapat menjalankan TLE for PostgreSQL di PostgreSQL 14.5 atau lebih tinggi di Amazon Aurora dan Amazon RDS.  

Saat ini, TLE for PostgreSQL tersedia di semua Wilayah AWS (tidak termasuk Wilayah AWS Tiongkok) dan Wilayah AWS GovCloud.

TLE for PostgreSQL tersedia untuk pelanggan Aurora dan Amazon RDS tanpa biaya tambahan.

Aurora dan Amazon RDS mendukung lebih dari 85 ekstensi PostgreSQL yang telah dikurasi. AWS mengelola risiko keamanan untuk masing-masing ekstensi ini di bawah model tanggung jawab bersama AWS. Ekstensi yang mengimplementasikan TLE for PostgreSQL disertakan dalam rangkaian ini. Ekstensi yang Anda tulis atau Anda peroleh dari sumber pihak ketiga dan diinstal di TLE akan dianggap sebagai bagian dari kode aplikasi Anda. Anda bertanggung jawab atas keamanan aplikasi yang menggunakan ekstensi TLE.

Anda dapat membangun fungsi developer, seperti kompresi bitmap dan privasi diferensial (seperti kueri statistik yang dapat diakses publik yang melindungi privasi individu).

Saat ini, TLE for PostgreSQL mendukung JavaScript, PL/pgSQL, Perl, dan SQL.

Setelah peran rds_superuser mengaktifkan TLE for PostgreSQL, Anda dapat melakukan deployment ekstensi TLE menggunakan perintah SQL CREATE EXTENSION dari klien PostgreSQL apa pun, seperti psql. Hal ini mirip dengan cara Anda membuat fungsi yang ditentukan pengguna yang ditulis dalam bahasa prosedural, seperti PL/pgSQL atau PL/Perl. Anda dapat mengontrol pengguna mana yang memiliki izin untuk melakukan deployment ekstensi TLE dan menggunakan ekstensi tertentu.

TLE for PostgreSQL mengakses basis data PostgreSQL Anda secara eksklusif melalui API TLE. Bahasa tepercaya yang didukung TLE mencakup semua fungsi antarmuka pemrograman server PostgreSQL (SPI) dan dukungan untuk hook PostgreSQL, termasuk hook periksa kata sandi.

Anda dapat mempelajari proyek TLE for PostgreSQL selengkapnya di halaman GitHub TLE resmi.

Amazon RDS Blue/Green Deployments tersedia di Amazon Aurora MySQL-Compatible Edition, Amazon Aurora PostgreSQL-Compatible Edition, Amazon RDS for MySQL, Amazon RDS for MariaDB, dan Amazon RDS for PostgreSQL. 

Amazon RDS Blue/Green Deployments tersedia untuk Amazon Aurora MySQL-Compatible Edition versi 5.6 dan lebih tinggi, RDS for MySQL versi 5.7 dan lebih tinggi, serta RDS for versions MariaDB versi 10.2 dan lebih tinggi. Blue/Green Deployment juga didukung untuk Amazon Aurora PostgreSQL-Compatible Edition dan Amazon RDS for PostgreSQL untuk versi 11.21 dan lebih tinggi, 12.16 dan lebih tinggi, 13.12 dan lebih tinggi, 14.9 dan lebih tinggi, serta 15.4 dan lebih tinggi. Pelajari selengkapnya tentang versi yang tersedia di dokumentasi Amazon Aurora dan Amazon RDS. 

Amazon RDS Blue/Green Deployments tersedia di semua Wilayah AWS dan Wilayah AWS GovCloud yang berlaku.

Deployment Blue/Green Amazon RDS memungkinkan Anda melakukan perubahan basis data yang lebih aman, sederhana, dan cepat. Deployment Blue/Green ideal untuk kasus penggunaan, seperti peningkatan mesin basis data versi utama atau minor, pembaruan sistem operasi, perubahan skema pada lingkungan green yang tidak merusak replikasi logis, seperti menambahkan kolom baru di akhir tabel, atau perubahan pengaturan parameter basis data. Anda dapat menggunakan Deployment Blue/Green untuk membuat beberapa pembaruan basis data secara bersamaan menggunakan satu switchover. Hal ini memungkinkan Anda untuk tetap mengikuti patch keamanan, meningkatkan performa basis data, serta mengakses fitur basis data yang lebih baru dengan waktu henti yang singkat dan dapat diprediksi.

Anda akan dikenai biaya yang sama untuk menjalankan beban kerja Anda pada instans green seperti yang Anda lakukan untuk instans blue. Biaya menjalankan instans blue dan green mencakup harga standar terkini untuk db.instance, biaya penyimpanan, biaya I/O baca/tulis, serta setiap fitur yang diaktifkan, seperti biaya pencadangan dan Wawasan Performa Amazon RDS. Anda akan membayar sekitar 2x biaya untuk menjalankan beban kerja di db.instance untuk masa pakai deployment-blue-green.

Misalnya: Anda memiliki basis data RDS for MySQL 5.7 yang berjalan pada dua db.instance r5.2xlarge, sebuah instans basis data primer, dan sebuah replika baca, di wilayah AWS us-east-1 dengan konfigurasi Multi-AZ (MAZ). Setiap db.instance r5.2xlarge dikonfigurasi untuk Amazon Elastic Block Storge (EBS) Tujuan Umum sebesar 20 GiB. Anda membuat klona topologi instans blue menggunakan Amazon RDS Blue/Green Deployment, menjalankannya selama 15 hari (360 jam), lalu menghapus instans blue tersebut setelah switchover berhasil. Biaya instans blue adalah 1.387 USD selama 15 hari dengan tarif sesuai permintaan sebesar 1,926 USD/jam (biaya Instans + EBS). Total biaya Anda untuk penggunaan Blue/Green Deployment selama 15 hari tersebut adalah 2.774 USD, yaitu 2x biaya menjalankan instans blue selama periode waktu tersebut.

Amazon Blue/Green Deployment memungkinkan Anda untuk membuat perubahan basis data yang lebih aman, sederhana, dan cepat, seperti peningkatan versi utama atau minor, perubahan skema, penskalaan instans, perubahan parameter mesin, serta pembaruan pemeliharaan.

Di Amazon RDS Blue/Green Deployments, lingkungan blue adalah lingkungan produksi Anda saat ini. Lingkungan green adalah lingkungan uji coba yang akan menjadi lingkungan produksi baru Anda setelah switchover.

Saat Amazon RDS Blue/Green Deployments memulai switchover, deployment tersebut memblokir penulisan ke lingkungan blue dan green hingga switchover selesai. Selama switchover, lingkungan uji coba, atau lingkungan green, akan mengikuti sistem produksi, sehingga memastikan data antara lingkungan uji coba dan produksi konsisten satu sama lain. Setelah lingkungan produksi dan uji coba sepenuhnya sinkron, Blue/Green Deployment mempromosikan lingkungan uji coba sebagai lingkungan produksi dengan mengarahkan lalu lintas ke lingkungan produksi yang baru dipromosikan. Blue/Green Deployment didesain untuk mengaktifkan penulisan di lingkungan green setelah switchover selesai, sehingga tidak data yang hilang selama proses switchover.

Jika lingkungan blue Anda adalah replika logis yang dikelola sendiri, atau pelanggan, kami akan memblokir switchover. Sebaiknya hentikan replikasi ke lingkungan blue terlebih dahulu, proses switchover, lalu lanjutkan replikasi. Sebaliknya, jika lingkungan blue Anda adalah sumber untuk replika logis yang dikelola sendiri, atau penerbit, Anda dapat melanjutkan switchover. Namun, Anda perlu memperbarui replika yang dikelola sendiri untuk mereplikasi dari lingkungan green pasca-switchover.

Amazon RDS Blue/Green Deployments tidak menghapus lingkungan produksi lama Anda. Jika diperlukan, Anda dapat mengaksesnya untuk validasi tambahan dan pengujian performa/regresi. Jika tidak lagi membutuhkan lingkungan produksi yang lama, Anda dapat menghapusnya. Biaya penagihan standar berlaku pada instans produksi lama hingga Anda menghapusnya.

Pagar pembatas switchover Amazon RDS Blue/Green Deployment memblokir penulisan di lingkungan blue dan green Anda hingga lingkungan green mengikutinya sebelum melakukan switchover. Deployment Blue/Green juga melakukan pemeriksaan kondisi atas primer dan replika Anda di lingkungan blue dan green. Deployment Blue/Green juga melakukan pemeriksaan kondisi replikasi, misalnya, untuk melihat apakah replikasi telah berhenti atau jika terdapat kesalahan. Deployment Blue/Green mendeteksi transaksi jangka panjang antara lingkungan blue dan green Anda. Anda dapat menentukan waktu henti maksimum yang dapat ditoleransi, serendah-rendahnya 30 detik, dan jika memiliki transaksi yang sedang berlangsung yang melebihi waktu tersebut, switchover akan berakhir.

Tidak, Amazon RDS Blue/Green Deployments tidak mendukung Basis Data Global, Proksi Amazon RDS, replika baca lintas Wilayah, atau replika baca bertingkat.

Tidak, saat ini Anda tidak dapat menggunakan Amazon RDS Blue/Green Deployment untuk mengembalikan perubahan.

MySQL melindungi pengguna dari kehilangan data dengan menuliskan data pada halaman 16 KiB di dalam memori sebanyak dua kali ke penyimpanan yang tahan lama—pertama ke “buffer penulisan ganda” lalu ke penyimpanan tabel. Amazon RDS Optimized Writes menuliskan halaman data 16 KiB langsung ke file data Anda dengan andal dan tahan lama dalam satu langkah menggunakan fitur Pencegahan Tumpang Tindih dari AWS Nitro System.

Amazon RDS Optimized Writes tersedia untuk MySQL versi utama 8.0.30 dan di atasnya.

Amazon RDS Optimized Writes tersedia di instans db.r6i dan db.r5b. Amazon RDS Optimized Writes tersedia di semua Wilayah yang menyediakan instans ini, kecuali Wilayah AWS Tiongkok.

Tidak. Amazon Aurora Edisi Kompatibel MySQL sudah menghindari penggunaan “buffer penulisan ganda.” Sebagai gantinya, Amazon Aurora mereplikasi data dengan enam cara di tiga Zona Ketersediaan (AZ) dan menggunakan pendekatan berbasis quorum untuk menulis data secara tahan lama serta membacanya dengan benar setelah itu.

Saat ini, rilis awal ini tidak mendukung pengaktifan Amazon RDS Optimized Writes untuk instans basis data yang sudah ada meskipun kelas instans mendukung Optimized Writes.

Amazon RDS Optimized Writes tersedia untuk pelanggan RDS for MySQL tanpa biaya tambahan.

Beban kerja yang menggunakan objek sementara di MySQL dan MariaDB untuk pemrosesan kueri mendapatkan keuntungan dari Amazon RDS Optimized Reads. Optimized Reads menempatkan objek sementara pada penyimpanan instans berbasis NVMe dari instans basis data, alih-alih volume Amazon Elastic Block Store. Hal ini membantu mempercepat pemrosesan kueri kompleks hingga 2X.

Amazon RDS Optimized Reads tersedia untuk RDS for MySQL pada MySQL versi 8.0.28 dan lebih tinggi serta di RDS for MariaDB pada MariaDB versi 10.4.25, 10.5.16, 10.6.7 dan lebih tinggi.

Amazon RDS Optimized Reads tersedia di semua wilayah yang menyediakan instans db.r5d, db.m5d, db.r6gd, and db.m6gd, X2idn, dan X2iedn. Untuk informasi selengkapnya, lihat dokumentasi kelas instans DB Amazon RDS.

Pelanggan sebaiknya menggunakan Amazon RDS Optimized Reads ketika mereka memiliki beban kerja yang memerlukan kueri kompleks; analitik tujuan umum; atau yang memerlukan grup, penyortiran, agregasi hash, penggabungan beban tinggi, dan Ekspresi Tabel Umum (CTE) yang rumit. Kasus penggunaan ini menghasilkan pembuatan tabel sementara, yang memungkinkan Optimized Reads mempercepat pemrosesan kueri beban kerja Anda.

Ya, pelanggan dapat mengonversi basis data Amazon RDS mereka yang ada untuk menggunakan Amazon RDS Optimized Reads dengan memindahkan beban kerja Anda ke instans dengan Optimized Reads aktif. Optimized Reads juga tersedia secara default pada semua kelas instans yang didukung. Jika menjalankan beban kerja pada instans db.r5d, db.m5d, db.r6gd, db.m6gd, X2idn, dan X2iedn, Anda sudah mendapatkan manfaat dari Optimized Reads.