Aller au contenu
Networks

Bring your own IP

BYOIP chez Google Cloud : apportez vos propres adresses IPv4 sur Compute Engine

BYOIP disponibleÉtats-UnisVérifié d'après la documentation de Google Cloud le Traduit de l'anglais. Lire l'original

Vous prouvez le contrôle du bloc avec un ROA qui nomme l'ASN de Google et un enregistrement PTR portant un nom que Google vous donne, puis vous y découpez des préfixes délégués et en tirez des adresses externes statiques.

Ce guide couvre l'IPv4 dans la configuration que Google recommande, un préfixe régional (v2) en Premium Tier, avec la gcloud CLI. Les adresses globales pour les load balancers globaux utilisent l'ancienne configuration v1, et votre projet doit d'abord figurer sur une liste d'autorisation.

Ce que Google Cloud accepte

D'après la documentation de Google Cloud, le jour de notre vérification :

  • Taille. Un public advertised prefix de « /16 to /24 » (traduction : « /16 à /24 ») en Premium Tier, le niveau par défaut, ou de « /16 to /23 » (traduction : « /16 à /23 ») en Standard Tier, qui est en Preview. Vous pouvez le découper jusqu'à des blocs /28.
  • Registre. Google renvoie vers les instructions ROA de chaque registre régional, dont l'ARIN, le RIPE NCC et l'APNIC. Il ne publie rien sur le statut PA, PI ou legacy, ni sur le nom au titre duquel le bloc doit être enregistré.
  • Qui annonce. Google, depuis AS396982 en Premium Tier ou AS19527 en Standard Tier. Il ne documente aucune option pour annoncer depuis votre propre ASN.
  • Pas de chevauchement. « Google does not support overlapping BYOIP route announcements » (traduction : « Google Cloud ne prend pas en charge les annonces de routes BYOIP qui se chevauchent ») : ni le préfixe ni aucune de ses parties ne peut être annoncé ailleurs pendant que Google l'annonce.
  • Régions. Chaque préfixe délégué sert une région, ou la portée globale. Les pages BYOIP de Google ne nomment aucune région exclue.
  • Prix. « There are no charges for idle or in-use IP addresses. » (traduction : « Les adresses IP inutilisées ou en service ne sont pas facturées. »)
  • Délai. « Approximately 2 weeks » (traduction : « environ 2 semaines ») pour un préfixe v2 après validation, « approximately 4 weeks » (traduction : « environ 4 semaines ») pour les préfixes v1 et globaux. Le provisionnement « cannot be accelerated » (traduction : « ne peut pas être accéléré »).
  • Ressources. La plupart de celles qui prennent une adresse externe statique, mais pas les nœuds et Pods GKE ni l'adresse externe d'une passerelle Cloud VPN. Les adresses ne peuvent pas passer d'un projet à un autre.

Avant de commencer

Un ROA pour l'ASN de Google. En Premium Tier, il nomme le préfixe, sa longueur exacte et AS396982. En Standard Tier, il nomme AS19527, soit dans un ROA par préfixe que vous provisionnerez, ce que Google recommande, soit dans un seul ROA avec une longueur maximale de /24 (RPKI et ROA).

Un second ROA pour votre propre ASN. Google en recommande un avec les mêmes détails et votre ASN comme origine, pour que les réseaux qui pratiquent la validation de l'origine des routes ne considèrent pas le préfixe comme invalide si vous l'annoncez un jour vous-même.

Le contrôle du DNS inverse. Google vérifie la propriété par un enregistrement PTR, pas par un jeton dans l'objet du registre. Vous choisissez une adresse inutilisée du préfixe, Google renvoie un nom (son secret partagé), et vous publiez pour cette adresse un enregistrement PTR qui pointe vers ce nom sous votre domaine.

Rien d'autre côté registre. Google ne demande ni certificat, ni lettre d'autorisation, ni objet route. De son côté, il vous faut le rôle Compute Public IP Admin (roles/compute.publicIpAdmin) sur le projet.

Étape par étape

01Créez le public advertised prefix, en nommant l'adresse qui servira à la validation DNS :

Shell
gcloud compute public-advertised-prefixes create pap-203-0-113-0-24 \
    --range=203.0.113.0/24 \
    --pdp-scope=REGIONAL \
    --dns-verification-ip=203.0.113.144

Pour le Standard Tier, utilisez gcloud beta et ajoutez --network-tier=STANDARD.

02Publiez l'enregistrement PTR. gcloud compute public-advertised-prefixes describe pap-203-0-113-0-24 --format='value(sharedSecret)' donne le nom. Si c'est 55kk88tt00 et que votre domaine est example.net, alors dig +short -x 203.0.113.144 doit renvoyer 55kk88tt00.example.net.

03Déclenchez la validation :

Shell
gcloud compute public-advertised-prefixes update pap-203-0-113-0-24 --status=PTR-CONFIGURED

Le statut passe à VALIDATED, ou à REVERSE_DNS_LOOKUP_FAILED si Google ne trouve pas l'enregistrement. Le provisionnement est terminé quand describe avec --format='value(status)' affiche PREFIX_CONFIGURATION_COMPLETE.

04Déléguez un bloc à une région. Vous pouvez le faire pendant l'attente :

Shell
gcloud compute public-delegated-prefixes create pdp-203-0-113-0-25 \
    --public-advertised-prefix=pap-203-0-113-0-24 \
    --range=203.0.113.0/25 \
    --region=europe-west4

05Créez des adresses. Les préfixes délégués publics régionaux créés après le 13 décembre 2025 permettent des adresses isolées :

Shell
gcloud compute addresses create web-1 --network-tier=PREMIUM \
    --ip-collection=pdp-203-0-113-0-25 --addresses=203.0.113.10 --region=europe-west4

Les préfixes plus anciens et les adresses globales prennent des blocs entiers, via delegated-sub-prefixes create --create-addresses. Attachez les adresses à des VM ou à des forwarding rules. Elles ne sont pas encore joignables.

06Annoncez. Assurez-vous qu'aucun autre réseau n'annonce le bloc. Annoncez d'abord le préfixe délégué, que Google transporte dans son propre réseau, puis le public advertised prefix, qui part vers Internet depuis tous les points de présence de Google :

Shell
gcloud compute public-delegated-prefixes update pdp-203-0-113-0-25 --region=europe-west4 --announce-prefix
gcloud compute public-advertised-prefixes update pap-203-0-113-0-24 --announce-prefix

Depuis l'extérieur, le validateur de RIPEstat doit déclarer le préfixe valide pour AS396982 : curl "https://stat.ripe.net/data/rpki-validation/data.json?resource=396982&prefix=203.0.113.0/24".

Les erreurs qui coûtent une journée

  • Deux réseaux qui annoncent. Le chevauchement inclut une route plus spécifique : un /24 annoncé ailleurs à l'intérieur d'un /23 que vous apportez compte. Google met en garde contre un « unexpected routing and packet loss » (traduction : « routage inattendu et perte de paquets »).
  • La v1 s'annonce d'elle-même. Un préfixe global (v1) est annoncé dès que son préfixe délégué est provisionné. Google dit de ne pas créer de préfixes délégués tant qu'un autre annonce le bloc.
  • Un ROA expiré. Si le ROA expire et que vous ne le renouvelez pas dans les quatre semaines suivant la notification de renouvellement de Google, Google cesse d'annoncer le préfixe.
  • Les noms et les régions sont figés. Renommer un préfixe impose de le supprimer et de le recréer, et déplacer un préfixe délégué vers une autre région « can take approximately eight weeks » (traduction : « peut prendre environ huit semaines »). Choisissez des noms comme pap-203-0-113-0-24 et ne déléguez que ce dont vous êtes sûr.
  • Retirer le ROA trop tôt. Après avoir supprimé un public advertised prefix, attendez 14 jours avant de retirer le ROA pour l'ASN de Google.

Si vous louez le bloc

Google ne publie aucune règle sur le nom au titre duquel le bloc est enregistré, et ne demande pas de lettre d'autorisation. Ses deux contrôles, le ROA et l'enregistrement PTR, relèvent tous deux du titulaire d'un bloc loué. Le titulaire crée le ROA pour AS396982 ou AS19527, et celui pour votre ASN si vous le souhaitez. Le titulaire crée aussi l'enregistrement PTR avec le nom de Google, ou délègue la zone inverse du bloc à des serveurs de noms que vous contrôlez. Convenez que le ROA sera renouvelé aussi longtemps que Google annonce le bloc, et conservé 14 jours après votre départ.

La place de RTM Networks

Nous louons des /24 et plus grands depuis notre propre espace d'adresses RIPE NCC, et vendons des blocs dans les régions du RIPE NCC, de l'ARIN et de l'APNIC. Pour un espace loué chez nous, nous créons le ROA pour l'ASN de Google et l'enregistrement PTR avec le nom de Google (louer de l'IPv4). S'il vous faut moins de 256 adresses sur une VM Compute Engine, nous annonçons nous-mêmes un bloc et le livrons par GRE ou WireGuard, dans toute taille jusqu'à une seule adresse (tunnels GRE et WireGuard). Comment le tarif horaire des IPv4 s'additionne chez les grands clouds : le vrai coût des IPv4 dans le cloud. Autres fournisseurs : guides BYOIP.

Contact

Vous importez vos propres adresses IP chez Google Cloud ?

Indiquez-nous le fournisseur, la région et le nombre d'adresses dont vous avez besoin. Nous louons des /24 et plus avec le travail de registre fait pour votre fournisseur, vendons des blocs en pleine propriété, ou livrons moins d'adresses par un tunnel. Nous répondons en général sous 1 à 3 heures ouvrées.

Nous contacter

FAQ

BYOIP chez Google Cloud : questions

Google Cloud prend-il en charge le BYOIP ?

Oui, nativement. Vous prouvez le contrôle d'un /24 ou plus avec un ROA qui nomme l'ASN de Google et un enregistrement PTR portant un nom que Google vous donne, puis vous en déléguez des parties à des régions et à des projets. Google ne facture rien pour les adresses, inutilisées ou en service, mais le provisionnement prend des semaines.

Quel ASN le ROA doit-il nommer pour Google Cloud ?

AS396982 en Premium Tier, le niveau par défaut, pour le préfixe à sa longueur exacte. En Standard Tier, qui est en Preview, AS19527, de préférence dans un ROA par préfixe provisionné. Google recommande aussi un second ROA avec votre propre ASN, pour que le bloc reste valide si vous l'annoncez un jour vous-même.

Combien de temps prend le BYOIP chez Google Cloud ?

Environ deux semaines après validation pour un préfixe régional (v2) et environ quatre semaines pour les préfixes v1 et globaux, et Google indique que le provisionnement ne peut pas être accéléré. Les préfixes délégués prennent ensuite quelques minutes en v2. Supprimer un préfixe prend autant de temps : planifiez donc les régions avant de commencer.

Puis-je utiliser une partie de mon bloc chez Google Cloud ?

Oui. Vous découpez le préfixe en préfixes délégués et en sous-préfixes jusqu'à un /28, chacun lié à une région et à un projet, et les préfixes délégués publics régionaux créés après le 13 décembre 2025 permettent aussi de créer des adresses isolées. Le préfixe apporté doit tout de même être un /24 ou plus.

Puis-je apporter chez Google Cloud un espace loué ?

Google ne publie aucune règle sur le nom au titre duquel le bloc est enregistré, et ne demande pas de lettre d'autorisation. Le titulaire crée le ROA pour l'ASN de Google et crée l'enregistrement PTR ou vous délègue la zone inverse. Pour un espace loué chez nous, nous créons les deux.