Études de cas et applications concrètes

Construction d’une API serverless avec API Gateway et Lambda

Une entreprise technologique développant une solution SaaS B2B devait exposer une API publique capable de traiter des millions de requêtes par mois, tout en garantissant un coût d’exploitation minimal. Le modèle économique reposait sur la facturation à l’usage : impossible donc d’entretenir une infrastructure surdimensionnée.

La solution retenue fut une architecture entièrement serverless. En façade, Amazon API Gateway assure la gestion du trafic, le routage, le throttling et la validation des requêtes. Chaque appel déclenche une fonction AWS Lambda, écrite en Node.js, qui exécute la logique métier. Les données sont stockées dans Amazon DynamoDB, un service NoSQL sans serveur, et les utilisateurs sont authentifiés via Amazon Cognito.

La conception de cette architecture a exigé une attention particulière à la granularité : trop de petites fonctions Lambda entraînent une explosion de points d’entrée et des coûts de supervision ; trop peu, et l’on perd en modularité. Un équilibre a été trouvé : chaque domaine fonctionnel (utilisateurs, produits, reporting) possède sa propre collection de Lambdas regroupées par logique.

Pour limiter les latences...

Migration d’une infrastructure on-premise vers AWS

Le cas suivant provient d’un acteur industriel européen dont l’infrastructure vieillissante reposait sur deux datacenters privés. Les serveurs approchaient de la fin de leur cycle de vie, et les opérations de maintenance devenaient coûteuses. L’entreprise souhaitait migrer vers AWS pour moderniser son environnement, renforcer la résilience et accélérer le déploiement de nouveaux services.

La première étape a consisté à mettre en place une Landing Zone avec AWS Control Tower. Cette fondation a permis de séparer clairement les environnements (Développement, Préproduction, Production), de centraliser les logs via CloudTrail (Organization Trail), et de sécuriser la gouvernance avec des SCP interdisant l’usage de services non approuvés.

Côté réseau, la connectivité entre les sites a été assurée par un VPN IPsec, puis renforcée par un AWS Direct Connect dédié. Le DNS interne a été migré sur Route 53 Private Hosted Zones, et un contrôle d’e-gress a été mis en place via AWS Network Firewall.

La migration des serveurs s’est appuyée sur AWS Application Migration Service (MGN), qui réplique les disques en continu sur le cloud avant de déclencher...

Monitoring avancé et mise en place de dashboards efficaces

Une entreprise e-commerce exploitant plusieurs régions AWS faisait face à un défi typique : des dizaines de microservices, chacun gérant ses logs et métriques sans cohérence globale. Lorsqu’un incident survenait, les équipes perdaient un temps précieux à comprendre quelle partie du système était réellement affectée.

Le projet a consisté à instaurer une observabilité unifiée. Les logs applicatifs sont désormais collectés dans CloudWatch Logs, filtrés par subscription filter, puis envoyés vers OpenSearch pour l’analyse. Chaque log est structuré en JSON et contient un traceId et un correlationId : ces identifiants permettent de suivre une transaction d’un microservice à l’autre.

Les métriques techniques sont collectées via CloudWatch Metrics et Amazon Managed Service for Prometheus (AMP) pour les workloads Kubernetes (EKS). Les traces distribuées sont instrumentées avec AWS X-Ray, offrant une vue end-to-end des appels applicatifs. Des tableaux de bord Grafana consolident ces informations par domaine fonctionnel : panier, commande, paiement, recherche.

Les alertes ont été repensées : seules les anomalies significatives déclenchent une notification...

Sécurisation d’une architecture cloud pour un environnement bancaire

Dans le secteur bancaire, la migration vers AWS n’est envisageable qu’à condition de respecter les normes les plus strictes : EBA, GDPR, ISO 27001, ou encore SOC 2. Une institution européenne souhaitait créer un nouveau service digital, mais sous contrainte d’audit permanent et de séparation stricte des environnements.

L’architecture a été conçue selon la logique de la défense en profondeur. Au niveau organisationnel, AWS Organizations structure les comptes par périmètre fonctionnel : Sécurité, Réseau, Développement, Production. Des Service Control Policies (SCP) empêchent toute action non autorisée : création d’instances publiques, suppression de logs, usage de régions non approuvées. 

L’identité est centralisée via IAM Identity Center, et toutes les actions sensibles requièrent une authentification multi-facteur (MFA). Les workloads utilisent des rôles IAM à permissions minimales, audités régulièrement avec IAM Access Analyzer.

Sur le plan réseau, chaque VPC est cloisonné, connecté par Transit Gateway, et les flux sortants sont filtrés par AWS Network Firewall. Les accès aux services managés passent...