What Corey Quinn's Architecture-as-Cost Method Taught Our Cost Agent
The cloud economist who reframed billing as an architecture readout — and what that means for agents that manage data platform spend
By The Data Workers Team
Corey Quinn is the Chief Cloud Economist at Duckbill Group and the curator of Last Week in AWS, a newsletter that has become the closest thing the cloud industry has to a weekly audit of its own absurdity. He has spent years helping organizations untangle AWS bills that had grown into something between a mystery novel and a horror story. But what makes his work interesting to us is not the snark — it is the underlying method.
Quinn's most important insight is deceptively compact: 'When you talk about AWS billing, you're talking about AWS architecture. Most folks don't recognize that they're the same thing.' If that is true — and the more you work on data platform costs, the more obviously true it becomes — then every cost question is really an architecture question in disguise. And every agent that tries to answer cost questions without reading architecture is going to give bad answers.
What Is Actually Worth Learning
Quinn's method has three pillars that do the real work. None of them are about discount instruments or Reserved Instances — those come last, if at all.
The first pillar is the architecture-as-cost equivalence. 'All architecture is fundamentally about cost, and all cloud cost is fundamentally about architecture.' A data transfer spike is a networking topology decision made visible. A storage cost that keeps climbing is a retention policy that was never written down. A query that costs ten times what it should is a schema that was designed for write speed, not read efficiency. Read the bill and you are reading the architecture.
The second pillar is timing. Quinn describes an Innovation-Optimization continuum: 'There's a continuum, with Innovation on one end and Efficiency on the other.' His hard-won rule is that 'Innovation is expensive, but choosing efficiency too early is even more expensive.' A workload that is still answering the question 'does it work at all?' should not be on a cost diet. Optimizing an experiment kills the experiment.
The third pillar is business context. A large number is not inherently a problem. The question is whether it is reasonable for the business's compute intensity, growth stage, and architectural constraints. Alarming a team over a number that is actually appropriate for their situation is its own kind of failure.
- •Cost is an architecture readout, not a finance line item to be minimized in isolation
- •Optimization timing matters: mature workloads deserve scrutiny; active experiments do not
- •Business context comes before the dollar figure — a large bill can be perfectly reasonable
- •Architectural fixes are durable; discount instruments are temporary — sequence them accordingly
How a Method Becomes a Skill
The architecture-as-cost skill in our dw-cost agent encodes these three pillars directly into its decision loop. When a cost question arrives, the agent does not immediately reach for savings recommendations. It opens the cost dashboard, asks the architectural question behind each cost line, and checks the maturity position of each workload before forming a view.
The ordering of recommendations follows Quinn's implicit sequence: zero-risk reclaim first (orphaned tables, abandoned experiments, idle pipelines confirmed by lineage), then architectural fixes routed to the appropriate specialist agent, then — and only then — commitment model instruments. A discount on a workload with a structural inefficiency is a discount on waste.
One of More Than 400
The architecture-as-cost skill is one of more than 400 method-named skills across 19 agents in the Data Workers swarm. The goal is to encode the judgment that makes the difference between a recommendation that is technically correct and one that is actually right for the situation.
A note on this post: This is independent commentary and homage. It distills publicly available writing and talks by Corey Quinn to illustrate a working method, and every quote is drawn from and verified against the primary sources linked above. The skill it describes is named for the method, not the person, and contains no marketing claims attributed to them. Data Workers is not affiliated with, sponsored by, or endorsed by Corey Quinn. If you are Corey Quinn and would like anything adjusted or removed, email hello@dataworkers.io and we will respond promptly.
Related Posts
What Ralph Kimball's Dimensional Modeling Taught Our Pipelines Agent
Ralph Kimball's four-step dimensional design process is one of the most durable ideas in data engineering — here is what it taught our pipelines agent.
What Jay Kreps's Log-Centric Architecture Taught Our Streaming Agent
Jay Kreps's core insight is deceptively simple: an append-only, totally-ordered log is not just a message bus — it is the single source of truth that eliminates N² integration pipelines and makes reprocessing routine. We studied his published writing and built a reusable streaming skill around the method.
What W. Edwards Deming's Plan-Do-Study-Act Taught Our Data Quality Agent
W. Edwards Deming spent a career arguing that quality comes from improving the process, not inspecting for defects. His Plan-Do-Study-Act cycle is the most rigorous improvement loop in the field. Here is how we encoded it into our data quality agent.