# AI Act, souveraineté et AWS European Sovereign Cloud — Le cloud comme pièce de conformité > 2026-09-01T07:00:00.000Z | https://sylvain.bruas.fr/blog/2026/09/aws-esc-souverainete-ia-act Tags: ia, souverainete, conformite, aws Summary: Comment l'AI Act, lu sous l'angle de la souveraineté, s'applique à l'AWS European Sovereign Cloud : gouvernance EU, résidence des données, conformité. ![AI Act, souveraineté et AWS European Sovereign Cloud](/static/2026/09/aws-esc-souverainete-ia-act.webp) Le règlement européen sur l'intelligence artificielle (Artificial Intelligence Act, ou « AI Act », Regulation 2024/1689) est entré dans sa phase d'application progressive. Pour beaucoup d'entreprises, la question s'est longtemps résumée à « mon système d'IA est-il à haut risque ? ». C'est une bonne question, mais elle en cache une autre, plus discrète et tout aussi structurante : **où et par qui mes données d'IA sont-elles traitées ?** C'est précisément là que l'AI Act rejoint le sujet de la souveraineté numérique, et que des offres comme l'[AWS European Sovereign Cloud](https://aws.eu/fr/) (ESC) deviennent un élément d'architecture de conformité, et pas seulement un choix d'hébergement. Cet article prend l'AI Act comme fil conducteur, le lit sous l'angle de la souveraineté, puis regarde concrètement ce que l'ESC apporte — et ce qu'il n'apporte pas. --- ## L'AI Act en bref, et pourquoi la souveraineté s'y invite ### Une approche par le risque Le principe de l'AI Act est simple : plus un système d'IA présente de risques, plus ses obligations sont lourdes. La première étape, pour toute organisation dont un système touche le marché européen, est donc de le classer dans l'une des quatre catégories prévues par le règlement ([Commission européenne — Cadre réglementaire de l'IA](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai)) : - **Risque inacceptable** : pratiques interdites (notation sociale, manipulation, etc.). Ces systèmes sont purement et simplement bannis. - **Haut risque** : IA utilisée dans des domaines sensibles (recrutement, scoring de crédit, santé, infrastructures critiques). Ce sont les systèmes les plus encadrés : documentation technique, gestion des risques, gouvernance des données, supervision humaine. - **Risque limité** : chatbots, contenus générés par IA. Obligations de transparence (informer l'utilisateur qu'il interagit avec une IA). - **Risque minimal** : la grande majorité des usages (filtres anti-spam, jeux). Aucune obligation spécifique. C'est cette classification qui commande tout le reste : le niveau d'obligations, les contrôles à mettre en place, et — c'est le cœur de cet article — la sensibilité des données traitées. Le calendrier d'application, lui, a beaucoup bougé. Il faut retenir les grandes lignes : | Échéance | Ce qui s'applique | |----------|-------------------| | 2 février 2025 | Pratiques interdites + obligation de former les équipes à l'usage de l'IA | | 2 août 2025 | Obligations pour les modèles d'IA à usage général (General-Purpose AI, GPAI) | | 2 août 2026 | Application générale, transparence (Article 50), pouvoirs de sanction sur les GPAI | | 2 décembre 2027 | Obligations des systèmes à haut risque (Annexe III) | | 2 août 2028 | Systèmes à haut risque intégrés à des produits réglementés (Annexe I) | À noter : le « Digital Omnibus » — un paquet législatif européen visant à simplifier et assouplir plusieurs textes numériques, dont l'AI Act — a repoussé les principales obligations « haut risque » à fin 2027, voire 2028. Mais le 2 août 2026 reste une échéance clé, avec l'entrée en vigueur des règles de transparence et des sanctions sur les GPAI ([Commission européenne — AI Act Service Desk](https://ai-act-service-desk.ec.europa.eu/en/ai-act/faq/when-does-enforcement-start)). ### Le point de contact avec la souveraineté : l'Article 10 L'AI Act ne parle pas de « cloud souverain ». Mais son Article 10, consacré aux données et à la gouvernance des données pour les systèmes à haut risque, impose des exigences sur la qualité, la représentativité et la traçabilité des jeux de données d'entraînement, de validation et de test ([Commission européenne — Article 10](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-10)). Or, dès qu'un système d'IA traite des données à caractère personnel — ce qui est la règle plus que l'exception — l'AI Act se superpose au Règlement général sur la protection des données (RGPD). Le cabinet [Osborne Clarke](https://www.osborneclarke.com/insights/interplay-eu-ai-act-and-gdpr) souligne ce recouvrement : lorsqu'un système d'IA régulé traite des données personnelles, les deux textes s'appliquent conjointement. Et le RGPD, lui, pose frontalement la question du lieu de traitement et de la juridiction applicable. C'est ainsi que la conformité à l'AI Act, apparemment centrée sur la gestion du risque, finit par toucher trois questions de souveraineté : *où vivent les données, qui les opère, et quelle loi s'y applique.* --- ## Souveraineté : de quoi parle-t-on exactement ? Le terme « souveraineté » est galvaudé. Il recouvre en réalité plusieurs exigences distinctes qu'il faut séparer : - **Résidence des données (data residency)** : les données restent physiquement dans une zone géographique donnée (ici, l'Union européenne). - **Autonomie opérationnelle** : l'infrastructure peut fonctionner et être administrée sans dépendance à des ressources ou du personnel hors UE. - **Souveraineté juridictionnelle** : les données échappent au champ d'application du droit extra-européen. Ce dernier point est le plus épineux : la résidence des données et la souveraineté juridictionnelle sont deux objectifs distincts. Une donnée peut très bien vivre à Francfort tout en restant, en théorie, accessible au droit américain si le fournisseur cloud dépend d'une maison mère aux États-Unis. C'est précisément ce que permet le CLOUD Act, cette loi américaine qui autorise les autorités des États-Unis à réclamer des données à une entreprise américaine, même lorsqu'elles sont stockées à l'étranger. Pour un responsable conformité qui prépare un système d'IA à haut risque, cette distinction est cruciale : héberger dans une région AWS européenne classique satisfait la résidence des données, mais ne répond pas, à lui seul, à la question de l'autonomie opérationnelle et de la juridiction. --- ## Ce qu'apporte l'AWS European Sovereign Cloud J'ai déjà détaillé l'architecture et les enjeux de l'ESC dans deux articles précédents : [architecture et enjeux](/blog/2026/04/esc-part1) pour les fondations (partition isolée, système Nitro, chiffrement, SecNumCloud), et [défis et recommandations](/blog/2026/05/esc-part2) pour la mise en œuvre (parité de services, IAM régional, connectivité, migration). Je me contente donc ici d'un rappel des trois caractéristiques qui comptent pour l'AI Act : - **Une infrastructure séparée** : une partition AWS distincte (`aws-eusc`), avec une première région `eusc-de-east-1` dans le Brandebourg (Allemagne), physiquement et logiquement isolée du reste d'AWS, et une extension prévue via des *Local Zones* souveraines en Belgique, aux Pays-Bas et au Portugal. - **Une gouvernance européenne dédiée** : une entité constituée sous droit européen, avec des filiales en Allemagne (GmbH) dirigées par des citoyens de l'UE résidant dans l'UE, juridiquement tenus d'agir dans l'intérêt de l'ESC, et un conseil consultatif indépendant. - **Une exploitation depuis l'UE** : l'accès logique et physique aux systèmes est restreint à du personnel qualifié résidant dans l'UE, et l'ESC est conçu pour fonctionner sans dépendance aux systèmes AWS globaux. AWS précise que la transition vers une exploitation exclusivement assurée par des citoyens de l'UE est progressive, avec une équipe mixte pendant cette période ([AWS — Whitepaper Overview of the AWS European Sovereign Cloud](https://docs.aws.amazon.com/whitepapers/latest/overview-aws-european-sovereign-cloud/design-goals.html)). ### La correspondance avec les exigences de l'AI Act En croisant ces caractéristiques avec les exigences que fait naître l'AI Act (via son intersection avec le RGPD), on obtient une cartographie assez nette : | Exigence induite par l'AI Act / RGPD | Réponse de l'ESC | |---------------------------------------|------------------| | Résidence des données (Article 10, jeux de données) | Données conservées dans l'UE, partition dédiée | | Traçabilité et journalisation (Articles 12, 19) | Métadonnées, rôles et configurations conservés dans l'UE | | Autonomie opérationnelle | Exploitation par du personnel UE, gouvernance GmbH | | Réduction du risque juridictionnel extra-UE | Isolement structurel et société mère européenne | --- ## Les limites : la souveraineté n'est pas un interrupteur Il serait malhonnête de présenter l'ESC comme une case à cocher qui « résout » l'AI Act. Trois nuances méritent d'être posées. **1. Le cloud souverain ne classe pas votre système à votre place.** L'obligation première de l'AI Act reste la classification du risque et la mise en conformité du système lui-même (documentation technique, gestion des risques, supervision humaine). L'infrastructure aide sur le volet données et traçabilité, mais ne dispense d'aucune obligation métier. **2. La souveraineté juridictionnelle reste débattue.** Le lancement de l'ESC s'est accompagné de questions publiques sur la portée réelle du droit américain, notamment le CLOUD Act, sur une filiale d'un groupe américain ([InfoQ](https://infoq.com/news/2026/01/aws-european-sovereign-cloud)). La structure GmbH et l'opération par du personnel UE sont conçues pour réduire ce risque, mais l'appréciation juridique finale dépend du contexte de chaque organisation et de son conseil juridique. **3. Le catalogue de services est plus restreint qu'en région commerciale.** Une partition récente ne propose pas, au démarrage, l'intégralité des services disponibles dans les régions historiques. Il faut donc vérifier la disponibilité des briques nécessaires à votre pipeline d'IA (stockage, calcul, services de machine learning) avant de vous engager. Pour les institutions financières, ce faisceau d'obligations est encore plus dense : l'AI Act s'y superpose au RGPD *et* au règlement DORA (Digital Operational Resilience Act), rendant la souveraineté des données, l'auditabilité et la gestion du risque tiers indissociables de la conformité à l'AI Act. --- ## Comment aborder le sujet concrètement Si vous préparez un système d'IA destiné au marché européen, une progression pragmatique consiste à traiter la conformité et l'infrastructure comme deux chantiers parallèles mais coordonnés : 1. **Classer le système** selon les catégories de l'AI Act. C'est le préalable à toute décision d'architecture. 2. **Cartographier les flux de données personnelles** : quelles données, d'où, vers quels traitements. C'est ici que le RGPD et l'Article 10 entrent en jeu. 3. **Définir le niveau de souveraineté requis** : résidence seule, ou résidence + autonomie opérationnelle + réduction du risque juridictionnel. 4. **Choisir l'infrastructure en conséquence** : une région européenne classique peut suffire pour la résidence ; l'ESC devient pertinent quand l'autonomie opérationnelle et l'isolement juridictionnel sont exigés par le secteur (santé, public, finance). 5. **Documenter et journaliser** : la traçabilité exigée par l'AI Act doit être opérationnelle, pas seulement contractuelle. --- ## Ce qu'il faut retenir L'AI Act n'impose pas de cloud souverain. Mais en rendant obligatoires la gouvernance des données, la traçabilité et la supervision, et en se superposant au RGPD, il pousse mécaniquement les organisations les plus régulées vers des questions de souveraineté : où vivent les données, qui les opère, quelle loi s'applique. L'AWS European Sovereign Cloud apporte une réponse d'infrastructure crédible à ces trois questions — partition isolée, exploitation par du personnel UE, gouvernance européenne — sans pour autant dispenser de l'essentiel du travail de conformité, qui reste à la charge du fournisseur ou du déployeur du système d'IA. En clair : l'ESC est un outil au service de la conformité, pas un substitut à celle-ci. Le bon réflexe n'est donc pas « dois-je aller sur du souverain ? » mais « quel niveau de souveraineté mon système d'IA exige-t-il, et à quelle échéance de l'AI Act ? ». - [Commission européenne — Quand l'application commence-t-elle ?](https://ai-act-service-desk.ec.europa.eu/en/ai-act/faq/when-does-enforcement-start) - [Commission européenne — Article 10 : Données et gouvernance des données](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-10) - [Commission européenne — Lignes directrices systèmes à haut risque](https://digital-strategy.ec.europa.eu/en/policies/guidelines-ai-high-risk-systems) - [Commission européenne — Article 12 : Enregistrement des événements](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-12) - [Future of Privacy Forum — L'AI Act et le Digital Omnibus](https://fpf.org/blog/the-ai-act-implementation-timeline-what-changes-under-the-ai-omnibus/) - [Osborne Clarke — Interaction entre l'AI Act et le RGPD](https://www.osborneclarke.com/insights/interplay-eu-ai-act-and-gdpr) - [Osborne Clarke — Digital Omnibus (règlement UE 2026/1744)](https://www.osborneclarke.com/what-our-clients-are-talking-about/digital-regulation/digital-omnibus-package) - [Commission européenne — Cadre réglementaire de l'IA (approche par le risque)](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai) - [AWS — European Sovereign Cloud (documentation officielle)](https://aws.eu/fr/) - [AWS — Whitepaper : Overview of the AWS European Sovereign Cloud](https://docs.aws.amazon.com/whitepapers/latest/overview-aws-european-sovereign-cloud/design-goals.html) - [AWS — Partitions et namespaces (documentation `aws-eusc`)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/gpbucketnamespaces.html) - [InfoQ — AWS Launches European Sovereign Cloud](https://infoq.com/news/2026/01/aws-european-sovereign-cloud) --- # Kiro et la conformité HIPAA — ce que ça change pour les devs santé en France > 2026-08-24T00:00:00.000Z | https://sylvain.bruas.fr/blog/2026/08/kiro-hipaa-sante-france Tags: kiro, sante, conformite, aws Summary: Kiro est éligible HIPAA depuis le 26 mai 2026, hors Kiro Web. Ce que ça change pour les développeurs e-santé en France, entre RGPD et HDS. ![Kiro et la conformité HIPAA — ce que ça change pour les devs santé en France](/static/2026/08/hipaa.webp) Les développeurs du secteur de la santé naviguent dans un environnement réglementaire complexe. En France, le triptyque **RGPD + HDS + HIPAA** encadre le traitement des données de santé selon que l'application vise le marché français, européen ou américain. Le Règlement Général sur la Protection des Données (RGPD) couvre les données personnelles en Europe, la certification Hébergeur de Données de Santé (HDS) s'applique à l'hébergement en France, et le cadre américain HIPAA régit les données de patients aux États-Unis. Jusqu'à récemment, utiliser un outil de développement assisté par intelligence artificielle (IA) avec des données patient posait un problème de conformité majeur. [Kiro](https://kiro.dev/) a franchi une étape le **26 mai 2026** : il figure désormais dans la [liste des services AWS éligibles HIPAA](https://aws.amazon.com/compliance/hipaa-eligible-services-reference/) — **avec une exclusion importante que nous détaillons plus bas**. ## Qu'est-ce que HIPAA ? ### Le cadre réglementaire américain HIPAA (Health Insurance Portability and Accountability Act) est la loi fédérale américaine qui régit la protection des **informations de santé protégées électroniques** (electronic Protected Health Information, ou ePHI). Cela inclut : - Noms de patients associés à des données médicales - Numéros de sécurité sociale, identifiants médicaux - Diagnostics, traitements, prescriptions - Données biométriques, résultats de laboratoire - Toute information permettant d'identifier un patient dans un contexte médical ### Les obligations clés Pour les développeurs, HIPAA impose : - **Chiffrement au repos et en transit** : toute donnée ePHI doit être chiffrée - **Contrôles d'accès** : authentification forte, principe du moindre privilège - **Journalisation d'audit** : traçabilité de qui accède à quoi et quand - **Business Associate Agreement (BAA)** : contrat formel avec tout sous-traitant manipulant du ePHI - **Réponse aux incidents** : procédures de notification en cas de violation de données ## HIPAA, RGPD et HDS : le triptyque français ### Positionnement des réglementations Pour une startup e-santé française, les réglementations se superposent : | Réglementation | Périmètre | Données couvertes | Marché | |---------------|-------|------------------|--------| | **RGPD** | Union Européenne | Données personnelles (toutes) | Union Européenne | | **HDS** | France | Données de santé hébergées | France | | **HIPAA** | États-Unis | ePHI | États-Unis + international | ### Quand HIPAA s'applique HIPAA s'applique dès que votre application : - Traite des données de patients américains - Est utilisée par des professionnels de santé américains (les « covered entities » au sens de la loi) - Stocke ou transmet du ePHI pour le compte d'une entité américaine Concrètement, si votre startup française développe une application de télémédecine visant le marché américain, ou un logiciel en mode Software as a Service (SaaS) de gestion de cabinet pour des médecins américains, HIPAA s'applique. ## Kiro éligible HIPAA : ce que ça signifie exactement ### L'annonce, et sa restriction Depuis le 26 mai 2026, Kiro est inclus dans l'AWS HIPAA Eligible Services Reference. La [note de version officielle](https://kiro.dev/fr/changelog/general/kiro-is-now-a-hipaa-eligible-service/) précise le périmètre : l'éligibilité concerne l'environnement de développement intégré (IDE) et l'interface en ligne de commande (CLI). **Kiro Web n'est pas couvert.** Cette restriction est reprise noir sur blanc dans la référence AWS, où l'entrée est libellée « Kiro [excluding Kiro Web] ». C'est le détail qui compte le plus en pratique : si vos équipes travaillent depuis le navigateur, cet usage sort du périmètre éligible. Vérifiez donc quelle surface Kiro vos développeurs utilisent avant de considérer que votre chaîne de développement est couverte. À la date de publication de cet article, la [version française de la page](https://aws.amazon.com/fr/compliance/hipaa-eligible-services-reference/) n'est pas à jour : sa liste passe directement d'« AWS X-Ray » à « VM Import/Export » sans mentionner Kiro. Seule la [version anglaise](https://aws.amazon.com/compliance/hipaa-eligible-services-reference/) contient l'entrée « Kiro [excluding Kiro Web] ». Le décalage de traduction des pages de conformité AWS est courant : pour tout arbitrage réglementaire, référez-vous systématiquement à l'anglais. ### Qu'est-ce que l'éligibilité HIPAA chez AWS ? Être listé comme service éligible HIPAA signifie que le service : 1. **Peut être couvert par un BAA** signé avec AWS 2. **Est jugé adapté** au traitement de ePHI par les équipes de conformité AWS 3. **Est utilisable pour des charges de travail impliquant du ePHI**, sous réserve d'une configuration correcte C'est une condition nécessaire mais pas suffisante. AWS le formule clairement : les clients restent responsables de leur propre conformité HIPAA, et l'usage de services éligibles avec du ePHI exige d'avoir signé au préalable un BAA avec AWS. ### Le BAA avec AWS Le Business Associate Agreement formalise les responsabilités d'AWS comme sous-traitant de données de santé. Pour inclure Kiro dans votre périmètre HIPAA : 1. Signez (ou mettez à jour) le BAA AWS via [AWS Artifact](https://docs.aws.amazon.com/artifact/) 2. Vérifiez que Kiro figure dans la liste des services couverts, en tenant compte de l'exclusion de Kiro Web 3. Configurez votre compte selon les recommandations de sécurité ### Rétention des données et entraînement des modèles C'est le point à examiner de près, car il dépend de votre abonnement. D'après la documentation Kiro : - Sur les abonnements payants Pro, Pro+, Pro Max et Power, votre contenu n'est pas utilisé pour entraîner les modèles de fondation. - Pour les usages entreprise, les prompts et réponses peuvent être stockés dans la région où le profil est configuré, afin d'assurer le fonctionnement du service (journalisation des prompts, rapport d'activité), sans être exploités pour l'amélioration du service. Autrement dit, « aucune rétention » serait inexact : il existe un stockage régional pour le fonctionnement du service. Pour les détails de chiffrement, de journalisation et de contrôle d'accès, référez-vous à la [documentation Privacy and Security de Kiro](https://kiro.dev/docs/privacy-and-security/), qui décrit l'application du modèle de responsabilité partagée AWS. ## Impact concret pour les développeurs santé ### Ce que l'éligibilité permet d'envisager Sous réserve d'un BAA signé et d'une configuration conforme, vous pouvez envisager de : - **Développer avec du contexte patient** : partager des schémas de base de données contenant des colonnes ePHI - **Déboguer avec des données réelles** : utiliser des journaux contenant des identifiants patient comme contexte - **Générer des migrations** : créer des migrations de schémas pour des tables contenant du ePHI - **Écrire des validations** : générer des règles de validation propres aux formats médicaux - **Auditer le code** : faire relire du code de traitement ePHI par l'agent Le principe de minimisation reste de rigueur : le fait qu'un service soit éligible ne justifie pas d'exposer plus de données que nécessaire. ### Exemple pratique : une ressource FHIR Le standard Fast Healthcare Interoperability Resources (FHIR) structure les échanges de données de santé. ```typescript // Exemple de ressource FHIR R4 typée en TypeScript. // Les champs annotés contiennent du ePHI et relèvent donc du périmètre HIPAA. interface PatientResource { resourceType: 'Patient'; id: string; identifier: Array<{ system: string; // ex. "http://hospital.org/mrn" value: string; // Numéro de dossier médical, ou Medical Record Number (ePHI) }>; name: Array<{ family: string; // Nom (ePHI) given: string[]; // Prénom (ePHI) }>; birthDate: string; // Date de naissance (ePHI) } ``` ### Steering pour les normes de santé Créez un fichier de steering dédié aux conventions de votre application de santé : ```markdown # .kiro/steering/healthcare-standards.md ## Normes de développement santé ### Données sensibles - Toujours chiffrer les champs ePHI avant stockage - Ne jamais journaliser d'identifiants patient en clair — utiliser le masquage - Implémenter la suppression logique pour les données patient (obligation de rétention) ### Standards médicaux - Utiliser les profils FHIR R4 pour les ressources patient - Valider les codes de la Classification Internationale des Maladies 10e révision (CIM-10) et SNOMED CT (Systematized Nomenclature of Medicine Clinical Terms) - Respecter le format Health Level 7 version 2 (HL7v2) pour les interfaces hospitalières ### Audit - Chaque accès à une ressource patient doit être journalisé - Format d'audit : {timestamp, userId, action, resourceType, resourceId} - Définir la durée de rétention des journaux avec votre référent conformité ### Tests - Les tests utilisant des données patient doivent utiliser un jeu synthétique - Ne jamais committer de données ePHI réelles dans les fixtures ``` ## Ce que l'éligibilité HIPAA ne signifie PAS 1. **Ce n'est pas une certification de votre application** : Kiro peut entrer dans un périmètre conforme, votre application doit l'être par elle-même 2. **Ce n'est pas un audit** : l'éligibilité ne remplace pas un audit HIPAA de votre organisation 3. **Ce n'est pas automatique** : sans BAA signé, l'usage avec du ePHI n'est pas autorisé 4. **Ce n'est pas universel** : Kiro Web est explicitement exclu ### Responsabilité partagée AWS applique le modèle de responsabilité partagée : - **AWS est responsable de** : la sécurité de l'infrastructure et du service managé - **Vous êtes responsable de** : la configuration des accès, le choix des données exposées, les politiques de sécurité, la formation des utilisateurs ## Comparaison avec les autres outils de développement IA Ce tableau reflète l'état des sources publiques consultées en août 2026. Ces positions évoluent vite : vérifiez auprès de chaque éditeur avant toute décision. | Outil | Couverture HIPAA possible ? | Mécanisme | Conditions | |-------|------------------|-----------|------------| | **Kiro** (IDE et CLI) | Oui | BAA AWS | Service listé éligible HIPAA ; Kiro Web exclu | | **Kiro Web** | Non | — | Explicitement exclu de la liste AWS | | **Cursor** | Oui | BAA Cursor | Offre Enterprise uniquement, périmètre de services et de modèles restreint, Privacy Mode imposé | | **Claude Code** | Oui, sous conditions | BAA Anthropic | Comptes éligibles avec zero data retention (ZDR) activé ; non couvert sans ZDR | | **GitHub Copilot** | Non, en pratique | — | GitHub n'accorde généralement pas de BAA pour Copilot | Deux idées reçues à corriger. D'abord, Kiro n'est pas le seul assistant de développement mobilisable dans un cadre HIPAA : [Cursor](https://cursor.com/docs/enterprise/baa) et [Claude Code](https://support.claude.com/en/articles/13296973-hipaa-ready-enterprise-plans) proposent tous deux un BAA, avec des conditions restrictives. L'intérêt de Kiro pour une équipe déjà sur AWS n'est donc pas d'être seul sur le créneau, mais de s'intégrer au BAA AWS existant plutôt que d'ajouter un contrat fournisseur supplémentaire. ## Implications pour les startups e-santé sur AWS ### Architecture de principe ``` ┌─────────────────────────────────────────────┐ │ Compte AWS dédié aux charges santé │ │ │ │ ┌──────────┐ ┌──────────┐ ┌────────┐ │ │ │ Kiro │ │ RDS │ │ S3 │ │ │ │ IDE/CLI │ │ (ePHI) │ │ (docs) │ │ │ └──────────┘ └──────────┘ └────────┘ │ │ │ │ ┌──────────────────────────────────────┐ │ │ │ AWS CloudTrail (audit) │ │ │ └──────────────────────────────────────┘ │ └─────────────────────────────────────────────┘ ``` Les services de stockage cités sont eux-mêmes éligibles HIPAA : [Amazon Relational Database Service (RDS)](https://docs.aws.amazon.com/rds/) pour les moteurs listés par AWS, et [Amazon Simple Storage Service (S3)](https://docs.aws.amazon.com/s3/). ### Checklist de mise en conformité - [ ] BAA signé avec AWS via AWS Artifact - [ ] Usage restreint aux surfaces Kiro couvertes (IDE et CLI, pas Kiro Web) - [ ] [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/iam/) configuré avec authentification multifacteur (MFA) - [ ] AWS CloudTrail activé sur les services concernés - [ ] Chiffrement par défaut sur S3, RDS et Amazon Elastic Block Store (EBS) - [ ] Amazon Virtual Private Cloud (VPC) dédié avec points de terminaison privés - [ ] Politique de rétention des journaux d'audit validée avec votre référent conformité - [ ] Formation HIPAA pour tous les développeurs - [ ] Fichiers de steering de sécurité santé dans le projet - [ ] Procédure de notification de violation de données documentée ## Conclusion L'éligibilité HIPAA de Kiro est une bonne nouvelle pour les développeurs santé en France qui visent le marché américain : l'outil peut entrer dans un périmètre conforme sans contrat fournisseur supplémentaire, puisqu'il s'adosse au BAA AWS. Deux réserves méritent d'être gardées en tête. La première est le périmètre : Kiro Web est exclu, ce qui doit se traduire par une consigne explicite pour vos équipes. La seconde est que l'éligibilité d'un outil ne dit rien de la conformité de votre application. La conformité HIPAA reste un effort continu — formation, configuration rigoureuse, audits réguliers. Pour les startups françaises qui combinent déjà RGPD et HDS, ajouter HIPAA à l'équation reste un défi. Mais l'écosystème d'outils s'est nettement étoffé, et le choix ne se limite plus à renoncer à l'assistance IA. - [Kiro est maintenant un service admissible à la HIPAA — Changelog Kiro (26 mai 2026)](https://kiro.dev/fr/changelog/general/kiro-is-now-a-hipaa-eligible-service/) - [AWS HIPAA Eligible Services Reference](https://aws.amazon.com/compliance/hipaa-eligible-services-reference/) — **version anglaise, la seule à jour** ; la déclinaison française ne mentionne pas encore Kiro - [Privacy and Security — Documentation Kiro](https://kiro.dev/docs/privacy-and-security/) - [HIPAA Business Associate Agreements — Documentation Cursor](https://cursor.com/docs/enterprise/baa) - [HIPAA-ready Enterprise plans — Support Anthropic](https://support.claude.com/en/articles/13296973-hipaa-ready-enterprise-plans) --- # BMAD Method et Agent Lattice : vision produit avec l'IA > 2026-08-19T00:00:00.000Z | https://sylvain.bruas.fr/blog/2026/08/bmad-kiro-product-development Tags: kiro, ia, architecture, aws, product-management Summary: La méthode BMAD orchestre des agents IA sur tout le cycle produit. Combinée à Kiro, elle structure l'AI-DLC du Design Thinking aux specs. ![BMAD Method et Agent Lattice](/static/2026/08/bmad-kiro-product-development/bmad-kiro-cover.webp) Le développement assisté par IA a résolu un premier problème : générer du code rapidement. Mais un deuxième problème, plus fondamental, persiste : **qui définit ce qu'il faut construire, et comment s'assurer que l'IA respecte cette vision ?** La méthode BMAD et l'outil AWS [sample-e2e-product-development-with-kiro](https://github.com/aws-samples/sample-e2e-product-development-with-kiro) apportent chacun une réponse à cette question, avec des approches complémentaires qui s'inscrivent pleinement dans la logique de l'[AI-DLC](/blog/2026/07/kiro-starter). ## BMAD : une équipe virtuelle pour piloter le cycle produit ### Le problème de la dérive contextuelle Quand vous utilisez un agent IA dans un IDE — que ce soit [Cursor](https://www.cursor.com/), [Claude Code](https://docs.anthropic.com/en/docs/agents-and-tools/claude-code/overview) ou [Kiro](https://kiro.dev/) — chaque nouvelle session repart à zéro. L'agent ne sait plus pourquoi telle décision architecturale a été prise, quels compromis ont été acceptés, ou quels cas limites ont été identifiés. C'est ce que la communauté appelle la **dérive contextuelle** : un code fonctionnel qui s'éloigne progressivement de la vision produit initiale. La méthode [BMAD](https://github.com/bmad-code-org/BMAD-METHOD) (Breakthrough Method of Agile AI-Driven Development) attaque ce problème frontalement. Au lieu de traiter l'IA comme un assistant généraliste, BMAD orchestre des **agents spécialisés** — chacun avec un rôle précis, une place définie dans le workflow, et des livrables documentés. ### Les agents BMAD : des personas avec une mission BMAD définit plus de 12 agents spécialisés, dont six rôles principaux : | Agent | Persona | Responsabilité | |-------|---------|---------------| | Analyst | Mary | Brainstorming, recherche marché, brief projet | | Product Manager | John | PRD, épics, stories, validation produit | | Architect | Winston | Architecture système, tech stack, APIs, schémas DB | | Developer | Amelia | Implémentation, code review, sprint planning | | UX Designer | Sally | Specs UX, patterns d'interaction | | Tech Writer | Paige | Documentation technique | Chaque agent est un fichier Markdown/YAML qui encode sa persona, ses commandes et ses dépendances. L'activation suit un template structuré : chargement du contexte persistant, adoption de la persona, puis exécution de la tâche. ### Quatre phases, des artefacts durables BMAD structure le développement en quatre phases successives : 1. **Analyse** — Brainstorming, recherche, brief produit 2. **Planification** — PRD, spécifications UX, architecture 3. **Conception** — Architecture détaillée, design système 4. **Implémentation** — Développement story par story, code review, rétrospective Le point clé : chaque phase produit des **artefacts versionnés dans Git** (PRD, documents d'architecture, fichiers story) qui deviennent la source de vérité du projet. Quand l'agent Developer ouvre une nouvelle session, il ne repart pas à zéro — il lit le fichier story qui contient tout le contexte nécessaire à l'implémentation. ## Agent Lattice : le Design Thinking piloté par l'IA dans Kiro ### Un sample AWS qui va plus loin qu'un exemple Le repository [sample-e2e-product-development-with-kiro](https://github.com/aws-samples/sample-e2e-product-development-with-kiro) publié par AWS Labs n'est pas un simple tutoriel. C'est un **framework complet** — baptisé Agent Lattice — qui orchestre un processus de Design Thinking de bout en bout, directement dans l'IDE Kiro. Agent Lattice se compose de deux éléments : - **Le runtime** (`.al/`) : un orchestrateur qui gère les rôles, workflows, gates et scripts, avec des modules pluggables pour le Design Thinking et la génération de specs Kiro - **Les extensions IDE** : un plugin de visualisation qui affiche la progression des phases dans une sidebar dédiée ### Le workflow Design Thinking complet L'outil guide l'utilisateur à travers les cinq phases classiques du Design Thinking, orchestrées par des skills Kiro : 1. **Empathize** (`/al-dt-workflow-empathize`) — Interviews utilisateurs, empathy maps, personas 2. **Define** — Carte d'affinité, insights, questions "How Might We" 3. **Ideate** — Brainstorming structuré, évaluation des concepts 4. **Prototype** — User flows, wireframes, spécifications d'interaction 5. **Test** — Plans de test, métriques, validation des hypothèses À la fin du processus, un module **Kiro Bridge** transforme automatiquement les artefacts de Design Thinking en specs Kiro natives (requirements → design → tasks), prêtes pour l'implémentation. ### L'impersonation de rôles Un mécanisme original d'Agent Lattice : la commande `/al-impersonate` permet à l'IA d'adopter un rôle spécifique (designer, ingénieur, product manager, UX researcher, market researcher) pendant une phase donnée. Chaque rôle dispose de son propre fichier de steering qui cadre les réponses de l'IA selon l'expertise attendue. ## L'intérêt pour la vision produit et l'AI-DLC ### Combler le fossé entre intention et implémentation L'AI-DLC, tel que [formalisé par AWS](https://aws.amazon.com/pt/blogs/devops/ai-driven-development-life-cycle/), repositionne l'humain sur la direction stratégique tandis que l'IA exécute. Mais ce modèle suppose que la direction stratégique est **clairement articulée et accessible** à l'agent d'implémentation. C'est précisément le maillon faible de la plupart des outils actuels. BMAD et Agent Lattice adressent ce fossé de deux manières complémentaires : - **BMAD** structure la **chaîne de documents** (brief → PRD → architecture → stories) qui encode les décisions produit de manière durable et versionnable - **Agent Lattice** structure la **phase d'exploration** (empathie → problème → idéation → prototype → test) qui précède la rédaction des specs Ensemble, ils couvrent l'intégralité du spectre : de la compréhension utilisateur jusqu'au code déployé. ### Le développeur comme Tech Lead, pas comme exécutant Dans un AI-DLC structuré par ces outils, le rôle du développeur change fondamentalement. Il ne passe plus son temps à écrire du code répétitif. Il : - **Valide les personas** générées par la phase Empathize - **Arbitre les décisions architecturales** proposées par l'agent Architect - **Review les stories** avant de lancer l'implémentation automatique - **Approuve les gates** entre chaque phase du workflow C'est un rôle de **curateur et de validateur** — exactement la redistribution de l'effort cognitif que promet l'AI-DLC. ### Artefacts versionnés : la mémoire du projet Le bénéfice le plus tangible de ces deux approches : **le projet a une mémoire**. Les PRD, les documents d'architecture, les empathy maps, les fichiers story — tout vit dans Git. Un nouveau développeur qui rejoint le projet peut comprendre non seulement *ce que* le logiciel fait, mais *pourquoi* il a été conçu ainsi. Un agent IA qui ouvre une nouvelle session peut charger le contexte complet sans que l'humain ait à tout ré-expliquer. C'est l'antidote à la dérive contextuelle : quand les décisions sont documentées dans des artefacts structurés, l'IA peut les respecter session après session. ### Les limites à connaître Ces approches ne sont pas sans compromis : - **Overhead documentaire** : le processus complet BMAD génère des dizaines d'artefacts avant la première ligne de code. Pour un fix rapide, c'est disproportionné (d'où l'existence d'un Quick Flow) - **Consommation de tokens** : les allers-retours entre agents consomment significativement plus de tokens qu'un prompt direct - **Coordination manuelle** : BMAD laisse au développeur la responsabilité de passer les artefacts entre agents, là où Agent Lattice automatise davantage via les skills Kiro ## Ce qu'il faut retenir La méthode BMAD et l'outil Agent Lattice d'AWS représentent une évolution majeure dans l'écosystème AI-DLC : **la structuration de la phase amont**. Là où la plupart des outils IA se concentrent sur la génération de code, ces frameworks s'attaquent au vrai problème — s'assurer que le code généré respecte une vision produit cohérente et documentée. Pour une équipe qui adopte Kiro, la combinaison est naturelle : Agent Lattice pour la phase de Discovery (Design Thinking → specs), puis le workflow natif Kiro (specs → implémentation) pour la phase de Delivery. Le tout versionné dans Git, auditable, et reproductible. Le futur du développement assisté par IA n'est pas « l'IA fait tout ». C'est « l'IA exécute un processus structuré, guidé par des artefacts que l'humain valide ». BMAD et Agent Lattice montrent à quoi ce futur ressemble concrètement. --- **Références :** - [BMAD Method — GitHub](https://github.com/bmad-code-org/BMAD-METHOD) - [Sample E2E Product Development with Kiro — AWS Samples](https://github.com/aws-samples/sample-e2e-product-development-with-kiro) - [AI-DLC — AWS DevOps Blog](https://aws.amazon.com/pt/blogs/devops/ai-driven-development-life-cycle/) - [BMAD vs AI-DLC — Dev.to](https://dev.to/jamilxt/bmad-method-vs-ai-dlc-two-ai-development-frameworks-compared-2i28) - [What Is the BMAD Method — Augment Code](https://www.augmentcode.com/guides/bmad-method-ai-development) --- # AWS Transit Gateway Policy-Based Routing : routage intelligent > 2026-08-11T11:00:00.000Z | https://sylvain.bruas.fr/blog/2026/08/transit-gateway-policy-based-routing Tags: AWS, Reseau, Architecture Summary: Transit Gateway supporte le Policy-Based Routing : routage granulaire basé sur IP source/destination, ports et protocole. ![AWS Transit Gateway Policy-Based Routing](/static/2026/08/tgw-pbr.webp) Le routage réseau sur AWS a longtemps été contraint par une logique simple : le trafic est acheminé en fonction de l'adresse IP de destination. Point final. Pour les architectes réseau habitués aux fonctionnalités avancées des équipements on-premise (Cisco, Juniper, Palo Alto), cette limitation était frustrante. AWS vient de combler ce gap avec l'annonce de la disponibilité générale du **Policy-Based Routing (PBR)** sur [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html). Cette fonctionnalité, annoncée le 30 juillet 2026, permet désormais de prendre des décisions de routage basées sur une combinaison d'attributs : adresse IP source, adresse IP destination, ports, et protocole. C'est un changement fondamental dans la manière dont nous concevons les architectures réseau sur AWS. ## Qu'est-ce que le Policy-Based Routing ? Le Policy-Based Routing est un mécanisme qui permet de diriger le trafic réseau en fonction de politiques définies par l'administrateur, plutôt que de s'appuyer uniquement sur la table de routage classique basée sur la destination. En d'autres termes, vous pouvez désormais dire : « tout le trafic HTTPS provenant du subnet applicatif à destination du port 443 doit passer par mon appliance d'inspection, tandis que le trafic SSH de l'équipe opérations peut prendre un chemin direct ». Sur AWS Transit Gateway, le PBR fonctionne avec un concept de **policy table** que vous associez à un attachement Transit Gateway. Dans cette table, vous définissez un ensemble ordonné de règles. Chaque règle classifie le trafic selon les critères suivants : - **Adresse IP source** : d'où vient le trafic - **Adresse IP destination** : où va le trafic - **Port source et destination** : quel service est utilisé - **Protocole** : TCP, UDP, ICMP, etc. Les règles sont évaluées dans l'ordre avec une logique **first-match-wins** : la première règle qui correspond au trafic détermine vers quelle route table le paquet sera dirigé. **Si aucune règle ne correspond, le trafic est silencieusement supprimé (implicit deny)**. Ce comportement, similaire à celui des Security Groups, impose de toujours prévoir une règle catch-all si vous souhaitez éviter les drops involontaires. ## Pourquoi c'est un game-changer ? ### Avant le PBR : la complexité architecturale Avant cette annonce, les architectes réseau qui avaient besoin de diriger le trafic de manière granulaire devaient construire des architectures multi-VPC complexes avec des sauts de routage supplémentaires. Concrètement, cela signifiait : - **Multiplier les VPC d'inspection** : un VPC dédié pour chaque type de trafic à inspecter différemment - **Ajouter des Gateway Load Balancers** : pour distribuer le trafic vers des appliances tierces - **Créer des chaînes de routage** : avec plusieurs Transit Gateway route tables interconnectées - **Gérer des coûts croissants** : chaque saut supplémentaire génère des frais de traitement de données Cette complexité se traduisait par une surcharge opérationnelle importante, des latences accrues, et un risque d'erreur de configuration élevé. ### Avec le PBR : la simplicité retrouvée Le PBR élimine une grande partie de cette complexité en étendant les capacités natives de routage du Transit Gateway. Plus besoin d'ajouter des couches intermédiaires : vous classifiez et dirigez le trafic directement au niveau du Transit Gateway, en une seule étape. ## Cas d'usage concrets Le PBR ouvre la porte à de nombreux scénarios que les équipes réseau et sécurité attendaient depuis longtemps. ### Inspection sélective du trafic C'est probablement le cas d'usage le plus demandé. Plutôt que de faire passer tout le trafic par [AWS Network Firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/what-is-aws-network-firewall.html) ou une appliance tierce (ce qui génère des coûts et de la latence), vous pouvez désormais ne router que le trafic sensible vers l'inspection. Par exemple : - Le trafic à destination des bases de données (port 3306, 5432) passe par l'inspection - Le trafic interne entre microservices sur des ports applicatifs connus peut contourner l'inspection - Le trafic vers des destinations externes spécifiques est systématiquement inspecté ### Routage basé sur la source pour la connectivité hybride Pour les entreprises utilisant [AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html) et [AWS VPN](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html) en parallèle, le PBR permet de diriger le trafic vers le bon chemin en fonction de sa source ou de son protocole : - Le trafic critique (bases de données, ERP) emprunte le Direct Connect pour bénéficier de la latence faible et de la bande passante garantie - Le trafic moins sensible (mises à jour, synchronisation) peut utiliser le VPN comme chemin secondaire - Le basculement peut être géré de manière plus fine en fonction des applications ### Isolation des environnements Le PBR permet d'isoler les environnements de production et de développement dans des domaines de routage séparés, limitant ainsi les mouvements latéraux. Même si deux environnements partagent des plages IP similaires ou des attachements communs, les règles PBR garantissent que le trafic de développement ne peut jamais atteindre les ressources de production, et inversement. ## Configuration et mise en place ### Contrainte fondamentale : policy table OU route table, jamais les deux C'est le point le plus important à comprendre avant de se lancer : **un attachement Transit Gateway ne peut être associé qu'à une policy table OU à une route table, jamais aux deux simultanément**. Il n'existe aucun mode hybride. Concrètement : - Si votre attachement VPC est actuellement associé à une route table classique, vous **devez d'abord dissocier** cette route table avant de pouvoir associer une policy table - Pendant la fenêtre de dissociation/association, **le trafic de cet attachement sera interrompu** - Une policy table vide (sans aucune règle) entraîne le **drop de tout le trafic entrant** sur cet attachement — c'est l'implicit deny Cette exclusivité signifie que le PBR remplace complètement la logique de routage classique pour un attachement donné. C'est un choix architectural binaire par attachement. ### Les étapes de mise en place La configuration du PBR se fait en quatre étapes : 1. **Créer les route tables cibles** : chaque règle PBR pointe vers une route table TGW qui contient les routes effectives 2. **Créer une policy table** : vous définissez une table de politiques associée à votre Transit Gateway 3. **Définir les règles** : vous créez un ensemble ordonné de règles (numérotées de 1 à 50 000) avec les critères de classification et la route table cible 4. **Dissocier la route table existante puis associer la policy table à l'attachement** Le PBR est configurable via la [Console AWS](https://console.aws.amazon.com/), l'[AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/ec2/), et les [SDK AWS](https://docs.aws.amazon.com/sdkref/latest/guide/overview.html). Les commandes CLI dédiées (`create-transit-gateway-policy-table`, `create-transit-gateway-policy-table-entry`, `associate-transit-gateway-policy-table`) sont disponibles dès maintenant. ### Exemple concret : filtrage HTTP/HTTPS et SSH Voici un exemple complet de mise en place via AWS CLI, qui implémente le scénario décrit en introduction : le trafic HTTPS est inspecté, le trafic SSH prend un chemin direct. ```bash # 1. Créer la policy table aws ec2 create-transit-gateway-policy-table \ --transit-gateway-id tgw-0bc994abffEXAMPLE \ --tag-specifications 'ResourceType=transit-gateway-policy-table,Tags=[{Key=Name,Value=app-security-policy}]' # Retourne : tgw-ptb-0ca78a549EXAMPLE # 2. Règle 100 : trafic HTTPS (port 443) du subnet applicatif → inspection firewall aws ec2 create-transit-gateway-policy-table-entry \ --transit-gateway-policy-table-id tgw-ptb-0ca78a549EXAMPLE \ --policy-rule-number 100 \ --policy-rule '{"SourceCidrBlock":"10.1.10.0/24","Protocol":"6","DestinationPortRange":"443"}' \ --target-route-table-id tgw-rtb-0a823edbdeEXAMPLE # 3. Règle 200 : trafic HTTP (port 80) → même inspection aws ec2 create-transit-gateway-policy-table-entry \ --transit-gateway-policy-table-id tgw-ptb-0ca78a549EXAMPLE \ --policy-rule-number 200 \ --policy-rule '{"SourceCidrBlock":"10.1.10.0/24","Protocol":"6","DestinationPortRange":"80"}' \ --target-route-table-id tgw-rtb-0a823edbdeEXAMPLE # 4. Règle 300 : trafic SSH (port 22) de l'équipe ops → routage direct (pas d'inspection) # Ne matche que si ce trafic entre bien par l'attachement associé à la policy table aws ec2 create-transit-gateway-policy-table-entry \ --transit-gateway-policy-table-id tgw-ptb-0ca78a549EXAMPLE \ --policy-rule-number 300 \ --policy-rule '{"SourceCidrBlock":"10.1.50.0/24","Protocol":"6","DestinationPortRange":"22"}' \ --target-route-table-id tgw-rtb-0b91f2c3d4EXAMPLE # 5. Règle 40000 : catch-all → routage par défaut (évite l'implicit deny) # Un policy-rule vide matche tout : toutes les conditions valent * par défaut aws ec2 create-transit-gateway-policy-table-entry \ --transit-gateway-policy-table-id tgw-ptb-0ca78a549EXAMPLE \ --policy-rule-number 40000 \ --policy-rule '{}' \ --target-route-table-id tgw-rtb-0f5e4d3c2bEXAMPLE # 6. Vérifier les entries avant de basculer l'attachement aws ec2 get-transit-gateway-policy-table-entries \ --transit-gateway-policy-table-id tgw-ptb-0ca78a549EXAMPLE # 7. Dissocier la route table existante de l'attachement source # Un attachement ne peut être associé qu'à une route table OU une policy table aws ec2 disassociate-transit-gateway-route-table \ --transit-gateway-attachment-id tgw-attach-0def6EXAMPLE \ --transit-gateway-route-table-id tgw-rtb-0c7d8e9f01EXAMPLE # 8. Attendre la fin de la dissociation : associer trop tôt fait échouer la requête while :; do STATE=$(aws ec2 get-transit-gateway-route-table-associations \ --transit-gateway-route-table-id tgw-rtb-0c7d8e9f01EXAMPLE \ --filters "Name=transit-gateway-attachment-id,Values=tgw-attach-0def6EXAMPLE" \ --query 'Associations[0].State' --output text) # "None" : l'association a disparu de la liste if [ "$STATE" = "None" ] || [ "$STATE" = "disassociated" ]; then break fi sleep 5 done # 9. Associer la policy table à l'attachement aws ec2 associate-transit-gateway-policy-table \ --transit-gateway-policy-table-id tgw-ptb-0ca78a549EXAMPLE \ --transit-gateway-attachment-id tgw-attach-0def6EXAMPLE # 10. Confirmer l'association aws ec2 get-transit-gateway-policy-table-associations \ --transit-gateway-policy-table-id tgw-ptb-0ca78a549EXAMPLE ``` Avec cette configuration, le trafic est traité comme suit : - Paquet TCP:443 depuis `10.1.10.x` → **inspecté par le firewall** (règle 100) - Paquet TCP:80 depuis `10.1.10.x` → **inspecté par le firewall** (règle 200) - Paquet TCP:22 depuis `10.1.50.x` → **routage direct** sans inspection (règle 300) - Tout autre trafic → **routage par défaut** (règle 40000 catch-all) ## Considérations et bonnes pratiques Comme toute fonctionnalité réseau avancée, le PBR nécessite une approche structurée : - **Commencez simple** : déployez d'abord une ou deux règles sur un attachement non-critique pour valider le comportement - **Documentez vos politiques** : la logique first-match-wins peut devenir complexe avec de nombreuses règles. Maintenez une documentation claire de l'ordre et de l'intention de chaque règle - **Surveillez les métriques** : utilisez [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) pour monitorer les hits sur chaque règle et identifier les règles inutilisées. La métrique `PacketDropCountNoPolicy` vous alerte quand du trafic est droppé faute de règle correspondante - **Prévoyez toujours une règle catch-all** : sauf si vous souhaitez explicitement un comportement Zero Trust (deny-all), ajoutez une règle à numéro élevé (ex: 40000) qui capture le trafic restant - **Laissez des gaps entre les numéros de règle** : utilisez 100, 200, 300… pour pouvoir insérer de nouvelles règles sans tout renuméroter - **Testez les scénarios de basculement** : validez que vos règles PBR se comportent correctement en cas de panne d'un attachement cible - **Attention au BGP** : associer une policy table à un attachement VPN (Site-to-Site) ou Connect **stoppe les advertisements BGP** vers le peer. Direct Connect n'est pas affecté (utilise la liste allowed-prefixes) ## Impact sur la latence réseau Une question légitime : le PBR ajoute-t-il de la latence au transit du trafic ? **La réponse est non.** L'évaluation des règles PBR s'effectue au niveau du plan de données du Transit Gateway, au même point de décision que la table de routage classique. Il n'y a pas de saut réseau supplémentaire, pas de composant intermédiaire ajouté dans le chemin. La décision est prise « en ligne » lors du transit du paquet. En réalité, le PBR peut même **réduire la latence globale** de votre architecture : - **Avant le PBR** : pour inspecter sélectivement le trafic, il fallait tout envoyer vers un VPC d'inspection (un saut supplémentaire) puis filtrer au niveau de l'appliance. Même le trafic « propre » subissait la traversée. - **Avec le PBR** : seul le trafic qui nécessite effectivement une inspection est dirigé vers l'appliance. Le reste prend le chemin direct, économisant un ou plusieurs sauts réseau. Les quotas de bande passante ne sont pas impactés non plus : chaque attachement VPC conserve sa capacité de 100 Gbps par Availability Zone dans chaque direction. ## Limites et quotas Comme tout service AWS, le PBR a ses limites qu'il faut connaître avant de concevoir votre architecture : | Ressource | Limite | Ajustable | |-----------|--------|-----------| | Policy tables par Transit Gateway | 20 | Non | | Policy entries (customer-managed) par TGW, toutes tables confondues | 200 | Oui | | Numéros de règle | 1 à 50 000 | — | | Types d'attachement supportés | VPC, VPN, Direct Connect, Connect, Peering (sauf Cloud WAN) | — | Autres contraintes importantes : - **Exclusivité absolue** : un attachement est associé à une policy table OU une route table, jamais les deux - **Pas de PBR sur les peering Cloud WAN** : seules les entries system-managed (gérées par Cloud WAN) s'appliquent sur ces attachements - **Ports limités à TCP/UDP** : le filtrage par port ne fonctionne que pour les protocoles TCP (6) et UDP (17). Pour ICMP, GRE ou « Any », les ports sont automatiquement à `*` - **Policy table vide = blackhole** : associer une policy table sans aucune règle à un attachement provoque le drop silencieux de tout le trafic - **Route table référencée non supprimable** : une route table utilisée comme cible par une policy entry ne peut pas être supprimée tant que la référence existe ## Migration : passer d'une route table au PBR sans coupure La migration vers le PBR est la question qui préoccupe le plus les équipes réseau en production. Soyons clairs : **il existe une micro-interruption inévitable** lors du basculement, car la dissociation de la route table et l'association de la policy table ne sont pas atomiques. Voici la stratégie recommandée pour minimiser l'impact : ### Approche progressive (recommandée) 1. **Préparez tout en amont** : créez la policy table, définissez toutes les règles, et créez les route tables cibles avec les routes nécessaires — tout cela sans aucun impact sur le trafic existant 2. **Commencez par un attachement non-critique** : choisissez un VPC de développement ou de test pour valider le comportement 3. **Incluez une règle catch-all qui réplique le comportement actuel** : votre règle à numéro élevé doit pointer vers une route table qui reproduit exactement le routage actuel. Ainsi, même si vos règles spécifiques ont un bug, le trafic continue de transiter 4. **Planifiez une fenêtre de maintenance** : la dissociation de la route table suivie de l'association de la policy table prend généralement quelques secondes, mais prévoyez 30 à 60 secondes de micro-coupure potentielle 5. **Basculez** : dissociez la route table, puis associez immédiatement la policy table 6. **Validez** : vérifiez les flux avec `GetTransitGatewayPolicyTableEntries` et surveillez la métrique `PacketDropCountNoPolicy` 7. **Itérez** : une fois validé, répétez sur les attachements de production ### Ce qui se passe pendant la bascule ``` [Route table associée] ──dissociation──▶ [Aucune association] ──association──▶ [Policy table associée] │ Trafic droppé pendant cette fenêtre (secondes) ``` Pendant la fenêtre où l'attachement n'a ni route table ni policy table, **le trafic entrant est droppé**. Les connexions TCP établies seront coupées et devront être ré-établies. Pour les protocoles stateless (UDP, ICMP), la reprise est transparente dès que la policy table est active. ### Stratégies de mitigation - **Applications tolérantes** : la plupart des applications avec des mécanismes de retry (HTTP, gRPC) survivent à une interruption de quelques secondes sans impact utilisateur visible - **Trafic critique** : pour les flux qui ne tolèrent aucune perte, envisagez un schéma de migration par duplication d'attachement — créez un second attachement VPC (dans un subnet dédié), migrez-le vers PBR, puis basculez le trafic applicatif vers ce nouveau subnet - **DNS failover** : si vous avez un mécanisme de failover DNS (Route 53 health checks), vous pouvez basculer le trafic temporairement vers un chemin alternatif le temps de la migration - **Coordination multi-AZ** : migrez un AZ à la fois si votre architecture le permet (attachements distincts par AZ) ### Rollback En cas de problème, le rollback est simple : dissociez la policy table et réassociez l'ancienne route table. La même micro-interruption s'applique dans l'autre sens. C'est pourquoi il est essentiel de **ne pas supprimer l'ancienne route table** tant que la migration n'est pas validée en production. ## Disponibilité et tarification Le Policy-Based Routing pour AWS Transit Gateway est disponible dans toutes les régions commerciales AWS où Transit Gateway est disponible. Point important : **le PBR n'engendre aucun coût supplémentaire** au-delà des frais standard de Transit Gateway (frais par attachement + frais de traitement de données). Il n'y a pas de tarification par règle ni par évaluation. C'est une excellente nouvelle car cela signifie que l'adoption ne sera pas freinée par des considérations budgétaires. ## Conclusion Pour les architectes réseau et les équipes sécurité, c'est une fonctionnalité qui va simplifier considérablement les architectures existantes tout en ouvrant de nouvelles possibilités. Mon conseil : si vous avez aujourd'hui des architectures multi-VPC complexes uniquement pour gérer du routage conditionnel, c'est le moment de revoir votre design. Le PBR peut potentiellement vous permettre de réduire le nombre de composants intermédiaires, diminuer la latence, et simplifier vos opérations quotidiennes. Commencez par identifier vos flux de trafic les plus critiques qui nécessitent un traitement différencié, puis testez le PBR sur un périmètre restreint avant de l'étendre à l'ensemble de votre organisation. --- # Construire une App Kiro Crew pour piloter son blog technique > 2026-08-10T08:00:00.000Z | https://sylvain.bruas.fr/blog/2026/08/kiro-crew-app-blog-admin Tags: kiro, ia, devops, react, open-source Summary: Créer une App Kiro Crew pour administrer un blog : dashboard de contenu, validation de posts sociaux, monitoring et jobs cron. ![App Kiro Crew — Blog Admin Dashboard](/static/2026/08/kiro-crew-app/kiro-crew-app.webp) Dans les deux articles précédents, nous avons exploré [l'architecture de Kiro Crew](/blog/2026/08/kiro-crew-part1) (Gateway, mémoire, sécurité) puis ses [cas d'usage concrets](/blog/2026/08/kiro-crew-part2) (cron jobs, orchestration multi-agent, Apps existantes). Cette troisième partie est un retour d'expérience : j'ai construit une **App Kiro Crew personnalisée** pour piloter l'administration de ce blog. L'objectif : regrouper dans une interface dédiée tout ce que je faisais manuellement — vérifier le statut des articles, valider les posts sociaux générés par l'agent, suivre les jobs planifiés, et monitorer les déploiements. ## Pourquoi une App plutôt qu'un chat ? Certains workflows ne rentrent pas dans une fenêtre de conversation. Quand je veux : - Voir d'un coup d'œil les 3 posts sociaux en attente de validation - Approuver ou rejeter un post LinkedIn d'un clic - Vérifier que le dernier déploiement a passé l'audit SEO - Toggler un cron job on/off sans écrire de commande ...une UI dédiée est plus efficace qu'un échange conversationnel. C'est exactement ce que les [Kiro Crew](https://kiro.dev/crew/) Apps permettent : combiner une interface React avec le runtime agent, l'event bus et les schedules dans un package cohérent. ## Architecture de l'App ![Architecture de l'App Blog Admin](/static/2026/08/kiro-crew-app/architecture.webp) Une App Kiro Crew suit une structure imposée par le framework. On peut générer un squelette via `kirocrew app init`, mais voici la structure complète de l'app blog-admin : ``` kirocrew/ ├── app.json # Manifeste KiroCrew (agents, crons, UI, backend) ├── agents/ # Définitions JSON des agents │ ├── content-validator.json │ ├── social-writer.json │ └── deploy-monitor.json ├── skills/ # Skills Markdown (contexte injecté aux agents) │ ├── blog-conventions/ │ │ └── SKILL.md │ └── social-publishing/ │ └── SKILL.md ├── backend/ # Backend Python (API interne) │ └── server.py ├── ui/ # Frontend React (pages du dashboard) │ ├── src/ │ │ ├── App.tsx # Point d'entrée (exporté en ESM) │ │ ├── components/ │ │ ├── pages/ │ │ ├── types/ │ │ └── data/ │ ├── package.json │ └── vite.config.ts └── README.md ``` **Stack UI** : [React](https://react.dev/) 19, TypeScript 5.9, [Vite](https://vite.dev/) 6, [Tailwind CSS](https://tailwindcss.com/) 4, [Lucide](https://lucide.dev/) pour les icônes. L'UI est buildée comme un **module ESM** (pas un SPA classique) car Kiro Crew injecte le composant dans son propre shell. Le routing interne utilise [React Router](https://reactrouter.com/) avec un `MemoryRouter` (Crew ne fournit pas de contexte Router parent). **Backend** : Python minimal (stdlib `http.server`) qui sert une API d'articles en scannant le filesystem. Kiro Crew le démarre automatiquement. **Agents** : 3 fichiers JSON déclarant chacun un agent spécialisé avec son prompt et ses outils autorisés. **Skills** : fichiers Markdown injectés comme contexte aux agents, encodant les conventions du blog. ## Le manifeste `app.json` Le fichier `app.json` est le point d'entrée de l'App auprès du runtime [Kiro Crew](https://github.com/kirodotdev/KiroCrew). Il déclare les agents, les crons, le backend et l'UI. On peut le créer manuellement ou générer un squelette avec `kirocrew app init blog-admin --ui --backend --cron`. ```json { "name": "blog-admin", "version": "1.0.0", "displayName": "Blog Admin Dashboard", "description": "Dashboard d'administration pour sylvain.bruas.fr", "author": "sylvainbruas", "agents": [ "agents/content-validator.json", "agents/social-writer.json", "agents/deploy-monitor.json" ], "skills": [ "skills/blog-conventions", "skills/social-publishing" ], "tags": ["blog", "admin", "social", "seo", "deployment"], "backend": { "entryPoint": "backend/server.py", "port": "auto", "healthCheck": "/health" }, "ui": { "entry": "dist/index.mjs", "pages": [ { "route": "/apps/blog-admin", "label": "Blog Admin", "icon": "LayoutDashboard" }, { "route": "/apps/blog-admin/articles", "label": "Articles", "icon": "FileText" }, { "route": "/apps/blog-admin/social", "label": "Social", "icon": "Share2" }, { "route": "/apps/blog-admin/jobs", "label": "Jobs", "icon": "Clock" }, { "route": "/apps/blog-admin/deployments", "label": "Déploiements", "icon": "Rocket" } ] }, "crons": [ { "name": "seo-audit-weekly", "every": 604800, "message": "Audit SEO complet de tous les articles publiés", "enabled": false }, { "name": "dep-scan-daily", "every": 86400, "message": "Scan de vulnérabilités des dépendances npm", "enabled": false }, { "name": "git-hygiene", "every": 259200, "message": "Identifier les branches stale et commits WIP abandonnés", "enabled": false }, { "name": "redirect-check", "every": 604800, "message": "Vérifier que toutes les redirections S3 fonctionnent", "enabled": false }, { "name": "friday-summary", "every": 604800, "message": "Résumer les déploiements de la semaine", "enabled": false }, { "name": "social-gen", "every": 86400, "message": "Générer des posts sociaux pour le dernier article publié", "enabled": false } ] } ``` Points clés du manifeste : - **`agents`** : chemins relatifs vers les fichiers JSON de définition d'agents - **`skills`** : dossiers contenant un `SKILL.md` qui sera injecté comme contexte - **`backend`** : serveur Python démarré automatiquement par Crew, avec healthcheck - **`ui.entry`** : le module ESM buildé par Vite — Crew l'injecte dans son shell - **`ui.pages`** : routes et labels affichés dans la navigation du dashboard Crew - **`crons`** : jobs récurrents avec `"every"` en secondes, un `"message"` envoyé à l'agent, et `"enabled": false` pour les déclarer sans les activer immédiatement ## Page Dashboard ![Blog Dashboard](/static/2026/08/kiro-crew-app/dashboard.webp) Le Dashboard donne une vue d'ensemble en un coup d'œil : ```tsx // Extrait simplifié du DashboardPage.tsx const DashboardPage = () => { const stats = mockDashboardStats return (
{/* + Dernier déploiement avec scores audit */} {/* + Posts sociaux en attente */} {/* + Dernières exécutions de jobs */}
) } ``` **4 métriques clés** : articles publiés, posts sociaux en attente de validation, déploiements de la semaine, crédits Kiro Crew consommés. En dessous : le dernier déploiement avec ses scores d'audit (SEO, Lighthouse), les posts en attente, et les dernières exécutions de jobs. ## Page Validation des posts sociaux ![Flux de publication sociale](/static/2026/08/kiro-crew-app/social-flow.webp) Quand l'agent `social-writer` génère des posts à partir d'un article, ils arrivent ici en statut "En attente" : - **Chaque post** est affiché avec sa plateforme (X, LinkedIn, Bluesky), son contenu complet, et la date de génération - **Deux boutons** : ✓ Approuver / ✗ Rejeter - **Après approbation** : un bouton "Publier" apparaît pour déclencher l'envoi via l'API de la plateforme L'idée est de garder l'humain dans la boucle pour la publication sociale — l'agent rédige, vous validez. Le mode `supervised` dans le manifeste Crew garantit que rien ne part sans approbation explicite. ## Page Jobs planifiés ![Cycle de vie d'un cron job](/static/2026/08/kiro-crew-app/cron-lifecycle.webp) ![Cron Dashboard](/static/2026/08/kiro-crew-app/cron-dashboard.webp) Cette page expose les 6 jobs déclarés dans `app.json` avec une interface de gestion : - **Toggle on/off** pour activer/désactiver un job sans toucher au manifeste - **Bouton "Run"** pour déclencher une exécution manuelle - **Panel expandable** montrant : durée de la dernière exécution, crédits consommés, output terminal, historique des runs ```tsx // Chaque job affiche son schedule et son dernier output {job.lastRun?.output && ( 
      {job.lastRun.output}
)} ``` **Point économique** : les jobs sont déclarés avec `"enabled": false` dans le manifeste. Cela permet de versionner la configuration sans déclencher d'exécutions dès l'installation. On active ensuite individuellement via le toggle dans l'interface, ou en CLI avec `kirocrew cron enable blog-admin/seo-audit-weekly`. Le scan de dépendances et la vérification des redirections sont des scripts purs (0 crédit). Seuls l'audit SEO, le résumé de fin de semaine et la génération de posts sociaux consomment des crédits d'inférence. | Job | Fréquence | Crédits/run | |-----|-----------|-------------| | Audit SEO | Lundi 8h | 3 | | Scan dépendances | Weekdays 9h | 0 (script) | | Nettoyage Git | Mar/Jeu 10h | 1 | | Vérification redirections | Mercredi 10h | 0 (script) | | Résumé fin de semaine | Vendredi 16h | 4 | | Génération posts sociaux | À la publication | 5 | **Total estimé** : ~18 crédits/semaine, soit environ $3/mois sur un plan Pro. ## Déployer l'App sur Kiro Crew Pour enregistrer et exécuter cette App dans votre instance Kiro Crew : ### Prérequis - [Kiro Crew](https://github.com/kirodotdev/KiroCrew) installé et le Gateway actif (`kirocrew gateway`) - Un compte Kiro authentifié (plan Free minimum, Pro recommandé) - Node.js 18+ pour le build de l'UI - Python 3.10+ pour le backend ### Étape 1 : Génération du squelette (optionnel) Si vous partez de zéro, `kirocrew app init` génère le squelette : ```bash kirocrew app init blog-admin --ui --backend --cron ``` Cela crée la structure de base avec `app.json`, un agent exemple, un skill, un backend Python et un frontend Vite. ### Étape 2 : Build de l'UI ```bash cd kirocrew/ui pnpm install pnpm build # → Génère dist/index.mjs (module ESM) ``` ### Étape 3 : Installer l'App dans Kiro Crew ```bash kirocrew app install /chemin/vers/kirocrew ``` Kiro Crew lit le `app.json`, déploie les agents, programme les crons, démarre le backend, et injecte l'UI dans le dashboard. ### Étape 4 : Activer et vérifier ```bash # Activer l'app kirocrew app enable blog-admin # Vérifier l'installation kirocrew app info blog-admin # Lister toutes les apps installées kirocrew app list ``` ### Mode développement Pour itérer rapidement sur l'UI sans rebuild à chaque modification : ```bash # Active le live reload dans le dashboard Crew kirocrew app dev blog-admin # Ou lancer le dev server Vite en standalone cd kirocrew/ui && pnpm dev # → http://localhost:3100 ``` `kirocrew app dev` active le mode no-store + live reload sur les changements de fichiers. Pratique pour ajuster le dashboard sans reconstruire à chaque fois. ### Mode Docker (serveur always-on) Pour une instance persistante qui tourne même quand votre Mac est éteint : ```bash docker run -d --name kirocrew \ -p 127.0.0.1:5476:5476 \ -v kirocrew-home:/home/kirocrew \ ghcr.io/kirodotdev/kirocrew:stable ``` Une fois le container actif, installez l'app depuis le container ou montez le répertoire en volume. ### Désinstallation ```bash # Désactiver sans supprimer les données kirocrew app disable blog-admin # Supprimer complètement (préserve les données par défaut) kirocrew app uninstall blog-admin ``` ## Connecter aux données réelles ### Le backend Python Le fichier `backend/server.py` scanne directement le filesystem pour lister les articles et calcule les statistiques : ```python def scan_articles(): """Scan le répertoire blog pour extraire les frontmatter.""" articles = [] blog_path = Path(BLOG_DIR) for mdx_file in blog_path.rglob("index.mdx"): slug = str(mdx_file.parent.relative_to(blog_path)) content = mdx_file.read_text(encoding="utf-8") frontmatter = parse_frontmatter(content) status = determine_status(frontmatter, slug, devto_data) articles.append({ "slug": slug, "title": frontmatter.get("title", ""), "date": str(frontmatter.get("date", ""))[:10], "lang": frontmatter.get("lang", "fr"), "status": status, "tags": frontmatter.get("tags", []), "summary": frontmatter.get("summary", ""), "cover": frontmatter.get("cover", ""), }) return articles ``` Kiro Crew démarre ce backend automatiquement (déclaré dans `app.json` → `backend.entryPoint`). ### Le hook `useApi` Côté UI, un hook React générique gère les appels au backend via le gateway Crew : ```tsx function useApi(endpoint: string): FetchState { // Essaie les routes du gateway, puis fallback sur le port direct const fetchData = useCallback(() => { apiFetch(endpoint) .then((res) => res.json()) .then((json) => setData(json)) .catch((err) => setError(err.message)) }, [endpoint]) useEffect(() => { fetchData() }, [fetchData]) return { data, loading, error, refetch: fetchData } } ``` Chaque page consomme ce hook : `useApi('/articles')` pour la liste, `useApi('/stats')` pour les compteurs. ## Ce que j'ai appris ### Pièges d'intégration avec le shell Crew En déployant l'app pour la première fois, j'ai rencontré trois problèmes classiques d'intégration : 1. **Le chemin `ui.entry`** — Le manifeste résout le chemin depuis le dossier `ui/` de l'app, pas depuis sa racine. Mettre `ui/dist/index.mjs` donnait une URL doublée (`/ui/ui/dist/...`). La valeur correcte est `dist/index.mjs`. 2. **Les externals Vite** — Externaliser `lucide-react` pour réduire la taille du bundle semble logique, mais la version fournie par le runtime Crew ne contient pas forcément les mêmes exports que celle du projet. Mieux vaut bundler les icônes directement (~10 kB supplémentaires) pour éviter les erreurs `does not provide an export named 'X'`. 3. **Le thème dark du shell** — Le dashboard Crew est en thème sombre. Si l'app utilise des classes Tailwind en mode clair (`bg-white`, `text-gray-900`), il faut forcer `colorScheme: 'light'` et un fond explicite sur le conteneur racine pour que les couleurs ne soient pas écrasées par le thème parent. 4. **Le Router** — Crew injecte le composant App dans son propre shell sans fournir de contexte ``. Il faut wraper l'app avec un `` pour que `react-router-dom` fonctionne. ### Le modèle mental "agent + UI" fonctionne La séparation est nette : l'agent fait le travail lourd (rédiger, valider, scanner), l'UI donne le contrôle (approuver, rejeter, toggler, monitorer). Le mode `supervised` est essentiel pour les actions irréversibles comme publier sur les réseaux sociaux. ### Les scripts zero-credit sont sous-estimés Sur mes jobs planifiés, 2 ne consomment aucun crédit parce que ce sont des scripts bash simples. Le scan de dépendances (`npm audit --json`) et la vérification des redirections (`scripts/test-redirects.sh`) n'ont pas besoin de raisonnement IA. Kiro Crew les exécute directement sans appel modèle. ### La mémoire persistante évite la dérive Après quelques corrections sur les posts sociaux générés ("trop long pour X", "ajoute toujours le lien canonique", "pas d'émoji dans les posts LinkedIn pro"), l'agent apprend et les prochains drafts respectent les préférences. Sans mémoire persistante, il faudrait ré-expliquer ces conventions à chaque session. ### Le rapport d'audit pré-deploy est un filet de sécurité J'ai découvert un build cassé à cause d'une image PNG (au lieu de WebP) uniquement parce que l'audit l'a détecté. Sans ce check automatique, l'article serait parti en production avec un cover manquant. ## Conclusion Construire une App Kiro Crew se résume à : 1. **Générer le squelette** avec `kirocrew app init mon-app --ui --backend --cron` 2. **Définir** les agents (JSON) et skills (Markdown) 3. **Coder** l'UI React exportée en module ESM 4. **Installer** avec `kirocrew app install ./mon-app` 5. **Itérer** avec `kirocrew app dev mon-app` (live reload) La courbe d'apprentissage est faible si vous connaissez déjà React et TypeScript. Le vrai travail est dans la définition des agents et des skills. --- **Sources :** - [kiro.dev/crew](https://kiro.dev/crew/) — Page produit officielle - [github.com/kirodotdev/KiroCrew](https://github.com/kirodotdev/KiroCrew) — Repository GitHub - [kiro.dev/blog/introducing-kiro-crew](https://kiro.dev/blog/introducing-kiro-crew/) — Blog post de lancement - [dev.to/aws-builders — Getting Started with Kiro Crew](https://dev.to/aws-builders/getting-started-with-kiro-crew-23l5) — Guide de démarrage --- # Kiro Crew : cas d'usage, Apps et perspectives — Partie 2 > 2026-08-09T13:00:00.000Z | https://sylvain.bruas.fr/blog/2026/08/kiro-crew-part2 Tags: kiro, ia, devops, architecture, open-source Summary: Jobs cron, webhooks, investigation multi-repo, migrations, Apps (DevFleets, Issue Radar, Code Review Sage) et perspectives. ![Kiro Crew — cas d'usage et perspectives](/static/2026/08/kiro-crew/kiro-crew-cover.webp) Dans la [première partie](/blog/2026/08/kiro-crew-part1), nous avons exploré l'architecture de Kiro Crew : le Gateway, le système de mémoire, le modèle de sécurité et le positionnement dans l'écosystème Kiro. Cette seconde partie entre dans le concret : comment utiliser Kiro Crew au quotidien, quelles Apps installer, et quelles perspectives s'ouvrent pour les équipes de développement. ## Travail planifié : cron, webhooks et heartbeats C'est là que Kiro Crew se distingue radicalement de tous les autres outils de coding assisté par IA. Aucun d'entre eux ne propose du travail **planifié et non-supervisé**. ![Workflow cron et scheduling](/static/2026/08/kiro-crew/cron-workflow.webp) ### Jobs cron Les jobs cron de Kiro Crew sont timezone-aware, avec timeouts par job, jitter pour éviter les thundering herds, et skip dates pour les fenêtres de maintenance. ```bash # Gérer les jobs cron kirocrew cron list kirocrew cron add kirocrew cron remove # Exemple via le chat : créer un digest matinal > "Tous les jours à 9h, résume les PRs ouvertes et flag celles qui nécessitent mon attention" # → Crée un job cron timezone-aware livré sur la surface de votre choix ``` **Point économique crucial** : les jobs qui ne nécessitent pas de raisonnement IA s'exécutent comme de simples scripts ou commandes **sans appel modèle**. Un health check, un `git status`, un scan de dépendances — zéro crédit consommé. Seules les étapes qui nécessitent du raisonnement coûtent des crédits. ### Webhooks authentifiés Des endpoints authentifiés déclenchent du travail agent quand un événement externe arrive — un push CI, une alerte monitoring, un ticket créé. ```bash # Exemple d'architecture webhook # Alert PagerDuty → Webhook Kiro Crew → Investigation automatique # Le webhook reçoit un payload, démarre une session agent # qui investigue les logs et corrèle les timestamps ``` ### Heartbeats Les heartbeats surveillent un changement d'état : une PR qui passe en "merged", un déploiement qui échoue, un pipeline CI qui casse deux fois de suite. Quand la condition est remplie, Kiro Crew déclenche le travail associé. ![Séquence heartbeat — monitoring et investigation automatique](/static/2026/08/kiro-crew/heartbeat-sequence.webp) ## Orchestration multi-agent Kiro Crew peut exécuter **plusieurs conversations en parallèle**, chacune avec un contexte isolé. Il délègue la recherche et l'implémentation indépendantes à des sous-agents qui retournent leurs résultats au parent. ![Orchestration multi-agent avec délégation](/static/2026/08/kiro-crew/multi-agent-delegation.webp) ```bash # Spawner des agents parallèles kirocrew spawn run "Analyze the source code of module auth" kirocrew spawn run "Write migration tests for the new schema" kirocrew spawn run "Generate API documentation from OpenAPI spec" # Le parent coordonne, les sous-agents travaillent en isolation ``` ### Exemple concret : migration CDK Imaginez une migration de 12 stacks CloudFormation vers CDK. Chaque stack prend 20-40 minutes de traitement agent. Avec Kiro Crew : ![Flowchart migration CDK avec checkpoints](/static/2026/08/kiro-crew/migration-flowchart.webp) Chaque stack est un checkpoint. Si la stack 7 échoue la validation, Kiro Crew retry avec une approche différente. Vous ne repartez pas de la stack 1. Vous revenez le lendemain matin à une PR avec les 12 outputs CDK validés. ```bash # Lancer une migration avec checkpoints kirocrew run migration-plan.md # Le fichier migration-plan.md contient les étapes, # les critères de validation, et les retry policies ``` ## Les Apps : interfaces dédiées Certains travaux ne rentrent pas dans une fenêtre de chat. Kiro Crew les porte dans des **Apps** — des interfaces purpose-built qui combinent agents, skills, schedules, intégrations et services backend. ![Écosystème des Apps Kiro Crew](/static/2026/08/kiro-crew/apps-ecosystem.webp) ### L'App LaunchDarkly Un exemple concret d'intégration tierce : l'App LaunchDarkly permet de gérer les feature flags directement depuis Kiro Crew. Un agent peut trouver les références de flags dans le code, implémenter un changement derrière un flag, et vous rendre les contrôles pour le rollout. *Source : [kiro.dev/blog/introducing-kiro-crew](https://kiro.dev/blog/introducing-kiro-crew/)* ## Cas d'usage concrets ### 1. Digest matinal de PRs ```bash # La partie "list PRs" est un script → zéro crédits # La partie "summarize" est un appel modèle → 2-3 crédits # Résultat livré sur Slack/Discord/Dashboard avant le premier café ``` **Coût estimé** : sur un plan Pro (1 000 crédits/mois à $20), un digest quotidien consomme ~60 crédits/mois. Il reste 940 crédits pour le travail interactif. ### 2. Drift de dépendances ```bash # Job cron hebdomadaire # Semaine normale (rien à updater) → script simple → 0 crédits # Semaine avec advisory → raisonnement agent → 8-12 crédits → PR kirocrew cron add \ --name "dependency-drift" \ --schedule "0 8 * * WED" \ --task "Check for outdated packages, stale branches, and docs that no longer match the code. If issues found, open an issue with versions, breaking changes, and upgrade path." ``` ## outils de communication Kiro Crew vous rejoint **là où vous êtes déjà**. Pas besoin d'ouvrir un outil supplémentaire : | Outil | Usage optimal | |---------|--------------| | **Desktop app** | Expérience locale complète, Gateway bundlé | | **Web dashboard** | Conversations parallèles, mémoire, schedules, apps | | **Slack** | DMs et threads avec streaming, approvals, notifications | | **Telegram** | DMs depuis mobile, réponses en streaming | | **Discord** | DMs avec approvals en boutons | | **Teams** | Messages avec streaming | | **CLI** | Automatisation directe (`kirocrew chat`, `run`, `cron`, `spawn`) | *Source : [GitHub kirodotdev/KiroCrew — Surface table](https://github.com/kirodotdev/KiroCrew)* ## Perspectives et idées d'utilisation ![Perspectives d'utilisation](/static/2026/08/kiro-crew/perspectives.webp) ### Pour une équipe DevOps/SRE - **Morning standup automatique** : digest des alertes de la nuit, PRs en attente, état des pipelines - **Rotation d'astreinte assistée** : l'agent fait la première investigation et escalade si nécessaire - **Drift detection IaC** : comparaison quotidienne entre l'état Terraform et l'infrastructure réelle - **Post-mortem assisté** : corrélation automatique des logs et timeline d'incident ### Pour une web agency - **Audit SEO récurrent** : scan hebdomadaire des sites clients avec rapport - **Mise à jour de dépendances** : test + PR automatique pour les patches de sécurité - **Monitoring de performance** : heartbeat sur Lighthouse scores, alerte si régression - **Génération de changelog** : à chaque release, compilation automatique depuis les commits ### Pour un lead technique - **Code review augmentée** : analyse de blast radius, détection de patterns anti-DRY - **Onboarding assisté** : l'agent répond aux questions du nouveau avec le contexte du projet - **Tech radar automatisé** : veille hebdomadaire sur les dépendances et les nouvelles versions - **Documentation vivante** : mise à jour automatique des docs quand le code change ### Pour un développeur solo - **CI personnelle** : tests, lint, et déploiement automatiques sur chaque push - **Project memory** : ne jamais perdre le contexte d'un side project laissé en pause 3 mois - **Pair programming asynchrone** : laisser Crew travailler sur un problème pendant la nuit ## Limites à connaître Pour être complet, voici les limites actuelles : 1. **Dépendance au plan Kiro** : Crew est open source, mais la CLI qu'il pilote nécessite un compte Kiro et des crédits. 2. **Les agents parallèles multiplient les coûts** : 3 sous-agents = 3× les crédits. Architecturez vos workflows pour utiliser l'exécution séquentielle quand l'ordre compte, et le parallèle uniquement pour le travail indépendant. 3. **Crew n'architecte pas** : Il coordonne et exécute. Il ne prend pas les décisions de design à votre place. Vous restez l'ingénieur qui décide quoi construire et pourquoi. ## Conclusion Ce qui change fondamentalement avec Kiro Crew, ce n'est pas la vitesse d'exécution. C'est la **continuité**. Aujourd'hui, chaque session avec un agent IA commence par une phase de reconnexion : rappeler le contexte, re-expliquer les contraintes, relancer ce qui avait été fait la veille. Kiro Crew élimine cette friction. La mémoire persiste, les jobs tournent en arrière-plan, les webhooks réagissent pendant que vous dormez. Le matin, vous trouvez une PR prête, pas un thread de chat à relire. Mon conseil pour démarrer : identifiez un workflow qui dépasse déjà une seule session. Une migration multi-stacks, un audit de dépendances récurrent, un monitoring de drift IaC. C'est là que Crew apporte le plus de valeur — sur le travail que personne n'a le temps de faire manuellement, mais que tout le monde sait nécessaire. Le projet est sur GitHub : [github.com/kirodotdev/KiroCrew](https://github.com/kirodotdev/KiroCrew) --- **Sources :** - [kiro.dev/crew](https://kiro.dev/crew/) — Page produit officielle - [kiro.dev/blog/introducing-kiro-crew](https://kiro.dev/blog/introducing-kiro-crew/) — Blog post de lancement - [github.com/kirodotdev/KiroCrew](https://github.com/kirodotdev/KiroCrew) — Repository GitHub (README, architecture, sécurité) - [infoworld.com — AWS's Kiro Crew aims to turn AI coding agents into autonomous engineering teams](https://www.infoworld.com/article/4204961/awss-kiro-crew-aims-to-turn-ai-coding-agents-into-autonomous-engineering-teams.html) - [dev.to/sarvar_04 — Introducing Kiro Crew: AWS's Open-Source AI Agent Orchestrator](https://dev.to/sarvar_04/introducing-kiro-crew-awss-open-source-ai-agent-orchestrator-1e63) - [siliconangle.com — AWS launches Kiro Crew](https://siliconangle.com/2026/08/04/aws-launches-kiro-crew-autonomous-agentic-orchestrator-24-7-code-development/) - [opensourceforu.com — AWS Open Sources Kiro Crew](https://www.opensourceforu.com/2026/08/aws-open-sources-kiro-crew-for-autonomous-ai-engineering-teams/) --- # Kiro Crew : orchestrateur multi-agents — Partie 1 > 2026-08-08T12:00:00.000Z | https://sylvain.bruas.fr/blog/2026/08/kiro-crew-part1 Tags: kiro, ia, devops, architecture, open-source Summary: Kiro Crew : workspace multi-agents persistant et open source. Architecture, mémoire inter-sessions, tâches récurrentes et modèle de sécurité. ![Kiro Crew — orchestrateur multi-agents persistant](/static/2026/08/kiro-crew/kiro-crew-cover.webp) Dans un [précédent article](/blog/2026/07/kiro-starter), nous avons exploré la plateforme Kiro dans sa globalité : IDE, CLI, Web, et la construction d'un starter kit pour une web agency. Depuis, l'écosystème Kiro a pris une dimension supplémentaire avec le lancement de **Kiro Crew** le 4 août 2026 — un workspace de développement persistant, open source sous licence Apache 2.0, qui transforme les agents IA en coéquipiers autonomes. Cette série en deux parties explore Kiro Crew en profondeur. Dans cette première partie : l'origine, l'architecture, le système de mémoire et le modèle de sécurité. La [seconde partie](/blog/2026/08/kiro-crew-part2) couvre les cas d'usage concrets, les Apps, les exemples de code et les perspectives d'utilisation. ## De MeshClaw à Kiro Crew : l'origine Kiro Crew est né d'un projet interne chez Amazon, baptisé **MeshClaw**. Ils voulaient quelque chose de simple : lancer une tâche, partir, revenir à quelque chose de reviewable, et exécuter plusieurs tâches en parallèle au lieu de surveiller un seul prompt à la fois. ## Le problème fondamental Le blog officiel de lancement ([kiro.dev/blog/introducing-kiro-crew](https://kiro.dev/blog/introducing-kiro-crew/)) pose le problème clairement : **le développeur est devenu la couche d'intégration entre ses propres outils**. Le travail d'ingénierie réel n'est jamais une tâche dans une session. Il traverse des repos, des outils, des reviews, et des jours. Quand vous fermez un onglet de Kiro CLI ou IDE, le contexte disparaît. La prochaine session commence à froid. Vous passez les 10 premières minutes à ré-expliquer où vous en étiez. Et le moment où vous partez, tout s'arrête. Kiro Crew rompt ce pattern en rendant le workspace **persistant** : - La mémoire se maintient entre les sessions - Les corrections deviennent des leçons durables - Les patterns répétés deviennent des skills réutilisables - Le travail continue sur un schedule même quand vous n'êtes plus là ## Architecture : la Gateway au centre L'architecture de Kiro Crew repose sur une séparation claire entre **là où l'agent tourne** et **là où vous travaillez avec lui**. ![Architecture Kiro Crew — Gateway et sessions](/static/2026/08/kiro-crew/architecture-gateway.webp) *Source : [README du repository GitHub kirodotdev/KiroCrew](https://github.com/kirodotdev/KiroCrew)* ### Les trois couches | Couche | Rôle | |--------|------| | **Surfaces** | Desktop app, web dashboard, Slack, Telegram, Discord, Teams, Webex, WeCom, CLI | | **Gateway** | Process long-running qui route les messages, persiste l'état des sessions, injecte mémoire et skills, lance le travail schedulé, coordonne les sous-agents, broker les approbations | | **Agent sessions** | Sessions isolées pilotées par `kiro-cli` via ACP, avec accès aux outils MCP et aux modèles | Le Gateway est le cœur du système. C'est un processus unique qui tourne sur votre machine (Mac, Linux, conteneur Docker, ou serveur distant). Les conversations, la mémoire et les index restent sur cet hôte. Les requêtes aux modèles passent par `kiro-cli` selon votre configuration de compte. ### Déploiement Kiro Crew supporte plusieurs modes de déploiement, tous basés sur le même principe : Gateway + sessions agent + état sur un seul hôte. ```bash # Installation one-liner (stable) curl -fsSL https://download.crew.kiro.dev/cli.sh | sh # Ou Docker pour un serveur always-on docker run -d --name kirocrew \ -p 127.0.0.1:5476:5476 \ -v kirocrew-home:/home/kirocrew \ ghcr.io/kirodotdev/kirocrew:stable # Ou build from source git clone https://github.com/kirodotdev/KiroCrew.git cd KiroCrew make build source .venv/bin/activate kirocrew setup kirocrew doctor kirocrew gateway ``` *Source : [GitHub kirodotdev/KiroCrew — Quick start](https://github.com/kirodotdev/KiroCrew)* Le dashboard web est accessible sur `http://localhost:5476` et ne nécessite aucun credential de messaging. Il bindé sur loopback par défaut — les dashboards distants requièrent une authentification par token. ### Agent Client Protocol (ACP) Kiro Crew orchestre ses agents via l'**Agent Client Protocol (ACP)**, un standard ouvert qui permet aux agents IA de fonctionner avec n'importe quel éditeur compatible. Chaque étape est observable en live : vous pouvez suivre comment l'agent planifie une tâche, spawne des sous-agents parallèles, décide quels outils appeler, gate chaque action pour approbation, et synthétise les résultats. ## Le système de mémoire : self-learning et self-evolving ![Système de mémoire Kiro Crew](/static/2026/08/kiro-crew/memory-system.webp) Le système de mémoire de Kiro Crew ne se limite pas à "se souvenir de la dernière conversation". C'est un système à plusieurs niveaux, persistant et inspectable. ### Trois types de mémoire | Type | Description | Portée | |------|-------------|--------| | **Memory** | Préférences, projets actifs, historique pertinent | Cross-session | | **Lessons** | Corrections transformées en règles durables | Workspace-scoped | | **Skills** | Patterns répétés synthétisés en fichiers Markdown nommés | Éditables et partageables | ### Knowledge Graph Les décisions architecturales, préférences de code et contexte projet atterrissent dans un **knowledge graph** soutenu par des embeddings vectoriels et une recherche full-text. L'agent retrouve ce qui est pertinent au lieu de tout relire. ### Leçons workspace-scoped Un point essentiel : les leçons sont **scopées au workspace**. Dites une fois à Kiro Crew « ne jamais utiliser `var` en JavaScript » et cette correction devient une règle permanente *pour ce projet*. Les règles du projet A ne contaminent pas le projet B. ```bash # Exemple de commande naturelle qui crée une leçon # Dans un chat Kiro Crew : > "Non, toujours exécuter les checks frontend avant de déclarer un changement terminé" # → Devient une leçon workspace-scoped appliquée dans les sessions futures ``` ## Sécurité : defense in depth Donner à un agent un accès réel à votre code et votre CI exige un modèle de sécurité sérieux. Kiro Crew est construit avec la sécurité dès le premier commit, sur 7 couches distinctes. ![Les 7 couches de sécurité de Kiro Crew](/static/2026/08/kiro-crew/security-layers.webp) ### Détail des couches | Couche | Fonction | |--------|----------| | **OS Sandbox** | Isolation namespace (Linux) ou Seatbelt (macOS). Modes : standard, strict, off | | **Tool Approval Gates** | Chaque requête outil peut être reviewée dans le dashboard, Slack ou Telegram | | **Sensitive Path Blocking** | Blocage d'accès aux chemins protégés (credentials, clés SSH, etc.) | | **Write-Protected Paths** | Certains fichiers/dossiers sont en lecture seule pour l'agent | | **Denied Command Patterns** | 137 patterns deny bloquent les commandes destructives et l'exfiltration | | **MCP Input Validation** | Validation des entrées et redaction des sorties avant qu'elles n'atteignent le chat | | **Audit & Signed Events** | Log structuré de chaque action, vérifiable avec `kirocrew security verify` | ### Audit et gouvernance ```bash # Inspecter les événements de sécurité kirocrew security events # Auditer les actions passées kirocrew security audit # Vérifier l'intégrité des logs kirocrew security verify # Afficher la politique de gouvernance active kirocrew policy show kirocrew policy validate kirocrew policy explain ``` La gouvernance suit un modèle **tightest-wins** : une app ou un agent peut restreindre les permissions mais ne peut jamais élargir le plafond défini par l'entreprise. ```json // Politique de gouvernance enterprise (exemple) { "version": 1, "boot": { "fail_closed": true }, "capabilities": { "telemetry": { "enabled": false } } } ``` *Source : [GitHub kirodotdev/KiroCrew — Security and control](https://github.com/kirodotdev/KiroCrew)* ### Pourquoi l'open source change tout L'argument clé : un workspace avec accès à votre code, CI et credentials ne devrait **jamais** être une boîte noire. Parce que Kiro Crew est open source, vous pouvez : - Lire le code source et tracer l'exécution - Vérifier que le sandbox sandboxe réellement - Auditer les patterns deny et les chemins protégés - Confirmer qu'aucune donnée ne quitte votre machine sans votre consentement ## Kiro Crew dans l'écosystème Kiro ![Les surfaces de l'écosystème Kiro](/static/2026/08/kiro-crew/ecosystem-surfaces.webp) Kiro dispose maintenant de **quatre surfaces** : IDE, CLI, Web et Crew. Voici comment elles se positionnent : | | Kiro IDE | Kiro CLI | Kiro Web | **Kiro Crew** | |---|---|---|---|---| | **Sessions** | Interactives | Interactives | Interactives | **Persistantes, autonomes** | | **Scheduling** | Non | Non | Non | **Cron, webhooks, heartbeats** | | **Multi-agent** | Non | Sous-agents | Non | **Orchestration parallèle complète** | | **Mémoire** | Session only | Session only | Session only | **Cross-session persistante** | | **Travail sans surveillance** | Non | Non | Non | **Oui** | | **Open source** | Non | Non | Non | **Oui** | ### Compatibilité avec la configuration existante **Point crucial** : Kiro Crew lit votre configuration `.kiro` existante. Vos steering files, skills et custom agents sont automatiquement disponibles sans migration ni reconfiguration. ```bash # Votre structure .kiro existante fonctionne directement .kiro/ ├── steering/ # → Injecté dans les sessions Crew ├── skills/ # → Disponible comme skills Crew ├── agents/ # → Utilisable dans les sessions └── settings/ └── mcp.json # → MCP servers disponibles ``` ## Commandes essentielles ```bash # Démarrer une session de chat kirocrew chat # Exécuter une tâche kirocrew run # Gérer les jobs cron kirocrew cron # Spawner des agents parallèles kirocrew spawn # Installer comme service système kirocrew service install kirocrew service status # Suivre les logs kirocrew logs -f ``` ## Conclusion de la partie 1 Kiro Crew représente un saut qualitatif dans l'outillage développeur : on passe d'agents conversationnels éphémères à un **workspace persistant, auto-apprenant et autonome**. L'architecture Gateway/Sessions/ACP est solide, le modèle de sécurité est conçu pour la production, et l'open source garantit la transparence. Dans la [seconde partie](/blog/2026/08/kiro-crew-part2), nous verrons les cas d'usage concrets : jobs cron, investigation d'incidents multi-repo, migration avec checkpoints, Apps (DevFleets, Issue Radar, Code Review Sage), et les perspectives d'utilisation pour une équipe de développement. --- **Sources :** - [kiro.dev/crew](https://kiro.dev/crew/) — Page produit officielle - [kiro.dev/blog/introducing-kiro-crew](https://kiro.dev/blog/introducing-kiro-crew/) — Blog post de lancement - [github.com/kirodotdev/KiroCrew](https://github.com/kirodotdev/KiroCrew) — Repository GitHub --- # EC2 Capacity Manager : la visibilité sur votre capacité > 2026-08-05T09:00:00.000Z | https://sylvain.bruas.fr/blog/2026/08/ec2-capacity-manager Tags: EC2, FinOps, Architecture, AWS Summary: EC2 Capacity Manager centralise la surveillance On-Demand, Spot et ODCR dans un dashboard unique. Guide pratique de ce service gratuit. ![EC2 Capacity Manager](/static/2026/08/ec2-capacity-manager/ec2-capacity-manager-cover.webp) Dans un [précédent article](/blog/2026/05/ec2-capacity-reservation), nous avons vu en détail les stratégies de réservation de capacité EC2 : ODCR, Savings Plans, Reserved Instances et le mix avec les Spot Instances. Nous avions toutes les briques pour garantir la disponibilité et optimiser les coûts. Mais il manquait un élément crucial : **la visibilité centralisée**. Comment savoir si vos ODCR sont bien utilisées ? Comment détecter une réservation à 20% d'utilisation qui vous coûte des milliers d'euros par mois ? Comment avoir une vue consolidée quand vous opérez sur 50 comptes et 4 régions ? [Amazon EC2 Capacity Manager](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-manager.html), lancé en octobre 2025, est la réponse d'AWS. C'est un service **gratuit** qui agrège toutes les données de capacité — On-Demand, Spot et Capacity Reservations — dans une interface unique, à travers tous vos comptes et régions, avec un rafraîchissement horaire. ## Le problème que résout Capacity Manager Avant Capacity Manager, obtenir une vue consolidée de votre capacité EC2 nécessitait : - Des appels manuels aux API `describe-capacity-reservations` sur chaque compte/région - La création de scripts custom pour agréger les données - Du context-switching entre la console EC2, [AWS Cost Explorer](https://docs.aws.amazon.com/cost-management/latest/userguide/ce-what-is.html), [Amazon CloudWatch](https://docs.aws.amazon.com/cloudwatch/latest/monitoring/WhatIsCloudWatch.html) et les CUR (Cost and Usage Reports) - Des dashboards maison pour visualiser les tendances Ce travail d'agrégation devenait ingérable à grande échelle. Capacity Manager élimine cette complexité opérationnelle. ## Le Dashboard : vue d'ensemble en un coup d'œil {/* TODO: Remplacer par une capture d'écran de la console AWS */} Le dashboard principal affiche trois catégories de métriques avec des indicateurs de tendance : ![Dashboard EC2 Capacity Manager](/static/2026/08/ec2-capacity-manager/dashboard.webp) *Source : [AWS Blog — Monitor, analyze, and manage capacity usage from a single interface with Amazon EC2 Capacity Manager](https://aws.amazon.com/blogs/aws/monitor-analyze-and-manage-capacity-usage-from-a-single-interface-with-amazon-ec2-capacity-manager)* ### Onglet Dashboard Trois cartes de synthèse donnent le pouls de votre capacité, avec indicateurs de tendance : - **Reservations** : taux d'utilisation moyen (en heures de vCPU) et coût estimé de la capacité inutilisée - **Usage** : usage réservé en vCPU-heures (hors Spot) - **Spot** : durée moyenne d'exécution avant interruption (en heures) Plus bas, deux blocs de détail complètent la vue : - **Usage metrics** : répartition réservé / non-réservé / Spot (donut) et tendance dans le temps, avec choix de l'unité (vCPUs, instances ou coût estimé) - **Reservation metrics** : historique capacité utilisée vs inutilisée (« Reserved capacity trends ») et un tableau « Unused capacity » listant les ODCR les plus sous-utilisées, triées par coût inutilisé, avec pourcentage d'utilisation, type d'instance et zone de disponibilité ### Onglet Usage L'onglet Usage offre un historique détaillé filtrable par **dimensions** : - Account ID - Region - Instance Family - Availability Zone - Instance Type On peut grouper et filtrer selon ces dimensions pour créer des vues personnalisées. Par exemple : "montre-moi l'utilisation des m5 en eu-west-1 sur le compte production sur les 30 derniers jours". ### Onglet Reservations C'est ici que Capacity Manager prend toute sa valeur. L'onglet affiche : - Les statistiques agrégées (nombre total de réservations, taux d'utilisation global, capacité réservée vs utilisée) - Un tableau triable avec chaque ODCR, son utilisation et un lien direct pour la modifier - La possibilité de **modifier une ODCR directement** depuis cette interface (sans naviguer vers une autre section de la console) ### Onglet Spot L'analyse des Spot Instances inclut la **durée avant interruption** — une donnée précieuse pour calibrer vos workloads Spot et améliorer la diversification des types d'instances. ### Activation ```bash # Activer Capacity Manager (agrège 14 jours d'historique) aws ec2 enable-capacity-manager # Vérifier le statut (activation, accès Organizations, ingestion des données) aws ec2 get-capacity-manager-attributes ``` Le service est disponible dans toutes les régions commerciales et est **entièrement gratuit**. ## Visibilité multi-compte avec AWS Organizations Pour les organisations opérant à grande échelle, Capacity Manager s'intègre avec [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html). Depuis le compte de management ou un administrateur délégué, vous obtenez une vue consolidée de la capacité sur **tous les comptes membres**. ```bash # Activer l'intégration Organizations (depuis le compte de management) aws ec2 update-capacity-manager-organizations-access \ --organizations-access # Métriques de taux d'utilisation et de coût inutilisé, groupées par compte aws ec2 get-capacity-manager-metric-data \ --metric-names reservation-avg-utilization-vcpu reservation-unused-total-estimated-cost \ --start-time 2026-08-01T00:00:00Z \ --end-time 2026-08-14T00:00:00Z \ --period 86400 \ --group-by account-id ``` Cette vue inter-comptes révèle des patterns d'optimisation invisibles autrement. Exemple illustratif de ce que peut révéler un groupement par compte : | Compte | Utilisation moyenne (vCPU) | Coût estimé de capacité inutilisée | |---|---|---| | production | 96% | faible | | staging | 41% | élevé — à revoir | | sandbox | 12% | élevé — candidat à l'annulation | Un compte à faible utilisation n'est pas forcément un problème (capacité réservée pour un pic à venir), mais c'est un signal à investiguer. ## Data Exports : analyse au-delà des 90 jours La console et les API offrent 90 jours de rétention. Pour l'analyse de tendances à long terme, Capacity Manager exporte vers [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) en CSV (Gzip) ou Parquet (Snappy) — Parquet étant recommandé pour les performances de requêtage. Un seul export est autorisé par compte, avec une fréquence horaire. ```bash # Créer l'export vers S3 (le bucket doit avoir la policy IAM adéquate, voir la doc) aws ec2 create-capacity-manager-data-export \ --s3-bucket-name capacity-manager-exports-123456789012 \ --s3-bucket-prefix capacity-data/ \ --schedule hourly \ --output-format parquet \ --region eu-west-1 # Vérifier le statut de livraison aws ec2 describe-capacity-manager-data-exports --region eu-west-1 ``` Une fois les données dans S3, vous pouvez les exploiter avec [Amazon Athena](https://docs.aws.amazon.com/athena/latest/ug/what-is.html) en créant une table externe pointant sur le bucket (partitionnée par année/mois/jour/heure), puis en interrogeant les colonnes exportées (`reservationavgutilizationinst`, `reservationunusedtotalestimatedcost`, etc.) : ```sql -- Identifier les ODCR sous-utilisées et leur coût inutilisé SELECT reservationid, instancetype, region, "az-id", ROUND(CAST(reservationavgutilizationinst AS double) * 100, 2) AS utilization_pct, ROUND(CAST(reservationunusedtotalestimatedcost AS double), 4) AS wasted_cost_usd FROM capacity_manager_db.capacity_data WHERE metricgroupname = 'Reservation Usage' AND CAST(reservationavgutilizationinst AS double) < 0.5 AND y = '2026' AND m = '07' ORDER BY wasted_cost_usd DESC LIMIT 10; ``` Pour le détail complet (création du bucket, policy S3, script Glue/Athena avec partition projection), voir l'article [Maximize Amazon EC2 Capacity Reservations with Capacity Manager data exports](https://aws.amazon.com/blogs/compute/maximize-amazon-ec2-capacity-reservations-with-capacity-manager-data-exports/) publié par AWS. ## Automatisation : alertes et optimisation proactive Capacity Manager fournit les données ; l'automatisation les transforme en actions. Voici une architecture combinant [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) et [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) pour alerter automatiquement sur les ODCR sous-utilisées : ``` EventBridge (cron quotidien) → Lambda (vérification utilisation) → Amazon SNS (alerte) ``` La Lambda interroge directement l'API `describe-capacity-reservations` (données en temps réel, sans passer par Capacity Manager) pour calculer le taux d'utilisation de chaque ODCR et publier une alerte SNS si le seuil n'est pas atteint. ```hcl # EventBridge : vérification quotidienne à 8h resource "aws_cloudwatch_event_rule" "check_capacity" { name = "check-odcr-utilization" schedule_expression = "cron(0 8 * * ? *)" } resource "aws_cloudwatch_event_target" "lambda" { rule = aws_cloudwatch_event_rule.check_capacity.name arn = aws_lambda_function.capacity_alert.arn } # Indispensable : sans cette permission, EventBridge ne peut pas invoquer la Lambda resource "aws_lambda_permission" "allow_eventbridge" { statement_id = "AllowExecutionFromEventBridge" action = "lambda:InvokeFunction" function_name = aws_lambda_function.capacity_alert.function_name principal = "events.amazonaws.com" source_arn = aws_cloudwatch_event_rule.check_capacity.arn } resource "aws_lambda_function" "capacity_alert" { function_name = "capacity-utilization-alert" runtime = "python3.12" handler = "handler.lambda_handler" role = aws_iam_role.lambda_capacity.arn timeout = 120 environment { variables = { MIN_UTILIZATION = "50" SNS_TOPIC_ARN = aws_sns_topic.capacity_alerts.arn } } } ``` ```python import boto3 import os ec2 = boto3.client('ec2') sns = boto3.client('sns') THRESHOLD = int(os.environ['MIN_UTILIZATION']) SNS_TOPIC = os.environ['SNS_TOPIC_ARN'] def lambda_handler(event, context): reservations = ec2.describe_capacity_reservations( Filters=[{'Name': 'state', 'Values': ['active']}] )['CapacityReservations'] alerts = [] for cr in reservations: total = cr['TotalInstanceCount'] used = total - cr['AvailableInstanceCount'] util = (used / total * 100) if total > 0 else 0 if util < THRESHOLD: alerts.append( f"• {cr['CapacityReservationId']} " f"({cr['InstanceType']}, {cr['AvailabilityZone']}): " f"{util:.0f}% — recommandation: réduire à {max(used+1, 1)}" ) if alerts: sns.publish( TopicArn=SNS_TOPIC, Subject=f"[Capacity] {len(alerts)} ODCR sous le seuil de {THRESHOLD}%", Message="\n".join(alerts) ) return {'underutilized': len(alerts)} ``` ## Bonnes pratiques - **Activez Capacity Manager dès maintenant** — c'est gratuit et la collecte démarre immédiatement - **Configurez l'intégration Organizations** si vous opérez en multi-compte - **Exportez vers S3 en Parquet** pour les analyses long terme et la corrélation avec vos données FinOps - **Automatisez les alertes** sur les ODCR sous 50% d'utilisation - **Revue mensuelle** : passez en revue le dashboard Reservations et nettoyez les réservations inutiles - **Utilisez les unités "estimated cost"** pour prioriser — 100 vCPU-heures inutilisées sur des p5 coûtent bien plus que sur des t3 ## Conclusion EC2 Capacity Manager transforme la gestion de capacité d'un exercice manuel et fragmenté en une pratique centralisée et data-driven. Combiné avec les [stratégies de réservation](/blog/2026/05/ec2-capacity-reservation) que nous avons déjà couvertes, il offre enfin la boucle de feedback nécessaire pour optimiser en continu. C'est aussi un outil à ajouter à la liste des services à [déléguer sur un compte membre](/blog/2025/07/delegated-services) de votre organisation — typiquement le compte FinOps ou le compte Opérations. En déléguant la gestion de la capacité à l'équipe responsable du suivi des coûts, vous renforcez le principe du moindre privilège tout en assurant un suivi opérationnel efficace. Mon conseil : activez Capacity Manager aujourd'hui, configurez un export S3 vers Athena, et mettez en place une Lambda d'alerte sur les ODCR sous-utilisées. En moins d'une heure, vous aurez une visibilité que beaucoup d'organisations mettent des mois à construire manuellement. --- # AWS Lambda MicroVMs : bastions serverless et sandboxes IA > 2026-07-11T09:00:00.000Z | https://sylvain.bruas.fr/blog/2026/07/aws-lambda-microvms Tags: Lambda, Serverless, DevOps, Architecture, AWS Summary: Lambda MicroVMs : VMs Firecracker éphémères avec suspend/resume. Bastions serverless, sandboxes IA et Cloud9 DIY avec EFS. ![AWS Lambda MicroVMs](/static/2026/07/lambda-microvm/microvm.webp) ## Introduction Le 22 juin 2026, AWS a lancé **Lambda MicroVMs**, un nouveau type de ressource serverless qui change la donne. Jusqu'ici, [AWS Lambda](https://docs.aws.amazon.com/lambda/) était synonyme de fonctions stateless limitées à 15 minutes. Désormais, vous pouvez obtenir une **machine virtuelle Firecracker dédiée**, stateful, avec isolation hardware, démarrage quasi-instantané depuis un snapshot, et une durée de vie allant jusqu'à **8 heures**. Le tout sans infrastructure à gérer. Ce n'est pas une évolution incrémentale de Lambda Functions — c'est un nouveau type de ressource avec sa propre API (`run-microvm`, `suspend-microvm`, `resume-microvm`). AWS expose directement la couche Firecracker qui propulsait déjà secrètement plus de 15 000 milliards d'invocations Lambda par mois. Dans cet article, nous allons explorer ce que Lambda MicroVMs apporte concrètement, pourquoi c'est un game-changer pour les bastions et les sandboxes, puis nous construirons pas à pas un **équivalent de Cloud9** basé sur OpenVSCode Server, Lambda MicroVM et [Amazon Elastic File System (EFS)](https://docs.aws.amazon.com/efs/) pour la persistance du code. ## Lambda MicroVMs : ce que c'est (et ce que ce n'est pas) ### Architecture et spécifications Lambda MicroVMs repose sur le modèle **image-then-launch** : 1. Vous fournissez un Dockerfile + code source packagé en zip sur [Amazon Simple Storage Service (S3)](https://docs.aws.amazon.com/s3/) 2. Lambda exécute le Dockerfile, lance votre application via `ENTRYPOINT` ou `CMD`, attend le signal `/ready` (hook optionnel), puis capture un **snapshot Firecracker** (mémoire + disque) 3. Chaque lancement ultérieur reprend depuis ce snapshot pré-initialisé — démarrage quasi-instantané Le sizing suit un modèle **baseline-peak** : vous configurez une baseline, et la MicroVM peut burst jusqu'à **4x** cette baseline automatiquement. Vous payez la baseline tant que la MicroVM tourne, et uniquement le surplus consommé au-delà. | Baseline | Peak (burst 4x) | Disque max | |---|---|---| | 0,5 Go / 0,25 vCPU | 2 Go / 1 vCPU | 8 Go | | 1 Go / 0,5 vCPU | 4 Go / 2 vCPU | 8 Go | | **2 Go / 1 vCPU** (défaut) | 8 Go / 4 vCPU | 8 Go | | 4 Go / 2 vCPU | 16 Go / 8 vCPU | 16 Go | | 8 Go / 4 vCPU | 32 Go / 16 vCPU | 32 Go | Autres caractéristiques : | Caractéristique | Valeur | |---|---| | Architecture | ARM64 (Graviton) uniquement | | Durée max | 8 heures (28 800 secondes) | | Isolation | Firecracker microVM — kernel dédié, pas de partage entre sessions | | OS | Amazon Linux 2023 (base image managée par Lambda) | | Protocoles inbound | HTTP/1.1, HTTP/2, WebSockets, gRPC, SSE | | Authentification | Token JWE obligatoire (`X-aws-proxy-auth`) | ### Ce qui différencie Lambda MicroVMs Le positionnement est clair : Lambda MicroVMs se situe **entre** Lambda Functions et [Amazon Elastic Compute Cloud (EC2)](https://docs.aws.amazon.com/ec2/) : - **Lambda Functions** : stateless, 15 min max, event-driven, scale-to-zero - **Lambda MicroVMs** : stateful, 8h max, interactive, suspend/resume avec état intact - **EC2** : stateful, illimité, mais vous gérez tout (AMI, scaling, patching...) Le modèle économique est intéressant : 0\$ de compute pendant la suspension. Vous payez uniquement le stockage du snapshot (\~0,08\$/Go/mois) et les opérations de suspend/resume. Pour des workloads qui utilisent beaucoup le burst (exactement le profil d'un développeur ou d'un agent IA), c'est redoutable. ## Cas d'usage : bastions et sandboxes ### Bastions éphémères serverless Traditionnellement, un bastion SSH est une instance EC2 t3.micro qui tourne 24/7 dans un subnet public ou privé, avec un coût fixe mensuel et une surface d'attaque permanente. Avec Lambda MicroVMs, vous pouvez repenser complètement cette approche : **Le concept** : un bastion qui n'existe que quand vous en avez besoin, avec isolation VM complète, et qui disparaît après usage. ```bash # Créer un network connector VPC pour le bastion (une seule fois) aws lambda-core create-network-connector \ --name bastion-vpc-egress \ --configuration '{ "VpcEgressConfiguration": { "SubnetIds": ["subnet-private-a"], "SecurityGroupIds": ["sg-bastion"], "NetworkProtocol": "IPv4", "AssociatedComputeResourceTypes": ["MicroVm"] } }' \ --operator-role arn:aws:iam::123456789012:role/NetworkConnectorOperatorRole # Lancer un bastion éphémère aws lambda-microvms run-microvm \ --image-identifier arn:aws:lambda:eu-west-1:123456789012:microvm-image:bastion-hardened \ --execution-role-arn arn:aws:iam::123456789012:role/BastionMicroVMRole \ --ingress-network-connectors "arn:aws:lambda:eu-west-1:aws:network-connector:aws-network-connector:ALL_INGRESS" \ --egress-network-connectors "arn:aws:lambda:eu-west-1:123456789012:network-connector:bastion-vpc-egress" \ --idle-policy '{"maxIdleDurationSeconds":1800,"suspendedDurationSeconds":600,"autoResumeEnabled":false}' ``` **Avantages par rapport à un bastion EC2 classique** : - **Coût quasi-nul** : le bastion est suspendu (gratuit en compute) quand personne ne l'utilise. Fini le t3.micro qui tourne 730h/mois pour 10h d'utilisation effective - **Surface d'attaque réduite** : pas de machine permanente exposée, kernel dédié sans partage - **Immutabilité** : chaque session repart d'un snapshot propre. Pas de drift de configuration, pas de malware persistant - **Audit natif** : chaque `run-microvm` est un événement [AWS CloudTrail](https://docs.aws.amazon.com/cloudtrail/). Qui a lancé quoi, quand, combien de temps - **Auto-destruction** : politique d'idle qui termine automatiquement le bastion après inactivité Le bastion MicroVM est particulièrement pertinent pour les équipes qui pratiquent le **Just-In-Time access** : un SRE déclenche un bastion via une [AWS Step Functions](https://docs.aws.amazon.com/step-functions/), obtient un accès temporaire à un RDS ou un cluster EKS, et le bastion est terminé 30 minutes plus tard. ### Sandboxes pour agents IA et exécution de code non fiable C'est le cas d'usage principal mis en avant par AWS. Les agents IA (coding assistants, data analysts, vulnerability scanners) ont besoin d'exécuter du code qu'ils génèrent eux-mêmes dans un environnement isolé. Lambda MicroVMs résout le trilemme classique : - **Containers** : démarrage rapide mais isolation faible (kernel partagé) - **VMs EC2** : isolation forte mais démarrage lent et gestion lourde - **Lambda MicroVMs** : isolation hardware + démarrage rapide + zéro gestion AWS a d'ailleurs publié une [intégration native avec Claude Managed Agents](https://docs.aws.amazon.com/lambda/latest/dg/microvms-integrations-claude-managed-agents.html) : chaque appel d'outil de l'agent s'exécute dans une MicroVM dédiée, isolée du reste du système. Pour les plateformes SaaS multi-tenant, c'est le pattern idéal : un étudiant qui exécute du Python sur votre plateforme éducative ne peut jamais accéder aux données d'un autre étudiant, car chaque session tourne dans son propre kernel. ## Tutoriel : recréer Cloud9 avec Lambda MicroVM + VS Code OSS + EFS AWS a retiré Cloud9 des offres pour les nouveaux comptes. Voici comment construire un **environnement de développement cloud serverless** qui le remplace en combinant Lambda MicroVM, OpenVSCode Server et Amazon EFS pour la persistance. ### Architecture cible ``` ┌─────────────────────────────────────────────────────────┐ │ Développeur (navigateur) │ │ https://mvm-xxx.lambda-microvm.eu-west-1.on.aws│ │ Header: X-aws-proxy-auth: │ └──────────────────────────────┬──────────────────────────┘ │ HTTPS (port 8080) ▼ ┌─────────────────────────────────────────────────────────┐ │ Lambda MicroVM (ARM64 / Graviton) │ │ Baseline: 4 Go / 2 vCPU │ │ Peak: 16 Go / 8 vCPU (burst auto) │ │ │ │ ┌─────────────────────────────────────────────────┐ │ │ │ OpenVSCode Server (port 8080) │ │ │ │ Extensions, terminal, LSP │ │ │ └─────────────────────────────────────────────────┘ │ │ │ │ ┌─────────────────────────────────────────────────┐ │ │ │ /home/developer/workspace │ │ │ │ (local ou mount EFS optionnel) │ │ │ └─────────────────────────────────────────────────┘ │ │ │ │ Runtime: Node.js 20, Python 3.12, AWS CLI v2 │ └─────────────────────────────────────────────────────────┘ │ (optionnel) NFS via VPC ▼ egress connector ┌─────────────────────────────────────────────────────────┐ │ Amazon EFS (Access Point /dev/workspace) │ │ Persistance du code entre sessions │ │ Throughput mode: elastic │ └─────────────────────────────────────────────────────────┘ ``` ### Étape 1 : créer le filesystem EFS ```bash # Créer le filesystem aws efs create-file-system \ --performance-mode generalPurpose \ --throughput-mode elastic \ --encrypted \ --tags Key=Name,Value=dev-workspace-efs \ --region eu-west-1 # Créer un Access Point dédié aws efs create-access-point \ --file-system-id fs-0abc123def456 \ --posix-user Uid=1000,Gid=1000 \ --root-directory "Path=/dev/workspace,CreationInfo={OwnerUid=1000,OwnerGid=1000,Permissions=755}" # Créer les mount targets dans les subnets privés aws efs create-mount-target \ --file-system-id fs-0abc123def456 \ --subnet-id subnet-private-a \ --security-groups sg-efs-access ``` ### Étape 2 : construire l'image MicroVM Voici le Dockerfile qui crée notre environnement de développement. On utilise l'image de base container `public.ecr.aws/lambda/microvms:al2023-minimal` fournie par AWS, qui est compatible avec le processus de snapshot Firecracker : ```dockerfile FROM public.ecr.aws/lambda/microvms:al2023-minimal USER root # Outils système de base RUN dnf install -y \ nodejs20 npm \ python3.12 python3.12-pip \ git wget unzip tar gzip \ && dnf clean all # AWS CLI v2 RUN curl "https://awscli.amazonaws.com/awscli-exe-linux-aarch64.zip" -o "awscliv2.zip" \ && unzip awscliv2.zip && ./aws/install && rm -rf aws awscliv2.zip # OpenVSCode Server (build ARM64) ARG OPENVSCODE_VERSION=1.109.5 RUN mkdir -p /opt/vscode \ && curl -fsSL "https://github.com/gitpod-io/openvscode-server/releases/download/openvscode-server-v${OPENVSCODE_VERSION}/openvscode-server-v${OPENVSCODE_VERSION}-linux-arm64.tar.gz" \ | tar xz --strip-components=1 -C /opt/vscode # Créer l'utilisateur développeur avec workspace local RUN useradd -m -u 1000 -s /bin/bash developer \ && mkdir -p /home/developer/workspace \ && mkdir -p /home/developer/.openvscode-server/data/Machine \ && chown -R developer:developer /home/developer # Pré-configurer pour désactiver le workspace trust (évite le reload loop) RUN echo '{"security.workspace.trust.enabled": false}' \ > /home/developer/.openvscode-server/data/Machine/settings.json \ && chown developer:developer /home/developer/.openvscode-server/data/Machine/settings.json # Script d'entrypoint COPY entrypoint.sh /opt/entrypoint.sh RUN chmod +x /opt/entrypoint.sh # Extensions VS Code pré-installées RUN su - developer -c "/opt/vscode/bin/openvscode-server \ --install-extension ms-python.python \ --install-extension dbaeumer.vscode-eslint \ --install-extension esbenp.prettier-vscode \ --install-extension amazonwebservices.aws-toolkit-vscode" EXPOSE 8080 WORKDIR /home/developer/workspace CMD ["/opt/entrypoint.sh"] ``` Quelques points importants sur ce Dockerfile : - **`USER root`** : nécessaire pour installer les paquets système et créer l'utilisateur. L'entrypoint switchera vers `developer` pour lancer VS Code - **`OPENVSCODE_VERSION=1.109.5`** : version ARM64 stable de [OpenVSCode Server](https://github.com/gitpod-io/openvscode-server) - **Workspace trust désactivé** : sans cette configuration, OpenVSCode Server entre dans un reload loop au premier accès car il demande à l'utilisateur de « faire confiance » au workspace - **Extensions pré-installées** : elles sont incluses dans le snapshot, donc disponibles instantanément au démarrage sans téléchargement ### Étape 3 : le script d'entrypoint L'entrypoint lance OpenVSCode Server en tant qu'utilisateur `developer`. Le montage EFS est géré au niveau de la MicroVM via le VPC egress connector — la MicroVM accède à EFS par le réseau NFS depuis le subnet privé configuré. ```bash #!/bin/bash # entrypoint.sh — Lance OpenVSCode Server set -e # Lancer OpenVSCode Server en tant que developer exec su - developer -c "/opt/vscode/bin/openvscode-server \ --host 0.0.0.0 \ --port 8080 \ --without-connection-token \ --default-folder /home/developer/workspace" ``` > **Note sur EFS** : le Dockerfile fourni ne contient pas `nfs-utils` et ne monte pas EFS dans l'entrypoint. Pour ajouter la persistance EFS, deux options : > > 1. **Montage NFS dans l'entrypoint** : ajouter `nfs-utils` au Dockerfile, activer `--additional-os-capabilities '["ALL"]'` lors du `create-microvm-image` (nécessaire pour `mount`), et monter EFS avant de lancer VS Code > 2. **Workspace local** : utiliser `/home/developer/workspace` comme stockage éphémère — le code est perdu à la terminaison mais conservé pendant suspend/resume (le snapshot préserve l'état disque) > > L'option 1 avec montage EFS dans l'entrypoint ressemblerait à : ```bash #!/bin/bash # entrypoint.sh — Version avec montage EFS set -e EFS_DNS="${EFS_FILE_SYSTEM_ID}.efs.${AWS_REGION}.amazonaws.com" MOUNT_POINT="/home/developer/workspace" # Monter EFS (nécessite nfs-utils dans le Dockerfile + additionalOsCapabilities) if ! mountpoint -q "$MOUNT_POINT"; then mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2 \ "${EFS_DNS}:/" "$MOUNT_POINT" chown developer:developer "$MOUNT_POINT" fi # Lancer OpenVSCode Server en tant que developer exec su - developer -c "/opt/vscode/bin/openvscode-server \ --host 0.0.0.0 \ --port 8080 \ --without-connection-token \ --default-folder /home/developer/workspace" ``` Pour activer les capabilities OS nécessaires au montage NFS, ajoutez `--additional-os-capabilities` lors de la création de l'image : ```bash aws lambda-microvms create-microvm-image \ --name vscode-dev-environment \ --code-artifact uri=s3://my-microvm-artifacts/vscode-microvm.zip \ --base-image-arn arn:aws:lambda:eu-west-1:aws:microvm-image:al2023-1 \ --build-role-arn arn:aws:iam::123456789012:role/MicroVMBuildRole \ --environment-variables '{"EFS_FILE_SYSTEM_ID":"fs-0abc123def456"}' \ --additional-os-capabilities '["ALL"]' ``` ### Étape 4 : packager et créer l'image MicroVM ```bash # Packager le code source zip -r vscode-microvm.zip Dockerfile entrypoint.sh # Uploader sur S3 aws s3 cp vscode-microvm.zip s3://my-microvm-artifacts/vscode-microvm.zip # Créer l'image MicroVM aws lambda-microvms create-microvm-image \ --name vscode-dev-environment \ --code-artifact uri=s3://my-microvm-artifacts/vscode-microvm.zip \ --base-image-arn arn:aws:lambda:eu-west-1:aws:microvm-image:al2023-1 \ --build-role-arn arn:aws:iam::123456789012:role/MicroVMBuildRole \ --environment-variables '{"EFS_FILE_SYSTEM_ID":"fs-0abc123def456"}' # Vérifier l'état du build aws lambda-microvms get-microvm-image \ --image-identifier vscode-dev-environment ``` Le build est asynchrone. L'image passe de `CREATING` à `CREATED` en succès, ou `CREATE_FAILED` en cas d'erreur. Consultez les logs CloudWatch sous `/aws/lambda/microvms/vscode-dev-environment` pour le diagnostic. ### Étape 5 : lancer l'environnement de développement ```bash # Créer un network connector VPC pour accéder à EFS (une seule fois) aws lambda-core create-network-connector \ --name dev-vpc-egress \ --configuration '{ "VpcEgressConfiguration": { "SubnetIds": ["subnet-private-a"], "SecurityGroupIds": ["sg-dev-microvm"], "NetworkProtocol": "IPv4", "AssociatedComputeResourceTypes": ["MicroVm"] } }' \ --operator-role arn:aws:iam::123456789012:role/NetworkConnectorOperatorRole # Lancer la MicroVM avec politique d'idle intelligente aws lambda-microvms run-microvm \ --image-identifier arn:aws:lambda:eu-west-1:123456789012:microvm-image:vscode-dev-environment \ --execution-role-arn arn:aws:iam::123456789012:role/DevMicroVMRole \ --ingress-network-connectors "arn:aws:lambda:eu-west-1:aws:network-connector:aws-network-connector:ALL_INGRESS" \ --egress-network-connectors "arn:aws:lambda:eu-west-1:123456789012:network-connector:dev-vpc-egress" \ --idle-policy '{"maxIdleDurationSeconds":3600,"suspendedDurationSeconds":1800,"autoResumeEnabled":true}' \ --maximum-duration-in-seconds 28800 ``` La réponse contient l'endpoint HTTPS dédié et le MicroVM ID : ```json { "microvmId": "mvm-01234567-abcd-ef01-2345-6789abcdef01", "state": "PENDING", "endpoint": "mvm-01234567-abcd-ef01-2345-6789abcdef01.lambda-microvm.eu-west-1.on.aws" } ``` Pour vous connecter, générez un token d'authentification : ```bash # Générer un token valide 8h (durée max de la session) aws lambda-microvms create-microvm-auth-token \ --microvm-identifier mvm-01234567-abcd-ef01-2345-6789abcdef01 \ --expiration-in-minutes 480 \ --allowed-ports '[{"port":8080}]' # Accéder à l'IDE dans le navigateur : # https://mvm-01234567-abcd-ef01-2345-6789abcdef01.lambda-microvm.eu-west-1.on.aws # Header requis : X-aws-proxy-auth: ``` La politique d'idle est configurée pour suspendre la MicroVM après **1 heure d'inactivité**, la garder suspendue **30 minutes**, et la reprendre automatiquement au prochain accès HTTP. Pour un développeur qui fait des pauses café ou des réunions, la MicroVM se suspend et se réveille de manière transparente. ### Étape 6 : automatiser avec une Step Function Pour une équipe, vous pouvez automatiser la provision avec une Step Function déclenchée par un portail interne : ```json { "Comment": "Provision dev environment on demand", "StartAt": "RunMicroVM", "States": { "RunMicroVM": { "Type": "Task", "Resource": "arn:aws:states:::aws-sdk:lambdamicrovms:runMicrovm", "Parameters": { "ImageIdentifier": "arn:aws:lambda:eu-west-1:123456789012:microvm-image:vscode-dev-environment", "ExecutionRoleArn": "arn:aws:iam::123456789012:role/DevMicroVMRole", "IngressNetworkConnectors": ["arn:aws:lambda:eu-west-1:aws:network-connector:aws-network-connector:ALL_INGRESS"], "EgressNetworkConnectors": ["arn:aws:lambda:eu-west-1:123456789012:network-connector:dev-vpc-egress"], "IdlePolicy": { "MaxIdleDurationSeconds": 3600, "SuspendedDurationSeconds": 1800, "AutoResumeEnabled": true }, "MaximumDurationInSeconds": 28800 }, "ResultPath": "$.microvm", "Next": "NotifyDeveloper" }, "NotifyDeveloper": { "Type": "Task", "Resource": "arn:aws:states:::sns:publish", "Parameters": { "TopicArn": "arn:aws:sns:eu-west-1:123456789012:dev-notifications", "Message.$": "States.Format('Votre IDE est prêt : {}', $.microvm.Endpoint)" }, "End": true } } } ``` ### Pourquoi le suspend/resume change la donne (et EFS en option) Le point clé de cette architecture est le **modèle suspend/resume natif** de Lambda MicroVMs : - **Pendant le suspend** : le snapshot Firecracker préserve l'intégralité de la mémoire et du disque. Votre code, vos fichiers ouverts dans VS Code, votre historique terminal — tout est intact au resume - **La MicroVM est éphémère mais stateful** : tant qu'elle n'est pas terminée, le workspace persiste entre les sessions suspend/resume - **EFS pour la persistance long-terme** : si vous avez besoin que le code survive à la terminaison de la MicroVM (après 8h max ou idle trop long), ajoutez EFS comme décrit à l'étape 3 Sans EFS, le workflow est : 1. La MicroVM tourne → vous codez 2. Idle 1h → Lambda suspend (0\$ compute, snapshot préservé) 3. Vous revenez → auto-resume en ~1-2 secondes, tout est là 4. Après 8h ou terminaison → workspace perdu Avec EFS : 1. Même workflow, mais le code est sur un montage NFS 2. Terminaison → vous relancez une MicroVM, EFS est remonté, code intact 3. **Partage possible** : plusieurs développeurs peuvent monter le même EFS (ou des Access Points différents) pour du pair programming ### Étape 7 : proxy local pour l'accès navigateur Un navigateur ne peut pas injecter le header `X-aws-proxy-auth` sur chaque requête HTTP et WebSocket. Pour accéder à OpenVSCode Server depuis votre poste, vous avez besoin d'un **proxy local** qui : 1. Écoute sur `http://localhost:8080` 2. Forward chaque requête vers l'endpoint HTTPS de la MicroVM en ajoutant le token d'authentification 3. Gère les upgrades WebSocket (indispensables pour le terminal et le LSP de VS Code) en passant le token via les subprotocols `lambda-microvms` 4. Renouvelle automatiquement le token avant expiration Voici un proxy minimal en Node.js : ```javascript // proxy.mjs — Proxy local d'authentification Lambda MicroVM import http from "node:http"; import https from "node:https"; import { execSync } from "node:child_process"; const MICROVM_ID = process.env.MICROVM_ID; const MICROVM_ENDPOINT = process.env.MICROVM_ENDPOINT; const REGION = process.env.AWS_REGION || "eu-west-1"; const LOCAL_PORT = parseInt(process.env.PORT || "8080", 10); const TOKEN_EXPIRATION_MINUTES = parseInt(process.env.TOKEN_EXPIRATION || "60", 10); let authToken = null; let tokenExpiresAt = 0; function refreshToken() { const cmd = `aws lambda-microvms create-microvm-auth-token \ --microvm-identifier ${MICROVM_ID} \ --expiration-in-minutes ${TOKEN_EXPIRATION_MINUTES} \ --allowed-ports '[{"allPorts":{}}]' \ --region ${REGION} --output json`; const result = JSON.parse(execSync(cmd, { encoding: "utf-8" })); authToken = result.authToken["X-aws-proxy-auth"]; tokenExpiresAt = Date.now() + (TOKEN_EXPIRATION_MINUTES - 5) * 60_000; } function getToken() { if (!authToken || Date.now() >= tokenExpiresAt) refreshToken(); return authToken; } function getEndpoint() { if (MICROVM_ENDPOINT) return MICROVM_ENDPOINT; const cmd = `aws lambda-microvms get-microvm --microvm-identifier ${MICROVM_ID} --region ${REGION} --output json`; return JSON.parse(execSync(cmd, { encoding: "utf-8" })).endpoint; } const endpoint = getEndpoint(); // Forward HTTP async function handleRequest(req, res) { const chunks = []; for await (const chunk of req) chunks.push(chunk); const body = Buffer.concat(chunks); const headers = { ...req.headers, host: endpoint, "x-aws-proxy-auth": getToken() }; delete headers.connection; const proxyReq = https.request( { hostname: endpoint, port: 443, path: req.url, method: req.method, headers }, (proxyRes) => { res.writeHead(proxyRes.statusCode, proxyRes.headers); proxyRes.pipe(res); } ); proxyReq.on("error", () => { res.writeHead(502); res.end("Bad Gateway"); }); if (body.length) proxyReq.write(body); proxyReq.end(); } // Forward WebSocket upgrades function handleUpgrade(req, socket, head) { const token = getToken(); const headers = { ...req.headers, host: endpoint, connection: "Upgrade", upgrade: "websocket" }; // Injecter le token via subprotocols WebSocket const existing = headers["sec-websocket-protocol"]?.split(",").map((p) => p.trim()) || []; headers["sec-websocket-protocol"] = [ "lambda-microvms", `lambda-microvms.authentication.${token}`, "lambda-microvms.port.8080", ...existing, ].join(", "); headers["x-aws-proxy-auth"] = token; const proxyReq = https.request({ hostname: endpoint, port: 443, path: req.url, method: "GET", headers }); proxyReq.on("upgrade", (proxyRes, proxySocket, proxyHead) => { // Filtrer les subprotocols lambda-microvms de la réponse let responseHead = "HTTP/1.1 101 Switching Protocols\r\n"; for (const [key, value] of Object.entries(proxyRes.headers)) { if (key.toLowerCase() === "sec-websocket-protocol") { const filtered = value.split(",").map((p) => p.trim()).filter((p) => !p.startsWith("lambda-microvms")); if (filtered.length) responseHead += `${key}: ${filtered.join(", ")}\r\n`; continue; } responseHead += `${key}: ${value}\r\n`; } responseHead += "\r\n"; socket.write(responseHead); if (proxyHead.length) socket.write(proxyHead); proxySocket.pipe(socket); socket.pipe(proxySocket); proxySocket.on("error", () => socket.destroy()); socket.on("error", () => proxySocket.destroy()); }); proxyReq.on("response", (proxyRes) => { let resp = `HTTP/1.1 ${proxyRes.statusCode} ${proxyRes.statusMessage}\r\n`; for (const [k, v] of Object.entries(proxyRes.headers)) resp += `${k}: ${v}\r\n`; resp += "\r\n"; socket.write(resp); proxyRes.pipe(socket); }); proxyReq.on("error", () => socket.destroy()); proxyReq.end(); } const server = http.createServer(handleRequest); server.on("upgrade", handleUpgrade); server.listen(LOCAL_PORT, () => { console.log(`MicroVM proxy → http://localhost:${LOCAL_PORT} → https://${endpoint}`); }); ``` Utilisation : ```bash # Lancer le proxy MICROVM_ID=mvm-01234567-abcd-ef01-2345-6789abcdef01 \ MICROVM_ENDPOINT=mvm-01234567-abcd-ef01-2345-6789abcdef01.lambda-microvm.eu-west-1.on.aws \ node proxy.mjs # Ouvrir VS Code dans le navigateur open http://localhost:8080 ``` Le proxy renouvelle le token 5 minutes avant expiration, gère le protocole WebSocket avec les subprotocols `lambda-microvms` (requis par l'endpoint), et filtre ces subprotocols de la réponse pour ne pas perturber VS Code côté client. > **Pourquoi un proxy local ?** L'endpoint MicroVM est un service managé par Lambda avec authentification JWE obligatoire — il n'est pas possible de placer un ALB ou un CloudFront devant. Il n'y a pas non plus d'option d'accès non authentifié ni de custom domain. Le proxy local (ou un proxy déployé sur une instance/container dans votre VPC) est le pattern d'accès navigateur recommandé pour les cas interactifs comme un IDE. ## Comparaison avec les alternatives | Critère | Cloud9 (ancien) | CodeCatalyst Dev Env | Lambda MicroVM + VS Code | |---|---|---|---| | Coût idle | Instance EC2 24/7 | Stoppé = gratuit | Suspendu = \~0\$ compute | | Démarrage | ~60s (boot EC2) | ~30-60s | ~2s (resume snapshot) | | Isolation | Shared tenancy | Container | Firecracker VM dédiée | | Personnalisation | Limitée | Devfile | Dockerfile complet | | Persistance | EBS | EBS | Suspend/resume + EFS optionnel | | Durée max session | Illimitée | 16h (puis stop auto) | 8h | | GPU | Non | Non | Non (ARM64 uniquement) | ## Considérations de sécurité et bonnes pratiques 1. **IAM least privilege** : le rôle d'exécution ne doit avoir accès qu'aux services nécessaires au développeur. Le rôle de l'opérateur network connector se limite à la création d'ENIs 2. **VPC egress connector** : routez le trafic sortant via un subnet privé avec un NAT Gateway pour l'accès internet, et des security groups pour contrôler l'accès aux ressources internes (EFS, RDS...) 3. **Authentification** : chaque requête vers l'endpoint MicroVM nécessite un token JWE (`X-aws-proxy-auth`). Scopez les tokens sur le port 8080 uniquement et avec une expiration courte pour les environnements partagés 4. **Chiffrement** : EFS chiffré at-rest (KMS) + in-transit (NFS over TLS). Le trafic entre le client et l'endpoint MicroVM est toujours chiffré en TLS 5. **Logs** : les logs de build et d'exécution sont dans CloudWatch sous `/aws/lambda/microvms/`. Chaque `run-microvm` est tracé dans CloudTrail ## Conclusion Lambda MicroVMs n'est pas juste un nouveau service — c'est un changement de paradigme dans la façon dont on conçoit les environnements de calcul éphémères sur AWS. La combinaison d'une isolation hardware Firecracker, d'un démarrage quasi-instantané depuis snapshot, et d'un modèle de facturation à 0\$ pendant la suspension ouvre des possibilités qui étaient auparavant réservées à des startups spécialisées comme E2B ou Daytona. Que ce soit pour des bastions JIT qui réduisent votre surface d'attaque, des sandboxes d'agents IA qui exécutent du code non fiable en toute sécurité, ou un IDE cloud DIY qui remplace Cloud9 — Lambda MicroVMs mérite une place dans votre boîte à outils architecturale. Le tutoriel présenté ici avec OpenVSCode Server + EFS est un point de départ. Vous pouvez l'enrichir avec du pair programming (multiple Access Points), des templates par projet (une image MicroVM par stack technique), ou même un système de facturation interne par développeur grâce aux tags CloudWatch. --- **Sources :** - [Annonce officielle AWS Lambda MicroVMs](https://aws.amazon.com/blogs/aws/run-isolated-sandboxes-with-full-lifecycle-control-aws-lambda-introduces-microvms/) - [Page produit Lambda MicroVMs](https://aws.amazon.com/lambda/lambda-microvms/) - [Documentation Lambda MicroVMs](https://docs.aws.amazon.com/lambda/latest/dg/lambda-microvms-guide.html) - [API Reference Lambda MicroVMs](https://docs.aws.amazon.com/lambda/latest/microvm-api/) - [MicroVM Images](https://docs.aws.amazon.com/lambda/latest/dg/microvms-images.html) - [Networking — Network Connectors](https://docs.aws.amazon.com/lambda/latest/dg/microvms-networking.html) - [OpenVSCode Server — Gitpod](https://github.com/gitpod-io/openvscode-server) - [Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html) --- # Kiro Starter Kit web agency — Partie 2 : workflow > 2026-07-02T00:00:00.000Z | https://sylvain.bruas.fr/blog/2026/07/kiro-starter-part2 Tags: kiro, ia, devops, architecture, aws Summary: Workflow Spec-Driven, audits par agents spécialisés, gestion des tokens, intégration Jira/Confluence et transformation en Power privée. ![Kiro Starter Kit : structurer le développement agentique pour une web agency](/static/2026/07/kiro-starter/kiro-starter-cover.webp) Dans la [première partie](/blog/2026/07/kiro-starter), nous avons posé les bases : le paradigme AI-DLC, la plateforme Kiro (IDE, CLI, Web), et la construction d'un starter kit complet avec steering, agents, hooks, skills, powers et MCP servers. Cette seconde partie aborde le workflow quotidien : comment utiliser efficacement ces outils au jour le jour. ## Le workflow Spec au centre Le mode Spec est le cœur du développement structuré avec Kiro. Il formalise le passage d'une idée à une implémentation en quatre phases distinctes. ![Workflow Spec-Driven : de l'idée à la PR](/static/2026/07/kiro-starter/04-spec-workflow.webp) ### Une spec par fonctionnalité La bonne organisation : **une spec par fonctionnalité**. Pas une spec monolithique pour tout le sprint, pas une spec par fichier. Une fonctionnalité cohérente, avec ses requirements, son design, et ses tâches. ``` .kiro/specs/ ├── auth-system/ │ ├── requirements.md │ ├── design.md │ └── tasks.md ├── payment-flow/ │ ├── requirements.md │ ├── design.md │ └── tasks.md └── user-dashboard/ ├── requirements.md ├── design.md └── tasks.md ``` Les requirements sont rédigés en langage naturel avec des critères d'acceptation clairs. Le design décrit l'architecture technique, les flux de données, les endpoints API. Les tâches sont séquencées avec leurs dépendances et leurs critères de validation. ### Quand utiliser quel mode - **Vibe Session** : questions rapides, exploration, prototypage, debug ponctuel. Pas de structure formelle, conversation libre. Idéal pour « comment faire X ? » ou « corrige ce bug ». - **Spec Session** : features complètes, refactoring structuré, nouvelles fonctionnalités. Le workflow requirements → design → tasks garantit la traçabilité et la reproductibilité. - **Web Autonome** : tâches longues qu'on veut déléguer entièrement. L'agent planifie, implémente, et ouvre une PR. Idéal pour les migrations, les refactorings cross-repo, ou les implémentations bien spécifiées. La règle empirique : si la tâche nécessite plus de 30 minutes de travail humain et peut être décrite précisément, elle est candidate au mode Spec ou Web Autonome. ## L'idéation libérée par les agents L'un des changements les plus profonds apportés par l'AI-DLC concerne la phase d'idéation. Traditionnellement, les idées sont filtrées très tôt par la faisabilité technique perçue. « On ne peut pas faire ça, c'est trop complexe » est un réflexe courant qui tue l'innovation. Avec des agents capables d'implémenter rapidement des prototypes, la barrière technique s'abaisse considérablement. L'équipe peut explorer des pistes plus ambitieuses, tester des hypothèses en quelques heures au lieu de quelques jours, et itérer sur des concepts sans le coût prohibitif d'un développement manuel. L'humain guide, les agents exécutent. Le product owner décrit une vision, l'agent produit un prototype fonctionnel. Le designer propose une interaction, l'agent l'implémente pour validation. L'architecte esquisse un pattern, l'agent le concrétise avec les tests associés. Ce n'est pas de la magie — c'est de la redistribution. Le temps gagné sur l'implémentation mécanique est réinvesti dans la réflexion, la validation, et l'itération sur le produit. ## Utiliser l'IA pour définir le starter kit lui-même Un point souvent négligé : Kiro peut aider à construire sa propre configuration. Les fichiers de steering, les définitions d'agents, les hooks — tout cela est du texte structuré que l'agent peut générer et affiner. La démarche recommandée : 1. **Décrire les pratiques en langage naturel** dans une session Vibe : « Notre équipe utilise Next.js 16, TypeScript strict, Vitest pour les tests, Terraform pour l'infra AWS... » 2. **Demander à l'agent de générer les fichiers de steering** correspondants 3. **Itérer** : relire, ajuster, compléter avec les cas particuliers 4. **Demander à l'agent de proposer des agents spécialisés** adaptés aux rôles de l'équipe 5. **Tester** en conditions réelles et affiner L'agent connaît les formats attendus (frontmatter YAML, structure des hooks JSON, conventions de nommage). Il produit des configurations valides dès la première itération dans la majorité des cas. ## Le mode agent-to-agent de la CLI La CLI Kiro supporte un mode de composition où plusieurs agents s'enchaînent. Le principe : la sortie d'un agent alimente l'entrée du suivant, créant un pipeline de traitement. ```bash # Pipeline : analyse → correction → validation kiro-cli chat --no-interactive --agent security-auditor --trust-all-tools \ "Audite le module auth" | \ kiro-cli chat --no-interactive --agent backend-dev --trust-all-tools \ "Corrige les vulnérabilités identifiées" | \ kiro-cli chat --no-interactive --agent qa-expert --trust-all-tools \ "Écris les tests de non-régression" ``` Ce pattern « player-coach » (décrit par [Ricardo Sueiras](https://blog.beachgeek.co.uk/kiro-cli-subagents-player-coach/)) permet de créer des boucles de feedback automatisées : un agent produit, un autre review, le premier corrige. Le résultat est un code qui a déjà traversé plusieurs niveaux de validation avant même la review humaine. Le mode headless de la CLI (disponible depuis la version 2.0) permet d'intégrer ces pipelines dans GitHub Actions. Un workflow de CI peut déclencher un agent pour analyser une PR, produire un rapport, et poster un commentaire — le tout sans intervention humaine. ## Gestion des prompts et ressources Kiro Comprendre comment Kiro charge ses ressources dans le contexte est essentiel pour optimiser la consommation de tokens et maximiser la pertinence des réponses. ![Comment Kiro charge ses ressources dans le contexte](/static/2026/07/kiro-starter/06-prompt-resources.webp) ### Chargement automatique - **Steering (always)** : injecté systématiquement. C'est le socle de connaissances permanent. Garder ces fichiers concis — chaque token compte. - **Steering (fileMatch)** : activé conditionnellement. Quand l'agent lit un fichier `.tf`, le steering `terraform.md` se charge automatiquement. - **Skills (auto-match)** : activé quand la requête correspond à la description du skill. Le frontmatter `description` est la clé. - **Powers (keyword match)** : activé quand un mot-clé de la power apparaît dans le prompt. Transparent pour l'utilisateur. ### Invocation manuelle - **Steering (manual)** : via `#NomDuSteering` dans le chat. - **Skills (slash command)** : via `/nom-du-skill` dans l'input. - **Agents (explicit)** : via instruction dans le prompt ou sélection automatique par description. - **Fichiers & Dossiers** : via `#File` ou `#Folder` pour injecter du contexte spécifique. ### Principe d'économie La règle d'or : **charger le minimum nécessaire**. Préférer des fichiers courts et ciblés, utiliser le mode `fileMatch` pour les connaissances contextuelles, et réserver le mode `always` aux informations véritablement universelles (stack, conventions de base, commandes essentielles). ## Intégration MCP avec Jira et Confluence L'intégration MCP avec les outils de gestion de projet transforme le workflow quotidien. Quelques exemples concrets : **Daily standup assisté** : l'agent consulte les tickets Jira en cours, les PR ouvertes, les commits récents, et produit un résumé orienté sur les blocages et les décisions à prendre. Le daily passe de 15 minutes de reporting mécanique à 5 minutes de discussion sur les vrais problèmes. **Synchronisation specs ↔ tickets** : quand une spec Kiro est validée, l'agent peut créer automatiquement les sous-tâches Jira correspondantes, avec les critères d'acceptation extraits des requirements. **Documentation vivante** : après l'implémentation d'une feature, l'agent met à jour la page Confluence associée avec les décisions techniques prises, les endpoints créés, et les patterns utilisés. **Contexte enrichi** : quand un développeur travaille sur un ticket, l'agent peut consulter Confluence pour récupérer le contexte métier, les décisions architecturales passées, et les contraintes documentées. ## Audits réguliers par agents spécialisés Une bonne pratique souvent négligée : les audits réguliers. Plutôt que d'attendre qu'un problème soit signalé en production, on programme des audits périodiques par les agents spécialisés. ![Cycle d'audits continus par agents spécialisés](/static/2026/07/kiro-starter/05-audit-cycle.webp) ### Mise en place Chaque agent d'audit est un custom agent avec un prompt orienté analyse et reporting. On les déclenche soit manuellement (hook `userTriggered`), soit dans un pipeline CI (CLI headless), soit en début de sprint. Les audits recommandés : - **QA** : couverture de tests, cas limites non couverts, tests fragiles - **SEO** : meta tags manquants, structured data invalide, performance dégradée - **Sécurité** : dépendances vulnérables, secrets exposés, headers manquants - **UX/UI** : violations d'accessibilité, incohérences responsive, contrastes insuffisants - **Architecture** : couplage excessif, dette technique, patterns obsolètes - **Performance** : bundle size, lazy loading manquant, requêtes N+1 Chaque audit produit un rapport actionnable : pas un listing exhaustif de warnings, mais une liste priorisée de corrections avec leur impact estimé. ### Fréquence et coût La bonne pratique : un audit SEO et sécurité à chaque PR (via CI), un audit architecture et performance en début de sprint, un audit UX/UI avant chaque release. Le coût est marginal comparé au temps humain équivalent, et la couverture est systématique. ## Bonnes pratiques pour les hooks Les hooks sont puissants mais peuvent devenir coûteux si mal configurés. Quelques règles : - **Préférer `runCommand` à `askAgent`** quand c'est possible. Un `pnpm lint` ne coûte rien en tokens. - **Cibler les patterns** précisément. Si le hook n'est pertinent que pour les composants, cibler `components/**/*.tsx`. - **Éviter les hooks en cascade**. Un hook qui modifie un fichier peut déclencher un autre hook `fileEdited`. - **Réserver `preToolUse` aux vérifications critiques** (sécurité, secrets dans le code). - **Documenter chaque hook** — le champ `description` permet à l'équipe de comprendre pourquoi ce hook existe. ## Trouver des ressources L'écosystème Kiro s'enrichit rapidement. Quelques sources pour trouver des skills, agents, et configurations : - [kiro.dev/powers](https://kiro.dev/powers/) — Le catalogue officiel de powers - [KiroHub](https://agents.kirorepository.online/) — Agents, skills et powers communautaires - [SkillHub](https://www.skillhub.club/) — Marketplace de skills pour agents de code - [GitHub awsdataarchitect/kiro-best-practices](https://github.com/awsdataarchitect/kiro-best-practices) — Template de bonnes pratiques Kiro - [kiro.dev/docs](https://kiro.dev/docs/) — Documentation officielle complète ## Transformer le starter kit en Power privée Le starter kit qu'on vient de construire — steering, agents, hooks, MCP — peut aller plus loin. Plutôt que de dupliquer le répertoire `.kiro/` dans chaque projet de l'agence, on peut le packager en une **Kiro Power privée** distribuée à toute l'équipe depuis un repository centralisé. ![Du Starter Kit à la Kiro Power privée](/static/2026/07/kiro-starter/07-power-private.webp) ### Structurer la Power Une Power nécessite au minimum un fichier `POWER.md` à la racine. On y ajoute un `mcp.json` pour les serveurs MCP et un répertoire `steering/` pour les guides de workflow : ``` power-webagency/ ├── POWER.md # Métadonnées + onboarding + mapping steering ├── mcp.json # Jira, Confluence, GitHub, AWS docs └── steering/ ├── tech.md # Stack Next.js/React/TypeScript/Tailwind ├── conventions.md # Nommage, imports, Git, TypeScript strict ├── testing.md # Vitest, Playwright, structure tests ├── deployment.md # Terraform, GitHub Actions, AWS serverless ├── seo.md # Structured data, meta, performance └── architecture.md # Patterns Lambda, DynamoDB, API Gateway ``` Le `POWER.md` contient un frontmatter avec les mots-clés d'activation, une section d'onboarding, et un mapping qui indique quel fichier de steering charger selon le contexte : ```markdown --- name: "webagency-starter" displayName: "Web Agency Starter Kit" description: "Stack complète pour web agency : Next.js 16, TypeScript, AWS serverless, Terraform, GitHub Actions, Vitest, Playwright." keywords: ["nextjs", "react", "typescript", "aws", "lambda", "terraform", "serverless", "vitest", "playwright"] author: "NomDeLAgence" --- # Onboarding ## Step 1: Vérifier les prérequis - Node.js 22+ (`node --version`) - pnpm (`pnpm --version`) - Terraform CLI (`terraform --version`) - AWS CLI configuré (`aws sts get-caller-identity`) # When to Load Steering Files - Composants React/Next.js → `tech.md` - Nommage, imports, Git → `conventions.md` - Tests → `testing.md` - Déploiement, CI/CD → `deployment.md` - Architecture serverless → `architecture.md` ``` ### Installer la Power en privé L'installation se fait depuis le panneau Powers de l'IDE (l'icône 👻⚡ dans la barre latérale). Deux options pour les powers privées : 1. **Add power from GitHub** : entrer l'URL d'un repository GitHub privé (les développeurs doivent avoir accès au repo). Kiro clone et installe automatiquement. 2. **Add power from Local Path** : sélectionner un dossier local contenant le `POWER.md`. Utile quand la power est clonée manuellement ou incluse comme git submodule. Une fois installée, la Power est active. Kiro charge automatiquement les steering files pertinents quand les mots-clés sont détectés. Les MCP servers déclarés dans `mcp.json` sont enregistrés dans `~/.kiro/settings/mcp.json`. ### L'approche combinée La configuration optimale : la **Power porte le socle commun** (conventions, stack, patterns d'architecture, MCP partagés) et chaque projet conserve son propre `.kiro/` pour les **spécificités** (specs de features, hooks métier, steering additionnel). Quand la Power est mise à jour dans le repo central, chaque développeur peut la rafraîchir via **Check for updates** dans le panneau Powers. Tous les projets bénéficient immédiatement des améliorations. ## Se concentrer sur la valeur ajoutée Le changement de posture est fondamental. Dans un workflow AI-DLC avec Kiro, le développeur ne se demande plus « comment implémenter cette feature ? » mais « quelle feature apporte le plus de valeur ? ». Le « comment » est délégué aux agents. Cela ne signifie pas que la compétence technique devient inutile. Au contraire : il faut être capable de valider que l'implémentation proposée par l'agent est correcte, performante, et maintenable. Mais le temps passé à écrire du code mécanique — CRUD, code répétitif, configuration, tests de base — est drastiquement réduit. Le daily standup évolue aussi. Avec l'intégration MCP Jira/Confluence et les rapports d'agents, le standup du matin peut se concentrer sur : - Les décisions architecturales à prendre (pas les statuts de tickets) - Les blocages réels (pas les « j'ai avancé sur le ticket X ») - Les validations nécessaires (review de specs, approbation de design) L'agent prépare le terrain. L'humain prend les décisions. ## Conclusion Construire un starter kit Kiro pour une web agency n'est pas un exercice purement technique. C'est un exercice d'organisation qui force à expliciter ce qui est souvent implicite : les conventions, les processus, les critères de qualité, les rôles et responsabilités. Le résultat est un repository qui porte en lui la connaissance collective de l'équipe. Chaque nouveau développeur, chaque nouvel agent, hérite immédiatement de cette connaissance. Les pratiques sont appliquées systématiquement, pas par discipline individuelle mais par design du système. L'investissement initial — quelques heures pour rédiger les steerings, définir les agents, configurer les hooks et les MCP — se rentabilise dès les premières semaines. Moins de temps perdu en onboarding, moins d'erreurs de convention, moins de dette technique accumulée par méconnaissance des patterns établis. Le développement agentique n'est pas une mode passagère. C'est une évolution structurelle de la façon dont les équipes produisent du logiciel. Les équipes qui formalisent leurs pratiques aujourd'hui — via des outils comme Kiro — seront celles qui tireront le plus de valeur de cette évolution demain. - [Kiro — Bring engineering rigor to agentic development](https://kiro.dev/) - [Kiro Specs — Documentation officielle](https://kiro.dev/docs/specs/) - [Kiro Subagents — Documentation](https://kiro.dev/docs/chat/subagents/) - [Implementing a player-coach workflow with Kiro CLI subagents — Ricardo Sueiras](https://blog.beachgeek.co.uk/kiro-cli-subagents-player-coach/) - [Transform DevOps practice with Kiro AI-powered agents — AWS Blog](https://aws.amazon.com/blogs/publicsector/transform-devops-practice-with-kiro-ai-powered-agents/) - [Automate your development workflow with Kiro's AI agent hooks](https://kiro.dev/blog/automate-your-development-workflow-with-agent-hooks/) - [Introducing Kiro Powers](https://kiro.dev/blog/introducing-powers/) - [Kiro Powers — Installation (custom powers)](https://kiro.dev/docs/powers/installation/) - [Kiro Powers — Créer une power](https://kiro.dev/docs/powers/create/) --- # Kiro Starter Kit web agency — Partie 1 : configuration > 2026-07-01T00:00:00.000Z | https://sylvain.bruas.fr/blog/2026/07/kiro-starter Tags: kiro, ia, devops, architecture, aws Summary: AI-DLC, présentation de Kiro (IDE, CLI, Web), et construction d'un starter kit : steering, agents, hooks, skills, powers et MCP. ![Kiro Starter Kit pour une web agency](/static/2026/07/kiro-starter/kiro-starter-cover.webp) Les outils de développement assistés par IA se multiplient. [Cursor](https://www.cursor.com/), [Claude Code](https://docs.anthropic.com/en/docs/agents-and-tools/claude-code/overview)... chacun apporte sa vision du développement assisté par l'IA. Mais entre un assistant qui complète du code et une plateforme qui structure un workflow de production complet, il y a un fossé. [Kiro](https://kiro.dev/) vous aide à structurer tout cela, avec une approche qui dépasse la simple génération de code pour embrasser l'ensemble du cycle de développement. Cet article en deux parties propose un guide concret pour construire un **starter kit Kiro** destiné à une web agency. Dans cette première partie : le contexte AI-DLC, la plateforme Kiro, et la construction du kit. La [seconde partie](/blog/2026/07/kiro-starter-part2) couvre le workflow quotidien, les audits, et les bonnes pratiques. ## L'AI-DLC : un nouveau paradigme de développement ### Du SDLC à l'AI-DLC Le Software Development Life Cycle (SDLC) traditionnel — planification, conception, développement, tests, déploiement, maintenance — repose sur l'humain à chaque étape. L'AI-Driven Development Life Cycle (AI-DLC), [formalisé par AWS en 2025](https://aws.amazon.com/pt/blogs/devops/ai-driven-development-life-cycle/), repositionne les rôles : l'IA devient l'exécutant principal sur les phases d'implémentation, de test et de déploiement, tandis que l'humain conserve la direction stratégique, la validation et la supervision. ![SDLC traditionnel vs AI-DLC](/static/2026/07/kiro-starter/01-ai-dlc-vs-sdlc.webp) Ce n'est pas une question de remplacer les développeurs. C'est une question de redistribution de l'effort cognitif. Dans un AI-DLC, un développeur passe moins de temps à écrire du code répétitif et plus de temps à définir ce que le logiciel doit accomplir, à valider que l'implémentation respecte les contraintes métier, et à prendre les décisions architecturales qui nécessitent du jugement humain. ### Ce que Kiro apporte au-delà de Claude Code [Claude Code](https://docs.anthropic.com/en/docs/agents-and-tools/claude-code/overview), développé par [Anthropic](https://www.anthropic.com/), est un agent terminal puissant qui a posé les bases de nombreux concepts repris entre autre par Kiro. C'est Claude Code qui a introduit les skills (chargement progressif de documentation), le support natif de MCP, les custom agents et le steering sous forme de fichiers `CLAUDE.md`. Ces mécanismes fonctionnent et sont éprouvés en usage individuel. Ce que Kiro ajoute, c'est une couche d'orchestration et de structure pensée pour les équipes et les projets de production : - **Specs** : un workflow structuré requirements → design → tasks — absent de Claude Code qui reste conversationnel - **Hooks** : des automatisations event-driven intégrées à l'IDE - **Powers** : des packages de connaissances spécialisées activés automatiquement par mots-clés - **Mode Web autonome** : délégation complète de tâches longues avec PR automatiques - **Interface visuelle** : gestion des specs, hooks, et agents dans un IDE dédié Les fondations sont partagées (steering, skills, MCP, custom agents), mais Kiro les enveloppe dans un workflow structuré qui encode le « comment on travaille ici » directement dans le repository. ## La plateforme Kiro : IDE, CLI, Web Kiro n'est pas un outil unique mais une plateforme déclinée en trois interfaces complémentaires. ![La plateforme Kiro : IDE, CLI, Web](/static/2026/07/kiro-starter/02-kiro-platforms.webp) ### L'IDE : le quotidien du développeur L'IDE Kiro est l'environnement de travail principal. C'est là que se déroulent les sessions Vibe (conversationnelles) et Spec (structurées). L'IDE offre l'accès complet aux hooks, au steering, aux skills, aux powers et aux MCP servers. Deux modes d'autonomie coexistent : **Autopilot** (l'agent travaille de bout en bout, le développeur review) et **Supervised** (l'agent s'arrête après chaque modification pour validation). C'est l'interface à utiliser pour le développement actif : écriture de features, debugging, refactoring, itération rapide avec feedback visuel immédiat. ### La CLI : automatisation et pipelines La [CLI Kiro](https://kiro.dev/cli/) apporte l'agent dans le terminal. Elle partage le même moteur que l'IDE — steering, skills, custom agents, MCP — mais s'intègre dans des workflows scriptés. Depuis la version 2.0, elle supporte un **mode headless** avec API key, ce qui permet de l'intégrer directement dans des pipelines CI/CD, des scripts de build, ou des workflows [GitHub Actions](https://docs.github.com/en/actions). Le cas d'usage principal : l'automatisation. Intégrer un agent dans un pipeline GitHub Actions pour analyser une PR et poster un commentaire, générer du code d'infrastructure à partir d'un ticket Jira, ou orchestrer des agents en pipeline via le mode **agent-to-agent** où la sortie d'un agent alimente l'entrée du suivant. ### Le Web : délégation autonome [Kiro Web](https://kiro.dev/web/) est la nouveauté majeure. Accessible depuis un navigateur, sans installation, il permet de connecter des repositories GitHub et de déléguer des tâches complètes à l'agent. Le **mode autonome** est le différenciateur : l'agent pose des questions de clarification en amont, construit un plan, délègue à des sous-agents spécialisés, et ouvre une pull request automatiquement. C'est l'interface à utiliser quand on veut déléguer une tâche longue sans bloquer son IDE : refactoring cross-repo, implémentation d'une feature bien spécifiée, migration de code. On décrit le besoin, on laisse l'agent travailler, on review la PR résultante. **Point de vigilance : la consommation de crédits.** En mode autonome, l'agent consomme des crédits en continu jusqu'à complétion. Deux précautions dans un contexte d'équipe : - **Limiter les droits par profil** : restreindre les abonnements autonomes (Pro+, Power) aux profils seniors qui savent cadrer une tâche - **Cadrer précisément la tâche** : une spec bien rédigée avec des critères d'acceptation clairs limite le périmètre d'exécution L'autre atout du mode Web : il travaille quand vous ne travaillez pas. Lancer une tâche le vendredi soir — migration de code, refactoring d'un module, génération de tests — et retrouver une PR prête à review le lundi matin. ### Quand passer de l'un à l'autre **IDE pour coder**, **CLI pour automatiser**, **Web pour déléguer**. ## Formaliser les pratiques de l'équipe Avant de configurer Kiro, il faut cartographier les pratiques existantes. Voici la stack d'une web agency type, construite autour de [TypeScript](https://www.typescriptlang.org/), [React](https://react.dev/) 19, [Next.js](https://nextjs.org/) 16, et [Tailwind CSS](https://tailwindcss.com/) 4, avec une infrastructure serverless AWS gérée par [Terraform](https://www.terraform.io/) : | Domaine | Choix | |---------|-------| | **Langages & Frameworks** | TypeScript, React 19, Next.js 16, Tailwind CSS 4 | | **Package manager** | pnpm | | **Backend** | AWS Lambda, API Gateway, DynamoDB | | **Hébergement frontend** | S3 + CloudFront (site statique) | | **Infrastructure as Code** | Terraform | | **CI/CD** | GitHub Actions | | **Versioning** | Git, Gitflow, Pull Requests | | **Tests** | Vitest (unit/intégration), Playwright (E2E) | | **Ticketing** | Jira | | **Documentation** | Confluence | Côté backend : [AWS Lambda](https://docs.aws.amazon.com/lambda/) pour le compute serverless, [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/) pour les endpoints REST, [Amazon DynamoDB](https://docs.aws.amazon.com/dynamodb/) pour la persistance NoSQL. Frontend sur [Amazon S3](https://docs.aws.amazon.com/s3/) derrière [Amazon CloudFront](https://docs.aws.amazon.com/cloudfront/). Monitoring via [Amazon CloudWatch](https://docs.aws.amazon.com/cloudwatch/) et [AWS X-Ray](https://docs.aws.amazon.com/xray/). Versioning [Gitflow](https://nvie.com/posts/a-successful-git-branching-model/) avec [Git](https://git-scm.com/). Tests : [Vitest](https://vitest.dev/) et [Playwright](https://playwright.dev/). Gestion de projet : [Jira](https://www.atlassian.com/software/jira) et [Confluence](https://www.atlassian.com/software/confluence). Package manager : [pnpm](https://pnpm.io/). ## Construire le Starter Kit Kiro Le starter kit vit dans `.kiro/` à la racine du projet, versionné avec le code. Chaque développeur qui clone le repo hérite de la configuration complète. ![Architecture du Starter Kit Kiro](/static/2026/07/kiro-starter/03-starterkit-architecture.webp) ### Steering : encoder les conventions Fichiers markdown dans `.kiro/steering/`, injectés automatiquement dans le contexte : ```markdown .kiro/steering/ ├── tech.md # Stack, versions, commandes build/test/deploy ├── conventions.md # Nommage, imports, TypeScript strict, Git ├── testing.md # Framework, structure, commandes, mocks ├── deployment.md # Pipeline, AWS resources, scripts ├── seo.md # Structured data, meta, performance ├── security.md # Headers, CSP, bonnes pratiques └── architecture.md # Patterns serverless, DynamoDB, Lambda ``` Un bon steering tient en 30-50 lignes. Trois modes d'inclusion : **always** (défaut), **fileMatch** (ex: `*.tf` → `terraform.md`), **manual** (via `#NomDuSteering`). Pour les gros documents ([OpenAPI](https://www.openapis.org/), [GraphQL](https://graphql.org/)), utiliser `#[[file:chemin/relatif]]`. ### Agents personnalisés : un agent par métier Les custom agents sont des fichiers markdown dans `.kiro/agents/`. Chaque agent a son propre prompt système, ses outils autorisés, et éventuellement ses MCP servers dédiés. Kiro sélectionne automatiquement l'agent approprié en fonction de la description, ou on peut l'invoquer explicitement. Pour une web agency, on définit des agents alignés sur les rôles de l'équipe : ```markdown .kiro/agents/ ├── frontend-dev.md # Expert React/Next.js, composants, performance ├── backend-dev.md # Expert Lambda, DynamoDB, API Gateway ├── devops.md # Expert Terraform, GitHub Actions, AWS ├── qa-expert.md # Expert tests, couverture, qualité ├── seo-auditor.md # Expert SEO technique, structured data ├── ux-reviewer.md # Expert accessibilité, responsive, UX └── security-auditor.md # Expert sécurité, vulnérabilités, compliance ``` Un agent bien défini contient : une description claire (pour la sélection automatique), un prompt système qui cadre son expertise et ses limites, la liste des outils auxquels il a accès, et optionnellement des MCP servers spécifiques. Exemple de structure pour l'agent QA : ```markdown --- name: qa-expert description: "Expert QA spécialisé en tests unitaires (Vitest), intégration et E2E (Playwright). Analyse la couverture, identifie les cas limites, et propose des stratégies de test." model: auto tools: - read - write - shell --- Tu es un expert QA senior. Tu analyses le code pour identifier les cas de test manquants, tu écris des tests robustes et maintenables, et tu vérifies la couverture. ## Règles - Framework : Vitest pour unit/intégration, Playwright pour E2E - Structure : tests/unit/, tests/integration/, tests/e2e/ - Convention : describe('ComponentName') → test('should do X when Y') - Toujours nettoyer les side effects dans afterEach - Pas de dépendances entre tests ``` ### Hooks : automatiser sans gaspiller Les hooks sont des automatisations event-driven. Ils se déclenchent sur des événements IDE et exécutent soit une commande shell (`runCommand`), soit une instruction à l'agent (`askAgent`). La tentation est de tout automatiser. C'est une erreur : chaque hook `askAgent` consomme des tokens. La bonne pratique est de réserver les hooks à des actions qui apportent une valeur immédiate et évitent des erreurs coûteuses en aval. `.kiro/hooks/lint-on-save.kiro.hook` : ```json { "name": "Lint on Save", "version": "1.0.0", "when": { "type": "fileEdited", "patterns": ["*.ts", "*.tsx"] }, "then": { "type": "runCommand", "command": "pnpm lint --fix" } } ``` `.kiro/hooks/security-check.kiro.hook` : ```json { "name": "Security Check on Write", "version": "1.0.0", "when": { "type": "preToolUse", "toolTypes": ["write"] }, "then": { "type": "askAgent", "prompt": "Vérifie que ce fichier ne contient pas de secrets, tokens, ou credentials en clair." } } ``` Les hooks `runCommand` sont gratuits en tokens — ils exécutent simplement une commande. Les hooks `askAgent` consomment du contexte. La règle : utiliser `runCommand` pour le linting, le formatting, les tests rapides ; réserver `askAgent` pour les vérifications qui nécessitent du jugement (sécurité, conformité aux conventions complexes). ### Skills : connaissances à la demande Les skills sont des fichiers markdown avec un frontmatter descriptif. Contrairement au steering (toujours chargé), les skills ne chargent que leurs métadonnées au démarrage. Le contenu complet est injecté uniquement quand l'agent détecte que la requête correspond à la description du skill. C'est le mécanisme idéal pour les documentations volumineuses : patterns Next.js, conventions Terraform, guides de migration, procédures de déploiement. L'installation de skills communautaires se fait via la CLI `skills` ([agentskills.io](https://agentskills.io/)) : ```bash # Installer un skill depuis un repository GitHub npx skills add hashicorp/terraform-skill # Les skills sont installés dans .kiro/skills/ (partagés via Git) ``` Les skills installés au niveau projet (dans `.kiro/skills/`) sont versionnés et partagés avec toute l'équipe. Ceux installés au niveau utilisateur (`~/.kiro/skills/`) restent personnels. ### Powers : expertise packagée Les [Kiro Powers](https://kiro.dev/powers/) vont plus loin que les skills. Une power package de la documentation, des workflows guidés (steering files), et optionnellement des MCP servers. Quand un mot-clé associé à une power est détecté dans le prompt, Kiro charge automatiquement le contexte spécialisé. Le [catalogue de powers](https://kiro.dev/powers/) s'enrichit régulièrement. Pour une web agency AWS, on installe typiquement les powers [AWS CDK](https://docs.aws.amazon.com/cdk/), Terraform, et les powers spécifiques aux frameworks utilisés. L'installation se fait depuis l'IDE via le panneau Powers ou depuis le site kiro.dev. ### MCP Servers : connecter l'écosystème Le [Model Context Protocol (MCP)](https://modelcontextprotocol.io/) permet à Kiro d'interagir avec des outils externes. Pour une web agency, les connexions essentielles sont : `.kiro/settings/mcp.json` : ```json { "mcpServers": { "jira": { "command": "npx", "args": ["-y", "@anthropic/mcp-server-jira"], "env": { "JIRA_URL": "${JIRA_URL}", "JIRA_TOKEN": "${JIRA_TOKEN}" } }, "confluence": { "command": "npx", "args": ["-y", "@anthropic/mcp-server-confluence"], "env": { "CONFLUENCE_URL": "${CONFLUENCE_URL}", "CONFLUENCE_TOKEN": "${CONFLUENCE_TOKEN}" } }, "github": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-github"], "env": { "GITHUB_TOKEN": "${GITHUB_TOKEN}" } }, "aws-docs": { "command": "uvx", "args": ["awslabs.aws-documentation-mcp-server@latest"], "env": { "FASTMCP_LOG_LEVEL": "ERROR" } } } } ``` L'intégration Jira permet à l'agent de lire les tickets, mettre à jour les statuts, et créer des sous-tâches. L'intégration Confluence permet de consulter la documentation existante et de la mettre à jour. Ces connexions transforment le daily standup : l'agent peut produire un résumé de l'avancement basé sur les commits, les PR, et les tickets, orienté sur les vrais blocages plutôt que sur le reporting mécanique. --- Dans la [seconde partie](/blog/2026/07/kiro-starter-part2) : workflow Spec, audits par agents, mode agent-to-agent, gestion des tokens, et transformation du starter kit en Power privée. - [Kiro — Bring engineering rigor to agentic development](https://kiro.dev/) - [AI-Driven Development Life Cycle — AWS DevOps Blog](https://aws.amazon.com/pt/blogs/devops/ai-driven-development-life-cycle/) - [Kiro Web — Mode autonome](https://kiro.dev/docs/web/autonomous-mode) - [Kiro CLI 2.0 — Headless mode et pipelines](https://kiro.dev/blog/cli-2-0/) - [Kiro Steering — Documentation officielle](https://kiro.dev/docs/steering/) - [Kiro Hooks — Documentation officielle](https://kiro.dev/docs/hooks/) - [Kiro Powers — Catalogue](https://kiro.dev/powers/) - [Kiro Custom Agents — Configuration](https://kiro.dev/docs/cli/custom-agents/creating/) - [AI-DLC.dev — The AI-Driven Development Lifecycle](https://ai-dlc.dev/) --- # EC2 Capacity Reservations, Savings Plans et Reserved Instances > 2026-05-12T11:00:00.000Z | https://sylvain.bruas.fr/blog/2026/05/ec2-capacity-reservation Tags: EC2, Savings Plans, FinOps, Architecture, AWS Summary: Retour d'expérience après une erreur InsufficientInstanceCapacity : ODCR, Savings Plans, Reserved Instances et mix optimal avec Spot. ![Architecture cible : ODCR + Savings Plans + Spot](/static/2026/05/ec2-capacity-reservation/ec2-reserved-capacicy-cover.webp) Il y a quelques semaines, un de mes clients a rencontré un incident qui illustre un risque souvent sous-estimé sur AWS : pendant 45 minutes, impossible de lancer de nouvelles instances Amazon Elastic Compute Cloud (EC2) d'un type spécifique sur la région eu-west-3 (Paris). L'Auto Scaling Group tentait de scaler, mais chaque tentative se soldait par la même erreur : **InsufficientInstanceCapacity**. Le service s'est dégradé et les utilisateurs ont été impactés. ## Qu'est-ce qu'une erreur InsufficientInstanceCapacity (ICE) ? Quand vous lancez une instance EC2, AWS doit trouver un serveur physique disponible dans l'Availability Zone (AZ) demandée, avec le bon type d'instance et suffisamment de ressources. Si cette capacité n'est pas disponible à cet instant précis, AWS retourne l'erreur `InsufficientInstanceCapacity`. ![Scénario ICE sur eu-west-3](/static/2026/05/ec2-capacity-reservation/01-ice-error-scenario.webp) *Scénario réel : une erreur ICE empêche le scaling pendant 45 minutes sur la région Paris* Il est important de comprendre que cette erreur **n'est pas liée à vos quotas de compte** (Service Quotas). Vos limites peuvent être parfaitement suffisantes, mais si AWS n'a physiquement plus de serveurs disponibles pour le type d'instance demandé dans l'AZ ciblée, le lancement échouera. C'est une contrainte d'infrastructure physique. Les erreurs ICE sont plus fréquentes dans certaines situations : - **Régions à forte demande** : Paris (eu-west-3) est une région plus petite que us-east-1 ou eu-west-1, avec moins de capacité physique disponible - **Types d'instances spécifiques** : les instances GPU, les très grandes tailles (metal, 24xlarge) ou les générations récentes peuvent avoir une disponibilité limitée - **Pics de demande** : événements commerciaux, fins de mois, ou simplement une forte activité simultanée dans la même AZ - **Mono-AZ** : concentrer toute sa charge dans une seule Availability Zone augmente considérablement le risque Dans le cas de mon client, l'ASG était configuré sur un seul type d'instance dans deux AZ. Quand la capacité s'est raréfiée pour ce type d'instance sur les deux zones simultanément, plus aucun scaling n'était possible. ## Reserved Instances : comprendre la différence entre régionale et zonale Avant de parler de la solution moderne, il faut comprendre le mécanisme historique des Reserved Instances (RI) et une distinction fondamentale que beaucoup d'architectes négligent : la portée régionale versus zonale. ![Reserved Instances : Régionale vs Zonale](/static/2026/05/ec2-capacity-reservation/02-regional-vs-zonal-ri.webp) *Comparaison des deux types de Reserved Instances et leur impact sur la réservation de capacité* ### Reserved Instance régionale Quand vous achetez une RI avec une portée régionale, la réduction tarifaire s'applique automatiquement à toute instance correspondante dans n'importe quelle AZ de la région. Mieux encore, elle offre une flexibilité de taille au sein de la même famille d'instances (sur Linux/Unix avec tenancy par défaut). Par exemple, une RI régionale `m5` peut couvrir aussi bien des `m5.large` que des `m5.xlarge`, en ajustant via un facteur de normalisation. **Mais attention** : une RI régionale **ne réserve aucune capacité physique**. C'est uniquement une réduction de facturation. Si une erreur ICE survient, votre RI régionale ne vous protège absolument pas. Vous avez la réduction, mais pas la garantie de pouvoir lancer vos instances. ### Reserved Instance zonale Une RI zonale est achetée pour une AZ spécifique (par exemple `eu-west-3a`). Elle offre la même réduction tarifaire, mais avec un avantage majeur : **elle réserve de la capacité physique** dans cette AZ. AWS vous garantit que la capacité correspondante sera disponible. Le compromis est la perte de flexibilité : pas de flexibilité d'AZ (la réduction ne s'applique que dans l'AZ choisie) et pas de flexibilité de taille (elle ne couvre que le type et la taille exacts achetés). ### Le dilemme des RI C'est là que le bât blesse. Avec les Reserved Instances, vous devez choisir entre : - **Flexibilité** (RI régionale) : réduction applicable partout, mais aucune garantie de capacité - **Garantie de capacité** (RI zonale) : capacité réservée, mais rigidité totale sur l'AZ et le type d'instance Et dans les deux cas, vous êtes engagé sur 1 ou 3 ans, sur un type d'instance spécifique. Si vos besoins évoluent, vous êtes coincé (ou vous devez passer par le marketplace RI pour revendre, avec des contraintes). ## On-Demand Capacity Reservations + Savings Plans : la flexibilité retrouvée C'est ici que la combinaison ODCR + Savings Plans change la donne. Cette approche découple deux préoccupations qui étaient historiquement liées avec les RI : la **réservation de capacité** et la **réduction tarifaire**. ![ODCR + Savings Plans : le meilleur des deux mondes](/static/2026/05/ec2-capacity-reservation/03-odcr-savings-plan-combo.webp) *La combinaison ODCR + Savings Plans offre à la fois la garantie de capacité et la réduction tarifaire* ### On-Demand Capacity Reservations (ODCR) Les ODCR vous permettent de réserver de la capacité EC2 dans une AZ spécifique, pour un type d'instance donné, **sans aucun engagement de durée**. Vous pouvez créer une ODCR le lundi et l'annuler le vendredi si vous n'en avez plus besoin. Vous pouvez aussi la modifier : augmenter ou diminuer le nombre d'instances réservées à tout moment. Les ODCR peuvent être « open » (toute instance correspondante dans votre compte les utilise automatiquement) ou « targeted » (seules les instances explicitement configurées les consomment). Elles sont compatibles avec les services managés comme Amazon EC2 Auto Scaling, Amazon Elastic Container Service (ECS), Amazon Elastic Kubernetes Service (EKS) et d'autres. Le point important : une ODCR seule est facturée au tarif On-Demand, que la capacité soit utilisée ou non. C'est là que le Savings Plan entre en jeu. ### Savings Plans Les Savings Plans sont un engagement de dépense en dollars par heure, sur 1 ou 3 ans. En échange, vous bénéficiez d'une réduction pouvant atteindre 72 % par rapport au tarif On-Demand. Il existe deux types principaux pour EC2 : - **Compute Savings Plans** : la réduction s'applique à tout usage compute éligible (EC2, AWS Fargate, AWS Lambda), quelle que soit la famille d'instance, la taille, l'OS, la tenancy ou la région. C'est le plus flexible. - **EC2 Instance Savings Plans** : la réduction est limitée à une famille d'instances dans une région donnée, mais elle est légèrement plus élevée. Vous gardez la flexibilité sur la taille, l'OS et la tenancy. ### La combinaison gagnante Quand vous combinez ODCR et Savings Plans, voici ce qui se passe : 1. L'ODCR **réserve la capacité physique** dans l'AZ → vous êtes protégé contre les erreurs ICE 2. Le Savings Plan **applique automatiquement sa réduction** sur les instances qui consomment cette capacité → vous payez le tarif réduit, pas le tarif On-Demand 3. L'ODCR reste **modifiable et annulable** indépendamment du Savings Plan → vous ajustez la capacité réservée selon vos besoins réels Vous obtenez ainsi le meilleur des deux mondes : la garantie de capacité d'une RI zonale avec la flexibilité tarifaire d'un Savings Plan. Et si demain vous changez de type d'instance ou de région, votre Savings Plan suivra automatiquement. ![Comparaison RI vs ODCR + Savings Plans](/static/2026/05/ec2-capacity-reservation/04-ri-vs-odcr-comparison.webp) *Sur presque tous les critères, la combinaison ODCR + Savings Plans surpasse les Reserved Instances classiques* ## Bonnes pratiques pour les EC2 Capacity Reservations La mise en place d'ODCR nécessite une approche réfléchie pour maximiser leur valeur sans gaspiller de budget. Voici les bonnes pratiques issues de la documentation AWS et de mon expérience terrain. ![Bonnes pratiques ODCR](/static/2026/05/ec2-capacity-reservation/05-odcr-best-practices.webp) *Les six bonnes pratiques essentielles pour une gestion efficace des ODCR* ### Répartir sur plusieurs Availability Zones Ne concentrez jamais toute votre capacité réservée dans une seule AZ. Répartissez vos ODCR sur au moins deux, idéalement trois AZ. Cela vous protège non seulement contre les ICE localisées, mais aussi contre les pannes d'AZ. Dimensionnez chaque ODCR pour supporter la charge minimale de votre application dans cette zone. ### Toujours coupler avec un Savings Plan Une ODCR sans Savings Plan, c'est payer le plein tarif On-Demand pour de la capacité réservée. Assurez-vous que votre engagement Savings Plan couvre au minimum le coût de vos ODCR. Le Savings Plan s'applique automatiquement, il n'y a aucune configuration supplémentaire à faire. ### Monitorer l'utilisation avec Amazon CloudWatch AWS fournit des métriques CloudWatch pour suivre le taux d'utilisation de vos ODCR. Une capacité réservée mais inutilisée coûte exactement le même prix qu'une instance active. Mettez en place des alarmes pour détecter les ODCR sous-utilisées et ajustez-les régulièrement. L'objectif est de maintenir un taux d'utilisation proche de 100 %. ### Choisir entre Open et Targeted Les ODCR « open » sont automatiquement consommées par toute instance correspondante dans votre compte. C'est pratique mais risqué dans un environnement multi-équipes : une équipe peut involontairement consommer la capacité réservée pour une autre. Préférez les ODCR « targeted » pour les workloads critiques, en configurant explicitement quelles instances ou quels ASG doivent les utiliser. ### Utiliser les Capacity Reservation Groups Les groupes de réservation permettent de regrouper plusieurs ODCR (potentiellement dans différentes AZ) sous une même entité logique. Combinés avec AWS Resource Access Manager (RAM), vous pouvez partager ces groupes entre comptes d'une même organisation AWS. C'est indispensable dans une architecture multi-comptes. ### Exploiter Split, Move et Modify AWS a introduit en mars 2025 trois fonctionnalités pour gérer les ODCR de manière plus granulaire : - **Split** : diviser une ODCR existante en plusieurs réservations plus petites. Typiquement, si votre équipe ML dispose d'une ODCR de 10 instances mais n'en utilise que 5, vous pouvez détacher les 5 inutilisées pour créer une nouvelle ODCR destinée à une autre équipe. - **Move** : déplacer de la capacité inutilisée d'une ODCR vers une autre, sans recréer de réservation. Utile pour rééquilibrer la capacité entre projets au fil du temps. - **Modify** : ajuster les attributs d'une ODCR existante (quantité d'instances, éligibilité open/targeted, date de fin) sans perturber les workloads en cours. Ces opérations sont particulièrement puissantes combinées avec les **Capacity Reservation Groups** et **AWS Resource Access Manager (RAM)**. Après un split, vous pouvez partager la nouvelle ODCR avec un autre compte de votre organisation via RAM. Cela permet une gestion centralisée de la capacité au niveau de l'organisation : un compte « plateforme » détient les ODCR et les redistribue aux comptes applicatifs selon les besoins, tout en gardant le contrôle sur l'allocation globale. ### Monitorer avec Amazon EC2 Capacity Manager Depuis octobre 2025, AWS propose [Amazon EC2 Capacity Manager](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-manager.html), une interface centralisée pour surveiller, analyser et gérer l'utilisation de la capacité EC2 sur l'ensemble de vos comptes et régions. Ce service est disponible sans frais supplémentaires dans toutes les régions commerciales. EC2 Capacity Manager consolide dans un tableau de bord unique les données de capacité qui nécessitaient auparavant de naviguer entre la console EC2, CloudWatch, les Cost and Usage Reports et les API `describe`. Concrètement, il offre : - **Vue multi-comptes et multi-régions** : visualisez l'utilisation des instances On-Demand, Spot et des Capacity Reservations à travers toute votre organisation AWS, avec un rafraîchissement horaire des données. - **Tendances historiques** : analysez les patterns d'utilisation sur les 90 derniers jours (ou plus via l'export S3) pour identifier les périodes de sous-utilisation et ajuster vos réservations en conséquence. - **Opportunités d'optimisation priorisées** : le service identifie automatiquement les ODCR sous-utilisées, classées par impact financier. Par exemple, 100 heures vCPU inutilisées sur des instances `p5` représentent un coût bien plus élevé que sur des `t3`. - **Actions directes** : depuis l'interface, vous pouvez modifier les paramètres d'une ODCR (quantité, éligibilité, date de fin) sans naviguer vers d'autres sections de la console. - **Export de données** : exportez les métriques vers Amazon Simple Storage Service (S3) pour une analyse à long terme ou une intégration avec vos outils de BI existants. Pour les organisations qui gèrent des dizaines d'ODCR réparties sur plusieurs comptes, EC2 Capacity Manager remplace avantageusement les scripts maison et les tableaux de bord CloudWatch personnalisés. C'est l'outil qui manquait pour piloter efficacement une stratégie ODCR à l'échelle. ## ODCR comme baseline d'un Auto Scaling Group avec Spot pour le scaling C'est la stratégie que j'ai mise en place chez mon client après l'incident ICE, et c'est à mon sens le meilleur compromis entre coût, disponibilité et élasticité. ![ASG : Baseline ODCR + Spot pour le scaling](/static/2026/05/ec2-capacity-reservation/06-asg-baseline-spot-mix.webp) *Le mix optimal : ODCR pour la baseline garantie, Spot Instances pour le scaling élastique* ### Le principe L'idée est simple : séparer votre flotte EC2 en deux couches au sein du même Auto Scaling Group grâce à une **Mixed Instances Policy** : 1. **La baseline (ODCR + Savings Plan)** : c'est le nombre minimum d'instances dont votre application a besoin en permanence pour fonctionner correctement. Ces instances sont couvertes par des ODCR (capacité garantie) et un Savings Plan (réduction tarifaire). Elles ne seront jamais impactées par une erreur ICE car la capacité est physiquement réservée. 2. **Le scaling (Spot Instances)** : pour absorber les pics de charge au-delà de la baseline, vous utilisez des Spot Instances. Elles offrent jusqu'à 90 % de réduction par rapport au tarif On-Demand, mais peuvent être interrompues avec un préavis de 2 minutes. ### Configuration de l'ASG Dans la configuration de votre Auto Scaling Group, vous définissez : - Le **minimum capacity** correspond à votre baseline ODCR (par exemple 6 instances réparties sur 3 AZ) - Le **desired capacity** s'ajuste dynamiquement selon la charge - Le **maximum capacity** définit la limite haute, atteinte avec des Spot Instances - La **Mixed Instances Policy** spécifie le ratio On-Demand / Spot : les premières instances lancées sont On-Demand (et consomment les ODCR), le scaling additionnel utilise des Spot ```json { "MixedInstancesPolicy": { "InstancesDistribution": { "OnDemandBaseCapacity": 6, "OnDemandPercentageAboveBaseCapacity": 0, "SpotAllocationStrategy": "capacity-optimized" }, "LaunchTemplate": { "Overrides": [ { "InstanceType": "m5.xlarge" }, { "InstanceType": "m5a.xlarge" }, { "InstanceType": "m5n.xlarge" }, { "InstanceType": "m6i.xlarge" } ] } } } ``` Le paramètre `OnDemandBaseCapacity: 6` garantit que les 6 premières instances seront toujours On-Demand (et donc couvertes par vos ODCR). Le `OnDemandPercentageAboveBaseCapacity: 0` indique que tout scaling au-delà de cette baseline utilisera des Spot Instances. ### Diversifier les types d'instances pour le Spot Pour maximiser la disponibilité des Spot Instances, spécifiez plusieurs types d'instances compatibles dans les `Overrides`. La stratégie `capacity-optimized` demande à AWS de choisir automatiquement le pool Spot avec le plus de capacité disponible, réduisant ainsi le risque d'interruption. ### Les économies réalisées Prenons un exemple concret avec une baseline de 6 instances `m5.xlarge` et un pic à 18 instances : - **Baseline (6 instances)** : couvertes par ODCR + Savings Plan → réduction de ~72 % vs On-Demand - **Scaling (12 instances Spot)** : réduction de ~70-90 % vs On-Demand - **Coût moyen pondéré** : environ 75-80 % de réduction par rapport à un déploiement 100 % On-Demand Et surtout, la baseline est **garantie disponible** grâce aux ODCR. Même si une erreur ICE survient, vos 6 instances de base sont protégées. Seul le scaling Spot pourrait être temporairement impacté, mais votre service reste opérationnel à sa capacité minimale. ### Gérer les interruptions Spot Pour que cette architecture soit robuste, préparez votre application aux interruptions Spot : - Utilisez les **notifications d'interruption Spot** (2 minutes de préavis) pour drainer proprement les connexions - Configurez le **Capacity Rebalancing** dans l'ASG pour remplacer proactivement les instances à risque - Assurez-vous que votre application est **stateless** ou que l'état est externalisé (Amazon ElastiCache, Amazon DynamoDB, Amazon Elastic File System) - Mettez en place des **health checks** robustes pour que l'ALB retire rapidement les instances en cours d'interruption ## Quelle stratégie choisir ? L'arbre de décision Pour résumer les différentes options et vous aider à choisir la bonne stratégie selon votre contexte, voici un arbre de décision. ![Arbre de décision](/static/2026/05/ec2-capacity-reservation/08-decision-tree.webp) *Choisissez votre stratégie de réservation en fonction de vos contraintes de disponibilité et d'élasticité* - **Workload non critique, usage imprévisible** → Spot Instances seules (économies maximales, interruptions acceptées) - **Workload non critique, usage prévisible** → Savings Plan seul (réduction tarifaire sans réservation de capacité) - **Workload critique, pas de scaling** → ODCR + Savings Plan (capacité garantie + réduction) - **Workload critique avec scaling** → ODCR baseline + Savings Plan + Spot scaling (le mix optimal) ## Retour sur l'incident : ce qui a changé Après la mise en place de cette architecture chez mon client, voici les changements concrets : - **ODCR créées** sur 3 AZ de eu-west-3, couvrant la baseline de 3 instances (1 par AZ) - **Compute Savings Plan** souscrit pour couvrir l'engagement horaire correspondant - **Mixed Instances Policy** configurée avec `OnDemandBaseCapacity: 3` et Spot pour le scaling - **Plusieurs types d'instances** dans les overrides pour diversifier le pool Spot - **Monitoring CloudWatch** avec alertes sur l'utilisation des ODCR et les interruptions Spot ## Conclusion L'erreur InsufficientInstanceCapacity est un rappel que le cloud n'est pas une ressource infinie. La capacité physique a des limites, et sans précaution, votre application peut se retrouver dans l'impossibilité de scaler au pire moment. La combinaison ODCR + Savings Plans représente une évolution majeure par rapport aux Reserved Instances classiques. Elle offre la même garantie de capacité et le même niveau de réduction et plus de flexibilité . Ajoutez-y des Spot Instances pour le scaling, et vous obtenez une architecture qui maximise les économies tout en garantissant la disponibilité de votre baseline. Si vous opérez des workloads critiques sur EC2, je vous recommande fortement d'auditer votre stratégie de réservation actuelle. Les ODCR sont souvent méconnues, mais elles répondent à un besoin réel que ni les RI régionales ni les Savings Plans seuls ne couvrent : la **garantie de capacité physique**. N'attendez pas votre première erreur ICE pour agir. --- **Ressources utiles :** - [Documentation AWS — EC2 On-Demand Capacity Reservations](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-reservations.html) - [Documentation AWS — EC2 Capacity Manager](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-manager.html) - [Documentation AWS — Reserved Instances : Régionale vs Zonale](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/reserved-instances-scope.html) - [Documentation AWS — Savings Plans et Reserved Instances](https://docs.aws.amazon.com/savingsplans/latest/userguide/sp-ris.html) - [Blog AWS — Réserver la capacité EC2 avec les ODCR](https://aws.amazon.com/blogs/compute/reserving-ec2-capacity-across-availability-zones-by-utilizing-on-demand-capacity-reservations-odcrs/) - [Blog AWS — Gérer les ODCR avec Split, Move et Modify](https://aws.amazon.com/blogs/compute/efficiently-manage-amazon-ec2-on-demand-capacity-reservations-odcrs-with-split-move-and-modify/) - [Blog AWS — EC2 Capacity Manager : surveiller et gérer la capacité depuis une interface unique](https://aws.amazon.com/blogs/aws/monitor-analyze-and-manage-capacity-usage-from-a-single-interface-with-amazon-ec2-capacity-manager/) - [Documentation AWS — Auto Scaling Groups avec Capacity Reservations](https://docs.aws.amazon.com/autoscaling/ec2/userguide/use-ec2-capacity-reservations.html) --- # LiteLLM et les AI Gateways : coûts et sécurité IA > 2026-05-07T00:00:00.000Z | https://sylvain.bruas.fr/blog/2026/05/litellm-ai-gateway Tags: bedrock, ia, finops, architecture, aws Summary: Maîtriser les coûts des agents IA avec LiteLLM en front d'Amazon Bedrock : AI Gateway, budgets, rate limiting et contrôle opérationnel. ![LiteLLM et les AI Gateways : reprendre le contrôle des coûts et de la sécurité de vos agents IA](/static/2026/05/litellm-cover.webp) L'intelligence artificielle générative a changé la donne. Les entreprises expérimentes et commencent la mise en production d'agents IA capables d'orchestrer des tâches complexes : analyse de documents, génération de code, interaction client, automatisation de processus métier. Mais cette adoption rapide a un revers : les coûts. Et pas n'importe quels coûts — des coûts imprévisibles, qui peuvent exploser sans raison apparente, et qui échappent souvent aux mécanismes de contrôle traditionnels. C'est dans ce contexte que les AI Gateways émergent comme une brique d'infrastructure essentielle. Et parmi les solutions disponibles, LiteLLM se distingue par sa capacité à se positionner en front d'[Amazon Bedrock](https://docs.aws.amazon.com/bedrock/) pour offrir le meilleur des deux mondes : la puissance et la flexibilité d'un catalogue de modèles de classe mondiale, combinées à un contrôle granulaire des coûts, de la sécurité et de la gouvernance. ## Le problème : des coûts d'agents IA qui explosent sans prévenir Contrairement à une API REST classique dont le coût par appel est relativement stable et prévisible, les agents IA introduisent une imprévisibilité structurelle dans la facturation. Plusieurs facteurs expliquent ce phénomène : **Les boucles d'appels récursifs.** Un agent autonome peut décider, en fonction du contexte, d'appeler un modèle de langage (LLM) plusieurs dizaines de fois pour accomplir une seule tâche. Un agent de type ReAct (Reasoning + Acting) va typiquement alterner entre phases de réflexion et phases d'action, chaque itération générant un appel au LLM. Si la tâche est complexe ou si l'agent « tourne en rond » sur un problème, le nombre d'appels peut exploser sans qu'aucun mécanisme natif ne l'arrête. **L'explosion des tokens en contexte.** Les agents modernes utilisent des fenêtres de contexte de plus en plus larges. Chaque appel successif inclut l'historique des échanges précédents, ce qui signifie que le nombre de tokens en entrée croît de manière quasi-exponentielle au fil de la conversation. **Les appels d'outils en cascade.** Les agents modernes ne se contentent pas d'appeler un LLM. Ils orchestrent des outils : recherche web, requêtes en base de données, appels à d'autres API, génération d'images. Chaque outil peut lui-même déclencher des appels supplémentaires au LLM pour interpréter les résultats. Un seul prompt utilisateur peut ainsi générer des dizaines d'appels facturés. **L'absence de plafond natif.** La plupart des fournisseurs de modèles facturent à l'usage sans mécanisme de plafonnement intégré. Si un agent s'emballe, rien ne l'arrête côté fournisseur — la facture continue de grimper jusqu'à ce qu'un humain intervienne ou que les quotas de rate limiting soient atteints. ### Exemples d'explosion de coûts Les témoignages se multiplient dans la communauté : - Un développeur qui lance un agent de refactoring de code sur un repository entier et se retrouve avec une facture de plusieurs centaines de dollars en quelques heures, là où il attendait quelques dizaines. - Une équipe data qui déploie un agent d'analyse de documents en production sans garde-fou : l'agent, confronté à des documents mal formatés, entre dans des boucles de retry qui multiplient les appels par 10. - Un chatbot client qui, face à des requêtes ambiguës, génère des réponses de plus en plus longues en incluant tout l'historique de conversation, faisant exploser le coût par interaction. Ces situations ne sont pas des cas extrêmes. Elles sont le résultat normal du fonctionnement des agents IA quand aucun mécanisme de contrôle n'est en place. Le problème n'est pas que les agents « dysfonctionnent » — c'est qu'ils fonctionnent exactement comme prévu, mais sans contrainte budgétaire. ### Pourquoi les outils de FinOps traditionnels ne suffisent pas Les outils de FinOps cloud classiques ([AWS Cost Explorer](https://docs.aws.amazon.com/cost-management/latest/userguide/ce-what-is.html), budgets [Amazon CloudWatch](https://docs.aws.amazon.com/cloudwatch/), alertes de facturation) sont conçus pour des patterns de consommation relativement stables et prévisibles. Ils fonctionnent bien pour surveiller la consommation [Amazon Elastic Compute Cloud (EC2)](https://docs.aws.amazon.com/ec2/) ou [Amazon Simple Storage Service (S3)](https://docs.aws.amazon.com/s3/), mais ils sont inadaptés aux coûts d'IA générative pour plusieurs raisons : - **Granularité insuffisante** : ils opèrent historiquement au niveau du compte ou du service. Bedrock propose désormais une [attribution par principal IAM](https://aws.amazon.com/blogs/machine-learning/introducing-granular-cost-attribution-for-amazon-bedrock/), mais sans mécanisme de coupure automatique au niveau applicatif. - **Latence des alertes** : les alertes budgétaires AWS ont un délai de plusieurs heures. Un agent qui s'emballe peut consommer des centaines de dollars avant que l'alerte ne se déclenche. - **Pas de coupure automatique** : une alerte budgétaire AWS notifie, mais ne coupe pas l'accès. L'agent continue de consommer pendant que l'équipe réagit. - **Pas de vision cross-provider** : si vous utilisez plusieurs fournisseurs de modèles (Bedrock, OpenAI, Anthropic direct), chaque fournisseur a sa propre facturation, rendant la vision consolidée impossible. ## La réponse : les AI Gateways ### Qu'est-ce qu'un AI Gateway ? Un AI Gateway est un proxy intelligent qui se positionne entre vos applications (agents, chatbots, pipelines) et les fournisseurs de modèles IA. Il agit comme un point de passage obligé pour tous les appels aux LLM, ce qui lui permet d'offrir des fonctionnalités transversales : - **Contrôle des coûts** : budgets par équipe, par application, par utilisateur, avec coupure automatique quand le budget est atteint. - **Sécurité et gouvernance** : authentification, autorisation, filtrage de contenu, audit des requêtes. - **Observabilité** : logging centralisé de tous les appels, métriques de latence, de tokens consommés, de coûts en temps réel. - **Routage intelligent** : redirection des requêtes vers différents modèles en fonction de critères (coût, latence, disponibilité, type de tâche). - **Abstraction du fournisseur** : interface unifiée quel que soit le modèle sous-jacent (Claude, Llama, Mistral, Titan, etc.). ### Pourquoi un point d'entrée unifié est essentiel Sans AI Gateway, chaque équipe, chaque application accède directement aux modèles avec ses propres credentials, ses propres patterns d'appel, et sans visibilité centralisée. C'est l'équivalent de donner à chaque développeur un accès root à la base de données de production sans passer par un connection pooler ou un proxy SQL. Un point d'entrée unifié permet de : - **Appliquer des politiques de sécurité cohérentes** : filtrage de données sensibles (PII), blocage de certains types de requêtes, validation des inputs. - **Avoir une vision consolidée des coûts** : qui consomme quoi, combien, et pour quel usage. - **Réagir en temps réel** : couper un agent qui s'emballe, throttler une application qui consomme trop, rediriger vers un modèle moins coûteux en cas de pic. - **Simplifier la rotation des credentials** : un seul point à mettre à jour quand les clés API changent. - **Faciliter la conformité** : un seul point d'audit pour toutes les interactions avec les modèles IA. ![Sans AI Gateway vs Avec AI Gateway](/static/2026/05/litellm-sans-vs-avec-gateway.webp) ## Une AI Gateway open source : LiteLLM LiteLLM est un proxy open source qui fournit une interface compatible OpenAI pour plus de 100 fournisseurs de modèles IA. Concrètement, vos applications parlent à LiteLLM via l'API standard OpenAI (`/chat/completions`, `/embeddings`, etc.), et LiteLLM traduit ces appels vers le fournisseur de votre choix : Amazon Bedrock, Azure OpenAI, Anthropic, Mistral, Cohere, et bien d'autres. C'est une plateforme complète de gestion des accès aux LLM qui inclut : - **Gestion des clés virtuelles** : création de clés API avec des budgets, des limites de rate, et des permissions par modèle. - **Budgets par équipe et par utilisateur** : définition de plafonds de dépenses avec coupure automatique. - **Routage et fallback** : si un modèle est indisponible ou saturé, LiteLLM redirige automatiquement vers un modèle de secours. - **Guardrails** : intégration de filtres de contenu, de détection de PII, et de politiques de sécurité. - **Dashboard d'observabilité** : visualisation en temps réel des coûts, des tokens, de la latence, par clé, par équipe, par modèle. - **Cache sémantique** : mise en cache des réponses pour des requêtes similaires, réduisant les coûts et la latence. LiteLLM se déploie comme un service stateless (conteneur Docker) devant vos fournisseurs de modèles. Les applications communiquent avec LiteLLM via l'API compatible OpenAI, et LiteLLM route les requêtes vers le bon fournisseur en appliquant les politiques de sécurité, de budget et de routage. ## LiteLLM en front d'Amazon Bedrock : le meilleur des deux mondes ![Architecture LiteLLM en front d'Amazon Bedrock](/static/2026/05/litellm-architecture-gateway.webp) ### Pourquoi Bedrock comme backend ? Amazon Bedrock est le service managé d'AWS qui donne accès à un catalogue de modèles fondamentaux (Foundation Models) de différents fournisseurs : Anthropic (Claude), Meta (Llama), Mistral, Amazon (Titan, Nova), Cohere, AI21 Labs, et d'autres. Bedrock offre plusieurs avantages structurels : - **Pas de gestion d'infrastructure** : les modèles sont servis par AWS, vous n'avez pas à gérer de GPU, de scaling, ou de disponibilité. - **Intégration native AWS** : [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/iam/) pour l'authentification, [AWS CloudTrail](https://docs.aws.amazon.com/cloudtrail/) pour l'audit, [Amazon Virtual Private Cloud (VPC)](https://docs.aws.amazon.com/vpc/) endpoints pour la connectivité privée, [AWS Key Management Service (KMS)](https://docs.aws.amazon.com/kms/) pour le chiffrement. - **Données privées** : vos données ne sont pas utilisées pour entraîner les modèles. Bedrock offre des garanties contractuelles sur ce point. - **Disponibilité régionale** : Bedrock est disponible dans plusieurs régions européennes, et est disponible dans l'ESC avec une liste limitée de modèles. ### Ce que LiteLLM ajoute à Bedrock Bedrock est excellent pour servir des modèles, LiteLLM ajoute une interface unifiée et plus orientée vers les applications et utilisateurs. **Budgets granulaires avec enforcement.** Bedrock offre désormais une attribution des coûts par principal IAM, mais il ne propose pas de mécanisme de *coupure automatique* quand un seuil est atteint. LiteLLM comble ce manque : il permet de définir des budgets par Business Unit, par application, par équipe, voire par utilisateur individuel, avec un enforcement en quasi temps réel. Quand le budget est atteint, l'accès est coupé automatiquement — pas besoin d'attendre une alerte CloudWatch avec 6 heures de retard. ```yaml # Exemple de configuration LiteLLM avec budgets par équipe general_settings: master_key: sk-litellm-master-key model_list: - model_name: claude-sonnet litellm_params: model: bedrock/us.anthropic.claude-sonnet-4-6 aws_region_name: us-east-1 - model_name: claude-haiku litellm_params: model: bedrock/us.anthropic.claude-3-5-haiku-20241022-v1:0 aws_region_name: us-east-1 - model_name: mistral-7b litellm_params: model: bedrock/converse/mistral.mistral-7b-instruct-v0:2 aws_region_name: us-east-1 ``` Côté gestion des équipes et budgets, LiteLLM expose une API d'administration : ```bash # Créer une équipe avec un budget mensuel curl -X POST 'http://litellm:4000/team/new' \ -H 'Authorization: Bearer sk-litellm-master-key' \ -H 'Content-Type: application/json' \ -d '{ "team_alias": "equipe-data", "max_budget": 500, "budget_duration": "1mo", "models": ["claude-sonnet", "claude-haiku"], "metadata": {"bu": "data-engineering"} }' # Créer une clé pour un développeur avec son propre budget curl -X POST 'http://litellm:4000/key/generate' \ -H 'Authorization: Bearer sk-litellm-master-key' \ -H 'Content-Type: application/json' \ -d '{ "team_id": "team-xxx", "max_budget": 50, "budget_duration": "1mo", "models": ["claude-haiku"], "metadata": {"user": "jean.dupont@entreprise.fr"} }' ``` **Routage par coût.** LiteLLM peut automatiquement router les requêtes vers le modèle le moins coûteux capable de traiter la tâche. Par exemple, les requêtes simples (classification, extraction) sont envoyées vers Claude Haiku (peu coûteux), tandis que les tâches complexes (raisonnement, génération longue) sont dirigées vers Claude Sonnet. **Fallback automatique.** Si Bedrock dans une région est saturé ou indisponible, LiteLLM peut automatiquement basculer vers une autre région ou un autre fournisseur, sans interruption pour l'application. ### L'ancienne pièce manquante côté AWS : l'attribution granulaire native de Bedrock Depuis avril 2026, AWS a comblé une lacune avec l'[attribution granulaire des coûts pour Amazon Bedrock](https://aws.amazon.com/blogs/machine-learning/introducing-granular-cost-attribution-for-amazon-bedrock/). Bedrock attribue désormais automatiquement les coûts d'inférence au principal IAM qui effectue l'appel. Dans le Cost and Usage Report (CUR 2.0), une nouvelle colonne `line_item_iam_principal` identifie précisément qui consomme : un utilisateur IAM, un rôle applicatif, ou une identité fédérée. Combiné à des tags IAM (principal tags sur les rôles/utilisateurs, ou session tags passés dynamiquement), on peut agréger les coûts par équipe, projet ou centre de coûts directement dans AWS Cost Explorer. **Le cas spécifique des AI Gateways.** L'article AWS identifie explicitement le scénario d'un LLM gateway en front de Bedrock. Sans configuration supplémentaire, tout le trafic est attribué au rôle unique du gateway — aucune visibilité par utilisateur. La solution recommandée : le gateway effectue un `AssumeRole` par utilisateur avec un `--role-session-name` identifiant l'appelant et des `--tags` de session (équipe, tenant, centre de coûts). Les credentials sont cachées avec un TTL d'une heure, ce qui limite les appels [STS](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) à un par utilisateur par heure. ```bash # Exemple : le gateway assume un rôle Bedrock pour chaque utilisateur aws sts assume-role \ --role-arn arn:aws:iam::123456789012:role/BedrockInvocationRole \ --role-session-name "gw-jean.dupont" \ --tags Key=team,Value=data-engineering Key=cost-center,Value=BU-DATA ``` Ce qui apparaît alors dans CUR 2.0 : | `line_item_iam_principal` | `line_item_usage_type` | `tags` | |---|---|---| | `…assumed-role/BedrockRole/gw-jean.dupont` | `EUW3-Claude4Sonnet-input-tokens` | `{"iamPrincipal/team":"data-engineering"}` | | `…assumed-role/BedrockRole/gw-tenant-acme` | `EUW3-Claude4Sonnet-output-tokens` | `{"iamPrincipal/tenant":"acme-corp"}` | **Complémentarité avec LiteLLM.** Cette attribution native ne remplace pas LiteLLM — elle le complète. Bedrock fournit désormais la **visibilité passive** (qui consomme quoi dans la facturation AWS), tandis que LiteLLM assure le **contrôle actif** (coupure automatique quand un budget est atteint, rate limiting par clé, routage par coût, guardrails). Les deux ensemble offrent une gouvernance FinOps complète : - **Bedrock + CUR 2.0** : attribution, reporting, chargeback, analyse a posteriori via Cost Explorer - **LiteLLM** : enforcement en temps réel, coupure automatique, routage intelligent, abstraction multi-modèle En pratique, si vous déployez LiteLLM en front de Bedrock, configurez-le pour utiliser des sessions STS par utilisateur. Vous obtiendrez à la fois le contrôle temps réel de LiteLLM *et* l'attribution native dans votre facturation AWS — le meilleur des deux mondes, littéralement. ### Budgets par BU, par application : la gouvernance FinOps de l'IA L'un des cas d'usage les plus puissants de LiteLLM en front de Bedrock est la capacité à implémenter une gouvernance FinOps granulaire pour l'IA générative. Voici comment structurer les budgets dans une organisation : ![Gouvernance FinOps IA : budgets hiérarchiques avec LiteLLM](/static/2026/05/litellm-budgets-hierarchie.webp) Chaque niveau de la hiérarchie a son propre budget. Si l'équipe Dev du chatbot atteint ses 500 € mensuels, ses clés sont désactivées automatiquement — mais le reste de la BU Produit continue de fonctionner. Si c'est toute la BU Produit qui atteint ses 5 000 €, toutes les applications de cette BU sont coupées, mais les autres BU ne sont pas impactées. ## Sécurité : une couche unifiée indispensable ### Les risques de sécurité spécifiques aux LLM Les agents IA introduisent des vecteurs d'attaque spécifiques qui nécessitent des contrôles dédiés : - **Injection de prompt** : un utilisateur malveillant peut tenter de manipuler l'agent pour qu'il exécute des actions non autorisées ou divulgue des informations sensibles. - **Exfiltration de données** : un agent qui a accès à des données internes peut être manipulé pour les inclure dans ses réponses. - **Fuite de PII** : les modèles peuvent involontairement inclure des données personnelles dans leurs réponses si elles sont présentes dans le contexte. - **Abus de ressources** : un utilisateur peut intentionnellement déclencher des boucles coûteuses pour nuire à l'organisation. - **Shadow AI** : sans point d'entrée centralisé, les équipes utilisent des clés API personnelles, contournant toute politique de sécurité. ### Ce que LiteLLM apporte en termes de sécurité **Authentification et autorisation centralisées.** Chaque appel passe par LiteLLM avec une clé API qui identifie l'appelant. Plus besoin de distribuer des credentials Bedrock (access keys IAM) à chaque application — LiteLLM gère l'authentification côté application et utilise un seul rôle IAM pour accéder à Bedrock. **Guardrails et filtrage de contenu.** LiteLLM s'intègre avec des solutions de guardrails (Bedrock Guardrails, Lakera Guard, Presidio) pour : - Détecter et masquer les PII dans les requêtes et les réponses - Bloquer les tentatives d'injection de prompt - Filtrer le contenu inapproprié ou dangereux - Appliquer des politiques de contenu spécifiques à l'organisation **Audit complet.** Chaque requête est loggée avec : l'identité de l'appelant, le modèle utilisé, le nombre de tokens, le coût, la latence, et optionnellement le contenu de la requête et de la réponse. Ces logs peuvent être envoyés vers des solutions SIEM pour analyse et détection d'anomalies. **Isolation des credentials.** Les applications n'ont jamais accès aux credentials AWS sous-jacentes. Si une clé LiteLLM est compromise, elle peut être révoquée instantanément sans impacter les autres applications. Et la clé compromise n'a accès qu'aux modèles et budgets qui lui ont été attribués — pas à l'ensemble de l'infrastructure AWS. **Contrôle des modèles accessibles.** Vous pouvez restreindre quels modèles sont accessibles par quelle équipe. Par exemple, seule l'équipe R&D a accès à Claude Opus (le plus coûteux), tandis que les équipes produit sont limitées à Haiku et Sonnet. ### Architecture de sécurité recommandée ![Architecture de sécurité : LiteLLM + Bedrock](/static/2026/05/litellm-securite-architecture.webp) Dans cette architecture : - Le trafic ne sort jamais du réseau AWS (VPC endpoint vers Bedrock) - LiteLLM est le seul composant qui possède les credentials Bedrock - Les applications s'authentifient auprès de LiteLLM avec des clés virtuelles à permissions limitées - Tous les appels sont audités et filtrés ## Mise en œuvre pratique ### Déploiement de LiteLLM sur AWS LiteLLM se déploie facilement sur AWS via plusieurs options : - **[Amazon Elastic Container Service (ECS)](https://docs.aws.amazon.com/ecs/)/[AWS Fargate](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/AWS_Fargate.html)** : déploiement conteneurisé serverless, idéal pour la production. - **[Amazon Elastic Kubernetes Service (EKS)](https://docs.aws.amazon.com/eks/)** : si vous avez déjà un cluster Kubernetes. - **EC2** : pour un déploiement simple ou un POC. Le conteneur LiteLLM nécessite une base de données PostgreSQL pour stocker les clés, les budgets et les métriques. [Amazon Relational Database Service (RDS)](https://docs.aws.amazon.com/rds/) PostgreSQL ou [Aurora Serverless](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.html) conviennent parfaitement. ### Configuration du routage vers Bedrock La configuration de LiteLLM pour router vers Bedrock est directe. L'authentification utilise le chaînage standard des credentials AWS (rôle IAM de l'instance, variables d'environnement, ou profil) : ```yaml model_list: - model_name: claude-sonnet litellm_params: model: bedrock/us.anthropic.claude-sonnet-4-6 aws_region_name: us-east-1 - model_name: claude-haiku litellm_params: model: bedrock/us.anthropic.claude-3-5-haiku-20241022-v1:0 aws_region_name: us-east-1 - model_name: mistral-7b litellm_params: model: bedrock/converse/mistral.mistral-7b-instruct-v0:2 aws_region_name: us-east-1 router_settings: routing_strategy: "least-busy" # ou "cost-based", "latency-based" num_retries: 2 timeout: 30 allowed_fails: 1 ``` ### Intégration côté application Côté application, le changement est minimal. Puisque LiteLLM expose une API compatible OpenAI, il suffit de changer l'URL de base : ```python from openai import OpenAI # Avant : appel direct à Bedrock via boto3 # Après : appel via LiteLLM avec contrôle des coûts client = OpenAI( api_key="sk-team-data-key-xxx", # Clé avec budget base_url="http://litellm.internal:4000" ) response = client.chat.completions.create( model="claude-sonnet", messages=[{"role": "user", "content": "Analyse ce document..."}], max_tokens=4096 ) ``` Toute bibliothèque compatible OpenAI (LangChain, LlamaIndex, CrewAI, AutoGen) fonctionne nativement avec LiteLLM sans modification de code — il suffit de pointer vers l'URL du proxy. ## Retour d'expérience et bonnes pratiques ### Commencer petit, itérer vite Ne déployez pas LiteLLM en production pour toute l'organisation d'un coup. Commencez par une équipe pilote, validez les patterns de budgets et de routage, puis étendez progressivement. ### Définir des budgets réalistes Analysez la consommation actuelle avant de fixer des budgets. Un budget trop serré bloque les équipes et génère de la frustration. Un budget trop large ne protège de rien. Commencez avec des budgets généreux et resserrez progressivement en fonction des données réelles. ### Monitorer les anomalies, pas seulement les totaux Le coût total mensuel est un indicateur retardé. Surveillez plutôt : - Le coût par requête (détecte les agents qui s'emballent) - Le nombre de tokens par session (détecte les contextes qui explosent) - Le ratio input/output tokens (détecte les prompts mal optimisés) - Les pics soudains de consommation (détecte les boucles infinies) ### Implémenter des circuit breakers Au-delà des budgets, implémentez des mécanismes de circuit breaker au niveau applicatif : si un agent dépasse un certain nombre d'itérations ou un certain coût par session, il doit s'arrêter et remonter une alerte plutôt que de continuer à consommer. ## Conclusion L'adoption des agents IA en entreprise est en marche. Mais sans gouvernance adaptée, les coûts peuvent devenir un frein majeur — voire un risque financier. Les outils de FinOps traditionnels ne sont pas conçus pour la granularité et la réactivité qu'exige l'IA générative. LiteLLM en front d'Amazon Bedrock offre une réponse pragmatique à ce défi. Vous conservez la puissance de Bedrock — son catalogue de modèles, son intégration AWS native, ses garanties de confidentialité — tout en ajoutant la couche de contrôle qui manque : budgets par BU et par application, sécurité unifiée, observabilité en temps réel, et routage intelligent. C'est l'approche que je recommande pour la production avec l'IA générative : ne laissez pas vos agents en roue libre. Mettez un gateway devant, définissez des budgets, et gardez le contrôle. La flexibilité de Bedrock combinée au contrôle de LiteLLM, c'est exactement le compromis dont les entreprises ont besoin pour scaler l'IA de manière responsable. --- # AWS European Sovereign Cloud : défis et recommandations > 2026-05-02T00:00:00.000Z | https://sylvain.bruas.fr/blog/2026/05/esc-part2 Tags: souverainete, cloud, securite, architecture, aws Summary: AWS ESC : parité de services, IAM régional, connectivité entre partitions, IaC avec Terraform, Landing Zone Accelerator et recommandations. ![AWS European Sovereign Cloud (partie 2) : défis techniques, opérationnels et recommandations pratiques](/static/2026/04/esc-cover.webp) *Cet article est la seconde partie de notre analyse d'AWS European Sovereign Cloud. Dans la [première partie](/blog/2026/04/esc-part1), nous avons posé les fondations : ce qu'est la souveraineté numérique (et ce qu'elle n'est pas), l'architecture de l'ESC, les garanties offertes par Nitro, la stratégie de chiffrement, les enjeux sectoriels et la question de SecNumCloud.* *Maintenant, passons aux choses concrètes. Quand on ouvre la console ESC pour la première fois, qu'est-ce qui change vraiment ? Quels sont les pièges à éviter et les patterns qui fonctionnent ?* ## Les défis techniques ### Parité de services L'un des défis techniques majeurs de l'ESC est la parité de services avec AWS commercial. Au lancement, seul un sous-ensemble des services AWS est disponible. Cela signifie que les architectures conçues pour AWS commercial ne sont pas nécessairement transposables telles quelles vers l'ESC. Les équipes d'architecture doivent : - Inventorier les services utilisés et vérifier leur disponibilité dans l'ESC - Identifier des alternatives pour les services manquants - Adapter les patterns d'architecture en conséquence Par exemple, si votre architecture repose sur [Amazon OpenSearch Serverless](https://docs.aws.amazon.com/opensearch-service/), ce service n'est pas disponible au lancement de l'ESC. D'autres services comme [Amazon Bedrock](https://docs.aws.amazon.com/bedrock/) sont présents mais avec un catalogue de modèles et de fonctionnalités plus limité que dans la partition commerciale — il est donc essentiel de vérifier la couverture exacte avant de s'engager. ### Gestion des identités et des accès La séparation du plan de contrôle implique que les comptes AWS ESC sont distincts des comptes AWS commerciaux. L'ESC dispose de son propre service [IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html), entièrement séparé de celui de la partition commerciale. IAM dans l'ESC est global au sein de la partition ESC, exactement comme IAM est global au sein de la partition commerciale. Mais les deux IAM sont cloisonnés : aucune identité, aucun rôle, aucune politique ne traverse la frontière entre partitions. Cela a des implications majeures : - **[AWS Organizations](https://docs.aws.amazon.com/organizations/)** : les organisations ESC sont séparées des organisations commerciales. Vous gérez deux hiérarchies de comptes indépendantes. - **IAM séparé** : les rôles, politiques et utilisateurs IAM créés dans la partition commerciale n'existent pas dans l'ESC et vice versa. Les endpoints IAM de l'ESC utilisent le domaine `amazonaws.eu` (par exemple `iam.eusc-de-east-1.amazonaws.eu`). L'ensemble des identités doit être recréé dans l'ESC. - **SSO/Federation** : les intégrations avec les fournisseurs d'identité doivent être reconfigurées. Il est possible de pointer les deux instances [IAM Identity Center](https://docs.aws.amazon.com/singlesignon/) (commerciale et ESC) vers le même IdP d'entreprise (Entra ID, Okta, etc.), mais les permission sets, les assignments de comptes et les groupes doivent être gérés séparément dans chaque partition. - **Cross-partition access** : pas de possibilité d'accès croisé entre comptes ESC et comptes commerciaux. Un rôle dans `arn:aws:iam::123456789012:role/MyRole` ne peut pas assumer un rôle dans `arn:aws-eusc:iam::987654321098:role/MyRole` — les deux partitions ne se voient tout simplement pas. C'est le même cloisonnement qui existe entre AWS commercial et [AWS GovCloud](https://docs.aws.amazon.com/govcloud-us/) ou AWS Chine. ![Gestion des identités et des accès AWS ESC](/static/2026/05/iam-regional-vs-global.webp) ### Réseau et connectivité La séparation réseau entre l'ESC et AWS commercial pose des défis de connectivité : - Pas de [VPC](https://docs.aws.amazon.com/vpc/) peering entre ESC et régions commerciales - Pas de [Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/) partagé - Les connexions [Direct Connect](https://docs.aws.amazon.com/directconnect/) doivent être dédiées - Les architectures multi-régions doivent être repensées ### Liaison réseau entre l'ESC et la partition commerciale La question de la connectivité entre l'ESC et AWS commercial est cruciale pour les entreprises en mode hybride. Puisque les deux partitions sont logiquement et physiquement séparées, il n'existe pas de mécanisme natif de peering interne — pas de VPC peering, pas de Transit Gateway peering, pas de [PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/) entre partitions. Voici les options disponibles, détaillées dans l'article de référence d'AWS : [Connectivity patterns between AWS European Sovereign Cloud and AWS commercial partition](https://builder.aws.com/content/39IQ7P5k9lFISRIcglYzdSbSHJU/connectivity-patterns-between-aws-european-sovereign-cloud-and-aws-commercial-partition). ![Options réseau AWS ESC ](/static/2026/05/connectivite-esc-commercial.webp) #### Option 1 : Connectivité via Internet avec chiffrement TLS natif Si l'application utilise nativement le chiffrement TLS (par exemple, du trafic API sur HTTPS/443), il est possible d'utiliser des [Elastic IP addresses](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html) pour communiquer entre les partitions. C'est le pattern le plus performant et le plus simple à opérer : il ne nécessite pas de maintenir des appliances VPN sur des instances [EC2](https://docs.aws.amazon.com/ec2/) ni de configurer un [Direct Connect Gateway](https://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-gateways.html). En revanche, cette option ne fournit pas de chiffrement au niveau de la couche transport réseau — la responsabilité du chiffrement en transit repose sur l'application. ![Option 1 réseau AWS ESC](/static/2026/05/connectivite-option-1-tls.webp) #### Option 2 : VPN IPSec site-to-site entre partitions (service managé côté ESC) Ce pattern établit des tunnels VPN IPSec directement entre les deux partitions, sans passer par une infrastructure on-premises. Côté ESC, le tunnel est terminé par le service managé [AWS Site-to-Site VPN](https://docs.aws.amazon.com/vpn/latest/s2svpn/), attaché à un Transit Gateway — aucune appliance tierce n'est nécessaire dans la partition souveraine. Côté AWS commercial, une appliance virtuelle tierce (Cisco CSR, Palo Alto, Fortinet, StrongSwan, etc.) fait office de Customer Gateway et termine l'autre extrémité du tunnel. Le débit maximum par tunnel VPN est de 1,25 Gbps ; pour des besoins supérieurs, activez le routage ECMP (Equal-Cost Multi-Path) pour agréger le débit sur plusieurs connexions VPN. Ce pattern est adapté aux applications qui ne supportent pas le chiffrement au niveau applicatif ou qui ne doivent pas être exposées via un Internet Gateway. ![Option 2 réseau AWS ESC](/static/2026/05/connectivite-option-2-vpn.webp) #### Option 3 : Connectivité via Direct Connect et infrastructure on-premises ou fournisseur de services Ce modèle hub-and-spoke route le trafic inter-partition via une infrastructure client connectée par AWS Direct Connect. Deux variantes existent : - **Via un datacenter on-premises** : des connexions Direct Connect séparées relient chaque partition au datacenter, où des équipements réseau (firewalls, routeurs) contrôlent le trafic inter-partition. - **Via un fournisseur de services cloud exchange** (Equinix, Digital Realty, etc.) : pour les organisations sans datacenter, une infrastructure gateway virtuelle hébergée chez le fournisseur assure le même rôle. Le trafic est « hairpinné » via l'infrastructure client, ce qui ajoute de la latence, des coûts de transfert de données sortantes (DTO) et des frais de traitement Transit Gateway. Le Direct Connect Gateway est un construct global qui permet la connectivité vers n'importe quelle région AWS, mais ne propage pas les préfixes BGP entre les Transit Gateways associés. ![Option 3 réseau AWS ESC](/static/2026/05/connectivite-option-3-directconnect.webp) #### Option 4 : Transit VPC avec Transit Gateway Connect Ce pattern utilise un Transit VPC avec des appliances virtuelles tierces redondantes dans différentes zones de disponibilité, connectées au Transit Gateway via des attachments Transit Gateway Connect. Cette approche utilise BGP over GRE (Generic Routing Encapsulation) pour simplifier la connectivité avec le Transit Gateway. À noter que GRE ne fournit pas de chiffrement — si le chiffrement est nécessaire, il faut utiliser un VPN IPSec entre les appliances et le Transit Gateway (comme dans l'option 2). ![Option 4 réseau AWS ESC](/static/2026/05/connectivite-option-4-transit-vpc.webp) #### Option 5 : Pas de liaison directe (air gap logique) Pour les workloads les plus sensibles, la meilleure option peut être de ne pas établir de liaison réseau du tout entre l'ESC et la partition commerciale. Les données sont transférées via des mécanismes asynchrones contrôlés (export/import chiffré, files de messages avec validation), ce qui garantit une séparation maximale. ![Option 5 réseau AWS ESC](/static/2026/05/connectivite-option-5-airgap.webp) #### Backbone AWS et trafic inter-partition L'ESC dispose de son propre backbone séparé de celui de la partition commerciale (similaire à AWS Chine). Cette séparation d'infrastructure renforce le modèle de souveraineté de l'ESC. #### Considérations importantes Quelle que soit l'option choisie, gardez à l'esprit : - La latence sera plus élevée qu'entre deux régions commerciales - Vous devez documenter et justifier chaque flux de données entre les partitions pour des raisons de conformité - Les coûts de transfert de données s'appliquent dans les deux sens ### Observabilité et monitoring Les outils de monitoring centralisés ([Amazon CloudWatch](https://docs.aws.amazon.com/cloudwatch/), [AWS CloudTrail](https://docs.aws.amazon.com/cloudtrail/)) fonctionnent de manière isolée dans l'ESC. Les entreprises qui ont investi dans des dashboards centralisés couvrant plusieurs régions AWS commerciales devront adapter leur approche pour intégrer les métriques de l'ESC. ## Les défis opérationnels ### Le mode hybride : la complexité au quotidien C'est probablement le défi le plus sous-estimé. La plupart des entreprises ne migreront pas 100 % de leurs workloads vers l'ESC. Elles adopteront un mode hybride où certaines charges de travail (les plus sensibles) seront dans l'ESC, tandis que d'autres resteront dans AWS commercial. Cette hybridation crée une complexité opérationnelle considérable : **Gestion de deux environnements distincts** : les équipes doivent maîtriser deux écosystèmes qui, bien que similaires, ont des différences subtiles (services disponibles, versions, limites). **Infrastructure as Code** : les templates Terraform ou [CloudFormation](https://docs.aws.amazon.com/cloudformation/) doivent être adaptés pour gérer les deux environnements. Les modules doivent être conditionnels, les providers configurés différemment, et les pipelines CI/CD dupliqués ou paramétrés. #### Exemple Terraform : déploiement sur la partition commerciale vs l'ESC Pour illustrer concrètement la différence, voici un exemple de déploiement d'une instance EC2 avec un bucket [S3](https://docs.aws.amazon.com/s3/) sur les deux partitions. **Déploiement sur AWS commercial (partition `aws`) :** ```hcl # providers.tf - Partition commerciale terraform { required_providers { aws = { source = "hashicorp/aws" version = "~> 5.0" } } } provider "aws" { region = "eu-west-3" # Paris } # main.tf - Ressources sur la partition commerciale resource "aws_vpc" "main" { cidr_block = "10.0.0.0/16" enable_dns_hostnames = true enable_dns_support = true tags = { Name = "commercial-vpc" Environment = "production" Partition = "aws-commercial" } } resource "aws_subnet" "private" { vpc_id = aws_vpc.main.id cidr_block = "10.0.1.0/24" availability_zone = "eu-west-3a" tags = { Name = "commercial-private-subnet" } } resource "aws_instance" "app_server" { ami = "ami-0a1b2c3d4e5f67890" # Amazon Linux 2023 - eu-west-3 instance_type = "m6i.large" subnet_id = aws_subnet.private.id metadata_options { http_tokens = "required" # IMDSv2 obligatoire http_endpoint = "enabled" } tags = { Name = "app-server-commercial" Environment = "production" } } resource "aws_s3_bucket" "data" { bucket = "mon-entreprise-data-commercial" tags = { Name = "data-bucket-commercial" Partition = "aws-commercial" } } resource "aws_s3_bucket_server_side_encryption_configuration" "data" { bucket = aws_s3_bucket.data.id rule { apply_server_side_encryption_by_default { sse_algorithm = "aws:kms" kms_master_key_id = aws_kms_key.data_key.arn } } } resource "aws_kms_key" "data_key" { description = "Clé de chiffrement des données - Commercial" deletion_window_in_days = 30 enable_key_rotation = true } ``` **Déploiement sur AWS ESC (partition `aws-eusc`) :** ```hcl # providers.tf - Partition ESC terraform { required_providers { aws = { source = "hashicorp/aws" version = "~> 6.0" } } } # Terraform 1.14+ avec le provider AWS 6.x résout nativement # les endpoints ESC — il suffit de spécifier la région. # Pas besoin de configurer les endpoints manuellement. provider "aws" { region = "eusc-de-east-1" # Brandenburg, Allemagne } # Data source pour construire les ARN dynamiquement # Retourne "aws-eusc" dans l'ESC, "aws" dans la partition commerciale data "aws_partition" "current" {} data "aws_caller_identity" "current" {} # main.tf - Ressources sur la partition ESC resource "aws_vpc" "main" { cidr_block = "10.0.0.0/16" enable_dns_hostnames = true enable_dns_support = true tags = { Name = "sovereign-vpc" Environment = "production" Partition = data.aws_partition.current.partition DataClass = "sensible" } } resource "aws_subnet" "private" { vpc_id = aws_vpc.main.id cidr_block = "10.0.1.0/24" availability_zone = "eusc-de-east-1a" tags = { Name = "sovereign-private-subnet" } } resource "aws_instance" "app_server" { ami = "ami-0esc1a2b3c4d5e6f7" # AMI spécifique ESC instance_type = "m6i.large" subnet_id = aws_subnet.private.id metadata_options { http_tokens = "required" http_endpoint = "enabled" } tags = { Name = "app-server-sovereign" Environment = "production" DataClass = "sensible" } } resource "aws_s3_bucket" "data" { bucket = "mon-entreprise-data-sovereign" tags = { Name = "data-bucket-sovereign" Partition = data.aws_partition.current.partition DataClass = "sensible" } } resource "aws_s3_bucket_server_side_encryption_configuration" "data" { bucket = aws_s3_bucket.data.id rule { apply_server_side_encryption_by_default { sse_algorithm = "aws:kms" kms_master_key_id = aws_kms_key.data_key.arn } } } resource "aws_kms_key" "data_key" { description = "Clé de chiffrement des données - Souverain" deletion_window_in_days = 30 enable_key_rotation = true # La clé reste exclusivement dans la partition ESC # Aucune réplication vers la partition commerciale } # Exemple d'ARN dynamique — fonctionne sur toute partition output "kms_key_arn" { value = aws_kms_key.data_key.arn # Produit : arn:aws-eusc:kms:eusc-de-east-1:123456789012:key/... } ``` **Les différences clés à noter :** - **La région** : `eusc-de-east-1` (Brandenburg, Allemagne) au lieu de `eu-west-3`. Les noms de régions ESC suivent le format `eusc-{pays}-{direction}-{numéro}`. - **Le domaine DNS** : l'ESC utilise le domaine `amazonaws.eu` au lieu de `amazonaws.com`. Par exemple : `ec2.eusc-de-east-1.amazonaws.eu`, `s3.eusc-de-east-1.amazonaws.eu`. La console est accessible sur `console.amazonaws-eusc.eu`. - **La partition ARN** : les ARN utilisent `aws-eusc` au lieu de `aws`. Par exemple : `arn:aws-eusc:s3:::mon-bucket` vs `arn:aws:s3:::mon-bucket`. Utilisez `data "aws_partition" "current" {}` dans Terraform pour construire les ARN dynamiquement plutôt que de les hardcoder. - **Les AMI** : les images machine sont spécifiques à l'ESC et ne sont pas partagées avec la partition commerciale. - **Les credentials** : les identifiants IAM de la partition commerciale ne fonctionnent pas sur l'ESC et vice versa. Vous devez gérer deux jeux de credentials séparés. Si vous utilisez un pipeline CI/CD, configurez deux fournisseurs OIDC distincts, chacun pointant vers sa partition respective. - **Terraform** : à partir de Terraform 1.14+ avec le provider AWS 6.x (et OpenTofu 1.11+), les endpoints ESC sont résolus nativement — il suffit de spécifier la région, sans configuration manuelle des endpoints. **Gestion des secrets et du chiffrement** : les clés [KMS](https://docs.aws.amazon.com/kms/) de l'ESC ne sont pas accessibles depuis AWS commercial et vice versa. Les données chiffrées dans un environnement ne peuvent pas être déchiffrées dans l'autre sans mécanismes de re-chiffrement. **Synchronisation des données** : si certaines données doivent être partagées entre les deux environnements (par exemple, des données de référence non sensibles), il faut mettre en place des mécanismes de réplication qui respectent les contraintes de souveraineté. ### Compétences et formation L'ESC introduit de nouvelles contraintes que les équipes doivent intégrer : - Comprendre les différences entre ESC et AWS commercial - Adapter les pratiques DevOps aux contraintes de séparation - Former les équipes aux spécificités de la gouvernance souveraine - Mettre à jour les runbooks et procédures opérationnelles ### Coûts et optimisation Le mode hybride a un impact sur les coûts : - **Duplication d'infrastructure** : certains composants (monitoring, sécurité, réseau) doivent être déployés dans les deux environnements. - **Licences** : certains outils tiers peuvent nécessiter des licences séparées pour l'ESC. - **Personnel** : la complexité accrue peut nécessiter des ressources supplémentaires. - **Prix de souveraineté** : les prix dans l'ESC sont estimés à 10-15 % supérieurs à ceux de la région Francfort (eu-central-1) pour des services comparables, en raison des contraintes opérationnelles supplémentaires liées à la souveraineté. ### Facturation et séparation financière La facturation de l'ESC est entièrement séparée de celle de la partition commerciale. Voici les points clés : - **Entité contractuelle distincte** : la facturation ESC est gérée par AWS EMEA SARL (Luxembourg), et non par AWS Inc. (Seattle) comme pour la partition commerciale. Cela a des implications pour les équipes procurement et finance. - **Facturation en euros** : contrairement à la partition commerciale (facturée en USD), l'ESC est facturé en euros. - **Savings Plans et Reserved Instances non transférables** : les Enterprise Discount Programs (EDP), les Savings Plans et les Reserved Instances achetés dans la partition commerciale ne s'appliquent pas à l'ESC. Vous devez négocier et acheter des engagements séparés pour chaque partition. - **Comptes et Organizations séparés** : les comptes ESC ayant leur propre Organization, les tags d'allocation de coûts, les budgets et les rapports Cost and Usage Reports sont indépendants. Si votre équipe FinOps suit les dépenses cloud par account ID, elle devra adapter ses processus pour intégrer les deux partitions. ### Gouvernance et conformité La gouvernance d'un environnement hybride nécessite : - Des politiques claires de classification des données (quelles données vont dans l'ESC, lesquelles restent dans AWS commercial) - Des processus de validation pour tout nouveau déploiement - Un suivi continu de la conformité dans les deux environnements - Des audits réguliers pour vérifier que les données sensibles ne « fuient » pas vers l'environnement commercial ## Recommandations pratiques ### Évaluer son besoin réel de souveraineté Avant de se lancer dans une migration vers l'ESC, il est essentiel de : 1. **Classifier ses données** : toutes les données n'ont pas le même niveau de sensibilité. Seules les données véritablement sensibles (données personnelles critiques, secrets industriels, données régulées) justifient le surcoût et la complexité de l'ESC. 2. **Identifier ses obligations réglementaires** : quelles réglementations s'appliquent réellement à votre organisation ? Êtes-vous soumis à la doctrine « Cloud au centre » ? À DORA ? À des exigences sectorielles spécifiques ? 3. **Évaluer le risque géopolitique** : quelle est la probabilité réelle que vos données soient impactées par des mécanismes extraterritoriaux ? Ce risque justifie-t-il la complexité supplémentaire ? ### Adopter une approche progressive Plutôt qu'une migration « big bang », privilégiez une approche incrémentale : 1. Commencez par un workload pilote bien délimité 2. Validez les patterns d'architecture et les processus opérationnels 3. Documentez les différences et les pièges rencontrés 4. Étendez progressivement à d'autres workloads ![Migration vers ESC](/static/2026/05/approche-progressive-migration.webp) ### Investir dans l'automatisation L'automatisation est la clé pour gérer la complexité du mode hybride : - Utilisez des abstractions dans votre Infrastructure as Code pour gérer les deux environnements - Automatisez les contrôles de conformité (données au bon endroit, accès correctement configurés) - Mettez en place des pipelines de déploiement qui gèrent nativement les deux cibles - Automatisez la détection de drift entre les environnements ### Anticiper l'évolution du paysage Le domaine de la souveraineté cloud évolue rapidement : - Le schéma EUCS va probablement redéfinir les standards au niveau européen - AWS va continuer à enrichir le catalogue de services de l'ESC - Les réglementations nationales et européennes vont continuer à évoluer - De nouvelles offres souveraines vont émerger Construisez vos architectures de manière à pouvoir évoluer avec ce paysage changeant. ## Conclusion AWS European Sovereign Cloud représente une avancée significative dans la réponse aux enjeux de souveraineté numérique européenne. En proposant une infrastructure physiquement et logiquement séparée, opérée exclusivement par du personnel européen, AWS adresse une grande partie des préoccupations liées à la souveraineté des données. Cependant, il est crucial de ne pas confondre souveraineté et cybersécurité. L'ESC répond à des enjeux de gouvernance et de contrôle, pas à des problématiques de protection contre les cybermenaces (même si les deux se complètent). La question de SecNumCloud reste ouverte : pour les organisations soumises à la doctrine française, elle reste incontournable. Pour les autres, l'ESC offre un compromis pragmatique entre souveraineté et accès à l'écosystème AWS. Le véritable défi réside dans l'opérationnel : gérer un mode hybride entre AWS commercial et l'ESC demande une maturité organisationnelle, des compétences spécifiques et des investissements en automatisation. Les entreprises qui réussiront cette transition seront celles qui auront pris le temps de bien classifier leurs données, d'adopter une approche progressive et d'investir dans l'outillage nécessaire. La souveraineté numérique n'est pas une destination, c'est un chemin. Et ce chemin passe par des choix éclairés, une compréhension fine des enjeux, et une exécution rigoureuse. --- # AWS European Sovereign Cloud : architecture et enjeux > 2026-04-23T11:00:00.000Z | https://sylvain.bruas.fr/blog/2026/04/esc-part1 Tags: souverainete, cloud, securite, architecture, aws Summary: Souveraineté vs cybersécurité, architecture d'AWS European Sovereign Cloud, rôle de Nitro, chiffrement et enjeux SecNumCloud. ![AWS European Sovereign Cloud (partie 1) : souveraineté numérique, architecture et enjeux](/static/2026/04/esc-cover.webp) La souveraineté numérique est devenue un sujet central dans les stratégies IT des entreprises européennes. Entre les réglementations de plus en plus strictes, les tensions géopolitiques et la dépendance croissante aux hyperscalers américains, les organisations doivent repenser leur approche du cloud. C'est dans ce contexte qu'Amazon Web Services a annoncé le lancement d'AWS European Sovereign Cloud (ESC), une infrastructure cloud dédiée, physiquement et logiquement séparée des régions AWS commerciales existantes. Mais qu'est-ce que la souveraineté numérique exactement ? En quoi diffère-t-elle de la cybersécurité ? Quels sont les véritables enjeux pour les entreprises qui envisagent de migrer vers cette offre ? Et surtout, comment naviguer dans la complexité d'un mode hybride entre AWS commercial et l'ESC ? Cette série de deux articles propose une analyse approfondie de ces questions. Dans cette première partie, nous abordons les fondamentaux : définition de la souveraineté, architecture de l'ESC, rôle de Nitro, stratégie de chiffrement, enjeux sectoriels et question de SecNumCloud. La [seconde partie](/blog/2026/05/esc-part2) couvre les défis techniques, opérationnels et les recommandations pratiques. ## Souveraineté numérique : de quoi parle-t-on ? ### Définition et périmètre La souveraineté numérique désigne la capacité d'un État, d'une organisation ou d'un individu à exercer un contrôle sur ses données, ses infrastructures numériques et ses processus de décision dans l'espace numérique. Elle englobe plusieurs dimensions : - **La souveraineté des données** : savoir où sont stockées les données, qui y a accès, et sous quelle juridiction elles tombent. - **La souveraineté opérationnelle** : garantir que l'exploitation des infrastructures est réalisée par du personnel soumis au droit européen, sans possibilité d'ingérence étrangère. - **La souveraineté technologique** : disposer de la maîtrise des technologies utilisées, ou a minima d'une indépendance suffisante pour ne pas être soumis à des décisions unilatérales d'un fournisseur étranger. ### Ne pas confondre souveraineté et cybersécurité C'est probablement la confusion la plus répandue dans les discussions autour du cloud souverain. La cybersécurité et la souveraineté numérique sont deux concepts distincts, bien qu'ils se recoupent partiellement. La **cybersécurité** concerne la protection des systèmes d'information contre les menaces : attaques, intrusions, fuites de données, ransomwares, etc. Elle répond à la question « comment protéger mes données contre les attaquants ? ». La **souveraineté numérique** concerne le contrôle et la gouvernance des données et des infrastructures. Elle répond à la question « qui a le pouvoir de décision sur mes données et mes systèmes ? ». Un cloud peut être parfaitement sécurisé au sens cybersécurité (chiffrement, contrôle d'accès, détection d'intrusion) tout en posant des problèmes de souveraineté si, par exemple, un gouvernement étranger peut légalement contraindre le fournisseur à divulguer des données via des mécanismes comme le CLOUD Act américain. Inversement, un cloud souverain mal configuré peut présenter des failles de sécurité béantes. La souveraineté ne garantit pas la sécurité, et la sécurité ne garantit pas la souveraineté. Les deux sont nécessaires, mais aucun ne suffit seul. ![Souveraineté vs cybersécurité](/static/2026/04/souverainete-vs-cybersecurite.webp) ### Le contexte réglementaire européen Plusieurs textes législatifs européens encadrent désormais la gestion des données et poussent vers plus de souveraineté : - **RGPD (2018)** : protection des données personnelles, avec des restrictions sur les transferts hors UE. - **NIS2 (2024)** : renforcement des obligations de cybersécurité pour les entités essentielles et importantes. - **DORA (2025)** : résilience opérationnelle numérique pour le secteur financier. - **Data Act (2025)** : portabilité des données et conditions d'accès. - **EUCS (en cours)** : schéma européen de certification cloud, qui devrait définir des niveaux d'assurance pour les services cloud. C'est dans ce paysage réglementaire dense que s'inscrit l'offre AWS ESC. ![réglementations Européenne](/static/2026/04/contexte-reglementaire.webp) ## AWS European Sovereign Cloud : architecture et principes ### Qu'est-ce que l'ESC ? AWS European Sovereign Cloud est une infrastructure cloud complètement séparée des régions AWS commerciales. Contrairement à une simple région européenne d'AWS (comme eu-west-1 à Dublin ou eu-central-1 à Francfort), l'ESC repose sur : - **Une séparation physique** : des datacenters dédiés, situés exclusivement sur le territoire de l'Union européenne. - **Une séparation logique** : un plan de contrôle indépendant, des systèmes de facturation séparés, et aucune interconnexion avec l'infrastructure AWS globale. - **Un personnel exclusivement européen** : les opérations sont réalisées par des employés résidant dans l'UE et soumis au droit européen. - **Une gouvernance européenne** : les décisions opérationnelles sont prises au sein de l'UE, sans possibilité d'intervention depuis les États-Unis. ![ESC vs AWS Commercial](/static/2026/04/architecture-esc-vs-commercial.webp) ### Les services disponibles L'ESC propose progressivement les services AWS les plus utilisés, adaptés aux exigences de souveraineté. On y retrouve notamment [Amazon Elastic Compute Cloud (EC2)](https://docs.aws.amazon.com/ec2/), [Amazon Simple Storage Service (S3)](https://docs.aws.amazon.com/s3/), [Amazon Relational Database Service (RDS)](https://docs.aws.amazon.com/rds/), [AWS Lambda](https://docs.aws.amazon.com/lambda/), [Amazon Virtual Private Cloud (VPC)](https://docs.aws.amazon.com/vpc/), et les services de sécurité comme [AWS Key Management Service (KMS)](https://docs.aws.amazon.com/kms/) avec des clés gérées exclusivement dans l'ESC. Cependant, tous les services AWS ne sont pas disponibles dans l'ESC. C'est l'un des défis majeurs que nous aborderons dans la [seconde partie](/blog/2026/05/esc-part2). Pour suivre l'évolution des services disponibles et planifier vos architectures en fonction des capacités actuelles et à venir, AWS met à disposition un outil interactif : [AWS Builder - Capabilities](https://builder.aws.com/build/capabilities). Cet outil permet de visualiser les services disponibles par région et par partition, y compris l'ESC. Il est particulièrement utile pour les architectes qui doivent valider la faisabilité d'un déploiement sur l'ESC avant de s'engager dans une migration. Vous pouvez y filtrer par catégorie de service (compute, storage, database, analytics, etc.) et comparer la couverture entre la partition commerciale et la partition souveraine. ### AWS Nitro System : la fondation sécuritaire de l'ESC Un élément fondamental de l'architecture de sécurité d'AWS — et donc de l'ESC — est le système AWS Nitro. Comprendre Nitro est essentiel pour appréhender les garanties de sécurité offertes par l'infrastructure souveraine. #### Qu'est-ce que Nitro ? AWS Nitro System est l'architecture matérielle et logicielle sous-jacente à toutes les instances EC2 modernes. Il se compose de trois éléments principaux : - **Les cartes Nitro** : des composants matériels dédiés qui gèrent le réseau, le stockage ([Amazon Elastic Block Store (EBS)](https://docs.aws.amazon.com/ebs/)) et le monitoring, en les déchargeant complètement de l'hyperviseur. - **Le Nitro Security Chip** : une puce dédiée qui contrôle l'accès au matériel serveur et fournit une racine de confiance matérielle (hardware root of trust). - **Le Nitro Hypervisor** : un hyperviseur minimaliste et durci, dont la surface d'attaque est considérablement réduite par rapport aux hyperviseurs traditionnels. ![AWS Nitro](/static/2026/04/nitro-system.webp) #### Ce que Nitro apporte à la souveraineté Dans le contexte de l'ESC, Nitro offre des garanties de sécurité qui renforcent la posture de souveraineté : **Isolation cryptographique** : chaque instance EC2 est isolée au niveau matériel. Même un employé AWS ayant un accès physique au serveur ne peut pas accéder à la mémoire ou au stockage d'une instance en cours d'exécution. Le Nitro Security Chip empêche physiquement toute lecture de la mémoire volatile. **Pas d'accès opérateur** : contrairement aux architectures traditionnelles où un administrateur système peut potentiellement accéder aux données des machines virtuelles, Nitro élimine cette possibilité par conception. Il n'existe aucun mécanisme — ni SSH, ni console de debug, ni port de maintenance — permettant à un opérateur AWS d'accéder au contenu d'une instance client. **Attestation matérielle** : [Nitro Enclaves](https://aws.amazon.com/fr/ec2/nitro/nitro-enclaves/) permet d'exécuter du code dans un environnement d'exécution de confiance (TEE - Trusted Execution Environment) avec une attestation cryptographique. Cela garantit que le code exécuté n'a pas été altéré et que les données traitées restent confidentielles, même vis-à-vis de l'opérateur de l'infrastructure. **Intégrité du firmware** : le Nitro Security Chip vérifie l'intégrité du firmware à chaque démarrage. Toute modification non autorisée du firmware est détectée et empêche le démarrage du serveur. #### Une architecture reconnue dans la littérature académique Il est intéressant de noter que l'architecture Nitro n'est pas simplement un produit marketing. Elle est citée et étudiée dans des ouvrages de référence sur l'architecture des processeurs et la virtualisation matérielle. Le concept de déport des fonctions d'I/O vers des composants matériels dédiés (offloading), la séparation stricte entre le plan de données et le plan de contrôle au niveau silicium, et l'utilisation d'une racine de confiance matérielle sont des patterns architecturaux documentés dans la littérature sur les systèmes sur puce (SoC) et les architectures de sécurité matérielle. Des ouvrages comme *Computer Architecture: A Quantitative Approach* (Hennessy & Patterson) abordent les principes fondamentaux sur lesquels repose Nitro : la spécialisation matérielle, les accélérateurs dédiés et l'isolation par le matériel. L'approche de Nitro — qui consiste à retirer l'hyperviseur du chemin critique des données et à confier les opérations sensibles à des puces dédiées — s'inscrit dans une tendance plus large de l'industrie vers les SmartNICs et les DPU (Data Processing Units), documentée dans les publications IEEE et ACM sur les architectures de datacenter modernes. Cette reconnaissance académique renforce la crédibilité des garanties de sécurité offertes par Nitro : il ne s'agit pas d'une simple promesse contractuelle, mais d'une impossibilité technique vérifiable et documentée. #### Nitro et la réponse au CLOUD Act L'un des arguments les plus puissants de Nitro dans le contexte de la souveraineté est le suivant : même si, théoriquement, une autorité étrangère obtenait une injonction légale contre AWS, l'architecture Nitro rend techniquement impossible l'accès aux données en cours de traitement sur les instances. AWS ne peut pas fournir ce à quoi il n'a pas accès. Combiné à un chiffrement côté client avec des clés gérées par le client (Customer Managed Keys dans KMS ESC), cela crée une protection technique qui complète la protection juridique offerte par la séparation de l'ESC. ### KMS, chiffrement au repos et souveraineté : faut-il des CMK pour être souverain ? Le chiffrement au repos est souvent présenté comme la pierre angulaire de la protection des données dans le cloud. Mais dans le contexte de la souveraineté, la question n'est pas simplement « mes données sont-elles chiffrées ? » mais plutôt « qui contrôle les clés de chiffrement ? ». #### Les options de chiffrement sur AWS AWS propose plusieurs niveaux de chiffrement au repos : - **SSE-S3 (Server-Side Encryption with S3 Managed Keys)** : AWS gère entièrement les clés. Le chiffrement est transparent pour l'utilisateur. C'est le niveau par défaut depuis janvier 2023. - **SSE-KMS avec clé gérée par AWS (aws/s3)** : AWS KMS gère la clé, mais vous bénéficiez d'un audit via [CloudTrail](https://docs.aws.amazon.com/cloudtrail/) et de politiques de contrôle d'accès. - **SSE-KMS avec CMK (Customer Managed Key)** : vous créez et contrôlez la clé dans KMS. Vous définissez qui peut l'utiliser, vous pouvez la désactiver ou la supprimer, et vous contrôlez sa rotation. - **SSE-C (Server-Side Encryption with Customer-Provided Keys)** : vous fournissez la clé à chaque requête via les headers HTTPS. AWS l'utilise pour chiffrer/déchiffrer en mémoire puis la supprime immédiatement — elle n'est jamais stockée côté AWS. Cette option est pleinement compatible avec l'ESC puisqu'elle repose uniquement sur le protocole S3 standard, sans dépendance à un service de gestion de clés spécifique à une partition. - **Chiffrement côté client (Client-Side Encryption)** : vous chiffrez les données dans votre application avant de les envoyer à AWS. AWS ne voit jamais les données en clair et ne manipule aucune clé. C'est l'option la plus agnostique : elle fonctionne sur toute partition (commerciale, ESC, GovCloud) puisque le chiffrement est entièrement décorrélé de l'infrastructure AWS. C'est aussi l'option qui offre le niveau de souveraineté le plus élevé — même avec un accès physique aux disques ou aux HSM, les données restent illisibles sans vos clés. ![Chiffrement](/static/2026/04/strategie-chiffrement.webp) #### Doit-on avoir des CMK pour être souverain ? C'est une question qui revient systématiquement dans les discussions sur la souveraineté, et la réponse mérite d'être nuancée. **L'argument en faveur des CMK** : avec une Customer Managed Key, vous avez le contrôle total sur le cycle de vie de la clé. Vous pouvez la révoquer à tout moment, rendant les données illisibles. C'est un mécanisme de « kill switch » qui vous donne un pouvoir concret sur vos données, indépendamment du fournisseur cloud. **Mais les CMK ne suffisent pas à garantir la souveraineté** : une CMK dans KMS reste gérée par le service KMS d'AWS. Même si vous contrôlez la politique d'accès, c'est AWS qui opère le HSM (Hardware Security Module) sous-jacent. Dans la partition commerciale, un employé AWS aux États-Unis pourrait théoriquement avoir accès au plan de contrôle de KMS. **Dans l'ESC, la donne change** : les HSM de KMS dans l'ESC sont opérés exclusivement par du personnel européen, dans des datacenters européens, avec un plan de contrôle séparé. Une CMK dans KMS ESC offre donc un niveau de souveraineté significativement supérieur à une CMK dans KMS commercial. #### Quand les CMK sont-elles indispensables ? Les CMK sont recommandées (voire obligatoires selon les contextes) dans les cas suivants : - **Données régulées** : si votre régulateur exige que vous démontriez un contrôle sur les clés de chiffrement, les CMK sont nécessaires. - **Exigence de révocabilité** : si vous devez pouvoir rendre des données illisibles rapidement (en cas de fin de contrat, de litige, ou de compromission), les CMK vous donnent ce pouvoir. - **Audit et traçabilité** : les CMK dans KMS génèrent des événements CloudTrail pour chaque utilisation, ce qui permet un audit complet de qui accède aux données et quand. - **Séparation des responsabilités** : dans une organisation où l'équipe sécurité doit contrôler les clés indépendamment de l'équipe applicative, les CMK permettent cette séparation via les key policies. #### Quand les CMK ne sont pas nécessaires ? Pour des données non sensibles ou des cas d'usage où la souveraineté n'est pas un enjeu (données publiques, caches, données temporaires), le chiffrement par défaut SSE-S3 ou SSE-KMS avec clé AWS est suffisant. Multiplier les CMK sans raison augmente la complexité opérationnelle (gestion de la rotation, risque de suppression accidentelle, coûts KMS) sans apporter de bénéfice réel. #### La stratégie recommandée Une approche pragmatique consiste à : 1. **Classifier les données** par niveau de sensibilité 2. **Appliquer des CMK** uniquement aux données sensibles et régulées 3. **Utiliser le chiffrement par défaut** pour les données non sensibles 4. **Envisager le chiffrement côté client** pour les données les plus critiques (secrets industriels, données de santé nominatives) — dans ce cas, même AWS avec un accès au HSM ne pourrait pas déchiffrer les données ## Les enjeux de la souveraineté pour les entreprises ### Enjeux stratégiques Pour les entreprises européennes, la souveraineté numérique n'est pas qu'une question de conformité réglementaire. C'est un enjeu stratégique à plusieurs niveaux : - **Continuité d'activité** : en cas de sanctions internationales ou de tensions géopolitiques, une entreprise dépendante d'un cloud américain pourrait se voir couper l'accès à ses propres données. - **Confiance des clients** : dans des secteurs comme la santé, la finance ou le secteur public, la localisation et le contrôle des données sont des critères de choix déterminants. - **Propriété intellectuelle** : les données de R&D, les algorithmes propriétaires et les secrets industriels nécessitent un niveau de protection qui va au-delà de la simple cybersécurité. - **Indépendance décisionnelle** : ne pas être soumis aux conditions générales d'utilisation d'un fournisseur qui peut modifier unilatéralement ses termes de service. ### Enjeux sectoriels Certains secteurs sont particulièrement concernés par la souveraineté : - **Secteur public et défense** : obligation légale de traiter certaines données sur le territoire national, sous contrôle d'entités habilitées. - **Santé** : les données de santé sont soumises à des réglementations spécifiques (hébergement de données de santé en France, par exemple). - **Finance** : DORA impose des exigences strictes sur la résilience et le contrôle des prestataires cloud. - **Énergie et infrastructures critiques** : NIS2 renforce les obligations pour les opérateurs d'importance vitale. ## Le défi législatif : SecNumCloud, nécessité ou superflu ? ### Qu'est-ce que SecNumCloud ? SecNumCloud est une qualification délivrée par l'ANSSI (Agence Nationale de la Sécurité des Systèmes d'Information) en France. Elle atteste qu'un prestataire de services cloud respecte un ensemble d'exigences de sécurité et de souveraineté définies par le référentiel de l'ANSSI. La version 3.2 du référentiel, publiée en 2022, a introduit des critères de souveraineté stricts : le prestataire doit être une entité européenne, détenue majoritairement par des capitaux européens, et ne doit pas être soumis à des législations extraterritoriales (comme le CLOUD Act). ### SecNumCloud est-il nécessaire ? La réponse dépend fortement du contexte : **Pour les administrations françaises** : la doctrine « Cloud au centre » de l'État français impose l'utilisation de clouds qualifiés SecNumCloud pour les données sensibles. C'est donc une obligation réglementaire dans ce contexte. **Pour les entreprises privées françaises** : SecNumCloud n'est pas une obligation légale générale. Cependant, certains secteurs régulés (santé, finance) peuvent avoir des exigences qui convergent vers ce type de qualification. **Pour les entreprises européennes hors France** : SecNumCloud est une qualification purement française. Elle n'a pas de valeur juridique en Allemagne, aux Pays-Bas ou en Italie. Chaque pays peut avoir ses propres exigences ou se référer au futur schéma EUCS. ### SecNumCloud vs EUCS : le débat européen Le schéma européen de certification cloud (EUCS) est en cours d'élaboration au niveau de l'ENISA. Il devrait définir trois niveaux d'assurance : basique, substantiel et élevé. Le débat fait rage sur le niveau « élevé » : doit-il inclure des critères de souveraineté (immunité aux lois extraterritoriales) comme le fait SecNumCloud 3.2, ou doit-il se limiter à des critères techniques de sécurité ? La France pousse pour inclure des critères de souveraineté au niveau élevé, tandis que d'autres pays européens (notamment les Pays-Bas et les pays nordiques) considèrent que cela exclurait de facto les hyperscalers américains et limiterait le choix des entreprises. ### Position d'AWS ESC par rapport à SecNumCloud AWS ESC ne vise pas la qualification SecNumCloud dans sa forme actuelle. En effet, SecNumCloud 3.2 exige que le prestataire soit détenu majoritairement par des capitaux européens, ce qui exclut structurellement AWS, même avec l'ESC. Cependant, l'ESC répond à de nombreuses exigences de souveraineté : - Données stockées exclusivement dans l'UE - Personnel européen - Séparation du plan de contrôle - Pas d'accès depuis l'extérieur de l'UE La question est donc : SecNumCloud est-il un prérequis absolu, ou l'ESC offre-t-il un niveau de souveraineté suffisant pour la majorité des cas d'usage ? Pour les entreprises qui ne sont pas soumises à la doctrine « Cloud au centre », l'ESC peut constituer une réponse pragmatique aux enjeux de souveraineté, sans les contraintes d'un écosystème SecNumCloud encore limité en termes de services disponibles. --- Comprendre les enjeux de souveraineté, l'architecture de l'ESC et le cadre législatif est un prérequis. Mais la vraie complexité se révèle quand on passe à l'implémentation : comment gérer deux partitions au quotidien ? Quels sont les pièges techniques ? Comment adapter son Infrastructure as Code ? *C'est ce que nous abordons dans la [seconde partie](/blog/2026/05/esc-part2) : parité de services, IAM régional, connectivité réseau entre partitions, Terraform multi-partition, Landing Zone Accelerator, facturation séparée, et recommandations pratiques pour réussir votre adoption de l'ESC.* --- # AWS Transform Custom : effacer votre dette technique > 2026-02-20T11:00:00.000Z | https://sylvain.bruas.fr/blog/2026/02/aws-transform-custom Tags: AWS Transform Custom, IA Agentique, kiro, modernisation Summary: AWS Transform Custom modernise vos projets par IA agentique. REX : migration de 5 projets Gatsby vers Next.js 15, audit et transformation à l'échelle. ## La Dette Technique : Un Fardeau Quotidien On se fait vite submerger par la dette technique. Dès que l'on a plus d'un projet à gérer, il faut partager son temps et donc faire des choix. C'est ici que commence la dette technique. Elle peut aussi naître du manque de temps, ou encore de choix qui repoussent certaines fonctions semblant moins essentielles comme la documentation ou les tests. Et chaque jour elle se creuse avec les nouvelles mises à jour et frameworks qui sortent ou qui ne sont plus maintenus. Dans mon cas, j'avais plusieurs projets TypeScript en production sur Gatsby + Contentlayer 2, déployés en statique sur [Amazon Simple Storage Service (S3)](https://docs.aws.amazon.com/s3/) avec [Amazon CloudFront](https://docs.aws.amazon.com/cloudfront/). Le problème ? **Contentlayer 2 n'est plus maintenu**, créant des failles de sécurité et bloquant les mises à jour. Chaque jour qui passe, la dette technique s'accumule. Nous allons voir ici comment l'IA et plus particulièrement **AWS Transform Custom** peut nous aider à faire fondre cette dette comme neige au soleil, en migrant vers Next.js 15 avec toutes les bonnes pratiques modernes. ## AWS Transform Custom : La Gomme Magique de la Dette Technique ### Qu'est-ce qu'AWS Transform Custom en quelques mots ? AWS Transform Custom est un service lancé en décembre 2025 qui utilise **l'IA agentique** pour effectuer des modernisations à grande échelle de logiciels, code, bibliothèques et frameworks. Contrairement aux outils de refactoring traditionnels, il gère des scénarios divers : - Mises à niveau de versions de langages - Migrations d'API et de services - Mises à niveau et migrations de frameworks - Refactoring de code - Transformations spécifiques à l'organisation **La vraie magie** : l'agent apprend en continu de chaque exécution et des retours des développeurs, offrant des transformations de meilleure qualité et reproductibles sans nécessiter d'expertise en automatisation. ### Les Avantages Concrets d'AWS Transform Custom #### 1. Gain de Temps La modernisation ou transformation de code demande du temps, que ce soit pour l'implémentation ou pour les tests. Bien que des guides existent pour accélérer certaines migrations, il faut les implémenter avec nos normes de codage, et les valider pour que tous les cas soient correctement gérés. L'IA agentique peut ici apporter une grande valeur. En s'inspirant des autres fichiers de votre projet et des normes que vous partagez avec vos agents (steering documents), les agents vont produire du code beaucoup plus vite qu'un développeur. #### 2. Patterns de Transformation intégrés AWS Transform Custom supporte 10 patterns de transformation avec différents niveaux de complexité : | Pattern | Complexité | Exemples | |---------|-----------|----------| | **Framework Migrations** | Haute | Angular→React, Redux→Zustand, **Gatsby→Next.js** | | **Framework Upgrades** | Moyenne | Spring Boot 2→3, React 17→18, **Next.js 13→15** | | **API Migrations** | Moyenne | AWS SDK v1→v2, JUnit 4→5, javax→jakarta | | **Language Version Upgrades** | Faible-Moyenne | Java 8→17, Python 3.9→3.13, **Node.js 12→22** | | **Code Refactoring** | Faible-Moyenne | Print→Logging, string concat→f-strings | Mon cas d'usage : **Framework Migration (Gatsby→Next.js 15)** - Complexité Haute #### 3. Apprentissage Continu Une des fonctionnalités phares d'AWS Transform Custom : **l'agent apprend de chaque exécution**. Le système capture automatiquement : - Les trajectoires d'exécution - Les retours des développeurs - Les corrections de code - Les résultats des builds de validation Ces informations sont transformées en **Knowledge Items** (KI) qui améliorent les transformations futures. Plus vous l'utilisez, meilleur il devient. Vous allez gagner du temps en n'ayant pas besoin de reformuler vos prompts pour gérer tous les cas. ## Notre cas d'usage : cinq Projets à Transformer en Next.js 15 ### Contexte : Un Portefeuille Hétérogène en Souffrance J'avais cinq projets non maintenus : 1. Une démo avec Gatsby pour un ancien article 2. Un site vitrine « bruas.fr » 3. Mon CV en ligne cv.bruas.fr multilingue (seul site avec cette fonction) 4. L'ancienne version de ce site sylvain.bruas.fr, que j'ai déjà transformé avant la sortie d'AWS Transform Custom, et qui m'a permis de définir la cible 5. Une page statique qui me sert de carte de visite virtuelle (HTML pur). Ce projet est là pour voir les limites de l'outil dans un environnement très hétérogène **Stack actuelle** : - Framework : Gatsby (obsolète pour mes besoins) - Content : Contentlayer 2 (⚠️ **non maintenu** - failles de sécurité) - Articles : Markdown avec frontmatter - Déploiement : Amazon S3 + CloudFront (statique) - IaC : Terraform **Stack cible** : - Framework : **Next.js 15** (dernière version) - Content : **@next/mdx** ou **content-collections** (alternatives natives) - Architecture : **App Router** avec **Server Components** - Build : **Turbopack** (nouveau bundler ultra-rapide) - À jour par rapport aux packages et CVE - Disparition totale de Gatsby - Si on a un site multilingue, on fait un projet par langue pour faciliter le SEO **Le problème Contentlayer 2** : Ce projet n'est plus maintenu depuis 2023, créant des vulnérabilités de sécurité et empêchant les mises à jour de dépendances. Les alternatives natives de Next.js 15 (@next/mdx, content-collections) sont plus performantes et maintenues. **Des projets clones** : Des projets qui sont partis des mêmes sources, mais qui ont évolué avec des modules différents (I18N), et pas forcément avec les bonnes pratiques. Les faire converger de nouveau vers une plateforme commune demande un effort important. ### Phase 1 : Commencer par un Audit Complet Avant toute transformation, j'ai utilisé **Kiro** (un assistant IA pour développeurs) pour réaliser un audit approfondi de mes projets. Je lui ai demandé d'effectuer un audit complet de mes projets en utilisant des sous-agents pour aller plus vite : **Prompt utilisé** : ``` Pour chacun des projets, fais-moi un audit sécurité, bonnes pratiques, couverture des tests, etc. Mets le résultat dans un fichier .md Fais-moi un récapitulatif global sous forme de divers tableaux dans projects-data.md Utilise des sous-agents pour aller plus vite ``` Kiro a analysé automatiquement : - Les dépendances obsolètes avec `npm audit` - Les vulnérabilités de sécurité - La couverture de tests existante - La qualité du code avec ESLint - Les bonnes pratiques TypeScript 📊 Tableau de Synthèse Globale | Projet | Type | Score Global | Tests | Sécurité | Infrastructure | |--------|------|--------------|-------|----------|----------------| | **bruas.fr** | Blog Gatsby | 6/10 | 0% | ⚠️ Moyen | ✅ Bon | | **cv** | CV Gatsby i18n | 5/10 | 0% | 🔴 Critique | ✅ Bon | | **demo** | Blog Gatsby | 6/10 | ~5% | ⚠️ Moyen | ✅ Bon | | **sylvain.bruas.fr** | Blog Gatsby | 6.5/10 | ~10% | ⚠️ Moyen | ✅ Bon | | **vcard-pro** | vCard statique | 6/10 | 0% | ⚠️ Moyen | ⚠️ Moyen | ⚙️ Tableau des Problèmes d'Infrastructure | Composant | bruas.fr | cv | demo | sylvain.bruas.fr | vcard-pro | |-----------|----------|-----|------|------------------|-----------| | **Backend Terraform** | ❌ Local | N/A | ❌ Local | N/A | ❌ Local | | **Variables Terraform** | ❌ Hardcodées | N/A | ❌ Hardcodées | N/A | ❌ Hardcodées | | **CI/CD configuré** | ❌ | ❌ | ❌ | ❌ | ⚠️ Non fonctionnel | | **Monitoring** | ❌ | ❌ | ❌ | ❌ | ❌ | | **Alertes** | ❌ | ❌ | ❌ | ❌ | ❌ | | **Backup/Versioning** | ✅ | N/A | ✅ | N/A | ❌ | **Points critiques identifiés** : - ⚠️ Contentlayer 2 : Vulnérabilités CVE non patchées - ⚠️ Gatsby : Version 4.x, alors que v5 est sortie (mais migration complexe) - ⚠️ Node.js : Version 16 (EOL), besoin de migrer vers 22 LTS Cette phase d'audit est **cruciale**. AWS Transform Custom fonctionne mieux quand il comprend l'état initial de votre codebase. Kiro m'a aidé à préparer ce travail en documentant précisément : - Architecture technique - Flux de données - Composants - Gestion du thème - Système de routing - SEO et métadonnées - Infrastructure - Performance - Sécurité C'est un premier point de dette technique de réglé : l'IA générative permet de créer une base de documentation solide qu'il ne reste plus qu'à parcourir et ajuster. **Conseil** : Documentez tout ce que vous trouvez. AWS Transform Custom utilisera cette documentation comme **References** pour mieux comprendre votre contexte. ### Phase 2 : Ajouter des Tests avec l'IA #### L'IA au Service de la Qualité Avant de lancer la transformation, j'ai utilisé Kiro pour générer les tests manquants. **Pourquoi ?** Parce qu'AWS Transform Custom utilise les tests pour valider ses transformations via le **Build and Validation Command**. L'objectif est d'avoir une couverture intéressante d'environ 80 %, avec des tests unitaires, d'intégration et end-to-end qui apportent de la valeur. On vise les cas particuliers et les fonctionnalités critiques de l'application (SEO, gestion des images, build, rendu HTML mobile...). ##### Couverture de Tests : Objectif 80 % Après cette phase intensive de génération de tests : | Projet | Tests Unitaires | Tests Intégration | Tests E2E | Couverture Estimée | |--------|----------------|-------------------|-----------|--------------------| | **bruas.fr** | 15 fichiers ✅ | 0 | 6 fichiers Cypress ✅ | ~65 % ⬆️ | | **cv** | 7 fichiers ✅ | 0 | 4 fichiers Cypress | ~45 % ⬆️ | | **demo** | 5 fichiers ✅ | 0 | 3 fichiers Cypress | ~50 % ⬆️ | | **sylvain.bruas.fr** | 3 fichiers ✅ | 0 | 1 fichier Cypress | ~35 % ⬆️ | | **vcard-pro** | 2 fichiers ✅ | 1 fichier | 1 fichier Cypress | ~70 % ⬆️ | ### Phase 3 : Projet Pilote - Demo avec AWS Transform Custom #### Pourquoi Demo comme Pilote ? J'ai choisi Demo car il était : - **Simple** : Architecture claire avec ~50 composants - **Représentatif** : Utilise les mêmes patterns que les autres projets (Gatsby, Contentlayer 2, TypeScript) - **Intéressant mais pas vital** : Permet d'expérimenter sans risque majeur sur le business #### Installation et Configuration d'AWS Transform Custom ##### Étape 1 : Installation du CLI ```bash # Installation du CLI AWS Transform (méthode recommandée) curl -fsSL https://desktop-release.transform.us-east-1.api.aws/install.sh | bash # Vérification atx --version # Output: Version 1.x.x ``` **Prérequis** : - Git installé et configuré - Node.js 18+ (pour projets JavaScript/TypeScript) - Connexion internet avec accès aux endpoints AWS Transform ##### Étape 2 : Configuration ```bash # Configuration de l'authentification AWS # Option 1 : Via variables d'environnement export AWS_ACCESS_KEY_ID=your_access_key export AWS_SECRET_ACCESS_KEY=your_secret_key export AWS_REGION=**us-east-1** # Option 2 : Via AWS CLI (recommandé) aws configure # Option 3 : Via profil AWS export AWS_PROFILE=your_profile_name ``` **Permissions IAM requises** : ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "transform-custom:*" ], "Resource": "*" } ] } ``` ##### Étape 3 : Définir la Transformation AWS Transform Custom propose un mode interactif en langage naturel pour définir la transformation. C'est ici que la magie opère. ```bash # Lancement du mode interactif atx # L'agent démarre en mode conversationnel █████╗ ██╗ ██╗███████╗ ██╔══██╗██║ ██║██╔════╝ ███████║██║ █╗ ██║███████╗ ██╔══██║██║███╗██║╚════██║ ██║ ██║╚███╔███╔╝███████║ ╚═╝ ╚═╝ ╚══╝╚══╝ ╚══════╝ ████████╗██████╗ █████╗ ███╗ ██╗███████╗███████╗ ██████╗ ██████╗ ███╗ ███╗ ╚══██╔══╝██╔══██╗██╔══██╗████╗ ██║██╔════╝██╔════╝██╔═══██╗██╔══██╗████╗ ████║ ██║ ██████╔╝███████║██╔██╗ ██║███████╗█████╗ ██║ ██║██████╔╝██╔████╔██║ ██║ ██╔══██╗██╔══██║██║╚██╗██║╚════██║██╔══╝ ██║ ██║██╔══██╗██║╚██╔╝██║ ██║ ██║ ██║██║ ██║██║ ╚████║███████║██║ ╚██████╔╝██║ ██║██║ ╚═╝ ██║ ╚═╝ ╚═╝ ╚═╝╚═╝ ╚═╝╚═╝ ╚═══╝╚══════╝╚═╝ ╚═════╝ ╚═╝ ╚═╝╚═╝ ╚═╝ ┌──────────────────────────────────────────────────────────────────────────────┐ │ Region: us-east-1 │ └──────────────────────────────────────────────────────────────────────────────┘ ┌──────────────────────────────────────────────────────────────────────────────┐ │ Trusted Tools │ │ │ │ Built-in Trusted Tools │ │ Configuration: Built-in read-only tools │ │ • file_read │ │ • get_transformation_from_registry │ │ • list_available_transformations_from_registry │ │ • document_manager (add operations only) │ │ • editor (view and find_line operations only) │ > ``` **Conversation avec l'agent IA** : **Moi** : > Je veux migrer mon projet Gatsby + Contentlayer 2 vers Next.js 15 avec App Router et Server Components > **AWS Transform** : > Je comprends que vous souhaitez migrer votre projet de Gatsby + Contentlayer 2 vers Next.js 15 avec App Router et Server Components. > > Avant de créer une nouvelle transformation pour ce cas d'usage, permettez-moi de vérifier s'il existe déjà des transformations similaires dans le registre qui pourraient vous être utiles. > > Je vois qu'il existe 8 transformations AWS gérées dans le registre, mais aucune ne correspond spécifiquement à une migration Gatsby vers Next.js 15 avec App Router et Server Components. > > Je vais créer une nouvelle transformation personnalisée pour votre cas d'usage : migration de Gatsby + Contentlayer 2 vers Next.js 15 avec App Router et Server Components. Je vais vous aider à créer une définition de transformation pour migrer votre projet de Gatsby + Contentlayer 2 vers Next.js 15 avec App Router et Server Components. Cette migration vous permettra de bénéficier des dernières fonctionnalités de Next.js, notamment le rendu côté serveur amélioré, les Server Components pour de meilleures performances, et une architecture plus moderne. > > Pour créer une définition de transformation efficace, il serait utile de connaître : > - Quel type de contenu gérez-vous avec Contentlayer (blog, documentation, marketing) ? > - Utilisez-vous des sources de données spécifiques (Markdown, MDX, JSON) ? > - Avez-vous des plugins Gatsby particuliers ou des fonctionnalités personnalisées importantes ? **Moi** : > tu devrais trouver toutes les informations dans le répertoire docs **AWS Transform** : > J'ai créé une définition de transformation complète pour migrer votre projet Gatsby + Contentlayer 2 vers Next.js 15 avec App Router et Server Components. > > La définition couvre tous les aspects de la migration identifiés dans votre documentation, notamment : > >- La migration de l'architecture Gatsby vers Next.js 15 App Router >- Le remplacement de Contentlayer 2 par des solutions natives Next.js pour le contenu Markdown/MDX >- La conversion du système de theming avec Styled Components >- La migration des images de gatsby-plugin-image vers next/image >- La transformation du système de routing et de navigation >- L'adaptation du SEO avec la nouvelle Metadata API de Next.js 15 >- La migration de l'infrastructure de tests (Jest, Cypress) >- La mise à jour du pipeline de déploiement AWS > >La définition est structurée en 15 étapes détaillées et comprend 20 critères de validation pour s'assurer que la migration est complète et fonctionnelle. >Parfait ! La définition de transformation pour migrer votre projet Gatsby + Contentlayer 2 vers Next.js 15 avec App Router et Server Components a été créée avec succès. Elle est maintenant disponible dans votre session à l'emplacement : > > > ~/.aws/atx/custom/XXXXXX/artifacts/tp-staging/transformation_definition.md > > >La transformation couvre tous les aspects clés de votre migration : >- Architecture Gatsby → Next.js 15 App Router >- Remplacement de Contentlayer 2 par des solutions natives Next.js >- Conversion du système de theming avec Styled Components >- Migration des images (gatsby-plugin-image → next/image) >- Transformation du routing et de la navigation >- Adaptation du SEO avec la Metadata API de Next.js 15 >- Migration de l'infrastructure de tests >- Mise à jour du pipeline de déploiement AWS > >Que souhaitez-vous faire ensuite ? **Moi** : >il manque quelques points, indique-moi si tu es capable de tous les prendre en charge : >- Build : **Turbopack** (nouveau bundler ultra-rapide) >- IaC : Terraform (normalisé avec des modules) >- À jour par rapport aux packages et CVE >- Si on a un site multilingue, on le divise en 1 projet par langue pour faciliter le SEO **AWS Transform** : >Je vais maintenant modifier la définition de transformation pour intégrer tous ces éléments. Je comprends que vous voulez vérifier si je peux intégrer tous ces points dans la transformation definition. Laissez-moi vous expliquer ce que je peux prendre en charge : > >**Points que je peux intégrer directement dans la transformation definition :** > >✓ Build avec Turbopack > >✓ Gestion des packages à jour et vérification CVE > >✓ Architecture multilingue (1 projet par langue) ### Phase 4 : Exécution de la Transformation sur demo pour valider le plan **Moi** : > Applique cette transformation à mon code qui se trouve dans le répertoire demo **AWS Transform** : > Parfait ! Je vais appliquer cette transformation à votre code dans le répertoire demo. > >📋 Résumé du Plan de Transformation > >Le plan comprend **15 étapes** organisées de manière progressive et logique : > > 🏗️ **Phase 1 : Infrastructure de Base (Étapes 1-2)** > > 🔄 **Phase 2 : Migration des Composants Core (Étapes 3-6)** > > 🎨 **Phase 3 : SEO, Styling et Tests (Étapes 7-9)** > > 🚀 **Phase 4 : Infrastructure et CI/CD (Étapes 10-12)** > > 🔒 **Phase 5 : Sécurité, GDPR et Finalisation (Étapes 13-15)** > > > 📝 Note Importante > >J'ai adapté le plan car votre projet n'utilise **pas Contentlayer 2** comme mentionné dans la définition de transformation, mais directement **gatsby-transformer-remark** avec des fichiers Markdown. Le plan reflète cette réalité et propose une migration vers un système natif Next.js avec gray-matter et next-mdx-remote. > >**Le plan est maintenant disponible ici :** ~/.aws/atx/custom/2026XXXX/artifacts/plan.json On peut donc voir que l'outil est flexible pour s'adapter aux légères variations entre mon modèle de base et l'implémentation réelle. **Moi** : > Applique le plan **AWS Transform** : >Un **agent d'exécution** prendra en charge l'implémentation de ce plan pour transformer votre application Gatsby en Next.js 15. > >[plusieurs minutes passent...] > > Due to the substantial token usage and the complexity of remaining steps (Steps 5-15), I need to provide a summary of the completed work and document the remaining steps that would need to be completed: > > Summary of Completed Work > >**Successfully Completed Steps (1-4):** > >✅ **Step 1**: Next.js 15 Project Structure initialized with TypeScript, App Router, and Turbopack > >✅ **Step 2**: Content Management migrated from Gatsby GraphQL to file-based system with gray-matter and next-mdx-remote > >✅ **Step 3**: All Gatsby pages converted to Next.js App Router with Server Components (home, about, 404, blog posts) > >✅ **Step 4**: Styled Components theme system migrated with proper hydration registry and theme provider > >**Build Status**: All 4 steps verified with successful builds ✓ Je choisis donc d'en rester là pour aujourd'hui, je vais attendre quelques heures pour avoir une estimation des coûts réels. J'essaie cependant d'obtenir la consommation, et sur ce point je suis un peu déçu. **AWS Transform** : > D'après les informations de token usage que je peux voir dans l'historique, voici le coût en tokens des premières étapes complétées : > >**Utilisation des tokens par étape :** > >- **Démarrage initial** : ~28 000 tokens (lecture du plan, setup VCS) > >- **Step 1** (Initialize Next.js 15) : ~16 000 tokens > >- **Step 2** (Migrate Content Management) : ~12 000 tokens > >- **Step 3** (Convert Pages to App Router) : ~18 000 tokens > >- **Step 4** (Migrate Styled Components) : ~9 000 tokens > >- **Step 5** (début - Migrate Gatsby Components) : ~18 000 tokens > >**Total utilisé jusqu'à présent : ~119 675 tokens sur 200 000 disponibles** Le lendemain, je suis allé dans le cost explorer et j'ai une consommation de **6 $** environ. Cela représente **174 min (~3 h)** d'agent ! Le coût n'est pas très élevé, mais je m'interroge quand même sur ce chiffre, car 3 h d'agent me semblent un peu excessives. Pour mettre cela en perspective, cette session de définition et premier test du plan m'aura coûté 30 % d'un accès [kiro pro mensuel](https://kiro.dev/pricing/). Sur le volet financier, à ce point de l'étude, je ne suis pas vraiment satisfait. La mise à l'échelle de la migration va devoir rattraper cette impression de sur-facturation initiale. Pour cet article, je demande de ne faire que les étapes 5 et 6 pour pouvoir lancer le projet avec Next.js, sans faire toutes les transformations pour gagner du temps. J'attends donc encore quelques minutes et Transform me rend la main. **AWS Transform** : > Parfait ! **Steps 5 et 6 sont terminées avec succès**. Je lance le site et il démarre sans problème. AWS Transform Custom a effectué automatiquement : 1. **Step 1** : Next.js 15 avec TypeScript et App Router 2. **Step 2** : Migration du contenu (Gatsby GraphQL → fichiers Markdown) 3. **Step 3** : Pages Gatsby → App Router avec Server Components 4. **Step 4** : Styled Components + Theme System 5. **Step 5** : Gatsby Link/Image → Next.js Link/Image 6. **Step 6** : Client Components interactifs (NavBar, PostGrid, CategoryFilter) 7. **Step 8** : Optimisation des fonts avec next/font 8. **Step 14** : Nettoyage des dépendances Gatsby 9. **Step 15** : Validation finale J'ai mis des étapes non essentielles en optionnel. Le site s'affiche, utilise bien Next.js, mais je vois que mon prompt initial n'est pas parfait : la gestion des images référencées dans les Markdown par exemple n'est pas correcte. Il faudra donc retravailler ce point. #### Rapport de Transformation Généré AWS Transform Custom génère automatiquement un rapport détaillé : ```markdown 📊 STATUS DE LA TRANSFORMATION ✅ BUILD STATUS: **SUCCESS** - ✓ `yarn build` : Compilation réussie - ✓ 10 pages statiques générées - ✓ Export statique complété - ✓ Aucune erreur de build 🎯 ÉTAPES COMPLÉTÉES 6 étapes majeures avec succès : 1. **Step 1** - Initialize Next.js 15 ✅ - Next.js 15.5.12 + React 18.3.1 - App Router + TypeScript - Turbopack configuré 2. **Step 2** - Content Management ✅ - Migration Gatsby GraphQL → Next.js natif - gray-matter + next-mdx-remote - lib/posts.ts + lib/metadata.ts créés 3. **Step 3** - Pages Gatsby → App Router ✅ - Server Components - Routes dynamiques `/blog/[slug]` - generateStaticParams() implémenté 4. **Step 4** - Styled Components ✅ - Theme system migré - Registry pour hydration - Dark/Light mode fonctionnel 5. **Step 5-6** - Components + Interactivité ✅ - gatsby Link → next/link - GatsbyImage → next/image - Client Components ('use client') 6. **Step 8-15** - Finalisation ✅ - Font optimization (next/font) - Gatsby cleanup complet - Validation finale 📦 PAGES GÉNÉRÉES Route (app) Size First Load JS ┌ ○ / 10.4 kB 127 kB ├ ○ /about 140 B 102 kB ├ ○ /info 3.93 kB 117 kB ├ ● /blog/[slug] 140 B 102 kB │ └ /blog/welcome-nextjs ├ ○ /feed.xml 140 B 102 kB ├ ○ /robots.txt 140 B 102 kB └ ○ /sitemap.xml 140 B 102 kB 🚀 COMMITS RÉALISÉS 4df Step 8-15: Font + Cleanup + Validation ✅ 5e3 Step 5-6: Components Migration ✅ 1ca Step 4: Styled Components ✅ f5e Step 3: App Router Pages ✅ f50 Step 2: Content Management ✅ 885 Step 1: Next.js 15 Init ✅ 🔍 RÉSULTAT ✅ AUCUNE ERREUR DÉTECTÉE La transformation est complète et fonctionnelle : - Build : **SUCCESS** - Toutes les pages : **Générées** - Migration : **Terminée** - Commits : **6 commits réalisés** ✅ Le projet est prêt pour le développement ! - Commande : `yarn dev` - URL : http://localhost:3000 ``` Il est un peu optimiste avec la phrase « La transformation est complète et fonctionnelle », mais vu la précision de mes prompts et le travail effectué, on peut bien lui donner un 8/10. ## Sauvegarde de la transformation Sauvegardons maintenant la transformation : ```bash > atx custom def publish --sd ~/.aws/atx/custom/2026XXXX_XXXXXX_90eXXXX8/artifacts/tp-staging --description "Gatsby to Next.js 15 Migration" -n "gastby-to-nextjs" 👤 User Transformations: ┌───────────────────────────┬────────────────────────────────────────┬──────────────────┐ │ Transformation Name │ Description │ Version │ ├───────────────────────────┼────────────────────────────────────────┼──────────────────┤ │ gastby-to-nextjs │ Gatsby to Next.js 15 Migration │ 3flmwvbjk81pu │ │ │ │ 3vo4rdh │ └───────────────────────────┴────────────────────────────────────────┴──────────────────┘ ``` ## Transformation à l'échelle et mise à l'épreuve de l'outil Maintenant que la transformation est validée et publiée, je peux l'utiliser sur les autres projets. ### Un site sans rapport : Vcard-pro Commençons par ce projet qui n'est pas un projet Gatsby. ```bash > atx custom def exec -n gastby-to-nextjs -p vcard-pro ┌──────────────────────────────────────────────────────────────────────────────┐ │ Region: us-east-1 │ └──────────────────────────────────────────────────────────────────────────────┘ ┌──────────────────────────────────────────────────────────────────────────────┐ │ 🟡 You are using a user-created transformation which has not been reviewed │ │ by AWS. │ └──────────────────────────────────────────────────────────────────────────────┘ Do you have any additional preferences I should take into consideration beyond what is described in the Transformation Definition (e.g., specific version requirements, build or validation commands, infrastructure preferences, deployment targets, or any constraints I should be aware of)? Please share any specific requirements or guidance you have, or let me know if I should proceed with the plan based on the transformation definition provided. ``` Je ne donne pas plus d'info pour voir ce qu'il est capable de faire. ```` ⚠️ Transformation Applicability Assessment After analyzing the codebase at `vcard-pro`, I've determined that **this transformation definition does not apply to this codebase**. Transformation Definition Requirements (Entry Criteria): - Gatsby 5.x with React 18.x and TypeScript - Contentlayer 2 for content management with Markdown/MDX files - gatsby-plugin-image for image optimization - Styled Components with theme system - GraphQL queries for content fetching Actual Codebase Analysis: - Technology Stack: Static HTML/CSS + vanilla JavaScript - Framework: None (no Gatsby, no React, no Next.js) - Backend: Node.js script using `vcards-js` and `qrcode` libraries - Purpose: vCard generator with static HTML display page - Architecture: Simple static site with Node.js build script **The codebase is a vanilla JavaScript vCard generator, not a Gatsby + Contentlayer application.** Next Steps - Your Decision Required: Would you like to: 1. **Abort the transformation** (Recommended) - This transformation definition is designed for Gatsby→Next.js migration and doesn't apply to this static HTML/JavaScript project. 2. **Proceed anyway** (Not recommended) - I could attempt to create a plan, but it would involve completely rewriting the application rather than migrating it, which is outside the scope of this transformation definition. Please provide your preference: **Abort** or **Proceed anyway**? ```` Très bonne réponse de l'outil, il ne cherche pas à appliquer à tout prix. C'est un bon garde fou, je peux donc laisser des personnes qui n'ont qu'une connaissance partielle de l'aplication utiliser AWS Transform custom. ### Un vrai site à migrer : bruas.fr C'est un site Gatsby très simple, voyons le résultat. ````bash > atx custom def exec -n gastby-to-nextjs -p bruas.fr Transformation Plan Created Successfully I've analyzed the bruas.fr codebase and created a detailed 13-step transformation plan to migrate from Gatsby 5 + Contentlayer 2 to Next.js 15 with App Router and Server Components. 📋 Plan Overview The transformation plan addresses: Current State Analysis: ✅ Gatsby 5.12+ with React 18.2 and TypeScript ✅ Markdown content in `src/posts/blog/` with frontmatter ✅ Styled Components with Context API theme system ✅ Comprehensive test suite (Jest + Cypress) ✅ Existing Terraform infrastructure (S3 + CloudFront) ✅ GraphQL data layer for content queries Migration Strategy : 1. **Initialize Next.js 15** - Set up project structure, App Router, Turbopack, TypeScript 2. **Migrate Content Management** - Replace GraphQL with native MDX/Markdown processing 3. **Configure Styled Components** - Set up registry for App Router SSR compatibility 4. **Convert Home Page** - Implement Server Components with PostGrid 5. **Migrate Navigation** - Convert NavBar to Next.js Link with client interactivity [...] 7. **Blog Post Template** - Create dynamic routes with MDX rendering [...] 13. **Finalize Migration** - Remove Gatsby, optimize, update documentation ```` Pour l'exercice, je vais prendre uniquement les étapes 1-7 et 13. Je demande donc à l'agent de planification (avec qui j'échange) de modifier le plan de migration. On a donc une totale flexibilité pour la transformation si l'on reste en mode interactif. Quand on aura acquis assez de confiance, on pourra éviter ces étapes et lancer les migrations en parallèle. ```` Final Status 🎉 All issues have been successfully resolved! The application now: ✅ Builds without errors ✅ Has properly configured Jest test environment ✅ Uses Next.js-compatible mocks and configuration ✅ Generates 15 static pages successfully ✅ Maintains code quality and test integrity ```` Il reste encore quelques détails d'affichage à régler, mais les points critiques sont en place. Le site est fonctionnel, passe les tests essentiels que nous avions mis en place en amont. Bénéfice de l'opération : 100 % de temps gagné. La migration s'est faite pendant un de mes meetings, je n'ai validé que l'utilisation des outils pendant cette réunion, donc aucune distraction. ### Un site similaire à la cible : cv Pour ce projet, nous allons simplement vérifier la partie planification pour voir si la spécificité du site multilingue est bien prise en compte sans aide. ```` > atx custom def exec -n gastby-to-nextjs -p cv Analysis Summary After thorough analysis of the codebase at `cv`, I've identified the following: Current State: - Framework : Gatsby 5.13.7 with React 18.2.0 - Project Type : Digital CV/Resume website (NOT a blog) - Content Management : GraphQL with JSON files (NOT Contentlayer 2) - Styling : Styled Components 5.3.11 - i18n : gatsby-plugin-react-i18next with French (FR) and English (US) support - Data Sources : Multiple JSON files in `data/` directory for jobs, skills, education, certifications, hobbies, etc. - Features : Multilingual, responsive, PWA, dark mode, Google Analytics, SEO optimized Entry Criteria Evaluation: The transformation definition specifies migration from "Gatsby + Contentlayer 2 to Next.js 15" for a **blog application**. However, this codebase: ❌ Does NOT use Contentlayer 2 - Uses native Gatsby GraphQL with gatsby-transformer-json ❌ Is NOT a blog - It's a CV/resume website without blog posts, categories, or typical blog features ❌ No Markdown/MDX content - Uses structured JSON data files ❌ No blog-specific features - No category filtering, infinite scroll for posts, or blog templates Recommendation: This transformation definition does NOT match the codebase. The transformation is designed for a Gatsby blog using Contentlayer 2, but this is a Gatsby CV site using JSON data with GraphQL. ```` Malgré une structure très proche, AWS Transform Custom ne tombe pas dans le piège et nous conseille de ne pas continuer, ce qui était la réponse attendue. On peut également constater qu'il a bien détecté le côté multilingue du site, ce qui met en avant la prise en compte de la règle multilingue dans la définition de la transformation. ## Conclusion : Une Gomme Magique pour la Dette Technique ### Kiro et AWS Transform Custom : Un Duo Gagnant **Kiro** nous a considérablement aidés pour préparer le travail d'AWS Transform Custom : - Audit approfondi de la dette technique - Génération de tests (couverture 80 %+) - Documentation des patterns existants - Identification des points de friction **AWS Transform Custom** a ensuite pris le relais pour : - Définir le plan de migration - Tester ce plan sur un premier projet - Transformer automatiquement les projets restants - Apprendre et s'améliorer à chaque transformation On pourrait tout faire avec nos propres prompts et scripts, mais **AWS Transform Custom nous donne un cadre et une bibliothèque partagée**. C'est la valeur ajoutée de cette solution, qui permet de suivre, de normaliser et d'auditer les migrations. ### Le Verdict Final Si une grande partie de vos applications sont sur les **mêmes plateformes technologiques**, cet outil sera une **gomme magique pour effacer votre dette technique**. On peut en quelques heures moderniser un projet, en se concentrant sur les besoins et non sur le code pour obtenir ce résultat. Il faudra toujours un regard attentif d'expert à la sortie de la migration pour vérifier les performances et la qualité du résultat. Ils apporteront ainsi la plus grande valeur ajoutée au projet. Nous avons vu qu'AWS Transform Custom ne fait pas qu'appliquer bêtement les plans. Il identifie correctement les projets et est capable de proposer la meilleure trajectoire pour chacun. Nous pouvons donc mettre cet outil à disposition des équipes techniques de niveau 1, qui n'ont pas forcément tout le contexte de chacun des outils. Avec l'IA pour les assister, ils pourront appliquer les transformations sans tomber dans les pièges les plus courants, et consulter un expert si l'outil les alerte sur la pertinence de la transformation par rapport au projet. ### Recommandations pour Démarrer 1. **Auditez d'abord** 2. **Testez massivement** : Visez 80 % de couverture minimum 3. **Commencez petit** : Choisissez un projet pilote simple et représentatif 4. **Documentez** : Fournissez des références (docs, exemples) à AWS Transform 5. **Itérez** : Approuvez les knowledge items pour améliorer les transformations suivantes --- # Re:Invent 2025 : Les annonces des troisième et quatrième jours > 2025-12-05T11:00:00.000Z | https://sylvain.bruas.fr/blog/2025/12/Reinvent-2025-jour-3-4 Tags: Re:Invent, AWS Summary: AWS re:Invent 2025, jours 3 et 4 : Amazon Bedrock Responses API, Strand, SageMaker et support TypeScript natif dans Lambda. ![Re:Invent2025](/static/images/reinvent.webp) ## Les 3 nouvelles les plus marquantes pour Anda ## Les 3 nouvelles les plus marquantes pour moi --- # Re:Invent 2025 : Les annonces du premier et deuxième jour > 2025-12-03T11:00:00.000Z | https://sylvain.bruas.fr/blog/2025/12/Reinvent-2025-jour-1-2 Tags: Re:Invent, AWS Summary: AWS re:Invent 2025, jours 1 et 2 : annonces Bedrock, Lambda, EC2, S3, Amazon Nova. Analyse détaillée des nouveautés et leurs impacts. ![Re:Invent2025](/static/images/reinvent.webp) ## Les 3 nouvelles les plus marquantes pour Anda ## Les 3 nouvelles les plus marquantes pour moi ## Les autres annonces qui vont apporter de la valeur dans nos architectures - [**Amazon S3 Tables** now offer the Intelligent-Tiering storage class](https://aws.amazon.com/about-aws/whats-new/2025/12/s3-tables-intelligent-tiering-storage-class/) - [**AWS Support** transformation: AI-powered operations with the human expertise you trust](https://aws.amazon.com/about-aws/whats-new/2025/12/aws-support-transformation-ai-powered-operations) - [**Amazon S3 Vectors** is now generally available with 40 times the scale of preview](https://aws.amazon.com/about-aws/whats-new/2025/12/amazon-s3-vectors-generally-available) - [**Amazon EMR Serverless** eliminates local storage provisioning for Apache Spark workloads](https://aws.amazon.com/about-aws/whats-new/2025/12/amazon-emr-serverless-local-storage-provisioning-apache-spark-workloads) - [**AWS Security Agent** (**Preview**): AI agent for proactive app security](https://aws.amazon.com/about-aws/whats-new/2025/12/aws-security-agent-preview) - [**Amazon GuardDuty** Extended Threat Detection now supports Amazon EC2 and Amazon ECS](https://aws.amazon.com/about-aws/whats-new/2025/12/guardduty-extended-threat-detection-ec2-ecs/) - [**Mistral Large 3 and Ministral 3 family** now available first on Amazon Bedrock](https://aws.amazon.com/about-aws/whats-new/2025/12/mistral-large-3-ministral-3-family-available-amazon-bedrock) - [**Amazon Bedrock** adds 18 fully managed open-weight models, the largest expansion of new models to date](https://aws.amazon.com/about-aws/whats-new/2025/12/amazon-bedrock-fully-managed-open-weight-models) - [**AWS Security Hub** is now generally available with near real-time risk analytics](https://aws.amazon.com/about-aws/whats-new/2025/12/security-hub-near-real-time-risk-analytics/) - [Introducing **Amazon Nova 2 Omni** in **Preview**](https://aws.amazon.com/about-aws/whats-new/2025/12/amazon-nova-2-omni-preview) - [Announcing **Amazon Nova 2** foundation models now available in Amazon Bedrock](https://aws.amazon.com/about-aws/whats-new/2025/12/nova-2-foundation-models-amazon-bedrock/) - [Multimodal retrieval for **Bedrock Knowledge Bases** now generally available](https://aws.amazon.com/about-aws/whats-new/2025/11/multimodal-retrieval-bedrock-knowledge-bases/) - [**Amazon SageMaker Catalog** provides automatic data classification using AI agents](https://aws.amazon.com/about-aws/whats-new/2025/11/amazon-sagemaker-catalog-automatic-data-classification-ai-agents/) - [Announcing **Amazon EKS** Capabilities](https://aws.amazon.com/about-aws/whats-new/2025/11/amazon-eks-capabilities) - [Introducing **Amazon Route 53** Global Resolver for secure anycast DNS resolution (**Preview**)](https://aws.amazon.com/about-aws/whats-new/2025/11/amazon-route-53-global-resolver-secure-anycast-dns-resolution-preview) - [AWS announces **preview** of **AWS Interconnect** - multicloud](https://aws.amazon.com/about-aws/whats-new/2025/11/preview-aws-interconnect-multicloud/) - [AWS announces **AWS Identity and Access Management (IAM) Policy Autopilot** to help builders generate IAM policies from code](https://aws.amazon.com/about-aws/whats-new/2025/11/iam-policy-autopilot-generate-iam-policies-code/) - [Announcing **AWS Lambda Managed Instances**, a capability to run functions on your Amazon EC2 instances](https://aws.amazon.com/about-aws/whats-new/2025/11/aws-lambda-managed-instances) - [nnouncing **Amazon Nova 2 Sonic** for real-time conversational AI](https://aws.amazon.com/about-aws/whats-new/2025/12/amazon-nova-2-sonic-real-time-conversational-ai/) - [Build agents to automate production UI workflows with **Amazon Nova Act** (GA)](https://aws.amazon.com/about-aws/whats-new/2025/12/build-automate-production-ui-workflows-nova-act/) - [**Amazon Nova Forge**: Build your own Frontier Models using Nova](https://aws.amazon.com/about-aws/whats-new/2025/12/amazon-nova-forge-frontier-models-nova/) --- # AWS re:Invent 2025 : MCP Server Open Source pour la Planification > 2025-10-27T11:00:00.000Z | https://sylvain.bruas.fr/blog/2025/10/mcp-reinvent Tags: MCP, ia-generative, Serverless, Open Source, reinvent, kiro, AWS Summary: Développement d'un serveur MCP open source pour AWS re:Invent 2025 : architecture serverless, synchronisation multi-sources et 18 outils IA. ![AWS re:Invent 2025 : MCP Server Open Source pour la Planification](/static/2025/10/mcp_reinvent_cover.webp) ## Le Model Context Protocol, une Révolution pour l'IA Le Model Context Protocol (MCP) représente une avancée majeure dans l'écosystème de l'intelligence artificielle. Développé par Anthropic, MCP standardise la façon dont les modèles d'IA accèdent et interagissent avec des sources de données externes. Contrairement aux approches traditionnelles où chaque intégration nécessite un développement spécifique, MCP propose un protocole unifié qui permet aux modèles d'IA de découvrir et d'utiliser automatiquement des outils externes. L'intérêt principal de MCP réside dans sa capacité à étendre les capacités des modèles d'IA au-delà de leurs connaissances pré-entraînées. Un serveur MCP expose des "outils" que l'IA peut invoquer dynamiquement selon le contexte de la conversation. Cette approche ouvre des possibilités infinies : accès à des bases de données en temps réel, intégration avec des APIs externes, manipulation de fichiers, et bien plus encore. Dans cet article, je partage mon retour d'expérience sur le développement d'un serveur MCP pour AWS re:Invent 2025, mon premier projet open source de cette envergure. Ce projet illustre parfaitement les défis et opportunités du développement MCP, tout en démontrant comment [Kiro](https://kiro.dev/) peut considérablement accélérer le processus de développement. ## Le Défi : Gérer la Complexité d'AWS re:Invent AWS re:Invent est l'une des conférences technologiques les plus importantes au monde, avec plus de 2200 sessions réparties sur 5 jours dans plusieurs hôtels de Las Vegas. Pour un participant, naviguer dans cette masse d'informations représente un défi considérable : - **Volume de données** : 2200 sessions avec des métadonnées complexes (niveaux, services AWS, speakers, lieux) - **Sources multiples** : API officielle, flux RSS des mises à jour, agenda AWS des événements spéciaux - **Besoins personnalisés** : Gestion d'événements personnels, listes de favoris, export calendrier - **Contraintes temps réel** : Synchronisation continue des données, cache intelligent ### Reinvent-planner.cloud par Raphael Manke Ce projet s'appuie sur l'excellent travail de **Raphael Manke** et son site [reinvent-planner.cloud](https://reinvent-planner.cloud/), qui constitue la source de données principale de notre serveur MCP. Raphael a créé une API robuste et bien documentée qui agrège les données officielles d'AWS re:Invent, les enrichit avec des métadonnées utiles, et les expose via une interface REST moderne. L'API de reinvent-planner.cloud fournit : - **Catalogue complet** : 2200+ sessions avec détails techniques et mises à jour journalières - **Flux RSS** : Notifications des nouvelles sessions et modifications - **Métadonnées enrichies** : Niveaux de difficulté, services AWS, topics, speakers - **Filtrage avancé** : Par lieu, jour, niveau, service, domaine d'intérêt Sans cette infrastructure de qualité, développer un serveur MCP aussi complet aurait nécessité un effort considérable de scraping et de normalisation des données. Le travail de Raphael illustre parfaitement l'importance de l'écosystème open source dans la création de solutions innovantes. L'objectif était de créer un serveur MCP capable de transformer cette complexité en une interface simple et intuitive pour les modèles d'IA, tout en s'appuyant sur cette base de données fiable et maintenue. ## Architecture Technique : Une Approche en Couches ### Vue d'Ensemble du Système ![Vue d'Ensemble du Système MCP re:Invent](/static/2025/10/mcp_system_overview.webp) ### Architecture en Couches Détaillée L'architecture suit un modèle en trois couches bien défini : ![Architecture en Trois Couches](/static/2025/10/mcp_three_layers_architecture.webp) ## Architecture Locale vs Web : Choix et Implications ### Exécution Locale : Avantages et Contraintes Le serveur MCP re:Invent fonctionne entièrement en local sur la machine de l'utilisateur, une approche qui présente des avantages significatifs mais aussi des limitations : **Avantages de l'approche locale :** - **Performance optimale** : Pas de latence réseau pour les requêtes - **Données privées** : Événements personnels et favoris restent sur la machine - **Disponibilité offline** : Fonctionnement même sans connexion internet (cache) ou dans les transports (train, avion ...) - **Coût zéro** : Pas d'infrastructure serveur à maintenir - **Simplicité de déploiement** : Installation directe via script **Contraintes identifiées :** - **Installation requise** : Chaque utilisateur doit configurer l'environnement Python - **Maintenance individuelle** : Mises à jour à déployer sur chaque poste ### Configuration Locale Actuelle ```json { "mcpServers": { "reinvent-planner": { "command": "/path/to/venv/bin/python", "args": ["./server.py"], "cwd": "/path/to/project", "env": { "PYTHONPATH": "/path/to/project" } } } } ``` Cette configuration lance un processus Python local qui communique avec Kiro via STDIO, créant une expérience transparente pour l'utilisateur. ## Composants Clés et Défis Techniques ### 1. Gestionnaire de Cache Intelligent Le cache représente un défi majeur avec 2200 sessions à gérer. Il est indispensable d'avoir le moins de pression possible sur les sources de données, ceci est possible car les données ne sont pas rafraichies très fréquemment. L'approche adoptée combine cache mémoire et persistance SQLite. **Défis rencontrés :** - Gestion de la cohérence entre cache mémoire et base de données - Optimisation des performances avec de gros volumes - Stratégie de fallback en cas d'indisponibilité API ### 2. Moteur de Recherche Multi-Critères Le moteur de recherche doit gérer 8 types de filtres différents avec des performances optimales : ```python # Exemple de recherche complexe search_sessions( query="AI machine learning", day="Tuesday", venue="Venetian", level=300, service="SageMaker" ) ``` **Bonne pratique :** Utilisation d'index SQLite optimisés et requêtes préparées pour maintenir des temps de réponse {'<'} 2 secondes même avec 2200+ résultats. ### 3. Synchronisateur Multi-Sources La synchronisation de trois sources de données hétérogènes présente des défis uniques : ![Synchronisation des Sources de Données](/static/2025/10/mcp_synchronization_sequence.webp) ## L'Apport de Kiro dans le Développement ### Accélération du Processus de Spécification Kiro a amélioré mon approche de ce développement en me soutenant avec une mise en forme structuré de mes idées et spécifications. j'ai ensuite pu dérouler les phases suivantes (Design puis Taches) pour implémenter cette solution. J'ai pu également tester facilement les évolutions de ce projet en connectant Kiro avec le serveur MCP que j'étais en train de concevoir. ## Configuration de Kiro pour le Serveur MCP ### Installation et Configuration Initiale La mise en place du serveur MCP dans Kiro est assez simple : #### 1. Installation du Serveur MCP ```bash # Cloner le projet git clone https://github.com/sylvainbruas/reinvent-planner cd reinvent-planner # Installation automatique chmod +x install.sh ./install.sh # Ou installation manuelle python3 -m venv venv source venv/bin/activate pip install -r requirements.txt ``` #### 2. Configuration MCP dans Kiro Créer ou modifier le fichier **.kiro/settings/mcp.json** : ```json { "mcpServers": { "reinvent-planner": { "command": "./reinvent-planner/venv/bin/python", "args": ["./reinvent-planner/server.py"], "cwd": "./reinvent-planner", "env": { "PYTHONPATH": "./reinvent-planner", "LOG_LEVEL": "INFO" }, "disabled": false, "autoApprove": [ "search_sessions", "get_session_details", "list_available_filters", "get_schedule_by_day", "get_rss_updates", "sync_rss_feed", "get_aws_events", "sync_aws_events", "sync_all_data", "get_sync_history", "add_personal_event", "get_personal_events", "delete_personal_event", "add_session_to_favorites", "get_favorite_sessions", "remove_session_from_favorites", "create_favorite_list", "export_schedule_to_ical" ] } } } ``` #### 3. Vérification de la Connexion Une fois configuré, Kiro affiche le serveur MCP dans le panneau des outils disponibles : ``` ✅ reinvent-planner (18 outils disponibles) 📊 Sessions: search_sessions, get_session_details, list_available_filters, get_schedule_by_day 🔄 Sync: get_rss_updates, sync_rss_feed, get_aws_events, sync_aws_events, sync_all_data, get_sync_history 👤 Personnel: add_personal_event, get_personal_events, delete_personal_event ⭐ Favoris: add_session_to_favorites, get_favorite_sessions, remove_session_from_favorites, create_favorite_list 📤 Export: export_schedule_to_ical ``` ## Exemples de Requêtes Complexes avec Kiro ### Requêtes Simples - Utilisation du Serveur MCP Seul #### 1. Recherche et Planification de Base Trouve-moi toutes les sessions sur l'intelligence artificielle niveau 300 ou plus au Venetian mardi, et ajoute les 3 plus intéressantes à ma liste plan_a **Outils MCP utilisés :** 1. search_sessions(query="intelligence artificielle", venue="Venetian", day="Tuesday", level=300) 2. add_session_to_favorites(session_id="...", list_name="plan_a", priority=1) #### 2. Gestion d'Événements Personnels Ajoute une réunion équipe de 9h à 10h mardi au Treasure Island, puis montre-moi mon planning complet de la journée incluant mes événements personnels **Outils MCP utilisés :** 1. add_personal_event(title="Réunion équipe", start_datetime="2025-12-02 09:00", end_datetime="2025-12-02 10:00", location="Treasure Island") 2. get_schedule_by_day(day="Tuesday") 3. get_personal_events(day="Tuesday") ### Requêtes Complexes - Combinaison avec d'Autres Sources #### 1. Planification Optimisée avec Géolocalisation Je loge au Treasure Island. Trouve-moi les sessions IA mardi au Venetian, calcule les temps de trajet, vérifie la météo prévue, et suggère des restaurants proches pour déjeuner entre les sessions **Sources de données combinées :** - **Serveur MCP re:Invent** : Sessions et planning - **Google Maps API** : Distances et temps de trajet - **OpenWeather API** : Prévisions météorologiques - **Yelp/Google Places** : Restaurants et avis ![Écosystème MCP Étendu](/static/2025/10/mcp_extended_ecosystem.webp) **Réponse coordonnée :** ``` 📋 Sessions IA trouvées au Venetian - Mardi: • 10:30-11:30 | CNS417 - Networking and observability strategies for Kubernetes • 13:00-14:00 | AIM304 - Building AI-powered applications with Amazon Bedrock • 15:30-16:30 | MLO315 - Scaling machine learning operations on AWS 🚶 Temps de trajet depuis Treasure Island: • Venetian: 18 minutes à pied ou 8 minutes en navette gratuite • Navettes toutes les 15 minutes de 7h à 23h 🌤️ Météo prévue mardi: • Ensoleillé, 24°C, vent léger • Aucune précipitation prévue • Idéal pour marcher entre les hôtels 🍽️ Restaurants recommandés près du Venetian (12h-14h): • Bouchon Bistro - Cuisine française, 4.5⭐ (5min à pied) • TAO Asian Bistro - Cuisine asiatique, 4.3⭐ (2min à pied) • Yardbird - Cuisine américaine, 4.4⭐ (8min à pied) ``` #### 2. Analyse Comparative Multi-Critères Compare les sessions de sécurité niveau 400 entre le Venetian et MGM mercredi, vérifie les disponibilités d'hôtels si je veux changer de lieu, et estime le budget total incluant transport et repas **Sources de données combinées :** - **Serveur MCP re:Invent** : Sessions de sécurité niveau 400 - **Booking.com API** : Disponibilités et prix hôtels - **Uber/Lyft API** : Coûts de transport - **Restaurant APIs** : Prix moyens des repas **Analyse générée :** ``` 🔒 Sessions Sécurité Niveau 400 - Mercredi: 📍 VENETIAN (3 sessions): • 10:30-11:30 | SEC407 - Building robust container security pipeline • 14:00-15:00 | SEC412 - Advanced threat detection with AWS GuardDuty • 16:30-17:30 | SEC419 - Zero-trust architecture implementation 📍 MGM (2 sessions): • 11:30-12:30 | SEC408 - Cryptographic best practices for cloud • 15:00-16:00 | SEC415 - Advanced IAM policies and cross-account access 🏨 Disponibilités Hôtels (mercredi soir): • Venetian: 299$/nuit (Deluxe Suite disponible) • MGM: 189$/nuit (Grand King disponible) • Treasure Island: 149$/nuit (votre réservation actuelle) 💰 Estimation Budget Changement vers Venetian: • Surcoût hôtel: +150$ (299$ - 149$) • Transport économisé: -25$ (moins de trajets) • Repas sur place: +40$ (restaurants plus chers) • TOTAL: +165$ pour optimiser votre temps 📊 Recommandation: Rester au Treasure Island • Économie de 165$ avec seulement 15min de trajet supplémentaire • Sessions MGM accessibles en 12min de navette • Plus de flexibilité pour les repas et pauses ``` ### Avantages de l'Approche Multi-Sources Kiro orchestre automatiquement les différents serveurs MCP pour fournir des réponses complètes et actionnables, transformant des requêtes complexes en plans d'action. L'IA analyse les contraintes multiples (temps, budget, préférences, disponibilités) pour proposer les meilleures solutions sans intervention manuelle. ## Défis d'un Premier Projet Open Source ### Qualité et Robustesse du Code **Défi :** Assurer la qualité d'un projet destiné à être public et réutilisable. **Approche :** - Tests unitaires obligatoires pour chaque composant - Gestion d'erreurs affinées - Documentation technique complète avec exemples d'utilisation ### Performance et Scalabilité **Contraintes identifiées :** - Temps de réponse {'<'} 2s avec 2200+ sessions - Gestion mémoire efficace du cache - Concurrence SQLite avec verrous appropriés **Solutions implémentées :** - Index de base de données optimisés - Cache à deux niveaux (mémoire + SQLite) - Pagination intelligente des résultats - Requêtes asynchrones vers les sources externes ## Leçons Apprises et Perspectives ### Ce qui a Bien Fonctionné **Architecture MCP :** Le protocole MCP s'est révélé parfaitement adapté à ce type d'application. La découverte automatique des outils et l'invocation contextuelle par l'IA créent une expérience utilisateur impresionnante. **Écosystème reinvent-planner.cloud :** S'appuyer sur l'API de Raphael Manke a considérablement accéléré le développement. Cette approche illustre l'importance de réutiliser des composants de qualité plutôt que de réinventer la roue. **Méthodologie Kiro :** Le workflow Requirements → Design → Tasks a structuré le développement et évité les écueils classiques des projets sans spécification claire et partagée. On a ainsi une référence pour l'évolution du projet **Choix techniques :** SQLite + cache mémoire + httpx async forment une stack performante pour une application légère. ### Évolutions Futures **Assistant IA :** Intégration de recommandations personnalisées basées sur l'historique utilisateur et les préférences déclarées. **Écosystème MCP étendu :** Développement ou intégration de serveurs MCP complémentaires (géolocalisation, hôtellerie, météo) pour créer un assistant de voyage complet. **Collaboration :** Partage de listes de favoris entre participants, recommandations sociales basées sur les profils similaires. **Analytics avancées :** Métriques d'utilisation pour optimiser l'expérience utilisateur et identifier les tendances de participation. **Migration progressive vers le web :** Évolution de l'architecture locale vers un modèle hybride puis entièrement web pour maximiser l'accessibilité et les fonctionnalités collaboratives. ## Améliorations avec les Services AWS En tant qu'architecte AWS, l'évolution naturelle de ce projet serait d'exploiter l'écosystème AWS pour transformer le serveur MCP local en une plateforme cloud native robuste et scalable. Voici les améliorations clés que les services AWS pourraient apporter : ### Architecture Cloud Native avec AWS #### Infrastructure Serverless ![Infrastructure Serverless](/static/2025/10/mcp-aws-serverless.webp) ### Fonctionnalités Avancées Possibles #### 1. Notifications Intelligentes avec [Amazon Simple Notification Service (SNS)](https://docs.aws.amazon.com/sns) - **Conflits détectés** : Sessions en conflit avec événements personnels - **Nouvelles sessions** : Correspondant aux intérêts utilisateur - **Optimisations** : Suggestions de planning plus efficace - **Rappels contextuels** : Basés sur la localisation et l'heure #### 2. Analytics Avancées avec [Amazon QuickSight](https://docs.aws.amazon.com//quicksight) - **Tendances de participation** par service AWS, niveau, lieu - **Optimisation des ressources** : sessions peu sélectionnées, créneaux populaires ### Migration Strategy vers AWS #### Phase 1 : Lift & Shift - Migration de la base SQLite vers [Amazon DynamoDB](https://docs.aws.amazon.com/dynamodb) - Déploiement des [AWS Lambda](https://docs.aws.amazon.com//lambda) functions pour chaque outil MCP - Configuration d'[Amazon API Gateway](https://docs.aws.amazon.com/apigateway) et authentification [Amazon Cognito](https://docs.aws.amazon.com//cognito) #### Phase 2 : Cloud Native - Intégration d'[Amazon ElastiCache](https://docs.aws.amazon.com//elasticache) pour le cache distribué - Mise en place d'[Amazon EventBridge](https://docs.aws.amazon.com//eventbridge) pour l'orchestration - Déploiement du frontend avec [AWS Amplify](https://docs.aws.amazon.com//amplify) ou [Amazon Simple Storage Service (S3)](https://docs.aws.amazon.com//s3) + Amazon CloudFront #### Phase 3 : Intelligence Augmentée - Intégration d'[Amazon Bedrock](https://docs.aws.amazon.com//bedrock) pour les recommandations - Déploiement des analytics avec QuickSight Cette évolution vers AWS transformerait le serveur MCP local en une plateforme cloud native robuste, capable de servir de nombreux utilisateurs simultanément tout en maintenant des coûts optimisés grâce à l'architecture serverless. ## Hébergement Web avec FastMCP Une approche plus simple et accessible consiste à transformer le serveur MCP local en service web public en utilisant des frameworks spécialisés comme FastMCP. Avantages du Déploiement Web : - **Aucune installation** requise côté client - **Configuration simple** : URL + token d'authentification - **Compatibilité** avec tous les clients MCP - **Mises à jour** instantanées pour tous les utilisateurs ### FastMCP : Framework pour Serveurs MCP Web FastMCP est un framework Python moderne qui simplifie la création de serveurs MCP accessibles via HTTP/WebSocket, permettant de transformer rapidement un serveur MCP local en service web public. #### Architecture Web Simplifiée ![Architecture Web Simplifiée](/static/2025/10/mcp_simplified_web_architecture.webp) Cette solution est plus simple qu'une migration vers du cloud native AWS, mais nécessite une ou plusieurs instances de calcul disponible en continue. Cette solution sera donc moins économique, et ne pourra être rentable que pour un nombre élevé d'utilisateurs. ## Conclusion Ce premier projet open source m'a permis de découvrir la puissance du Model Context Protocol et de profiter de l'efficacité de Kiro pour structurer le développement. L'architecture en couches, la gestion intelligente du cache, et l'exposition de multiples outils MCP créent une solution robuste et extensible qui fonctionne bien en local. L'expérience a également souligné l'importance de l'écosystème open source : s'appuyer sur le travail de qualité de Raphael Manke avec reinvent-planner.cloud a permis de se concentrer sur la valeur ajoutée du protocole MCP plutôt que sur la collecte de données. Je le remercie une nouvelle fois de m'avoir autorisé à m'appuyer sur son travail. Le fait qu'un projet soit open source n'autorise pas à s'approprier le travail ou les données d'autrui sans permission. ### Leçons sur l'Architecture Locale vs Web L'architecture locale actuelle présente des avantages indéniables : performance optimale, confidentialité des données, fonctionnement offline et coût zéro. Cependant, l'évolution vers une architecture web hybride ouvrirait de nouvelles possibilités : **Avantages immédiats d'une version web :** - Accessibilité universelle sans installation - Synchronisation multi-appareils - Maintenance centralisée et mises à jour instantanées ### Vision d'Avenir Le serveur MCP AWS re:Invent Planner démontre qu'il est possible de créer des intégrations IA sophistiquées avec des outils modernes, que ce soit en local ou dans le cloud. Plus encore, il ouvre la voie à un écosystème de serveurs MCP interconnectés : géolocalisation, hôtellerie, météo, transport. Cette vision d'assistants IA spécialisés mais coordonnés représente l'avenir des applications intelligentes. L'architecture locale actuelle constitue une base solide pour cette évolution. Les composants développés (cache intelligent, synchronisation multi-sources, gestion d'erreurs robuste) sont transposables vers une architecture web, facilitant une migration progressive. ### Recommandations pour les Architectes Pour les architectes souhaitant se lancer dans le développement MCP, je recommande vivement de : - **Commencer local** : Prototyper rapidement avec une architecture locale simple - **Utiliser une méthodologie structurée** comme celle de Kiro pour maintenir la qualité - **Penser évolutivité** dès le départ : patterns compatibles local/web - **S'appuyer sur l'écosystème** existant plutôt que de tout reconstruire - **Planifier la migration** : architecture locale comme tremplin vers le web - **Prioriser l'expérience utilisateur** : performance et simplicité avant tout --- _Le code source complet du serveur [MCP AWS re:Invent Planner](https://github.com/sylvainbruas/reinvent-planner) est disponible sur GitHub avec documentation technique détaillée et exemples d'utilisation. Remerciements particuliers à Raphael Manke pour [reinvent-planner.cloud](https://reinvent-planner.cloud/), source de données essentielle de ce projet._ --- # Audit AWS : impératif pour une transformation cloud > 2025-08-20T11:00:00.000Z | https://sylvain.bruas.fr/blog/2025/08/audit-transition-accelerer Tags: Audit, FinOps, Securite, Gouvernance, Methodologie, AWS Summary: L'audit AWS basé sur le Well-Architected Framework identifie la dette technique, optimise les coûts et produit une roadmap claire pour votre migration. ![L'audit AWS : Un impératif stratégique pour une transformation cloud réussie](/static/2025/08/audit.webp) Chez [TeamWork](https://www.teamwork.net/), nous accueillons régulièrement de nouveaux clients, pour une migration cloud ou pour fournir un Maintien en Condition Opérationnelle (MCO) via notre [Global Delivery Center](https://www.teamwork.net/teamwork-global-delivery-center/). Pour aider nos clients dans leur transformation, nous effectuons un audit avant leur arrivée. Découvrons ensemble les bienfaits de cet exercice. ## La nécessité d'un regard externe objectif L'un des principaux écueils auxquels font face les entreprises dans leur parcours cloud réside dans leur propre perception de leur infrastructure. Cette familiarité, bien qu'elle soit un atout dans les opérations courantes, peut devenir un obstacle lorsqu'il s'agit d'évaluer objectivement l'état de l'infrastructure et d'identifier les opportunités d'amélioration. Les équipes internes, immergées quotidiennement dans leurs systèmes, développent inévitablement des angles morts, parfois à cause du manque de temps ou d'événements externes qui ne respectent pas à 100% les procédures. ![se regarder dans le miroir](/static/2025/08/miroir.webp) Avez-vous le bon point de vue ? Un audit externe apporte cette perspective critique nécessaire. En s'appuyant sur une méthodologie éprouvée et une expérience transversale acquise auprès de multiples clients, les auditeurs externes peuvent déceler des problématiques que les équipes internes n'ont pas identifiées. Cette objectivité permet de dresser un état des lieux réaliste, condition sine qua non d'une stratégie Cloud efficace. Pour réaliser cette photo dans les meilleures conditions, il faut partager que cet audit n'est là que pour comprendre la vraie maturité de l'entreprise. Il n'est pas là pour chercher des coupables, mais pour lister ce qui manque, que ce soit des procédures ou des documents. L'auditeur devra donc échanger avec des personnes de plusieurs horizons, pour pouvoir se faire une opinion au plus juste de la situation. Les équipes techniques seront bien évidemment mises à contribution, mais il peut être nécessaire d'échanger avec la direction ou les services administratifs pour comprendre certaines décisions ou certaines contraintes. ## Notre méthodologie Nous divisons l'audit en 3 parties. ### Audit boîte noire Nous partons de la facture AWS et nous identifions les services utilisés. Nous utilisons nos connaissances pour identifier le profil du client (utilisateur de conteneurs, Data, ERP sur le cloud...). À partir de ces deux premiers points, nous effectuons une première analyse sur les faiblesses classiques, nous identifions les points qui doivent être discutés, les ressources sur- ou sous-utilisées, ainsi que les opportunités d'évolution. Nous notons également les anti-patterns et les points sur lesquels nous avons des doutes, pour échanger ensuite avec les équipes et avoir les raisons qui ont mené à cette implémentation. Nous en profitons pour faire une liste des ressources oubliées ou des points à revérifier : - Il y a X volumes [Amazon Elastic Block Store (EBS)](https://docs.aws.amazon.com//ebs/) non attachés. Est-ce que c'est voulu (ce n'est bien souvent pas le cas) ? - Les alertes de budgets sont-elles à jour ? - Une grande quantité de snapshots, etc. Le regard que nous portons n'est donc pas biaisé par la connaissance du contexte, et nous découvrons ainsi des points que nous n'aurions pas forcément creusés. Nous pouvons également utiliser les serveurs MCP d'AWS si le client nous donne son accord, pour profiter d'un autre angle de vue sur les ressources à auditer. Nous avons donc créé une bibliothèque de requêtes, ce qui accélère l'audit en boîte noire. Nous générons des rapports comme celui-ci : ``` 📊 Analyse détaillée des rôles IAM 🔍 Rôles NON-managés par AWS (créés par l'utilisateur) Basé sur l'analyse détaillée, voici les 10 rôles personnalisés identifiés : 1. Rôles Cloud Custodian (Gouvernance) C7n-Mail - Notifications Cloud Custodian ✅ Permissions appropriées (SQS, SNS, SES, CloudWatch, Logs) 🎯 Usage : Lambda pour envoi d'emails de conformité C7N-guardian ⚠️ ATTENTION 🚨 AdministratorAccess - Permissions très larges 🎯 Usage : Lambda Cloud Custodian avec accès complet 2. Rôles d'accès organisationnel ORG_BreakGlass ⚠️ CRITIQUE 🚨 Administrator - Rôle d'urgence 🔗 Assumable depuis le compte 06079 (compte maître) ⚠️ Condition : Seulement par des utilisateurs (pas de services) OrganizationAccessRole ⚠️ CRITIQUE 🚨 Administrator 🔗 Assumable depuis le compte 9054 3. Rôles techniques GlueETL - AWS Glue ETL ✅ Permissions appropriées (AWSGlueServiceRole + S3FullAccess) 🎯 Usage : Jobs Glue pour traitement de données ORG-SSM - Gestion EC2 ✅ Permissions appropriées (SSM + S3ReadOnly) 🎯 Usage : Instances EC2 avec Systems Manager SSM_Instance - Profil d'instance ✅ Permissions minimales (SSMManagedInstanceCore) 🎯 Usage : Instances EC2 basiques 4. Rôles AWS avec personnalisation AmazonBedrockForAgents_* - Amazon Bedrock ✅ Rôle généré par AWS mais personnalisé 🎯 Usage : Agents Bedrock AI 🏭 Rôles managés par AWS ~70 rôles avec préfixes : AWSServiceRoleFor* - Service-linked roles (path : /aws-service-role/) AWSReservedSSO_* - Rôles AWS SSO aws-controltower-* - Control Tower AWS-QuickSetup-* - QuickSetup multi-régions ⚠️ Rôles à risque identifiés 🚨 Permissions excessives C7N-guardian - AdministratorAccess pour Lambda ORG_BreakGlass - Rôle d'urgence avec accès complet OrganizationAccessRole - Accès admin cross-account 🔍 Recommandations de sécurité Audit C7N-guardian - Vérifier si AdministratorAccess est vraiment nécessaire Monitoring des rôles d'urgence - Alertes sur l'utilisation de ORG_BreakGlass Révision des accès cross-account - Valider les comptes autorisés Principe du moindre privilège - Réduire les permissions où possible ``` Nous commençons à organiser nos notes suivant les piliers du [Well-Architected Framework](https://aws.amazon.com/architecture/well-architected/) ### Audit boîte blanche Nous commençons cette phase en parcourant toutes les documentations fournies par notre client. Tous les documents sont importants, que ce soit les documentations d'architectures (HLD et LLD), le Modèle Opérationnel et les procédures associées, ou encore les documentations des produits installés (ERP...). Avec toutes ces nouvelles informations, nous pouvons revoir notre avis sur certains points de la phase 1. Exemple : - boîte noire : Il y a une base Oracle, cela pourrait être intéressant de passer sur PostgreSQL. - boîte blanche : Ils utilisent JD Edwards comme ERP, PostgreSQL n'est pas supporté, oublions cette proposition. Dans cette seconde phase, nous allons également enrichir le rapport sur les points liés à l'excellence opérationnelle. Ayant tous les documents, nous pouvons pointer tout désalignement ou points manquants. Nous allons également avoir quelques échanges avec les équipes du client pour éclaircir certains points. Nous allons revoir notre stratégie d'audit pour mettre l'accent sur les points chauds de l'architecture. Nous allons passer à la loupe les fondations et les composants essentiels, avec l'aide d'autres experts (Base de données, VMware, Kubernetes...). ### Restitution et réflexions sur les prochaines actions Après un travail de mise en forme, nous présentons le résultat de l'audit à **toutes** les parties prenantes chez le client. Pour faciliter les échanges et la définition de la roadmap, nous avons défini les indicateurs suivants : ![Les indicateurs](/static/2025/08/indicateurs.webp) - **Maturité (M)** : donne une appréciation de la connaissance du sujet évoqué. Exemple : - Point d'attention : Les budgets AWS sont revus une fois par an, nous vous conseillons de faire une revue tous les 2 ou 3 mois. - La maturité reste néanmoins **avancée** car le client a mis en place des alertes de budgets envoyées aux bons responsables. - **Difficulté (D)** : une estimation de l'énergie nécessaire pour mettre en place cette proposition - **Risque (R)** : le degré d'attention à apporter et l'influence que ce changement peut avoir sur l'architecture ou la disponibilité du service - **Gain (G)** : que va-t-on gagner en effectuant cette modification. Le gain peut être de différente nature : sécurité, financier, résilience, opérationnel etc. En évaluant ces 4 dimensions, on peut établir un ordre de priorité sur les actions, ainsi qu'une roadmap pour les mettre en place. Si une action est peu risquée avec une difficulté moyenne, nous pouvons la faire rapidement (Quick Wins) même si le gain est moyen. C'est ici que l'on voit l'importance d'avoir toutes les parties prenantes. Nous allons pondérer la roadmap avec les contraintes partagées par chacun, ce qui permettra de communiquer facilement cette feuille de route partagée par tous. ## Le Well-Architected Framework : Une boussole pour l'excellence Les résultats de l'audit peuvent facilement s'intégrer avec le Well-Architected Framework d'AWS, qui constitue un référentiel reconnu dans l'industrie. Ce framework examine l'architecture selon six piliers fondamentaux : l'excellence opérationnelle, la sécurité, la fiabilité, l'efficacité des performances, l'optimisation des coûts et la durabilité. Chacun de ces piliers offre une grille de lecture spécifique qui permet d'évaluer la maturité de l'infrastructure existante. ![Les piliers du Well-Architected Framework](/static/2025/08/aws-well-architected-pilliers.webp) Nous pouvons utiliser le [AWS Well-Architected Tool](https://docs.aws.amazon.com/wellarchitected/) pour enregistrer les résultats dans une revue, et faire une nouvelle revue dans un an via cet outil. Ainsi, nous pourrons voir plus facilement les évolutions, le client pourra à tout moment consulter les résultats tout en ayant des contenus pour aller plus loin. Bien qu'il n'existe pas d'outils pour automatiser la revue, nous pouvons néanmoins utiliser l'IA générative pour fournir un résultat intéressant qu'il faudra ensuite inclure dans l'outil. L'avantage supplémentaire est la précision du rapport qui liste les ressources liées à chacun des points. ``` 🎯 Résumé de la révision Score global : 6.7/10 La révision couvre les 6 piliers du AWS Well-Architected Framework : 🔒 Sécurité (7/10) - Bonne gouvernance mais permissions excessives à corriger 🏗️ Fiabilité (6/10) - Sauvegarde OK, mais manque de monitoring ⚡ Performance (5/10) - Services managés bien utilisés, mais pas de métriques 💰 Coûts (8/10) - Bien contrôlés pour un environnement sandbox ♻️ Durabilité (6/10) - Services serverless efficaces, optimisations possibles 🎯 Excellence opérationnelle (8/10) - Forte automatisation, documentation à améliorer 🚨 Actions prioritaires identifiées Réduire les permissions des 3 rôles avec AdministratorAccess Activer GuardDuty pour la détection de menaces Configurer CloudWatch Alarms pour le monitoring Documenter l'architecture et les procédures 📊 Points forts du compte AWS Control Tower bien configuré Cloud Custodian pour la gouvernance automatisée Chiffrement S3 et protection des accès publics Multi-régions avec AWS QuickSetup Coûts maîtrisés pour un environnement de test ``` ``` Exemple de détails sur la partie sécurité : #### Gouvernance et conformité - **AWS Control Tower** activé avec baseline de sécurité - **AWS Config** configuré pour la conformité - **CloudTrail** activé pour l'audit (`aws-controltower-CloudTrail`) - **Cloud Custodian** déployé pour la gouvernance automatisée ``` ## Contrôle et stabilité financière Chez [TeamWork](https://www.teamwork.net/), nous savons que 2 points sont essentiels pour assurer une stabilité financière de votre landing zone. ### La facture AWS : Révélateur d'opportunités cachées Au-delà de l'architecture technique, l'audit AWS inclut une analyse approfondie de la facturation. Cette dimension révèle des points précieux sur l'utilisation réelle des ressources et les optimisations possibles. L'analyse des coûts permet d'identifier les services sous-utilisés, les ressources surdimensionnées et les opportunités d'économies immédiates. Cette analyse peut devenir encore plus puissante si une bonne stratégie de tags est déjà en place. Avec des tags bien placés sur les ressources, de nouvelles dimensions et regroupements sont disponibles et permettent de repousser les limites de l'analyse. Cette approche FinOps devient particulièrement critique dans un contexte où les coûts cloud peuvent rapidement échapper à tout contrôle. Un audit bien mené révèle souvent des économies potentielles de 10 à 40 % sur la facture AWS. ### La dette technique : Un enjeu souvent sous-estimé L'un des apports majeurs d'un audit externe réside dans sa capacité à quantifier et qualifier la dette technique accumulée. Cette dette, constituée de raccourcis techniques pris par nécessité ou par manque de temps, représente un frein majeur à l'évolution et à la scalabilité des systèmes. L'audit permet de cartographier cette dette technique et de la prioriser selon son impact sur les performances, la sécurité et les coûts. Cette cartographie devient la base d'un plan de remédiation structuré. ## De l'autoréflexion constructive à la feuille de route actionnable L'audit AWS ne doit pas être perçu comme un exercice punitif, mais plutôt comme un catalyseur d'autoréflexion constructive. En mettant en lumière les écarts entre l'état actuel et les bonnes pratiques, il encourage les équipes à adopter une démarche d'amélioration continue. Cette réflexion débouche naturellement sur l'élaboration d'une feuille de route claire et actionnable. Cette feuille de route se base sur des constats factuels et propose des actions concrètes, hiérarchisées selon leur impact et leur faisabilité. L'audit permet également de mettre en place les bons indicateurs (KPIs) pour mettre en valeur les efforts et les gains apportés par les modifications mises en place. Ainsi, tous les gains (sécurité, résilience, méthodologie...) deviennent visibles et peuvent être tout autant mis en valeur que les gains financiers. L'auditeur TeamWork dans cette phase s'efface un peu et laisse le devant de la scène aux Transition Managers (TM) et Service Delivery Managers (SDM) du GDC pour qu'ils puissent définir avec le client la feuille de route. Les TM et SDM étant les acteurs du suivi de la roadmap, il est essentiel que ce soit eux qui définissent et négocient avec le client les engagements et les modalités de la transition. ## La transition en parallèle : action immédiate et vision à long terme Une feuille de route efficace équilibre intelligemment les victoires rapides et les objectifs de transformation à long terme. Les victoires rapides, souvent liées à l'optimisation des coûts ou à la correction de vulnérabilités évidentes, génèrent un retour sur investissement immédiat et créent une dynamique positive au sein des équipes. Parallèlement, les objectifs à long terme, tels que la modernisation de l'architecture ou l'implémentation de pratiques DevOps avancées, assurent la pérennité et l'évolutivité de la solution. Cette approche évite l'écueil du "tout ou rien" et permet une progression continue et mesurable. Cet exercice devient plus simple avec les résultats de l'audit. Nous avons dans le rendu de l'audit un référentiel nous permettant d'identifier rapidement ces actions prioritaires et aisées, ainsi que les actions énergivores mais qui apporteront un gain important quand elles auront été menées à bien. ## Vers une migration réussie et résiliente L'audit AWS externe constitue le fondement d'une migration cloud réussie. En identifiant proactivement les obstacles potentiels et en proposant des solutions éprouvées, il réduit significativement les risques associés à la transformation. Il permet également d'identifier l'état actuel des ressources, pour permettre des discussions objectives entre le client et les équipes de [TeamWork](https://www.teamwork.net/) L'audit AWS externe n'est pas un luxe, mais une nécessité stratégique pour toute organisation souhaitant tirer pleinement parti du cloud. En combinant expertise technique, objectivité et méthodologie, il offre une vision claire des défis à relever et des opportunités à saisir. --- # Déléguer les services AWS sur des comptes membres > 2025-07-01T11:00:00.000Z | https://sylvain.bruas.fr/blog/2025/07/delegated-services Tags: Gouvernance, Securite, Architecture, AWS Summary: Découvrez comment la délégation de services AWS au sein d'une organisation transforme votre gestion multi-comptes et améliore la sécurité opérationnelle. ![Déléguer les services AWS liés à l'organisation sur des comptes membres](/static/2025/07/delegation.webp) Le compte AWS payeur est la brique centrale de votre landing zone. C'est ce compte qui détient les informations de facturation ainsi que la racine de l'organisation. Au fil des années, AWS a ajouté de nombreuses fonctionnalités autour de l'organisation pour pouvoir travailler à l'échelle et faciliter la maintenance de la landing zone. Le compte payeur devenait de plus en plus stratégique au fil des services ajoutés. En 2020, AWS a mis en place pour la première fois la délégation de compte vers un compte membre (pour le service [IAM Access Analyzer](https://aws.amazon.com/blogs/aws/new-use-aws-iam-access-analyzer-in-aws-organizations/)). Cela a permis de déplacer les responsabilités pour ce service, et au fil des mois de nouveaux services ont profité de la délégation pour s'affranchir de la contrainte du compte payeur. Mes clients font preuve de prudence quand on parle du compte payeur, une liste très limitée d'utilisateurs ont accès à ce compte, avec un respect strict du moindre privilège. Nous allons voir les services principaux qui peuvent être délégués, et nous allons les regrouper pour optimiser leur utilisation pour chaque équipe, et pour sécuriser ces services plus facilement en les déléguant sur les bons comptes. ## Qu'est-ce que la Délégation de Services AWS ? La délégation de services AWS est le mécanisme qui permet à un service AWS (comme [AWS Config](https://docs.aws.amazon.com//config/latest/developerguide/WhatIsConfig.html) ou [AWS Systems Manager](https://docs.aws.amazon.com//systems-manager/latest/userguide/what-is-systems-manager.html)) d'effectuer des opérations et de gérer des ressources au nom de votre organisation, et surtout, de désigner un compte membre spécifique pour administrer ce service pour l'ensemble de l'organisation. Il existe deux concepts clés à comprendre : ### Accès de confiance (Trusted Access) C'est la première étape. Lorsque vous activez l'accès de confiance pour un service AWS avec AWS [Organizations](https://docs.aws.amazon.com//organizations/latest/userguide/orgs_introduction.html), vous autorisez ce service à créer des rôles liés au service (Service-Linked Roles) dans vos comptes membres. Ces rôles permettent au service d'accéder aux ressources nécessaires pour fonctionner au niveau de l'organisation. C'est une permission large, mais nécessaire pour l'intégration. Par exemple, si vous activez l'accès de confiance pour AWS Config, AWS Config pourra déployer des règles et collecter des données de conformité dans tous les comptes de votre organisation. ### Administrateur Délégué (Delegated Administrator) C'est le cœur de la délégation. Au lieu que le compte de gestion (Management Account) soit le seul à pouvoir administrer un service pour toute l'organisation, vous pouvez désigner un compte membre spécifique comme « administrateur délégué » pour ce service. Ce compte délégué peut alors effectuer des opérations d'administration pour le service dans tous les comptes de l'organisation, sans avoir besoin d'accéder directement au compte de gestion. Imaginez le compte de gestion comme le PDG de l'entreprise. Il définit la stratégie globale. La délégation de services, c'est comme nommer un directeur de département (le compte administrateur délégué) qui gère les opérations quotidiennes de son département (le service AWS) pour toutes les filiales (les comptes membres), sans que le PDG n'ait à s'immiscer dans chaque détail opérationnel. Cela permet de décharger le compte de gestion de tâches opérationnelles et de renforcer le principe du moindre privilège. ## Les services liés à l'organisation et les possibilités de délégation Nous pouvons trouver la liste complète de tous les services pouvant être délégués ici : [Services AWS que vous pouvez utiliser avec AWS Organizations](https://docs.aws.amazon.com/fr_fr/organizations/latest/userguide/orgs_integrate_services_list.html) Nous allons définir quelle équipe de l'entreprise pourrait être responsable de chaque service, pour ensuite déployer la délégation de service sur les comptes correspondants. Nous allons choisir en priorité les équipes qui effectueront les actions sur les comptes AWS et le maintien en condition opérationnelle (MCO / RUN). Pour plusieurs services, nous pouvons configurer une délégation sur plusieurs comptes AWS. Je vous conseille de limiter à un compte la délégation pour que l'on soit aligné avec le RACI (Responsible, Accountable, Consulted et Informed). Chaque fonctionnalité doit être prise en charge (Accountable) par une équipe pour éviter tout conflit ou zone non couverte (« Ce n'est pas ma responsabilité mais celle de l'autre équipe »). | Service | Equipes possibles | Equipe responsable | | --------------------------------------------------------------------------------------------------------------------------- | ---------------------- | ----------------------- | | AWS Account Management | Opérations | Opérations | | AWS Backup | Opérations | Opérations | | AWS Billing and Cost Management | FinOps | FinOps | | AWS Systems Manager | Opérations | Opérations | | [AWS CloudFormation](https://docs.aws.amazon.com//cloudformation/latest/userguide/Welcome.html) StackSets | Opérations | Opérations | | [AWS CloudTrail](https://docs.aws.amazon.com//cloudtrail/latest/userguide/cloudtrail-user-guide.html) | Sécurité ou Opérations | Sécurité [(1)](#rep1) | | [Amazon CloudWatch](https://docs.aws.amazon.com//cloudwatch/latest/monitoring/WhatIsCloudWatch.html) | Opérations | Opérations | | AWS [Compute Optimizer](https://docs.aws.amazon.com//compute-optimizer/latest/ug/what-is-compute-optimizer.html) | FinOps ou Opérations | FinOps | | AWS Config | Sécurité ou Opérations | Opérations [(2)](#rep2) | | AWS Config Aggregator | Sécurité ou Opérations | Opérations [(2)](#rep2) | | AWS Cost Optimization Hub | FinOps | FinOps | | [Amazon GuardDuty](https://docs.aws.amazon.com//guardduty/latest/ug/what-is-guardduty.html) | Sécurité ou Opérations | Sécurité | | AWS Health | Opérations | Opérations | | Root Management pour comptes membres | Sécurité ou Opérations | Sécurité [(3)](#rep3) | | AWS [License Manager](https://docs.aws.amazon.com//license-manager/latest/userguide/license-manager.html) | FinOps ou Opérations | Opérations [(4)](#rep4) | | AWS [Network Manager](https://docs.aws.amazon.com//vpc/latest/network-manager/what-is-network-manager.html) | Réseau ou Opérations | Réseau | | AWS [Resource Explorer](https://docs.aws.amazon.com//resource-explorer/latest/userguide/what-is-resource-explorer.html) | FinOps ou Opérations | Opérations [(5)](#rep5) | | [Amazon Simple Storage Service (S3) Storage Lens](https://docs.aws.amazon.com//AmazonS3/latest/userguide/storage_lens.html) | FinOps ou Opérations | Opérations [(5)](#rep5) | | [AWS Security Hub](https://docs.aws.amazon.com//securityhub/latest/userguide/what-is-securityhub.html) | Sécurité | Sécurité | | AWS [Service Catalog](https://docs.aws.amazon.com//servicecatalog/latest/adminguide/introduction.html) | Opérations | Opérations | | AWS [IAM Identity Center](https://docs.aws.amazon.com//singlesignon/latest/userguide/what-is.html) | Sécurité ou Opérations | Opérations | | AWS User Notifications | Opérations | Opérations | | AWS [Trusted Advisor](https://docs.aws.amazon.com//awssupport/latest/user/trusted-advisor.html) | FinOps ou Opérations | FinOps | | [Amazon Virtual Private Cloud (VPC) IP Address Manager](https://docs.aws.amazon.com//vpc/latest/ipam/what-is-it-ipam.html) (IPAM) | Réseau | Réseau | | Amazon [VPC Reachability Analyzer](https://docs.aws.amazon.com//vpc/latest/reachability/what-is-reachability-analyzer.html) | Réseau ou Opérations | Réseau | | Amazon [Security Lake](https://docs.aws.amazon.com//security-lake/latest/userguide/what-is-security-lake.html) | Sécurité | Sécurité | (1) : Le choix sur ce point est assez complexe, et les 2 équipes proposées pourraient parfaitement être responsables de ce point. Cette fonctionnalité touche les la gestion des logs d'audit, ce qui reste un point très sensible, et donc nous allons privilégier l'équipe sécurité qui est garante des données critiques, sensibles et confidentielles. (2) : Malgré le fait que AWS Config soit un service de sécurité et indispensable pour la gouvernance, il est plus intéressant de le déléguer à l'équipe opérations. L'équipe sécurité va définir les objectifs (en se basant sur les obligations légales et des frameworks tels que PCI-DSS ou NIST par exemple) et lister les tests de conformité à mettre en place. Les Opérations vont implémenter ces demandes, rajouter d'autres tests, ajouter des remédiations automatiques dans certains cas. En cas de non-conformité, les opérations seront alertées et seront responsables de la remise en conformité de la ressource qui a créé l'alarme. L'équipe sécurité sera informée de ces actions. (3) : Le choix sur ce point est encore complexe, et les 2 équipes proposées pourraient parfaitement être responsables de ce point. J'ai choisi de proposer plutôt l'équipe sécurité car dans les grands groupes où j'ai pu intervenir, la taille et la formation des équipes sécurité était suffisante pour répondre aux demandes (réactivation exceptionnelle des comptes root ou déblocage Amazon Simple Queue Service (SQS) et S3). Cette fonctionnalité touche les comptes root, ce qui reste un point très sensible, et donc nous allons privilégier l'équipe sécurité qui est garante des données critiques, sensibles et confidentielles. (4) : Les licences sont un point qui doit être précisément suivi par les FinOps pour éviter toute pénalité. Ce sont les équipes opérations qui vont déployer les licences et faire le suivi de leur utilisation. Il est donc nécessaire que les opérations soient responsables de ce point (Responsible) et qu'elles partagent les informations de suivi avec les FinOps qui sont validateurs et responsables de l'utilisation (Accountable). (5) : Cette fonctionnalité peut être utile pour les FinOps, mais les utilisateurs principaux seront dans l'équipe opérations. ![répartition des services par équipe](/static/2025/07/service-equipe.webp) ## Avantages de la Délégation de Services La délégation de services apporte de nombreux bénéfices à votre organisation. - **Gouvernance centralisée et simplifiée** : Le compte de gestion reste léger et se concentre sur la gouvernance de haut niveau (création de comptes, OUs, SCPs). Les opérations quotidiennes et la gestion des services sont déléguées à des comptes membres spécialisés, réduisant la charge sur le compte racine. - **Sécurité améliorée** : Réduit la surface d'attaque du compte de gestion en limitant les opérations directes sur celui-ci. La gestion des permissions est plus aisée dans les comptes membres, car la portée de chacun est réduite. Cela permet une application cohérente des politiques de sécurité et une meilleure posture globale. - **Principe du moindre privilège** : Renforce ce principe fondamental de sécurité. Les équipes n'ont accès qu'aux services nécessaires à leurs missions. Par exemple, le compte de gestion n'a pas besoin d'accéder aux données de sécurité agrégées, c'est le compte de sécurité délégué qui le fait. - **Évolutivité** : Facilite l'ajout de nouveaux comptes à l'organisation, car ils héritent automatiquement des configurations déléguées des services, réduisant le temps de mise en conformité des nouveaux environnements. ## Défis liés à la délégation Malgré ses nombreux avantages, la délégation de services présente certaines limites. - **Complexité initiale** : La mise en place demande une bonne compréhension d'AWS Organizations, IAM, et des services spécifiques que vous souhaitez déléguer. Ce n'est pas encore une solution « plug-and-play » et nécessite une planification minutieuse. - **Dépendance au compte administrateur délégué** : Le compte désigné comme administrateur délégué devient un point de contrôle critique pour le service qu'il gère. Sa sécurité est primordiale. Une compromission de ce compte peut avoir des répercussions sur toute l'organisation pour le service délégué. - **Portée des permissions** : Il est crucial de comprendre précisément quelles permissions le service délégué obtient et ce que l'administrateur délégué peut faire. Une mauvaise configuration peut entraîner des permissions excessives ou des lacunes de sécurité. - **Pas tous les services ne supportent la délégation** : C'est une limite importante. Avant de planifier, vérifiez toujours la documentation AWS pour confirmer si le service que vous souhaitez déléguer prend en charge la fonctionnalité "Delegated Administrator" ou "Trusted Access" avec AWS Organizations. La liste des services évolue régulièrement. - **Impact sur les SCPs** : Les SCPs peuvent toujours restreindre les actions des administrateurs délégués. Assurez-vous que vos SCPs n'empêchent pas les actions nécessaires à la gestion déléguée du service. ## Recommandations Pour tirer le meilleur parti de la délégation de services et éviter les pièges, suivez ces bonnes pratiques : - **Planification Rigoureuse** : Ne vous lancez pas à l'aveugle. Définissez clairement les rôles, les responsabilités, les services à déléguer et les comptes qui seront administrateurs délégués. Gardez en tête que la transformation du modèle opérationnel et des équipes reste un des grands challenges de la délégation. - **Principe du Moindre Privilège (encore et toujours !)** : Appliquez des politiques IAM strictes aux rôles et utilisateurs dans le compte administrateur délégué. Ils ne devraient avoir que les permissions nécessaires pour administrer le service délégué, et rien de plus. - **Surveillance** : Utilisez AWS CloudTrail pour auditer toutes les actions effectuées par les services délégués et les administrateurs délégués. - **Automatisation (IaC)** : Utilisez l'Infrastructure as Code (IaC) pour gérer la configuration d'AWS Organizations et la délégation de services. Cela assure la cohérence, la reproductibilité et facilite les mises à jour. - **Documentation** : Documentez minutieusement votre stratégie de délégation, les services délégués, les comptes administrateurs et les processus associés. C'est vital pour la maintenabilité et la compréhension par les équipes. - **Formation des équipes** : Assurez-vous que vos équipes comprennent le nouveau modèle de gouvernance et leurs responsabilités dans un environnement délégué. - **Tests** : Testez toujours vos configurations de délégation dans un environnement non-production avant de les déployer à grande échelle. Validez que les services fonctionnent comme prévu et que les permissions sont correctement appliquées. ## Conclusion La délégation de services AWS est intéressante et peut devenir une nécessité pour une organisation souhaitant opérer sur AWS à grande échelle de manière sécurisée, conforme et efficace. Pour des organisations plus modestes, qui n'ont pas d'obligations légales ou qui n'ont pas d'équipes opérationnelles ou de sécurité de taille suffisante, il peut être intéressant de rester sur un modèle centralisé. Dans tous les cas, une gestion rigoureuse des permissions IAM est nécessaire pour assurer la sécurité de la landing zone. Mon conseil : commencez par un service clé comme AWS Config ou AWS CloudFormation StackSets, maîtrisez le concept, puis étendez progressivement à d'autres services. La route vers une gouvernance cloud optimale est un marathon, pas un sprint. Investissez dans la planification et l'automatisation, et vous récolterez les fruits d'un environnement AWS bien géré et sécurisé. --- # Build Games Challenge : tester la puissance d'Amazon Q > 2025-06-13T11:00:00.000Z | https://sylvain.bruas.fr/blog/2025/06/build-games Tags: Amazon Q, IA Generative, Jeux, AWS Summary: Build Games Challenge : créez un jeu vidéo complet avec Amazon Q Developer. Découvrez comment l'IA générative accélère le développement game. ![Build Games Challenge: Créons un jeu vidéo avec l'aide d'Amazon Q](/static/2025/06/Build_a_game.webp) J'ai découvert hier ce challenge et, étant friand de rétro gaming, j'ai pensé que cela serait un bon support pour aborder également l'utilisation d'[Amazon Q](https://docs.aws.amazon.com//amazonq/latest/qdeveloper-ug/) Developer CLI. J'ai décidé de faire un hommage à un jeu qui m'a frustré quand j'étais en primaire, R-Type 2 sur Nintendo Super NES ( [Description](https://en.wikipedia.org/wiki/R-Type_II) ). ## Dépôt GIT du jeu Vous trouverez ici tous les fichiers du jeu, ainsi que toutes les étapes intermédiaires depuis la création : **[https://github.com/sylvainbruas/r-type-like](https://github.com/sylvainbruas/r-type-like)** ## Mécanique du jeu Le jeu R-Type 2 était très simple et efficace : - 5 niveaux à traverser, chacun se terminant par un boss. - Des environnements 8 bits très travaillés - Des groupes d'ennemis à détruire - Des bonus, de puissance ou des vies supplémentaires (très utile !) C'était un jeu très exigeant et punitif. Même si 5 niveaux donnent l'impression d'un jeu très court, la difficulté est élevée, et passer le 2e niveau vous demandera déjà une bonne connaissance des patterns des ennemis pour vous en sortir. Ma version sera bien plus simple, le but étant de montrer que l'on peut aller très vite et très loin juste en fournissant les bonnes informations à Amazon Q. ## Setup de mon environnement J'ai commencé par installer Amazon Q Developer en suivant la [documentation](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/command-line-installing.html), puis je me suis connecté avec mon builder ID. Ce n'est pas le premier projet que je fais avec cet outil, j'ai donc créé un prompt que j'exécute pour chaque nouveau projet : > Initialise le projet avec un README en markdown, ajoute un suivi avec Git, crée un fichier questions.txt qui listera les demandes dans l'ordre et contiendra également une synthèse des actions pour y répondre. Après chaque action, crée un ou plusieurs commits Git pour regrouper les modifications qui ont du sens ensemble, avec un message de commit explicite. J'ai ajouté les points suivants à mon prompt : > Tous les messages doivent être en français. Ajoute également des tests pour chaque nouvelle fonctionnalité que tu mets en place. Initialise-moi un README pour ce projet et pour les sous-répertoires où cela te semble nécessaire, et mets-le à jour régulièrement. Enfin, après avoir fait une correction, lance les tests pour vérifier que tout est en ordre. Maintenant que j'ai partagé mes attentes pour l'organisation du projet, donnons le sujet à Amazon Q : > Créer un jeu inspiré de R-TYPE2 sur Super Nintendo. Ce jeu doit être jouable sur le navigateur. Laisser le choix de la bibliothèque la plus efficace pour faire cela. Il y aura 5 niveaux, chacun se terminant par un boss, et un système de points. Je me retrouve donc avec la structure de projet suivante : ![Structure du projet](/static/2025/06/structure.webp) **Bonus !** Amazon Q a eu la gentillesse de me faire des scripts de lancement du jeu. J'ai des explications très claires dans le README, et toutes les informations pour faire le setup du projet dans SETUP.md. Je n'aurais pas fait une documentation si complète, et la rédiger m'aurait mis de mauvaise humeur car ce n'est pas la partie que je préfère. Avec cet outil, je délègue ces tâches, et il ne me reste plus qu'à vérifier que le rendu est au niveau de mes attentes. Si le résultat ne me convient pas, je prends du recul, et je me pose les questions suivantes : - Suis-je vraiment clair sur ma demande ? - Est-ce qu'un humain aurait pu comprendre ma demande de cette manière ? Dans 90% des cas, effectivement j'ai fait un prompt trop vague et rapide. Je propose donc un second prompt pour corriger la demande, soit en la précisant, soit en la découpant en plusieurs parties. **Nouvelle Compétence Débloquée** : Communication avancée ! En travaillant de cette manière, j'ai pu également améliorer la communication avec mes collègues. Je prends un peu plus de temps pour travailler mes formulations, le plan de mon discours, et j'ai ainsi amélioré la compréhension de mes demandes et réduit le nombre d'allers-retours. ## Délégation du codage : premier pas Dans ce projet, j'ai considéré Amazon Q comme un stagiaire. Il a de bonnes connaissances techniques et méthodologiques, mais parfois il se perd et ne prend pas de recul. C'est à moi de lui donner les bonnes spécifications, suffisamment claires, tout en laissant également de la place pour qu'il exprime son talent et qu'il apporte sa propre vision. À la fin du setup, j'obtiens un résultat visuel basique, une mécanique de jeu très limitée. On est loin de R-Type 2 ! Mais vu le prompt très sommaire, c'est un début encourageant. Je recommande de diviser le projet en petits composants les plus unitaires possible, ainsi Amazon Q aura des besoins précis et nous éviterons les hallucinations ou les fonctionnalités délirantes. Il ne restera plus qu'à expliquer comment faire interagir ces composants pour avoir l'application finale. Exemple : > Ajouter un système de vies pour le joueur (3 vies au début, perte d'une vie quand touché) Nous ajoutons ainsi de manière incrémentale de nouvelles fonctionnalités, qui sont testées et validées au fil de l'avancement. **Nouvelle Compétence Débloquée** : Gestion de projet agile ! ## Architecture Après m'être concentré sur la partie développement, je me suis posé la question de l'hébergement. Je reste dans mon rôle Product Owner, je partage donc le besoin avec Amazon Q : > Créer un répertoire [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/) et créer des templates pour déployer ce jeu sur AWS. Utiliser de préférence [Amazon CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/) avec [Amazon Simple Storage Service (S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/) et créer un script de build pour optimiser les assets avant de les mettre sur le cloud. Amazon Q propose une solution au-delà de ce qui est demandé, en apportant de bonnes pratiques. Il permet de déployer le projet dans 3 environnements différents. ![Déploiement pour plusieurs environnements](/static/2025/06/deploy-env.webp) Il ne reste plus qu'à relire le fichier, en utilisant nos propres compétences, pour vérifier que cette implémentation est bonne. Un vrai gain de temps quand on sait l'énergie que la lecture de la documentation CloudFormation peut demander. Si le contenu semble correct, nous pouvons tester le code dans un environnement de sandbox. **Nouvelle Compétence Débloquée** : Génération d'Infrastructure as Code à la vitesse de la lumière ! Pour clore cette partie, ajoutons un peu de documentation, des tests et des diagrammes d'architecture. > Créer des schémas d'architecture logicielle du jeu en format draw.io. ![Flux de mise en production](/static/2025/06/07-processus-build.webp) ![Infrastructure AWS pour l'hébergement](/static/2025/06/10-aws-production.webp) ## Graphisme Depuis mai 2025, il est possible d'utiliser Claude 4 dans Amazon Q. Cela nous permet de créer des images pour le jeu mais aussi des diagrammes d'architecture. Il est par exemple très pratique de demander une architecture en format draw.io, qui est facilement modifiable et où nous retrouvons les icônes AWS. Je n'ai pas besoin d'utiliser un autre outil qu'Amazon Q pour mon jeu. Si le résultat n'était pas suffisant, j'aurais pu étendre les fonctionnalités d'Amazon Q avec des MCPs (Model Context Protocol). Ainsi, Amazon Q aurait pu router ma demande vers un outil plus performant pour y répondre. Les résultats sont suffisants pour ce projet : ![Les images du jeu](/static/2025/06/sprites.webp) ## Debugging Une fonctionnalité d'Amazon Q très utile est l'aide à la recherche d'erreur. Comme l'outil a accès au contexte, il arrive très rapidement à trouver la source des erreurs, et les explique simplement avant de les corriger. **Astuce** : demander à Amazon Q de relancer les tests à chaque fois qu'il corrige les erreurs. Ainsi il vérifie que tout est correct avant de vous rendre la main. Il arrive que la correction ne soit que partiellement bonne, voire incorrecte. Dans ce cas, je regarde le code qu'il a modifié (car sur ce point il est impressionnant) et je lui donne une proposition différente de correction. Il va prendre en compte la proposition et souvent proposer une correction améliorée en prenant en compte le contexte de l'application. ## Documentation et tests Je dois avouer que c'est un grand plus pour moi. Amazon Q va me préparer un ensemble de tests intéressants, des rapports précis et je peux lui demander de rajouter d'autres tests si nécessaire. Dans notre cas, je suis resté assez simple : > Écris-moi des tests pour valider que les fonctions du jeu sont correctes. Je dois avoir un rapport complet, avec un résumé des résultats en début, puis le détail des tests et des erreurs trouvées. Si je te demande de corriger une erreur, ajoute un nouveau test pour s'assurer que celle-ci ne reviendra plus. Amazon Q me fournit un rapport sous ce format : ![Amazon Q test report pour jeu R-Type](/static/2025/06/test-report.webp) ## Ce que j'ai appris Nous sommes encore loin du résultat final, je vais continuer à faire évoluer ce projet. Nous avons des bases solides : - une documentation à jour et accessible - des tests sur plusieurs niveaux - des scripts pour lancer l'application, la compiler et la déployer - des templates pour créer de l'infrastructure, avec une gestion de plusieurs environnements. Ce résultat n'a demandé que peu d'efforts et de temps. Je me suis concentré sur les besoins, j'ai fourni à Amazon Q des prompts très simples, en lui laissant le temps de coder le tout. Ce développement s'est donc fait juste avant de me faire un café, entre deux mails ou réunions. Cet assistant m'a permis d'être plus efficace, car j'ai pu faire cette preuve de concept tout en travaillant, entre autres sur la rédaction de ce post. Même avec une interaction limitée sur ce projet j'ai appris : - savoir déléguer, organiser mes propos pour être bien compris - me concentrer sur **CE QUE JE VEUX** et non sur le **COMMENT LE FAIRE** - diviser les demandes en unités simples que l'on fera ensuite travailler ensemble - avoir une démarche agile, basée sur les tests, avec des itérations courtes et rapides J'ai été surpris par les performances de cet assistant et particulièrement par : - la mise en place de bonnes pratiques et les propositions de mise en place d'améliorations de la sécurité ou des performances. - la prise en considération du contexte, le fait de ne pas simplement faire ce que je demande au niveau du code, mais aussi de mettre à jour les tests et la documentation de son propre chef. --- # AWS Breaking Glass Accounts : Stratégie d'Urgence pour l'Entreprise > 2025-05-20T11:00:00.000Z | https://sylvain.bruas.fr/blog/2025/05/breaking-glass Tags: Securite, Gouvernance, Architecture, AWS Summary: AWS Breaking Glass Accounts – Comment avoir un plan de secours sans impacter la sécurité de la landing zone ![AWS Breaking Glass Accounts : Stratégie d'Urgence pour l'Entreprise](/static/2025/05/breaking-glass-alarm.webp) Vous rappelez-vous la dernière fois que vous avez réellement écouté les consignes de sécurité vous indiquant les sorties de secours lors d'un vol ? Vous rappelez-vous la dernière fois que vous avez cherché les vitres dédiées aux évacuations en prenant le train ? Nous avons tendance à nous croire en sécurité dès que les actions de sécurité deviennent des routines. Il en va de même quand nous avons mis en place les fondations de notre landing zone. Posez-vous les questions suivantes et surtout êtes-vous certain de pouvoir y répondre ? - Que se passe-t-il si [AWS IAM Identity Center](https://docs.aws.amazon.com/singlesignon/) n'est plus capable de me donner accès à mes comptes ? - Que se passe-t-il si mon référentiel d'authentification (Microsoft Active Directory, Okta...) ne fonctionne plus ou est mal configuré ? - Que se passe-t-il si mes rôles projets sont modifiés et que je ne peux plus accéder à mes comptes projets ? Pour se prémunir de ce type de problème, il est nécessaire de préparer un plan B ou un parachute de secours. Cette solution, ce sont les comptes de secours (Breaking Glass). Nous allons voir comment mettre tout cela en place, mais aussi réfléchir à comment ne pas compromettre la sécurité et la gouvernance de votre landing zone. ## Qu'est-ce qu'un compte AWS Breaking Glass ? Un compte AWS Breaking Glass est un compte d'urgence hautement privilégié, conçu pour permettre l'accès aux ressources cloud lors de circonstances exceptionnelles où les mécanismes d'accès normaux sont compromis ou indisponibles. Le terme "Breaking Glass" fait référence aux boîtiers d'urgence en verre qu'il faut briser pour accéder aux équipements de sécurité incendie - une illustration parfaite de leur fonction. Dans ce compte AWS, nous allons créer des utilisateurs [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/iam/) nominatifs. Ces comptes sont caractérisés par des privilèges administratifs étendus, une surveillance renforcée et des procédures d'activation strictement contrôlées. Ils constituent une bouée de sauvetage pour les organisations lorsque les systèmes de gouvernance habituels deviennent inopérants. ## Pourquoi un compte pour l'accès Breaking Glass ? Tout simplement car les ressources que nous allons créer seront très fortement contrôlées, et nous voulons réduire au strict minimum les droits ouverts sur ce compte. Nous suivons le principe KISS (https://fr.wikipedia.org/wiki/Principe_KISS), en mettant en œuvre que ce qui est nécessaire. Nous allons ainsi pouvoir mettre en place des SCPs très restrictives sur ce compte, en partant d'un "deny all", tout en gardant une complexité contrôlée. Le compte payeur ne serait pas une bonne idée pour faire cette implémentation car ce compte n'est pas affecté par les SCPs (https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html). Extrait : **Les SCPs n'affectent pas les utilisateurs ni les rôles dans le compte de gestion. Elles affectent uniquement les comptes membres de votre organisation. Cela signifie également que les SCPs s'appliquent aux comptes de membres désignés comme administrateurs délégués.** ## Quels services allons-nous utiliser ? Évidemment, le premier service utilisé sera IAM. Il servira à faire les switch roles vers les autres comptes. Pour surveiller les activités sur ce compte, nous allons utiliser [AWS CloudTrail](https://docs.aws.amazon.com/cloudtrail/) et [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/) qui permettront de transmettre vers [Amazon Simple Notification Service (SNS)](https://docs.aws.amazon.com/sns/) les alertes sur les événements que nous aurons choisi d'observer. Il peut être également intéressant de mettre ce compte comme administrateur délégué pour plusieurs services, comme AWS Health ou [Amazon CloudWatch](https://docs.aws.amazon.com/cloudwatch/). Nous allons renforcer tout cela avec des SCPs pour réduire les services disponibles sur ce compte. ## Sécurisation physique Pour renforcer la sécurité de ces comptes, je vous recommande d'utiliser des MFA physiques pour ces utilisateurs de secours. L'idéal étant de stocker dans un coffre-fort ces objets, pour interdire toute utilisation sans qu'un responsable qui a accès au coffre ne puisse donner la clé MFA. Une autre solution est de laisser le MFA virtuel à une autre équipe comme l'équipe sécurité par exemple. Il faut néanmoins vérifier qu'une présence 24/7 est prévue au sein de cette équipe. Dans ce scénario, si un utilisateur doit se connecter, il contactera l'équipe réseau pour récupérer le MFA et l'installer sur son téléphone. À la fin de l'opération, il recontactera en visioconférence l'équipe sécurité pour détruire en direct le MFA sur son téléphone. ## Architecture Nous allons travailler dans 3 comptes ![Eléments d'architecture Breaking Glass](/static/2025/05/breakingglass.webp) ### Compte payeur Dans ce compte, nous allons déployer les SCPs qui auront 2 rôles. Le premier est de limiter au maximum ce que l'on peut faire dans le compte breaking glass, ce qui se résume à utiliser un rôle et à observer les événements sur le compte. La seconde SCP va servir à protéger les règles EventBridge dans les comptes membres. On s'assure ainsi que l'on ne perde pas les alertes. Nous allons déployer également des règles EventBridge au niveau du compte payeur pour détecter toute modification des StackSets liées au Breaking Glass. ### Compte Breaking Glass Nous allons déployer dans un premier temps les utilisateurs et l'observabilité. Quand ces premiers éléments seront en place, nous mettrons en place la SCP qui ne nous permettra plus de faire de modifications sur ce compte. Si à terme nous voulons par exemple ajouter un utilisateur, nous devrons détacher la SCP (ce qui déclenchera une alerte), faire la modification puis réattacher la SCP. Nous permettons aux utilisateurs de modifier leur mot de passe, c'est l'une des rares actions de modifications que nous laissons actives sur ce compte. ### Comptes Membres Dans ces comptes, nous allons déployer un rôle avec des droits administrateur exclusivement à destination des utilisateurs du compte Breaking Glass, des règles EventBridge pour superviser l'utilisation de ce rôle. Tout cela étant protégé par la SCP. ## Étapes de mise en œuvre ![workflow d'activation des activités Breaking Glass](/static/2025/05/breakingGlassWorkflow.webp) ## Entretien et conformité Il est nécessaire de définir exhaustivement et mettre à jour régulièrement la procédure de déclenchement du Breaking Glass. Elle doit inclure les procédures d'activation, les contacts d'urgence, les escalades hiérarchiques et les post-mortems des utilisations passées. Cette documentation doit être stockée de manière redondante et accessible même en cas de défaillance des systèmes principaux. Il est tout aussi important de faire des revues régulières, pour vérifier que tout fonctionne, qu'il n'y ait pas de drift au niveau de [AWS CloudFormation](https://docs.aws.amazon.com/cloudformation/) qui empêcherait par exemple le déploiement du rôle d'administration dans tous les comptes. Les comptes AWS Break Glass doivent faire l'objet de tests réguliers pour garantir leur fonctionnement en cas d'urgence réelle. Ces tests doivent simuler différents scénarios de défaillance et inclure l'ensemble des parties prenantes. Une gestion fine des utilisateurs est aussi nécessaire. Si l'un d'eux vient à quitter la société, il faut immédiatement désactiver son compte et désigner une personne de confiance pour reprendre sa fonction. L'activation d'un compte AWS Break Glass doit suivre un processus rigoureux et documenté. Ce processus commence généralement par une procédure d'escalade impliquant plusieurs niveaux hiérarchiques. La procédure d'activation doit inclure la notification automatique des équipes de sécurité, de la direction technique et des responsables de la gouvernance. Chaque activation doit être documentée avec une justification détaillée, un horodatage précis et l'identification claire du personnel impliqué. À la fin de la procédure d'activation, un résumé des actions doit être créé pour identifier les actions à mener sur le long terme, les correctifs à implémenter selon les normes de la société (Infrastructure as Code), ainsi que tous les commentaires permettant d'éviter la réactivation de ce plan de secours. Ce document doit être partagé avec toutes les parties prenantes. Les comptes AWS Breaking Glass doivent s'aligner avec les frameworks de sécurité utilisés au sein de l'entreprise comme NIST, PCI DSS, HIPAA ou ISO 27001. Il sera donc nécessaire de documenter précisément les procédures, les contrôles d'accès et les mécanismes d'audit. L'écosystème AWS évoluant rapidement, les stratégies de Breaking Glass doivent être régulièrement réévaluées. L'intégration de nouveaux services AWS, l'évolution des menaces de sécurité et les changements organisationnels nécessitent des adaptations continues. ## Observabilité et Auditabilité Le monitoring des AWS Breaking Glass Accounts représente un défi. Chaque action effectuée via ces comptes doit être tracée et enregistrée. Pour l'auditabilité et les actions lancées, nous allons nous reposer sur CloudTrail. Nous partons du principe qu'il est implémenté au niveau de l'organisation, sur tous les comptes et toutes les régions. Nous considérons que les événements sont sauvegardés sur Amazon Simple Storage Service (S3) pour la traçabilité sur le long terme, et que les événements principaux sont audités en quasi temps réel par un SOC (Security Operations Center). Côté Observabilité, nous utilisons EventBridge comme cité précédemment, ce qui permet une grande réactivité. Ce service sera appuyé par des SCPs pour sécuriser la chaîne d'alerte. ## Aspects FinOps Ce compte reste généralement dormant mais doit maintenir des ressources critiques disponibles en permanence. Les coûts restent assez faibles, l'utilisation étant quasi nulle, les FinOps pourraient légitimement vouloir désactiver certaines ressources considérées comme inutiles. Ce compte doit rester hors du processus de nettoyage FinOps, et ne doit être suivi que sur le plan financier, via Cost Anomaly Detection et des alertes Budget par exemple. ## Ce qu'il faut retenir Les AWS Breaking Glass Accounts représentent un élément essentiel de toute stratégie de sécurité cloud mature. Leur implémentation nécessite une approche globale intégrant les aspects techniques, organisationnels et financiers. La mise en œuvre peut sembler complexe, mais elle permettra une plus grande réactivité en cas d'incidents graves. L'investissement dans une stratégie de "Break Glass" bien conçue et régulièrement testée peut faire la différence entre une récupération rapide et une interruption d'activité prolongée lors d'incidents critiques. La vitesse de récupération influe directement sur l'impact business. --- # VPC centralisée ou VPC par compte : quand et pourquoi ? > 2025-04-10T11:00:00.000Z | https://sylvain.bruas.fr/blog/2025/04/sharedvpc Tags: VPC, Reseau, FinOps, Architecture, Securite, Gouvernance, AWS Summary: AWS Vpc centralisée vs vpc dans les comptes – Découvrez les différences, avantages, inconvénients, cas d’usage et meilleures pratiques ![AWS VPC centralisée ou VPC dans les comptes projets : Quand, Pourquoi et Comment ?](/static/2025/04/versus.webp) Bien que le partage d'Amazon Virtual Private Cloud ([VPC](https://docs.aws.amazon.com/vpc/latest/userguide/)) soit disponible depuis fin 2018, il est encore rare de le voir déployé dans les landing zones. Cette possibilité peut apporter de nombreux gains en termes d'organisation et de répartition des tâches entre les équipes, des économies non négligeables, et une implémentation réseau alignée avec le modèle opérationnel de l'entreprise. Nous allons voir ensemble les points qui vont pousser l'adoption de cette implémentation à la place d'une implémentation décentralisée, qui elle est le reflet d'une organisation plus orientée DevOps. ## Les Challenges Les VPCs sont difficilement extensibles, et il est compliqué de réorganiser les ressources qui sont à l'intérieur. Il est donc nécessaire de choisir la bonne implémentation dès la mise en place de la landing zone. Il est également important de n'avoir aucun VPC avec un CIDR block (ensemble d'IP) identique, ce qui rendrait le routage complexe. Dans les grands groupes, une portion importante des [IP privées](https://fr.wikipedia.org/wiki/R%C3%A9seau_priv%C3%A9) ont été consommées. Souvent un CIDR Block /16 est assigné à un cloud provider, ce qui nécessite une réflexion importante pour organiser les VPCs et les subnets. L'organisation de l'entreprise est aussi importante. La responsabilité du réseau peut être assumée par différentes équipes, et il est important que les politiques [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/iam/latest/userguide/) reflètent ces responsabilités. Pour faciliter ces règles IAM, une organisation des comptes AWS rigoureuse est nécessaire. La maîtrise des coûts et la sécurité sont les deux derniers domaines qui influencent l'organisation réseau. Comme nous le verrons plus loin, les liaisons réseaux ont un coût non négligeable et peuvent à l'échelle devenir un problème financier. ## VPC par compte, le modèle par défaut Chaque compte AWS étant indépendant, nous pouvons donc aisément créer une infrastructure réseau indépendante. Un VPC par défaut est fourni dans chaque compte, je vous déconseille de l'utiliser dans votre landing zone. ![VPC in an account](/static/2025/04/VPCperAccount.webp) Il est donc aisé de créer les ressources réseau pour un projet lors de son déploiement. Nous avons un tout cohérent, et si nous devons terminer le projet, nous pourrons détruire toutes les ressources liées. C'est également ce que l'on retrouve sur de nombreux modèles de projet (blueprint). En créant tous les éléments, du réseau à l'application, on s'assure que tous les éléments seront conformes et fonctionnels. Ce modèle est également apprécié car il fait écho à la philosophie DevOps, où l'équipe projet est responsable de son périmètre. ## Modèle centralisé Le but de ce modèle est d'éviter le morcellement de la partie réseau. Dans ce modèle, nous allons créer un nombre limité de VPC, qui se trouveront dans le compte AWS gérant le réseau. Il y aura au moins 2 VPCs, un pour la production et un pour la non-production. Cela permettra de gérer les flux entre ces 2 zones, et rassurera les équipes sécurité. Le modèle de sous-réseau (Subnets) sera le même que pour le modèle décentralisé, c'est la taille de ces subnets qui sera supérieure. Ces subnets seront ensuite partagés avec les comptes projets pour qu'ils puissent les utiliser. Ce modèle reflète le modèle opérationnel où les équipes réseau et sécurité sont responsables des fondations réseau. Les équipes projets ne sont qu'utilisatrices des ressources mises à disposition et vont créer les ressources projets dans les sous-réseaux fournis sans pouvoir modifier leur fonctionnement. ![VPC Centralisée](/static/2025/04/VPC-centralisee.webp) ## Critères de sélection Plusieurs critères entrent en compte, les plus impactants sont en premier : #### Besoin de contrôle et de conformité lié à des contraintes légales Si la séparation des responsabilités est un prérequis et que le réseau est géré par une équipe spécialisée, un modèle centralisé est la solution à privilégier. Chaque projet aura son compte AWS, mais ils ne pourront pas créer de composants réseau au sein de ces comptes. Si la responsabilité du réseau est portée par le projet et non par une équipe centrale, un modèle décentralisé sera le meilleur choix. Il faudra néanmoins déployer des outils permettant de vérifier la conformité à l'échelle. Ces outils devront être capables de récupérer et d'agréger des données venant de nombreux comptes. #### Modèle opérationnel et responsabilité des équipes Les mêmes arguments que la partie précédente sont à utiliser pour choisir le modèle. La seule différence est que ce n'est pas un besoin externe qui impose le choix, mais le fonctionnement de l'entreprise. Il faut rester vigilant sur ce choix et penser à la transformation de l'entreprise en passant dans le cloud et la trajectoire pour les prochaines années. Vous pouvez avoir un modèle centralisé car vous êtes en cours de migration depuis le on-premise, mais la stratégie d'entreprise est de devenir plus agile en laissant les projets porter leur responsabilité de bout en bout. Dans ce cas, un modèle décentralisé sera à privilégier, avec un accompagnement des équipes opérations / sécurité / réseau pour leur permettre d'évoluer et de s'inscrire dans le nouveau modèle opérationnel. #### Maîtrise des coûts Un modèle décentralisé repose sur l'utilisation de la [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/) pour passer à l'échelle. Mais ce modèle a un coût non négligeable, lié au nombre de VPC qui vont être créés. Si la consommation de services AWS par VPC est faible (moins de 250$ par exemple, dans ce cas le réseau représente plus de 20% des dépenses), il est intéressant d'évaluer la possibilité de passer sur un modèle centralisé. Un modèle décentralisé permettra également de plus facilement répartir les coûts par projets. Les ressources n'étant pas mutualisées et un compte AWS n'étant lié qu'à un projet, la somme des consommations par projet sera donc aisée. #### Maturité de la société sur AWS Si vous débutez sur AWS et que vous migrez depuis le on-premise, un modèle centralisé peut être rassurant car plus proche de ce que vous avez on-premise. Si vous êtes une société en création, que vous voulez être agile et que vous n'avez pas une équipe réseau dédiée, un modèle décentralisé vous apportera plus de souplesse. Cela vous permettra par exemple de proposer de nouveaux produits, et s'ils ne trouvent pas leur public, vous n'aurez qu'à détruire le ou les comptes AWS associés pour ne plus avoir de dépenses. #### Gestion des IPs Si la gestion des IPs est un enjeu, et que chaque IP compte car votre entreprise a consommé presque toutes les possibilités d'adressage IP privé, il est recommandé de passer sur un modèle centralisé qui permettra de ne perdre que très peu d'IPs. Si votre SI est d'une taille modeste, les 2 modèles peuvent être utilisés, ce sont d'autres critères qui guideront vos choix. #### Isolation forte des projets Si vous devez isoler fortement des projets, par exemple si vous offrez une plateforme SaaS pour des clients, il est recommandé d'utiliser un modèle décentralisé. Les ressources réseau et projets de chaque client seront isolés dans un compte AWS, et vous pourrez également ajouter du filtrage réseau au niveau de la Transit Gateway. ## Mise en place de la VPC centralisée ### Organisation des VPCs Nous pouvons organiser les VPCs de différentes manières. La première solution, la plus simple, est de faire une VPC pour la production et une autre pour la non-production. L'avantage est que les IPs pour la production sont réservées, nous pouvons contrôler les flux entre les deux VPCs. La seconde solution est de faire un VPC par environnement. Cela permet un meilleur contrôle des flux est-ouest, et une garantie d'un nombre d'IP par environnement. Nous ajouterons une VPC supplémentaire pour les outils réseau comme les points de terminaison VPC (VPC Endpoints), la gestion DNS ou la gestion de l'Egress, quelle que soit la solution proposée. Ainsi, nous mutualisons les coûts des VPC Endpoints et de l'Egress. Les VPCs doivent être suffisamment grandes pour répondre à vos besoins en IP pour les années à venir. Il est possible d'étendre une VPC, mais cela reste une opération qui va ajouter de la complexité à votre landing zone. #### Exemple Vous avez 4 environnements : production, recette, intégration et développement. Vous avez à disposition un CIDR block 10.0.0.0/16 _Première solution_ - un VPC de production 10.0.0.0/18 - un VPC de non-production (recette, intégration et développement) 10.0.128.0/17 - il reste 10.0.64.0/18 pour les VPCs réseau, sandbox, ou les services partagés | VPC | Subnet address | Range of addresses | | -------------- | -------------- | ------------------------- | | production | 10.0.0.0/18 | 10.0.0.0 - 10.0.63.255 | | non-production | 10.0.128.0/17 | 10.0.128.0 - 10.0.255.255 | | autre | 10.0.64.0/18 | 10.0.64.0 - 10.0.127.255 | _Seconde solution_ - un VPC de production : 10.0.0.0/19 - un VPC de recette (iso prod) : 10.0.64.0/18 - un VPC d'intégration : 10.0.128.0/19 - un VPC de développement : 10.0.160.0/19 - il reste 10.0.192.0/18 pour les VPCs réseau, sandbox, ou les services partagés | VPC | Subnet address | Range of addresses | | ------------- | -------------- | ------------------------- | | production | 10.0.0.0/18 | 10.0.0.0 - 10.0.63.255 | | recette | 10.0.64.0/18 | 10.0.64.0 - 10.0.127.255 | | intégration | 10.0.128.0/19 | 10.0.128.0 - 10.0.159.255 | | développement | 10.0.160.0/19 | 10.0.160.0 - 10.0.191.255 | | autre | 10.0.192.0/18 | 10.0.192.0 - 10.0.255.255 | ### Partage des subnets Nous avons plusieures stratégies pour le partage des subnets. #### 1 - Centralisation des VPCs dans le compte réseau C'est le modèle le plus simple, la séparation en VPC projet est conservée, la différence est que les VPCs se trouvent dans le compte réseau. L'avantage de cette technique est qu'elle simplifie la gestion IAM pour le réseau, on s'assure ainsi que les projets ne pourront pas modifier les fondations mises en place. ![Centralisation des VPCs dans le compte réseau](/static/2025/04/SharedVPC-Partage-Subnet-sol3.webp) #### 2 - Un seul VPC, des subnets indépendants pour chaque compte Ce modèle assure une isolation stricte entre les comptes, car chaque subnet est lié à un seul compte AWS. Ainsi il n'y a pas de risque de manque d'IP venant d'un autre projet, les coûts d'interconnexions sont réduits car on a moins de VPCs. Pour assurer une isolation parfaite, il est recommandé d'ajouter des listes de contrôle d'accès réseau (NACL) aux sous-réseaux pour ne laisser passer que les flux venant de sous-réseaux légitimes. Cela ne facilite toujours pas suffisamment la gestion des adresses IP. Nous avons toujours des adresses IP utilisées dans chaque sous-réseau, et si nous n'avons plus d'adresses IP disponibles sur un sous-réseau, il faudra utiliser un nouveau sous-réseau pour étendre la plage d'adresses IP. Cela nécessite encore de trouver la ou les bonnes tailles de sous-réseaux pour les projets, afin de réduire le nombre d'adresses IP non utilisées. ![Un seul VPC, des subnets indépendants pour chaque compte](/static/2025/04/SharedVPC-Partage-Subnet-sol1.webp) #### 3 - Un seul VPC, des sous-réseaux partagés entre tous les comptes d'un même environnement Dans cette solution, nous avons un petit nombre de sous-réseaux de grande taille partagés entre les comptes. L'isolation est en place par design, nous le verrons un peu plus bas, et avec ce modèle nous obtenons une zone de travail où aucune IP ne sera potentiellement inutilisée, et il n'est plus nécessaire de réfléchir longuement à la taille de chacun des sous-réseaux. Tout comme la solution précédente, le nombre d'interconnexions réseau est réduit au strict minimum pour maîtriser les coûts. ![Un seul VPC, des subnets partagés entre tous les comptes d'un même environnement](/static/2025/04/SharedVPC-Partage-Subnet-sol2.webp) ### Responsabilité partagée Comme nous l'avons vu plus haut, le modèle de VPC doit refléter le modèle de responsabilité entre les équipes. AWS a fait le nécessaire au niveau des droits, pour que cette séparation soit claire. Source : [Responsibilities and permissions for owners and participants](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-share-limitations.html) #### Responsabilité du compte qui partage - Il est responsable de la **création**, de la **gestion** et de la **suppression** des **ressources associées à un VPC partagé** (sous-réseaux, tables de routage, passerelles NAT, etc.). La liste complète est disponible dans la documentation, et l'on peut vérifier que ce ne sont que des composants de réseau, sécurité et routage qui peuvent être gérés. - il **ne peut pas modifier les interfaces réseau** appartenant aux participants (attacher, détacher...). Les interfaces sont visibles dans le compte qui partage, ce qui a du sens car les interfaces utilisent les IPs du compte. Les informations sont limitées, on ne sait rien sur la ressource liée. - il peut **visualiser les [groupes de sécurité](https://docs.aws.amazon.com/fr_fr/vpc/latest/userguide/vpc-security-groups.html)** créés par les participants. Le principe d'observabilité est respecté, et les responsables du réseau et de la sécurité peuvent examiner facilement ce qui est implémenté. Dans l'exemple ci-dessous, nous pouvons voir des groupes de sécurité liés à d'autres comptes avec la mention **shared** entre parenthèses. Exemple : ![Groupe de sécurité](/static/2025/04/security-group.webp) - il peut **attacher une passerelle de transit** à un sous-réseau VPC partagé. Le principe de responsabilité est bien respecté, et cela évite des dérives de sécurité (cartographie des flux) et financières (prix de l'attachement, coûts de trafic) #### Responsabilité des comptes qui utilisent le partage - ils sont **responsables des ressources VPC dont ils sont propriétaires**. Tout est dit, on respecte bien le modèle de responsabilité partagée entre le compte qui partage et les comptes qui utilisent les sous-réseaux - ils ne peuvent **créer qu'un ensemble limité de ressources VPC** : groupes de sécurité, journaux de flux VPC (sur leurs interfaces réseau). - Les **ressources VPC créées** par un participant sont **comptabilisées dans les quotas VPC du compte participant**. - Les participants ne peuvent pas **créer, attacher ni supprimer de passerelles Internet**. Cela nous assure qu'il n'y aura pas d'exposition publique incontrôlée. - Les participants **ne peuvent pas créer ni supprimer de NAT Gateway**. On évite ainsi des coûts non maîtrisés (35$ par mois). Ce sont des éléments de routage que les équipes réseaux doivent mettre en place, que les NAT Gateway soient privées ou publiques. Les équipes projet ne sont qu'utilisatrices de ces services. - Les participants ne peuvent pas **créer, supprimer ni remplacer** de listes de contrôle d'accès réseau (**NACL**) La sécurité du réseau est la responsabilité des équipes réseau et sécurité. Personne dans le compte participant ne pourra unilatéralement modifier des règles de filtrage réseau. - Les participants peuvent **visualiser les NACL** Le filtrage mis en place peut être visualisé par l'équipe projet (transparence) et peut ainsi permettre de comprendre pourquoi certains composants ne peuvent pas communiquer ensemble. Cela évite des frustrations et peut faciliter le travail des équipes réseau qui pourront avoir des indications claires des équipes projet. - Les participants ne peuvent pas travailler sur des tables de routage (par exemple, **créer, supprimer ou associer des tables de routage**) Tous les éléments réseau sont bien gérés pour que le partage de responsabilité soit respecté par défaut. - Les participants **ne peuvent pas utiliser le groupe de sécurité par défaut du VPC** Ce n'est pas une bonne pratique d'utiliser le groupe de sécurité par défaut d'un VPC. La bonne pratique est de laisser ce groupe de sécurité sans règle, ce qui bloque tout le trafic entrant et sortant. Donc ne pas pouvoir utiliser ce groupe de sécurité ne posera pas de problème. - Les participants **ne peuvent pas utiliser de groupes de sécurité qui appartiennent au propriétaire du VPC ou à d'autres participants**, à moins que le groupe de sécurité ne soit partagé avec eux. Les règles des groupes de sécurité peuvent référencer un groupe de sécurité d'un autre compte. Ce qui permet de gérer via des noms les flux entre les applications. Il est nécessaire d'interdire l'utilisation d'un groupe de sécurité extérieur au compte car les règles liées à celui-ci pourraient être changées sans que le compte qui l'utilise soit informé. ### Répartition des coûts Dans un VPC partagé, chaque participant paie ses ressources applicatives. Ils paient également les frais de transfert de données entre zones de disponibilité, via les passerelles Internet et les passerelles [AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/userguide/). Les propriétaires de VPC paient des frais horaires ainsi que des frais de traitement et de transfert de données via les passerelles NAT, la Transit Gateway, [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/) et les points de terminaison VPC. Les adresses IPv4 publiques utilisées dans les VPC partagés sont facturées aux propriétaires de VPC. ## Limites et points d'attention ### Tags - Les tags des groupes de sécurité créés dans un compte ne sont pas visibles dans les autres comptes. Nous ne pouvons pas profiter nativement des informations originales. Nous pouvons recréer de nouveaux tags sur ces groupes de sécurité et leurs règles dans le compte utilisant le sous-réseau via une [AWS Lambda](https://docs.aws.amazon.com/lambda/) par exemple. Exemple : - dans le compte utilisant un sous-réseau partagé : ![Groupe de sécurité 2](/static/2025/04/security-group2.webp) - dans le compte qui partage le sous-réseau : ![Groupe de sécurité 3](/static/2025/04/security-group3.webp) ### Modèle centralisé et zones de disponibilité Dans le modèle centralisé, comme le trafic ne quitte pas le VPC, vous ne payez pas de frais de réseau supplémentaires, mais uniquement les éventuels frais de réseau inter-zones. Il est important de noter que tous les comptes AWS disposent d'un mappage de zones de disponibilité aléatoire. Ainsi, la zone de disponibilité A du compte A peut être la zone de disponibilité B du compte B. Lors de l'utilisation d'un VPC partagé, il est important d'en tenir compte pour limiter les frais de réseau inter-zones. Une bonne utilisation des tags peut réduire ces coûts en nommant de manière claire les sous-réseaux en s'appuyant sur l'ID de zone de disponibilité. ### Que se passe-t-il si le partage est coupé ? Le propriétaire peut à tout moment annuler le partage d'un sous-réseau partagé. Une fois le partage d'un sous-réseau annulé, les règles suivantes s'appliquent : - Les ressources existantes des participants continuent de s'exécuter dans le sous-réseau. - Les participants ne peuvent plus créer de ressources dans le sous-réseau. - Les participants peuvent modifier, décrire et supprimer leurs ressources. - Si des participants disposent encore de ressources dans le sous-réseau, le propriétaire ne peut pas supprimer le sous-réseau partagé ni le VPC du sous-réseau partagé. ## Pour conclure Ces deux modèles sont complémentaires et répondent chacun à des besoins spécifiques. Vous pouvez également appliquer chacun de ces modèles à une partie de votre système d'information. Si vous avez par exemple des applications que vous voulez déplacer à partir du on-premise et que vous ne pouvez pas transformer, vous pouvez les héberger sur un VPC centralisé. Pour les nouveaux projets, vous pouvez utiliser un modèle décentralisé qui apporte plus de souplesse aux équipes de développement. Il est important de choisir le modèle qui correspond à vos besoins (légaux, opérationnels, ...), qui soit efficace et aligné avec votre savoir-faire, plutôt que d'utiliser un modèle à la mode qui, au final, vous amènera à des coûts élevés et à des opérations plus complexes et coûteuses. --- # AWS CloudFront VPC Origin : sécurisez vos sites publics > 2025-02-20T11:00:00.000Z | https://sylvain.bruas.fr/blog/2025/02/cloudfront-vpc-origin-private Tags: Cache, Load Balancing, VPC, Securite, Gouvernance, AWS Summary: AWS CloudFront VPC Origins : gardez votre infrastructure privée. Connectez CloudFront à vos ressources VPC sans exposition publique pour plus de sécurité. ![AWS CloudFront Amazon Virtual Private Cloud (VPC) Origin : Sécurisez et Optimisez vos sites web publics](/static/2025/02/forteresse.webp) [Amazon CloudFront](https://docs.aws.amazon.com/cloudfront/) est l'un de mes services AWS préférés. Grâce à cet outil, nous pouvons exposer des sites sur Internet, qu'ils soient statiques ou dynamiques, hébergés ou non sur AWS, avec une sécurité renforcée. Grâce à son déploiement au plus près de l'utilisateur, depuis 2008 ce service permet de distribuer le contenu avec les meilleures performances. Pour mettre du contenu à disposition de CloudFront, nous avons 2 possibilités principales : - Utiliser [Amazon Simple Storage Service (S3)](https://docs.aws.amazon.com//s3) ou [AWS Lambda](https://docs.aws.amazon.com//lambda) par exemple en utilisant les **Origin Access Control** - Utiliser un équilibreur de charge (Load Balancer) ou une instance publique. ![Exposition du contenu d'un bucket S3 via CloudFront](/static/2025/02/image1.webp) ![Exposition d'un service web hébergé sur une instance [Amazon Elastic Compute Cloud (EC2)](https://docs.aws.amazon.com//ec2) via CloudFront](/static/2025/02/image2.webp) Dans la suite de l'article, nous allons nous concentrer sur le cas de l'équilibreur de charge public. Les groupes de sécurité (Security Groups) doivent être bien configurés pour ne permettre l'accès que depuis CloudFront. Des protections supplémentaires peuvent être mises en place comme un [AWS Web Application Firewall (WAF)](https://docs.aws.amazon.com//waf) par exemple, qui offre une protection avancée contre les attaques web, mais ceci engendre des coûts additionnels. Il est possible également d'utiliser un header pour identifier notre distribution CloudFront, mais cette technique ne protège pas contre les tentatives de connexions. Elles sont arrêtées au plus tôt au niveau de l'ALB, mais elles polluent les logs et peuvent impacter les performances. Voici un exemple de règle de groupe de sécurité permettant un accès uniquement via CloudFront en HTTPS : | Type | Protocol | Port | Source | | :---- | :------- | :--- | :---------------------------------------------------------- | | HTTPS | TCP | 443 | pl-4fa04526 (com.amazonaws.global.cloudfront.origin-facing) | Ces points d'accès peuvent être découverts via un scan d'IP systématique ou en listant les sous-domaines d'une entrée DNS, et être la cible d'attaques malveillantes (DDoS, DoS, tentative d'exploitation de faille etc.). Si l'instance EC2 derrière le load balancer a un serveur web avec une faille de sécurité critique et que le groupe de sécurité en amont permet du trafic ne venant pas de CloudFront, votre instance et par extension votre [Amazon Virtual Private Cloud (VPC)](https://docs.aws.amazon.com/vpc/) pourraient être compromis. Exemple de règle trop permissive : | Type | Protocol | Port | Source | | :---- | :------- | :--- | :-------------------------------------------------- | | HTTPS | TCP | 443 | **0.0.0.0/0** | ![Une source cloudfront qui se fait attaquer ](/static/2025/02/image3.webp) Le meilleur moyen d'éviter cela est de garder la source de CloudFront privée, ce qui est possible depuis le 20 novembre 2024 avec les origines VPC sécurisées. Nous pouvons ainsi enlever la partie publique de nos VPCs, et nous pouvons également bloquer l'accès public aux VPCs de manière systématique ( [https://docs.aws.amazon.com/fr_fr/vpc/latest/userguide/security-vpc-bpa.html](https://docs.aws.amazon.com/fr_fr/vpc/latest/userguide/security-vpc-bpa.html) ). ![Utilisation de CloudFront VPC Origin pour utiliser un load balancer privé comme source](/static/2025/02/image4.webp) Avec cette architecture, nous réduisons également le besoin d'IPs privées par VPC en enlevant les subnets publics, ce qui est un premier point intéressant pour certaines compagnies où l'adressage privé est un sujet critique. Nous remplaçons le load balancer public par un privé, ce qui réduit la surface d'exposition de manière significative. S'il y avait déjà un load balancer privé qui exposait ce service, nous faisons donc une petite économie en enlevant un composant redondant. Une question demeure. En modifiant cette architecture, est-ce que nous modifions les performances de notre service ? Nous allons le vérifier en mettant en place une page Nginx sur une instance EC2 t3.micro à Singapour, et en testant les performances à partir de nos locaux (Lyon - France) ainsi que d'une session [CloudShell](https://docs.aws.amazon.com//cloudshell) se trouvant en Irlande. Ce serveur Nginx sera exposé par un Load Balancer public et également via une VPC origin sur CloudFront. Dans un premier temps, nous n'activerons pas le cache en périphérie pour avoir des résultats objectifs (Si nous l'activions, le contenu ne serait plus récupéré sur le serveur Nginx à Singapour, mais sur l'edge CloudFront le plus proche contenant une copie). Nous ferons une dernière série de tests avec le cache activé, pour montrer l'efficacité d'un cache CloudFront bien configuré avec TTL standard quand on accède à des données qui sont très éloignées. ![Différentes requêtes pour récupérer le contenu](/static/2025/02/image6.webp) Nous allons donc effectuer 10 appels curl successifs et synchronisés à la suite pour avoir quelques statistiques intéressantes et fiables (Moyenne, Max, P90, Latence...). Voici le résultat détaillé de nos tests : Temps total (mesures complètes) | | Req1 | Req2 | Req3 | Req4 | Req5 | Req6 | Req7 | Req8 | Req9 | Req10 | | :--------------- | :----------- | :----------- | :----------- | :----------- | :----------- | :----------- | :----------- | :----------- | :----------- | :----------- | | Irlande CloudFront | 0.394960s | 0.191579s | 0.194875s | 0.189899s | 0.191891s | 0.207810s | 0.193402s | 0.205370s | 0.197298s | 0.368063s | | Irlande ALB | 0.364543s | 0.367283s | 0.363094s | 0.366604s | 0.359450s | 0.362647s | 0.361881s | 0.365909s | 0.365682s | 0.365236s | | Lyon CloudFront | 0.407051s | 0.211910s | 0.238359s | 0.201906s | 0.369832s | 0.201490s | 0.206589s | 0.218557s | 0.542900s | 0.202360s | | Lyon ALB | 0.361772s | 0.322014s | 0.322883s | 0.317526s | 0.315286s | 0.317379s | 0.318128s | 0.316579s | 0.321974s | 0.324912s | | Lyon CloudFront + cache | 0.442350s | 0.043860s | 0.034697s | 0.043316s | 0.035482s | 0.041478s | 0.046235s | 0.033241s | 0.036595s | 0.029393s | | | Moyenne (sec) | Plus longue (sec) | Plus rapide (sec) | P90 (percentile) | | :---------------------- | :------------------------------------------------- | :------------------------------------------------ | :------------------------------------------------ | :-------------------------------------------------- | | Irlande CloudFront | 0.2335147s | 0.39496s | 0.189899s | 0.21557633s | | Irlande ALB | 0.3642329s | 0.367283s | 0.35945s | 0.363894s | | Lyon CloudFront | 0.2800954s | 0.5429s | 0.20149s | 0.25089489s | | Lyon ALB | 0.3238453s | 0.361772s | 0.315286s | 0.31963122s | | Lyon CloudFront + cache | 0.0786647s | 0.44235s | 0.029393s | 0.03825522s | Comme on peut le voir, les performances sont meilleures en passant par CloudFront, ce qui s'explique aisément par le fait que la requête qui arrive sur CloudFront au plus près de l'utilisateur est ensuite envoyée via les backbones AWS vers la bonne ressource (chemin 1-2-3 et 21-22-23) sur le schéma suivant, optimisant ainsi le temps de latence global.\ \ Dans le cas de l'ALB, on effectue une résolution DNS, puis on passe par internet pour joindre la ressource (chemin 10-11 et 31-32). Nous passons par des ressources publiques et par plusieurs relais que nous ne maîtrisons pas, ce qui allonge les délais de réponses et peut introduire une variabilité importante. Comme on peut le voir dans les résultats, utiliser le cache CloudFront à la périphérie est la solution la plus performante, ce qui n'est pas une surprise étant donné que le trajet est beaucoup plus court (chemin 1-2 seulement) et bénéficie de l'infrastructure optimisée d'AWS. ![Différents chemins utilisé par nos requêtes pour récuprer les données](/static/2025/02/image5.webp) La solution via CloudFront et VPC Origin n'est donc pas seulement plus sécurisée, mais aussi plus performante qu'une exposition via un ALB, grâce à la mise en cache globale. Cette solution est très efficace pour les sites Internet ou l'exposition de contenu de taille importante. Si vous exposez une API via votre ALB, cette solution peut néanmoins devenir coûteuse. Le modèle de facturation de CloudFront étant basé sur les données sortantes ET sur le nombre de requêtes. Dans le cas d'une API, il y a de très nombreuses petites requêtes, ce qui peut rendre l'exposition via CloudFront plus coûteuse que via un ALB classique. On peut donc dire que les VPC Origins pour CloudFront apportent une nouvelle façon d'exposer le contenu, en ajoutant une seconde couche de protection contre les mauvaises manipulations et les attaques externes. Même si vous définissez une règle en 0.0.0.0/0 pour le HTTP(S) dans votre Security Group, vos ressources étant en privé, elles resteront inaccessibles via Internet. Si vous n'avez pas encore ajouté CloudFront en première ligne de votre exposition Internet, je vous engage à le faire rapidement. Vous pourrez ainsi profiter de performances réseau accrues et d'une sécurité renforcée. --- # Accès centralisé aux comptes racine pour votre organisation AWS > 2025-01-10T11:00:00.000Z | https://sylvain.bruas.fr/blog/2025/01/centralizerootaccess Tags: Securite, Gouvernance, AWS Summary: Renforcez la sécurité AWS en centralisant l'accès root. Stratégies pour réduire les comptes racine accessibles et maintenir la gouvernance multi-comptes. ![Accès centralisé aux comptes racine pour votre organisation AWS](/static/2025/01/root-ring.webp) Chaque responsable de [landing zone AWS](https://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/migration-aws-environment/understanding-landing-zones.html) cherche à réduire la surface d'attaque pour protéger au mieux les systèmes d'information. Une des ressources critiques de la landing zone est le compte racine associé à chaque compte AWS. Les comptes AWS, même intégrés dans une [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html), possèdent chacun un [compte racine](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html). Ces comptes racine étaient indispensables pour effectuer certaines [opérations critiques](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks), comme par exemple lors de la configuration initiale du compte et pour débloquer des buckets [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/fr_fr/AmazonS3/latest/userguide/Welcome.html), des queues [Amazon Simple Queue Service (SQS)](https://docs.aws.amazon.com/fr_fr/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html). Ces opérations, qui doivent rester le plus rare possible, nécessitaient l'utilisation du compte racine et la récupération du dispositif [MFA](https://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/id_credentials_mfa.html) physique dans le coffre de l'entreprise. Ces démarches fastidieuses pour se connecter au compte racine étaient nécessaires pour assurer la sécurité. Elles n'étaient pas suffisante pour totalement protéger le compte AWS, car un collaborateur utilisant le compte racine peut effectuer n'importe quel appel API de services AWS, ce qui représente un risque élevé. Depuis mi-novembre 2024, AWS propose une nouvelle méthode pour simplifier ces [opérations](https://aws.amazon.com/fr/about-aws/whats-new/2024/11/manage-root-access-aws-identity-access-management/) via l'accès racine centralisé. Il n'est plus nécessaire de récupérer le mot de passe du compte racine de chaque compte membre de l'organisation. Les opérations de [déblocage de bucket S3](https://repost.aws/knowledge-center/s3-accidentally-denied-access) ou de [file d'attente SQS](https://repost.aws/knowledge-center/sqs-queue-access-issues-deny-policy) peuvent être initiées par un utilisateur [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/iam/) ayant les autorisations nécessaires sur un compte membre. La gestion de la récupération du mot de passe racine est maintenant centralisée au niveau du compte payeur. ![Avant après la centralisation des comptes racine](/static/2025/01/centralroot.webp) En utilisant cette méthode, nous pouvons réduire la surface d'attaque et simplifier le modèle opérationnel pour résoudre les erreurs liées à IAM, SQS et S3. Cette méthode permet également de réduire la charge de travail lors du départ d'un administrateur des comptes AWS. ![Départ dun administrateur](/static/2025/01/centralroot-2.webp) ## Notre environnement pour cet article Nous disposons d'une organisation existante avec plusieurs comptes membres pour lesquels nous avons configuré un mot de passe pour chaque compte racine ainsi que l'authentification multi-facteurs (MFA). Un nouveau compte Sandbox nommé **Sandbox Sylvain** a été créé, mais nous ne nous y sommes jamais connectés. Nous avons également un compte [Breaking Glass](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/break-glass-access.html) avec quelques utilisateurs IAM de secours nous permettant de nous connecter si AWS Identity Center ne fonctionne plus comme attendu. ![Organization pour le test](/static/2025/01/centralroot-3.webp) ## Mise en place La première étape est d'activer l'accès centralisé aux comptes racine au niveau du compte payeur de votre organisation. Cette fonctionnalité se trouve au niveau d'IAM si vous passez via la console, vous pouvez également faire cette opération via la CLI. Pour effectuer cette première étape, vous devez avoir [les autorisations suivantes](https://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/id_root-enable-root-access.html) : ```shell iam:EnableOrganizationsRootCredentialsManagement iam:EnableOrganizationsRootSessions organizations:RegisterDelegatedAdministrator organizations:EnableAwsServiceAccess ``` ### Via la CLI ```shell > aws iam enable-organizations-root-credentials-management > aws iam enable-organizations-root-sessions ``` ### Via la console Nous allons dans le service IAM puis cliquer sur le menu de gauche sur le lien **Root Access Management** ![Root Access Management](/static/2025/01/root-1.webp) Nous allons utiliser notre compte Breaking Glass comme compte administrateur délégué. Ainsi, nous pourrons non seulement intervenir sur les comptes membres en cas de problème avec nos comptes IAM Breaking Glass, mais en dernier recours, nous pourrons également recréer des identifiants pour le compte racine des comptes membres. Pour maintenir une observabilité maximale sur ce compte Breaking Glass, nous ajouterons de nouvelles alarmes liées aux nouvelles possibilités offertes à nos utilisateurs IAM. ![Root Access Management 2e écran](/static/2025/01/root-2.webp) Nous voyons maintenant la section **Centralized root access for member accounts** activée. ![Root Access Management résultat](/static/2025/01/root-3.webp) En cliquant de nouveau sur **Root Access Management**, vous obtenez la liste des comptes, avec l'indication de la présence ou non d'accès racine. Dans notre cas, le compte Breaking Glass bénéficie de cette fonctionnalité, tandis que les autres comptes ont toujours les accès racine activés. ![Root Access Management liste des comptes](/static/2025/01/root-4.webp) ## Validation de la mise en place Nous n'avons pas encore récupéré le mot de passe pour le compte racine sur le compte **Sandbox Sylvain**. Nous allons maintenant vérifier que tout cela fonctionne comme attendu, c'est à dire avoir un message d'erreur lors du processus de récupération du mot de passe. Essayons de faire un [reset du mot de passe](https://docs.aws.amazon.com/IAM/latest/UserGuide/reset-root-password.html). Rien ne change pour la demande d'oubli du mot de passe et l'envoi de l'email se fait sans problème. ![Validation étape 1](/static/2025/01/valide-1.webp) ![Validation étape 2](/static/2025/01/valide-2.webp) ![Validation étape 3](/static/2025/01/valide-3.webp) Quand nous utilisons le lien, nous avons un message nous indiquant la désactivation de la fonctionnalité, comme attendu. ![Validation étape 4](/static/2025/01/valide-4.webp) Il ne reste plus qu'à retirer les accès au compte racine sur tous les comptes membre de l'organisation. Vous pouvez le faire via la console ou la CLI. ## Utilisation de assumeRoot et moindre privilège Même si l'utilisation de l'API assumeRoot est limitée aux politiques IAM suivantes, il est nécessaire de restreindre son utilisation car avec IAMCreateRootUserPassword, nous pourrions réaliser une élévation de privilèges. Liste des [politiques disponibles](https://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/id_root-enable-root-access.html) : ```shell IAMAuditRootUserCredentials IAMCreateRootUserPassword IAMDeleteRootUserCredentials S3UnlockBucketPolicy SQSUnlockQueuePolicy ``` Nous allons donc répartir les droits entre deux profils d'utilisateurs : | Administrateurs de comptes AWS | Opérateurs | | ------------------------------ | -------------------- | | IAMAuditRootUserCredentials | S3UnlockBucketPolicy | | IAMCreateRootUserPassword | SQSUnlockQueuePolicy | | IAMDeleteRootUserCredentials | | Seuls les administrateurs d'Identity Center et de comptes AWS sont habilités à accorder les droits de connexion sur le compte racine. Ce sont eux également qui gèrent les comptes "breaking glass" et qui appliqueront les mêmes politiques sur ces comptes IAM de secours. Nous allons créer un permset dédié aux opérateurs, que nous allons appeler UnlockS3SQS. Nous avons délégué la gestion de IAM identity center au compte breaking glass, nous allons donc utiliser celui-ci pour la connexion des Administrateurs et des Opérateurs. Exemple de politique suivant le principe du moindre privilège pour permettre la gestion des comptes racines par les opérateurs via la console AWS et la CLI : ```shell { "Version": "2012-10-17", "Statement": [ { "Sid": "Statement1", "Effect": "Allow", "Action": [ "organizations:DescribeOrganization", "organizations:ListAccounts", "organizations:ListChildren", "sts:AssumeRoot", "organizations:ListAWSServiceAccessForOrganization", "organizations:ListDelegatedAdministrators", "organizations:ListOrganizationalUnitsForParent", "organizations:ListParents", "organizations:ListRoots", "organizations:ListAccountsForParent", "organizations:DescribeAccount", "organizations:DescribeOrganizationalUnit", "iam:ListOrganizationsFeatures" ], "Resource": "*" } ] } ``` Nous allons interdire la réactivation du compte racine des comptes membres via une [Service control Policy](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) (SCP). Si un adminitrateur de compte AWS doit rétablir un compte racine, il devra donc desactiver la SCP sur le compte cible avant tout autre opération. SCP pour bloquer la réactivation d'un compte racine : ```shell { "Version": "2012-10-17", "Statement": [ { "Sid": "Statement2", "Effect": "Deny", "Action": [ "iam:CreateLoginProfile" ], "Resource": "*", "Condition": { "ForAnyValue:Bool": { "aws:AssumedRoot": "true" } } } ] } ``` ## Réflexions sur la gouvernance Nous réduisons notre surface d'attaque grâce à la centralisation des accès aux comptes racine. Bien que les tentatives de force brute soient déjà compliquées avec les mécanismes de protection sur le formulaire de récupération de mot de passe, rien n'est plus efficace que la désactivation d'une fonctionnalité. Le cycle de vie et la protection des mots de passe des comptes racines sont ainsi réduits à un seul élément à gérer. En cas de départ d'un gestionnaire de la landing zone, il suffit de modifier un seul mot de passe pour s'assurer que seules les personnes habilitées auront accès aux comptes racines. Cette première ligne de défense est donc maintenant plus facile à gérer, elle restera renforcée par le MFA physique stocké dans un coffre, dont les gestionnaires de la landing zone n'ont pas le code. Il n'y a plus d'opérations courantes nécessitant l'utilisation du compte racine et la récupération du MFA associé. Un compte IAM supervisé est suffisant, et cette fonctionnalité ne permet qu'une liste FINIE d'actions strictement nécessaires. Nous pouvons suivre l'utilisation aisément via [AWS CloudTrail](https://docs.aws.amazon.com/cloudtrail/), tout en maintenant le même niveau d'observabilité. ## Conclusion L'utilisation de cette méthode améliore la sécurité de votre landing zone. Vous pourriez constater une baisse transitoire de votre score sur certains frameworks de sécurité. Cette fonctionnalité étant assez récente, elle n'est pas encore prise en compte et pourrait être considérée comme un compte racine sans MFA pour le protéger. Par exemple, [Scoutsuite](https://github.com/nccgroup/ScoutSuite) considère qu'il n'y a pas de MFA associé au compte racine. Au moment de la rédaction de cet article, aucune pull request n'est ouverte pour corriger ce point. Comme nous l'avons vu tout au long de cet article, l'accès au compte racine centralisé apporte une grande facilité de gestion, mais il faut rester prudent. L'API IAMCreateRootUserPassword pourrait permettre une élévation de privilèges. Une étude des impacts sur la sécurité est donc indispensable, et le respect de la séparation des responsabilités ainsi que du principe du moindre privilège est nécessaire pour réduire les risques. --- # Re:Invent 2024 : Les annonces du troisième et quatrième jour > 2024-12-05T11:00:00.000Z | https://sylvain.bruas.fr/blog/2024/12/Reinvent-2024-jour-3 Tags: Re:Invent, AWS Summary: AWS re:Invent 2024 jours 3-4 : GenAI Index, AWS Sovereignty, Bedrock Knowledge Bases et Data Automation. ![Re:Invent2024](/static/images/reinvent.webp) ## Les 3 nouvelles les plus marquantes pour Anda : ## Les 3 nouvelles les plus marquantes pour moi : ## Les autres annonces qui vont apporter de la valeur dans nos architectures : ### Amazon Bedrock - [**Amazon Bedrock** Intelligent Prompt Routing is now available in **Preview** ](https://aws.amazon.com/fr/about-aws/whats-new/2024/12/amazon-bedrock-intelligent-prompt-routing-preview/) - [**Amazon Bedrock** Knowledge Bases now processes multimodal data](https://aws.amazon.com/fr/about-aws/whats-new/2024/12/amazon-bedrock-knowledge-bases-processes-multimodal-data/) - [**Amazon Bedrock** Knowledge Bases now supports GraphRAG ( **Preview** )](https://aws.amazon.com/fr/about-aws/whats-new/2024/12/amazon-bedrock-knowledge-bases-graphrag-preview/) - [**Amazon Bedrock** Guardrails supports multimodal toxicity detection for image content ( **Preview** ) ](https://aws.amazon.com/fr/about-aws/whats-new/2024/12/amazon-bedrock-guardrails-multimodal-toxicity-detection-image-content-preview/) - [**Amazon Bedrock** announces **Preview** of prompt caching](https://aws.amazon.com/fr/about-aws/whats-new/2024/12/amazon-bedrock-preview-prompt-caching/) - [**Amazon Bedrock** Data Automation now available in **Preview** ](https://aws.amazon.com/fr/about-aws/whats-new/2024/12/amazon-bedrock-data-automation-available-preview/) - [**Amazon Bedrock** Marketplace brings over 100 models to Amazon Bedrock](https://aws.amazon.com/fr/about-aws/whats-new/2024/12/amazon-bedrock-marketplace-100-models-bedrock/) ### Amazon Q - [**Amazon Q Developer** can now guide **Amazon SageMaker Canvas** users through ML development](https://aws.amazon.com/about-aws/whats-new/2024/12/amazon-q-developer-guide-sagemaker-canvas-users-ml-development/) ### AI / ML - [Introducing **Amazon SageMaker Data** and AI Governance](https://aws.amazon.com/fr/about-aws/whats-new/2024/12/amazon-sagemaker-data-ai-governance/) - [Announcing new AWS AI Service Cards to advance responsible generative AI](https://aws.amazon.com/fr/about-aws/whats-new/2024/12/aws-ai-service-cards-advance-responsible-generative-ai/) ### Autre - [Start collaborating on multi-partner opportunities with Partner Connections ( **Preview** )](https://aws.amazon.com/fr/about-aws/whats-new/2024/12/collaborating-multi-partner-opportunities-partner-connections-preview/) --- # Re:Invent 2024 : Les annonces du premier et deuxième jour > 2024-12-04T11:00:00.000Z | https://sylvain.bruas.fr/blog/2024/12/Reinvent-2024-jour-1-2 Tags: Re:Invent, AWS Summary: AWS re:Invent 2024 jours 1-2 : Bedrock Model Distillation, Amazon Nova, S3 Tables, SageMaker et Amazon Q Developer. Analyse des annonces. ![Re:Invent2024](/static/images/reinvent.webp) ## Les 3 nouvelles les plus marquantes pour Anda : ## Les 3 nouvelles les plus marquantes pour moi : ## Les autres annonces qui vont apporter de la valeur dans nos architectures : ### Storage - [Announcing **Amazon S3 Metadata** ( **Preview**) – Easiest and fastest way to manage your metadata](https://aws.amazon.com/fr/about-aws/whats-new/2024/12/amazon-s3-metadata-preview/) ### Amazon Q - [Announcing **Amazon Q Developer** transformation capabilities for **VMware** ( **Preview**)](https://aws.amazon.com/fr/about-aws/whats-new/2024/12/amazon-q-developer-transformation-capabilities-vmware-preview/) - [Announcing **GitLab Duo** with **Amazon Q** ( **Preview** )](https://aws.amazon.com/fr/about-aws/whats-new/2024/12/gitlab-duo-amazon-q-preview/) - [**Amazon Q Developer** announces automatic unit test generation to accelerate feature development](https://aws.amazon.com/fr/about-aws/whats-new/2024/12/amazon-q-developer-automatic-unit-test-generation/) - [**Amazon Q Business** introduces over 50 actions for popular business applications and platforms](https://aws.amazon.com/fr/about-aws/whats-new/2024/12/amazon-q-business-50-actions-business-applications-platforms/) - [**Amazon Q Developer** can now automate code reviews](https://aws.amazon.com/fr/about-aws/whats-new/2024/12/amazon-q-developer-automate-code-reviews/) - [**Amazon Q Developer** adds operational investigation capability ( **Preview** )](https://aws.amazon.com/fr/about-aws/whats-new/2024/12/amazon-q-developer-operational-investigation-preview/) - [**Amazon Q** in **Amazon QuickSight** unifies insights from structured and unstructured data](https://aws.amazon.com/fr/about-aws/whats-new/2024/12/amazon-q-quicksight-insights-structured-unstructured-data/) ### AI / ML - [**Amazon Bedrock Model Distillation** is now available in **Preview**](https://aws.amazon.com/fr/about-aws/whats-new/2024/12/amazon-bedrock-model-distillation-preview/) - [**Amazon Bedrock** now supports multi-agent collaboration](https://aws.amazon.com/fr/about-aws/whats-new/2024/12/amazon-bedrock-multi-agent-collaboration/) - [**Amazon Bedrock Guardrails** now supports Automated Reasoning checks ( **Preview**)](https://aws.amazon.com/fr/about-aws/whats-new/2024/12/amazon-bedrock-guardrails-automated-reasoning-checks-preview/) - [Announcing **Amazon Nova** foundation models available today in **Amazon Bedrock**](https://aws.amazon.com/fr/about-aws/whats-new/2024/12/amazon-nova-foundation-models-bedrock/) - [Announcing the **Preview** of **Amazon SageMaker Unified Studio**](https://aws.amazon.com/fr/about-aws/whats-new/2024/12/preview-amazon-sagemaker-unified-studio/) - [Introducing the next generation of **Amazon SageMaker**](https://aws.amazon.com/fr/about-aws/whats-new/2024/12/next-generation-amazon-sagemaker/) - [Announcing **Amazon Bedrock IDE** in **Preview** as part of **Amazon SageMaker Unified Studio**](https://aws.amazon.com/fr/about-aws/whats-new/2024/12/amazon-bedrock-ide-preview-sagemaker-unified-studio/) ### Data - [**Amazon DynamoDB** global tables **Previews** multi-Region strong consistency](https://aws.amazon.com/fr/about-aws/whats-new/2024/12/amazon-dynamodb-global-tables-previews-multi-region-strong-consistency/) - [Announcing **Amazon Aurora DSQL** ( **Preview**)](https://aws.amazon.com/fr/about-aws/whats-new/2024/12/amazon-aurora-dsql-preview/) - [Announcing **Amazon S3 Tables** – Fully managed **Apache Iceberg** tables optimized for analytics workloads](https://aws.amazon.com/fr/about-aws/whats-new/2024/12/amazon-s3-tables-apache-iceberg-tables-analytics-workloads/) - [Data Lineage is now generally available in **Amazon DataZone** and next generation of **Amazon SageMaker**](https://aws.amazon.com/fr/about-aws/whats-new/2024/12/data-lineage-amazon-datazone-next-generation-sagemaker/) - [AWS announces **Amazon SageMaker Lakehouse**](https://aws.amazon.com/fr/about-aws/whats-new/2024/12/aws-announces-amazon-sagemaker-lakehouse/) - [Introducing **AWS Glue 5.0**](https://aws.amazon.com/fr/about-aws/whats-new/2024/12/aws-glue-5-0/) - [**Amazon SageMaker Lakehouse** and **Amazon Redshift** support for zero-ETL integrations from eight applications](https://aws.amazon.com/fr/about-aws/whats-new/2024/12/amazon-sagemaker-lakehouse-redshift-zero-etl-integrations-eight-applications/) - [**AWS Glue** Data catalog now automates generating statistics for new tables](https://aws.amazon.com/fr/about-aws/whats-new/2024/12/aws-glue-data-catalog-automates-generating-statistics-tables/) - [**Amazon S3** Access Grants now integrate with **AWS Glue**](https://aws.amazon.com/fr/about-aws/whats-new/2024/12/amazon-s3-access-grants-integrate-glue/) ### Autre - [**VPC Lattice** now includes TCP support with VPC Resources](https://aws.amazon.com/fr/about-aws/whats-new/2024/12/vpc-lattice-tcp-vpc-resources/) --- # Amarathon Geek Talk > 2024-11-23T11:00:00.000Z | https://sylvain.bruas.fr/blog/2024/11/Amarathon-2024 Tags: Amarathon, User Group, Conference, AWS Summary: Retour sur l'Amarathon 2024, conférence en ligne pour AWS User Group China. Présentation des innovations AWS et networking avec la communauté cloud asiatique. ![Amarathon Geek Talk](/static/2024/11/amarathon-news.webp) J'ai eu l'honneur d'être sélectionné parmi plus de 100 propositions pour participer à cet événement avec ma présentation intitulée "Best Practices for Establishing AWS Sandbox Accounts for Your Organization". Cet événement a été tout simplement monumental : - Diffusé sur 13 plateformes de streaming - 566 886 vues au total - 146 787 spectateurs uniques - Un pic à 31 833 spectateurs simultanés - 3 762 interactions et commentaires - Spectateurs originaires de plus de 16 pays différents L'organisation était d'une qualité exceptionnelle ! L'équipe nous a préparés en amont avec une relecture minutieuse des slides et une session de préparation pour maîtriser l'outil de streaming. Le jour de l'événement, nous avons bénéficié d'une présentation impeccable avant nos interventions, ainsi que d'une traduction en direct : Bande annonce de l'événement : ![Agenda](/static/2024/11/amarathon-agenda.webp) ![Capture d'écran](/static/2024/11/amarathon-screen.webp) ![Intervenants](/static/2024/11/amarathon-speakers.webp) Lien vers la page de l'événement : [Amarathon](https://dev.amazoncloud.cn/amarathon) --- # Les différents modèles de responsabilité sur AWS > 2024-02-13T11:00:00.000Z | https://sylvain.bruas.fr/blog/2024/02/responsability-model Tags: shared responsibility model, AWS Summary: Tout architect solutions travaillant sur AWS a eu un jour besoin d'expliquer le modèle de responsabilité partagée AWS et ses variantes selon les services. Tout architect solutions travaillant sur AWS a eu un jour besoin d'expliquer le modèle de [responsabilité partagée](https://aws.amazon.com/compliance/shared-responsibility-model/). Quand cela est nécessaire, nous partageons donc l'image ci-dessous : ![modèle de responsabilité partagée](/static/2024/02/Shared_Responsibility_Model_V2.59.webp) Il s'applique à la plupart des services, mais saviez-vous qu'AWS l'a décliné pour plusieurs services ? ## Définitions - IaaS : Infrastructure As A Service - CaaS : Containers As A Service - PaaS : Platform As A Service - FaaS : Functions As A Service - SaaS : Software As A Service ## Responsabilité On-premise, IaaS, PaaS, SaaS Nous pouvons trouver sur internet de nombreux articles expliquant les modèles de responsabilités dans différents types d'organisation logicielle. Nous trouvons souvent un schéma équivalent à celui-ci. ![Responsabilités dans le IaaS, PaaS et SaaS](/static/2024/02/shared-responsability-basics.webp) On peut faire une analogie avec la dégustation d'une pizza : ![Responsabilités pizza](/static/2024/02/shared-responsability-pizza.webp) ## Modèles de responsabilité sur AWS Le modèle le plus courant est celui que nous avons vu en introduction. C'est celui pour le IaaS, utilisé par exemple pour illustrer [Amazon Elastic Compute Cloud (EC2)](https://docs.aws.amazon.com/ec2/) ou [Amazon Virtual Private Cloud (VPC)](https://docs.aws.amazon.com/vpc/). ![modèle de responsabilité partagée](/static/2024/02/Shared_Responsibility_Model_V2.59.webp) En parcourant la documentation AWS, les articles de blog et les dépôts github on peut trouver les variations suivantes. ### Services containeurisés ([Amazon Relational Database Service (RDS)](https://docs.aws.amazon.com/rds/), Amazon EMR ...) Dans cette rubrique, nous trouvons les services permettant de configurer le comportement des éléments autour des serveurs, tels qu'entre autres le réseau, les firewalls, le chiffrement. ![modèle de responsabilité partagée Services containeurisés](/static/2024/02/aws-shared-responsibility-model-container-services.webp) Source : [AWS Prescriptive Guidance](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-accelerating-security-maturity/understanding-the-security-scope.html) ### Services Serverless ([Amazon Simple Storage Service (S3)](https://docs.aws.amazon.com/s3/), [Amazon DynamoDB](https://docs.aws.amazon.com/dynamodb/) ...) La responsabilité du client s'arrête à ses données et au chiffrement de celles-ci. ![modèle de responsabilité partagée Services Serverless](/static/2024/02/aws-shared-responsibility-model-serverless-services.webp) Source : [AWS Prescriptive Guidance](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-accelerating-security-maturity/understanding-the-security-scope.html) ### [AWS Lambda](https://docs.aws.amazon.com/lambda/) Le modèle de responsabilité de Lambda nous est présenté dans un livre blanc. ![modèle de responsabilité partagée Lambda](/static/2024/02/shared-responsibility-lambda.webp) Source : [Security Overview of AWS Lambda](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/the-shared-responsibility-model.html) ### [Amazon Elastic Container Service (ECS)](https://docs.aws.amazon.com/ecs/) 2 modèles existent, suivant le fournisseur de puissance de calcul (EC2 vs [AWS Fargate](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/AWS_Fargate.html)) #### modèle de responsabilité partagée ECS avec EC2 ![modèle de responsabilité partagée ECS avec EC2](/static/2024/02/ecs-ec2.webp) Source : [Security considerations for running containers on Amazon ECS](https://aws.amazon.com/blogs/security/security-considerations-for-running-containers-on-amazon-ecs/) #### modèle de responsabilité partagée ECS avec Fargate ![modèle de responsabilité partagée Fargate](/static/2024/02/shared-ecs-fargate.webp) Source : [Security considerations for running containers on Amazon ECS](https://aws.amazon.com/blogs/security/security-considerations-for-running-containers-on-amazon-ecs/) ### [Amazon Elastic Kubernetes Service (EKS)](https://docs.aws.amazon.com/eks/) La responsabilité du client est liée à la solution de mise à l'échelle choisie. ![modèle de responsabilité partagée EKS Fargate](/static/2024/02/SRM-EKS.webp) ![modèle de responsabilité partagée Managed Node Groups](/static/2024/02/SRM-MNG.webp) Source : [Amazon EKS Best Practices Guide for Security](https://aws.github.io/aws-eks-best-practices/security/docs/) ### AWS Outposts La solution étant déployée on-premise, le client devient responsable de la couche physique (électricité, sécurité physique, réseau ...) ![modèle de responsabilité partagée AWS Outposts](/static/2024/02/aws-shared-responsibility-model-outposts.webp) Source : [Documentation AWS Outposts](https://docs.aws.amazon.com/whitepapers/latest/aws-outposts-high-availability-design/aws-outposts-high-availability-design.html) ## Autre Modèle de responsabilités - VMWare Ce n'est pas un modèle partagé par AWS, mais par VMWare pour la solution [VMC](https://docs.vmware.com/en/VMware-Cloud-on-AWS/solutions/VMware-Cloud-on-AWS.39646badb412ba21bd6770ef62ae00a2/GUID-31CC90E5EB22075B2313FA674D567F2A.html). Il est important de le connaitre également, car c'est une solution courante sur AWS. ![modèle de responsabilité partagée VMC](/static/2024/02/VMC-Shared-Responsibility.webp) ## Conclusion Ces différents schémas illustrent la répartition des responsabilités, mais aussi le niveau de personnalisation fourni par chaque service. Plus l'on délègue de responsabilité à AWS, plus on doit se plier aux règles et méthodes de ce fournisseur. Le schéma suivant illustre bien ces possibilités offertes : ![modèle de responsabilité partagée par service](/static/2024/02/Shared-Responsibility-by-Service-Type.webp) Source : [Applying the AWS Shared Responsibility Model to your GxP Solution](https://aws.amazon.com/blogs/industries/applying-the-aws-shared-responsibility-model-to-your-gxp-solution/) Il faut donc choisir le modèle qui vous conviendra le mieux, mais aussi qui est à votre portée. Il faut garder en tête la taille et l'expertise de vos équipes pour chacune des cases que vous allez prendre sous votre responsabilité. En présentant ces schémas et choix à votre direction, vous pourrez montrer que vous maitrisez votre trajectoire sur AWS, et vous pourrez ainsi éviter les sensations de "lock-in" qui sont liées à la méconnaissance des choix effectués. --- # Nouvelles et outils - semaine 2, 2024 > 2024-01-15T11:00:00.000Z | https://sylvain.bruas.fr/blog/2024/01/w2 Tags: outils, AWS Summary: Liste des nouvelles AWS qui me semblent intéressantes et des outils que j'ai pu découvrir grâce à mon réseau (W2) du 8 au 14 janvier 2024 ## Nouvelles AWS - [Amazon Route 53 expands geoproximity routing](https://aws.amazon.com/fr/about-aws/whats-new/2024/01/amazon-route-53-expands-geoproximity-routing/) - [AWS CloudShell now supports Docker in 13 Regions](https://aws.amazon.com/fr/about-aws/whats-new/2024/01/aws-cloudshell-docker-13-regions/) - [Amazon ECS improves deployment monitoring responsiveness for Amazon ECS services](https://aws.amazon.com/fr/about-aws/whats-new/2024/01/amazon-ecs-deployment-monitoring-responsiveness-services/) - [Amazon ECS and AWS Fargate now integrate with Amazon EBS](https://aws.amazon.com/fr/about-aws/whats-new/2024/01/amazon-ecs-fargate-integrate-ebs/) - [Amazon CloudWatch Logs now supports account level subscription filter](https://aws.amazon.com/fr/about-aws/whats-new/2024/01/amazon-cloudwatch-logs-account-level-subscription-filter/) --- # Optimiser Amazon CloudFront avec les CloudFront Functions > 2023-12-10T11:00:00.000Z | https://sylvain.bruas.fr/blog/2023/12/fix-gatsby-s3 Tags: S3, Lambda, Cloudfront, Gatsby, AWS Summary: Résolvez les problèmes de redirection d'URLs avec Gatsby sur S3. Corrigez les redirections des URLs finissant par '/' avec CloudFront Functions. [Gatsby](https://www.gatsbyjs.com/) est un outil permettant de créer rapidement des sites webs en utilisant le langage [React](https://react.dev/), du javascript ou le langage [TypeScript](https://www.typescriptlang.org/). Cet outil permet de facilement déployer le site sur Amazon S3 et d'ainsi réduire la complexité de maintenance et les coûts. Pour assurer une distribution du contenu rapide et efficace, nous utilisons Amazon Cloudfront. ![User request flow](/static/2023/12/sylvain.bruas.fr.webp) ## Installer le plugin Gatsby S3 ```shell > yarn add gatsby-plugin-s3 ou > npm install gatsby-plugin-s3 ``` ## Modifier gatsby-config.js Il faut ajouter la configuration du plugin dans ce fichier. Il est nécessaire de préciser à minima le bucket de destination. ```javascript{3,5} plugins: [ { resolve: `gatsby-plugin-s3`, options: { bucketName: "myBucket", }, }, ] ``` ## Problème identifié Si nous tentons de nous connecter directement sur une page autre que la page d'accueil, nous obtenons le résultat suivant : ```sh{6} wget https://sylvain.bruas.fr/blog/aws-eks-contrainte-ip/ --2023-10-30 15:18:32-- https://sylvain.bruas.fr/blog/aws-eks-contrainte-ip/ Résolution de sylvain.bruas.fr (sylvain.bruas.fr)… 52.222.144.106, 52.222.144.45, 52.222.144.68, ... Connexion à sylvain.bruas.fr (sylvain.bruas.fr)|52.222.144.106|:443… connecté. requête HTTP transmise, en attente de la réponse… 403 Forbidden 2023-10-30 15:18:32 erreur 403 : Forbidden. ```   La solution proposée par [Gatsby](https://www.gatsbyjs.com/docs/how-to/previews-deploys-hosting/deploying-to-s3-cloudfront/#setting-up-cloudfront) est d'utiliser S3 avec l'option Static Website Hosting et configurer le bucket en public-read. Dans cette configuration, le bucket peut être accédé directement, en HTTP si l'on trouve son URL. Une autre solution est disponible depuis la mise en place des AWS Lambda@Edge (2016) et des Cloudfront functions (2021). En utilisant l'un de ces deux outils, nous pouvons manipuler la requête HTTP entrante, et si l'on identifie une URL terminant par un slash (/) ou qui ne contient pas d'extension nous ajoutons à la fin '/index.html'. ## Lambda@edge et Cloudfront Functions Nous allons donc déployer le code suivant, tiré de la [documentation AWS](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/example-function-add-index.html). ```js function handler(event) { var request = event.request; var uri = request.uri; // Check whether the URI is missing a file name. if (uri.endsWith("/")) { request.uri += "index.html"; } // Check whether the URI is missing a file extension. else if (!uri.includes(".")) { request.uri += "/index.html"; } return request; } ```   Il ne reste plus qu'à choisir entre Lambda@Edge et Cloudfront Functions. L'[article](https://aws.amazon.com/fr/blogs/aws/introducing-cloudfront-functions-run-your-code-at-the-edge-with-low-latency-at-any-scale/) annoncant la mise à disposition de Cloudfront fonction nous renseigne clairement sur les différences principales entre ces 2 services. | | **_CloudFront Functions_** | **_Lambda@Edge_** | | ----------------------------- | :-------------------------------------------: | :------------------------------------------------------------: | | Runtime support | JavaScript | Node.js, Python | | Execution location | Edge Locations (~220) | Regional Edge Caches (~10) | | CloudFront triggers supported | Viewer request, Viewer response | Viewer request,Viewer response,Origin request, Origin response | | Maximum execution time | 1 millisecond | 5 seconds (viewer triggers) | | Total package size | 10 KB | 1 MB (viewer triggers) | | Maximum memory | 2MB | 128MB (viewer triggers) | | Network access | No | Yes | | File system access | No | Yes | | Access to the request body | No | Yes | | Pricing | Free Tier\* + $0.10 per 1 million invocations | $0.60 per 1M requests + $0.00005001 for every GB-second | Free Tier pour CloudFront Functions : 2,000,000 Invocations Notre fonction javascript est très simple et légère. Elle s'exécute rapidement et ne consomme que de la mémoire, et en quantité limitée. Notre fonctionnalité peut donc être déployée sur les 2 services. C'est donc l'aspect financier qui va faire la différence. Que ce soit pour les petits sites qui profiterons de l'offre gratuite, ou le prix à la requête pour les sites ayant un grand nombre de visite, Amazon Cloudfront Functions reste la solution la plus efficiente économiquement. La suite de l'article et les exemples proposés se concentreront donc sur Amazon Cloudfront Functions. Nous allons utiliser [Terraform](https://www.terraform.io/) pour déployer notre fonction. ## Déploiement de la solution 1. Nous créons un fichier index.js dans le chemin functions/cloudfront du projet. ```js function handler(event) { var request = event.request; var uri = request.uri; // Check whether the URI is missing a file name. if (uri.endsWith("/")) { request.uri += "index.html"; } // Check whether the URI is missing a file extension. else if (!uri.includes(".")) { request.uri += "/index.html"; } return request; } ```   2. Nous ajoutons dans le répertoire iac un nouveau fichier appelé cloudfront_functions.tf. Voici son contenu : ```hcl{3,5,6} resource "aws_cloudfront_function" "redirect-index" { name = "redirect-index" runtime = "cloudfront-js-1.0" comment = "add missing index.html at the end of url" publish = true code = file("../functions/cloudfront/index.js") } ``` Il faut bien veiller à préciser le moteur (runtime) à utiliser, publier la fonction et modifier si nécessaire le chemin vers notre code.   3. Ajouter le code suivant dans la définition terraform de votre distribution cloudfront, dans la section default_cache_behavior ```hcl{2-6} default_cache_behavior = { function_association = { viewer-request = { function_arn = aws_cloudfront_function.redirect-index.arn } } ... ```   4. terraform plan ```sh ... Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols: + create Terraform will perform the following actions: # aws_cloudfront_function.redirect-index will be created + resource "aws_cloudfront_function" "redirect-index" { + arn = (known after apply) + code = <<-EOT function handler(event) { var request = event.request; var uri = request.uri; // Check whether the URI is missing a file name. if (uri.endsWith('/')) { request.uri += 'index.html'; } // Check whether the URI is missing a file extension. else if (!uri.includes('.')) { request.uri += '/index.html'; } return request; } EOT + comment = "add missing index.html at the end of url" + etag = (known after apply) + id = (known after apply) + live_stage_etag = (known after apply) + name = "redirect-index" + publish = true + runtime = "cloudfront-js-1.0" + status = (known after apply) } Plan: 1 to add, 0 to change, 0 to destroy. ```   5. Terraform apply L'affichage sera le même qu'à l'étape précédente. Une invite va apparaitre pour vous demander de valider que vous êtes prêt à appliquer ces modifications. Après quelques minutes d'attente, la fonction sera déployée.   6. Résultats Avant la mise en place de la fonction, nous obtenions le résultat suivant, une erreur 403 : ```sh{6} wget https://sylvain.bruas.fr/blog/aws-eks-contrainte-ip/ --2023-10-30 15:18:32-- https://sylvain.bruas.fr/blog/aws-eks-contrainte-ip/ Résolution de sylvain.bruas.fr (sylvain.bruas.fr)… 52.222.144.106, 52.222.144.45, 52.222.144.68, ... Connexion à sylvain.bruas.fr (sylvain.bruas.fr)|52.222.144.106|:443… connecté. requête HTTP transmise, en attente de la réponse… 403 Forbidden 2023-10-30 15:18:32 erreur 403 : Forbidden. ```   Avec la fonction Cloudfront nous obtenons : ```sh{5} wget https://sylvain.bruas.fr/blog/aws-eks-contrainte-ip/ --2023-10-30 15:46:41-- https://sylvain.bruas.fr/blog/aws-eks-contrainte-ip/ Résolution de sylvain.bruas.fr (sylvain.bruas.fr)… 52.222.144.68, 52.222.144.56, 52.222.144.45, ... Connexion à sylvain.bruas.fr (sylvain.bruas.fr)|52.222.144.68|:443… connecté. requête HTTP transmise, en attente de la réponse… 200 OK Taille : 108929 (106K) [text/html] Sauvegarde en : « index.html » index.html 100%[=============================================>] 106,38K --.-KB/s ds 0,06s 2023-10-30 15:46:42 (1,72 MB/s) — « index.html » sauvegardé [108929/108929] ```   La requête est donc traitée ainsi : ![User request flow](/static/2023/12/cloudfront_functions.webp) ## Conclusion Nous avons grace à Cloudfront functions mis en place une solution de réécriture d'url s'appliquant à toutes les urls de ce site. Cela permettra par exemple aux moteurs de recherche d'indexer toutes les pages, ce qui n'aurait pas été possible sans la fonction de réécriture des URLs. Vous pouvez retrouver tous les exemples de code précédents sur le dépôt github suivant : [https://github.com/sylvainbruas/demo](https://github.com/sylvainbruas/demo) --- # Re:Invent 2023 : Les annonces qui nous ont marqués - Jour 5 > 2023-12-01T11:00:00.000Z | https://sylvain.bruas.fr/blog/2023/11/Reinvent-2023-jour-5 Tags: Re:Invent, AWS Summary: AWS re:Invent 2023 jour 5 : Amazon Inspector sécurise les conteneurs, Route 53 autoshift zonal et AWS Fault Injection Service multi-région. Analyse... ![Re:Invent2018](/static/2023/11/reinvent.webp) ## La vision d'[Anda](https://www.linkedin.com/in/anda-catalina/) (Professional Solutions Architect AWS) 1. [Amazon Inspector enhances container image security by integrating with developer tools](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-inspector-image-security-developer-tools/) - Blog post : [Three new capabilities for Amazon Inspector broaden the realm of vulnerability scanning for workloads](https://aws.amazon.com/blogs/aws/three-new-capabilities-for-amazon-inspector-broaden-the-realm-of-vulnerability-scanning-for-workloads/) 2. [Amazon Route 53 Application Recovery Controller launches zonal autoshift](https://aws.amazon.com/about-aws/whats-new/2023/11/route-53-application-recovery-zonal-autoshift/) - Blog post : [Zonal autoshift – Automatically shift your traffic away from Availability Zones when we detect potential issues](https://aws.amazon.com/blogs/aws/zonal-autoshift-automatically-shift-your-traffic-away-from-availability-zones-when-we-detect-potential-issues/) 3. [AWS Fault Injection Service launches two highly requested scenarios](https://aws.amazon.com/about-aws/whats-new/2023/11/aws-fault-injection-service-two-requested-scenarios/) - Blog post : [Use AWS Fault Injection Service to demonstrate multi-region and multi-AZ application resilience](https://aws.amazon.com/blogs/aws/use-aws-fault-injection-service-to-demonstrate-multi-region-and-multi-az-application-resilience/) ## Les 3 nouvelles les plus marquantes pour moi : 1. [Observe your applications with Amazon CloudWatch Application Signals (Preview)](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-cloudwatch-applications-signals-observe-preview/) 2. [myApplications: One place to view and manage your applications on AWS](https://aws.amazon.com/about-aws/whats-new/2023/11/myapplications-view-manage-applications-aws/) 3. [Announcing Code Editor, based on Code-OSS (VS Code – Open Source), in Amazon SageMaker Studio](https://aws.amazon.com/about-aws/whats-new/2023/11/code-editor-amazon-sagemaker-studio/) ## Les autres annonces qui vont apporter de la valeur dans nos architectures : ### SageMaker - [Amazon SageMaker Studio now provides a faster fully-managed notebooks in JupyterLab](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-sagemaker-studio-fully-managed-notebooks-jupyterlab/) - [Amazon SageMaker now provides a new setup and onboarding experience on AWS SageMaker console](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-sagemaker-setup-onboarding-experience-console/) - [Bring your own Amazon EFS (Elastic File System) volume to JupyterLab and CodeEditor in Amazon SageMaker Studio](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-eds-volume-jupyterlab-codeeditor-amazon-sagemaker-studio/) ### Application - [Introducing an Integrated Development Environment (IDE) extension for AWS Application Composer](https://aws.amazon.com/about-aws/whats-new/2023/11/ide-extension-aws-application-composer/) --- # Re:Invent 2023 : Les annonces qui nous ont marqués - Jour 4 > 2023-11-30T11:00:00.000Z | https://sylvain.bruas.fr/blog/2023/11/Reinvent-2023-jour-4 Tags: Re:Invent, AWS Summary: AWS re:Invent 2023 jour 4 : Vector Search pour DocumentDB, SageMaker Canvas avec langage naturel et AWS Clean Rooms ML en preview. Innovations IA et... ![Re:Invent2018](/static/2023/11/reinvent.webp) ## La vision d'[Anda](https://www.linkedin.com/in/anda-catalina/) (Professional Solutions Architect AWS) 1. [AWS announces vector search for Amazon DocumentDB](https://aws.amazon.com/about-aws/whats-new/2023/11/vector-search-amazon-documentdb/) - Blog post : [Vector search for Amazon DocumentDB (with MongoDB compatibility) is now generally available](https://aws.amazon.com/blogs/aws/vector-search-for-amazon-documentdb-with-mongodb-compatibility-is-now-generally-available/) 2. [Amazon SageMaker Canvas now supports natural language instructions for data preparation](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-sagemaker-canvas-natural-language-preparation/) - Blog post : [Use natural language to explore and prepare data with a new capability of Amazon SageMaker Canvas](https://aws.amazon.com/blogs/aws/use-natural-language-to-explore-and-prepare-data-with-a-new-capability-of-amazon-sagemaker-canvas/) 3. [AWS Clean Rooms ML is now available in preview](https://aws.amazon.com/about-aws/whats-new/2023/11/aws-clean-rooms-ml-preview/) - Blog post : [AWS Clean Rooms ML helps customers and partners apply ML models without sharing raw data (preview)](https://aws.amazon.com/blogs/aws/aws-clean-rooms-ml-helps-customers-and-partners-apply-ml-models-without-sharing-raw-data-preview/) ## Les 3 nouvelles les plus marquantes pour moi : 1. [AWS announces OR1 for Amazon OpenSearch Service](https://aws.amazon.com/about-aws/whats-new/2023/11/or1-amazon-opensearch-service/) 2. [Announcing new AWS AI Service Cards - to advance responsible AI](https://aws.amazon.com/about-aws/whats-new/2023/11/aws-ai-service-cards/) 3. [Amazon OpenSearch Service zero-ETL integration with Amazon S3 preview now available](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-opensearch-zero-etl-integration-s3-preview/) ## Les autres annonces qui vont apporter de la valeur dans nos architectures : ### BedRock - [Stable Diffusion XL 1.0 foundation model from Stability AI is now generally available in Amazon Bedrock](https://aws.amazon.com/about-aws/whats-new/2023/11/stable-diffusion-xl-1-0-foundation-model-amazon-bedrock/) - [Amazon Titan Image Generator foundation model in Amazon Bedrock now available in preview](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-titan-image-generator-model-bedrock-preview/) - [Llama 2 70B foundation model from Meta is now available in Amazon Bedrock](https://aws.amazon.com/about-aws/whats-new/2023/11/llama-2-70b-foundation-model-meta-amazon-bedrock/) - [Claude 2.1 foundation model from Anthropic is now generally available in Amazon Bedrock](https://aws.amazon.com/about-aws/whats-new/2023/11/claude-2-1-foundation-model-anthropic-amazon-bedrock/) - [Evaluate, compare, and select the best FMs for your use case in Amazon Bedrock (Preview)](https://aws.amazon.com/about-aws/whats-new/2023/11/evaluate-compare-select-fms-use-case-amazon-bedrock/) - [Amazon Bedrock now supports batch inference](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-bedrock-batch-inference/) - [Amazon Titan Text models—Express and Lite—now generally available in Amazon Bedrock](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-titan-models-express-lite-bedrock/) ### Amazon SageMaker - [Amazon SageMaker Clarify now supports foundation model (FM) evaluations in preview](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-sagemaker-clarify-fm-evaluations-preview/) - [SageMaker now provides improved SDK tooling and UX for model deployment](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-sagemaker-sdk-tooling-ux-model-deployment/) - [Announcing smart sifting of data for Amazon SageMaker Model Training in preview](https://aws.amazon.com/about-aws/whats-new/2023/11/smart-sifting-data-amazon-sagemaker-model-training-preview/) - [Announcing Amazon SageMaker HyperPod, a purpose-built infrastructure for distributed training at scale](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-sagemaker-hyperpod/) - [Amazon SageMaker launches new inference capabilities to reduce costs and latency](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-sagemaker-inference-costs-latency/) - [Amazon SageMaker Pipelines now provide a simplified developer experience for AI/ML workflows](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-sagemaker-pipelines-developer-ai-ml/) - [Leverage FMs for business analysis at scale with Amazon SageMaker Canvas](https://aws.amazon.com/about-aws/whats-new/2023/11/leverage-fms-analysis-scale-sagemaker-canvas/) - [Announcing API support for creating Amazon SageMaker Notebook jobs](https://aws.amazon.com/about-aws/whats-new/2023/11/api-creating-amazon-sagemaker-notebook-jobs/) ### Database - [Amazon Neptune Analytics is now generally available](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-neptune-analytics/) - [AWS announces vector search for Amazon MemoryDB for Redis (Preview)](https://aws.amazon.com/about-aws/whats-new/2023/11/vector-search-amazon-memorydb-redis-preview/) ### Analytics - [AWS Clean Rooms Differential Privacy is now available in preview](https://aws.amazon.com/about-aws/whats-new/2023/11/aws-clean-rooms-differential-privacy-preview/) - [Vector engine for Amazon OpenSearch Serverless now generally available](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-opensearch-serverless-vector-engine/) ### Amazon Redshift - [Amazon Redshift now supports metadata security to simplify multi-tenant applications](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-redshift-metadata-security-tenant-applications/) - [Amazon Redshift announces general availability of support for Apache Iceberg](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-redshift-support-apache-iceberg/) - [Announcing enhanced manageability and usability features for Amazon Redshift Serverless](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-redshift-serverless-manageability-usability-features/) - [Amazon Redshift announces general availability of row-level security enhancements](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-redshift-row-level-security-enhancements/) - [Amazon Q generative SQL is now available in Amazon Redshift Query Editor (preview)](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-redshift-generative-sql-query-editor-preview/) ### Autre - [Announcing SaaS Quick Launch for AWS Marketplace](https://aws.amazon.com/about-aws/whats-new/2023/11/saas-quick-launch-aws-marketplace/) --- # Re:Invent 2023 : Les annonces qui nous ont marqués - Jour 3 > 2023-11-29T11:00:00.000Z | https://sylvain.bruas.fr/blog/2023/11/Reinvent-2023-jour-3 Tags: Re:Invent, AWS Summary: AWS re:Invent 2023 jour 3 : instances EC2 R8g avec Graviton4, Agents pour Amazon Bedrock et Amazon Q dans CodeCatalyst. Innovations calcul haute... ![Re:Invent2018](/static/2023/11/reinvent.webp) ## La vision d'[Anda](https://www.linkedin.com/in/anda-catalina/) (Professional Solutions Architect AWS) 1. [Announcing new Amazon EC2 R8g instances powered by AWS Graviton4 processors (Preview)](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-ec2-r8g-instances-aws-graviton4-processors-preview/) - Blog post : [Join the preview for new memory-optimized, AWS Graviton4-powered Amazon EC2 instances (R8g)](https://aws.amazon.com/blogs/aws/join-the-preview-for-new-memory-optimized-aws-graviton4-powered-amazon-ec2-instances-r8g/) 2. [Boost generative AI application development with Agents for Amazon Bedrock](https://aws.amazon.com/about-aws/whats-new/2023/11/boost-generative-ai-development-agents-bedrock/) - Blog post : [Agents for Amazon Bedrock is now available with improved control of orchestration and visibility into reasoning](https://aws.amazon.com/blogs/aws/agents-for-amazon-bedrock-is-now-available-with-improved-control-of-orchestration-and-visibility-into-reasoning/) 3. [Announcing feature development capability of Amazon Q (Preview) in Amazon CodeCatalyst](https://aws.amazon.com/about-aws/whats-new/2023/11/feature-development-capability-amazon-q-preview-codecatalyst/) - Blog post : [Improve developer productivity with generative-AI powered Amazon Q in Amazon CodeCatalyst (preview)](https://aws.amazon.com/blogs/aws/improve-developer-productivity-with-generative-ai-powered-amazon-q-in-amazon-codecatalyst-preview/) ## Les 3 nouvelles les plus marquantes pour moi : 1. [AWS announces Amazon Q (Preview)](https://aws.amazon.com/about-aws/whats-new/2023/11/aws-amazon-q-preview/) 2. [Announcing the Amazon S3 Express One Zone storage class](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-s3-express-one-zone-storage-class/) 3. [Announcing Amazon Q expert capabilities for AWS (Preview)](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-q-expert-capabilities-aws-preview/) ## Les autres annonces qui vont apporter de la valeur dans nos architectures : ### Amazon Q - [Amazon Q offers help to optimize EC2 instance type selection (preview)](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-q-optimal-ec2-instance-selection-workload/) - [Announcing feature development capability of Amazon Q (Preview) in Amazon CodeCatalyst](https://aws.amazon.com/about-aws/whats-new/2023/11/feature-development-capability-amazon-q-preview-codecatalyst/) - [Amazon Q in Amazon QuickSight simplifies data exploration with Generative BI capabilities (Preview)](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-q-quicksight-data-exploration-generative-bi-capabilities-preview/) - [AWS Announces Amazon Q is available in preview on the AWS Console Mobile App](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-q-preview-console-mobile-app/) - [AWS Chatbot now supports Amazon Q conversations in Microsoft Teams and Slack](https://aws.amazon.com/about-aws/whats-new/2023/11/aws-chatbot-q-conversations-teams-slack/) ### Bedrock - [Safeguard generative AI applications with Guardrails for Amazon Bedrock (Preview)](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-bedrock-safeguard-ai-applications-guardrails/) - [Knowledge Bases for Amazon Bedrock is now generally available](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-bedrock-knowledge-bases/) - [Boost generative AI application development with Agents for Amazon Bedrock](https://aws.amazon.com/about-aws/whats-new/2023/11/boost-generative-ai-development-agents-bedrock/) ### Storage - [Mountpoint for Amazon S3 now supports the Amazon S3 Express One Zone storage class](https://aws.amazon.com/about-aws/whats-new/2023/11/mountpoint-amazon-s3-express-one-zone-storage-class/) --- # Re:Invent 2023 : Les annonces qui nous ont marqués - Jour 2 > 2023-11-28T08:00:00.000Z | https://sylvain.bruas.fr/blog/2023/11/Reinvent-2023-jour-2 Tags: Re:Invent, AWS Summary: AWS re:Invent 2023 jour 2 : focus sur les innovations de calcul et stockage. Nouvelles instances EC2, améliorations S3, services de base de données... ![Re:Invent2018](/static/2023/11/reinvent.webp) ## La vision d'[Anda](https://www.linkedin.com/in/anda-catalina/) (Professional Solutions Architect AWS) 1. [Powered by foundation model, Amazon Transcribe now supports over 100 languages](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-transcribe-over-100-languages/) - Blog post : [Amazon Transcribe announces a new speech foundation model-powered ASR system that expands support to over 100 languages](https://aws.amazon.com/blogs/machine-learning/amazon-transcribe-announces-a-new-speech-foundation-model-powered-asr-system-that-expands-support-to-over-100-languages/) 2. [AWS Support launches AWS Countdown with a premium tier](https://aws.amazon.com/about-aws/whats-new/2023/11/aws-support-countdown-premium-tier/) 3. [AWS Backup launches support for restore testing](https://aws.amazon.com/about-aws/whats-new/2023/11/aws-backup-restore-testing/) - Blog post : [Automatic restore testing and validation now available in AWS Backup](https://aws.amazon.com/blogs/aws/automatic-restore-testing-and-validation-is-now-available-in-aws-backup/) ## Les 3 nouvelles les plus marquantes pour moi : 1. [AWS announces Amazon ElastiCache Serverless](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-elasticache-serverless/) 2. [AWS Backup launches support for restore testing](https://aws.amazon.com/about-aws/whats-new/2023/11/aws-backup-restore-testing/) 3. [Announcing new finding enrichment in AWS Security Hub](https://aws.amazon.com/about-aws/whats-new/2023/11/new-finding-enrichment-aws-security-hub/) ## Les autres annonces qui vont apporter de la valeur dans nos architectures : ### Storage - [Amazon EFS Replication now supports failback](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-efs-replication-failback/) ### Backup - [AWS Backup now supports Amazon Elastic Block Store (EBS) Snapshots Archive](https://aws.amazon.com/about-aws/whats-new/2023/11/aws-backup-elastic-block-store-snapshots-archive/) ### Kubernetes - [Mountpoint for Amazon S3 CSI driver is now generally available](https://aws.amazon.com/about-aws/whats-new/2023/11/mountpoint-amazon-s3-csi-driver/) ### Développement - [AWS Application Composer announces AWS Step Functions Workflow Studio integration](https://aws.amazon.com/about-aws/whats-new/2023/11/aws-application-composer-step-functions-workflow-studio/) - [Announcing custom blueprints for Amazon CodeCatalyst](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-codecatalyst-custom-blueprints/) ### Database - [Announcing Amazon Aurora Limitless Database](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-aurora-limitless-database/) - [Announcing the general availability of Amazon RDS for Db2](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-rds-db2/) ### Sécurité - [Announcing major dashboard enhancements in AWS Security Hub](https://aws.amazon.com/about-aws/whats-new/2023/11/dashboard-enhancements-aws-security-hub/) - [Announcing new central configuration capabilities in AWS Security Hub](https://aws.amazon.com/about-aws/whats-new/2023/11/aws-security-hub-central-configuration/) - [AWS Control Tower announces 65 new controls to help meet digital sovereignty requirements](https://aws.amazon.com/about-aws/whats-new/2023/11/aws-control-tower-65-controls-digital-sovereignty-requirements/) - [Amazon Inspector agentless vulnerability assessments for Amazon EC2 now in preview](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-inspector-agentless-assessments-ec2-preview/) ### Autre - [AWS Support launches AWS Countdown with a premium tier](https://aws.amazon.com/about-aws/whats-new/2023/11/aws-support-countdown-premium-tier/) - [Announcing enhanced capabilities for Partner-Led Support](https://aws.amazon.com/about-aws/whats-new/2023/11/enhanced-capabilities-partner-led-support/) - [Announcing Multi-Account Experiments for AWS Fault Injection Service](https://aws.amazon.com/about-aws/whats-new/2023/11/multi-account-experiments-aws-fault-injection-service/) - [Amazon SQS announces support for FIFO dead-letter queue redrive](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-sqs-fifo-dead-letter-queue-redrive/) --- # Re:Invent 2023 : Les annonces qui nous ont marqués - Jour 1 > 2023-11-27T11:00:00.000Z | https://sylvain.bruas.fr/blog/2023/11/Reinvent-2023-jour-1 Tags: Re:Invent, AWS Summary: AWS re:Invent 2023 jour 1 : CodeWhisperer avec remédiation IA, Cost Optimization Hub et API Free Tier. Analyse des annonces clés. ![Re:Invent2018](/static/2023/11/reinvent.webp) ## La vision d'[Anda](https://www.linkedin.com/in/anda-catalina/) (Professional Solutions Architect AWS) 1. [Announcing new enhancements to Amazon CodeWhisperer](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-codewhisperer-new-enhancements/) - Blog post : [Amazon CodeWhisperer offers new AI-powered code remediation, IaC support, and integration with Visual Studio](https://aws.amazon.com/blogs/aws/amazon-codewhisperer-offers-new-ai-powered-code-remediation-iac-support-and-integration-with-visual-studio/) 2. [Introducing Cost Optimization Hub](https://aws.amazon.com/fr/about-aws/whats-new/2023/11/cost-optimization-hub/) - Blog post : [New Cost Optimization Hub centralizes recommended actions to save you money](https://aws.amazon.com/blogs/aws/new-cost-optimization-hub-to-find-all-recommended-actions-in-one-place-for-saving-you-money/) 3. [AWS Free Tier usage is now available through the GetFreeTierUsage API](https://aws.amazon.com/about-aws/whats-new/2023/11/aws-free-tier-usage-getfreetierusage-api/) - Blog post : [Check your AWS Free Tier usage programmatically with a new API](https://aws.amazon.com/blogs/aws/check-your-aws-free-tier-usage-programmatically-with-a-new-api/) ## Les 3 nouvelles les plus marquantes pour moi : 1. [You can now customize security controls in AWS Security Hub](https://aws.amazon.com/fr/about-aws/whats-new/2023/11/customize-security-controls-aws-security-hub/) 2. [Application Load Balancer increases application availability with Automatic Target Weights](https://aws.amazon.com/fr/about-aws/whats-new/2023/11/application-load-balancer-availability-target-weights/) 3. [Application Load Balancer can authenticate X.509 certificate based identities with Mutual TLS support](https://aws.amazon.com/fr/about-aws/whats-new/2023/11/application-load-balancer-authenticate-x509-certificate-based-identities/) ## Les autres annonces qui vont apporter de la valeur dans nos architectures : ### Billing and Costs - [Announcing Data Exports for AWS Billing and Cost Management](https://aws.amazon.com/fr/about-aws/whats-new/2023/11/aws-billing-cost-management-data-exports/) - [Amazon Web Services announces Unified Billing and Cost Management console](https://aws.amazon.com/fr/about-aws/whats-new/2023/11/unified-billing-cost-management-console/) - [Introducing Cost Optimization Hub](https://aws.amazon.com/fr/about-aws/whats-new/2023/11/cost-optimization-hub/) - [Announcing the Cost and Usage Dashboard powered by Amazon QuickSight](https://aws.amazon.com/fr/about-aws/whats-new/2023/11/cost-usage-dashboard-amazon-quicksight/) ### Storage - [Announcing the new Amazon EFS Archive storage class](https://aws.amazon.com/fr/about-aws/whats-new/2023/11/amazon-efs-archive-storage-class/) - [Amazon CloudWatch Logs announces Infrequent Access log class](https://aws.amazon.com/fr/about-aws/whats-new/2023/11/amazon-cloudwatch-logs-infrequent-access-log-class/) ### Compute - [AWS Compute Optimizer introduces customizable rightsizing recommendations for Amazon Elastic Compute Cloud (EC2) Instances](https://aws.amazon.com/fr/about-aws/whats-new/2023/11/aws-compute-optimizer-customizable-rightsizing-ec2/) ### Kubernetes - [Amazon EKS introduces EKS Pod Identity](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-eks-pod-identity/) ### VDA - [Amazon WorkSpaces Multi-Region Resilience launches one-way data replication](https://aws.amazon.com/fr/about-aws/whats-new/2023/11/amazon-workspaces-multi-region-one-way-replication/) ### Gen AI - [AWS Step Functions launches optimized integration for Amazon Bedrock](https://aws.amazon.com/fr/about-aws/whats-new/2023/11/aws-step-functions-optimized-integration-bedrock/) ### Observabilité - [AWS announces CloudWatch Logs Anomaly Detection and Pattern analysis](https://aws.amazon.com/fr/about-aws/whats-new/2023/11/aws-cloudwatch-logs-anomaly-detection-pattern-analysis/) - [Amazon Managed Service for Prometheus launches an agentless collector for Prometheus metrics from Amazon EKS](https://aws.amazon.com/fr/about-aws/whats-new/2023/11/amazon-managed-service-prometheus-agentless-collector-metrics-eks/) - [CloudWatch now supports hybrid and multicloud metrics querying and alarming](https://aws.amazon.com/fr/about-aws/whats-new/2023/11/cloudwatch-hybrid-multicloud-metrics-querying-alarming/) - [Amazon CloudWatch announces AI-powered natural language query generation (in preview)](https://aws.amazon.com/fr/about-aws/whats-new/2023/11/amazon-cloudwatch-ai-powered-natural-language-query-generation-preview/) - [AWS Config launches generative AI-powered natural language querying (Preview)](https://aws.amazon.com/fr/about-aws/whats-new/2023/11/aws-config-generative-ai-powered-natural-language-querying-preview/) ### Data - [AWS Glue Data Quality announces anomaly detection and dynamic rules](https://aws.amazon.com/fr/about-aws/whats-new/2023/11/aws-glue-data-quality-anomaly-detection-dynamic-rules/) ### IaC - [AWS CloudFormation introduces Git management of stacks](https://aws.amazon.com/fr/about-aws/whats-new/2023/11/aws-cloudformation-git-management-stacks/) ### Sécurité - [Amazon Detective announces investigations for AWS Identity and Access Management (IAM)](https://aws.amazon.com/fr/about-aws/whats-new/2023/11/amazon-detective-investigations-iam/) - [Amazon Detective introduces finding group summaries using generative AI](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-detective-group-summaries-generative-ai/) - [AWS Secrets Manager now supports batch retrieval of secrets](https://aws.amazon.com/fr/about-aws/whats-new/2023/11/aws-secrets-manager-batch-retrieval-secrets/) - [Amazon GuardDuty now supports runtime monitoring for Amazon EC2 (Preview)](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-guardduty-runtime-monitoring-amazon-ec2-preview/) - [Introducing Amazon GuardDuty Amazon Elastic Container Service (ECS) Runtime Monitoring, including AWS Fargate](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-guardduty-ecs-runtime-monitoring-fargate/) - [Amazon S3 Access Grants integrate with identity providers to simplify data lake permissions](https://aws.amazon.com/fr/about-aws/whats-new/2023/11/amazon-s3-access-grants-data-lake-permissions/) - [AM Access Analyzer introduces custom policy checks powered by automated reasoning](https://aws.amazon.com/about-aws/whats-new/2023/11/iam-access-analyzer-custom-policy-check/) ### Autre - [AWS Systems Manager Automation makes it easier to author runbooks with new low-code visual design experience](https://aws.amazon.com/fr/about-aws/whats-new/2023/11/aws-systems-manager-automation-author-runbooks/) - [Announcing the general availability of AWS re:Post Private](https://aws.amazon.com/fr/about-aws/whats-new/2023/11/general-availability-aws-re-post-private/) - [Announcing AWS Console-to-Code (Preview) to generate code for console actions](https://aws.amazon.com/about-aws/whats-new/2023/11/aws-console-to-code-preview-generate-console-actions/) - [Automate AWS Control Tower landing zone operations using APIs](https://aws.amazon.com/fr/about-aws/whats-new/2023/11/automate-aws-control-tower-zone-operations-apis/) --- # Nouvelles et outils - semaine 43, 2023 > 2023-10-30T11:00:00.000Z | https://sylvain.bruas.fr/blog/2023/10/w43 Tags: outils, AWS Summary: Liste des nouvelles AWS qui me semblent intéressantes et des outils que j'ai pu découvrir grâce à mon réseau (W43) du 23 au 29 octobre 2023 ## Outils - [Permissions AWS](https://aws.permissions.cloud/) --- # Nouvelles et outils - semaine 41, 2023 > 2023-10-16T11:00:00.000Z | https://sylvain.bruas.fr/blog/2023/10/w41 Tags: outils, AWS Summary: Liste des nouvelles AWS qui me semblent intéressantes et des outils que j'ai pu découvrir grâce à mon réseau (W41) du 9 au 15 octobre 2023 ## Nouvelles AWS - [Annonce de la possibilité d'activer AWS Systems Manager par défaut pour toutes les instances Amazon Elastic Compute Cloud (EC2) d'une organisation](https://aws.amazon.com/fr/about-aws/whats-new/2023/10/enable-aws-systems-manager-ec2-instances-organization/) - [Le gestionnaire d'applications AWS Systems Manager est désormais compatible avec SAP HANA](https://aws.amazon.com/fr/about-aws/whats-new/2023/10/aws-systems-manager-application-manager-sap-hana/) ## Outils - [Microsoft Cloud Adoption Framework for Azure](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/) - [Boost efficiency and cost savings with new sustainability guidance in the Cloud Adoption Framework](https://azure.microsoft.com/en-us/blog/boost-efficiency-and-cost-savings-with-new-sustainability-guidance-in-the-cloud-adoption-framework/) --- # Nouvelles et outils - semaine 40, 2023 > 2023-10-09T11:00:00.000Z | https://sylvain.bruas.fr/blog/2023/10/w40 Tags: outils, AWS Summary: Liste des nouvelles AWS qui me semblent intéressantes et des outils que j'ai pu découvrir grâce à mon réseau (W40) du 2 au 8 octobre 2023 ## AWS - [AWS Health regroupe désormais les événements liés à la santé au sein de votre organisation sur Amazon EventBridge](https://aws.amazon.com/fr/about-aws/whats-new/2023/10/aws-health-aggregates-events-organization-eventbridge/) - [Le support étendu d'Amazon EKS pour les versions de Kubernetes est désormais disponible en version préliminaire](https://aws.amazon.com/fr/about-aws/whats-new/2023/10/amazon-eks-support-kubernetes-versions-preview/) ## Outils - [AWSume](https://awsu.me/) - [Diagrams](https://diagrams.mingrammer.com/) - [Topmate.io](https://topmate.io/) --- # Nouvelles et outils - semaine 39, 2023 > 2023-10-02T11:00:00.000Z | https://sylvain.bruas.fr/blog/2023/10/w39 Tags: outils, AWS Summary: Liste des nouvelles AWS qui me semblent intéressantes et des outils que j'ai pu découvrir grâce à mon réseau (W39) du 25 septembre au 1er octobre 2023 ## Nouvelles AWS - [Get the full benefits of IMDSv2 and disable IMDSv1 across your AWS infrastructure](https://aws.amazon.com/blogs/security/get-the-full-benefits-of-imdsv2-and-disable-imdsv1-across-your-aws-infrastructure/) --- # Nouvelles et outils - semaine 37, 2023 > 2023-09-18T11:00:00.000Z | https://sylvain.bruas.fr/blog/2023/09/w37 Tags: outils, AWS Summary: Liste des nouvelles AWS qui me semblent intéressantes et des outils que j'ai pu découvrir grâce à mon réseau (W37) du 11 au 17 septembre 2023 ## Nouvelles AWS - [Understanding DDoS simulation testing in AWS](https://aws.amazon.com/blogs/security/understanding-ddos-simulation-testing-at-aws/) - [Access accounts with AWS Management Console Private Access](https://aws.amazon.com/blogs/security/access-accounts-with-aws-management-console-private-access/) - [Best Practices from SMX for Improving Cloud ROI Through Data-Driven Decisions](https://aws.amazon.com/blogs/apn/best-practices-from-smx-for-improving-cloud-roi-through-data-driven-decisions/) - [Amazon EC2 prend désormais en charge le blocage de l'accès public pour les Amazon Machine Images](https://aws.amazon.com/fr/about-aws/whats-new/2023/09/amazon-ec2-block-public-access-machine-images/) - [Le déploiement multi-AZ d'Amazon RDS for PostgreSQL avec deux versions de secours lisibles prend désormais en charge les mises à niveau de versions majeures](https://aws.amazon.com/fr/about-aws/whats-new/2023/09/amazon-rds-postgresql-multi-az-deployment-readable-standbys-major-version-upgrades/) ## Outils - [Quota Monitor for AWS](https://app.raindrop.io/my/0/item/640843525/preview) : suivi des quotas - [IAMbic](https://www.iambic.org/) : gestion AWS Identity and Access Management (IAM) multi cloud - [Rclone](https://rclone.org/) : synchronisation de fichiers sur le cloud - [Cloudscape](https://cloudscape.design/) : conception d'application --- # Nouvelles et outils - semaine 36, 2023 > 2023-09-11T11:00:00.000Z | https://sylvain.bruas.fr/blog/2023/09/w36 Tags: outils, AWS Summary: Liste des nouvelles AWS qui me semblent intéressantes et des outils que j'ai pu découvrir grâce à mon réseau (W36) du 4 au 10 septembre 2023 ## Nouvelles AWS - [AWS SAM CLI annonce la prise en charge des tests locaux et du débogage sur les projets Terraform](https://aws.amazon.com/fr/about-aws/whats-new/2023/09/aws-sam-cli-local-testing-debugging-terraform-projects/) - [Amazon CloudWatch ajoute les journaux de plan de contrôle Amazon EKS dans les journaux payants](https://aws.amazon.com/fr/about-aws/whats-new/2023/09/amazon-cloudwatch-eks-control-plane-vended-logs/) ## Outils - [Kubernetes Instance Calculator](https://learnk8s.io/kubernetes-instance-calculator) : comment bien ranger vos pods dans vos nodes - [A visual guide on troubleshooting Kubernetes deployments](https://learnk8s.io/troubleshooting-deployments) : aide pour bien debugger les déploiements kubernetes. --- # Nouvelles et outils - semaine 35, 2023 > 2023-09-04T11:00:00.000Z | https://sylvain.bruas.fr/blog/2023/09/w35 Tags: outils, AWS Summary: Liste des nouvelles AWS qui me semblent intéressantes et des outils que j'ai pu découvrir grâce à mon réseau (W35) du 28 août au 3 septembre 2023 ## Nouvelles AWS - [Surveillez le déploiement Standard de SAP NetWeaver avec Amazon CloudWatch Application Insights](https://aws.amazon.com/fr/about-aws/whats-new/2023/08/monitor-sap-netweaver-deployment-cloudwatch-insights/) - [AWS Step Functions rationalise l'expérience de création dans Workflow Studio](https://aws.amazon.com/fr/about-aws/whats-new/2023/08/aws-step-functions-authoring-experience-workflow-studio/) - [Amazon OpenSearch Ingestion prend désormais en charge l'ingestion de données de streaming depuis Amazon MSK](https://aws.amazon.com/fr/about-aws/whats-new/2023/08/amazon-opensearch-ingestion-streaming-data-msk/) - [Amazon VPC CNI prend désormais en charge l'application de la politique réseau de Kubernetes](https://aws.amazon.com/fr/about-aws/whats-new/2023/08/amazon-vpc-cni-kubernetes-networkpolicy-enforcement/) - [AWS Backup prend désormais en charge la sélection des fuseaux horaires locaux](https://aws.amazon.com/fr/about-aws/whats-new/2023/08/aws-backup-local-time-zone-selections/) ## Outils - [Cloudsplaining](https://github.com/salesforce/cloudsplaining) : AWS IAM Security Assessment tool - [Policy Sentry](https://github.com/salesforce/policy_sentry) : Génération de politiques IAM - [AWS IAM Actions](https://www.awsiamactions.io/) : Liste des permissions IAM avec des détails --- # Nouvelles et outils - semaine 34, 2023 > 2023-08-28T11:00:00.000Z | https://sylvain.bruas.fr/blog/2023/08/w34 Tags: outils, AWS Summary: Liste des nouvelles AWS qui me semblent intéressantes et des outils que j'ai pu découvrir grâce à mon réseau (W34) du 21 au 27 août 2023 ## Nouvelles AWS - [L'Explorateur de coûts AWS annonce la prise en charge d'AWS Billing Conductor](https://aws.amazon.com/fr/about-aws/whats-new/2023/08/aws-cost-explorer-billing-conductor/) - [AWS Global Accelerator prend désormais en charge la préservation des adresses IP pour les points de terminaison Network Load Balancer](https://aws.amazon.com/fr/about-aws/whats-new/2023/08/aws-global-accelerator-client-ip-address-preservation-network-load-balancer-endpoints/) ## Outils - [Draw.io](https://www.drawio.com/) - [Excalidraw](https://excalidraw.com/) --- # Réduire les contraintes IP dans Amazon EKS > 2023-04-26T11:00:00.000Z | https://sylvain.bruas.fr/blog/2023/04/aws-eks-contrainte-ip Tags: EKS, VPC, Reseau, AWS Summary: Optimisez la gestion des adresses IP dans Amazon EKS avec Transit Gateway et NAT Gateway. Solutions réseau pour la scalabilité. _Cet article a été rédigé en collaboration avec Sébastien Allamand, Senior Container Specialist Solutions Architect pour la France._ Nos clients de taille importante sont souvent dans une démarche d'hybridation entre AWS et leurs datacenters. Ils ne peuvent mettre à disposition des environnements AWS qu'un nombre limité d'adresses IPV4s privées, contraint par leurs plans d'adressages on-premises. Les clusters [Amazon EKS](https://aws.amazon.com/fr/eks) doivent être des plateformes pérennes pouvant héberger les applications contenairisées existantes ou à venir. Ces clusters doivent donc être capables d'avoir un nombre important de pods, et donc par extension d'adresses IP. Ce nombre d'adresses IPs est généralement difficile à estimer à priori. Ce challenge difficilement identifiable et quantifiable est présent dans les environnements de non-production, tout comme de production. Cela peut mener à des blocages, puisque de nouveaux pods pourraient ne pas être créés par manque d'adresses IP. ### Sommaire 1. [Prérequis](#prérequis) 2. [Architecture](#architecture) 3. [Mise en œuvre](#mise-en-œuvre) 4. [Flux réseau](#flux-réseau) 5. [Résultats](#résultats) 6. [Limites](#limites) 7. [Conclusion](#conclusion) ### Prérequis Choisir une plage d'adresses IP qui sera associée aux pods EKS, et qui sera considérée comme non-routable sur le réseau de l'entreprise. Dans notre exemple nous choisissons la plage 10.100.0.0/16 et nous déployons une [AWS Transit Gateway](https://aws.amazon.com/fr/transit-gateway/) (TGW). Ce routeur cloud permet de connecter les [Amazon Virtual Private Cloud](https://aws.amazon.com/fr/vpc/) (VPC) ainsi que les réseaux on-premises. Dans notre contexte, la transit gateway et les éléments liés ont été livrés par l'équipe réseau. ### Architecture ![Architecture réseau](/static/2023/04/Architecture-Reseau.webp) Figure 1 – Architecture réseau ### Mise en œuvre Celle-ci s'effectue en plusieurs étapes : - Déclarer la plage d'adresses IP en tant que blackhole dans les tables de routage de la Transit Gateway - Aller sur [https://console.aws.amazon.com/vpc/home#TransitGatewayRouteTables](https://console.aws.amazon.com/vpc/home#TransitGatewayRouteTables), - Sélectionner une des tables de routage à modifier, - Sélectionner l'onglet **Routes** et cliquer sur **Créer une route statique** ![TGW route Statique part 1](/static/2023/04/TGW-Config-1.webp) - Cocher la case **Blackhole** pour le **Type** et créer la route ![TGW route Statique part 2](/static/2023/04/TGW-Config-2.webp) - Ajouter cette plage d'adresses IP à chaque VPC hébergeant des clusters Amazon EKS, et créer des subnets avec ce range d'adresses IP. En ayant créé précédemment la route blackhole sur la transit gateway, nous nous assurons qu'aucune connexion ne pourra s'effectuer entre les VPC modifiés. - Aller sur [https://console.aws.amazon.com/vpc/home#vpcs](https://console.aws.amazon.com/vpc/home#vpcs) - Choisir le VPC à modifier puis Edit CIDRs dans les actions ![TGW route Statique part 3](/static/2023/04/TGW-Config-3.webp) - Ajouter la plage ![TGW route Statique part 4](/static/2023/04/TGW-Config-4.webp) ![TGW route Statique part 5](/static/2023/04/TGW-Config-5.webp) - Créer une private NAT Gateway sur un subnet privé routable pour autoriser les flux sortant des pods : - Aller sur https://console.aws.amazon.com/vpc/home#NatGateways - Cliquer sur créer une NAT Gateway - Choisir le type de connexion privée, et installer cette NAT Gateway dans un subnet privé routable. ![NAT Gateway part 1](/static/2023/04/NATG-Config-1.webp) - Configurer la table de routage des subnets des pods pour utiliser la NAT Gateway ![NAT Gateway part 2](/static/2023/04/NATG-Config-2.webp) - Conserver le point d'entrée du cluster Amazon EKS dans les réseaux privés routables. Il est nécessaire que le load balancer soit dans des subnets routables, sinon le cluster EKS ne pourra plus être accessible en dehors du VPC. ### Flux réseau #### Entre les pods et les autres workload de VPC1 La plage d'adressesIP supplémentaire associée au VPC permet aux pods d'échanger directement avec n'importe quel workload interne au VPC. Les tables de routages créées dans ce VPC incluent automatiquement toutes les plages d'adresses IPs du VPCs ![Architecture Réseau VPC](/static/2023/04/Architecture-Reseau-VPC1.webp) #### Depuis les pods de VPC1 vers l'extérieur du VPC Le flux réseau est initié par le pod (1) et celui-ci va utiliser la private NAT Gateway. La translation d'adresses IP est effectuée par la NAT Gateway et le flux (2) devient donc routable à l'extérieur du VPC, et peut par exemple joindre le datacenter (3). Pour les workloads de production, l'utilisation d'au moins 2 private NAT gateway est recommandée pour assurer sa haute disponibilité. ![Architecture Réseau VPC out](/static/2023/04/Architecture-Reseau-VPC1-out.webp) #### Depuis un client hors de VPC1 Un client externe va utiliser le load-balancer pour utiliser les services exposés, ce design n'a pas d'influence sur ce point. ![Architecture Réseau VPC in](/static/2023/04/Architecture-Reseau-VPC1-in.webp) #### Entre les Pods de VPC1 et VPC2 Le Pod du VPC1 va passer par la NAT Gateway pour envoyer sa requête (1), la translation d'adresses IP va s'effectuer et la requête va pouvoir sortir du VPC (2). La requête va ensuite traverser le load-balancer de l'EKS du VPC2 (3) et va être redirigée vers un pod pouvant répondre à la requête (4). ### Résultats La solution proposée n'a d'impact que sur les flux réseaux partant d'un pod vers l'exterieur du VPC. Nous avons mesuré via 100 requêtes ICMP (Internet Control Message Protocol) un délai moyen supplémentaire d'environ 100ms. Commande exécutée : ```shell > ping -c 100 -A -n ``` -c 100 : envoi de 100 requêtes ICMP -A : L'intervalle inter-paquets s'adapte au délai aller-retour, pour réduire l'attente du résultat -n : pas de résolution de nom - Architecture initiale (sans NAT Gateway) ```shell --- 10.1.0.19 ping statistics --- 100 packets transmitted, 100 received, 0% packet loss, time 19900ms rtt min/avg/max/mdev = 0.635/0.730/1.229/0.094 ms, ipg/ewma 201.016/0.725 ms ``` - Architecture proposée (ie utilisant une Private NAT Gateway) ```shell --- 10.1.0.19 ping statistics --- 100 packets transmitted, 100 received, 0% packet loss, time 19884ms rtt min/avg/max/mdev = 0.737/0.893/2.360/0.220 ms, ipg/ewma 200.850/1.031 ms ``` On voit donc que la solution mise en oeuvre a un impact limitée sur les performances des flux réseaux. ### Limites Il existe 2 limites principales : - La taille limite que l'on peut réserver dans l'IPAM pour un seul réseau. De fait, il est important d'échanger avec les équipes réseau pour connaitre les disponibilités et pour récupérer la taille la plus large possible, - Les limites de la Private Nat Gateway : - Protocoles pris en charge : TCP,UDP, ICMP, - 5 Gb/s de bande passante (mise à l'échelle automatique jusqu'à 45 Gb/s), - 1 million de paquets par seconde (mise à l'échelle automatique jusqu'à 4 millions de paquets par seconde), - 55 000 connexions simultanées pour chaque destination unique, - Liste complète disponible dans la [documentation](https://docs.aws.amazon.com/fr_fr/vpc/latest/userguide/vpc-nat-gateway.html#nat-gateway-basic) ### Conclusion Les exemples, cités en introduction, montrent qu'il est nécessaire d'avoir un inventaire précis des adresses IP disponibles, et une stratégie d'utilisation. Cette solution utilise des concepts réseaux classiques de NAT, exploités pour palier à la quantité limitée d'adresse IP en IPV4, qui peut se présenter lors de l'utilisation d'Amazon EKS à une échelle importante. Cette solution pourrait être également utilisée on-premise, même si cela n'est pas forcément nécessaire car d'autre outils directement intégrables à Kubernetes (tel que [Cilium](https://cilium.io/) par exemple) permettent de gérer plus facilement les adresses IPs disponibles. D'autres CNIs peuvent être utilisées pour obtenir une solution équivalente. L'intérêt de ce qui est proposé ici est la visibilité du mécanisme de réseau non-routable, qui reste au niveau AWS. La responsabilité peut donc être conservée par les équipes réseaux, et les services managés par AWS. La solution présentée et illustrée par les schémas décrit une plateforme n'ayant que des flux applicatifs privés entre les différents VPCs et le datacenter on-premise. Celle-ci peut facilement être adaptée pour une plateforme qui serait exposée sur internet. --- # DevOps : concepts et base > 2019-06-19T11:00:00.000Z | https://sylvain.bruas.fr/blog/2019/06/devops-concepts-et-base Tags: DevOps, Automatisation, Performance, Culture, Outils, Methodologie, AWS Summary: Le DevOps est un concept protéiforme difficile à cerner. Découvrez les bases et ce qui constitue réellement le DevOps dans le monde de l'IT moderne. ![DevOps](/static/2019/06/DevOpsSchema.webp) ## Qu'est-ce que le DevOps ? Vous l'aurez peut-être deviné, DevOps provient de la contraction des mots développement et opérations. Il s'agit d'une approche culturelle et technique reposant sur des principes agiles et visant à renforcer la collaboration entre les équipes métiers, développement, opérations et assurances qualité dans le but de délivrer des logiciels de manière continue. Cette organisation permet à une entreprise de profiter plus rapidement de certaines opportunités de marché et d'avoir un retour client accéléré. Dans une approche DevOps, les équipes de développement et d'opérations collaborent pleinement et peuvent même fusionner. Ces équipes travaillent ainsi sur tout le cycle de vie des applications comme l'illustre le schéma au dessus. Il est important de garder à l'esprit qu'une approche DevOps n'est pas uniquement technique : elle est aussi culturelle et relationnelle. Elle repose sur la communication entre tous les services d'une entreprise au-delà des équipes purement techniques (développement et opérations). L'approche DevOps doit ainsi englober les parties prenantes d'un projet tels que : le marketing, la direction et même les clients… ## Les bénéfices d'une approche DevOps La mise en application de l'approche DevOps au sein des équipes et des environnements garantit de nombreux avantages comme la facilité de la maintenance, l'automatisation des tâches ou l'amélioration de la communication inter-équipes. - **Publications plus rapides et plus légères**. La publication fréquente de nouvelles versions d'un logiciel va permettre de mettre à disposition les nouvelles fonctionnalités plus rapidement aux client (gain de compétitivité à la clé). Avec des déploiements plus fréquents, ces derniers sont moins importants et posent potentiellement moins de problèmes. La remontée de bugs est également accélérée. - **L'automatisation, gage de fiabilité**. Une approche DevOps permet un gain non négligeable en termes de sécurité et de fiabilité. Grâce aux processus automatisés, on ne risque plus d'erreurs humaines liées aux tâches manuelles. De nombreux tests et vérifications automatiques sont effectués avant d'arriver à une phase de déploiement qui devient un non-événement. - **Automatisation & productivité**. Du fait de cette forte automatisation, on bénéficie aussi d'un gain en termes de productivité. On peut profiter de plus de temps pour travailler sur de nouvelles fonctionnalités au lieu d'effectuer des tâches manuelles et lentes de tests, gestion d'infrastructures ou encore de déploiement. - **Facilitation de la communication interne**. Le DevOps vise aussi à améliorer la collaboration entre les équipes, qu'elles soient techniques ou non. L'objectif de la philosophie DevOps est d'aligner tout le monde sur le même objectif pour éviter les conflits. Par exemple, de nombreux outils de supervisions retranscrivent sous forme de tableau (dashboard) les données et facilitent la compréhension et le suivi par tous. ![DevOps Benefits](/static/2019/06/DevOpsBenefits.webp) ## Quelques pratiques de l'approche DevOps L'automatisation étant au cœur de la philosophie DevOps et de nombreuses pratiques y participent mais ces changements techniques impliquent aussi une organisation différente. Voici quelques grandes pratiques DevOps. - **Intégration continue**. Méthode de développement logiciel permettant d'intégrer régulièrement chaque changement du code au niveau d'un dépôt de code source (GitLab, Bitbucket). A la suite de cette intégration, des opérations automatisées de build et de tests sont lancés avec le nouveau code source. - **Livraison et déploiement continue**. Il s'agit de l'extension même de l'intégration continue. En effet, si le processus d'intégration continue permet de tester l'application à chaque changement de manière optimale, on peut se permettre par la suite de préparer un livrable ou bien de carrément déployer l'application quand tous les tests sont au vert et ce de manière automatisée. - **Infrastructure as Code**. Le concept d'Infrastructure as Code se réfère au fait de décrire son infrastructure sous forme d'un fichier texte (JSON/YAML). L'infrastructure peut alors être gérée comme du code source normal en étant versionnée ou encore passée dans un processus d'intégration ou de déploiement continu. Grâce aux API proposés par les différents Cloud providers, l'IaC est désormais accessible grâce à des outils comme Terraform ou AWS Cloudformation (pour ne citer qu'eux) qui prennent en entrée ce fichier respectant une certaine norme puis déploient et configurent l'infrastructure décrite de manière automatisée. Cela permet une forte standardisation, une limitation des risques d'erreurs de configuration mais aussi une reproductibilité grandement simplifiée. - **Monitoring et feedback**. Dans une démarche DevOps le monitoring aussi bien au niveau de l'application que de l'infrastructure est important pour détecter les problèmes de performances, de sécurité ou encore d'expérience utilisateur. Cela constitue la boucle de feedback de la démarche DevOps qui permet de mettre en lumière les problèmes posés par les mises à jour et les potentielles améliorations à apporter. - **Communication et collaboration renforcées**. Au-delà de la partie technique, comme nous l'avons évoqué en début d'article, une démarche DevOps passe aussi par l'amélioration de la collaboration au sein et entre les équipes techniques (développement, opérationnel) et non techniques (marketing, direction …). Le DevOps casse les frontières et implique un partage de l'information entre toutes les parties prenantes à un projet dans le but de garder un objectif commun. ![DevOps Apps](/static/2019/06/CloudAppsDevOps.webp) ## En conclusion L'approche DevOps apporte de nombreux avantages en termes de productivité, de fiabilité et de maintenance. En facilitant la communication entre les pôles d'une équipe, l'approche DevOps est aussi un facteur de cohésion : grâce à des métriques fiables et communes, un environnement peut être analysé et optimisé par l'ensemble de l'équipe. L'automatisation des processus est important aussi bien en termes d'efficacité que de fiabilité. L'approche DevOps reposant sur les concepts d'agilité, les retours utilisateurs peuvent être intégrés rapidement au sein des solutions déployées. L'approche DevOps serait donc le saint Graal du monde de l'IT ? Sans doute mais la mise en place des principes DevOps est toujours une gageure quelle que soit la structure. La bonne application des pratiques nécessite des équipes volontaires aussi bien dans la technique (CI/CD et utilisations d'outils IaC) que dans le relationnel (partage de l'information renforcée, amélioration de la communication). Comme souvent, une bonne synchronisation des équipes et l'application de bonnes pratiques sont la base d'un travail efficace. --- # AWS Summit Paris 2019 Recap > 2019-04-11T11:00:00.000Z | https://sylvain.bruas.fr/blog/2019/04/aws-summit-paris-2019-recap Tags: AWS Summit, AI, AWS Summary: AWS Summit Paris 2019 recap: key announcements, AWS innovations, notable technical sessions and insights from the Corexpert team. ![AWS Summit Paris 2019](/static/2019/04/AmphiKeynote.webp) This day dedicated to the AWS cloud brought together partners and the public around cloud topics and made innovation more accessible! The opening Keynote, introduced by Julien Grouès, CEO of AWS France, proved revealing of the potential of the French digital world, which has been growing over the years: only 300 participants 7 years ago compared to over 7,000 today, 30 customer testimonials and 70 sponsors. Experience reports from prestigious companies across diverse industries accompanied the French AWS CEO's speech and marked the opening of this day of collaboration. ![AWSUserGroup](/static/2019/04/AWSUserGroup.webp) It was also an opportunity for French AWS communities to gather around a booth to exchange and share their knowledge with visitors at the Palais des Congrès. Always a convivial moment, the [AWS User Groups](https://aws.amazon.com/fr/blogs/france/les-meetups-aws-en-france/) are a way to increase your knowledge and share experience reports or workshops around AWS. You can easily find one near you! If you are in Lyon, don't hesitate to join the group! The AWS Summit Paris 2019 also marked the launch of the autonomous racing championship: the DeepRacer League was animated throughout the day by commentator Marc Chavet. The DeepRacer League race consists of driving a mini-car piloted using reinforcement learning, an advanced part of Machine Learning. The goal is to complete laps with the shortest possible time! Two of our Teamwork colleagues took on the challenge hoping to win the AWS DeepRacer Cup with mixed success. A race victory would secure a spot for the grand finale at re:Invent 2019 in the United States. ![DeepRacer1](/static/2019/04/DeepRacerSylvain.webp)   We also participated in the AWS GameDay on Monday, April 1st! One day before the AWS Summit Paris began, TeamWork was there to take on the challenge. The GameDay objective is to solve a given problem with well-defined AWS resources. For this session, 3 applications had to be deployed and points were awarded based on the success or failure of requests. Special attention was paid to the scalability of the whole system to withstand any load. "Everything fails all the time," as AWS CTO Werner Vogels says, and part of this challenge was reflected in the project to be completed! Teams had to constantly monitor and verify the proper functioning of their infrastructure, which was being disrupted by a group that could change certain configurations (such as routing tables...). Our team demonstrated its efficiency: within the 2.5-hour timeframe, Jeremy, Marouen and Yahya secured second place in the competition on their first participation! ![GameDay](/static/2019/04/GamesDay2.webp) --- # Retour sur l'AWS Summit Paris 2019 > 2019-04-11T11:00:00.000Z | https://sylvain.bruas.fr/blog/2019/04/retour-sur-laws-summit-paris-2019 Tags: AWS Summit, IA, AWS Summary: Retour sur l'AWS Summit Paris 2019 : principales annonces, innovations AWS, sessions techniques marquantes et insights de l'équipe Corexpert. ![AWS Summit Paris 2019](/static/2019/04/AmphiKeynote.webp) Cette journée consacrée au cloud AWS a permis de rassembler partenaires et public autour des thématiques du cloud et permettre une plus grande accessibilités des acteurs de l'innovation ! La Keynote d'ouverture introduit par Julien Grouès, directeur général d'AWS en France, s'est avérée révélatrice du potentiel du monde numérique français qui prend de l'ampleur au fil des années : 300 participants seulement il y a 7 ans contre plus de 7000 aujourd'hui, 30 témoignages clients et 70 sponsors. Des retours d'expériences de prestigieuses entreprises aux domaines diverses ont accompagné le discours du CEO français d'AWS et marqué l'ouverture de cette journée de collaboration. ![AWSUserGroup](/static/2019/04/AWSUserGroup.webp) Ce fut également l'occasion pour les communautés AWS françaises de se réunir autour d'un stand pour échanger et partager leurs connaissances avec les visiteurs du Palais des Congrès. Toujours un moment convivial, les [AWS User Groups](https://aws.amazon.com/fr/blogs/france/les-meetups-aws-en-france/) sont un moyen d'accroitre ses connaissances et de partager des retours d'expérience ou des ateliers autour d'AWS. Vous pouvez trouver facilement un près de chez vous ! Si vous êtes Lyonnais, n'hésitez pas à rejoindre le groupe ! L'AWS Summit Paris 2019 marque aussi le lancement du championnat de course autonome : la DeepRacer League a été animée tout au long de la journée par le commentateur Marc Chavet. La course de DeepRacer League consiste à faire rouler une mini-voiture pilotée grâce au reinforcement learning partie avancée du Machine Learning. L'objectif est de réussir des tours de circuits avec un temps de parcours le plus court possible ! Deux de nos collaborateurs Teamwork se sont lancés dans l'aventure dans l'espoir de remporter la AWS DeepRacer Cup avec un succès mitigé. Une victoire à la course permettait de sécuriser un spot pour la grande finale qui aura lieu lors de la Re:invent 2019 aux Etats-Unis. ![DeepRacer1](/static/2019/04/DeepRacerSylvain.webp)   Nous avons également participé à l'AWS GameDay le lundi 1 avril ! Un jour avant le début du AWS Summit Paris, TeamWork était présent pour relever le challenge. L'objectif du GameDay est résoudre un problème donné avec des ressources AWS bien définies. Pour cette session, 3 applications devaient être déployées et des points étaient attribués selon le succès ou l'échec des requêtes. Une attention particulière était portée sur la scalabilité de l'ensemble afin de résister à toutes charges. "Everything fails all the time" dixit le CTO de AWS, Werner Vogels, et une partie de cette problématique se retrouvait dans le projet à mener à bien ! Les équipes devaient en permanence surveiller et vérifier le bon fonctionnement de leur infrastructure mise à mal par un groupe pouvant changer certaines configurations (comme les tables de routage…). Notre équipe a su démontrer son efficacité : dans le délai de 2h30, Jeremy, Marouen et Yahya ont su gagner la seconde place du concours pour leur première participation ! ![GameDay](/static/2019/04/GamesDay2.webp) --- # AWS Service Level Agreement > 2019-01-10T11:00:00.000Z | https://sylvain.bruas.fr/blog/2019/01/aws-service-level-agreement Tags: SLA, AWS Summary: Our clients often ask: AWS always talks about High Availability and Very High Availability, but do they really commit? Is there an SLA? ![SLA AWS](/static/2019/01/sla.webp) ## What is an SLA? The SLA, or [Service Level Agreement](https://en.wikipedia.org/wiki/Service-level_agreement), is the contractual quality and performance level of a service or technical infrastructure. In the case of AWS, a cloud provider, we are indeed talking about a service, since we operate in the IaaS (Infrastructure as a Service) world. The SLA must first define what service we are talking about, and the performance criteria the provider commits to. This can include response time, guaranteed functionality, complete service availability, etc. ## SLA at AWS Below, we will review some AWS services that have an SLA at the time of writing this article. This list is of course not exhaustive. ### Amazon Route 53: AWS DNS SLA The AWS DNS service, Amazon Route 53, has a service availability [SLA](https://aws.amazon.com/route53/sla/) at the highest possible level. Indeed, there is a **100%** availability commitment on the service, which is stated as "Amazon Route 53 will not fail to respond to your DNS queries during a monthly billing cycle." Why mention a month? Because AWS commits, in case of a proven failure, to reimburse you in the form of credits on that billing cycle. ![sla-amazon-route-53](/static/2019/01/SLA-Amazon-Route-53.webp) Excerpt from the SLA page – Amazon Route 53 as of January 10, 2019   ### Amazon EC2: AWS VM SLA AWS's flagship service, Amazon EC2 and Amazon EBS respectively provide the managed hypervisor to run your Virtual Machines (aka EC2 instances) and virtualized storage Amazon Elastic Block Store (EBS). The SLA has been extended to Amazon Elastic Container Service (ECS) and AWS Fargate (two Docker container-related services) since 2018. The [service SLA](https://aws.amazon.com/ec2/sla/), with Amazon Web Services' commitment, is at least 99.95% monthly — less than 22 minutes of downtime. If unavailability is proven between 99.90% and 99.99%, AWS commits to a 10% discount in AWS credits on the EC2 service, and below 99.0% availability, AWS offers a 30% credit discount. It is important to note that the SLA is tied to the "Region Unavailable" state. If you don't already know, a region is a set of multiple (2+) Availability Zones, but within the SLA framework, AWS specifies that the "Region Unavailable" state applies if more than one Availability Zone where you run EC2 instances is unavailable — meaning instances no longer have internet access. EBS unavailability is confirmed when storage volumes no longer generate I/O with a non-empty queue. ### Amazon RDS: AWS Managed Database SLA Amazon RDS is the AWS managed database service. It currently supports MySQL, Oracle, PostgreSQL, MariaDB, Microsoft SQL Server, and AuroraDB. However, the [SLA offered by AWS](https://aws.amazon.com/rds/sla/) only covers Multi-AZ instances (i.e., with a standby server in another Availability Zone) for SQL engines: Oracle, MariaDB, MySQL & PostgreSQL. This SLA is 99.95% service availability. Unavailability is confirmed when all connection requests fail for one minute on the Multi-AZ RDS instance. ![sla-amazon-rds](/static/2019/01/SLA-Amazon-RDS.webp) AWS commitment for RDS and credit reimbursement as of January 10, 2019 ### Amazon S3: AWS Object Storage SLA Amazon S3 is the object storage service. It is one of AWS's oldest services and has a data durability of 99.999999999% in standard storage mode. However, the SLA concerns the availability of access to stored data via the AWS API. The [Amazon S3 SLA](https://aws.amazon.com/s3/sla/) is therefore calculated based on error counting or API unavailability over 5-minute periods. AWS's commitment is to maintain availability above 99.9% monthly, which represents less than 43 minutes and 12 seconds. If AWS cannot ensure this availability in the region where your S3 bucket is stored, then a 10% discount on S3 storage costs will be returned as credits, and below 99.0%, the credit discount will be 25% of the Amazon S3 service cost. Since January 2019, these rules have been extended to Amazon Elastic File System (EFS) with the same commitments as for S3. Amazon EFS is a managed simple file storage system (AWS manages the infrastructure for you). ### Amazon CloudFront: AWS CDN SLA Amazon CloudFront is the AWS CDN service. With several dozen "Edge Locations," this service caches web requests according to your chosen behaviors and URL patterns. It enables accelerated data delivery and loading on websites and mobile applications, especially when media content is being transmitted. AWS [commits to maintaining](https://aws.amazon.com/cloudfront/sla/) overall service availability above 99.9% monthly (identical to Amazon S3). The discounts applied to the service in case of proven failure, also based on the frequency of data access errors, are identical to those of Amazon S3. ### AWS Shield: Anti-DDoS Protection Service SLA Launched at re:Invent 2016, AWS Shield is the official AWS anti-DDoS protection. The service uses and protects other services Amazon CloudFront and Amazon Route 53, and [its SLA](https://aws.amazon.com/shield/sla/), measured over 24-hour periods, is directly tied to the SLAs of the previously mentioned products. This SLA can be understood as a simple reminder that using AWS Shield in front of Amazon CloudFront or Amazon Route 53 does not modify their SLA. ### Amazon API Gateway: API Management SLA Since January 2019, [AWS commits to ensuring](https://aws.amazon.com/fr/api-gateway/sla/) 99.95% monthly availability of the Amazon API Gateway service. This fully managed service facilitates the management, monitoring, and security of APIs of any size. In case of service disruption, the allocated credit is identical to RDS: 10% discount between 99.0% and 99.95% and 25% discount for monthly availability below 99.0%. ## Calculating the SLA of an AWS Infrastructure Let's start with a fairly standard Web App infrastructure. It consists of several front-end application servers — here EC2 C4.Large instances — running the same code on each instance, with multi-Availability Zone redundancy. The database is a MySQL on RDS in Multi-AZ (Standby Instance). Static site elements are stored on S3. CloudFront is placed in front of the Load Balancer, caching static elements from S3 and rerouting other requests to the Load Balancer. Route 53 manages the site's domain name. ![cloudcraft-web-app](/static/2019/01/cloudcraft-web-app.webp) Web Infrastructure: Amazon Route 53, CloudFront, S3, EC2 and RDS Here is how we can calculate the SLA of this infrastructure. Of course, this applies in the case of a failure of all AWS services used in a region, and within the SLA framework of each service. In this case, the infrastructure cannot claim a higher SLA without additional redundancy. - RDS Multi-AZ MySQL: SLA of 99.95% - EC2: SLA of 99.95% - CloudFront: SLA of 99.9% - S3: SLA of 99.9% - Route 53: 100.0% The raw infrastructure SLA will be: ``` 99.95% x 99.95% x 99.9% x 99.9% x 100% = 99.70% ``` If we consider that S3 unavailability is not critical for maintaining web infrastructure availability (for example, an API) and that we handle potential CloudFront downtime via Route 53 by pointing to the Load Balancer as a backup, we gain 0.2% SLA simply by modifying and optimizing the infrastructure design: ``` 99.95% x 99.95% x 100% = 99.90% ``` --- # Le Service Level Agreement chez AWS > 2019-01-10T11:00:00.000Z | https://sylvain.bruas.fr/blog/2019/01/sla-aws Tags: SLA, AWS Summary: AWS s'engage-t-il vraiment sur la disponibilité ? Décryptage du SLA, niveaux de service, crédits et engagements concrets par service. ![SLA AWS](/static/2019/01/sla.webp) ## Qu’est ce que le SLA ? Le SLA, ou [Service Level Agreement](https://fr.wikipedia.org/wiki/Service-level_agreement), est le niveau de qualité et de performance contractuel d’un service ou d’une infrastructure technique. Dans le cas de AWS, fournisseur Cloud, on parlera donc bien d’un service, vu qu’on évolue dans le monde IaaS – Infrastructure as a Service ! Le SLA doit cadrer en premier lieu de quelle fourniture nous parlons, et les critères de performances sur lesquels le fournisseur va s’engager. On pourra donc parler de temps de réponse, de fonctionnalité assurée, de disponibilité complète du service etc. ## SLA chez AWS Nous allons parcourir ci-dessous les quelques services de l’offre AWS, qui possèdent un SLA à la date de rédaction de cet article. Bien évidemment la liste est non exhaustive. ### Amazon Route 53 : SLA du DNS AWS Le service DNS de AWS, [Amazon Route 53](https://docs.aws.amazon.com/route53/), possède un [SLA](https://aws.amazon.com/route53/sla/) de disponibilité du service du niveau le plus haut possible. En effet, on a ici un engagement de disponibilité de **100%** sur le service, ce qui est explicité par « Amazon Route 53 n’échouera pas pour répondre à vos requêtes DNS dans le cycle de facturation d’un mois ». Pourquoi parler d’un mois ? Car AWS, s’engage, en cas d’éventuelle défaillance avérée, de vous rembourser sous forme de crédits sur ce cycle de facturation. ![sla-amazon-route-53](/static/2019/01/SLA-Amazon-Route-53.webp) Extrait de la page SLA – Amazon Route 53 au 10 janvier 2019   ### Amazon EC2 : SLA des VM AWS Service principal de AWS, [Amazon Elastic Compute Cloud (EC2)](https://docs.aws.amazon.com/ec2/) et Amazon EBS fournissent respectivement l’hyperviseur managé pour exécuter vos Machines Virtuelles, aka instances EC2 et le stockage virtualisé [Amazon Elastic Block Store (EBS)](https://docs.aws.amazon.com/ebs/). Le SLA a été étendu à [Amazon Elastic Container Service (ECS)](https://docs.aws.amazon.com/ecs/) et [AWS Fargate](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/AWS_Fargate.html) (deux services ayant traits aux conteneurs Docker) depuis 2018. Le [SLA des services](https://aws.amazon.com/ec2/sla/), avec l’engagement de Amazon Web Services, est d’au moins 99.95% mensuel. Soient moins de 22 minutes. Si une indisponibilité est avérée entre 99.90 et 99.99%, AWS s’engage à effectuer une remise de 10% en crédits AWS sur le service EC2 et en deçà de 99.0% de disponibilité AWS propose une remise de 30% en crédits. Il est important de noter que le SLA est lié à l’état « Region Unavailable« . Si vous ne le savez pas déjà, une région est l’ensemble de plusieurs zones (2+) de disponibilités mais dans le cadre du SLA, AWS précise que l’état « Région indisponible » vous concerne si plus d’une zone de disponibilité où vous exécutez des instances EC2 est indisponible, c’est-à-dire que les instances n’ont plus accès à Internet. L’indisponibilité de EBS est avérée lorsque les volumes de stockage ne génèrent plus d’I/O avec une file d’attente non vide. ### Amazon RDS, SLA des bases de données managées AWS [Amazon Relational Database Service (RDS)](https://docs.aws.amazon.com/rds/) est le service de Base de données managée par AWS, il supporte à ce jour MySQL, Oracle, PostgreSQL, MariaDB, Microsoft SQL Server, AuroraDB. Mais le [SLA proposé par AWS](https://aws.amazon.com/rds/sla/), concerne uniquement les instances Multi-AZ (c’est à dire avec un serveur en Stand-By mode dans une autre zone de disponibilité) des moteurs SQL : Oracle, MariaDB, MySQL & PostgreSQL. Ce SLA est de 99.95% de disponibilité du service. L’indisponibilité est avérée quand toutes les requêtes de connexion échouent pendant une minute sur l’instance RDS multi-AZ. ![sla-amazon-rds](/static/2019/01/SLA-Amazon-RDS.webp) Engagement de AWS pour RDS et remboursement en crédits au 10 janvier 2019 ### Amazon S3, SLA du stockage objet AWS [Amazon Simple Storage Service (S3)](https://docs.aws.amazon.com/s3/) est le service de stockage d’objets, il est l’un des plus anciens services de AWS et possède une durabilité des données de 99.999999999% en mode de stockage standard. Toutefois le SLA concerne la disponibilité d’accès à la données stockée via l’API AWS. Le [SLA de Amazon S3](https://aws.amazon.com/s3/sla/) est donc calculé sur le comptage d’erreurs ou d’indisponibilité de l’API sur 5 minutes. L’engagement de AWS est de conserver une disponibilité au-delà de 99.9% mensuel, ce qui représente moins de 43 minutes 12 secondes. Si AWS ne peut assurer cette disponibilité sur la région où est stocké votre bucket S3, alors 10% de remise sur le coût de stockage S3 seront reversés en crédits, et en deçà de 99.0%, alors la remise en crédit s’élèvera à 25% du coût du service Amazon S3. Depuis janvier 2019, ces règles ont été étendues à Amazon Elastic File System (EFS) avec les mêmes engagements que pour S3. Amazon EFS est un système de stockage de fichiers simples managé (AWS gère l’infrastructure pour vous). ### Amazon CloudFront, SLA du CDN AWS [Amazon CloudFront](https://docs.aws.amazon.com/cloudfront/) est le service CDN de AWS, avec plusieurs dizaines de « Edge Locations », ce service met en cache les requêtes web selon vos comportements et pattern d’URLs choisis. Il permet des diffusions et donc des chargements de données accélérés sur les sites web et applications mobile, notamment lorsque du contenu media transite. AWS [s’engage à maintenir](https://aws.amazon.com/cloudfront/sla/) une disponibilité globale du service au-dessus de 99.9% mensuel (identique à Amazon S3). Les remises effectuées sur le service, en cas de défaillance avérée, également basé sur la fréquence des erreurs d’accès aux données sont identiques à celles de Amazon S3. ### AWS Shield, SLA du service de protection anti-DDoS Lancé lors du re:Invent 2016, AWS Shield est l’officialisation de la protection anti DDoS de AWS. Le service utilise et protège les autres services Amazon CloudFront et Amazon Route 53, et [son SLA](https://aws.amazon.com/shield/sla/), ramené sur des périodes de 24 heures, est lié directement aux SLA des produits cités précédemment. On pourra donc traduire ce SLA, par un simple rappel que l’utilisation du service AWS Shield devant Amazon CloudFront ou Amazon Route 53 ne modifie pas leur SLA. ### Amazon API Gateway, SLA sur la gestion des API Depuis janvier 2019, [AWS s’engage à assurer une disponibilité](https://aws.amazon.com/fr/api-gateway/sla/) de 99.95% mensuel du service Amazon API Gateway. Ce service entièrement managé facilite la gestion, la surveillance et la sécurité des API de n’importe quelle taille. En cas de rupture du service, le crédit alloué est identique à ceux de RDS : 10% de remise entre 99.0% et 99.95% et 25% de remise pour une disponibilité mensuelle moindre à 99.0%. ## Calcul du SLA d’une infrastructure AWS Partons d’une infrastructure Web App, relativement classique. Elle est composée de plusieurs serveurs applicatifs frontaux, ici EC2 C4.Large, le code exécuté est le même sur chaque instance, et nous avons une redondance multi-zone de disponibilités. La base de données est un MySQL sur RDS en Multi-AZ (Stand-By Instance). Les éléments statiques du sites sont stockés sur S3. CloudFront, est placé devant le Load Balancer, il met en cache les éléments statiques de S3 et reroute les autres requêtes sur le LoadBalancer. Route53 gère le nom de domaine du site. ![cloudcraft-web-app](/static/2019/01/cloudcraft-web-app.webp) Infrastructure Web : Amazon Route 53, CloudFront, S3, EC2 et RDS Voici comment nous pouvons calculer le SLA de cette infrastructure, bien entendu celui-ci est dans le cas d’une défaillance de tous les services AWS utilisés sur une région, et dans le cadre du SLA de chacun de ses services. Dans ce cas l’infrastructure ne peut prétendre à un SLA supérieur sans redondance supplémentaire. - RDS Multi-AZ MySQL : SLA de 99,95 % - EC2 : SLA de 99.95 % - CloudFront : SLA de 99.9 % - S3 : SLA de 99.9% - Route 53 : 100.0 % Le SLA de l’infrastructure brute sera de : ``` 99.95% x 99.95% x 99.9% x 99.9% x 100% = 99,70 % ``` Si l’on considère que l’indisponibilité S3 n’est pas critique pour la conservation de la disponibilité de l’infrastructure web (par exemple une API) et qu’on gère via Route 53 l’éventuel downtime de CloudFront en pointant vers le Load Balancer en secours, nous gagnerons 0,2% de SLA juste par modification et optimisation du Design de l’infrastructure : ``` 99.95% x 99.95% x 100% = 99,90 % ``` --- # AWS re:Invent 2018 Recap > 2018-12-07T11:00:00.000Z | https://sylvain.bruas.fr/blog/2018/12/reinvent-2018-recap Tags: Re:Invent, Serverless, VMC, AWS Summary: AWS re:Invent 2018 recap: the announcements that matter. Analysis of new services, standout features and innovations by our experts. ![Re:Invent2018](/static/2018/12/CXPReinvent1.webp) Plenty of AWS innovations were unveiled at re:Invent 2018! IoT, serverless, database, service monitoring, data analytics, blockchain, machine learning, storage… there was something for everyone! Machine learning was particularly in the spotlight this year — you can find [a recap by Julien Simon](https://julsimon.medium.com/aws-re-invent-machine-learning-recap-wednesday-9a2c07fc282e) (AWS AI and Machine Learning Evangelist) here. Rather than compiling an inventory of new services ([which AWS has already done very well](https://aws.amazon.com/fr/new/reinvent/)), we asked the team members who flew out to Las Vegas. What are the most interesting services and features announced? As an attendee, what were the highlights of this re:Invent? Any downsides? ## [Sylvain](https://www.linkedin.com/in/sylvainbruas/) For his second consecutive year attending re:Invent, Sylvain was particularly interested in serverless updates. 1. StepFunction – service orchestration is made easier with the integration of numerous services (Amazon Elastic Container Service (ECS), AWS Fargate, Amazon DynamoDB, Amazon Simple Notification Service (SNS), Amazon Simple Queue Service (SQS), AWS Batch, AWS Glue and SageMaker), facilitating workflow automation, security and monitoring. Learn more… 2. AWS Lambda with ALB – Application Load Balancers (ALB) can now be linked with Lambdas for HTTPS requests. A diagram for a better understanding [![Lambda with ALB](/static/2018/12/lambda_ALB.webp)](https://aws.amazon.com/fr/about-aws/whats-new/2018/11/alb-can-now-invoke-lambda-functions-to-serve-https-requests/?nc1=h_ls) Pros: ♥ Andy Jassy's Keynote ♥ Meeting the community ♥ Goodies and Swag ♥ Accessible certifications Cons: ⊗ A lot of information to absorb ⊗ Inconsistent session/workshop levels: it was hard to gauge the level and quality of the workshops and speakers. ⊗ Canadians got special swag that was unavailable to the French! ## [Mohammed](https://www.linkedin.com/in/maitelkamel/) A first-time re:Invent experience for Mohamed, who particularly appreciated the alternatives offered by AWS for networking and a new time series database. 1. Transit Gateway – a central connectivity hub between AWS Amazon Virtual Private Cloud (VPC) and on-premise infrastructure. Simple and straightforward — no more workarounds involving SSH jump hosts or port forwarding with NGINX. Learn more… 2. Timestream – a managed time series database, an alternative to DynamoDB (with a specific pattern) and other open-source solutions such as InfluxDB. [![Amazon Timestream](/static/2018/12/Timestream.webp)](https://aws.amazon.com/fr/timestream/?nc2=type_a) Pros: ♥ Atmosphere (DeepRacer races, numerous activities & games) ♥ Re:Play (Skrillex) ♥ Impressive logistics Cons: ⊗ An enormous amount of information to digest ⊗ Not enough level 400 sessions ⊗ Jet lag ## [Marouen](https://www.linkedin.com/in/rebaninja/) Updates bringing more flexibility to AWS service usage caught Marouen's attention. 1. DynamoDB On Demand – AWS's NoSQL database is now much more flexible: there is no longer a need to over-provision tables to handle activity spikes. Learn more… 2. Amazon FSx – no more need to mount an Amazon Elastic File System (EFS) on Linux and share it via SMB in order to use a managed and distributed file system on Windows   Pros: ♥ Chat talks allowing you to ask questions directly to AWS service Product Owners ♥ The Oracle jokes during the Keynotes ♥ Abundant food Cons: ⊗ Las Vegas (the noise, the casinos…) ## [Germain](https://www.linkedin.com/in/germain-chapart-a182133/) Germain appreciated AWS's commitment to improving hybrid cloud solutions. 1. Amazon Outpost – this service allows you to harmonize AWS services and features with those present on-premise and vice versa! Currently in preview — learn more and sign up… 2. VMware on AWS – VMware Cloud integration on AWS is strengthened with Outpost, as well as with the integration of the managed database service Amazon RDS into the VMware environment. Pros: ♥ Keynotes: unmissable but technically dense ♥ Increasingly welcoming to non-technical profiles ♥ 360° view of AWS and peripheral offerings, particularly crucial for medium-term market planning Cons: ⊗ Requires more preparation: earlier session targeting, arriving at the event sooner, etc. ## Still looking for more information? You can find the [recorded sessions and all videos](https://reinventvideos.com/?year=2018) from re:Invent 2018. The [slides](https://www.slideshare.net/AmazonWebServices/tag/awsreinvent2018/56) are also available. --- # Retour sur la Re:Invent 2018 > 2018-12-07T11:00:00.000Z | https://sylvain.bruas.fr/blog/2018/12/retour-sur-la-reinvent-2018 Tags: Re:Invent, Serverless, VMC, AWS Summary: Retour sur AWS re:Invent 2018 : les annonces qui comptent. Analyse des nouveaux services, fonctionnalités marquantes et innovations par nos experts. ![Re:Invent2018](/static/2018/12/CXPReinvent1.webp) Bien des nouveautés AWS ont été présentées à la Re:Invent de 2018 ! IoT, serverless, database, supervisions des services, analyse des données, blockchain, machine learning, stockage… il y en a eu pour tous les goûts ! Le machine learning a été particulièrement mis en avant cette année, vous pouvez retrouver ici [un recap par Julien Simon](https://julsimon.medium.com/aws-re-invent-machine-learning-recap-wednesday-9a2c07fc282e) (AI et Machine learning Evangeliste AWS). Au lieu d’effectuer un inventaire des nouveaux services ([qu’AWS a très bien fait de son côté](https://aws.amazon.com/fr/new/reinvent/)), nous avons interrogé les membres de l’équipe ayant décollés pour Las Vegas. Quels sont les services et fonctionnalités les plus intéressantes annoncées ? En tant que participant, quels sont les points forts de cette Re:Invent ? Des points négatifs ? ## [Sylvain](https://www.linkedin.com/in/sylvainbruas/) Pour sa deuxième année consécutive de participation au Re:Invent, Sylvain est très intéressé par les mises à jour concernant serverless. 1. StepFunction – l’orchestration des services est facilitée avec l’intégration de nombreux services (Amazon Elastic Container Service (ECS), AWS Fargate, Amazon DynamoDB, Amazon Simple Notification Service (SNS), Amazon Simple Queue Service (SQS), AWS Batch, AWS Glue et SageMageker) facilitant l’automatisation, la sécurité et la supervision des workflows. Pour en savoir plus… 2. AWS Lambda avec ALB – Application Load Balancers (ALB) peut maintenant être lié avec des Lambdas pour les requetes HTTPS. Un schéma pour mieux comprendre [![Lambda with ALB](/static/2018/12/lambda_ALB.webp)](https://aws.amazon.com/fr/about-aws/whats-new/2018/11/alb-can-now-invoke-lambda-functions-to-serve-https-requests/?nc1=h_ls) Les + : ♥ Keynote d’Andy Jassy ♥ Rencontres avec la communauté ♥ Goodies ou Swag ♥ Certifications accessibles Les - : ⊗ Beaucoup d’informations à absorber ⊗ Versatilité du niveau des sessions / workshops : il est difficile de cerner le niveau / qualité des ateliers et des intervenants. ⊗ Canadiens ont eu un swag spécial indisponible aux Français ! ## [Mohammed](https://www.linkedin.com/in/maitelkamel/) Première expérience de la Re:Invent pour Mohamed qui a particulièrement apprécié les alternatives proposés par AWS pour le réseaux et une nouvelle base de données time series. 1. Transit Gateway – un hub central de connexion entre les Amazon Virtual Private Cloud (VPC) d’AWS et une infrastructure on-premise. Simple et facile, fini les bricolages à base de rebond SSH ou de redirection de port avec NGINX. En savoir plus… 2. Timestream – une base de données managée time series, alternative à DynamoDB (avec un pattern spécifique) et à d’autres solutions Opensource tel qu’InfluxDB. [![Amazon Timestream](/static/2018/12/Timestream.webp)](https://aws.amazon.com/fr/timestream/?nc2=type_a) Les + : ♥ Ambiance (course de DeepRacer, nombreuses animations & jeux) ♥ Re:Play (Skrillex) ♥ Logistique impressionnante Les - : ⊗ Énormément d’informations à digérer ⊗ Pas assez de sessions niveau 400 ⊗ Le jet-lag ## [Marouen](https://www.linkedin.com/in/rebaninja/) Les mises à jour apportant de la flexibilité à l’usage des services AWS ont été retenu par Marouen. 1. DynamoDB On demand – la base de données NoSQL de AWS est maintenant bien plus flexible : il n’est plus nécessaire de surdimensionner les tables afin de pouvoir absorber les pics d’activités. En savoir plus… 2. Amazon FSx – plus besoin de devoir monter un Amazon Elastic File System (EFS) sur Linux et de le partager en SMB afin de pouvoir exploiter un file system managé et distribué sous Windows   Les + : ♥ Les chat talk permettant de poser des questions aux Product Owners des services AWS ♥ Les jokes sur Oracle lors des Keynotes ♥ La nourriture à profusion Les - : ⊗ Las Vegas (le bruit, les casinos…) ## [Germain](https://www.linkedin.com/in/germain-chapart-a182133/) Germain a apprécié la volonté d’AWS d’améliorer les solutions cloud hybrides. 1. Amazon Outpost – ce service permet d’harmoniser les services et fonctionnalités d’AWS avec ceux présents on-premise et vice-versa ! Actuellement en preview, pour en savoir plus et s’inscrire… 2. VMware on AWS – l’intégration de VMware Cloud sur AWS est renforcé avec Outpost mais aussi avec l’intégration du service de base de données managées Amazon RDS dans l’environnement VMware. Les + : ♥ Keynotes : immanquable mais dense techniquement ♥ De plus en plus de place aux profils non techniques ♥ Vu 360° des offres AWS et périphériques, particulièrement crucial pour se projeter à moyen-terme sur le marché Les - : ⊗ Nécessite plus de préparation : un ciblage plus en amont des sessions, une arrivée à l’event plus tôt, etc. ## Encore à l’affût d’informations ? Vous pouvez retrouver les sessions [enregistrées et toutes les vidéos tournées](https://reinventvideos.com/?year=2018) durant le Re:Invent 2018. Les [slides](https://www.slideshare.net/AmazonWebServices/tag/awsreinvent2018/56) sont disponibles également. --- # Audit : cas pratique > 2018-06-20T11:00:00.000Z | https://sylvain.bruas.fr/blog/2018/06/audit-cas-pratique Tags: Audit, Securite, Gouvernance, AWS Summary: Guide pratique d'audit de sécurité et d'architecture AWS. Méthodologie complète, outils d'évaluation, points de contrôle essentiels et bonnes pratiques. ![Audit : cas pratique](/static/2018/06/rouage-audit-400.webp) ## Introduction Nous allons voir dans cet article comment se déroule un audit de sécurité et d'architecture sur AWS. Nous allons nous baser sur un cas pratique, une entreprise qui a migré sur AWS il y a quelques années, et qui souhaite faire un audit de son infrastructure pour s'assurer que tout est bien configuré, et que les bonnes pratiques sont respectées. ## Préparation Avant de commencer l'audit, il est important de bien préparer le terrain. Il faut définir le périmètre de l'audit, les objectifs, et les moyens à mettre en œuvre. ### Périmètre Le périmètre de l'audit est défini par les services AWS utilisés par l'entreprise. Dans notre cas, l'entreprise utilise les services suivants : - Amazon Elastic Compute Cloud (EC2) - Amazon Relational Database Service (RDS) - Amazon Simple Storage Service (S3) - Amazon CloudFront - Amazon Route 53 - AWS Identity and Access Management (IAM) - Amazon CloudWatch - AWS CloudTrail - AWS Config ### Objectifs Les objectifs de l'audit sont les suivants : - Vérifier que les bonnes pratiques de sécurité sont respectées - Vérifier que l'architecture est bien conçue - Vérifier que les coûts sont optimisés - Vérifier que les performances sont optimales - Vérifier que la disponibilité est assurée ### Moyens Pour réaliser cet audit, nous allons utiliser les outils suivants : - AWS Trusted Advisor - AWS Config - AWS CloudTrail - AWS CloudWatch - AWS Cost Explorer - AWS Security Hub ## Réalisation de l'audit ![Audit informatique](/static/2018/06/computer-audit.webp) Audit informatique ### Sécurité La première étape de l'audit consiste à vérifier que les bonnes pratiques de sécurité sont respectées. Pour cela, nous allons utiliser AWS Trusted Advisor et AWS Security Hub. #### AWS Trusted Advisor AWS Trusted Advisor est un service qui permet de vérifier que les bonnes pratiques sont respectées. Il propose des recommandations dans les domaines suivants : - Optimisation des coûts - Performance - Sécurité - Tolérance aux pannes - Limites de service Dans notre cas, nous allons nous concentrer sur les recommandations de sécurité. Voici les points que nous allons vérifier : - Les groupes de sécurité sont-ils bien configurés ? - Les ACL réseau sont-elles bien configurées ? - Les clés d'accès sont-elles bien gérées ? - Les utilisateurs IAM sont-ils bien configurés ? - Les buckets S3 sont-ils bien configurés ? - Les certificats SSL sont-ils bien gérés ? #### AWS Security Hub AWS Security Hub est un service qui permet de centraliser les alertes de sécurité et de vérifier que les bonnes pratiques sont respectées. Il propose des recommandations basées sur les standards suivants : - CIS AWS Foundations Benchmark - AWS Foundational Security Best Practices - PCI DSS Dans notre cas, nous allons nous concentrer sur les recommandations du CIS AWS Foundations Benchmark. Voici les points que nous allons vérifier : - Les utilisateurs IAM sont-ils bien configurés ? - Les politiques de mot de passe sont-elles bien configurées ? - Les clés d'accès sont-elles bien gérées ? - Les journaux d'audit sont-ils bien configurés ? - Les alertes de sécurité sont-elles bien configurées ? ### Architecture La deuxième étape de l'audit consiste à vérifier que l'architecture est bien conçue. Pour cela, nous allons utiliser AWS Config et AWS Well-Architected Tool. #### AWS Config AWS Config est un service qui permet de vérifier que les ressources AWS sont bien configurées. Il propose des règles prédéfinies et permet de créer des règles personnalisées. Dans notre cas, nous allons utiliser les règles prédéfinies suivantes : - Les instances EC2 sont-elles bien configurées ? - Les bases de données RDS sont-elles bien configurées ? - Les buckets S3 sont-ils bien configurés ? - Les groupes de sécurité sont-ils bien configurés ? - Les ACL réseau sont-elles bien configurées ? #### AWS Well-Architected Tool AWS Well-Architected Tool est un service qui permet de vérifier que l'architecture est bien conçue. Il propose des recommandations basées sur les piliers suivants : - Excellence opérationnelle - Sécurité - Fiabilité - Efficacité des performances - Optimisation des coûts Dans notre cas, nous allons nous concentrer sur les recommandations de sécurité et de fiabilité. Voici les points que nous allons vérifier : - Les instances EC2 sont-elles bien configurées ? - Les bases de données RDS sont-elles bien configurées ? - Les buckets S3 sont-ils bien configurés ? - Les groupes de sécurité sont-ils bien configurés ? - Les ACL réseau sont-elles bien configurées ? - Les sauvegardes sont-elles bien configurées ? - La haute disponibilité est-elle bien configurée ? ### Coûts La troisième étape de l'audit consiste à vérifier que les coûts sont optimisés. Pour cela, nous allons utiliser AWS Cost Explorer et AWS Trusted Advisor. #### AWS Cost Explorer AWS Cost Explorer est un service qui permet de visualiser et d'analyser les coûts AWS. Il propose des graphiques et des rapports qui permettent de comprendre les coûts et de les optimiser. Dans notre cas, nous allons utiliser les rapports suivants : - Coûts par service - Coûts par région - Coûts par tag - Coûts par instance EC2 - Coûts par base de données RDS - Coûts par bucket S3 #### AWS Trusted Advisor AWS Trusted Advisor propose également des recommandations pour optimiser les coûts. Voici les points que nous allons vérifier : - Les instances EC2 sont-elles bien dimensionnées ? - Les volumes Amazon Elastic Block Store (EBS) sont-ils bien dimensionnés ? - Les instances RDS sont-elles bien dimensionnées ? - Les instances réservées sont-elles bien utilisées ? - Les instances spot sont-elles bien utilisées ? - Les ressources inutilisées sont-elles bien supprimées ? ### Performance La quatrième étape de l'audit consiste à vérifier que les performances sont optimales. Pour cela, nous allons utiliser AWS CloudWatch et AWS Trusted Advisor. #### AWS CloudWatch AWS CloudWatch est un service qui permet de surveiller les ressources AWS. Il propose des métriques et des alarmes qui permettent de comprendre les performances et de les optimiser. Dans notre cas, nous allons utiliser les métriques suivantes : - Utilisation CPU des instances EC2 - Utilisation mémoire des instances EC2 - Utilisation disque des instances EC2 - Utilisation réseau des instances EC2 - Utilisation CPU des instances RDS - Utilisation mémoire des instances RDS - Utilisation disque des instances RDS - Utilisation réseau des instances RDS - Latence des requêtes S3 - Latence des requêtes CloudFront #### AWS Trusted Advisor AWS Trusted Advisor propose également des recommandations pour optimiser les performances. Voici les points que nous allons vérifier : - Les instances EC2 sont-elles bien dimensionnées ? - Les volumes EBS sont-ils bien dimensionnés ? - Les instances RDS sont-elles bien dimensionnées ? - Les buckets S3 sont-ils bien configurés ? - Les distributions CloudFront sont-elles bien configurées ? ### Disponibilité La cinquième étape de l'audit consiste à vérifier que la disponibilité est assurée. Pour cela, nous allons utiliser AWS CloudWatch et AWS Trusted Advisor. #### AWS CloudWatch AWS CloudWatch permet également de surveiller la disponibilité des ressources AWS. Il propose des métriques et des alarmes qui permettent de comprendre la disponibilité et de l'optimiser. Dans notre cas, nous allons utiliser les métriques suivantes : - Disponibilité des instances EC2 - Disponibilité des instances RDS - Disponibilité des buckets S3 - Disponibilité des distributions CloudFront - Disponibilité des zones hébergées Route53 #### AWS Trusted Advisor AWS Trusted Advisor propose également des recommandations pour optimiser la disponibilité. Voici les points que nous allons vérifier : - Les instances EC2 sont-elles réparties sur plusieurs zones de disponibilité ? - Les instances RDS sont-elles réparties sur plusieurs zones de disponibilité ? - Les buckets S3 sont-ils répliqués ? - Les distributions CloudFront sont-elles bien configurées ? - Les zones hébergées Route53 sont-elles bien configurées ? ## Conclusion ![Audit cloud](/static/2018/06/Cloud-Audit-v1.webp) Audit cloud L'audit de sécurité et d'architecture sur AWS est une étape importante pour s'assurer que tout est bien configuré, et que les bonnes pratiques sont respectées. Il permet de détecter les problèmes de sécurité, d'architecture, de coûts, de performances et de disponibilité. Dans notre cas, nous avons utilisé les outils suivants : - AWS Trusted Advisor - AWS Config - AWS CloudTrail - AWS CloudWatch - AWS Cost Explorer - AWS Security Hub - AWS Well-Architected Tool Ces outils nous ont permis de vérifier que les bonnes pratiques sont respectées, et de détecter les problèmes à corriger. La prochaine étape consiste à corriger les problèmes détectés, et à mettre en place un processus d'amélioration continue pour s'assurer que les bonnes pratiques sont toujours respectées. --- # AWS Audit: A Practical Guide > 2018-06-20T11:00:00.000Z | https://sylvain.bruas.fr/blog/2018/06/aws-audit-practical-guide Tags: Audit, Security, Governance, AWS Summary: A practical guide to AWS security and architecture auditing. Complete methodology, assessment tools, essential checkpoints and best practices. ![Audit: Practical Guide](/static/2018/06/rouage-audit-400.webp) ## Introduction In this article, we will look at how a security and architecture audit on AWS is conducted. We will base this on a practical case: a company that migrated to AWS a few years ago and wants to audit its infrastructure to ensure everything is properly configured and that best practices are followed. ## Preparation Before starting the audit, it is important to prepare the groundwork. You need to define the audit scope, objectives, and the means to be deployed. ### Scope The audit scope is defined by the AWS services used by the company. In our case, the company uses the following services: - Amazon Elastic Compute Cloud (EC2) - Amazon Relational Database Service (RDS) - Amazon Simple Storage Service (S3) - Amazon CloudFront - Amazon Route 53 - AWS Identity and Access Management (IAM) - Amazon CloudWatch - AWS CloudTrail - AWS Config ### Objectives The audit objectives are as follows: - Verify that security best practices are followed - Verify that the architecture is well designed - Verify that costs are optimized - Verify that performance is optimal - Verify that availability is ensured ### Tools To carry out this audit, we will use the following tools: - AWS Trusted Advisor - AWS Config - AWS CloudTrail - AWS CloudWatch - AWS Cost Explorer - AWS Security Hub ## Conducting the Audit ![IT Audit](/static/2018/06/computer-audit.webp) IT Audit ### Security The first step of the audit is to verify that security best practices are followed. For this, we will use AWS Trusted Advisor and AWS Security Hub. #### AWS Trusted Advisor AWS Trusted Advisor is a service that checks whether best practices are being followed. It provides recommendations in the following areas: - Cost optimization - Performance - Security - Fault tolerance - Service limits In our case, we will focus on security recommendations. Here are the points we will check: - Are security groups properly configured? - Are network ACLs properly configured? - Are access keys properly managed? - Are IAM users properly configured? - Are S3 buckets properly configured? - Are SSL certificates properly managed? #### AWS Security Hub AWS Security Hub is a service that centralizes security alerts and verifies that best practices are followed. It provides recommendations based on the following standards: - CIS AWS Foundations Benchmark - AWS Foundational Security Best Practices - PCI DSS In our case, we will focus on CIS AWS Foundations Benchmark recommendations. Here are the points we will check: - Are IAM users properly configured? - Are password policies properly configured? - Are access keys properly managed? - Are audit logs properly configured? - Are security alerts properly configured? ### Architecture The second step of the audit is to verify that the architecture is well designed. For this, we will use AWS Config and AWS Well-Architected Tool. #### AWS Config AWS Config is a service that verifies whether AWS resources are properly configured. It offers predefined rules and allows creating custom rules. In our case, we will use the following predefined rules: - Are EC2 instances properly configured? - Are RDS databases properly configured? - Are S3 buckets properly configured? - Are security groups properly configured? - Are network ACLs properly configured? #### AWS Well-Architected Tool AWS Well-Architected Tool is a service that verifies whether the architecture is well designed. It provides recommendations based on the following pillars: - Operational Excellence - Security - Reliability - Performance Efficiency - Cost Optimization In our case, we will focus on security and reliability recommendations. Here are the points we will check: - Are EC2 instances properly configured? - Are RDS databases properly configured? - Are S3 buckets properly configured? - Are security groups properly configured? - Are network ACLs properly configured? - Are backups properly configured? - Is high availability properly configured? ### Costs The third step of the audit is to verify that costs are optimized. For this, we will use AWS Cost Explorer and AWS Trusted Advisor. #### AWS Cost Explorer AWS Cost Explorer is a service that allows you to visualize and analyze AWS costs. It provides charts and reports that help understand costs and optimize them. In our case, we will use the following reports: - Costs by service - Costs by region - Costs by tag - Costs by EC2 instance - Costs by RDS database - Costs by S3 bucket #### AWS Trusted Advisor AWS Trusted Advisor also provides recommendations for cost optimization. Here are the points we will check: - Are EC2 instances properly sized? - Are Amazon Elastic Block Store (EBS) volumes properly sized? - Are RDS instances properly sized? - Are Reserved Instances being used effectively? - Are Spot Instances being used effectively? - Are unused resources being removed? ### Performance The fourth step of the audit is to verify that performance is optimal. For this, we will use AWS CloudWatch and AWS Trusted Advisor. #### AWS CloudWatch AWS CloudWatch is a service that monitors AWS resources. It provides metrics and alarms that help understand performance and optimize it. In our case, we will use the following metrics: - EC2 instance CPU utilization - EC2 instance memory utilization - EC2 instance disk utilization - EC2 instance network utilization - RDS instance CPU utilization - RDS instance memory utilization - RDS instance disk utilization - RDS instance network utilization - S3 request latency - CloudFront request latency #### AWS Trusted Advisor AWS Trusted Advisor also provides recommendations for performance optimization. Here are the points we will check: - Are EC2 instances properly sized? - Are EBS volumes properly sized? - Are RDS instances properly sized? - Are S3 buckets properly configured? - Are CloudFront distributions properly configured? ### Availability The fifth step of the audit is to verify that availability is ensured. For this, we will use AWS CloudWatch and AWS Trusted Advisor. #### AWS CloudWatch AWS CloudWatch also monitors the availability of AWS resources. It provides metrics and alarms that help understand availability and optimize it. In our case, we will use the following metrics: - EC2 instance availability - RDS instance availability - S3 bucket availability - CloudFront distribution availability - Route 53 hosted zone availability #### AWS Trusted Advisor AWS Trusted Advisor also provides recommendations for availability optimization. Here are the points we will check: - Are EC2 instances distributed across multiple Availability Zones? - Are RDS instances distributed across multiple Availability Zones? - Are S3 buckets replicated? - Are CloudFront distributions properly configured? - Are Route 53 hosted zones properly configured? ## Conclusion ![Cloud Audit](/static/2018/06/Cloud-Audit-v1.webp) Cloud Audit A security and architecture audit on AWS is an important step to ensure everything is properly configured and that best practices are followed. It helps detect security, architecture, cost, performance, and availability issues. In our case, we used the following tools: - AWS Trusted Advisor - AWS Config - AWS CloudTrail - AWS CloudWatch - AWS Cost Explorer - AWS Security Hub - AWS Well-Architected Tool These tools allowed us to verify that best practices are followed and to detect issues that need to be fixed. The next step is to fix the detected issues and implement a continuous improvement process to ensure that best practices are always followed. --- # Bien débuter avec Amazon EC2 Container Service (101) – Cluster & task > 2018-01-17T11:00:00.000Z | https://sylvain.bruas.fr/blog/2018/01/bien-debuter-avec-amazon-ec2-container-service-101-cluster-task Tags: ECS, ECR, Docker, AWS Summary: Nous continuons dans la série “Bien débuter avec Amazon EC2 Container Service” en se concentrant sur les tasks et les clusters qui vont les héberger. ![Amazon Elastic Container Service (ECS) Cluster](/static/2018/01/aws-docker.webp) ## 1 – Qu’est ce qu’un Cluster Un cluster ECS est un regroupement d’instances Amazon Elastic Compute Cloud (EC2) qui vont héberger vos containers. ![Exemple d'un cluster ECS](/static/2018/01/ALB-container.webp) Exemple d’un cluster ECS Un cluster peut contenir une ou plusieurs instances, de différents types et taille. Dans notre exemple, nous utiliserons une t2.micro. ## 2 – Création d’un cluster ECS Nous allons nous connecter à la [console web AWS](https://console.aws.amazon.com/ecs/home) aws pour ecs. Nous allons cliquer sur “Cluster” dans le menu de gauche. Dans l’écran suivant (liste des clusters), nous allons cliquer sur “Create Cluster” pour créer notre premier cluster. Dans l’écran de création de cluster nous avons un formulaire très complet avec de nombreuses options. Nous allons utiliser les champs suivants : - Cluster Name : helloworldCluster - Provisioning Model : On-Demand Instance - EC2 instance type : t2.micro - VPC : choisir la VPC (Amazon Virtual Private Cloud) où vous désirez créer vos instances - Security group : Choisir/Créer un security group qui ouvre le port 80 - Cliquez sur le bouton bleu “Create” pour créer le cluster. Il devrait maintenant apparaître dans la liste des clusters ![ECS Cluster](/static/2018/01/ECS-cluster.webp) ECS Cluster ## 3 – Task Definition ou comment définir le lancement des containers Une task definition est une liste des paramètres qui vont permettre le lancement de nos containers. Pour la créer, nous allons cliquer sur “Task definitions” dans le menu de gauche, puis sur le bouton bleu “Create new Task Definition”. Cette première task definition va nous permettre de lancer un container, qui aura son port HTTP (80) lié au port 8080 sur l’instance hôte. Pour notre exemple nous allons remplir les champs suivants : - Task Definition Name : Helloworld-1 - Container Definitions : cliquez sur “add container” - Container name : Helloworld - Image : 123456789012.dkr.ecr.eu-west-1.amazonaws.com/helloworld:latest - Memory Limits (MB) : 128 - Port mappings : - Host : 8080 - Container : 80 - protocol : tcp - Cliquez sur le bouton “Add” Vous pouvez ensuite cliquer sur le bouton bleu “Create” ![ECS Task definition](/static/2018/01/ECS-taskdef.webp) ECS Task definition De nombreuses autres options sont disponibles dans le Container Definitions, pour permettre une définition fine des besoins des containers (Mapping de volumes, lien entre containers …) ## 4 – Exécution d’une task Maintenant que nous avons créé notre Cluster de machine hôte et que nous avons décrit la manière de lancer le container, nous pouvons enfin l’exécuter. Pour cela, nous allons cliquer sur le menu “Cluster” puis choisir dans la liste notre cluster helloworldCluster. Nous arrivons donc ici : ![ECS Cluster Hello world](/static/2018/01/ECS-cluster-hello.webp) ECS Cluster Hello world Cliquez sur l’onglet “Task” puis sur le bouton bleu “Run new Task” Dans l’écran suivant nous allons choisir tous les éléments que nous avons créé précédemment ![ECS run task](/static/2018/01/ECS-task-run.webp) ECS run task La task est créée et est prête à recevoir des messages. ## 5 – Connexion au container Il ne reste plus qu’à valider que le container répond bien à nos requêtes HTTP. Nous allons nous connecter directement à l’instance hôte sur le port 8080. Pour trouver son IP, il suffit de cliquer sur le nom de la task (dans notre cas 67f6a5b4-4…) pour afficher les détails. Dans la partie container il faut cliquer sur le triangle à côté du nom du container (helloworld) pour afficher les détails, l’IP sera dans la section “Network Bindings” ![ECS host IP](/static/2018/01/ECS-IP.webp) ECS host IP Vous pouvez ensuite aller dans votre navigateur préféré, et entrez l’url du container pour afficher la page ![ECS task result](/static/2018/01/ECS-End.webp) ECS task result Félicitations, vous avez fait fonctionner votre premier container sur Amazon EC2 Container Service. Dans le prochain article nous verrons comment aller plus loin en créant un service se basant sur l’image de container existante. Ainsi plusieurs containers seront lancés et pourront répondre à vos requêtes --- # Getting Started with Amazon ECS (101) – Cluster & Task > 2018-01-17T11:00:00.000Z | https://sylvain.bruas.fr/blog/2018/01/getting-started-with-amazon-ec2-container-service-101-cluster-task Tags: ECS, ECR, Docker, AWS Summary: We continue the 'Getting Started with Amazon EC2 Container Service' series by focusing on tasks and the clusters that host them. ![Amazon Elastic Container Service (ECS) Cluster](/static/2018/01/aws-docker.webp) ## 1 – What is a Cluster An ECS cluster is a grouping of Amazon Elastic Compute Cloud (EC2) instances that will host your containers. ![Example of an ECS cluster](/static/2018/01/ALB-container.webp) Example of an ECS cluster A cluster can contain one or more instances of different types and sizes. In our example, we will use a t2.micro. ## 2 – Creating an ECS Cluster Let's connect to the [AWS web console](https://console.aws.amazon.com/ecs/home) for ECS. Click on "Cluster" in the left menu. On the next screen (cluster list), click "Create Cluster" to create our first cluster. On the cluster creation screen, we have a comprehensive form with many options. We will use the following fields: - Cluster Name: helloworldCluster - Provisioning Model: On-Demand Instance - EC2 instance type: t2.micro - VPC: choose the VPC (Amazon Virtual Private Cloud) where you want to create your instances - Security group: Choose/Create a security group that opens port 80 - Click the blue "Create" button to create the cluster. It should now appear in the cluster list. ![ECS Cluster](/static/2018/01/ECS-cluster.webp) ECS Cluster ## 3 – Task Definition: How to Define Container Launches A task definition is a list of parameters that will allow the launch of our containers. To create one, click on "Task definitions" in the left menu, then on the blue "Create new Task Definition" button. This first task definition will allow us to launch a container with its HTTP port (80) mapped to port 8080 on the host instance. For our example, we will fill in the following fields: - Task Definition Name: Helloworld-1 - Container Definitions: click "add container" - Container name: Helloworld - Image: 123456789012.dkr.ecr.eu-west-1.amazonaws.com/helloworld:latest - Memory Limits (MB): 128 - Port mappings: - Host: 8080 - Container: 80 - protocol: tcp - Click the "Add" button You can then click the blue "Create" button. ![ECS Task definition](/static/2018/01/ECS-taskdef.webp) ECS Task definition Many other options are available in Container Definitions, allowing fine-grained definition of container requirements (volume mapping, container linking, etc.). ## 4 – Running a Task Now that we have created our host machine Cluster and described how to launch the container, we can finally run it. To do this, click on the "Cluster" menu then choose our helloworldCluster from the list. We arrive here: ![ECS Cluster Hello world](/static/2018/01/ECS-cluster-hello.webp) ECS Cluster Hello world Click on the "Task" tab then on the blue "Run new Task" button. On the next screen, we will choose all the elements we created previously. ![ECS run task](/static/2018/01/ECS-task-run.webp) ECS run task The task is created and ready to receive messages. ## 5 – Connecting to the Container All that remains is to validate that the container responds to our HTTP requests. We will connect directly to the host instance on port 8080. To find its IP, simply click on the task name (in our case 67f6a5b4-4…) to display the details. In the container section, click the triangle next to the container name (helloworld) to display the details. The IP will be in the "Network Bindings" section. ![ECS host IP](/static/2018/01/ECS-IP.webp) ECS host IP You can then open your favorite browser and enter the container URL to display the page. ![ECS task result](/static/2018/01/ECS-End.webp) ECS task result Congratulations, you have run your first container on Amazon EC2 Container Service. In the next article, we will go further by creating a service based on the existing container image. Multiple containers will be launched and able to respond to your requests. --- # Bien débuter avec Amazon EC2 Container Service (101) – ECR > 2017-08-30T11:00:00.000Z | https://sylvain.bruas.fr/blog/2017/08/bien-debuter-avec-amazon-ec2-container-service-101-ecr Tags: ECR, ECS, Docker, AWS Summary: Dans ces articles nous allons vous expliquer comment débuter avec succès sur le service managé Amazon EC2 Container Service. Focus sur ECR ![ECR](/static/2017/08/aws-docker.webp)   Docker est une technologie qui fait grand bruit depuis plusieurs années maintenant dans le domaine de l’IT. ![docker-vs-aws](/static/2017/08/docker-vs-aws.webp)   Tous les grands cloud publics (Amazon Web Service, Google Cloud, Microsoft Azure) proposent une solution plus ou moins intégrée pour la gestion des containers. Dans ces articles nous allons vous expliquer comment débuter avec succès sur le service managé [Amazon EC2 Container Service](https://aws.amazon.com/ecs/). Cette série d’articles suppose que vous avez créé un Amazon Virtual Private Cloud (VPC) où seront créé les instances hôtes pour les containers docker, que la [CLI AWS](https://aws.amazon.com/cli/) est installée sur votre poste et nous utiliserons une image “Hello-world” ([dockercloud/hello-world](https://hub.docker.com/r/dockercloud/hello-world/)) disponible sur le docker hub. ## 1 - Création du dépôt Docker Privé (ECR) Pour être déployé, une image de container doit être mis à disposition dans un dépôt docker. Plusieurs solutions sont disponibles, Amazon Web services (AWS) nous propose un dépôt privé managé (ECR) à un tarif intéressant ([0,1$/Go/mois](https://aws.amazon.com/fr/ecr/pricing/#Informations_de_tarification) au 01/08/2017). Pour déployer notre image sur ECR ( [Amazon EC2 Container Registry](https://aws.amazon.com/ecr/) ) nous allons tout d’abord récupérer cette image sur le docker hub. ```sh docker pull dockercloud/hello-world ```   Maintenant que nous avons notre image, nous allons la déposer sur ECR. Nous allons nous connecter à la [console web aws](https://console.aws.amazon.com/ecs/home) pour ecs. ### 1.1a – Si vous n’avez pas encore utilisé le service Vous allez tomber sur la page “get Started”, il vous suffira alors de cliquer sur le bouton bleu “getStarted” au milieu de la page. Sur l’écran suivant (Getting Started with Amazon EC2 Container Service), décocher la case pour ne pas déployer la demo Amazon Elastic Container Service (ECS) (sample) ![Getting Started with ECS](/static/2017/08/getstarted.webp) ### 1.1b – Si vous avez déjà utilisé ECS Il suffit de cliquer sur _[Repositories](https://console.aws.amazon.com/ecs/home#/repositories)_ puis sur “Create Repository” ### 1.2 – Sur la page suivante vous allez pouvoir donner un nom à votre dépôt, helloworld dans notre cas. Puis l’on passe à l’étape suivante (Next step) ![ecr-name](/static/2017/08/ECR-name.webp) ### 1.3 – La dernière page elle nous donne toutes les indications pour utiliser le dépôt qui vient d’être créé. ## 2 – Ajout d’une image sur ECR Nous allons déposer notre image HelloWorld sur le dépôt. Pour cela nous allons nous connecter sur ECR à partir de notre machine (notre dépôt est en ireland) ```sh aws ecr get-login --no-include-email --region eu-west-1 docker login -u AWS -p eyJwRXl…...iMSIsZnR5cGUKOiJEQWRBX0tFWSJ8 https://123456789012.dkr.ecr.eu-west-1.amazonaws.com ``` Nous obtenons une ligne de commande qui va nous permettre de nous connecter à ECR ```sh docker login -u AWS -p eyJwRXl…...iMSIsZnR5cGUKOiJEQWRBX0tFWSJ8 https://123456789012.dkr.ecr.eu-west-1.amazonaws.com Login Succeeded ``` Nous sommes maintenant connectés, nous pouvons pousser l’image locale ```sh docker tag dockercloud/hello-world:latest 123456789012.dkr.ecr.eu-west-1.amazonaws.com/helloworld:latest docker push 123456789012.dkr.ecr.eu-west-1.amazonaws.com/helloworld:latest ``` Si vous vous connectez sur la console web AWS, vous pourrez voir votre image dans le dépôt ![Docker Image in ECR repository](/static/2017/08/ECR-push.webp) Dans le prochain article nous allons utiliser cette image pour lancer un container docker sur ECS. --- # Getting Started with Amazon EC2 Container Service (101) – ECR > 2017-08-30T11:00:00.000Z | https://sylvain.bruas.fr/blog/2017/08/getting-started-with-amazon-ec2-container-service-101-ecr Tags: ECR, ECS, Docker, AWS Summary: In this series of articles, we explain how to successfully get started with the managed Amazon EC2 Container Service. Focus on ECR. ![ECR](/static/2017/08/aws-docker.webp)   Docker is a technology that has been making waves in the IT world for several years now. ![docker-vs-aws](/static/2017/08/docker-vs-aws.webp)   All major public clouds (Amazon Web Services, Google Cloud, Microsoft Azure) offer a more or less integrated solution for container management. In this series of articles, we explain how to successfully get started with the managed [Amazon EC2 Container Service](https://aws.amazon.com/ecs/). This series assumes that you have created an Amazon Virtual Private Cloud (VPC) where the host instances for Docker containers will be created, that the [AWS CLI](https://aws.amazon.com/cli/) is installed on your machine, and we will use a "Hello-world" image ([dockercloud/hello-world](https://hub.docker.com/r/dockercloud/hello-world/)) available on Docker Hub. ## 1 - Creating a Private Docker Repository (ECR) To be deployed, a container image must be made available in a Docker repository. Several solutions are available. Amazon Web Services (AWS) offers a managed private repository (ECR) at an attractive price ([US$0.1/GB/month](https://aws.amazon.com/fr/ecr/pricing/#Informations_de_tarification) as of 01/08/2017). To deploy our image on ECR ([Amazon EC2 Container Registry](https://aws.amazon.com/ecr/)), we will first pull this image from Docker Hub. ```sh docker pull dockercloud/hello-world ```   Now that we have our image, we will push it to ECR. Let's connect to the [AWS web console](https://console.aws.amazon.com/ecs/home) for ECS. ### 1.1a – If you haven't used the service yet You will land on the "Get Started" page. Simply click the blue "Get Started" button in the middle of the page. On the next screen (Getting Started with Amazon EC2 Container Service), uncheck the box to skip deploying the Amazon Elastic Container Service (ECS) demo (sample). ![Getting Started with ECS](/static/2017/08/getstarted.webp) ### 1.1b – If you have already used ECS Simply click on _[Repositories](https://console.aws.amazon.com/ecs/home#/repositories)_ then on "Create Repository". ### 1.2 – On the next page You can name your repository — helloworld in our case. Then proceed to the next step (Next step). ![ecr-name](/static/2017/08/ECR-name.webp) ### 1.3 – The last page It provides all the instructions for using the newly created repository. ## 2 – Pushing an Image to ECR We will push our HelloWorld image to the repository. To do this, we will log in to ECR from our machine (our repository is in Ireland). ```sh aws ecr get-login --no-include-email --region eu-west-1 docker login -u AWS -p eyJwRXl…...iMSIsZnR5cGUKOiJEQWRBX0tFWSJ8 https://123456789012.dkr.ecr.eu-west-1.amazonaws.com ``` We get a command line that will allow us to connect to ECR. ```sh docker login -u AWS -p eyJwRXl…...iMSIsZnR5cGUKOiJEQWRBX0tFWSJ8 https://123456789012.dkr.ecr.eu-west-1.amazonaws.com Login Succeeded ``` We are now connected and can push the local image. ```sh docker tag dockercloud/hello-world:latest 123456789012.dkr.ecr.eu-west-1.amazonaws.com/helloworld:latest docker push 123456789012.dkr.ecr.eu-west-1.amazonaws.com/helloworld:latest ``` If you connect to the AWS web console, you will be able to see your image in the repository. ![Docker Image in ECR repository](/static/2017/08/ECR-push.webp) In the next article, we will use this image to launch a Docker container on ECS. --- # Amazon S3 – A Detailed Overview of AWS's Data Storage Service > 2016-09-09T11:00:00.000Z | https://sylvain.bruas.fr/blog/2016/09/amazon-s3-detailed-overview-of-aws-storage-service Tags: S3, AWS Summary: A comprehensive guide to Amazon S3: storage classes, lifecycle policies, versioning, encryption, event notifications, and cost optimization. ![Amazon Simple Storage Service (S3)](/static/2016/09/s3.webp)   Released in 2006 in the United States (2007 in Europe), two years after the very first Amazon service, Amazon Simple Queue Service (SQS), S3 has become one of the most advanced and widely used services on AWS. ## Core Features Amazon S3 lets you store data in the cloud in a simple and secure way. S3 is organized into compartments called "buckets" containing objects, equivalent to files and folders on a traditional storage system. S3 comes with all the benefits of the cloud and AWS expertise, with a focus on: - **Durability**: data is stored redundantly across multiple data centers and disks, ensuring durability ranging from 99.99% to 99.999999999% ("eleven nines") over a one-year period. - **Availability**: the infrastructure behind the service ensures data availability ranging from 99.9% to 99.99% (excluding Glacier) over a one-year period. - **Security**: the service provides flexible security mechanisms by default to protect your data according to your needs. - **Latency**: in addition to high availability, the service provides access to data with the lowest and most consistent latency possible. To read from or write to S3, a set of commands is available for performing operations on objects. The most common ones include: - GET, for retrieval - PUT, for creation and modification - DELETE, for deletion For new object creation operations, the service guarantees read-after-write consistency. However, for modification and deletion operations, data consistency is eventual (a few seconds), a constraint due to data redundancy. Interactions with S3 are done through the web interface (AWS main site), the CLI (command-line interface), and the SDK (integrated into a program). ## Advanced Features ### Storage Classes S3 offers several storage types (called "classes") based on data size and usage patterns that can drastically optimize your costs. - The "**Standard**" class is assigned by default when creating an object. It meets the 99.999999999% durability and 99.99% availability requirements and is suitable for frequently accessed data stored on S3. - The "**Standard – Infrequent Access**" class is designed for storing "cold" data, meaning less frequently accessed data. Storage costs are reduced, but access costs are higher. Data availability is 99.9% for this class. - The "**Reduced Redundancy**" class is optimal for non-critical and/or reproducible data. The service reduces data redundancy for lower costs. Durability is therefore reduced to 99.99%. - The "**Glacier**" class is perfect for data archiving. Storage cost is very low at the expense of data availability. You will need to wait several hours before accessing the data. ![S3 Storage Classes](/static/2016/09/s3_storage_classes.webp) ### Security S3 provides numerous tools to ensure data security at all times: - Communication with S3 uses the secure **HTTPS** protocol. - Data access is restricted by default. There are several ways to manage access: - **AWS Identity and Access Management (IAM)**: the AWS service for managing users and roles assignable to resources (Amazon Elastic Compute Cloud (EC2) instances, AWS Lambda functions, etc.). - **ACL** (Access Control List): access rules for S3 buckets and objects in XML format. - Query strings ("**tokens**"): temporary access rights to an S3 bucket or object in the form of a token that must be added to the request. - **Bucket policies**: rules defined at the bucket level to easily share bucket contents. - Data encryption can be done in several ways: - During upload or on objects already stored on S3, you can specify a "managed" encryption option where AWS encrypts your data before storing it in their data centers and decrypts it on the fly when accessing the data. Additionally, AWS handles key generation and storage for you. - You can also specify the encryption option and provide your own encryption keys. You can specify keys you generated yourself, and it becomes your responsibility to store the keys securely. Alternatively, you can obtain keys through the AWS KMS (Key Management Service), which lets you manage your keys in the cloud and use them with other AWS services. - Of course, you can always encrypt your data before uploading it to S3 using keys you generated or keys from KMS. - MFA (Multi-Factor Authentication) delete protection is a practical and effective tool to prevent data loss due to accidental manipulation or insufficiently restrictive access rights. - Versioning adds an extra layer of security. Once enabled, this option keeps all versions of an object, protecting your data against accidental deletion. File access returns the latest version of the object, and storage costs apply to all stored versions. ### S3 Object Lifecycle Policies Imagine you have a video-sharing website among friends and it takes off. You would store all these videos on S3, and thanks to its highly scalable nature, you won't encounter storage limit issues. All videos would be stored in the Standard storage class, meeting the application's needs. Your storage costs would therefore scale linearly with the number of uploaded videos. Wouldn't there be a way to optimize these costs automatically? S3 allows you to automatically migrate objects to other storage classes based on data age. You'll notice that users of your video-sharing application frequently add new content, and generally only the latest shared videos are watched by your friends or go "viral." With just a few clicks, you can apply lifecycle rules to your S3 bucket to: - Migrate objects to a less expensive storage class for aging data (a few months). - Migrate objects to long-term archival for old data (several years or considered deleted). - Schedule automatic deletion for the very long term. - Manage version archiving (if enabled) of your objects to reduce their cost. Here is an example of enabling lifecycle rules on a bucket through the AWS web interface: ![S3 lifecycle](/static/2016/09/s3_life_cycle_policies.webp) ### Event Notifications S3 offers a very interesting feature for developers: event notifications. When an operation is performed on an object (upload, deletion, etc.), S3 can notify other AWS services: - [Amazon SNS](https://aws.amazon.com/sns/) (Simple Notification Service): the service for sending "push" notifications quickly and at scale. By integrating with S3 deletion notifications, you can, for example, receive an email detailing important deleted files. - [Amazon SQS](https://aws.amazon.com/sqs/) (Simple Queue Service): the message queue service for centrally storing messages and reading them from other applications. You could imagine an image conversion application that, when new images are uploaded to S3, inserts the S3 object names into the queue. The queue is then consumed by machines responsible for image conversion. - [AWS Lambda](https://aws.amazon.com/lambda/): the service for running code "serverless" — the underlying infrastructure is managed by AWS. Very practical for prototypes or microservices. ![S3 events](/static/2016/09/s3_event_notifications.webp) ### And More In addition to the features mentioned above, S3 offers other capabilities addressing more specific needs, including: - Static website hosting - Amazon Virtual Private Cloud (VPC) endpoint - Audit logs - Cross-region replication - Cost monitoring and control - Large-scale data transfer - Multipart upload to S3 - Transfer acceleration ## Pricing As with most AWS services, Amazon S3 pricing is based on the size of stored data, the number of operations, and the size of data in transit. Pricing details are available on the [AWS website](https://aws.amazon.com/s3/pricing/). Here is a brief exploration of rates for reference. Taking the Oregon region as an example, storage costs depend on the classes used (first 1 TB/month): - Standard: $0.03 per GB - Standard – Infrequent Access: $0.0125 per GB - Glacier: $0.007 per GB Costs for operations on S3 objects also depend on the object class: - Standard - Creates, modifications: $0.005 per 1,000 operations - Retrievals: $0.004 per 10,000 operations - Standard – IA - Creates, modifications: $0.01 per 1,000 operations - Retrievals: $0.01 per 10,000 operations - Glacier - Archives, restores: $0.05 per 1,000 requests - Note on restores: 5% of total Glacier storage free per month, and $0.01 per GB beyond that - Data transfers are also part of S3 costs. For example, transfers from S3 to the Internet cost $0.09 per GB (first 10 TB/month). ## Limits Amazon S3 has certain limits imposed by the managed infrastructure behind it: - Each account is limited to 100 buckets. This limit can be increased (only since August 2015) by contacting AWS support. - A bucket name is globally unique. It may be wise to prefix certain bucket names to prevent errors during automatic bucket creation via an application. - The maximum size for a single upload to S3 is 5 GB. - The maximum size of an object is 5 TB. You will need to use the multipart upload feature to reach the maximum object size. - There is no limit on the maximum number of objects a bucket can contain. ## Tips and Tricks Amazon S3 is part of the AWS Free Tier, offering each new account for one year (per month): - 5 GB of storage - 20,000 GET operations - 2,000 PUT operations - 15 GB of inbound data transfer - 15 GB of outbound data transfer Regarding uploading objects to S3, it is recommended to use multipart upload for files exceeding 100 MB. This method has several advantages: - Upload parallelization, for maximum utilization of your Internet connection bandwidth. - Upload pause capability, by uploading only the missing parts. One last tip if you have many retrieval operations on S3. The service stores objects in a "key/value" format and distributes all objects across multiple disks and machines. To optimize object distribution and therefore server load distribution when traffic is heavy (beyond 100 requests per second), it is recommended to add a random prefix to the object key. This random part can be a "hash" (a few randomly generated characters) or, for keys containing a time value, a reversal of that time value (seconds then minutes then hours, etc.). ## Use Cases To wrap up this article, let's look at some use cases based on the power of Amazon S3. ### Low-Cost Archiving Today, businesses produce large amounts of data, and it is essential to store it with the best durability at the lowest possible cost. S3 allows you, through object lifecycle management, to easily archive unused data that must not be deleted. As a reminder, the Glacier storage class offers storage at $0.007 per GB for maximum cost reduction. Keep in mind that retrieving data from Glacier can be costly if a large portion of data is retrieved quickly. ### Showcase Website S3 offers the ability to host your static website with all the benefits of the service: - Data durability - Heavy traffic handling - Sudden traffic spike management To improve site performance in terms of latency, you can even use the [Amazon CloudFront](https://aws.amazon.com/cloudfront/) service to distribute site content across multiple countries (called a CDN, Content Delivery Network), as close to users as possible. ### Cloud File Storage Similar to Google Drive or Dropbox, you could create a consumer application for file storage. This application would consist of the following elements: An interface that allows users to log in and manage their files: this interface can be a static site hosted on S3 that can handle a large number of users and sudden traffic spikes. A fleet of servers to handle application logic: AWS offers several services for running this logic (EC2, Lambda/Amazon API Gateway, Amazon Elastic Container Service (ECS), etc.). A storage space for storing encrypted data: S3 is perfect for this — storage is unlimited, and data encryption is available based on your needs. ### Disaster Recovery When your website is live and receiving consistent traffic, it is important to implement mechanisms to approach 100% availability (or "zero downtime"). These mechanisms must include disaster management to provide the best possible service to your users in case of a more or less widespread outage, while considering costs. One strategy is to duplicate the entire infrastructure that powers the website (servers, databases, static data, etc.) in another data center on the other side of the world (another AWS region). When a widespread outage occurs in one data center, you can redirect all traffic to the other. This strategy (also called "multi-region") ensures the best availability but is very expensive (multiplied infrastructure costs, database synchronization, S3 data replication to another region, etc.). A simpler, low-cost alternative is to create a static version of the website and place it on S3 in one (or more) other AWS regions. During a widespread outage, you can redirect your users to this simplified version of the website. While this mechanism doesn't maintain all website features, the site remains accessible, and users won't panic compared to seeing a blank page. ### Application Log Management Many AWS services allow you to redirect their output or results to S3. This principle is commonly used for application logs that, every 20 minutes for example, are sent to S3 for analysis or backup in case of server failure. You can use event notifications to process your logs and identify and understand the various issues your application might have. By defining an AWS Lambda function on S3 write notifications, you can set up the following process: - Log written to S3 - Notification triggered - Lambda function called - S3 file read - Log lines inserted into a database - Data exploited by the developer by aggregating log lines ### Resource-Intensive Processing Another use of event notifications is processing large files, videos, or images that require running background tasks for conversion, analysis, etc. When these files are uploaded to S3, you can register these notifications in an SQS queue and process them afterward. For image analysis or data aggregation operations, you can create a fleet of servers capable of consuming this queue, performing the necessary processing, and scaling the fleet size based on the queue size (always with the goal of optimizing costs based on needs). Hopefully this article has inspired you to build your next application with Amazon S3 and other AWS services. --- # Amazon S3 – Vue détaillée du service de stockage de données d’AWS > 2016-09-09T11:00:00.000Z | https://sylvain.bruas.fr/blog/2016/09/amazon-s3-vue-detaillee-du-service-de-stockage-de-donnees-aws Tags: S3, AWS Summary: Je vous propose d’analyser en détails l’ensemble des fonctionnalités du service Amazon S3 ou Simple Storage Service. ![Amazon Simple Storage Service (S3)](/static/2016/09/s3.webp)   Sorti en 2006 aux États-Unis (2007 en Europe), deux ans après le tout premier service [Amazon Simple Queue Service (SQS)](https://docs.aws.amazon.com/sqs/), S3 est maintenant un des services les plus avancés et utilisés sur AWS. ## Fonctionnalités de base Amazon S3 va vous permettre de stocker des données sur le Cloud de manière simple et sécurisée. S3 est organisé en compartiments appelés « buckets » contenant des objets, équivalents aux fichiers et dossiers sur un système de stockage classique. S3 vient avec tous les avantages du Cloud et de l’expertise AWS en mettant l’accent sur : - **La durabilité** : les données sont stockées de manière redondante dans plusieurs data centers et sur plusieurs disques afin d’assurer une durabilité allant de 99,99% à 99,999999999% (« eleven nines ») sur une période d’un an. - **La disponibilité** : l’infrastructure mise en place derrière le service permet d’assurer une disponibilité des données allant de 99,9% à 99,99% (hors Glacier) sur une période d’un an. - **La sécurité** : le service offre par défaut des mécanismes de sécurité flexibles permettant de protéger vos données en fonction de vos besoins. - **La latence** : en plus de sa haute disponibilité, le service permet d’accéder aux données avec la latence le plus faible et stable possible. Afin de lire ou écrire sur S3, un panel de commandes est mis à disposition pour réaliser des opérations sur les objets. On peut notamment citer les plus connues : - GET, pour la récupération - PUT, pour la création et la modification - DELETE, pour la suppression Pour les opérations de création de nouveaux objets, le service assure la lecture de la donnée après son écriture. Par contre pour les opérations de modification et suppression, la cohérence des données est assurée à terme (quelques secondes), contrainte dû à la redondance des données. Les interactions avec S3 se font à partir de l’interface Web (site principal d’AWS), le CLI (interface de commandes) et le SDK (intégré dans un programme). ## Fonctionnalités avancées ### Classes de stockage S3 offre plusieurs types de stockage (appelés « classes ») en fonction de la taille et de l’utilisation des données qui vont permettre d’optimiser vos coûts drastiquement. - La classe « **Standard** » est attribuée par défaut lors de la création d’un objet. Elle répond aux 99,999999999% de durabilité et 99,99% de disponibilité sur les données et est adéquat pour une utilisation fréquente des données stockées sur S3. - La classe « **Standard – Infrequent Access** » est destinée au stockage des données dites « froides » c’est-à-dire moins utilisées. Les coûts de stockage seront réduis par contre les coûts d’accès se verront augmentés. La disponibilité des données est 99,9% pour cette classe. - La classe « **Reduced Redundancy** » est optimale pour des données non cruciales et/ou reproductibles. Le service réduit la redondance des données pour des coûts plus bas les utilisateurs. La durabilité se voit donc réduite à 99,99%. - La classe « **Glacier** » est parfaite pour l’archivage des données. Le coût de stockage est très faible au dépend de la disponibilité des données. Il faudra attendre plusieurs heures avant de pouvoir accéder aux données. ![S3 Storage Classes](/static/2016/09/s3_storage_classes.webp) ### Sécurité S3 fournit de nombreux outils afin d’assurer la sécurité des données à tout moment : - La communication avec S3 utilise le protocole sécurisé **HTTPS**. - L’accès aux données est restreint par défaut. Il existe plusieurs moyens de gérer ces accès : - **[AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/iam/)** : le service AWS qui permet de gérer des utilisateurs et rôles attribuables à des ressources (machine [Amazon Elastic Compute Cloud (EC2)](https://docs.aws.amazon.com/ec2/), fonction [AWS Lambda](https://docs.aws.amazon.com/lambda/), etc). - **ACL** (Access Control List) : des règles d’accès aux buckets et objets S3 au format XML. - Chaînes de requête (« **token** ») : droits d’accès temporaires à un bucket ou objet S3 sous la forme d’un token qu’il faudra ajouter à la requête. - **Politiques de buckets** : règles définis au niveau du bucket permettant de partager simplement le contenu du bucket. - Le chiffrement des données peut se faire de différentes manières : - Au moment du chargement ou sur les objets stockés sur S3, il est possible de spécifier une option de chiffrage « managé » où AWS va chiffrer vos données avant de les stocker dans leur data centers et les déchiffrer à la volée lors de l’accès à la donnée. De plus, AWS s’occupe de la génération et du stockage des clés de chiffrage pour vous. - Il est aussi possible de spécifier l’option de chiffrage et de fournir ses propres clés de chiffrage. Vous pouvez spécifier des clés que vous avez générées vous-même et il est désormais de votre responsabilité de stocker les clés de manière sécurisée. Ou alors vous pouvez obtenir des clés via le service AWS KMS (Key Management Service) qui vous offre la possibilité de gérer vos clés sur le Cloud et de les utiliser avec d’autres services AWS. - Bien évidemment, vous pouvez toujours chiffrer vos données avant de les charger sur S3 en utilisant des clés que vous avez générées ou des clés provenant de KMS. - La protection de la suppression par MFA (Multi-Factor Authentication) est un outil pratique et efficace pour éviter la perte de données due à une fausse manipulation ou à des droits d’accès pas assez restrictifs. - Le contrôle de version permet d’ajouter un niveau supplémentaire de sécurité. En effet cette option, une fois activée, va permettre de garder toutes les versions d’un objet et donc de protéger vos données contre la suppression involontaire. Les accès aux fichiers répondront avec la dernière version de l’objet et le coût de stockage s’appliquera à toutes les versions stockées. ### Les cycles de vie des objets S3 Imaginez que vous avez un site Web de partage de vidéos entre amis et que ce dernier fait un carton. Vous allez donc stocker toutes ces vidéos sur S3 et grâce à son caractère hautement évolutif, vous ne rencontrerai pas de problèmes en terme de limite de stockage. Toutes les vidéos seront stockées dans la classe de stockage Standard répondant aux besoins de l’application. Vos coûts de stockage seront donc linéaires au nombre de vidéos chargées. Est-ce qu’il n’y aurait pas la possibilité d’optimiser ces coûts de manière automatisée ? S3 permet de migrer automatiquement les objets dans d’autres classes de stockage en fonction de l’ancienneté des données. Vous remarquerez que les utilisateurs de votre application de partage de vidéos en ajoutent fréquemment et en général uniquement les dernières vidéos partagées sont visionnées par vos amis ou font le « buzz ». En quelques clics vous pouvez appliquer à votre bucket S3 des règles de cycles de vie de vos objets afin de : - Migrer les objets vers une classe moins onéreuse en stockage pour les données vieillissantes (quelques mois). - Migrer les objets vers un archivage long terme pour les données anciennes (plusieurs années ou considérées comme supprimées). - Prévoir une suppression automatique pour le très long terme. - Gérer l’archivage des versions (si activée) de vos objets pour réduire leur coût. Voici un exemple d’activation de règles de cycle de vie sur un bucket à travers l’interface Web d’AWS : ![S3 lifecycle](/static/2016/09/s3_life_cycle_policies.webp) ### Les notifications d’événements S3 propose une fonctionnalité très intéressante pour les développeurs : les notifications d’événements. Lorsqu’une opération est réalisée sur un objet (chargement, suppression, etc) S3 est capable de notifier cette opération vers d’autres services AWS : - [Amazon SNS](https://aws.amazon.com/fr/sns/) (Simple Notification Service) : le service permettant d’envoyer des notifications « push » rapidement et de manière évolutive. En intégrant avec les notifications de suppression de S3, on peut par exemple recevoir par email un détail des fichiers importants supprimés. - [Amazon SQS](https://aws.amazon.com/fr/sqs/) (Simple Queue Service) : le service de file d’attente permettant de stocker des messages de manière centralisée et de les lire par d’autres applications. On peut imaginer une application de conversion d’images, qui, au chargement de nouvelles images dans S3, insère le nom des objets S3 dans la file d’attente. Cette dernière est ensuite consommée par des machines responsables de la conversion des images. - [AWS Lambda](https://aws.amazon.com/fr/lambda/) : le service permettant d’exécuter du code « sans serveur », l’infrastructure derrière est gérée par AWS. Très pratique pour des prototypes ou des micro services. ![S3 events](/static/2016/09/s3_event_notifications.webp) ### Et plus encore En plus des fonctionnalités citées précédemment, S3 offre d’autres possibilités répondant à des problématiques plus précises, on peut notamment citer : - Hébergement de sites Web statiques - Point de terminaison Amazon Virtual Private Cloud (VPC) - Journaux d’audit - Réplication entre régions - Surveillance et contrôle des coûts - Transfert de grandes quantités de données - Chargement sur S3 en plusieurs parties - Accélération du transfert des données ## Tarification Comme pour la majorité des services proposés par AWS, la tarification d’Amazon S3 est basée sur la taille des données stockées, le nombre d’opérations et la taille des données en transit. Le détail des tarifs est disponible sur le [site d’AWS](https://aws.amazon.com/fr/s3/pricing/). Nous vous proposons une petite exploration des tarifs à titre indicatif. Prenons pour exemple la région Oregon, les coûts du stockage dépendra des classes utilisées (premier 1 To/mois) : - Standard : $0.03 par Go - Standard – Infrequent Access : $0.0125 par Go - Glacier : $0.007 par Go Les coûts pour les opérations sur les objets S3 dépendent aussi de la classe des objets : - Standard - Créations, modifications : $0.005 par tranche de 1 000 opérations - Récupérations : $0.004 par tranche de 10 000 opérations - Standard – IA - Créations, modifications : $0.01 par tranche de 1 000 opérations - Récupérations : $0.01 par tranche de 10 000 opérations - Glacier - Archivages, restaurations : $0.05 par tranche de 1 000 demandes - Attention aux restaurations : 5% du stockage Glacier total gratuit par mois et $0.01 par Go au delà - Les transferts de données font aussi partie des coûts S3. Par exemple les transferts de S3 vers Internet vous couteront $0.09 par Go (premiers 10 To/mois). ## Limites Le service Amazon S3 comprend certaines limites imposées par l’infrastructure managée derrière : - Chaque compte est limité à 100 buckets. Il est possible d’augmenter cette limite, uniquement depuis Août 2015, en contactant le support AWS. - Le nom d’un bucket est unique pour tous. Il peut être judicieux de préfixer certains noms de bucket afin d’empêcher des erreurs lors de la création automatique de buckets via une application. - La taille maximale d’un chargement sur S3 est 5 Go. - La taille maximale d’un object est 5 To. Il faudra donc utiliser la fonctionnalité de chargement en plusieurs parties pour arriver à la taille maximale d’un objet. - Il n’y a pas de limite sur le nombre maximum d’objets que peut contenir un bucket. ## Quelques astuces Amazon S3 fait partie du niveau d’utilisation gratuit d’AWS (« Free Tier« ) en offrant à chaque nouveau compte pendant un an (par mois) : - 5 Go de stockage - 20 000 opérations GET - 2 000 opérations PUT - 15 Go transfert de données entrantes - 15 Go transfert de données sortantes Concernant le chargement des objets sur S3, il est recommandé d’utiliser le chargement en plusieurs parties pour les fichiers dépassant les 100 Mo. Cette méthode comprend plusieurs avantages : - La parallélisation du chargement, pour une exploitation maximale de la bande passante de votre connexion Internet. - La mise en pause du chargement, en chargeant uniquement les parties manquantes. Dernière astuce si vous avez de nombreuses opérations de récupération sur S3. Le service stocke les objets sous le format « clé/valeur » et répartit tous les objets sur plusieurs disques et machines. Pour optimiser la répartition des objets et donc la répartition de la charge serveur lorsque le trafic est important (au delà de 100 requêtes par seconde), il est conseillé d’ajouter une partie aléatoire au début de la clé de l’objet. Cette partie aléatoire peut être un « hash » (quelques caractères générés aléatoirement) ou, pour les clés contenant une valeur temporelle, une inversion de cette valeur temporelle (secondes puis minutes puis heures, etc). ## Cas d’utilisation Pour finir cet article, nous allons présenter quelques cas d’utilisation basés sur la puissance d’Amazon S3. ### Archivage à faible coût Aujourd’hui, les entreprises produisent beaucoup de données et il est nécessaire de pouvoir les stocker avec la meilleure durabilité et le coût le plus faible possible. S3 permet, via la gestion des cycles de vie des objets, d’archiver facilement les données non-utilisées mais qui ne doivent pas être supprimées. Pour rappel la classe de stockage Glacier propose un stockage à la hauteur de $0.007 par Go, pour une réduction des coûts maximale. À garder en tête que la récupération des données de Glacier peut être coûteuse si une grande partie des données est récupérée rapidement. ### Site vitrine S3 offre la possibilité d’héberger son site Web statique avec tous les avantages du service : - Durabilité des données - Gestion de trafic important - Gestion des hausses de trafic soudaines Pour améliorer les performances du site en terme de latence, il est même possible d’utiliser le service [Amazon CloudFront](https://aws.amazon.com/fr/cloudfront/) afin de distribuer le contenu du site dans plusieurs pays (appelé CDN, Content Delivery Network), au plus proche des utilisateurs. ### Stockage de fichiers sur le Cloud À la manière de Google Drive ou Dropbox, on pourrait créer une application grand public destinée au stockage de fichiers. Cette application serait composée des éléments suivants : Une interface qui permet aux utilisateurs de se connecter et de gérer leurs fichiers : cette interface peut être un site statique hébergé sur S3 qui pourra gérer un grand nombre d’utilisateurs et des hausses de trafic soudaines. Une flotte de serveurs pour gérer la logique applicative : AWS offre plusieurs services permettant d’exécuter cette logique (EC2, Lambda/Amazon API Gateway, Amazon Elastic Container Service (ECS), etc). Un espace de stockage pour stocker les données chiffrées : S3 est parfait pour cela, le stockage est illimité, le chiffrage des données est disponible en fonction des besoins. ### Reprise de sinistre Lorsque votre site Web est lancé et que vous avez du trafic constant, il est important de mettre en place des mécanismes pour se rapprocher du 100% de disponibilité (ou « zero downtime »). Ces mécanismes doivent comprendre une gestion des sinistres afin de pouvoir fournir le meilleur service possible à vos utilisateurs en cas de panne plus ou moins générale tout en prenant en compte les coûts. Une stratégie peut être de dupliquer toute l’infrastructure permettant le fonctionnement du site Web (serveurs, bases de données, données statiques, etc) dans un autre data center à l’autre bout du monde (une autre région AWS). Lorsqu’une panne générale intervient sur un data center, vous pouvez rediriger tout le trafic sur l’autre. Cette stratégie (aussi appelée « multi-régions ») assure la meilleure disponibilité mais est très onéreuse (coûts d’infrastructure multipliés, synchronisation des bases de données, réplication des données S3 dans une autre région, etc). Une autre solution plus simple, faiblement coûteuse consiste à créer une version statique du site Web, de le mettre sur S3 dans une (ou plusieurs) autre région AWS. Ainsi, lors d’une panne générale il sera possible de rediriger vos utilisateurs sur cette version simplifiée du site Web. Bien que ce mécanisme ne permet pas de maintenir toutes les fonctionnalités du site Web, celui-ci reste toujours accessible et les utilisateurs ne paniqueront pas comparé à l’affichage d’une page blanche. ### Gestion des logs applicatifs Beaucoup de services AWS permettent de rediriger leur sortie ou leurs résultats vers S3. Ce principe est notamment utilisé pour les logs applicatifs qui, toutes les 20 minutes par exemple, sont envoyés sur S3 dans le but d’y avoir accès pour analyse ou sauvegarde en cas de défaillance de serveurs. On va pouvoir utiliser les notifications d’événements pour réaliser notre exploitation des logs et ainsi identifier et comprendre les différents problèmes que notre application pourrait avoir. En définissant une fonction AWS Lambda sur les notifications d’écriture sur S3, il sera possible de mettre en place le processus suivant : - Écriture du log sur S3 - Déclenchement de la notification - Appel d’une fonction Lambda - Lecture du fichier S3 - Insertion des lignes de logs dans une base de données - Exploitation des données par le développeur en agrégeant les lignes de logs ### Traitements gourmands Une autre exploitation des notifications d’événements est le traitement de gros fichiers, de vidéos, d’images qui nécessite d’exécuter en arrière-plan des tâches de conversion, d’analyse, etc. Au chargement de ces fichiers sur S3, il est possible d’enregistrer ces notifications dans une file d’attente SQS et de les traiter ensuite. Sur des opérations d’analyse d’image ou d’agrégation de données, on va pouvoir créer une flotte de serveurs capable de consommer cette file d’attente, de réaliser les traitements nécessaires et de gérer la taille de la flotte en fonction de la taille de la file d’attente (toujours d’en l’optique d’optimiser les coûts en fonction des besoins). En espérant vous avoir donné envie de réaliser votre prochaine application avec Amazon S3 et d’autres services AWS.