Principaux services AWS

EC2, Amazon Elastic Compute Cloud, fournit une capacité de calcul redimensionnable, c'est-à-dire des serveurs virtuels. S3, Amazon Simple Storage Service, permet de stocker n'importe quelle quantité de données sous forme d'objets. Confondre ces deux services est une erreur fréquente et ancienne ; il est utile de se souvenir du rôle de chacun à partir de son nom. Celui qui exécute le code de fonctions est Lambda, et celui qui partage des fichiers est EFS.

Lambda permet d'exécuter du code sans provisionner ni gérer de serveurs, et la facturation ne porte que sur le temps de calcul consommé. L'absence de facturation lorsque le code n'est pas en cours d'exécution constitue la grande différence avec EC2, où des frais s'appliquent tant que l'instance tourne. Ni le nombre de fonctions créées ni la taille du code téléversé en eux-mêmes ne servent d'unité de facturation.

« Sans serveur » ne signifie pas qu'il n'existe aucun serveur physique, mais que le client n'a pas besoin de provisionner, configurer ou faire évoluer les serveurs. Lambda est décrit comme permettant « d'exécuter du code sans provisionner ni gérer de serveurs », et Fargate est décrit comme ne nécessitant « aucun provisionnement, configuration ni mise à l'échelle de serveurs ou de clusters ». Le serveur physique se trouve du côté d'AWS, et déterminer le type de système d'exploitation ou la politique d'application des correctifs relève d'une approche comme EC2.

Fargate est un moteur de calcul serverless facturé à l'usage pour les conteneurs, ne nécessitant aucun provisionnement, configuration ni mise à l'échelle de serveurs ou de clusters ; on l'utilise comme type de lancement pour ECS ou EKS. L'exploitation managée de Kubernetes est assurée par EKS, le choix du type d'instance et de leur nombre par soi-même correspond au type de lancement EC2, et la définition des étapes sous forme de workflow correspond à Step Functions.

Les options de capacité d'ECS reposent essentiellement sur deux choix : Fargate, serverless, où AWS gère l'infrastructure, et EC2, où le client choisit et gère lui-même le type d'instance et leur nombre. Il existe aussi ECS Managed Instances, et ECS Anywhere pour l'infrastructure sur site. Quel que soit le choix, c'est ECS qui assure le placement et la mise à l'échelle des conteneurs ; ce qui change, c'est uniquement qui prend en charge la gestion de l'infrastructure.

EKS, Amazon Elastic Kubernetes Service, est un service managé qui permet d'exécuter Kubernetes sur AWS sans avoir à installer ni exploiter soi-même un cluster Kubernetes, et il est certifié conforme à Kubernetes. L'automatisation de l'exploitation d'une base de données est assurée par RDS, la diffusion de contenu depuis un point proche par CloudFront, et la répartition du trafic par Elastic Load Balancing.

Lambda permet d'exécuter du code sans gérer de serveurs, et la facturation ne porte que sur le temps de calcul consommé ; aucun frais n'est engagé pendant les périodes où rien ne s'exécute. Pour un traitement déclenché de manière peu fréquente, Lambda est donc avantageux, car aucun coût n'est engagé pendant les périodes d'attente. Faire tourner en permanence un cluster EC2 ou EKS entraîne des coûts continus pendant la majeure partie du temps où aucun traitement ne s'exécute.

EC2 est un service offrant une capacité de calcul sécurisée et redimensionnable dans le cloud ; AWS précise officiellement que l'on paie ce que l'on utilise tout en gardant un contrôle complet sur les ressources de calcul. Le fait que seul le temps d'exécution soit facturé sans avoir à toucher au système d'exploitation correspond à Lambda, le stockage par objet correspond à S3, et la définition d'un workflow sous forme d'états correspond à Step Functions. Ce large périmètre de contrôle a pour contrepartie le fait que la gestion du système d'exploitation reste à la charge du client.

ECS, Amazon Elastic Container Service, est un service d'orchestration de conteneurs entièrement managé, qui facilite le déploiement, la gestion et la mise à l'échelle d'applications conteneurisées. Le service fournissant un cluster conforme à Kubernetes est EKS, le lancement d'instances de serveur virtuel relève d'EC2, et l'exécution de code en réaction à des événements relève de Lambda. ECS et EKS regroupent tous deux des conteneurs, mais se distinguent selon qu'ils reposent ou non sur Kubernetes.

EKS est un service managé qui permet d'exécuter Kubernetes sur AWS sans avoir à installer ni exploiter soi-même un cluster Kubernetes, et il est certifié conforme à Kubernetes. ECS, en revanche, est un service d'orchestration de conteneurs entièrement managé propre à AWS, qui ne repose pas sur Kubernetes. Les deux sont des services traitant des conteneurs, et ne se limitent pas à gérer uniquement des images de serveur virtuel. Fargate peut être choisi comme cible de lancement dans les deux cas.

EBS est un volume de stockage bloc persistant utilisé par les instances EC2, automatiquement répliqué au sein d'une zone de disponibilité, et en principe attaché à une seule instance. EFS est un système de fichiers destiné aux charges de travail Linux, dont la capacité s'ajuste automatiquement, et qui prend en charge l'accès partagé en parallèle depuis des milliers d'instances EC2. C'est EFS qui permet le partage ; il n'est pas exact que les deux soient destinés au partage, ni que les deux soient réservés à une connexion unique.

S3, Amazon Simple Storage Service, est un stockage objet offrant une excellente scalabilité et disponibilité, capable de stocker et de protéger n'importe quelle quantité de données. Le stockage bloc est assuré par EBS, le système de fichiers partagé pour Linux par EFS, et le cache en mémoire par ElastiCache. La distinction entre objet, bloc et fichier constitue le point de départ pour choisir un service de stockage AWS.

EFS est un stockage de fichiers dont la capacité s'ajuste automatiquement en fonction de l'augmentation ou de la diminution des fichiers, et qui prend en charge l'accès partagé en parallèle depuis des milliers d'instances EC2 ; il convient donc à un usage où le même répertoire est monté simultanément par de nombreuses instances. EBS est un stockage bloc au sein d'une zone de disponibilité, en principe attaché à une seule instance, ce qui fait que chaque instance dispose de son propre espace distinct. Glacier Deep Archive est une classe destinée à l'archivage avec un délai de récupération important, et ElastiCache est un cache en mémoire, et non un système de fichiers.

EBS est un stockage bloc persistant destiné aux instances EC2, automatiquement répliqué au sein d'une zone de disponibilité, offrant des performances cohérentes à faible latence. En raison de cette caractéristique limitée à une seule AZ, obtenir une disponibilité multi-AZ nécessite un mécanisme supplémentaire. La réplication entre régions ou la diffusion depuis des edge locations ne relèvent pas du rôle d'EBS.

S3 Glacier regroupe des classes de stockage destinées à l'archivage : S3 Glacier Instant Retrieval pour les données nécessitant une récupération instantanée, S3 Glacier Flexible Retrieval pour les données consultées rarement à long terme, et S3 Glacier Deep Archive, au coût le plus bas, avec une récupération qui prend plusieurs heures. Le choix de la classe repose sur un compromis entre rapidité de récupération et coût ; le temps de récupération n'est pas uniforme. Il n'y a aucune restriction sur le type de données pouvant être stocké, et ce n'est pas non plus un usage où l'on se connecte comme à un stockage bloc.

S3 est un stockage objet, EBS est un stockage bloc connecté à EC2, et EFS est un stockage de fichiers destiné aux charges de travail Linux. En résumant ainsi : l'objet est ce que l'on manipule dans son ensemble via une API, le bloc est ce qui apparaît au système d'exploitation comme un disque, et le fichier est ce qui peut être monté et partagé depuis plusieurs hôtes, il devient plus facile de choisir selon les besoins.

EBS est un volume de stockage bloc persistant utilisé par les instances EC2, offrant des performances cohérentes à faible latence, ce qui le rend adapté comme disque pour le système d'exploitation ou une base de données. S3 est un stockage objet et n'a pas de mécanisme permettant de connecter un bucket comme périphérique bloc. Glacier est une classe destinée à l'archivage avec un délai de récupération important, et CloudFront est un CDN destiné à accélérer la diffusion.

S3 est un stockage objet offrant une excellente scalabilité, disponibilité, sécurité et performance, capable de stocker et de protéger n'importe quelle quantité de données ; les usages officiellement cités incluent le web, le mobile, la sauvegarde, l'archivage, l'IoT et l'analyse de big data. Ce qui apparaît au système d'exploitation comme un disque est EBS, ce qui suit en principe une connexion à une seule instance est également EBS, et ce qui place les données en mémoire est une caractéristique d'ElastiCache.

EFS est un système de fichiers simple, évolutif et élastique : lorsqu'on ajoute ou supprime des fichiers, la capacité s'ajuste automatiquement, sans nécessiter de planification préalable de la capacité. Fixer la capacité à l'avance ou devoir recréer le système pour l'étendre relève de la logique d'un stockage bloc, et la quantité de mémoire de l'instance connectée ne détermine pas non plus la capacité. Cette élasticité explique pourquoi il est pratique à utiliser comme espace de travail partagé.

S3 Glacier Deep Archive conserve les données rarement consultées au coût le plus bas, avec un délai de récupération de plusieurs heures ; c'est une classe de stockage d'archivage qui correspond bien à cette exigence. EBS et EFS sont conçus pour maintenir une récupération rapide et reviennent souvent plus cher pour héberger des données dormantes à long terme. ElastiCache est un cache en mémoire et n'est de toute façon pas un mécanisme destiné à la conservation à long terme. La démarche consiste à déterminer d'abord combien de temps d'attente est acceptable pour la récupération, avant de choisir la classe.

RDS est un service managé qui facilite la mise en place, l'exploitation et la mise à l'échelle d'une base de données relationnelle dans le cloud, et il automatise des tâches de gestion telles que le provisionnement du matériel, la mise en place de la base de données, l'application des correctifs et les sauvegardes. En revanche, la conception des tables et des colonnes, le choix des index, la construction de l'application et la validité du contenu des données restent des tâches du côté du client. Être managé signifie confier la charge d'exploitation, pas confier la conception.

Aurora fait partie d'Amazon RDS, le service de base de données managée, et utilise la même console de gestion, la même CLI et la même API pour le provisionnement, l'application des correctifs, les sauvegardes, la restauration et la détection des défaillances. La différence réside dans l'unité de gestion : RDS standard gère des instances de base de données individuelles, tandis qu'Aurora gère l'ensemble d'un cluster de serveurs de base de données synchronisés par réplication. Aurora est une base de données relationnelle compatible MySQL et PostgreSQL, et non une base de type clé-valeur.

DynamoDB est une base de données NoSQL de type clé-valeur et document, entièrement managée et compatible multi-régions, offrant des performances de l'ordre de la milliseconde à n'importe quelle échelle. L'entrepôt de données est assuré par Redshift, la base de données relationnelle compatible MySQL et PostgreSQL par Aurora, et la lecture et l'écriture en mémoire par ElastiCache.

Redshift est un service d'entrepôt de données entièrement managé, à l'échelle du pétaoctet dans le cloud, offrant des performances de requête rapides depuis des outils SQL classiques ou des applications de BI existantes, quelle que soit la taille du jeu de données. ElastiCache est un cache en mémoire, EFS un système de fichiers partagé, et SQS une file de messages ; aucun de ces services n'est une infrastructure dédiée à l'agrégation et à l'analyse de grandes quantités de données.

ElastiCache est un service permettant de déployer, exploiter et faire évoluer facilement un cache en mémoire dans le cloud ; il améliore les performances des applications web en récupérant les informations depuis un cache en mémoire rapide, sans dépendre d'une base de données sur disque. L'accélération des requêtes analytiques relève de Redshift, la réduction du coût de conservation à long terme des classes de S3 Glacier, et le partage de répertoire d'EFS.

Aurora est un moteur de base de données relationnelle entièrement managé, compatible MySQL et PostgreSQL, doté d'un sous-système de stockage distribué et partagé hautement performant, dont le stockage s'étend automatiquement selon les besoins. Il n'est pas nécessaire de fixer la capacité à l'avance ni de l'agrandir manuellement. Le stockage sous forme de paires clé-valeur relève de DynamoDB, et la conservation à bas coût en échange d'une récupération lente relève des classes d'archivage de S3 Glacier.

Redshift est un service d'entrepôt de données entièrement managé, à l'échelle du pétaoctet, adapté à l'agrégation et à l'analyse de grands volumes de données depuis des outils SQL ou des applications de BI. RDS est un service facilitant la mise en place, l'exploitation et la mise à l'échelle d'une base de données relationnelle, adapté à la lecture et à l'écriture quotidiennes des transactions d'un système métier. Les deux se ressemblent car ils s'interrogent en SQL, mais ce ne sont pas des bases NoSQL, et leur différence ne se limite pas au volume.

DynamoDB est officiellement décrit comme une base de données NoSQL de type clé-valeur et document offrant des performances de l'ordre de la milliseconde à n'importe quelle échelle. Redshift est un entrepôt de données adapté à l'agrégation et à l'analyse de grands volumes de données, RDS un service assurant la lecture et l'écriture selon un modèle relationnel, et EFS un stockage assurant le partage de fichiers ; aucun de ces services ne vise en premier lieu cette exigence.

RDS, Amazon Relational Database Service, est un service managé qui facilite la mise en place, l'exploitation et la mise à l'échelle d'une base de données relationnelle dans le cloud. Le stockage sous forme de paires clé-valeur relève de DynamoDB, le cache en mémoire d'ElastiCache, et l'agrégation de grands volumes de données de l'entrepôt de données Redshift. Notons qu'Aurora est un moteur proposé dans le cadre de RDS.

Aurora est proposé dans le cadre de RDS, et utilise la même console de gestion, la même CLI et la même API pour le provisionnement, l'application des correctifs, les sauvegardes, la restauration et la détection des défaillances. Il n'est pas nécessaire de monter une instance de gestion dédiée, ni de construire soi-même ces procédures. La différence est que RDS standard gère des instances de base de données individuelles, alors qu'Aurora prend le cluster entier comme unité de gestion.

SQS est un service point à point qui conserve les messages dans une file, généralement récupérés par un seul consommateur qui interroge la file. SNS est un service publish-subscribe où un éditeur envoie des messages à un topic, diffusés simultanément à plusieurs abonnés (push). Inverser les deux est une confusion classique, et ils n'assurent pas non plus la même façon de distribuer les messages. Il est utile de retenir que la file est un lieu où le destinataire vient chercher, et le topic un rôle qui pousse activement vers les destinataires.

SQS propose des files standard et des files FIFO. Les files standard offrent une livraison au moins une fois (at-least-once), si bien que le même message peut arriver plusieurs fois. Les files FIFO offrent un traitement exactement une fois (exactly-once) et une garantie d'ordre : l'ordre d'envoi est conservé, et chaque message est traité une seule fois. Pour les workflows où l'ordre et la prévention des pertes sont importants, on choisit une file FIFO.

SNS diffuse simultanément (push) les messages envoyés à un topic vers plusieurs abonnés, et une file SQS peut être désignée comme abonné. Ce mode où un topic SNS distribue vers plusieurs files SQS est le pattern fan-out présenté officiellement comme configuration classique. Une file étant le côté récepteur et non l'émetteur, elle ne peut pas être orientée pour lire un topic.

Les types d'abonnés de SNS se répartissent en deux catégories : A2A (application-to-application), incluant SQS, Lambda, HTTP(S) ou Data Firehose, et A2P (application-to-person), incluant l'e-mail, les notifications push mobiles ou le SMS. Ce n'est pas limité à l'une des deux catégories, ni réservé aux instances EC2 comme seules destinations. Cette large étendue explique pourquoi SNS sert aussi bien aux notifications à destination des personnes qu'à l'intégration entre applications.

Step Functions est un service qui permet de créer des workflows, c'est-à-dire des machines à états, rendant possible la construction d'applications distribuées, l'automatisation de processus, l'orchestration de microservices et la création de pipelines de données ou de machine learning. Chaque étape est appelée state, et une instance en cours d'exécution est appelée execution. La répartition du trafic relève d'Elastic Load Balancing, le stockage d'objets de S3, et le cache clé-valeur d'ElastiCache.

API Gateway est un service permettant de créer, publier, maintenir, surveiller et sécuriser des API REST, HTTP et WebSocket à n'importe quelle échelle ; il fonctionne comme porte d'entrée pour accéder à des backends tels que des charges de travail sur EC2, Lambda, ou n'importe quelle application web. Exécuter le traitement lui-même relève du backend, l'application centralisée de règles de protection d'AWS Firewall Manager, et la mise en cache à la périphérie de CloudFront.

EventBridge est un service serverless qui connecte les composants d'une application au moyen d'événements, en assurant leur ingestion, leur filtrage, leur transformation et leur diffusion. Le bus d'événements est un routeur qui achemine les événements de nombreuses sources vers de nombreuses cibles. La file d'attente correspond à SQS, la machine à états à Step Functions, et la porte d'entrée à API Gateway.

EventBridge Scheduler est un mécanisme qui gère les exécutions planifiées ou ponctuelles à l'aide d'expressions cron ou rate ; c'est donc lui qui traite un déclenchement à heure fixe. SQS est une file qui conserve les messages pour que le destinataire les récupère, SNS un système publish-subscribe diffusant vers des abonnés, et API Gateway un service publiant et relayant des API ; aucun de ces services n'a pour objectif un déclenchement horaire.

SQS est un service de file hébergé, sécurisé, durable et hautement disponible qui intègre et découple les systèmes logiciels distribués et leurs composants. Le côté réception peut répondre dès que le message est déposé dans la file, et le traitement ultérieur le récupère et avance à son propre rythme, ce qui évite que le retard de l'un bloque l'autre. Avec un appel direct ou un programme unique, le retard du traitement ultérieur se répercute directement sur le temps d'attente de la réception.

SNS diffuse simultanément (push) les messages envoyés à un topic vers plusieurs abonnés, et une file SQS peut être désignée comme abonné ; pour distribuer un événement vers trois traitements, on utilise donc le pattern fan-out combinant un topic SNS et plusieurs files SQS. Si trois traitements partagent une seule file, généralement dès que l'un des trois récupère le message, les autres ne peuvent plus le recevoir. Une configuration où la source envoie trois fois, ou où le traitement récepteur retransmet, oblige à modifier l'émetteur à chaque nouvelle destination, ce qui va à l'encontre du couplage faible.