Adresse IP statique pour le trafic sortant du groupe de mise à l'échelle automatique AWS
Je vais avoir un certain nombre d'instances EC2 dans un groupe de mise à l'échelle automatique Elastic Beanstalk dans un sous-réseau par défaut dans un VPC. L'application sur ces instances EC2 doit se connecter à un service tiers qui utilise une liste blanche d'adresses IP pour autoriser l'accès. J'ai donc besoin d'une ou plusieurs adresses IP statiques que je peux donner à ce fournisseur de services afin qu'elles puissent être ajoutées à la liste blanche. Ma compréhension est que la seule façon d'obtenir une adresse IP statique est d'obtenir une adresse IP élastique. Et je ne peux associer l'IP Elastic qu'à une seule instance EC2 à la fois - je ne peux pas l'associer à tout mon sous-réseau ou à ma passerelle Internet (est-ce correct?). Ai-je donc besoin d'une adresse IP élastique pour chaque instance EC2, afin que chaque instance puisse être ajoutée séparément à la liste blanche? Comment cela fonctionnerait-il si la mise à l'échelle automatique ajoute une autre instance? Dois-je avoir une instance EC2 avec une adresse IP élastique et acheminer tout le trafic sortant via cette instance? Si tel est le cas, cette instance doit-elle être uniquement à cette fin ou peut-elle être l'une des instances qui exécutent mon application?
Vous avez besoin d'un NAT. Cette configuration est couramment utilisée pour prendre en charge les sous-réseaux privés dans VPC, il y a un guide assez détaillé ici . Une fois que votre VPC est configuré pour utiliser l'instance NAT tout le trafic sortant sera attribué au EIP de l'instance NAT.
Si tel est le cas, cette instance doit-elle être uniquement à cette fin ou peut-elle être l'une des instances qui exécutent mon application?
Techniquement, vous pourriez probablement, mais ce n'est pas une bonne idée:
- C'est une bonne sécurité d'avoir des rôles isolés.
- Vous souhaitez que vos serveurs d'applications aient des profils de charge similaires ou identiques. Si une instance a une charge supplémentaire de 10% à cause du NAT alors vous devrez évoluer prématurément lorsque vous atteindrez les limites de cette instance. Cela s'aggravera avec le NAT devient plus occupé à mesure que de nouvelles instances sont ajoutées à votre cluster.
- Vous voulez que vos serveurs d'applications soient identiques et éphémères afin que vous puissiez les démolir et/ou les remplacer chaque fois qu'il y a un problème ou que vous devez évoluer. Avoir un serveur d'applications différent des autres serait un casse-tête majeur.
Vous pourriez vous en sortir si vos instances sont conteneurisées mais ce n'est probablement pas une bonne idée.
Gardez également à l'esprit que votre instance NAT peut être un point de défaillance unique, vous pouvez donc penser à la redondance.
Je comprends que c'est un vieux fil - pour quelqu'un qui a maintenant un cas d'utilisation similaire, AWS nat-gateway serait une meilleure solution.
Je n'ai pas assez de réputation pour commenter les réponses ci-dessus, mais je voulais ajouter quelques informations que vous devrez savoir si vous utilisez une passerelle NAT pour y parvenir. Lorsque vous créez une passerelle NAT, vous sélectionnez un sous-réseau et une adresse IP élastique.
Au début, je venais d'ajouter la passerelle NAT au même sous-réseau que mon équilibreur de charge élastique et mes instances EC2. Ensuite, vous devez ajouter la passerelle NAT à votre table de routage. J'ai ajouté la passerelle NAT comme cible pour l'IP de mon serveur de base de données externe que j'essayais de contacter. Cela a entraîné la fin des applications hébergées dans mon haricot élastique. C'est parce qu'ils essayaient de se connecter à cette base de données externe via le NAT. Ils ont atteint le NAT, puis le NAT a essayé de contacter mon serveur via Internet et l'a recherché dans la table de routage pour le sous-réseau sur lequel il se trouvait, qui pointait vers lui-même, créant un boucle.
La solution est, avant de créer votre passerelle NAT, de créer un nouveau sous-réseau uniquement pour le NAT afin que le NAT possède son propre sous-réseau et sa propre table de routage. Dans la table de routage du NAT, pointez tout le trafic vers la passerelle Internet. Dans votre table de routage principale, pointez votre IP externe vers le NAT. Ensuite, lorsque vos instances EC2 tentent de se connecter à votre IP externe, elles les recherchent dans la table de routage principale (ou dans la table de routage que vous avez définie pour les sous-réseaux dans lesquels se trouvent vos instances), et trouvent le NAT. Ensuite, votre NAT recherchera cette IP dans sa propre table de routage et trouvera Internet.