Why AWS costs explode after a migration During a migration to AWS, the cloud bill rarely spirals out of control during the transition phase itself, but reveals its true challenges once the infrastructure is stabilized in production. This cost explosion happens for several structural reasons. First, resources were often sized "large" to guarantee stability during the migration: oversized EC2 instances, over-provisioned EBS volumes, databases with generous reservations remain in place long after the transition is complete. Then, the migration creates unintended duplicates: test environments that were never deleted, orphaned snapshots or AMIs, data replications inherited from the switchover process that keep consuming resources. Finally, internal teams often discover that the legacy infrastructure already contained hidden waste: duplicated services, obsolete cache layers, databases that are never queried. Once on AWS, these inefficiencies become visible and measurable through native AWS tools (CloudWatch, Cost Explorer), whereas they were masked by the fixed costs of an on-premises datacenter. The challenge is therefore not a bad migration, but the gradual adjustment of resources to the true production load once it has stabilized and the teams have regained the capacity to act after the urgency of the cutover.
Identifying the direct costs to optimize after migration Before launching a cost optimization strategy, you first need to locate where your money is actually going. AWS Cost Explorer is your first instrument: enable the breakdown by service (EC2, RDS, S3, ElastiCache, etc.), by environment (prod, staging, dev) and by project or cost center tag to understand the real granularity of your spending. Generally, three cost items absorb 80% of the bill after a migration. The first is compute: EC2 instances run at an hourly cost, and a poorly sized instance costs the same as a correctly sized one. The second is storage: EBS volumes, uncleaned snapshots and data archived in S3 accumulate without active attention. The third is the database: RDS instances for relational databases, NoSQL or ElastiCache services for caches. For each item, start by exporting your spending from the last three months (or more if you have only just stabilized) in Cost Explorer, then compare this breakdown to your initial budget allocation. If you had planned 10,000 euros per month for EC2 but are consuming 14,000, this difference of 4,000 euros must be explained: normal business growth, orphaned resources, or oversizing? AWS Compute Optimizer then provides automated recommendations, but filter them with caution: they are based on past metrics and may overlook seasonal peaks or test loads. Real optimization begins when you have a clear picture of who consumes what and why, not when you blindly follow a list of recommendations.
Adjusting resource sizing to match the real load Once identified, oversized resources become your first gains. Optimal sizing means adapting capacity to the observed load, not to the maximum imagined capacity. For EC2 instances, use CloudWatch to extract CPU, memory (via the CloudWatch agent if necessary) and bandwidth metrics from the last three months. An instance running at 15% CPU on average can generally move from an expensive type (for example m5.2xlarge) to a smaller type (m5.large or even m5.xlarge) without risk, provided that CPU peaks stay below 70-80%. For an RDS database, look at the IOPS actually consumed, the memory used and the storage space used: a db.r5.4xlarge instance can often be brought down to db.r5.2xlarge or db.r5.xlarge if the queries do not saturate the resources. The reduction must remain gradual: reduce by one notch, observe for one to two weeks, then consider a further reduction if performance remains acceptable. For non-production environments (development, staging, testing), sizing can be aggressive: a development instance that runs 24/7 with no real need can be reduced to the minimum viable size or even stopped outside working hours via AWS Lambda or Systems Manager scripts. Each instance type reduction typically represents 30 to 50% savings on that specific item, cumulative if several resources are adjusted. Be careful, however: an optimization that degrades user performance or creates instability completely cancels out the benefit. Consult your observability and application logs to validate that the resource reduction does not cause invisible throttling or amplified errors.
Optimizing instance reservations and Savings Plans Beyond sizing, reserved instances (RIs) and AWS Savings Plans are your major levers for cost reduction. An EC2 instance paid on-demand costs much more than a reserved instance or one covered by a Savings Plan: expect 30 to 70% savings depending on the commitment and the type. After a migration, you have generally waited a few weeks or months to validate stability before committing to reservations. At this stage, you finally have real metrics: you know which instances run 24/7, which ones vary, and where you have a predictable load. A flexible Savings Plan (compute, 1 year or 3 years depending on risk appetite) typically covers 50 to 60% of your EC2 and RDS bill without locking you into specific resources, which is relevant post-migration when the architecture may still evolve. Classic reserved instances (RIs) offer up to 72% reduction for a 3-year commitment, but require you to freeze the instance type, the region and the availability zone: useful only if your infrastructure is truly stabilized and you are confident in its permanence. Before committing, validate three points: first, that your load is effectively stable (same instance, same region) over the observation period; second, that you do not plan any further migrations or reductions within 12 months; third, that you have tested the alternatives (horizontal scaling, Lambda orchestration) that could reduce the need for reservations. The classic post-migration mistake is to immediately reserve a big stack of instances simply because they seem "stable" in the first month, then discover three months later that you could have reduced them by 30%. Wait for the natural peak and trough of your business before committing: if your load varies by 20% between January and December, buy flexible Savings Plans, not fixed RIs.
Removing orphaned and unused resources Very often, the fastest cost optimization is not a fine adjustment, but a pure and simple deletion. During a migration, you create snapshots to save the state before cutover, AMIs for templates, EBS volumes as backups, and once the transition succeeds, no one has time to clean them up. Three months later, a dozen obsolete AMIs, duplicated snapshots, volumes detached from deleted instances remain in place and keep costing money. AWS charges them only for storage (a hundred euros to a thousand euros per month depending on the volume), but it is money that generates no value. Systematically check your EBS snapshots (EC2 / Snapshots / Owned by me) and delete those whose purpose or origin you no longer know. Same for AMIs: run a report of the AMIs created before the migration (filtered by tag or date) and confirm that none is a forgotten duplicate. For EBS volumes, a volume detached for more than a month is a candidate for deletion: ask your team before removing it, but if no one can tell you why it is there, it is an orphan. Unattached Elastic IPs also cost money, even at rest: if you have 5 unused EIPs, release them. Unused network interfaces (ENIs), empty DynamoDB tables, ElastiCache caches that are never queried: all these elements are candidates for archiving or deletion. Systematize this cleanup every six to eight weeks: enable AWS Cost Anomaly Detection reports to detect unusual spikes (sometimes revealing leaks), ask your infrastructure team to clearly label the resources ("environment: prod", "project: xyz") and delete anything that has not been tagged after a given delay. A day of cleanup can recover 500 to 2,000 euros per month of avoidable costs, which is worth the investment.
Optimizing storage and data management Storage is often the second cost item forgotten after compute. After a migration, legacy data accumulates: application logs dumped into S3 without a retention policy, backup snapshots kept indefinitely, databases with dead tables that are never deleted. S3 offers several storage classes whose pricing differs radically: S3 Standard costs 0.023 euros per GB/month, S3 Standard-IA (Infrequent Access) costs 0.0125 euros, S3 Glacier costs 0.004 euros. Data consulted daily must stay in Standard; data archived for legal reasons but never read can move to Glacier as early as the third week. Configure S3 Lifecycle Policies for each bucket: for example, move application logs to Standard-IA after 30 days and to Glacier after 90 days, then delete after 1 year. This typically reduces 40 to 60% of the S3 storage cost if your data includes a lot of logs or backups. For databases, look at the retention of automatic backups: AWS RDS keeps 7 days of backups by default, but your business may only require 3 or 5 if you have a disaster recovery system in place. Reducing from 7 to 5 days saves 30% on this item. Also audit the tables or partitions that are never queried in your NoSQL databases or data warehouses: Amazon Athena costs per query and per data scanned, so if a table is read once a month, it takes up space for a tiny use. Archive it or merge it. Finally, evaluate your data replication and synchronization strategies: if you replicate an entire database to a secondary region for DR, make sure it is necessary; scaling the replication back to a critical selection of data can reduce costs by 30%. These storage adjustments do not tie up your team for long, but the impacts add up quickly: fixing S3 Lifecycle, reducing backup retentions and archiving dead tables can recover 1,000 to 3,000 euros per month depending on your size.
Setting up continuous monitoring and best practices Cost optimization is never finished after a migration. It requires regular monitoring to stay effective over the long term. Create a Cost Management dashboard: export your monthly spending from Cost Explorer, compare it to the allocated budget, and identify the month-over-month drifts. If your bill jumps from 10,000 to 12,000 euros with no major new business load, something has changed: forgotten new reservations, orphaned resources accumulating, or an accidental deployment of a test environment into production. A simple Google Sheet with total spending, by service, by environment, refreshed each month, is enough to detect anomalies. Then automate your best practices: configure AWS budgets (Billing / Budgets) that send alerts if you exceed a given threshold, enable AWS Cost Anomaly Detection for machine-learning-driven anomaly detection, and ask your infrastructure team to systematically tag all resources at deployment time (project, environment, owner) rather than retrospectively. Finally, integrate cost optimization into your infrastructure review cycle: each quarter, consult Cost Explorer, identify the three main savings levers, implement them, measure the impact, and iterate. A company that has just stabilized a migration can typically recover 20 to 30% of costs in three to four months of gradual optimization, simply by adjusting sizing, enabling Savings Plans and removing orphans. It is not magic, it is regular and methodical work.