Fourniture de vos propres adresses IP (BYOIP) dans Amazon EC2 - Amazon Elastic Compute Cloud
Définitions BYOIPExigences et quotasConditions préalables à l’onboardingIntégrer votre BYOIPUtiliser votre plage d’adressesValider votre BYOIPDisponibilité par régionDisponibilité de la zone localeEn savoir plus

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Fourniture de vos propres adresses IP (BYOIP) dans Amazon EC2

Vous pouvez transférer une partie ou la totalité de votre plage d'adresses IPv4 ou IPv6 routables publiquement de votre réseau local vers votre compte. AWS Vous continuez à contrôler la plage d'adresses et vous pouvez la publier sur Internet via AWS. Une fois que vous avez transféré la plage d'adresses AWS, elle apparaît dans votre AWS compte sous forme de pool d'adresses.

Pour obtenir la liste des régions où BYOIP est disponible, consultez Disponibilité par région.

Pour afficher les informations BYOIP pour les instances Windows, consultez cette page dans le Guide de l’utilisateur Amazon EC2 pour les instances Windows : Fourniture de vos propres adresses IP (BYOIP) dans Amazon EC2.

Note

  • Les étapes de cette page décrivent comment fournir votre propre plage d’adresses IP pour l’utiliser dans Amazon EC2 uniquement.

  • Pour apporter votre propre plage d'adresses IP à utiliser AWS Global Accelerator, consultez la section Apporter vos propres adresses IP (BYOIP) dans le guide du AWS Global Accelerator développeur.

  • Pour apporter votre propre plage d'adresses IP à utiliser Amazon VPC IP Address Manager, consultez le didacticiel : Transférer vos adresses IP à l'IPAM dans le guide de l'utilisateur Amazon VPC IPAM.

Définitions BYOIP

  • Certificat auto-signé X.509 : norme de certificat la plus couramment utilisée pour chiffrer et authentifier les données au sein d’un réseau. Il s'agit d'un certificat utilisé AWS pour valider le contrôle de l'espace IP à partir d'un enregistrement RDAP. Pour plus d’informations sur les certificats X.509, consultez RFC 3280.

  • Numéro de système autonome (ASN) : identifiant unique au monde qui définit un groupe de préfixes IP gérés par un ou plusieurs opérateurs réseau qui appliquent une politique de routage unique et clairement définie.

  • Registre Internet régional (RIR) : organisation qui gère l’attribution et l’enregistrement des adresses IP et des ASN dans une région du monde.

  • Protocole d’accès aux données de registre (RDAP) : protocole en lecture seule permettant d’interroger les données d’enregistrement actuelles dans un RIR. Les entrées de la base de données RIR interrogée sont appelées « enregistrements RDAP ». Certains types d’enregistrements doivent être mis à jour par les clients via un mécanisme fourni par le RIR. Ces enregistrements sont interrogés AWS pour vérifier le contrôle d'un espace d'adressage dans le RIR.

  • Autorisation d’origine d’itinéraire (ROA) : objet créé par les RIR pour que les clients authentifient la publicité IP, en particulier les systèmes autonomes. Pour obtenir une présentation, consultez Autorisation d’origine d’itinéraire (ROA) sur le site web d’ARIN.

  • Registre Internet local (LIR) : organisations telles que les fournisseurs de services Internet qui allouent un bloc d’adresses IP à partir d’un RIR à leurs clients.

Exigences et quotas

  • La plage d'adresses doit être enregistrée dans votre registre Internet régional (RIR). Consultez votre RIR pour connaître les politiques relatives aux régions géographiques. BYOIP prend actuellement en charge l’enregistrement dans l’ARIN (American Registry for Internet Numbers), le RIPE (Réseaux IP Européens Network Coordination Centre) ou l’APNIC (Asia-Pacific Network Information Centre). Elle doit être enregistrée pour une entreprise ou une entité institutionnelle et ne peut pas être enregistrée pour une personne individuelle.

  • La plage d’adresses IPv4 la plus spécifique que vous pouvez apporter est /24.

  • La plage d'adresses IPv6 la plus spécifique que vous pouvez apporter est /48 pour les CIDR pouvant faire l'objet d'une publicité publique et /56 pour les CIDR qui ne le sont pas.

  • Les ROA ne sont pas nécessaires pour les plages CIDR qui ne sont pas publiquement publiées, mais les registres RDAP doivent toujours être mis à jour.

  • Vous pouvez attribuer chaque plage d'adresses à une AWS région à la fois.

  • Vous pouvez ajouter à votre compte un total de cinq plages d'adresses BYOIP IPv4 et IPv6 par AWS région. AWS Vous ne pouvez pas ajuster les quotas pour les CIDR BYOIP à l'aide de la console Service Quotas, mais vous pouvez demander une augmentation des quotas en contactant le AWS Support Center comme décrit dans la section Quotas de AWS service du. Références générales AWS

  • Vous ne pouvez pas partager votre plage d'adresses IP avec d'autres comptes, AWS RAM sauf si vous utilisez Amazon VPC IP Address Manager (IPAM) et si vous intégrez IPAM à Organizations. AWS Pour plus d'informations, consultez Intégrer l'IPAM aux AWS organisations dans le guide de l'utilisateur Amazon VPC IPAM.

  • L’historique des adresses de la plage d’adresses IP doit être propre. Nous pouvons enquêter sur la réputation de la plage d’adresses IP et nous réserver le droit de rejeter une plage d’adresses IP si elle contient une adresse IP qui a une mauvaise réputation ou qui est associée à un comportement malveillant.

  • L’espace d’adressage hérité IPv4 qui était distribué par le registre central de l’IANA (Internet Assigned Numbers Authority) avant la création du système de registre Internet régional (RIR), nécessite toujours un objet ROA correspondant.

  • Il est courant que les LIR utilisent un processus manuel pour mettre à jour leurs registres. Ce déploiement peut prendre plusieurs jours en fonction de la LIR.

  • Un seul objet ROA et un registre RDAP sont nécessaires pour un bloc d’adresse CIDR volumineux. Vous pouvez transférer plusieurs blocs CIDR plus petits de cette plage AWS, même dans plusieurs AWS régions, en utilisant un seul objet et un seul enregistrement.

  • Le BYOIP n'est pas pris en charge pour Wavelength Zones ou versions ultérieures. AWS Outposts

  • N’apportez aucune modification manuelle à BYOIP dans RADb ou dans tout autre IRR. BYOIP mettra automatiquement à jour RADb. Toute modification manuelle incluant l’ASN de BYOIP entraînera l’échec de l’opération de mise à disposition de BYOIP.

  • Une fois que vous avez transféré une plage d'adresses IPv4 AWS, vous pouvez utiliser toutes les adresses IP de la plage, y compris la première adresse (adresse réseau) et la dernière adresse (adresse de diffusion).

Conditions préalables à l’onboarding de votre plage d’adresses BYOIP

Le processus d’onboarding de BYOIP comporte deux phases, pour lesquelles vous devez effectuer trois étapes. Ces étapes correspondent aux étapes décrites dans le diagramme suivant. Nous incluons des étapes manuelles dans cette documentation, mais votre RIR peut proposer des services gérés pour vous aider au cours de ces étapes.

Phase de préparation

1. Créez une paire de clés RSA et utilisez-la pour générer un certificat X.509 auto-signé à des fins d’authentification. Ce certificat n’est utilisé que pendant la phase d’allocation.

Phase de configuration RIR

2. Chargez le certificat auto-signé dans vos commentaires de registre RDAP.

3. Créez un objet ROA dans votre RIR. Le ROA définit la plage d’adresses souhaitée, les numéros système autonomes (ASN) autorisés à publier la plage d’adresses et une date d’expiration à enregistrer avec l’infrastructure RPKI (Resource Public Key Infrastructure) de votre RIR.

Note

Un ROA n’est pas nécessaire pour les espaces d’adressage IPv6 qui ne sont pas publiquement publiés.

Le processus d’intégration de BYOIP comporte trois étapes.

Pour ajouter plusieurs plages d’adresses non-contiguës, vous devez répéter ce processus avec chacune d’elles. Cependant, il n'est pas nécessaire de répéter les étapes de préparation et de configuration du RIR si vous divisez un bloc contigu sur plusieurs régions différentes. AWS

L’ajout d’une plage d’adresses n’a aucun effet sur les plages d’adresses que vous avez ajoutées précédemment.

Important

Avant d’intégrer votre plage d’adresses, respectez les prérequis suivants. Les tâches de cette section nécessitent un terminal Linux et peuvent être effectuées à l'aide de Linux, du AWS CloudShell ou du sous-système Windows pour Linux.

1. Création d’une clé privée et génération d’un certificat X.509

Utilisez la procédure suivante pour créer un certificat X509 auto-signé et l’ajouter au registre RDAP de votre RIR. Cette paire de clés est utilisée pour authentifier la plage d’adresses auprès du RIR. Les commandes openssl exigent OpenSSL version 1.0.2 ou ultérieure.

Copiez les commandes suivantes et remplacez uniquement les valeurs d’espace réservé (en italique et en couleur).

Cette procédure suit la bonne pratique consistant à chiffrer votre clé RSA privée et à exiger une phrase secrète pour y accéder.

  1. Générez une paire de clés RSA 2048 bits comme indiqué ci-après.

    $ openssl genpkey -aes256 -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out private-key.pem

    Le paramètre -aes256 spécifie l’algorithme utilisé pour chiffrer la clé privée. La commande renvoie la sortie suivante, y compris les invites pour définir une phrase secrète :

    ......+++
.+++
Enter PEM pass phrase: xxxxxxx
Verifying - Enter PEM pass phrase: xxxxxxx

    Vous pouvez inspecter la clé publique à l’aide de la commande suivante :

    $ openssl pkey -in private-key.pem -text

    Cela renvoie une invite de phrase secrète et le contenu de la clé, qui devrait être similaire à ce qui suit :

    Enter pass phrase for private-key.pem: xxxxxxx
-----BEGIN PRIVATE KEY-----
MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQDFBXHRI4HVKAhh
3seiciooizCRTbJe1+YsxNTja4XyKypVGIFWDGhZs44FCHlPOOSVJ+NqP74w96oM
7DPS3xo9kaQyZBFn2YEp2EBq5vf307KHNRmZZUmkn0zHOSEpNmY2fMxISBxewlxR
FAniwmSd/8TDvHJMY9FvAIvWuTsv5l0tJKk+a91K4+tO3UdDR7Sno5WXExfsBrW3
g1ydo3TBsx8i5/YiVOcNApy7ge2/FiwY3aCXJB6r6nuF6H8mRgI4r4vkMRsOlAhJ
DnZPNeweboo+K3Q3lwbgbmOKD/z9svk8N/+hUTBtIX0fRtbG+PLIw3xWRHGrMSn2
BzsPVuDLAgMBAAECggEACiJUj2hfJkKv47Dc3es3Zex67A5uDVjXmxfox2Xhdupn
fAcNqAptV6fXt0SPUNbhUxbBKNbshoJGufFwXPli1SXnpzvkdU4Hyco4zgbhXFsE
RNYjYfOGzTPwdBLpNMB6k3Tp4RHse6dNrlH0jDhpioL8cQEBdBJyVF5X0wymEbmV
mC0jgH/MxsBAPWW6ZKicg9ULMlWiAZ3MRAZPjHHgpYkAAsUWKAbCBwVQcVjGO59W
jfZjzTX5pQtVVH68ruciH88DTZCwjCkjBhxg+OIkJBLE5wkh82jIHSivZ63flwLw
z+E0+HhELSZJrn2MY6Jxmik3qNNUOF/Z+3msdj2luQKBgQDjwlC/3jxp8zJy6P8o
JQKv7TdvMwUj4VSWOHZBHLv4evJaaia0uQjIo1UDa8AYitqhX1NmCCehGH8yuXj/
v6V3CzMKDkmRr1NrONnSz5QsndQ04Z6ihAQlPmJ96g4wKtgoC7AYpyP0g1a+4/sj
b1+o3YQI4pD/F71c+qaztH7PRwKBgQDdc23yNmT3+Jyptf0fKjEvONK+xwUKzi9c
L/OzBq5yOIC1Pz2T85gOe1i8kwZws+xlpG6uBT6lmIJELd0k59FyupNu4dPvX5SD
6GGqdx4jk9KvI74usGeOBohmF0phTHkrWKBxXiyT0oS8zjnJlEn8ysIpGgO28jjr
LpaHNZ/MXQKBgQDfLNcnS0LzpsS2aK0tzyZU8SMyqVHOGMxj7quhneBq2T6FbiLD
T9TVlYaGNZ0j71vQaLI19qOubWymbautH0Op5KV8owdf4+bf1/NJaPIOzhDUSIjD
Qo01WW31Z9XDSRhKFTnWzmCjBdeIcajyzf10YKsycaAW9lItu8aBrMndnQKBgQDb
nNp/JyRwqjOrNljk7DHEs+SD39kHQzzCfqd+dnTPv2sc06+cpym3yulQcbokULpy
fmRo3bin/pvJQ3aZX/Bdh9woTXqhXDdrrSwWInVYMQPyPk8f/D9mIOJp5FUWMwHD
U+whIZSxsEeE+jtixlWtheKRYkQmzQZXbWdIhYyI3QKBgD+F/6wcZ85QW8nAUykA
3WrSIx/3cwDGdm4NRGct8ZOZjTHjiy9ojMOD1L7iMhRQ/3k3hUsin5LDMp/ryWGG
x4uIaLat40kiC7T4I66DM7P59euqdz3w0PD+VU+h7GSivvsFDdySUt7bNK0AUVLh
dMJfWxDN8QV0b5p3WuWH1U8B
-----END PRIVATE KEY-----
Private-Key: (2048 bit)
modulus:
    00:c5:05:71:d1:23:81:d5:28:08:61:de:c7:a2:72:
    2a:28:8b:30:91:4d:b2:5e:d7:e6:2c:c4:d4:e3:6b:
    85:f2:2b:2a:55:18:81:56:0c:68:59:b3:8e:05:08:
    79:4f:38:e4:95:27:e3:6a:3f:be:30:f7:aa:0c:ec:
    33:d2:df:1a:3d:91:a4:32:64:11:67:d9:81:29:d8:
    40:6a:e6:f7:f7:d3:b2:87:35:19:99:65:49:a4:9f:
    4c:c7:39:21:29:36:66:36:7c:cc:48:48:1c:5e:c2:
    5c:51:14:09:e2:c2:64:9d:ff:c4:c3:bc:72:4c:63:
    d1:6f:00:8b:d6:b9:3b:2f:e6:5d:2d:24:a9:3e:6b:
    dd:4a:e3:eb:4e:dd:47:43:47:b4:a7:a3:95:97:13:
    17:ec:06:b5:b7:83:5c:9d:a3:74:c1:b3:1f:22:e7:
    f6:22:54:e7:0d:02:9c:bb:81:ed:bf:16:2c:18:dd:
    a0:97:24:1e:ab:ea:7b:85:e8:7f:26:46:02:38:af:
    8b:e4:31:1b:0e:94:08:49:0e:76:4f:35:ec:1e:6e:
    8a:3e:2b:74:37:97:06:e0:6e:63:8a:0f:fc:fd:b2:
    f9:3c:37:ff:a1:51:30:6d:21:7d:1f:46:d6:c6:f8:
    f2:c8:c3:7c:56:44:71:ab:31:29:f6:07:3b:0f:56:
    e0:cb
publicExponent: 65537 (0x10001)
privateExponent:
    0a:22:54:8f:68:5f:26:42:af:e3:b0:dc:dd:eb:37:
    65:ec:7a:ec:0e:6e:0d:58:d7:9b:17:e8:c7:65:e1:
    76:ea:67:7c:07:0d:a8:0a:6d:57:a7:d7:b7:44:8f:
    50:d6:e1:53:16:c1:28:d6:ec:86:82:46:b9:f1:70:
    5c:f9:62:d5:25:e7:a7:3b:e4:75:4e:07:c9:ca:38:
    ce:06:e1:5c:5b:04:44:d6:23:61:f3:86:cd:33:f0:
    74:12:e9:34:c0:7a:93:74:e9:e1:11:ec:7b:a7:4d:
    ae:51:f4:8c:38:69:8a:82:fc:71:01:01:74:12:72:
    54:5e:57:d3:0c:a6:11:b9:95:98:2d:23:80:7f:cc:
    c6:c0:40:3d:65:ba:64:a8:9c:83:d5:0b:32:55:a2:
    01:9d:cc:44:06:4f:8c:71:e0:a5:89:00:02:c5:16:
    28:06:c2:07:05:50:71:58:c6:3b:9f:56:8d:f6:63:
    cd:35:f9:a5:0b:55:54:7e:bc:ae:e7:22:1f:cf:03:
    4d:90:b0:8c:29:23:06:1c:60:f8:e2:24:24:12:c4:
    e7:09:21:f3:68:c8:1d:28:af:67:ad:df:97:02:f0:
    cf:e1:34:f8:78:44:2d:26:49:ae:7d:8c:63:a2:71:
    9a:29:37:a8:d3:54:38:5f:d9:fb:79:ac:76:3d:a5:
    b9
prime1:
    00:e3:c2:50:bf:de:3c:69:f3:32:72:e8:ff:28:25:
    02:af:ed:37:6f:33:05:23:e1:54:96:38:76:41:1c:
    bb:f8:7a:f2:5a:6a:26:b4:b9:08:c8:a3:55:03:6b:
    c0:18:8a:da:a1:5f:53:66:08:27:a1:18:7f:32:b9:
    78:ff:bf:a5:77:0b:33:0a:0e:49:91:af:53:6b:38:
    d9:d2:cf:94:2c:9d:d4:34:e1:9e:a2:84:04:25:3e:
    62:7d:ea:0e:30:2a:d8:28:0b:b0:18:a7:23:f4:83:
    56:be:e3:fb:23:6f:5f:a8:dd:84:08:e2:90:ff:17:
    bd:5c:fa:a6:b3:b4:7e:cf:47
prime2:
    00:dd:73:6d:f2:36:64:f7:f8:9c:a9:b5:fd:1f:2a:
    31:2f:38:d2:be:c7:05:0a:ce:2f:5c:2f:f3:b3:06:
    ae:72:38:80:b5:3f:3d:93:f3:98:0e:7b:58:bc:93:
    06:70:b3:ec:65:a4:6e:ae:05:3e:a5:98:82:44:2d:
    dd:24:e7:d1:72:ba:93:6e:e1:d3:ef:5f:94:83:e8:
    61:aa:77:1e:23:93:d2:af:23:be:2e:b0:67:8e:06:
    88:66:17:4a:61:4c:79:2b:58:a0:71:5e:2c:93:d2:
    84:bc:ce:39:c9:94:49:fc:ca:c2:29:1a:03:b6:f2:
    38:eb:2e:96:87:35:9f:cc:5d
exponent1:
    00:df:2c:d7:27:4b:42:f3:a6:c4:b6:68:ad:2d:cf:
    26:54:f1:23:32:a9:51:ce:18:cc:63:ee:ab:a1:9d:
    e0:6a:d9:3e:85:6e:22:c3:4f:d4:d5:95:86:86:35:
    9d:23:ef:5b:d0:68:b2:35:f6:a3:ae:6d:6c:a6:6d:
    ab:ad:1f:43:a9:e4:a5:7c:a3:07:5f:e3:e6:df:d7:
    f3:49:68:f2:0e:ce:10:d4:48:88:c3:42:8d:35:59:
    6d:f5:67:d5:c3:49:18:4a:15:39:d6:ce:60:a3:05:
    d7:88:71:a8:f2:cd:fd:74:60:ab:32:71:a0:16:f6:
    52:2d:bb:c6:81:ac:c9:dd:9d
exponent2:
    00:db:9c:da:7f:27:24:70:aa:33:ab:36:58:e4:ec:
    31:c4:b3:e4:83:df:d9:07:43:3c:c2:7e:a7:7e:76:
    74:cf:bf:6b:1c:d3:af:9c:a7:29:b7:ca:e9:50:71:
    ba:24:50:ba:72:7e:64:68:dd:b8:a7:fe:9b:c9:43:
    76:99:5f:f0:5d:87:dc:28:4d:7a:a1:5c:37:6b:ad:
    2c:16:22:75:58:31:03:f2:3e:4f:1f:fc:3f:66:20:
    e2:69:e4:55:16:33:01:c3:53:ec:21:21:94:b1:b0:
    47:84:fa:3b:62:c6:55:ad:85:e2:91:62:44:26:cd:
    06:57:6d:67:48:85:8c:88:dd
coefficient:
    3f:85:ff:ac:1c:67:ce:50:5b:c9:c0:53:29:00:dd:
    6a:d2:23:1f:f7:73:00:c6:76:6e:0d:44:67:2d:f1:
    93:99:8d:31:e3:8b:2f:68:8c:c3:83:d4:be:e2:32:
    14:50:ff:79:37:85:4b:22:9f:92:c3:32:9f:eb:c9:
    61:86:c7:8b:88:68:b6:ad:e3:49:22:0b:b4:f8:23:
    ae:83:33:b3:f9:f5:eb:aa:77:3d:f0:d0:f0:fe:55:
    4f:a1:ec:64:a2:be:fb:05:0d:dc:92:52:de:db:34:
    ad:00:51:52:e1:74:c2:5f:5b:10:cd:f1:05:74:6f:
    9a:77:5a:e5:87:d5:4f:01

    Conservez votre clé privée dans un endroit sécurisé lorsqu’elle n’est pas utilisée.

  2. Générez un certificat X.509 à l’aide de la paire de clés créée à l’étape précédente. Dans cet exemple, le certificat expire dans 365 jours, après quoi il n’est plus fiable. Veillez donc à définir l’expiration de façon appropriée. Le certificat ne doit être valide que pendant la durée du processus de provisionnement. Vous pouvez supprimer le certificat du dossier de votre RIR une fois le provisionnement terminé. La commande tr -d "\n" supprime les caractères de nouvelle ligne (sauts de ligne) de la sortie. Vous devez fournir un nom commun lorsque vous y êtes invité, mais les autres champs peuvent être laissés vides.

    $ openssl req -new -x509 -key private-key.pem -days 365 | tr -d "\n" > certificate.pem

    Cela génère une sortie semblable à ce qui suit :

    Enter pass phrase for private-key.pem: xxxxxxx
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) []:
State or Province Name (full name) []:
Locality Name (eg, city) []:
Organization Name (eg, company) []:
Organizational Unit Name (eg, section) []:
Common Name (eg, fully qualified host name) []:example.com
Email Address []:
    Note

    Le nom commun n'est pas nécessaire pour le AWS provisionnement. Il peut s’agir de n’importe quel nom de domaine interne ou public.

    Vous pouvez inspecter le certificat à l’aide de la commande suivante :

    $ cat certificate.pem

    La sortie doit être une longue chaîne codée PEM sans sauts de ligne, préfacée par -----BEGIN CERTIFICATE----- et suivi de -----END CERTIFICATE-----.

2. Chargement du certificat X.509 dans l’enregistrement RDAP de votre RIR

Ajoutez le certificat que vous avez créé précédemment au registre RDAP pour votre RIR. Veillez à inclure le -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- avant et après la partie encodée. Tout ce contenu doit se trouver sur une seule et longue ligne. La procédure de mise à jour de RDAP dépend de votre RIR :

  • Pour ARIN, utilisez le portail Account Manager pour ajouter le certificat dans la section « Commentaires publics » pour l’objet « Informations réseau » représentant votre plage d’adresses. Ne l’ajoutez pas à la section des commentaires de votre organisation.

  • Pour RIPE, ajoutez le certificat en tant que nouveau champ « descr » à l’objet « inetnum » ou « inet6num » représentant votre plage d’adresses. Vous les trouverez généralement dans la section « Mes ressources » du portail de la base de données RIPE. Ne l’ajoutez pas dans la section des commentaires de votre organisation ni dans le champ « remarques » des objets ci-dessus.

  • Pour l’APNIC, envoyez le certificat par e-mail à l’adresse helpdesk@apnic.net afin de l’ajouter manuellement au champ « remarks » (remarques) pour votre plage d’adresses. Envoyez l’e-mail en utilisant le contact autorisé APNIC pour les adresses IP.

Vous pouvez supprimer le certificat de l’enregistrement de votre RIR une fois l’étape d’allocation ci-dessous terminée.

3. Création d’un objet ROA dans votre RIR

Créez un objet ROA pour autoriser les ASN 16509 et 14618 d’Amazon à publier votre plage d’adresses et les ASN qui sont actuellement autorisés à publier la plage d’adresses. Pour le AWS GovCloud (US) Regions, autorisez l'ASN 8987 au lieu de 16509 et 14618. Vous devez définir la longueur maximale sur la taille du CIDR que vous apportez. Le préfixe IPv4 le plus spécifique que vous pouvez apporter est /24. La plage d’adresses IPv6 la plus spécifique que vous pouvez apporter est /48 pour les CIDR publiquement publiés et /56 pour les CIDR qui ne sont pas publiquement publiés.

Important

Si vous créez un objet ROA pour Amazon VPC IP Address Manager (IPAM), lorsque vous créez les ROA, pour les CIDR IPv4, vous devez définir la longueur maximale d’un préfixe d’adresse IP sur /24. Pour les CIDR IPv6, si vous les ajoutez à un groupe annoncé, la longueur maximale d’un préfixe d’adresse IP doit être /48. Cela vous garantit une flexibilité totale pour répartir votre adresse IP publique entre AWS les régions. L’IPAM applique la longueur maximale que vous avez définie. Pour plus d’informations sur les adresses BYOIP vers IPAM, consultez Tutoriel : BYOIP transfert des CIDR vers IPAM dans le Guide de l’utilisateur Amazon VPC IPAM.

La mise à disposition de la ROA sur Amazon peut prendre jusqu’à 24 heures. Pour plus d’informations, consultez votre RIR :

Lorsque vous migrez des publicités d'une charge de travail sur site vers AWS, vous devez créer un ROA pour votre ASN existant avant de créer les ROA pour les ASN d'Amazon. Sinon, vous risquez de voir un impact sur votre routage et vos annonces existantes.

Important

Pour qu’Amazon puisse annoncer votre plage d’adresses IP et continuer à le faire, vos ROA avec les ASN d’Amazon doivent être conformes aux lignes directrices susmentionnées. Si vos ROA ne sont pas valides ou ne sont pas conformes aux directives ci-dessus, Amazon se réserve le droit de cesser de faire de la publicité pour votre plage d'adresses IP.

Note

Cette étape n’est pas nécessaire pour les espaces d’adressage IPv6 qui ne sont pas publiquement publiés.

Intégrer votre BYOIP

Le processus d’onboarding de BYOIP comporte les tâches suivantes selon vos besoins :

Allocation d’une plage d’adresses publiquement publiée dans AWS

Lorsque vous configurez une plage d'adresses à utiliser avec AWS, vous confirmez que vous contrôlez la plage d'adresses et que vous autorisez Amazon à en faire la publicité. Nous vérifions également que vous contrôlez la plage d’adresses via un message d’autorisation signé. Ce message est signé avec la paire de clés X.509 auto-signée que vous avez utilisée lors de la mise à jour de l'enregistrement RDAP avec le certificat X.509. AWS nécessite un message d'autorisation signé cryptographiquement qu'il présente au RIR. Le RIR authentifie la signature par rapport au certificat que vous avez ajouté au RDAP et vérifie les détails d’autorisation par rapport au ROA.

Pour allouer la plage d’adresses
  1. Composer un message

    Composez le message d’autorisation en texte brut. Le format du message est le suivant, où la date est la date d’expiration du message : 

    1|aws|account|cidr|YYYYMMDD|SHA256|RSAPSS

    Remplacez le numéro de compte, la plage d’adresses et la date d’expiration par vos propres valeurs pour créer un message semblable au suivant :

    text_message="1|aws|0123456789AB|198.51.100.0/24|20211231|SHA256|RSAPSS"

    Cela ne doit pas être confondu avec un message ROA, qui a une apparence similaire.

  2. Signer un message

    Signez le message en texte brut à l’aide de la clé privée que vous avez créée précédemment. La signature renvoyée par cette commande est une longue chaîne que vous devrez utiliser à l’étape suivante.

    Important

    Nous vous recommandons de copier et de coller cette commande. À l’exception du contenu du message, ne modifiez ni ne remplacez aucune des valeurs.

    signed_message=$( echo -n $text_message | openssl dgst -sha256 -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 -sign private-key.pem -keyform PEM | openssl base64 | tr -- '+=/' '-_~' | tr -d "\n")
  3. Approvisionner une adresse

    Utilisez la AWS CLI provision-byoip-cidrcommande pour provisionner la plage d'adresses. La commande --cidr-authorization-context utilise les chaînes de message et de signature que vous avez créées précédemment.

    Important

    Vous devez spécifier la AWS région dans laquelle la plage BYOIP doit être provisionnée si elle diffère de votre configuration.AWS CLI Default region name

    aws ec2 provision-byoip-cidr --cidr address-range --cidr-authorization-context Message="$text_message",Signature="$signed_message" --region us-east-1

    La mise en service d’une plage d’adresses est une opération asynchrone : l’appel est immédiatement renvoyé, mais la plage d’adresses ne peut pas être utilisée tant que son statut ne bascule pas de pending-provision à provisioned.

  4. Surveiller la progression

    Bien que la plupart des approvisionnements soient effectués dans les deux heures, le processus d'approvisionnement pour les gammes pouvant faire l'objet d'une publicité publique peut prendre jusqu'à une semaine. Utilisez la describe-byoip-cidrscommande pour suivre les progrès, comme dans cet exemple :

    aws ec2 describe-byoip-cidrs --max-results 5 --region us-east-1

    S’il y a des problèmes pendant la mise en service et que l’état passe à failed-provision, vous devez exécuter à nouveau la commande provision-byoip-cidr une fois que les problèmes ont été résolus.

Allocation d’une plage d’adresses IPv6 qui n’est pas publiquement publiée

Par défaut, une plage d’adresses est allouée pour être publiquement publiée sur Internet. Vous pouvez allouer une plage d’adresses IPv6 qui ne sera pas publiquement publiée. Pour les acheminements qui ne sont pas publiquement annoncés, le processus d’approvisionnement se termine généralement en quelques minutes. Lorsque vous associez un bloc d’adresses CIDR IPv6 d’une plage d’adresses non publique à un VPC, le CIDR IPv6 ne peut être accessible que via les options de connectivité hybride prenant en charge IPv6, telles que AWS Direct Connect, AWS Site-to-Site VPN, ou les passerelles Transit Gateway d’Amazon VPC.

Un ROA n’est pas nécessaire pour fournir une plage d’adresses non publique.

Important

  • Vous ne pouvez spécifier si une plage d’adresses est publiquement publiée que pendant l’allocation. Vous ne pouvez pas modifier l’état annoncé ultérieurement.

  • Amazon VPC ne prend pas en charge les CIDR à adresse locale unique (ULA). Tous les VPC doivent disposer de CIDR IPv6 uniques. Deux VPC ne peuvent pas avoir la même plage d’adresses CIDR IPv6.

Pour fournir une plage d'adresses IPv6 qui ne sera pas publiée publiquement, utilisez la provision-byoip-cidrcommande suivante.

aws ec2 provision-byoip-cidr --cidr address-range --cidr-authorization-context Message="$text_message",Signature="$signed_message" --no-publicly-advertisable --region us-east-1

Faites connaître la plage d'adresses via AWS

Une fois que la plage d’adresses est mise en service, elle est prête à être publiée. Vous devez publier la plage d’adresses exacte que vous avez mise en service. Vous ne pouvez pas publier seulement une portion de la plage d’adresses mise en service.

Si vous avez provisionné une plage d’adresses IPv6 qui ne sera pas publiée publiquement, vous n’avez pas besoin de terminer cette étape.

Nous vous recommandons de cesser de faire de la publicité pour la plage d'adresses provenant d'autres sites avant de la diffuser AWS. Si vous continuez à publier votre plage d’adresses IP à partir d’autres emplacements, sa prise en charge ne sera pas assurée de manière fiable ou les problèmes associés ne pourront pas être identifiés et résolus. Plus précisément, nous ne pouvons pas garantir que le trafic vers la plage d’adresses entrera dans notre réseau.

Pour minimiser les temps d'arrêt, vous pouvez configurer vos AWS ressources pour utiliser une adresse de votre pool d'adresses avant qu'elle ne soit publiée, puis arrêter de la publier depuis son emplacement actuel et commencer à en faire la publicité par le biais AWS de cette adresse. Pour plus d’informations sur l’allocation d’une adresse IP Elastic à partir de votre groupe d’adresses, consultez allouer une adresse IP Elastic ;.

Limites

  • Vous pouvez exécuter la commande advertise-byoip-cidr au moins une fois tous les 10 secondes, même si vous spécifiez des plages d’adresses différentes à chaque fois.

  • Vous pouvez exécuter la commande withdraw-byoip-cidr au moins une fois tous les 10 secondes, même si vous spécifiez des plages d’adresses différentes à chaque fois.

Pour publier la plage d'adresses, utilisez la advertise-byoip-cidrcommande suivante.

aws ec2 advertise-byoip-cidr --cidr address-range --region us-east-1

Pour arrêter de publier la plage d'adresses, utilisez la withdraw-byoip-cidrcommande suivante.

aws ec2 withdraw-byoip-cidr --cidr address-range --region us-east-1

Mise hors service de la plage d’adresses

Pour arrêter d'utiliser votre plage d'adresses AWS, libérez d'abord toutes les adresses IP élastiques et dissociez tous les blocs d'adresse CIDR IPv6 encore alloués du pool d'adresses. Ensuite, arrêtez la publicité de la plage d’adresses et enfin, mettez hors service la plage d’adresses.

Vous ne pouvez pas mettre hors service une partie de la plage d’adresses. Si vous souhaitez utiliser une plage d'adresses plus spécifique avec AWS, déprovisionnez l'ensemble de la plage d'adresses et configurez une plage d'adresses plus spécifique.

Pour libérer chaque adresse IP Elastic, utilisez la commande release-address suivante.

aws ec2 release-address --allocation-id eipalloc-12345678abcabcabc --region us-east-1

(IPv6) Pour dissocier un bloc d'adresse CIDR IPv6, utilisez la commande suivante disassociate-vpc-cidr-block.

aws ec2 disassociate-vpc-cidr-block --association-id vpc-cidr-assoc-12345abcd1234abc1 --region us-east-1

Pour arrêter de publier la plage d'adresses, utilisez la withdraw-byoip-cidrcommande suivante.

aws ec2 withdraw-byoip-cidr --cidr address-range --region us-east-1

Pour déprovisionner la plage d'adresses, utilisez la deprovision-byoip-cidrcommande suivante.

aws ec2 deprovision-byoip-cidr --cidr address-range --region us-east-1

La mise hors service d’une plage d’adresses peut prendre jusqu’à un jour.

Utiliser votre plage d’adresses

Vous pouvez afficher et utiliser les plages d’adresses IPv4 et IPv6 que vous avez approvisionnées dans votre compte.

Plages d’adresses IPv4

Vous pouvez créer une adresse IP élastique à partir de votre pool d'adresses IPv4 et l'utiliser avec vos AWS ressources, telles que les instances EC2, les passerelles NAT et les équilibreurs de charge réseau.

Pour afficher des informations sur les pools d'adresses IPv4 que vous avez configurés dans votre compte, utilisez la commande describe-public-ipv4-pools suivante.

aws ec2 describe-public-ipv4-pools --region us-east-1

Pour créer une adresse IP Elastic à partir de votre pool d’adresses, utilisez la commande allocate-address. Vous pouvez utiliser l’option --public-ipv4-pool pour spécifier l’ID du groupe d’adresses renvoyé par describe-byoip-cidrs. Vous pouvez aussi utiliser l’option --address pour spécifier une adresse de la plage d’adresses que vous avez allouée.

Plages d’adresses IPv6

Pour afficher des informations sur les pools d’adresses IPv6 que vous avez provisionnés dans votre compte, utilisez la commande describe-ipv6-pools suivante.

aws ec2 describe-ipv6-pools --region us-east-1

Pour créer un VPC et spécifier un CIDR IPv6 à partir de votre pool d’adresses IPv6, utilisez la commande create-vpc suivante. Pour laisser Amazon choisir le CIDR IPv6 dans votre pool d’adresses IPv6, omettez l’option --ipv6-cidr-block.

aws ec2 create-vpc --cidr-block 10.0.0.0/16 --ipv6-cidr-block ipv6-cidr --ipv6-pool pool-id --region us-east-1

Pour associer un bloc d'adresse CIDR IPv6 de votre pool d'adresses IPv6 à un VPC, utilisez la associate-vpc-cidr-blockcommande suivante. Pour laisser Amazon choisir le CIDR IPv6 dans votre pool d’adresses IPv6, omettez l’option --ipv6-cidr-block.

aws ec2 associate-vpc-cidr-block --vpc-id vpc-123456789abc123ab --ipv6-cidr-block ipv6-cidr --ipv6-pool pool-id --region us-east-1

Pour afficher vos VPC et les informations de pool d’adresses IPv6 associées, utilisez la commande describe-vpcs . Pour afficher des informations sur les blocs d'adresse CIDR IPv6 associés à partir d'un pool d'adresses IPv6 spécifique, utilisez la commande get-associated-ipv6-pool-cidrs suivante.

aws ec2 get-associated-ipv6-pool-cidrs --pool-id pool-id --region us-east-1

Si vous dissociez le bloc CIDR IPv6 de votre VPC, il est libéré dans votre pool d’adresses IPv6.

Valider votre BYOIP

  1. Valider la paire de clés x.509 auto-signée

    Vérifiez que le certificat a été chargé et est valide via la commande whois.

    Pour ARIN, utilisez whois -h whois.arin.net r + 2001:0DB8:6172::/48 pour rechercher le registre RDAP pour votre plage d’adresses. Recherchez la NetRange (plage réseau) dans la section Public Comments dans la sortie de commande. Le certificat doit être ajouté dans la section Public Comments pour la plage d’adresses.

    Vous pouvez inspecter le Public Comments contenant le certificat à l’aide de la commande suivante :

    whois -h whois.arin.net r + 2001:0DB8:6172::/48 | grep Comments | grep BEGIN

    Cela renvoie une sortie avec le contenu de la clé, qui devrait être similaire à ce qui suit :

    Public Comments:
-----BEGIN CERTIFICATE-----
MIID1zCCAr+gAwIBAgIUBkRPNSLrPqbRAFP8RDAHSP+I1TowDQYJKoZIhvcNAQE
LBQAwezELMAkGA1UEBhMCTloxETAPBgNVBAgMCEF1Y2tsYW5kMREwDwYDVQQHDA
hBdWNrbGFuZDEcMBoGA1UECgwTQW1hem9uIFdlYiBTZXJ2aWNlczETMBEGA1UEC
wwKQllPSVAgRGVtbzETMBEGA1UEAwwKQllPSVAgRGVtbzAeFw0yMTEyMDcyMDI0
NTRaFw0yMjEyMDcyMDI0NTRaMHsxCzAJBgNVBAYTAk5aMREwDwYDVQQIDAhBdWN
rbGFuZDERMA8GA1UEBwwIQXVja2xhbmQxHDAaBgNVBAoME0FtYXpvbiBXZWIgU2
VydmljZXMxEzARBgNVBAsMCkJZT0lQIERlbW8xEzARBgNVBAMMCkJZT0lQIERlb
W8wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCfmacvDp0wZ0ceiXXc
R/q27mHI/U5HKt7SST4X2eAqufR9wXkfNanAEskgAseyFypwEEQr4CJijI/5hp9
prh+jsWHWwkFRoBRR9FBtwcU/45XDXLga7D3stsI5QesHVRwOaXUdprAnndaTug
mDPkD0vrl475JWDSIm+PUxGWLy+60aBqiaZq35wU/x+wXlAqBXg4MZK2KoUu27k
Yt2zhmy0S7Ky+oRfRJ9QbAiSu/RwhQbh5Mkp1ZnVIc7NqnhdeIW48QaYjhMlUEf
xdaqYUinzz8KpjfADZ4Hvqj9jWZ/eXo/9b2rGlHWkJsbhr0VEUyAGu1bwkgcdww
3A7NjOxQbAgMBAAGjUzBRMB0GA1UdDgQWBBStFyujN6SYBr2glHpGt0XGF7GbGT
AfBgNVHSMEGDAWgBStFyujN6SYBr2glHpGt0XGF7GbGTAPBgNVHRMBAf8EBTADA
QH/MA0GCSqGSIb3DQEBCwUAA4IBAQBX6nn6YLhz521lfyVfxY0t6o3410bQAeAF
08ud+ICtmQ4IO4A4B7zV3zIVYr0clrOOaFyLxngwMYN0XY5tVhDQqk4/gmDNEKS
Zy2QkX4Eg0YUWVzOyt6fPzjOvJLcsqc1hcF9wySL507XQz76Uk5cFypBOzbnk35
UkWrzA9KK97cXckfIESgK/k1N4ecwxwG6VQ8mBGqVpPpey+dXpzzzv1iBKN/VY4
ydjgH/LBfdTsVarmmy2vtWBxwrqkFvpdhSGCvRDl/qdO/GIDJi77dmZWkh/ic90
MNk1f38gs1jrCj8lThoar17Uo9y/Q5qJIsoNPyQrJRzqFU9F3FBjiPJF
-----END CERTIFICATE-----

    Pour RIPE, utilisez whois -r -h whois.ripe.net 2001:0DB8:7269::/48 pour rechercher le registre RDAP pour votre plage d’adresses. Recherchez l’object inetnum (plage réseau) dans la section descr dans la sortie de commande. Le certificat doit être ajouté en tant que nouveau champ descr pour la plage d’adresses.

    Vous pouvez inspecter le descr contenant le certificat à l’aide de la commande suivante :

    whois -r -h whois.ripe.net 2001:0DB8:7269::/48 | grep descr | grep BEGIN

    Cela renvoie une sortie avec le contenu de la clé, qui devrait être similaire à ce qui suit :

    descr:
-----BEGIN CERTIFICATE-----MIID1zCCAr+gAwIBAgIUBkRPNSLrPqbRAFP8
RDAHSP+I1TowDQYJKoZIhvcNAQELBQAwezELMAkGA1UEBhMCTloxETAPBgNVBAg
MCEF1Y2tsYW5kMREwDwYDVQQHDAhBdWNrbGFuZDEcMBoGA1UECgwTQW1hem9uIF
dlYiBTZXJ2aWNlczETMBEGA1UECwwKQllPSVAgRGVtbzETMBEGA1UEAwwKQllPS
VAgRGVtbzAeFw0yMTEyMDcyMDI0NTRaFw0yMjEyMDcyMDI0NTRaMHsxCzAJBgNV
BAYTAk5aMREwDwYDVQQIDAhBdWNrbGFuZDERMA8GA1UEBwwIQXVja2xhbmQxHDA
aBgNVBAoME0FtYXpvbiBXZWIgU2VydmljZXMxEzARBgNVBAsMCkJZT0lQIERlbW
8xEzARBgNVBAMMCkJZT0lQIERlbW8wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwg
gEKAoIBAQCfmacvDp0wZ0ceiXXcR/q27mHI/U5HKt7SST4X2eAqufR9wXkfNanA
EskgAseyFypwEEQr4CJijI/5hp9prh+jsWHWwkFRoBRR9FBtwcU/45XDXLga7D3
stsI5QesHVRwOaXUdprAnndaTugmDPkD0vrl475JWDSIm+PUxGWLy+60aBqiaZq
35wU/x+wXlAqBXg4MZK2KoUu27kYt2zhmy0S7Ky+oRfRJ9QbAiSu/RwhQbh5Mkp
1ZnVIc7NqnhdeIW48QaYjhMlUEfxdaqYUinzz8KpjfADZ4Hvqj9jWZ/eXo/9b2r
GlHWkJsbhr0VEUyAGu1bwkgcdww3A7NjOxQbAgMBAAGjUzBRMB0GA1UdDgQWBBS
tFyujN6SYBr2glHpGt0XGF7GbGTAfBgNVHSMEGDAWgBStFyujN6SYBr2glHpGt0
XGF7GbGTAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IBAQBX6nn6Y
Lhz521lfyVfxY0t6o3410bQAeAF08ud+ICtmQ4IO4A4B7zV3zIVYr0clrOOaFyL
xngwMYN0XY5tVhDQqk4/gmDNEKSZy2QkX4Eg0YUWVzOyt6fPzjOvJLcsqc1hcF9
wySL507XQz76Uk5cFypBOzbnk35UkWrzA9KK97cXckfIESgK/k1N4ecwxwG6VQ8
mBGqVpPpey+dXpzzzv1iBKN/VY4ydjgH/LBfdTsVarmmy2vtWBxwrqkFvpdhSGC
vRDl/qdO/GIDJi77dmZWkh/ic90MNk1f38gs1jrCj8lThoar17Uo9y/Q5qJIsoN
PyQrJRzqFU9F3FBjiPJF
-----END CERTIFICATE-----

    Pour APNIC, utilisez whois -h whois.apnic.net 2001:0DB8:6170::/48 pour rechercher le registre RDAP pour votre plage d’adresses BYOIP. Recherchez l’object inetnum (plage réseau) dans la section remarks dans la sortie de commande. Le certificat doit être ajouté en tant que nouveau champ remarks pour la plage d’adresses.

    Vous pouvez inspecter le remarks contenant le certificat à l’aide de la commande suivante :

    whois -h whois.apnic.net 2001:0DB8:6170::/48 | grep remarks | grep BEGIN

    Cela renvoie une sortie avec le contenu de la clé, qui devrait être similaire à ce qui suit :

    remarks:
-----BEGIN CERTIFICATE-----
MIID1zCCAr+gAwIBAgIUBkRPNSLrPqbRAFP8RDAHSP+I1TowDQYJKoZIhvcNAQE
LBQAwezELMAkGA1UEBhMCTloxETAPBgNVBAgMCEF1Y2tsYW5kMREwDwYDVQQHDA
hBdWNrbGFuZDEcMBoGA1UECgwTQW1hem9uIFdlYiBTZXJ2aWNlczETMBEGA1UEC
wwKQllPSVAgRGVtbzETMBEGA1UEAwwKQllPSVAgRGVtbzAeFw0yMTEyMDcyMDI0
NTRaFw0yMjEyMDcyMDI0NTRaMHsxCzAJBgNVBAYTAk5aMREwDwYDVQQIDAhBdWN
rbGFuZDERMA8GA1UEBwwIQXVja2xhbmQxHDAaBgNVBAoME0FtYXpvbiBXZWIgU2
VydmljZXMxEzARBgNVBAsMCkJZT0lQIERlbW8xEzARBgNVBAMMCkJZT0lQIERlb
W8wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCfmacvDp0wZ0ceiXXc
R/q27mHI/U5HKt7SST4X2eAqufR9wXkfNanAEskgAseyFypwEEQr4CJijI/5hp9
prh+jsWHWwkFRoBRR9FBtwcU/45XDXLga7D3stsI5QesHVRwOaXUdprAnndaTug
mDPkD0vrl475JWDSIm+PUxGWLy+60aBqiaZq35wU/x+wXlAqBXg4MZK2KoUu27k
Yt2zhmy0S7Ky+oRfRJ9QbAiSu/RwhQbh5Mkp1ZnVIc7NqnhdeIW48QaYjhMlUEf
xdaqYUinzz8KpjfADZ4Hvqj9jWZ/eXo/9b2rGlHWkJsbhr0VEUyAGu1bwkgcdww
3A7NjOxQbAgMBAAGjUzBRMB0GA1UdDgQWBBStFyujN6SYBr2glHpGt0XGF7GbGT
AfBgNVHSMEGDAWgBStFyujN6SYBr2glHpGt0XGF7GbGTAPBgNVHRMBAf8EBTADA
QH/MA0GCSqGSIb3DQEBCwUAA4IBAQBX6nn6YLhz521lfyVfxY0t6o3410bQAeAF
08ud+ICtmQ4IO4A4B7zV3zIVYr0clrOOaFyLxngwMYN0XY5tVhDQqk4/gmDNEKS
Zy2QkX4Eg0YUWVzOyt6fPzjOvJLcsqc1hcF9wySL507XQz76Uk5cFypBOzbnk35
UkWrzA9KK97cXckfIESgK/k1N4ecwxwG6VQ8mBGqVpPpey+dXpzzzv1iBKN/VY4
ydjgH/LBfdTsVarmmy2vtWBxwrqkFvpdhSGCvRDl/qdO/GIDJi77dmZWkh/ic90
MNk1f38gs1jrCj8lThoar17Uo9y/Q5qJIsoNPyQrJRzqFU9F3FBjiPJF
-----END CERTIFICATE-----

  2. Valider la création d’un objet ROA

    Validez la création réussie des objets ROA à l’aide de l’API de données RIPEstat. Assurez-vous de tester votre plage d’adresses par rapport aux ASN 16509 et 14618 d’Amazon, ainsi que les ASN qui sont actuellement autorisés à publier la plage d’adresses.

    Vous pouvez inspecter les objets ROA provenant de différents ASN d’Amazon avec votre plage d’adresses à l’aide de la commande suivante :

    curl --location --request GET "https://stat.ripe.net/data/rpki-validation/data.json?resource=ASN&prefix=CIDR

    Dans cet exemple de sortie, la réponse a un résultat de "status": "valid" pour l’ASN 16509 d’Amazon. Cela indique que l’objet ROA de la plage d’adresses a été créé avec succès :

    {
    "messages": [],
    "see_also": [],
    "version": "0.3",
    "data_call_name": "rpki-validation",
    "data_call_status": "supported",
    "cached": false,
    "data": {
        "validating_roas": [
            {
                "origin": "16509",
                "prefix": "2001:0DB8::/32",
                "max_length": 48,
                "validity": "valid"
            },
            {
                "origin": "14618",
                "prefix": "2001:0DB8::/32",
                "max_length": 48,
                "validity": "invalid_asn"
            },
            {
                "origin": "64496",
                "prefix": "2001:0DB8::/32",
                "max_length": 48,
                "validity": "invalid_asn"
            }
        ],
        "status": "valid",
        "validator": "routinator",
        "resource": "16509",
        "prefix": "2001:0DB8::/32"
    },
    "query_id": "20230224152430-81e6384e-21ba-4a86-852a-31850787105f",
    "process_time": 58,
    "server_id": "app116",
    "build_version": "live.2023.2.1.142",
    "status": "ok",
    "status_code": 200,
    "time": "2023-02-24T15:24:30.773654"
}

Le statut “unknown” indique que l’objet ROA de la plage d’adresses n’a pas été créé. Le statut “invalid_asn” indique que l’objet ROA de la plage d’adresses n’a pas été créé avec succès.

Disponibilité par région

La fonctionnalité BYOIP est actuellement disponible dans toutes les régions AWS  commerciales à l’exception des régions chinoises.

Disponibilité de la zone locale

Une zone locale est une extension d'une AWS région située à proximité géographique de vos utilisateurs. Les Zones Locales sont regroupées en « groupes de frontières réseau ». Dans AWS, un groupe frontalier du réseau est un ensemble de zones de disponibilité (AZ), de zones locales ou de zones de longueur d'onde à partir desquelles AWS une adresse IP publique est annoncée. Les zones locales peuvent avoir des groupes de frontières de réseau différents de ceux des zones de disponibilité d'une AWS région afin de garantir une latence minimale ou une distance physique minimale entre le AWS réseau et les clients accédant aux ressources de ces zones.

Vous pouvez fournir des plages d’adresses BYOIPv4 et les publier dans les groupes frontaliers du réseau de zone locale suivants à l’aide de l’option --network-border-group :

  • us-east-1-dfw-2

  • us-west-2-lax-1

  • us-west-2-phx-2

Si vous avez des zones locales activées (voir Enable a Local Zone), vous pouvez choisir un groupe de frontières réseau pour les zones locales lorsque vous allouez et publiez un CIDR BYOIPv4. Choisissez soigneusement le groupe de bordure du réseau car l'EIP et la AWS ressource à laquelle il est associé doivent résider dans le même groupe de bordure du réseau.

Note

Vous ne pouvez pas allouer ou publier des plages d’adresses BYOIPv6 dans les zones locales pour le moment.

En savoir plus

Pour plus d'informations, consultez le débat technique AWS en ligne sur le thème « Bring Your Own IP ».