Le Blog Amazon Web Services

Créer un point de sortie unique pour plusieurs VPCs avec AWS Transit Gateway

Dans ce blog nous allons illustrer comment centraliser du trafic internet sortant depuis plusieurs VPCs sans compromettre l’isolation de ces VPCs. En utilisant AWS Transit Gateway, vous pouvez configurer un unique VPC avec plusieurs NAT gateways et consolider le trafic sortant de plusieurs VPCs. Dans le même temps, l’usage de plusieurs tables de routage dans la AWS Transit Gateway permet de maintenir l’isolation VPC vers VPC. Cette architecture hub and spoke vous permet de gérer tout le trafic sortant sur Internet de façon sûre depuis un point unique.

Sans AWS Transit Gateway, il est nécessaire de combiner une internet gateway avec une NAT gateway ou une NAT instance pour chaque VPC nécessitant un accès sortant vers Internet. A l’échelle, avec un nombre significatif de VPCs, le management de plusieurs internet gateways et NAT gateways (ou instances) ajoute de la charge et des coûts. Dans ce cas, vous pouvez réduire cet overhead en centralisant le trafic sortant avec AWS Transit Gateway.

Bien que ce design permette une architecture centralisaée avec une paire de NAT gateways, il est possible de modifier cette architecture et remplacer les NAT gateways avec d’autres appliances de sécurité pour capturer du trafic, filtrer les flux web, forcer des policies, etc. Les seuls pré-requis pour ces appliances sont: la capacité à faire du NAT let support des configurations de routage.

Aperçu de la solution

Le diagramme d’architecture ci-dessous illustre comment utiliser AWS Transit Gateway pour centraliser du trafic sortant sur Internet depuis plusieurs VPCs, avec un design hub and spoke. Ce design inclut deux NAT Gateways, comme indiqué sur le schéma suivant :

Figure 1: Architecture avec AWS Transit Gateway centralisant le trafic sortant vers Internet depuis plusieurs VPCs

Pré-requis

Pour réaliser les étapes suivantes, vous aurez besoin:

  • d’un compte AWS
  • d’un user IAM avec accès aux ressources AWS, y compris AWS Transit Gateway

Deployer l’exemple

Dans cette section, j’illustre comment déployer AWS Transit Gateway et trois VPCs avec des plages d’IP sans recouvrement dans une seule Région et comment attacher la transit gateway à ces VPCs. Dans le VPC hub, je mets en évidence comment déployer les NAT Gateways (une par Zone de Disponibilité) et une Internet Gateway. Enfin, je mets en évidence comment configurer les tables de routage des VPCs et comment déployer une instance de test dans un VPC Spoke pour tester la connectivité sortante vers Internet.

Si vous préférez automatiser la configuration de test, il vous suffit de suivre les instructions pour déployer tous les composants. Cela automatise les trois prochaines étapes du déploiement, vous permettant d’aller directement à la section « Tester le Deploiement ». Assurez-vous de bien choisir la Région souhaitée pour cette stack avant le déploiement.

Créer et configurer les VPCs

Je commence par déployer les composants essentiels de ce design : VPCs, subnets, une internet gateway, une NAT gateway et les tables de routage. Les instructions suivantes deploient cet exemple dans la Région N. Virginia (us-east-1). Cela dit, vous pouvez déployer cette procédure dans toute Région, en ajustant les paramètres de Région et d’AZ (Zone de Disponibilité).

  1. Créez les trois VPCs suivant: Egress-VPC, App1-VPC, and App2-VPC. Renseignez les champs pour chacun d’entre eux, comme indiqué dans le tableau suivant. Pour plus d’informations, voir Getting Started with Amazon VPC.
    VPC name tag IPv4 CIDR IPv6 CIDR Tenancy
    Egress-VPC 192.168.0.0/16 No IPv6 CIDR Block Default
    App1-VPC 10.0.0.0/16 No IPv6 CIDR Block Default
    App2-VPC 10.1.0.0/16 No IPv6 CIDR Block Default
  2. Créez les subnets dans chaque VPC comme indiqué dans le tableau suivant. Pour plus d’informations, voir Creating a Subnet. Lors des prochaines étapes, vous configurerez les tables de routage pour rendre publics certains de ces subnets.
    Subnet name tag VPC AZ IPv4 CIDR
    Egress-Public-AZ1 Egress-VPC us-east-1a 192.168.1.0/24
    Egress-Public-AZ2 Egress-VPC us-east-1b 192.168.2.0/24
    Egress-Private-AZ1 Egress-VPC us-east-1a 192.168.3.0/24
    Egress-Private-AZ2 Egress-VPC us-east-1b 192.168.4.0/24
    App1-Private-AZ1 App1-VPC us-east-1a 10.0.1.0/24
    App1-Private-AZ2 App1-VPC us-east-1b 10.0.2.0/24
    App2-Private-AZ1 App2-VPC us-east-1a 10.1.1.0/24
    App2-Private-AZ2 App2-VPC us-east-1b 10.1.2.0/24
  3. Créez et attachez une internet gateway au VPC Egress-VPC. Utilisez IGW comme Name tag pour cette internet gateway. Pour plus d’informations, voir Creating and Attaching an Internet Gateway
  4. Créez une NAT gateway dans le VPC Egress-VPC. Pour plus d’informations, voir NAT Gateways. Créez seulement une NAT gateway pour cet exemple. En environnement de production, vous devriez créer une NAT gateway pour chaque Zone de Disponibilité dans laquelle vous avez un subnet, et utiliser la NAT gateway de la même Zone de Disponibilité.
    • Pour Subnet, entrez Egress-Public-AZ1,
    • Pour Elastic IP Allocation ID, choisissez Create new EIP.
  5. Créez deux tables de routage dans le VPC Egress-VPC. Pour les Name tags, utilisez Egress-Public-RT et Egress-Private-RT,
  6. Ajoutez une nouvelle route par défaut dans la table de routage Egress-Public-RT, avec la destination à 0.0.0.0/0. Associez la route avec l’internet gateway IGW. Pour plus d’informations, voir Adding and Removing Routes from a route table. Editez ensuite le « subnet association » et ajoutez les deux subnets Egress-Public-AZ1 et Egress-Public-AZ2 à cette table de routage,
  7. Ajoutez une nouvelle route par défaut à la table de routage Egress-Private-RT, avec la destination 0.0.0.0/0. Associez cette route à la NAT gateway. Editez ensuite la « subnet association », en ajoutant les deux subnets Egress-Private-AZ1 et Egress-Private-AZ2 à cette table de routage.

Deployer et Configurer la Transit Gateway

J’illustre ensuite comment déployer la nouvelle transit gateway et son raccordement aux trois VPCs, comment router le trafic vers Internet à travers la NAT Gateway. Vous pouvez le réaliser en connectant la Transit Gateway aux trois VPCs :

  1. Dans la console VPC, choisissez AWS Transit Gateway et créez une nouvelle Transit Gateway. Utilisez le nom TGW-Internet, ajoutez une description appropriée, et assurez-vous de décocher les cases Default route table propagation et Default route table association,
  2. Choisissez Transit Gateway Attachments et créez les attachements décrits dans le tableau suivant :
    AWS Transit Gateway ID Attachment type Attachment name tag Subnet IDs
    TGW-Internet VPC Egress-Attachment Egress-Private-AZ1
    Egress-Private-AZ2
    TGW-Internet VPC App1-Attachment App1-Private-AZ1
    App1-Private-AZ2
    TGW-Internet VPC App2-Attachment App2-Private-AZ1
    App2-Private-AZ2
  3. Choisissez AWS Transit Gateway Route tables et créez deux tables de routage. Nommez les tables de routage Egress-RouteTable et App-RouteTable et associez les deux tables de routage à la transit gateway TGW-Internet,
  4. Dans AWS Transit Gateway route tables, choisissez App-RouteTable, Associations, Create association. Associez les attachements App1-Attachment et App2-Attachment à cette table de routage,
  5. Dans cette même table de routage, choisissez Routes, Create route, tapez la route 0.0.0.0/0, et choisissez l’attachement: Egress-VPC,
  6. Ajoutez ces routes supplémentaires : 192.168.0.0/16, 172.16.0.0/12 et 10.0.0.0/8  en tant que Blackhole pour s’assurer que les VPCs ne peuvent pas communiquer entre eux à travers la NAT gateway,
  7. Dans AWS Transit Gateway route tables, choisissez Egress-RouteTable, Associations, Create association. Associez Egress-Attachment à cette table de routage,
  8. Dans cette même table de routage, choisissez Routes, Create route, et entrez 10.0.0.0/16 avec l’attachement App1-Attachment. Entrez ensuite une seconde route vers 10.1.0.0/16 avec l’attachement App2-Attachment,
  9. Dans la partie gauche de la console, choisissez Route Tables et éditez la table de routage par défaut associée aux VPCs App1-VPC et App2-VPC, en ajoutant la route 0.0.0.0/0 avec TGW-Internet comme target,
  10. Editez la table de routage Egress-Public-RT associée au VPC Egress-VPC en ajoutant les routes 10.0.0.0/16 et 10.1.0.0/16. Indiquez TGW-Internet comme target.

Lancer l’instance de test

Pour tester cette architecture, lancez trois instances EC2. Lancez la première dans le subnet public du VPC Egress-VPC, comme bastion. Lancez les deux autres instances dans les VPCs App1-VPC et App2-VPC. Pour plus d’informations, voir Launch an Instance :

  1. Lancez une instance EC2 dans le VPC Egress-VPC avec la configuration suivante : 
    AMI: Amazon Linux 2 AMI (HVM)
Instance Type: t2.large
Network: Egress-VPC
Subnet: Egress-Public-AZ1
Auto Assign Public IP: Enabled
Tags: Add a tag with Key: Name and Value: Bastion
Security Group: Create a new security group to allow SSH traffic from your Public IP address (you can find your current IP address by browsing to www.myipaddress.com)
  2. Lancez deux instances EC2, une dans le VPC App1-VPC et l’autre dans le VPC App2-VPC avec la configuration suivante : 
    AMI: Amazon Linux 2 AMI (HVM)
Instance Type: t2.large
Network: App1-VPC
Subnet: App1-Private-AZ1
Auto Assign Public IP: Disabled
Tags: Add a tag with Key: Name and Value: App1VM
Inbound Security Group: Create a new security group to allow SSH & All ICMP – IPV4 traffic from 10.0.0.0/16, 10.1.0.0/16 & 192.168.0.0/16.
    AMI: Amazon Linux 2 AMI (HVM)
Instance Type: t2.large
Network: App2-VPC
Subnet: App2-Private-AZ1
Auto Assign Public IP: Disabled
Tags: Add a tag with Key: Name and Value: App2VM
Inbound Security Group: Create a new security group to allow SSH & All ICMP – IPV4 traffic from 10.0.0.0/16, 10.1.0.0/16 & 192.168.0.0/16.

Tester le déploiement

Connectez-vous à l’instance de bastion avec SSH. Utilisez ensuite SSH pour vous connecter sur la machine App1VM. Pour vérifier qu’AWS Transit Gateway route correctement le trafic du VPC Egress-VPC vers la NAT gateway, utilisez curl pour vous connecter à différents sites Web. Utilisez ensuite SSH depuis App1VM pour connecter à App2VM. Bien qu’autorisé par les security groups, ces connexions devraient échouer. L’échec confirme qu’AWS Transit Gateway ne route pas entre les instances App1VM et App2VM. Le schéma suivant illustre le test.

Figure 2: Schéma d’architecture de test de Transit Gateway avec un trafic sortant vers Internet

  1. Dans la console EC2, identifiez l’adresse IP public dans le nom DNS public du bastion que vous avez lancé dans l’étape précédente,
  2. Utilisez SSH pour vous connecter au bastion : 
    ssh -i (chemin vers la clé) ec2-user@(IP publique du bastion)
  3. Copiez la clé SSH pour cette Région vers le bastion pour vous connecter sur App1VM: 
    vi sshkey.pem
Appuyer sur i afin de passer en mode insertion
Copier la clef privée précédemment téléchargée et appliquer-là dans vi
Appuyer sur Echap
Taper :wq pour sauvegarder et sortir
  4. Utilisez SSH pour vous connecter à l’instance App1VM depuis le bastion : 
    ssh -i ./sshkey.pem ec2-user@(IP privée de l'instance App1VM)
  5. Testez le filtrage d’URL avec curl et les URLs suivantes : 
    curl http://www.amazon.com
curl http://calculator.s3.amazonaws.com/index.html
  6. Vous pouvez aussi vérifier que la connectivité échoue avec la commande SSH suivante : 
    ssh ec2-user@(IP privée de App2VM)

Notions de coût

Dans la plupart des cas, une NAT gateway centralisée permet un meilleur retour sur investissement que de multiples Gateways. Même en considérant le coût de la NAT Gateway et le coût du transfert de données par Go, ce procédé devrait réduire le coût horaire de multiples NAT Gateways et simplifier leur gestion.

Si vous utilisez déjà des NAT gateways, la quantité de données traversant les NAT gateways reste constante, que cela passe par une une seule NAT gateway ou plusieurs.

Les facteurs suivants affectent le coût de la solution :

  • Attachement Transit gateway (horaire)
  • Données transitant par la Transit gateway (au Go)
  • NAT gateway (horaire)
  • Données transitant par la NAT gateway (au Go)

Vous pouvez vous reporter aux pages AWS Transit Gateway pricing et NAT Gateway pricing pour davantage d’informations.

Considérations de design

Aucun design ne peut prendre en compte tous les cas d’usages. Ainsi, des problèmes de coût et de performance peuvent rendre cette solution non appropriée pour certains cas d’usages.

Coût

Comme mentionné précédemment, il y a un coût data transfer additionnel de $0.02/Go comparé à des NAT gateways locales aux VPCs. En fonction du nombre de VPCs et du volume de données transférées, on peut envisager de déployer une NAT Gateway locale.

Performance

En déployant cette solution, il faut considérer le débit. A date (de publication du blog), une unique NAT gateway supporte 10Gbps de bande passante, montant automatiquement à 45Gbps. Si vous déployez deux NAT Gateways (une par Zone de Disponibilité) dans un environnement en production, votre bande passante sera plus élevée qu’avec une unique NAT Gateway. Si vos besoins en bande passante dépassent la capacité de deux NAT Gateways, vous pouvez envisager de connecter les VPCs à des NAT Gateways locales.

Une NAT Gateway supporte jusqu’à 55.000 connexions simultanées (ou environ 900 connexions par seconde / 55.000 conexions par minute) pour chaque unique destination. Si vous avez besoin de davantage de capacité, vous pouvez envisager de créer plusieurs NAT gateways pour distribuer la charge.

Avant de conclure, nous attirons votre attention sur deux autres élements critiques du design :

Routes Blackhole

En configurant la transit gateway, on a configuré tout l’espace IP de la RFC 1918 (192.168.0.0/16, 172.16.0.0/12 et 10.0.0.0/8) comme des destinations blackhole destinations dans la table de routage. Comme on annonce la route 0.0.0.0/0 dans chacun des VPCs App, le trafic destiné à un autre VPC est routé vers la NAT gateway, qui reroute le trafic vers le VPC destination. Par conséquent, la communication inter-VPC fonctionne alors que la transit gateway ne route pas directement ce trafic. L’ajout de routes blackhole permet d’éviter un routage non souhaité et assure que les VPCs restent isolés les uns des autres.

Inspections de sécurité

Le design présenté dans ce blog permet de centraliser le trafic sortant vers Internet à travers un VPC Hub supporté par deux NAT gateways. Vous pouvez aussi utiliser ce design et remplacer les NAT Gateways avec d’autres appliances de sécurité qui permettent de gérer le trafic sortant, par exemple capture de trafic, deep inspection et filtrage d’URLs.

Cependant, vous restez responsable de la haute disponibilité et de la montée en charge de ces appliances. AWS utilise une architecture distribuée pour maintenir la tolérance de panne et la montée en charge de chaque NAT Gateway. Si vous remplacez les NAT Gateways avec des instances EC2, votre design route chaque préfixe vers une seule instance sans health check sur les routes statiques. Assurez-vous que les appliances de sécurité peuvent réaliser la fonction de NAT et ont les bonnes configurations de routage.

Conclusion

Dans ce blog, nous avons illustré comment utiliser AWS Transit Gateway pour construire un point de sortie centralisé vers Internet. En consolidant le trafic sortant, vous pouvez gérer les aspects sécurité, configuration et montée en charge du trafic sortant en un point unique. Si vous avez un nombre conséquent de VPCs, nous pensons que cette centralisation permet de réduire votre charge de travail, votre facture et votre stress. Cependant, si ce design réduit le nombre de NAT gateways et d’internet gateways à gérer, gardez en tête qu’il faut déployer et gérer les transit gateways.

Enfin, nous avons simplement illustré du trafic sortant vers Internet par une NAT Gateway. Vous pouvez ajuster ce design en remplaçant les NAT gateways par des appliances tiers vous permettant de réaliser d’autres fonctions comme le filtrage d’URL, la détection de malwares et l’inspection de paquets.

Article traduit par Olivier Cahagne, Solutions Architect travaillant sur le secteur des télécommunications, LinkedIn.