This article is based on a TechRepublic interview with Corey Quinn, co-founder of The Duckbill Group, originally published in October 2019. Quinn is known for pointed commentary on AWS billing and cloud economics.
Who Is Corey Quinn?
Corey Quinn occupies an unusual niche in the cloud industry. As a self-styled cloud economist and co-founder of The Duckbill Group — a consulting firm that specialises in AWS cost reduction — he has built a recognisable personal brand by saying plainly what many AWS practitioners only whisper. His Twitter commentary is dense with one-liners, and his willingness to criticise Amazon publicly, despite depending on AWS complexity for his business model, gives his opinions an unusual credibility.
TechRepublic sat down with Quinn to discuss AWS billing opacity, the real cost of data transfer, whether Kubernetes is a career move masquerading as a platform strategy, Docker’s business model failure, the multicloud fallacy, and Oracle lock-in.
The Most Common AWS Mistake: Treating Old Knowledge as Current
When asked what AWS users consistently get wrong, Quinn’s answer was not about architecture or security — it was about knowledge decay.
“The most consistent mistake that everyone makes when using AWS — this extends to life as well — is once people learn something, they stop keeping current on that thing. There is an entire ecosystem of people who know something about AWS, with a certainty. That is simply no longer true, because capabilities change. Restrictions get relaxed. Constraints stop applying. If you learned a few years ago that there are only 10 tags permitted per resource, you aren’t necessarily keeping current to understand that that limit is now 50.”
— Corey Quinn, The Duckbill Group
This is a practical concern for any team running long-lived AWS infrastructure. Service limits, pricing tiers, managed service capabilities, and IAM behaviour all change — sometimes quietly. Engineers who certified or deeply studied AWS two or three years ago may be architecting around constraints that no longer exist, or missing cost-saving options that have since been introduced.
AWS Data Transfer Pricing: The Bill’s Silent Killer
Asked which AWS services he would eliminate if given the power, Quinn used two of his three choices on data transfer pricing — for different reasons.
- Amazon CodeCommit — Quinn considers it a distraction, a GitHub equivalent that adds little differentiated value.
- Data transfer pricing (reason one) — It is practically impossible for engineers to predict costs in advance. The pricing matrix across regions, availability zones, services, and internet egress is genuinely opaque.
- Data transfer pricing (reason two) — Prices have not meaningfully dropped in years, despite the dramatic reduction in the underlying cost of bandwidth in the broader market.
“It’s really the cloud’s Achilles heel.”
— Corey Quinn
Quinn’s explanation for why data transfer costs persist at current levels is structural rather than cynical: the charges are spread across so many line items — and are dwarfed by EC2 and storage spend for most workloads — that they disappear into background noise. There is also, Quinn suspects, no single internal AWS team that owns the problem end-to-end, making it politically difficult to address.
Hidden Costs: Cross-AZ Replication and Managed NAT Gateway
Two specific patterns generate unexpectedly large data transfer bills:
- Cross-availability-zone replication: Databases such as Cassandra and MongoDB replicate data across nodes. When those nodes span AZs — which is the recommended high-availability pattern — each gigabyte of replicated data incurs inter-AZ transfer charges. At petabyte-scale replication, this can translate to tens of thousands of dollars per month that engineers did not anticipate when designing the cluster.
- Managed NAT Gateway: In addition to standard data transfer charges, Managed NAT Gateway applies a per-GB processing fee (Quinn cited $0.045/GB at the time of the interview). For workloads routing large volumes of traffic to the internet or to S3 through a NAT Gateway, this charge can reach millions of dollars — yet it appears in the EC2 section of the bill, not the data transfer section, making it easy to miss.
Quinn’s broader point is that AWS services that are perfectly efficient at small scale often contain inflection points where the cost model breaks down. Recognising those inflection points requires continuously reading AWS pricing documentation, not assuming the architecture that worked at $10,000/month will remain sensible at $500,000/month.
Infrastructure Costs vs. Payroll: Keeping Perspective
Quinn challenges the instinct to treat cloud cost optimisation as a primary lever for business improvement.
“What people lose sight of is that infrastructure, in almost every case, costs less than payroll. The people who run these things are inherently more expensive than the infrastructure itself, and losing sight of that leads to ridiculous things.”
— Corey Quinn
He used the example of Lyft’s publicly announced multi-year, nine-figure AWS commitment: critics argued the company should save money by running its own data centres, but Lyft was simultaneously reporting losses far larger than its entire cloud budget. In that context, optimising the AWS bill — whether reducing it or doubling it — was economically irrelevant compared to the company’s core business challenges.
This does not mean cost optimisation is worthless. It means it should be sized correctly as an effort. Spending six months of senior engineering time to reduce a $200,000/month AWS bill by 15% is often a bad trade.
Why Kubernetes Is Better for Building a Résumé Than a Platform
Quinn’s criticism of Kubernetes is two-pronged: operational complexity today, and career risk tomorrow.
Operational Complexity
Getting a Kubernetes cluster running is a well-documented process. Maintaining it — diagnosing intermittent slowness six months after deployment, understanding which abstraction layer is misbehaving, keeping up with upstream version changes — is substantially harder. Quinn argues that the cognitive and financial overhead of that maintenance is underestimated during adoption decisions.
“Right now, the burden for maintaining Kubernetes is at least a million dollars, in managed consultancies or engineering time.”
— Corey Quinn
The Technology Abstraction Cycle
Quinn’s deeper critique is historical. He argues that complex infrastructure technologies inevitably get abstracted away as the market matures. Web server configuration, compiler flags, package management — each was once a specialist skill, and each is now either automated or irrelevant. His prediction is that Kubernetes will follow the same trajectory: the container orchestration problem will be solved at a higher level, and the engineers who built their entire identity around Kubernetes will find the skill commoditised or invisible.
He also characterises the technology as bearing Google’s cultural fingerprints: opinionated, complex, and built for a scale that most organisations running it do not actually have.
What Docker Got Wrong
Docker’s strategic failure, in Quinn’s assessment, was relational rather than technical. By keeping potential partners at arm’s length while the company worked out its business model, Docker left itself without allies when the industry moved on. The container runtime became an invisible plumbing layer — essential but unremarkable — and Docker never found a position in the value chain where users were naturally inclined to pay for it.
“There’s no part of that story where you’re cutting a check to Docker.”
— Corey Quinn
On the related question of open-source projects feeling exploited by Amazon offering managed versions of their software, Quinn is unsympathetic to the complaint. He argues that the companies most vocal about Amazon’s behaviour — MongoDB, Elastic, Redis Labs — were, at the time of the interview, commercially healthy. Treating an open-source licence as a business model, he suggests, was always a fragile strategy.
Why “More or Less Everything” Is Wrong with Multicloud
Quinn’s position on multicloud is blunt: as a greenfield architectural default, it is an engineering constraint masquerading as a best practice.
His objections:
- Lowest common denominator problem: Multicloud forces teams to use only the services and abstractions that exist identically — or nearly so — across providers. The genuinely differentiating higher-level services on each platform become unavailable or too risky to adopt.
- Who benefits: Multicloud as a doctrine is most actively promoted by second- and third-tier cloud providers who know that a customer going all-in on a single provider will not choose them. It serves their interests more than the customer’s.
- Valid exceptions exist: Regulatory requirements and explicit customer contractual demands are legitimate reasons to operate across clouds. These are not the same as choosing multicloud speculatively to avoid vendor lock-in.
Quinn’s practical advice: pick the cloud provider that best fits your business model and go deep. For many organisations that is AWS, but not for all — and the choice matters less than committing to it.
Walmart’s AWS Paranoia
Walmart has been publicly reported to discourage its technology vendors from using AWS, given that Amazon is a direct retail competitor. Quinn acknowledges the surface logic — not wanting to fund a competitor — but considers the pressure Walmart allegedly exerts on smaller suppliers to change their infrastructure choices to be anti-competitive bullying that places an unfair burden on companies that may not have the resources to comply.
“If you want to compete, compete on your merits. Not out of what would be anti-competitive behavior, in a functioning antitrust regulatory environment.”
— Corey Quinn
On Migrating Away from Oracle
Quinn’s advice on Oracle migrations starts with a reality check. At the time of this interview, Amazon itself — one of the most technically capable and financially motivated organisations on the planet — was still in the middle of a multi-year effort to migrate its own internal systems off Oracle. Larry Ellison had publicly highlighted this on stage as a sign of Oracle’s indispensability.
Quinn reads it differently: if Amazon, with all its resources and motivation to complete the migration quickly, was still years away from finishing, that is a realistic signal to any organisation considering a similar project. Oracle migrations are long, expensive, and technically dangerous. That is not an argument against doing them — Quinn thinks it is generally a good idea — but it is an argument for planning realistically rather than optimistically.
How Quinn Became the Face of AWS Billing
Quinn’s path to building a consultancy around AWS billing was deliberate. After leaving a role running operations at a large financial institution — which he describes as an environment poorly suited to his personality — he identified AWS cost management as a problem with several attractive properties for a consulting business:
- It is expensive enough that clients are genuinely motivated to fix it.
- It is a business-hours problem — no 2 a.m. incident pages.
- It does not resolve itself without intervention.
“At first, I was afraid that Amazon was going to fix the billing system and put me out of business in six months. Now, I’m scared that they never will.”
— Corey Quinn
The brand he built around public, unfiltered commentary on AWS — including open criticism of Amazon’s product decisions — is insulated in a way that a traditional consulting firm’s communications would not be. An individual practitioner owning their own firm can say things on stage that would get a corporate employee fired or a partner firm blacklisted. Quinn has leaned into that structural advantage deliberately.
This article is adapted from a TechRepublic interview originally published in October 2019. Some AWS service details, pricing figures, and company situations described by Quinn may have changed since the interview was conducted.