Why eliminating duplicated cloud resources during consolidation matters During an AWS migration, it is common to keep the old systems and the new cloud resources running in parallel, creating a fragmented and costly infrastructure. This redundancy slows down operations, multiplies potential points of failure, and sustains technical debt that is hard to control. Teams end up managing two stacks at once, which scatters effort, multiplies the configurations to maintain, and generates a cloud bill far higher than necessary. Beyond cost, this duplication poses a major governance problem, with project leads losing visibility into who does what, on which account, in which environment. During a consolidation, eliminating these duplicates is not a cosmetic luxury, it is a strategic step that creates the conditions for calm, controlled operations. Internal teams can finally focus on continuous improvement rather than managing several layers of obsolete infrastructure. Identifying and merging redundant resources makes it possible to return to a clear, traceable, cost-optimized platform. ## Identifying redundant resources in your existing infrastructure Precise identification of duplicated resources is the foundation of any successful consolidation. Start with a complete audit of your current AWS environment, including all active accounts, running services, and stored data. Use native AWS tools such as AWS Trusted Advisor or third-party audit solutions to build an exhaustive inventory of EC2 instances, RDS databases, S3 buckets, Lambda functions, EBS volumes, and other resources. For each major resource, determine its ownership, its activation date, and its real utilization rate. You will often discover PostgreSQL databases tested during the PoC but never shut down, AWS accounts created for a pilot project and now forgotten, or application services launched in duplicate for reasons of progressive migration. Also catalog obsolete test environments, those that never left the validation phase and continue to consume resources. For legacy systems still active, record their real utilization rate (consult CloudWatch and the logs for the last three to six months) rather than making assumptions. A service used at 2% once a quarter does not justify its retention. Once this picture is drawn, group the duplicates by category: identical resources across several accounts, services running in several AWS regions without functional justification, test environments with overlapping roles, or data replicated without active synchronization. ## Strategy for merging AWS accounts and consolidating resources Once the redundancies are identified, the next step is to define a progressive and secure merging strategy. Most organizations migrate toward a consolidated-account model where a single main AWS account or a minimal number of accounts clearly separate the environments (production, staging, development) rather than accounts fragmented by project or migration phase. This structure helps with budget control via AWS Billing Consolidation and simplifies IAM and security policies. Before merging the accounts, align the teams on the target scheme: decide whether you will keep a single production account, with separate accounts for staging and dev, or whether you will maintain multi-environment accounts. Document this target architecture in a diagram that will serve as a reference throughout the project. For the resources themselves, start by eliminating the definitively obsolete test environments (no activity in 6 months, no identified owner). These deletions do not impact production and deliver quick wins. Next, progressively migrate the active services from a source account to the target consolidated account, using AWS DataSync for data, AWS Application Migration Service for applications, or a manual configuration replication for lightweight resources. Test each migration in a non-production environment before executing in production. For duplicated databases, favor a merge at the application level: progressively redirect traffic from the duplicated database to the consolidated database, validate that the data no longer diverges, then delete the old instance. A merge schedule by resource type (storage first, then compute, then databases) helps pace the work and minimize risk. Each step must be documented, tested, and validated by the teams before the next one. ## Securely deleting resources that have become obsolete Deleting redundant resources must follow a strict protocol to avoid accidental data loss or the interruption of a still-active service. Before any deletion, create snapshots or complete backups of the resources to be eliminated, including disks, databases, and configurations (back up the security settings, IAM policies, VPCs, and network configurations). Keep these backups for at least 90 days after deletion, in case a forgotten dependency resurfaces. Then, implement a graduated deletion procedure: start by stopping the non-critical resources (stopping EC2 instances rather than deleting them immediately), observe for one to two weeks that no incident is reported, then delete the stopped resources. For databases, first establish an executive copy (SQL dump or snapshot) and validate its restoration on a test database before deleting the active volume. Use AWS Backup policies to automate pre-deletion backups and set up CloudWatch alerts if a resource that is supposed to be deleted is reactivated accidentally. For entire AWS accounts to be closed after resource consolidation, AWS offers a closure process that provides a grace period (often 90 days) before permanent destruction. This delay allows any residual dependency to be detected. Finally, document each deletion in an audit register (date, resource, reason, approval) that can serve as evidence of compliance in the event of an audit or dispute. ## Data consolidation and schema harmonization Merging resources often includes a consolidation of legacy data, in particular if several duplicated databases must converge into a single one. This step is critical because it requires validating schema consistency, reconciling conflicting writes, and a smooth migration with no loss or duplication. For two PostgreSQL or MySQL databases that have diverged, start with a schema audit: compare the tables, columns, constraints, and sequences to identify the gaps. Then establish a mapping table that defines how the data from a source database corresponds to the target database. If the schemas differ slightly (an extra table here, a renamed column there), create transformation scripts that normalize the data before insertion. For conflicting data (for example, two customer records with the same ID but different addresses), establish an explicit resolution rule (keep the most recent version, merge the fields, or notify the administrator for manual arbitration). Use a write-freeze window (all systems stop their inserts) for 30 minutes to a few hours, the time needed for the final synchronization. This approach reduces the risk of desync after the merge. Once the merge is tested in non-production, execute it in production during a scheduled maintenance window. After the merge, validate that every record made it through and that no data was duplicated or lost (row counts before/after the merge, checksums, end-to-end application tests). This data harmonization is also an opportunity to improve the quality of the existing data: clean up duplicate customers, standardize date or phone formats, remove obsolete columns. ## Post-consolidation validation and audit Once the consolidation is complete (accounts merged, resources eliminated, data harmonized), a complete validation is essential before considering the phase finished. Start with an inventory audit: use AWS Config or a custom scan tool to list all remaining resources and verify that they match the approved consolidation plan. No phantom resource should remain. Then functionally test each critical application or service: run regression tests covering the main business flows, validate the performance (response time, network latency), and verify that the applications on the consolidated infrastructure behave as before. Also check the costs: compare the current AWS bill with the one before consolidation. You should observe a significant reduction (often 20 to 40%) thanks to the elimination of redundant resources. If that is not the case, there are probably unused resources that were not detected initially. Finally, audit the governance: verify that tagging is consistent (each resource is identified by project, environment, and owner), that IAM policies are restrictive (least privilege), and that access logs and security alerts are working. Document the results of this audit in a formal report that will serve as a baseline for future tracking. This report also becomes a key element of the consolidation file that you can present to your management or internal auditors.