In 2017, a systems engineer with a sharp tongue and a sharper spreadsheet published the first issue of a newsletter called Last Week in AWS. It was a curated summary of Amazon Web Services news, wrapped in sarcasm and unsolicited opinions about cloud pricing. Within two years, Last Week in AWS had over 30,000 subscribers. By 2024, that number had grown past 100,000, making it one of the most widely read independent technology newsletters in the world. But the newsletter was only the public face of something larger. Corey Quinn had identified a problem that no one else was willing to name plainly: cloud computing bills were out of control, and the companies paying them had almost no idea why. He co-founded the Duckbill Group, a consultancy that specialized exclusively in understanding and reducing AWS costs, and in doing so created an entirely new discipline — cloud economics. Before Quinn, cloud cost management was an afterthought, something finance teams complained about and engineering teams ignored. After Quinn, it became a recognized function, with dedicated roles, tooling, and executive attention. His path from sysadmin to cloud economist to media personality is one of the most unconventional career arcs in modern technology, and it offers a masterclass in how to build influence by solving a problem everyone has but nobody wants to talk about.
Early Life and the Sysadmin Years
Corey Quinn’s entry into technology did not follow the typical Silicon Valley script. He did not study computer science at Stanford. He did not intern at a FAANG company. Instead, Quinn came up through the operations side of the industry — the world of system administrators, on-call rotations, and infrastructure firefighting that keeps the internet running but rarely gets the credit. His early career was spent managing Linux servers, writing Bash scripts, debugging network configurations, and dealing with the unglamorous reality of keeping production systems alive at three in the morning.
This background shaped everything that followed. Unlike many cloud commentators who approach the subject from a product management or venture capital perspective, Quinn understood infrastructure from the ground up. He knew what it felt like to provision servers by hand, to manage capacity planning on physical hardware, and to watch a carefully planned deployment fall apart because of a misconfigured load balancer. He had the deep operational instincts of someone who had been paged at 2 AM enough times to develop strong opinions about monitoring, alerting, and the fundamental fragility of distributed systems.
The sysadmin experience also gave Quinn something else: a communication style. Operations engineers develop a particular brand of dark humor — a coping mechanism for working in an environment where things constantly break, where success is invisible, and where failure is a public spectacle. Quinn’s ability to explain complex cloud concepts through humor, metaphor, and calculated provocation comes directly from years of writing postmortem reports, explaining outages to non-technical stakeholders, and maintaining sanity in the face of production chaos. This skill — translating technical complexity into language that resonates with both engineers and executives — would become the foundation of his entire public career.
The Birth of Cloud Economics
Discovering the AWS Billing Problem
The transition from hands-on operations to cloud economics began with a simple observation: AWS bills were incomprehensible. Not just large — genuinely impossible to understand. Amazon Web Services, by the mid-2010s, had grown into the dominant cloud platform, with hundreds of services, thousands of instance types, and a pricing model so convoluted that even experienced engineers struggled to predict what a workload would cost. The AWS bill itself was a sprawling document full of line items like “USW2-EBS:VolumeUsage.gp2” and “USE1-DataTransfer-Out-Bytes” — entries that required specialized knowledge just to decode, let alone optimize.
Quinn recognized that this complexity was not accidental. Cloud pricing opacity served the vendor’s interests: confused customers overspend, and overspending customers are profitable customers. The traditional response was to build more dashboards and monitoring tools — products like AWS Cost Explorer gave you pretty graphs of your spending, but they rarely explained why you were spending what you were spending or how to spend less. It was the equivalent of a bank showing you your declining balance without explaining which subscriptions were draining it.
Quinn’s insight was that cloud cost optimization was not a tooling problem — it was a people and process problem. The engineers building systems on AWS had no incentive to think about cost. Their performance reviews measured uptime, feature velocity, and system reliability, not monthly spend. Finance teams could see the numbers but lacked the technical context to understand them. And management sat between the two, unable to bridge the gap. Cloud economics, as Quinn conceived it, was the discipline of connecting these disconnected worlds — giving engineers enough financial context to make cost-aware decisions, and giving finance teams enough technical context to ask the right questions.
The AWS Bill Anatomy
To illustrate the kind of analysis Quinn championed, consider a typical scenario. A company running a production workload on AWS might see a sudden 40% increase in their monthly bill and have no idea why. The investigation requires cross-referencing multiple data sources — CloudWatch metrics, Cost Explorer reports, billing line items, and resource tags — to identify the root cause. Quinn’s approach emphasized building systematic processes for this kind of analysis. Here is an example of a cost analysis script that demonstrates the methodology:
#!/usr/bin/env python3
"""
AWS Cost Anomaly Detector — inspired by Duckbill Group methodology.
Identifies the top cost drivers and flags unexpected spending spikes
by comparing current month usage against the trailing 3-month average.
"""
import boto3
from datetime import datetime, timedelta
from collections import defaultdict
def get_cost_by_service(ce_client, start_date, end_date):
"""Retrieve AWS costs grouped by service for a date range."""
response = ce_client.get_cost_and_usage(
TimePeriod={
'Start': start_date.strftime('%Y-%m-%d'),
'End': end_date.strftime('%Y-%m-%d')
},
Granularity='MONTHLY',
Metrics=['UnblendedCost'],
GroupBy=[{
'Type': 'DIMENSION',
'Key': 'SERVICE'
}]
)
costs = {}
for group in response['ResultsByTime'][0]['Groups']:
service = group['Keys'][0]
amount = float(group['Metrics']['UnblendedCost']['Amount'])
if amount > 0.01:
costs[service] = round(amount, 2)
return costs
def detect_anomalies(current_costs, historical_avg, threshold=0.25):
"""Flag services where current spend exceeds historical avg by threshold."""
anomalies = []
for service, current in current_costs.items():
avg = historical_avg.get(service, 0)
if avg > 10 and current > avg * (1 + threshold):
increase_pct = ((current - avg) / avg) * 100
anomalies.append({
'service': service,
'current': current,
'average': avg,
'increase_pct': round(increase_pct, 1),
'excess_cost': round(current - avg, 2)
})
return sorted(anomalies, key=lambda x: x['excess_cost'], reverse=True)
def main():
ce = boto3.client('ce', region_name='us-east-1')
today = datetime.utcnow().replace(day=1)
# Current month costs
current = get_cost_by_service(ce, today, datetime.utcnow())
# Trailing 3-month average for baseline comparison
historical = defaultdict(list)
for i in range(1, 4):
month_start = (today - timedelta(days=30 * i)).replace(day=1)
month_end = (month_start + timedelta(days=32)).replace(day=1)
monthly = get_cost_by_service(ce, month_start, month_end)
for svc, cost in monthly.items():
historical[svc].append(cost)
avg_costs = {
svc: round(sum(vals) / len(vals), 2)
for svc, vals in historical.items()
}
anomalies = detect_anomalies(current, avg_costs)
print(f"\n{'='*60}")
print(f" AWS Cost Anomaly Report — {today.strftime('%B %Y')}")
print(f"{'='*60}\n")
if not anomalies:
print(" No significant cost anomalies detected.\n")
else:
for a in anomalies[:10]:
print(f" {a['service']}")
print(f" Current: ${a['current']:>10,.2f}")
print(f" Average: ${a['average']:>10,.2f}")
print(f" Increase: {a['increase_pct']:>9.1f}%")
print(f" Excess: ${a['excess_cost']:>10,.2f}\n")
if __name__ == '__main__':
main()This type of programmatic cost analysis, combining billing data with usage metrics and historical baselines, became the foundation of the Duckbill Group’s methodology. Quinn’s key contribution was framing cost optimization not as a technical exercise but as a business discipline — one that required understanding both the engineering architecture and the financial incentives driving cloud spending decisions.
The Duckbill Group and Professional Cloud Economics
In 2019, Quinn co-founded the Duckbill Group with Mike Julian. The company’s premise was radical in its simplicity: they would look at your AWS bill, figure out why it was so high, and tell you how to make it lower. No software to install. No dashboards to configure. No annual subscription. Just expert analysis and actionable recommendations.
The Duckbill Group’s model challenged the prevailing assumption in the cloud cost management space that the solution was better tooling. Companies like CloudHealth, Cloudability, and Spot.io (later acquired by NetApp) had built sophisticated platforms for visualizing and optimizing cloud spending. These tools were useful, but Quinn argued they solved the wrong problem. Showing a company a graph of their spending was like showing an overweight person a graph of their weight — technically informative but practically useless without context and a concrete action plan. What companies needed was not another dashboard but someone who could sit down with the engineering team, understand the architecture, identify the waste, and propose specific changes with quantified savings.
The Duckbill Group’s engagements typically uncovered savings of 20-40% on monthly AWS spend, often through changes that seemed obvious in retrospect but required deep platform knowledge to identify: switching from on-demand instances to Savings Plans, eliminating forgotten development environments running 24/7, right-sizing databases that had been provisioned for peak load but consistently ran at 10% utilization, consolidating S3 storage tiers, and renegotiating Enterprise Discount Programs. The work required a rare combination of skills — the technical depth to understand cloud architectures and the financial literacy to quantify the business impact of proposed changes. In the broader landscape of CI/CD and DevOps tooling, cost awareness has become an increasingly critical dimension of operational excellence.
Last Week in AWS and Media Influence
Building the Newsletter
While the Duckbill Group was the business, Last Week in AWS was the megaphone. The newsletter, launched in 2017, started as a curated roundup of AWS news with Quinn’s commentary layered on top. What set it apart from every other cloud computing newsletter was the tone. Quinn wrote with the irreverence of a stand-up comedian and the authority of someone who had spent years deep in the operational trenches. He gave AWS services absurd nicknames, openly mocked confusing product announcements, and regularly pointed out the gap between AWS’s marketing and the reality of using their products in production.
The humor served a strategic purpose. Cloud computing news is, by its nature, dry and dense — product launches, pricing changes, API updates, compliance certifications. Most coverage reads like press releases rewritten by someone who does not actually use the products. Quinn’s approach cut through the noise by making cloud news genuinely entertaining to read. Engineers forwarded his newsletter to their colleagues not because they needed to know about a new EC2 instance type, but because Quinn’s take on it was funny. The result was organic growth that no marketing budget could replicate.
Last Week in AWS also became an influential platform for holding AWS accountable. When AWS released a confusingly named service, Quinn called it out. When pricing changes buried cost increases in technical jargon, Quinn translated them into plain language. When AWS documentation was incomplete or misleading, Quinn said so publicly. This willingness to criticize the dominant cloud provider — while simultaneously building a business that depended on that provider’s continued complexity — gave Quinn a unique position in the ecosystem. He was not anti-AWS; he was pro-transparency. The distinction mattered, and it earned him credibility with both AWS customers and AWS employees, many of whom read Last Week in AWS more carefully than their own internal communications.
The Screaming in the Cloud Podcast
Quinn expanded his media presence with Screaming in the Cloud, a podcast that brought long-form interviews with cloud practitioners, executives, and open-source maintainers. The podcast filled a gap in the cloud media landscape — most existing podcasts were either vendor-sponsored marketing vehicles or deeply technical discussions aimed at specialists. Screaming in the Cloud found the middle ground: substantive technical conversations conducted in accessible language, often touching on the business and organizational dimensions of cloud adoption that purely technical shows ignored.
Over hundreds of episodes, the podcast became a valuable oral history of the cloud computing era, capturing perspectives from engineers at companies of every size, from solo developers running personal projects on AWS to architects managing multi-million-dollar cloud deployments at Fortune 100 companies. The interviews revealed patterns that no amount of documentation or training material could convey — the human stories behind infrastructure decisions, the organizational dynamics that drive cloud adoption (and cloud waste), and the career paths that lead people into cloud engineering. For those interested in the broader landscape of how technology teams organize and operate, understanding the principles of web performance optimization provides additional context on why infrastructure decisions matter at every scale.
Technical Philosophy and Contributions
The Art of Cloud Cost Analysis
Quinn’s technical philosophy can be distilled into a few core principles. First, cloud costs are an engineering problem with a business solution. You cannot optimize what you do not understand, and understanding requires both technical and financial literacy. Second, the default configuration of any cloud service is optimized for the vendor, not the customer. Every default instance size, every default storage class, every default retention policy is set to maximize the vendor’s revenue, not minimize the customer’s costs. Third, cloud cost optimization is not a one-time project but an ongoing discipline — architectures change, pricing models evolve, and new services create new opportunities for both savings and waste.
These principles informed a practical methodology that Quinn applied and evangelized. The process typically started with a comprehensive bill audit, examining every line item to understand what was being spent and where. Next came architecture review — mapping the actual resource usage to the business requirements to identify over-provisioning, redundancy, and waste. Then came the recommendations phase, where each proposed change was quantified in terms of both cost savings and engineering effort, allowing the customer to prioritize based on return on investment. Finally, ongoing monitoring ensured that optimizations persisted and new cost anomalies were caught early.
The following Bash script illustrates a practical approach to identifying unused AWS resources — the kind of low-hanging fruit that Quinn’s team routinely discovered in client environments:
#!/usr/bin/env bash
# AWS Resource Waste Finder — identifies idle and unused resources
# that contribute to unnecessary cloud spending.
# Inspired by Duckbill Group's cost optimization methodology.
set -euo pipefail
AWS_REGION="${AWS_REGION:-us-east-1}"
echo "============================================"
echo " AWS Waste Finder — Region: $AWS_REGION"
echo " Generated: $(date -u '+%Y-%m-%d %H:%M UTC')"
echo "============================================"
# 1. Unattached EBS Volumes (paying for storage nobody uses)
echo -e "\n--- Unattached EBS Volumes ---"
UNATTACHED=$(aws ec2 describe-volumes \
--region "$AWS_REGION" \
--filters "Name=status,Values=available" \
--query 'Volumes[].{ID:VolumeId,Size:Size,Type:VolumeType,Created:CreateTime}' \
--output table 2>/dev/null)
if [ -n "$UNATTACHED" ]; then
echo "$UNATTACHED"
TOTAL_GB=$(aws ec2 describe-volumes \
--region "$AWS_REGION" \
--filters "Name=status,Values=available" \
--query 'sum(Volumes[].Size)' \
--output text 2>/dev/null)
echo " Total unattached storage: ${TOTAL_GB} GB"
echo " Estimated monthly waste: \$$(echo "$TOTAL_GB * 0.10" | bc) (gp3)"
else
echo " No unattached volumes found."
fi
# 2. Elastic IPs not associated with running instances
echo -e "\n--- Unused Elastic IPs ---"
UNUSED_EIPS=$(aws ec2 describe-addresses \
--region "$AWS_REGION" \
--query 'Addresses[?AssociationId==`null`].{IP:PublicIp,AllocID:AllocationId}' \
--output table 2>/dev/null)
if [ -n "$UNUSED_EIPS" ]; then
echo "$UNUSED_EIPS"
COUNT=$(aws ec2 describe-addresses \
--region "$AWS_REGION" \
--query 'length(Addresses[?AssociationId==`null`])' \
--output text 2>/dev/null)
echo " Unused EIPs: $COUNT"
echo " Monthly waste: \$$(echo "$COUNT * 3.65" | bc)"
else
echo " No unused Elastic IPs."
fi
# 3. Old EBS Snapshots (over 180 days)
echo -e "\n--- EBS Snapshots Older Than 180 Days ---"
CUTOFF=$(date -u -v-180d '+%Y-%m-%dT%H:%M:%S' 2>/dev/null \
|| date -u -d '180 days ago' '+%Y-%m-%dT%H:%M:%S')
OLD_SNAPS=$(aws ec2 describe-snapshots \
--region "$AWS_REGION" \
--owner-ids self \
--query "length(Snapshots[?StartTime<='${CUTOFF}'])" \
--output text 2>/dev/null)
echo " Snapshots older than 180 days: $OLD_SNAPS"
# 4. Idle Load Balancers (zero healthy targets)
echo -e "\n--- Idle Application Load Balancers ---"
for ALB_ARN in $(aws elbv2 describe-load-balancers \
--region "$AWS_REGION" \
--query 'LoadBalancers[].LoadBalancerArn' \
--output text 2>/dev/null); do
TG_COUNT=$(aws elbv2 describe-target-groups \
--region "$AWS_REGION" \
--load-balancer-arn "$ALB_ARN" \
--query 'length(TargetGroups[])' \
--output text 2>/dev/null)
if [ "$TG_COUNT" = "0" ]; then
ALB_NAME=$(echo "$ALB_ARN" | awk -F'/' '{print $(NF-1)}')
echo " IDLE: $ALB_NAME (no target groups)"
fi
done
echo -e "\n============================================"
echo " Review complete. Address items above to"
echo " reduce unnecessary AWS spending."
echo "============================================"Scripts like these represent the ethos Quinn promoted: cloud cost optimization does not require expensive third-party platforms. It requires understanding your infrastructure, asking the right questions, and building lightweight processes to catch waste before it accumulates. The same mindset that drives modern full-stack development workflows — automation, observability, and continuous improvement — applies directly to cloud financial management.
Industry Impact and the FinOps Movement
Quinn’s work intersected with and amplified a broader industry shift toward financial operations in cloud computing, now known as FinOps. The FinOps Foundation, established as a program under the Linux Foundation, codified many of the practices that Quinn had been advocating independently: cross-functional collaboration between engineering and finance, real-time visibility into cloud spending, and a culture of cost accountability distributed across engineering teams rather than centralized in a procurement department.
Quinn’s contribution to this movement was less about inventing specific practices and more about creating the cultural conditions that made FinOps adoption possible. By making cloud cost conversations entertaining and accessible through Last Week in AWS, by demonstrating the ROI of dedicated cost optimization through the Duckbill Group’s client work, and by relentlessly highlighting the absurdities of cloud pricing through his social media presence, Quinn helped normalize a conversation that many organizations found uncomfortable. Talking about cloud costs meant acknowledging waste, and acknowledging waste meant admitting that past decisions were suboptimal. Quinn’s humor made it safe to have that conversation — it was easier for an engineering manager to share a sarcastic Last Week in AWS article about S3 pricing than to write a formal memo arguing that the team was overspending.
The impact extended beyond AWS. Although Quinn focused primarily on Amazon’s cloud platform — partly because AWS had the largest market share and the most complex pricing, partly because focus is a strategic advantage — the principles he promoted applied across all major cloud providers. Google Cloud Platform and Microsoft Azure had their own versions of pricing complexity, their own defaults optimized for vendor revenue, and their own ecosystems of confused customers. For teams evaluating modern web frameworks and deployment strategies, understanding the cost implications of cloud hosting decisions has become as important as understanding the technical trade-offs.
Quinn’s influence also reshaped how AWS itself communicated. While it is impossible to draw a direct causal line, AWS’s increasing transparency around pricing — including the introduction of more granular cost allocation tags, improved Cost Explorer features, and the creation of the AWS Customer Carbon Footprint Tool — coincided with growing public pressure from voices like Quinn’s. The relationship between Quinn and AWS became a case study in constructive criticism: Quinn remained one of AWS’s most visible critics, and AWS continued to invite him to speak at re:Invent, the company’s annual conference. Both sides benefited from the dynamic — Quinn got access and credibility, and AWS got honest, public feedback that helped them improve.
Communication Style and Personal Brand
Any discussion of Corey Quinn’s career would be incomplete without examining his approach to personal branding and communication. Quinn built one of the most recognizable personal brands in cloud computing through a deliberate strategy that combined technical expertise with provocative humor. His Twitter presence (under the handle @QuinnyPig) became a must-follow for cloud professionals, featuring a mix of cost optimization tips, industry commentary, and jokes that walked the line between insightful and inflammatory.
The personal brand strategy was not accidental. Quinn understood that in a crowded market for cloud expertise, technical knowledge alone was not a differentiator — there were thousands of competent AWS engineers. What differentiated him was the ability to make that expertise visible, memorable, and shareable. Every sarcastic tweet, every provocative newsletter headline, every conference talk title designed to make the audience double-take was a calculated effort to cut through the noise of cloud computing content and reach decision-makers who would otherwise never encounter cost optimization advice.
This approach was not without controversy. Quinn’s confrontational style occasionally drew criticism from those who felt it crossed the line from constructive criticism into negativity. Some AWS employees found his constant ribbing tiresome. Some cloud professionals felt his humor overshadowed the substance of his message. But the results were undeniable: Last Week in AWS grew into one of the most-read newsletters in technology, the Duckbill Group never lacked for clients, and Quinn became one of the most requested speakers on the cloud computing conference circuit. For professionals building their own technology careers, the tools offered by platforms like Taskee can help organize the kind of systematic, multi-channel content strategy that Quinn executed so effectively.
Legacy and Ongoing Influence
Corey Quinn’s legacy extends across multiple dimensions of the cloud computing industry. He demonstrated that cloud economics is a legitimate and valuable specialization, not just a side concern for finance departments. He proved that media — newsletters, podcasts, social media — can be a business strategy in its own right, not just a marketing channel. He showed that humor and technical credibility are not mutually exclusive, and that the most effective way to change an industry is sometimes to make it laugh at its own absurdities.
The Duckbill Group’s methodology influenced how organizations think about cloud spending, shifting the conversation from “how much are we spending?” to “what value are we getting for what we spend?” This framing — treating cloud costs as an investment to be optimized rather than an expense to be minimized — has become standard in the FinOps community. The distinction matters because pure cost cutting can be counterproductive (turning off servers saves money but also stops revenue), while cost optimization seeks the highest return per dollar spent.
Quinn’s career also offers a template for how individual practitioners can build outsized influence in technology. Unlike many industry figures who rose through the ranks of large companies or built venture-backed startups, Quinn built his platform through consistent, high-quality content creation and a willingness to say things that others thought but were afraid to voice publicly. His trajectory — from anonymous sysadmin to one of the most recognized voices in cloud computing — demonstrates that expertise combined with communication skills can create career leverage that no job title can match. In an industry where teams frequently rely on Toimi for strategic digital planning and brand development, Quinn’s organic approach to authority-building stands as a compelling alternative to paid promotion and traditional marketing.
The questions Quinn raised about cloud pricing transparency, vendor lock-in economics, and the hidden costs of cloud migration remain central to the industry’s evolution. As cloud computing continues to grow — AWS alone generated over $100 billion in annual revenue by 2024 — the need for independent voices who can cut through vendor marketing, explain complex pricing in plain language, and advocate for customer interests has only intensified. Corey Quinn proved that being that voice is not just possible but profitable, and in doing so, he created a model that the next generation of cloud practitioners can build upon.
His contributions to pioneers like Mitchell Hashimoto and the broader infrastructure-as-code movement are complementary — where Hashimoto built the tools that made cloud infrastructure programmable, Quinn built the analytical framework that made cloud spending understandable. Together, they represent two sides of the cloud computing revolution: the engineering that makes it possible and the economics that make it sustainable.
Frequently Asked Questions
Who is Corey Quinn?
Corey Quinn is a cloud economics analyst, AWS commentator, and co-founder of the Duckbill Group. He is best known for creating the Last Week in AWS newsletter, which provides curated AWS news with candid analysis and humor. Quinn specializes in helping organizations understand and reduce their cloud computing costs, and he is widely regarded as one of the most influential independent voices in the cloud computing industry.
What is the Duckbill Group?
The Duckbill Group is a cloud cost optimization consultancy co-founded by Corey Quinn and Mike Julian in 2019. The company specializes exclusively in analyzing and reducing AWS bills for organizations of all sizes. Rather than selling software or dashboards, the Duckbill Group provides expert human analysis, typically uncovering 20-40% in potential savings on clients’ monthly AWS spending through architectural recommendations, pricing model optimization, and waste elimination.
What is Last Week in AWS?
Last Week in AWS is a weekly newsletter that curates and comments on the latest Amazon Web Services news, announcements, and developments. Created by Corey Quinn in 2017, it has grown to over 100,000 subscribers and is known for its irreverent tone, practical insights, and willingness to criticize AWS when warranted. The newsletter also serves as a platform for the broader Last Week in AWS media brand, which includes the Screaming in the Cloud podcast.
What is cloud economics and why does it matter?
Cloud economics is the discipline of understanding, analyzing, and optimizing the financial aspects of cloud computing. It matters because cloud bills can be extremely complex — AWS alone has hundreds of services with thousands of pricing variables — and organizations routinely overspend by 20-40% due to over-provisioning, unused resources, suboptimal pricing models, and lack of financial visibility. Cloud economics bridges the gap between engineering teams (who control spending through architecture decisions) and finance teams (who manage budgets), creating shared accountability for cloud costs.
What is the relationship between cloud economics and FinOps?
FinOps (Financial Operations) is the broader industry movement that formalized many cloud economics practices into a defined framework. The FinOps Foundation, operating under the Linux Foundation, provides certifications, frameworks, and community resources for cloud financial management. Corey Quinn’s work predated and influenced the FinOps movement — his advocacy for cloud cost transparency, cross-functional collaboration, and engineering-driven cost optimization helped create the cultural conditions that enabled FinOps to emerge as a recognized discipline.
How can organizations start optimizing their AWS costs?
Quinn consistently recommended starting with three high-impact areas: first, identify and eliminate unused resources (unattached EBS volumes, idle load balancers, forgotten development environments running 24/7); second, right-size over-provisioned instances by comparing actual CPU and memory utilization against provisioned capacity; and third, evaluate commitment-based pricing models (Reserved Instances and Savings Plans) for stable workloads where usage patterns are predictable. Beyond these technical measures, Quinn emphasized the organizational dimension — assigning cost accountability to engineering teams, implementing tagging standards for cost allocation, and establishing regular cost review processes that include both engineering and finance stakeholders.
