Redshift Serverless Migration & Right-Sizing

Redshift Serverless removes the cluster from Redshift. You create a namespace (your data and users) and a workgroup (compute), and AWS bills per Redshift Processing Unit-hour (RPU-hour) while queries run. For the right workload it is cheaper, simpler and faster to operate than a provisioned cluster. For the wrong workload it costs more than the RA3 cluster it replaced. Our job is to tell you which one you have, before you move.

When Serverless wins, and when it does not

Serverless wins on spiky and idle-heavy workloads: dashboards that are busy for three hours a day, dev and test environments, monthly close processing, ad-hoc analyst access, and new projects where nobody yet knows the steady-state load. Compute scales to zero between queries, so an environment that is idle 80% of the time stops paying for that 80%.

Provisioned RA3 usually wins on steady 24/7 load: a cluster that sits at 60% or more utilization around the clock, with predictable batch windows. Reserved-instance pricing on RA3 nodes is hard to beat on an hourly basis, and you keep full control of WLM queues and Concurrency Scaling.

Most estates are a mix. A common outcome of our assessment is a producer cluster on RA3 for the heavy ETL, with Serverless consumer workgroups for BI and analysts, joined by data sharing so nothing is copied.

What the engagement covers

Workload analysis. We pull 30 to 90 days of SYS_QUERY_HISTORY and cluster metrics from your existing environment and classify the load: concurrency profile by hour, idle windows, scan volumes, and which queries drive the cost. This is the input to the cost model, and it is the deliverable you keep even if you decide to stay provisioned.

Cost model. Provisioned node-hours against projected RPU-hours at your actual usage, with and without reserved pricing, including Redshift Managed Storage and Concurrency Scaling charges you may be paying today without noticing. You see the break-even point as a number, not a slide.

Migration path. For a provisioned-to-Serverless move the mechanics are a snapshot restore into a new namespace, followed by endpoint, IAM and VPC changes. The work is in everything around it: WLM rules that no longer apply, scheduled queries and maintenance scripts that assumed a cluster, JDBC/ODBC endpoints in every BI tool, and the parallel-run period where both environments are live and costs are compared against the model.

RPU right-sizing. We set the base RPU capacity from measured query memory and concurrency rather than from the default, tune the max RPU ceiling, and test the price-performance setting against real workloads. Base capacity too low means slow queries; too high means you are back to paying for idle.

Cost guardrails. Every Serverless workgroup we hand over has usage limits with alerts and, where appropriate, query limits on runtime and scanned rows. A Serverless bill cannot run away if it is configured not to.

Deliverables

• Workload classification report and cost model (provisioned vs Serverless vs hybrid)
• Migration runbook including cutover and rollback
• Configured namespaces and workgroups with base/max RPU, usage limits and CloudWatch alarms
• A 30-day post-migration review comparing the real bill to the model

If you are starting from scratch rather than migrating, read our Getting Started with Amazon Redshift Serverless tutorial, or our article RA3 vs Serverless in 2026.

Talk to us

Tell us what your cluster looks like today and what it costs, and we will come back with a written assessment and a fixed-scope proposal. Contact us or call +1 (726) 227-3497.