Sélectionner vos préférences de cookies

Nous utilisons des cookies essentiels et des outils similaires qui sont nécessaires au fonctionnement de notre site et à la fourniture de nos services. Nous utilisons des cookies de performance pour collecter des statistiques anonymes afin de comprendre comment les clients utilisent notre site et d’apporter des améliorations. Les cookies essentiels ne peuvent pas être désactivés, mais vous pouvez cliquer sur « Personnaliser » ou « Refuser » pour refuser les cookies de performance.

Si vous êtes d’accord, AWS et les tiers approuvés utiliseront également des cookies pour fournir des fonctionnalités utiles au site, mémoriser vos préférences et afficher du contenu pertinent, y compris des publicités pertinentes. Pour accepter ou refuser tous les cookies non essentiels, cliquez sur « Accepter » ou « Refuser ». Pour effectuer des choix plus détaillés, cliquez sur « Personnaliser ».

Running a Stack in a VPC - AWS OpsWorks

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Running a Stack in a VPC

Important

Le AWS OpsWorks Stacks service a atteint sa fin de vie le 26 mai 2024 et a été désactivé tant pour les nouveaux clients que pour les clients existants. Nous recommandons vivement aux clients de migrer leurs charges de travail vers d'autres solutions dès que possible. Si vous avez des questions sur la migration, contactez l' AWS Support équipe sur AWS Re:Post ou via le AWS Support Premium.

Vous pouvez contrôler l'accès utilisateur aux instances d'une pile en la créant dans un Virtual Private Cloud (VPC). Par exemple, il se peut que vous ne vouliez pas que les utilisateurs accèdent directement aux serveurs d'applications ou aux bases de données de votre pile, et, qu'à la place, tout le trafic public soit acheminé via un Elastic Load Balancer.

La procédure de base pour exécuter une pile dans un VPC est la suivante :

  1. Créez un VPC configuré de manière appropriée, à l'aide de la console ou de l'API Amazon VPC, ou d'un modèle. AWS CloudFormation

  2. Spécifiez l'ID VPC lorsque vous créez la pile.

  3. Lancez les instances de la pile dans le sous-réseau approprié.

Ce qui suit décrit brièvement le VPCs fonctionnement de AWS OpsWorks Stacks.

Important

Si vous utilisez la fonctionnalité VPC Endpoint, sachez que chaque instance de la pile doit être en mesure d'effectuer les actions suivantes depuis Amazon Simple Storage Service (Amazon S3) :

  • Installer l'agent de l'instance.

  • Installez les ressources, tels que Ruby.

  • Charger les journaux d'exécution Chef.

  • Récupérer les commandes de pile.

Pour activer ces actions, vous devez vous assurer que les instances de la pile ont accès aux compartiments suivants qui correspondent à la région de la pile. Sinon, les actions précédentes échouent.

Pour Chef 12 Linux et Chef 12.2 Windows, les compartiments sont les suivants.

Compartiments d'agents Compartiments de ressources Compartiments de journaux Compartiments DNA
  • opsworks-instance-agent-sa-est-1

  • opsworks-instance-agent-ap-sud-1

  • opsworks-instance-agent-ap-nord-est-1

  • opsworks-instance-agent-ap-nord-est-2

  • opsworks-instance-agent-ap-sud-est-1

  • opsworks-instance-agent-ap-sud-est-2

  • opsworks-instance-agent-ca-central-1

  • opsworks-instance-agent-eu-central-1

  • opsworks-instance-agent-eu-ouest-1

  • opsworks-instance-agent-eu-ouest-2

  • opsworks-instance-agent-eu-ouest-3

  • opsworks-instance-agent-us-est-1

  • opsworks-instance-agent-us-est-2

  • opsworks-instance-agent-us-ouest-1

  • opsworks-instance-agent-us-ouest-2

  • opsworks-instance-assets-us-est-2

  • opsworks-instance-assets-us-est-1

  • opsworks-instance-assets-ap-sud-1

  • opsworks-instance-assets-ap-nord-est-1

  • opsworks-instance-assets-ap-nord-est-2

  • opsworks-instance-assets-ap-sud-est-1

  • opsworks-instance-assets-ap-sud-est-2

  • opsworks-instance-assets-ca-central-1

  • opsworks-instance-assets-eu-central-1

  • opsworks-instance-assets-eu-ouest-1

  • opsworks-instance-assets-eu-ouest-2

  • opsworks-instance-assets-eu-ouest-3

  • opsworks-instance-assets-sa-est-1

  • opsworks-instance-assets-us-ouest-1

  • opsworks-instance-assets-us-ouest-2

  • opsworks-us-east-2 journaux

  • opsworks-us-east-1 journal

  • opsworks-ap-south-1 journal

  • opsworks-ap-northeast-1 journal

  • opsworks-ap-northeast-2 journaux

  • opsworks-ap-southeast-1 journal

  • opsworks-ap-southeast-2 journaux

  • opsworks-ca-central-1 journal

  • opsworks-eu-central-1 journal

  • opsworks-eu-west-1 journal

  • opsworks-eu-west-2 journaux

  • opsworks-eu-west-3 journaux

  • opsworks-sa-east-1 journal

  • opsworks-us-west-1 journal

  • opsworks-us-west-2 journaux

  • opsworks-us-east-2-ADN

  • opsworks-us-east-1-ADN

  • opsworks-ap-south-1-ADN

  • opsworks-ap-northeast-1-ADN

  • opsworks-ap-northeast-2-ADN

  • opsworks-ap-southeast-1-ADN

  • opsworks-ap-southeast-2-ADN

  • opsworks-ca-central-1-ADN

  • opsworks-eu-central-1-ADN

  • opsworks-eu-west-1-ADN

  • opsworks-eu-west-2-ADN

  • opsworks-eu-west-3-ADN

  • opsworks-sa-east-1-ADN

  • opsworks-us-west-1-ADN

  • opsworks-us-west-2-ADN

Pour Chef 11.10 pour Linux et versions antérieures, les compartiments se présentent comme suit. Les piles Chef 11.4 ne sont pas prises en charge sur les points de terminaison régionaux situés en dehors de la région de l'est des États-Unis (Virginie du Nord).

Compartiments d'agents Compartiments de ressources Compartiments de journaux Compartiments DNA
  • opsworks-instance-agent-us-est-2

  • opsworks-instance-agent-us-est-1

  • opsworks-instance-agent-ap-sud-1

  • opsworks-instance-agent-ap-nord-est-1

  • opsworks-instance-agent-ap-nord-est-2

  • opsworks-instance-agent-ap-sud-est-1

  • opsworks-instance-agent-ap-sud-est-2

  • opsworks-instance-agent-ca-central-1

  • opsworks-instance-agent-eu-central-1

  • opsworks-instance-agent-eu-ouest-1

  • opsworks-instance-agent-eu-ouest-2

  • opsworks-instance-agent-eu-ouest-3

  • opsworks-instance-agent-us-est-1

  • opsworks-instance-agent-us-ouest-1

  • opsworks-instance-agent-us-ouest-2

  • opsworks-instance-assets-us-est-2

  • opsworks-instance-assets-us-est-1

  • opsworks-instance-assets-ap-sud-1

  • opsworks-instance-assets-ap-nord-est-1

  • opsworks-instance-assets-ap-nord-est-2

  • opsworks-instance-assets-ap-sud-est-1

  • opsworks-instance-assets-ap-sud-est-2

  • opsworks-instance-assets-ca-central-1

  • opsworks-instance-assets-eu-central-1

  • opsworks-instance-assets-eu-ouest-1

  • opsworks-instance-assets-eu-ouest-2

  • opsworks-instance-assets-eu-ouest-3

  • opsworks-instance-assets-sa-est-1

  • opsworks-instance-assets-us-ouest-1

  • opsworks-instance-assets-us-ouest-2

  • prod_stage-log

  • prod_stage-dna

Pour plus d'informations, consultez Points de terminaison d'un VPC.

Note

Pour que AWS OpsWorks Stacks puisse se connecter aux points de terminaison VPC que vous activez, vous devez également configurer le routage pour votre NAT ou votre adresse IP publique, car AWS OpsWorks l'agent Stacks a toujours besoin d'accéder au point de terminaison public.

Notions de base des VPC

Pour une discussion détaillée sur VPCs, consultez Amazon Virtual Private Cloud. En bref, un VPC se compose d'un ou plusieurs sous-réseaux, chacun contenant une ou plusieurs instances. Chaque sous-réseau dispose d'une table de routage associée qui dirige le trafic sortant en fonction de son adresse IP de destination.

  • Les instances au sein d'un VPC peuvent communiquer les unes avec les autres par défaut, quel que soit leur sous-réseau. Cependant, les modifications apportées aux listes de contrôle d'accès au réseau (ACLs), aux politiques des groupes de sécurité ou à l'utilisation d'adresses IP statiques peuvent interrompre cette communication.

  • Les sous-réseaux dont les instances peuvent communiquer avec Internet sont appelés sous-réseaux publics.

  • Les sous-réseaux dont les instances peuvent communiquer uniquement avec d'autres instances du VPC et ne peuvent pas communiquer directement avec le réseau Internet sont appelés sous-réseaux privés.

AWS OpsWorks Stacks nécessite que le VPC soit configuré de telle sorte que chaque instance de la pile, y compris les instances situées dans des sous-réseaux privés, ait accès aux points de terminaison suivants :

  • L'un des points de terminaison du service AWS OpsWorks Stacks répertoriés dans la section « Support régional » de. Débuter avec AWS OpsWorks Stacks

  • L'un des points de terminaison du service d'instance suivants, utilisé par l'agent AWS OpsWorks Stacks. L'agent s'exécute sur les instances gérées par le client pour échanger des données avec le service.

    • opsworks-instance-service.us-east-2.amazonaws.com

    • opsworks-instance-service.us-east-1.amazonaws.com

    • opsworks-instance-service.us-west-1.amazonaws.com

    • opsworks-instance-service.us-west-2.amazonaws.com

    • opsworks-instance-service.ap-south-1.amazonaws.com

    • opsworks-instance-service.ap-northeast-1.amazonaws.com

    • opsworks-instance-service.ap-northeast-2.amazonaws.com

    • opsworks-instance-service.ap-southeast-1.amazonaws.com

    • opsworks-instance-service.ap-southeast-2.amazonaws.com

    • opsworks-instance-service.ca-central-1.amazonaws.com

    • opsworks-instance-service.eu-central-1.amazonaws.com

    • opsworks-instance-service.eu-west-1.amazonaws.com

    • opsworks-instance-service.eu-west-2.amazonaws.com

    • opsworks-instance-service.eu-west-3.amazonaws.com

  • Amazon S3

  • Tous les référentiels de package dont votre système d'exploitation dépend, tels que les référentiels Amazon Linux ou Ubuntu Linux.

  • Vos référentiels d'applications et de livres de recettes personnalisés.

Il existe différentes façons de configurer un VPC pour assurer cette connectivité. Voici un exemple simple de configuration d'un VPC pour une pile de serveurs d'applications AWS OpsWorks Stacks.

VPC diagram showing public and private subnets, NAT, load balancing, and connections to external services.

Ce VPC a plusieurs composants :

Sous-réseaux

Le VPC a deux sous-réseaux, l'un public et l'autre privé.

  • Le sous-réseau public contient un équilibreur de charge et un périphérique de traduction d'adresses réseau (NAT), qui peuvent communiquer avec des adresses externes et les instances du sous-réseau privé.

  • Le sous-réseau privé contient les serveurs d'applications, qui peuvent communiquer avec le périphérique NAT et l'équilibreur de charge du sous-réseau public, mais pas directement avec les adresses externes.

Passerelle Internet

La passerelle Internet permet aux instances ayant des adresses IP publiques, telles que l'équilibreur de charge, de communiquer avec des adresses externes au VPC.

Équilibreur de charge

L'équilibreur de charge Elastic Load Balancing accepte le trafic entrant des utilisateurs, le distribue aux serveurs d'applications du sous-réseau privé et retourne les réponses aux utilisateurs.

NAT

Le périphérique NAT fournit aux serveurs d'applications un accès limité à Internet, généralement utilisé à des fins telles que le téléchargement de mises à jour logicielles à partir d'un référentiel externe. Toutes les instances de AWS OpsWorks Stacks doivent être capables de communiquer avec AWS OpsWorks Stacks et avec les référentiels Linux appropriés. Le seul moyen de gérer ce problème consiste à placer un périphérique NAT avec une adresse IP Elastic associée dans un sous-réseau public. Vous pouvez alors acheminer le trafic sortant à partir des instances du sous-réseau privé via le périphérique NAT.

Note

Une seule instance NAT crée un point de défaillance unique dans le trafic sortant de votre sous-réseau privé. Vous pouvez améliorer la fiabilité en configurant un VPC avec une paire d'instances NAT qui prennent le relais en cas de défaillance de l'une d'entre elles. Pour plus d'informations, consultez Solution haute disponibilité des instances NAT sur Amazon VPC. Vous pouvez également utiliser une passerelle NAT. Pour plus d'informations, consultez la section NAT dans le guide de l'utilisateur Amazon VPC.

La configuration VPC optimale dépend de votre stack AWS OpsWorks Stacks. Voici quelques exemples où vous pourriez utiliser certaines configurations de VPC. Pour obtenir des exemples de scénarios VPC, consultez Scénarios d'utilisation d'Amazon VPC.

Utilisation d'une instance dans un sous-réseau public

Si vous disposez d'une pile à instance unique sans ressources privées associées, telle qu'une instance Amazon RDS qui ne doit pas être accessible au public, vous pouvez créer un VPC avec un sous-réseau public et placer l'instance dans ce sous-réseau. Si vous n'utilisez pas de VPC par défaut, la couche de l'instance doit assigner une adresse IP Elastic à l'instance. Pour de plus amples informations, veuillez consulter OpsWorks Principes de base des couches.

Utilisation des ressources privées

Si vous avez des ressources qui ne doivent pas être accessibles publiquement, vous pouvez créer un VPC avec un sous-réseau public et un sous-réseau privé. Par exemple, dans un environnement de dimensionnement automatique à équilibrage de charge, vous pouvez placer toutes les EC2 instances Amazon dans le sous-réseau privé et l'équilibreur de charge dans un sous-réseau public. Ainsi, les EC2 instances Amazon ne sont pas directement accessibles depuis Internet ; tout le trafic entrant doit être acheminé via l'équilibreur de charge.

Le sous-réseau privé isole les instances de l'accès EC2 direct des utilisateurs à Amazon, mais elles doivent tout de même envoyer des demandes sortantes à AWS et aux référentiels de packages Linux appropriés. Pour autoriser de telles demandes, vous pouvez, par exemple, utiliser un périphérique de traduction d'adresses réseau (NAT) avec sa propre adresse IP Elastic, puis acheminer le trafic sortant des instances via ce périphérique. Vous pouvez placer le périphérique NAT dans le même sous-réseau public que l'équilibreur de charge, comme illustré dans l'exemple précédent.

  • Si vous utilisez une base de données principale telle qu'une instance Amazon RDS, vous pouvez placer ces instances dans le sous-réseau privé. Pour les instances Amazon RDS, vous devez spécifier au moins deux sous-réseaux différents dans des zones de disponibilité différentes.

  • Si vous avez besoin d'un accès direct aux instances d'un sous-réseau privé (par exemple, si vous souhaitez utiliser SSH pour vous connecter à une instance), vous pouvez placer un hôte bastion dans le sous-réseau public qui transmet par proxy les demandes provenant d'Internet.

Extension de votre propre réseau dans AWS

Si vous souhaitez étendre votre propre réseau dans le cloud et accéder aussi directement à Internet depuis votre VPC, vous pouvez créer une passerelle VPN. Pour plus d'informations, consultez Scénario 3 : VPC avec sous-réseaux privés et publics, et accès VPN matériel.

Création d'un VPC pour un AWS OpsWorks Stacks Stacks

Cette section explique comment créer un VPC pour une pile AWS OpsWorks Stacks à l'aide d'un exemple de modèle AWS. CloudFormation Vous pouvez télécharger le modèle dans le fichier OpsWorks VPCtemplates .zip. Pour plus d'informations sur la création manuelle d'un VPC comme celui présenté dans cette rubrique, consultez Scénario 2 : VPC avec sous-réseaux publics et privés. Pour plus d'informations sur la configuration des tables de routage, des groupes de sécurité, etc., consultez l'exemple de modèle.

Note

Par défaut, AWS OpsWorks Stacks affiche les noms de sous-réseaux en concaténant leur plage d'adresses CIDR et leur zone de disponibilité, par exemple. 10.0.0.1/24 - us-east-1b Pour rendre les noms plus lisibles, créez une balise pour chaque sous-réseau avec la clé définie sur Name et la valeur définie sur le nom du sous-réseau. AWS OpsWorks Stacks ajoute ensuite le nom du sous-réseau au nom par défaut. Par exemple, le sous-réseau privé de l'exemple suivant possède une balise dont le nom est défini surPrivate, qui s' OpsWorks affiche sous 10.0.0.1/24 us-east - 1b - Private la forme.

Vous pouvez lancer un modèle VPC à l'aide de la AWS CloudFormation console en quelques étapes seulement. La procédure suivante utilise l'exemple de modèle pour créer un VPC dans la région USA Est (Virginie du Nord). Pour obtenir les instructions sur l'utilisation du modèle pour créer un VPC dans d'autres régions, consultez la Remarque qui suit la procédure.

Pour créer le VPC
  1. Ouvrez la console AWS CloudFormation, sélectionnez la région USA Est (Virginie du Nord), puis choisissez Créer une pile.

  2. Sur la page Select Template (Sélectionner un modèle), sélectionnez Upload a template (Télécharger un modèle). Recherchez le OpsWorksinVPC.template fichier que vous avez téléchargé dans le fichier OpsWorks VPCtemplates .zip. Choisissez Continuer.

    CloudFormation Sélectionnez la page du modèle

    Vous pouvez également lancer cette pile en ouvrant AWS CloudFormation Sample Templates, en localisant le modèle VPC AWS OpsWorks Stacks et en choisissant Launch Stack.

  3. Sur la page Spécifier les paramètres, acceptez les valeurs par défaut et choisissez Continuer.

  4. Sur la page Ajouter une balise, créez une balise avec Clé défini sur Name et Valeur défini sur le nom du VPC. Cette balise facilitera l'identification de votre VPC lorsque vous créez une pile AWS OpsWorks Stacks.

  5. Choisissez Continuer, puis Fermer pour lancer la pile.

Remarque : Vous pouvez créer le VPC dans d'autres régions en utilisant l'une des approches suivantes.

  • Accédez à Utilisation de modèles dans différentes régions, choisissez la région appropriée, recherchez le modèle VPC AWS OpsWorks Stacks, puis choisissez Launch Stack.

  • Copiez le fichier modèle sur votre système, sélectionnez la région appropriée dans la AWS CloudFormation console et utilisez l'option Upload a template to Amazon S3 de l'assistant Create Stack pour télécharger le modèle depuis votre système.

L'exemple de modèle inclut des sorties qui fournissent le VPC, le sous-réseau et l'équilibreur de charge IDs dont vous aurez besoin pour créer la pile Stacks. AWS OpsWorks Vous pouvez les voir en choisissant l'onglet Sorties en bas de la fenêtre de AWS CloudFormation console.

Stack outputs table showing VPC, subnet, and load balancer IDs for an OpsWorks-in-VPC stack.

Rubrique suivante :

Mise à jour d'une pile

Rubrique précédente :

Créer une pile
ConfidentialitéConditions d'utilisation du sitePréférences de cookies
© 2025, Amazon Web Services, Inc. ou ses affiliés. Tous droits réservés.