SIVARO
Serverless vs Containers Cost Comparison: What We Paid
In March 2026, our AWS bill for a single ML inference microservice jumped from $34K to $61K in one month. I stared at the CUR export at 11pm, coffee going cold, and realized we'd quietly shifted from a serverless Lambda setup to spinning up EKS pods for a model that needed 400ms cold-start time. Nobody had flagged it. The "simplification" ticket from Q1 had a financial consequence nobody priced.
That's when I stopped treating the serverless vs containers cost comparison as a theoretical framework and started treating it as an operational decision with real dollar consequences. Here's what I learned pulling 18 months of billing data across three SIVARO client projects, running the same workloads on both, and watching the numbers bleed.
This article breaks down where serverless actually saves you money, where containers win by a landslide, and the hybrid patterns that keep your CFO from having a stroke. You'll get specific dollar figures, real architecture trade-offs for ML workloads, and how to frame this decision inside the AWS Well-Architected Framework cost optimization pillar so it survives a board review. No hand-waving. No "it depends" without a "depends on what" attached.
The billing statement that changed my mind
Here's the thing nobody tells you when you're picking between Lambda and EKS in 2026: the pricing model punishes you differently.
Serverless charges you per invocation and per GB-second of compute. You pay for the request. You pay for the time the function ran. Miss a request, pay zero. It's usage-based, which sounds beautiful until your traffic pattern is spiky and you've set your timeout to 30 seconds "just in case."
Containers charge you for the pod's existence. Whether it's processing 500 requests a minute or zero, the vCPU and memory allocation is billable from the second the pod schedules to the second it terminates. On EKS, that's roughly $0.042 per node-hour on a t3.medium (the node itself) plus your compute. On Fargate, it's $0.04042/vCPU-hour and $0.004445/GB-hour for memory.
The serverless vs containers cost comparison isn't a single number. It's a function of your traffic shape, your cold-start tolerance, and your memory requirements. Three variables that most architecture reviews skip entirely.
I've seen teams choose EKS because "containers are more flexible" and end up with 60% idle capacity. I've seen teams choose Lambda because "serverless is cheaper" and end up paying 4x for timeout extensions they never hit. Both are real. Both happened to SIVARO clients within the last 12 months.
How the serverless vs containers cost comparison actually breaks down
Let me give you the math I ran in April 2026 for a mid-tier API service. 50M requests/month, average payload 2KB, processing time 120ms, 512MB memory.
python
# Cost model I used for the SIVARO Q2 2026 architecture review
# Mid-tier API: 50M requests/mo, 120ms avg, 512MB
# --- SERVERLESS (Lambda) ---
# $0.20 per 1M requests + $0.0000166667 per GB-second
requests_cost = 50 * 0.20 # $10 in invocation charges
compute_cost = 50_000_000 * 0.120 * 0.512 * 0.0000166667 # $51.84
lambda_monthly = requests_cost + compute_cost # ~$61.84
# --- CONTAINERS (EKS, t3.medium nodes, 1 pod per node) ---
# Node cost: $0.042/hr * 730 hrs = $30.66/node
# 50M req / 730 hrs = ~68,493 req/hr
# t3.medium handles ~3,000 req/hr for this workload
pods_needed = 68493 // 3000 + 1 # 24 pods
node_monthly = 24 * 0.042 * 730 # $735.84
# Plus EKS control plane: $0.10/hr * 730 = $73
eks_monthly = node_monthly + 73 # ~$808.84
print(f"Lambda monthly: ${lambda_monthly:.2f}")
print(f"EKS monthly: ${eks_monthly:.2f}")
print(f"Ratio: EKS is {eks_monthly/lambda_monthly:.1f}x more expensive")
For this specific workload — high request volume, low compute per request, bursty traffic — Lambda wins by roughly 13x. The per-invocation pricing model rewards you when your individual requests are cheap.
Now flip it. Same 50M requests, but each one needs 4 seconds of compute and 4GB of memory (you're doing document parsing with a local model). Lambda timeout caps at 15 minutes, but you're burning through GB-seconds like they're free. Meanwhile, your EKS pod with 4GB allocated is sitting there, processing 4-second jobs continuously, and the marginal cost per additional request drops toward zero because the pod's already warm.
The crossover point, in my experience, sits somewhere between 800ms average processing time and 1GB memory. Below that, serverless almost always wins on pure cost. Above it, containers start pulling ahead. Your specific numbers will shift this line. Run your own math before you trust mine.
Running ML workloads: serverless vs containerized ml architecture
This is where the serverless vs containerized ml architecture debate gets genuinely painful.
We deployed a fraud detection model for a fintech client in November 2025. The model was a 14-layer transformer, ~800MB weights, needed a GPU inference pass per request. Average inference time: 340ms. Traffic: 12M requests/month, heavily spiky (weekend patterns, promotional events).
First attempt: Lambda with GPU. AWS launched Lambda GPU instances in 2025, and at first I thought this made the serverless-vs-containers debate for ML moot. Turns out it didn't. The cold start on a GPU Lambda is 8-12 seconds for model loading. On EKS with a warmed-up pod and model weights in local NVMe, it's 200ms. For a user-facing fraud check with a 500ms SLA, 12 seconds of cold start is a dealbreaker.
Second attempt: EKS with A10G GPUs, 4 pods, model weights cached on EFS. Total monthly: $14,200. The pods sat at 35% utilization on off-peak hours. We were paying for GPUs doing nothing.
Third attempt (the one that actually worked): Hybrid. EKS for the base inference layer (3 pods, handling 90% of steady-state traffic at $11,800/month) with an ALB in front, and a serverless Lambda layer for the business logic, feature retrieval, and response formatting that doesn't need GPU. The Lambda layer handled 12M invocations at roughly $4,300/month. Total: $16,100. Down from $14,200 for EKS-only AND we hit our SLA.
The serverless vs containerized ml architecture question isn't binary. It's "which layer of the pipeline justifies a persistent compute allocation." Your model inference layer probably does. Your feature engineering, your request validation, your response serialization — probably doesn't.
The cold start tax nobody mentions
I'll say it plainly: cold starts are the hidden line item in every serverless cost model, and most architects don't budget for them.
On a standard Lambda (no GPU), cold start is 100-800ms depending on runtime, layer size, and VPC networking. Add a VPC and a 200MB model layer, and you're looking at 2-4 seconds. Multiply that by your traffic pattern. If 30% of your requests hit a cold function (typical for medium-traffic services), you're adding 600ms of p99 latency that your SLO doesn't account for.
The cost impact? You set your timeout higher to absorb cold starts. You provision concurrency to reduce them (which costs extra). Or you just accept the p99 hit and your on-call engineer gets paged at 2am on a Monday.
On EKS, the "cold start" is the pod scheduling time: 10-30 seconds. But you mitigate it with a pod disruption budget, horizontal pod autoscaler with a warm pool, and (critically) node autoscaling that pre-warms capacity. The first request after scale-up is slow. Every subsequent request for that pod is fast.
We built a simple monitoring dashboard at SIVARO that tracks the ratio of cold-start invocations to total invocations. For our client's fraud detection service, that ratio was 34% on Lambda, 0.3% on the EKS warm pool. That 34% was costing us roughly $1,200/month in additional provisioned concurrency that we didn't need if we'd just kept two pods warm.
When containers eat serverless for breakfast
Most people think containers are always more expensive. They're wrong, and here's why.
If your service has sustained load above ~40% duty cycle (meaning the compute is busy 40% of the time or more), the per-second billing on serverless stops being an advantage. You're paying per invocation AND per second, and the per-second component starts to dwarf the per-invocation component.
yaml
# EKS pod spec for sustained ML inference workload
# This pod runs 22 hours/day with 78% utilization
# Cost: $0.4468/vCPU-hr (a1.4xlarge) + $0.04851/GB-hr memory
# 4 vCPUs, 16GB RAM, A10G GPU
apiVersion: apps/v1
kind: Deployment
metadata:
name: fraud-model-inference
namespace: ml-production
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 0 # keep serving during deploys
selector:
matchLabels:
app: fraud-model
template:
metadata:
labels:
app: fraud-model
tier: inference
spec:
containers:
- name: model-server
image: sivarocorp/fraud-transformer:2.4.1
resources:
requests:
cpu: "4"
memory: "16Gi"
nvidia.com/gpu: "1"
limits:
cpu: "4"
memory: "16Gi"
nvidia.com/gpu: "1"
env:
- name: MODEL_PATH
value: "/models/fraud_v2.4.onnx"
- name: INFERENCE_TIMEOUT_MS
value: "400"
readinessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 15
periodSeconds: 5
At 78% sustained utilization, this pod costs the same as (or less than) a Lambda handling the same traffic at 120ms average + 340ms GPU inference. The container is amortizing its fixed cost across more requests. The Lambda is paying a per-request tax on every single one.
I've seen this flip at around 35-45% utilization depending on the workload. Below that, serverless wins. Above it, containers win. Measure your actual utilization before you decide. Don't guess.
Mapping this to the AWS Well-Architected Framework cost optimization pillar
Here's where this gets interesting for the person who has to justify their architecture to a non-technical stakeholder.
The AWS Well-Architected Framework cost optimization pillar has four key questions. Let me map our serverless vs containers cost comparison onto them directly, because I've lost three client engagements to architects who couldn't answer these:
Am I using cost-effective resources? For the fintech fraud service, the answer was "no, not on the feature-retrieval layer." Moving that to Lambda saved $4,300/month without touching the ML inference path. We tagged every resource with a cost-owner label and ran a monthly CUR analysis. Took one afternoon to implement. Saved us from a $20K/month overage we wouldn't have caught until quarter-end.
Do I understand where I'm spending money? We built a Lambda function (ironic, I know) that ingested CUR data and flagged any resource where monthly spend exceeded 80% of its projected annual budget prorated. Alerted to Slack. The serverless function cost $0.003/month. The visibility it gave us was worth 100x that.
Am I using the right purchase options? For our EKS cluster, we shifted 60% of nodes to 1-year Reserved Instances in February 2026. Saved 31% on compute. The remaining 40% stayed on-demand to handle spike traffic. The serverless layer needed no reservation strategy — it's inherently pay-as-you-go.
Do I have a cost management process in place? This is the one that's not about the technology. It's about who looks at the bill, who has authority to say "let's move this workload," and how often you re-evaluate. We do a quarterly architecture cost review. Thirty minutes. Whiteboard. Two engineers and an engineer-who-is-not-the-founder. Catches drift before it becomes a March 2026 surprise.
hcl
# Terraform: cost-optimization guardrails we deploy to every client account
# Tags everything, enables CUR, sets budget alerts
resource "aws_budgets_budget" "ml_cluster" {
name = "ml-eks-cluster"
budget = 15000 # monthly soft cap
time_unit = "MONTHLY"
notification {
comparison_operator = "GREATER_THAN"
notification_type = "ACTUAL"
percentage = 80
}
}
resource "aws_cost_and_usage_report" "detailed" {
report_name = "sivarocorp-detailed-cur"
report_format = "TEXTORCSV"
time_grain = "DAILY"
data_refresh_freq = "DAILY"
included_accounts = ["*"]
compression = "GZIP"
}
# Tag policy: every resource MUST have cost-owner and project tags
resource "aws_organizations_organizational_unit" "cost-tagging" {
# Enforced via SCP: no resource without cost-owner tag can be created
}
The cost optimization pillar isn't a one-time audit. It's a rhythm. The serverless vs containers cost comparison you do in January will be wrong by June because your traffic shape changed, your model got bigger, or AWS shifted a price point. Re-run the math quarterly. Put it in the calendar.
The hybrid answer (most people won't like this)
I'll take a position here and I'll let you disagree.
The "serverless vs containers" framing is mostly a false binary for anything beyond the simplest workloads. The actual question is "which layer of my system should be stateless-and-bursty (serverless) and which should be stateful-and-sustained (containers)."
For a typical ML product in 2026, that looks like:
- Data ingestion / event processing: Serverless (Lambda, EventBridge). Spiky, low-compute-per-event, scales to zero overnight.
- Feature store / vector DB access: Serverless. Short read/write, no persistent state needed in the function.
- Model inference (GPU): Containers (EKS, GKE, or Fargate if you want the middle ground). Sustained load, expensive compute, cold-start matters.
- Orchestration / workflow: Serverless (Step Functions, or a lightweight containerized Airflow). Low sustained load, complex state management.
- Batch retraining: Containers. Long-running, resource-heavy, doesn't care about per-second billing.
We deployed this pattern for a logistics client in July 2026. Total monthly infrastructure cost: $22,400. If we'd run everything on EKS: $41,000. If we'd run everything on serverless (where possible): $36,000. The hybrid was 45% cheaper than the all-containers approach and 38% cheaper than the all-serverless approach.
The math isn't complicated. The organizational willingness to maintain two deployment pipelines, two monitoring stacks, and two scaling policies — that's the real cost. Budget for it. Budget the engineer time to keep both running.
FAQ
Is serverless always cheaper than containers?
No. It's cheaper when your average request is short (<800ms), your memory footprint is modest (<1GB), and your traffic is spiky. Once you cross into sustained GPU workloads or long-running batch jobs, containers get cheaper per unit of work. I've seen Lambda bills hit $40K/month for workloads that would cost $9K on EKS. The inverse is rarer but real: a Lambda with provisioned concurrency set to 500 "just in case" costs $14K/month while doing 200 requests/hour.
What's the break-even utilization for EKS vs Lambda in 2026?
In our testing with t3.medium-equivalent workloads, the break-even sits at roughly 40-45% sustained CPU utilization. Below that, Lambda's per-request pricing wins. Above it, the pod's amortized cost per request drops below Lambda's per-invocation + per-second pricing. GPU workloads shift this lower, to about 25-30%, because the GPU is expensive and you want it busy.
Does the cold start problem make serverless unusable for ML?
Not for batch or async ML workloads. If your user is waiting 30 seconds for a report, a 4-second cold start is 13% overhead. Acceptable. If your user is waiting 200ms for a real-time fraud decision, a 4-second cold start is a product failure. Use provisioned concurrency, warm pools, or just use containers. There's no shame in that.
How do I structure this decision for a CTO or VP of Engineering?
Frame it in the AWS Well-Architected cost optimization language. Show them the per-workload cost breakdown. Show the utilization data. Show the 12-month projection for both options including the engineering overhead of maintaining two stacks. Give them a recommendation with a confidence level. "I'm 80% confident the hybrid is right for Q3-Q4. By Q1 2027, if traffic doubles, we should re-evaluate and likely consolidate to EKS." They want a number, a timeline, and an exit strategy.
Can I use AWS Fargate as a middle ground?
Yes, and we do for clients who want container semantics without managing nodes. Fargate gives you per-task billing (vCPU-hours + GB-hours) with no node management. It's more expensive than Lambda for spiky workloads but much cheaper than EKS for low-volume containerized services. If your container workload is under 500 requests/minute sustained, Fargate is usually the cheapest option. Above that, EKS with right-sized nodes wins.
What about Kubernetes on-prem vs managed?
If you're already running a K8s cluster on-prem (or on EC2), the marginal cost of adding a containerized ML workload is your compute and storage. No control plane fee. No per-request tax. For workloads with sustained GPU demand above 60% utilization, on-prem K8s with a mix of on-demand and reserved GPU instances was the cheapest option we tested for a manufacturing client in 2025. But you need a platform team to keep it healthy. If you don't have one, managed K8s (EKS, GKE, AKS) is worth the premium.
How often should I re-run this cost comparison?
Quarterly, minimum. Your traffic shape changes. Model sizes grow. AWS changes pricing (they changed Lambda memory pricing in 2025, which shifted break-even points for everyone). New instance types launch. A comparison that was valid in January 2026 might be wrong by April. Build the comparison into your quarterly architecture review. Make it a 30-minute exercise with two people and a spreadsheet.
What about the engineering cost of maintaining both serverless and containerized stacks?
I'll be honest: it's real, and it's not small. Two deployment pipelines, two CI/CD paths, two monitoring dashboards, two sets of IAM roles, two on-call runbooks. At SIVARO, we budget roughly 15% additional engineering time for dual-stack maintenance. If your team is under 5 engineers, I'd strongly recommend picking one paradigm and sticking with it. The infrastructure savings won't offset the cognitive tax on a small team.
The number that matters
Here's what I tell every client who asks me "should we go serverless or containers?"
Pull your last 90 days of actual traffic. Plot the request rate, the average processing time, and the p95 latency. Calculate your sustained utilization. Then run the cost model — it's 20 lines of Python, you don't need a framework.
The serverless vs containers cost comparison isn't a philosophy. It's arithmetic. And the arithmetic changes every time your model gets bigger, your traffic spikes, or someone "simplifies" your architecture in a ticket that gets merged without a cost impact analysis.
Run the numbers. Quarterly. Put it in the calendar. And for the love of everything, tag your resources so you can actually see where the money's going.
Nishaant Dixit — Founder of SIVARO. Building data infrastructure and production AI systems since 2018. Built systems processing 200K events/sec.