Arrêter les frais d'Elastic IP : Désassocier et Libérer une IP Élastique AWS

Vous avez arrêté votre instance EC2 et vous découvrez, quelques jours plus tard, que les frais continuent de s'accumuler sur votre facture AWS. L'Elastic IP attachée à cette instance génère des coûts horaires — et c'est un piège que la majorité des ingénieurs rencontrent au moins une fois en production.

TL;DR — Arrêter les frais d'Elastic IP

Situation Facturation active ? Action requise
Instance EC2 en cours d'exécution, EIP associée Non (inclus dans l'instance) Aucune
Instance EC2 arrêtée, EIP associée Oui Désassocier + Libérer
EIP allouée mais non associée Oui Libérer
EIP libérée Non —

Comment fonctionne la facturation des Elastic IPs AWS

AWS facture les Elastic IPs selon un principe simple mais contre-intuitif : une adresse IP publique statique a de la valeur uniquement si elle est utilisée activement. Quand une instance tourne et qu'une EIP lui est associée, AWS considère que cette ressource est en service — aucun frais supplémentaire pour l'EIP elle-même. Dès que l'instance s'arrête ou que l'EIP n'est plus attachée à une ressource en cours d'exécution, AWS commence à facturer l'adresse au tarif horaire, car elle occupe un espace dans le pool d'adresses IPv4 publiques sans être utilisée.

C'est comme louer un parking : tant que votre voiture est garée dedans, le tarif est inclus dans votre abonnement. Mais si vous laissez la place réservée à votre nom sans y mettre de voiture, vous payez quand même la réservation.

La logique de facturation couvre trois cas distincts :

  • EIP associée à une instance en cours d'exécution → pas de frais EIP séparés
  • EIP associée à une instance arrêtée → facturation horaire active
  • EIP allouée mais non associée à aucune ressource → facturation horaire active
graph TD A["EIP allouée dans le compte"] --> B{"Associée à une ressource ?"} B -- "Oui" --> C{"Instance en cours
d'exécution ?"} B -- "Non" --> F["Facturation active
EIP inutilisée"] C -- "Oui (running)" --> D["Pas de frais EIP
séparés"] C -- "Non (stopped)" --> E["Facturation active
EIP sur instance arrêtée"] F --> G["Action : Libérer l'EIP"] E --> H["Action : Désassocier
puis Libérer"] G --> I["Facturation stoppée"] H --> I
  1. Instance running + EIP associée : état nominal, pas de surcoût EIP.
  2. Instance stopped + EIP associée : l'EIP reste allouée dans votre compte, AWS facture l'adresse inutilisée.
  3. EIP non associée : même situation — l'adresse existe dans votre compte sans être consommée.
  4. EIP libérée : l'adresse retourne dans le pool AWS, facturation stoppée immédiatement.

Désassocier vs. Libérer — quelle différence concrète ?

Ces deux opérations sont souvent confondues, et c'est précisément là que les frais persistent sans qu'on comprenne pourquoi.

Désassocier (Disassociate) détache l'EIP de l'instance ou de l'interface réseau, mais l'adresse reste allouée dans votre compte AWS. Vous la possédez toujours — et vous payez toujours.

Libérer (Release) restitue l'adresse IP au pool AWS. L'adresse disparaît de votre compte, la facturation s'arrête. Vous ne pouvez pas récupérer cette adresse IP spécifique après libération.

Pour stopper les frais, les deux étapes sont nécessaires dans cet ordre : désassocier d'abord si l'EIP est encore attachée, puis libérer. Si l'EIP n'est déjà plus associée à rien, seule la libération suffit.

graph LR A["EIP associée
instance arrêtée"] --> B["Désassocier
disassociate-address"] B --> C["EIP non associée
facturation continue"] C --> D["Libérer
release-address"] D --> E["EIP supprimée
facturation stoppée"] F["EIP non associée
déjà détachée"] --> D
  1. Vérifier l'état de l'EIP dans votre compte.
  2. Si elle est associée à une instance arrêtée, désassocier en premier.
  3. Libérer l'EIP pour stopper définitivement la facturation.

Arrêter les frais d'Elastic IP — Procédure complète via AWS CLI

Étape 1 : Identifier les Elastic IPs facturées dans votre compte

Avant d'agir, listez toutes les EIPs allouées dans la région concernée. Les adresses sans AssociationId sont non associées et génèrent des frais. Celles associées à une instance arrêtée apparaissent avec un InstanceId mais l'instance est dans l'état stopped.

aws ec2 describe-addresses \
  --region us-east-1 \
  --query 'Addresses[*].{AllocationId:AllocationId,PublicIp:PublicIp,InstanceId:InstanceId,AssociationId:AssociationId}' \
  --output table

Repérez les lignes où AssociationId est vide ou où l'instance associée est arrêtée — ce sont les EIPs qui génèrent des frais inutiles.

Étape 2 : Vérifier l'état de l'instance associée

Si une EIP affiche un InstanceId, confirmez que l'instance est bien arrêtée avant de désassocier — une désassociation sur une instance active peut interrompre la connectivité réseau en production.

aws ec2 describe-instances \
  --instance-ids i-0abcdef1234567890 \
  --region us-east-1 \
  --query 'Reservations[*].Instances[*].{InstanceId:InstanceId,State:State.Name}' \
  --output table

Étape 3 : Désassocier l'Elastic IP

Utilisez l'AssociationId récupéré à l'étape 1. Cette opération détache l'EIP sans la libérer — la facturation continue jusqu'à la libération.

aws ec2 disassociate-address \
  --association-id eipassoc-0abcdef1234567890 \
  --region us-east-1

Étape 4 : Libérer l'Elastic IP pour stopper la facturation

Utilisez l'AllocationId de l'EIP. Après cette commande, l'adresse IP disparaît définitivement de votre compte. Si vous avez besoin de cette adresse dans un DNS ou une liste blanche, mettez à jour ces configurations avant de libérer.

aws ec2 release-address \
  --allocation-id eipalloc-0abcdef1234567890 \
  --region us-east-1

Étape 5 : Confirmer la libération

Vérifiez que l'EIP n'apparaît plus dans la liste des adresses allouées.

aws ec2 describe-addresses \
  --region us-east-1 \
  --query 'Addresses[*].{AllocationId:AllocationId,PublicIp:PublicIp}' \
  --output table

Cas particulier : EIP associée à une interface réseau (ENI)

Une EIP peut être associée directement à une interface réseau Elastic (ENI) plutôt qu'à une instance. Dans ce cas, même si l'instance est supprimée, l'EIP reste attachée à l'ENI et continue d'être facturée. La commande describe-addresses retourne un NetworkInterfaceId dans ce cas — pensez à vérifier ce champ si vous ne trouvez pas d'instance associée.

aws ec2 describe-addresses \
  --region us-east-1 \
  --query 'Addresses[*].{AllocationId:AllocationId,PublicIp:PublicIp,NetworkInterfaceId:NetworkInterfaceId,InstanceId:InstanceId}' \
  --output table

Pour désassocier une EIP d'une ENI, la commande disassociate-address avec l'AssociationId fonctionne de la même façon.

Expérience terrain : le diagnostic qui prend du temps

Le scénario classique : une instance de développement est arrêtée un vendredi soir. L'ingénieurs vérifie la console EC2, voit l'instance stoppée, et suppose que les frais s'arrêtent. Deux semaines plus tard, la facture AWS affiche des charges inattendues.

Le premier réflexe est de chercher une instance qui aurait redémarré automatiquement — Auto Scaling, Lambda, une tâche planifiée. On passe du temps à vérifier les CloudTrail logs pour des événements StartInstances. Rien.

La cause réelle : l'EIP était toujours allouée, associée à l'instance arrêtée. La console EC2 dans la section 'Instances' ne montre pas les EIPs de façon proéminente quand l'instance est stoppée. Il faut aller explicitement dans Réseau et sécurité → Adresses IP élastiques pour voir l'état réel.

Le signal dans Cost Explorer : une ligne EC2-EIP:IdleAddress dans le détail des coûts par service. C'est ce libellé qui confirme qu'une EIP inutilisée est facturée — pas un coût d'instance, pas un coût de transfert de données.

Automatiser la détection des EIPs inutilisées

En environnement multi-comptes ou multi-régions, la vérification manuelle n'est pas viable. AWS Config propose la règle gérée eip-attached qui signale les EIPs non associées à une instance ou une interface réseau en cours d'exécution. Cette règle peut déclencher une alerte SNS ou une action corrective via AWS Systems Manager Automation.

🔽 Script de détection des EIPs non utilisées (toutes régions) 
#!/bin/bash
# Lister les EIPs non associées dans toutes les régions disponibles
for region in $(aws ec2 describe-regions --query 'Regions[*].RegionName' --output text); do
  echo "=== Region: $region ==="
  aws ec2 describe-addresses \
    --region "$region" \
    --query 'Addresses[?AssociationId==null].{AllocationId:AllocationId,PublicIp:PublicIp,Region:to_string(`'"$region"'`)}' \
    --output table
done

Permissions IAM minimales pour gérer les Elastic IPs

Pour exécuter les opérations de désassociation et libération, le principal IAM doit disposer des permissions suivantes. Appliquez le principe du moindre privilège en restreignant la portée aux ressources concernées autant que possible — notez que certaines actions EIP nécessitent Resource: "*" selon la documentation de référence des autorisations de service AWS.

🔽 Politique IAM minimale pour gérer les EIPs 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DescribeAddresses",
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeAddresses",
        "ec2:DescribeInstances"
      ],
      "Resource": "*"
    },
    {
      "Sid": "ManageEIP",
      "Effect": "Allow",
      "Action": [
        "ec2:DisassociateAddress",
        "ec2:ReleaseAddress"
      ],
      "Resource": "*"
    }
  ]
}

Arrêter les frais d'Elastic IP — Points clés et prochaines étapes

Arrêter une instance EC2 ne suffit pas à stopper les frais d'une Elastic IP associée. La désassociation détache l'adresse mais ne supprime pas la facturation. Seule la libération de l'EIP met fin aux charges. Si vous n'avez pas besoin de conserver cette adresse IP statique, libérez-la dès que l'instance est arrêtée.

Pour éviter ce problème à l'avenir :

  • Activez la règle AWS Config eip-attached dans chaque région active.
  • Consultez régulièrement Cost Explorer avec le filtre EC2-EIP:IdleAddress pour détecter les adresses inutilisées.
  • Documentez les EIPs utilisées dans des DNS ou listes blanches avant de les libérer — une fois libérée, l'adresse ne peut pas être récupérée.

Consultez la documentation officielle AWS sur les Elastic IP Addresses et la page de tarification EC2 pour les taux horaires actuels.

Glossaire

Terme Définition
Elastic IP (EIP) Adresse IPv4 publique statique allouée à un compte AWS, réassignable entre instances dans la même région.
Désassocier (Disassociate) Détacher une EIP d'une instance ou ENI sans la libérer du compte. La facturation continue.
Libérer (Release) Restituer une EIP au pool AWS. L'adresse disparaît du compte et la facturation s'arrête.
AllocationId Identifiant unique d'une EIP dans un compte AWS (format eipalloc-XXXXXXXXX).
ENI (Elastic Network Interface) Interface réseau virtuelle attachable à une instance EC2, pouvant recevoir une EIP indépendamment de l'instance.

Commentaires

Enregistrer un commentaire

Posts les plus consultés de ce blog

Groupes IAM AWS : Pourquoi Attacher les Politiques aux Groupes Plutôt qu'aux Utilisateurs

Vous venez d'intégrer trois nouveaux développeurs dans votre équipe. Vous créez leurs utilisateurs IAM, puis vous commencez à attacher les politiques une par une à chaque compte — et c'est là que le problème commence. Six mois plus tard, un développeur change de rôle, et personne ne sait exactement quelles permissions il possède ni pourquoi. TL;DR — Groupes IAM vs. Politiques Directes Critère Politiques directes sur l'utilisateur Politiques via Groupe IAM Auditabilité Difficile — chaque utilisateur est une île Claire — une politique, un groupe, N utilisateurs Gestion à l'échelle O(N) opérations pour N utilisateurs O(1) — modifier le groupe suffit Risque d'erreur Élevé — oubli fréquent lors des offboardings Faible — retirer l'utilisateur du groupe suffit Conformité (moindre...
Lire la suite

LSI vs GSI dans DynamoDB : choisir le bon index secondaire

Vous avez modélisé votre table DynamoDB autour d'une clé de partition, puis le jour où un nouveau cas d'usage apparaît — filtrer les commandes par statut, rechercher les utilisateurs par email — vous réalisez que la clé primaire ne suffit plus. C'est exactement là que les index secondaires entrent en jeu, et le choix entre un LSI et un GSI a des conséquences directes sur la cohérence des lectures, la capacité de la table et les contraintes de conception. TL;DR — LSI vs GSI dans DynamoDB Critère LSI (Local Secondary Index) GSI (Global Secondary Index) Clé de partition Identique à la table de base N'importe quel attribut Clé de tri Attribut différent de la table N'importe quel attribut (optionnel) Création Uniquement à la création de la table À tout moment Cohérence des lectures Fortement cohérente possible Éventuellement cohérente uniquement Capacité Partagée avec la table de base ...
Lire la suite

NAT Gateway vs NAT Instance : Quelle solution choisir pour vos instances privées ?

Vous venez de déployer vos premières instances EC2 dans un sous-réseau privé et vous réalisez qu'elles ne peuvent pas télécharger les mises à jour système — aucune route vers internet. La question qui suit est systématique : faut-il provisionner un NAT Gateway managé ou lancer une instance EC2 configurée comme NAT Instance ? Ce choix impacte directement la disponibilité, les coûts opérationnels et la charge de maintenance de votre infrastructure. TL;DR — NAT Gateway vs NAT Instance Critère NAT Gateway NAT Instance Gestion Entièrement managé par AWS Vous gérez l'OS, les patches, la HA Disponibilité Haute disponibilité dans une AZ Dépend de votre configuration Bande passante Scalabilité automatique jusqu'aux limites du service Limitée par le type d'instance EC2 Modèle de coût ...
Lire la suite