AWS on The Cloud Optimist

Le jour où j'ai accidentellement supprimé une API, et ce que cela m'a appris sur le DevOps

Tue, 17 Feb 2026 07:30:00 +0100

La journée du 4 avril 2024 avait bien commencé. Un petit café en main, un VS Code en plein ébullition, et de la douce musique électro dans les oreilles, tant de facteurs positifs qui ne pouvaient présager de la catastrophe à venir.

Aujourd’hui, j’aimerai vous raconter comment une journée en apparence tranquille est devenue un moment marquant de ma carrière de DevOps !

Incident

Le contexte

Je travaillais alors dans une équipe avec pour but de mettre à disposition une API Gateway globale sur AWS, avec plusieurs endpoints managés par différentes équipes. Concrètement, la mise en place de cette API Gateway était l’étape initiale du projet. Cela comprenait un record DNS qui pointait vers cette API, l’API Gateway elle-même, ainsi qu’un Cognito Authorizer configuré avec plusieurs clients.

Une fois cette API prête, des équipes externes pouvaient alors déployer leurs propres endpoints sur cette API. Pour cela, une pipeline CI/CD était mise en place, et via CloudFormation, les endpoints se rattachaient directement à l’API déjà créée.

Je simplifie au maximum, si des détails techniques vous intéressent, n’hésitez pas à me contacter !

De mon côté, en plus d’être responsable de l’infrastrcture globale de l’API, il m’arrivait de travailler ou de troubleshooter certains services.

Le début du drame

Si vous avez déjà travaillé avec CloudFormation, vous êtes peut-être familier avec le terme UPDATE_ROLLBACK_FAILED. C’est ce qui arrive lorsque vous essayez de mettre à jour une stack CloudFormation, mais que celle-ci a rencontré un problème. Elle essaiera donc de faire un rollback. Mais si ce rollback n’aboutit pas, votre stack sera alors en UPDATE_ROLLBACK_FAILED.

Et ce UPDATE_ROLLBACK_FAILED est bien embêtant, car vous ne pouvez plus relancer de déploiements tant que vous n’avez pas résolu le problème.

C’est exactement ce qui s’est passé ce fameux 4 avril 2024. Un de nos services s’est retrouvé dans cet état, et j’ai commencé à investiguer le pourquoi du comment.

Après quelques minutes, j’ai constaté que le problème venait de la ressource API elle-même. Sans trop réfléchir, et dans une optique de débloquer le problème rapidement, je me suis rendu directement sur la console AWS, sur le service API Gateway. J’ai cherché la ressource en question, et me suis empressé de la supprimer.

À ce moment précis, quelque chose de très étrange s’est produit. Un comportement inattendu qui m’a glacé le sang. Au lieu de me retrouver sur la même page, AWS m’a renvoyé sur la page principale du service API Gateway. Cette même page qui liste vos APIs disponibles, et qui affichait maintenant le nombre 0.

J’ai ainsi réalisé que je n’avais pas supprimé la ressource API, mais bien l’API Gateway dans sa totalité.

Les détails d’un échec

Jamais je n’aurais pensé commettre une telle bêtise. Et j’imagine que vous lisant ces lignes, vous vous dites la même chose.

Car pour se tromper, il fallait le faire !

Laissez-moi vous faire une reconstitution de la scène du crime. Voici ce que j’ai vu au moment où j’ai pris la décision de supprimer une ressource de l’API Gateway.

Toute ressemblance avec une situation réelle est totalement fortuite

Dans ma situation, sur quel bouton auriez-vous cliqué ? Facile ! Le bouton Delete juste à droite de la ressource !

Pour ma part (et je ne sais toujours pas ce qui m’a poussé à faire cela), j’ai préféré cliquer sur le bouton API actions. Après tout, je voulais en effet faire une action !

Et que se passe-t-il quand on clique sur ce bouton ?

Oula ! De suite, on voit que ce n’est pas du tout ce qu’on veut faire. Mais pensez-vous que cela m’a découragé ? Absolument pas ! J’étais venu pour supprimer une ressource, et quand j’ai vu le mot Delete, je n’ai pas réfléchi plus longtemps ! J’aurais dû, car ainsi, j’aurais sûrement vu le mot API juste à côté.

Heureusement, nos amis de chez AWS ont pensé à tout ! Lorsque vous cliquez sur Delete API, on va tout de même vous demander si vous êtes bel et bien certain de vouloir supprimer cette API. Un beau message s’affiche, vous indiquant le nom de l’API en question, et vous demandant de taper le mot confirm pour valider cette opération.

Tout ça, c’est bien beau, mais les ingénieurs d’AWS ont sous-estimé mon impatience. À ce moment-là, cette demande de confirmation n’était pas une mise en garde, mais un obstacle à mon but de supprimer ma ressource. Ni une ni deux, j’ai entré le mot confirm, et validé l’opération.

Voici donc la dernière chose que j’ai vue avant de finalement réaliser l’erreur que j’avais commise.

Une vision d’horreur

Je voulais absolument vous retracer ce petit parcours pour vous faire comprendre une chose : vous aurez beau mettre en place toutes les sécurités possibles, vous ne pourrez jamais rien faire contre un individu impatient, car ce dernier ne saura pas lire vos avertissements.

Alors, la prochaine fois que vous devrez faire une action somme toute inoffensive, prenez bien le temps de lire et de vous assurer que vous êtes bel et bien sur le bon chemin.

Cela étant dit, passons maintenant à une étape cruciale : la résolution de cet incident !

Résolution

Le déclic

Revenons donc sur le moment du drame. Après avoir réalisé ce qui était arrivé, j’ai eu comme un électrochoc, un éclair de génie (aucune poudre blanche n’ayant pourtant été consommée). Je savais maintenant ce que je devais faire : résoudre l’incident, mais surtout, documenter les actions que j’allais entreprendre.

Car quelques semaines plus tôt, je m’étais intéressé à l’incident GitLab de 2017, celui ayant interrompu le service pendant plusieurs heures, et résultant d’une perte de données pour certains utilisateurs. J’ai ainsi découvert le terme de Post-Morten, et leur intérêt dans ce genre de situation. Mais je garde ça pour la prochaine section de cet article.

En attendant, si vous êtes intéressés par ces sujets-là, je vous conseille la très bonne chaîne Youtube de Kevin Fang qui je le cite : “lit des postmortems et en fait des vidéos de piètre qualité”.

Rollback, impact, et communication

La première chose que je me suis dite, c’est qu’il était peut-être possible de faire une sorte de rollback directement depuis AWS, et d’ainsi réduire au maximum l’impact sur les utilisateurs. Si j’avais correctement lu le message d’avertissement plus haut, j’aurais tout de suite compris que cela était impossible (mais si je l’avais lu, je n’aurais de toute façon pas été dans cette situation).

N’ayant aucun moyen rapide et simple de revenir en arrière, j’étais maintenant confiant que j’étais face à un véritable incident ayant un impact global. J’ai donc dans un premier temps pris soin de comprendre tous les impacts que cette suppression d’API allait avoir. Dans mon cas, non seulement l’API n’était plus disponible (merci Captain Obvious), mais en plus de cela, aucun nouveau déploiement n’était possible jusqu’à ce que l’API soit de nouveau opérationnelle.

Finalement, j’ai fait en sorte d’avertir toute notre équipe interne de la situation. Ainsi, ils étaient au courant de l’incident en cours, et que j’étais en train de travailler à sa résolution.

Analyse et découverte de problèmes

Il était maintenant temps de se retrousser les manches et de trouver un moyen de redéployer cette API Gateway.

En premier lieu, je me suis rendu dans le service CloudFormation, car j’avais souvenir que cette API avait été initialement déployée via ce service. J’ai d’abord essayé de mettre à jour la stack, en pensant que cela pourrait faire revenir ma chère API comme par magie.

Évidemment, cela n’allait pas être aussi simple. La mise à jour de cette stack était maintenant impossible, car la suppression manuelle de l’API avait fait rentrer la stack dans un état “hybride” dont elle n’arrivait pas à se sortir.

La mise à jour de cette stack étant impossible, la suite logique était de la supprimer afin de la déployer à nouveau proprement. Et c’est là que les ennuis ont commencé. Cette fameuse stack CloudFormation produisait plusieurs Outputs. Deux de ces outputs étaient nécessaires à toutes les stacks “enfants” qui avaient jusqu’alors déployé leurs endpoints sur cette API. Ainsi, CloudFormation m’interdisait de supprimer ma stack, car elle pourrait impacter toutes les autres.

Après plusieurs minutes de réflexion pour essayer de trouver d’autres alternatives, cette forte interdépendance m’amena à prendre une décision difficile : supprimer toutes les stacks “enfants” de CloudFormation, pour un total de 81 stacks.

Pour couronner le tout, ces stacks “enfants” n’avaient pas de tags identifiables qui auraient pu nous permettre d’automatiser cette suppression. Heureusement, la plupart d’entre elles avaient un nom avec un préfixe reconnaissable, ce qui m’a permis de faire un bon coup de ménage sur la plupart d’entre elles.

Je vous ai parlé d’interdépendances ? Parce que ce n’est pas fini ! Certaines stacks avaient déployé des buckets S3. Et devinez quoi ? CloudFormation ne voudra pas supprimer votre stack, si votre bucket S3 n’est pas vide ! Et bien sûr, 14 stacks se sont retrouvées dans l’état DELETE_FAILED à cause de cela. Heureusement, le problème se résout assez facilement : après avoir fait un backup de chaque bucket, il suffit de les vider et de relancer la suppression de la stack.

Déploiement de l’API : Le bout du tunnel ?

Étant venu à bout de toutes ces interdépendances, il était maintenant temps de supprimer la stack CloudFormation de l’API Gateway, et de la déployer à nouveau.

La suppression se passa sans plus de problème (Dieu merci), mais évidemment, cela ne fût pas le cas pour sa création.

Déjà, parlons de la stack elle-même. Un fichier YML existait dans un repo GitHub, mais celui-ci n’avait pas été mis à jour depuis des lustres, et je savais que je ferais mieux d’utiliser la définition de la stack présente dans CloudFormation (et oui, je l’ai quand même gardée, pas fou le gars).

Cette stack ne déployait pas uniquement l’API Gateway, mais plusieurs ressources AWS (je ne rentrerai pas dans les détails du pourquoi nous avions besoin de ces ressources dans cet article), dont des Lambdas. Ces dernières se basaient encore sur Python 3.7, version avec laquelle il était impossible de se servir pour créer de nouvelles Lambdas. Heureusement, un petit upgrade en Python 3.12 sera suffisant pour qu’AWS nous laisse tranquille.

Et, à ma grande surprise, la stack se déployait maintenant sans souci !

Mais je vous la fait courte, il restait encore du pain sur la planche ! En effet, il manquait à la stack CloudFormation plusieurs ressources critiques à la bonne exécution de notre API. Des ressources qui avaient été créées à la main dans AWS directement, faisant fi de toute bonne pratique d’Infrastructure as Code (pleure en Terraform). Dans un souci de rétablissement du service le plus rapidement possible (on est DevOps, ou on ne l’est pas !), ces ressources seront donc créées une nouvelle fois à la main.

Pour finir, plusieurs composants clés faisaient référence à l’ARN de l’ancienne API en dur. Il fallait ainsi faire tout un travail d’archéologie pour trouver tous les endroits où une mise à jour vers la nouvelle API s’imposait.

Finalement, après plusieurs heures de troubleshooting, l’API était de nouveau opérationnelle, et les développeurs pouvaient à nouveau déployer leurs projets.

Cet incident aura démarré le 4 avril 2024 à 15h24 et se sera conclu le 5 avril 2024 à 08h46.

Post-Mortem et Lessons Learned

Pendant cet incident, j’ai réalisé une prise de note intensive sur les actions menées. J’avais déjà entendu parler du principe de Post-Mortem, et je pensais que cet incident serait le parfait candidat.

Si vous ignorez le principe d’un Post-Mortem, il agit comme un document retraçant les étapes de résolution d’un incident, couvrant les impacts, et la root cause, mais surtout — et à mon sens le plus intéressant — comporte une section appellée Lessons Learned. Cette section, si vous la prenez au sérieux, sera votre meilleure alliée pour construire une architecture plus robuste et plus durable.

Concrètement, vous allez noter dans cette section trois points clés : ce qui s’est bien passé, ce qui s’est mal passé, et là où vous avez eu de la chance. Et surtout, soyez honnêtes ! Même si certains points vous paraissent bêtes, ou vous font passer pour un incompétent (et je vous dis ça alors que j’ai manuellement supprimé une API, donc prenez-le avec légèreté), le but n’est pas de pointer du doigt (ce qu’on appelle aussi la blameless culture), mais de comprendre les failles dans notre système, afin de les améliorer.

« The cost of failure is education. » — Devin Carraway (Source)

Cela vous paraît peut-être encore un peu flou, alors laissez-moi vous montrer mes lessons learned de cet incident.

What went well

Pendant cet incident, deux choses se sont bien passées.

D’abord, la résolution s’est faite par un membre de l’équipe qui connaissait en profondeur cette architecture, ce qui a permis de comprendre rapidement ce qui devait être remis en place pour restaurer le service.

Enfin, il y a eu une bonne communication tout au long de cet incident. Lorsque le problème s’est présenté, il n’a pas essayé d’être dissimulé, et des mises à jour fréquentes ont été annoncées pour avertir de l’avancement de sa résolution. C’est un point très important, car non seulement vous donnez de la visibilité sur vos actions, mais par la communication, vous pouvez aussi acquérir des informations utiles à la résolution de votre incident (un collègue pourra par exemple vous pointer vers une documentation dont vous n’avez pas connaissance, ou vous donner un coup de main si nécessaire).

What went wrong

Ici, c’est la partie qui fait mal. Comme je vous l’ai dit, il faut ravaler sa fierté, et mettre en lumière tout ce qui aurait pu être mieux exécuté.

Pour cet incident, quatre choses ne se sont pas bien passées.

Pour commencer, l’infrastrucutre de cette API n’était non seulement pas consolidée dans un seul et même fichier (ou dossier), mais était en plus disséminée dans plusieurs repos GitHub. Il était ainsi très compliqué d’avoir une vue d’ensemble de ce qui était nécessaire au bon fonctionnement de cette API.

Ensuite, un gros problème résidait dans ce qu’on appelle le drift. Ce sont toutes les différences que vous avez entre votre infrastructure réelle, et votre infrastructure telle qu’elle est définie dans votre code. Idéalement, aucune modification manuelle ne doit avoit lieu, et tout doit passer par votre fichier d’Infrastructure as Code. Si cela avait était le cas, un simple redéploiement aurait permi une remise en service instantanée.

Un autre problème résidait dans la forte interdépendance de toutes les ressources. Beaucoup par exemple se basaient sur un output de la stack CloudFormation. Si vous enlevez cette stack, vous enlevez ainsi la possibilité de déployer la suite de votre infrastructure.

Enfin, l’identification des ressources liées à notre infrastructure était difficile. Notre stack déployait les ressources sans aucun tag associé, ce qui rendait compliqué la recherche de toutes les ressources nécessaires à notre API.

Where we got lucky

Cette partie peut ressembler à du positif, mais il n’en est rien ! Car vous allez ici parler des élément qui se sont bien passés, mais UNIQUEMENT car vous avez eu de la chance. Comprenez qu’à tout moment, cela aurait pû être un autre point à mettre dans la catégorie “What went wrong”. Donc soyez heureux pour cette fois, mais ne baissez pas votre garde pour autant !

Pour cet incident, trois choses se sont bien passées par chance.

Tout d’abord, l’incident a été immédiatement identifié (c’est au moins l’avantage quand on fait une boulette pareille). Mais cela aurait pû être bien pire ! Car si cette API avait été supprimée par tout autre moyen (un script d’automatisation par exemple), nous n’avions aucun monitoring en place capable de nous prévenir d’une telle chose.

Ensuite, il se trouve que la personne qui a supprimé cette API avait une excellente connaissance du projet et de l’infrastructure (je parle de moi oui, il faut bien s’envoyer quelques fleurs). Cela a permis de très vite enchaîner sur la résolution de l’incident, mais cela aurait pu se passer autrement.

Enfin, cette API était en fait notre API de dev. L’API de prod, elle, allait très bien (détail que j’ai volontairement gardé pour la fin, il paraît que c’est du storytelling). Alors certes, l’impact fût minime, mais l’incident aurait tout de même pû arriver en production, avec les mêmes problématiques de remise en service. Et cela aurait pû coûter bien plus cher.

Préparer le futur

Maintenant que vous avez pu lister les problèmes rencontrés lors de la résolution de cet incident, en tant que bon DevOps, vous vous devez d’en tirer les leçons. Notez bien tout ce qui pourrait être amélioré, mais surtout, fixez-vous un plan ! Sinon, ce ne seront que de vastes phrases sans utilité.

« Tout objectif sans plan n’est qu’un souhait. » — Antoine de Saint-Exupéry

Dans mon cas, les trois leçons clés ont été les suivantes :

Consolidation de l’Infrastructure as Code : tout doit pouvoir être déployé en un clin d’oeil. C’est un chantier que je serai amené à compléter dans les mois qui suivirent (mais cette histoire, c’est pour une prochaine fois).
Amélioration du monitoring et de l’alerting : si cet incident devait de nouveau arriver, il nous faut être averti rapidement afin de réagir en vitesse.
Documentation plus claire et cohérente : n’importe quel membre de l’équipe doit pouvoir faire face à un tel incident, et cela commence par une documentation fiable et compréhensible.

Toutes ces leçons seront ensuite trackées en tant qu’issues GitHub, et je m’appliquerai à les compléter dans les mois qui suivirent (mais cette histoire, c’est pour une prochaine fois).

Conclusion

Vous l’aurez compris, un accident ça arrive. L’essentiel est qu’il soit bénéfique pour vous, et l’ensemble de votre organisation. Servez-vous en comme d’une opportunité d’apprendre et de consolider des failles qui n’était jusqu’alors pas détectées (certaines entreprises s’amusent d’ailleurs même à volontairement créer ce chaos).

Merci de m’avoir lu jusqu’au bout ! Je vous laisse ici, car j’ai d’autres infrastructures à supprimer !

Comment migrer son State de Terraform Cloud vers AWS S3 ?

Wed, 17 Dec 2025 07:30:00 +0200

Introduction

Quand j’ai commencé à utiliser Terraform (notamment pour le déploiement de mon blog), je me suis tourné vers l’utilisation de Terraform Cloud (ce nom a ensuite été modifié en HCP Terraform).

Terraform et le State

Si vous connaissez un peu Terraform, vous êtes sûrement familier avec le terme State, qui correspond en fait à l’état actuel de votre infrastructure, et qui permet à Terraform de savoir quelles modifications seront à prévoir si vous venez à modifier vos fichiers Terraform. Ce State est représenté par un fichier : terraform.tfstate.

Par défaut, Terraform stocke ce fichier en local sur votre machine, mais recommande d’utiliser un backend storage (comprenez : “stockez ce fichier ailleurs bon sang !”).

Évidemment, Terraform vous propose en premier la solution HashiCorp : Terraform Cloud. En créant un compte, vous pourrez gratuitement utiliser leur backend pour stocker vos fichiers de state. C’est tout naturellement ce que j’ai fait il y a quelques années.

La fin de Terraform Cloud

Jusqu’à cette semaine, où j’ai reçu ce mail d’HashiCorp.

Aïe ! Il fallait s’en douter, toutes les bonnes choses ont une fin ! L’option gratuite de l’époque n’existera bientôt plus, et il me faut donc faire un choix : mettre à jour mon “plan” HashiCorp, ou aller stocker mes states ailleurs.

En regardant de plus près leurs offres actuelles, HashiCorp propose encore une version gratuite, bien que limitée dans le nombre de ressources pouvant être déployées (500 aujourd’hui). C’est une offre assez généreuse, mais ne sachant pas comment celle-ci pourra évoluer, je prends la décision de déménager mes States une bonne fois pour toutes.

Adieu, Terraform Cloud !

Une alternative pour stocker vos states

Heureusement pour moi, il existe bien des moyens pour stocker son state Terraform, et ce grâce au Remote State.

Pour faire simple, il suffit de dire à Terraform où sera stocké votre fichier de state. On utilise pour cela le block backend.

Il en existe une bonne poignée, mais possédant un compte AWS sur lequel je déploie toutes mes ressources, je me dirige tout naturellement vers le backend S3.

Voici par exemple comment configurer un backend S3 avec Terraform.

terraform {
  backend "s3" {
    bucket = "mybucket"
    key    = "path/to/my/key/terraform.tfstate"
    region = "eu-west-1"
  }
}

Maintenant qu’une alternative a été trouvée, il est temps de passer à la migration !

Migration du state vers S3

Je vais prendre en exemple la migration du state dont je me sers pour déployer ce blog.

Actuellement, si on regarde mon workflow GitHub Actions de déploiement, on voit que je m’authentifie avec un token à mon compte Terraform Cloud. Cette partie-là n’aura plus de raison d’exister (du moins pour les credentials, il faudra toujours initialiser la CLI Terraform).

Ensuite, il va falloir créer un bucket S3 qui contiendra les futurs fichiers de state.

Enfin, il faudra rajouter un block backend à mon projet afin d’indiquer à Terraform de ne plus utiliser Terraform Cloud, mais bien S3 lorsqu’il viendra utiliser le state.

Attention, nous n’avons pas encore fini ! Car si je laisse ce bucket vide, la prochaine fois que j’essaierai de déployer mon blog, Terraform viendra se baser sur un state… inexistant ! Et pensera donc qu’aucune ressource n’a encore été déployée sur mon compte AWS. Terraform essaiera ainsi de recréer des ressources déjà existantes.

La dernière étape sera donc de récupérer le fichier de state de mon projet de blog, et de le déplacer dans mon bucket S3.

Je dois ensuite m’assurer que les informations que j’ai fournies dans le block backend correspondent bien à la réalité.

Une fois tout cela prêt, il est temps de tester et de déployer tout ça !

J’ai volontairement omis quelques étapes de cette migration (des variables de workspace à migrer, l’utilisation de GitHub Secrets pour le nom du bucket S3, l’ajout des credentials AWS dans la GitHub Actions, …) pour rendre cet article plus concis. Si vous voulez en voir plus, rendez-vous dans la Pull Request que j’ai ouverte pour réaliser cette migration.

Si tout s’est passé comme prévu, vous devriez voir apparaitre la phrase No changes. Your infrastructure matches the configuration. lors de votre terraform plan !

Conclusion

Il est toujours pénible de devoir réaliser des migrations sur des infrastructures qui sont déjà en place. Mais avec un peu de temps, et avec une bonne volonté, c’est le genre de tâche qui ne prend au final que quelques heures.

Alors, n’attendez pas le dernier moment, et lancez-vous !

Comment et pourquoi configurer AWS IAM Identity Center sur votre compte AWS

Wed, 19 Nov 2025 07:30:00 +0200

Introduction

Si vous jonglez avec plusieurs comptes AWS, ou même un seul compte avec différents utilisateurs, vous savez à quel point la gestion des accès peut devenir un véritable casse-tête. Créer des utilisateurs IAM individuels dans chaque compte, gérer leurs permissions, s’assurer que tout le monde utilise le MFA… Ouf, rien que d’y penser, ça peut donner des sueurs froides ! Et si je vous disais qu’il existe une solution élégante, centralisée et bien plus sécurisée pour gérer tout ça ? Mesdames et Messieurs, laissez-moi vous présenter IAM Identity Center !

Depuis que j’ai découvert et mis en place IAM Identity Center (que certains connaissent peut-être sous son ancien nom, AWS Single Sign-On ou AWS SSO), ma vie d’administrateur Cloud a radicalement changé. C’est le genre d’outil qui, une fois adopté, vous fait vous demander comment vous avez pu vivre sans.

Alors, qu’est-ce que c’est exactement, et pourquoi est-ce si génial ? C’est ce qu’on va voir ensemble.

IAM Identity Center : Késako ?

En termes simples, IAM Identity Center est un service AWS qui vous permet de gérer de manière centralisée l’accès à tous vos comptes AWS et à vos applications Cloud. Que vous ayez une poignée de comptes ou une organisation AWS tentaculaire avec des dizaines, voire des centaines de comptes, IAM Identity Center est là pour vous simplifier la tâche.

Il vous offre un point d’entrée unique (un portail d’accès web) pour vos utilisateurs, leur permettant d’accéder aux rôles et aux comptes auxquels ils ont droit, le tout avec une seule authentification.

Les avantages d’IAM Identity Center

Si je suis aussi enthousiaste, c’est parce que les bénéfices sont nombreux et significatifs. Pour vous citer les plus importants :

Single Sign-On (SSO) : Vos utilisateurs se connectent une seule fois via le portail AWS (ou via votre fournisseur d’identité existant si vous en avez un) et accèdent ensuite à tous les comptes et rôles qui leur sont assignés, sans avoir à se ré-authentifier pour chaque compte.
Gestion Centralisée : Vous gérez tous vos utilisateurs, groupes et leurs permissions (via des Permission Sets) depuis un seul endroit, même s’ils doivent accéder à des dizaines de comptes AWS différents.
Identifiants Temporaires : C’est l’un des points les plus importants ! Lorsque les utilisateurs accèdent à un compte via IAM Identity Center, ils obtiennent des identifiants temporaires à durée de vie limitée. Adieu les Access Keys IAM qui traînent et qui représentent un risque de sécurité majeur.
MFA (Multi-Factor Authentication) : Vous pouvez (et devriez !) imposer l’utilisation du MFA directement au niveau de la connexion à IAM Identity Center.

Si j’ai piqué votre curiosité et que vous souhaitez en savoir plus, je vous laisse consulter la documentation AWS sur IAM Identity Center. Pour ceux qui sont déjà convaincus, continuons ensemble !

Se Lancer avec IAM Identity Center

Mettre en place IAM Identity Center est étonnamment simple, surtout si vous utilisez l’annuaire intégré d’Identity Center comme source d’identité. Voici les étapes clés pour démarrer :

Configuration initiale : Rendez-vous dans la console AWS, et cherchez IAM Identity Center. Attention, choisissez bien votre région AWS pour héberger IAM Identity Center dès le départ, car il est actuellement complexe de changer la région d’IAM Identity Center une fois configuré. La configuration initiale est souvent guidée et rapide. Vous choisirez votre source d’identité (l’annuaire Identity Center, AWS Managed Microsoft AD, ou un fournisseur externe).
Création de groupes et d’utilisateurs : Définissez des groupes pertinents pour votre organisation (ex: Developers, Administrators, …). Créez ensuite vos utilisateurs et assignez-les à ces groupes. Si vous utilisez un IdP externe, cette étape consistera plutôt à synchroniser vos utilisateurs et groupes existants.
Création des Permission Sets : Un Permission Set est un ensemble de permissions (similaire à une policy IAM) que vous allez pouvoir réutiliser. Vous pouvez partir de policies managées par AWS (ex: AdministratorAccess ou ReadOnlyAccess) ou créer les vôtres.
Assignation des accès : C’est ici que la magie opère. Vous assignez un groupe (ou un utilisateur) à un ou plusieurs comptes AWS, en leur donnant le droit d’utiliser un Permission Set spécifique sur ces comptes. Par exemple, le groupe Developers peut avoir le Permission Set PowerUserAccess sur les comptes AWS de développement.
Imposer le MFA : Dans les paramètres d’IAM Identity Center, configurez le MFA pour qu’il soit obligatoire pour tous vos utilisateurs.
Partager l’URL d’accès AWS : Chaque configuration IAM Identity Center a une URL unique pour le portail d’accès (ex: d-xxxxxxxxxx.awsapps.com/start). C’est cette URL que vos utilisateurs mettront en favori pour se connecter.

Une fois connectés au portail, les utilisateurs verront la liste des comptes AWS et des rôles (définis par les Permission Sets) auxquels ils ont accès. Un clic, et ils sont dans la console du compte AWS choisi avec les bonnes permissions !

Ils peuvent aussi obtenir des identifiants temporaires pour la CLI. Mais d’ailleurs, comment faire pour se connecter à un compte AWS en CLI via IAM Identity Center ? Voyons ça ensemble !

Configurer les accès CLI

La documentation d’AWS pour configurer l’authentification CLI avec IAM Identity Center est assez claire, mais je vais tout de même vous décrire les étapes. Je pars du principe que vous avez déjà installé votre AWS CLI.

La commande pour initier la configuration est la suivante :

`1`	`aws configure sso`

Ensuite, vous allez devoir rentrer quelques informations propres à votre IAM Identity Center. Le plus important étant le SSO start URL (que vous pouvez trouver dans IAM Identity Center sous le nom de AWS access portal URL, URL qui finit par /start). Il faut ensuite rentrer la région dans laquelle se trouve votre configuration, quant au SSO registration scopes, vous pouvez laisser la valeur par défaut.

SSO session name (Recommended): default
SSO start URL [None]: https://xxxxxxxxxxxx.awsapps.com/start
SSO region [None]: eu-west-1
SSO registration scopes [sso:account:access]:

Si tout se passe bien, une fenêtre devrait s’ouvrir dans votre navigateur pour valider votre identité. Une fois cela fait, retournez dans votre terminal.

Dans mon cas, je ne possède qu’un seul compte AWS, et IAM Identity Center me le sélectionne par défaut. Mais vous aurez peut-être le choix dans le compte AWS à sélectionner. Idem pour le role.

Enfin, choisissez un nom de profil à utiliser pour vos futurs appels API. Je vous conseille d’utiliser default, ce qui vous permettra de ne pas avoir à rajouter --profile my-aws-profile à la fin de chacune de vos commandes.

The only AWS account available to you is: xxxxxxxxxxxx
Using the account ID xxxxxxxxxxxx
The only role available to you is: AdministratorAccess
Using the role name "AdministratorAccess"
Default client Region [None]: eu-west-1
CLI default output format (json if not specified) [None]: json
Profile name [AdministratorAccess-xxxxxxxxxxxx]: default
The AWS CLI is now configured to use the default profile.
Run the following command to verify your configuration:

aws sts get-caller-identity

Et voilà, le tour est joué !

Conclusion

Vous l’aurez compris, je suis un grand fan d’AWS IAM Identity Center. Il apporte une couche de sécurité indispensable tout en simplifiant considérablement la gestion des accès, que ce soit pour les administrateurs ou pour les utilisateurs.

C’est un véritable pilier pour une infrastructure AWS bien gérée et sécurisée. Si vous ne l’utilisez pas encore, je vous encourage vivement à explorer sa mise en place. C’est un investissement en temps minime pour des gains en sécurité et en efficacité énormes.

Votre infrastructure (et vos équipes de sécurité) vous diront merci !

Sur la piste de la ressource perdue - Mon enquête avec Athena et CloudTrail

Wed, 09 Jul 2025 12:30:00 +0200

Introduction

Récemment, j’ai dû jouer les détectives sur notre compte AWS.

Une ressource était là (un Cognito User Pool), bien présente, mais personne ne se souvenait de son origine. Et évidemment, pas de tags pour nous aider (si seulement ils avaient lu mon article sur le tagging des ressources AWS).

Ma mission, si je l’acceptais : découvrir qui l’avait créée. Le problème ? L’événement datait d’il y a environ quatre mois.

Mon premier réflexe a été de me tourner vers AWS CloudTrail. Et là, premier mur : l’historique des événements n’est consultable que sur les 90 derniers jours. Raté !

Heureusement, je savais que nos logs CloudTrail étaient archivés dans un bucket S3. Mon premier réflexe : télécharger manuellement les archives du bon mois, décompresser des dizaines de fichiers JSON, et lancer un Ctrl+F en priant très fort. Autant vous dire que ce n’est ni efficace, ni agréable, ni rapide.

Je me suis donc demandé s’il n’y avait pas un moyen plus simple de chercher dans cet amas de logs, et j’ai finalement trouvé la solution parfaite : AWS Athena.

Interroger vos logs S3 avec Athena

Pour ceux qui ne connaissent pas, AWS Athena est un service de requête interactif qui facilite l’analyse de données directement dans Amazon S3 en utilisant du SQL standard. En gros, vous pouvez faire des requêtes sur des fichiers (JSON, CSV, …) comme s’il s’agissait d’une base de données traditionnelle. Plus besoin de télécharger quoi que ce soit !

L’idée est donc de “mapper” nos logs CloudTrail stockés dans S3 à une table dans Athena. Pour cela, on utilise une seule requête CREATE EXTERNAL TABLE. En suivant la documentation d’AWS sur le sujet, j’ai lancé la requête suivante dans la console Athena.

Cette requête crée une table et utilise une fonctionnalité très pratique appelée “partition projection”. Cela permet à Athena de déduire l’emplacement des logs en fonction de la date, sans avoir à gérer manuellement les partitions. C’est d’autant plus pratique quand la structure est bien standardisée comme c’est le cas avec AWS CloudTrail.

CREATE EXTERNAL TABLE cloudtrail_logs_pp (
    eventversion STRING,
    useridentity STRUCT<
        arn:STRING
    >,
    eventtime STRING,
    eventsource STRING,
    eventname STRING,
    awsregion STRING,
    requestparameters STRING,
    responseelements STRING,
    additionaleventdata STRING,
    requestid STRING,
    eventid STRING,
    resources ARRAY<STRUCT<
        arn:STRING,
        accountid:STRING,
        type:STRING
    >>,
    eventtype STRING,
    eventcategory STRING
)
PARTITIONED BY (
    `timestamp` string
)
ROW FORMAT SERDE 'org.apache.hive.hcatalog.data.JsonSerDe'
STORED AS INPUTFORMAT 'com.amazon.emr.cloudtrail.CloudTrailInputFormat'
OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat'
LOCATION 's3://BUCKET-NAME/AWSLogs/ACCOUNT-ID/CloudTrail/REGION' -- Remplacez par le chemin de votre bucket S3
TBLPROPERTIES (
    'projection.enabled'='true',
    'projection.timestamp.format'='yyyy/MM/dd',
    'projection.timestamp.interval'='1',
    'projection.timestamp.interval.unit'='DAYS',
    'projection.timestamp.range'='2024/01/01,NOW', -- Remplacez par la date de début
    'projection.timestamp.type'='date',
    'storage.location.template'='s3://BUCKET-NAME/AWSLogs/ACCOUNT-ID/CloudTrail/REGION/${timestamp}' -- Remplacez par le chemin de votre bucket S3
)

Attention : N’oubliez pas de remplacer les URLs s3://... par le chemin exact de votre bucket S3 où sont stockés vos logs CloudTrail, et d’ajuster la propriété projection.timestamp.range à la période qui vous intéresse.

L’Heure de l’Enquête : Trouver l’Information

Une fois la table créée (ce qui ne prend que quelques secondes), le plus dur est fait ! Mon enquête pouvait enfin commencer.

Je cherchais à savoir qui avait créé un UserPoolClient pour Cognito à une date précise. Ma requête SQL ressemblait donc à ça :

SELECT
    eventTime,
    eventName,
    userIdentity.arn
FROM
    cloudtrail_logs_pp
WHERE
    timestamp = '2025/02/25'
    AND eventName = 'CreateUserPoolClient';

En quelques secondes, Athena a scanné les logs du jour demandé et m’a retourné le résultat.

J’avais l’heure exacte, l’événement, et surtout, l’ARN de l’utilisateur qui avait effectué l’action. Mission accomplie !

Le Verdict… et le Coupable

Le plus drôle dans cette histoire ?

Après avoir mis en place cette solution et retrouvé l’information si facilement, j’ai découvert que le “coupable” qui avait créé cette ressource il y a quatre mois… c’était moi. J’avais complètement oublié !

Au-delà de l’anecdote, cette expérience m’a confirmé une chose : prendre quelques minutes pour configurer Athena sur vos logs CloudTrail est un investissement incroyablement rentable. Vous vous offrez une capacité d’audit et de recherche sur le long terme qui vous sauvera des heures de recherche manuelle le jour où vous en aurez vraiment besoin. Ne faites pas comme moi, n’attendez pas d’être coincé pour le mettre en place !

Pourquoi taguer vos ressources AWS est indispensable ?

Tue, 24 Jun 2025 07:30:00 +0200

Introduction

Plus on déploie de services sur AWS, plus on commence à s’y perdre. Au début, on connaît par coeur tous les services qu’on utilise, le nombre de Lambdas ou d’EC2 qui sont lancées. Mais petit à petit, il est facile de ne plus savoir où donner de la tête, surtout lorsque différents projets s’accumulent. Retrouver rapidement quelles ressources appartiennent à quel projet, ou identifier celles qui n’ont pas été correctement nettoyées après un PoC, tout cela peut vite devenir un casse-tête. Et c’est sans parler de la vision des coûts !

Heureusement, il existe une pratique simple mais incroyablement puissante : le tagging.

Dans cet article, j’aimerais vous montrer qu’une bonne stratégie de tags est cruciale pour votre organisation, votre gestion des coûts, et pour la sécurité de votre compte AWS.

À vos marques. Prêts ? Taguez !

Pourquoi les tags sont-ils utiles ?

Imaginez des étiquettes sur des boîtes de déménagement. Sans elles, impossible de savoir ce qu’il y a dedans ou à quelle pièce elles appartiennent. Les tags sur AWS, c’est pareil ! Un tag est une information (sous la forme clé-valeur) que vous assignez à vos ressources (instances EC2, buckets S3, bases de données RDS, etc.).

Une bonne stratégie de tagging vous permet notamment de :

Identifier des ressources orphelines : C’est le grand classique. Une ressource sans tag Project ou Owner ? Il y a de fortes chances qu’elle ait été oubliée et qu’elle consomme des ressources (et donc de l’argent) pour rien. Lister les ressources non taguées (ou mal taguées) est une première étape essentielle pour faire le ménage.
Ventiler les coûts : En taguant vos ressources avec un identifiant de projet, de centre de coût, ou d’équipe, vous pouvez ensuite utiliser AWS Cost Explorer pour filtrer vos dépenses et comprendre précisément quels projets consomment le plus. Indispensable pour la refacturation interne ou simplement pour optimiser votre budget.
Automatiser des actions : Les tags peuvent servir de déclencheurs pour des scripts d’automatisation (par exemple, sauvegarder toutes les instances EC2 avec le tag Backup=Daily).
Gérer les accès et la sécurité : Le service AWS IAM peut utiliser les tags pour accorder des permissions granulaires.

Bref, taguer, c’est la base d’une bonne gouvernance Cloud. Pour plus de détails, je vous invite à consulter le guide de tagging proposé par AWS.

On peut fort heureusement associer plusieurs tags à une même ressource. Mais cela pose la question : combien de tags sont nécessaires ?

Cela va dépendre de votre entreprise et de chaque projet, mais globalement, il y a des tags qui ne font pas de mal, peu importe votre situation :

Project : Le nom du projet lié à la ressource. Généralement, le nom du repository GitHub fait l’affaire
Environment : L’environnement désiré (dev, val, prod, …). Même si vous avez des comptes AWS cloisonnés, cela vous permettra d’identifier si une ressource s’est perdue durant un déploiement
Owner : L’owner de la ressource. Cela pourrait être une personne, mais plus idéalement une équipe (frontend, backend, security, …)

Selon votre usage, vous aurez sûrement d’autres idées de tags, mais avec ceux-ci, ce sera déjà un bon début ! Et dans le doute, n’hésitez pas à consulter les best practices de tagging recommandées par AWS.

Voyons maintenant quelques cas concrets de l’utilité des tags dans AWS.

AWS Cost Explorer : Suivre les coûts grâce aux tags

L’un des avantages les plus concrets du tagging est la visibilité qu’il apporte sur vos dépenses. AWS Cost Explorer est l’outil de prédilection pour cela.

Une fois vos ressources correctement taguées (par exemple, avec le tag Project), vous devez activer ces tags pour l’allocation des coûts dans la console de gestion de la facturation AWS (Billing and Cost Management -> Cost Organization -> Cost Allocation Tags). Attention, il peut y avoir un délai avant que les tags activés n’apparaissent dans Cost Explorer.

Une fois activés, vous pouvez :

Filtrer par tag : Dans Cost Explorer, vous pouvez filtrer vos coûts par la valeur d’un tag spécifique.
Grouper par tag : Vous pouvez également choisir de grouper vos dépenses par tag. Cela vous donnera une vue d’ensemble de la répartition des coûts entre les différents projets, environnements, etc.
Créer des budgets basés sur les tags : Avec AWS Budgets, vous pouvez définir des seuils d’alerte pour les coûts associés à des tags spécifiques, vous aidant à éviter les mauvaises surprises.

Exemple de filtrage par tag pour mon blog : les coûts sont minimes, suis-je un expert FinOps ?

Cette capacité à disséquer votre facture AWS par tags transforme la gestion des coûts d’une corvée obscure en un exercice transparent et contrôlable. C’est un must pour toute organisation soucieuse de son budget Cloud. Vous pourrez désormais rajouter FinOps dans votre bio LinkedIn !

AWS Resource Explorer : Garder un œil sur les ressources déployées

Maintenant que l’on est convaincu de l’utilité des tags, comment fait-on pour lister toutes les ressources qui utilisent un tag précis ? Nous allons le voir ensemble avec une partie dans la console AWS, et une partie qui se passera dans le terminal (pour tous les geeks qui lisent cet article !).

L’exploration visuelle dans la console AWS

Si vous n’êtes pas encore familier avec AWS Resource Explorer, c’est le moment de le découvrir ! Ce service, relativement récent, vous permet de rechercher et de découvrir vos ressources AWS à travers toutes les régions de votre compte, en utilisant une interface simple, un peu comme un moteur de recherche.

L’avantage principal de Resource Explorer est sa capacité à vous donner une vue unifiée. Plus besoin de sauter de région en région. Vous activez l’indexation, et ensuite, vous pouvez rechercher vos ressources par nom, ID, et bien sûr… par tag !

C’est un excellent outil pour :

Avoir une vue d’ensemble rapide.
Explorer visuellement les ressources associées à un tag spécifique.
Identifier rapidement des ressources sans avoir à coder quoi que ce soit.

Pour l’utiliser, activez-le dans les régions souhaitées (ou toutes), laissez-le indexer vos ressources, puis utilisez la barre de recherche avec une syntaxe comme tag.key:Project tag.value:Cloud*.

Exemple de recherche par tag pour mon blog : seulement trois ressources permettent de gérer ce blog !

Une approche plus technique avec AWS CLI

Pour ceux qui, comme moi, aiment avoir la main via la ligne de commande, ou qui ont besoin d’automatiser ces recherches, l’AWS CLI reste une alliée de choix. Plus précisément, c’est le service resourcegroupstaggingapi qui va nous intéresser.

La commande clé est get-resources. Voici un exemple typique pour lister les ARN de toutes les ressources ayant le tag Project avec la valeur “Cloud Antoine Delia” :

1
2
3

aws resourcegroupstaggingapi get-resources \
    --tag-filters "Key=Project,Values=Cloud Antoine Delia" \
    | jq "[.ResourceTagMappingList[].ResourceARN]"

Ce qui nous donne :

1
2
3

[
  "arn:aws:s3:::antoiXXXXXXXXXXXXX"
]

Décortiquons un peu :

aws resourcegroupstaggingapi get-resources : C’est l’appel à l’API, jusqu’ici, tout va bien.
--tag-filters "Key=Project,Values=Cloud Antoine Delia" : C’est ici qu’on spécifie notre filtre. On cherche le tag Project qui a la valeur “Cloud Antoine Delia”. Vous pouvez ajouter plusieurs filtres.
| jq "[.ResourceTagMappingList[].ResourceARN]" : jq est un outil formidable pour manipuler du JSON en ligne de commande. Ici, on l’utilise pour extraire proprement la liste des ARN des ressources trouvées (vous pouvez vous en passer, mais pourquoi se compliquer la vie ?).

Eh attends une minute ! Dans la console, tu nous montres trois ressources, et là il n’y en a plus qu’une ! Elle est où l’arnaque ?

Habilement remarqué ! Il faut savoir que lorsque vous faites votre appel à l’API, vous utilisez une region par défaut. Or, si vous avez des ressources dans diverses régions, il faudra le spécifier. Ainsi, si l’on ajoute --region us-east-1 juste avant le pipe jq, on obtient bien nos deux ressources manquantes.

[
  "arn:aws:acm:us-east-1:6XXXXXXXXXXX0:certificate/f4ca3b13-XXXXXXXXXXXXX",
  "arn:aws:cloudfront::6XXXXXXXXXXX0:distribution/ERSXXXXXXXXXX"
]

Outre ce détail qu’il ne vous faudra pas oublier, cette commande est extrêmement puissante car vous pouvez l’intégrer dans des scripts pour :

Générer des rapports réguliers sur les ressources par projet.
Détecter automatiquement les ressources qui ne respectent pas votre politique de tagging.
Combiner avec d’autres commandes AWS CLI pour effectuer des actions sur les ressources listées.

Par exemple, vous pourriez ainsi lister toutes vos ressources d’un certain type (ex: toutes vos instances EC2) et de vérifier celles à qui il manque des tags essentiels.

Et si vous vous demandez si AWS n’offre pas déjà un service pour ça… C’est le cas ! Mais nous en parlerons dans un futur article (pour les curieux, je veux parler d’AWS Config).

AWS IAM : Sécuriser l’utilisation de vos ressources

Vos ressources sont déployées dans AWS, et vous souhaitez maintenant donner à une équipe la permission de gérer tout cela.

Seulement voilà, dans votre compte AWS, vous avez aussi des ressources critiques qui ne doivent surtout pas être compromises.

AWS IAM est là pour vous ! À l’aide d’une simple policy, vous pouvez spécifier que seules les ressources comportant un certain tag peuvent être modifiées par un utilisateur ou un groupe.

Prenons par exemple le cas suivant : vous aimeriez la possibilité à une équipe de démarrer ou stopper certaines instances EC2, mais de les empêcher d’accidentellement stopper une instance EC2 critique !

Il vous suffit d’ajouter la policy suivante à vos utilisateurs :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowStartStopEC2IfProjectCloud",
      "Effect": "Allow",
      "Action": [
        "ec2:StartInstances",
        "ec2:StopInstances"
      ],
      "Resource": "arn:aws:ec2:*:*:instance/*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/Project": "Cloud Antoine Delia"
        }
      }
    },
    {
      "Sid": "AllowDescribeToSeeInstances",
      "Effect": "Allow",
      "Action": "ec2:DescribeInstances",
      "Resource": "*"
    }
  ]
}

Ainsi, vos utilisateurs seront autonomes dans l’utilisation de leurs ressources, sans pour autant avoir la possibilité d’impacter d’autres ressources.

Conclusion

Vous l’aurez compris, une stratégie de tagging rigoureuse n’est pas une option, c’est une nécessité pour opérer sereinement sur AWS. Que ce soit sur le plan organisationnel, financier, ou encore dans la gestion de la sécurité, AWS vous donne les moyens de tirer pleinement parti de vos tags.

Alors, un petit conseil : si ce n’est pas déjà fait, définissez une politique de tagging claire dans votre organisation, appliquez-la, et utilisez ces outils pour vérifier régulièrement que tout est en ordre. Vous m’en remercierez plus tard !

AWS Lambda : La phase d'INIT devient payante - faut-il s'alarmer ?

Tue, 13 May 2025 07:30:00 +0200

Introduction

Ah, les Lambdas. Probablement le service AWS que j’affectionne le plus ! En moins de temps qu’il ne faut pour le dire, elles permettent de créer un petit script ou carrément un backend API hosté dans le Cloud, et tout cela à moindre coût avec le “pay as you go”. Mais cela serait-il trop beau pour être vrai ?

Il y a quelques jours, AWS a annoncé une modification dans la manière dont la phase d’initialisation des Lambdas est facturée. À partir du 1er août 2025, cette phase sera systématiquement incluse dans le calcul de la durée facturée, et ce, pour toutes les Lambdas.

Si vous n’étiez pas au courant, sachez que jusqu’à présent, si vous utilisiez des fonctions Lambdas avec un code packagé en ZIP avec des runtimes managés par AWS (comme Python, Node.js, etc.), la durée de cette phase INIT n’était pas facturée. C’était un petit “cadeau” de la part d’AWS (plutôt sympa de leur part). Mais toutes les bonnes choses ont une fin, et il faudra maintenant payer ce temps d’initialisation de nos Lambdas.

Alors, cela va-t-il rendre l’usage des Lambdas trop cher ? Et comment faire en sorte de réduire au maximum cette partie d’initialisation ? Je vous propose aujourd’hui de répondre à toutes ces questions !

Comprendre le cycle de vie d’une Lambda

Avant de plonger dans la facturation, c’est l’occasion de se rappeler du cycle de vie d’une Lambda.

Pour simplifier la lecture, je ne rentrerai pas dans les détails des Lambda Extensions et de Lambda SnapStart.

Cela se compose de trois phases principales :

INIT : C’est l’étape du “démarrage à froid” ou cold start. Quand une nouvelle instance de votre fonction doit être créée pour répondre à une requête, Lambda prépare le terrain. Cette phase dure au maximum 10 secondes.
INVOKE : C’est là que votre code (le handler de votre fonction) est exécuté pour traiter la requête.
SHUTDOWN : Quand l’environnement d’exécution n’est plus utilisé pendant un certain temps, la Lambda se “shutdown” pour libérer les ressources. Si une nouvelle requête arrive, la Lambda devra de nouveau passer par la phase d’INIT.

Pendant la phase INIT, votre Lambda fait plusieurs choses :

Récupère votre code (depuis S3 pour un ZIP, ou ECR pour une image Docker).
Configure l’environnement avec la mémoire allouée, le runtime choisi, etc.
Démarre le runtime (Runtime INIT).
Exécute le code statique de votre fonction (tout ce qui est en dehors du handler, par exemple l’initialisation de variables globales ou de boto3) (Function INIT).

Le point clé à retenir de tout cela, c’est que la phase INIT ne se produit que lors d’un démarrage à froid (ce fameux cold start). Si une requête arrive alors qu’un environnement d’exécution est déjà “chaud” (prêt et réutilisé), cette phase est sautée, et on passe directement à l’INVOKE. C’est ce qu’on appelle un “démarrage à chaud” (warm start), qui est bien plus rapide.

AWS ne communique pas sur son calcul pour passer une Lambda “warm” à “cold”.

Le changement de facturation en détail

Actuellement, la facturation des Lambdas repose sur deux éléments :

Le nombre de requêtes.
La durée d’exécution de votre code, arrondie à la milliseconde supérieure (le coût de cette durée dépend de la mémoire allouée à la fonction).

Jusqu’au 1er août 2025, pour ces fonctions en ZIP avec runtime managé, la durée de la phase INIT n’était pas comptée dans la “Durée Facturée” (Billed Duration). On pouvait le voir dans les logs CloudWatch :

# Avant le 1er août 2025
# Notez que la Billed Duration est l'arrondie au supérieur
# de la Duration sans tenir compte de la Init Duration
REPORT RequestId: xxxxx   Duration: 250.06 ms   Billed Duration: 251 ms   Init Duration: 100.77 ms

# Après le 1er août 2025
# La Billed Duration est maintenant l'arrondie au supérieur
# de la Duration + la Init Duration
REPORT RequestId: xxxxx   Duration: 250.06 ms   Billed Duration: 351 ms   Init Duration: 100.77 ms

Comme vous pouvez le voir, AWS prendra maintenant en compte votre Init Duration en plus de la Duration pour réaliser son calcul de la Billed Duration.

Quel impact sur la facture ?

Alors tout ça, c’est bien beau, mais allons-nous tous finir ruiner par ce changement ?

Prenons un exemple pour y voir plus clair. Imaginons une Lambda en Python configurée avec 1024 Mo de mémoire, déployée dans la région eu-west-1 (Irlande).

Supposons les points suivants :

La Lambda reçoit 10 millions d’invocations par mois.
Le taux de cold start est de 1% (moyenne fournie par AWS), soit 100'000 démarrages à froid par mois.
La durée moyenne de l’invocation (Duration) est de 3 secondes.
La durée moyenne de l’initialisation (Init Duration) est de 1 seconde.
Coût par requête : $0.20 par million de requêtes.
Coût de la durée (x86) : $0.0000166667 par GB-seconde.

Détails des calculs

Calcul du coût AVANT le 1er août 2025 :

Coût des requêtes : 10 millions req * ($0.20 / 1 million req) = $2.00
Coût de la durée :
- Invocations “à chaud” (9.9 millions) : Durée facturée = 3 secondes.
- Invocations “à froid” (100 000) : Durée facturée = 3 secondes (INIT non facturée).
- Durée facturée totale (secondes) : (9'900'000 * 3 s) + (100'000 * 3 s) = 29'700'000 secondes + 300'000 secondes = 30'000'000 secondes.
- Go-secondes totaux : 30'000'000 secondes * (1024 Mo / 1024 Mo) = 30'000'000 Go-s.
- Coût Durée : 30'000'000 Go-s * $0.0000166667/Go-s = $500.00
Coût total mensuel (Avant) : $2.00 + $500.00 = $502.00

Calcul du coût APRÈS le 1er août 2025 :

Coût des requêtes : $2.00 (inchangé)
Coût de la durée :
- Invocations “à chaud” (9.9 millions) : Durée facturée = 3 secondes.
- Invocations “à froid” (100 000) : Durée facturée = 3 secondes (Duration) + 1 seconde (Init Duration) = 4 secondes.
- Durée facturée totale (secondes) : (9'900'000 * 3 s) + (100'000 * 4 s) = 29'700'000 secondes + 400'000 secondes = 30'100'000 secondes.
- Go-secondes totaux : 30'100'000 secondes * (1024 Mo / 1024 Mo) = 30'100'000 Go-s.
- Coût Durée : 30'100'000 Go-s * $0.0000166667/Go-s = $501.67
Coût total mensuel (Après) : $2.00 + $501.67 = $503.67

Dans ce scénario précis, l’augmentation est seulement de $1.67 par mois. C’est effectivement minime, et cela confirme la communication d’AWS. Mais faites quand même attention, car l’impact réel dépendra fortement de :

La mémoire allouée à vos Lambdas (plus de mémoire = coût par ms plus élevé).
La durée réelle de votre phase INIT.
Votre taux de cold start (peut être plus élevé si votre trafic est irrégulier).

Il est donc judicieux de vérifier avec vos propres chiffres !

Je vous mets ci-dessous un petit script qui vous permettra de rapidement tester cela de votre côté.

Script Python

def calculate_lambda_costs(
    total_invocations_per_month: int,
    cold_start_rate: float,
    average_invocation_duration_sec: float,
    average_init_duration_sec: float,
    allocated_memory_gb: float,
    cost_per_million_requests: float = 0.20,
    cost_per_gb_second: float = 0.0000166667,
):
    num_cold_starts = total_invocations_per_month * cold_start_rate
    num_warm_starts = total_invocations_per_month - num_cold_starts

    request_cost = (total_invocations_per_month / 1_000_000) * cost_per_million_requests

    # Duration cost BEFORE
    billed_duration_warm_starts_sec_before = num_warm_starts * average_invocation_duration_sec
    billed_duration_cold_starts_sec_before = num_cold_starts * average_invocation_duration_sec

    total_billed_duration_sec_before = billed_duration_warm_starts_sec_before + billed_duration_cold_starts_sec_before
    total_gb_seconds_before = total_billed_duration_sec_before * allocated_memory_gb / 1.024
    duration_cost_before = total_gb_seconds_before * cost_per_gb_second

    total_monthly_cost_before = request_cost + duration_cost_before

    # Duration cost AFTER
    billed_duration_warm_starts_sec_after = num_warm_starts * average_invocation_duration_sec
    billed_duration_cold_starts_sec_after = num_cold_starts * (average_invocation_duration_sec + average_init_duration_sec)

    total_billed_duration_sec_after = billed_duration_warm_starts_sec_after + billed_duration_cold_starts_sec_after
    total_gb_seconds_after = total_billed_duration_sec_after * allocated_memory_gb / 1.024
    duration_cost_after = total_gb_seconds_after * cost_per_gb_second

    total_monthly_cost_after = request_cost + duration_cost_after

    return total_monthly_cost_before, total_monthly_cost_after


def display_results(cost_before, cost_after):
    cost_difference = cost_after - cost_before
    print(f"\nMonthly cost increase: ${cost_difference:.2f}")
    if cost_difference > 0:
        percentage_increase = (cost_difference / cost_before) * 100 if cost_before > 0 else float("inf")
        print(f"Percentage increase: {percentage_increase:.2f}%")


if __name__ == "__main__":
    print("AWS Lambda Cost Calculator (before/after Init Duration pricing change)")
    print("Please enter the values for your scenario or press Enter to use default values.\n")
    default_invocations = 10_000_000
    default_cold_start_rate = 0.01  # 1%
    default_invocation_duration = 3.0  # seconds
    default_init_duration = 1.0  # seconds
    default_memory_gb = 1.024  # 1024 MB (1.024 GB)

    try:
        invocations_str = input(f"Total invocations per month (default: {default_invocations:,}): ")
        total_invocations_input = int(invocations_str) if invocations_str else default_invocations

        cold_start_rate_str = input(f"Cold start rate (e.g., 0.01 for 1%, default: {default_cold_start_rate}): ")
        cold_start_rate_input = float(cold_start_rate_str) if cold_start_rate_str else default_cold_start_rate

        invocation_duration_str = input(f"Average invocation duration in seconds (default: {default_invocation_duration}): ")
        invocation_duration_input = float(invocation_duration_str) if invocation_duration_str else default_invocation_duration

        init_duration_str = input(f"Average initialization duration in seconds (default: {default_init_duration}): ")
        init_duration_input = float(init_duration_str) if init_duration_str else default_init_duration

        memory_gb_str = input(f"Memory allocated to Lambda in GB (e.g., 0.512 for 512MB, default: {default_memory_gb}): ")
        memory_gb_input = float(memory_gb_str) if memory_gb_str else default_memory_gb

        cost_before, cost_after = calculate_lambda_costs(
            total_invocations_per_month=total_invocations_input,
            cold_start_rate=cold_start_rate_input,
            average_invocation_duration_sec=invocation_duration_input,
            average_init_duration_sec=init_duration_input,
            allocated_memory_gb=memory_gb_input,
        )

        display_results(cost_before, cost_after)

    except ValueError:
        print("\nError: Please enter valid numbers.")
    except Exception as e:
        print(f"\nAn unexpected error occurred: {e}")

Comment surveiller votre phase INIT et estimer l’impact ?

Un script, c’est bien, mais si vous avez un paquet de Lambdas à checker, vous risquez de vous épuiser à la tâche.

Heureusement, AWS nous donne quelques outils pour vérifier ça efficacement. En effet, comme vu plus haut, chaque Lambda va faire un REPORT de son Init Duration. Il nous est donc facile d’aggréger tout cela dans CloudWatch Logs Insights. Et cerise sur le gâteau, AWS nous offre même la requête qui va bien.

filter @type = "REPORT" and @billedDuration < (@duration + @initDuration) 
| stats sum((@memorySize/1000000/1024) * (@billedDuration/1000)) as BilledGBs, 
sum((@memorySize/1000000/1024) * ((ceil(@duration + @initDuration) - @billedDuration)/1000)) as UnbilledInitGBs, 
(UnbilledInitGBs/ (UnbilledInitGBs+BilledGBs)) as Ratio

Gardez en mémoire que CloudWatch Logs Insights vous est facturé $0.005 par GB de data scanné (source)

Plus qu’à lancer cette requête sur vos Lambdas (en utilisant le prefix /aws/lambda), et vous obtiendrez le résultat suivant :

BilledGBs	UnbilledInitGBs	Ratio
512.8007	86.6699	0.1446

Cette requête vous donne ainsi trois informations clés :

BilledGBs : Le total de Go-secondes actuellement facturé.
UnbilledInitGBs : Le total de Go-secondes consommés pendant la phase INIT qui n’étaient pas facturés auparavant.
Ratio : Le pourcentage que représentent ces Go-secondes INIT non facturés par rapport au total des Go-secondes consommés.

Dans notre exemple, la part du coût de l’INIT représente 14% de notre future facture ! Selon votre facture actuelle, cela pourrait être non négligeable.

Comprendre et optimiser sa Lambda

Bon, vous savez que vous allez devoir sortir la carte bleue. Mais n’y a-t-il pas un levier d’action pour diminuer cette augmentation dans votre facture ?

Je vous donne ici quelques conseils pour utiliser cette phase INIT au mieux et ainsi réduire vos futurs coûts.

Utiliser stratégiquement la phase INIT

Votre premier réflexe serait peut-être de vous dire qu’il faudrait enlever tout ce code INIT (celui hors du handler) pour le mettre dans votre handler. Comme ça, plus de facturation de l’INIT ! Mais non seulement vous ne feriez que déplacer le problème (car l’exécution de ce code vous sera tout de même facturé), cela sera encore pire, car maintenant, mêmes vos executions de Lambda “warm start” devront traiter ce code !

Car oui, rappelons que le code dans la phase INIT est exécuté uniquement pendant les “cold start”. C’est donc l’endroit idéal pour faire des opérations d’initialisation coûteuses qui pourront être réutilisées par les invocations suivantes (“warm start”). Cela est même recommandé par AWS. Ainsi, cette phase d’INIT est parfaite pour :

Importer des librairies ou dépendances lourdes.
Établir des connexions à d’autres services AWS (S3, DynamoDB, etc.) via les SDKs (boto3 pour Python).
Créer des pools de connexions à des bases de données.
Récupérer des paramètres ou des secrets depuis Systems Manager Parameter Store ou Secrets Manager.

Maximisez cette phase d’inititalisation pour réduire ainsi le temps d’exécutions des Lambdas qui elles tourneront en “warm start”.

Optimiser la taille du package

C’est souvent le levier le plus simple, car parfois, on importe un peu tout et n’importe quoi dans notre Lambda. Alors, soyez sûr de n’inclure que des dépendances strictement nécessaires. Veillez également à exclure tout ce qui est lié à votre environnement de développement (je ne vous dis pas le nombre de fois que j’ai trouvé un dossier node_modules ou tests dans des Lambdas…). Enfin, n’hésitez pas à consulter les articles d’AWS, car certains taclent directement le sujet des cold start.

Lambda SnapStart

Disponible pour les runtimes Java, .NET et Python, SnapStart est une fonctionnalité très intéressante pour combattre les “cold start”. Quand vous l’activez, Lambda prend un “snapshot” de l’environnement d’exécution initialisé après la première phase INIT. Pour les “cold start” suivants, la Lambda va restaurer ce snapshot au lieu de refaire toute la phase d’INIT, ce qui vous fera gagner pas mal de temps.

J’imagine qu’à la lecture de cette fonctionnalité, vous vous dites “mais enfin c’est super, je vais activer cette feature sur toutes mes Lambdas !”. Sauf qu’il y a quelques subtilités à connaître.

Premièrement, SnapStart n’est pour l’instant compatible qu’avec des versions bien précises de certains langages (Python 3.12 minimum, NodeJS pas supporté, …). Idem pour les régions, seulement 9 d’entre elles supportent cette feature pour Python et .NET. Enfin, cette feature n’est pas gratuite. Vérifiez bien le coût que cela pourrait engendrer si vous souhaitez l’activer sur vos Lambdas. ialisation).

Provisioned Concurrency

Si votre application a un trafic prévisible ou si la latence des cold start n’est pas envisageable, vous pouvez utiliser ce qu’on appelle la “Provisioned Concurrency”. Vous demandez à votre Lambda de garder un certain nombre d’environnements d’exécution pré-initialisés (chauds) en permanence.

Avantage : les requêtes arrivant sur ces instances provisionnées ne subissent jamais de cold start. La phase INIT est faite en amont, avant même la première requête.

Inconvénient : vous payez pour la durée pendant laquelle ces environnements sont provisionnés, qu’ils reçoivent des requêtes ou non. La phase INIT est d’ailleurs facturée lors de la pré-initialisation.

Là aussi, à vous de voir si cela vaut le coup d’activer cela sur certaines de vos Lambdas clées !

Conclusion

Le changement de facturation de la phase INIT de Lambda qui arrive le 1er août 2025 est avant tout une standardisation. Pour la majorité des Lambdas, cela signifie que la durée de cette phase sera désormais ajoutée à la durée facturée lors des cold start.

Même si l’impact financier sera probablement faible pour vous, c’est une excellente occasion de :

Comprendre le cycle de vie de vos Lambdas et ce qui se passe pendant l’initialisation.
Mesurer la durée de la phase INIT de vos fonctions critiques grâce aux outils CloudWatch.
Optimiser cette phase si nécessaire, en réduisant la taille de vos packages, en utilisant SnapStart, ou en envisageant la Provisioned Concurrency pour des cas spécifiques.

Alors, n’attendez pas le mois d’août ! Familiarisez-vous avec CloudWatch Logs Insights dès maintenant. Cela vous permettra d’identifier les Lambdas à optimiser en priorité et d’éviter toute mauvaise surprise sur votre facture AWS.

Comment j'ai automatisé la création de mon blog dans le Cloud

Tue, 04 Mar 2025 07:30:00 +0100

Le commencement et la fin

Quand j’ai envisagé de créer un blog pour la première fois, j’étais encore étudiant dans mon école d’ingénieurs. Et le monde des sites internets et des blogs était encore quelque chose de nouveau pour moi. Et lorsque je me suis finalement lancé dans l’aventure du blogging, c’est tout naturellement que je me suis tourné vers ce qui semblait être la meilleure solution à l’époque : WordPress.

Quoi que l’on en dise, WordPress est une solution relativement simple d’usage pour les débutants qui souhaitent créer leur premier site internet. Et ça tombe bien, car j’en faisais parti !

Alors, armé d’un tout nouveau compte chez OVH, j’ai pû mettre en ligne mon blog personnel en quelques cliques !

Et puis, quelques années plus tard, quand me vint l’idée de publier un blog dédié à des sujets professionels, là encore, j’ai fait appel à mon bon vieil ami WordPress.

Les mois passèrent, et l’idyle que je vivais avec WordPress commençait petit à petit à se ternir. Certes, rajouter des articles à travers l’UI de WordPress était pratique, mais pour ce qui était de gérer les backups, c’était une autre paire de manches. En plus, WordPress requiert une base de données pour fonctionner, ce qui rendait le tout très volumineux pour quelques articles, sans compter la facture qui venait avec.

Je me rendais alors compte que, pour un blog aussi simple, et avec si peu de visites, il y avait certainement un moyen d’améliorer les choses.

Le début d’un nouveau plan

Je vais vous raconter ici le cheminement qui m’a amené au renouveau de mon blog sur lequel vous vous trouvez aujourd’hui. Si vous êtes seulement intéressé par les détails techniques, vous pouvez avancer à la prochain section. Sinon, bonne lecture !

La découverte d’Hugo

Avant de me mettre en quête d’un nouvel outil pour mon blog, j’ai d’abord réfléchi à ce dont j’avais réelement besoin.

Mon blog était en fait assez rudimentaire : une page d’accueil qui listait les différents articles, pas de JavaScript tarabiscoté dans les parages, et aucun besoin d’un backend pour gérer une API. Au final, l’utilisation d’une base de données était-elle nécessaire ?

Il y avait aussi une chose importante à garder en mémoire. Je suis un ingénieur, ce qui fait de moi par définition, un bien piètre designer. Je voulais à tout prix éviter d’avoir à gérer le CSS de mon blog : je voualais me concenter sur le contenu, plutôt que sur le style.

J’ai donc commencé mes recherches, dans l’espoir de trouver un outil qui répondrait à ces critères. Et il ne m’a pas fallu bien longtemps avant de tomber sur la perle rare : Hugo.

À peine eus-je atterri sur le site d’Hugo que je fus accueilli par cet intriguant message : Le framework le plus rapide du monde pour générer des sites web. On peut dire que cela a piqué ma curiosité, et je me pressa d’aller fouiller dans la documentation. Et je n’allais pas être déçu.

Hugo se charge de convertir des articles au format markdown (comme l’on trouve sur les README de GitHub par exemple) vers le format HTML. Qui plus est, il existe une miriade de thèmes mis à disposition, ce qui me laissait l’embarras du choix, sans avoir besoin de designer quoi que ce soit !

Sans perdre une seconde, je m’empressai de convertir mon blog WordPress vers un site Hugo (j’ai utilisé pour ça un super petit script intitulé wordpress-to-hugo-exporter qui convertit une base de données WordPress en fichiers markdown avec l’arborescence requise pour Hugo).

Mon site Hugo était désormais prêt ! Il fallait maintenant trouver un moyen de l’héberger quelque part.

Un hébergeur à la hauteur : AWS

En même temps que je me creusais la tête pour trouver une alternative pour mon blog, j’ai eu une opportunité professionnelle qui m’a amené à travailler dans une entreprise spécialisée dans le Cloud, et plus particulièrement AWS.

À l’époque, le Cloud était tout nouveau pour moi. Mais j’en entendais tellement parler, que je voulais connaître la raison de cet engouement. Était-ce vraiment un “game-changer”, comme certains le disaient, ou était-ce encore un de ces mots-clés techniques qui faisait le buzz ?

Pour vous la faire courte, AWS était (et est toujours) absolument incroyable ! Ce n’était pas seulement la découverte d’un nouvel outil, il s’agissait là d’un changement de paradigme qui ne me ferait plus jamais aborder un problème de la même manière (si vous ne connaissez pas AWS et pensez que j’en fais trop, attendez de vous y mettre…).

Plus j’en apprenais sur AWS et la multitude de services qui le composait, plus je me disais : n’y a-t-il pas un moyen pour moi d’utiliser le Cloud pour mon blog ?

Avec cette idée en tête, je commençais à me renseigner sur toutes les options qu’offrait AWS. Et compte tenu de ma récente découverte d’Hugo, mon site n’avait ni besoin de PHP, ni d’une base de données pour fonctionner. Il s’agissait maintenant d’un site statique qui, à première vue, pouvait très bien être déployé dans un bucket S3.

Et non seulement AWS offre une documentation sur l’hébergement d’un site statique dans un bucket S3, mais le coût de stockage d’un site si léger ne représentait que quelques centimes.

J’avais trouvé là une manière simple et peu coûteuse d’héberger mon site.

Le dernier point qui me chiffonait, est que pour mettre en place tout cela, je devais créer un bucket AWS S3, le configurer convenablement, rajouter le CDN AWS CloudFront, prendre en compte les certificats via AWS ACM, et finalement créer une entrée DNS dans AWS Route53. Tant d’actions qui, si réalisées manuellement, pouvaient être difficiles à reproduire si jamais je venais à accidentellement supprimer mon compte AWS.

Il me fallait donc maintenant un moyen simple et robuste de configurer cette infrastructure.

Terraform à la rescousse

Quand vous commencez à apprendre le Cloud, vous allez généralement entendre parler d’Infrastructure as Code.

Le principe est simple : décrire son infrastructure Cloud avec… du code ! (oui, comme son nom l’indique).

L’avantage d’utiliser un outil d’IaC, c’est que vous allez pouvoir garder en mémoire les changements effectués sur votre infrastructure, et pouvoir ainsi avoir un historique de toutes les modifications effectuées (un peu comme vous pouvez le faire avec du code classique sur GitHub).

Imaginons par exemple que quelqu’un décide de changer la configuration d’un service AWS. Cette personne se connecte sur la console AWS et effectue ces modifications. Mais après plusieurs essais infructueux, cette personne décide de laisser tomber pour le moment, et de revenir en arrière. Mais voilà, elle n’est plus vraiment sûr de la manière dont le service était configuré au départ ! Et à moins d’avoir pris note de l’état initial, cette personne n’a plus qu’à deviner à coups de plusieurs essais l’état dans lequel remettre ce service.

Tout cela aurait pû être évité si le service avait initialement été configuré avec un outil d’Infrastructure as Code. Si tel avait été le cas, un petit coup de déploiement automatique aurait fait l’affaire !

Des outils d’IaC, il en existe un paquet. Mais comment ne pas parler du plus populaire, de celui qui a rendu cette pratique commune dans le milieu du Cloud : Terraform.

Terraform est donc un outil d’Infrastructure as Code avec une approche déclarative, ce qui signifie que c’est à vous de déclarer l’état dans lequel vous souhaitez déployer votre infrastructure. Pour cela, il faut utiliser un langage bien particulier : le hcl (pour HashiCorp Configuration Language). Voici par exemple la création d’un bucket S3 via Terraform.

resource "aws_s3_bucket" "example" {
  bucket = "my-tf-test-bucket"

  tags = {
    Name        = "My bucket"
    Environment = "Dev"
  }
}

Revenons maintenant à mon blog ! Terraform me semblait l’outil parfait pour configurer mon infrastructure qui accueillerait mon blog. Je n’avais plus qu’à passer par une étape d’architecture pour savoir de quels services AWS j’aurais besoin et comment les connecter entre eux, avant de mettre la main dans le code pour définir tout cela en langage Terraform.

Voici d’ailleurs le diagramme d’architecture que j’ai initialement crée pour l’occasion.

Tout cela était parfait, mais je me rendis vite compte d’une chose. À chaque fois que j’allais rajouter un article, ou que je devais modifier mon infrastructure, il me fallait cloner le projet sur mon ordinateur, et effectuer tout un tas d’opérations manuelles.

Autant vous dire que cela ne me plaisait pas du tout, et je comptais bien y remédier !

Oubliez les copier-coller avec GitHub Actions

Comme je le disais juste au-dessus, mon site était fin prêt. La dernière étape qui me manquait concernait le déploiement.

Pour l’instant, quand je voulais créer un nouvel article, il me fallait build le site Hugo à la main, et déplacer les fichiers générés dans mon bucket S3. Quel terrible gâchis de temps et d’énergie !

J’ai donc creusé le sujet des pipelines CI/CD afin de me rendre la vie plus simple (si le sujet vous intéresse, je vous conseille mon article sur la mise en place d’une stratégie CI/CD). Et bien que Jenkins essayait à tout prix de se distinguer, je suis parti sur ce qui semblait être le plus logique : GitHub Actions.

Les GitHub Actions sont en fait des pipelines CI/CD qui sont définies directement dans votre repository GitHub. Le gros avantage, est que vous n’avez pas besoin de créer un compte supplémentaire ou d’installer quoi que ce soit, tout est inclus ! En plus de ça, GitHub Actions utilise une syntaxe YAML très facile à comprendre (contrairement à Jenkins et son groovy des enfers !).

C’est donc assez facilement que j’ai pû créer une pipeline qui me reconfigure Terraform si mon infrastructure a été modifiée, et qui me build et deploy automatiquement mon blog sur mon bucket S3 en cas de modifications ou ajout d’un article.

Toutes les steps de la pipeline sont au vert, mission accomplie !

Côté technique : L’état actuel des choses

Mon blog est désormais automatisé et se déploie sur AWS automatiquement !

Si vous voulez plonger directement dedans, tout est publique sur mon repository GitHub : https://github.com/antoinedelia/cloud-optimist

Mais laissez-moi détailler un peu tout ça.

Structure du projet

La structure de mon projet est comme suit :

cloud-optimist/
├── .github/
│   └── workflows/
│       └── main.yml  # GitHub Actions
├── cloud/
│   └── ...  # Mon blog Hugo
├── terraform/
│   └── ...  # La configuration Terraform
└── README.md

Comme vous le voyez, je sépare ce projet en trois dossiers clés :

.github : contient le fichier main.yml qui définit les étapes CI/CD de la GitHub Actions
cloud : contient mon blog Hugo
terraform : contient toute l’infrastructure Terraform

La GitHub Actions

Ma GitHub Actions est assez simple, et se décompose en plusieurs étapes.

Les étapes de préparation

Regardons d’abord le haut du fichier.

name: 'Build and Deploy'

on:
  push:
    branches:
    - master
  pull_request:

jobs:
  build-and-deploy:
    name: 'Build & Deploy'
    runs-on: ubuntu-latest
    environment: production

    defaults:
      run:
        shell: bash
        working-directory: cloud

Ici, je dis à GitHub de lancer la pipeline uniquement sur la branch master, ou s’il s’agit d’une Pull Request. Je vous rassure, je ne déplois rien en production via une Pull Request. Vous verrez un peu plus bas, que cela me permet uniquement de build mon blog afin de tester que tout va bien, mais le déploiement ne sera effectué qu’une fois les changements mergés sur la branch master.

J’indique également à GitHub d’utiliser bash, et de se baser par défaut dans le dossier cloud.

Voyons maintenant la suite :

    steps:
    - uses: actions/checkout@v3
    - uses: dorny/paths-filter@v2
      id: filter
      with:
        filters: |
          web:
            - 'cloud/**'
          terraform:
            - 'terraform/**'

Cette première étape est cruciale si vous voulez accélérer vos temps de CI/CD ainsi qu’économiser de l’argent.

Je me sers de l’actions dorny/paths-filter qui me permet de détecter quels fichiers ont été modifiés lors du dernier commit. Dans mon cas, je regarde en particulier les dossiers cloud et terraform. Ainsi, si je ne détecte pas de changements côté Terraform, aucun besoin de lancer l’étape qui va reconfigurer mon infrastructure. Idem, si le dossier cloud est intact, inutile de build et deploy le blog. Cela vous sauvera quelques centimes liés au coût de transfert de fichiers vers AWS (pas la peine de me remercier !).

La section suivante parle d’elle-même.

    # Checkout the repository to the GitHub Actions runner
    - name: Checkout
      uses: actions/checkout@v2
      
    - name: Update Git Submodules
      working-directory: ./
      run: git submodule update --init --recursive

Je viens récupérer le contenu de mon repository et m’assure de mettre à jour les submodules. Cette dernière étape me servait du temps où j’utilisais les submodules pour mes thèmes Hugo. J’utilise désormais les Hugo Modules, et je pourrais donc zapper cette étape.

Les étapes Terraform

Passons à la partie Terraform :

    # Install the latest version of Terraform CLI and configure the Terraform CLI configuration file with a Terraform Cloud user API token
    - name: Setup Terraform
      if: steps.filter.outputs.terraform == 'true'
      uses: hashicorp/setup-terraform@v1
      with:
        cli_config_credentials_token: ${{ secrets.TF_API_TOKEN }}

    # Initialize a new or existing Terraform working directory by creating initial files, loading any remote state, downloading modules, etc.
    - name: Terraform Init
      if: steps.filter.outputs.terraform == 'true'
      working-directory: ./terraform
      run: terraform init

    # Checks that all Terraform configuration files adhere to a canonical format
    - name: Terraform Format
      if: steps.filter.outputs.terraform == 'true'
      working-directory: ./terraform
      run: terraform fmt -check

    # Generates an execution plan for Terraform
    - name: Terraform Plan
      if: steps.filter.outputs.terraform == 'true'
      working-directory: ./terraform
      run: terraform plan

      # On push to master, build or change infrastructure according to Terraform configuration files
    - name: Terraform Apply
      working-directory: ./terraform
      if: steps.filter.outputs.terraform == 'true' && github.ref == 'refs/heads/master' && github.event_name == 'push'
      run: terraform apply -auto-approve

C’est déjà bien plus long ! Analysons ça étape par étape.

La première chose qui devrait attirer votre attention, c’est cette ligne :

`1`	`if: steps.filter.outputs.terraform == 'true'`

Vous vous rappelez, c’est ce qui permet de dire si des fichiers ont été modifiés dans le dossier terraform. Je vérifie donc ici si j’ai besoin de lancer ces étapes ou non.

Ensuite, je lance quelques commandes basiques de Terraform : un terraform init pour initialiser mon projet, un terraform fmt -check pour m’assurer que mon code est tout joli, et enfin un terraform plan pour voir les changements à effectuer.

Reste une dernière étape, et pas des moindres : le terraform apply -auto-approve, qui permettra de déployer les changements. Mais si vous êtes attentifs, vous remarquerez que j’ai rajouté deux conditions :

`1`	`github.ref == 'refs/heads/master' && github.event_name == 'push'`

Cela me garantit que cette étape ne sera uniquement lancée si l’action est un push sur la branch master. Ainsi, aucun risque de déploiement inopportun si je décide de travailler sur une autre branch ou sur une Pull Request. Ouf !

Les étapes Hugo et AWS

Maintenant que mon infrastructure est au point, il est temps de publier mon blog !

    - name: Build
      uses: actions/setup-node@v2
      if: steps.filter.outputs.web == 'true'
    - run: sudo wget https://github.com/gohugoio/hugo/releases/download/v0.142.0/hugo_extended_0.142.0_linux-amd64.deb -O hugo.deb
    - run: sudo dpkg --install ./hugo.deb
    - run: hugo

    - name: Deploy to AWS
      uses: jakejarvis/s3-sync-action@master
      if: steps.filter.outputs.web == 'true' && github.ref == 'refs/heads/master' && github.event_name == 'push'
      with:
        args: --acl public-read --follow-symlinks --delete
      env:
        AWS_S3_BUCKET: ${{ secrets.AWS_S3_BUCKET }}
        AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
        AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        AWS_REGION: 'eu-west-1'
        SOURCE_DIR: 'cloud/public/'

Comme pour Terraform, nous vérifions si des modifications ont été effectuées au niveau du blog.

`1`	`if: steps.filter.outputs.web == 'true'`

Ensuite, je récupère une version extended d’Hugo directement depuis la release GitHub, ici la version v0.142.0. Je l’installe et build mon site en lançant la commande hugo.

Cette étape pourrait être simplifiée avec l’utilisation de l’actions peaceiris/actions-hugo

Enfin, j’utilise l’actions jakejarvis/s3-sync-action (je me rends compte en écrivant cet article que cette actions a été archivée quelques jours plus tôt, aïe ! – je rajouterai un edit plus tard pour parler d’une alternative) pour déplacer mon blog vers mon bucket S3.

Bien sûr, il vous faudra stocker vos credentials au niveau de votre repository GitHub pour autoriser cette opération vers AWS, mais rien de bien sorcier !

La partie Terraform

Concernant la partie Terraform, je vais essayer d’être bref, car il n’y a rien de bien compliqué.

Une particularité dans mon cas, c’est que j’aime séparer mes fichiers .tf en fonction des services AWS utilisés, plutôt que d’avoir un unique fichier main.tf qui peut vite devenir difficile à lire. J’ai donc un fichier s3.tf pour les ressources liées au service S3, un cloudfront.tf pour tout ce qui est lié au service CloudFront, etc.

Un détail important, c’est qu’il est nécessaire de définir à minima la region us-east-1, car c’est dans cette region que vous devez créer vos certificats ACM. Pour le reste, toutes mes ressources sont créées dans la region eu-west-1. J’utilise pour cela les alias Terraform. Voici un exemple :

# La configuration par défaut : les ressources qui commencent par `aws_` utiliseront ce provider
provider "aws" {
  region = "eu-west-1"
}

provider "aws" {
  region = "us-east-1"
  alias  = "us_east_1"
}

resource "aws_s3_bucket" "site" {
  bucket        = var.bucket_name
  force_destroy = true
}

resource "aws_acm_certificate" "cert" {
  provider                  = aws.us_east_1  # Utilise le provider AWS dans us-east-1 via son alias
  domain_name               = var.domain_name
  subject_alternative_names = ["*.${var.domain_name}"]
  validation_method         = "DNS"
}

La partie Hugo

Mon blog Hugo se base sur le theme Stack. Il existe d’ailleurs un template GitHub qui vous permet en un clic de récupérer le squelette du blog, et de l’adapter selon vos envies, ou de tout simplement vous concentrer directement sur vos articles.

Pas grande chose de plus à dire sur cette partie, si ce n’est que je vous encourage à voir le fonctionnement des Hugo Modules, ce qui vous évitera de gérer vos thèmes via un submodule (et qui vous simplifiera la vie lors de la mise à jour du thème).

Pistes d’améliorations

Bien que je sois très satisfait du résultat final, j’ai noté quelques points qui pourraient être améliorés dans le futur.

D’abord, j’ai vu qu’Hugo dispose d’une commande deploy qui est capable de déployer directement un blog sur un bucket S3. Parfait ! Je dois donc creuser le sujet de Hugo Deploy.

Enfin, même si l’hébergement dans AWS est peu coûteux (moins de 2$ par mois), il n’en est pas moins gratuit. Or, il serait tout à fait possible d’utiliser les GitHub Pages pour rendre ce blog accessible, et profiter de GitHub comme hébergement (là-dessus, je suis un peu moins emballé, car je ne pourrais plus me la péter avec mes jolis diagrammes AWS…).

Conclusion

Et voilà, vous savez tout !

De mes débuts avec WordPress, qui, bien que pratique, présentait des faiblesses du point de vue backup, maintenance et déploiement.

De mes recherches pour trouver une stack technique parfaite : AWS, Terraform, Hugo et GitHub Actions, tout ça pour permettre un déploiement rapide et à moindre coût !

Quand je compare avec ce que j’avais à l’époque, je ne suis que trop heureux d’avoir sauté le pas !

Et vous aussi, vous avez maintenant toutes les informations pour créer un blog à vous, et déployer tout ça en un clin d’oeil !

Happy blogging !