Comment puis-je utiliser une adresse IP statique avec un équilibreur de charge d'application de manière hautement disponible?
Je supervise une intégration pour un client et son fournisseur a besoin d'un certain nombre d'adresses IP pour figurer sur la liste blanche. Le ou les serveurs d'origine sont une instance Elastic Beanstalk dirigée par un équilibreur de charge d'application avec tous les réglages via Route53.
Cela ne fonctionnera pas, car vous ne pouvez pas attribuer une IP statique aux équilibreurs de charge d'application par définition (et j'ai besoin des fonctionnalités de la couche 7).
Je ne peux pas simplement proxy les demandes spécifiques au fournisseur via le code et une instance EC2 supplémentaire, car il s'agit d'une intégration bidirectionnelle.
J'ai lu cet article , mais cela ressemble franchement à un hack et non à quelque chose que je ferais dans un environnement de production.
Il semble certainement que j'ai besoin d'une combinaison d'un NLB avec un ALB, mais encore une fois, l'article de référence présente une tonne de pièces mobiles.
Modifier :
- J'utilise un VPC
- L'instance elle-même vit dans un sous-réseau privé
- L'ALB vit dans un sous-réseau public et les deux ont le routage nécessaire pour communiquer
- Je suis presque certain de parler en rond pour essayer de me convaincre
Static IP !== Single Point of Failure
Il n'y a actuellement qu'une seule façon d'associer des adresses IP statiques à Application Load Balancer (ALB) - AWS Global Accelerator.
IP Anycast statiques - Global Accelerator utilise des adresses IP statiques qui servent de point d'entrée fixe à vos applications hébergées dans un certain nombre de régions AWS. Ces adresses IP sont Anycast à partir des emplacements AWS Edge, ce qui signifie que ces adresses IP sont annoncées à partir de plusieurs emplacements AWS Edge, permettant au trafic d'entrer sur le réseau mondial AWS aussi près que possible de vos utilisateurs. Vous pouvez associer ces adresses à des ressources ou points de terminaison AWS régionaux, tels que des équilibreurs de charge réseau, des équilibreurs de charge d'application et des adresses IP Elastic. Vous n'avez pas besoin d'apporter de modifications face au client ni de mettre à jour les enregistrements DNS lorsque vous modifiez ou remplacez des points de terminaison.
https://aws.Amazon.com/blogs/aws/new-aws-global-accelerator-for-available-and-performance/
Global Accelerator alloue deux adresses IP statiques à partir de deux zones réseau¹, et celles-ci sont uniques à votre déploiement - non partagées. Ceux-ci sont annoncés sur Internet via des connexions d'appairage à plusieurs endroits sur le réseau AWS Edge (le même réseau où CloudFront, Route 53 et S3 Transfer Acceleration fonctionnent tous - il a plus de points de présence que les régions AWS et AWS (connexions fibre optique gérées vers les régions). Ensuite, vous associez les points de terminaison - Instance ALB, NLB, EIP ou EC2 (sans EIP) - à l'instance Global Accelerator, et le trafic provenant de l'emplacement Edge où les demandes arrivent est NAT-ed vers votre équilibreur.
Lorsque Global Accelerator a été initialement lancé, il s'appuyait sur Source NAT pour lier les adresses globales aux périphériques VPC, vous ne pouviez donc pas utiliser l'IP source du client ou le X-Forwarded-For en-tête de l'ALB pour déterminer l'adresse IP du client en temps réel; cependant, qui a changé - X-Forwarded-For identifie désormais correctement l'adresse IP du client lorsqu'un ALB est utilisé avec Global Accelerator dans la plupart des régions AWS .
Préservation de l'adresse IP du client ne fonctionne que lorsque le point de terminaison est une instance ALB ou EC2 (sans EIP). Il ne fonctionne pas avec les points de terminaison EIP ou les équilibreurs de charge réseau; pour ces cas, vous ne pouvez les corréler qu'ultérieurement en utilisant journaux de flux , qui capturent les tuples source/destination ainsi que l'adresse intermédiaire NAT que votre application verra.
Surtout, ALB est uniquement entrant (les connexions ne sont établies que de l'extérieur vers l'intérieur, quelle que soit la direction ultime du transfert de données), donc si vos serveurs établissent également des connexions, vous avez besoin d'une solution distincte pour une adresse source statique - a - Passerelle NAT .
Une NAT passerelle par zone de disponibilité, placée sur un sous-réseau public, peut servir de passerelle par défaut pour un ou plusieurs sous-réseaux privés dans la zone de disponibilité, de sorte que toutes les instances de ces sous-réseaux utilisent la même source IP lors de la connexion à Internet. NAT Gateway n'est pas une boîte noire dans un endroit physique - c'est une caractéristique de l'infrastructure réseau, donc elle est intrinsèquement à sécurité intrinsèque et n'est pas considérée comme un seul point de défaillance au sein d'une seule zone AZ. Vous pouvez partager une seule NAT passerelle entre les zones de disponibilité, mais vous avez un point de défaillance unique si quelque chose de catastrophique se produit dans cette zone de disponibilité (et vous paierez un peu plus pour transporter le trafic Internet à travers les frontières AZ, par rapport à placer une NAT passerelle dans chaque AZ). La NAT passerelle ne nécessite aucune modification d'application, car elle n'est pas 't un proxy - c'est un traducteur d'adresses réseau qui est transparent pour les instances qui se trouvent sur les sous-réseaux qui sont configurés pour utilise le. Chaque NAT passerelle a un EIP statique.
¹ la zone réseau est nouvelle terminologie AWS , introduite avec Global Accelerator. Il décrit le fait que les deux adresses IP sont, en interne, gérées par des infrastructures différentes.
C'est frustrant, car il n'y a pas de bon moyen de le faire, surtout si vous diffusez un site Web et que vous voulez savoir qui vient sur votre site,
Option 1: AWS Global Accelerator - qui fonctionne mais supprime l'adresse IP du client afin que vous n'ayez aucune comptabilité sur la provenance des personnes.
Option 2: Cette méthode vraiment obscure: https://aws.Amazon.com/blogs/networking-and-content-delivery/using-static-ip-addresses-for-application-load-balancers/ = qui en bref nécessite un ELB et un ALB et ainsi de suite ce qui rompt certaines fonctionnalités dans le processus et nécessite une approche lourde.
À partir du 5/2019, ce sont les principales façons de le faire.