The data warehouse question usually comes back for one of three reasons. Either the appliance renewal quote has landed, or an auditor wants to know where a number in a regulatory filing came from, or an AI pilot needs governed data and nobody can say where it lives.
Take a typical regional bank. Its Teradata box has roughly fifteen years of loan, deposit, and card history on it, and the support contract comes up for renewal next June. Every night Control-M kicks off around 3,000 BTEQ scripts.
On the first business day of each month, finance closes the books on Tableau dashboards that start hitting the warehouse at 7 a.m., and the quarterly Call Report gets built from tables that only two people really understand. Now the fraud team wants an AI agent that can query card transactions. We'll come back to this bank throughout, because most of the decisions below look different once they're attached to a real estate.
We've been building data platforms on AWS since 2008, much of that time inside banks, insurers, health systems, and manufacturers, where a botched cutover ends up in front of the board. Over those years, AWS Redshift has settled into a fairly specific job for us. It's the governed SQL layer that finance, risk, operations, and now AI agents all query, and they all expect it to give the same answer to the same question, even with hundreds of people hitting it at once.
That job is getting more important. McKinsey's research from June 2026 found that more than two-thirds of high-performing companies say data is the primary obstacle for enabling AI. We'd say the same about our own engagements, where the thing slowing an AI program down is far more often the warehouse feeding the model than the model itself, which is why most of the data modernization work we scope now starts there.
Mostly because AWS spent the last couple of years fixing what people used to complain about. In steering committees we'd hear three objections, price-performance, open table formats, and how much tuning it took, and by now each one has a generally available feature behind it rather than a roadmap slide. Most of those features came out in 2026.
Put together, those releases make Redshift the obvious pick for a certain kind of buyer. We'd check your own estate against the lists below before anyone signs a reservation.
When we'd usually recommend Amazon Redshift:
When we'd think twice:
The bank checks every box on the first list. The pattern we'd deploy for it, and the one we deploy most often, treats Redshift as the serving layer over an Iceberg lakehouse on Amazon S3, with zero-ETL feeding it from the operational databases. If you're still designing the lake side, our guide to AWS data lake architecture covers the storage and catalog choices. It's the same architecture behind our data platform modernization work, and the diagram below shows how the pieces fit.
Each group of consumers gets its own warehouse over the same Iceberg copy. That way a runaway agent query can't slow down the close dashboards, and every team carries its own line on the bill.
We'd decide it per workload rather than per company. Most of the enterprises we work with end up running two models side by side, joined by data sharing so every consumer reads one governed copy. For the bank, that would mean the jobs replacing its overnight BTEQ scripts run on provisioned RG nodes, since they keep a cluster busy for hours every night, while the month-end dashboards and the new fraud agent each get a Redshift Serverless workgroup.
Rules of thumb we use in scoping:
We get asked this in almost every evaluation, and the fair answer depends on where your data, your people's skills, and your controls already sit. We integrate with all three and they all run fine on AWS, so in our experience the Redshift vs. Snowflake decision turns on contracts and controls far more than on raw speed.
When most of your security model, spend commitments, and operational tooling already sit in AWS, as they do at the bank, Amazon Redshift usually takes a contract, an identity boundary, and a billing reconciliation out of the program. Auditors and CFOs tend to care about that kind of simplicity a lot more than they care about a benchmark chart.
On paper, Amazon Redshift pricing is a handful of rates, and most of them are easy to look up. When we review a Redshift budget that has gone over, though, the list rates are rarely the reason. It's usually consumption that nobody capped, a legacy system left running in parallel for too long, or lake data being scanned the expensive way.
Serverless reservations now come in 1-year and 3-year terms, paid No Upfront or All Upfront. AWS quotes savings of up to 24% for one year and up to 45% for three, and up to 50% on the 3-year All Upfront option. EU Regions such as Frankfurt and Ireland usually list a bit higher than US East, so we'd price the workload in the Region your residency rules require rather than the cheapest one on the calculator.
When a CFO asks what this will cost, we usually sketch something like the table below on a whiteboard. It's priced at US East list rates for a mid-sized BI and reporting workload on Redshift Serverless, about the size of the bank's month-end dashboards.
Compute is $2,640 of the $3,120, about 85%, which is why we'd watch it before anything else. What tends to happen is that someone sets up one workgroup without a ceiling, then the dashboards, the ad hoc analysts, and an AI agent or two all end up on it, and by the end of the quarter the compute line has doubled without anyone looking at it. If the bank had stayed on RA3, those lake queries would go through Spectrum instead, at $5 per TB scanned, and 30 TB a month would put about $150 back on the bill.
Most Redshift cost optimization work comes down to six leaks, and each one has a guardrail we'd put in before go-live.
The last two are where the real money is. As we put it in our point of view on funding AI from your existing budget:
“Most of the AI budget you think you need is already in the building. It is paying interest on the old stack.”
For the bank, cancelling the Teradata renewal next June is worth more to the P&L than any Redshift discount it could negotiate, and the same goes for a Netezza or Exadata renewal. We'd treat legacy retirement as the main financial outcome of the program and size the Redshift reservations only after the old platform is switched off.
Redshift itself is HIPAA eligible, and it's inside AWS's audit scope for PCI DSS, SOC, and ISO 27001. That's where AWS's part ends, though. Under the shared responsibility model, whether an examiner walks away happy depends on how you've configured it, how access is designed, and what evidence you can hand over.
The stakes keep rising. IBM's Cost of a Data Breach Report for 2026 came in at $4.99 million for the average breach worldwide, which is a record. For the bank, the warehouse is the one place where customer, card, and loan data all sit together, so it's the system we'd least want to see in that report.
We map the controls once and build them so the same design satisfies US and EU rules. This is the map we start from.
Two details catch out even experienced teams. Dynamic data masking and row-level security have to be designed around your real roles, or analysts quietly end up with exported extracts to get around them. And audit logs only count as evidence if someone can tie each query to a named person or agent, which shared service accounts make impossible. At the bank, that second one usually shows up as a single ETL service account that runs half the BTEQ jobs.
Our view, drawn from a regulated financial data platform we shipped, is “compliance as a foundation, not a tax.” Day to day, the platform writes the lineage, access records, and audit evidence as it goes, so there's no consultant team pulling it together the month before an exam. The analysts don't lose any speed, compliance stops chasing screenshots, and when an auditor at the bank asks where a Call Report number came from, someone can answer with a query instead of starting a quarter-long project.
For US banks, insurers, and payment firms, our financial services data modernization approach shows how FFIEC, SEC, and FINRA alignment gets built into the same foundation. Health systems and payers working under HIPAA can see how the same controls carry over in our healthcare data platform work.
European buyers have a couple of extra things to plan around. The AWS European Sovereign Cloud became generally available on January 15, 2026, and Amazon Redshift is on AWS's initial service roadmap for it, so we'd confirm availability in the sovereign Region before designing around it. Then there's the EU AI Act. The Digital Omnibus, adopted as Regulation (EU) 2026/1744, moved the high-risk obligations for Annex III systems to December 2, 2027 and for Annex I systems to August 2, 2028. That's a planning window rather than a reprieve, especially if a credit or fraud model reads from the warehouse.
Whether a warehouse is ready for AI agents comes down to three checks we'd run. The agent has to be able to find the right table, read fresh data under its own identity, and leave an audit trail a regulator would accept. Plenty of the warehouses we assess miss on at least one of those, and nobody finds out until the pilot tries to grow. The bank's fraud agent is a good example. It looked great in the demo because it was querying a clean extract someone had prepared for it. In production it would have to use the live card tables, and there are four transaction tables in the warehouse with no note anywhere saying which one is the real one.
The good news is that Redshift already has most of the pieces. What's left is connecting them with sensible guardrails, which is most of what data warehouse modernization means when we scope it, and the table below lists what we'd check before go-live.
If the bank built its agents on Amazon Bedrock, there's a useful side effect, because Redshift ML can call those same models from SQL. So the fraud team could ask for a summary or a risk label on a batch of card transactions, and the rows would stay where they are.
Agents also put a different kind of load on a warehouse. An analyst writes a query, reads what comes back, and thinks for a while before the next one. The bank's fraud agent won't pause like that. It'll send dozens of small exploratory queries, retry each one that fails, and if someone hands it a vague prompt before going home, it can end up scanning the whole card table at 2 a.m. Put agents on the same warehouse as the CFO's close dashboards, and the CFO will be the first to notice.
Before the bank's fraud agent touches production data, we'd put five guardrails in place:
These controls are what separate a demo from a system your risk committee will sign off on. They're also the controls we build into every AI agent we ship into production on AWS, because an agent is only as trustworthy as the warehouse underneath it. Our view on agentic AI in production goes further into the engineering discipline this takes.
We've rarely seen the data copy be the hard part of a Redshift migration. Discovery and validation are, and when a program ends up two or three times over budget, it's almost always because nobody took a full inventory of the stored procedures, scheduled jobs, and downstream reports up front, so they turned up one at a time in user acceptance testing.
So our data warehouse migration work starts with automated discovery. At the bank we'd want to know about every one of those 3,000 BTEQ scripts, the Control-M schedule that calls them, and each Tableau workbook and Call Report extract downstream, all before anyone puts a cutover date in writing.
For a Teradata to Amazon Redshift migration like the bank's, we'd expect most of the surprises to come out of the scheduler. A BTEQ script that looks like a plain load will turn out to apply a business rule, or hard-code a date, or read a temp table another job left behind, and you only find that out by reading it. Our Redshift migration consulting team does that reading as part of discovery, then runs the parallel-run reconciliation, all against a cutover date that's written into the statement of work.
We run every Redshift program through five phases, and each one ends with a signed exit before the next begins. That discipline is at the core of how we work, with a forward-deployed engineer making the judgment calls at each gate, and it's what lets a fixed date survive contact with a real estate.
A single business domain with a few hundred objects can usually reach production inside a quarter. A multi-petabyte estate with thousands of objects should move in domain waves, each following the same five phases. The bank, for example, might move finance and the Call Report first, because that's where the auditors' questions are, and leave card history and the fraud tables for the second wave.
We'd want every item on this list signed off before the bank's finance domain moves:
Sometimes the warehouse move is tied to getting off Oracle or SQL Server as well, and in that case we'd plan the two together. Our application and database modernization team treats the operational database and the warehouse as one dependency graph, so nobody ends up building the same pipelines twice.