Bonnes pratiques CloudFormation

Les bonnes pratiques sont des recommandations qui peuvent vous aider à utiliser CloudFormation plus efficacement et en toute sécurité tout au long de son flux de travail. Découvrez comment planifier et organiser vos piles, comment créer des modèles qui décrivent vos ressources et les applications qui y sont exécutées, et comment gérer vos piles et leurs ressources. Les bonnes pratiques suivantes reposent sur l'expérience réelle de clients actuels de CloudFormation.

Réduction du cycle de rétroaction pour accélérer le développement

Adoptez des pratiques et des outils qui vous aideront à raccourcir la boucle de rétroaction de l'infrastructure que vous décrivez à l'aide de modèles CloudFormation. Il s'agit notamment de procéder à un linting et à des tests précoces de vos modèles sur votre poste de travail ; vous pouvez ainsi détecter d'éventuels problèmes de syntaxe et de configuration avant même de soumettre vos contributions à un référentiel de code source. La détection précoce de ces problèmes permet d'éviter qu'ils atteignent les environnements formels du cycle de vie, tels que le développement, l'assurance qualité et la production. Cette approche de test précoce et d'interruption immédiate vous permet de réduire le temps d'attente pour le remaniement, de réduire les zones d'impact potentielles et d'accroître votre niveau de confiance dans la réussite des opérations de dimensionnement.

Les outils qui facilitent une approche de type interruption immédiate incluent les outils de ligne de commande CloudFormation Linter (cfn-lint) et TaskCat. L’outil cfn-lint permet de valider vos modèles CloudFormation par rapport à la Spécification des ressources CloudFormation. Il s'agit notamment de vérifier les valeurs valides des propriétés des ressources, ainsi que les meilleures pratiques. Des plug-ins pour cfn-lint sont disponibles pour plusieurs éditeurs de code, ce qui vous permet de visualiser les problèmes directement dans votre éditeur et d’obtenir un retour de validation immédiat. Vous pouvez également intégrer cfn-lint dans la configuration du référentiel de votre code source afin d’exécuter la validation de modèles lors de la validation de vos contributions. Pour plus d’informations, consultez Validation préalable des modèles CloudFormation par Git à l’aide de cfn-lint. Une fois que vous avez effectué votre validation initiale et corrigé les problèmes signalés par cfn-lint, vous pouvez utiliser TaskCat pour tester vos modèles en créant automatiquement des piles dans les Régions AWS que vous choisissez. TaskCat génère également un rapport avec une évaluation de réussite/échec pour chaque région sélectionnée.

Pour une présentation pratique, étape par étape, de l'utilisation de ces deux outils afin de raccourcir la boucle de rétroaction, suivez les instructions du Laboratoire de linting et de test de l'Atelier CloudFormation.

Organisation des piles par cycle de vie et propriétaire

Utilisez le cycle de vie et le propriétaire de vos ressources AWS pour vous aider à déterminer les ressources qui doivent aller dans chaque pile. Au départ, une pile peut suffire à contenir toutes vos ressources. Toutefois, à mesure que votre pile s'agrandit et se diversifie, sa gestion peut devenir longue et compliquée. En regroupant les ressources par cycle de vie et par propriétaire, les utilisateurs peuvent apporter des modifications à leur ensemble de ressources avec leurs propres processus et leur planification sans affecter les autres ressources.

Par exemple, imaginez une équipe de développeurs et d’ingénieurs responsable d’un site web hébergé sur des instances Amazon EC2 Auto Scaling derrière un équilibreur de charge. Comme le site web a son propre cycle de vie et qu'il est géré par l'équipe web, vous pouvez créer une pile pour le site web et ses ressources. Imaginez maintenant que le site web utilise également des bases de données principales, qui se trouvent dans une pile distincte où elles sont gérées par les administrateurs de base de données qui en sont également les propriétaires. Chaque fois que les membres de l'équipe web ou de l'équipe de base de données doivent mettre à jour leurs ressources, ils peuvent le faire sans affecter la pile de l'autre équipe. Si toutes les ressources étaient dans une seule pile, la coordination et la communication des mises à jour pourraient être difficiles.

Pour plus d'informations sur l'organisation de vos piles, vous pouvez utiliser deux structures communes : une architecture multicouche et une architecture orientée services (SOA).

Une architecture multicouche organise les piles dans plusieurs couches horizontales qui se chevauchent et où chaque couche dépend de la couche sous-jacente. Vous pouvez avoir une ou plusieurs piles dans chaque couche. Toutefois, les ressources AWS des piles de chaque couche doivent avoir des cycles de vie et un propriétaire similaires.

Avec une architecture orientée services, vous pouvez organiser les problématiques stratégiques d'une entreprise en portions gérables. Chacune de ces portions est un service dont l'objectif est clairement défini et qui représente une unité autonome de fonctionnalités. Vous pouvez mapper ces services avec des piles, où chaque pile a son propre cycle de vie et ses propriétaires. Ces services (piles) peuvent être reliés pour qu'ils puissent interagir les uns avec les autres.

Utilisation des références inter-piles pour récupérer la valeur d’une sortie exportée par une autre pile

Lorsque vous organisez vos ressources AWS en fonction du cycle de vie et de la propriété, vous pouvez créer une pile qui utilise des ressources situées dans une autre pile. Vous pouvez coder en dur des valeurs ou utiliser des paramètres d'entrée pour transmettre les noms et les ID de ressources. Toutefois, ces méthodes peuvent rendre difficile la réutilisation de modèles ou accroître les traitements nécessaires à l'exécution d'une pile. Au lieu de cela, utilisez des références inter-piles pour récupérer la valeur d’une sortie exportée par une autre pile, afin que d’autres piles puissent l’utiliser. Les piles peuvent utiliser les ressources exportées en les appelant à l'aide de la fonction Fn::ImportValue.

Par exemple, si vous disposez d'une pile de réseau constituée d'un VPC, d'un groupe de sécurité et d'un sous-réseau, et que vous souhaitez que toutes les applications web publiques utilisent ces ressources, vous devez exporter ces dernières. Toutes les piles dotées d'applications web publiques pourront ainsi les utiliser. Pour de plus amples informations, consultez Obtenir les sorties exportées d’une pile CloudFormation déployée.

Utilisez CloudFormation StackSets pour les déploiements multi-compte et multi-région

CloudFormation StackSets étendent la fonctionnalité des piles en vous permettant de créer, mettre à jour ou supprimer des piles dans plusieurs comptes et régions en une seule opération. Utilisez StackSets pour déployer des composants d’infrastructure communs, des contrôles de conformité ou des services partagés à l’échelle de votre organisation.

Lorsque vous utilisez StackSets, mettez en place des autorisations gérées par le service avec AWS Organizations, afin de simplifier la gestion des autorisations. Cette approche vous permet de déployer des StackSets dans les comptes de votre organisation sans devoir configurer manuellement des rôles IAM dans chaque compte.

Pour plus d’informations sur les StackSets, consultez Concepts StackSets.

Vérification des quotas pour tous les types de ressource

Avant de lancer une pile, vérifiez que vous pouvez créer toutes les ressources que vous voulez sans dépasser les limites de votre compte AWS. Si vous atteignez une limite, CloudFormation ne créera pas la pile tant que vous n'augmenterez pas le quota ou que vous ne supprimerez des ressources. Chaque service peut imposer des limites différentes que vous devez connaître avant de lancer une pile. Par exemple, par défaut, vous ne pouvez lancer que 2000 piles CloudFormation par région dans votre Compte AWS. Pour plus d'informations sur les limites et sur l'augmentation des limites par défaut, consultez service quotas AWS dans Références générales AWS.

Réutilisation de modèles pour répliquer des piles dans plusieurs environnements

Une fois que les piles et les ressources sont configurées, vous pouvez réutiliser vos modèles afin de répliquer votre infrastructure dans plusieurs environnements. Par exemple, vous pouvez créer des environnements de développement, de test et de production afin de pouvoir tester les modifications avant de les migrer en production. Pour que les modèles soient réutilisables, recourez aux sections Parameters, Mappings et Conditions afin de personnaliser les piles lorsque vous les créez. Par exemple, pour vos environnements de développement, vous pouvez spécifier un type d'instance qui coûte moins cher que votre environnement de production, mais où toutes les autres configurations et tous les autres paramètres restent les mêmes. Pour plus d'informations sur les paramètres, les mappages et les conditions, consultez Sections du modèle CloudFormation.

Utiliser des modules pour réutiliser les configurations de ressources

A mesure que votre infrastructure s'agrandit, des tendances peuvent émerger où vous déclarez les mêmes composants dans chacun de vos modèles. Les modules vous permettent d'empaqueter des configurations de ressources pour les inclure dans les modèles de pile, de manière transparente, gérable et reproductible. Les modules peuvent encapsuler les configurations de service courantes et les bonnes pratiques en tant que blocs de création modulaires et personnalisables à inclure dans vos modèles de pile.

Ces blocs de construction peuvent être destinés à une seule ressource, telle que les bonnes pratiques pour définir une instance Amazon Elastic Compute Cloud (Amazon EC2), ou à plusieurs ressources pour définir des modèles communs d'architecture d'application. Ces blocs de construction peuvent être imbriqués dans d'autres modules, de sorte que vous pouvez empiler vos bonnes pratiques dans des blocs de construction de niveau supérieur. Les modules sont disponibles dans le registre CloudFormation, de sorte que vous pouvez les utiliser comme ressources natives. Lorsque vous utilisez un module CloudFormation, le modèle de module est développé dans le modèle utilisé, ce qui vous permet d'accéder aux ressources dans le module à l'aide d'une fonction Ref ou Fn::GetAtt. Pour de plus amples informations, consultez Création de configurations de ressources réutilisables pouvant être incluses dans plusieurs modèles à l’aide des modules CloudFormation.

Adoption des pratiques d’infrastructure en tant que code

Traitez vos modèles CloudFormation comme du code en adoptant les pratiques d’infrastructure en tant que code (IaC). Stockez vos modèles dans des systèmes de gestion des versions, mettez en œuvre des révisions de code et utilisez des tests automatisés pour valider les modifications. Cette approche garantit la cohérence, améliore la collaboration et fournit une piste d’audit pour les modifications d’infrastructure.

Envisagez de mettre en place des pipelines CI/CD pour automatiser les tests et le déploiement de vos modèles CloudFormation. Des outils comme AWS CodePipeline, AWS CodeBuild et AWS CodeDeploy peuvent être utilisés pour créer des flux de travail automatisés pour vos déploiements d’infrastructure.

Pour plus d’informations sur la mise en œuvre des bonnes pratiques IaC, consultez Utilisation de AWS CloudFormation comme outil IaC.

Pour plus d’informations sur l’utilisation de la diffusion continue avec CloudFormation, consultez Diffusion continue avec CodePipeline.

N’intégrez pas d’informations d’identification dans vos modèles

Plutôt que de vectoriser des informations sensibles dans vos modèles CloudFormation, nous vous recommandons d’utiliser des références dynamiques dans votre modèle de pile.

Les références dynamiques vous permettent de faire référence de façon concise et efficace à des valeurs externes stockées et gérées dans d'autres services, tels qu'AWS Systems Manager Parameter Store ou AWS Secrets Manager. Lorsque vous utilisez une référence dynamique, CloudFormation récupère la valeur de la référence spécifiée lorsque cela est nécessaire au cours d'opérations de pile et de jeu de modifications et transmet cette valeur à la ressource appropriée. Cependant, CloudFormation ne stocke jamais la valeur de référence réelle. Pour de plus amples informations, veuillez consulter Utilisation de références dynamiques pour spécifier des valeurs de modèle.

AWS Secrets Manager vous aider à chiffrer, stocker et récupérer en toute sécurité des informations d'identification pour vos bases de données et d'autres services. AWS Systems Manager Parameter Store offre un stockage sécurisé et hiérarchique de la gestion des données de configuration.

Pour plus d'informations sur la définition des paramètres de modèle, consultez Syntaxe Parameters du modèle CloudFormation.

Utiliser les types de paramètres spécifique à AWS

Si votre modèle nécessite des entrées pour des valeurs existantes spécifiques à AWS, telles que des ID Amazon Virtual Private Cloud ou un nom de paire de clés Amazon EC2, utilisez des types de paramètres spécifiques à AWS. Par exemple, vous pouvez spécifier un paramètre de type AWS::EC2::KeyPair::KeyName, qui utilise un nom de paire de clés existante dans votre Compte AWS et dans la région où vous créez la pile. CloudFormation peut valider rapidement les valeurs pour les types de paramètres propres à AWS avant de créer votre pile. En outre, si vous utilisez la console CloudFormation, CloudFormation affiche une liste déroulante des valeurs valides. Dès lors, vous n'avez pas besoin de rechercher ni de mémoriser les ID de VPC ou les noms de paires de clés. Pour de plus amples informations, consultez Spécification de ressources existantes à l’exécution avec les types de paramètres fournis par CloudFormation.

Utilisation de contraintes de paramètre

Les contraintes vous permettent de décrire des valeurs d'entrée autorisées. De cette manière, CloudFormation détecte les valeurs non valides avant de créer une pile. Vous pouvez définir des contraintes comme une longueur minimale, une longueur maximale et des modèles autorisés. Par exemple, vous pouvez définir des contraintes au niveau de la valeur du nom d'utilisateur d'une base de données, de sorte qu'elle contienne au moins huit caractères alphanumériques. Pour de plus amples informations, consultez Syntaxe Parameters du modèle CloudFormation.

Utiliser des pseudoparamètres pour promouvoir la portabilité

Vous pouvez utiliser des pseudo-paramètres dans vos modèles comme arguments pour des fonctions intrinsèques, telles que Ref et Fn::Sub. Les pseudo-paramètres sont des paramètres prédéfinis par CloudFormation. Vous ne les déclarez pas dans le modèle. L’utilisation de pseudo-paramètres dans les fonctions intrinsèques augmente la portabilité de vos modèles de pile entre les régions et les comptes.

Par exemple, imaginez que vous souhaitiez créer un modèle dans lequel, pour une propriété de ressource donnée, vous devez spécifier l'Amazon Resource Name (ARN) d'une autre ressource existante. Dans ce cas, la ressource existante est une ressource AWS Systems Manager Parameter Store avec l'ARN suivant : arn:aws:ssm:us-east-1:123456789012:parameter/MySampleParameter. Vous devrez adapter le format ARN à votre partition cible AWS, à votre région et à votre ID de compte. Au lieu de coder ces valeurs en dur, vous pouvez utiliser des pseudo-paramètres AWS::Partition, AWS::Region et AWS::AccountId pour rendre votre modèle plus portable. Dans ce cas, l'exemple suivant vous montre comment concaténer des éléments dans un ARN avec CloudFormation : !Sub 'arn:${AWS::Partition}:ssm:${AWS::Region}:${AWS::AccountId}:parameter/MySampleParameter.

Pour un autre exemple, supposons que vous souhaitiez partager des ressources ou des configurations entre plusieurs piles. Dans cet exemple, supposons que vous avez créé un sous-réseau pour votre VPC, puis que vous avez exporté son ID pour l’utiliser avec d’autres piles du même Compte AWS et de la même région. Dans une autre pile, vous faites référence à la valeur exportée de l'ID de sous-réseau lorsque vous décrivez une instance Amazon EC2. Pour un exemple détaillé de l’utilisation du champ de sortie Export et de la fonction intrinsèque Fn::ImportValue, consultez Référencer les sorties de ressources dans une autre pile CloudFormation.

Les exportations de pile doivent être uniques par compte et par région. Dans ce cas, vous pouvez donc utiliser le pseudo paramètre AWS::StackName pour créer un préfixe pour votre exportation. Comme les noms de pile doivent également être uniques par compte et par région, l’utilisation de ce pseudo-paramètre comme préfixe augmente la possibilité d’avoir un nom d’exportation unique, tout en promouvant une approche réutilisable dans les piles à partir desquelles vous exportez des valeurs. Vous pouvez également utiliser un préfixe de votre choix.

Utilisation d'AWS::CloudFormation::Init pour déployer des applications dans des instances Amazon Amazon EC2

Lorsque vous lancez des piles, vous pouvez installer et configurer des applications logicielles sur des instances Amazon EC2 via le script d’assistance cfn-init et la ressource AWS::CloudFormation::Init. Avec AWS::CloudFormation::Init, vous pouvez décrire les configurations de votre choix au lieu de créer des scripts pour chaque étape de la procédure. Vous pouvez également mettre à jour les configurations sans avoir à recréer les instances. En cas de problème avec votre configuration, CloudFormation génère des journaux que vous pouvez utiliser pour en déterminer la cause.

Dans le modèle, spécifiez les états de l'installation et de la configuration dans la ressource AWS::CloudFormation::Init. Pour la procédure pas à pas montrant comment utiliser cfn-init et AWS::CloudFormation::Init, consultez Déploiement d’applications sur Amazon EC2.

Utilisation des derniers scripts d'assistant

Les scripts d’assistance CloudFormation sont mis à jour périodiquement. Veillez à inclure la commande suivante dans la propriété UserData de votre modèle avant d'appeler les scripts d'assistant pour vous assurer que vos instances lancées obtiennent les derniers scripts d'assistant :

yum install -y aws-cfn-bootstrap

Pour plus d’informations sur les scripts d’assistance les plus récents, consultez Référence des scripts d’assistance CloudFormation dans le Guide de référence des modèles CloudFormation.

Validation des modèles avant leur utilisation

Avant d'utiliser un modèle pour créer ou mettre à jour une pile, vous pouvez utiliser CloudFormation pour le valider. La validation d'un modèle peut vous aider à détecter les erreurs de syntaxe et certaines erreurs sémantiques, telles que des dépendances circulaires, avant que CloudFormation ne crée les ressources. Si vous utilisez la console CloudFormation, celle-ci valide automatiquement le modèle une fois que vous spécifiez les paramètres d'entrée. Pour la AWS CLI ou l’API CloudFormation, utilisez la commande CLI validate-template ou l’opération API ValidateTemplate.

Pendant la validation, CloudFormation vérifie d'abord si le modèle est dans un format JSON valide. Si ce n'est pas le cas, CloudFormation vérifie si le modèle est dans un format YAML valide. Si les deux vérifications échouent, CloudFormation retourne une erreur de validation de modèle.

Valider les modèles pour la conformité des politiques de l'organisation

Vous pouvez également valider votre modèle pour la conformité aux directives de politique de l'organisation. AWS CloudFormation Guard (cfn-guard) est un outil d'interface de ligne de commande (CLI) open source qui fournit un langage de politique en tant que code pour définir des règles permettant de vérifier les configurations de ressources requises et interdites. Il vous permet ensuite de valider vos modèles par rapport à ces règles. Par exemple, les administrateurs peuvent créer des règles pour garantir que les utilisateurs créent toujours des compartiments Amazon S3 chiffrés.

Vous pouvez utiliser cfn-guard soit localement lors de la modification des modèles, soit automatiquement dans le cadre d'un pipeline IC/DC pour arrêter le déploiement de ressources non conformes.

En outre, cfn-guard inclut la fonction rulegen, qui vous permet d'extraire des règles à partir de modèles CloudFormation conformes existants.

Pour de plus amples informations, veuillez consulter le référentiel cfn-guard sur GitHub.

Utilisation de YAML ou JSON pour la création de modèles

CloudFormation prend en charge les formats YAML et JSON pour les modèles. Chaque format présente des avantages, et le choix dépend de vos besoins :

Utilisez YAML lorsque

Utilisez JSON lorsque :

Le format YAML est généralement recommandé pour une création manuelle grâce à sa lisibilité et sa prise en charge des commentaires. Il est particulièrement utile pour les modèles complexes où l’indentation facilite la visualisation des hiérarchies de ressources. Le format JSON peut être avantageux dans les flux de travail automatisés ou lorsque vous travaillez avec des API qui nécessitent une entrée JSON. C’est également avantageux lorsque vous devez garantir le strict respect d’une structure spécifique. Quel que soit le format choisi, privilégiez des modèles bien structurés, documentés et maintenables. Si vous utilisez le format YAML, tirez parti de ses fonctionnalités telles que les ancres et les alias pour réduire les répétitions et améliorer la maintenabilité.

Mise en œuvre d’une stratégie de balisage complète

Mettez en œuvre une stratégie de balisage cohérente pour toutes les ressources créées par vos modèles CloudFormation. Les balises facilitent l’organisation des ressources, la répartition des coûts, le contrôle d’accès et l’automatisation. Envisagez d’inclure des balises pour l’environnement, le propriétaire, le centre de coûts, l’application et l’objectif.

Utilisez la propriété Tags de la ressource AWS::CloudFormation::Stack pour appliquer des balises à toutes les ressources prises en charge dans une pile. Vous pouvez également utiliser la propriété TagSpecifications disponible sur de nombreux types de ressources pour appliquer des balises lors de la création des ressources.

Pour plus d’informations sur le balisage, consultez Balisage des ressources.

Exploitation des macros de modèle pour des transformations avancées

Les macros CloudFormation permettent d’effectuer un traitement personnalisé sur les modèles, depuis de simples opérations de recherche et remplacement jusqu’à des transformations complexes générant des ressources supplémentaires. Utilisez des macros pour étendre les fonctionnalités des modèles CloudFormation et implémenter des modèles réutilisables au sein de votre organisation.

Le AWS Serverless Application Model est un exemple de macro simplifiant le développement d’applications sans serveur. Envisagez la création de macros personnalisées adaptées aux modèles, contraintes et exigences propres à votre organisation.

Pour plus d’informations sur l’utilisation des macros dans vos modèles, consultez Présentation des macros CloudFormation.

Gestion de toutes les ressources de pile par CloudFormation

Après avoir lancé une pile, utilisez la console, l’API ou la CLI AWS pour mettre à jour les ressources de la pile. N'apportez aucune modification aux ressources de la pile en dehors de CloudFormation. Cette approche peut générer un décalage entre le modèle de votre pile et l'état actuel de ses ressources, ce qui peut entraîner des erreurs si vous mettez à jour ou supprimez la pile. Ce phénomène est appelé dérive. Si une modification est effectuée directement sur une ressource en dehors du modèle CloudFormation puis que vous mettez à jour la pile, les modifications manuelles seront écrasées : la configuration de la ressource reviendra à celle définie dans le modèle.

Pour plus d’informations sur la dérive, consultez Qu'est-ce qu'un écart ?.

Pour plus d’informations sur la mise à jour des piles, consultez Mise à jour d'une pile.

Création de jeux de modification avant la mise à jour des piles

Les jeux de modifications vous permettent d'avoir un aperçu de l'impact possible des modifications d'une pile sur les ressources exécutées avant d'appliquer ces modifications. CloudFormation n'apporte pas de modifications à votre pile tant que vous n'exécutez pas le jeu de modifications, ce qui vous permet de décider si vous souhaitez procéder aux modifications proposées ou créer un autre jeu de modifications.

Utilisez les jeux de modification pour vérifier l'impact possible des modifications sur les ressources exécutées, notamment les ressources critiques. Par exemple, si vous modifiez le nom d'une instance de base de données Amazon RDS, CloudFormation crée une nouvelle base de données et supprime l'ancienne. Vous perdez les données de l'ancienne base de données, sauf si vous les avez sauvegardées. Si vous générez un jeu de modification, vous verrez que la modification remplacera la base de données. Vous pouvez donc vous préparer à la mise à jour la pile en conséquence. Pour de plus amples informations, consultez Mettre à jour les piles CloudFormation à l’aide de jeux de modifications.

Utilisation des politiques de pile pour protéger les ressources

Les politiques de pile contribuent à protéger les ressources critiques d'une pile contre toute mise à jour accidentelle qui pourrait entraîner l'interruption des ressources, voire leur remplacement. Une politique de pile est un document JSON qui décrit les actions de mise à jour qui peuvent être effectuées au niveau des ressources désignées. Spécifiez une politique de pile chaque fois que vous créez une pile qui contient des ressources critiques.

Pendant une mise à jour de la pile, vous devez spécifier explicitement les ressources protégées que vous souhaitez mettre à jour. Dans le cas contraire, aucune modification ne sera apportée aux ressources protégées. Pour de plus amples informations, consultez Empêcher les mises à jour des ressources de la pile.

Utilisation de AWS CloudTrail pour journaliser les appels CloudFormation

AWS CloudTrail suit toutes les personnes qui effectuent des appels d’API CloudFormation dans votre Compte AWS. Les appels d’API sont journalisés chaque fois qu’une personne utilise l’API CloudFormation, la console CloudFormation, une console back-end ou des commandes AWS CLI CloudFormation. Activez la journalisation et spécifiez un compartiment Amazon S3 pour y stocker les journaux. De cette façon, le cas échéant, vous pourrez déterminer qui a effectué quel appel CloudFormation dans votre compte.

Pour de plus amples informations, consultez Journalisation des appels d’API CloudFormation avec AWS CloudTrail.

Utilisation des révisions de code et des contrôles de révision pour gérer les modèles

Les modèles d'une pile décrivent la configuration de vos ressources AWS, telle que leurs valeurs de propriété. Pour passer en revue les modifications et pour conserver un historique précis de vos ressources, utilisez les révisions de code et les contrôles de révision. Ces méthodes vous permettent de suivre les modifications apportées entre différentes versions de vos modèles, ce qui peut vous aider à identifier les modifications apportées aux ressources de votre pile. En outre, en conservant un historique, vous pouvez toujours restaurer la pile sur la base d'une certaine version de votre modèle.

Mettez à jour régulièrement vos instances Amazon EC2

Sur toutes vos instances Amazon EC2 Windows et vos instances Amazon EC2 Linux créées avec CloudFormation, exécutez régulièrement la commande yum update pour mettre à jour le package RPM. Cela garantit que vous obtenez les derniers correctifs et mises à jour de sécurité.

Utilisation régulière de la détection de dérive

Utilisez régulièrement la caractéristique de détection de dérive de CloudFormation pour identifier les ressources qui ont été modifiées en dehors de la gestion de CloudFormation. La détection et la résolution des dérives contribuent à préserver l’intégrité de votre approche d’infrastructure en tant que code et à garantir que vos modèles reflètent fidèlement l’état de vos ressources déployées.

Envisagez de mettre en œuvre une détection automatique de la dérive dans le cadre de vos procédures opérationnelles. Vous pouvez utiliser des fonctions AWS Lambda déclenchées par des règles Amazon EventBridge pour vérifier périodiquement l’existence de dérive et notifier votre équipe en cas d’écart.

Pour plus d’informations sur la dérive, consultez Détection de modifications non gérées de la configuration des piles et des ressources avec la détection de dérive.

Configuration des déclencheurs de restauration automatique

Utilisez des déclencheurs de restauration pour spécifier les alarmes Amazon CloudWatch que CloudFormation doit surveiller lors des opérations de création ou de mise à jour d’une pile. Si l’une des alarmes spécifiées passe à l’état ALARM, CloudFormation restaure automatiquement l’ensemble de l’opération, ce qui garantit que votre infrastructure reste dans un état stable.

Configurez des déclencheurs de restauration pour des métriques critiques comme les taux d’erreur des applications, l’utilisation des ressources du système, ou des métriques commerciales personnalisées qui indiquent l’état de votre application et de votre infrastructure.

Pour plus d’informations sur les déclencheurs de restauration, consultez Restauration de la pile en cas de déclenchement d’une alarme.

Mise en œuvre de stratégies efficaces de refactorisation des piles

À mesure que votre infrastructure évolue, vous pouvez être amené à refactoriser vos piles CloudFormation pour améliorer leur maintenabilité, réduire leur complexité ou vous adapter à de nouvelles exigences. La refactorisation des piles consiste à réorganiser vos modèles et ressources tout en préservant leur comportement et leur fonctionnement externes. La refactorisation des piles est présente des avantages lorsquelle est utilisée avec CloudFormation des manières suivantes :

Pour plus d’informations sur la refactorisation des piles CloudFormation, consultez Refactorisation de piles.

Utilisation des hooks CloudFormation pour la gestion du cycle de vie

Les hooks CloudFormation exécutent du code qui inspecte de manière proactive la configuration de vos ressources AWS avant leur provisionnement et effectuent des contrôles avancés de validation. Les hooks permettent de vérifier la conformité de vos ressources, de vos piles et de vos ensembles de modifications aux exigences de sécurité, d’exploitation et d’optimisation des coûts. Ils générent des avertissements avant le provisionnement d’une ressource, ou avant l’échec de l’opération et son arrêt complet, selon la configuration du hook. Les violations et les avertissements sont enregistrés dans Amazon CloudWatch afin de fournir une visibilité sur les déploiements non conformes.

Pour plus d’informations sur les bonnes pratiques relatives aux hooks, consultez Concepts des hooks AWS CloudFormation.

Pour plus d’informations sur ce que les jooks peuvent apporter à vos ressources CloudFormation, consultez Qu’est-ce que les hooks AWS CloudFormation ?

Utilisation du générateur IaC pour créer des modèles à partir de ressources existantes

Le générateur IaC (infrastructure en tant que code) CloudFormation vous aide à créer des modèles CloudFormation à partir de vos ressources AWS existantes. Cette fonctionnalité est particulièrement utile lorsque vous devez répliquer une infrastructure existante, documenter des ressources créées manuellement ou transférer des ressources auparavant non gérées sous la gestion de CloudFormation. Le générateur IaC est utile pour créer vos modèles CloudFormation de la manière suivante :

Pour plus d’informations sur le générateur iAC, consultez Génération de modèles à partir de ressources existantes avec le générateur IaC.

Utilisation de AWS Infrastructure Composer pour la conception de modèles visuels

AWS Infrastructure Composer est un outil de conception visuelle permettant de créer, visualiser et modifier des modèles CloudFormation grâce à une interface de type glisser-déposer. Il peut être particulièrement utile lors de l’utilisation de CloudFormation des manières suivantes :

Pour plus d’informations sur Infrastructure Composer, consultez Qu’est-ce qu’AWS Infrastructure Composer ?.

Utilisation du AWS Cloud Development Kit (AWS CDK) pour les infrastructures complexes

Pour des infrastructures complexes, envisagez l’utilisation du CDK, qui permet de définir vos ressources cloud en utilisant des langages de programmation familiers tels que TypeScript, Python, Java et .NET. AWS CDK génère automatiquement des modèles CloudFormation à partir de votre code, ce qui vous permet de bénéficier des capacités complètes de CloudFormation tout en utilisant des abstractions et des constructions propres au langage choisi.

Le AWS CDK fournit des constructions de haut niveau qui encapsulent les bonnes pratiques et simplifient la définition des modèles d’infrastructure courants. Cela peut réduire considérablement la quantité de code nécessaire pour définir votre infrastructure tout en garantissant le respect des bonnes pratiques.

Pour plus d’informations sur le CDK, consultez AWS Cloud Development Kit (AWS CDK).

Utilisation du contrôle d'accès IAM

IAM est un service AWS que vous pouvez utiliser pour gérer les utilisateurs et leurs autorisations dans AWS. Vous pouvez utiliser IAM avec CloudFormation pour spécifier les actions CloudFormation que les utilisateurs sont autorisés à effectuer, comme afficher les modèles de piles, créer des piles ou supprimer des piles. De plus, toute personne qui gère des piles CloudFormation doit disposer d’autorisations pour les ressources contenues dans ces piles. Par exemple, si des utilisateurs souhaitent utiliser CloudFormation pour lancer, mettre à jour ou résilier des instances Amazon EC2, ils doivent disposer de l’autorisation d’appeler les actions Amazon EC2 correspondantes.

Dans la majorité des cas, les utilisateurs doivent avoir un accès complet pour gérer toutes les ressources d’un modèle. CloudFormation effectue les appels permettant de créer, modifier et supprimer ces ressources en leur nom. Pour séparer les autorisations entre un utilisateur et le service CloudFormation, utilisez un rôle de service. CloudFormation utilise la stratégie du rôle de service pour effectuer les appels, au lieu de la stratégie de l’utilisateur. Pour de plus amples informations, consultez CloudFormationRôle de service .

Application du principe du moindre privilège

Lorsque vous configurez des rôles IAM pour les rôles de service CloudFormation ou pour les ressources créées par vos modèles, appliquez toujours le principe du moindre privilège. N’accordez que les autorisations strictement nécessaires à la fonctionnalité prévue et évitez autant que possible les autorisations génériques avec caractères génériques.

Utilisez l’analyseur d’accès IAM pour examiner les autorisations accordées à vos rôles de service CloudFormation et identifier les autorisations inutilisées qui peuvent être supprimées. Examinez et mettez régulièrement à jour les politiques IAM afin de vous assurer qu’elles restent conformes à vos exigences de sécurité.

Sécurisation des paramètres sensibles

Pour les informations sensibles, comme les mots de passe, les clés API et autres secrets, utilisez le magasin de paramètres AWS Systems Manager ou AWS Secrets Manager plutôt que de les vectoriser directement dans vos modèles. Utilisez des références dynamiques dans vos modèles pour extraire ces valeurs de manière sécurisée lors des opérations sur les piles.

Lorsque vous utilisez des paramètres dans vos modèles, définissez la propriété NoEcho sur true pour les paramètres sensibles, afin d’éviter que leurs valeurs ne s’affichent dans la console, dans les réponses de l’API ou dans la sortie de la CLI. Notez toutefois que NoEcho n’empêche pas la valeur d’être consignée si elle est transmise à d’autres services ou ressources susceptibles de la journaliser.

Pour plus d’informations sur l’utilisation du magasin de paramètres AWS Systems Manager avec CloudFormation, consultez Obtenir une valeur en texte brut à partir du magasin de paramètres AWS Systems Manager.

Pour plus d’informations sur l’utilisation de la propriété NoEcho, consultez Syntaxe des paramètres de modèles CloudFormation.

Pour plus d’informations sur l’utilisation de AWS Secrets Manager avec CloudFormation, consultez Création des secrets AWS Secrets Manager dans AWS CloudFormation.

Mise en œuvre de la politique en tant que code avec AWS CloudFormation Guard

AWS CloudFormation Guard (cfn-guard) est un outil open source de politique en tant que code qui permet de définir et d’appliquer des règles à vos modèles CloudFormation. Utilisez cfn-guard pour garantir que vos modèles respectent les politiques organisationnelles, les bonnes pratiques de sécurité et les exigences de gouvernance.

Intégrez cfn-guard dans vos pipelines CI/CD pour valider automatiquement les modèles selon vos règles avant leur déploiement. Cela permet d’empêcher le déploiement de ressources non conformes dans votre environnement et fournit un retour rapide aux développeurs en cas de violation de règles.

Pour plus d’informations sur Guard, consultez Qu’est-ce qu’AWS CloudFormation Guard ?