Les mardis du cloud special fondamentaux

Transcript

Bonjour à toutes et à tous, très heureux de vous retrouver pour un nouveau webinar AWS sur YouTube, notre nouvelle plateforme de diffusion pour l'année, suite aux tests plutôt concluants qu'on a faits l'année dernière. Ce webinaire sera un peu particulier aujourd'hui car je suis en direct, mais je ne suis pas dans nos bureaux, je suis aux États-Unis. C'est pourquoi vous n'avez pas de vidéo de ma part, mais ce n'est pas forcément le plus grave. Il est 6h32 du matin dans ma zone. J'espère que le café a fait effet, et si ce n'est pas le cas, vous voudrez bien m'en excuser. Aujourd'hui, on va faire deux sessions comme d'habitude. On va commencer par une introduction à AWS, très orientée débutant, où on va essayer de se poser les bonnes questions. On y reviendra dans deux minutes. Le deuxième webinaire sera consacré à un récapitulatif des annonces faites à ReInvent à Las Vegas il y a presque deux mois. Donc, un panorama des nouvelles annonces. Comme d'habitude, je répondrai à vos questions. Je vous précise que pour poser des questions, il est impératif de vous connecter à votre compte Google sur YouTube. Je suis toujours accompagné d'Hugo qui est en France. Salut Hugo, merci pour l'organisation. Comme d'habitude, c'est Hugo qui triera vos questions et me les fera parvenir. Donc, quelques petits changements, mais comme d'habitude, on devrait y arriver. J'espère que la connexion wifi de l'hôtel ne me jouera pas des tours, même s'il n'y a pas beaucoup de campagne là où je suis. Très bien, écoutez, on va donc commencer. Dans ce premier webinar, la première bonne nouvelle, c'est que je n'ai aucun slide. On va vraiment faire de la démo, on va regarder différents services, je vais vous montrer différentes parties du site AWS Webinar qui sont sans doute les plus importantes pour bien commencer. On me demande souvent comment commencer avec AWS, comment ça se passe, où est la doc, etc. Sans surprise, tout est en ligne. Donc, si vous cherchez quelque chose, tout est sur le site d'AWS. Donc aws.amazon.com, une grande partie du site est francisée. Vous trouverez là-dessus nos actualités, nos produits, etc. C'est vraiment là qu'il faut vous diriger. C'est là que vous allez trouver les premières docs, les premiers tutos qui vont vous permettre de commencer. Avant de plonger directement dans le sujet, je voudrais rappeler quelques notions importantes sur AWS. Notions qu'on retrouvera tout au long de l'utilisation des services et de la construction de projets. AWS a plus de 10 ans maintenant. La plateforme a été créée en 2006 avec quelques premiers services pour les développeurs, et au fil des années, on a ajouté des services en fonction des demandes de nos clients. Vous savez sans doute que plus de 90% de la roadmap d'AWS est pilotée par les demandes des clients, et donc la plateforme AWS telle qu'elle existe aujourd'hui est vraiment le reflet des demandes de nos clients au fil des années. Aujourd'hui, nous avons des millions de clients dans toutes sortes d'industries, dans tous les pays, de toute taille, de tout type. Cela nous permet sans doute de couvrir un très grand nombre de cas d'utilisation. On va regarder un peu les services tout à l'heure, mais évidemment, le cloud computing, c'est avant tout de l'infrastructure. L'infrastructure d'AWS aujourd'hui est déployée dans 18 régions, comme vous le voyez ici, les cercles jaunes sur la carte. Donc 18 régions et 52 zones de disponibilité. Une région, c'est un ensemble situé autour d'une grande ville. Pour l'Europe, on a Dublin, Francfort, Londres. Et depuis décembre, on est très heureux d'avoir également une région à Paris. Pour ce qui est de l'Europe, on ouvrira en 2018, donc cette année, une région supplémentaire à Stockholm, qui est le cercle vert que vous voyez là. Aux États-Unis, on dispose également de plusieurs régions, sur la côte Est, sur la côte Ouest, également au Canada, au Brésil, en Inde, à Singapour, en Chine, en Corée, au Japon, en Australie, avec de nouvelles régions qui vont arriver également à Bahreïn et une nouvelle région chinoise. Ces régions sont des ensembles de data centers qui vont héberger l'infrastructure d'AWS, donc les serveurs, le stockage, le réseau, etc., et qui vont héberger également les services, donc les briques logicielles que vous allez utiliser pour construire vos applications. Ce qui différencie les régions entre elles, c'est souvent la taille. Les régions les plus anciennes ont tendance à être un peu plus grosses que d'autres. Pour l'Europe, la première région était la région irlandaise. On a des régions de référence qui sont souvent plus grosses, avec plus de serveurs, bien que l'on fasse en sorte d'avoir de la capacité partout. Dans ces régions de référence, surtout, on va avoir tendance à déployer les services plus tôt et plus vite. Par exemple, pour l'Europe, lorsqu'un nouveau service AWS est lancé globalement, la plupart du temps, il sera d'abord disponible en Irlande avant d'être disponible dans les autres régions. Mais au fil du temps, l'objectif est de disposer de tous les services dans toutes les régions en fonction des demandes de nos clients et de leurs priorités. Quand vous choisissez de construire de l'infrastructure sur AWS, la première chose que vous faites, c'est de choisir une région. Vous avez la certitude, si vous choisissez la région France par exemple, que l'infrastructure que vous construisez et les données que vous mettez dans AWS resteront dans cette région. C'est un point essentiel. Les données ne sont jamais déplacées en dehors d'une région sans votre initiative. Vous pouvez les déplacer si vous voulez répliquer des données depuis Paris vers Singapour, et on vous donne des mécanismes pour le faire de manière simple et sécurisée. Mais c'est à votre initiative. La région est l'unité d'infrastructure sur laquelle vous allez travailler. Le chiffre que vous voyez à l'intérieur du cercle est le nombre de zones de disponibilité. Une zone de disponibilité est une partition de notre infrastructure, et les zones de disponibilité sont indépendantes entre elles. Une région est un ensemble de zones de disponibilité, qui sont elles-mêmes des ensembles de data centers. L'idée est que si un data center dans une zone de disponibilité a un problème, ce problème n'affecte pas les autres zones de disponibilité, et les clients qui ont choisi cette région peuvent continuer à fonctionner avec le minimum d'impact possible. C'est un des concepts clés d'AWS, cette infrastructure à trois niveaux : le data center, la zone de disponibilité, et la région. Un data center peut avoir un incident majeur sans que cela affecte forcément la zone de disponibilité, et une zone de disponibilité peut avoir un incident majeur sans que cela affecte les autres zones de disponibilité de la même région, et par conséquent, le fonctionnement global de la région. On a encore un niveau supplémentaire qui est le multi-région, où des clients dont l'infrastructure est particulièrement critique choisissent d'héberger de l'infrastructure dans différentes régions. Cela peut être pour des raisons de proximité de leurs utilisateurs, mais aussi pour des raisons de haute disponibilité, pour dire que si une catastrophe majeure survenait sur une région AWS, on aurait la possibilité de basculer ou de continuer à fonctionner sur une autre région. Ces concepts sont vraiment essentiels. Je tenais à prendre cinq minutes pour les expliquer parce que dans le monde du cloud computing, tout le monde n'a pas la même définition de la région. Certains vous diront qu'ils ont une région quand ils ont un data center, mais pour nous, une région est au minimum, pour les nouvelles régions, trois zones de disponibilité, ce qui signifie au minimum trois data centers, et probablement beaucoup plus. C'est un niveau de redondance très élevé. Sur cette page, vous trouverez beaucoup d'informations supplémentaires, n'hésitez pas à les consulter. Comment bien démarrer ? On a une première page intéressante, qui s'appelle "Getting Started", et qui vous indique un ensemble de tutoriels, de projets que vous pouvez commencer à mener en fonction de ce que vous voulez faire sur AWS. Par exemple, vous pouvez apprendre à déployer des sites web, découvrir le DevOps sur AWS, découvrir le Big Data sur AWS, etc. Vous avez une série de documents, de livres blancs qui sont vraiment importants. Si vous êtes développeur, vous trouverez les liens sur tous les SDK AWS qui vous permettront d'appeler nos API et de construire et piloter votre infrastructure de manière programmatique. On a 11 langages et la ligne de commande pour les scripts. N'hésitez pas à regarder ces didacticiels, c'est un bon point de départ. Un autre point important est l'offre gratuite. L'offre gratuite permet à une personne ou une entreprise qui crée son compte sur AWS d'utiliser un grand nombre de services totalement gratuitement, dans certaines limites d'utilisation. Pour la formation, le prototypage, le test, etc., c'est vraiment très intéressant pour les étudiants, les développeurs qui veulent se former. Pendant les 12 mois qui suivent la création du compte, chaque mois, vous avez le droit d'utiliser cette liste de services dans les limites indiquées. Par exemple, prenons EC2, le service de machine virtuelle qu'on verra dans quelques minutes. Chaque mois, vous pouvez utiliser 750 heures d'instance, ce qui est presque un mois entier. Sur des instances de petite taille, vous ne ferez pas de production, mais pour tester, vous former, découvrir, c'est vraiment intéressant. Vous avez une liste de services relativement étendue. Par exemple, notre service de chatbot, Amazon Lex, le service d'intelligence artificielle pour la synthèse vocale, Amazon Polly, RDS pour les bases de données relationnelles MySQL, PostgreSQL, etc., Redshift pour le data warehouse. Il y a bien plus d'une centaine de services sur AWS aujourd'hui, mais vous voyez qu'il y en a quand même un grand nombre. La plupart des nouveaux services qui sortent font partie de ce niveau d'usage gratuit, appelé également le free tier. Avec ça, vous allez pouvoir tester, expérimenter, vous former vraiment à coup zéro, à condition de bien rester dans les limites indiquées. Créer un compte prend à peu près cinq minutes. Vous cliquez sur un de ces boutons jaunes, vous créez votre compte, vous aurez besoin de votre nom, adresse, etc., et d'une carte bleue, car même si vous utilisez le niveau d'usage gratuit, tous les services d'AWS sont en paiement à l'usage, et notre mécanisme de facturation par défaut est la carte bleue. Mais rassurez-vous, si vous restez dans le niveau d'usage gratuit, votre facture sera zéro, et je vais vous montrer tout à l'heure comment consulter votre facture. Pour les entreprises qui s'inquiètent et disent que ce n'est pas très pratique d'avoir une carte bleue, vous pouvez créer votre compte avec une carte bleue et ensuite nous contacter pour demander à mettre en place un prélèvement, etc. Bien sûr, Netflix ou d'autres ne payent pas leur facture AWS par carte de crédit. Une fois que vous avez créé votre compte et que vous vous connectez, vous arrivez sur cette page qu'on appelle la console AWS. C'est une application web qui vous permet d'utiliser tous les services d'AWS. Pour bien débuter, la console est un outil intéressant. Au fur et à mesure de votre apprentissage, vous verrez qu'il y a d'autres façons d'utiliser AWS. Je l'ai mentionné rapidement, mais vous pouvez utiliser l'intégralité des services via des API, appelables via les kits de développement, via la ligne de commande d'AWS. Ces actions sont strictement équivalentes, c'est-à-dire qu'on peut voir AWS comme un ensemble d'API qui permettent de piloter des services d'infrastructure. Au-dessus de ces API, on a la console web pour des actions manuelles, de l'apprentissage, etc., et la ligne de commande pour les gens qui veulent faire du shell, écrire des scripts, etc., et appeler ces API. On a aussi les SDK, Python, Java, C++, etc., pour les développeurs. Mais vous appelez la même chose. La console n'est qu'une application web qui appelle un jeu d'API. Parfois, dans la console, on ne peut pas faire 100% de ce que permettent les API, donc il est possible que vous ne trouviez pas certaines opérations un peu fines, et dans ce cas, il faudra les faire soit en ligne de commande, soit programmatiquement. Pour les débutants, la console est un bon outil. Elle est souvent un peu intimidante à cause de la longue liste des services AWS qui ne fait que s'allonger. Ils sont groupés par catégories, ce qui vous permet de vous y retrouver. Vous avez les services que vous avez récemment utilisés, et surtout, vous avez le moteur de recherche. Si vous voulez EC2, vous trouvez directement EC2 ici. Il n'est pas nécessaire de connaître l'intégralité de ces services. Je pense qu'il n'y a pas un client AWS qui utilise l'intégralité des services. Il y a des services cœur, qui sont d'ailleurs plutôt ceux-là. Si je peux vous donner un conseil, c'est plutôt de commencer votre apprentissage par cela : comment déployer du code sur AWS, comment stocker des données, comment déployer des bases de données relationnelles ou non relationnelles. Les problématiques de migration sont importantes pour les grandes entreprises. Ensuite, des services liés au réseau et à la distribution de contenu, le CDN, les outils pour développeurs, tout ce qui permet de construire des chaînes d'intégration et de déploiement continu, et peut-être CloudWatch pour le monitoring. Ces services sont sans doute importants à regarder au début. Si vous voulez vous plonger dans la réalité virtuelle ou dans le test d'application mobile, vous trouverez également ces services. Ne vous noyez pas, ne vous perdez pas dans cette jungle. Les services importants sont plutôt sur la colonne de gauche, et en tout cas, dans les premiers jours, les premières semaines, c'est vraiment là qu'il faut se concentrer. On va commencer par un premier service super simple qui est dans la colonne de gauche, qui s'appelle LightSail. LightSail est un service lancé il y a environ un an et qui est certainement la manière la plus simple de démarrer un serveur sur AWS. Je suis dans la console LightSail, j'ai déjà un serveur Windows qui tourne, on le regardera tout à l'heure. On va donc créer une instance. On va commencer par choisir la région, qui est le paramètre clé. Ici, on voit qu'il n'y a pas 18 régions, simplement parce que LightSail n'est pas disponible dans les 18 régions. On va choisir l'Irlande. Par défaut, on va lancer cette instance dans la zone de disponibilité A. Il y a trois zones de disponibilité en Irlande, nommées EUS, qui est le nom de la région Irlande, et puis iOS1A, iOS1B, iOS1C, pour indiquer la zone de disponibilité. On va rester sur cette zone-là, on n'a pas de raison de le changer. On peut choisir un serveur Linux ou un serveur Windows. On va choisir un serveur Linux. On a la possibilité de lancer un serveur préinstallé avec telle ou telle application, comme WordPress, Magento, Joomla, etc. On va lancer un serveur Linux tout simple. On pourrait choisir Ubuntu si ça nous chantait, mais prenons Amazon Linux. On va avoir envie de se connecter à cette instance, donc on a besoin d'une paire de clés pour pouvoir exécuter SSH, ouvrir un shell à distance. Créons une paire de clés SSH, on va l'appeler LinuxDemo. On va la télécharger, comme ça, on pourra s'en servir plus tard. On va choisir ensuite le plan, donc la machine plus ou moins puissante et le forfait de données que vous pourrez transférer depuis cette machine, de 5 à 80 dollars. Prenons par exemple celui-là. On va lui donner un petit nom, on va l'appeler Linux Demo LightSail. On va en créer une seule, et c'est parti. Vous voyez, c'est difficile de faire plus simple. Pendant que cette machine démarre, on va regarder celle que j'ai lancée. J'ai lancé une machine Windows tout à l'heure. Cette machine fonctionne, je peux l'arrêter, la redémarrer, etc. Je peux m'y connecter automatiquement en RDP. Cette machine a une adresse IP publique, je pourrais utiliser un client RDP traditionnel pour m'y connecter. Ici, on a un raccourci qui nous permet de nous connecter et d'avoir accès à la machine. C'est donc à ça que Windows ressemble. On peut faire du Windows, ouvrir un terminal, et faire ce que font les gens sur Windows. Tout ça en quelques clics et en quelques minutes, j'ai une machine, je peux ouvrir un navigateur, travailler dessus, installer ce que j'ai envie d'installer. C'est vraiment le chemin le plus court vers une instance AWS, c'est d'utiliser LightSail. J'ai mon serveur Linux, on voit qu'on a l'adresse IP, donc on pourrait utiliser ça pour faire du RDP, déployer un serveur web, etc. On va regarder si cette machine est là. Oui, elle est là. J'ai un shell sur cette machine, et si on update les packages, c'est une bonne pratique de sécurité. Un nouveau noyau, allons-y. Voilà, c'est un serveur Linux tout ce qu'il y a de plus traditionnel, il tourne avec Amazon Linux, mais vous pouvez déployer Ubuntu, Debian, et tout ce que vous voulez. Une fois qu'on a fini, on peut tout simplement arrêter ces machines. Supprimer, c'est vraiment supprimer, donc là, c'est vraiment détruire ce serveur. On pourrait l'arrêter, ce qui serait l'équivalent d'éteindre un serveur physique et de le rallumer. On pourrait l'arrêter et le relancer ensuite. Là, le supprimer, c'est vraiment le supprimer. C'est vraiment difficile de faire plus simple. C'est sympa, ça répond bien aux besoins de petites entreprises ou de gens qui ont des compétences techniques peut-être un peu réduites et qui ont juste envie d'avoir un serveur et d'installer des applications dessus. Dans la majorité des cas, LightSail est peut-être un peu trop simple, et pour des entreprises déjà de taille supérieure qui ont des équipes IT, on va avoir envie de des vrais serveurs. Quand je dis des vrais serveurs, c'est des serveurs sur lesquels on va vraiment avoir la main et on va pouvoir configurer l'intégralité des paramètres. On va aller dans la console EC2, qui signifie Elastic Cloud Compute, la technologie de machine virtuelle d'AWS. Ici, j'ai déjà quelques instances qui tournent, et on va en rajouter. On va donc lancer une instance, donc en avant, cliquons sur le bouton bleu. On va pouvoir choisir différentes choses ici. Le premier paramètre important, c'est l'AMI, l'Amazon Machine Image, qui est le fichier de départ qui va servir à construire votre machine virtuelle. Vous pouvez choisir parmi tout un tas de systèmes d'exploitation, on voit Amazon Linux, SUSE Linux, Red Hat, Ubuntu, des AMI Microsoft Windows Server en diverses versions, etc. Ces AMI sont des images sur étagères que vous pouvez utiliser directement, et elles sont maintenues par Amazon régulièrement, mises à jour avec les patches de sécurité, etc. Ce sont des bonnes images de départ pour construire votre infra. Vous pouvez créer vos propres AMI, mais cela dépasse le cadre de cette présentation. Vous pourrez le faire plus tard, à partir d'une machine que vous avez installée, en un appel d'API, vous êtes capable de générer votre propre image avec votre configuration, vos logiciels installés, etc. Surtout, je vous incite à parcourir cette page, vous pouvez piocher dans ce qu'on appelle l'AWS Marketplace. L'AWS Marketplace, c'est plus de 4000 logiciels dans diverses catégories, préinstallés, préconstruits et prêts à être déployés directement. Par exemple, allons voir dans Business Software, si vous cherchez un outil, disons un outil de CRM, vous allez trouver 88 AMI fournies par des hébergeurs contenant Magento, WordPress, etc. Ces AMI sont construites par des partenaires d'AWS, certifiées par AWS, et mises à disposition des clients d'AWS sur la Marketplace. L'avantage de la Marketplace, c'est que vous pouvez trouver et installer des solutions dont vous avez besoin. Par exemple, si vous avez besoin de Magento, vous pourriez installer un serveur à partir de zéro, une machine virtuelle, installer Magento, le configurer, etc. Vous pouvez tout à fait faire ça, vous aurez la main complète sur le serveur, mais c'est peut-être plus simple et plus utile d'aller directement installer cet AMI et d'économiser le temps d'installation. Autre cas d'utilisation, si vous migrez de vos datacenters vers AWS, il est probable que vous ayez envie de retrouver dans AWS certains, voire tous, les progiciels dont vous disposiez dans votre propre datacenter. Il est très probable que les éditeurs avec lesquels vous travaillez dans votre datacenter aient également mis à disposition de nos clients les mêmes services sur AWS Marketplace. On voit des solutions de sécurité, des firewalls, du Fortinet, du Cisco, du Sophos, Trend Micro, F5, ils y sont presque tous. C'est souvent un sujet important pour les gens qui migrent, c'est de dire, oui, nous avons des règles de conformité à respecter, nous avons besoin d'avoir des firewalls, nous utilisons ça dans notre datacenter, est-ce qu'on peut aussi l'utiliser sur AWS ? Si vous trouvez ces solutions dans la Marketplace, oui, ça se fait de manière assez simple. Un dernier point, combien est-ce que ça coûte ? EC2, donc les machines virtuelles EC2, sont facturées à la seconde, en fonction de la taille d'instance que vous choisissez. Plus les instances sont puissantes, plus elles coûtent cher, mais vous payez à la seconde. Quand vous démarrez une AMI sur la Marketplace, certaines sont gratuites, c'est-à-dire que vous ne payez que l'utilisation de l'instance sous-jacente, et d'autres sont évidemment payantes. L'avantage est qu'elles sont payables le plus souvent à l'heure. Par exemple, cette solution de Fortigate que je ne connais pas, mais je vois que je peux payer 30 centimes de l'heure. Je vais payer le coût de l'instance qui fait tourner cette solution plus 30 centimes de l'heure. L'avantage, c'est que si vous voulez tester cette solution ou une autre, vous pouvez la tester pendant un jour, deux jours, trois jours, quatre jours à coûts extrêmement faibles. Si on parle de 30 cents de l'heure, ça fait 7 dollars par jour. Vous pouvez tester pendant trois ou quatre jours pour quelques dizaines de dollars. Si ça vous plaît, très bien, si ça vous plaît pas, tant pis, mais vous n'avez pas acheté une licence coûteuse, vous n'avez pas perdu des semaines à négocier ces licences, à passer à travers les achats, le juridique, etc. La Marketplace est donc une solution qui va vous permettre de tester pas mal de choses à faible coût et rapidement. Si vraiment ça vous plaît, vous pouvez souscrire à l'année sur cette solution avec un discount. La Marketplace est vraiment utilisée par plus de 100 000 clients actifs chaque mois, donc c'est très massivement utilisé. Je vous incite à aller voir un peu ce que vous pouvez y trouver. Revenons à nos instances. On va choisir la première de la liste, Amazon Linux, notre distribution, la version de septembre 2017. On va prendre la première, on va simplifier les choses. Le premier truc qu'on va choisir, c'est le type d'instance, c'est-à-dire la taille, la quantité d'infrastructure qui va être allouée à cette machine. On a parlé de l'offre gratuite, et vous voyez que si vous voulez rester dans le cadre de l'offre gratuite, vous devez utiliser cette instance T2Micro. Une instance T2 Micro, ce n'est pas très gros, c'est un coeur, un VCPU, un giga de mémoire, mais pour se former, pour tester, pour prototyper, c'est suffisant. Je connais même des clients qui utilisent du T2 Micro en production pour des petites charges de travail, ça peut suffire. Si on choisit T2Micro, on reste dans l'offre gratuite. On a une famille d'instances, des familles d'instances, par type de cas d'usage. Par exemple, si j'ai des charges de travail qui ont besoin de calcul, du machine learning, je vais m'orienter vers des C5 qui ont les dernières générations Intel les plus puissantes et qui sont vraiment optimisées pour le travail. Puis j'ai différentes tailles, comme les tailles de t-shirt : XL, 2XL, 4XL. On a des instances GPU, etc. Je sais, il y en a beaucoup, ça paraît un peu intimidant, mais une fois qu'on a compris le principe, on choisit un cas d'usage. Les instances T2 sont très économiques et bien adaptées pour des petites charges de travail générales. Ça marche très bien, pas la peine d'aller chercher plus gros. En fonction des contraintes mémoires de votre application, vous choisissez 2 Go, 4 Go, 8 Go, et c'est parti. On va regarder celle-là, on veut rester gratuit. On va continuer, je vais vous montrer les détails. Combien d'instances voulons-nous ? Une. Est-ce qu'on veut une configuration réseau particulière ? Non, on va garder cette configuration réseau. Je ne vais pas rentrer dans les détails du réseau AWS aujourd'hui. On a fait d'autres webinars sur ce sujet que vous trouverez sur notre chaîne YouTube, Amazon Web Services France. Vous pouvez créer plusieurs VPC, par exemple, un VPC pour l'équipe finance, un VPC pour l'équipe RH, un VPC pour l'équipe de développement, etc. Vous pouvez avoir plusieurs VPC, mais dans tous les cas, le VPC vous appartient et vous contrôlez entièrement ce qui se passe à l'intérieur, et personne d'autre que vous ne voit ce qui s'y passe. Quand vous créez votre compte AWS, vous avez un VPC par défaut qui est créé dans chaque région. Ici, je suis toujours dans la région Irlande, et on voit toutes les régions AWS, environ 18. Vous avez un VPC par défaut qui est créé, mais j'en ai créé d'autres ici. On va rester dans le VPC par défaut, on va pas toucher au reste, on va rester sur les paramètres. Si vous cochez cette case, ça protège vos instances contre une terminaison accidentelle, c'est-à-dire qu'il faudra explicitement décocher cette case pour pouvoir tuer l'instance. On va la laisser activée. On va s'occuper du stockage. Par défaut, on crée un volume de 8 gigaoctets, on pourrait mettre plus, on pourrait choisir différents types de stockage, on pourrait rajouter d'autres volumes. On va faire très simple, on va rester comme ça. C'est une bonne pratique d'ajouter des balises ou des tags. Ça permet, lorsqu'on a créé des tonnes de ressources, de s'y retrouver facilement. Via l'API, par exemple, vous pouvez dire : donne-moi toutes les instances EC2 dont le nom commence par Linux instance. Si vous avez des dizaines, des centaines d'instances qui tournent, vous pouvez les retrouver comme ça. Une autre bonne pratique est de taguer les ressources par projet. Ici, on va dire que mon projet s'appelle Webinar. On pourrait mettre une clé environnement pour dire, par exemple, c'est l'environnement de démo. On pourrait mettre une balise Cost Center pour trouver facilement qui doit payer pour tout ça. C'est vraiment une bonne pratique, mettez les bons tags, quand vous aurez plein de ressources différentes, ça vous aidera à les retrouver. Les règles de sécurité réseau, donc ici on voit ce qu'on appelle un groupe de sécurité ou security group, et on va configurer les ports réseau qui seront ouverts sur l'instance. On pourrait dire : on ouvre le port 22 parce qu'on veut faire SSH. Plus tard, on pourrait installer un serveur web sur ce serveur, donc on ouvre le port 80. On pourrait restreindre les adresses IP source qui sont autorisées à accéder à ce port. Pour le SSH, on pourrait dire par exemple : mon IP. Pour HTTP, on pourrait dire n'importe où, c'est un serveur public. On vérifie. Là, on va retrouver un récapitulatif de tout ce qu'on a défini, et puis on va lancer l'instance. Ici, j'ai déjà une paire de clés SSH. Je vais choisir une paire de clés existantes, mais je pourrais aussi la créer. Mon instance a démarré. Les T2 généralement démarrent vite. Donc là, on voit dans la console cette instance qui est en train de démarrer. Elle a déjà une IP publique, un nom DNS, elle tourne dans la région Irlande, zone de disponibilité A. On voit le nom de la clé SSH que j'ai utilisée, etc. On va lui laisser une ou deux minutes pour s'initialiser, et puis on va essayer de s'y connecter. En espérant qu'elle soit déjà prête, parce que j'ai tendance à être assez impatient sur ce genre de choses. L'utilisateur par défaut s'appelle ec2-user. Elle est prête, parfait. Sur ce terminal, je suis en local sur mon Mac. J'ai utilisé ma clé SSH, c'est pour ça que je ne l'ai pas spécifiée. Je suis connecté sur mon serveur. Je vois mon serveur Linux qui tourne, et j'ai la main dessus, je peux installer tout ce que j'ai envie d'installer. Je suis le seul, en tout cas, ma machine a le droit de faire ça puisque j'ai restreint le security group à mon adresse IP. Si j'installais un serveur web, je pourrais accéder à ce serveur web depuis partout. Essayons de la tuer. Si je lui dis résilier, il me dit non, ce n'est pas possible parce qu'elle est protégée. Vous ne pouvez pas la tuer ni dans la console, ni via un appel d'API. C'est cette fameuse protection, ça peut être utile pour des serveurs importants dans votre infrastructure. Pour pouvoir la tuer, il va falloir explicitement désactiver la protection, et maintenant je peux la tuer. Je pourrais l'arrêter, la redémarrer, start stop, mais je peux aussi la tuer. Là, je paye à la seconde. En l'occurrence, je ne paye rien puisque j'utilise une T2 Micro et que je suis dans le free tier. Si j'avais lancé une instance plus significative, j'aurais payé quelques minutes d'utilisation et c'est tout. C'est vraiment un mode de fonctionnement différent par rapport à de l'infrastructure traditionnelle. Le mécanisme de base que je voulais vous montrer, comment lancer des serveurs, etc. Dans le dernier quart d'heure, je voudrais vous montrer des services complémentaires, en particulier des services de sécurité qui sont vraiment indispensables à connaître, et il est important de prendre très tôt les bonnes habitudes de sécurité. Juste avant ça, vous pouvez aller dans votre compte. Vous voyez ici un tableau de bord facturation qui va vous permettre d'explorer vos coûts. Vous voyez les dépenses du mois en cours, par service, vous pouvez explorer les coûts. Si vous restez dans le cadre du free tier, vous verrez votre facture à zéro tout le temps. Vous pouvez définir des rapports, des alertes, recevoir une alerte si votre consommation dépasse un certain montant, etc. Si vous restez dans le cadre du free tier, une fois de plus, vous verrez votre facture à zéro tout le temps. N'hésitez pas à aller voir le tableau de bord. Ok, facturation. Et puis, tant qu'on y est, vous avez l'onglet support qui vous permet d'ouvrir des tickets, de demander un peu d'aide, d'avoir accès aux forums AWS qui sont une excellente ressource pour obtenir de l'aide, la documentation, etc. Ok ? Alors, parlons un peu de sécurité, pendant les quelques minutes qui restent. AWS, c'est finalement un jeu d'API. Ce qui compte, c'est de savoir qui a le droit d'appeler quelle API et pour faire quoi. Une API, ça va être par exemple démarrer une instance, arrêter une instance, tuer une instance. Chaque action unitaire est une API. L'utilisation de ces API est protégée par un service qu'on appelle IAM, Identity and Access Management, qui va vous permettre très finement de définir les permissions API par API. Vous pourriez dire, tel utilisateur a le droit de lancer des instances, il a le droit de les arrêter et de les redémarrer, mais il n'a pas le droit de les tuer. Vous pourriez dire, cet utilisateur n'a pas le droit de lancer des instances, il a le droit de les utiliser, mais il ne peut pas les arrêter. Chaque API va être protégée ainsi. Ça se passe dans IAM. IAM, on peut en parler pendant des heures. Il y a un webinar existant sur IAM que vous trouverez sur notre chaîne YouTube qui vous explique comment ça marche en détail, comment bien s'en servir, les bonnes pratiques, etc. C'est souvent un point qui peut vous bloquer dans vos premières étapes sur AWS si vous ne prenez pas le temps de comprendre comment il fonctionne. Je vous incite vraiment très fortement, une fois que vous avez joué un peu avec des serveurs, d'aller lire la documentation IAM, de regarder le webinar et de mettre en place les bonnes permissions. L'idée est de donner le minimum de permissions à chaque utilisateur. Le principe de moindre privilège est un bon principe de sécurité. Vous avez uniquement le droit de faire ce que vous devez faire, mais pas plus. Pour autoriser ou restreindre les droits des utilisateurs, on va travailler avec IAM et manipuler des entités comme des stratégies, des policies, des ensembles de permissions qu'on va attacher à tel ou tel utilisateur, des groupes d'utilisateurs, des rôles, etc. IAM est épais, mais lire les premières pages, faire les premiers tutoriels est vraiment indispensable si vous voulez bien progresser sur AWS. Un autre service absolument vital, si vous ne l'avez pas activé, activez-le tout de suite, c'est CloudTrail. CloudTrail est un service tout simple, mais qui vous sauve la vie. Il s'active en un clic. Si ce n'est pas le cas chez vous, vous devez avoir un gros bouton bleu qui s'appelle Enable CloudTrail. Ce service enregistre l'intégralité des appels d'API qui sont faits dans votre compte, et vous pouvez le faire sur toutes les régions. Vous pouvez consolider dans un seul journal d'accès l'ensemble des appels d'API qui sont faits sur votre compte AWS. On voit ici mes dernières actions. Dans ces trails, on trouve l'ensemble des appels d'API. Tout est un appel d'API sur AWS, que vous utilisiez la console, les SDK ou la ligne de commande, tout est tracé. Ça vous permet d'avoir une trace de tout ce qui se passe dans votre compte et, en cas d'incident de sécurité, d'analyser ce qui s'est passé. En cas d'erreur, de savoir ce qui s'est passé, si quelqu'un a effacé ou a tué par erreur des instances, vous pouvez voir qui l'a fait, quel jour, à quelle heure, etc. Ça vous permet d'avoir un suivi complet de toute l'activité de votre compte. Activer CloudTrail, le coût de CloudTrail est vraiment minime, il n'y a vraiment aucune raison de ne pas s'en servir. Un autre service récent, lancé à reInvent il y a deux mois, s'appelle GuardDuty. C'est un service qui s'acquitte en un clic. Il va analyser le trafic réseau à l'intérieur de votre VPC, à l'intérieur de votre compte, et vous signaler des problèmes divers et variés. Par exemple, il va dire : je vois que sur cette instance EC2 il y a un port non protégé. C'est le port 22, donc là, oui, je dois avoir un port SSH qui est ouvert à tous. Bon, ce n'est pas idéal, c'est sûrement pour faire des démos. Je vois que quelqu'un essaie de forcer mon mot de passe SSH. Peut-être sur la même instance. Je peux sans doute voir de qui il s'agit. C'est une IP chinoise. Donc, on voit tous les problèmes potentiels de sécurité, toutes les anomalies, avec un niveau de sévérité bleu, jaune, rouge. C'est vraiment un service qu'il est indispensable d'activer, il n'y a aucune raison de s'en passer. Si tout va bien, vous n'en aurez jamais besoin, mais si vous avez un souci ou si quelqu'un veut vous jouer des tours, GuardDuty va le détecter. Un troisième service, un peu du même genre, s'appelle Macie. Il s'active en un clic, et il va analyser le type de données que vous stockez dans Amazon S3, le service de stockage d'objets d'AWS, qui est un des services les plus utilisés. Il va essayer de voir si, par hasard, vous n'auriez pas des permissions dangereuses sur tel ou tel compartiment dans S3. Un compartiment est l'équivalent d'un répertoire avec un jeu de permissions précis, etc. Il va regarder ce qu'il y a dans vos compartiments S3, essayer automatiquement avec du machine learning d'identifier de quel type de données il s'agit, et regarder les permissions que vous avez assignées à ce compartiment. S'il se rend compte qu'il y a des numéros de carte bleue dans un compartiment qui est en accès public, il va vous alerter. Il y a une typologie de données construite automatiquement, et en cas de souci, il va vous remonter les alertes. J'ai fait le test tout à l'heure, donc il me dit qu'il y a peut-être des informations de carte de crédit dans ce bucket. Je n'y crois que modérément, mais il faut être prudent. Il y a des fichiers JSON, et peut-être qu'à l'intérieur de ces fichiers, il y a une chaîne de caractère qui l'inquiète. Il dit que c'est peut-être des numéros de cartes bleues. En l'occurrence, non, mais il vaut mieux vérifier. Il va être capable de trouver si vous avez des mots de passe, des données financières, etc. Vous pouvez configurer tout ça de manière assez fine. C'est un service que je vous conseille d'activer sans réfléchir. Ça peut vous sauver la vie si quelqu'un, par mégarde, a mis des permissions trop laxiques sur un compartiment S3 qui contient des données de l'entreprise. Il vaut mieux s'en rendre compte avec Macie que s'en rendre compte à la une de tel ou tel site web. On a pu en avoir des exemples récents. Un autre service qui mérite d'être mentionné, c'est Inspector. Inspector est un outil qui va auditer vos instances. Vous allez installer un agent sur vos instances EC2, et cet agent va s'exécuter périodiquement pour chercher des vulnérabilités sur vos instances. S'il y a des trous de sécurité, il va les trouver et vous recommander des manières de les corriger, etc. C'est un service un peu plus avancé, mais qui peut être intéressant. Le dernier dont je voulais parler, c'est Config. Config va construire un historique des modifications qui ont été faites sur vos ressources. Par exemple, si je regarde les instances EC2, vous avez une timeline, instance par instance. On va en prendre une complètement au hasard. On va voir le cycle de vie de cette instance depuis sa création. Elle a été créée il y a longtemps, c'est peut-être une de mes instances de test que je passe ma vie à arrêter, à redémarrer, etc. Et à chaque fois qu'il y a des changements, il les enregistre. Là, manifestement, j'ai attaché un volume disque à ce moment-là. À chaque fois qu'on fait un changement de config sur une ressource AWS, on a cette timeline, cet historique de ce qui s'est passé. C'est toujours à des fins d'audit et d'analyse pour dire, il y a quelque chose qui ne va pas bien sur la plateforme, qu'est-ce qui a changé ? Est-ce que quelqu'un a touché à quelque chose ? Est-ce qu'une instance a été modifiée ? On peut appliquer ce traitement à un grand nombre de ressources. On peut le regarder sur les VPC, est-ce qu'il y a des modifs sur mes VPC, etc. C'est la première partie de Config. La deuxième partie, ce sont les règles. Vous pouvez demander à Config de vérifier que telle ou telle règle est appliquée. Par exemple, j'ai une règle prédéfinie qui s'assure que CloudTrail est activée. Ok, CloudTrail est activé, tout va bien. J'ai une règle qui s'assure que l'authentification multifacteur est activée dans mon compte. Parfait. J'ai ajouté une règle pour dire qu'il faut vérifier que les volumes disques de toutes mes instances sont chiffrés. Ces instances-là ne sont pas chiffrées, donc j'ai une alerte qui me dit que j'ai sept instances EC2 dont les volumes ne sont pas chiffrés. On peut simplement alerter ou on peut agir, on peut automatiser la réponse en disant qu'une instance qui n'est pas conforme à cette règle peut être arrêtée, etc. On peut envoyer un message. Sur des règles de très haut niveau, par exemple, vérifier que CloudTrail est activé, Config est un bon outil pour s'assurer que vous utilisez tel ou tel service de manière conforme aux règles de l'entreprise. Je tenais à aborder certains de ces sujets qui sont peut-être un peu avancés pour des utilisateurs débutants, mais je voulais vraiment vous sensibiliser au fait que la sécurité est indispensable, c'est notre priorité zéro. On passe beaucoup de temps et d'énergie à sécuriser les services et à fournir des services qui permettent aux clients de sécuriser leur plateforme, mais il faut que vous en serviez. Dès le début, si vous commencez sur AWS, c'est vraiment une bonne idée de jeter un œil à ces services : IAM, CloudTrail, GuardDuty, Macie, peut-être Inspector, et Config. Vous vous familiarisez avec eux, les activez généralement en un clic, et commencez à enregistrer l'historique de l'activité dans votre compte. Ça peut vous sauver la vie à un moment ou un autre. En cas d'erreur humaine ou en cas de malversation, vous avez une trace de ce qui s'est passé. C'est vraiment intéressant. Voilà, j'en ai fini avec ce premier webinar. Vous retrouverez tout ça en détail sur le site. Vous trouverez bien sûr les documentations détaillées sur le site. Et une fois de plus, je vous incite vraiment à tester, créer un compte, lire bien l'offre gratuite et rester dans le cadre de cette offre. Vous verrez, vous arriverez déjà à faire pas mal de choses. Et puis, à l'aide de la documentation et d'autres webinars antérieurs, vous pourrez continuer à progresser. Merci beaucoup. Merci beaucoup pour nous avoir écoutés. Hugo m'envoie des questions. Je vais commencer à y répondre au fil de l'eau. Une question de Franck sur le niveau d'usage gratuit : qu'est-ce qui se passe si on dépasse le niveau d'utilisation gratuite ? C'est facturé. Dès que vous dépassez, c'est facturé. C'est important d'avoir ça en tête, mais si vous dépassez un peu, vous allez avoir une facture qui sera de quelques cents ou au grand maximum de quelques dollars. Il n'y a pas d'effet de seuil, il n'y a pas de crainte à avoir. Si vous débordez un peu du niveau d'usage gratuit, vous n'aurez pas une facture de 500 dollars d'un coup. Une question de Benjamin : quelle différence entre EC2 et LightSail sur une même config ? Il n'y en a pas. LightSail, c'est vraiment juste une façon simple de vous donner accès aux ressources. Ça tourne sur le même type d'infrastructure. Si vous regardez les plans LightSail, c'est assez facile de voir sur quel type d'instance EC2 ça fonctionne. Une question de Patrice : est-ce qu'on peut faire communiquer plusieurs régions entre elles ? Oui, vous pouvez avoir des instances déployées, par exemple à Paris et à Francfort, et vous pouvez les faire communiquer. Si elles sont publiques, vous pouvez les faire communiquer par le réseau public. Si elles sont privées, vous pouvez définir des VPN, créer des chemins privés, etc. Un serveur AWS reste un serveur. S'il a une IP publique, il peut parler sur Internet et réciproquement. Est-ce que Macie fonctionne sur EBS ? Non, Macie, aujourd'hui, c'est uniquement S3. Mais c'est une bonne idée. La question de Gérard : est-ce qu'il y a une traçabilité des configs ? Oui, dans Config, je vous l'ai montré dans la console, mais ces infos-là, vous pouvez les extraire via des appels d'API. Via les infos qui sont dans Config, vous pourriez vous construire une base de données des changements au fil de l'eau et réappliquer des changements ou annuler des changements qui ont pu être faits. Entre CloudTrail qui logue tout, donc l'appel d'API et les paramètres, on peut voir très précisément qui a fait l'appel depuis quelle IP, à quelle heure, sur quelle ressource, avec quels paramètres. Entre ça et les infos qui sont en Config, oui, vous avez une trace assez fine de ce qui se passe dans votre compte. Est-ce qu'on peut avoir des IPv6 sur les instances ? Oui, on a lancé IPv6 pour EC2. C'est même, il y a décembre 2016, on a lancé IPv6 pour EC2, et ça a été étendu l'année dernière sur pratiquement toutes les régions et sur d'autres services AWS. N'hésitez pas à aller regarder ce blog. Est-ce qu'il est possible de voir les flux réseau bloqués ? Oui, c'est un truc qui s'appelle VPC Flow Logs. C'est un log qui peut contenir l'intégralité du trafic entrant et sortant sur votre réseau. Vous avez le choix d'activer uniquement le logging du trafic bloqué, vous pouvez le faire par subnet, par interface, etc. Vous pouvez capturer le trafic, le loguer et l'inspecter. La deuxième partie de la question d'Alexis, c'était détecter des comportements anormaux type DDoS. Oui, vous l'avez vu même dans GuardDuty, on voit des images qui essaient de brute forcer mes clés SSH. Spécifiquement sur le DDoS, on a un autre service qui s'appelle AWS Shield, qui va protéger votre plateforme du DDoS. Il y a deux niveaux dans Shield : un premier niveau inclus dans le service, Shield Standard, que vous en profitez même sans le savoir gratuitement, et un deuxième niveau, Shield Advanced, qui s'intègre avec du WAF, donne accès à une hotline, aux experts AWS. C'est un service payant qui est relativement coûteux et destiné aux très grosses entreprises. Mais déjà, allez voir AWS Shield Standard, ça vous donnera la liste de tout ce qu'on fait déjà automatiquement lorsqu'on vous protège. Est-ce que l'historique de AWS Config est limité dans le temps ? Quelle est la durée de rétention ? J'ai envie de dire qu'il n'y a pas de limite. Il n'y a pas de limite de rétention. Tout ça est stocké dans S3. Il est possible que vous ayez une limite à ce que vous pouvez voir dans la console, mais on peut le faire en utilisant l'API. Je ne crois pas qu'il y ait de limite de rétention. Si vous en trouvez une, envoyez-moi un message sur la chaîne YouTube. CloudTrail est gratuit ? Non, mais vu son prix, ce serait une erreur de s'en passer. Le coût de CloudTrail est de 2 dollars par tranche de 100 000 appels pour les événements de gestion, et 10 cents par tranche de 100 000 événements pour les événements de données, principalement les accès à S3. Même si vous avez un compte très actif, votre facture CloudTrail sera de quelques dollars par mois, mais le jour où vous en avez besoin pour diagnostiquer une erreur humaine, une intrusion, vous me remercierez de vous avoir dit de cliquer sur le bouton. Il n'y a pas de raison de ne pas le faire. Hugo est en train de m'insulter en disant que j'ai débordé, mais ça, c'est comme d'habitude. Écoutez, merci beaucoup de nous avoir suivis pour ce premier webinaire. On va faire une courte pause de quelques minutes et on se retrouve très rapidement pour le deuxième webinaire qui sera le récap de ReInvent. On va l'afficher à l'écran. Donc rendez-vous dans quelques minutes pour le deuxième webinaire. Merci beaucoup et à tout de suite. Rebonjour à tous, nous revoilà pour le deuxième webinar de cet après-midi, même si pour moi c'est le matin, car il est ici 7h45, le soleil est levé, le ciel est bleu. Je suis déjà en train de travailler, mais c'est rien, c'est pour la bonne cause. Ça me fait plaisir de vous retrouver. Dans ce deuxième webinaire, on va faire un panorama, un vaste tour d'horizon des nouveautés annoncées à ReInvent 2017. Notre conférence qui a eu lieu à Las Vegas, fin novembre, début décembre, mais qui a été particulièrement riche. Accrochez vos ceintures, on a beaucoup de choses à voir et j'espère qu'on ne débordera pas trop cette fois-ci. On prendra quand même du temps pour répondre à vos questions. Je sais que c'est un sujet qui vous intéresse beaucoup, donc allons-y. Voilà l'agenda, on va parler d'abord de tout ce qui touche au compute, donc toutes les nouveautés instances, containers, serveurless, ensuite on passera aux données en général, base de données, stockage, on parlera de quelques nouveautés réseau, sécurité, puis les outils de développement, l'intelligence artificielle, mon sujet favori, l'internet des objets, et l'annonce d'un nouveau service pour la réalité augmentée et la réalité virtuelle. Il est possible que certaines annonces de moindre importance ne figurent pas dans cette liste. Je me suis concentré sur les gros sujets et j'ai volontairement supprimé deux catégories qui ne rentraient pas dans le timing : les services médias, tout ce qui touche à Amazon Elemental, tout ce qui est traitement de flux vidéo, et je ne parlerai pas non plus d'Alexa for Business qui a été une des annonces importantes. Je laisserai les équipes Alexa faire ce travail bien mieux que moi. On va se concentrer déjà sur AWS, vous allez voir qu'il y a de quoi faire. Allez, c'est parti ! Commençons donc par le calcul et en particulier les instances. La famille d'instances AWS s'est encore étoffée. On va de LightSail, que je vous ai montré dans le webinaire précédent, les instances T2, jusqu'à des monstres comme les instances C5, les instances GPU, G3, P3 et même des instances FPGA pour l'accélération matérielle. L'annonce avait eu lieu un petit peu avant Re:Invent, mais je pense que ça vaut la peine de le re-mentionner. On a lancé la famille P3, qui est une nouvelle famille d'instances GPU destinée au machine learning et au deep learning. Cette famille P3 utilise le dernier GPU Nvidia, l'architecture Volta, qui est le GPU le plus puissant disponible aujourd'hui sur le marché. Cette famille existe en plusieurs tailles, avec 1, 4 ou 8 GPU. Dans le cas de P3 16X Large, la plus grosse, on a 8 GPU pour un total de 40 960 coeurs CUDA et des performances absolument incroyables. Si vous avez des charges de travail machine learning, deep learning ou que vous faites du calcul scientifique qui nécessite des GPU en général, je vous incite très fortement à migrer de P2 vers P3. L'augmentation de performance est très spectaculaire. On a également rajouté une nouvelle génération d'instances M. Les instances M, ce sont les instances généralistes d'AWS. Ce sont celles qui conviennent bien, qu'on choisit par défaut pour des charges de travail classiques. Typiquement, des applis web, des applis métiers qui n'ont pas de besoin en calcul particulièrement classique. M c'est vraiment le compagnon fidèle de vos projets sur AWS. Vous ne pouvez pas vraiment vous tromper en commençant avec ça. Et puis s'il faut mettre plus puissant ou plus spécialisé, vous pouvez le faire après. On a la cinquième génération ici, qui s'appelle M5, dont la principale nouveauté est de supporter la nouvelle génération Intel, basée sur les architectures Skylake. Plus de puissance, également plus de mémoire, plus de coeurs, plus de tout. Et comme vous le voyez, une augmentation du rapport prix performance de 14% par rapport à M4. Donc là aussi, si vous aviez des M4, progressivement, il n'y a pas d'urgence à le faire, mais progressivement passer sur M5 et vous en aurez encore plus pour votre argent. On a également annoncé une nouvelle famille qui s'appelle H1. Les instances H1, ce sont des instances qui sont optimisées pour le stockage dense. Des instances qui vont disposer de jusqu'à 16 Tera de stockage local. Ce qui les prédispose à l'utilisation dans des clusters Big Data, des clusters Hadoop, etc., où il faut avoir du stockage local pour travailler par exemple sur Hadoop. Un nœud Hadoop va travailler avec les données qui sont localement présentes. Donc si on a du stockage local par rapport à du stockage réseau, bien sûr on gagne en performances. Elles ont des débits réseau importants puisque comme ce sont souvent des instances qui sont en clusters, elles doivent discuter entre elles, donc il faut qu'elles puissent avoir du débit entre elles. On a également lancé ce qui était une forte attente de nos clients, une famille d'instances bare metal qui s'appelle i3.metal, j'adore ce nom. Et donc ces instances, comme leur nom l'indique, vous permettent d'accéder directement aux ressources matérielles tout en continuant à profiter de l'environnement AWS et des services AWS. Voilà donc c'était une demande importante de certains de nos clients et on est content de pouvoir les satisfaire. On a également fait une évolution très importante sur la famille T2. On a parlé des T2 tout à l'heure. Les T2 sont extrêmement utilisées. Elles ont une particularité par rapport aux autres instances, c'est-à-dire qu'une instance T2 n'accède pas à 100% du CPU. Quand vous avez une C5 ou une M5, elle a accès à 100% du CPU de son temps disponible. Une instance T2 est destinée à des charges de travail un peu épisodiques et donc il y a un système de crédit qu'une instance va acquérir au fil du temps, donc elle gagne périodiquement des crédits et puis lorsqu'elle a un pic d'activité, lorsque le CPU de l'instance a un pic, on va consommer ses crédits, donc on va pouvoir consommer ses crédits pendant un certain temps jusqu'à l'épuisement du crédit et là l'instance va être ralentie jusqu'à ce qu'elle ait à nouveau obtenu des crédits. Ça c'est super parce que ça permet d'avoir des instances extrêmement économiques pour des charges de travail, des environnements de développement, des machines de test, des machines qui travaillent de manière épisodique et sur lesquelles on n'a pas besoin d'avoir des garanties de temps de réponse, on n'a pas besoin d'avoir des garanties de performance très fortes, mais par contre on ne veut pas qu'elles coûtent cher. Si on met des M4 ou des M5 pour faire ça, on aura de bonnes performances, mais on va les payer un peu plus cher que nécessaire. Donc généralement on met des T2. Parfois sur des T2, on peut avoir un pic de charge un peu prolongé, et on n'a pas envie que pour autant cette instance soit ralentie. On a introduit ce nouveau mécanisme qui s'appelle T2 Unlimited, que vous pouvez activer à la demande sur des instances T2. Pour un surcoût qui est plutôt faible, vous avez la possibilité de garder le CPU au-delà de l'épuisement des crédits. Ça permet de se dire, bon ok, j'ai des T2, mais de temps en temps, j'ai peut-être un gros build à faire, j'ai peut-être un truc un peu plus lourd que d'habitude à faire, j'ai envie de le faire vite et bien, donc bon, c'est pas grave, je vais burster au-delà de ma capacité autorisée par les crédits, je vais avoir une très légère surfacturation, mais bon, au moins je finis le boulot. Et ça, c'était une forte demande de nos clients sur T2. On a également ajouté dans EC2 la possibilité d'avoir des templates pour lancer des instances, ce qui permet facilement de lancer une ou plusieurs instances avec des paramètres communs. Vous pouvez définir vos templates en disant, je veux lancer un paquet d'instances avec telle et telle propriété. Et donc je les lance à la demande, toujours en utilisant RunInstance comme avant, mais au lieu de passer tous les paramètres de l'instance, je peux passer un template, et ça permet de simplifier son automatisation. On a fait pas mal d'améliorations sur Spot également, donc maintenant la plus grosse étant sans doute la capacité à commander des instances Spot de manière synchrone, directement avec RunInstance. Vous lancez, vous demandez des instances Spot comme vous demandez des instances à la demande finalement, avec la même API. Simplement vous spécifiez que vous voulez des spots et vous les payez au prix du marché. On a simplifié le mécanisme d'achat sur Spot pour le rendre identique au mécanisme d'achat d'instance on-demand. On a également ajouté la capacité à faire hiberner les instances. Lorsque vous perdez une instance Spot, vous allez pouvoir conserver un état mémoire sur un volume EBS, ce qui permet de ne pas perdre l'état de l'instance au moment où elle a été arrêtée. On a ajouté également un nouveau service, qui s'appelle TimeSync, qui est un service NTP hébergé, donc qui vous permet tout simplement de synchroniser l'heure sur vos instances avec un service AWS. Voilà, truc tout simple, mais on s'est dit que c'était peut-être pas la peine que tous nos clients s'amusent à installer des serveurs NTP. Donc maintenant vous pouvez utiliser directement le NTP fourni par Amazon. Passons aux containers. Il y a eu beaucoup de choses sur les containers. On a un service de containers qui existe depuis déjà deux ou trois ans qui s'appelle ECS, que vous connaissez sans doute, qui est sans doute la façon la plus simple de déployer des containers sur AWS, qui vous fournit de l'infrastructure managée pour déployer vos containers. C'est un service qui a eu un grand succès. On a plus de 100 000 clouds actifs sur ECS, donc des centaines de millions de containers lancés chaque semaine et une croissance qui ne se dément pas depuis le lancement du service en 2015. On a vraiment une excellente adoption sur ce service et on a un ensemble de références clients qui sont importantes. Voilà, je vous renvoie à la page du service ECS pour plus de détails. Première solution qui a été mise à disposition des clients AWS et une partie de nos clients nous a dit ok très bien ECS mais nous on voudrait utiliser Kubernetes. Et très bien, donc notre position n'est pas de forcer nos clients à utiliser tel ou tel service, notre objectif c'est de faire en sorte que les clients aient le choix et que quel que soit le choix technologique qui est le leur, bien que notre plateforme AWS soit le meilleur endroit pour le supporter. Et de manière intéressante, il y a eu une enquête du CNCF, donc la Cloud Native Foundation, qui a réalisé que 63% des charges de travail Kubernetes qui tournent dans le cloud tournent sur AWS. Donc, en très forte augmentation par rapport à l'année précédente. Voilà, c'est peut-être un chiffre qui en surprendra plus d'un, mais toujours est-il que la forte demande de nos clients de supporter Kubernetes sur AWS, AWS nous a amené à lancer un nouveau service qui s'appelle EKS qui est finalement le jumeau d'ECS mais simplement cette fois l'orchestrateur qui est utilisé pour les containers c'est Kubernetes. Ce service est disponible en preview, vous pouvez rejoindre la preview et on a exactement la même philosophie que sur ECS, c'est-à-dire de l'infrastructure managée, des clusters managés mais avec les API et les mécanismes de Kubernetes. Et on est allé un cran plus loin, on a sorti un service qui s'appelle Fargate, qui est un service entièrement managé, où vous ne voyez même plus les clusters, vous ne faites que déployer vos containers sur des flottes d'infra entièrement managées, entièrement invisibles, un peu comme Lambda finalement vous permet de déployer du code sur de l'infra complètement invisible, Fargate vous permet de déployer vos containers à la demande en quelques secondes sur de l'infra qui est complètement invisible. Fargate pour ECS est disponible aujourd'hui et sera disponible cette année pour EKS. De très grosses innovations sur les containers cette année. Passons au serverless. Lambda est partout, il n'y a pas un service qui ne dispose pas de son intégration avec Lambda, ce qui permet aux développeurs de concevoir des applications événementielles qui réagissent à des événements d'infrastructures à l'intérieur de la plateforme, à des événements provenant de l'extérieur via des API, etc. Lambda s'est imposé comme la technologie qui permet de construire ce genre d'application. Là aussi on a une adoption qui est extrêmement forte. Je crois que je ne croise plus un client aujourd'hui qui n'utilise pas Lambda pour une chose ou pour une autre. C'est vraiment devenu, que ce soit pour la partie DevOps, la partie automatisation ou même la partie construction d'applications complètes, d'applications web en particulier, un des services fondamentaux sur AWS. Il était logique qu'on ajoute des nouvelles fonctionnalités. On a introduit un application repository qui permet aux développeurs de publier des applications serverless, un peu comme la marketplace permet de déployer des AMIs pré-packagés. Grâce à ce repository, vous allez pouvoir chercher des applications serverless fournies par des tiers et les déployer à l'intérieur de votre compte. C'est un service qui est encore en preview pour l'instant. On a également ajouté deux nouveaux runtimes pour Lambda. On avait déjà Python, Node, Java et... Non, pardon, ce n'est pas C++. C'est C#. J'ai pris mes rêves pour des réalités. C'est C#, pardon. J'aimerais bien avoir C++. Et on a ajouté .NET et Go. On en est donc à 6 runtimes pour Lambda. Toujours pas de PHP au grand désespoir des développeurs. Toujours pas de Ruby, mon grand désespoir. Je ne perds pas complètement espoir. Les prochains, ce sera forcément ça. Il ne reste plus rien. C'est triste. On a ajouté le support de Lambda dans CodeDeploy, qui est un des outils d'intégration et de déploiement continu sur AWS, qui permet, comme son nom l'indique, de déployer du code sur de l'infrastructure AWS, et d'ailleurs sur l'infrastructure on-premise également. CodeDeploy supportait EC2, les groupes d'autoscaling et les serveurs on-premises, et on a ajouté Lambda. Vous pouvez maintenant intégrer votre code Lambda dans vos chaînes de déploiement continu. Ce qui est plutôt une bonne nouvelle. Dans la même logique, on a ajouté sur API Gateway la possibilité de déployer plusieurs versions d'une même API. On peut faire du canary deployment, on peut faire du déploiement progressif lorsqu'on a une nouvelle version d'une API, un peu comme un AB test finalement, on peut basculer une fraction du trafic vers cette API, vérifier que tout va bien et puis ensuite faire le déploiement complet. On n'avait pas cette possibilité là avant, donc on était un petit peu obligé de ruser. Maintenant on peut le faire de manière un peu plus sécurisée, un peu plus fine. Parlons des bases de données maintenant. Vous connaissez sûrement Aurora qui a été lancé il y a un petit moment maintenant, qui est une implémentation par AWS, une implémentation haute performance de MySQL et Postgre. C'est toujours le service à la plus forte croissance dans l'histoire d'AWS. On a encore multiplié par 2,5 le nombre de clients qui utilisent Aurora. Aujourd'hui, on a des dizaines de milliers de clients sur ce service. C'est vraiment un service dont le succès ne se dément pas. Vous connaissez certainement le fonctionnement d'Aurora. C'est un fonctionnement maître-esclave. On a un nœud maître, on construit un cluster avec un nœud maître qui va prendre des écritures, qui va les appliquer sur une couche de stockage partagée sur laquelle un ensemble de reads replica vont venir lire. Et donc cette couche de stockage étant à très faible latence, on n'a quasiment pas de lag entre le maître et les esclaves. On est très heureux d'annoncer une évolution importante de ce service qui s'appelle le Multimaster, c'est-à-dire la capacité cette fois à écrire non plus sur un seul maître mais sur plusieurs maîtres. C'est un problème que beaucoup de compagnies de bases de données ont essayé de résoudre de manière efficace et scalable au fil des années, et on est vraiment heureux de pouvoir amener cette capacité à nos clients. Ça c'est disponible aujourd'hui en multi-AZ, donc à l'intérieur d'une région. Vous pouvez avoir plusieurs maîtres dans des AZ différentes, ce qui veut dire que si vous avez un incident dans une AZ, vous pouvez continuer sans interruption à écrire sur votre cluster via les maîtres survivants, là où auparavant, si l'AZ où le maître mourait, il y avait un petit délai de failover, très court, mais quand même un délai de failover pour qu'une des réplicas soit promue en tant que nouveau maître. Ce problème aujourd'hui n'existe plus. On livrera cette année la capacité à faire ça entre régions, à avoir des écritures sur un même cluster, étalé sur plusieurs régions, la capacité à faire des écritures de chaque côté. Ce qui est vraiment une capacité hyper importante pour la haute disponibilité et la performance des applications. Ça c'est vraiment une, sans doute une des plus belles annonces de Re:Invent, en tout cas de mon point de vue, mais il y en a une deuxième qui est assez sympa aussi, c'est pour répondre à ce constat finalement que certaines charges de travail sur des bases de données sont très irrégulières et c'est difficile de répondre efficacement avec des techniques de scaling habituelles, parce qu'on peut avoir des pics qui vont durer quelques minutes ou quelques dizaines de minutes et donc c'est pas facile de savoir à quel moment précisément est-ce qu'il faut scaler le nombre de répliquats. On peut avoir du mal sur des fonctionnements de ce style à répondre efficacement. Soit on va sur-provisionner pour répondre au pic et on va trop dépenser d'argent et ça c'est mal, soit on va dire tant pis pour le pic, on l'encaisse comme on peut et pendant cette période là on va avoir des performances dégradées. Pour répondre à ce problème là on a ajouté Aurora Serverless qui est exactement ce que le nom indique, c'est-à-dire Aurora, mais sans avoir à gérer d'infrastructures, sans avoir à gérer de clusters, simplement accéder à Aurora avec une chaîne de connexion, et puis on laisse le back-end scaler automatiquement, et on paye à la seconde. Ça c'est en preview, et je pense que c'est un des services les plus attendus aujourd'hui. On ne pouvait pas ne pas parler de DynamoDB qui existe depuis longtemps maintenant, qui est là aussi utilisé massivement par les clients d'AWS qui ont besoin de stocker des données peu structurées ou de type NoSQL ou autre. Et un petit peu comme finalement pour Aurora, on est très heureux d'annoncer le multi-master sur DynamoDB et non seulement le multi-master mais une multi-région. C'est-à-dire que vous êtes capable maintenant de déployer des tables globales à l'échelle mondiale, donc à l'échelle de peut-être toutes les régions d'AWS et d'écrire depuis n'importe où dans cette table de manière synchronisée. Ça c'est sûrement un rêve aussi pour beaucoup de concepteurs et beaucoup d'architectes. Je sais que ça a été un de mes problèmes pendant longtemps. La capacité à écrire de manière globale et distribuée sur un datastore unique, en ignorant les frontières géographiques et les frontières de datacenter. Et ça, c'est disponible aujourd'hui, vous pouvez le tester. On a également ajouté la capacité à backuper les tables DynamoDB, ce qui était une demande de nos clients. Ça, c'est disponible tout de suite. Et vous pourrez faire de la restauration Point in Time, c'est-à-dire vous pourrez demander à DynamoDB, sur la base d'un backup, de dire remets-moi la base dans le même état que dans l'état où elle était le 15 janvier, à 12h35 et pas juste à restaurer le dernier backup, mais en tout cas vous pouvez dire, je veux revenir à un état précis de ma table et je peux le faire. Donc deux très grosses innovations sur DynamoDB. Et puis, comme si ça ne suffisait pas, on a ajouté encore une nouvelle base de données qui s'appelle Neptune, qui est une base de données graph. Là aussi, ça a manqué certainement à un arsenal. On a eu beaucoup de demandes en ce sens et donc vous pouvez là aussi rejoindre la preview de Neptune et profiter d'une base graph sur de l'infrastructure managée hautement disponible, etc. Encore un autre, c'est un nouveau service, décidément, qu'est-ce qui est comme annonce à Re:Invent cette année, ça n'a pas arrêté. Ce service s'appelle S3 Select. C'est un service qui est à la frontière du stockage et des bases de données. Ce service va vous permettre de faire des requêtes sur le contenu de vos objets S3 en utilisant du SQL standard. Ce qui vous permet de... On pourrait presque dire que ça vous permet de vous passer des bases de données, ce n'est pas tout à fait vrai, mais en tout cas, sur du contenu qui est peut-être du contenu peu structuré, peut-être à faible valeur ajoutée, mais sur lequel de temps en temps vous avez envie de faire des requêtes, vous pourrez le faire avec S3 Select directement, sans ingérer ces données dans le moindre back-end. Voilà. Donc c'est une technologie qui ressemble un peu à ce qu'Athena sait faire. D'ailleurs je crois qu'il est probable qu'Athena utilise S3 Select, si ce n'est pas déjà le cas. Mais ici c'est vraiment encore un cran plus loin, c'est-à-dire vraiment là on accède aux données directement dans S3, et on le fait avec du SQL Standard. Et on étend cette capacité aux données calculatives qui sont en Glacier. Ça reste encore un peu un mystère pour moi, je pense qu'il y a de la sorcellerie parce que Glacier c'est de l'archivage long terme et bien on peut quand même réussir à le requêter. Donc l'objectif c'est toujours le même, c'est de vous simplifier la vie, c'est de vous permettre de requêter les données là où elles sont sans avoir à les charger, sans avoir à les transformer, sans avoir à les bricoler. Vous avez des grandes quantités de logs ou des grandes quantités de données dans S3. De temps en temps, vous avez besoin de faire une requête sur des gros volumes, vous avez envie que ça aille vite. Vous pouvez le faire avec S3 Select et Glacier Select, avec des niveaux de performances qui sont intéressants. On a également lancé un service qui s'appelle Amazon MQ, qui est un gestionnaire de messages managé. Si vous connaissez des solutions open source comme RabbitMQ par exemple, sans parler des solutions commerciales, vous pouvez désormais les remplacer, du moins les évaluer face à Amazon MQ qui est conforme à ActiveMQ et à d'autres standards de messagerie, et toujours avec la même logique, de l'infra-managée, du paiement à l'usage, etc. Voilà, nouveau service disponible à tester dès aujourd'hui. Voilà, donc beaucoup de choses en data également, ça a été vraiment complet et ça fait beaucoup de choses à tester. Alors parlons maintenant un peu de réseau. Une des grosses annonces réseau, c'est PrivateLink. PrivateLink, c'est... Vous connaissiez peut-être déjà les VPC Endpoint, qui étaient la capacité pour S3 et DynamoDB à être disponibles à l'intérieur de vos VPC, y compris dans des subnets privés. Ce qui vous permettait d'accéder à S3 et à Dynamo depuis des subnets privés sans passer du tout par l'Internet public, sans passer par des endpoints publics. Finalement, PrivateLink, c'est la généralisation de ça. C'est la généralisation des VPC endpoints à d'autres services AWS, à vos propres services. Vous pouvez cliquer vous-même des liens privés entre vos VPC et votre infrastructure on-premise et ça c'est une chose que je trouve particulièrement intéressante. C'est également disponible pour les partenaires, c'est-à-dire que vous pouvez via des solutions tierces disponibles sur la marketplace créer un VPC endpoint qui vous permettra d'accéder à son service SaaS par exemple directement depuis la partie privée de votre VPC. Une fois de plus sans passer par l'Internet public. Ce qui en termes de performance, en termes de sécurité, etc. est particulièrement intéressant puisque vous pouvez également appliquer des règles de sécurité particulières sur ces endpoints. C'est vraiment la généralisation du VPC endpoint à davantage de services, vos propres applications et des applications des partenaires. On peut également maintenant faire du peering inter-région entre les VPC. Avant, le peering était limité à une région. Maintenant, c'est étendu. Vous pouvez peerer de partout à partout. Sachant que ça passe par le réseau interne et que donc le trafic ne passe pas sur l'Internet public. Un autre service de sécurité, enfin un nouveau service de sécurité que je vous ai montré dans le premier webinar, donc il s'appelle GuardDuty, qui sur la base de CloudTrail, sur la base des VPC Flowlog, sur la base d'un ensemble de logs, applique des algorithmes de machine learning, des traitements intelligents pour détecter en permanence des menaces, des risques, des comportements anormaux à l'intérieur ou à la frontière de votre compte. N'hésitez pas à l'activer, c'est comme CloudTrail, ça s'active en un clic et il faut vraiment ne pas s'en passer. Le coût là aussi est faible et l'historique de sécurité, la détection de sécurité que fait GuardDuty vaut 100 fois le prix qu'il vous coûte. Passons maintenant aux outils de développement, en tout cas outils développeurs. Un service un peu différent qui s'appelle Cloud9, qui est un IDE complètement hébergé dans le cloud, qui vous permet de faire ce qu'on fait avec un IDE, c'est-à-dire d'écrire du code, de l'exécuter, de le débugger. Il y a une intégration avec certains services AWS, Lambda, etc. On peut faire du travail collaboratif, on peut travailler en temps réel sur le même code, etc. Voilà, c'est assez intéressant. C'est plutôt orienté, si vous utilisez des IDE historiques comme Eclipse ou IntelliJIDE, on ne parle pas tout à fait la même chose. Là c'est vraiment des IDE web, c'est vraiment très orienté front-end, développement web, développement de fonction Lambda, etc. L'objectif n'est pas de faire un IntelliJIDE hébergé, c'est vraiment d'avoir un environnement à la fois léger, collaboratif, pour des petits bouts de code que des très gros projets. Mais néanmoins pour ce genre de cas d'usage c'est assez intéressant, assez joli et assez agréable à utiliser. Autre outil qui a été annoncé, autre service s'appelle AppSync. AppSync c'est un service qui va vous permettre de simplifier la réalisation de vos applis mobiles et web collaboratives et qui s'appuie sur GraphQL, qui va vous permettre de synchroniser du contenu, de gérer du contenu offline, etc. Là aussi, essentiellement, il demande des développeurs mobiles qui voulaient avoir du GraphQL. Passons à l'IA. Je sais qu'on en a parlé il y a quelques mois maintenant mais on va refaire un petit passage donc on a fait la AI week mi-décembre donc les webinaires sont en ligne donc si vous voulez plus de détails sur tous ces services je vais aller assez vite n'hésitez pas à aller voir les webinaires antérieurs. Le premier problème que nos clients ont demandé de résoudre c'était de la capacité à streamer et à traiter du contenu vidéo venant de caméras, d'appareils photos, d'équipements connectés. C'est vrai que c'était une capacité qu'on n'avait pas encore construite et qui est disponible maintenant via un service qui s'appelle Kinesis Video Streams. Vous connaissez certainement Kinesis qui est notre service de messaging, du streaming manager, qui était jusque là plutôt utilisé pour des messages applicatifs, et bien désormais vous pouvez streamer de la vidéo directement dans Kinesis et diriger ce stream vers différentes destinations. L'une d'entre elles étant un nouveau service qui s'appelle Amazon Recognition Video. Vous connaissez là aussi Recognition qui avait été lancé à Re:Invent en 2016, analysé de contenu visuel, et bien Recognition Video, c'est l'extension de ça à du contenu vidéo. Donc on est capable de faire de la reconnaissance faciale, du tracking, de la reconnaissance de scène, etc. Plus seulement sur des images, mais maintenant sur des vidéos, que ce soit en mode archive, en mode batch, ou que ce soit en mode temps réel, notamment avec l'intégration de Kinesis Video Streams. Mon service préféré, Amazon SageMaker. C'est un service destiné aux développeurs et aux data scientists qui souhaitent simplifier leurs travaux de machine learning. SageMaker va vous fournir différentes briques. La première, d'abord, ce sont des notebooks de l'infrastructure pour faire tourner vos notebooks, ce qui est toujours le point de départ d'un projet où on va commencer par explorer, etc. Ensuite, vous avez une bibliothèque d'algorithmes de machine learning sur étagère, qui sont des algorithmes qui ont été implémentés par Amazon. Et d'ailleurs, depuis le lancement de SageMaker, on en a rajouté déjà deux. Donc, il y a maintenant une bonne dizaine d'algos sur étagère pour faire de la classification, pour faire du clustering, pour faire des time series, pour gérer du traitement du langage naturel, etc. Donc voilà, ils sont déjà là, donc vous pouvez vous en servir. Vous pouvez aussi utiliser vos propres scripts, TensorFlow, MXNet, etc. Vous pouvez même amener votre propre librairie de training et de prédiction, si vous le souhaitez. Tout ça est encapsulé dans des containers Docker, donc vous pouvez amener votre propre container Docker avec votre propre code de machine learning et le déployer via SageMaker sur de l'infrastructure donc scalable pour faire du training, du training distribué et puis ensuite une fois que vous avez un modèle vous pouvez le déployer sur là aussi des instances managées et servir des prédictions à partir de cette instance. Donc c'est vraiment quand je dis que c'est mon service préféré c'est pas simplement parce que je m'occupe maintenant de sujets IA c'est vraiment je trouve c'est un service qui simplifie la vie où on passe très peu de temps à faire de la plomberie et beaucoup de temps à analyser et à comprendre ces données. Vous pouvez l'utiliser de bout en bout, du notebook jusqu'à la prédiction, mais vous pouvez aussi utiliser juste une partie de ce service. J'avais fait une vidéo sur YouTube décrivant très en détail SageMaker. Si vous cherchez sur YouTube Julien Simon SageMaker, je pense que vous allez la trouver. Et vous aurez plus de détails et de démos sur SageMaker si le machine learning fait partie de vos sujets. Et puis ensuite, on a continué à compléter la famille de services IA de haut niveau. Vous connaissiez Polly, Recognition. On a rajouté Transcribe, qui est l'inverse de Polly, qui va faire du Speech to Text. Donc retranscrire en texte des échantillons de voix avec la ponctuation, avec plein de choses. Le service est en preview mais il est testable et il va continuer à s'enrichir avec pas mal de fonctionnalités. Et bien sûr, nous continuerons d'ajouter des paires de langues. Tout cela s'utilise avec une seule API. Si vous avez utilisé Polly Recognition, vous savez à quoi vous attendre, c'est un appel d'API, il n'y a aucune difficulté et ça marche en temps réel. Un autre service, Comprehend, analyse des bases documentaires, peut analyser un unique document pour en extraire les entités, déterminer le langage, faire de l'analyse de sentiments, etc. Mais surtout, il peut analyser des ensembles de documents. Si vous avez 10 000, 20 000, 30 000 documents que vous voulez classer, dans lesquels vous voulez détecter des thèmes, Comprehend va vous aider. Il construit la liste des thèmes, détermine la liste des mots qui correspondent à chaque thème, puis classe les documents par thème avec des scores de confiance. Par exemple, un document peut parler de sport et de finance, comme dans le cas d'un transfert de joueur de football. Dans le thème sport, il y aura des mots comme équipe, joueur, football, etc. Et dans le thème finance, il y aura peut-être dollars, contrats, etc. Il construit les thèmes et classe les documents par thème. C'est un service entièrement managé. Tout ce que vous avez à faire, c'est mettre vos documents dans S3, lancer l'analyse, et attendre quelques minutes pour obtenir le résultat. Pour les personnes qui ont de très grosses bases de documents à analyser, c'est intéressant. Voici quelques mots sur l'Internet des objets où il y a eu un certain nombre de nouveautés. Nous avons lancé un service appelé IoT OneClick qui permet de déployer une fonction Lambda pour n'importe quel appareil en un clic, sans avoir à écrire de code. C'est une façon sympathique d'accélérer et de simplifier l'intégration entre le monde de l'IoT et le reste d'AWS via des fonctions Lambda. Un autre service, Device Management, vous permet de gérer des flottes d'appareils, de les configurer, de les rechercher, d'analyser leurs logs, de les surveiller, de les mettre à jour, etc. Lorsqu'on a déployé des milliers d'appareils, on n'a pas envie de faire ça à la main ou d'écrire une application pour le faire. Ce service vous permet de gérer vos flottes et de les mettre à jour. Un autre service, IoT Analytics, vous permet de faire de l'analyse sur les données remontées par vos équipements IoT. Il offre un ensemble d'outils pour traiter, filtrer et analyser les données, avec une intégration avec QuickSight pour faire des tableaux de bord et de la BI, ainsi qu'avec des notebooks Jupyter pour faire de l'analyse en Python et construire des modèles de machine learning avec SageMaker. Le dernier service IoT, Greengrass ML Inference, permet de déployer automatiquement des modèles de machine learning sur les appareils Greengrass. Avant, il fallait embarquer le modèle à l'intérieur d'une Lambda, mais maintenant, le modèle est défini comme une ressource propre au groupe Greengrass, ce qui facilite son déploiement et sa mise à jour. Cela permet d'utiliser le modèle pour faire des prédictions locales sur vos appareils IoT. FreeRTOS, qui n'est pas un service à proprement parler mais un OS temps réel open source, est maintenant géré par Amazon et peut être déployé sur vos appareils. Il est déjà supporté sur un ensemble d'appareils partenaires et peut être porté sur vos propres appareils, offrant un noyau temps réel qui s'intègre facilement avec les autres services AWS pour piloter vos appareils et la connectivité. Le dernier service dont je parlerai aujourd'hui est Sumerian, qui vous permet de créer des mondes et des personnages en 3D. Cela devrait intéresser les développeurs de jeux et de réalité virtuelle. Vous pouvez utiliser ces modèles sur différentes plateformes comme l'Oculus Rift, l'HTC, etc. C'est un service très spécifique mais très important pour les personnes travaillant en 3D. Si vous voulez plus de détails sur ces services, vous pouvez retrouver sur cette URL sur notre site le détail des annonces, y compris celles dont je n'ai pas parlé, ainsi que les billets de blog qui ont été faits à cette occasion. Il y a beaucoup plus de détails que ce que j'ai pu vous donner aujourd'hui, mais vous voyez qu'il y avait tellement de choses à dire que j'étais obligé de délaisser un peu. J'en ai fini donc pour ce second webinar, Hugo. Si on a des questions, allons-y et on va essayer de répondre. Les questions vont arriver. Donc voilà la page que je mentionnais à l'instant. Voilà, donc la liste de tous les services qui ont été lancés, les liens vers les blogs. L'URL est compliquée, mais voilà, c'est aws.amazon.com. Presque tout ce dont j'ai parlé aujourd'hui, et sans doute un peu plus, car je pense que j'en ai enlevé quelques-uns. Voyons un peu les questions. Il y a une question de Franck. J'ai dit qu'il y avait trois zones de disponibilité minimum par région, mais certaines régions en Asie n'en ont que deux. Le nouveau standard, c'est trois. Toutes les régions qui sortent maintenant en ont trois. La France en a trois, Stockholm en aura trois, etc. Quelques régions, notamment en Asie, n'en ont que deux, mais souvent, elles sont en cours d'upgrade. L'objectif est d'avoir au moins trois partout. Est-ce que j'ai une date de disponibilité pour lancer Kubernetes via EKS sur EU-West 3 ? Je ne suis pas sûr de comprendre la question. Parce que lancer un cluster EKS, on peut le faire. J'avais fait un webinar sur Kubernetes il y a quelques mois et j'avais lancé un cluster. Vous pouvez aujourd'hui, dans n'importe quelle région, créer des instances EC2 et utiliser EKS. EKS est encore en preview, donc on va devoir attendre un peu, mais je ne doute pas qu'on l'aura un de ces jours. Si la question est quand est-ce qu'on a EKS à Paris, je ne sais pas, c'est toujours une question un peu difficile. EKS est encore en preview, donc on va devoir attendre un peu, mais je ne doute pas qu'on l'aura un de ces jours. Est-ce que SageMaker utilise Nvidia Docker ? Et lorsque les algorithmes sont déployés, le backend est-il un GPU ? Lorsqu'on déploie un modèle sur SageMaker, on choisit le type d'instance sur lequel on l'entraîne. On peut prendre des instances CPU comme C4, C5, etc., et on peut prendre des instances GPU, comme P2, P3, en une ou plusieurs pour du training distribué. Donc, si on a dit qu'on voulait des instances GPU pour faire le training, et que tout ça tourne sur Docker, on peut raisonnablement imaginer que le job de training utilise Nvidia Docker pour accéder au GPU de l'instance sous-jacente. Je n'ai pas la preuve formelle, mais l'intuition me dit que c'est comme ça. Nous avons plein de questions du type : quand est-ce qu'on a le service X dans la région Y ? Je suis désolé, mais j'ai toujours le plus grand mal à répondre à ces questions. La logique veut que l'on ait tous les services à terme dans toutes les régions. Certains services, comme vous pouvez le voir sur la région France, sont disponibles dès le premier jour, et ce sous-ensemble continue d'augmenter. Si vous êtes client AWS, vous pouvez demander à votre contact, surtout si vous êtes une entreprise. Si vous êtes un développeur individuel, vous pouvez toujours faire la demande, mais vous comprenez que ça a moins de poids. Si vous êtes une entreprise et que vous avez un cas d'utilisation fort pour un service dans la région France, n'hésitez pas à contacter votre account manager et à lui demander explicitement d'avoir ce service. C'est son boulot de relayer cette info et de créer un ticket qui va rentrer dans la roadmap avec les informations sur votre use case. Plus de 90% de ce qu'on fait est lié à des demandes clients. Si suffisamment de clients insistent, ayant des vrais cas d'utilisation pour EKS à Paris, ou d'autres services, il faut insister, travailler avec nous pour définir le use case, remonter ça aux équipes centrales, et ça pèse dans la balance. Je pense qu'on a fait le tour des questions, sauf s'il y a des petites dernières. Hugo, je te laisse 30 secondes pour... Non, Hugo ne répond plus. Ok, je pense qu'on a fait le tour. Merci beaucoup d'avoir participé à cette nouvelle série de webinaires. J'espère que vous avez trouvé des éléments d'information utiles. Vous retrouverez les vidéos très rapidement en ligne sur YouTube. N'hésitez pas à consulter, à vous abonner à notre chaîne Amazon Web Services France sur YouTube pour avoir les notifications de ces nouvelles vidéos. On vous donne rendez-vous le mois prochain en février pour de nouveaux webinaires, sans doute autour du Big Data. Vous l'avez vu, ce n'est pas les sujets qui manquent, et on continuera à essayer de vous répondre à vos questions et vous apporter du contenu intéressant. Merci beaucoup, je vous souhaite une bonne fin de journée. Pour moi, elle ne fait que commencer, le ciel est toujours bleu sur Las Vegas. Ça va peut-être être l'heure d'aller prendre un petit café et de continuer à travailler. La journée n'est pas finie. Merci beaucoup, à très bientôt et n'hésitez pas à nous envoyer vos questions ou vos commentaires sur la chaîne YouTube. Ou évidemment, vous pouvez toujours me trouver sur Twitter, @julien_simon. Et j'adore répondre à vos questions et écouter vos idées. C'est la fin pour cette fois-ci, merci beaucoup et à bientôt.