Cloud Cost Optimisation: Controlling Your AWS, Azure and GCP Bill

The pay-as-you-go model that makes cloud computing attractive is also what makes it dangerous. Unlike a capital expenditure on physical hardware where the cost is fixed at purchase, cloud spend is an operational expense that fluctuates with usage — and usage is controlled by potentially hundreds of engineers, each spinning up resources with a few clicks or lines of code. Without guardrails, it is common for organisations to discover they are paying for development instances running 24/7 despite being used only during business hours, storage volumes attached to terminated VMs, oversized database instances provisioned "just in case," and data-transfer charges from architectures that move data between regions unnecessarily.

For Australian MSPs managing cloud environments on behalf of clients, cloud cost governance is both a service differentiator and a trust issue. Clients expect their technology partner to not only deploy workloads correctly but to ensure those workloads run efficiently. An MSP that proactively identifies a 30% cost reduction through right-sizing and reserved instances builds significant goodwill and demonstrates value beyond break-fix support. Conversely, a client who discovers they have been overspending for months will question the expertise of their provider.

The single largest cost-saving lever in any cloud environment is commitment-based pricing. All three major providers offer discounts of 30-72% in exchange for committing to a specific level of usage over one or three years. On AWS, Reserved Instances (RIs) and Savings Plans cover EC2, RDS, ElastiCache, Redshift, and more. Azure offers Reserved VM Instances and Azure Savings Plans for Compute. GCP provides Committed Use Discounts (CUDs) and Sustained Use Discounts (automatic discounts for VMs that run more than 25% of the month). The key is to analyse historical usage to identify workloads with stable, predictable consumption and commit only for that baseline — leaving variable or spiky workloads on on-demand pricing.

AWS Savings Plans deserve special attention because they offer more flexibility than traditional RIs. A Compute Savings Plan applies automatically to any EC2, Fargate, or Lambda usage regardless of instance family, region, OS, or tenancy — making it ideal for dynamic environments where workload shapes change over time. An EC2 Instance Savings Plan offers a deeper discount but is locked to a specific instance family in a specific region. Understanding these trade-offs and layering multiple commitment types is how experienced FinOps practitioners extract maximum savings without sacrificing flexibility.

Spot Instances (AWS), Spot VMs (Azure), and Preemptible VMs / Spot VMs (GCP) offer the deepest discounts — up to 90% off on-demand prices — in exchange for the provider being able to reclaim the capacity with little notice (typically two minutes on AWS). These instances are suitable for workloads that are fault-tolerant and interruptible: batch processing, CI/CD build runners, data analytics jobs, rendering farms, and stateless web-tier instances behind a load balancer that can absorb the loss of individual nodes. They are not appropriate for databases, single-instance applications, or any workload where interruption causes data loss or user-facing downtime.

Right-sizing is the practice of adjusting the size (CPU, memory, storage) of cloud resources to match actual usage rather than perceived need. It is remarkably common to find production instances running at 5-10% average CPU utilisation because they were provisioned based on worst-case estimates or simply left at the default size. Each cloud provider offers native right-sizing recommendations: AWS Compute Optimizer analyses CloudWatch metrics and suggests instance type changes; Azure Advisor identifies underutilised VMs and databases; GCP Recommender provides machine-type suggestions based on observed consumption. These recommendations should be reviewed monthly and acted upon — right-sizing is not a one-time exercise but an ongoing discipline as workload profiles change over time.

Beyond compute, right-sizing applies to storage and databases. An RDS instance on db.r5.2xlarge with 20% memory utilisation can likely move to db.r5.xlarge. An S3 bucket storing years of access logs in Standard tier can save significantly by applying lifecycle policies that transition old objects to Infrequent Access and eventually Glacier. EBS volumes provisioned as io1 for performance that only gp3 levels of IOPS are actually consumed represent another common source of waste. Systematic right-sizing across compute, storage, and database layers typically yields 20-40% cost savings in environments that have never been optimised.

You cannot optimise what you cannot attribute. A robust tagging strategy is the foundation of cloud cost governance. Every resource should carry tags that identify its owner (which team or individual is responsible), environment (dev, staging, production), project or client (for MSPs, which customer the resource belongs to), and cost centre (the financial bucket it charges to). These tags flow through to the provider's billing data (AWS Cost Explorer, Azure Cost Management, GCP Billing Reports), enabling granular cost breakdowns by team, project, environment, or client.

Enforcing tagging compliance requires automation. Use AWS Service Control Policies, Azure Policy, or GCP Organisation Policies to prevent the creation of resources that lack mandatory tags. Terraform and other IaC tools should enforce tagging at the module level so that every provisioned resource inherits the correct tags automatically. Regularly audit for untagged resources using cloud-native tools or third-party platforms like CloudHealth, Spot by NetApp, or Infracost. For MSPs, accurate tagging is not just a cost governance tool — it is the mechanism by which you generate per-client invoices and demonstrate the value you deliver.

FinOps (a portmanteau of Finance and DevOps) is an emerging practice that brings financial accountability to cloud spending. Rather than treating the cloud bill as a single line item managed by finance or IT leadership, FinOps distributes cost awareness to the engineering teams that actually create and consume cloud resources. It operates on three principles: Inform (make cost data visible and accessible to everyone), Optimise (continuously right-size, commit, and eliminate waste), and Operate (build governance processes and automation that sustain efficiency over time). The FinOps Foundation, a program of the Linux Foundation, provides frameworks, certifications, and community resources for organisations adopting this discipline.

In practice, a FinOps operating model involves a cross-functional team — finance, engineering, and management — that meets regularly to review cloud spend, discuss anomalies, and prioritise optimisation actions. Engineering teams receive their own cost dashboards and are accountable for the efficiency of the resources they manage. Showback reports (showing costs attributed to each team) or chargeback models (actually billing internal teams) create incentives for efficient resource usage. For MSPs, adopting FinOps principles and presenting clients with clear, tagged cost reports positions you as a strategic partner rather than just a technology vendor.

Beyond native tools, third-party platforms like CloudHealth by VMware, Spot by NetApp, Infracost (which estimates costs in pull requests before resources are deployed), and Kubecost (for Kubernetes-specific cost allocation) provide deeper analytics, multi-cloud visibility, and automation capabilities. For MSPs managing environments across multiple providers, a multi-cloud cost management tool is essential for consolidated reporting and consistent governance. Many of these tools also provide automated scheduling — shutting down non-production environments outside business hours — which alone can reduce development and testing costs by 65% or more.

Every cloud cost optimisation journey should start with low-hanging fruit. First, identify and terminate unused resources: unattached EBS volumes, idle Elastic IPs, load balancers with no targets, orphaned snapshots, and stopped instances that still incur storage charges. Second, schedule non-production environments to shut down outside business hours and on weekends — an environment that runs 50 hours per week instead of 168 costs 70% less. Third, review data transfer costs: ensure services that communicate frequently are in the same region and availability zone where possible, and use VPC endpoints to avoid NAT gateway data-processing fees. Fourth, optimise storage tiers: move infrequently accessed data to cheaper storage classes and set lifecycle policies to automate transitions. These four actions alone can typically save 15-25% on an unoptimised cloud bill.