BYOIP chez AWS : apportez vos propres adresses IPv4 sur EC2

Vous prouvez que vous contrôlez la plage avec un certificat dans son objet du registre et un ROA qui nomme les ASN d'AWS, vous la provisionnez dans un pool d'adresses, et vous en tirez des adresses Elastic IP comme vous le feriez depuis celles d'AWS. Les adresses que vous apportez ne sont pas soumises au tarif horaire des IPv4 publiques.

Ce guide couvre EC2 avec l'AWS CLI. La même plage peut aussi aller vers AWS Global Accelerator, qui a sa propre procédure, ou passer par VPC IP Address Manager (IPAM), qui ajoute une façon de prouver le contrôle par le DNS et la possibilité d'annoncer depuis votre propre ASN.

Ce qu'AWS accepte

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

• Taille. La plage IPv4 la plus spécifique que vous pouvez apporter est un /24.
• Registre. L'ARIN, le RIPE NCC ou l'APNIC, et enregistrée au nom d'une entreprise ou d'une institution, jamais d'une personne.
• Historique. AWS peut vérifier la réputation de la plage et refuser celle dont les adresses ont de mauvais antécédents (garder un bloc propre).
• L'espace legacy est accepté, mais il lui faut quand même un ROA.
• Une seule région à la fois par plage, et cinq plages par région par défaut ; le support AWS peut relever cette limite.
• Où. Toutes les régions commerciales sauf les régions de Chine, et une liste de Local Zones.
• Ne touchez pas au registre de routage. AWS met à jour RADb lui-même, et une modification manuelle qui inclut l'ASN d'AWS fait échouer le provisionnement.

Avant de commencer

Un ROA pour les ASN d'AWS. Il doit autoriser AS16509 et AS14618, ainsi que tout ASN qui annonce la plage aujourd'hui, avec une longueur maximale égale à la taille de la plage que vous apportez. Dans les régions AWS GovCloud (US), le ROA nomme AS8987 à la place, et dans l'AWS European Sovereign Cloud AS16509 et AS214101 ; via IPAM, fixez-la à /24 pour pouvoir découper le bloc. Si vous déplacez la plage depuis votre propre réseau, créez d'abord le ROA pour votre ASN actuel, afin que rien de ce qui fonctionne aujourd'hui ne devienne invalide (RPKI et ROA). Un ROA peut mettre jusqu'à 24 heures pour parvenir à AWS.

Une paire de clés et un certificat, créés avec OpenSSL 1.0.2 ou plus récent :

openssl genpkey -aes256 -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out private-key.pem
openssl req -new -x509 -key private-key.pem -days 365 | tr -d "\n" > certificate.pem

Le certificat dans l'objet du registre, sur une seule ligne, marqueurs BEGIN et END compris. L'endroit dépend du registre, et le champ compte :

Vous pouvez retirer le certificat une fois le provisionnement terminé.

Étape par étape

01Signez le message d'autorisation. Le message nomme votre compte, la plage et une date d'expiration :

text_message="1|aws|123456789012|203.0.113.0/24|20261231|SHA256|RSAPSS"
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")

02Provisionnez la plage dans la région où vous l'utiliserez :

aws ec2 provision-byoip-cidr --cidr 203.0.113.0/24 \
  --cidr-authorization-context Message="$text_message",Signature="$signed_message" \
  --region eu-central-1

03Attendez. Le statut passe de pending-provision à provisioned. AWS indique que la plupart des plages sont prêtes en deux heures et que certaines prennent jusqu'à une semaine ; aws ec2 describe-byoip-cidrs --max-results 5 --region eu-central-1 montre où en est la vôtre.

04Préparez, puis basculez. Pour réduire l'interruption, allouez des adresses Elastic IP depuis le nouveau pool et attachez-les avant que la plage soit annoncée. aws ec2 describe-public-ipv4-pools donne l'ID du pool, et aws ec2 allocate-address --public-ipv4-pool <pool-id> en tire une adresse.

05Annoncez. Cessez d'annoncer la plage partout ailleurs, puis :

aws ec2 advertise-byoip-cidr --cidr 203.0.113.0/24 --region eu-central-1

AWS recommande de retirer d'abord la plage des autres emplacements ; tant qu'un autre l'annonce, AWS ne peut pas promettre que le trafic qui lui est destiné atteigne son réseau. Vous devez annoncer exactement la plage provisionnée, jamais une partie.

06Vérifiez depuis l'extérieur. whois -r -h whois.ripe.net 203.0.113.0/24 | grep descr doit afficher le certificat, et le validateur de RIPEstat doit déclarer la plage valide pour AS16509 : curl "https://stat.ripe.net/data/rpki-validation/data.json?resource=16509&prefix=203.0.113.0/24".

Les erreurs qui coûtent une journée

• Le certificat dans le mauvais champ. Pour le RIPE NCC, AWS lit descr et explicitement pas remarks. Azure veut l'inverse : un bloc déplacé entre les deux clouds demande donc de modifier l'objet.
• Un ROA avec la mauvaise longueur maximale. AWS exige qu'elle soit égale à la taille de la plage apportée, ou /24 via IPAM. Une longueur maximale plus spécifique que la plage apportée facilite les détournements de sous-préfixes, et AWS se réserve le droit de cesser d'annoncer une plage dont les ROA ne suivent pas ses règles.
• Annoncer une partie de la plage. AWS annonce exactement ce que vous avez provisionné. Pour utiliser une plage plus petite, déprovisionnez et provisionnez de nouveau.
• Deux réseaux qui annoncent en même temps. Le trafic se partage entre eux, et AWS ne fera pas le diagnostic.

Votre propre ASN

Via VPC IPAM, AWS peut annoncer votre plage depuis votre propre ASN au lieu du sien. Vous ajoutez le même certificat à l'objet du registre de votre ASN (pour le RIPE NCC, comme ligne descr dans l'aut-num), vous créez un second ROA qui nomme votre ASN, et AWS recommande un objet ASPA qui liste AS16509 et AS14618 comme vos fournisseurs ; sans eux, les routes qu'AWS transmet pour vous échouent à la validation ASPA. Vous pouvez remettre l'origine sur l'ASN d'AWS à tout moment, et sur le vôtre au plus une fois par heure.

Si vous louez le bloc

L'espace loué fonctionne, à condition que le registre le montre détenu par une organisation. Le titulaire s'occupe du côté registre : le certificat dans l'objet inetnum, que seul le mainteneur du titulaire peut modifier, et le ROA pour AS16509 et AS14618. Vous faites le reste depuis votre compte AWS.

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 ajoutons votre certificat AWS à l'objet du registre et créons le ROA pour les ASN d'AWS : le provisionnement est la seule étape qui vous reste (louer de l'IPv4). S'il vous faut moins de 256 adresses sur une instance EC2, nous pouvons plutôt les livrer par un tunnel (tunnels GRE et WireGuard). Comment le tarif horaire des IPv4 s'additionne, et quand apporter les vôtres est rentable : le vrai coût des IPv4 dans le cloud. Autres fournisseurs : guides BYOIP.