Question Connexion de deux régions AWS: Pourquoi ne pas utiliser deux passerelles privées privées?


J'essaie de connecter deux régions AWS. La documentation d'AWS suggère de démarrer une instance des deux côtés pour exécuter le logiciel IPSec (OpenSWAN ou StrongSWAN), en leur attribuant une adresse IP élastique et en les utilisant comme tunnel. C'est bien beau, mais nous avons maintenant un seul point d'échec des deux côtés.

AWS a publié un Guide de connectivité VPC en juillet qui détaille les options possibles pour connecter deux VPC ensemble. J'ai lié ce fichier PDF à la page 15, qui explique les options.

Chaque option répertoriée présente des inconvénients importants, car dans la plupart des cas, tout le trafic passe par une seule instance (possible). Jusqu'à présent, il semble que la meilleure option consiste à utiliser un tunnel logiciel d'un côté et une passerelle privée virtuelle de l'autre. Ils disent, au moins vous obtenez la redondance d'un côté. Cela semble encore sous-optimal.

Existe-t-il un moyen de connecter deux passerelles privées privées afin d'obtenir le meilleur des deux mondes: la redondance gérée par Amazon et la simplicité de garder tout cela dans ma configuration de VPC? Ou bien les VGW sont-ils essentiellement réservés aux clients?


5
2017-11-12 17:32


origine




Réponses:


Non, il n'y a aucun moyen en ce moment de connecter deux passerelles privées virtuelles dans des régions différentes. Je suis sûr que c'est une fonctionnalité à venir, étant donné que le peering VPC est disponible pour les VPC d'une seule région.

En ce qui concerne "Vous êtes responsable de la mise en œuvre des solutions de haute disponibilité pour tous les points de terminaison VPN (le cas échéant)", réponse précédente Il existe différentes techniques pour gérer la défaillance d’une instance VPN / NAT. Récemment, je parlais avec un collègue qui non seulement a configuré un VPN maillé complet avec mise à l'échelle automatique et script pour réapprovisionner des instances VPN / NAT défaillantes, mais il disposait également de scripts supplémentaires qui modifiaient les tables de routage VPC pour une prise en charge immédiate des itinéraires par un autre AZ. jusqu'à ce que l'instance VPN / NAT défaillante ait terminé de renaître. Ils ont également échoué la route une fois que l'instance VPC / NAT était en place et que l'ENI a été reconnecté. Il y a beaucoup de scripts "NAT monitor" sur github qui font des choses similaires. Il y a aussi un Article AWS qui décrit le processus.

Haute disponibilité décente? Oui. Configuration simple? Malheureusement non.


6
2017-11-18 04:18