How Savings Are Calculated
Servyx analyzes your infrastructure across multiple dimensions to find optimization opportunities. Here is how we identify waste and calculate potential savings.
The Optimization Engine
Engine
AI analysis
Savings
Prioritized with $
When you sync an AWS account, Servyx collects resource configurations, performance metrics, and cost data. Our optimization engine then evaluates every resource against a set of rules that detect common patterns of waste.
Each finding includes an estimated monthly savings amount based on current pricing data and your actual usage patterns.
Optimization Categories
Idle Detection
We identify resources that are running but doing effectively nothing. Examples:
- EC2 instances with sustained CPU utilization below a meaningful threshold
- RDS databases with near-zero connections over an extended period
- Load balancers receiving no traffic
- NAT Gateways with negligible data processing
Savings are calculated as the full cost of the resource, since idle resources can typically be terminated.
Right-Sizing
Right-sizing finds resources that are significantly over-provisioned for their actual workload. We compare:
- Provisioned capacity (vCPUs, memory, network bandwidth)
- Actual utilization from CloudWatch metrics
- Workload patterns over time
When we find a resource consistently using only a fraction of its capacity, we recommend a smaller instance type that still provides comfortable headroom. Savings are the price difference between the current and recommended type.
Scheduling
Many non-production environments run 24/7 but are only used during business hours. Servyx detects:
- Instances tagged as development, staging, QA, or test environments
- Resources with usage patterns concentrated in specific hours
- Environments that could be shut down nights and weekends
Savings are calculated based on the hours the resource could be stopped. Running an environment only during business hours (roughly 50 hours per week vs. 168) can reduce its cost by up to 70%.
Architecture
Architectural findings identify resources that are wasting money due to how they are configured:
- Orphaned EBS volumes -- Volumes not attached to any instance, still incurring storage costs
- Unused Elastic IPs -- Allocated but unattached IPs (AWS charges for these)
- Old EBS snapshots -- Snapshots that have been accumulating for months with no lifecycle policy
- Unattached load balancers -- Load balancers with no healthy targets
Savings are the direct cost of the unused resource.
Commitment Gaps
AWS offers significant discounts through Reserved Instances and Savings Plans, but many teams either under-commit or let commitments expire. Servyx analyzes:
- Current Reserved Instance and Savings Plans coverage
- Workloads with stable, predictable usage that would benefit from commitments
- Expiring commitments that should be renewed
Savings are estimated as the discount percentage (typically 30-60%) applied to the qualifying on-demand spend.
Kubernetes Over-Provisioning
For connected Kubernetes clusters, Servyx compares:
- Pod resource requests (CPU and memory) vs. actual utilization
- Node capacity vs. total scheduled requests
- Namespace-level resource consumption
When pods are requesting significantly more resources than they use, your nodes are carrying unnecessary capacity. Savings come from reducing requests to match actual usage, which can allow you to run fewer or smaller nodes.
How Estimates Are Calculated
All savings estimates are based on:
- Current AWS pricing -- We use the AWS Pricing API to get up-to-date on-demand rates for your region
- Your actual usage -- Not theoretical benchmarks, but real CloudWatch metrics from your account
- Conservative assumptions -- We recommend changes that leave headroom for traffic spikes and growth
- Monthly projection -- All savings are expressed as monthly amounts for easy comparison
Confidence and Accuracy
Not all findings carry the same weight. A resource running at 2% CPU for 30 days is a much stronger signal than one at 15% for 3 days. Servyx factors in:
- Duration of the observed pattern
- Consistency of the signal (sustained vs. intermittent)
- Resource type and typical usage patterns
- Risk of the recommended change
We aim to give you recommendations you can act on with confidence, not a long list of theoretical optimizations.