Encryption in transit forces all Redshift client connections to use SSL/TLS, protecting data while it moves across the network.
Encryption in transit ensures every byte sent between your application and Redshift travels inside an SSL/TLS tunnel. It prevents attackers from sniffing credentials, SQL text, or result sets.
Create or edit a parameter group and set require_ssl
to 1
, then reboot the cluster. From that point, only SSL connections are accepted.
psql needs sslmode=require
.JDBC/ODBC need ssl=true
(and optionally sslfactory=com.amazon.redshift.ssl.NonValidatingFactory
if you skip certificate validation).
Run SELECT ssl_cipher FROM stl_connection_log WHERE pid = pg_backend_pid();
. A non-NULL cipher confirms SSL.
Yes.After SSL handshake, SQL works normally—e.g., SELECT * FROM Customers LIMIT 10;
runs exactly the same.
Always rotate certificates, pin the Amazon root CA in apps, and monitor stl_connection_log
for non-SSL attempts.
Limit your Redshift security group to port 5439 and require SSL inside the cluster; block other ports entirely.
AWS Config rules, CloudTrail events, and Redshift system views (stv_recents
, stl_connection_log
) reveal whether plaintext connections ever occur.
.
Negligibly. SSL handshake is a one-time cost; data-transfer overhead is generally under 2%.
No. Redshift provides an Amazon-signed certificate. Use a custom CA only if corporate policy demands it.
Only if require_ssl
=0. Once enabled, every connection—BI tools, scripts, apps—must use SSL.