Aller au contenu

AWS Mis à jour le 2026-07-04

Ajouter IPv6 à un VPC existant : les étapes concrètes et les pièges

Activer IPv6 sur un VPC existant n'est pas perturbateur en soi, mais la suite compte : /64 par sous-réseau, passerelle Internet de sortie seulement, règles de groupes de sécurité distinctes et configuration de l'OS. La séquence complète.

Vous pouvez ajouter IPv6 à un VPC en service sans interruption : associer un /56 fourni par Amazon au VPC, donner un /64 à chaque sous-réseau, ajouter les routes IPv6, étendre les groupes de sécurité et laisser les instances récupérer des adresses. Le résultat est une double pile — IPv4 continue de fonctionner exactement comme avant. Les pièges sont tous dans la seconde moitié de cette liste : IPv6 n’a pas de NAT sur AWS, chaque adresse est globalement unique, le « privé » dépend maintenant entièrement du routage et des groupes de sécurité, et la moitié de vos règles de groupes de sécurité ne s’appliquent silencieusement pas à la nouvelle famille d’adresses.

Ce qui se passe

L’IPv6 d’AWS diffère du modèle mental IPv4 de trois façons qui structurent toute la migration.

Premièrement, les adresses sont en unicast global. Le /56 associé est de l’espace routable publiquement; il n’y a pas d’équivalent RFC1918 en usage normal. L’adresse IPv6 d’une instance est « publique » au sens où elle est unique sur Internet — que quelqu’un puisse la joindre est décidé purement par les tables de routage et les groupes de sécurité. La confidentialité devient donc un acte de conception explicite, pas un défaut d’adressage.

Deuxièmement, il n’y a pas de NAT pour IPv6. La NAT Gateway ne traduit pas l’IPv6 (elle peut faire du NAT64 pour joindre des destinations IPv4 seulement depuis des sous-réseaux IPv6 seulement, un autre problème). Le patron du sous-réseau privé est la passerelle Internet de sortie seulement (EIGW) : avec état comme la NAT dans les faits — les instances peuvent initier des sorties IPv6, rien ne peut initier d’entrée — mais sans frais horaires ni au Go. Les sous-réseaux publics routent plutôt ::/0 vers la passerelle Internet ordinaire.

Troisièmement, tout s’active couche par couche. L’association au VPC ne fait rien tant que les sous-réseaux n’ont pas leurs /64; les sous-réseaux ne font rien tant que les tables de routage ne portent pas de routes IPv6; les paquets meurent quand même tant que les groupes de sécurité (et les NACL, si personnalisées) n’ont pas de règles IPv6 — les règles IPv4 ne couvrent jamais l’IPv6. Ensuite, l’OS doit réellement configurer l’adresse (DHCPv6 ou RA, automatique sur les AMI récentes Amazon Linux/Ubuntu, manuel sur les images plus vieilles ou durcies), et vos répartiteurs de charge doivent passer au type d’adresse dualstack avec des enregistrements AAAA avant qu’aucun trafic utilisateur n’arrive.

Quoi vérifier en premier

  • Le plan des /64 par sous-réseau — chaque sous-réseau reçoit exactement un /64 du /56 (256 disponibles), alors attribuez les créneaux hexadécimaux délibérément.
  • Des NACL personnalisées en service? Elles auront besoin de règles IPv6 explicites, ports éphémères de retour compris.
  • Les groupes de sécurité référençant 0.0.0.0/0 — décidez, règle par règle, si le jumeau IPv6 ::/0 convient; pas de copie en bloc.
  • Le comportement des AMI et de l’OS — confirmez que vos images configurent IPv6 automatiquement ou planifiez le changement cloud-init.
  • Tout ce qui journalise, met en liste ou limite par IP — règles WAF, listes d’autorisation applicatives, blocages géographiques, outils antifraude — tout doit connaître IPv6 avant que les clients arrivent par là.

Comment vérifier

# Associer un /56 fourni par Amazon au VPC
aws ec2 associate-vpc-cidr-block --vpc-id vpc-0abc123 \
  --amazon-provided-ipv6-cidr-block

# Confirmer l'allocation
aws ec2 describe-vpcs --vpc-ids vpc-0abc123 \
  --query 'Vpcs[].Ipv6CidrBlockAssociationSet'

# Donner son /64 à un sous-réseau (choisir le créneau hexa : 00, 01, 02...)
aws ec2 associate-subnet-cidr-block --subnet-id subnet-0abc123 \
  --ipv6-cidr-block 2600:1f11:abc:de00::/64

Sur une instance, confirmer l’adresse et le chemin :

ip -6 addr show dev ens5
# Connectivité globale (sous-réseau public via IGW, privé via EIGW)
curl -6 -m 5 https://checkip.amazonaws.com
ping6 -c 3 ipv6.google.com

Chemins console : VPC > Your VPCs > Actions > Edit CIDRs pour le /56, Subnets > Actions > Edit IPv6 CIDRs par sous-réseau, et EC2 > Load Balancers > Edit IP address type pour dualstack. Les détails de planification d’adresses sont dans la documentation Amazon VPC.

Le runbook

  1. Associez le /56 et tracez votre plan de /64. Utilisez la même logique palier-et-AZ que votre plan IPv4 — la discipline de conception de sous-réseaux multi-AZ s’applique telle quelle; seule l’arithmétique est devenue plus facile.
  2. Attribuez les /64 aux sous-réseaux et activez l’auto-attribution. aws ec2 modify-subnet-attribute --subnet-id subnet-0abc123 --assign-ipv6-address-on-creation pour que les nouvelles ENI reçoivent des adresses; les instances existantes ont besoin d’une adresse assignée à leur ENI ou d’un cycle via le modèle de lancement.
  3. Ajoutez les routes par palier. Sous-réseaux publics : ::/0 -> igw-.... Sous-réseaux privés : créez une passerelle de sortie seulement (aws ec2 create-egress-only-internet-gateway --vpc-id vpc-0abc123) et routez ::/0 -> eigw-.... Ne pointez jamais le ::/0 des sous-réseaux privés vers l’IGW — cette seule route rend chaque instance adressée joignable depuis Internet, avec les groupes de sécurité pour unique barrière.
  4. Étendez groupes de sécurité et NACL délibérément. Ajoutez des règles IPv6 qui reflètent l’intention, pas le texte, des règles IPv4 : les règles internes reçoivent votre /56, pas ::/0. Les NACL personnalisées exigent des entrées IPv6 en entrée et en sortie, ports éphémères compris.
  5. Allumez les bordures en dernier. Passez l’ALB/NLB en dualstack, publiez les AAAA avec un TTL court, et surveillez taux d’erreurs et journaux — c’est le moment où de vrais utilisateurs arrivent par IPv6, alors gardez le retour arrière (supprimer les AAAA) à une commande de distance.
  6. Vérifiez les deux familles de bout en bout. curl -4 et curl -6 contre le nom d’hôte public depuis l’extérieur; à l’intérieur, confirmez que les applications écoutent sur :: (qui accepte les deux) ou explicitement sur les deux familles.

Quand c’est la mauvaise approche

Si le but est seulement d’arrêter de payer le traitement NAT du trafic vers AWS, les points de terminaison VPC y arrivent sans toucher aux familles d’adresses. Si vos dépendances incluent des tiers IPv4 seulement et que vos instances passeraient en IPv6 seulement, vous vous engagez dans la complexité NAT64/DNS64 que la double pile évite — restez en double pile. Et un environnement de conformité avec des contrôles par IP éparpillés dans les applications devrait traiter IPv6 comme un projet avec une phase d’inventaire, pas comme une activation de fin de semaine.

Erreurs fréquentes

  • Router le ::/0 des sous-réseaux privés vers la passerelle Internet, exposant instantanément tout ce qui a une adresse et un groupe de sécurité ouvert.
  • Copier mécaniquement chaque règle 0.0.0.0/0 vers ::/0, y compris la règle SSH qui devait être temporaire.
  • Publier les AAAA avant le travail sur les groupes de sécurité et les NACL, si bien que les clients qui préfèrent IPv6 (la plupart des réseaux mobiles) frappent des délais pendant que les utilisateurs IPv4 ne voient rien d’anormal.
  • Oublier que points de terminaison d’interface, RDS et services plus anciens ne répondent pas tous en IPv6 — vérifiez la prise en charge double pile de chaque dépendance au lieu de la supposer.

Prévention

  • Encodez la carte des créneaux /64 dans l’IaC à côté du plan CIDR IPv4, avec palier et AZ dans le nommage.
  • Ajoutez des cas IPv6 à vos tests de joignabilité et sondes de surveillance le jour de l’activation, pas le jour de la panne.
  • Alertez sur les nouvelles routes ::/0 et sur les règles de groupes de sécurité contenant ::/0, comme vous le faites pour IPv4.
  • Déployez les AAAA service par service avec des TTL courts, en surveillant les métriques d’erreurs par famille.
  • Documentez quelles dépendances sont IPv4 seulement pour que personne ne planifie une migration IPv6 seulement autour d’elles.

La double pile sur un VPC existant est une séquence de petits pas individuellement sûrs — le risque se concentre entièrement dans le routage et l’intention des groupes de sécurité, et c’est là que votre temps de revue doit aller. 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.