Why clean up the infrastructure immediately after the migration Most teams that finish an AWS migration focus on the functional validation of the cutover and on reassuring users. Yet the first days and weeks after the migration are critical for cleaning up the infrastructure, because this is when orphaned resources, fallback configurations that have become useless, and duplicates are easiest to identify and remove with confidence. Without a quick cleanup, three problems accumulate. First, the AWS bill keeps piling up the cost of resources that no longer have any business justification, multiplying the migration's TCO by a factor you could have avoided. Second, the infrastructure becomes increasingly opaque: in three months, no one will be able to say for certain what that classic load balancer or that "fallback" RDS database still in place was for. Third, the accumulation of zombie resources creates technical debt that slows down future operations, performance diagnostics, and scaling decisions. Immediate post-migration cleanup turns a confusing situation into a clear, streamlined, documented infrastructure. It is also the best time to align cloud costs with the figures that were announced and to rebuild leadership's confidence in the migration's return on investment. ## Full resource inventory and identification of orphans The starting point of the cleanup is an exhaustive inventory of what is actually running on AWS after the cutover. Unlike the migration plan, which listed everything that was supposed to be migrated, here you must scan the real infrastructure to discover what exists, in particular the gaps, the oversights, and the resources created in a hurry during the cutover but never removed afterward. AWS Cost Explorer and AWS Compute Optimizer are your first tools. Cost Explorer shows you the cost breakdown by service and region, quickly identifying unexpected budget items. Compute Optimizer analyzes EC2, EBS, RDS, and Lambda to detect the under-used (an 8 vCPU instance running at 2% CPU utilization for weeks) and the over-provisioned. Run a full scan through the AWS console: the results list the instances and volumes that are candidates for deletion or resizing. For a finer inventory, use AWS Systems Manager Fleet Manager or open-source tools like CloudMapper or Botocross. CloudMapper generates a visual representation of your AWS infrastructure, region by region, with the dependency links between resources (which instances use which security groups, which volumes, which snapshots). Botocross scrapes your entire AWS account and exports an inventory to CSV, exportable to Excel for sorting and analysis. During this scan, identify the categories of resources that are candidates for deletion: EC2 instances with zero inbound traffic since the cutover, floating unattached Elastic IP addresses (EIP) (costly and useless), EBS volumes detached for weeks, old volume snapshots you no longer need, multi-AZ RDS databases that were migrated but left on standby, load balancers created for testing, VPN or Direct Connect provisioned for the migration tunnel but now redundant. Document each identified resource in a spreadsheet with three columns: AWS identifier (instance ID, volume name, ARN), presumed reason for its presence (backup, test, fallback, oversight), and proposed status (delete, downsize, keep). This traceability is crucial for justifying decisions and making it easier for business owners to approve them. ## Removing residual resources and migration configurations After business validation of your inventory, move on to the deletion itself. Start with the safest resources, that is, the ones with no obvious dependency and no operational risk. Unattached EIP addresses, migration snapshots dating from before the cutover, EBS volumes detached with no link to an active instance, empty security groups, and test VPCs are ideal candidates for a first batch of deletions. Before deleting a resource, check its dependencies in the AWS account. An EC2 instance can be attached to a load balancer, volumes, network interfaces, and multiple security groups. Deleting the instance without first detaching or reconfiguring the load balancer will cause a service outage. Use AWS CloudFormation or the "Dependencies" tab in the console to trace the dependency relationships. AWS Systems Manager Dependency Mapper can help you with complex dependencies. A common post-migration pattern: the on-premises infrastructure remains partially in place, either to provide a coexistence period in case a rollback is needed, or because some non-migrated systems remain connected. After validating that all business cutovers are complete and stable (generally 1 to 2 weeks), remove the migration tunnels (IPSec VPN, virtual Direct Connect), the gateway instances (AWS DataSync or AWS DMS replication gateways), the temporary S3 staging buckets created for the data transfer, and the routing rules between on-premises and AWS that have become useless. For critical or large-scale deletions (removing 50 EC2 instances at once, for example), use AWS CloudFormation stacks or Terraform to run the deletions in the correct order, rather than manually through the console. This ensures that dependencies are handled automatically and that each deletion is traced in the AWS CloudTrail events. During the deletion, enable MFA (Multi-Factor Authentication) on the root account or on the IAM users who trigger these operations. Create final snapshots of important EBS volumes before deletion, in case an emergency restore is required within the 30 days following the cutover. This "reassurance" is cheap compared with the emotional and operational cost of a regretted deletion. ## Consolidating duplicated resources and harmonizing During a phased or cohort-based migration, it is common to temporarily create duplicate resources: two Kubernetes clusters (old and new), two relational databases (old and new RDS instance), two load balancers (one testing the new routing, one still on the old). After validating that the new cluster/database/load balancer runs stably in production, you must remove the old ones. Unlike the simple deletion of orphans, consolidation requires verifying that all traffic has indeed switched to the new resource and that no one is accidentally bypassing it through the old one. For databases: if you had an on-premises MySQL RDS instance and migrated it to RDS on AWS, delete the old one after a week of validating that the application uses the new one exclusively. First check the connection strings in the application, the backup scripts, the reporting tools, and the backup cron jobs. An application still connecting to the old database for non-critical reads will complicate your consolidation. Harmonize all references to the new database, and only then delete the old one. For load balancers or API Gateways: the cutover probably created a period where both accepted traffic (to test the new one). After stabilization, switch 100% of the traffic to the new one and monitor the error logs of the old load balancer. Once no request has reached it for 24 hours, you can delete it safely. For storage (S3 buckets, EFS): some data may have been copied several times during the migration (source snapshot, staging bucket, replica for testing). After the cutover is validated, consolidate to a single source of truth and delete the test replicas. But keep at least one backup (snapshot or backup) in case a fast rollback is required. Consolidation also reduces operational complexity: an operations team with two similar databases to monitor and two configs to keep up to date would make twice as many errors as with a single optimized resource. Consolidation creates a clearer, more maintainable infrastructure. ## Post-cleanup documentation and cost validation Once the physical cleanup is complete, document what was deleted, when, and why. This record is your assurance that the decisions were made rationally. Create an archive register listing: resource name, AWS ID, deletion date, justification, approval, and final snapshot created if relevant. This documentation serves three purposes. First, it exonerates the owners in case of a later question (for example, if a business owner asks why a resource disappeared). Second, it creates a post-cleanup baseline that you will compare with the following monthly cost statements. Third, it documents the real state of the infrastructure for compliance audits and IT governance reports. Compare AWS costs day by day before and after the cleanup. If you had a monthly bill of 150,000 euros before cleanup and 120,000 euros after, that is an immediate saving of 30% (360,000 euros annualized) with no functional change, simply by removing waste. Documenting this gain for leadership reinforces the legitimacy of the migration investment and helps justify future budgets. The last step is creating a policy or procedure to prevent the future accumulation of orphaned resources. For example: every resource created must have an "Owner" and "Business Unit" tag, every month an inventory of resources without an owner is generated automatically, and owners have 15 days to justify their presence or the resources are deleted. AWS Config and AWS CloudTrail make it possible to automate this monitoring. A light audit every quarter (30 minutes to scan for unused resources, instances stopped for a long time, and old snapshots) prevents the buildup of debt and keeps the infrastructure clear and fairly priced. ## Common risks and security best practices during cleanup Post-migration cleanup carries risks that are never documented openly but that can be costly if they materialize. The first is the risk of accidental deletion. An instance that looks orphaned may be used by a nightly batch process or by a satellite team that never told you about it. Before deleting, send a notification to the relevant mailing list (for example, to the Data Scientists, the BI team, the business teams): "We plan to delete the instance prod-analytics-old-box on 2024-12-20. If it is critical for you, let us know before that date." The second risk is deleting a shared resource. For example, a security group used by ten instances, or a KMS key that encrypts hundreds of snapshots. Delete the security group, and ten instances stop communicating. Delete the KMS key, and you can no longer restore the snapshots. Before deletion, list the resources that depend on it. A KMS key has a "Key Policy" and "Dependents" tab; a security group shows the attached instances. The third risk concerns data. An EBS volume that seems useless may contain an informal backup or a file someone copied "just in case." Before deleting a volume larger than 10 GB containing data, create a final snapshot and keep it for 30 days. It is cheap insurance (it costs less than 1 euro per snapshot at AWS) against a later claim. The fourth is regulatory compliance. Some systems produce logs or data that must be retained for legal reasons (GDPR, audit logs, financial traceability). Before deleting a database or an S3 bucket containing logs, check the imposed retention rules. CloudTrail logs, for example, must often be archived for 7 years. Best practices: use IAM policies to restrict deletion permissions (only authorized AWS administrators can delete EC2 or RDS), trace every deletion via CloudTrail (enable logging if it is not already on), use AWS resource tags to categorize (Production, Test, Temporary) and apply lifecycle policies (e.g., instances tagged Temporary=true are deleted automatically after 7 days), and finally conduct the cleanup as a team with at least two pairs of eyes on every critical deletion. A pattern of progressive confidence: first test the deletions on a test AWS account, then on non-critical infrastructure, then finally on production. This builds experience and reduces surprises. ## Integration with consolidation and cost optimization Post-migration cleanup is the first chapter of a longer story of consolidation and optimization. Once you have eliminated the orphaned resources and the duplicates, you move on to active consolidation: merging fragmented AWS accounts into a more centralized structure, harmonizing the security and tagging configurations, and correctly sizing the remaining resources. This is the stage at which you also explore more efficient pricing models: buying Reserved Instances (RI) or Savings Plans for the stable workloads identified during the cleanup, using Spot instances for batch and test workloads, and rightsizing over-provisioned instances that suddenly become visible after removing the duplicates. The cleanup also creates the opportunity to review the architecture itself. For example, a cleanup may reveal that you had four small RDS databases instead of a single well-partitioned one, creating an opportunity for a more ambitious architectural consolidation. In this context, cleanup is not an isolated activity but a critical phase of a broader consolidation program that spans 2 to 3 months after the migration and finalizes the transition to a stable, optimized cloud infrastructure.