Guide

Retour arrière automatisé pour un déploiement ECS Fargate défaillant sans script personnalisé.

→Activer le disjoncteur de déploiement ECS avec retour arrière sur le service ECS.

Pourquoi: Fonctionnalité native d'ECS qui effectue un retour arrière automatique si les nouvelles tâches ne parviennent pas à se stabiliser. Coût opérationnel minimal par rapport à l'interrogation CodeBuild personnalisée ou aux configurations CodeDeploy complexes.

Référence↗

Déployer vers une région primaire, valider avec des tests automatisés, puis déployer vers d'autres régions en parallèle.

→Utiliser un seul CodePipeline avec des étapes séquentielles : (1) Déployer la Région A, (2) une étape de test CodeBuild qui exécute la validation, (3) une étape de déploiement parallèle pour les Régions B et C.

Pourquoi: CodeBuild agit comme une porte programmatique automatisée. Un seul pipeline est plus simple que d'orchestrer plusieurs pipelines avec Step Functions.

Un script de validation de longue durée dans un hook de cycle de vie CodeDeploy provoque une réussite prématurée du déploiement.

→Augmenter la propriété `timeout` pour le script de hook de cycle de vie spécifique dans le fichier `AppSpec.yml`.

Pourquoi: Le timeout est configuré par hook dans le fichier AppSpec, et non au niveau du groupe de déploiement. Cela garantit que le script de validation dispose de suffisamment de temps pour se terminer.

Accélérer les builds d'images Docker lents de CodeBuild causés par le téléchargement répété des dépendances et des couches d'image à chaque exécution.

→Dans la configuration du projet CodeBuild, activer `LOCAL_DOCKER_LAYER_CACHE` et configurer un cache S3 pour les répertoires de dépendances (par exemple, `.m2`, `node_modules`).

Pourquoi: Traite directement les deux sources de lenteur. Le cache de couches Docker réutilise les couches d'image inchangées ; le cache S3 réutilise les dépendances d'application téléchargées.

Mettre en œuvre un déploiement canari pour une fonction Lambda avec un retour arrière automatisé et basé sur des métriques.

→Utiliser AWS SAM avec `DeploymentPreference` (par exemple, type `Canary10Percent5Minutes`). Ajouter une alarme CloudWatch sur la métrique `Errors` comme déclencheur de retour arrière.

Pourquoi: SAM s'intègre nativement à CodeDeploy pour Lambda, automatisant le déplacement du trafic d'alias, la surveillance et le retour arrière sans scripts personnalisés.

Référence↗

Configurer IAM pour un CodePipeline dans le Compte A afin de déployer des ressources dans le Compte B.

→Le rôle du pipeline (Compte A) assume un rôle d'action (Compte B). Le rôle d'action dans B fait confiance au rôle du pipeline et dispose des permissions de déploiement. Le compartiment d'artefacts S3 et la clé KMS dans A doivent avoir des politiques de ressources accordant l'accès au rôle d'action dans B.

Pourquoi: C'est le modèle d'accès inter-comptes standard et sécurisé : assomption de rôle pour les actions, politiques basées sur les ressources pour l'accès aux données.

Mettre en œuvre un workflow GitOps pour EKS où l'état du cluster est automatiquement et continuellement réconcilié avec un dépôt Git.

→Déployer un contrôleur GitOps (par exemple, Flux, ArgoCD) dans le cluster EKS. Le configurer pour surveiller le dépôt Git et appliquer/réconcilier les changements.

Pourquoi: C'est le modèle GitOps "pull-based" standard. Le contrôleur in-cluster gère la réconciliation continue et la détection de dérive, ce qui est le principe fondamental de GitOps.

Permettre à un projet CodeBuild dans un compte d'outillage central de déployer des manifestes Kubernetes vers des clusters EKS dans des comptes de charge de travail distincts.

→Dans chaque compte de charge de travail, créer un rôle IAM inter-comptes auquel le rôle CodeBuild fait confiance. Mapper ce nouveau rôle à un groupe RBAC Kubernetes dans le `aws-auth` ConfigMap du cluster EKS. Le script CodeBuild assume le rôle avant d'exécuter `kubectl`.

Pourquoi: C'est le modèle standard et sécurisé pour l'accès inter-comptes à EKS. Il suit le principe du moindre privilège en créant un rôle dédié et de confiance à cette fin.

Effectuer une migration de schéma complexe pour une base de données RDS PostgreSQL ou MySQL avec une interruption de service nulle ou quasi-nulle.

→Utiliser la fonctionnalité Déploiements Bleu/Vert d'Amazon RDS. Créer un environnement de staging (vert) synchronisé, y appliquer les modifications de schéma, puis effectuer un basculement pour le promouvoir en production.

Pourquoi: C'est le service géré spécialement conçu pour les mises à jour RDS sûres et sans interruption de service. Il gère le clonage, la synchronisation et un basculement rapide (< 1 min) avec des garde-fous intégrés.

Déployer une nouvelle version d'une application monopage (SPA) sur S3/CloudFront et s'assurer que les utilisateurs reçoivent la nouvelle version immédiatement avec des coûts d'invalidation de cache minimaux.

→Utiliser le hachage basé sur le contenu pour les noms de fichiers d'actifs (par exemple, `app.a1b2c3d4.js`). Après le déploiement des nouveaux actifs, invalider uniquement le fichier `index.html` dans la distribution CloudFront.

Pourquoi: Les noms de fichiers hachés sont uniques, de sorte que CloudFront les traite comme de nouveaux objets et les récupère de l'origine, en contournant le cache. Seul le fichier de point d'entrée unique (`index.html`) nécessite une invalidation, ce qui est significativement moins cher qu'une invalidation générique (`/*`).

Implémenter un pipeline CI/CD pour une application AWS CDK qui se met à jour automatiquement lorsque la définition du pipeline elle-même change.

→Utiliser le construct CDK Pipelines (`pipelines.CodePipeline`). Ce construct crée un pipeline qui inclut une étape `SelfMutate` par défaut.

Pourquoi: CDK Pipelines est un construct de haut niveau spécialement conçu pour ce modèle. L'étape `SelfMutate` garantit que le pipeline reflète toujours la dernière définition du code avant de déployer les modifications de l'application.

Déployer une nouvelle version d'application qui nécessite une modification de schéma de base de données rétrocompatible (par exemple, l'ajout de nouvelles colonnes) sans interruption de service.

→Implémenter un modèle d'expansion et de contraction (ou de changement parallèle). Premièrement, déployer les modifications de schéma de base de données additives et rétrocompatibles. Deuxièmement, déployer la nouvelle version de l'application qui utilise le nouveau schéma. Les anciennes et nouvelles versions de l'application peuvent coexister avec la base de données mise à jour.

Pourquoi: Ce modèle découple les déploiements de base de données et d'application, garantissant que l'état de la base de données est toujours compatible avec les anciennes et nouvelles versions de l'application, permettant ainsi des déploiements sans interruption de service.

Déployer progressivement une nouvelle fonctionnalité auprès de segments d'utilisateurs spécifiques et mesurer l'impact sur les métriques métier (par exemple, le taux de conversion) à l'aide de tests A/B.

→Utiliser Amazon CloudWatch Evidently. Créer une fonctionnalité avec plusieurs variations, un lancement pour contrôler le pourcentage de déploiement, et une expérience pour mesurer l'impact statistique sur des métriques définies.

Pourquoi: Evidently est un service spécialement conçu pour le feature flagging et l'expérimentation A/B, fournissant non seulement le mécanisme de déploiement mais aussi le moteur d'analyse statistique pour mesurer l'impact.

Appliquer des tags obligatoires sur toutes les instances EC2 au moment du lancement dans une AWS Organization.

→Utiliser une politique de contrôle de service (SCP) qui refuse `ec2:RunInstances` à moins que les clés de tag requises ne soient présentes dans la requête.

Pourquoi: Contrôle préventif qui empêche la création de ressources non conformes. S'applique à tous les comptes et ne peut être remplacé par des politiques IAM locales.

Référence↗

Gérer et faire pivoter les secrets (par exemple, les identifiants de base de données) utilisés par les applications dans plusieurs comptes sans interruption de service.

→Utiliser AWS Secrets Manager avec la rotation automatique activée. Accorder l'accès inter-comptes à l'aide de politiques basées sur les ressources pour le secret.

Pourquoi: Secrets Manager prend en charge les stratégies de rotation sans interruption de service (alternance des utilisateurs) et offre un partage sécurisé et natif entre comptes.

Déployer automatiquement des ressources de sécurité de base sur les nouveaux comptes créés via Control Tower Account Factory.

→Utiliser l'événement de cycle de vie Control Tower `CreateManagedAccount` via EventBridge pour déclencher une fonction Lambda qui déploie un CloudFormation StackSet. Alternativement, utiliser les personnalisations pour AWS Control Tower (CfCT).

Pourquoi: L'automatisation événementielle est le modèle standard et évolutif pour étendre les baselines de Control Tower sans intervention manuelle après la création du compte.

Activer l'accès SSM Session Manager aux instances EC2 dans un sous-réseau privé sans accès à Internet.

→Créer des points de terminaison d'interface VPC (alimentés par PrivateLink) pour les services `ssm`, `ssmmessages` et `ec2messages` dans le VPC.

Pourquoi: Les points de terminaison VPC permettent à l'agent SSM de communiquer avec le service entièrement au sein du réseau AWS, offrant le modèle d'accès le plus sécurisé sans nécessiter de NAT ou de passerelle Internet.

Centraliser les logs avec une rétention à long terme et les protéger de la suppression ou de la modification, même par les administrateurs.

→Stocker les logs dans un compartiment S3 avec S3 Object Lock en mode conformité. Activer la validation de l'intégrité des fichiers de log CloudTrail.

Pourquoi: Object Lock (mode conformité) offre une protection WORM que même le compte root ne peut pas contourner. La validation de l'intégrité des fichiers de log fournit une vérification cryptographique contre la falsification après livraison.

Offrir aux développeurs un moyen en libre-service de provisionner des modèles d'infrastructure pré-approuvés sans leur accorder toutes les permissions de services AWS.

→Utiliser AWS Service Catalog. Créer un portefeuille de produits approuvés (définis par des modèles CloudFormation). Utiliser des contraintes de lancement pour que Service Catalog provisionne les ressources à l'aide d'un rôle IAM privilégié géré par l'équipe de la plateforme.

Pourquoi: Service Catalog est le service AWS spécialement conçu pour créer des catalogues de services IT. Les contraintes de lancement sont la fonctionnalité de gouvernance clé, permettant aux développeurs de provisionner une infrastructure complexe sans avoir eux-mêmes les permissions sous-jacentes.

Fournir en toute sécurité des secrets uniques à différents microservices exécutés en tant que tâches ECS, en garantissant que chaque service ne peut accéder qu'à ses propres secrets.

→Créer des secrets AWS Secrets Manager distincts pour chaque service. Dans la définition de tâche ECS, référencer les ARN des secrets dans la propriété `secrets` de la définition du conteneur. Limiter la politique du rôle IAM d'exécution de tâche pour n'autoriser `secretsmanager:GetSecretValue` que sur l'ARN de secret spécifique de ce service.

Pourquoi: Cela applique le principe du moindre privilège à plusieurs niveaux : le secret lui-même, la politique IAM et la définition de tâche ECS. Les secrets sont injectés en toute sécurité lors de l'exécution.

Permettre à un workflow GitHub Actions d'accéder en toute sécurité à AWS sans stocker de identifiants de longue durée.

→Configurer un fournisseur d'identité IAM OIDC pour GitHub. Créer un rôle IAM avec une politique de confiance restreignant le principal fédéré à l'organisation, au dépôt et à la branche GitHub spécifiques. Utiliser l'action `aws-actions/configure-aws-credentials` avec OIDC pour assumer le rôle.

Pourquoi: La fédération OIDC est la méthode la plus sécurisée, fournissant des identifiants de courte durée limités à une exécution de workflow spécifique, éliminant le risque d'exposition des identifiants de longue durée.

Surveiller en continu toutes les politiques IAM au sein d'une AWS Organization pour identifier les ressources partagées avec des entités externes et être alerté à leur sujet.

→Activer IAM Access Analyzer au niveau de l'organisation, en définissant l'organisation comme zone de confiance. Utiliser EventBridge pour capturer les nouvelles découvertes et déclencher des notifications.

Pourquoi: IAM Access Analyzer est spécialement conçu pour utiliser le raisonnement automatisé afin de trouver les ressources partagées en externe. L'exécuter au niveau de l'organisation fournit une vue centralisée et continue sans script personnalisé.

Réduire le rayon d'impact des mises à jour CloudFormation ayant échoué dans une architecture de pile monolithique ou imbriquée.

→Décomposer l'architecture en piles indépendantes à l'aide de références croisées (CloudFormation Exports/Fn::ImportValue).

Pourquoi: Une défaillance dans une pile (par exemple, la base de données) ne déclenchera pas de retour arrière des autres piles mises à jour avec succès (par exemple, la mise en réseau), isolant ainsi les domaines de défaillance.

Gérer de manière centralisée le patching inter-comptes avec des calendriers différents pour les environnements de production et de non-production.

→Utiliser AWS Systems Manager Patch Manager avec des baselines de patch personnalisées, des fenêtres de maintenance distinctes pour chaque environnement, et Systems Manager Explorer pour un rapport de conformité centralisé.

Pourquoi: Supporte nativement toutes les exigences : définitions de patch personnalisées, planification flexible via des fenêtres de maintenance et visibilité inter-comptes via Explorer.

Prévisualiser les modifications d'infrastructure sur tous les comptes cibles avant d'exécuter une mise à jour CloudFormation StackSet.

→Créer et examiner un change set CloudFormation pour l'opération StackSet avant l'exécution.

Pourquoi: Les change sets sont le mécanisme natif de CloudFormation pour prévisualiser les modifications exactes des ressources (ajout, modification, suppression) qu'une mise à jour effectuera.

S'assurer que CloudFormation attend la fin réussie du script UserData d'une instance EC2 avant de poursuivre la création de la pile.

→Ajouter une `CreationPolicy` avec `ResourceSignal` à la ressource d'instance EC2. Appeler le script d'aide `cfn-signal` depuis UserData une fois la tâche terminée avec succès.

Pourquoi: C'est le mécanisme natif de CloudFormation pour la coordination avec les scripts de configuration sur une ressource. L'échec de la signalisation dans le délai imparti déclenche automatiquement un retour arrière de la pile.

Détecter quand des modifications manuelles, hors bande, entraînent une différence entre les ressources déployées et leur définition dans le modèle CloudFormation.

→Exécuter périodiquement la détection de dérive CloudFormation sur la pile. Pour une détection continue, utiliser la règle AWS Config `cloudformation-stack-drift-detection-check`.

Pourquoi: La détection de dérive est la fonctionnalité native pour comparer le modèle d'une pile avec l'état réel de ses ressources. L'utilisation de la règle Config automatise cette vérification.

Protéger les ressources avec état (par exemple, un compartiment S3 ou une base de données RDS) contre la suppression ou le remplacement accidentel via les opérations de pile CloudFormation.

→Sur la ressource, définir `DeletionPolicy: Retain` (ou `Snapshot` pour RDS). Sur la pile, activer `TerminationProtection`. Appliquer une `StackPolicy` qui refuse les actions `Update:Replace` et `Update:Delete` sur la ressource critique.

Pourquoi: Offre une défense en profondeur : la protection contre la terminaison empêche la suppression de la pile, la politique de suppression préserve la ressource si la pile est supprimée, et la politique de pile empêche les mises à jour destructrices.

Migrer un CloudFormation StackSet d'un modèle de rôle IAM complexe et auto-géré vers un modèle de permissions plus simple pour une AWS Organization.

→Mettre à jour le StackSet pour utiliser des permissions gérées par le service.

Pourquoi: Les permissions gérées par le service tirent parti de l'accès de confiance d'Organizations, éliminant le besoin de créer et de gérer des rôles IAM dans chaque compte cible. Cela permet également le déploiement automatique vers de nouveaux comptes ajoutés aux unités d'organisation ciblées.

Une ressource personnalisée CloudFormation doit gérer une tâche qui prend plus de temps que le délai d'attente de 15 minutes d'une fonction Lambda.

→Déclencher une machine d'état AWS Step Functions à partir de la fonction Lambda de la ressource personnalisée. La machine d'état gère la tâche de longue durée en utilisant des états d'attente ou le modèle Task Token et renvoie la réponse à l'URL S3 pré-signée de CloudFormation.

Pourquoi: Step Functions est conçu pour orchestrer des workflows de longue durée et multi-étapes, contournant efficacement la limitation de timeout de Lambda tout en maintenant l'intégration avec CloudFormation.

Appliquer de manière centralisée une politique (par exemple, tous les compartiments S3 doivent avoir le versionnement) sur l'ensemble d'une application AWS CDK, quelle que soit la façon dont les développeurs définissent leurs ressources.

→Créer un Aspect CDK qui implémente l'interface `IAspect`. L'Aspect visite tous les constructs de l'arbre de l'application, trouve tous les constructs de compartiment S3 et applique la configuration requise ou ajoute une erreur de validation si elle est manquante.

Pourquoi: Les Aspects sont le modèle officiel de CDK pour appliquer des préoccupations transversales et implémenter des validations de politique en tant que code de manière centralisée sans modifier les constructs individuels.

Empêcher les opérations automatisées, telles que le patching via les fenêtres de maintenance SSM, de s'exécuter pendant des périodes spécifiques et changeantes (par exemple, un black-out financier trimestriel).

→Utiliser SSM Change Calendar pour définir des événements marquant les périodes de black-out comme "fermées". Associer le Change Calendar à la fenêtre de maintenance.

Pourquoi: Change Calendar agit comme une porte pour les automatismes. Il bloque automatiquement l'exécution pendant les périodes "fermées" sans nécessiter de modifications manuelles du calendrier de la fenêtre de maintenance, ce qui le rend très efficace pour gérer les périodes de black-out dynamiques.

Gérer de manière centralisée l'installation et le versionnement d'un package logiciel personnalisé (par exemple, un agent de surveillance) sur une flotte d'instances EC2.

→Packager le logiciel à l'aide de SSM Distributor. Utiliser SSM State Manager pour créer une association qui applique le package Distributor à toutes les instances ciblées.

Pourquoi: Distributor gère le cycle de vie du package (y compris les versions). State Manager garantit que l'état désiré (par exemple, "la version 1.2 de l'agent est installée") est continuellement appliqué, corrigeant automatiquement la dérive et configurant les nouvelles instances.

Récupération après sinistre (RPO < 1 min et RTO < 5 min) pour une base de données Aurora et la couche applicative entre les régions.

→Utiliser une base de données globale Aurora pour la réplication de base de données en moins d'une seconde. Pour la couche applicative, utiliser une "veille chaude" avec un groupe Auto Scaling configuré à une capacité désirée de 0, à augmenter via l'automatisation en cas de basculement.

Pourquoi: Aurora Global Database offre un RPO inférieur à la seconde et un RTO inférieur à 1 minute. La couche applicative en veille chaude est rentable tout en respectant un RTO rapide.

Réduire le temps de mise à l'échelle d'un groupe Auto Scaling pour les instances ayant des temps de démarrage/initialisation longs.

→Créer une "AMI dorée" pré-configurée avec les dépendances installées. Configurer un warm pool sur le groupe Auto Scaling pour maintenir les instances pré-initialisées.

Pourquoi: Une AMI dorée minimise le temps de démarrage. Un warm pool minimise le temps de lancement (démarrage vs lancement). Ensemble, ils réduisent considérablement le temps nécessaire à une nouvelle instance pour être prête à servir du trafic.

Un service ECS augmente le nombre de ses tâches, mais ne peut pas placer de nouvelles tâches car le cluster EC2 sous-jacent est en manque de capacité.

→Activer l'Auto Scaling de cluster ECS en associant un fournisseur de capacité au groupe Auto Scaling EC2 et au cluster ECS.

Pourquoi: Les fournisseurs de capacité lient la mise à l'échelle du service ECS à la mise à l'échelle des instances EC2. Lorsque les tâches ne peuvent pas être placées en raison de ressources de cluster insuffisantes, le fournisseur de capacité met automatiquement à l'échelle le groupe ASG EC2.

Mettre à l'échelle dynamiquement une flotte d'instances de worker EC2 en fonction du nombre de messages dans une file d'attente SQS.

→Utiliser une politique Auto Scaling de suivi de cible basée sur la métrique personnalisée : `ApproximateNumberOfMessagesVisible` / `GroupInServiceInstances` (c'est-à-dire, backlog par instance).

Pourquoi: C'est le modèle recommandé pour la mise à l'échelle basée sur SQS. Il maintient juste assez de workers pour traiter le backlog dans un délai cible, s'adaptant efficacement à la profondeur de la file d'attente.

Créer des snapshots de volumes EBS cohérents avec l'application (pas seulement crash-consistent) pour les applications avec état.

→Utiliser AWS Backup avec un plan de sauvegarde. Dans le plan, utiliser Systems Manager Run Command pour exécuter des scripts de pré-snapshot afin de mettre l'application en veille (ou activer VSS pour Windows).

Pourquoi: AWS Backup orchestre l'ensemble du processus. La mise en veille de l'application (vidage des tampons d'E/S sur le disque) avant l'instantané garantit l'intégrité des données et un état d'application récupérable.

S'assurer que les événements critiques d'une règle EventBridge ne sont pas perdus lorsqu'un service cible (par exemple, Lambda) est temporairement indisponible ou limité.

→Sur la cible de la règle EventBridge, configurer une politique de réessai (par exemple, âge maximal de 24 heures) et une file d'attente de lettres mortes (DLQ) en utilisant une file d'attente SQS.

Pourquoi: La politique de réessai gère automatiquement les échecs transitoires. La DLQ agit comme un dernier filet de sécurité, capturant les événements qui épuisent tous les réessais afin qu'ils puissent être retraités ultérieurement, évitant ainsi la perte de données.

Déclencher des alertes en temps réel sur des motifs de logs spécifiques et inclure des informations contextuelles (par exemple, les lignes de log environnantes) dans la notification.

→Utiliser un filtre d'abonnement CloudWatch Logs pour diffuser les événements de log correspondants vers une fonction Lambda. La fonction Lambda formate et envoie une notification détaillée (par exemple, à SNS ou Chime).

Pourquoi: Les filtres d'abonnement fournissent un streaming d'événements en temps réel. Lambda permet une logique personnalisée pour extraire et formater le contexte, ce que les simples filtres métriques ne peuvent pas faire.

Identifier les goulots d'étranglement de latence dans une application distribuée basée sur des microservices.

→Activer le traçage AWS X-Ray sur les points d'entrée (par exemple, API Gateway, ALB) et le calcul (par exemple, Lambda, ECS). Utiliser le SDK X-Ray pour les appels en aval. Analyser la carte de service et les traces.

Pourquoi: X-Ray est le service AWS spécialement conçu pour le traçage distribué. La carte de service visualise la chaîne d'appels et met en évidence les services avec une latence élevée et des taux d'erreur.

Créer une seule alarme de haut niveau qui représente la santé combinée d'une application multi-niveaux pour réduire le bruit des alertes.

→Créer des alarmes CloudWatch individuelles pour chaque niveau (par exemple, taux d'erreurs 5xx de l'ALB, CPU de l'application, connexions RDS). Ensuite, les combiner à l'aide d'une alarme composite CloudWatch avec une logique OU.

Pourquoi: Les alarmes composites sont conçues pour réduire le bruit des alarmes en créant une seule alarme logique basée sur l'état de plusieurs alarmes sous-jacentes.

Analyser des pétaoctets de logs avec des requêtes SQL complexes (y compris des jointures) et les conserver pendant des années de manière rentable.

→Diffuser les logs vers Amazon S3 via Kinesis Data Firehose. Cataloguer les données avec AWS Glue. Interroger avec Amazon Athena. Utiliser les politiques de cycle de vie S3 pour transférer les données vers Glacier/Deep Archive pour une rétention à long terme.

Pourquoi: C'est l'architecture de data lake serverless standard. Athena offre de puissantes capacités SQL sur les données S3, et S3/Glacier offre le stockage à long terme le plus rentable.

Surveiller une métrique avec des motifs cycliques prévisibles (par exemple, pics quotidiens/hebdomadaires) et ne déclencher une alarme que sur des déviations réelles du motif.

→Configurer la détection d'anomalies CloudWatch sur la métrique. Créer une alarme qui se déclenche lorsque la valeur de la métrique sort de la plage attendue du modèle.

Pourquoi: La détection d'anomalies utilise l'apprentissage automatique pour apprendre les motifs normaux de la métrique, créant une bande de seuil dynamique qui s'adapte aux cycles. Cela réduit les faux positifs dus aux pics prévisibles et améliore le rapport signal/bruit.

Obtenir une visibilité complète sur les métriques de CPU, mémoire, disque et réseau au niveau du conteneur pour les charges de travail sur EKS ou ECS sans installer et gérer des outils tiers.

→Activer Amazon CloudWatch Container Insights pour le cluster EKS/ECS.

Pourquoi: Container Insights est un service entièrement géré qui collecte, agrège et visualise automatiquement des métriques de performance détaillées pour les charges de travail conteneurisées, offrant une visibilité approfondie avec un surcoût opérationnel minimal.

Surveiller la disponibilité et les performances d'une application exposée à Internet du point de vue des utilisateurs finaux, en identifiant les problèmes de réseau au niveau des FAI et géographiques.

→Activer Amazon CloudWatch Internet Monitor pour l'application.

Pourquoi: Internet Monitor utilise les données du réseau mondial AWS pour fournir une visibilité sur les conditions Internet qui affectent vos utilisateurs finaux, aidant à diagnostiquer les problèmes en dehors de votre environnement AWS.

Mesurer l'expérience utilisateur réelle d'une application web en collectant les temps de chargement des pages, les erreurs JavaScript et d'autres métriques de performance côté client.

→Intégrer le snippet JavaScript CloudWatch RUM (Real User Monitoring) dans l'application web.

Pourquoi: RUM est un service géré qui collecte les données de performance et d'erreur côté client directement depuis les navigateurs des utilisateurs, offrant une véritable visibilité sur l'expérience utilisateur réelle sans tests synthétiques.

Émettre des métriques d'application personnalisées à partir d'une fonction AWS Lambda avec une haute résolution et des dimensions, sans ajouter la latence et le coût des appels directs à l'API CloudWatch.

→Utiliser le format de métrique intégré CloudWatch (EMF) en écrivant du JSON spécialement structuré en sortie standard. Une bibliothèque cliente peut simplifier cela.

Pourquoi: CloudWatch Logs extrait automatiquement et de manière asynchrone les métriques des entrées de log EMF, n'entraînant aucune latence supplémentaire dans la fonction Lambda et réduisant les coûts en évitant les appels à l'API PutMetricData.

Remédier automatiquement aux volumes EBS non chiffrés détectés par AWS Config, en assurant la cohérence des données pendant le processus.

→Utiliser l'auto-remédiation d'AWS Config avec un document d'automatisation Systems Manager. Le runbook arrête l'instance, crée une copie chiffrée du volume, échange les volumes et redémarre l'instance.

Pourquoi: SSM Automation offre un flux de travail robuste, multi-étapes et auditable. L'arrêt de l'instance est essentiel pour garantir un instantané cohérent des données avant de créer la copie chiffrée.

Exécuter des expériences d'ingénierie du chaos contrôlées (par exemple, injecter de la latence réseau) avec des conditions d'arrêt automatiques pour prévenir l'impact sur la production.

→Utiliser AWS Fault Injection Simulator (FIS) avec un modèle d'expérience. Définir des conditions d'arrêt basées sur des alarmes CloudWatch qui surveillent les métriques clés de l'application.

Pourquoi: FIS est le service AWS spécialement conçu pour l'ingénierie du chaos, offrant des garde-fous de sécurité (conditions d'arrêt) et un catalogue d'actions d'injection de fautes contrôlées.

Une pile CloudFormation est bloquée dans l'état `UPDATE_ROLLBACK_FAILED` car une ressource a été supprimée ou modifiée lors d'une mise à jour ayant échoué, empêchant un retour arrière propre.

→Utiliser l'action API `ContinueUpdateRollback`, en spécifiant l'ID logique de la ressource problématique dans le paramètre `ResourcesToSkip`.

Pourquoi: C'est la procédure de récupération standard pour forcer le retour arrière à se terminer en indiquant à CloudFormation d'ignorer la ressource qu'il ne peut plus gérer, ramenant ainsi la pile à un état stable.

Recevoir des notifications en quelques minutes après la survenue d'événements de sécurité critiques, tels qu'une connexion au compte root, des modifications de politique IAM ou des modifications de groupe de sécurité.

→Créer des règles Amazon EventBridge qui correspondent à des motifs d'événements de gestion CloudTrail spécifiques et les acheminer vers une rubrique SNS pour notification.

Pourquoi: EventBridge reçoit les événements de gestion CloudTrail en temps quasi réel, offrant la latence la plus faible pour les alertes de sécurité basées sur les événements, par rapport aux méthodes par interrogation ou basées sur les logs.

Une fonction Lambda à fort trafic est limitée et épuise également les connexions à la base de données RDS lorsqu'elle monte en charge.

→Demander une augmentation de la limite d'exécution concurrente de Lambda. Implémenter Amazon RDS Proxy entre les fonctions Lambda et la base de données RDS.

Pourquoi: L'augmentation de la concurrence résout la limitation. RDS Proxy est essentiel pour les applications serverless, car il met en commun et réutilise les connexions à la base de données, empêchant la base de données d'être submergée par un grand nombre de connexions éphémères.

Mettre en œuvre un basculement DNS automatisé entre les régions et déclencher un runbook de récupération automatisé pour la région défaillante.

→Utiliser le routage de basculement Route 53 avec les vérifications d'état associées. Créer une règle EventBridge qui capture l'événement de changement d'état de la vérification d'état Route 53 et déclenche un runbook d'automatisation Systems Manager.

Pourquoi: Cette architecture combine le basculement de trafic automatisé (Route 53) avec une réponse automatisée aux incidents basée sur les événements (EventBridge + SSM Automation) pour un modèle de résilience complet.

Empêcher une base de données RDS de manquer de stockage et de provoquer une interruption de service de l'application.

→Activer l'Auto Scaling de stockage RDS en définissant un seuil de stockage maximal. En tant que contrôle secondaire, créer une alarme CloudWatch sur la métrique `FreeStorageSpace`.

Pourquoi: L'Auto Scaling de stockage est une fonctionnalité proactive et gérée qui augmente automatiquement le stockage alloué. L'alarme CloudWatch offre un filet de sécurité pour la surveillance et l'alerte.

Besoin de retraiter un lot d'événements qui ont été traités incorrectement en raison d'un bug temporaire chez un consommateur.

→Configurer une archive EventBridge sur le bus d'événements au préalable. Après la correction du bug, créer un Replay pour renvoyer les événements de la fenêtre de temps spécifique de l'incident.

Pourquoi: Archive et Replay est la fonctionnalité native d'EventBridge pour stocker et retraiter les événements historiques, cruciale pour la récupération après des défaillances de traitement transitoires.

Automatiser l'ensemble du processus de réponse aux incidents : créer un incident, engager l'équipe d'astreinte, ouvrir un canal de chat et exécuter un runbook de remédiation lorsqu'une alarme critique se déclenche.

→Créer un plan de réponse SSM Incident Manager qui définit toutes les étapes d'engagement et de remédiation. Configurer l'alarme CloudWatch pour déclencher ce plan de réponse comme son action.

Pourquoi: Les plans de réponse offrent une configuration unique et cohérente pour orchestrer tous les aspects de la réponse aux incidents, réduisant l'effort manuel et garantissant des procédures cohérentes.