AWS SAM - l'outil IaC d'AWS dédié au serverless

AWS SAM : "Simplify Serverless", telle est la devise qu'Amazon nous propose pour son Framework d'Infrastructure as Code (IaC) dédié au Serverless ! La promesse est-elle tenue ? Est-ce un concurrent ou un allié des outils déjà existants comme Terraform ? C'est ce que nous allons tenter de découvrir dans cet article !
HeadersBlog.png
JonathanM.jpg
Jonathan MOURIER
Mis à jour le 23 Avr 2025

17+

ans
d'experience

60+

experts
techniques

100K

écoutes de notre podcast
logo Axopen

AWS SAM, quésaco ?

SAM, pour ServerlessLe terme serverless se dit d'un traitement qui ne nécessite pas de serveur (à comprendre ici : dont on ne s'occupe pas du serveur) ApplicationC'est un programme conçu pour effectuer une ou plusieurs tâches. Réaliser des applications, c'est notre cœur de métier chez AXOPEN ! Model, est un FrameworkUn framework est un ensemble d'outils permettant de cadrer la façon dont on conçoit une application. mis à disposition par AWSLe Cloud AWS (Amazon WebServices) est une plateforme de services cloud développée par le géant américain Amazon. depuis fin 2018. Cet outil fournit un écosystème simplifié, basé sur CloudLe Cloud consiste à accéder à des ressources informatiques, à partir d'internet, via un fournisseur. Formation, qui permet de créer, organiser et tester facilement ses fonctions avant de les déployer sur Lambda, le service serverless d'AWS.

Cet outil permet également d'interconnecter très facilement des services annexes à Lambda comme APIUne API est un programme permettant à deux applications distinctes de communiquer entre elles et d’échanger des données. Gateway, DynamoDB, SNS ou autres, le tout en seulement quelques lignes ! La liste des services compatibles est d'ailleurs disponible dans la documentation de SAM.

Cloud Formation VS SAM

SAM peut être considéré comme une simplification ou une abstraction de Cloud Formation dédiée exclusivement au serverless. Là où Cloud Formation se veut accessible uniquement par des experts AWS, SAM fournit aux développeurs une syntaxe simplifiée de CloudFormation qui rend beaucoup plus accessible le service aux personnes qui ne sont pas des experts absolus sur AWS. SAM s'occupe ensuite de faire la transformation en modèle Cloud Formation pour provisionner l'infrastructure nécessaire au projet.

Attention tout de même, une bonne connaissance d'AWS et des principaux services reste nécessaire pour ne pas avoir de surprise lors des déploiements !

Terraform VS SAM

Comme expliqué juste au-dessus, SAM se concentre exclusivement sur le service serverless d'AWS. Là où avec Terraform vous allez pouvoir configurer une architecture complète sur AWS et avoir la main sur quasiment tout, SAM va se concentrer sur le service Lambda et les services qui gravitent autour. Néanmoins, ces deux services ne sont pas incompatibles et peuvent au contraire se combiner pour améliorer le développement de fonctions en local. Le CLI SAM peut lire les ressources disponibles dans le projet Terraform et lancer la fonction dans un conteneur Docker.

L'implémentation est disponible sur la doc SAM d'AWS : https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/terraform-support.html

Comment fonctionne SAM ?

AWS SAM fournit deux composants pour créer des applications serverless :

  • Le projet AWS SAM qui est généré après avoir lancé la commande sam init. Celui-ci est composé d'un fichier template.yaml qui définit l'ensemble des ressources nécessaires à votre application. Ce fichier contient les spécifications définissant la syntaxe simplifiée des fonctions, événements, configurations et permissions de l'application. Il s'apparente fortement à un modèle CloudFormation.
  • Le CLI AWS SAM qui fournit un certain nombre de commandes permettant de compiler et lancer vos fonctions serverless en local et ensuite de les déployer (nous allons y revenir). Avec ces deux composants, SAM fournit aux développeurs les outils nécessaires pour développer des fonctions serverless, tester en local et ensuite déployer son code très facilement !

Initialisation d'un projet SAM

Vu qu'un exemple vaut mieux que 1024 mots 😁

  • Avant de démarrer, assurez-vous d'avoir bien installé le SAM CLI (Windows, MAC et Linux)

https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/install-sam-cli.html

  • Une fois l'installation terminée, rendez-vous dans le dossier de votre projet, ouvrez une invite de commande et lancez simplement la commande suivante : sam init

  • Une fois l'installation terminée, rendez-vous dans le dossier de votre projet, ouvrez un invite de commande et lancer simplement la commande suivante: sam init

  • La commande va alors vous proposer de générer une application basée sur un modèle existant ou d'utiliser un modèle personnalisé. Choisissez la première option.

  • Vous avez ensuite le choix entre 16 modèles différents, du simple "Hello World" au "Machine Learning". Nous allons choisir le "Hello World Example" pour commencer notre exemple. 

    179007ed-05d7-491c-83ac-35eaef1c697b.png

Pour la suite, répondez comme ceci aux questions suivantes :

  • Use the most popular runtime and package type? (python3.13 and zip) [y/N]: Yes

  • Would you like to enable X-Ray tracing on the function(s) in your application? No

Ce service permet de débugger en production mais il est assez coûteux

  • Would you like to enable monitoring using CloudWatch Application Insights? No

Ce service service pourra être activé plus tard

  • Would you like to set Structured Logging in JSON format on your Lambda functions? No

Pas d'authentification prévue sur cette fonction

  • Project name : hello_world

Une fois l'installation terminée, un projet prêt à être déployé est chargé dans notre dossier "hello_world".

Tour du propriétaire 
9c036722-1a2f-442e-98e8-452e4082fcee.png

Les principaux fichiers qui nous intéressent sont le suivants :

Le fichier template.yaml

C'est le fichier clé de configuration qui va nous permettre de configurer l'infrastructure de notre fonction ainsi que tous les services interconnectés.

Ci-dessous, l'explication des propriétés :

#...

Resources:
  HelloWorldFunction: #Déclaration de la ressource
    Type: AWS::Serverless::Function #Type de ressource
      CodeUri: hello_world/  #Localisation du code
      Handler: app.lambda_handler
      Runtime: python3.13
      Architectures:
        - x86_64
      Events:
        HelloWorld: #Evenement joué par la fonction
          Type: Api
          Properties:
            Path: /hello #Route et méthode de la fonction 
            Method: get

#Valeurs affichées après le déploiement
Outputs: 
  HelloWorldApi:
    Description: "API Gateway endpoint URL for Prod stage for Hello World function"
    Value: !Sub "https://${ServerlessRestApi}.execute-api.${AWS::Region}.amazonaws.com/Prod/hello/"
  HelloWorldFunction:
    Description: "Hello World Lambda Function ARN"
    Value: !GetAtt HelloWorldFunction.Arn
  HelloWorldFunctionIamRole:
    Description: "Implicit IAM Role created for Hello World function"
    Value: !GetAtt HelloWorldFunctionRole.Arn

Pour notre fonction HelloWorld, nous n'utilisons aucun autre service. Cependant, pour ajouter un service supplémentaire, il suffit de le spécifier sous l'attribut Resources. Par exemple, pour intégrer une API Gateway devant notre fonction :

  Resources:
    ServerlessRestApi:
      Type: AWS::Serverless::Api
      Properties:
        Name: "api-hello-world"
        StageName: Prod
    HelloWorldFunction:
      Type: AWS::Serverless::Function
      #...

Le fichier event.json

Ce fichier permet de simuler une requête HTTP qui appelle notre fonction. Très utile pour invoquer localement la fonction et lui passer ce fichier en guise de requête.

Exemple d'utilisation :

sam local invoke HelloWorldFunction --event events/event.json

Cette commande va permettre d'invoquer la fonction dans un container docker, en simulant la requête contenue dans le fichier event.json et ensuite retourner le résultat dans la console ! 

13403228-e74c-4785-a4f0-a0e8b64136f6.png

Le fichier samconfig.toml

Fichier de configuration du CLI SAM. Utilisé pour configurer les commandes et sauvegarder les paramètres de build et deploy.

Le dossier hello_world

Dossier contenant les fichiers de code de notre fonction.

Le dossier tests

Dans tous les modèles, AWS nous fournit une base pour réaliser des tests sur notre fonction.

Lancement de notre fonction en local

L'énorme force de l'outil d'AWS, c'est la possibilité de pouvoir lancer les fonctions en local ! Nous pouvons invoquer la fonction en passant en paramètre un évènement comme nous l'avons vu plus haut mais nous pouvons également en faire une API ! Idéal pour développer la fonction en local sans la déployer sur AWS 😎

Exemple avec notre fonction HelloWorld

Pour lancer notre API contenant notre fonction, il suffit simplement de lancer la commande sam local start-api. Notre API sera ensuite disponible sur le port 3000 ! 

8e2380b2-351b-4a19-a675-c14af0ed3bd7.png

Un curl de notre fonction nous permet de tester le fonctionnement de notre fonction

curl http://localhost:3000/hello
{"message": "hello world"}

Notre premier déploiement

Réalisons maintenant le premier déploiement de notre super application HelloWorld (il faut un début à tout !).

Mais on peut déployer sans rien configurer ? Et oui Jamy, ce modèle est livré prêt à l'emploi ! SAM se base sur notre environnement AWS local et c'est parti 🚀.

Avant de déployer, assurez-vous d'avoir renseigné des identifiants AWS qui permettent de créer un service lambda & API Gateway et d'avoir Docker installé sur votre poste.

https://docs.aws.amazon.com/cli/latest/userguide/getting-started-quickstart.html

Lancez la commande sam build --use-container, cette commande va télécharger une image python3.13 et compiler la fonction dans cette image.

Une fois le build effectué, un nouveau dossier .aws-sam a été créé. Ce dossier contient l'ensemble des dépendances python, votre code ainsi qu'un fichier "build.toml" qui contient les informations nécessaires au déploiement.

Tout est prêt pour notre premier test de déploiement !

  • Lancer la commande sam deploy --guided
  • Répondez aux questions du CLI :
    • Stack Name [form-contact]: Ne rien toucher
    • AWS Region [eu-west-3]: Spécifier la région où vous voulez déployer
    • Confirm changes before deploy [Y/n]: y (Toujours mieux)
    • Allow SAM CLI IAM role creation [Y/n]: y (Je s'occupe de tout, tu s'occupes de rien)
    • Disable rollback [y/N]: n (en cas d'erreur de déploiement, on autorise un retour arrière)
    • HelloWorldFunction has no authentication. Is this okay? [y/N]: y (Pas d'authentification à prévoir)
    • Save arguments to configuration file [Y/n]: y (Le fichier samconfig.toml sera modifié pour inclure les réponses précédentes)
    • SAM configuration file [samconfig.toml]: Ne rien toucher
    • SAM configuration environment [default]: Ne rien toucher
  • Vous devriez avoir un tableau récapitulatif une fois le questionnaire terminé 
    e93c5f29-4226-4fb3-8a68-63cd26743425.png
  • Vous pouvez ensuite déployer votre toute première application 🚀 en appuyant sur "Y" 
    d91f7492-ac16-4601-9ed7-128d22a3f738.png
  • Votre application "Hello World" est déployée ! Pour la tester, faites un curl avec un body et vous aurez (si tout va bien) une réponse "Hello World" de la part de votre lambda.

Détruire l'environnement de test

Une fois notre déploiement et notre test effectués avec succès, nous allons pouvoir détruire notre environnement. Pour cela, rien de plus simple ! Il nous suffit de lancer la commande sam delete. SAM va vous demander de confirmer la suppression de la pile Cloudformation et du S3 et ensuite, comme le déploiement, SAM s'occupe de tout ! (un vrai IaC 😍).

SAM, pour quels usages ?

Là où la configuration d'un déploiement de fonctions aurait été plus laborieuse avec Cloudformation et des IaC comme Terraform, SAM nous permet de déployer une ou plusieurs fonctions beaucoup plus rapidement tout en offrant la possibilité d'une configuration assez poussée.

Cet outil peut être idéal pour des fonctions en complément d'un site web statique, pour un projet exclusivement composé de fonctions serverless ou en marge d'une architecture Terraform comme spécifié plus haut !

De plus, depuis le changement de politique du célèbre Framework Serverless, qui impose dans sa dernière version, l'utilisation de leur cloud pour pouvoir déployer les fonctions (et avec une utilisation trop intense de votre application, de vous facturer en plus de votre infrastructure AWS), AWS SAM peut devenir une alternative cohérente à Serverless.

Alors convaincu ?