Amazon Redshift will no longer support the creation of new Python UDFs starting Patch 198. Existing Python UDFs will continue to function until June 30, 2026. For more information, see the [ blog post ](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/).
# Encryption in transit
You can configure your environment to protect the confidentiality and integrity of data in transit.
The following details apply to encryption of data in transit between an Amazon Redshift cluster and SQL clients over JDBC/ODBC:
+ You can connect to Amazon Redshift clusters from SQL client tools over Java Database Connectivity (JDBC) and Open Database Connectivity (ODBC) connections.
+ Amazon Redshift supports Secure Sockets Layer (SSL) connections to encrypt data and server certificates to validate the server certificate that the client connects to. The client connects to the leader node of an Amazon Redshift cluster. For more information, see [Configuring security options for connections](connecting-ssl-support.md).
+ To support SSL connections, Amazon Redshift creates and installs AWS Certificate Manager (ACM) issued certificates on each cluster. For more information, see [Transitioning to ACM certificates for SSL connections](connecting-transitioning-to-acm-certs.md).
+ To protect your data in transit within the AWS Cloud, Amazon Redshift uses hardware accelerated SSL to communicate with Amazon S3 or Amazon DynamoDB for COPY, UNLOAD, backup, and restore operations.
The following details apply to encryption of data in transit between an Amazon Redshift cluster and Amazon S3 or DynamoDB:
+ Amazon Redshift uses hardware accelerated SSL to communicate with Amazon S3 or DynamoDB for COPY, UNLOAD, backup, and restore operations.
+ Redshift Spectrum supports the Amazon S3 server-side encryption (SSE) using your account's default key managed by the AWS Key Management Service (KMS).
+ You can encrypt Amazon Redshift loads with Amazon S3 and AWS KMS. For more information, see [Encrypt Your Amazon Redshift Loads with Amazon S3 and AWS KMS](https://aws.amazon.com/blogs/big-data/encrypt-your-amazon-redshift-loads-with-amazon-s3-and-aws-kms/).
The following details apply to encryption and signing of data in transit between AWS CLI, SDK, or API clients and Amazon Redshift endpoints:
+ Amazon Redshift provides HTTPS endpoints for encrypting data in transit.
+ To protect the integrity of API requests to Amazon Redshift, API calls must be signed by the caller. Calls are signed by an X.509 certificate or the customer's AWS secret access key according to the Signature Version 4 Signing Process (Sigv4). For more information, see [Signature Version 4 Signing Process](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html) in the *AWS General Reference*.
+ Use the AWS CLI or one of the AWS SDKs to make requests to AWS. These tools automatically sign the requests for you with the access key that you specify when you configure the tools.
The following details apply to encryption of data in transit between Amazon Redshift clusters and Amazon Redshift query editor v2:
+ Data is transmitted between query editor v2 and Amazon Redshift clusters over a TLS-encrypted channel.
# VPC encryption controls with Amazon Redshift
Amazon Redshift supports [ VPC encryption controls](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-encryption-controls.html), a security feature that helps you enforce encryption in transit for all traffic within and across VPCs in a Region. This document describes how to use VPC encryption controls with Amazon Redshift clusters and serverless workgroups.
VPC encryption controls provide centralized control to monitor and enforce encryption in transit within your VPCs. When enabled in enforce mode, it ensures that all network traffic is encrypted either at the hardware layer (using AWS Nitro System) or at the application layer (using TLS/SSL).
Amazon Redshift integrates with VPC encryption controls to help you meet compliance requirements for industries such as healthcare (HIPAA), government (FedRAMP), and finance (PCI DSS).
## How VPC encryption controls work with Amazon Redshift
VPC encryption controls operate in two modes:
+ Monitor Mode: Provides visibility into the encryption status of traffic flows and helps identify resources that allow unencrypted traffic.
+ Enforce Mode: Prevents the creation or use of resources that allow unencrypted traffic within the VPC. All traffic must be encrypted either at the hardware layer (Nitro-based instances) or application layer (TLS/SSL).
## Requirements for using VPC encryption controls
**Instance type requirements**
Amazon Redshift requires Nitro-based instances to support VPC encryption controls. All modern Redshift instance types support the necessary encryption capabilities.
**SSL/TLS requirements**
When VPC encryption controls is enabled in enforce mode, the require\$1ssl parameter must be set to true and cannot be disabled. This ensures that all client connections use encrypted TLS connections.
## Migrating to VPC ecncryption controls
**For existing clusters and workgroups**
You cannot enable VPC encryption controls in enforce mode on a VPC that contains existing Redshift clusters or serverless workgroups. See the following steps to use encryption controls if you have an existing cluster or workgroup:
1. Create a snapshot of your existing cluster or namespace
1. Create a new VPC with VPC encryption controls enabled in enforce mode
1. Restore from the snapshot into the new VPC using one of these operations:
+ For provisioned clusters: Use the `restore-from-cluster-snapshot` operation
+ For serverless: Use the `restore-from-snapshot` operation on your workgroup
**When creating new clusters or workgroups in a VPC with encryption controls enabled, the require\$1ssl parameter must be set to true.**
Amazon Redshift requires Nitro-based instances to support VPC encryption controls. All modern Redshift instance types support the necessary encryption capabilities.
**SSL/TLS requirements**
When VPC encryption controls is enabled in enforce mode, the require\$1ssl parameter must be set to true and cannot be disabled. This ensures that all client connections use encrypted TLS connections.
## Considerations and limitations
When using VPC encryption controls in Amazon Redshift, consider the following:
**VPC State Restrictions**
+ Cluster and workgroup creation is blocked when VPC encryption controls is in `enforce-in-progress` state
+ You must wait until the VPC reaches `enforce` mode before creating new resources
**SSL configuration**
+ require\$1ssl parameter: Must always be `true` for clusters and workgroups created in encryption-enforced VPCs
+ Once a cluster or workgroup is created in an encryption-enforced VPC, `require_ssl` cannot be disabled for its lifetime
**Region availability**
This feature is not available in enforce mode with Amazon Redshift Serverless in the following Regions:
+ South America (São Paulo)
+ Europe (Zurich)