Ce livre blanc est fourni à titre de référence historique uniquement. Certains contenus peuvent être obsolètes et certains liens peuvent ne pas être disponibles.
Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Exemples de modèles d'architecture
Vous pouvez implémenter des modèles d'architecture courants à l'aide d'API Gateway et AWS Lambda en tant que niveau logique. Ce livre blanc présente les modèles d'architecture les plus courants qui exploitent des niveaux logiques AWS Lambda basés sur des niveaux de logique :
+ **Backend mobile :** une application mobile communique avec API Gateway et Lambda pour accéder aux données de l'application. Ce modèle peut être étendu aux clients HTTPS génériques qui n'utilisent pas de ressources AWS sans serveur pour héberger des ressources de niveau présentation (telles que des clients de bureau, des serveurs Web exécutés dessus EC2, etc.).
+ **Application d'une seule page : application** d'une seule page hébergée sur Amazon S3 CloudFront qui communique avec API Gateway et permet AWS Lambda d'accéder aux données de l'application.
+ **Application Web** — L'application Web est un back-end d'application Web à usage général, piloté par des événements, qui utilise API AWS Lambda Gateway pour sa logique métier. Il utilise également DynamoDB comme base de données et Amazon Cognito pour la gestion des utilisateurs. Tout le contenu statique est hébergé à l'aide d'Amplify.
Outre ces deux modèles, ce livre blanc décrit l'applicabilité de Lambda et d'API Gateway à une architecture générale de microservices. L'architecture de microservices est un modèle courant qui, bien qu'il ne s'agisse pas d'une architecture standard à trois niveaux, implique de découpler les composants de l'application et de les déployer sous forme d'unités de fonctionnalité individuelles et apatrides communiquant entre elles.
# Backend mobile
![\[Modèle architectural pour le backend mobile sans serveur\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/serverless-multi-tier-architectures-api-gateway-lambda/images/arch-pattern-serverless-mobile-backend.png)
*Modèle architectural pour le backend mobile sans serveur*
*Tableau 1 : composants du niveau backend mobile*
| Palier | Composants |
| --- | --- |
| Présentation | Application mobile exécutée sur un appareil utilisateur. |
| Logic | Amazon API Gateway avec AWS Lambda. Cette architecture présente trois services exposés (`/tickets``/shows`, et`/info`). Les points de terminaison d'API Gateway sont sécurisés par les groupes [d'utilisateurs Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-identity-pools.html). Dans cette méthode, les utilisateurs se connectent aux groupes d'utilisateurs Amazon Cognito (en utilisant un tiers fédéré si nécessaire) et reçoivent des jetons d'accès et d'identification utilisés pour autoriser les appels d'API Gateway. Chaque fonction Lambda se voit attribuer son propre rôle Identity and Access Management (IAM) afin de fournir un accès à la source de données appropriée. |
| Données | DynamoDB est utilisé pour `/tickets` les services et. `/shows` Amazon RDS est utilisé pour le `/info` service. Cette fonction Lambda récupère les informations d'identification Amazon RDS auprès de Secrets AWS Manager et utilise une interface Elastic Network pour accéder au sous-réseau privé. |
# Application d'une seule page
![\[AWS architecture diagram showing interactions between services like CloudFront, S3, Lambda, and DynamoDB.\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/serverless-multi-tier-architectures-api-gateway-lambda/images/single-page-application.png)
*Modèle architectural pour une application mono-page sans serveur*
*Tableau 2 : composants d'une seule page de l'application*
| Palier | Composants |
| --- | --- |
| Présentation | Contenu de site Web statique hébergé sur Amazon S3, distribué par CloudFront. AWS Certificate Manager permet d'utiliser un certificat SSL/TLS personnalisé. |
| Logic | API Gateway avec AWS Lambda. Cette architecture présente trois services exposés (`/tickets``/shows`, et`/info`). Les points de terminaison API Gateway sont sécurisés par un autorisateur Lambda. Dans cette méthode, les utilisateurs se connectent via un fournisseur d'identité tiers et obtiennent des jetons d'accès et d'identification. Ces jetons sont inclus dans les appels d'API Gateway, et l'autorisateur Lambda valide ces jetons et génère une politique IAM contenant les autorisations d'initiation d'API. Chaque fonction Lambda se voit attribuer son propre rôle IAM afin de fournir un accès à la source de données appropriée. |
| Données | Amazon DynamoDB est utilisé pour `/tickets` les services et. `/shows` Amazon ElastiCache est utilisé par le `/shows` service pour améliorer les performances de la base de données. Les erreurs de cache sont envoyées à DynamoDB. Amazon S3 est utilisé pour héberger le contenu statique utilisé par le`/info service`. |
# Application web
![\[AWS Cloud architecture diagram showing client interaction with various Services AWS.\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/serverless-multi-tier-architectures-api-gateway-lambda/images/web-application.png)
*Modèle architectural pour application Web*
*Tableau 3 : composants de l'application Web*
| Palier | Composants |
| --- | --- |
| Présentation | L'application frontale est constituée de tout le contenu statique (HTML, CSS JavaScript et images) généré par des utilitaires React tels que create-react-app. Amazon CloudFront héberge tous ces objets. L'application Web, lorsqu'elle est utilisée, télécharge toutes les ressources dans le navigateur et commence à s'exécuter à partir de là. L'application Web se connecte au backend en appelant le APIs. |
| Logic | La couche logique est construite à l'aide de fonctions Lambda gérées par API Gateway REST. APIs Cette architecture présente plusieurs services exposés. Il existe plusieurs fonctions Lambda différentes, chacune gérant un aspect différent de l'application. Les fonctions Lambda se trouvent derrière API Gateway et sont accessibles via les chemins d'URL des API. L'authentification des utilisateurs est gérée à l'aide de groupes d'utilisateurs Amazon Cognito ou de fournisseurs d'utilisateurs fédérés. API Gateway utilise une intégration prête à l'emploi avec Amazon Cognito. Ce n'est qu'une fois l'utilisateur authentifié que le client reçoit un jeton Web JSON (JWT) qu'il doit ensuite utiliser lors des appels d'API. Chaque fonction Lambda se voit attribuer son propre rôle IAM afin de fournir un accès à la source de données appropriée. |
| Données | Dans cet exemple particulier, DynamoDB est utilisé pour le stockage des données, mais d'autres services de base de données ou de stockage Amazon spécialement conçus peuvent être utilisés en fonction du cas d'utilisation et du scénario d'utilisation. |
# Microservices avec Lambda
![\[AWS Cloud architecture with API Gateways and Lambda functions across two accounts.\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/serverless-multi-tier-architectures-api-gateway-lambda/images/microservices-with-lambda.png)
*Modèle architectural pour les microservices avec Lambda*
Le modèle d'architecture des microservices n'est pas lié à l'architecture classique à trois niveaux ; toutefois, ce modèle populaire peut apporter des avantages significatifs grâce à l'utilisation de ressources sans serveur.
Dans cette architecture, chacun des composants de l'application est découplé et déployé et exploité indépendamment. Une API créée avec Amazon API Gateway et des fonctions lancées par AWS Lambda la suite sont tout ce dont vous avez besoin pour créer un microservice. Votre équipe peut utiliser ces services pour découpler et fragmenter votre environnement au niveau de granularité souhaité.
En général, un environnement de microservices peut présenter les difficultés suivantes : surcharge répétitive pour créer chaque nouveau microservice, problèmes liés à l'optimisation de la densité et de l'utilisation des serveurs, complexité liée à l'exécution simultanée de plusieurs versions de plusieurs microservices et multiplication des exigences de code côté client pour l'intégration à de nombreux services distincts.
Lorsque vous créez des microservices à l'aide de ressources sans serveur, ces problèmes deviennent moins difficiles à résoudre et, dans certains cas, disparaissent tout simplement. Le modèle de microservices sans serveur réduit les obstacles à la création de chaque microservice suivant (API Gateway permet même le clonage de fonctions Lambda existantes et l'utilisation de fonctions APIs Lambda dans d'autres comptes). L'optimisation de l'utilisation des serveurs n'est plus pertinente avec ce modèle. Enfin, Amazon API Gateway fournit un client généré par programmation SDKs dans un certain nombre de langages courants afin de réduire les frais d'intégration.