Cloud Cost Optimization: 20 Practical Techniques

Cloud cost optimization is the practice of paying only for the capacity your workloads use, at the best rate the vendor offers for the way you use it. Most bills contain the same leaks: servers sized for a peak that never comes, non-production environments running all weekend, disks and IP addresses nobody owns, on-demand rates on workloads that have run unchanged for a year, and storage, logging and data transfer that grow quietly. The twenty techniques below fix those on Azure and AWS, grouped so you can work through them in order, followed by the monthly FinOps routine that stops the bill from drifting back.

Where money leaks

Cloud waste is rarely one big mistake. It is a few dozen small defaults left in place after a migration or a launch. The usual sources, in rough order of size:

• Over-provisioning. Lift-and-shift copies the old server’s size, which was itself sized for a hardware refresh cycle, not for actual load.
• Always-on non-production. Development, test and staging environments billed for 168 hours a week and used for 50.
• Orphans. Disks detached when a VM was deleted, public IPs released from nothing, snapshots from a migration two years ago, load balancers with no backends.
• On-demand pricing for steady work. A database server that has run every hour since go-live, still billed at the list rate.
• Storage growth. Backups retained forever, logs ingested at debug level, hot-tier storage holding files nobody has opened since the migration.
• Data transfer. Chatty traffic between regions or zones, through NAT gateways, or out to the internet without a CDN.
• No owner. Resources without tags, so nobody sees the line on the bill and nobody is asked about it.

Cloud cost management starts with visibility: Azure Cost Management and Advisor, AWS Cost Explorer, Compute Optimizer and Trusted Advisor all show the leaks for free. The work is in acting on them.

The 20 cloud cost optimization techniques, grouped

Compute

1. Right-size virtual machines. Compare CPU, memory, disk and network utilization over a few weeks against the instance size. Azure Advisor and AWS Compute Optimizer produce the recommendations; the change is usually one size down or a lower-cost family of the same generation. Do this before buying any commitment, or you lock in the oversized footprint.
2. Schedule non-production. Shut down development, test and training environments outside working hours with Azure auto-shutdown, Azure Automation or the AWS Instance Scheduler. An environment that runs business hours on weekdays costs less than a third of one that never sleeps.
3. Delete idle and orphaned resources. Stopped VMs still allocated, unattached managed disks and EBS volumes, unused public IPs, idle load balancers, empty resource groups, old snapshots and AMIs. Run the inventory monthly and delete with a short grace period.
4. Commit to reservations and savings plans. For workloads that have run unchanged for months, buy Azure reservations or a savings plan for compute, or AWS Reserved Instances or Savings Plans, for one or three years. Both vendors publish steep discounts for commitment; the right coverage is the steady-state floor of usage, not the peak.
5. Use Spot capacity for interruptible work. Batch processing, CI build agents, rendering, data-pipeline workers and disposable test environments run on Azure Spot VMs or AWS Spot Instances at a fraction of on-demand rates, provided the job can be interrupted and restarted.
6. Bring your own licenses. Azure Hybrid Benefit applies existing Windows Server and SQL Server licenses with Software Assurance to Azure VMs and Azure SQL; AWS offers license-included and bring-your-own-license options. Also check the dev/test pricing offers both vendors provide for non-production subscriptions.

Storage and data

7. Tier storage with lifecycle policies. Move blobs and objects from hot to cool, cold and archive tiers (Azure) or from S3 Standard to Infrequent Access and Glacier classes (AWS) automatically, based on last access or age. Mind the retrieval and early-deletion charges on the cold tiers.
8. Right-size disks and disk types. High-performance SSD disks on servers that do not need the IOPS, io1 volumes where gp3 would do, and disks provisioned at the size of the old SAN LUN rather than the data. Resize, change type, and delete snapshots older than the retention policy.
9. Match backup retention and redundancy to policy. Daily backups kept for years, geo-redundant storage on data that has no recovery requirement, and duplicate backup tools all add up. Set retention per data class and pick locally or zone-redundant storage where the recovery plan allows it.
10. Right-size databases. Use the Azure SQL serverless tier with auto-pause for databases that sit idle, elastic pools for many small databases, and a lower vCore count where the DTU history shows headroom. On AWS, move dev databases to smaller RDS classes or stop them out of hours, and consider Aurora Serverless for spiky workloads. Reserved capacity covers the production floor.

Network and observability

11. Cut data-transfer charges. Keep tightly coupled services in the same region and availability zone, use private endpoints instead of routing through public addresses, remove cross-region replication nobody asked for, and serve static content through a CDN. NAT gateway data-processing charges deserve their own line in the review.
12. Trim logging and monitoring ingestion. Log Analytics and CloudWatch bill per gigabyte ingested and retained. Set daily caps and retention periods, use the lower-cost log tiers for data you keep but rarely query, enable sampling in Application Insights, and stop sending debug-level logs from production.
13. Consolidate high-cost network components. Firewalls, application gateways, NAT gateways and VPN gateways are billed per hour whether or not traffic flows. One shared hub for all non-production environments, instead of a firewall per environment, removes several of them.
14. Remove duplicate environments. Two staging environments from two teams, a “temporary” performance-test copy from last year, a disaster-recovery environment running hot when warm would meet the recovery objective. Each is a full bill.

Architecture and platform

15. Move to managed and serverless services where they fit. A VM running a single web application costs the same at 3 a.m. as at noon; App Service, Azure Container Apps, AWS Fargate, Functions and Lambda bill closer to actual use and remove the patching work. This is the replatform option in a cloud migration strategy.
16. Autoscale, including to zero. VM scale sets and Auto Scaling groups for the web tier, KEDA or the horizontal pod autoscaler for containers, and minimum replica counts of zero on Container Apps for services that are idle most of the day.
17. Right-size Kubernetes. Set CPU and memory requests from measured use rather than guesses, enable the cluster autoscaler or Karpenter so nodes follow pods, add a Spot node pool for tolerant workloads, and remove idle namespaces. A small cluster with three services often costs less as Container Apps or ECS.

Governance and FinOps

18. Tag everything and allocate cost. Owner, cost center, environment and application on every resource, enforced with Azure Policy or AWS tag policies so untagged resources cannot be created. Showback reports per team turn the bill into something people act on.
19. Set budgets, alerts and anomaly detection. Azure Cost Management budgets and AWS Budgets per subscription, account or team, with alerts at thresholds and on forecast, plus AWS Cost Anomaly Detection or Azure’s anomaly alerts for the surprise that appears mid-month.
20. Review commitments and pricing every quarter. Reservation utilization and coverage, reservations about to expire, newer instance generations that cost less for the same work, regional price differences for workloads that could move, and enterprise agreement renewals.

The FinOps routine

FinOps is the operating practice behind all twenty techniques: engineering, finance and the business sharing responsibility for cloud spend, with timely data and a regular cadence. The FinOps Foundation describes it as a loop of inform, optimize and operate. In practice it looks like this:

Cadence	Who	What
Weekly	Platform or DevOps lead	Check anomaly alerts, new untagged resources, and spend against forecast
Monthly	Engineering leads and finance	Cost review by team and application: right-sizing recommendations, idle resources, storage growth, unit cost per customer or transaction
Quarterly	Architecture and finance	Commitment coverage and renewals, architecture changes worth funding, pricing changes, budget reset
Per release	Development team	Cost impact of new services in the design review; cost estimate in the pull request for infrastructure changes

Azure cost optimization and AWS cost optimization use different consoles but the same routine. Export billing data to a warehouse or Power BI once the estate is large enough that the console views are not enough, and define two or three unit metrics (cost per active customer, per order, per environment) so the conversation is about efficiency rather than the total. Pipeline changes that add infrastructure should carry a cost estimate in the review, which is one reason to put infrastructure in code through a DevOps pipeline.

Where PS3G fits

PS3G offers cloud optimization services as a one-time review and as part of managed cloud. The review works through the twenty techniques against your bill and your architecture and delivers a prioritized list with the savings mechanism for each, which you can implement yourself or have us implement. Under managed services the FinOps routine above runs every month as part of operating the environment. Both sit inside our cloud consulting practice, which covers Azure, AWS and Google Cloud for organizations of every size, and we are not a reseller of any of them, so a recommendation to spend less is never in conflict with our own margin.

Related reading

• Cloud Migration Strategy: The 6 Rs Explained with Examples
• What Is a DevOps Pipeline? Stages, Tools and a Starter Setup
• Cloud consulting and cloud solutions from PS3G

Frequently asked questions

What is cloud cost optimization?

Cloud cost optimization is the ongoing work of matching what you pay for cloud services to what your workloads use: sizing resources from measured load, turning off what is idle, choosing the right storage and database tiers, using commitment discounts for steady workloads, and fixing architecture patterns that generate data-transfer or logging charges. It pairs with governance (tags, budgets, reviews) so the savings last.

What is FinOps?

FinOps is an operating practice, described by the FinOps Foundation, in which engineering, finance and business teams share accountability for cloud spend. It relies on timely cost data allocated to owners, a cadence of reviews, and decisions based on business value rather than the lowest possible bill. The three phases are inform (visibility and allocation), optimize (rates and usage) and operate (the routine that keeps it going).

Should we buy reservations or savings plans?

Buy them for the usage you are sure will continue, after right-sizing. Reservations give the largest discount for a specific instance family or database tier; savings plans give a smaller discount with more flexibility across sizes, families and services. Many estates use both: reservations for databases and other fixed components, a savings plan for the compute floor, and on-demand or Spot for everything variable.

How much can cloud cost optimization save?

It depends on how the estate was built. A lift-and-shift migration that was never revisited usually has the most room, because every server is still its old size and billed on demand. A well-run platform has less, and the work shifts to architecture and unit cost. A first review tells you which case you are in within days, and the savings from idle resources and scheduling arrive immediately.

How often should we review cloud costs?

Weekly for anomalies, monthly for right-sizing and idle resources, quarterly for commitments and architecture. The monthly review is the one that matters most and the one most often skipped. Put it on the calendar with a named owner, feed it with tagged cost data, and keep a running list of actions with dates, so each review starts from the last one.