Perubahan perilaku di Amazon Redshift

Saat 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.

Tipe data SUPER mendukung string individu yang lebih besar dimulai dengan Patch 205

Dimulai dengan Patch 205, Amazon Redshift mendukung string individu hingga 16.000.000 byte dalam tipe data SUPER (digunakan untuk menyimpan data semistruktur). Batas ini juga berlaku untuk operasi string dalam memori. Untuk menggunakan kemampuan ini, buat grup parameter database dan atur enable_large_strings_opt_in parameter keYes. Kemudian, lampirkan grup parameter ke gudang data Anda. Untuk cluster yang disediakan, Anda harus me-reboot cluster untuk menerapkan perubahan parameter.

Perubahan ini dapat memengaruhi Anda jika Anda menggunakan tipe data SUPER untuk menyimpan dokumen JSON besar. Ini juga dapat memengaruhi Anda jika beban kerja Anda bergantung VARCHAR(MAX) pada tampilan, fungsi yang ditentukan pengguna (UDF), atau prosedur tersimpan yang memproses string yang lebih panjang dari 65.535 byte.

Saat Anda menyet enable_large_strings_opt_in el keYes, operasi dalam memori diselesaikan VARCHAR(MAX) menjadiVARCHAR(16000000). Operasi ini termasukCAST, tampilan, UDF, dan prosedur tersimpan. Mereka kemudian dapat memproses string yang lebih panjang dari 65.535 byte. Perubahan ini tidak mempengaruhi penyimpanan persisten untuk kolom VARCHAR. CREATE TABLEdengan VARCHAR(MAX) terus membuat VARCHAR(65535) kolom. Saat Anda menyetel parameter keNo, Amazon Redshift mempertahankan perilaku gudang data yang ada. Untuk memeriksa status gudang data Anda saat ini, jalankanSELECT is_large_string_enabled();.

Saat Anda mengatur enable_large_strings_opt_in keYes:

• COPYdan INSERT ke kolom SUPER mendukung ukuran yang lebih besar dari batas 65.535-byte sebelumnya. Fungsi string sepertiJSON_PARSE,JSON_SERIALIZE, dan LISTAGG juga mendukung ukuran yang lebih besar ini.

• Tampilan yang ada, UDF, dan prosedur tersimpan tetap dibatasi pada 65.535 byte hingga Anda membuatnya kembali.

• Jika tampilan yang ada menggunakan VARCHAR(MAX) dan objek lain (seperti tampilan lain) bergantung padanya, CREATE OR REPLACE VIEW gagal. Kesalahannya adalah “tidak dapat mengubah tipe data kolom tampilan.” Untuk memperbarui tampilan, jatuhkan objek dependen, jatuhkan dan buat ulang tampilan, lalu buat ulang objek dependen. Anda dapat mengganti tampilan yang menggunakan VARCHAR(MAX) dan tidak memiliki objek dependen tanpa langkah-langkah tambahan ini.

• Jaga pengaturan ini selaras antara produsen berbagi data dan gudang data konsumen.

Saat Anda mengatur enable_large_strings_opt_in keNo:

• Anda tidak dapat COPY atau merang INSERT kai lebih dari 65.535 byte ke dalam kolom SUPER. Anda masih dapat membaca string yang ada melalui SUPER. Namun, casting to VARCHAR(MAX) memotong nilai menjadi 65.535 byte.

• Fungsi string sepertiJSON_PARSE,JSON_SERIALIZE, dan tidak LISTAGG dapat memproses nilai VARCHAR lebih panjang dari 65.535 byte.

• Anda tidak dapat menanyakan tampilan, prosedur tersimpan, dan UDF yang memproses literal string yang lebih panjang dari 65.535 byte.

• Jika Anda membuat tampilan dengan VARCHAR(MAX) saat parameter disetel keYes, dan objek lain (seperti tampilan lain) bergantung padanya, CREATE OR REPLACE VIEW gagal dengan kesalahan “tidak dapat mengubah tipe data kolom tampilan” yang sama. Ikuti langkah-langkah remediasi yang sama yang dijelaskan dalam daftar sebelumnya.

• Pemulihan snapshot lintas-instance dapat gagal menyerap string panjang. Kegagalan ini terjadi ketika snapshot berisi string yang lebih panjang dari 65.535 byte dalam kolom SUPER. Itu terjadi ketika Anda mengembalikan snapshot itu ke cluster tempat parameter ini disetelNo.

Untuk informasi selengkapnya tentang versi patch, lihatVersi cluster untuk Amazon Redshift.

AWS KMS penegakan izin kunci untuk API Tanpa Server Amazon Redshift setelah 17 Agustus 2026

Amazon Redshift Serverless sekarang melakukan pemeriksaan otorisasi baru yang mengharuskan prinsipal IAM memanggil API Tanpa Server Amazon Redshift tertentu untuk memiliki AWS KMS izin eksplisit pada kunci yang dikelola pelanggan yang mengenkripsi namespace target. Sebelumnya, Amazon Redshift melakukan AWS KMS operasi atas nama Anda menggunakan peran layanan Amazon Redshift tanpa memverifikasi apakah kepala sekolah IAM yang memanggil itu sendiri diberi wewenang untuk menggunakan kunci tersebut.

Setelah pemeriksaan otorisasi baru diaktifkan, panggilan API dari prinsipal yang tidak memiliki AWS KMS izin yang diperlukan akan gagal denganValidationException: "Insufficient KMS permissions." Anda mungkin terpengaruh oleh ini jika Anda memiliki ruang nama Amazon Redshift Serverless yang dienkripsi dengan kunci yang dikelola pelanggan dan menggunakan prinsipal IAM untuk memanggil API yang terpengaruh yang tercantum di bawah ini.

Untuk menghindari gangguan, tinjau prinsipal IAM mana di akun Anda yang memanggil API yang tercantum di bawah ini terhadap ruang nama yang dienkripsi dengan kunci yang dikelola pelanggan, dan pastikan prinsipal tersebut memiliki izin yang diperlukan AWS KMS pada kunci tersebut. Anda dapat memberikan izin ini melalui kebijakan AWS KMS utama, kebijakan berbasis identitas IAM, atau hibah. AWS KMS

Perubahan ini tidak mempengaruhi ruang nama yang dienkripsi dengan kunci yang dimiliki default AWS. Jika kepala sekolah IAM Anda sudah memiliki AWS KMS izin yang diperlukan yang tercantum di bawah ini, tidak ada tindakan yang diperlukan.

API yang terpengaruh dan izin yang diperlukan pada kunci yang dikelola pelanggan namespace tercantum di bawah ini:

• CreateWorkgroup,RestoreFromSnapshot, RestoreFromRecoveryPoint - membutuhkankms:Encrypt,kms:GenerateDataKey,kms:CreateGrant, dankms:Decrypt.

• RestoreTableFromSnapshot, RestoreTableFromRecoveryPoint - membutuhkankms:Decrypt.

Untuk informasi selengkapnya, lihat Mengontrol akses ke AWS KMS kunci di Panduan AWS Key Management Service Pengembang. Untuk informasi selengkapnya tentang enkripsi database Amazon Redshift, lihatEnkripsi basis data Amazon Redshift.

Amazon Redshift memberlakukan penguncian pengguna setelah beberapa upaya login gagal dimulai dengan Patch 204

Dimulai dengan Amazon Redshift Patch 204, untuk meningkatkan postur keamanan gudang data Anda, Amazon Redshift secara otomatis mengunci pengguna database setelah melebihi jumlah upaya login gagal berturut-turut yang dikonfigurasi. Fitur ini diaktifkan secara default dengan ambang 5 upaya gagal (dapat dikonfigurasi dari 2 hingga 50) dan berlaku untuk cluster yang disediakan dan grup kerja tanpa server.

Anda mungkin terpengaruh oleh ini jika Anda terhubung menggunakan koneksi database (berbasis kata sandi). Setelah terkunci, upaya login ditolak bahkan dengan kata sandi yang benar sampai administrator atau superuser membukanya. Identitas federasi yang mengotentikasi melalui IAM atau AWS IAM Identity Center tidak terpengaruh, karena mereka menggunakan token berumur pendek daripada kata sandi statis.

Untuk mengelola perilaku ini:

• Atur ambang batas dengan ALTER SYSTEM SET max_failed_login_attempts TO value; (2—50, default 5).

• Periksa status lockout untuk semua pengguna denganSHOW USER LOCKOUT;.

• Buka kunci pengguna denganALTER USER username LOGIN PASSWORD 'password';, yang juga mengatur ulang penghitung upaya gagal.

Untuk informasi selengkapnya, lihat SHOW USER LOCKOUT, ALTER USER, dan max _failed_login_.

Model penagihan yang disempurnakan untuk snapshot manual pada instans Amazon Redshift Serverless dan Amazon Redshift RG efektif 8 Juni 2026

Mulai 08 Juni 2026, Amazon Redshift mengumumkan model penagihan yang disempurnakan untuk snapshot manual pada instans Amazon Redshift Serverless dan Amazon Redshift RG. Dengan peningkatan ini, snapshot manual sekarang diukur berdasarkan blok data unik yang disimpan di semua snapshot manual aktif di akun Anda. Blok data bersama yang muncul di beberapa snapshot hanya dihitung sekali, ditagih dengan tarif snapshot manual yang ada untuk wilayah Anda.

Anda mungkin terpengaruh oleh hal ini jika menggunakan snapshot manual di grup kerja Amazon Redshift Serverless atau cluster Amazon Redshift RG. Hal ini menghasilkan biaya snapshot manual yang lebih rendah bagi pelanggan yang memelihara beberapa snapshot.

Tidak ada tindakan yang diperlukan. Model penagihan yang disempurnakan secara otomatis berlaku untuk snapshot manual yang ada dan yang baru.

Untuk informasi selengkapnya tentang harga snapshot, lihat harga https://aws.amazon.com/redshift/pricing/ Amazon Redshift.

Iceberg DELETE pada tabel Formasi Danau memerlukan izin DELETE dimulai dengan Patch 202

Dimulai dengan Amazon Redshift Patch 202, operasi Iceberg DELETE pada tabel yang dikelola Lake Formation (LF) memerlukan izin DELETE Lake Formation. Operasi UPDATE dan MERGE memerlukan izin INSERT dan DELETE. Semua operasi Iceberg DML memerlukan izin ALTER.

Anda mungkin terpengaruh oleh ini jika Anda melakukan operasi DELETE, UPDATE, atau MERGE terhadap tabel Iceberg yang dikelola oleh AWS Lake Formation.

Sebelumnya, prinsipal dengan hanya izin INSERT (dan tanpa izin DELETE) dapat melakukan operasi penghapusan pada tabel LF-managed Iceberg. Dimulai dengan Patch 202, operasi DELETE memerlukan izin DELETE Lake Formation. Prinsipal yang hanya mengandalkan izin INSERT untuk melakukan penghapusan akan menerima kesalahan izin sampai izin DELETE diberikan secara eksplisit. Tabel S3 tidak terpengaruh oleh perubahan ini.

Untuk terus melakukan operasi DELETE setelah perubahan ini, tinjau izin Formasi Danau Anda untuk tabel Gunung Es dan pastikan bahwa kepala sekolah yang melakukan operasi penghapusan memiliki izin DELETE Lake Formation yang diberikan. Anda dapat memverifikasi hibah yang ada menggunakan konsol Formasi AWS Danau atau aws lakeformation list-permissions AWS CLI perintah.

Jika Anda perlu untuk sementara kembali ke perilaku sebelumnya, hubungi AWS Dukungan untuk menonaktifkan perubahan ini di cluster Anda tanpa memerlukan penerapan kode.

Untuk informasi selengkapnya tentang versi patch, lihatVersi cluster untuk Amazon Redshift.

Amazon Redshift Serverless mempertahankan integrasi peristiwa Zero-ETL dan S3 pada pemulihan snapshot dimulai dengan Patch 202

Dimulai dengan Amazon Redshift Patch 202, saat Anda memulihkan namespace Amazon Redshift Serverless dari snapshot atau titik pemulihan ke namespace tanpa server yang sama, integrasi peristiwa Zero-ETL dan S3 yang terkait dengan namespace dan titik dipertahankan secara otomatis. snapshot/recovery Tidak diperlukan tindakan tambahan.

Anda mungkin terpengaruh oleh hal ini jika memulihkan snapshot atau titik pemulihan ke ruang nama Amazon Redshift Serverless yang memiliki integrasi peristiwa Zero-ETL atau S3 yang dikonfigurasi.

Sebelumnya, memulihkan snapshot atau titik pemulihan ke namespace tanpa server menandai integrasi peristiwa Zero-ETL dan S3 terkait sebagai gagal, mengharuskan Anda membuat ulang secara manual setelah pemulihan selesai. Dimulai dengan Patch 202, integrasi ini dipertahankan secara default dan melanjutkan operasi setelah pemulihan selesai.

Fitur ini berlaku untuk Amazon Redshift Serverless hanya ketika dipulihkan ke namespace tanpa server yang sama. Memulihkan snapshot ke namespace yang berbeda tidak mempertahankan integrasi. Pemulihan snapshot pada cluster yang disediakan tidak mempertahankan integrasi peristiwa Zero-ETL atau S3.

Untuk memilih tidak mempertahankan integrasi selama pemulihan, hapus centang pada kotak Per tahankan Integrasi pada halaman pemulihan di. Konsol Manajemen AWS Jika Anda menggunakan AWS CLI, setel --no-maintain-integration parameter saat memanggil operasi API restore-from-snapshot atau restore-from- recovery-point. https://docs.aws.amazon.com/redshift-serverless/latest/APIReference/API_RestoreFromRecoveryPoint.html Saat Anda memilih keluar, integrasi masuk ke FAILED status setelah pemulihan. Anda kemudian dapat menghapus integrasi yang gagal dan membuatnya kembali.

Untuk informasi selengkapnya tentang versi patch, lihatVersi cluster untuk Amazon Redshift.

Akhir dukungan untuk driver Amazon Redshift ODBC 1.x pada 30 September 2026

Mulai 30 September 2026, Amazon Redshift akan menghentikan dukungan untuk driver ODBC 1.x. Berdasarkan umpan balik pelanggan, kami telah memperpanjang tanggal akhir dukungan asli dari 30 Juni 2026 hingga 30 September 2026, untuk memberikan waktu tambahan untuk migrasi. Ini berlaku untuk cluster yang disediakan Amazon Redshift dan grup kerja tanpa server.

Anda mungkin terpengaruh oleh ini jika Anda menggunakan versi driver ODBC 1.x apa pun untuk terhubung ke Amazon Redshift. Untuk memverifikasi apakah Anda menggunakan driver ODBC 1.x, jalankan kueri berikut:

SELECT *
FROM SYS_CONNECTION_LOG
WHERE 
(driver_version ilike 'Amazon Redshift ODBC Driver 1%'
OR driver_version ilike 'Redshift ODBC Driver 01%'
OR driver_version ilike 'Redshift ODBC Driver 1,%'
)
OR
(application_name ilike 'Amazon Redshift ODBC Driver 1%');

Untuk terus menerima dukungan teknis untuk koneksi driver ODBC Amazon Redshift Anda, silakan bermigrasi ke driver Amazon Redshift ODBC 2.x terbaru sebelum 29 September 2026.

Sebelum bermigrasi ke driver ODBC 2.x di lingkungan produksi, kami sarankan melakukan bukti konsep menyeluruh untuk memverifikasi bahwa driver baru memenuhi semua persyaratan fungsional Anda.

Sebaiknya gunakan driver Amazon Redshift ODBC 2.x versi terbaru dan mengatur ApplicationName properti untuk mengidentifikasi aplikasi Anda saat menghubungkan ke Amazon Redshift.

UDF Python Scalar akan mencapai akhir dukungan setelah 30 Juni 2026

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

UDF Lambda memiliki keunggulan berikut dibandingkan UDF Python:

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

• UDF Lambda menggunakan sumber daya komputasi Lambda. UDF Lambda yang padat dengan komputasi atau memori tidak memengaruhi kinerja kueri atau konkurensi sumber daya Amazon Redshift.

• Lambda UDF mendukung menjalankan kode Python. Lambda UDF 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 membuat dan menggunakan UDF Lambda, lihat UDF Scalar Lambda di Panduan Pengembang Database Amazon Redshift. Untuk informasi tentang mengonversi UDF Python yang ada ke UDF Lambda, lihat posting blog. https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/

Perubahan Perilaku Tampilan Terwujud (MV) Auto-REFRESH setelah 27 Februari 2026

Mulai 27 Februari 2026, kueri Auto REFRESH untuk tampilan terwujud Amazon Redshift dijalankan sebagai kueri pengguna daripada proses otonom latar belakang. Akibatnya, kueri Auto REFRESH sekarang berjalan dengan prioritas yang sama dengan kueri pengguna lainnya.

Perubahan ini meningkatkan kesegaran tampilan yang terwujud dengan Auto REFRESH diaktifkan, membantu mereka tetap up to date dengan perubahan terbaru pada tabel dasar mereka dibandingkan dengan perilaku sebelumnya.

Catatan: Fitur perubahan perilaku MV Auto REFRESH hanya diaktifkan untuk cluster Amazon Redshift Provisioned pada Track CURRENT dari rilis patch P198 dan yang lebih baru. Saat ini dinonaktifkan di Serverless.

Amazon Redshift tidak akan mendukung fungsi yang mengakses informasi konsumen melalui berbagi data setelah 16 Februari 2026

Mulai 16 Februari 2026, Amazon Redshift tidak akan lagi mendukung penggunaan user_is_member_of dan fungsi terkait yang mengakses pengguna konsumen, peran, atau informasi grup melalui pembagian data.

Perubahan versi Minimum Transport Layer Security (TLS) berlaku mulai 30 September 2026

Mulai 30 September 2026, Amazon Redshift akan memberlakukan Transport Layer Security (TLS) versi 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. Gudang data Amazon Redshift yang tidak menggunakan TLS tidak akan terpengaruh oleh perubahan ini.

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

Untuk memverifikasi versi TLS mana yang saat ini 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 versi terbaru dari driver Amazon Redshift [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 tidak akan mendukung pembuatan UDF Python skalar baru setelah 30 Oktober 2025

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

UDF Lambda memiliki keunggulan berikut dibandingkan UDF Python:

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

• UDF Lambda menggunakan sumber daya komputasi Lambda. UDF Lambda yang padat dengan komputasi atau memori tidak memengaruhi kinerja kueri atau konkurensi sumber daya Amazon Redshift.

• Lambda UDF mendukung menjalankan kode Python. Lambda UDF 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 membuat dan menggunakan UDF Lambda, lihat UDF Scalar Lambda di Panduan Pengembang Database Amazon Redshift. Untuk informasi tentang mengonversi UDF Python yang ada ke UDF Lambda, lihat posting blog. https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/

Perubahan perilaku terbaru

Topik

• Amazon Redshift menggunakan Database Zona Waktu IANA terbaru setelah 26 Agustus 2025

• Perubahan RPU Tanpa Server Amazon Redshift efektif setelah 15 Agustus 2025

• Perubahan pencatatan audit database efektif setelah 10 Agustus 2025

• Perubahan Virtual Private Cloud Endpoint untuk kelompok kerja tanpa server efektif setelah 27 Juni 2025

• Perubahan pemantauan kueri efektif setelah 2 Mei 2025

• Perubahan keamanan efektif setelah 10 Januari 2025

Amazon Redshift menggunakan Database Zona Waktu IANA terbaru setelah 26 Agustus 2025

Mulai 26 Agustus 2025, Amazon Redshift menghitung zona waktu dengan mengadopsi patch Database Zona Waktu IANA terbaru. Perubahan ini mengubah cara konversi tanggal dan waktu berfungsi untuk zona waktu dan periode waktu tertentu. Pembaruan ini memengaruhi konversi zona waktu eksplisit, seperti yang dilakukan dengan fungsi CONVERT_TIMEZONE atau perintah TIMEZONE dan AT TIME ZONE, serta konversi implisit yang terjadi selama operasi pengecoran tipe, terutama antara format TIMESTAMP dan TIMESTAMPTZ. https://docs.aws.amazon.com/redshift/latest/dg/r_Datetime_types.html#r_Datetime_types-timestamptz

Berikut ini adalah daftar pembaruan untuk kombinasi zona waktu dan periode waktu:

• Zona waktu sekarang mengamati dengan benar waktu musim panas (DST) setelah tahun 2038. Sebelumnya, tidak ada zona waktu yang diamati DST setelah 2038.

• Zona America/Toronto waktu, dan zona waktu yang terhubung dengannya, memiliki sakelar DST pada 1947-1950 pada pukul 2 pagi waktu setempat, bukan pada tengah malam.

• Amazon Redshift sekarang mencerminkan waktu rata-rata lokal (LMT) dengan benar untuk periode sebelum standardisasi untuk semua zona waktu. Periode ini khusus untuk zona waktu, dengan sebagian besar zona waktu beralih ke standarisasi sebelum pertengahan abad ke-19.

• EET,CET, WET dan sekarang MET diperlakukan sebagai zona waktu normal alih-alih singkatan.

• Nama zona waktu berikut tidak ada lagi di Amazon Redshift:

  • Asia/Riyadh87

  • Asia/Riyadh88

  • Asia/Riyadh89

  • Mideast/Riyadh87

  • Mideast/Riyadh88

  • Mideast/Riyadh89

  • US/Pacific-New

Untuk informasi lebih lanjut tentang Basis Data Zona Waktu IANA, lihat Bas is Data Zona Waktu di situs web IANA Time Zone Database.

Perubahan RPU Tanpa Server Amazon Redshift efektif setelah 15 Agustus 2025

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

Perubahan pencatatan audit database 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 sebagai SERVICE-PRINCIPAL gantinya, dalam kebijakan bucket S3 untuk pencatatan audit. Untuk informasi tentang pencatatan audit, lihatIzin bucket untuk pencatatan audit Amazon Redshift.

Untuk menghindari gangguan pencatatan, 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 Dukungan.

Perubahan Virtual Private Cloud Endpoint untuk kelompok kerja tanpa server efektif setelah 27 Juni 2025

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

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

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

Topik

• Perubahan pemantauan kueri efektif setelah 2 Mei 2025

• Perubahan keamanan efektif setelah 10 Januari 2025

Perubahan pemantauan kueri efektif setelah 2 Mei 2025

Berlaku 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 Query Limits untuk kelompok 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 kelompok kerja Redshift Serverless.

Batas kueri dirancang untuk menangkap kueri yang tidak dapat dihindari. Namun, Query CPU time (max_query_cpu_time) dan Query CPU usage (max_query_cpu_percentage) dapat bervariasi selama masa pakai kueri, dan dengan demikian bukan metode yang efektif secara konsisten untuk menangkap kueri yang tidak berhasil. Untuk menangkap kueri tak terduga, 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.

• Return row count (max_scan_row_count): Untuk memantau skala data yang sedang diproses.

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

Untuk daftar lengkap metrik yang didukung, lihat Metrik pemanta uan kueri untuk Amazon Redshift Serverless.

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 grup kerja tanpa server dan cluster yang disediakan untuk membuat perubahan yang diperlukan agar selaras dengan setelan 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 V PC. Perubahan ini akan tercermin dalam operasi CreateCluster dan RestoreFromClusterSnapshot API, dan SDK dan AWS CLI perintah yang sesuai. Jika Anda membuat cluster yang disediakan dari konsol Amazon Redshift, maka akses publik cluster dinonaktifkan secara default.

Jika Anda masih memerlukan akses publik, Anda harus mengganti default dan mengatur PubliclyAccessible parameter ke true saat Anda menjalankan CreateCluster operasi RestoreFromClusterSnapshot API. Dengan cluster yang dapat diakses publik, sebaiknya gunakan grup keamanan atau daftar kontrol akses jaringan (ACL) untuk membatasi akses. Untuk informasi selengkapnya, lihat Grup keamanan VPC dan Mengkonfigurasi pengaturan komunikasi grup keamanan untuk cluster Amazon Redshift atau grup kerja Amazon Redshift Serverless.

Enkripsi secara default

Setelah 10 Januari 2025, Amazon Redshift akan lebih meningkatkan keamanan data dan cluster 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 lagi tersedia saat menggunakan Konsol Manajemen AWS, AWS CLI, atau API untuk membuat cluster yang disediakan tanpa menentukan kunci KMS. Cluster akan secara otomatis dienkripsi dengan Kunci milik AWS.

Pembaruan ini mungkin berdampak pada Anda jika Anda membuat cluster yang tidak dienkripsi menggunakan skrip otomatis atau memanfaatkan berbagi data dengan cluster yang tidak dienkripsi. Untuk memastikan transisi yang mulus, perbarui skrip Anda yang membuat cluster yang tidak terenkripsi. Selain itu, jika Anda secara teratur membuat cluster konsumen baru yang tidak terenkripsi dan menggunakannya untuk berbagi data, tinjau konfigurasi Anda untuk memastikan cluster produsen dan konsumen keduanya 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 baru dibuat dan dipulihkan. Perubahan default ini juga akan berlaku untuk kelompok 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 disetel ke true secara 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 Serverless, nilai default require_ssl di config-parameters akan diubah menjadi. true Setiap permintaan untuk membuat grup kerja baru dengan diset require_ssl el ke false akan ditolak. Anda dapat mengubah require_ssl nilai 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.