Reseau Deep dive Amazon Virtual Private Cloud VPC

Transcript

Bonjour, bienvenue dans cette troisième journée de la Security Week. Aujourd'hui, nous sommes au rayon plomberie puisque nous allons aborder successivement deux sujets. Le premier sujet, le VPC, nous allons l'aborder en détail. Tout à l'heure, nous parlerons d'EDOS et des bonnes façons de s'en protéger avec l'architecture AWS et les solutions AWS adéquates. Merci d'être encore très nombreux. Visiblement, vous n'êtes pas en train de faire les courses de Noël. Pas encore. Merci beaucoup. Merci à Hugo pour sa présence et son soutien logistique sans faille. On est prêt, et donc on va attaquer immédiatement sur ce beau sujet qui est le VPC. Alors, le titre du webinaire est clair, c'est un deep dive, donc on ne va pas rappeler du tout de basique VPC, on va rentrer directement dans le vif du sujet. J'espère que vous êtes à l'aise sur les concepts de base du VPC, j'espère que vous êtes chargés en caféine, vous avez bien réveillé cet après-midi, et bien sûr n'hésitez pas pendant la présentation à envoyer toutes vos questions dans le chat. Hugo me les consolidera, et on essaiera de répondre au maximum tout à l'heure. Les 4 sujets dont on va parler durant ce deep dive sont les suivants : d'abord, on va parler de routage et de connexion privée dans le cadre d'architecture hybride. On va étudier un certain nombre d'options de connexion entre l'infrastructure cloud et votre data center. Ensuite, on va parler de peering de VPC. Vous m'excuserez d'utiliser le terme anglais, mais je pense que si je parle d'apairage de VPC, personne ne va comprendre de quoi je parle. Même si vous trouvez ce terme dans la doc française, je resterai sur le peering. Ça me paraît plus clair. Troisième sujet, ce que la doc AWS appelle la mise en réseau améliorée. Je ne vous cache pas que j'avais du mal à comprendre de quoi on parlait, quand on m'a dit qu'il s'agissait du enhanced networking, ça m'a paru plus clair, donc là aussi je vais garder le terme anglais. Comment améliorer la performance de ces instances EC2 avec un pilote réseau spécifique. Et puis nous terminerons avec un dernier sujet qui est l'utilisation de endpoints, donc de points de terminaison S3 à l'intérieur de votre VPC. Une technique qui n'est pas forcément très connue mais qui a de nombreux avantages. Commençons par un très bref rappel des configurations réseau disponibles sur AWS. Il était une fois EC2 classique, qui était le premier modèle d'architecture réseau d'AWS où toutes les instances étaient visibles sur internet, avaient des adresses IP privées et publiques auto-assignées. C'était le premier modèle d'AWS. Ce modèle était particulièrement simple mais il était sans doute insuffisant pour les gens qui souhaitaient avoir de l'infrastructure privée. Et donc AWS a ensuite introduit l'architecture de VPC que vous connaissez et dont on va parler en détail aujourd'hui, qui est extrêmement riche, extrêmement configurable, au prix parfois d'une certaine complexité puisqu'il faut créer ses VPC, créer ses subnets, etc. Et donc, histoire de trouver un terrain médian, le choix a été fait de créer, lorsque vous créez votre compte, un VPC par défaut avec des subnets publics qui vous permettent de lancer en particulier des frontaux web visibles sur internet, etc. Donc a priori, aujourd'hui, j'ai envie de dire que tout le monde est dans cette configuration-là. Si vous avez un compte AWS qui est antérieur au 4 décembre 2013, je suis sûr qu'il y a des gens qui nous écoutent et qui sont dans cette situation-là. Si vous avez un compte qui est antérieur à cette date, vous étiez en EC2 classique, et j'espère que vous avez migré depuis vers le modèle VPC. Si vous avez un compte qui est postérieur à cette date, vous n'avez plus la possibilité d'utiliser ces deux classiques, et donc vous avez nécessairement un modèle VPC et un VPC par défaut. C'est vraiment de ça qu'on va parler aujourd'hui. Comment identifier son VPC par défaut ? Bien sûr, vous pouvez aller dans la console, mais aujourd'hui on est dans un deep dive, donc on ne va pas du tout regarder la console, on va travailler uniquement en ligne de commande. Vous avez une commande qui est `describe account attributes` qui, comme son nom l'indique, va lister les attributs d'un compte AWS, et l'un de ces attributs s'appelle `default VPC`. Comme vous le voyez là, et donc en utilisant, en exécutant cette commande, vous allez récupérer l'identifiant du VPC par défaut et au passage confirmer que vous êtes bien en configuration VPC. Une fois de plus, pour les gens qui sont sur des comptes antérieurs à décembre 2013, si vous utilisez cette commande, vous verrez un résultat différent. J'espère que vous avez tous migré depuis vers le VPC. Comment identifier son VPC par défaut programmatiquement ? Avec cette commande, `describe account attributes`. Rentrons directement dans le sujet : routage et infra-hybride qui est le premier gros sujet du jour. Donc le contexte dans lequel on va se placer, c'est le contexte d'une infrastructure sur site, donc un data center, qui est un data center public ou un data center d'entreprise, peu importe, que vous souhaitez connecter à AWS et sur lequel vous voulez définir des règles. Première étape, évidemment, créer un VPC. Là, on prend un petit exemple tout simple où on crée un VPC avec un range d'adresse avec une classe B en 10.10.0.0. On crée deux subnets en classe C, 10.10.1.0, 10.10.2.0, et on les met dans des zones de disponibilité différentes, ce qui est une bonne pratique. Pour les gens qui pourraient être effrayés par la ligne de commande, je précise quand même que quand vous utilisez la console EC2 qui vous donne accès au VPC, lorsque vous voulez créer des VPC, on a un certain nombre de wizards qui permettent de créer des VPCs avec des subnets publics, des subnets privés, etc. Pour commencer, peut-être, si vous voulez commencer à créer des VPC en plus de votre VPC par défaut, c'est peut-être une bonne idée de le faire une fois ou deux avec la console pour vous rassurer et vérifier que vous n'oubliez rien. Après, je vous conseille de passer rapidement sur l'automatisation, soit du script, soit du CloudFormation. Si vous créez beaucoup de VPC, beaucoup d'environnements différents, vous voulez et pas le taper à la main et encore moins le faire dans la console à chaque fois. Première étape, créer le VPC. Ensuite, on va vouloir une connectivité. Donc on va créer la première étape, la plus immédiate à mettre en place, c'est de créer une connexion VPN entre votre data center et votre VPC. Donc côté data center, il vous faut un équipement réseau de votre marque préférée. Je ne sais pas, Cisco, Juniper ou quelques autres. Je pense que quand on a dit Cisco et Juniper, on a déjà couvert pas mal de monde. Donc ça, c'est à vous de jouer. Et côté VPC, on va créer un objet qui s'appelle un VPN Gateway. Donc il va être l'endpoint du VPN côté AWS, c'est la première commande que vous voyez là. On va l'attacher au VPC créé précédemment. Ensuite, sur ce gateway, on va déclarer le Customer Gateway, troisième commande, où donc là, on donne finalement les paramètres de votre gateway, donc l'IP publique de votre routeur et son numéro d'AS qui peut être un AS privé, on en parlera tout à l'heure. Et donc une fois qu'on a fait ça, il reste à créer la connexion VPN elle-même, et donc vous voyez les paramètres ici qui sont d'une part le VPN Gateway, d'autre part le Customer Gateway, et puis enfin l'utilisation d'IPsec pour monter le tunnel. Alors, point important qui peut vous freiner, évidemment, côté AWS, la configuration n'excède pas ce que je montre là, là aussi vous pouvez le faire dans la console si vous préférez, de votre côté, sur votre équipement, et effectivement il va falloir taper de la configuration, rentrer les commandes. Alors sachez que nous vous fournissons tout un tas de modèles dans lesquels il vous reste à rentrer l'identifiant du VPN Gateway de notre côté, etc. On les fournit pour les principaux équipements du marché. Une fois de plus, si vous utilisez du Cisco, de l'ASA, de l'Juniper, des choses comme ça, vous allez sur les liens qui sont indiqués là en bas trouver le template de connexion pour ne pas avoir à réinventer une config compliquée pour vous connecter à AWS. N'hésitez pas à aller voir la doc, vous pouvez copier-coller les scripts de CLI qui sont indiqués en insérant les paramètres du gateway, et vous devriez réussir à vous connecter sans aucune difficulté. Une fois que vous avez fait ça, vous avez un VPN entre AWS et votre site. Alors, j'allais dire accessoirement, mais non, puisque l'objectif c'est quand même de lancer des charges de travail dans AWS. Ici, dans le cadre du VPC, ce n'est effectivement pas le sujet de la discussion, mais une fois que vous avez monté le VPC et monté le VPN, vous pouvez avoir envie de lancer quelques instances adéquates dans les différents subnets, ne serait-ce que pour tester votre connectivité, faire des ping et vérifier que la communication fonctionne bien dans les deux sens. C'est toujours plus intéressant de le tester de bout en bout que juste d'équipement à équipement. Pas de surprise, Run Instance, une AMI, le subnet dans lequel vous les lancez, vous connaissez ça par cœur. Deuxième canal de communication, l'utilisation de Direct Connect. Alors Direct Connect en tant que tel mériterait un webinar d'une heure. Il se trouve que j'ai en ligne une présentation sur Direct Connect dont vous voyez l'URL en bas du slide que je vous conseille de parcourir si vous n'êtes pas bien à jour sur Direct Connect, ou si vous voulez vous rafraîchir la mémoire, j'ai essayé d'être le plus pratique et le plus concret possible. Avant de parler des commandes, la seule chose à savoir, c'est que, ça paraît inévident, il ne suffit pas de taper trois commandes ou deux commandes de CLI pour avoir un lien Direct Connect. Il y a un process préalable de souscription de ce service, soit en direct auprès d'AWS, soit auprès d'un partenaire. Donc ne tapez pas ces commandes-là en espérant avoir un lien Direct Connect prêt en 10 secondes, ce n'est pas aussi simple que ça. Il peut y avoir du travail aussi auprès de votre fournisseur de transit, etc. Donc ça c'est expliqué dans l'autre présentation, mais peut-être qu'en 2017, si vous souhaitez, on fera une session dédiée à Direct Connect. Donc en supposant que vous ayez fait tout ce travail préalable, et que votre hébergeur et votre opérateur vous aient fourni les cross connect, etc, effectivement ces commandes-là vont vous permettre de monter le lien direct connect. Donc la première qui va juste créer une connexion entre un point de présence, donc le paramètre `location` qui est l'emplacement du pop direct connect, alors ici je pense qu'on parle d'un lien Equinix étant donné le nom. Vous pouvez les lister aussi avec la CLI. C'est un lien 1 giga qui s'appelle `MyFirst`. Ça, ça va vraiment juste enregistrer la connexion côté AWS. Ensuite, on va passer la commande `Create Private Virtual Interface` qui va référencer la connexion qu'on vient de créer en lui donnant un nom, un VLAN, un numéro d'AS, et puis les adresses IP respectives d'Amazon et de votre routeur. Et donc ça, vous croisez les doigts, si tout se passe bien, si tous les intervenants ont bien fait leur boulot et si le lien fonctionne, à l'issue de cette commande, vous devez pouvoir pinguer votre infra, de part et d'autre du lien. Une fois de plus, Direct Connect, il y a énormément de choses à dire. Là, je vous montre simplement les commandes finales. Peut-être un point sur pourquoi Direct Connect par rapport à un VPN. C'est peut-être un point intéressant, qu'est-ce que ça apporte. Un VPN, vous passez par l'Internet public, a priori. Donc vous êtes soumis aux vicissitudes de l'Internet public en termes de disponibilité, de performance, de latence, etc. Avec un lien Direct Connect, vous avez un lien privé dédié, avec une latence et des performances prévisibles et stables dans le temps. Et puis surtout, vous avez un lien dédié en termes de débit, ce qui veut dire que si vous prenez un lien 1 giga ou un lien 10 gigas, vous aurez 1 giga ou 10 gigas de débit de manière constante et prévisible. Ce qui, dans le cas d'architecture hybride, de réplication de bases de données, etc., est vraiment important. Donc il n'est pas indispensable d'avoir un Direct Connect. Mais si votre archi hybride est là pour durer, si ce n'est pas juste une phase de migration, on vous conseille d'avoir du Direct Connect. N'hésitez pas à poser des questions sur Direct Connect, j'y répondrai tout à l'heure. Alors là, on voit déjà qu'on a plusieurs liens et on pourrait avoir plusieurs... plusieurs VPN et plusieurs Direct Connect, donc rentrons un petit peu dans les détails de ces connexions. Ici, on voit toujours notre data center avec un équipement client et on voit qu'il est connecté aux VPCs, c'est exactement la configuration de tout à l'heure. Sachez que les connexions VPN que nous montons sont systématiquement redondantes, vous montez deux tunnels IPsec qui vont correspondre chez nous à des zones de disponibilité différentes. Donc c'est vraiment ce que j'ai expliqué à l'instant, ce n'est pas deux fois ce que j'ai expliqué tout à l'heure, c'est la même chose, mais simplement en zoomant sur ce qui se passe de notre côté. Donc on a une connexion VPN, deux tunnels qui sont configurés pour cette connexion et donc qui pointent sur deux zones de disponibilité différentes. Donc ça nous permet, en cas de problème d'un gateway dans une de nos zones de disponibilité, d'avoir une bascule sur l'autre zone de dispo, sans que vous ayez à faire quoi que ce soit. Si ce n'est utiliser BGP pour le routage, puisque si vous utilisez de votre côté des routes statiques, c'est vrai comme moi que des routes statiques ne géreront pas le failover. Donc on vous conseille très fortement d'utiliser BGP pour le routage entre votre data center et nous, quitte à utiliser des numéros d'AS privés, si vous n'avez pas d'AS public, ce n'est pas grave, cet AS il sert uniquement sur ce lien entre votre routeur et le gateway, donc vous pouvez prendre un AS privé, il n'y a absolument aucune difficulté. Donc ça, c'est déjà un premier niveau de fiabilisation de la connexion. On vous recommande de doubler de votre côté votre équipement si jamais votre passerelle tombe, vous perdez la connectivité entre votre infra et le VPC. Dans le cas d'architecture fortement couplée, de bases de données répliquées, de choses comme ça, c'est catastrophique, donc on vous conseille d'avoir deux équipements redondants de votre côté, qui chacun disposeront d'une connexion VPN elle-même, comme je l'ai expliquée à l'instant, composée de deux tunnels. Donc ça élimine le SPOF de votre côté, une fois de plus sur des archi-hybrides, c'est très très fortement conseillé. Et puis, la meilleure solution, c'est celle que j'ai montrée sur l'un des slides précédents, c'est de cumuler une connexion VPN, voire plusieurs connexions VPN, et des connexions Direct Connect. Certains clients allant même jusqu'à avoir plusieurs liens Direct Connect, comme vous le voyez ici, sur la partie... je vous montre avec la souris, là on a deux liens direct connect qui sont potentiellement même des liens direct connect issus de points de présence différents. Nous avons en fonction des régions différents points de présence direct connect. Donc il est tout à fait possible que cette connexion direct connect là et celle-ci soient physiquement séparées dans des bâtiments séparés, chez des fournisseurs séparés, ce qui vous donne encore un niveau de redondance géographique supplémentaire. L'idée étant évidemment de monter ces direct connect vers des zones de disponibilité là aussi différentes et puis toujours d'avoir un VPN en secours. Donc là ça vous donne vraiment une redondance maximale avec deux tunnels VPN, et peut-être quatre si vous avez suivi le conseil du slide précédent, et puis un, voire deux liens direct connect physiquement distincts, avec des chemins de connexion et des fibres complètement différentes. Et là, dans le cas d'archi-critique, on est obligé d'aller jusqu'à ce genre de solution. Alors, ça amène très vite une question supplémentaire qui est de se dire, ok, on a compris, on comprend l'intérêt d'avoir du multilien, etc. Maintenant, comment ça se passe en termes de routage ? Donc, de votre côté, du site client, donc le trafic entrant sur AWS, du site client vers le Virtual Gateway, eh bien, il est effectivement possible que vous ayez plusieurs routes. C'est votre équipement, donc c'est à vous de jouer. C'est à vous de configurer votre équipement. On vous fournit des modèles, mais attention au routage que vous utilisez, comme je disais tout à l'heure. Si vous utilisez des routes statiques, vous n'aurez pas de failover automatique, sauf à automatiser, à scrypter. Par défaut, vous aurez le fail, mais vous n'aurez pas le hover. C'est pour ça qu'on vous conseille d'utiliser BGP qui est évidemment dynamique et la meilleure solution pour gérer ce multi lien. Vous pouvez avoir une configuration active-passive. Par exemple en privilégiant un chemin, vous pourriez dire je veux que mon trafic passe par le direct connect parce que j'ai plus de débit, j'ai des performances garanties, prévisibles, j'ai une sécurité accrue parce que c'est un lien privé, etc. Donc vous pourriez dire, je veux que tout mon trafic passe par le Direct Connect, et si jamais le Direct Connect tombe, à ce moment-là, BGP le détectera et fera passer le trafic sur le VPN. Si vous êtes Cisco, vous pouvez jouer avec les attributs Wait et Local Préférence de la connexion BGP pour faire passer le trafic directement sur un chemin plutôt que sur un autre. Vous pouvez aussi faire de l'actif-actif, par exemple si vous avez deux liens direct connect et que vous voulez les utiliser tous les deux, ce qui est une bonne idée, vous pouvez tout à fait faire du BGP multipasse. Si vous avez des liens de vitesse différente, ça pourrait même être un VPN et un lien direct connect, pourquoi pas, vous voulez l'utiliser en actif-actif. Idem avec Cisco, si vous pouvez jouer sur la trému BGP Link Bandwidth qui vous permet d'indiquer à BGP la bande passante du lien et il fera un load balancing proportionnel à la capacité des liens. Mais une fois de plus, là c'est à vous de jouer, c'est à votre équipe réseau de configurer ça. Dans l'autre sens, sur le trafic sortant, si vous annoncez des routes en BGP sur votre passerelle venant de plusieurs chemins, elles vont être reçues sur le gateway et on peut avoir plusieurs possibilités. Là j'ai envie de dire comme d'habitude, AWS ne fait rien de très spécifique de ce point de vue là, on applique les règles habituelles dans ces cas là, à savoir que premièrement c'est le préfixe IP le plus spécifique qui va être privilégié, donc si vous avez une route qui annonce 10.000 en classe C, on la préférera à la route qui est annoncée en 10.000 classe B, classique. Si jamais les préfixes sont identiques, il est possible que deux chemins annoncent exactement le même préfixe IP, à ce moment-là on préférera une route statique à une route BGP, avec le problème qu'une route statique lorsqu'elle tombe, en tout cas de votre côté, elle peut induire un problème de disponibilité, mais en tout cas côté Gateway, si jamais il y avait une route statique, c'est celle-là qu'on prendrait. Et si vraiment on a des routes BGP qui sont identiques, à ce moment-là, comme d'habitude, on prend le chemin d'AS-LEC plus court. Sachant que vous pouvez aussi utiliser ce mécanisme pour privilégier ou en l'occurrence défavoriser une route. Donc si vous voulez que votre trafic passe par le Direct Connect et pas par le VPN, à ce moment-là vous pouvez rallonger le préfixe avec ASPass sur le VPN tout simplement pour que le BGP côté AWS prenne la route plus courte, qui est celle du Direct Connect. Si vraiment tous les chemins sont de même longueur, à ce moment-là, comme d'habitude, c'est l'origine du chemin qui fera foi, donc une route interne qui a été configurée explicitement sur un équipement par une commande network, etc., sera préférée à une route qui a été distribuée. Donc là, c'est les règles traditionnelles sur ce genre d'équipement. Si vous êtes familier de ça, vous retrouverez la même chose, c'est du BGP4 standard de notre côté, il n'y aura pas de surprise. Voilà un ensemble de solutions pour gérer les connexions multiples et router votre trafic sur le lien que vous avez choisi. Plus d'infos sur la page qui est indiquée là, si vous voulez relire tout ça à tête reposée. Ok, alors revenons sur nos architectures. On a connecté notre data center au VPC avec un VPN et un Direct Connect. Et maintenant, on voudrait vraiment définir des tables de routage pour nos instances. Dans un VPC, on a une table de routage par défaut qui est créée pour le VPC et qui va s'appliquer par défaut à tous les subnets. On va pouvoir utiliser la commande `create route` pour, dans cette table de routage, ajouter ici une route par défaut qu'on va envoyer sur le gateway. Donc là on crée pour les deux subnets, tout le trafic par défaut des deux subnets sera envoyé au gateway qui lui-même choisira les routes vers votre datacenter. Alors il est peu probable que vous ayez envie d'avoir quelque chose d'aussi simple que ça, il est possible que vous ayez envie d'avoir du trafic public vers Internet et du trafic privé vers votre data center. Et donc là, pour gérer le trafic public, on va créer une Internet Gateway avec la première commande. On va l'attacher au VPC. On va supprimer cette route par défaut qu'on a créée à l'instant et qui routait tout vers la VPN Gateway. On va recréer une route par défaut qui envoie tout le trafic vers l'Internet Gateway. Donc par défaut, tout va sur Internet, sauf évidemment qu'on va créer une dernière route sur 192.168.0.0 qui est donc le range de votre data center et là on va l'envoyer vers le VPN Gateway. Donc une route vers votre data center et puis tout le reste vers internet. Vous voyez en quelques commandes très très facilement on configure le routage pour l'ensemble des instances du VPC. Il n'y a pas beaucoup de difficultés de ce point de vue là. Alors ça c'est bien, maintenant. Et ça peut fonctionner très bien. Maintenant, imaginons que dans votre data center, vous ayez un environnement réseau assez dynamique, assez riche, avec pas mal de subnets, avec pas juste une classe B, 192.168.0.0, et puis on route tout vers ça. Donc plein de subnets, potentiellement qui changent, etc. Voilà. Évidemment, vous n'avez pas envie de reconfigurer à la main les tables de routage du VPC à chaque fois que quelque chose a changé dans votre data center. On peut propager les routes reçues par le Virtual Gateway, qui ont été annoncées par votre infra, reçues par le Virtual Gateway, on peut les propager dans la table de routage du VPC. Pour ça, on va... effacer la route qu'on a créée sur le slide précédent et on va avec cette commande `enable virtual gateway route propagation` activer la propagation automatique des routes du gateway vers la table de routage du VPC ce qui fait qu'à chaque fois que vous allez si vous créez un nouveau subnet à l'intérieur de votre entreprise et qu'il est annoncé en BGP par l'un de vos routeurs Edge est reçu par le Virtual Gateway, à ce moment très vite, il va être également visible dans la table de routage du VPC, et donc accessible à vos instances. Donc une infrastructure beaucoup plus dynamique, mais beaucoup plus également résiliente au changement. Une bonne solution. Que se passe-t-il si vous avez envie de faire un routage spécifique à un sous-réseau, vous pouvez, on a vu jusqu'ici que la table de routage était attachée au VPC, vous pouvez aussi attacher une table de routage à un subnet en particulier. Donc ici je crée un troisième subnet, 10.10.3.0, je crée une nouvelle table de routage, je l'associe au subnet, et en l'occurrence ici, dans cette table de routage, de 10.10.30, j'ajoute une route par défaut qui sort sur internet. Donc voilà, ce subnet là, il n'a pas du tout accès, il n'a pas de route vers votre datacenter. Si vous voulez un subnet public, complètement isolé du reste finalement, voilà comment vous pouvez faire. Vous pouvez avoir une table de routage par sous-réseau si vous le souhaitez. Il y a une autre façon de monter les VPN, qui me paraît compliquée personnellement, mais ça n'est que mon avis. Mais si vous avez envie de monter un VPN à la main entre des VPC, sans passer par des virtual gateway, bien sûr vous pouvez le faire, il n'y a pas de problème là-dessus. Vous pouvez démarrer une instance EC2 de chaque côté, qui va exécuter votre serveur de VPN préféré. Par contre, il y a une petite subtilité qui est mentionnée ici, c'est que ces deux instances marquées VPN sur ce schéma vont recevoir du trafic qui ne leur est pas destiné et donc il faut désactiver le trafic ce qu'on appelle le source destination check qui vérifie qu'une instance ne reçoit que du trafic qui lui est destiné. Ici ce n'est pas le cas puisque les instances VPN vont recevoir du trafic qu'elles doivent envoyer à leur homologue dans l'autre VPC. Donc il faut que vous pensiez à désactiver sur l'interface réseau de ces instances le source destination check, sinon le trafic est dropé et ça ne marchera pas. Donc une fois que vous avez fait ça, vous pouvez monter un tunnel entre vos deux VPC. Une façon de le faire, un peu compliquée à mon avis, mais pourquoi pas. Et puis pour que les instances de gauche puissent parler aux instances de droite et réciproquement, il va falloir dans les deux VPC créer une route dans la table de routage, soit du VPC soit du subnet, il va falloir créer une route qui va envoyer le trafic pour le subnet de l'autre VPC à l'instance VPN que vous venez d'activer. Dans le VPC A à gauche, on va définir la destination 10.20.0.0 vers l'instance qui est l'instance VPN et puis la même chose de l'autre côté. Voilà comment vous pouvez faire un VPN dans EC2. On peut aussi avoir dans le même style, si on veut avoir un firewall dans EC2, pourquoi pas, on peut faire le même genre de choses. Donc lancer une instance EC2 qui va exécuter votre firewall, il faut là aussi désactiver le source destination check et modifier la table de routage pour que tout le trafic sortant de vos instances passe bien par le firewall, donc une route par défaut en 0.0.0.0 vers l'instance ID concernée, et puis une route par défaut du firewall vers Internet, donc à nouveau destination par défaut vers Internet. Vous pouvez utiliser les security group, vous pouvez utiliser les VPN gateway, etc. Maintenant, si pour une raison particulière, vous avez besoin de le faire sans utiliser un service AWS, que ce soit en VPN ou en NAT Firewall, c'est tout à fait possible. Voilà, modulo cette configuration. Voilà qui conclut la première partie, qui était la plus longue, la plus complexe. Et on va maintenant passer au deuxième sujet qui est le peering de VPC. On respire un coup, prenez une petite gorgée de café, j'espère que vous êtes toujours vivants. Alors, pourquoi faire du peering entre les VPC ? Le cas, alors il y a un cas, j'ai envie de dire basique, j'ai des instances d'un VPC et je veux qu'elles parlent à un autre VPC, donc oui, ok, très bien, il faut qu'il soit péré. Mais de manière plus générale, on va souvent voir chez les clients des architectures de ce type, donc avec un VPC, une topologie un peu en étoile comme ça, un VPC qui va contenir des services communs, de la journalisation, on n'a toujours pas parlé de CloudTrail, on va finir par en parler, mais ça pourrait être ce genre de choses, du monitoring ou des outils de sécurité, des outils d'administration, bref, des fonctions centrales généralement d'administration de sécurité, d'accounting, auxquelles vous voulez que tous vos VPC aient accès. J'en profite pour vous rappeler, parce que je me suis fait avoir par ça il n'y a pas longtemps, que la service limite par défaut est de 5 VPC par région. Donc vous voyez sur ce schéma on en a déjà plus que ça. Donc si vous avez besoin de créer plus de VPC, plus que 5, vous créez un ticket au support, vous leur demandez d'augmenter la limite, ils vont vous l'augmenter. Mais attention, la limite par défaut est de 5 VPC, ce qui est assez bas et ne permettrait pas par exemple de faire cette topologie-là. Une autre raison de péré, c'est d'avoir découpé son infrastructure en différents VPC, ce qui est effectivement une bonne pratique, et de dire peut-être que j'ai un VPC de développement, j'ai un VPC de test, j'ai un VPC de production, etc. Donc ça me permet d'isoler mes ressources et c'est une bonne pratique. Maintenant j'ai besoin évidemment de pouvoir avoir quelques accès quand même d'un VPC vers un autre. Donc là aussi le peering peut être une approche intéressante. Alors premier cas, comment est-ce qu'on monte un peering entre des VPC du même compte ? Donc imaginez un VPC dev et un VPC prod par exemple. Alors vous allez choisir un côté, vous allez créer un peering dans ce VPC. Vous spécifiez l'identifiant du VPC dans lequel vous êtes et l'identifiant du peer. Vous allez passer une deuxième commande qui va accepter la connexion de peering que vous venez de créer. Et puis ensuite vous allez tout simplement créer des routes des deux côtés. Vous allez dans les tables de routage des VPC respectifs rajouter des entrées vers leur peer. En référençant le paramètre VPC peer, en référençant le peering que vous venez de créer. Tout ça c'est facile puisque vous êtes propriétaire de tous les VPC, donc vous êtes totalement autonome et vous pouvez en quelques commandes créer le peering entre vos VPC. Super simple. Maintenant, si les VPC sont dans des comptes différents, alors peut-être que ces comptes vous appartiennent tous, ou peut-être que l'un des comptes appartient peut-être à un de vos fournisseurs SaaS, peut-être que vous utilisez une solution SaaS qui est déployée dans AWS dans un autre VPC, et pour y accéder, vous voulez faire un peer-reign. Donc là aussi, vous allez créer une peering connection un petit peu de la même façon, en donnant l'identifiant de votre VPC, l'identifiant du peer et le numéro de compte auquel le peer appartient. Et dans ce compte-là, peut-être qu'il vous appartient aussi, mais peut-être pas, je reprends mon exemple du fournisseur SaaS, vous allez exécuter dans votre VPC l'acceptation de la peering connection. Et puis, votre fournisseur, de son côté, va devoir accepter la peering connection venant de vous. Ce qui paraît là aussi rassurant de se dire qu'il faut que les deux côtés soient d'accord pour que le peering soit mis en place. Voilà, ceci dit, ce n'est pas très compliqué, ça doit pouvoir se faire rapidement. Vous pouvez monter... Un peu comme tout à l'heure, vous pouvez faire du peering avec un firewall entre les deux VPC. Comme tout à l'heure, on va rediriger dans le VPC de gauche, on va rediriger tout le trafic destiné au VPC de droite vers une instance EC2 qui exécute un NAT et un firewall, et on va ajouter dans la table de routage une route vers le peering. Ce que j'ai expliqué tout à l'heure, entre votre infrastructure physique et votre infrastructure cloud, tout ça peut aussi marcher entre VPC péré, il n'y a pas de grosses différences de ce point de vue là. Les mêmes mécanismes peuvent fonctionner. La différence c'est que vous référencez à chaque fois le peering en question. Quelques points importants à connaître sur le peering. Les VPC doivent être dans la même région. Si vous devez faire communiquer des VPC qui sont dans des régions différentes, ça ne se fera pas avec un peering. Vous passerez par l'Internet public et vous montrerez des VPN, etc. Les plages d'adresse des VPC des péré ne peuvent pas se chevaucher, ce qui paraît raisonnable. Donc, deux VPC qui peer, doivent avoir des ranges d'adresse distincts. Pour le routage, on utilise les adresses privées pour le routage. Tout ça se passe en interne, donc pas du tout question d'utiliser les IP publiques, les Elastic IP, etc. Vous devez vraiment vous baser sur les adresses privées. Et depuis quelques semaines, vous pouvez également utiliser les adresses IPv6. Alors pas dans toutes les régions, mais le routage IPv6 est disponible et sera étendu rapidement à toutes les régions. Jusqu'à il y a quelques mois, on ne pouvait pas référencer les security group entre VPC, ce qui était problématique pour définir des règles d'accès entre instances dans des VPC différents. Il fallait se baser sur les préfixes IP, pas toujours simple. Et depuis mars, vous pouvez référencer les security group entre VPC. Je vous renvoie à la doc pour comment le faire, mais c'est possible, ça simplifie bien la vie. Idem, depuis le mois de juillet, on peut utiliser une résolution DNS privée entre VPC, ce n'était pas le cas avant. Idem, beaucoup plus facile pour se faire parler des instances qui sont situées dans des peers. Puis un dernier point qui est très très important, c'est que le peering n'est pas transitif, ce qui veut dire que si A peer avec B et B peer avec C, A ne peer pas avec C. Donc c'est valable pour les peerings et c'est valable pour les VPN et les Direct Connect, etc. Donc le peering ne concerne que les deux VPC qui sont explicitement reliés par la liaison de peering. Donc si vous avez besoin que A parle à C, il faut qu'il y ait un peering entre A et C. Quitte à faire des topologies full mesh ou des trucs comme ça, si vous avez besoin que tous les VPC parlent à tous les VPC, ce qui est peut-être peu probable. Mais voilà, gardez bien ce point-là à l'esprit, il n'y a pas de transitivité. Vous devez monter explicitement les peerings entre VPC qui veulent se parler. Troisième sujet, le réseau amélioré. Le point important ici, c'est le point clé pour la performance des instances, c'est combien de paquets par seconde elles sont capables d'envoyer et de recevoir. C'est vraiment le point qu'on observe comme étant le plus important. Et dans le schéma par défaut de réseau EC2, on travaille avec des interfaces virtuelles. On a des interfaces qui sont visibles sur les instances et qui envoient et reçoivent des paquets à travers la couche de virtualisation de l'instance EC2 et cette couche de virtualisation elle accède elle-même à la carte physique du serveur. Donc le fait de traverser cette couche de virtualisation a introduit un overhead de performance et un côté peut-être moins prévisible sur les performances réseaux. Et donc pour ce problème, on a introduit un mécanisme au nom barbare qui s'appelle SRIOV, qui veut dire Single Root I/O Virtualization. Ce qu'il faut retenir, ce qui est important, c'est qu'avec ce mécanisme, les paquets réseau ne traversent plus la couche de virtualisation, comme vous le voyez sur le schéma. En fait, on va modifier le driver réseau qui tourne sur l'instance et on va adresser directement le trafic réseau à ce nouveau driver qui lui est capable d'accéder directement à l'interface physique. On bypass complètement la couche de virtualisation, on gagne en latence et on gagne en prédictibilité. Le truc c'est qu'évidemment il faut que ce driver soit activé sur votre instance. Une petite comparaison de perf, en jaune vous voyez les perfs dans le modèle classique et vous voyez en rose les perfs dans le modèle amélioré. TP0 c'est les meilleures performances qu'on a observées, TP50 c'est 50% des cas, c'est les percentiles habituelles, 99, 99, 100%. Alors vous voyez quand on regarde la meilleure performance, oui il y a un petit gain avec le réseau amélioré, mais pas énorme. Par contre, quand on va sur les percentiles élevés, on voit que la performance avec le réseau amélioré est d'une part bien meilleure, la latence est bien plus faible et surtout elle est extrêmement constante. Vous voyez la différence qu'il y a entre le TP0 et le TP100. TP0 c'est le meilleur des cas, TP100 c'est le pire des cas, c'est plus que le simple au double. Alors que pour le réseau amélioré finalement on a peut-être 10% d'écart au grand maximum, même pas. Donc c'est vraiment ces deux sujets là, oui on va cracher plus de paquets par réseau mais surtout les performances vont être beaucoup plus stables et beaucoup plus prévisibles, ce qui est important pour certaines applications. Donc comment est-ce qu'on s'en sert ? Alors la bonne nouvelle c'est que pour les AMI récentes et les familles d'instances récentes, il est probable que vous profitiez déjà du Enhanced Networking. Que ce soit sur Linux ou sur Windows, il est probablement déjà activé. Je vais vous montrer comment vérifier et comment l'activer si ce n'est pas le cas. Comment vérifier qu'il est activé sur Linux ? Je vous montrerai Windows ensuite. Vous vous connectez sur votre instance, vous exécutez cette commande et ethtool -i eth0 et si le driver installé est VIF, donc Virtual Interface, vous êtes dans l'ancien modèle. Si c'est ce nom barbare, IXGBEVF, vous êtes en réseau amélioré. Cette simple commande vous dit si oui ou non vous êtes au niveau de performance max ou pas. Sur les instances, sur quelles instances on a le support de SR-IOV ? Je ne vais pas dire toutes parce qu'elles n'y sont pas toutes, mais vous voyez que sur les C, les D, les I, les R, etc., on y est. Qu'est-ce qui manque finalement ? Il manque surtout T2. Donc T2 est un bon environnement, mais il n'est pas conçu pour les charges de travail intensives. Au-delà du côté burstable des instances, il y a aussi le fait que vous n'avez pas l'enhanced networking sur les instances T2. Pour des environnements de développement, des environnements où les charges ne sont pas énormes, ce n'est pas gênant. Mais si vous avez besoin de trafic réseau élevé, une bonne raison de ne pas utiliser T2, là voilà. Il faut aussi que vous utilisiez la virtualisation matérielle. Je doute qu'il y a encore beaucoup de gens qui utilisent la para-virtualisation. Il faut que vous ayez un noyau récent, mais vous voyez, un Linux 2.6.32, j'espère bien que tout le monde est plus récent que ça. Windows Server 2008, ça, je m'abstiendrai de tous commentaires. Et il faut que vous ayez le driver installé. Donc si vous êtes sur les instances, les grands classiques, les C4, les M4, et que vous avez un Linux même à peine récent, vous êtes bien. Ok. Pour vérifier vos AMI, vous pouvez utiliser cette commande si vous avez un petit doute, pour savoir si c'est bien une AMI en virtualisation hardware, mais une fois de plus, en 2016, je pense que ce n'est plus un problème. Vous pouvez vérifier si votre instance est bien au-delà du driver, est-ce qu'il est bien activé ou pas avec cette commande. Vous voyez que là on lui demande l'attribut sriov-net-support et il n'est pas présent. Donc là cette instance n'est pas activée. Donc pour installer le driver, vous commencez par mettre à jour votre distribution Linux, ça ne fait jamais de mal. Vous la rebootez, histoire qu'elle applique bien les patches de sécurité et qu'elle installe le nouveau driver en question, vous l'arrêtez et vous modifiez l'attribut SR-IOV net support en activant le mode simple qui est le seul mode qui est supporté aujourd'hui. Il y a deux choses importantes ici, il faut stopper l'instance pour faire ce changement, vous ne pouvez pas le faire à la volée sur une instance qui s'exécute. Et surtout, ce n'est pas réversible. Donc si vous activez ce mode, vous ne pouvez pas revenir en arrière sur l'instance. Donc avant de le faire, je vous conseille de faire un test, de vérifier que tout se passe bien, que vous ne cassez pas la charge de travail et que l'instance ne part pas dans un mode bizarre. Ça ne devrait pas arriver, mais voilà. Je pense qu'il est plus prudent de cloner votre instance, de faire un test à part et de s'assurer que tout marche bien avant de le faire en live sur des instances de production. Une fois que c'est fait, une fois que vous avez activé l'attribut, vous redémarrez l'instance et quand vous redécrivez l'instance, quand vous lui redemandez de vous donner l'attribut sriov-net-support, là il va vous répondre simple, c'est bon. Donc là, le driver a été installé, le single route I/O virtualization a été installé, donc là d'emblée, c'est bon, vous êtes en performance réseau améliorée. Rapidement sur Windows, comment vérifier que vous avez ou pas le bon driver ? Vous allez dans la console de management, le device manager, vous regardez quel est le driver réseau qui est installé. Si vous voyez ce driver Citrix, ce n'est pas bon, vous êtes dans l'ancien modèle. Si vous voyez le driver Intel tel qu'il est indiqué là, Virtual Function, c'est bon, vous avez le bon driver. Où trouver ce driver ? Vous devez le télécharger sur le site d'Intel si vous ne l'avez pas. Vous trouverez l'URL exacte sur le lien que je vous ai indiqué, dans la doc Windows qui est indiqué ici. Vous le téléchargez, vous l'exécutez localement, vous l'installez, ça s'installe comme n'importe quel driver Windows, il n'y a pas de difficulté. Très bien, on est presque au bout. Dernier petit sujet que je voulais aborder aujourd'hui, les points de terminaison VPC pour S3. Bien sûr, vous pouvez accéder à S3 à partir de vos instances, je pense que vous êtes nombreux à le faire, à partir du moment où votre instance EC2 a un rôle qui lui permet d'accéder à S3, elle peut accéder au endpoint public d'S3. Mais ça, ça suppose que votre instance ait un accès à l'Internet public, ce qui n'est pas forcément le cas. Vous pouvez avoir un sous-réseau privé qui n'a pas d'accès à Internet et qui a néanmoins besoin d'accéder à S3. Donc ça, c'est le premier point. Le deuxième point, c'est qu'en créant ces points de terminaison, vous allez pouvoir utiliser S3 à l'intérieur de votre VPC directement, sans passer par l'Internet public. Donc comme je disais à l'instant, ça veut dire que du coup, même sans accès à Internet, vous pouvez utiliser S3, mais aussi, surtout, vous n'allez pas encombrer, même si vous avez un accès à Internet dans ce subnet, vous n'allez pas encombrer vos liens sortants, vos liens VPN ou votre lien Direct Connect qui peuvent être peut-être la route que vous suivez pour aller sur internet, vous n'allez pas les encombrer avec du trafic S3 qui peut être évidemment volumineux. Donc l'intérêt de ces endpoints c'est vraiment plusieurs choses, c'est d'une part effectivement pouvoir accéder à S3 même si le subnet et les instances n'ont pas accès à internet et puis dans certains cas ça va optimiser votre bande passante sortante, vous allez économiser votre Direct Connect si jamais c'était par là que les instances passaient pour aller sur internet et puis vous allez avoir de meilleures performances puisque vous aurez un accès local à S3 sans latence accrue et puis une sécurité accrue comme on va le voir. Donc si vous êtes des utilisateurs intenses d'S3 c'est une chose intéressante à regarder. Vous allez créer ce endpoint à l'intérieur de votre VPC. Imaginons qu'on a un bucket qui s'appelle MyPix qui va contenir des images et dont les instances se servent. Vous allez créer comme ceci un point S3 à l'intérieur de votre VPC. Vous allez référencer votre VPC, vous allez donner le nom de domaine inversé du endpoint auquel vous voulez accéder. Vous allez donner la table de routage du VPC dans laquelle il faut insérer cette entrée, ou du subnet, ça peut être une table de subnet, et puis vous allez pouvoir appliquer une stratégie IAM pour restreindre l'accès à ce S3. Ce qui a un intérêt encore supplémentaire par rapport à un accès au S3 public. Une fois que vous avez fait ça, il y a le subnet ou le VPC ont une table de routage qui contient une destination vers S3 via ce point de terminaison. Vous êtes capable de résoudre le nom de votre bucket en utilisant une URL traditionnelle et il va répondre avec les IP d'S3. Vu de votre application, vu de votre instance, très transparent, si ce n'est que ça va se passer sans doute avec des performances supérieures puisque tout reste finalement local. Voilà, donc vous allez voir dans votre table de routage, vous allez voir un préfixe et puis vous allez voir la cible qui va être le VPC. La stratégie, elle peut vous permettre de blinder la sécurité, c'est en disant par exemple que ce point de terminaison ne permet que d'accéder au bucket MyPix et pas aux autres. Donc ça vous permet de resserrer encore plus finalement l'accès à S3 plutôt que d'ouvrir un accès à tout S3 ou d'être obligé de gérer des rôles compliqués sur les instances. Là vous pouvez faire un peu plus de temps. Vous pouvez autoriser tout S3 à vos instances avec leur rôle et puis fermer au niveau du point de terminaison VPC, fermer l'accès en disant non, il n'y a que le bucket MyPix qui est présent. Quitte à créer plusieurs points de terminaison si c'est utile. Voilà l'exemple de stratégie qu'on pourrait appliquer. On n'autorise que get et put sur le bucket et le contenu du bucket. Policy toute simple. Et on pourrait évidemment sur le bucket avoir aussi une stratégie, comme d'habitude, sur S3, on pourrait avoir une stratégie de bucket où on autoriserait comme source sur le bucket MyPix et son contenu, on n'autoriserait que le point de terminaison de VPC que le endpoint qu'on a créé. Donc vous voyez, il y a plein d'avantages, on va dire, d'infrastructures à le faire, en termes de bande passante, etc., de latence, mais il y a aussi une bonne raison de sécurité de le faire. Si vous voulez vraiment blinder que, quelle que soit l'instance qui est dans le subnet, quel que soit le rôle IAM qui lui a été attaché, elle ne puisse accéder qu'à un bucket, vous pouvez serrer les boulons aussi sur le endpoint. Voilà, j'espère que vous êtes toujours vivant, moi ça va, j'ai encore du café. Je vous avais prévenu que c'était la session compliquée de la semaine, j'espère que vous avez encore de l'énergie pour les questions, moi ça va. Quelques ressources supplémentaires, alors le premier lien c'est la keynote de James Hamilton qui est un des architectes d'AWS en général. Pourquoi j'en parle ? Parce qu'il a abordé énormément de sujets réseau, et vraiment si vous n'avez pas vu cette keynote, je vous incite très fortement à la regarder, c'est sans doute une des meilleures vidéos AWS que vous puissiez voir, et qui révèle énormément de choses sur comment AWS fonctionne. Donc c'est tout récent, c'est très frais, c'est plein d'infos croustillantes. Et puis ensuite tout un tas de vidéos encore de re:Invent sur les VPC, sur IPv6 etc qui vous apprendront encore tout un tas de choses sur les VPC, sur l'architecture réseau dans AWS. Voilà, j'ai terminé, je vous remercie d'avoir écouté ces différents sujets. Hugo va vous afficher le sondage comme d'habitude. Alors n'oubliez pas, 5 c'est la meilleure note, 1 c'est la plus mauvaise, donc si vous êtes très content c'est 5, si vous n'êtes pas content c'est 1, ne vous trompez pas, c'est important pour nous aussi. Donc on va laisser ce sondage quelques minutes et on va vous afficher un deuxième sondage dans la foulée, Hugo le fera. Un deuxième sondage dans la foulée pour vous demander quel sujet vous auriez envie qu'on aborde en 2017. Vous ne pouvez en choisir qu'un. Choisissez vraiment celui qui est le plus intéressant pour vous. Si rien ne vous intéresse, ce n'est pas grave, prenez le deuxième qui vous intéresse. Ne vous inquiétez pas, on fait un premier test sur cinq sujets, on en mettra d'autres. C'est pour essayer de prier un petit peu ce qu'on fait en janvier, en février, etc. Ok. Très bien. Écoutez, donc je laisse Hugo gérer les sondages et on va passer aux questions. Ok. Alors, je vais essayer de les prendre, j'essaie de les grouper un petit peu. Question de Bruno, quel est le débit et la tarification de Direct Connect ? Je vais répondre brièvement, Bruno, je vous renvoie au deck que j'ai mentionné, vous trouverez toutes les infos et puis vous n'hésitez pas à me contacter si nécessaire. Très brièvement, il y a deux façons d'utiliser Direct Connect. Soit vous souscrivez le lien auprès d'AWS et vous avez le choix entre un lien 1 gigabit ou 10 gigabit, soit vous le souscrivez auprès de l'un de nos partenaires et vous pouvez avoir des débits à partir de 50 mégas, 50, 100, 200, je crois jusqu'à 500 de mémoire. Donc vous pouvez fractionner. J'insiste sur le fait qu'il y a des différences techniques dans les deux solutions. Vous avez plus de liberté lorsque vous avez un vrai lien 1 giga ou 10 gigas que lorsque vous avez un lien fractionné. Je n'ai pas le temps d'expliquer les détails, vous les trouverez dans la présentation. Quant au prix, c'est à l'heure. Ça varie entre les régions, ça varie entre les points de connexion. Donc je vous renvoie aux tarifs qui sont publics. Vous allez sur aws.amazon.com/direct-connect et vous trouverez les tarifs. Ce sont les tarifs du lien Direct Connect. Si jamais vous avez besoin d'un circuit d'accès entre vous et le point de présence Direct Connect, là c'est à voir avec votre opérateur et ça va être des coûts supplémentaires. Mais pour la partie Direct Connect, il y a un coût fixe qui est très faible et puis après un coût à l'heure. Mais c'est très compétitif. L'objectif n'est pas de, je pense, de gagner beaucoup d'argent avec Direct Connect, c'est de permettre aux gens de se connecter et de migrer et de bâtir leurs archives hybrides. Voilà. Est-ce qu'on peut bénéficier de Direct Connect avant l'ouverture de la région France ? Y a-t-il déjà un point de présence Direct Connect en France ? Oui, merci Jean pour la question. On a annoncé au mois de juin l'ouverture de notre premier point Direct Connect en France qui est à Paris et pour être très précis qui est hébergé chez Téléhouse 2 Boulevard Voltaire à Paris, qui est un bon endroit pour le faire, c'est le plus gros nœud internet français. Donc vous pouvez vous connecter à TH2 sur Direct Connect et pour l'instant vous accédez à la région de Francfort. OK ? Idem, plus de détails sur notre site, vous trouverez tout ça sans problème. Alors, question... Est-ce que la doc technique sur l'implémentation du virtual gateway est publique ? Non, on n'a pas pour habitude de divulguer nos implémentations. Par contre, vous trouverez, c'est du BGP4 comme d'habitude, il n'y a pas de surprise, on aurait bien tort de vous imposer des protocoles propriétaires ou des bizarreries, donc à chaque fois je m'en suis servi, j'ai fait du BGP4 comme à la maison et je n'ai pas eu de surprise. Je ne sais pas quel point précis vous souhaitez connaître, je vous renvoie la documentation, s'il y a des choses qui ne sont pas claires, posez vos questions, n'hésitez pas, mais c'est un gateway BGP4 et il n'y a pas de grosse surprise. La différence étant que vous ne pouvez pas avoir une console sur ce gateway comme vous avez une console sur votre équipement. Il faut rester dans les clous de l'API et des fonctionnalités qu'on vous propose. Alors une question, une autre question encore. Si j'utilise Direct Connect, est-ce que j'ai besoin d'activer Enhanced Networking pour améliorer la latence ? Oui, oui, oui. Direct Connect, c'est une connexion, c'est une connexion WAN, c'est une connexion entre sites. Donc l'Enhanced Networking, c'est un mécanisme vraiment sur les instances. Donc il va accélérer le nombre, augmenter le nombre de paquets par seconde et réduire la latence entre vos instances. Donc imaginez que vous ayez un cluster Hadoop ou un cluster de bases données, quelque chose qui crache énormément de trafic et qui a besoin de performance prévisible. Vous voulez absolument avoir l'Internetworking. Le Enhanced Networking a un avantage à l'intérieur du VPC entre instances et entre vos instances et les services de la région. Direct Connect, effectivement, vous avez raison, vous allez avoir une latence plus prévisible et de meilleure performance, mais entre sites. Donc, c'est des mécanismes qui sont vraiment complémentaires. Alors, ensuite... Quand on connecte plusieurs VPC à un même Direct Connect, ces VPC sont-ils de fait routés entre eux ? Non, les VPC, non, non, il faut les... Vous devez, si vous voulez qu'il y ait de la communication inter-VPC, il faut explicitement définir des peering et définir les routages comme je vous l'ai montré. Par défaut c'est complètement cloisonné. N'oubliez pas que le P de VPC c'est private. Alors Régis nous dit on peut très bien avoir un débit garanti et une disponibilité très bonne sur l'internet public. Si vous le dites, oui, sur Non mais c'est vrai, on peut avoir ça. J'ai eu des très bons transitaires IP. Maintenant le problème étant que si je fais de la réplication de bases de données Oracle, j'ai besoin d'avoir un niveau de performance le plus élevé possible et le plus prévisible possible et sans doute pour des raisons même de sécurité. Indépendamment du fait que je vais le monter sur un VPN j'ai envie et certains clients ont besoin de démontrer en termes de compliance que ce trafic ne passe pas par l'internet public il peut y avoir une dimension technique et il peut y avoir une dimension même de compliance sur ces sujets là qui est importante pour certaines personnes. Qu'est-ce qu'on a encore ? Alors, vaut-il mieux, ça c'est une bonne question, vaut-il mieux cloisonner les machines de dev prod par des VPC ou par des subnets ? Effectivement, on pourrait faire les deux. C'est-à-dire qu'à partir du moment où on peut définir des tables de routage par subnet, comme je vous l'ai montré, on pourrait imaginer qu'effectivement on est un subnet de dev, un subnet de prod, des tables de routage différentes et des ACL différentes, etc. Bon, si vous êtes sur une infra relativement simple, ça peut suffire, pourquoi pas. Moi je persiste à penser que la frontière du VPC est quand même plus forte et je ne suis pas le seul à la penser. Et je vous conseille sur des environnements comme ça très différents de séparer les VPC. Une autre raison de le faire, c'est aussi une raison très simple d'automatisation qui est que c'est plus facile de créer et détruire des VPC que de détruire et de créer des subnets. Vous voyez ce que je veux dire ? Le VPC c'est vraiment une entité en tant que tel, vous avez vos templates CloudFormation, vous créez vos VPC, vous les détruisez, vous les recréez, vous les détruisez, vous ne vous posez pas de questions. Si vous créez et détruisez des subnets, j'ai envie de dire le risque d'erreur, si vous faites des manips comme ça à l'intérieur d'un VPC, il y a quand même toujours le risque de faire une bêtise. Mon conseil serait plutôt de segmenter avec des VPC. On est à court de temps ? On est à court de temps. Il restait encore quelques questions, on va les garder, on va les lire tranquillement et puis soit j'essaierai d'y répondre dans les autres webinaires, soit renvoyez-les-moi par mail, laissez-moi un petit peu de temps pour y répondre. Mais je vous répondrai. Je suis sûr qu'il y a des gens qui m'écoutent et qui ont reçu des réponses par mail. Vous pouvez le dire dans le chat, oui c'est vrai. Je vous demande un peu de patience parce que j'en reçois évidemment un certain nombre. Je crois qu'on a fini pour le MPC. J'espère que vous êtes toujours vivant. Mais manifestement oui, puisqu'il y a des questions. Je vous remercie beaucoup d'avoir participé, j'espère que vous avez appris plein de choses. Et on va faire une petite pause de 5 minutes, c'est ça Hugo ? 5 minutes ? Et puis on enchaîne sur la session des DOS, alors je ne ferai pas de démonstration, je suis désolé, je pense que ça risquerait d'être mon dernier webinaire si c'était le cas. Mais voilà, on va parler des bonnes pratiques et on va parler de AWS Shield qui a été annoncé à re:Invent et de plein d'autres choses. Donc faites une petite pause, prenez un café et on se retrouve dans 5 minutes. Merci beaucoup, à tout de suite.