Amazon Redshift Well-Architected Best Practices
This article provides best practices for designing and operating Amazon Redshift workloads aligned with the AWS Well-Architected Framework. It helps architects and data engineers make informed decisions across five pillars — Security, Resiliency, Performance, Cost Optimization, and Observability. As Redshift evolves with serverless, RG nodes, and multi-warehouse capabilities, this document ensures teams can build secure, reliable, performant, and cost-efficient data warehouse environments.
Why the Well-Architected Framework Matters
The AWS Well-Architected Framework provides a structured and consistent approach for evaluating cloud architectures against industry best practices.
This article is organized around five key pillars, each containing targeted assessment questions. For each question, we provide an explanation of why it matters and direct links to relevant AWS documentation to help you implement improvements
Pillar 1: Security
Security covers protecting your data and systems through robust access controls, encryption, network isolation, and version management. A strong security posture minimizes the risk of unauthorized data access, data breaches, and ensures compliance with regulatory requirements such as GDPR, HIPAA, SOC 2, and PCI DSS. Security is a shared responsibility, and this pillar helps ensure you are fulfilling your part.
| Best Practice | Why This Is Important |
|---|---|
| Redshift Access Controls | Following the least privilege access principle ensures users and applications have only the minimum permissions necessary to perform their tasks, within the Redshift database. This significantly reduces the risk of unauthorized data access, accidental data modification, or malicious activity from compromised credentials. This is foundational to a Zero Trust security model and is mandated by most compliance frameworks including HIPAA, PCI DSS, and SOC. |
| Restricting access to IAM roles | To implement least-privilege access for IAM roles in Amazon Redshift, restrict role availability to specific database users inclusters rather than relying on the default behavior. |
| Implementing Encryption | Encryption is a critical control required by virtually all data privacy and security regulations and is a best practice regardless of the sensitivity of your data. In Amazon Redshift, your database is encrypted by default to protect your data at rest. Database encryption applies to the cluster and also to its snapshots. Redshift Serverless workgroups have always been encrypted by default since launch. Starting in January 2025, Amazon Redshift extended this default to provisioned clusters as well, all newly created provisioned clusters and clusters restored from snapshots are now automatically encrypted. If you do not specify an AWS KMS key, the cluster is encrypted with an AWS-owned key. Best practice: Use a customer-managed KMS key (CMK) rather than an AWS-owned key to maintain full control over key rotation, access policies, and audit trails. |
| Using VPC Endpoints and Private Subnets to Isolate Redshift Network Traffic | Deploying Redshift in a private subnet (i.e., a subnet with no internet gateway route) prevents direct internet access to the cluster. Combined with VPC endpoints, this ensures traffic between your applications and Redshift stays within the AWS network, eliminating exposure to the public internet and significantly reducing attack surface. Security groups provide fine-grained network-level access control. |
Pillar 2: Resiliency
Resiliency ensures your ability to recover from failures and maintain business continuity, minimizing downtime and data loss during unexpected disruptions. Note: This section focuses on Redshift-specific resiliency. A comprehensive business continuity plan for region-wide failures will need to address all dependent services, not just Redshift.
High Availability (HA) ensures continuous operation of your data warehouse with minimal or zero downtime by maintaining an active-active environment. In an active-active configuration, two or more Redshift clusters are simultaneously running and processing workloads, either within the same region across Availability Zones, or across different regions using a dual-ETL approach, Multi AZ deployment or other replication approach.
Disaster Recovery, addresses catastrophic regional failures by replicating data and infrastructure across AWS Regions, with RPO ranging from near-zero to minutes and RTO from minutes to hours depending on the strategy chosen (Active-Passive, Active-Active, or Hybrid)
| Best Practice | Why This Is Important |
|---|---|
| Defining RTO/RPO for Your Redshift Applications | RTO is the maximum acceptable downtime; RPO is the maximum acceptable data loss or reprocessing window. Stakeholders need to set clear expectations by defining RTO and RPO requirements. IT teams then determine the appropriate DR strategy to meet those expectations. Tighter requirements demand more robust and costly solutions. |
| DR Implementation & Testing | DR ensures business continuity by minimizing downtime and data loss for critical reporting and analytics. A DR plan that is never tested provides false confidence. We recommend conducting DR drills at least twice a year to verify that recovery procedures work and that your team is prepared to execute under pressure. |
| Aligning Backups with RPO | Provisioned clusters: Automatic snapshots are incremental backups taken every 8 hours or after 5 GB of data changes per node, retained for 1–35 days (default: 1 day). Serverless: Recovery points are created every 30 minutes regardless of data volume changes. Backups provide recovery for data corruption, accidental changes, or failures, and support cross-region DR when copied to another region. Automatic snapshots can be scheduled at a minimum frequency of once per hour. For RPO requirements of less than one hour, or for workloads with unpredictable data change volumes, configure manual snapshot schedules to ensure consistent recovery points at your desired interval. Cross-Region snapshot copy enables disaster recovery by replicating snapshots to a DR AWS Region. |
| Redshift Multi-AZ Deployment | Multi-AZ deploys synchronized compute resources across two Availability Zones, accessible through a single endpoint. With Multi-AZ, both the primary and secondary compute are actively running, in the event of an AZ failure, the secondary continues processing queries seamlessly. This provides near-zero RPO and rapid recovery without manual intervention for mission-critical workloads. |
| Configuring Cross-Region Backups | Cross-region backups are essential for all critical production workloads. They protect against region-wide outages, natural disasters, or catastrophic failures by storing snapshot copies in a geographically separate AWS region, enabling cluster restoration in another region to ensure business continuity |
| Use Trailing Track for production workload | Trailing Track provides greater stability for production environments by deploying a Redshift version that has been validated in production across many customers, reducing the risk of encountering newly introduced issues. Trailing Track is ideal for mission-critical workloads where stability and predictability are prioritized over having the latest features immediately. |
Pillar 3: Performance Efficiency
This pillar ensures your data warehouse delivers optimal query performance and scales efficiently with growing demand. Proper performance tuning directly impacts user satisfaction, SLA adherence, and overall return on your data warehouse investment
| Best Practice | Why This Is Important |
|---|---|
| Enabling Concurrency Scaling (Provisioned clusters) | Automatically adds cluster capacity during peak demand, ensuring consistent query performance without over-provisioning. Reduces queue wait times and helps maintain SLAs during traffic spikes. Concurrency Scaling is billed on-demand at per-second granularity, with one hour of free credits accumulated per 24 hours of cluster uptime. |
| Creating Query Monitoring Rules (QMR) | Query Monitoring Rules automatically monitor and control query behavior by defining thresholds for execution time, CPU usage, or rows returned, with actions like logging or aborting runaway queries. |
| Following Table Design Best Practices | Distribution keys, sort keys, and compression are fundamental to Redshift performance. Distribution keys minimize data movement during joins, sort keys reduce disk I/O, and compression lowers storage costs while improving query speed. Redshift automates all of these through AUTO distribution, AUTO sort keys, and automatic compression encoding, in most cases, no manual configuration is required. |
| Data loading Best Practices | Efficient data loading directly impacts both ingestion performance and downstream query execution in Amazon Redshift. Use the COPY command as the primary loading mechanism, it leverages massively parallel processing (MPP) and use all compute nodes to ingest data. |
| Accelerating Query Performance with Materialized Views | Materialized Views pre-compute complex query results, delivering faster response times for repetitive and dashboard workloads. Redshift’s optimizer automatically uses MVs without application changes, reducing compute consumption with incremental refresh support. Redshift Auto-MV automatically identifies and creates materialized views for frequently executed query patterns without any user intervention. |
| Multi-Cluster Redshift: Scaling Performance with Data Sharing | Multi cluster architecture provides workload isolation where each team can independently scale compute without impacting others, improving cost efficiency and performance. Redshift Data Sharing enables multiple clusters to work on a single shared copy of data without data movement, ensuring consistency while allowing independent scaling of compute resources for different workloads. Please refer for multi cluster architecture patterns |
Pillar 4: Observability, Monitoring & Alerts
This pillar focuses on gaining visibility into cluster health, query performance, and operational events. Proactive monitoring enables teams to detect issues early, respond quickly to anomalies, and optimize resource utilization before problems impact end users. Without proper observability, teams are left troubleshooting reactively, leading to prolonged outages and degraded performance
| Best Practice | Why This Is Important |
|---|---|
| Configuring Cluster Events | Cluster event notifications send real-time alerts through Amazon SNS for important activities like maintenance, resizes, snapshot creation, security changes, and hardware failures. This helps teams stay informed about what's happening with their clusters without having to manually check the console. |
| Enabling Audit Logging | Audit logging tracks user activity, connection attempts, and query details. It shows who accessed what data, when, and from where. This is essential for security monitoring and for investigating any breaches or suspicious behavior |
| Regularly Monitoring Query Performance | Analyzing query performance using Redshift system tables (sys_* views) identifies slow queries, bottlenecks like disk spills and queue wait times, and inefficient execution plans. Proactive monitoring optimizes resource utilization, improves response times, and reduces costs. |
| Periodic Review of QMR Violators | Regularly review queries flagged by Query Monitoring Rules — especially those that are logged but not aborted. These represent queries that exceeded thresholds but were allowed to complete. Trending analysis of QMR violators helps identify workloads that may need optimization or resource allocation changes. |
Pillar 5: Cost Optimization
Cost optimization focuses on achieving maximum business value at the lowest possible cost. This includes right-sizing clusters based on actual usage, leveraging reserved pricing models, implementing data lifecycle and archival policies, using Redshift Spectrum for infrequently accessed data, and applying cost controls for serverless workloads. Effective cost management ensures sustainable growth without overspending.
| Best Practice | Why This Is Important |
|---|---|
| Leveraging RG, Latest Generation Redshift Instance Type | RG nodes, powered by AWS Graviton processors, deliver up to 2.2x faster data warehouse performance compared to previous generation RA3 instances at 30% lower price per vCPU. Migrating to RG reduces costs while significantly improving query throughput, making it the most cost-efficient option for both data warehouse and data lake workloads. |
| Reserved Instances (provisioned) | For steady-state workloads running on Amazon Redshift Provisioned, Reserved Instances (1-year or 3-year terms) provide significant discounts compared to on-demand pricing. |
| Reserved capacity(Serverless) | For Amazon Redshift Serverless, Reserved Capacity commitments (1-year or 3-year terms) offer similar savings on RPU costs. Evaluate usage patterns across and commit to reservations for baseline capacity. |
| Redshift Cost Optimization best practices | Please refer this article for other cost optimization details. |
- Language
- English
Relevant content
asked 8 years ago
asked 8 years ago
asked 8 years ago
- AWS OFFICIALUpdated 4 years ago
- AWS OFFICIALUpdated 7 months ago
