Snowflake’s new five-year, $6 billion agreement with AWS is easy to read as another big cloud spend commitment. It is more interesting than that. The deal ties Snowflake’s AI workload strategy more tightly to AWS Graviton ARM CPUs, and that says something important about where enterprise AI is headed: not every useful AI system is being built around expensive GPUs.
The immediate business signal is straightforward. Snowflake said its AWS spend doubled in 2025 to $2 billion, and AWS said Snowflake has already sold roughly $7 billion of services through AWS Marketplace since 2012. Against that backdrop, a five-year, $6 billion deal is not a side note. It is evidence that the center of gravity for Snowflake’s next phase of AI deployment is moving deeper into AWS infrastructure, with all the cost, architecture, and dependency implications that come with that choice.
Technically, the significance is in the compute mix. AWS Graviton is ARM-based, and ARM-based CPUs are attractive for workloads that benefit from good price-performance, dense packing, and strong efficiency per watt rather than raw accelerator throughput. That makes them a credible fit for a broad class of AI workloads adjacent to model training: feature generation, retrieval, orchestration, batch inference, summarization, query augmentation, and other serving paths that do not always need a GPU in the loop.
That distinction matters because enterprise AI stacks are not monoliths. The popular picture of AI infrastructure still centers on GPU-heavy training clusters, but many production systems spend more time moving data, shaping prompts, routing requests, enforcing governance, and running inference than they do training frontier models. In that environment, CPU economics can matter as much as peak FLOPS. ARM-based AWS Graviton CPUs can change the shape of the bill, the shape of the deployment topology, and the shape of the bottlenecks.
For Snowflake, the placement of compute inside the data fabric is the point. Cortex AI already sits at the junction of Snowflake’s warehouse, metadata, and application layer. Running more of that stack on AWS CPUs creates the possibility of tighter data locality and a simpler path from stored enterprise data to AI output. When the model-adjacent work stays close to the data, customers can reduce movement across systems, keep governance controls in one place, and avoid turning a data platform into a patchwork of external services.
That is especially relevant for products like Cortex AI, which Snowflake has been positioning as a way to let users interact with data through natural language queries, summaries, and other AI-assisted workflows. The product promise depends less on brute-force model training and more on operational reliability, latency, cost discipline, and policy enforcement. Those are all areas where a CPU-centered deployment can be attractive if the workload profile fits.
The deal also deepens the AWS relationship in a way that is hard to ignore. Snowflake is still available on Microsoft Azure and Google Cloud, but its business calculus now looks more AWS-centric than before. If Snowflake’s customers are already accelerating spend on AWS, as the company says, then aligning AI infrastructure more closely to AWS hardware can simplify some product delivery decisions. It can also sharpen the tradeoff for multicloud buyers: they may get a cleaner operational stack on AWS, but at the cost of greater dependence on one provider’s economics, roadmap, and hardware choices.
That is the core market issue here. AI hardware economics are not just about whether a chip is fast. They are about which workloads deserve scarce GPU capacity, which workloads can be cost-effectively served on CPUs, and how much engineering complexity a vendor is willing to absorb to make that split work. Snowflake’s bet suggests that more enterprise AI than many people assume can run on CPUs, especially when the surrounding platform already owns the data, the governance layer, and the request path.
For customers evaluating Cortex AI on Graviton, the practical questions come before the marketing claims. Teams should benchmark representative AI workloads rather than assume GPU-style architecture is always necessary. They should test data placement carefully, because the value of a data platform usually depends on minimizing unnecessary movement. They should also look at governance and observability together, since AI features embedded in a data stack can create subtle policy and lineage issues if they are bolted on rather than integrated.
The CPU vs GPU tradeoffs are not ideological; they are workload-specific. GPU acceleration still makes sense for large-scale model training and some high-throughput inference paths. But if the application is closer to enterprise copilots, retrieval-augmented queries, summarization, or text generation over governed data, CPU efficiency may be good enough — and economically preferable. Snowflake’s deal suggests it wants to make that argument inside its own platform.
There are real constraints, though. A deeper AWS relationship can improve execution but also concentrates risk. If Snowflake’s AI roadmap becomes too dependent on AWS infrastructure, customers with strict multicloud or portability requirements may see that as a strategic tax. CPU-centric AI also has limits: not every workload will scale elegantly on Graviton, and not every latency target will be comfortable on general-purpose processors. The architecture still has to prove itself against the realities of production traffic.
Even so, the broader message is clear. This is not just Snowflake buying capacity. It is Snowflake shaping its AI future around a specific hardware and cloud relationship, one that reflects where the economics of enterprise AI may be heading: closer to the data, more selective about accelerators, and increasingly intertwined with the cloud vendor that can bundle the stack most efficiently.
