Perubahan perilaku di Amazon Redshift - Amazon Redshift
Perubahan perilaku yang akan datangPerubahan perilaku terbaru

Amazon Redshift tidak akan lagi mendukung pembuatan Python UDFs baru mulai 1 November 2025. Jika Anda ingin menggunakan Python UDFs, buat UDFs sebelum tanggal tersebut. Python yang ada UDFs akan terus berfungsi seperti biasa. Untuk informasi lebih lanjut, lihat posting blog.

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

Perubahan perilaku di Amazon Redshift

Seiring Amazon Redshift terus berkembang dan meningkat, perubahan perilaku tertentu diperkenalkan untuk meningkatkan kinerja, keamanan, dan pengalaman pengguna. Halaman ini berfungsi sebagai sumber daya komprehensif bagi Anda untuk tetap mendapat informasi tentang pembaruan penting ini, mengambil tindakan, dan menghindari potensi gangguan pada beban kerja Anda.

Perubahan perilaku yang akan datang

Berikut ini menjelaskan perubahan perilaku yang akan datang.

Scalar UDFs Python akan mencapai akhir dukungan setelah 30 Juni 2026

Amazon Redshift akan mengakhiri dukungan untuk Python UDFs setelah 30 Juni 2026. Sebagai alternatif, kami sarankan Anda menggunakan Lambda UDFs.

Lambda UDFs memiliki keunggulan sebagai berikut dibandingkan Python: UDFs

  • Lambda UDFs dapat terhubung ke layanan eksternal dan APIs dari dalam logika UDF.

  • Lambda menggunakan sumber daya UDFs komputasi Lambda. UDFs Lambda komputasi berat atau intensif memori tidak memengaruhi kinerja kueri atau konkurensi sumber daya Amazon Redshift.

  • UDFs Dukungan Lambda menjalankan kode Python. Lambda UDFs mendukung beberapa runtime Python tergantung pada kasus penggunaan tertentu. Untuk informasi selengkapnya, lihat Membangun dengan Python di Panduan AWS Lambda Pengembang.

  • Anda dapat mengisolasi eksekusi kode kustom dalam batas layanan terpisah. Ini menyederhanakan pemeliharaan, pemantauan, penganggaran, dan manajemen izin.

Untuk informasi tentang cara membuat dan menggunakan Lambda UDFs, lihat Skalar UDFs Lambda di Panduan Pengembang Database Amazon Redshift. Untuk informasi tentang mengonversi UDFs Python yang ada ke UDFs Lambda, lihat posting blog.

Amazon Redshift tidak akan mendukung pembuatan UDFs Python skalar baru setelah 30 Oktober 2025

Amazon Redshift tidak akan lagi mendukung pembuatan Python baru UDFs setelah 30 Oktober 2025. Python yang ada UDFs akan terus berfungsi secara normal. Kami sangat menyarankan agar Anda memigrasikan UDFs Python yang ada ke UDFs Lambda sebelum tanggal ini.

Lambda UDFs memiliki keunggulan sebagai berikut dibandingkan Python: UDFs

  • Lambda UDFs dapat terhubung ke layanan eksternal dan APIs dari dalam logika UDF.

  • Lambda menggunakan sumber daya UDFs komputasi Lambda. UDFs Lambda komputasi berat atau intensif memori tidak memengaruhi kinerja kueri atau konkurensi sumber daya Amazon Redshift.

  • UDFs Dukungan Lambda menjalankan kode Python. Lambda UDFs mendukung beberapa runtime Python tergantung pada kasus penggunaan tertentu. Untuk informasi selengkapnya, lihat Membangun dengan Python di Panduan AWS Lambda Pengembang.

  • Anda dapat mengisolasi eksekusi kode kustom dalam batas layanan terpisah. Ini menyederhanakan pemeliharaan, pemantauan, penganggaran, dan manajemen izin.

Untuk informasi tentang cara membuat dan menggunakan Lambda UDFs, lihat Skalar UDFs Lambda di Panduan Pengembang Database Amazon Redshift. Untuk informasi tentang mengonversi UDFs Python yang ada ke UDFs Lambda, lihat posting blog.

Perubahan versi Minimum Transport Layer Security (TLS) efektif setelah 31 Oktober 2025

Mulai 31 Oktober 2025, Amazon Redshift akan memberlakukan versi Transport Layer Security (TLS) minimum 1.2. Koneksi masuk yang menggunakan TLS versi 1.0 atau 1.1 akan ditolak. Ini berlaku untuk cluster yang disediakan Amazon Redshift dan grup kerja tanpa server.

Pembaruan ini mungkin memengaruhi Anda jika Anda menggunakan TLS versi 1.0 atau 1.1 untuk terhubung ke Amazon Redshift.

Untuk memverifikasi versi TLS yang sedang Anda gunakan, Anda dapat:

Untuk Amazon Redshift Provisioned: Periksa kolom sslversion di tabel sistem STL_CONNECTION_LOG [1].

Untuk Amazon Redshift Serverless Workgroup: Periksa kolom ssl_version di tabel sistem SYS_CONNECTION_LOG [2].

Untuk mempertahankan akses tanpa gangguan ke gudang data Amazon Redshift Anda setelah perubahan ini, ikuti langkah-langkah yang tercantum di bawah ini:

  1. Perbarui klien Anda untuk mendukung TLS 1.2 atau lebih tinggi

  2. Instal versi driver terbaru dengan dukungan TLS 1.2+

Sebaiknya gunakan driver Amazon Redshift versi terbaru [3] jika memungkinkan.

[1] https://docs.aws.amazon.com/redshift/latest/dg/r_STL_CONNECTION_LOG.html

[2] https://docs.aws.amazon.com/redshift/latest/dg/SYS_CONNECTION_LOG.html

[3] https://docs.aws.amazon.com/redshift/latest/mgmt/configuring-connections.html

Amazon Redshift Serverless RPU berubah efektif setelah 15 Agustus 2025

Mulai 15 Agustus 2025, kuota AWS akun untuk Amazon Redshift Serverless basis Redshift Processing Units RPUs () lebih besar dari RPUs 3.200 atau 1,5 kali basis agregat maksimum Anda dari enam bulan sebelumnya. RPUs

Perubahan pencatatan audit basis data efektif setelah 10 Agustus 2025

Mulai 10 Agustus 2025, Amazon Redshift membuat perubahan pada Database Audit Logging, yang memerlukan tindakan Anda. Amazon Redshift mencatat informasi tentang koneksi dan aktivitas pengguna di database Anda ke bucket Amazon S3 dan. CloudWatch Setelah 10 Agustus 2025, Amazon Redshift akan menghentikan pencatatan audit database ke bucket Amazon S3 Anda yang memiliki kebijakan bucket yang menentukan PENGGUNA IAM Redshift. Sebaiknya perbarui kebijakan Anda untuk menggunakan Redshift SERVICE-PRINCIPAL sebagai gantinya, dalam kebijakan bucket S3 untuk pencatatan audit. Untuk informasi tentang pencatatan audit, lihatIzin bucket untuk pencatatan audit Amazon Redshift.

Untuk menghindari gangguan logging, tinjau dan perbarui kebijakan bucket S3 Anda untuk memberikan akses ke prinsipal layanan Redshift di wilayah terkait sebelum 10 Agustus 2025. Untuk informasi tentang pencatatan audit database, lihat Log file di Amazon S3

Untuk pertanyaan atau masalah, hubungi AWS dukungan di tautan berikut: AWS Support.

Perubahan perilaku terbaru

Perubahan Titik Akhir Cloud Pribadi Virtual untuk grup kerja tanpa server efektif setelah 27 Juni 2025

Mulai 27 Juni 2025, Amazon Redshift membuat perubahan pada dukungan Virtual Private Cloud Endpoint (VPCE) untuk grup kerja tanpa server. Sebelum tanggal ini, Amazon Redshift menerapkan dengan titik akhir ke dalam Availability Zone (AZ) tunggal selama pembuatan workgroup, dan memperluas dukungan VPCE hingga tiga dari waktu ke waktu. AZs Setelah tanggal ini, Amazon Redshift menerapkan VPCEs hingga tiga Availability Zone yang ditentukan selama pembuatan workgroup.

Untuk informasi selengkapnya, lihat Pertimbangan saat menggunakan Amazon Redshift Serverless.

Untuk pertanyaan atau masalah, hubungi AWS dukungan di tautan berikut: AWS Support.

Perubahan pemantauan kueri efektif setelah 2 Mei 2025

Efektif 2 Mei 2025, kami tidak akan lagi menawarkan metrik Query CPU time (max_query_cpu_time) dan Query CPU usage (max_query_cpu_percentage) dari tab Batas Kueri untuk grup kerja Redshift Serverless yang ada dan yang baru dibuat. Setelah tanggal ini, kami akan secara otomatis menghapus semua batas kueri berdasarkan metrik ini di semua grup kerja Redshift Tanpa Server.

Batas kueri dirancang untuk menangkap kueri runaway. Namun, Query CPU time (max_query_cpu_time) dan Query CPU usage (max_query_cpu_percentage) dapat bervariasi selama masa kueri, dan dengan demikian bukan metode yang efektif secara konsisten untuk menangkap kueri runaway. Untuk menangkap kueri runaway, sebaiknya Anda memanfaatkan metrik pemantauan kueri yang memberikan informasi yang konsisten dan dapat ditindaklanjuti. Beberapa contoh termasuk:

  • Waktu eksekusi kueri (max_query_execution_time): Untuk memastikan kueri selesai dalam jangka waktu yang diharapkan.

  • Mengembalikan jumlah baris (max_scan_row_count): Untuk memantau skala data yang sedang diproses.

  • Query queue time (max_query_queue_time): Untuk mengidentifikasi kueri yang menghabiskan waktu antrian.

Untuk mengetahui daftar lengkap metrik yang didukung, lihat Metrik pemantauan kueri untuk Amazon Redshift Tanpa Server.

Perubahan keamanan efektif setelah 10 Januari 2025

Keamanan adalah prioritas utama kami di Amazon Web Services (AWS). Untuk itu, kami semakin memperkuat postur keamanan lingkungan Amazon Redshift dengan memperkenalkan default keamanan yang ditingkatkan yang membantu Anda mematuhi praktik terbaik dalam keamanan data tanpa memerlukan pengaturan tambahan dan mengurangi risiko potensi kesalahan konfigurasi. Untuk menghindari potensi gangguan, tinjau konfigurasi, skrip, dan alat pembuatan klaster dan grup kerja tanpa server yang disediakan untuk membuat perubahan yang diperlukan agar selaras dengan pengaturan default baru sebelum tanggal efektif.

Akses publik dinonaktifkan secara default

Setelah 10 Januari 2025, aksesibilitas publik akan dinonaktifkan secara default untuk semua cluster yang baru dibuat, dan untuk cluster yang dipulihkan dari snapshot. Dengan rilis ini, secara default, koneksi ke cluster hanya akan diizinkan dari aplikasi klien dalam Virtual Private Cloud (VPC) yang sama. Untuk mengakses gudang data Anda dari aplikasi di VPC lain, konfigurasikan akses lintas-VPC. Perubahan ini akan tercermin dalam operasi CreateCluster dan RestoreFromClusterSnapshot API, serta SDK dan AWS CLI perintah yang sesuai. Jika Anda membuat klaster yang disediakan dari konsol Amazon Redshift, maka klaster memiliki akses publik yang dinonaktifkan secara default.

Jika Anda masih memerlukan akses publik, Anda harus mengganti default dan menyetel PubliclyAccessible parameter ke true saat Anda menjalankan CreateCluster atau operasi RestoreFromClusterSnapshot API. Dengan klaster yang dapat diakses publik, sebaiknya Anda menggunakan grup keamanan atau daftar kontrol akses jaringan (ACLs) untuk membatasi akses. Untuk informasi selengkapnya, lihat Grup keamanan VPC dan Mengonfigurasi setelan komunikasi grup keamanan untuk klaster Amazon Redshift atau grup kerja Amazon Redshift Tanpa Server.

Enkripsi secara default

Setelah 10 Januari 2025, Amazon Redshift akan lebih meningkatkan keamanan data dan klaster dengan mengaktifkan enkripsi sebagai pengaturan default untuk semua cluster yang disediakan Amazon Redshift yang baru dibuat. Ini tidak berlaku untuk cluster yang dipulihkan dari snapshot.

Dengan perubahan ini, kemampuan untuk mendekripsi cluster tidak akan lagi tersedia saat menggunakan AWS Management Console, AWS CLI, atau API untuk membuat klaster yang disediakan tanpa menentukan kunci KMS. Cluster akan secara otomatis dienkripsi dengan file. Kunci milik AWS

Pembaruan ini dapat memengaruhi Anda jika Anda membuat kluster yang tidak terenkripsi menggunakan skrip otomatis atau memanfaatkan berbagi data dengan kluster yang tidak terenkripsi. Untuk memastikan transisi yang mulus, perbarui skrip Anda yang membuat cluster yang tidak terenkripsi. Selain itu, jika Anda secara teratur membuat kluster konsumen baru yang tidak terenkripsi dan menggunakannya untuk berbagi data, tinjau konfigurasi Anda untuk memastikan produsen dan kluster konsumen dienkripsi, mencegah gangguan pada aktivitas berbagi data Anda. Untuk informasi selengkapnya, lihat Enkripsi basis data Amazon Redshift.

Menegakkan koneksi SSL

Setelah 10 Januari 2025, Amazon Redshift akan menerapkan koneksi SSL secara default untuk klien yang terhubung ke cluster yang disediakan dan dipulihkan yang baru dibuat. Perubahan default ini juga akan berlaku untuk grup kerja tanpa server.

Dengan perubahan ini, grup parameter default baru bernama default.redshift-2.0 akan diperkenalkan untuk semua cluster yang baru dibuat atau dipulihkan, dengan require_ssl parameter diatur ke secara true default. Setiap cluster baru yang dibuat tanpa grup parameter tertentu akan secara otomatis menggunakan grup default.redshift-2.0 parameter. Saat membuat cluster melalui konsol Amazon Redshift, grup default.redshift-2.0 parameter baru akan dipilih secara otomatis. Perubahan ini juga akan tercermin dalam operasi CreateCluster dan RestoreFromClusterSnapshot API, dan SDK dan AWS CLI perintah yang sesuai. Jika Anda menggunakan grup parameter yang ada atau kustom, Amazon Redshift akan terus menghormati require_ssl nilai yang ditentukan dalam grup parameter Anda. Anda terus memiliki opsi untuk mengubah require_ssl nilai dalam grup parameter kustom Anda sesuai kebutuhan.

Untuk pengguna Amazon Redshift Tanpa Server, nilai default di require_ssl dalam config-parameters akan diubah menjadi. true Setiap permintaan untuk membuat grup kerja baru dengan require_ssl set to false akan ditolak. Anda dapat mengubah require_ssl nilainya false setelah workgroup dibuat. Untuk informasi selengkapnya, lihat Mengkonfigurasi opsi keamanan untuk koneksi.

Perhatikan bahwa Anda masih memiliki kemampuan untuk memodifikasi pengaturan cluster atau workgroup untuk mengubah perilaku default, jika diperlukan untuk kasus penggunaan spesifik Anda.