Enseigner AWS sans compte : S3, DynamoDB et SQS pour chaque élève

Les services cloud sont la partie du développement moderne qu’une classe ne peut généralement pas enseigner du tout. Lire un cours sur le stockage d’objets n’a rien à voir avec le fait de déposer soi-même un fichier dans un bucket, et la voie habituelle passe par un compte AWS, une carte bancaire et une facture que personne n’a envie d’expliquer au service comptable. La plupart des établissements ne dépassent jamais le stade du schéma au tableau.

Ici, l’élève appuie sur « Démarrer » dans l’onglet « Cloud » et dispose de trois services : un stockage d’objets, une table NoSQL et une file de messages, compatibles avec les API Amazon S3, DynamoDB et SQS. boto3, le SDK AWS pour JavaScript, Java ou Go et l’AWS CLI fonctionnent donc sans modification, et le code qu’il écrit ici est celui qu’il écrirait pour un vrai compte.

Cette pile cloud lui est réservée, disparaît quand il a terminé et ne coûte rien. Nous ne sommes pas affiliés à Amazon Web Services, et il ne s’agit pas d’un compte AWS : la pile fonctionne avec MiniStack, un émulateur open source, sur la même machine que son application. AWS, Amazon S3, DynamoDB et Amazon SQS sont des marques d’Amazon.com, Inc. ou de ses filiales, citées ici uniquement pour indiquer quelles API la pile implémente.

Ce dont dispose chaque élève

Chaque élève a sa propre pile, sur le même réseau privé que son application, sa base de données et son terminal. Tout ce qui tourne dans sa session y accède sous le nom `cloud` : la configuration d’un tutoriel fonctionne telle quelle, sans URL à copier.

Au démarrage, la pile définit les variables que tout SDK AWS lit déjà : `AWS_ENDPOINT_URL`, une clé d’accès et une clé secrète créées pour l’élève, et `AWS_REGION`. Ainsi, `boto3.client("s3")` sans argument trouve la pile, sans rien à configurer ni URL à copier.

La pile démarre vide, comme un nouveau compte : l’élève crée lui-même ses buckets, ses tables et ses files, depuis son code ou dans l’onglet « Cloud », et appeler `create_bucket` avant `put_object` fait partie de ce que l’exercice enseigne.

Les identifiants sont générés automatiquement, jamais choisis, et affichés sur la page pour que l’élève comprenne à quoi correspondent les variables.

  1. Ouvrir l’onglet « Cloud ». Il se trouve dans « Déploiements », à côté de « Application » et de « Base de données ». Une pile par élève.
  2. Appuyer sur « Démarrer ». La pile est prête en quelques secondes, vide, comme un nouveau compte.
  3. Lire les variables. Le point de terminaison, la paire de clés et la région sont affichés sur la page. Tout SDK AWS les lit automatiquement dans l’environnement.
  4. Écrire le code. Dans son application ou dans le terminal : `aws s3 ls`, `boto3.client("s3")`, ou le SDK JavaScript, Java ou Go. Aucune configuration nécessaire.
  5. Voir ce qui a été créé. La console, sur la même page, affiche les buckets, les clés, les tables, les éléments et les messages en attente au fur et à mesure que le code les écrit.
L’onglet « Cloud » d’un élève, avec sa session (une application, une base de données, une pile cloud et un terminal) et un bouton pour créer une pile
Une pile par élève, à côté de son application et de sa base de données, sur le même réseau privé.

Une console dans le navigateur, à la place de la console AWS

Une fois la pile démarrée, une console s’affiche sur la page, en trois onglets : « Stockage d’objets (S3) », « Base NoSQL (DynamoDB) » et « File (SQS) ». Chacun liste les éléments de ce type que contient la pile (buckets, tables ou files), avec un bouton « Supprimer » à côté de chacun et un champ pour en ajouter ; sélectionnez-en un pour l’ouvrir en dessous. « Stockage d’objets » liste tout le contenu du bucket sélectionné par clé complète, avec un téléchargement pour chaque objet ; il permet aussi d’importer un fichier sous une clé saisie par l’élève, et de créer ou supprimer des buckets. « Base NoSQL » liste les tables, permet d’en parcourir une et de modifier un élément à la fois. « File » indique le nombre de messages de chaque file et permet d’envoyer un message, de voir ceux qui attendent, d’en supprimer un ou de tout vider.

Le stockage d’objets affiche des clés, et non des dossiers. Les dossiers n’y existent pas : ce qui y ressemble n’est qu’un ensemble de clés qui commencent de la même façon, et photos/2026/cat.png est un nom unique qui contient des barres obliques. C’est ce que renverra le list_objects_v2 de l’élève, et c’est donc ce que la page affiche. On n’y modifie ni n’y supprime aucun fichier : changer le contenu d’un bucket, c’est le rôle de l’application qu’il est en train d’écrire. En revanche, supprimer un bucket supprime aussi son contenu, et une confirmation est demandée d’abord, qui nomme ce qui disparaît.

Consulter une file ne la vide pas : les messages y retournent aussitôt, et l’élève peut donc observer sa file pendant que son programme la lit. Beaucoup de consoles s’y prennent mal, et un programme qui fonctionne semble alors en panne.

La console permet de créer autant que de consulter : un bucket, une table avec sa clé primaire, une file, chacun créé et supprimé depuis les trois mêmes onglets. L’élève peut ainsi préparer son stockage à la main, puis écrire son code, dans l’ordre que suivent la plupart des tutoriels.

Un élément s’affiche sous la forme typée dans laquelle la table le stocke réellement, car c’est sous cette forme que son code le relira.

La console importe des fichiers jusqu’à 1 Mo et en télécharge jusqu’à 2 Mo ; une liste affiche les 200 premiers objets, un parcours les 100 premières lignes, et un aperçu dix messages. Le programme de l’élève n’a aucune de ces limites, et le terminal est là pour tout ce qui est plus volumineux.

L’AWS CLI dans le terminal du navigateur

« Ouvrir le terminal », depuis n’importe lequel des trois onglets, ouvre un vrai shell à côté de la session, avec l’AWS CLI déjà configurée pour la pile : `aws s3 ls`, `aws s3 cp`, `aws dynamodb scan` et `aws sqs send-message` fonctionnent sans étape `configure` ni `--endpoint-url`. Tout ce que la console ne propose pas peut s’y faire, et c’est le meilleur endroit pour manipuler un gros fichier.

La console importe des fichiers jusqu’à 1 Mo et en télécharge jusqu’à 2 Mo. Le programme de l’élève n’a pas cette limite : il écrit directement dans la pile.

Ce qui est conservé, et pour combien de temps

L’ensemble de la pile est enregistré dans une seule archive à l’arrêt et restauré au démarrage, dans la limite de 25 Mo pour tout son contenu. La page indique son taux de remplissage et prévient avant que la limite soit atteinte, pas après : un stockage d’objets ne peut pas être passé en lecture seule, et le plus honnête est d’anticiper le problème.

Elle utilise le même quota qu’une base de données, avec la même garantie, le même plafond et la même règle d’inactivité : une pile oubliée en marche n’épuise pas en silence la journée de quelqu’un.

En faire un travail à rendre

Cochez la pile dans le formulaire de déploiement : elle démarre avec l’application, variables déjà définies. Un devoir peut donc être « une application Flask qui stocke les fichiers importés dans un bucket S3 », « un worker qui lit une file SQS » ou « une page qui s’appuie sur une table DynamoDB » : des tâches courantes en entreprise, impossibles à donner jusqu’ici sans un compte AWS par élève.

La personne qui corrige un rendu déployé reçoit la pile de l’élève telle qu’il l’a laissée, et celle-ci n’est jamais réenregistrée : essayer l’application ne modifie donc en rien ce sur quoi l’élève est noté.

Questions fréquentes

Les élèves peuvent-ils apprendre AWS sans compte AWS ?
Oui. Chaque élève dispose d’un stockage d’objets, d’une table NoSQL et d’une file de messages qui implémentent les API Amazon S3, DynamoDB et SQS : il écrit donc le même code que pour AWS, avec boto3 ou les SDK et la CLI AWS. Ni compte AWS, ni carte bancaire, ni facture. L’ensemble fonctionne avec MiniStack, un émulateur open source, sur la même machine que son application ; ce n’est pas un compte AWS, et rien n’est exposé sur Internet.
Quel SDK un élève doit-il installer ?
Le SDK AWS habituel pour son langage : boto3 pour Python, le SDK AWS pour JavaScript, Java ou Go, ou l’AWS CLI v2 dans le terminal du navigateur. Tous lisent AWS_ENDPOINT_URL, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY et AWS_REGION dans l’environnement, et la pile définit ces quatre variables : le code d’un tutoriel fonctionne donc tel quel, sans aucune configuration.
Quels services AWS sont pris en charge ?
Les trois dont un premier cours a besoin : Amazon S3 pour les objets, DynamoDB pour une table NoSQL et Amazon SQS pour une file, qui sont aussi les trois qu’utilise la plateforme elle-même. Les autres services émulés par l’image MiniStack sont fournis avec, mais seuls ces trois-là sont affichés dans la console et pris en charge par nos soins.
Est-ce affilié à Amazon Web Services ?
Non. MitsuruTech n’est ni affilié à Amazon Web Services, ni approuvé ou parrainé par cette société. AWS, Amazon S3, DynamoDB et Amazon SQS sont des marques d’Amazon.com, Inc. ou de ses filiales, citées ici uniquement pour indiquer quelles API la pile implémente, comme le ferait n’importe quel tutoriel ou émulateur.
Deux élèves peuvent-ils voir la pile l’un de l’autre ?
Non. Chaque pile se trouve sur le réseau privé de son propriétaire, sans accès entrant ni sortant : rien en dehors de sa session ne peut l’atteindre, pas même le reste du site. La console fonctionne en demandant à la session de l’élève d’effectuer l’appel.
Un invité y a-t-il droit ?
Oui. Un invité peut avoir une pile cloud et une base de données en même temps : la pile ne compte pas dans la limite des bases de données, et « Déployer cet exemple » sur la page « Déploiements » crée les deux. Le compte d’un invité est conservé 24 heures après sa dernière utilisation et chacun de ses déploiements dure 30 minutes au maximum, ce qui borne aussi la pile. « Conserver ce compte » en fait un vrai compte.