Why a cloud cost audit is essential before migration Before migrating to AWS, understanding where the money spent on your current cloud infrastructure goes is not a luxury, it is a strategic necessity. Many organizations discover during a migration that 30 to 40% of their cloud budget funds underused, orphaned, or misconfigured resources. Discovering this too late can turn a coherent migration plan into a budget nightmare.
A cloud cost audit conducted before the transition gives you two essential things. First, it establishes a quantified and transparent baseline: you know precisely how much each component of your infrastructure costs today, you identify the line items that are ballooning, and you detect the obvious anomalies (instances that are never stopped, zombie storage, software licenses running idle). Second, it arms you with solid arguments for the CFO and the executive committee. Rather than saying "we will migrate and save money someday," you can put a factual analysis on the table: "we have identified 150k euros per year of over-provisioning and 85k euros of orphaned resources; by removing or optimizing them right now, we cut billing by 235k euros before even touching AWS."
This transparency about current costs also becomes the compass for your migration strategy itself. It tells you which applications are budget hogs (and therefore priority candidates for optimization), which resources are critical (and therefore must be replicated faithfully to AWS without loss of performance), and where the potential gains will be greatest.
The five most common budget leaks to detect Most cloud cost audits reveal flaws that repeat from one organization to the next. Learning to recognize them lets you start your audit with a trained eye.
The first leak is over-provisioning of compute power. An AWS instance (or an equivalent at another provider) often remains configured with the size someone estimated "just in case" six months earlier, without ever being reassessed. A t3.2xlarge costs 3 to 4 times more than a t3.medium, but in practice it uses 20% of its CPU and 15% of its RAM on average. The monthly cost can climb to 800 or 1,200 euros for real usage that would only require a t3.small at 120 euros. Multiplied across ten or a hundred instances, this waste easily reaches five figures.
The second category is orphaned resources: volumes detached but not deleted, backup snapshots never cleaned up, static IP addresses reserved but unused, or databases on standby for a failover that never happened. These objects cost almost nothing individually (a few euros a month), but in aggregate they often represent 15 to 20% of the storage bill.
The third leak, more subtle, is data transfer and outbound bandwidth. Every gigabyte of data that leaves the datacenter costs 5 to 12 cents depending on the region and the path. An application that pushes logs to a third party, replicates data between zones, or serves content to external users without a CDN can accumulate hundreds of euros in transfer fees without anyone noticing.
The fourth is the lack of consolidation on low-usage environments. Many organizations keep isolated development, staging, or test environments with their own instances, databases, and network services, even when these environments only run 30 or 40 hours a week. A simple plan to automatically shut down resources outside business hours can cut the cost of these environments by a factor of 3 to 4.
Finally, the fifth leak is software licensing. Many vendor licenses (Microsoft SQL Server, Oracle, etc.) are billed per instance or per vCore, and organizations no longer know which software runs where. An instance that was supposed to hold a "Development" license turned into a critical staging server, then a production standby, but the categorization was never updated. Checking license compliance regularly reveals forgotten under-licensing or licenses purchased but never deployed.
The concrete steps of an effective cost audit A cloud cost audit should not be a three-month study run by external consultants disconnected from your operational reality. Here is how to run an effective audit in-house, with or without external support to validate the conclusions.
Step 1: gather the raw data. Export your last 6 to 12 months of cloud bills in CSV or JSON format from your provider's console (AWS Cost Explorer, detailed GCP or Azure invoices). These files contain every charge, every service, every region, and every tag. Import them into an analysis tool: a simple Google Sheets is enough to get started, but a dedicated tool like CloudFit, Densify, or even the native AWS Cost Explorer offers dashboards that speed up the analysis.
Step 2: segment by strategic dimension. Do not just look at "compute" versus "storage" in aggregate. Break it down by application, by environment (prod/staging/dev), by responsible team, by geographic region, and by workload type (on-demand vs reserved vs spot). This immediately reveals which service spends the most and where the anomalies are located.
Step 3: identify anomalies through tagging and untagged resources. Go into your provider's console and list the instances, volumes, snapshots, and databases. Look for untagged resources (often ad hoc creations whose owner or purpose no one remembers). Also list resources tagged "environment = dev" or "temporary = true" but still active after 6 months, those with no network activity for a month, or with 0% CPU utilization for weeks. These strong signals often indicate orphaned resources.
Step 4: confront the analysis with the teams. Application team X must confirm: "yes, this 2,000 euros/month instance is ours, and here is its real usage" or "no, this machine has not been used since the migration of microservice Y four months ago." This confrontation systematically reveals surprises: a resource no one thought was still active, another everyone believed was already shut down. It also turns the audit from a purely financial exercise into a technical conversation, which creates the context to propose optimizations.
Step 5: quantify the impact of the obvious optimizations. List the immediate actions: "delete 47 orphaned snapshots = 3,200 euros/year," "stop dev environments between 7 pm and 8 am = 18,000 euros/year," "resize 23 oversized instances = 42,000 euros/year." Put figures on them. The sum of these "easy" moves regularly reveals 100,000 to 300,000 euros of annual savings without any major architectural effort.
Step 6: document for the migration. Create an inventory sheet for each significant application: name, current monthly cost, typical usage (CPU, RAM, storage, bandwidth), latency sensitivity, critical dependencies. This sheet becomes the specification for your migration: it says what you must reproduce on AWS, at what performance level, and above all what cost you must not exceed.
Cloud cost analysis tools and methods Several approaches and tools can speed up or automate your cloud cost audit. The choice depends on your size, your cloud maturity, and your budget for the audit itself.
The provider's native tools are the free and mandatory starting point. AWS Cost Explorer offers interactive dashboards, filters by tag, service, and region, and alerts on trend anomalies. Its "Recommendations" tab already suggests optimizations (unused instances, underutilized reservations, etc.). Use it first before considering third-party tools. GCP BigQuery and Microsoft Azure Cost Analysis offer similar features.
For organizations with more than 500k euros per year of cloud spend, a third-party tool like CloudFit, Optimizely, or Densify offers deeper analysis: it ingests your usage history over months or years, detects patterns (seasonal over-provisioning, unexplained spikes), automatically recommends rightsizing, and models the impact on your budget of a migration to AWS or a transition to reserved capacity. These tools cost between 500 and 3,000 euros per month, so they must be justified by real savings of more than 50,000 euros per year.
For a structured approach, a homemade framework on Google Sheets or Airtable is often enough. Import your bill exports, create pivots by application, by team, by region. Add an "observed CPU/RAM usage" column filled in by your operational teams, and an "orphaned or over-provisioned resource" column for the diagnostic. This template quickly becomes your decision tool throughout the audit phase.
A complementary but labor-intensive method is manual application analysis. Connect to your monitoring (Prometheus, New Relic, DataDog, CloudWatch) and look at the real metrics of each application over the last 3 months: average CPU, peaks, RAM used, requests per second, P99 latency. Compare with the allocated capacity. A t3.xlarge instance showing 8% CPU and 12% RAM on average, even with peaks at 40%, can run on a t3.medium without risk. This analysis takes time but it produces quality recommendations that automated tools, being too cautious, might miss.
Finally, consider bringing in an external auditor for a few days. A cloud cost expert can sniff out leaks that your team, accustomed to the existing setup, no longer sees. Their fresh eye and complete checklist speed up the detection phase. At Stralya, we often rely on this mixed approach: a fast internal audit plus external validation over 2-3 days to catch what was overlooked.
From audit to decisions: figures and prioritization An audit that ends with a simple list of facts has served no purpose. The goal is to turn these findings into quantified decisions and prioritized actions.
First, present the findings along two axes that speak to leadership: short-term cost reduction, and the savings tied to the migration itself. The short term is "we have identified 235k euros of savings without deploying AWS: shutting down environments outside business hours, deleting orphaned resources, and resizing oversized instances." These actions take 2 to 6 weeks and require no major architecture, just operational discipline. They also demonstrate a willingness to optimize before the big migration.
The second axis is the AWS potential: "this cleaned-up baseline lets us project a realistic AWS cost and identify the AWS services (reserved instances, savings plans, spot instances for non-critical workloads, data transfer reduction) that will add 20 to 30% of additional savings after migration." This shows that the AWS cost is not a surprise, that it has been budgeted based on a genuine understanding of your workload.
Second, create an impact-complexity matrix for your identified optimizations. Each action (delete 50 orphaned snapshots, stop dev at night, resize instance X, refactor data replication) must have an estimated impact (how much it saves per month) and a complexity (engineering hours required, risks, dependencies). High-impact, low-complexity actions (the northwest quadrant) must be done immediately. High-impact but complex ones go into the migration backlog. Low-impact, low-complexity ones are quick wins for the team.
Third, assign ownership for each optimization. Do not say "stop the dev environments at night." Say "the Platform team will launch a shutdown script at 7:00 pm on weekdays (impact: 18k euros/year, complexity: 4 hours, deadline: end of month)." This granularity turns the audit into an action plan.
Finally, document the migration plan itself based on this baseline. If application A costs 4,000 euros/month in prod today and 2,500 euros/month in dev, your AWS design must budget at least 4,000 euros/month in prod (perhaps 3,200 euros if you use AWS Savings Plans). If optimization reveals that application A is actually oversized and that 2,800 euros/month would be enough, note it: that is your AWS target, not 4,000 euros. The cost audit then becomes the foundation of your AWS purchasing strategy (reserved instances, spot, etc.).
Cost audits and migration: how to connect them The cost audit should not remain an isolated exercise. It should structure your migration itself.
First, the audit tells you which applications are priority migration candidates. If application A costs 3,500 euros/month and application B costs 280 euros/month, migrating A first creates more visible returns on investment and lets you master AWS costs on a more significant use case before launching the full migration. The audit also identifies applications where AWS charges can be reduced: if application A runs on heavily oversized instances, using more granular AWS resources (Lambda for intermittent jobs, ECS for containers, Fargate to avoid managing infrastructure) can cut its cost by a factor of 3.
Second, the real usage data (CPU, RAM, bandwidth) gathered during the audit lets you correctly size your AWS resources from the start. Rather than migrating a t3.xlarge instance and discovering six months later that it uses 15% of its capacity, you migrate directly to a t3.medium, saving 80% on that cost from day 1. AWS teams that do not conduct a preliminary audit regularly make this mistake, and accumulate 6 to 12 months of over-provisioning on AWS before realizing the error.
Third, the audit reveals dependencies and consolidation opportunities. If you have four separate databases for four micro-applications, the audit may show that they all use very few resources and that a migration to RDS Aurora Serverless with a single cluster would be enough, reducing operational and fixed costs. Or if you have storage fragmented across several regions, you can consolidate into a single AWS region and use intra-AWS transfer (free) instead of multi-cloud transfers (expensive).
Fourth, identifying the current leaks lets you define realistic SLAs after migration. If today you lose 100k euros per year in orphaned resources, promise stakeholders that AWS will have an automated cleanup process that eliminates this waste. That is a viable commitment, based on real data from your own history.
Finally, the short-term optimizations carried out before the migration (stopping dev at night, deleting orphaned resources, resizing instances) reduce the total budget to migrate. If you reduce your baseline by 235k euros, you only need 235k euros less in AWS budget, which makes the migration business case even stronger.