How Channel Rocket cut its infrastructure run rate by about 86% by Muhammad HaseebHow Channel Rocket cut its infrastructure run rate by about 86% by Muhammad Haseeb
How Channel Rocket cut its infrastructure run rate by about 86%
Greg, the CEO of Channel Rocket, first hired me to oversee an existing development team. My job was to turn business requirements into product decisions, coordinate delivery, and make sure the technical work supported what the company actually needed.
Over time, my team took over the full product delivery. I became responsible for product management, hands-on product development, team leadership, deployments, cloud infrastructure, and contributing to design decisions.
One problem was impossible to ignore: infrastructure cost.
Channel Rocket's AWS bill was about $4,000 in July. The product was working, but the infrastructure had grown beyond what its current workloads required. There were oversized services, resources that were no longer used, and heavy workloads running on AWS services that were more expensive than necessary.
The goal was simple to state but risky to execute: reduce the recurring cost without removing features or making the product less reliable.
What we changed
We started by mapping the active resources, costs, and dependencies. That let us separate necessary production infrastructure from capacity and resources the product was no longer using.
Then my team and I worked through the changes in stages:
Removed orphaned infrastructure resources
Downsized services that were larger than the current workload required
Removed unused load balancers and stale snapshots
Consolidated NAT infrastructure
Moved heavy workloads from EKS and Fargate to a Vultr VPS
Rightsized the AWS services that remained
Added billing alerts so unexpected changes would show up early
This was not a blind move away from AWS. We kept AWS where it made sense and moved workloads that did not need its more expensive execution model. The result was a smaller, more deliberate production stack.
Unused resources were removed, remaining services were rightsized, and heavy EKS and Fargate workloads were moved to Vultr while AWS remained in use where it fit.
The result
The cost changed in stages:
July: about $4,000 in AWS spend
August: $2,885 in AWS spend
Current AWS run rate: about $400 per month, based on a stable daily cost of roughly $14
Current Vultr cost: about $150 per month
Current combined run rate: about $550 per month
Comparing the July AWS baseline with the current combined AWS and Vultr run rate, the infrastructure cost is now approximately 86% lower.
The comparison includes the cost moved to Vultr. It is not an AWS-only saving that hides spend on another provider.
AWS spend through September 7 was $202, but that is a partial-period figure, not a monthly bill. The more useful current estimate is the combined run rate of about $550 per month.
The product kept the same stated features and quality throughout the optimization. We tested during the migration, completed the planned phases, and had no unplanned customer-facing outage. One controlled late-Sunday maintenance window of approximately 30 minutes was used during the work.
AWS Cost Explorer shows the staged reduction. The current ~$550/month estimate includes both AWS and Vultr; September 1–7 AWS spend of $202 is a partial-period figure.
My role
I led this work as the product manager and technical owner working with my team. My responsibilities included:
Translating business requirements into implementation work
Managing the development team and delivery priorities
Building parts of the product directly
Coordinating deployments and migration work
Managing the cloud infrastructure
Contributing to product and design decisions
This was a team result. Greg hired me to oversee the existing developers, and my team later took over the product as the engagement expanded.
Why this worked
The biggest saving did not come from one clever setting. It came from understanding what the product actually needed, removing accumulated overhead, and choosing the right environment for each workload.
That is the same approach I use when a SaaS product is technically functional but unnecessarily expensive to operate: trace where the money is going, protect the workloads that matter, make reversible changes first, and verify the product as each change goes live.
If your SaaS product works but the cloud bill no longer makes sense, I can audit the infrastructure, find the expensive mismatches, and lead a safer path to a leaner operating model.
Project details
Client: Channel Rocket
Product: Partner and reseller program platform
Role: Product Manager, Product Developer, Team Lead and Cloud Manager
Infrastructure: AWS, EKS, Fargate and Vultr
Focus: Cloud cost optimization, workload migration, production stability and product delivery