Apprendre AWS : la carte, la roadmap et cinq projets

J'ai commencé comme cloud data engineer dans une ESN, en 2018. En 2019, j'ai passé la certification AWS Solutions Architect Associate, puis une spécialité data l'année d'après. C'est cette première certif qui m'a fait passer de développeur en ESN à freelance en full remote : des projets plus complexes, mieux payés, avec des technos qu'on n'a pas tous la chance d'apprendre sur le tas.

Depuis 2021, je suis freelance, data engineer sur AWS, pour de grands groupes industriels : des pipelines qui transforment la donnée avec Glue, orchestrés par Step Functions, avec S3 au milieu de tout. Aujourd'hui je fais surtout de l'IA générative sur Google Cloud, mais c'est sur AWS que j'ai appris le métier. Mes deux certifs sont expirées depuis ; ce qu'elles m'ont ouvert, non.

Cette page, c'est ce que je donnerais à quelqu'un qui part de zéro : ce que fait chaque service, comment ils se branchent, dans quel ordre les apprendre, et cinq projets pour les manipuler pour de vrai.

Avant le cloud, pour mettre une appli en ligne, il fallait acheter un serveur, l'installer, le mettre à jour, remplacer le disque quand il lâchait. Le cloud, c'est la même chose, mais tu loues. Et sur AWS, la plupart des services sont managés : ça veut dire qu'il n'y a rien à installer et rien à aller réparer. Tu dis ce que tu veux, Amazon fait tourner.

La plupart, pas tous. Le premier service qu'on te montre, EC2, n'est pas managé : tu loues une machine virtuelle, et son système, ses mises à jour, sa sécurité, c'est toi. C'est pour ça qu'on commence souvent par EC2 et qu'on la quitte dès qu'on peut, pour des services où il n'y a plus de machine du tout.

Et même sur un service managé, deux choses restent toujours à toi : ce que tu mets dedans, et qui a le droit d'y toucher.

Dans la vidéo, j'en cite vingt, de S3 à CloudFormation : tous ceux que j'ai déjà utilisés au moins une fois, et qui valent le coup d'être connus. Ils sont tous là, rangés par famille, avec ce que chacun remplace (le truc que tu n'as plus à gérer) et le moment où tu le croises. J'en ai ajouté cinq que je n'ai pas eu le temps de dire, marqués « pas dans la vidéo ».

Tu n'as pas besoin de les apprendre dans cet ordre-là. L'ordre, c'est la roadmap, section 6. Et tout tient aussi sur une antisèche d'une page, en bas.

Ce qui rend AWS impressionnant au début, c'est la liste. Ce qui le rend simple, c'est que les services se branchent toujours de la même façon : une entrée (par où arrive la requête), un calcul (où ton code tourne), des données (où elles dorment). Et en dessous, toujours les mêmes : les droits, les logs, les secrets, le code qui crée le tout.

Voilà les cinq chemins que tu croiseras le plus. Les quatre premiers sont des projets de la partie 3.

À un moment, il faut ouvrir un vrai compte et manipuler. C'est là que la plupart s'arrêtent, parce qu'ils ont lu l'histoire de quelqu'un qui a reçu une facture énorme. Voilà comment ça marche aujourd'hui.

• Le plan gratuit. Depuis juillet 2025, un nouveau compte choisit entre un plan gratuit et un plan payant. Le plan gratuit donne 100 $ de crédits à l'ouverture, et jusqu'à 100 $ de plus en découvrant des services. AWS écrit que tu ne paies rien tant que tu ne passes pas au plan payant. En échange, certains services ne sont pas disponibles, et le compte se ferme tout seul au bout de six mois ou quand les crédits sont épuisés.
• Le « toujours gratuit ». Plus de trente services ont une part gratuite chaque mois, même après. Par exemple Lambda (un million de requêtes par mois) et DynamoDB (25 Go stockés).
• Le jour où tu passes au plan payant, l'alerte de budget devient ta ceinture de sécurité. Créer un budget et recevoir ses alertes est gratuit.

Et avant de créer quoi que ce soit : active la double authentification sur le compte « racine » (celui de l'adresse mail d'inscription), crée-toi un utilisateur pour le quotidien, et ne te sers plus jamais du compte racine.

Pour aller plus loin sur la facture : les pièges, plus bas. La plupart sont des choses qu'on laisse allumées sans le savoir.

Chaque étape ajoute des services à ceux de la précédente. Les deux premières, tout le monde les fait. La troisième et la quatrième, c'est ce qui sépare quelqu'un qui a suivi un tuto de quelqu'un qu'on peut mettre sur un projet. La cinquième dépend du métier que tu vises : tu choisis un coin, pas tout AWS.

1. AWS Skill Builder — la formation officielle d'Amazon. Une grande partie des cours est gratuite. Elle t'apprend le vocabulaire : à quoi sert chaque brique. Et elle commence à te préparer à la certification.
2. AWS Cloud Quest — un jeu assez marrant : tu construis des architectures dans une ville en 3D. Il t'apprend à assembler les briques. Une partie est accessible avec un compte gratuit ; les rôles avancés sont dans l'abonnement.
3. Les labs — là, tu travailles dans une vraie console AWS, guidée pas à pas. Les Builder Labs de Skill Builder sont dans l'abonnement payant (29 $ par mois). Les AWS Workshops, eux, sont gratuits : des centaines d'ateliers guidés, que tu déroules dans ton propre compte. Attention, ce que tu crées dans ton compte se paie comme le reste.
4. Les tutoriels de la documentation — chaque service a les siens. Ce sont eux que je te donne pour chaque projet de la partie 3.

Une certification AWS est valable trois ans. Entre nous, l'examen Associate est assez compliqué : il faut pratiquer, et bachoter pas mal. Sur Skill Builder, AWS propose un cours officiel de préparation à l'examen pour chaque certif Associate.

Un site statique, c'est des fichiers HTML, CSS et images qui ne changent pas selon le visiteur : un portfolio, une page de présentation. Tu les poses dans un bucket S3, et CloudFront les sert partout dans le monde. Route 53 fait pointer ton nom de domaine vers CloudFront. IAM décide que seul CloudFront a le droit de lire le bucket (le bucket reste privé). CloudWatch te montre qui est venu et ce qui a échoué.

Ton site a besoin de données : un formulaire, une liste de choses à faire, des commentaires. API Gateway reçoit la requête HTTP et réveille une Lambda. La Lambda lit ou écrit dans DynamoDB, et répond. Il n'y a aucune machine allumée entre deux requêtes.

Prends un jeu de données public qui change (data.gouv.fr en a des centaines : qualité de l'air, transports, transactions immobilières). Tu déposes le fichier brut dans S3. Un job Glue le nettoie et le réécrit en Parquet, un format en colonnes, compressé, que tous les outils lisent. Athena te laisse faire du SQL directement dessus. Et Step Functions enchaîne le tout : télécharger, transformer, vérifier, et reprendre là où ça a planté.

Pour la suite de ce chemin (Spark, l'entrepôt, l'orchestration), c'est la roadmap data engineer.

C'est l'architecture que tu retrouveras dans beaucoup d'équipes. Ton appli est une image Docker. ECS la fait tourner, et avec Fargate tu ne gères aucune machine. Le répartiteur (ELB) reçoit le trafic et l'envoie aux copies qui répondent. La base Postgres est sur RDS, dans un sous-réseau privé du VPC que personne ne voit depuis internet. Le mot de passe de la base est dans Secrets Manager, pas dans ton code.

Reprends un des projets précédents (le 2 est idéal) et décris-le entièrement dans un fichier : la table, la Lambda, son rôle IAM, l'API. Détruis tout, puis recrée-le d'une commande. C'est ce qu'on attend de toi en entreprise : ce que tu cliques dans la console, tu ne sais pas le refaire ; ce que tu écris, tu le redéploies, tu le relis, tu le copies en préproduction.

Chez AWS, l'outil s'appelle CloudFormation. Beaucoup d'équipes utilisent Terraform à la place : même idée, et il marche sur tous les clouds. Choisis-en un. Et oui, une IA peut écrire ce fichier pour toi : rien ne change avant que tu aies lu et validé ce qu'il va créer.