AWS vs Azure Cost Optimization: Kubernetes FinOps Case Study

 

Introduction: Why Kubernetes Costs Can Grow Quickly

Kubernetes makes applications scalable and resilient, but it does not automatically make cloud infrastructure cost-efficient.

Over-provisioned CPU and memory, idle nodes, inefficient pod placement, conservative autoscaling, and excessive On-Demand capacity can significantly increase monthly cloud bills.

This is where Kubernetes FinOps becomes important. FinOps combines financial accountability with cloud engineering to continuously match infrastructure capacity with actual workload demand.

In this case study, we compare AWS EKS vs Azure AKS pricing and demonstrate how Kubernetes right-sizing, autoscaling, workload placement, and optimized compute purchasing produced a modeled 38% reduction in combined Kubernetes spending.

Key Takeaway: The biggest Kubernetes savings usually come from eliminating unused capacity not simply choosing the cloud provider with the cheaper control plane.

AWS EKS vs Azure AKS: What Drives Kubernetes Cost?

When organizations compare AWS vs Azure cost optimization, they often focus on Kubernetes control-plane pricing.

However, the total Kubernetes bill can include:

• Worker-node or VM compute
• Kubernetes control plane
• Persistent storage
• Load balancers
• NAT gateways
• Data transfer
• Monitoring and logging
• Backup and disaster recovery
• Cloud support
• DevOps operations

For most production environments, compute utilization, autoscaling efficiency, and purchasing strategy can have a much greater impact than the control-plane fee alone.

Cost Factor	AWS EKS	Azure AKS
Control plane	Paid per cluster	Free tier available
Worker compute	Amazon EC2	Azure VMs
Discounted compute	Savings Plans, Reservations, Spot	Reservations, Savings Plan, Spot
Autoscaling	HPA, Cluster Autoscaler, Karpenter	HPA, Cluster Autoscaler, KEDA
Storage	Amazon EBS	Azure Managed Disks
Networking	VPC, NAT, load balancers	VNet, NAT, load balancers

The most cost-effective platform depends on workload architecture, region, existing commitments, networking requirements, and operational needs.

EKS and AKS Pricing: What FinOps Teams Should Know

Amazon EKS currently charges $0.10 per cluster per hour during standard Kubernetes version support, which is approximately $73/month using a 730-hour month.

When an EKS cluster enters extended support, the charge increases to $0.60/hour, or approximately $438/month.

That makes Kubernetes version lifecycle management an important part of EKS cost optimization.

Azure AKS provides a Free tier without an AKS management fee, while Standard and Premium tiers provide additional production capabilities and service-level options.

However, a free or lower-cost control plane does not mean the entire Kubernetes environment is inexpensive. Worker compute, networking, storage, and monitoring can still dominate the bill.

The Case Study: Three-Node Production Kubernetes Cluster

A SaaS company was running equivalent production environments on AWS EKS and Azure AKS.

Each environment contained:

• 3 worker nodes
• 4 vCPU and 16 GB RAM per node
• 1 load balancer
• 1 NAT gateway
• 100 GB persistent storage

Before optimization, average utilization was only:

• 35% CPU
• 42% memory

All workloads were running on On-Demand capacity, and nodes remained active even after traffic spikes disappeared.

Several applications were also requesting significantly more CPU and memory than they actually consumed.

Kubernetes Cost Optimization Strategy

1. Right-Size CPU and Memory

The team analyzed two weeks of Prometheus, CloudWatch, and Azure Monitor data.

They reviewed:

• CPU and memory utilization
• p95/p99 usage
• CPU throttling
• OOMKills
• Pod restarts
• Application latency
• Traffic patterns

One service requested 2 vCPU but typically consumed only 0.4 vCPU.

That represented approximately 5× more CPU capacity requested than typically used.

The team adjusted resource requests based on historical usage while maintaining sufficient headroom for traffic spikes.

Pro Tip

Do not right-size using average utilization alone. Compare p50, p95, p99, peak usage, and SLO impact before changing production workloads.

2. Use Mixed Compute Capacity

The environment originally used On-Demand capacity for everything.

The team divided workloads into three categories:

Capacity	Suitable Workloads
Committed	Predictable baseline workloads
On-Demand	Critical or highly variable workloads
Spot	Fault-tolerant workloads

AWS EC2 Spot can provide discounts of up to 90% compared with On-Demand pricing for suitable workloads.

Good Spot candidates include:

• Stateless services
• CI/CD runners
• Batch jobs
• Background workers
• Data processing
• Development and testing

Stateful workloads require additional planning, including replication, persistent storage, graceful shutdown, and failover.

3. Improve Kubernetes Autoscaling

The team tuned the Horizontal Pod Autoscaler and node autoscaling configuration.

The HPA target was adjusted from approximately 80% CPU toward 60%, based on observed workload behavior.

Node autoscaling was enabled so that unused nodes could be removed during off-peak periods.

The objective was not simply to scale aggressively.

It was to:

Scale up quickly enough to meet demand and scale down quickly enough to avoid paying for idle capacity.

CPU is not always the best scaling metric. Applications driven by queue depth, Kafka lag, requests per second, or memory may benefit from custom metrics or tools such as KEDA.

4. Improve Kubernetes Bin-Packing

The team also reviewed pod placement and node utilization.

Poorly configured resource requests, anti-affinity rules, topology constraints, and DaemonSets can leave multiple nodes partially empty.

After right-sizing requests and improving workload placement, fewer nodes could accommodate the same workloads.

Better Kubernetes resource optimization therefore reduces the amount of infrastructure that needs to remain active.

Case Study Results

The following figures represent the modeled scenario described in this article and are not guaranteed savings for every Kubernetes environment.

Metric	Before	After	Improvement
Average CPU utilization	35%	68%	~94% relative improvement
EKS compute spend	Baseline	-41%	41% reduction
AKS compute spend	Baseline	-37%	37% reduction
Off-peak node count	Static	-55%	55% reduction
P99 latency	Baseline	No regression	SLO maintained
Combined Kubernetes spend	Baseline	-38%	38% reduction

The 38% blended reduction came from several improvements rather than a single optimization.

Best Practices for Kubernetes FinOps

For an effective Kubernetes cost optimization strategy:

Resource Management

• Set requests using historical utilization.
• Monitor CPU throttling and OOMKills.
• Review resource requests regularly.
• Remove unused workloads and environments.

Autoscaling

• Use HPA for pod scaling.
• Use Cluster Autoscaler or an equivalent node-provisioning solution.
• Consider KEDA for event-driven workloads.
• Use custom metrics where CPU is not representative of demand.

Compute Purchasing

• Use committed discounts for predictable baseline workloads.
• Use Spot for fault-tolerant workloads.
• Maintain stable capacity for critical applications.
• Reassess commitments as workloads change.

Governance

• Track costs by application, namespace, team, and environment.
• Set cloud budgets and anomaly alerts.
• Review Kubernetes versions before entering expensive support periods.
• Conduct monthly or quarterly FinOps reviews.

Common Kubernetes Cost Optimization Mistakes

Reducing Requests Too Aggressively

Lowering requests can improve utilization, but excessive reductions can cause throttling, OOMKills, latency increases, and instability.

Using Spot for Unsuitable Workloads

Spot is excellent for interruptible workloads but requires proper architecture and recovery mechanisms for production use.

Scaling Only on CPU

CPU may not reflect application demand. Queue depth, memory, traffic volume, and application metrics may provide better scaling signals.

Treating FinOps as a One-Time Audit

Cloud workloads continuously change. A workload that requires 10 nodes today may require 20 nodes next year.

FinOps should be continuous.

AWS vs Azure: Which Is Cheaper for Kubernetes?

There is no universal winner.

AWS can be attractive when organizations can effectively use EC2 Spot, Savings Plans, Karpenter, and existing AWS commitments.

Azure can be attractive for organizations with existing Azure infrastructure, Microsoft licensing agreements, Reservations, Azure Savings Plans, and Microsoft-focused workloads.

Therefore, an effective EKS vs AKS cost comparison should consider the entire infrastructure stack rather than control-plane pricing alone.

Conclusion: Make Kubernetes Cost Optimization Continuous

The AWS vs Azure cost optimization debate should not focus only on control-plane pricing.

The largest savings often come from:

• Right-sizing CPU and memory
• Improving pod placement
• Autoscaling nodes and workloads
• Using Spot capacity appropriately
• Applying committed-use discounts
• Removing idle infrastructure
• Monitoring costs continuously

In this case-study scenario, these techniques produced a 38% blended reduction in Kubernetes spending without measurable regression in the stated performance target.

The key principle is simple:

Do not just buy cheaper computers. First optimize how much compute your workloads actually need.

Optimize Your Kubernetes Cloud Costs with Geeks Solutions

Geeks Solutions helps organizations optimize AWS and Azure Kubernetes environments through cloud, DevOps, infrastructure, and Kubernetes expertise.

A Kubernetes cost optimization audit can identify:

• Over-provisioned resources
• Underutilized nodes
• Inefficient autoscaling
• Spot opportunities
• Unnecessary infrastructure
• EKS and AKS cost drivers

If your Kubernetes bill is growing faster than your application traffic, a structured cost audit can help identify where the waste is coming from and which optimizations deserve priority.

Talk to the Geeks Solutions Cloud & DevOps team about a Kubernetes cost audit →

Frequently Asked Questions