Apercu des services Amazon Web Services

Transcript

Bonjour à tous. Avant de commencer, est-ce que vous pouvez me confirmer dans le chat que vous m'entendez bien, s'il vous plaît ? Qu'on n'ait pas de soucis. Si quelqu'un peut poster juste un petit message pour nous dire que tout va bien. Ok, c'est bon. Très bien, bienvenue dans ce nouveau webinaire AWS. Je vais me présenter très rapidement, je suis Julien Simon, je suis évangéliste technique chez AWS, je suis basé dans le bureau de Paris et donc j'ai le plaisir d'animer ce webinaire aujourd'hui sur les principaux services AWS et je suis accompagné de l'équipe marketing, qui organise toute la partie technique et logistique autour du webinaire. Aujourd'hui nous allons passer une petite heure ensemble, j'ai quelques slides à vous présenter sur les principaux services, mais j'attire votre attention sur le fait que nous avons conservé énormément de temps pour les questions, puisque nous avons vu dans les webinaires précédents qu'il y avait beaucoup de questions qui étaient posées par les participants, ce qui est très bien, mais ça prend du temps pour y répondre. Donc on devrait faire à peu près une demi-heure de présentation à la louche, et donc ensuite on a beaucoup de temps pour les questions. Donc si vous avez des questions d'ores et déjà, n'hésitez pas à les poser, Hugo va les noter, va les trier et puis j'y répondrai ensuite. Les questions peuvent porter sur ce que je suis en train de présenter à l'instant T ou si vous avez des questions générales sur AWS, si vous découvrez AWS, n'hésitez pas vraiment, cette session est faite pour vous, on a gardé du temps, profitez-en, posez toutes vos questions, je serai ravi d'y répondre. Très bien, on va commencer. Avant toute chose, il s'est passé quelque chose de sympathique, de très sympathique hier, puisqu'on a annoncé l'ouverture d'une région AWS en France l'année prochaine, ce qui veut dire que dès que cette région sera disponible, vous pourrez déployer vos plateformes, vos applications dans nos data centers basés en France. On est très heureux de l'annoncer, on attendait tous et nos clients évidemment aussi depuis un moment, donc on espère bientôt pouvoir vous donner une date un peu plus précise, mais en tout cas sachez que nous aurons des data centers en France, l'année prochaine. Dans cette présentation, je me suis volontairement restreint aux principaux services AWS. Aujourd'hui, la plateforme est composée de plus d'une cinquantaine de services que vous pouvez voir lorsque vous ouvrez la console AWS. Néanmoins, présenter les 50 nécessite un peu trop de temps. Aujourd'hui on va vraiment se concentrer sur les principaux services, ceux que vous utiliserez en premier lieu pour lancer vos applications, stocker vos données, etc. Sachez qu'il en existe plein d'autres, ça donnera lieu à d'autres webinaires. A tout seigneur, tout honneur, on va commencer par les services qui vous permettent de déployer du code et des applications, ce qu'on appelle chez nous les services de calcul ou compute, qui sont au nombre de 4, donc EC2 et son ami l'autoscaling, lambda, EC2 container service et Elastic Beanstalk. Le premier d'entre eux, c'est l'un des plus anciens services d'AWS et c'est l'un des piliers de notre plateforme, c'est le service qu'on appelle EC2, Elastic Compute Cloud. EC2, c'est le service de machine virtuelle d'AWS. L'idée est toute simple, vous allez choisir une image, une image Linux, une image Windows, vous allez choisir une taille d'instance, on a aujourd'hui plus d'une trentaine de tailles qui vont de toutes petites instances à des très très grosses. La plus grosse dont on dispose aujourd'hui a 128 coeurs, 2 Tera de RAM. Elle est vraiment gigantesque. Mais généralement, vous pouvez vous orienter vers des instances beaucoup plus petites qui auront peut-être 1 Giga, 2 Giga de RAM, quelques coeurs. Et ça suffira amplement pour travailler. Bref, vous pourrez choisir parmi cette trentaine de types d'instances. Vous positionnez quelques paramètres de sécurité, d'authentification, etc. Vous définissez quelques paramètres pour le stockage, les disques. Tout ça se fait vraiment très très simplement. Et puis vous lancez le serveur. Il va démarrer en une à deux minutes. Et une fois qu'il est démarré, vous pouvez vous y connecter. Donc si c'est un serveur Linux en SSH, si c'est un serveur Windows en RDP. Et puis vous avez la main sur ce serveur et vous en faites ce que vous voulez. Vous installez, vous êtes l'administrateur de cette machine et vous faites ce que vous voulez avec. Vous payez à l'heure, le tarif dépend évidemment de la puissance de l'instance que vous avez démarrée. Et donc quand vous arrêtez votre serveur, vous arrêtez de payer. Voilà. Comme tous nos services, EC2 fonctionne sur le principe du paiement à l'usage, ce qui vous permet d'éteindre les serveurs dont vous n'avez plus besoin, quitte à les relancer ensuite, évidemment, et à faire des économies. Bien souvent, ce service EC2 va être utilisé conjointement avec un autre service qu'on appelle l'autoscaling. Comme je le disais à l'instant, vous pouvez lancer et arrêter à la demande vos instances, ce qui vous permet d'adapter la taille de votre infrastructure à vos besoins. Mais ce qui est encore mieux finalement, c'est qu'un mécanisme le fasse automatiquement à votre place. Par exemple, si vous avez une plateforme web, on peut imaginer que vous avez un pic de trafic rentable en début de soirée et puis qu'ensuite au milieu de la nuit votre trafic est beaucoup plus faible. Par conséquent, vous avez davantage besoin de serveurs peut-être entre 19 et 21 heures et puis beaucoup moins entre minuit et 8 heures du matin. Et donc si vous devez gérer tout ça manuellement, c'est évidemment pas pratique et c'est tout là l'avantage de l'autoscaling qui, en fonction de métriques que vous allez définir, la charge CPU de vos serveurs ou le trafic réseau, que sais-je, l'autoscaling va redimensionner automatiquement à la hausse ou à la baisse le nombre de serveurs de votre plateforme. Ce qui vous permet de manière très réactive en quelques minutes, soit d'ajouter de la capacité pour encaisser du trafic supplémentaire, soit d'enlever de la capacité et de faire des économies. Donc ça c'est vraiment un des grands avantages du cloud computing, c'est la fameuse élasticité, l'adaptation permanente de l'infrastructure au besoin, au trafic. Et donc c'est avec l'autoscaling que vous allez le faire. C'est un mécanisme extrêmement utilisé chez nos clients. Maintenant, on a évidemment continué à réfléchir au sujet en se disant, certes, des machines virtuelles, des serveurs virtuels procurent un certain nombre d'avantages par rapport à des serveurs physiques, l'élasticité, l'absence de maintenance matérielle, etc. Néanmoins, ça reste des serveurs, ce qui veut dire que vous devez patcher vos operating systems, vous devez back-up vos serveurs, bref, il reste un certain nombre de charges d'administration système. Et dans certains cas, on aimerait s'en passer, sans doute dans la plupart des cas, on aimerait s'en passer. Et donc on a lancé, il y a un peu moins de deux ans maintenant, un service qui s'appelle Lambda, qui est un service entièrement managé, dans lequel vous ne gérez plus aucune infrastructure, vous ne faites que déposer des petits bouts de code, qu'on appelle des fonctions lambda. Vous pouvez le faire en Node.js, en Python ou en Java. Et donc ces petits bouts de code vont servir soit à réagir à des événements au sein de la plateforme, ça c'est dans une logique d'automatisation, de DevOps, etc. C'est extrêmement pratique. Et puis ils vont aussi servir à construire des applications. Généralement, le code d'une API est un morceau de code relativement court et en le combinant à un autre service dont je ne parlerai pas aujourd'hui mais qui s'appelle l'API Gateway, vous pouvez très facilement construire sans gérer la moindre infrastructure des API REST, donc en couplant des API créées par API Gateway avec des fonctions lambda. C'est vraiment un modèle complètement différent, le scaling est fait automatiquement, tout est fait pour vous simplifier la vue au maximum. Un autre avantage de lambda, c'est que vous ne payez qu'à l'invocation, c'est-à-dire lorsque votre code est réellement exécuté, lorsqu'il est invoqué par un événement, par une API, vous payez. Par contre, s'il n'y a pas d'invocation, vous ne payez pas, ce qui est un avantage par rapport à EC2, ou vous payez à l'heure que votre instance soit utilisée ou pas. Voilà, donc si vous développez des API, des web services, des choses comme ça, je vous incite à jeter un œil à Lambda, vous verrez c'est un modèle un petit peu nouveau mais en tout cas vraiment efficace et assez simple à mettre en œuvre. Troisième façon de déployer du code chez nous, c'est le service ECS, EC2 Container Service, qui vous permet, comme son nom l'indique, de déployer des containers Docker qui vont fonctionner sur un ensemble d'instances EC2, donc sur un cluster d'instances EC2. L'avantage de ECS, c'est qu'il va gérer ce cluster pour vous. Il va s'assurer que vous avez toujours le bon nombre d'instances dans le cluster. C'est lui qui choisira l'instance sur laquelle un container est déployé, etc. Évidemment, vous pourriez faire tout ça vous-même. Vous pourriez lancer vos propres instances EC2, installer Docker dessus, avoir un ordonnanceur, le faire vous-même, etc. Mais ECS se propose de le faire à votre place. Et donc finalement, là aussi, de vous décharger de ces tâches de maintenance de clusters qui peuvent être particulièrement compliquées. Nous vous proposons également un service complémentaire qui s'appelle ECR, EC2 Container Registry, qui est un registry Docker privé hébergé dans AWS, ce qui vous permet de placer vos images Docker au plus près de votre infrastructure et de les garder privés, ce qui n'est pas le cas si vous les poussez sur le Docker Hub ou sur d'autres systèmes. Voilà, donc si vous êtes un fan de Docker, mais que vous ne voulez pas gérer l'infrastructure sous-jacente, ECS est pour vous. Dernier service de déploiement de code, le fameux Elastic Beanstalk qui a été lancé il y a quelques années maintenant en 2011. Elastic Beanstalk, je l'aime beaucoup parce que c'est vraiment un service fait pour les développeurs qui souhaitent développer et déployer leurs applications web ou leurs workers sur de l'infrastructure cloud, mais une fois de plus sans gérer la plomberie, sans gérer l'infrastructure. Elastic Beanstalk fonctionne avec de nombreux environnements, vous envoyez une liste là, si vous voulez la liste complète vous la trouverez sur le site web, toutes les versions de Java, de PHP, etc. L'idée là c'est vraiment de ne fournir que votre code. Très concrètement, vous avez votre repository Git que vous clonez sur votre poste de travail, vous utilisez la ligne de commande Elastic Beanstalk et en une commande vous créez un environnement Beanstalk PHP 7, peut-être même avec une base de données si vous en avez besoin. Et puis avec une deuxième commande, vous y déployez automatiquement votre application. Et Elastic Beanstalk est capable de gérer le scaling, l'équilibrage de charge, enfin il y a tout un tas de services comme ça qui sont créés et lancés automatiquement par Elastic Beanstalk. Et vraiment en deux, trois commandes, vous pouvez créer une plateforme de production solide et y déployer votre application. J'insiste vraiment, si vous êtes développeur dans l'une de ces technologies, que vous voulez déployer dans le cloud et que vous ne voulez pas vous poser trop de questions d'infrastructure et vraiment vous concentrer sur votre développement, vraiment, vraiment, vous devez regarder Elastic Beanstalk. Pour moi, c'est le choix numéro un, le choix par défaut lorsqu'on veut déployer une appli web dans AWS. Si jamais vous avez une architecture ou des contraintes particulières qui font que Beanstalk ne vous convient pas, vous pouvez aller vers Docker ou d'autres solutions. Mais vraiment, je vous conseille de regarder en premier lieu Elastic Beanstalk. Passons maintenant au réseau, qui est évidemment une compétence importante de l'infrastructure. On va parler de trois produits, les VPC, les réseaux privés virtuels, les ELB, l'Ordbalancer, et le Route 53. Alors, j'ai toujours cette anecdote, je vous assure qu'elle est exacte. Un jour, quelqu'un m'a dit, moi le cloud public, je n'irai pas dedans parce que c'est public et donc tout le monde peut voir mes données. Alors, j'ai souri, je n'ai pas pu m'en empêcher, mais je lui ai expliqué que le cloud public, ce n'était pas le jardin public et que ce n'est pas parce qu'on était dans le cloud public que tout le monde voyait ce que tout le monde faisait. Le cloud est public parce que tout le monde peut s'en servir, il est ouvert au public. Maintenant, lorsque vous créez un compte chez nous, nous vous créons automatiquement un petit bout de cloud qui vous est dédié, c'est ce qu'on appelle le VPC. Ça va être un environnement réseau complètement isolé du reste, à l'intérieur duquel vous pouvez créer votre plan d'adressage, vous pouvez créer votre source, vous pouvez créer vos access list, vous pouvez créer vos gateway, NAT, vos VPN, etc. Bref, vous avez la main sur ce réseau, vous le contrôlez totalement et personne d'autre que vous ne voit ce qui se passe à l'intérieur. Aujourd'hui, j'insiste, c'est le réglage par défaut d'AWS. Quand vous créez votre compte, vous avez ce qu'on appelle un VPC par défaut qui est créé, dans lequel vous pourrez lancer vos instances, vos bases de données, etc. Bien sûr, vous pouvez créer d'autres VPC pour segmenter davantage encore votre infrastructure. Et vous pouvez connecter ces VPC au monde extérieur, à votre data center, à votre bureau, en utilisant par exemple un VPN. Voilà, donc le Ce n'est pas parce qu'on est dans le cloud que les concepts réseau sont extrêmement différents. En lisant la documentation du VPC, vous retrouverez tous les concepts familiers des réseaux IP. Le deuxième produit dont il est important de parler, c'est évidemment le load balancer. On a parlé tout à l'heure d'autoscaling, de la capacité de faire grossir ou diminuer automatiquement des groupes de serveurs. S'il s'agit de serveurs web, il est bien probable que devant vous aurez envie de mettre un load balancer pour que ce groupe de serveurs offre un unique point d'entrée à votre trafic, à vos internautes. Donc c'est le rôle de l'ELB qui vous permet d'équilibrer du trafic entre les serveurs sur des protocoles HTTP ou TCP. Donc le load balancer va tester en permanence le bon fonctionnement des instances, retirer une instance qui semble être en panne, éventuellement la faire re-rentrer dans le groupe si elle se remet à fonctionner. Et voilà, ça s'intègre très très bien avec l'autoscaling, comme je le disais à l'instant. Il suffit d'ajouter un ELB dans le groupe d'autoscaling pour que tous les nouveaux serveurs y soient automatiquement intégrés. Si vous avez besoin là aussi de faire grossir vos plateformes et que vous voulez cacher tout ça derrière un unique point d'entrée, c'est avec un ELB que vous le ferez. Dernier service réseau dont je parlerai aujourd'hui et qui est évidemment essentiel, c'est notre service de DNS qui s'appelle Route 53, 53 étant le numéro de port utilisé par le DNS. Ce service permet bien sûr de gérer et d'enregistrer des noms de domaines et de les assigner à des ressources AWS, des load balancers, des instances EC2, etc. Mais ça va au-delà. Dans Route 53, on a aussi des mécanismes de gestion de trafic. Je prends un seul exemple, c'est du latency based routing, c'est-à-dire la capacité à répondre à des requêtes DNS avec l'adresse IP de la ressource la plus proche de vous en termes de réseau. Je vais prendre un exemple, vous pourriez avoir une plateforme qui est déployée dans la région américaine, dans une de nos régions américaines, et puis également déployée dans une de nos régions européennes. Et servir du trafic au niveau mondial à partir de ces deux plateformes. Lorsqu'un internaute américain essaie de résoudre votre nom de domaine, Route 53 lui renverrait une adresse IP qui correspond à un load balancer probablement de votre plateforme américaine, puisqu'en terme de réseau c'est évidemment le plus proche. Et puis de manière identique, un internaute européen lui recevrait une IP d'une instance ou d'un load balancer basé en Europe puisque là aussi c'est là qu'il est plus près. Donc voilà, dans Route 53 vous avez tous ces mécanismes assez avancés, on n'est pas juste dans du DNS de l'enregistrement de noms, on est aussi dans la définition de politique de ce style pour que l'expérience de vos utilisateurs soit la plus fluide possible. Très bien, écoutez, on a vu le calcul, on a vu le réseau, il y a un autre gros morceau dont il est temps de parler, c'est le stockage. Donc là je vais parler de 4 services, EBS, S3, Glacier et CloudFront. Commençons par EBS. Alors EBS c'est un stockage de type bloc, pour ceux qui ont les familiarités avec l'infrastructure traditionnelle, ça s'approche d'un SAN. Et donc l'idée est toute simple, vous allez créer des volumes qui peuvent faire de quelques gigas jusqu'à 16 Tera. Et puis ces volumes, vous allez les attacher à des instances. Les instances vont les formater, stocker des données, travailler avec, etc. Et puis sans doute par la suite vous aurez envie de détacher ces volumes et peut-être d'arrêter les instances parce que vous souhaitez faire des économies, vous n'avez plus besoin de serveur mais par contre vous voulez garder les données sur ce stockage. Et lorsque vous aurez à nouveau besoin de démarrer des instances, vous pourrez à nouveau rattacher ces volumes à ces instances. Donc c'est un stockage qui est persistant, il y a différentes classes, vous pouvez avoir du stockage SSD, du stockage sur disque, vous pouvez avoir des niveaux de performance garantie, etc. Il y a tout un tas de paramètres. Mais voilà, ce qu'il faut vraiment retenir, c'est que c'est du stockage qui est décorrélé de EC2, qui s'attache à des instances EC2, mais qui persiste indépendamment du lancement ou des terminaisons d'instances EC2. C'est la bonne façon de stocker les données de manière pérenne pour qu'elles soient accédées au fil du temps par des générations d'instances différentes. Ensuite, vous pouvez avoir d'autres besoins. Vous pouvez avoir besoin de stocker des données qui ne sont pas directement accédées par les instances. Vous pouvez avoir des archives, des logs, des backups, des vidéos, enfin bon bref, tout ce qu'on peut imaginer de stocker. Et là, la destination idéale pour le faire, c'est un service qui s'appelle S3, que tout le monde connaît, ou presque, qui est un des services les plus anciens et les plus connus de l'histoire. S3 c'est une solution de stockage internet, vous y déposez des objets, la seule contrainte c'est qu'un objet ne peut pas dépasser 5 Teraoctets, ça devrait convaincre à la majorité des gens, c'est à peu près la seule limite qui existe dans S3, donc vous déposez vos objets via une API HTTP, puis vous les récupérez via une API HTTP. S3 est très fiable. Il est conçu pour avoir une durabilité de ce qu'on appelle de 11,9, donc 99,999999, etc. Ce qui veut dire concrètement que si vous aviez 100 milliards d'objets stockés dans S3, peut-être, je dis bien peut-être, vous en perdriez un par an. Donc ça vous donne une ordre d'idée de la fiabilité. S3 est également conçu pour être hautement disponible. Il est conçu pour être disponible au moins à 99,99%. Et enfin, un des gros avantages d'S3, c'est qu'il est extrêmement peu onéreux puisque le tarif en Europe est de 3 centimes de dollars, 3 cents, par giga par mois. Donc vous voyez, vous avez un service sur lequel vous ne gérez aucune infrastructure, vous vous contentez de déposer des fichiers, sur un endpoint qui vous est fourni. Et c'est tout. Ces données resteront jusqu'à la fin des temps et vous coûtent au maximum 3 cents par giga par mois. Donc vraiment, si vous avez des gros volumes de données à stocker, si vous voulez ne plus vous inquiéter de la place disponible, S3 est la bonne solution. Au-delà d'S3, on peut aussi avoir envie de stocker des données à très long terme sans qu'il soit nécessaire d'y accéder fréquemment. S3, c'est du stockage en ligne, donc tout reste disponible instantanément. Mais vous avez d'autres besoins, par exemple je pense à l'archivage légal ou à des sujets comme ça, ou de l'archivage à très long terme, 10 ans, 15 ans, etc. où vous voulez conserver des données mais il est vraiment extrêmement peu probable que vous y accédiez. Auquel cas vous pouvez utiliser Glacier qui est un service d'archivage où les données ne sont plus instantanément disponibles, elles sont restaurables sous 3 à 4 heures mais elles sont archivées avec les mêmes contraintes de durabilité que S3. L'avantage de Glacier c'est qu'il est évidemment nettement moins cher qu'S3. Donc si vous avez des données que vous devez conserver mais sans avoir besoin d'y accéder instantanément, je vous conseille de vous tourner vers Glacier, vous ferez une économie importante. Et puis dernier service de stockage pour aujourd'hui, le service CloudFront qui est un CDN, Content Delivery Network, qui dispose aujourd'hui 52 points de présence, je crois que ce chiffre est déjà obsolète, il me semble qu'on est déjà à 54 ou 56, donc 56 points de présence dans le monde, à partir desquels CloudFront va servir à vos internautes du contenu statique, donc des images, des vidéos, des CSS, du HTML, du JavaScript, etc., donc une grosse partie de votre site web. Et où il va pouvoir également cacher du contenu dynamique. L'avantage de CloudFront, c'est l'avantage de tous les CDN, c'est de servir ce contenu au plus près de vos utilisateurs, de réduire la latence et d'offrir une meilleure expérience client. CloudFront est facile à configurer, c'est un service qui se déploie vraiment en 5 minutes. Si toutes les données statiques sont données en S3, vous créez une distribution CloudFront à partir de ces données, vous choisissez les zones géographiques dans lesquelles vous voulez déployer les fichiers, vous attendez un petit peu que les données se diffusent et c'est parti. Il n'y a vraiment pas besoin d'être un expert CDN pour utiliser CloudFront et si vous avez des sites web qui servent du contenu partout dans le monde, CloudFront peut vous offrir un gain de performance assez important. Il nous reste une dernière grosse catégorie à couvrir. On a vu le calcul, on a vu le réseau, on a vu le stockage. Évidemment, il reste les bases de données, le sujet favori de tout le monde. Et là, on va parler de RDS, DynamoDB, Elastic Cache et Redshift. Alors, RDS, comme son nom l'indique, c'est un service managé pour les bases de données relationnelles. Vous allez pouvoir, en un appel d'API ou en un clic, créer une instance ou même un cluster basé sur l'un des moteurs indiqués ici, soit open source, MySQL, Postgre, MariaDB, soit commercial avec SQL Server ou Oracle, soit avec Aurora qui est une réimplémentation de MySQL faite par AWS et qui est extrêmement scalable. Qui a des performances aussi bonnes que les moteurs commerciaux mais à une fraction du prix. L'avantage des RDS c'est de ne pas gérer, une fois de plus, les instances et de ne pas gérer les bases de données. Vous n'avez pas à les backuper, ça RDS peut le faire pour vous, vous n'avez pas à les upgrader, RDS peut faire pour vous les montées de version mineure. Là où disponibilité, vous n'avez pas non plus à la configurer, elle est gérée automatiquement par RDS. Toutes les applications aujourd'hui ont besoin de bases de données, mais pour autant on a envie de se concentrer sur la conception de l'application elle-même, on n'a pas forcément très envie de jouer à l'administrateur de bases de données. L'objectif d'RDS c'est ça, c'est d'être votre DBA et d'automatiser et de vous décharger de toutes ces tâches d'administration qui sont importantes mais qui ne créent pas forcément de valeur pour votre application. RDS est vraiment le meilleur ami du développeur de ce point de vue là. Vous pouvez également avoir besoin de bases de données non relationnelles, le fameux NoSQL. Dans ce cas, vous vous tournerez vers ce service DynamoDB. DynamoDB, c'est là aussi un service managé, vous ne gérez pas d'infrastructure. DynamoDB est une base de données NoSQL, extrêmement rapide, puisque les écritures, les lectures et les écritures sont typiquement faites en moins de 10 millisecondes. Les données sont répliquées, persistées, et surtout, DynamoDB est extrêmement scalable. Vous pouvez passer de quelques lectures, écritures secondes, à potentiellement un million ou plus de lectures, écritures secondes. Le tout, j'insiste, en ne gérant absolument aucune infrastructure. Tout ce que vous vous contentez de faire, vous créez vos tables, vous définissez vos clés de partitionnement, et puis vous faites put et get sur vos items. Vous pouvez faire quelques requêtes également, simple. Et c'est tout. C'est vraiment une solution hyper facile à mettre en œuvre pour gérer des données non structurées, des données de session, des cookies, etc. Sans avoir à gérer, à déployer des solutions et de la haute disponibilité complexe. Autre produit disponible, ElastiCache. Donc ElastiCache, là aussi comme son nom l'indique, est un produit qui va gérer des clusters de cache. Aujourd'hui nous supportons Memcached ou Redis. Et un petit peu comme dit un mot DB, tout ce que vous allez faire c'est créer en un clic votre cluster Memcached ou votre cluster Redis. Et puis le service va vous fournir un endpoint à partir duquel votre client Memcached ou votre client Redis va se connecter et puis lire ou écrire des clés et les intégrer directement dans votre application. Voilà, donc c'est toujours la même idée, c'est vraiment simplifier la vie des développeurs et des architectes, gérer l'infrastructure sous-jacente et vous décharger des tâches d'administration de ces systèmes, pour vous permettre de ne faire que du développement, que du produit et de la création de valeur. Le dernier dont je vais parler aujourd'hui, c'est Redshift. J'adore Redshift, c'est un de mes produits préférés aussi. Redshift, c'est l'entrepôt de données, le Data Warehouse d'AWS. L'avantage du Redshift, c'est qu'il est super simple à mettre en œuvre. J'espère faire un webinaire Redshift bientôt pour vous le montrer, mais vraiment on peut créer un cluster Redshift en 5 à 6 minutes et déposer des données et commencer à faire des analyses. L'avantage de Redshift c'est qu'il est compatible avec le SQL Postgre et donc vous n'avez pas à apprendre de nouveaux langages ou de nouveaux environnements pour faire du Data Warehouse à l'échelle. Si vous savez faire du SQL, vous saurez faire des analyses avec Redshift. Un autre avantage de Redshift, c'est qu'il est capable de scaler très très haut. Nous avons des clients qui utilisent Redshift très très au-delà du pétaoctet. Et donc cette croissance, ce redimensionnement de clusters peut se faire progressivement sans interruption de service. Il est extrêmement compétitif. On peut arriver à des tarifs avoisinant 1000 dollars par teraoctet par an. Alors, ça ne parle peut-être pas beaucoup de vie comme ça, mais comparer ça avec des autres offres du marché, vous verrez que c'est effectivement un coût extrêmement raisonnable. Voilà, il est compatible avec ODBC et JDBC, ce qui veut dire que vous pouvez utiliser tous vos outils de développement, vos outils d'analyse sans avoir à les changer. Donc vraiment Redshift c'est le côté, le sujet Data Warehouse est souvent un sujet un peu compliqué, lourd, fatigant, pénible, mais vraiment Redshift le rend simple une fois de plus, si vous savez faire du SQL, c'est bon, vous saurez utiliser Redshift et vous pourrez manipuler des teraoctets, voire plus de données sans difficulté. Vraiment un très très bon service pour l'analyse de données. Il en reste deux, je me suis senti obligé d'en parler, puisque le premier c'est IAM, c'est un service qui tourne autour de la sécurité, sujet important, et le deuxième est CloudWatch, qui concerne le monitoring, qui est là aussi un sujet important. Ce sont les deux derniers produits dont je parlerai aujourd'hui. Ensuite, on passera aux questions. Alors, IAM, c'est le service qui va gérer toutes les permissions et tous les droits d'accès au sein de votre plateforme. Donc, permissions et droits d'accès pour les utilisateurs humains, les administrateurs système, les développeurs, etc., que vous pourrez également grouper. Et aussi, et j'ai envie de dire surtout, les permissions pour les briques de la plateforme elle-même. Ce qu'il faut bien comprendre, c'est que dans AWS, la sécurité est essentielle, et par conséquent, la règle par défaut, c'est, je le répète souvent, rien n'a accès à rien. Donc si vous voulez qu'une instance EC2 puisse accéder à S3, par exemple, il faut qu'elle en ait le droit. Si vous ne lui donnez pas le droit de le faire, cette instance ne pourra pas accéder aux objets qui sont stockés dans S3. Donc c'est vraiment un point important à retenir et c'est souvent quelque chose qui bloque et qui déroute les débutants. Ils essayent de faire des choses et puis ils sont coincés, ça ne marche pas. C'est souvent à cause d'un problème de permission. Donc à chaque fois que vous voulez interconnecter des services au sein d'AWS, vous devez vous poser la question de qu'est-ce que je dois configurer dans IAM. Et la plupart du temps ça passera par un rôle, donc un rôle c'est un ensemble de permissions que vous allez associer à une ressource AWS, par exemple à une instance EC2. Je reprends mon exemple de tout à l'heure. Pour qu'une instance EC2 puisse accéder à S3, il faudra que vous ayez attaché à cette instance un rôle qui contient les permissions d'accès en lecture et ou en écriture pour S3. C'est un exemple parmi les milliers, mais celui-là est assez simple. D'accord ? Donc j'insiste, posez-vous bien la question des permissions, passez un peu de temps à lire la doc IAM, tout va s'éclairer, du moins je l'espère, et que vous ne serez pas bloqué. Alors IAM va aussi gérer des choses plus compliquées, les fédérations d'identité si vous voulez intégrer vos permissions IAM avec un annuaire d'entreprise, un Active Directory, un système de type SSO, etc. Vous pouvez aussi le faire avec IAM. C'est des sujets plutôt avancés, on ne va pas trop s'y lancer aujourd'hui. Et puis CloudWatch, c'est la technologie de monitoring d'AWS qui va vous permettre de consulter tout un tas de métriques, de graphes qui dépendent de telle ou telle ressource. Sur EC2, vous verrez le CPU, vous verrez le trafic réseau, vous verrez les entrées-sorties disques, etc. Il y a tout un tas de choses qui sont déjà paramétrées. Sur RDS, vous verrez d'autres choses. Sur Dynamo, vous verrez encore d'autres choses. Il y a tout un tas de métriques, de graphes qui sont préconfigurées et qui vous permettent de voir dans quel état sont vos plateformes et vos applications. Une autre fonctionnalité importante de CloudWatch, c'est vraiment l'aspect supervision et alarme, puisque vous pourrez définir des seuils sur telle ou telle métrique et au-delà ou en deçà desquels des alarmes seront envoyées. Par exemple, vous pourrez définir une alarme sur la charge CPU de tel ou tel serveur qui, lorsqu'elle dépasse par exemple 90%, envoie une notification qui peut être un SMS, un email ou un message envoyé dans une file de messages. Ou bien encore une notification envoyée à un autre service AWS, comme par exemple l'autoscaling. C'est comme ça que fonctionne l'autoscaling. Ce n'est pas juste des jolis graphes et des métriques, c'est aussi une façon d'automatiser tout un tas d'actions au sein de votre plateforme pour s'assurer qu'elle est toujours en capacité de traiter le trafic et la charge de travail qu'elle doit traiter. Si vous voulez en savoir plus et essayer tout ça, je vous dirige vers cette page de notre site, Getting Started, qui est vraiment le bon point d'entrée pour débuter sur AWS, avec tout un tas de tutoriels très simples, très concrets, qui vous mettront les mains dans le cambouis tout de suite, et vous permettront de jouer avec les principaux services tout de suite. La deuxième chose que je voulais mentionner, c'est ce que vous voyez sur la partie droite du slide, ce qu'on appelle le Free Tier, le niveau d'usage gratuit, qui est un niveau d'usage gratuit sur la plupart des services AWS pendant les 12 mois qui suivent la création de votre compte. Vous verrez tous les détails sur cette page. Donc très concrètement, ça veut dire que lorsque vous créez votre compte, jusqu'à un certain niveau d'usage, EC2, S3, RDS, etc., vous pouvez utiliser les services absolument gratuitement. D'expérience, ça permet de se former, ça permet de commencer à jouer un petit peu, ça permet de faire des prototypes, etc. Ça ne permet pas de faire de la production. Vraiment à toute petite échelle, mais en tout cas c'est vraiment très bien en phase de formation, en phase d'expérimentation. Donc là aussi mon conseil c'est quand vous jouez avec EC2, RDS, etc., assurez-vous que vous restez bien au sein du free tier. Généralement, le service lui-même au moment où il va vous demander la confirmation de création de ressources EC2, de RDS, etc., il va vous alerter, il va vous dire attention, si vous faites ça, oui, il n'y a pas de problème, mais vous n'êtes plus dans le free tier. Après, vous payez à l'usage. Lorsqu'il s'agit de se former ou d'expérimenter, ça ne vous coûtera jamais très cher. On parle de quelques fractions de dollars. Pensez bien à tout arrêter une fois que vous avez terminé. Mais en tout cas, il y a moyen de rester dans ce niveau d'usage gratuit très longtemps et vraiment de se former tranquillement et découvrir tranquillement AWS sans que ça vous coûte quoi que ce soit. Si vous voulez en savoir plus sur AWS, évidemment vous trouverez plein d'informations en ligne. Nous avons aussi des groupes d'utilisateurs dans plusieurs villes françaises, donc vous voyez la liste. Il y a aussi des groupes à l'étranger, vous les trouverez sur notre site web. Si vous ne les trouvez pas, envoyez-moi un petit mail. Mais voilà, en Europe et ailleurs, on a beaucoup de groupes d'utilisateurs, ce qui permet de participer à ces meet-up et de rencontrer d'autres utilisateurs, d'écouter des retours d'expérience, c'est assez sympa. On a un groupe également sur Facebook qui commence à grossir un petit peu. AWS Actu, c'est le Twitter officiel d'AWS en France. Voilà, j'ai fini ma présentation. Je vous remercie beaucoup d'avoir écouté. J'espère que vous avez appris plein de choses. Et je pense qu'on va pouvoir passer aux questions. Alors je vous demande juste quelques secondes de synchronisation avec Hugo pour voir un peu ces questions, et puis on va commencer à y répondre. On a une première question de Julie. Merci Julie. Pour la sécurité, est-ce qu'il est conseillé d'intégrer un annuaire à IAM ou est-ce qu'il vaut mieux créer des utilisateurs directement dans IAM ? Ça dépend. Si vous bossez dans une entreprise de 2000 personnes avec 150 administrateurs système, il vaut mieux intégrer l'Active Directory à IAM pour s'assurer d'une part que vos admins ont les pouvoirs d'admin sur AWS et puis que vos utilisateurs métiers ont les credentials pour accéder à telle ou telle application ou tel ou tel service. C'est vraiment une question de taille. Parfois, vraiment dans les entreprises organisées avec des grosses équipes, vous n'aurez pas le choix, c'est-à-dire que vous aurez un chief security officer ou quelqu'un comme ça qui vous dira, il n'est pas question que les comptes, il faut que la gestion des credentials soit 100% centralisée. Donc on crée les gens une fois dans l'Active Directory et puis de ça découle leur permission Active Directory et leur permission IAM. Si c'est là que vous gérez vos permissions, intégrez-le avec IAM. Si votre infra AWS en pratique, elle est gérée par deux ou trois personnes et que le reste de vos utilisateurs se connectent uniquement à des sites web et à des choses comme ça qui gèrent leur propre authentification, là effectivement il n'y a pas de raison d'aller intégrer l'Active Directory. L'intégration n'a de sens que si les utilisateurs de l'Active Directory doivent eux aussi explicitement manipuler des ressources AWS. C'est vraiment une question de taille d'équipe. Pour des startups, des petites équipes, non. Pour des grosses boîtes, oui. Et d'autant plus que vous n'aurez probablement pas le choix. Peut-on filtrer les adresses IP qui ont accès à mon instance ? Bonne question. La sécurité des flux est assurée par deux choses différentes. La première chose, c'est ce qu'on appelle les access list du VPC. Si vous avez déjà joué avec des équipements réseau, je parle d'access list où en fonction de l'IP source, du port source, de l'IP destination, du port destination, on va autoriser ou interdire. Donc on peut faire ça dans les VPC. On peut dire que seules les IP de telle range ont accès à tel subnet ou à telle adresse IP dans le subnet, et à contrario on peut interdire à tel range d'IP de se connecter à telle ou telle partie du subnet. Si vous devez filtrer sur des IP, il faut le faire avec les access list. La deuxième entité qui permet de gérer la sécurité, c'est ce qu'on appelle les security group. Vous allez gérer la sécurité non pas au niveau réseau mais au niveau de l'instance. Le Security Group va vous permettre d'ouvrir des ports, c'est tout ce qu'il fait. On ne peut pas interdire avec le Security Group, on ne peut qu'ouvrir. Si vous voulez autoriser sur un serveur web du trafic entrant, vous allez ouvrir le port 80 et vous allez a priori l'ouvrir pour tout le monde. La règle à retenir c'est que si vous devez interdire, il faut le faire avec des access listes. Si vous devez filtrer au niveau réseau, vous le faites avec des access listes. Si vous voulez ouvrir, ou à contrario, fermer des ports sur telle ou telle instance, il faut le faire avec des security group. Est-ce qu'on peut changer le type de l'instance une fois qu'elle est démarrée ? Oui, on peut tout à fait changer le type de l'instance. Comme je disais tout à l'heure, au moment où vous lancez une instance, vous choisissez le type, sa taille, mémoire, son nombre de cœurs, etc. Mon conseil est de toujours commencer avec les plus petites possibles parce que ce sont les moins chères. Et bien sûr il peut arriver que le trafic augmentant, vous ayez besoin de plus de puissance, plus de mémoire, plus de stockage, etc. Et donc dans ce cas-là, il est tout à fait possible dans la console d'arrêter l'instance, donc pas de la détruire, de l'arrêter, de changer son type et de la redémarrer. Bien évidemment, prenons le cas d'une application web, si vous aviez un seul serveur web, au moment où vous faites cette manip, vous avez une interruption de service. C'est logique, vous arrêtez le serveur et vous le redémarrez. Ça ne prend que quelques minutes, mais c'est quand même une interruption de service. Si vous voulez le faire sans interruption de service, typiquement c'est là que vous allez utiliser un load balancer, minimum il faudrait deux serveurs derrière ce load balancer, que vous arrêtez et redimensionnez à tour de rôle. Au moment où vous arrêtez l'instance, le load balancer va le voir, il va sortir le serveur du pool, vous changez sa taille, vous redémarrez le serveur, le load balancer le redétecte, il revient en service, et puis ensuite vous faites la deuxième instance. Si vous en avez 30 à faire comme ça, vous pouvez même l'automatiser avec un script, une ligne de commande, etc. Ok, donc c'est tout à fait faisable. Pouvez-vous nous parler de la facturation RDS ? Oui. RDS est basé sur des instances. Et donc, lorsque vous créez un cluster RDS, un peu comme dans EC2, vous avez différentes tailles. Et le prix des instances varie en fonction de leur taille. C'est un peu le même principe que pour EC2. Au bout des un an d'utilisation gratuite, est-ce que les ressources sont automatiquement stoppées ou facturées ? Ah, oui, ça c'est une bonne question. On ne coupe jamais. On fait tout notre possible pour offrir la meilleure disponibilité possible, ce n'est pas pour arrêter sauvagement les ressources et les serveurs de nos clients. Donc effectivement, si au bout d'un an, le niveau d'usage gratuit, le free tier n'est plus là, et donc si vous aviez des ressources qui étaient couvertes par le free tier et que le free tier expire, à ce moment-là, elles commenceront à être facturées au tarif normal. On ne jette rien, on n'interrompt rien, on ne détruit pas votre compte, simplement on commence à facturer à l'usage en fonction de ce que vous utilisez, tout simplement. Y a-t-il des régions à privilégier où les produits sont-ils disponibles plus rapidement ? On a aujourd'hui 13 régions dans le monde. Pour l'Europe, on a l'Irlande et l'Allemagne, Francfort. Il y a Londres et Paris maintenant qui arriveront l'année prochaine. On a des régions en Amérique du Nord, en Amérique du Sud, en Australie, en Asie, etc., en Chine, etc. Et donc vous pouvez déployer à l'identique dans n'importe laquelle de ces régions. Cependant, lorsque les nouveaux services sont lancés, ils ne sont pas forcément disponibles dans toutes les régions dès le lancement. Sur notre site web, il y a une carte des services par région, qui vous indique précisément région par région, est-ce qu'un service est disponible ou pas. On a des régions de référence, en particulier aux US, la région qui est sur la côte est, qu'on appelle US East One, qui est la plus ancienne région AWS, dans laquelle tous les nouveaux services sont systématiquement lancés. Pour l'Europe, à l'heure actuelle, cette région de référence c'est l'Irlande, qui s'appelle EU West One, qui était la première région en Europe. Donc là aussi, tous les nouveaux services, ou presque, il est vraiment rare qu'un service ne soit pas lancé dans la région irlandaise. Pour les utilisateurs européens, lorsque vous voulez tester un service, allez voir dans la région irlandaise, il y a plus de chances qu'il s'y trouve que dans la région allemande. S'il ne s'y trouve pas, si vraiment il ne s'y trouve pas, à ce moment-là vous allez dans US East One et puis là par contre vous êtes sûr de trouver tous nos services. J'ai une instance avec une partition de 100 gigas et que j'arrête l'instance, est-ce que je paye le stockage de 100 gigas ou non ? Ah oui, ça c'est une question intéressante. On a parlé d'EBS tout à l'heure, il y a EC2 et EBS, EC2, la machine virtuelle, qui a un peu de stockage, mais qui ne sert qu'un stockage éphémère, qui sert juste au démarrage de l'instance, et EBS qui est vraiment le stockage de travail, le stockage pérenne. Donc, lorsque vous arrêtez une instance EC2 à laquelle un volume EBS est attaché, vous cessez de payer pour l'instance EC2, puisqu'elle est arrêtée. Par contre, le volume, lui, comme je vous l'ai expliqué tout à l'heure, le volume continue à exister, et donc vous continuez effectivement à payer pour ce volume. Il faut bien différencier EC2, où on paye à l'heure, et on arrête de payer lorsque l'instance est arrêtée, et puis EBS, où lorsque vous payez au giga octet tant que le volume existe. Maintenant le coût d'un volume EBS est faible, on a différentes classes de stockage, les prix varient entre les SSD et les autres technos, etc., mais bon c'est pas par rapport au prix de l'instance, c'est effectivement assez faible. Qui gère la montée des versions des images une fois que nous l'exploitons ? Lorsque vous lancez une instance, vous choisissez une image. Lorsque l'instance a été lancée, lorsqu'elle tourne, se pose la question de la maintenance de cette image, de cette OS. Vous êtes responsable de la maintenance de cette OS. Nous n'avons absolument pas ni la main ni la visibilité sur ce que vous faites à l'intérieur de vos machines virtuelles. Prenez le cas de Linux, c'est à vous, ou de Windows c'est pareil, c'est à vous d'appliquer les patchs, c'est à vous de faire en sorte, via le package manager de l'OS, d'appliquer les mises à jour sur cette OS. Dans le cas de Linux par exemple, on vous propose un Linux maintenu par nous, il s'appelle Amazon Linux, on a nos repositories, ils sont très réactifs, lorsqu'il y a des updates de sécurité, elles sont poussées très vite dans nos repositories, etc. Tout est disponible très vite, maintenant c'est à vous de les appliquer, c'est à vous régulièrement de faire l'update des nouveaux packages. La maintenance des OS lancée dans les instances, c'est à vous de le faire. En revanche, les images elles-mêmes sont rapidement rafraîchies périodiquement. Dans le cas d'Amazon Linux, bon an, mal an, tous les trimestres, vous avez une nouvelle version. Et puis, quand il y a des nouvelles versions de Windows, là aussi, on met nos images à jour. Mais attention, on met l'image à jour, mais on ne met pas les machines virtuelles à jour. Si vous avez lancé un Amazon Linux il y a 6 mois, il tourne sur la version d'il y a 6 mois. Si vous voulez utiliser la nouvelle version Linux, vous devez utiliser une nouvelle machine virtuelle avec la nouvelle version de Linux qu'on a mise à disposition. La bonne façon de faire ça, c'est d'avoir un load balancer, d'avoir plusieurs serveurs, et puis vous les arrêtez un par un, vous les relancez avec la nouvelle image, et puis vous réattachez les volumes EBS qui étaient sur les anciennes instances et vous êtes reparti. Si vous en avez trois, vous pouvez le faire à la main, si vous en avez 150, vous allez le scripter avec notre ligne de commande ou nos SDK. La responsabilité de ce qui se passe sur l'instance, c'est vous. Nous mettons à jour les images régulièrement. Vous devez relancer vos VM avec les nouvelles images. Comment visualiser toutes les instances qui tournent sur mon compte ? Ça va me permettre de vous expliquer comment on interagit programmatiquement avec AWS. Ce qu'il faut savoir, c'est qu'il y a toujours trois façons de faire les choses. La première, c'est dans la console, sur notre console web. Vous vous loguez, vous cliquez, vous vous promenez dans les services et vous voyez tout ça. La restriction de la console, c'est que la console est régionale. Lorsque vous êtes connecté dans la console, vous ne voyez les ressources que dans une seule région. Si vous avez lancé des trucs un peu partout, ce qui m'arrive souvent parce que je fais des démos et j'aime bien utiliser les différentes régions, ce n'est pas très pratique de se promener dans toutes les régions avec la console et de voir ce qui a été lancé, ce qu'il faut éteindre, etc. La deuxième façon de faire les choses chez nous, c'est avec la ligne de commande. Dans le shell, vous utilisez la ligne de commande AWS qui va vous permettre d'appeler toutes nos API et donc de scrypter tout un tas de choses. Généralement, la région est un paramètre de cette ligne de commande. En prenant la liste des régions, vous pourriez en l'occurrence appeler l'API DescribeInstances sur chacune des régions et listez toutes les instances qui tournent partout dans votre compte, partout dans toutes les régions AWS. Et puis la troisième façon de le faire, c'est de le faire programmatiquement avec un des SDK. AWS vous propose des SDK dans la plupart des langages. Et donc là aussi, vous pouvez, à l'aide d'un SDK, appeler toutes les API AWS, et puis au sein de vos applications, par exemple, appeler la même API DescribeInstances, dans votre langage favori, et obtenir ces informations. La console, plutôt pour expérimenter, la ligne de commande plutôt pour le DevOps et l'administration système et puis les SDK pour les applications ou alors l'automatisation mais de plus haut niveau. Il nous reste 30 secondes. Tant que Hugo ne me fait pas des grands signes, je continue. C'est bon ? Oui, donc je crois que Hugo a partagé avec vous la présentation, le PDF des slides. Voilà, écoutez, je ne vois pas de nouvelles questions. Je pense qu'on va en rester là. Je vous remercie beaucoup d'avoir participé. J'espère vous avoir éclairé sur les principaux services AWS. Je vous remercie pour toutes les questions qui m'ont permis de compléter ma présentation. Nous aurons d'autres webinaires au mois d'octobre. Le 18 octobre, je crois que c'est sur les problématiques de migration de données dans AWS et le 19 octobre sur le modèle de sécurité AWS qui est un vaste sujet. Vous trouverez sur notre site aws.amazon.com, sur notre site français, une page dédiée à tous nos événements. Je vous invite à la consulter régulièrement. Vous y trouverez toutes les informations sur nos événements, nos salons en France et en province, tous les webinaires, et vous serez sûr de ne rien rater. Et puis bien sûr, je vous invite à me suivre sur Twitter ou à suivre AWS Actu, ou les deux, pour être parfaitement au courant de tout ce qui peut se passer chez AWS en France. Écoutez, il ne me reste plus qu'à vous remercier une dernière fois, à vous souhaiter un excellent week-end et je vous donne rendez-vous au mois d'octobre pour de prochains webinaires. Merci beaucoup et à bientôt.