FinOps Implementation
This is the part most of the FinOps industry doesn’t sell. Dashboards find the waste. Reports document it. Tickets get filed. Somebody still has to make the change, and that somebody is usually an engineer measured on features rather than on your bill.
Below is what actually gets changed. It is deliberately specific, because the vague version of this page is what everybody else publishes.
Where the money usually is
Cost problems are common after a lift-and-shift migration, where an oversized, mostly idle environment replicates the old on-prem setup at higher operating cost. Teams in that position get the drawbacks of the cloud without the benefits, and sometimes conclude the problem is their provider rather than the shape of their footprint.
Just as often the environment is already modern and reasonably well run, and what is left needs someone who will go instance by instance rather than another tool that summarizes.
Compute, containers and managed services
EC2, Lambda, EKS, ECS, Fargate and EMR, plus the managed services that expose the underlying instances: RDS, ElastiCache and OpenSearch.
Typical work: instance type selection matched to the workload, right-sizing, elasticity and autoscaling, adopting Spot, migrating to Graviton, and sizing Savings Plans and reserved capacity against the footprint you’ll actually run rather than the one you happen to run today.
Storage
S3 storage class selection, lifecycle policies and VPC endpoints. EBS volumes attached to instances and to managed services such as RDS: volume type per workload, right-sizing, and provisioned IOPS and throughput matched to real usage. Unattached volumes and stale snapshots removed.
This is where a lot of the money hides, and it’s also the part no Savings Plan or Reserved Instance will ever cover. Storage, logging and networking only get cheaper when somebody changes something.
Networking and delivery
Inter-AZ traffic, VPC endpoints and PrivateLink. For CloudFront, cache ratio improvements, and Lambda@Edge where it’s configured to cut the traffic and load reaching your origin. Done carelessly it does the opposite, since viewer-request functions run before the cache lookup and cache-key changes can drop the hit ratio.
Performance, not just cost
Plenty of this work makes things faster as well as cheaper. Moving to Graviton, adding VPC endpoints, cutting cross-AZ traffic and improving cache ratios all tend to show up as better performance, not only a smaller bill.
Commitments and pricing agreements
We can also help negotiate Enterprise Discount Program deals and private pricing at scale. We size commitments after the optimization work rather than before it, so you don’t lock in years of paying for resources we would otherwise have removed.
How the changes land
Changes are low risk by selection and reversible, with a rollback defined per change. Where a change is genuinely destructive, such as deleting stale snapshots or unattached volumes, we agree the retention rule and get explicit sign-off before anything is removed. Anything touching a repository goes through your own review. No AI agents are turned loose on your production account: analysis is AI-assisted, every production change is manual and verified.
Please contact us if this sounds interesting or you have any questions.