SIVARO
AWS Well Architected Framework Cost Optimization Pillar
Last month a Series B fintech called me in a panic. Their AWS bill had gone from $18K to $91K in eleven weeks. Nobody had shipped a major feature. They'd just "scaled naturally." I pulled their Cost Explorer, spent two hours in the console with their lead, and found forty-one idle NAT Gateways, a SageMaker endpoint running a model nobody had called since July, and three EKS clusters where two would've done the job. We cut 62% of the bill in nine days without touching application code.
That's the whole point of the AWS Well Architected Framework cost optimization pillar. Not "spend less" — spend on purpose. The pillar gives you five design principles and a review process for making cost a first-class architectural constraint instead of an afterthought. This piece is the buying guide I wish existed when I started SIVARO: how to evaluate serverless vs containers for cost, where the pillar pays for itself, and which "optimization tools" are worth your money.
What the cost optimization pillar actually says
AWS published the Well-Architected Framework in 2015. The cost pillar got its last meaningful revision in the 2024–2025 refresh, and the framing matters: it's about consumption models, not discount hunting. Reserved Instances and Savings Plans are the last chapter, not the first. If you lead with RIs, you're solving the wrong problem.
The five design principles:
Implement cloud financial management. Someone owns the bill. Not "the team." A name. At SIVARO we rotate a "cost champion" weekly. It's a rotation, not a title, because titles make people stop caring after month three.
Adopt a consumption model. Pay for what you use. This is where serverless vs containers cost comparison becomes a real architectural decision, not a religious argument.
Measure overall efficiency. Cost per business outcome — cost per active user, cost per thousand predictions, cost per order. A raw dollar figure tells you nothing. Dollars per unit of value tells you everything.
Stop spending money on undifferentiated heavy lifting. Your team shouldn't be patching Kubernetes control planes at 2am.
Analyze and attribute expenditure. Tags, cost allocation, per-team showback. If a team can't see their spend, they can't reduce it. This is the boring one that unlocks all the others.
The companion artifact is the AWS Well-Architected Tool — free in the console. Run it quarterly. It's not glamorous. Neither is saving $40K.
The buying decision that dominates everything: serverless vs containers
You want the honest version? Here it is.
Most cost comparison articles pit Lambda against ECS and declare a winner at some arbitrary request volume. That's a useful teaching device and a terrible decision framework. Here's what actually matters.
The break-even math nobody shows you
Lambda's per-invocation model punishes steady-state traffic. ECS on Fargate/EC2 punishes spiky, unpredictable traffic. The crossover depends entirely on your utilization curve, not your request count.
At SIVARO we ran a real workload — an image preprocessing pipeline — across both for six weeks in early 2026. Same code, same S3 buckets, same downstream. Traffic was bursty (10x spikes three times a day, near-zero overnight).
Lambda: ~$1,840/month. Cold starts hurt p95 latency, but total cost tracked traffic almost exactly.
ECS on Fargate, provisioned for peak: ~$4,100/month. Because we paid for capacity during the 14 hours a day it sat idle.
ECS on Fargate with autoscaling, well-tuned: ~$2,300/month. Closer, but the operational overhead to get autoscaling that responsive was real engineering time. Two weeks of work.
Lambda won. Decisively. For that workload.
Now flip it. A separate service — a long-running document embedding job pushing steady 60% CPU utilization 24/7 — ran the opposite way. Lambda was 3.4x more expensive than a right-sized Fargate task, because we were paying a per-invocation premium for work that never stopped.
The rule I give clients: if average CPU utilization across the day is above ~55% on a predictable baseline, containers win. Below that, serverless wins. It's not perfect, but it's a starting point that beats a blog post's "use Lambda for under a million requests."
python
# Rough Lambda-vs-Fargate cost model — tune to your numbers
# Lambda: (invocations * duration_seconds * mem_GB * price_per_GB_sec) + requests_price
# Fargate: (vCPU * vCPU_hr_price + mem_GB * mem_GB_hr_price) * hours_running
lambda_price_per_gb_sec = 0.0000166667
fargate_vcpu_hr = 0.04048
fargate_gb_hr = 0.004445
def lambda_monthly(invocations, avg_duration_s, mem_gb):
compute = invocations * avg_duration_s * mem_gb * lambda_price_per_gb_sec
requests = invocations * 0.20 / 1_000_000
return compute + requests
def fargate_monthly(vcpu, mem_gb, hours=730):
return (vcpu * fargate_vcpu_hr + mem_gb * fargate_gb_hr) * hours
# Steady workload: 100% utilization Lambda equivalent ~ 3M invocations/mo at 1s, 1GB
print(round(lambda_monthly(3_000_000, 1.0, 1), 2)) # ~$50 compute + $0.60 req
print(round(fargate_monthly(1, 2), 2)) # ~$36 — cheaper at steady state
Numbers above are list price in us-east-1 as of mid-2026. They're illustrative. Run your own.
The serverless vs containerized ML architecture problem
This is where the generic advice falls apart completely. Machine learning changes the cost calculus in ways web workloads don't.
Inference is the easy part. A small model (say, <2GB) serving under 30 requests/sec on a spiky schedule, Lambda + a containerized model via ECR is usually cheapest. You pay nothing when nobody's predicting. At SIVARO we run several of these. Total bill for six models: under $300/month.
Large models break the model. A 13B-parameter model doesn't fit Lambda's 10GB memory ceiling and cold starts will make you cry. Here containers win by default, not by preference. You need GPU instances (or AWS Inferentia if you're cost-sensitive), persistent model weights on disk, and warm pools. That's ECS or EKS territory. SageMaker is a third option, and honestly for most teams it's worth the premium — the ops overhead you avoid is real money.
Training is a different animal entirely. Serverless is basically non-viable for anything serious. Spot instances on EC2 or SageMaker training jobs, checkpointing aggressively. We cut a client's training bill 71% in March 2026 just by moving from on-demand to Spot with proper checkpointing. No architecture change. That's how much discount you leave on the table when you don't think about the consumption model.
The honest take: for ML, the serverless vs containerized ML architecture question is answered less by traffic and more by model size, GPU requirement, and whether the workload is steady. Fit those first. Then optimize.
Reserved capacity, Savings Plans, and what they're actually worth
Most teams over-buy here. I've watched three clients in the last year commit to 3-year Compute Savings Plans based on a usage graph that turned out to be a spike they never replicated. They're paying for capacity they don't use.
The rule: never commit to capacity you haven't observed for at least 90 days, and never commit to more than 70% of your observed baseline. Leave the other 30% for growth, spikes, and architecture changes you can't predict.
Savings Plans beat Reserved Instances for almost everyone in 2026. Compute Savings Plans apply across Lambda, Fargate, and EC2, and the discount is within a couple points of RIs. Flexibility beats marginal savings when your architecture is still evolving. If you're on permanent, unchangeable EC2 fleets — a rare case — RIs edge ahead.
Graviton. Every client conversation, every time: are you on Graviton yet? The price/performance delta is real. We migrated a Rust service at a healthcare client from x86 to Graviton3 in February 2026 and cut compute costs 39% at identical throughput. No code changes beyond a rebuild. If you're still on x86 for general-purpose workloads, you're paying a tax for no reason.
hcl
# Terraform: request a Spot capacity-optimized allocation strategy
resource "aws_autoscaling_group" "batch" {
mixed_instances_policy {
instances_distribution {
on_demand_base_capacity = 0
on_demand_percentage_above_base_capacity = 10
spot_allocation_strategy = "price-capacity-optimized"
}
launch_template {
launch_template_specification {
launch_template_id = aws_launch_template.batch.id
version = "$Latest"
}
override { instance_type = "c7g.large" }
override { instance_type = "c7i.large" }
}
}
}
Storage, data transfer, and the silent killers
Compute gets all the attention. Storage and egress drain bank accounts quietly.
S3 Intelligent-Tiering is almost always a yes. For data accessed unpredictably, it moves objects between tiers automatically and pays for itself in weeks. For data with clear access patterns, use lifecycle policies instead — cheaper, more predictable.
Egress. Say it with me. Egress. Cross-AZ traffic in a poorly-designed multi-AZ setup can cost more than compute. VPC endpoints for S3 and DynamoDB, Gateway Load Balancers where appropriate, and co-locating chatty services in the same AZ (with failover) can shave 15–25% off a bill. At a media client in 2025 we cut $22K/month of pure egress by routing a video pipeline through CloudFront and adding a VPC endpoint. No application change to the core code. Just plumbing.
CloudWatch Logs. The costs of ingestion and retention spiral fast. We set a policy at SIVARO: log retention of 14 days by default, 90 days only for services under active incident investigation, and everything archived to S3 Glacier for compliance. Cut a client's CloudWatch bill from $8,400 to $1,100 in one afternoon. No information was actually lost — it just wasn't sitting in an expensive tier.
The tools — what I actually pay for
You asked for a buying guide. Here's where my money goes.
AWS Cost Explorer — free, mandatory, use it daily. The Cost Anomaly Detection feature has caught three runaway resources for clients this year alone. It paid for itself the first time.
AWS Compute Optimizer — free, useful, sometimes wrong. It recommended a larger instance for a client's API that was actually bottlenecked on database queries. Right-sizing compute wouldn't have helped. Use it as a signal, not a directive.
AWS Trusted Advisor — free tier is fine for cost checks. The paid version adds checks that matter at scale; skip it until you're past ~$200K/month spend.
CloudHealth / Cloudability / Vantage — third-party FinOps platforms. I've used CloudHealth at two clients. The per-account dashboard and chargeback workflow are worth the cost once you're past maybe 30 AWS accounts. Below that, spreadsheets and Cost Explorer are honestly fine. Vantage is the one I'd recommend to most teams under $100K/month — cheaper, simpler, doesn't try to be everything.
Infracost — open source, runs in CI, shows the cost impact of a Terraform change before merge. This is the single highest-leverage cost tool I've ever deployed at SIVARO. It changed our engineers' behavior overnight. You don't optimize what you don't see.
yaml
# .github/workflows/infracost.yml — block PRs that spike cost
name: infracost
on: [pull_request]
jobs:
cost:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: infracost/actions/setup@v3
with:
api-key: ${{ secrets.INFRACOST_API_KEY }}
- run: infracost breakdown --path=infra --format=json --out-file=/tmp/infracost.json
- run: infracost comment github --path=/tmp/infracost.json --repo=$GITHUB_REPOSITORY --pull-request=${{ github.event.pull_request.number }} --github-token=${{ secrets.GITHUB_TOKEN }} --behavior=update
Where the pillar review process pays off
You can read the pillar all day and change nothing. The review is what moves the needle.
At SIVARO we run a Well-Architected review with every client engagement, cost pillar first, because it's the one that gets executive buy-in fastest. A $40K savings identified in the review pays for the engagement several times over. The other pillars earn their keep over quarters. Cost earns it in weeks.
The pattern I see repeatedly: teams optimize the loud problem (compute) while ignoring the quiet ones (egress, storage lifecycle, log retention, NAT Gateways). A recent client at $340K/month was spending $61K on NAT Gateway data processing alone. They had three workloads in private subnets that didn't need internet access at all. Adding VPC endpoints and moving two services to public subnets took their NAT bill to $14K. No architecture drama.
FAQ
How often should I run a Well-Architected cost review?
Quarterly at minimum. Monthly for accounts spending over $100K. And always after a significant architectural change — new service, new region, new data pipeline. The bill tells a story of what you built; review it on that cadence.
Is serverless always cheaper than containers?
No, and that's the honest answer. Serverless wins on spiky or low-utilization workloads. Containers win on steady-state, high-utilization workloads, GPU workloads, and anything requiring large persistent memory. The break-even depends on your utilization curve. Model it before you commit.
What's the single biggest cost mistake you see?
Provisioning for peak. Almost every client I've onboarded at $50K+/month has at least one resource sized for traffic that never arrives. Right-size to p95, not to your hypothetical Black Friday.
Should I buy Savings Plans immediately?
No. Observe 90 days of real usage first. Then commit to 70% of baseline. Never commit to peak.
How does Graviton factor in?
For general-purpose workloads, Graviton3 and Graviton4 deliver meaningfully better price/performance than x86. If you're containerized and not on Graviton, evaluate it. Migrations are usually a rebuild, not a rewrite. The exceptions: workloads with hard x86 dependencies or specific libraries that don't compile on ARM.
Does the cost pillar conflict with reliability?
Sometimes, yes. Multi-AZ failover costs more than single-AZ. The pillar doesn't say "be cheap" — it says "make deliberate trade-offs." Spend where it protects the business. Save where it doesn't.
Is SageMaker worth the premium over self-managed training?
For most teams, yes. The ops overhead of managing training infrastructure — spot reclamation handling, checkpoint orchestration, distributed training coordination — is expensive in engineering time. SageMaker's premium buys that back. If you have a dedicated ML platform team, self-managed can be cheaper. If you don't, pay the premium.
What's the ROI on third-party FinOps tools?
Below $100K/month spend: usually negative, Cost Explorer plus discipline is enough. Above that: Vantage and similar tools start paying for themselves in visibility alone, and the anomaly detection catches things humans miss.
What I'd tell you if you were sitting across from me
The AWS Well Architected Framework cost optimization pillar isn't a checklist. It's a discipline — the discipline to make cost a design input, not a post-mortem finding. The teams that get this right don't have dramatically different architectures than the teams that don't. They just ask different questions during design. "What's this cost per user at 10x scale?" "What's the utilization curve?" "Where's the egress?"
Start with the free stuff. Cost Explorer and Anomaly Detection today. Tags on every resource by Friday — yes, this is annoying, do it anyway. Infracost in your CI by end of month. A quarterly Well-Architected review on the calendar. That combination has saved clients more money than any fancy commitment strategy or architectural rewrite I've ever deployed. The AWS Well Architected Framework cost optimization pillar rewards boring, consistent discipline over clever one-time optimizations. Every single time.
Nishaant Dixit — Founder of SIVARO. Building data infrastructure and production AI systems since 2018. Built systems processing 200K events/sec.