The most common cloud cost problem is not that costs are high. It is that costs are invisible until they are not. A surprise invoice at month end, a budget alert that triggers two weeks after the underlying spend started, a workload that was "temporary" and is still running. Multi-cloud environments amplify this because the spend is split across two billing systems with different cost models, different resource types, and different optimisation levers.
Build a tagging standard before you build anything else
Tags are the foundation of cost visibility. Without them you cannot attribute spend to a team, a product, an environment, or a customer. With them, you can answer almost any cost question quickly.
The minimum viable tag set for most organisations: environment (production, staging, development), team or cost centre, service or application name, and a lifecycle tag (persistent vs temporary). Apply these consistently across both clouds using infrastructure-as-code, and enforce them with AWS Tag Policies and Azure Policy so new resources cannot be created without them.
Tags created retroactively on existing resources are better than no tags, but the value is lower because historical spend data cannot always be reclassified. Start the tagging discipline from the beginning and maintain it through IaC controls.
Understand the cost model for each service type
AWS and Azure price similar services differently. Compute instances, managed databases, storage, and data transfer all have pricing dimensions that differ between providers. The biggest multi-cloud cost surprises tend to come from data egress charges, because both providers charge for data leaving a region and the rates vary significantly depending on where it is going and which protocol it uses.
Map your data flows across both clouds and identify where egress charges are accumulating. In some cases, rearchitecting to keep data transfers within a region or within a provider significantly reduces cost. In others, the cross-cloud transfer is justified by workload requirements, but it needs to be understood and budgeted for explicitly rather than discovered as an unexpected line item.
Rightsize continuously, not just at procurement time
Rightsizing is the process of matching instance types and sizes to actual workload requirements. In most environments we assess, 30-50% of compute resources are materially over-provisioned: running at low average CPU and memory utilisation with no burst requirement that justifies the capacity. The gap between what is provisioned and what is needed represents direct waste.
Both AWS Compute Optimizer and Azure Advisor provide rightsizing recommendations based on observed utilisation. Route these recommendations into your engineering workflow and act on them quarterly as part of a regular cost review. Rightsizing is not a one-time activity because workloads change: a service that needed 16 vCPUs during a growth phase may need 4 once traffic stabilises.
Use reserved capacity for predictable workloads
On-demand compute is the most expensive way to run stable, predictable workloads. AWS Reserved Instances and Savings Plans, and Azure Reserved Virtual Machine Instances, offer significant discounts (typically 30-60% depending on term and flexibility) in exchange for a commitment to a usage level.
The key is to buy reservations for genuinely stable workloads and leave on-demand for variable or unpredictable ones. Buying reservations for workloads that subsequently get rightsized or decommissioned locks in spend on capacity you no longer need. Use utilisation data from your observability platform to validate baseline demand before making commitments.
Instrument cost anomaly detection
Cost anomaly detection is the cost management equivalent of infrastructure alerting. AWS Cost Anomaly Detection and Azure Cost Anomaly Alerts can flag when spend deviates significantly from its expected pattern. Set these up and route alerts to the relevant team, not just to finance.
A better approach is to instrument cost metrics directly in your observability platform alongside infrastructure and application metrics. With Datadog's cloud cost management capabilities, cost data appears in the same dashboards as performance and reliability data. This means an engineer investigating a performance issue can immediately see whether it correlates with a cost anomaly, and a cost spike investigation can be contextualised against deployment or traffic events.
Build a FinOps operating model
FinOps is the practice of bringing financial accountability into cloud operations. The core principle is that the people making cloud infrastructure decisions should have visibility of the cost consequences of those decisions, and should be accountable for them.
In practice this means: engineering teams own their cloud spend, not just finance; cost reviews happen as part of sprint cycles, not just at quarter end; and there is a defined process for identifying, reviewing, and acting on optimisation opportunities. A managed cloud provider with strong FinOps practice can accelerate this significantly, particularly for organisations that do not have dedicated cloud financial management expertise in-house.
Log volume as a cost lever
Log ingestion is a significant and often overlooked cost in cloud environments. Unfiltered application logs, debug-level logging left on in production, and redundant log shipping to multiple destinations can all drive log volume far above what is operationally useful. In environments where we have applied systematic log volume management, we have achieved 77% reductions in log volume without meaningful loss of observability. That represents a material reduction in observability platform costs alongside the storage and ingestion savings.