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.
Pièces jointes Amazon VPC dans AWS Passerelle de transit
Un attachement Amazon Virtual Private Cloud (VPC) à une passerelle de transit vous permet d'acheminer le trafic depuis et vers un ou plusieurs sous-réseaux VPC. Lorsque vous attachez un VPC à une passerelle de transit, vous devez spécifier un sous-réseau depuis chaque zone de disponibilité que la passerelle de transit va utiliser pour acheminer le trafic. Les sous-réseaux spécifiés servent de points d'entrée et de sortie pour le trafic de la passerelle de transit. Le trafic ne peut atteindre les ressources d'autres sous-réseaux de la même zone de disponibilité que si les sous-réseaux attachés à la passerelle de transit ont des itinéraires appropriés configurés dans leurs tables de routage pointant vers les sous-réseaux cibles.
Restrictions
-
Lorsque vous attachez un VPC à une passerelle de transit, les ressources des zones de disponibilité où il n'existe pas d'attachement de passerelle de transit ne peuvent pas atteindre celle-ci.
Note
Dans les zones de disponibilité qui comportent des pièces jointes de passerelle de transit, le trafic est uniquement transféré vers la passerelle de transit à partir des sous-réseaux spécifiques associés à la pièce jointe. S'il existe un itinéraire vers la passerelle de transit dans une table de routage de sous-réseau, le trafic est transféré vers la passerelle de transit uniquement lorsque la passerelle de transit possède une pièce jointe dans un sous-réseau de la même zone de disponibilité et que la table de routage du sous-réseau de pièces jointes contient des itinéraires appropriés vers la destination prévue du trafic au sein du VPC.
-
Une passerelle de transit n'est pas compatible avec la résolution DNS des noms DNS personnalisés lors de la configurations de VPC attachés à l'aide de zones hébergées privées dans Amazon Route 53. Pour configurer la résolution de noms pour les zones hébergées privées pour tous les VPC connectés à une passerelle de transit, consultez Gestion DNS centralisée du cloud hybride avec Amazon Route 53 et AWS Transit Gateway
. -
Une passerelle de transit ne prend pas en charge le routage entre des VPC ayant des CIDR identiques, ou si un CIDR d'une plage chevauche un CIDR d'un VPC attaché. Si vous attachez un VPC à une passerelle de transit et que son CIDR est identique ou chevauche le CIDR d'un autre VPC déjà attaché à la passerelle de transit, les itinéraires du VPC nouvellement connecté ne sont pas propagés vers la table de routage de la passerelle de transit.
-
Vous ne pouvez pas créer de pièce jointe pour un sous-réseau de VPC résidant dans une zone locale. Toutefois, vous pouvez configurer votre réseau de sorte que les sous-réseaux de la zone locale puissent se connecter à une passerelle de transit via la zone de disponibilité parente. Pour plus d'informations, consultez Connexion des sous-réseaux de la zone locale à une passerelle de transit.
-
Vous ne pouvez pas créer de pièce jointe à une passerelle de transit à l'aide de IPv6-only sous-réseaux. Les sous-réseaux d'attachement de la passerelle de transit doivent également prendre en charge les adresses IPv4.
-
Une passerelle de transit doit avoir au moins un attachement VPC avant de pouvoir être ajoutée à une table de routage.
Exigences relatives à la table de routage pour les pièces jointes VPC
Les pièces jointes VPC de passerelle de transit nécessitent des configurations de table de routage spécifiques pour fonctionner correctement :
-
Tables de routage des sous-réseaux des pièces jointes : les sous-réseaux associés à la pièce jointe de la passerelle de transit doivent contenir des entrées de table de routage pour toutes les destinations du VPC qui doivent être accessibles via la passerelle de transit. Cela inclut les itinéraires vers d'autres sous-réseaux, des passerelles Internet, des passerelles NAT et des points de terminaison VPC.
-
Tables de routage des sous-réseaux cibles : les sous-réseaux contenant des ressources qui doivent communiquer via la passerelle de transit doivent avoir des itinéraires pointant vers la passerelle de transit pour le trafic de retour vers des destinations externes.
-
Trafic VPC local : l'attachement à la passerelle de transit n'active pas automatiquement la communication entre les sous-réseaux d'un même VPC. Les règles de routage VPC standard s'appliquent et la route locale (CIDR VPC) doit être présente dans les tables de routage pour les communications intra-VPC.
Note
Le fait d'avoir des itinéraires configurés dans des sous-réseaux sans pièces jointes au sein de la même zone de disponibilité ne permet pas de fluidifier le trafic. Seuls les sous-réseaux spécifiques associés à l'attachement de la passerelle de transit peuvent servir de entry/exit points pour le trafic de la passerelle de transit.
Cycle de vie des attachements VPC
Un attachement VPC passe par différentes étapes, à partir du lancement de la demande. Vous pouvez être amené à effectuer des actions à chaque étape. À la fin de son cycle de vie, l'attachement du VPC reste visible dans la Amazon Virtual Private Cloud Console et dans l'API ou la sortie de la ligne de commande, pendant une période déterminée.
Le diagramme suivant montre les états par lesquels qu'un attachement peut passer dans une configuration de compte unique ou une configuration inter-comptes pour laquelle l' acceptation automatique des attachements partagés est activée.
-
En attente : une demande d'attachement VPC a été lancée et est en processus de mise en service. À ce stade, l'attachement peut échouer, ou peut aller à
available. -
Échec : une demande d'attachement VPC échoue. À ce stade, l'attachement VPC va à
failed. -
Échec : la demande de l'attachement VPC a échoué. Dans cet état, il ne peut pas être supprimé. L'attachement VPC défaillant reste visible pendant 2 heures, puis n'est plus visible.
-
Disponible : l'attachement VPC est disponible et le trafic peut circuler entre le VPC et la passerelle de transit. A ce stade, l'attachement peut aller à
modifying, ou aller àdeleting. -
Suppression : attachement VPC en cours de suppression. A ce stade, l'attachement peut aller à
deleted. -
Supprimé : un attachement VPC
availablea été supprimé. Dans cet état, l'attachement VPC ne peut pas être modifié. L'attachement VPC reste visible pendant 2 heures, puis n'est plus visible. -
Modification : une demande a été faite pour modifier les propriétés de l'attachement VPC. A ce stade, l'attachement peut aller à
available, ou aller àrolling back. -
Retour arrière : la demande de modification de l'attachement VPC ne peut pas être complétée et le système annule toutes les modifications qui ont été apportées. A ce stade, l'attachement peut aller à
available.
Le diagramme suivant montre les états par lesquels qu'un attachement peut passer dans une configuration inter-comptes pour laquelle l' acceptation automatique des attachements partagés est désactivée.
-
Pending-acceptance: La demande de pièce jointe du VPC est en attente d'acceptation. À ce stade, l'attachement peut aller à
pending,àrejecting, ou àdeleting. -
Rejet : attachement VPC en train d'être rejeté. A ce stade, l'attachement peut aller à
rejected. -
Rejeté : un attachement VPC
pending acceptancea été rejeté. Dans cet état, l'attachement VPC ne peut pas être modifié. L'attachement VPC reste visible pendant 2 heures, puis n'est plus visible. -
En attente : la demande d'attachement VPC a été acceptée et est en processus de mise en service. À ce stade, l'attachement peut échouer, ou peut aller à
available. -
Échec : une demande d'attachement VPC échoue. À ce stade, l'attachement VPC va à
failed. -
Échec : la demande de l'attachement VPC a échoué. Dans cet état, il ne peut pas être supprimé. L'attachement VPC défaillant reste visible pendant 2 heures, puis n'est plus visible.
-
Disponible : l'attachement VPC est disponible et le trafic peut circuler entre le VPC et la passerelle de transit. A ce stade, l'attachement peut aller à
modifying, ou aller àdeleting. -
Suppression : attachement VPC en cours de suppression. A ce stade, l'attachement peut aller à
deleted. -
Supprimé : un attachement VPC
availableoupending acceptancea été supprimé. Dans cet état, l'attachement VPC ne peut pas être modifié. L'attachement VPC reste visible 2 heures, puis n'est plus visible. -
Modification : une demande a été faite pour modifier les propriétés de l'attachement VPC. A ce stade, l'attachement peut aller à
available, ou aller àrolling back. -
Retour arrière : la demande de modification de l'attachement VPC ne peut pas être complétée et le système annule toutes les modifications qui ont été apportées. A ce stade, l'attachement peut aller à
available.
Mode Appliance
Si vous envisagez de configurer une appliance réseau dynamique dans votre VPC, vous pouvez activer la prise en charge du mode appliance pour la pièce jointe VPC dans laquelle se trouve l'appliance lorsque vous créez une pièce jointe. Cela garantit que AWS Transit Gateway utilise la même zone de disponibilité pour cette pièce jointe VPC pendant toute la durée de vie du flux de trafic entre une source et une destination. Il permet également à une passerelle de transit d'envoyer du trafic vers n'importe quelle zone de disponibilité du VPC tant qu'il existe une association de sous-réseau dans cette zone. Bien que le mode appliance ne soit pris en charge que sur les pièces jointes VPC, le flux réseau peut provenir de tout autre type de pièce jointe de passerelle de transit, y compris les pièces jointes VPC, VPN et Connect. Le mode appliance fonctionne également pour les flux réseau dont les sources et les destinations sont différentes Régions AWS. Les flux réseau peuvent potentiellement être rééquilibrés entre différentes zones de disponibilité si vous n'activez pas initialement le mode appliance, mais que vous modifiez ultérieurement la configuration des pièces jointes pour l'activer. Vous pouvez activer ou désactiver le mode appliance à l'aide de la console, de la ligne de commande ou de l'API.
Important
Le mode Appliance n'est pris en charge que pour les pièces jointes VPC.
Conditions requises pour le AZ-aware routage : la propagation du routage doit être activée pour la table de routage de la passerelle de transit associée à l'attachement VPC en mode appliance. Sans propagation, la passerelle de transit ne peut pas déterminer les zones de disponibilité source et de destination. Tout le trafic, y compris les mêmes Availability-Zone flux décrits dans le scénario 1, revient à une sélection de zone de disponibilité basée sur le hachage des flux. Cela signifie que le trafic au sein d'une même zone de disponibilité peut être acheminé vers une autre zone de disponibilité du VPC de l'appliance, rompant ainsi l'isolation de la zone de disponibilité.
Le mode appliance de AWS Transit Gateway optimise le routage du trafic en tenant compte des zones de disponibilité source et de destination lors de la détermination du chemin via un VPC en mode appliance. Cette approche améliore l'efficacité et réduit la latence. Le comportement varie en fonction de la configuration et des modèles de trafic spécifiques.
Les scénarios suivants supposent que la propagation de route est activée pour la table de routage de la passerelle de transit associée à l'attachement VPC en mode appliance. Sans propagation, la passerelle de transit ne peut pas déterminer les zones de disponibilité source et de destination, et tous les scénarios utilisent par défaut la sélection des zones de disponibilité basée sur le hachage des flux (comportement décrit dans le scénario 2).
Scénario 1 : routage du trafic de Intra-Availability zone via le VPC de l'appliance
Lorsque le trafic circule de la zone de disponibilité source us-east-1a vers la zone de disponibilité de destination us-east-1a, avec des pièces jointes VPC en mode appliance dans us-east-1a et us-east-1b, Transit Gateway sélectionne une interface réseau depuis us-east-1a dans le VPC de l'appliance. Cette zone de disponibilité est maintenue pendant toute la durée du flux de trafic entre la source et la destination.
Scénario 2 : routage du trafic de Inter-Availability zone via le VPC de l'appliance
Pour le trafic circulant de la zone de disponibilité source us-east-1a à la zone de disponibilité de destination us-east-1b, avec des pièces jointes VPC en mode appliance dans us-east-1a et us-east-1b, Transit Gateway utilise un algorithme de hachage de flux pour sélectionner us-east-1a ou us-east-1b dans le VPC de l'appliance. La zone de disponibilité choisie est utilisée de manière cohérente pendant toute la durée de vie du flux.
Scénario 3 : routage du trafic via un VPC d'appliance sans données de zone de disponibilité
Lorsque le trafic provient de la zone de disponibilité source us-east-1a vers une destination sans informations de zone de disponibilité (par exemple, le trafic lié à Internet), avec des pièces jointes VPC en mode appliance dans us-east-1a et us-east-1b, Transit Gateway sélectionne une interface réseau depuis us-east-1a au sein du VPC de l'appliance.
Scénario 4 : routage du trafic via un VPC d'appliance dans une zone de disponibilité distincte de la source ou de la destination
Lorsque le trafic circule de la zone de disponibilité source us-east-1a vers la zone de disponibilité de destination us-east-1b, avec des pièces jointes VPC en mode appliance dans différentes zones de disponibilité, par exemple us-east-1c et us-east-1d, Transit Gateway utilise un algorithme de hachage de flux pour sélectionner us-east-1c ou us-east-1d dans le VPC de l'appliance. La zone de disponibilité choisie est utilisée de manière cohérente pendant toute la durée de vie du flux.
Référencement des groupes de sécurité
Vous pouvez utiliser cette fonctionnalité pour simplifier la gestion des groupes de sécurité et le contrôle du trafic d'instance à instance sur les VPC connectés à la même passerelle de transit. Vous ne pouvez faire référence à des groupes de sécurité que dans les règles entrantes. Les règles de sécurité sortantes ne prennent pas en charge le référencement des groupes de sécurité. Aucun coût supplémentaire n'est associé à l'activation ou à l'utilisation du référencement des groupes de sécurité.
La prise en charge du référencement des groupes de sécurité peut être configurée à la fois pour les passerelles de transit et les pièces jointes VPC de passerelle de transit et ne fonctionnera que si elle a été activée à la fois pour une passerelle de transit et ses pièces jointes VPC.
Limitations
Les limites suivantes s'appliquent lors de l'utilisation du référencement de groupes de sécurité avec une pièce jointe VPC.
Le référencement des groupes de sécurité n'est pas pris en charge sur les connexions d'appairage des passerelles de transit. Les deux VPC doivent être connectés à la même passerelle de transit.
Le référencement des groupes de sécurité n'est pas pris en charge pour les pièces jointes VPC dans la zone de disponibilité use1-az3.
Le référencement des groupes de sécurité n'est pas pris en charge pour les PrivateLink terminaux. Nous vous recommandons d'utiliser les règles CIDR-based de sécurité IP comme alternative.
Le référencement des groupes de sécurité fonctionne pour Elastic File System (EFS) tant qu'une règle de groupe de sécurité Autoriser toutes les sorties est configurée pour les interfaces EFS du VPC.
AWS Les avant-postes, les zones de AWS longueur d'onde et certaines zones AWS locales ne prennent pas en charge le référencement des groupes de sécurité. Pour éviter toute interruption de service, désactivez le référencement des groupes de sécurité au niveau de l'attachement des VPC pour les VPC dotés de sous-réseaux à ces emplacements.
Non pris en charge AWS Local Zones
Les zones AWS locales suivantes ne prennent pas en charge cette fonctionnalité :
us-east-1-bos-1aus-east-1-bue-1aus-east-1-lim-1aus-east-1-mci-1aus-east-1-msp-1aus-east-1-phl-1a,us-east-1-scl-1a,us-west-2-den-1aus-west-2-hnl-1a,us-west-2-las-1a,us-west-2-sea-1a,ap-south-1-ccu-1a,ap-south-1-del-1aap-southeast-1-mnl-1a,ap-southeast-2-per-1a,eu-north-1-cph-1a,eu-north-1-hel-1a,eu-central-1-ham-1aeu-central-1-waw-1a,af-south-1-los-1a,,me-south-1-mct-1a-
Si vous disposez d'un VPC d'inspection, le référencement des groupes de sécurité via la passerelle de transit ne fonctionne pas sur AWS Gateway Load Balancer ou sur un AWS pare-feu réseau.
Prise en charge d’IPv6
Lorsque vous créez ou modifiez une pièce jointe VPC, vous pouvez activer ou désactiver le support IPv6. La valeur par défaut est disable.
L'activation du support IPv6 permet d'effectuer les opérations suivantes :
-
Assigne une adresse IPv6 à l'interface réseau de la passerelle de transit dans le sous-réseau de pièces jointes. La passerelle de transit utilise cette adresse pour envoyer et recevoir du trafic IPv6 via la pièce jointe.
-
Propage les CIDR VPC IPv6 à la table de routage de la passerelle de transit lorsque la propagation de route est configurée.
Lorsque vous désactivez la prise en charge d'IPv6, les comportements suivants s'appliquent toujours :
-
Vous pouvez toujours créer des routes IPv6 statiques qui ciblent la pièce jointe.
-
Le trafic IPv6 peut toujours entrer dans la passerelle de transit depuis le VPC si la table de routage du VPC comporte une route IPv6 qui pointe vers la passerelle de transit et si les ACL réseau et les groupes de sécurité autorisent le trafic.
Ce paramètre contrôle uniquement l'adressage de l'interface réseau et la propagation des itinéraires ; il ne filtre pas les paquets.
Tâches
