FAQ Amazon RDS

Amazon Relational Database Service (Amazon RDS) adalah layanan terkelola yang memudahkan untuk mengatur, mengoperasikan, dan menskalakan basis data relasional di cloud. Layanan tersebut menyediakan kapasitas yang hemat biaya dan dapat diubah ukurannya, serta mengelola tugas administrasi basis data yang memakan waktu, sehingga Anda dapat fokus pada aplikasi dan bisnis Anda.

Amazon RDS memberikan Anda akses ke kemampuan basis data PostgreSQL, MySQL, MariaDB, Oracle, SQL Server , yang sudah tidak asing lagi. Selain itu, Amazon Aurora, yang merupakan bagian dari RDS, memiliki versi Aurora MySQL dan Aurora PostgreSQL sendiri. Amazon RDS menggunakan replikasi untuk meningkatkan ketersediaan basis data, memastikan ketahanan data, atau menskalakan melampaui batasan kapasitas instans basis data tunggal untuk beban kerja basis data yang banyak membaca. Seperti halnya semua Amazon Web Services, tidak diperlukan investasi di muka, dan Anda hanya membayar untuk sumber daya yang Anda gunakan.

Amazon Web Services menyediakan sejumlah alternatif basis data untuk pengembang. Amazon RDS mengizinkan Anda untuk menjalankan basis data relasional yang sepenuhnya terkelola dan berfitur lengkap ketika membongkar administrasi basis data. Menggunakan salah satu dari banyak AMI basis data relasional kami di Amazon EC2 memungkinkan Anda mengelola basis data relasional Anda sendiri di cloud. Ada perbedaan penting di antara alternatif ini yang mungkin membuat satu alternatif yang lebih sesuai untuk kasus penggunaan Anda. Lihat Basis Data Cloud dengan AWS untuk panduan mengenai pilihan solusi yang terbaik bagi Anda.

Ya, Anda dapat menjalankan Amazon RDS on-premise menggunakan Amazon RDS di Outpost. Silakan baca FAQ mengenai Amazon RDS di Outpost untuk tambahan informasi.

Ya, spesialis Amazon RDS hadir untuk menjawab pertanyaan Anda dan memberikan dukungan. Hubungi Kami dan Anda akan mendapatkan respons dari kami dalam satu hari kerja untuk mendiskusikan cara AWS membantu organisasi Anda.

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, mendefinisikan/menyempurnakan atribut infrastruktur instans DB Anda, serta mengontrol akses dan keamanan melalui Konsol Manajemen AWS, API Amazon RDS, dan 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 akhir nya melalui deskripsi instans DB di Konsol Manajemen AWS, API DescribeDBInstances atau perintah gambarkan-instans-db. 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 mengenai cara mengonstruksi string koneksi Anda dan memulainya, silakan lihat Panduan Memulai kami.

Secara default, pelanggan diizinkan memiliki hingga total 40 instans DB Amazon RDS. Dari 40 instans tersebut, hingga 10 instans DB dapat merupakan instans DB Oracle atau SQL Server di bawah model "Termasuk Lisensi". 40 instans DB dapat digunakan untuk Amazon Aurora, MySQL, MariaDB, PostgreSQL, dan Oracle di bawah model "BYOL". Harap diingat bahwa RDS untuk SQL Server memiliki batasan hingga 100 basis data pada instans DB tunggal, lihat Panduan Pengguna Amazon RDS for SQL Server untuk mempelajari selengkapnya.

Jika aplikasi memerlukan lebih banyak instans DB, Anda dapat meminta tambahan instans DB melalui formulir permintaan ini.

• 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 for SQL Server: Hingga 100 basis data per instans, lihat di sini: Panduan Pengguna Amazon RDS for SQL Server
• RDS untuk PostgreSQL: Tidak ada batasan yang dikenakan oleh perangkat lunak

Ada sejumlah cara sederhana untuk mengimpor data ke Amazon RDS, seperti dengan utilitas mysqldump atau mysqlimport untuk MySQL; Pompa Data, impor/ekspor, atau SQL Loader untuk Oracle; wizard Impor/Ekspor, file cadangan penuh (file .bak) atau Bulk Copy Program (BCP) untuk SQL Server; atau pg_dump untuk PostgreSQL. Untuk informasi selengkapnya mengenai impor dan ekspor data, harap lihat Panduan Impor Data untuk MySQL, Panduan Impor Data untuk Oracle, Panduan Impor Data untuk SQL Server, atau Panduan Impor Data untuk PostgreSQL.

Selain itu, AWS Database Migration Service dapat membantu Anda memigrasi basis data ke AWS dengan mudah dan aman.

Periode pemeliharaan Amazon RDS merupakan kesempatan Anda untuk mengontrol ketika modifikasi instans DB, peningkatan 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 periode pemeliharaan mingguan pilihan ketika membuat instans DB, nilai default 30 menit akan ditetapkan. Jika ingin mengubah saat pemeliharaan dilakukan, Anda dapat melakukannya dengan mengubah instans DB di Konsol Manajemen AWS, API ModifyDBInstance, atau, perintah ubah-instans-db. 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. Silakan lihat Panduan Pengguna Amazon RDS untuk informasi selengkapnya mengenai operasi pemeliharaan.

Untuk basis data produksi, kami menyarankan Anda untuk 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 berdasarkan setiap 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 mengenai pemantauan instans DB Anda, lihat Panduan Pengguna Amazon RDS.

Jika Anda menggunakan RDS untuk MySQL atau MariaDB, Anda dapat mengakses log kueri lambat untuk basis data Anda guna menentukan adakah kueri SQL yang berjalan lambat, dan jika demikian, 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. Silakan lihat Panduan Pengguna Amazon RDS untuk mempelajari lebih lanjut.

Jika Anda menggunakan RDS untuk Oracle, Anda dapat menggunakan jejak data file Oracle untuk mengidentifikasi kueri yang lambat. Untuk informasi lebih lanjut tentang mengakses jejak data file, silakan 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 lebih lanjut tentang mengakses jejak data file server, silakan lihat Panduan Pengguna Amazon RDS.

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

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

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
  

Amazon RDS menambahkan dukungan untuk versi mesin basis data mayor dan minor dari waktu ke waktu. 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 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 (mayor dan minor) saat membuat instans DB baru melalui operasi Luncurkan Instans DB dalam Konsol Manajemen AWS atau API CreateDBInstance. Harap perhatikan bahwa tidak semua versi mesin basis data tersedia di setiap wilayah AWS.

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

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

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 atau selama periode 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 untuk 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 mengenai peningkatan 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 peningkatan versi untuk instans DB baru. Kemudian Anda dapat bereksperimen dengan aman pada salinan peningkatan instans DB Anda sebelum memutuskan apakah akan meningkatkan instans DB asli atau tidak.

Untuk informasi selengkapnya mengenai 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.

Secara berkala, kami akan menghentikan versi mesin mayor atau minor. 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 tertentu dapat menentukan linimasa yang berbeda tergantung pada masalah yang sedang ditangani.

Ketika versi minor dari mesin basis data tidak lagi digunakan di Amazon RDS, kami akan memberi waktu tiga (3) bulan setelah pengumuman sebelum memulai peningkatan otomatis. Di akhir periode ini, semua instans yang masih menjalankan versi minor yang sudah tidak digunakan akan dijadwalkan untuk peningkatan 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.

Setelah versi mesin basis data mayor atau minor tidak lagi didukung di Amazon RDS, setiap instans DB yang dipulihkan dari snapshot DB yang dibuat dengan versi yang tidak didukung akan dimutakhirkan secara otomatis dan dengan segera ke versi yang saat ini didukung.

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 tertentu dapat menentukan lini masa yang berbeda tergantung pada masalah yang sedang ditangani.

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 apa yang baru dari kami.
• Penyimpanan (per GB per bulan) – Kapasitas penyimpanan yang Anda sediakan untuk instans DB Anda. Jika Anda menskalakan kapasitas penyimpanan yang disediakan dalam bulan ini, tagihan Anda akan diterapkan dengan sistem pro-rata.
• Permintaan I/O per bulan – Jumlah total permintaan I/O penyimpanan yang Anda miliki (hanya untuk Penyimpanan Magnetik Amazon RDS 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 basis data tambahan meningkatkan penyimpanan cadangan yang digunakan oleh basis data Anda.
  
• Transfer data – Transfer data internet masuk dan keluar dari instans DB Anda.

Untuk informasi harga Amazon RDS, silakan 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 dalam hal kegagalan instans.

Jam instans DB ditagih untuk setiap jam saat instans DB Anda berjalan dalam keadaan 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. Untuk detail tambahan, baca pengumuman apa yang baru dari kami.

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

Penyimpanan yang disediakan untuk instans DB Anda untuk data primer berlokasi di satu Zona Ketersediaan. Ketika basis data Anda dicadangkan, data cadangan (termasuk log transaksi) secara geografis direplikasi di beberapa 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 Anda 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 memodifikasi kelas instans DB. Untuk detail tambahan, baca pengumuman apa yang baru dari kami. Jika Anda mengonversi deployment instans DB Anda antara standar dan Multi-AZ dalam jam tertentu, Anda akan dikenai dua tarif yang berlaku selama 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 deployment 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 penagihan di negara Jepang, penggunaan layanan AWS tunduk pada Pajak Konsumsi Jepang. Pelajari selengkapnya.

Penawaran AWS Tingkat Gratis untuk Amazon RDS memberikan penggunaan gratis instans DB Micro Single-AZ yang menjalankan MySQL, MariaDB, PostgreSQL dan Edisi SQL Server Express. Tingkat penggunaan gratis dibatasi pada 750 jam instans per bulan. Pelanggan juga menerima 20 GB penyimpanan data (SSD) Tujuan Umum dan 20 GB penyimpanan cadangan gratis per bulan.

Akun AWS yang 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. 50 jam sisanya akan ditagih pada Anda dengan harga standar Amazon RDS.

Tidak. Pelanggan dengan akses ke AWS Tingkat Gratis dapat menggunakan hingga 750 jam instans dari instans Micro yang menjalankan Edisi MySQL, PostgreSQL, atau SQL Server Express. Penggunaan apa pun yang melebihi 750 jam instans di seluruh instans DB Micro Single-AZ Amazon RDS dan di seluruh wilayah dan 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 mengetahui detailnya.

Instans Terpesan Amazon RDS memberi Anda opsi untuk memesan instans DB untuk jangka waktu satu atau tiga tahun dan sebagai gantinya menerima diskon yang signifikan dibandingkan dengan harga Instans Sesuai Permintaan untuk instans DB tersebut. Ada tiga opsi pembayaran RI – Tanpa Biaya di Muka, Biaya di Muka Sebagian, Semua di Muka – yang memungkinkan Anda menyeimbangkan jumlah yang Anda bayar di muka 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 terpesan di suatu Wilayah, semua instans DB akan ditagih dengan tarif per jam sesuai permintaan.

Anda dapat membeli instans terpesan di bagian "Instans Terpesan" 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, kemudian membeli reservasi instans DB.

Setelah Anda melakukan pembelian pencadangan, menggunakan instans DB cadangan 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 terpesan Amazon RDS dibeli untuk Wilayah alih-alih Zona Ketersediaan tertentu. Karena RI tidak spesifik untuk suatu Zona Ketersediaan, maka RI bukanlah reservasi kapasitas. Ini berarti bahwa meskipun kapasitas terbatas dalam satu Zona Ketersediaan, cadangan masih dapat dibeli di Wilayah dan potongan harga akan berlaku untuk penggunaan yang sesuai dalam Zona Ketersediaan mana pun dalam Wilayah tersebut.

Anda dapat membeli hingga 40 instans DB cadangan. Jika Anda ingin menjalankan lebih dari 40 instans DB, silakan 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 reservasi berhasil, Amazon RDS akan secara otomatis menerapkan biaya penggunaan baru per jam Anda ke instans DB yang sudah ada.

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

Ketika jangka waktu pencadangan Anda berakhir, instans terpesan Anda akan kembali ke tarif penggunaan per jam Sesuai Permintaan yang sesuai untuk kelas dan Wilayah instans DB Anda.

Operasi Amazon RDS untuk membuat, mengubah, dan menghapus instans DB tidak berbeda antara instans sesuai permintaan dan terpesan. Saat menghitung tagihan Anda, sistem kami akan secara otomatis menerapkan Pencadangan Anda sedemikian rupa sehingga semua instans DB yang memenuhi syarat dibebankan pada tarif instans DB cadangan 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 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, reservasi juga akan berlaku untuk instans DB yang berjalan di opsi deployment AZ Tunggal atau 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 mengenai fleksibilitas ukuran, lihat Panduan Pengguna Amazon RDS.

Setiap instans terpesan terkait dengan Wilayah tertentu, yang tetap selama masa berlaku reservasi dan tidak dapat diubah. Namun, setiap reservasi dapat digunakan di AZ mana pun yang tersedia dalam Wilayah terkait.

Ya. Ketika Anda membeli instans terpesan, 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 Single-AZ.

Reservasi instans DB dapat diterapkan ke replika baca, dengan kelas dan Wilayah instans DB yang tersedia sama. Saat menghitung tagihan Anda, sistem kami akan secara otomatis menerapkan Reservasi Anda sedemikian rupa sehingga semua instans DB yang memenuhi syarat dibebankan tarif instans terpesan 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, dan penyimpanan aplikasi Anda. Untuk informasi mengenai kelas instans DB yang tersedia, harap lihat Panduan Pengguna Amazon RDS.

Anda dapat menskalakan sumber daya komputasi dan kapasitas penyimpanan yang dialokasikan untuk instans DB Anda dengan Konsol Manajemen AWS (memilih instans DB yang diinginkan dan mengeklik tombol Ubah), 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 untuk SQL Server untuk informasi selengkapnya.

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

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 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 General Purpose (SSD) Amazon RDS sangat sesuai untuk berbagai beban kerja basis data yang memiliki persyaratan I/O yang cukup. Dengan dasar 3 IOPS/GB dan kemampuan untuk mencapai hingga 3.000 IOPS, opsi penyimpanan ini memberikan performa yang dapat diprediksi untuk memenuhi kebutuhan sebagian besar aplikasi.

Penyimpanan IOPS yang Tersedia (SSD) Amazon RDS adalah opsi penyimpanan yang didukung SSD dan didesain untuk menghasilkan 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, harap lihat Panduan Pengguna Amazon RDS.

Penyimpanan magnetik Amazon RDS berguna untuk beban kerja basis data kecil tempat data jarang diakses. Penyimpanan magnetik tidak disarankan untuk instans basis data produksi.

Pilih tipe penyimpanan yang paling cocok dengan beban kerja Anda.

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

IOPS yang didukung Amazon RDS bervariasi berdasarkan mesin basis data. Untuk detail selengkapnya, harap lihat Panduan Pengguna Amazon RDS.

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

Fitur cadangan otomatis Amazon RDS memungkinkan pemulihan titik waktu dari 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 untuk instans DB Anda, yang biasanya berlangsung dalam lima menit terakhir. Cara lainnya, Anda dapat menemukan Waktu Pemulihan Terkini untuk instans DB dengan memilihnya di AWS Management Console dan mencari tab “Deskripsi” di panel bawah Konsol.

Snapshot DB dimulai oleh pengguna dan memungkinkan Anda mencadangkan instans DB Anda dalam keadaan yang diketahui sesering yang diinginkan, kemudian mengembalikan ke keadaan tertentu tersebut kapan saja. Snapshot DB dapat dibuat dengan AWS Management Console, API CreateDBSnapshot, atau perintah create-db-snapshot dan disimpan sampai Anda menghapusnya secara eksplisit.

Snapshot yang dilakukan oleh Amazon RDS untuk mengaktifkan cadangan 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 cadangan otomatis untuk Instans DB Anda dengan 7 hari periode penyimpanan. Penyimpanan cadangan gratis terbatas untuk ukuran basis data yang disediakan dan hanya berlaku untuk Instans DB yang aktif. Contohnya, jika Anda memiliki 100 GB penyimpanan basis data yang disediakan selama satu bulan, kami akan memberikan 100 GB-bulan untuk penyimpanan cadangan tanpa biaya tambahan.

Jika Anda ingin mengubah periode retensi cadangan, Anda dapat melakukannya menggunakan konsol atau API CreateDBInstance (ketika membuat Instans DB baru) atau API ModifyDBInstance (untuk instans yang sudah ada). Anda dapat menggunakan API ini untuk mengubah parameter RetentionPeriod ke jumlah berapa pun dari 0 (yang akan menonaktifkan cadangan otomatis) ke jumlah hari yang diinginkan. Nilai tidak dapat diatur ke 0 jika instans DB merupakan sumber untuk Replika Baca. Untuk informasi selengkapnya mengenai cadangan otomatis, harap 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 deployment 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 Anda melalui bagian “Snapshot” Konsol Amazon RDS. Atau, Anda dapat melihat daftar Snapshot DB buatan pengguna untuk Instans DB yang diberikan menggunakan API DescribeDBSnapshots atau perintah gambarkan-snapshots-db dan menghapus snapshot dengan API DeleteDBSnapshot atau perintah hapus-snapshot-db.

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 privat dan terisolasi dari AWS cloud, tempat Anda dapat melakukan kontrol penuh atas aspek-aspek seperti rentang alamat IP privat, subnet, tabel perutean, dan 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 mengenai 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 mengenai perbedaan antara EC2-Classic dan EC2-VPC, lihat dokumentasi EC2.

Subnet 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 Antarmuka Jaringan Elastis ke Instans DB Anda dengan alamat IP tersebut.

Harap diperhatikan bahwa kami sangat merekomendasikan agar Anda menggunakan Nama DNS untuk terhubung dengan Instans DB Anda karena alamat IP yang mendasarinya 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 deployment Single-AZ, jika Anda ingin mengonversinya ke deployment Multi-AZ di beberapa titik.

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

Kunjungi bagian Grup Keamananpada Panduan Pengguna Amazon RDS untuk mempelajari mengenai 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 di-deploy dalam subnet publik dengan IP Elastis terkait, Anda dapat mengakses Instans EC2 melalui internet. Instans DB yang diterapkan 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 yang Dapat Diakses Publik dari Amazon RDS:

• Untuk menggunakan host bastion, Anda perlu menyiapkan subnet publik dengan instans EC2 yang bertindak sebagai SSH Bastion. 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 mengetahui 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 Konsol Manajemen AWS 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 oleh 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 Zona Ketersediaan yang sudah ada maupun Zona Ketersediaan baru yang ditambahkan sejak pembuatan Instans DB. Menghapus subnet dari Grup Subnet DB yang sudah ada dapat menyebabkan ketidaktersediaan instans jika 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 mungkin juga 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. Harap lihat Panduan Pengguna Amazon RDS untuk daftar hak istimewa terbatas dan alternatif terkait untuk melakukan tugas administratif yang mungkin memerlukan hak istimewa ini.

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

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

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

Ya, opsi ini didukung untuk semua mesin Amazon RDS. Amazon RDS memberikan 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 basis data 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 yang terenkripsi dengan Amazon RDS, harap kunjungi Panduan Pengguna MySQL, Panduan Pengguna MariaDB,Panduan Pengguna SQL Server, Panduan Pengguna PostgreSQL, atau Panduan Pengguna Oracle Amazon RDS. Untuk mempelajari selengkapnya mengenai 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 diam untuk semua mesin basis data, menggunakan 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 mengenai 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 Anda 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 Anda. Pengguna Amazon RDS yang dapat direferensikan di 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 tanda, Anda dapat mengategorikan sumber daya (misalnya, "Pengembangan" Instans DB, "Produksi" Instans DB, dan "Uji" Instans DB), serta menulis kebijakan AWS IAM yang mencantumkan izin (yaitu tindakan) yang dapat diambil untuk sumber daya dengan tanda yang sama. Untuk informasi selengkapnya, lihat Mengelola Akses ke Sumber Daya dan Basis Data Amazon RDS Anda dan Menandai 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. Pelajari selengkapnya mengenai CloudTrail di halaman detail AWS CloudTrail, dan aktifkan melalui halaman beranda Konsol Manajemen AWS CloudTrail.

J: Ya, semua mesin basis data Amazon RDS memenuhi syarat HIPAA, sehingga Anda dapat menggunakannya untuk membuat aplikasi sesuai dengan HIPAA dan menyimpan informasi yang berhubungan pemeliharaan kesehatan, termasuk informasi kesehatan yang dilindungi (PHI) di bawah Perjanjian Rekan Bisnis (BAA) dengan AWS. Jika Anda memiliki BAA yang telah dijalankan, 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 mengenai 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 Konsol Manajemen AWS, API Amazon RDS, atau AWS Command Line Interface. Harap perhatikan bahwa mengubah parameter konfigurasi dari nilai yang direkomendasikan dapat memiliki akibat yang tidak diinginkan, mulai dari penurunan performa hingga kerusakan sistem, dan hanya boleh dilakukan oleh pengguna tingkat lanjut yang ingin menanggung risiko ini.

Grup parameter basis data (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, mengubah parameter yang diinginkan, dan mengubah 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 mengenai cara 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 akan secara otomatis menyediakan dan mempertahankan replika “standby” 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 Zona Ketersediaan, Amazon RDS akan secara otomatis mengalami failover ke standby sehingga Anda dapat melanjutkan basis data 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 mengenai 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 Zona Ketersediaan berjalan di infrastruktur independen dan jauh secara fisik, serta dirancang agar sangat andal. 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 Wilayah yang sama mendapat manfaat dari konektivitas jaringan latensi rendah.

Saat Anda menjalankan instans DB sebagai deployment Multi-AZ, “primer” melayani tulis dan baca basis data. 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 dalam penskalaan lalu lintas baca di luar batasan kapasitas dari instans DB tunggal, silakan lihat FAQ di Replika Baca.

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

Menjalankan instans DB Anda sebagai deployment Multi-AZ akan melindungi data Anda dari kejadian tidak mungkin dari kegagalan komponen instans DB atau hilangnya ketersediaan dalam satu Zona Ketersediaan. 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. Deployment Multi-AZ didesain untuk memberikan peningkatan ketersediaan dan ketahanan basis data, bukan 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, silakan lihat FAQ pada Replika Baca.

Untuk membuat deployment instans DB Multi-AZ, cukup klik opsi “Ya” untuk “Deployment Multi-AZ” ketika 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 untuk MySQL, MariaDB, PostgreSQL, dan Oracle, ketika Anda memilih untuk mengonversi instans Amazon RDS Anda dari Single-AZ ke Multi-AZ, hal berikut 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 dalam proses menyesuaikan ke primer.

Amazon RDS mendeteksi dan pulih secara otomatis dari skenario kegagalan paling umum untuk deployment Multi-AZ sehingga Anda dapat melanjutkan operasi basis data 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 peristiwa instans DB untuk memberi tahu Anda bahwa failover otomatis terjadi. Anda dapat mengeklik bagian “Peristiwa” pada Konsol Amazon RDS atau menggunakan API DescribeEvents untuk mengembalikan informasi mengenai kejadian yang berkaitan dengan instans DB Anda. Anda juga dapat menggunakan Pemberitahuan Kejadian Amazon RDS untuk mendapatkan pemberitahuan saat terjadi peristiwa DB tertentu.

Failover secara otomatis ditangani oleh Amazon RDS sehingga Anda dapat melanjutkan operasi basis data sesegera mungkin tanpa intervensi administratif. Ketika melakukan failover, Amazon RDS hanya membalikkan catatan nama resmi (CNAME) bagi instans DB Anda untuk menunjuk ke standby, yang pada saatnya dipromosikan untuk menjadi primer baru. Kami menyarankan Anda untuk mengikuti praktik terbaik dan mengimplementasikan percobaan ulang koneksi basis data 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 tipe instans yang cukup besar direkomendasikan dengan Multi-AZ untuk mendapatkan hasil terbaik. AWS juga merekomendasikan penggunaan IOPS yang Tersedia dengan instans Multi-AZ, untuk performa 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 Konsol Manajemen AWS atau dengan menggunakan panggilan API RebootDBInstance.

Dengan deployment Multi-AZ, Anda cukup mengatur parameter “Multi-AZ” menjadi benar. Pembuatan replikasi standby, 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 basis data. Pelajari selengkapnya mengenai 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 ke lokasi primer saat ini menggunakan Konsol Manajemen AWSatau API DescribeDBInstances.

Zona Ketersediaan dirancang untuk menyediakan konektivitas jaringan berlatensi rendah ke Zona Ketersediaan 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 Zona Ketersediaan sehingga aplikasi Anda akan dapat tahan apabila terjadi kegagalan Zona Ketersediaan. Deployment Multi-AZ menjawab kebutuhan ini untuk tingkat basis data tanpa administrasi di pihak Anda.

Anda berinteraksi dengan fungsi cadangan otomatis dan Snapshot DB dengan cara yang sama baik ketika Anda menjalankan deployment standar dalam deployment Single-AZ atau Multi-AZ. Jika Anda menjalankan deployment 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 deployment Single-AZ dan Multi-AZ.

Memulai operasi pemulihan (pemulihan atau pengembalian titik waktu dari Snapshot DB) juga bekerja sama dengan deployment Multi-AZ sebagai standar, deployment 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 dalam mengambil keuntungan dari 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 baca yang besar. Anda dapat membuat replika baca dengan beberapa klik di Konsol Manajemen AWS atau menggunakan API CreateDBInstanceReadReplica. Setelah replika baca dibuat, pembaruan basis data 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 kelambatan 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 basis data 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 Zona Ketersediaan, 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 (replikasi “menyusul” untuk setiap Replika Baca akan dimulai setelah dibuat).

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, PostgreSQL, 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, tetapi tetap asinkron.

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

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

Selain itu, dengan deployment Multi-AZ, replikasi terkelola penuh. Amazon RDS secara otomatis memantau kondisi kegagalan instans DB atau kegagalan Zona Ketersediaan 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 deployment produksi dan untuk mengaitkan Replika Baca dengan Deployment 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, dan Oracle memungkinkan Anda mengaktifkan konfigurasi Multi-AZ pada replika baca untuk mendukung pemulihan bencana dan meminimalkan waktu henti dari peningkatan mesin.

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 replika baca tingkat kedua dari replika baca tingkat pertama yang ada. Dengan membuat replika baca tingkat kedua, Anda dapat memindahkan beberapa beban replikasi dari instans basis data primer ke Replika Baca tingkat pertama.

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.

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

Replika baca didesain 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 mengetahui 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 tertinggalnya replika baca dari utama dipublikasikan sebagai metrik Amazon CloudWatch ("Lag 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 Anda 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 mengenai pemecahan masalah replikasi di bagian Pemecahan Masalah Replika Baca pada Panduan Pengguna Amazon RDS for MySQL atau PostgreSQL. Jika kesalahan replikasi telah diperbaiki, Status Replikasi berubah menjadi Sedang Mereplikasi.

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 dengan mudah menghapus replika baca dengan beberapa klik dari Konsol Manajemen AWS atau dengan memberikan 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 Konsol Manajemen AWS.

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, silakan lihat halaman detail untuk mengetahui 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 ketika 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 mengenai 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 dan informasi proses, dengan perincian yang ditentukan.

Untuk tingkat diagnostik dan visualisasi yang lebih dalam pada muatan basis data Anda, dan periode retensi data 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 yang ingin Anda pantau untuk setiap instans dan menyesuaikan dasbor berdasarkan permintaan Anda.

Tidak. Anda dapat mengatur perincian yang berbeda untuk setiap Instans DB di akun Amazon RDS Anda. Anda juga dapat memilih instans yang ingin Anda aktifkan Pemantauan yang Ditingkatkan nya serta mengubah perincian setiap instans kapan pun 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 Log CloudWatch Anda. Anda dapat membuat filter metrik di CloudWatch dari CloudWatch Logs dan menampilkan grafiknya pada dasbor CloudWatch. Untuk detail selengkapnya, harap 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 nilai tersebut.

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 mengenai alarm CloudWatch, harap 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 CloudWatch Logs untuk menyiapkan umpan waktu nyata terdekat untuk metrik. Atau, Anda dapat menggunakan filter di CloudWatch Logs untuk menjembatani metrik di seluruh CloudWatch dan mengintegrasikan aplikasi Anda dengan CloudWatch. Harap kunjungi Dokumentasi Amazon CloudWatch untuk mengetahui detail selengkapnya.

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

Karena metrik dicatat ke Log CloudWatch, tagihan Anda akan didasarkan pada transfer data Log CloudWatch dan tingkat penyimpanan setelah Anda melebihi tingkat gratis Log CloudWatch. 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 Log CloudWatch oleh Pemantauan yang Ditingkatkan untuk suatu instans adalah seperti yang ditunjukkan di bawah ini:

Amazon RDS Proxy adalah fitur proksi basis data yang tersedia dengan sangat baik dan terkelola penuh untuk Amazon RDS. RDS Proxy membuat aplikasi lebih dapat diskalakan, lebih tahan terhadap kegagalan basis data, 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.

Amazon RDS Proxy mengatasi sejumlah kasus penggunaan terkait dengan skalabilitas, ketersediaan, dan keamanan aplikasi Anda, termasuk:

Aplikasi dengan beban kerja tak dapat diprediksi: Aplikasi yang mendukung beban kerja yang sangat bervariasi dapat berusaha untuk membuka koneksi basis data dengan tiba-tiba. Tata kelola koneksi Amazon RDS Proxy memungkinkan Anda untuk dapat menskalakan aplikasi yang berhubungan dengan beban kerja yang tidak dapat diprediksi dengan menggunakan kembali koneksi basis data secara efisien. Pertama, Proxy RDS memungkinkan beberapa koneksi aplikasi untuk berbagi koneksi basis data untuk penggunaan sumber daya basis data yang efisien. Kedua, Proxy RDS memungkinkan Anda untuk memelihara performa basis data yang dapat diprediksi dengan mengatur sejumlah koneksi basis data yang terbuka. Ketiga, RDS Proxy menghapus permintaan-permintaan yang tidak dapat dilayani untuk menjaga kinerja keseluruhan dan ketersediaan aplikasi.

Aplikasi yang sering membuka dan menutup koneksi basis data: Aplikasi yang dibangun pada teknologi seperti Nirserver, PHP, atau Ruby on Rails mungkin sering membuka dan menutup koneksi basis data untuk melayani permintaan aplikasi. Amazon RDS Proxy menjaga sekumpulan koneksi basis data untuk menghindari tekanan tidak perlu pada komputasi dan memori basis data untuk membangun koneksi baru.

Aplikasi yang menjaga koneksi tetap terbuka namun diam: Aplikasi dalam industri seperti SaaS atau eCommerce mungkin menjaga koneksi basis data tetap diam untuk meminimalisir waktu respons saat pelanggan mengaktifkan ulang. Alih-alih menyediakan basis data secara berlebihan untuk mendukung koneksi yang sebagian besar diam, Anda dapat menggunakan Amazon RDS Proxy untuk menahan koneksi diam selagi hanya membangun koneksi basis data sebagaimana diperlukan untuk melayani permintaan aktif secara optimal.

Aplikasi yang memerlukan ketersediaan melalui kegagalan sementara: Dengan Amazon RDS Proxy, Anda dapat membangun aplikasi yang dapat menolerir kegagalan basis data secara transparan tanpa keharusan untuk menulis kode penanganan kegagalan kompleks. Proksi RDS secara otomatis merutekan lalu lintas ke instans basis data baru selagi mempertahankan koneksi aplikasi. Proxy RDS juga melakukan bypass terhadap cache Sistem Nama Domain (DNS) untuk mengurangi jumlah failover hingga 66% untuk basis data Multi-AZ Amazon RDS dan Aurora. Selama failover basis data, aplikasi dapat mengalami penambahan latensi dan transaksi yang sedang berjalan mungkin harus dicoba lagi.

Manajemen keamanan dan kredensial terpusan yang ditingkatkan: Amazon RDS Proxy membantu Anda dalam membangun lebih banyak aplikasi aman dengan memberi Anda pilihan untuk memperkuat autentikasi berbasis IAM dengan basis data relasional. Proksi RDS juga memungkinkan Anda untuk mengelola kredensial basis data secara terpusat melalui 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.

Amazon RDS Proxy 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.

Amazon RDS Proxy tersedia untuk Amazon Aurora dengan kompatibilitas MySQL dan Amazon RDS for MySQL. Dukungan untuk mesin basis data tambahan akan segera hadir.

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 Anda dan menyiapkan fungsi Lambda untuk mengaksesnya hanya dengan beberapa klik di konsol Lambda. Anda dapat mempelajari selengkapnya mengenai cara memulai di Panduan Pengguna Amazon RDS.

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: