View a markdown version of this page

Konsep dan terminologi Proksi RDS - Amazon Aurora
Ikhtisar konsep Proksi RDSPengumpulan koneksiKeamananFailoverTransaksi

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Konsep dan terminologi Proksi RDS

Anda dapat menyederhanakan manajemen koneksi untuk klaster DB Amazon Aurora dengan menggunakan Proksi RDS.

Proksi RDS menangani lalu lintas jaringan antara aplikasi klien dan basis data. Tindakan ini dilakukan secara aktif terlebih dahulu dengan memahami protokol basis data. Lalu perilakunya disesuaikan berdasarkan operasi SQL dari aplikasi Anda dan serangkaian hasil dari basis data.

Proksi RDS mengurangi overhead memori dan CPU untuk manajemen koneksi pada basis data Anda. Basis data membutuhkan lebih sedikit sumber daya memori dan CPU saat aplikasi membuka banyak koneksi secara bersamaan. Logika juga tidak dibutuhkan dalam aplikasi Anda untuk menutup dan membuka kembali koneksi yang idle dalam waktu yang lama. Demikian pula, logika aplikasi yang dibutuhkan untuk membangun kembali koneksi juga lebih sedikit jika terjadi masalah pada basis data.

Infrastruktur untuk Proksi RDS memiliki ketersediaan tinggi dan di-deploy pada berbagai Zona Ketersediaan (AZ). Komputasi, memori, dan penyimpanan untuk Proksi RDS tidak bergantung pada klaster DB Aurora. Independensi ini membantu menurunkan overhead pada server basis data Anda, sehingga dapat mencurahkan sumber dayanya untuk melayani beban kerja basis data. Sumber daya komputasi Proksi RDS bersifat nirserver, yang diskalakan secara otomatis berdasarkan beban kerja basis data Anda.

Ikhtisar konsep Proksi RDS

Proksi RDS menangani infrastruktur untuk melakukan pengumpulan koneksi dan fitur lain yang dijelaskan di bagian berikutnya. Anda melihat proksi ditampilkan dalam konsol RDS pada halaman Proksi.

Setiap proksi menangani koneksi ke klaster DB Aurora tunggal. Proksi secara otomatis menentukan instance penulis saat ini untuk instans yang disediakan Aurora.

Koneksi yang dibiarkan terbuka dan disediakan oleh proksi untuk digunakan oleh aplikasi basis data Anda akan membentuk kumpulan koneksi.

Secara default, Proksi RDS dapat menggunakan ulang koneksi setelah setiap transaksi dalam sesi Anda. Penggunaan kembali tingkat transaksi ini disebut multiplexing. Jika Proksi RDS secara temporer menghapus satu koneksi dari kumpulan koneksi untuk menggunakannya kembali, operasi tersebut disebut borrowing koneksi. Jika aman dilakukan, Proksi RDS akan mengembalikan koneksi tersebut ke kumpulan koneksi.

Dalam beberapa kasus, Proksi RDS tidak dapat memastikan keamanan penggunaan ulang sebuah koneksi basis data di luar sesi saat ini. Untuk kasus seperti ini, Proksi RDS akan tetap mempertahankan sesi pada koneksi yang sama hingga sesi berakhir. Perilaku fallback ini disebut pinning.

Proksi memiliki titik akhir default. Anda terhubung ke titik akhir ini saat menggunakan klaster DB Amazon Aurora. Anda melakukannya alih-alih menghubungkan ke read/write titik akhir yang terhubung langsung ke . Titik akhir tujuan khusus untuk klaster Aurora tetap tersedia untuk Anda gunakan. Untuk cluster , Anda juga dapat membuat titik akhir tambahan read/write dan read-only. Untuk informasi selengkapnya, lihat Ikhtisar titik akhir proksi.

Misalnya, Anda masih dapat terhubung ke titik akhir cluster untuk read/write koneksi tanpa pengumpulan koneksi. Anda masih dapat terhubung ke titik akhir pembaca untuk koneksi keseimbangan beban hanya-baca. Anda masih dapat terhubung ke titik akhir instans untuk melakukan diagnosis dan memecahkan masalah instans DB tertentu dengan klaster. Jika Anda menggunakan AWS layanan lain seperti AWS Lambda untuk menyambung ke database RDS, ubah pengaturan koneksi mereka untuk menggunakan titik akhir proxy. Misalnya, tentukan titik akhir proksi untuk mengizinkan fungsi Lambda mengakses basis data Anda sekaligus memanfaatkan fungsionalitas Proksi RDS.

Setiap proksi berisi sebuah grup target. Grup target ini berisi klaster DB Aurora yang menjadi tujuan koneksi proksi. Untuk klaster Aurora, grup target dikaitkan secara default dengan semua instans DB dalam klaster tersebut. Dengan demikian, proksi dapat terhubung ke instans DB Aurora mana pun yang dipromosikan menjadi instans penulis dalam klaster. klaster DB Aurora yang terkait dengan proksi disebut sebagai target proksi tersebut. Untuk kemudahan, saat Anda membuat proksi melalui konsol, Proksi RDS juga membuat grup target yang sesuai dan mendaftarkan target terkait ini secara otomatis.

Keluarga mesin adalah serangkaian mesin basis data terkait yang menggunakan protokol DB yang sama. Anda dapat memilih keluarga mesin untuk setiap proksi yang Anda buat.

Pengumpulan koneksi

Setiap proxy melakukan pengumpulan koneksi secara terpisah untuk instance penulis dan pembaca dari database Aurora DB. Pengumpulan koneksi adalah pengoptimalan yang menurunkan overhead yang terkait dengan pembukaan dan penutupan koneksi dan dengan menjaga banyak koneksi terbuka secara bersamaan. Overhead ini mencakup memori yang diperlukan untuk menangani setiap koneksi baru. Ini juga melibatkan overhead CPU untuk menutup setiap koneksi dan membuka koneksi yang baru. Contohnya termasuk Transport Lay Security/Secure er Sockets Lay TLS/SSL er () handshake, otentikasi, kemampuan negosiasi, dan sebagainya. Pengumpulan koneksi menyederhanakan logika aplikasi Anda. Anda tidak perlu menulis kode aplikasi untuk meminimalkan jumlah koneksi terbuka secara bersamaan.

Setiap proksi juga melakukan multipleks koneksi, yang juga dikenal sebagai penggunaan ulang koneksi. Dengan multiplexing, Proksi RDS melakukan semua operasi untuk transaksi menggunakan satu koneksi basis data acuan. RDS kemudian dapat menggunakan koneksi yang berbeda untuk transaksi berikutnya. Anda dapat membuka banyak koneksi ke proksi secara bersamaan, dan proksi akan mempertahankan koneksi terbuka dalam jumlah yang lebih kecil ke instans atau klaster DB. Tindakan ini akan lebih meminimalkan overhead memori untuk koneksi di server basis data. Teknik ini juga mengurangi kemungkinan kesalahan "terlalu banyak koneksi".

Keamanan Proksi RDS

RDS Proxy menggunakan mekanisme keamanan RDS yang ada seperti TLS/SSL dan AWS Identity and Access Management (IAM). Untuk informasi umum tentang fitur keamanan tersebut, lihat Keamanan di . Selain itu, pastikan Anda benar-benar mengetahui bagaimana cara kerja Aurora dengan autentikasi, otorisasi, dan bidang keamanan lainnya.

Proksi RDS dapat bertindak sebagai lapisan keamanan tambahan antara aplikasi klien dan basis data acuan. Misalnya, Anda dapat menyambung ke proxy menggunakan TLS 1.3, bahkan jika instance DB yang mendasarinya mendukung versi TLS yang lebih lama. Anda dapat menyambung ke proxy menggunakan peran IAM meskipun proxy terhubung ke database menggunakan metode otentikasi pengguna dan kata sandi basis data. Dengan menggunakan teknik ini, Anda dapat menerapkan persyaratan autentikasi yang kuat untuk aplikasi basis data tanpa sebuah upaya migrasi yang mahal untuk instans DB itu sendiri.

Anda dapat menggunakan metode otentikasi berikut dengan RDS Proxy:

  • Kredensibilitas database

  • Otentikasi IAM standar

  • End-to-end Otentikasi IAM

Menggunakan IAM dengan RDS Proxy

RDS Proxy menawarkan dua metode otentikasi IAM:

  • Otentikasi IAM standar: Menerapkan otentikasi IAM untuk koneksi ke proxy Anda saat proxy terhubung ke database menggunakan kredenSIAL yang disimpan di Secrets Manager. Ini memberlakukan otentikasi IAM untuk akses database bahkan jika database menggunakan otentikasi kata sandi asli. Proksi mengambil kredentif database dari Secrets Manager dan menangani otentikasi ke database atas nama aplikasi Anda.

  • End-to-end Otentikasi IAM: Menegakkan otentikasi IAM untuk koneksi langsung dari aplikasi Anda ke database Anda melalui proxy. End-to-end Otentikasi IAM menyederhanakan konfigurasi keamanan Anda dan menghindari manajemen kredensia database di Secrets Manager. Lapisan keamanan tambahan ini memberlakukan kontrol IAM-based akses dari aplikasi klien ke database.

Untuk menggunakan otentikasi IAM standar, konfigurasikan proxy Anda untuk menggunakan rahasia Manajer Rahasia untuk otentikasi dan aktifkan otentikasi IAM untuk koneksi klien. Aplikasi Anda mengotentikasi ke proxy menggunakan IAM, sementara proxy mengotentikasi ke database menggunakan kredenSIAL yang diambil dari Secrets Manager.

Untuk menggunakan otentikasi IAM ujung ke ujung, konfigurasikan proxy Anda untuk menggunakan otentikasi IAM saat menyetel skema otentikasi default saat membuat atau memodifikasi proxy Anda.

Untuk otentikasi IAM ujung ke ujung, Anda harus memperbarui peran IAM yang terkait dengan proxy untuk memberikan izin. rds-db:connect Dengan otentikasi IAM ujung ke ujung, ini menghilangkan kebutuhan untuk mendaftarkan pengguna database individu dengan proxy melalui rahasia Manajer Rahasia.

Menggunakan TLS/SSL dengan RDS Proxy

Anda dapat terhubung ke RDS Proxy menggunakan TLS/SSL protokol.

catatan

RDS Proxy menggunakan sertifikat dari AWS Certificate Manager (ACM). Jika Anda menggunakan Proksi RDS, Anda tidak perlu mengunduh sertifikat Amazon RDS atau memperbarui aplikasi yang menggunakan koneksi Proksi RDS.

Untuk menerapkan TLS untuk semua koneksi antara proksi dan basis data, Anda dapat menentukan pengaturan Wajibkan Keamanan Lapisan Pengangkutan saat membuat atau mengubah sebuah Konsol Manajemen AWS.

RDS Proxy juga dapat memastikan bahwa sesi Anda menggunakan TLS/SSL antara klien Anda dan titik akhir Proxy RDS. Untuk membuat Proksi RDS melakukannya, tentukan persyaratan pada sisi klien. Variabel sesi SSL tidak diatur untuk koneksi SSL ke basis data menggunakan Proksi RDS.

  • Untuk Aurora MySQL, tentukan persyaratan pada sisi klien dengan parameter --ssl-mode saat Anda menjalankan perintah mysql.

  • Untuk dan Aurora PostgreSQL, tentukan sslmode=require sebagai bagian dari string conninfo saat Anda menjalankan perintah psql.

RDS Proxy mendukung protokol TLS versi 1.0, 1.1, 1.2, dan 1.3. Anda dapat terhubung ke proksi menggunakan versi TLS yang lebih tinggi daripada yang digunakan dalam basis data acuan.

Secara default, program klien membangun koneksi terenkripsi dengan Proksi RDS, dengan ketersediaan kontrol lebih lanjut melalui opsi --ssl-mode. Dari sisi klien, Proksi RDS mendukung semua mode SSL.

Untuk klien, mode SSL adalah sebagai berikut:

PREFERRED

SSL adalah pilihan pertama, tetapi tidak diharuskan.

DISABLED

Tidak ada SSL yang diperbolehkan.

REQUIRED

Menerapkan SSL.

VERIFY_CA

Menerapkan SSL dan memverifikasi otoritas sertifikat (CA).

VERIFY_IDENTITY

Menerapkan SSL dan memverifikasi CA dan nama host CA.

Saat menggunakan sebuah klien dengan --ssl-mode VERIFY_CA atau VERIFY_IDENTITY, tentukan opsi --ssl-ca yang menunjuk ke CA dalam format .pem. Untuk file .pem yang akan digunakan, unduh semua CA PEM root dari Amazon Trust Services dan tempatkan ke dalam satu file .pem.

Proksi RDS menggunakan sertifikat wildcard, yang berlaku untuk domain dan subdomainnya. Jika Anda menggunakan klien mysql untuk terhubung dengan mode SSL VERIFY_IDENTITY, Anda kini harus menggunakan perintah mysql yang kompatibel dengan MySQL 8.0.

Dukungan Cipher Suite Kustom di Proxy RDS

TLS cipher suite adalah kombinasi standar dari algoritma kriptografi yang digunakan untuk mengamankan koneksi klien-server. Mereka menentukan bagaimana enkripsi dan integritas data diterapkan. Di TLS 1.2 dan sebelumnya, mereka juga menentukan pertukaran kunci dan metode otentikasi. Suite sandi terakhir dinegosiasikan selama jabat tangan TLS.

RDS/Aurora MySQL dan MariaDB

Suite cipher kustom dapat dikonfigurasi melalui grup parameter menggunakan:

  • ssl_cipher— untuk koneksi TLS 1.2

  • tls_ciphersuites— untuk koneksi TLS 1.3

Untuk suite sandi yang didukung oleh mesin, lihat Mengon figurasi suite cipher untuk Aurora MySQL.

RDS/Aurora PostgreSQL

Suite cipher kustom dapat dikonfigurasi melalui grup parameter menggunakan:

  • ssl_ciphers— untuk koneksi TLS 1.2. Di Aurora PostgreSQL 17, ini juga dapat mencakup suite cipher TLS 1.3.

  • ssl_tls13_ciphers— untuk koneksi TLS 1.3

Untuk suite sandi yang didukung oleh mesin, lihat Mengon figurasi suite cipher untuk RDS PostgreSQL dan Meng konfigurasi suite cipher untuk Aurora PostgreSQL.

Perilaku dengan RDS Proxy

Saat menggunakan RDS Proxy, pengaturan cipher suite yang dikonfigurasi pada database berlaku untuk koneksi antara RDS Proxy dan database.

RDS Proxy juga memberlakukan suite cipher terdaftar yang sama untuk koneksi antara aplikasi Anda dan Proxy RDS. Ini memastikan penegakan sandi kustom dari ujung ke ujung — dari aplikasi hingga proxy hingga database — membantu menjaga standar keamanan yang konsisten di seluruh lingkungan Anda.

RDS Proxy hanya mendukung subset tertentu dari cipher suite untuk koneksi TLS. Bahkan jika database mendukung suite cipher tambahan, hanya suite cipher berikut yang didukung oleh RDS Proxy. Menegakkan suite sandi lain pada koneksi klien ke proxy akan menyebabkan kegagalan dalam pengaturan koneksi.

Suite Cipher didukung oleh RDS Proxy
# Versi TLS Cipher dalam Format OpenSSL Cipher dalam Format IANA
1 TLS 1.0, TLS 1.1, TLS 1.2 ECDHE-RSA-AES256-SHA TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
2 TLS 1.0, TLS 1.1, TLS 1.2 DHE-RSA-AES256-SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA
3 TLS 1.0, TLS 1.1, TLS 1.2 ECDHE-RSA-AES128-SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
4 TLS 1.0, TLS 1.1, TLS 1.2 DHE-RSA-AES128-SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA
5 TLS 1.2 ECDHE-RSA-AES256-GCM-SHA384 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
6 TLS 1.2 DHE-RSA-AES256-GCM-SHA384 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
7 TLS 1.2 DHE-RSA-AES256-SHA256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
8 TLS 1.2 ECDHE-RSA-AES128-GCM-SHA256 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
9 TLS 1.2 DHE-RSA-AES128-GCM-SHA256 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
10 TLS 1.2 DHE-RSA-AES128-SHA256 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
11 TLS 1.2 DHE-RSA-CHACHA20-POLY1305 TLS_DHE_RSA_DENGAN_CHACHA20_POLY1305_SHA256
12 TLS 1.3 TLS_AES_256_GCM_SHA384 TLS_AES_256_GCM_SHA384
13 TLS 1.3 TLS_AES_128_GCM_SHA256 TLS_AES_128_GCM_SHA256

Dukungan Post-quantum Kriptografi Hibrid (ML-KEM) dalam Proksi RDS

TLS 1.3 mendukung pertukaran kunci pasca-kuantum hibrida melalui grup bernama. Kelompok bernama ini menggabungkan algoritma pertukaran kunci pasca-kuantum ML-KEM dengan algoritma pertukaran kunci Kurva Elliptik Diffie-Hellman (ECDH) klasik—seperti dan. X25519MLKEM768 SecP256r1MLKEM768

RDS Proxy saat ini tidak mendukung kelompok bernama pasca-kuantum hibrida ini. Post-quantumnegosiasi pertukaran kunci hanya berlaku untuk koneksi langsung ke database Anda, bukan untuk koneksi melalui Proxy RDS.

Saat Anda terhubung melalui Proxy RDS:

  • Klien yang menawarkan kelompok pertukaran kunci pasca-kuantum dan klasik menegosiasikan grup klasik dengan RDS Proxy dan berhasil terhubung.

  • Klien yang dikonfigurasi untuk menawarkan hanya grup pertukaran kunci pasca-kuantum (tanpa fallback klasik) tidak dapat terhubung ke RDS Proxy; jabat tangan TLS gagal.

Failover

Failover adalah fitur ketersediaan tinggi yang menggantikan instans basis data dengan yang lain saat instans asli tidak tersedia. Failover dapat terjadi karena sebuah masalah pada instans basis data. Bisa juga bagian dari prosedur pemeliharaan normal, seperti saat peningkatan basis data. Failover berlaku untuk cluster Aurora DB dengan satu atau lebih instance pembaca selain instance penulis.

Terhubung melalui proksi membuat aplikasi Anda lebih tangguh menghadapi failover basis data. Saat instans DB asli tidak tersedia, Proksi RDS akan terhubung ke basis data siaga tanpa kehilangan koneksi aplikasi yang idle. Hal ini dapat membantu mempercepat dan menyederhanakan proses failover. Dampaknya terhadap aplikasi juga lebih kecil dibandingkan masalah boot ulang atau basis data pada umumnya.

Tanpa Proksi RDS, failover dapat menyebabkan pemadaman singkat. Selama pemadaman, Anda tidak dapat melakukan operasi tulis pada basis data dengan failover. Koneksi semua basis data yang ada akan terganggu, dan aplikasi Anda harus membuka ulang koneksi tersebut. Basis data akan tersedia untuk koneksi dan operasi tulis baru saat instans DB hanya-baca dipromosikan menggantikan yang tidak tersedia.

Selama failover DB, Proksi RDS terus menerima koneksi di alamat IP yang sama dan secara otomatis mengarahkan koneksi ke instans DB primer baru. Klien yang terhubung melalui Proksi RDS tidak rentan terhadap hal berikut:

  • Penundaan propagasi Sistem Nama Domain (DNS) saat failover.

  • Caching DNS lokal.

  • Waktu koneksi habis.

  • Ketidakpastian tentang instans DB mana yang merupakan instans penulis saat ini.

  • Menunggu respons kueri dari penulis sebelumnya yang menjadi tidak tersedia tanpa menutup koneksi.

Untuk aplikasi yang mempertahankan kumpulan koneksinya sendiri, melewati Proksi RDS berarti sebagian besar koneksi tetap aktif selama failover atau gangguan lainnya. Hanya koneksi yang berada di tengah transaksi atau pernyataan SQL yang dibatalkan. Proksi RDS segera menerima koneksi baru. Saat penulis basis data tidak tersedia, Proksi RDS akan mengantrekan permintaan masuk.

Untuk aplikasi yang tidak mempertahankan kumpulan koneksinya sendiri, Proksi RDS menawarkan tingkat koneksi yang lebih cepat dan lebih banyak koneksi terbuka. Hal ini menyebabkan overhead yang mahal dikarenakan seringnya koneksi ulang dari basis data. Hal ini dilakukan dengan menggunakan kembali koneksi basis data yang dipertahankan dalam kumpulan koneksi Proksi RDS. Pendekatan ini sangatlah penting untuk koneksi TLS, yang memerlukan biaya penyiapan yang sangat besar.

Transaksi

Semua pernyataan dalam satu transaksi selalu menggunakan koneksi basis data acuan yang sama. Koneksi akan dapat digunakan oleh sesi yang berbeda saat transaksi berakhir. Penggunaan transaksi sebagai unit granularitas memiliki konsekuensi sebagai berikut:

  • Penggunaan ulang koneksi bisa terjadi setelah setiap pernyataan jika pengaturan autocommit Aurora MySQL diaktifkan.

  • Sebaliknya, jika pengaturan autocommit dinonaktifkan, pernyataan pertama yang Anda terbitkan dalam sesi akan memulai transaksi baru. Misalnya, Anda memasukkan urutan pernyataan SELECT, INSERT, UPDATE, dan bahasa manipulasi data (DML) lainnya. Dalam hal ini, penggunaan kembali koneksi tidak terjadi hingga Anda mengeluarkan COMMIT, ROLLBACK, atau mengakhiri transaksi.

  • Memasukkan pernyataan bahasa definisi data (DDL) akan menyebabkan transaksi berakhir setelah pernyataan tersebut selesai.

Proksi RDS mendeteksi waktu saat transaksi berakhir melalui protokol jaringan yang digunakan oleh aplikasi klien basis data. Deteksi transaksi tidak bergantung pada kata kunci seperti COMMIT atau ROLLBACK yang muncul dalam teks pernyataan SQL.

Dalam beberapa kasus, Proksi RDS dapat mendeteksi permintaan basis data yang membuatnya tidak praktis untuk memindahkan sesi Anda ke koneksi yang berbeda. Dalam kasus ini, multiplexing dinonaktifkan untuk koneksi tersebut hingga sesi Anda berakhir. Aturan serupa berlaku jika Proksi RDS tidak dapat memastikan apakah multiplexing praktis untuk sesi ini. Operasi ini disebut pinning. Untuk mendeteksi dan meminimalkan pinning, lihat Menghindari menyematkan Proxy RDS.