Aller au contenu

AWS Mis à jour le 2026-07-04

Nettoyage des ressources AWS inutilisées : la liste de chasse aux orphelins

Liste pratique de nettoyage des ressources AWS inutilisées : trouver les volumes EBS détachés, les répartiteurs de charge inactifs, les vieux instantanés et les Elastic IP inutilisées — et les supprimer sans risque.

Tout compte AWS vivant depuis plus d’un an traîne des orphelins : des volumes EBS détachés d’instances terminées depuis longtemps, des instantanés de serveurs dont personne ne se souvient, des répartiteurs de charge pointant vers des groupes cibles vides, des Elastic IP allouées pour une migration finie en 2023. Aucun ne fait quoi que ce soit, sauf apparaître sur la facture. Une chasse structurée — inventaire, vérification d’inactivité, instantané de ce qui est supprimable-mais-inquiétant, puis suppression — retranche typiquement une tranche visible de la facture mensuelle en un après-midi, avec un risque presque nul si vous suivez l’ordre ci-dessous.

Ce que vous décidez

Pour chaque ressource candidate, vous tranchez entre trois options : supprimer maintenant (orpheline prouvée, aucune valeur de données), archiver puis supprimer (les données pourraient compter — instantané du volume, archivage de l’instantané, puis suppression de l’original), ou garder avec un responsable et une étiquette (réellement utilisée, juste anonyme). L’erreur à éviter est d’en faire un pur exercice de suppression : le gain durable, c’est que tout ce qui survit à la chasse finit étiqueté avec un responsable, et la prochaine chasse prend des minutes au lieu d’heures.

Les suspects habituels, en ordre approximatif de gaspillage : volumes EBS détachés (facturés au Go-mois, attachés ou non), vieux instantanés qui s’accumulent sans fin, répartiteurs de charge inactifs (facturés à l’heure même sans trafic), Elastic IP non associées — et notez que depuis qu’AWS facture toutes les adresses IPv4 publiques, chaque EIP inactive est du gaspillage pur — plus les instances arrêtées dont le stockage se facture encore, les passerelles NAT orphelines dans des VPC abandonnés et les instances RDS de dev auxquelles personne ne s’est connecté depuis des mois.

Quoi vérifier d’abord

  • Les vérifications de coûts de Trusted Advisor sous Trusted Advisor > Recommendations > Cost optimization — l’ensemble complet exige un plan de soutien Business ou Enterprise; en Basic/Developer vous n’avez qu’un sous-ensemble.
  • Cost Explorer groupé par type d’utilisation sur les trois derniers mois — les lignes EBS:VolumeUsage, ElasticIP:IdleAddress et LoadBalancerUsage vous disent quelle catégorie chasser en premier.
  • Les régions oubliées. Les orphelins adorent la région que quelqu’un a essayée une fois en 2022. Vérifiez chaque région avec la moindre dépense dans Cost Explorer.
  • La couverture d’étiquetage. Si la plupart des ressources n’ont pas d’étiquette de responsable, planifiez la chasse comme inventaire-plus-étiquetage, pas juste comme suppression.

Comment vérifier

Lancez l’inventaire par région — ces commandes sont en lecture seule :

# Volumes EBS détachés
aws ec2 describe-volumes --filters Name=status,Values=available \
  --query 'Volumes[].[VolumeId,Size,VolumeType,CreateTime]' --output table

# Elastic IP associées à rien
aws ec2 describe-addresses \
  --query 'Addresses[?AssociationId==null].[PublicIp,AllocationId]' --output table

# Instantanés que vous possédez, du plus vieux au plus récent
aws ec2 describe-snapshots --owner-ids self \
  --query 'sort_by(Snapshots,&StartTime)[].[SnapshotId,VolumeId,StartTime,VolumeSize]' \
  --output table

# Répartiteurs de charge, puis vérification des cibles de chacun
aws elbv2 describe-load-balancers \
  --query 'LoadBalancers[].[LoadBalancerName,CreatedTime]' --output table
aws elbv2 describe-target-health --target-group-arn <target-group-arn>

Un répartiteur avec des cibles saines peut quand même être inactif — confirmez avec le trafic des 30 derniers jours avant d’y toucher :

aws cloudwatch get-metric-statistics --namespace AWS/ApplicationELB \
  --metric-name RequestCount \
  --dimensions Name=LoadBalancer,Value=app/old-alb/0123456789abcdef \
  --start-time 2026-06-04T00:00:00Z --end-time 2026-07-04T00:00:00Z \
  --period 86400 --statistics Sum

Des sommes quotidiennes nulles ou presque pendant un mois sont un fort signal d’inactivité. Les équivalents console sont EC2 > Elastic Block Store > Volumes (filtre State : Available), EC2 > Network & Security > Elastic IPs, et l’onglet Monitoring de chaque répartiteur. La documentation EC2 couvre la sémantique de suppression de chaque type de ressource si vous voulez les détails fins.

Le plan d’exécution

  1. Les Elastic IP non associées d’abord. Zéro donnée, zéro risque, arrêt immédiat des frais horaires. Libérez-les sous EC2 > Elastic IPs > Release Elastic IP addresses. Pause seulement si une adresse est sur une liste blanche chez un partenaire — vérifiez avant, parce que vous ne pourrez pas ravoir la même adresse plus tard.
  2. Les volumes EBS détachés, avec un instantané de sécurité. Pour chaque volume available : instantané, étiquette avec l’ID du volume d’origine et une date de suppression, puis suppression du volume. L’instantané coûte une fraction du volume actif et préserve votre marche arrière. Le calcul de stockage est détaillé dans l’article sur le cycle de vie EBS et instantanés.
  3. Les vieux instantanés. Supprimez les instantanés manuels plus vieux que votre vrai besoin de rétention, les plus anciens d’abord. Deux pièges : les instantanés sont incrémentaux, donc en supprimer un ne libère pas toujours toute sa taille affichée; et les instantanés derrière des AMI enregistrées ne peuvent pas être supprimés avant la désinscription de l’AMI — désinscrivez les AMI mortes d’abord.
  4. Les répartiteurs de charge inactifs. Après la vérification RequestCount, supprimez le répartiteur, puis ses groupes cibles devenus orphelins. Si un DNS quelque part pointe encore vers son nom, corrigez ça d’abord — un CNAME pendant, c’est comme ça qu’un nettoyage devient un incident.
  5. Les instances arrêtées mais stockées. Une instance arrêtée ne coûte rien en calcul mais tout en EBS. Arrêtée depuis 90 jours ou plus : instantanés des volumes, AMI si vous êtes sentimental, puis terminaison.
  6. Les passerelles NAT et points de terminaison d’interface orphelins. Les deux se facturent à l’heure dans des VPC que plus personne n’utilise. Confirmez que le VPC n’a aucune instance en marche avant de supprimer.
  7. Étiquetez tout ce qui survit. Responsable, environnement, date de revue. Ça transforme une purge ponctuelle en processus répétable.

Quand c’est le mauvais choix

Ne lancez pas une suppression de masse pendant une migration ou une fenêtre de test de relève — les volumes « détachés » et les répartiteurs « inactifs » sont parfois de l’infrastructure en transit. Sautez tout ce qui appartient à un système sous conformité tant que vous n’avez pas confirmé les exigences de rétention; certains instantanés existent parce qu’un auditeur l’a exigé. Et si le compte n’a aucune discipline d’étiquetage, faites la passe inventaire-et-étiquettes d’abord et les suppressions une semaine plus tard, après que les responsables aient pu s’objecter.

Erreurs courantes

  • Libérer une Elastic IP qu’un client ou un pare-feu partenaire avait en liste blanche — l’adresse retourne au bassin et est pratiquement irrécupérable.
  • Supprimer des instantanés derrière une AMI enregistrée, puis se demander pourquoi le nettoyage de désinscription ne trouve plus rien à supprimer.
  • Juger un répartiteur inactif sur une fenêtre d’un jour au lieu d’un mois complet incluant cycles de facturation et tâches par lots.
  • Nettoyer seulement la région principale et crier victoire pendant que trois régions oubliées continuent de facturer.

Prévention

  • Une revue mensuelle de 30 minutes des orphelins bat une fouille archéologique annuelle.
  • Imposez les étiquettes responsable/environnement à la création avec des politiques d’étiquetage ou des conditions IAM.
  • Automatisez le cycle de vie des instantanés avec Data Lifecycle Manager pour rendre les chasses aux vieux instantanés inutiles.
  • Alertez sur le nombre de volumes available et d’EIP non associées avec un script planifié ou des règles AWS Config.
  • Faites du démantèlement une partie de la définition de « terminé » de chaque projet — les orphelins sont presque toujours le fantôme d’un projet fini.

La chasse aux orphelins est l’argent le plus facile du travail de coûts AWS parce que rien de ce que vous enlevez ne faisait quoi que ce soit. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.