Exigences relatives aux tables de routage pour les pièces jointes VPC Cycle de vie des attachements VPC Mode Appliance Référencement des groupes de sécurité Prise en charge d’IPv6

Pièces jointes Amazon VPC dans AWS Passerelle de transit

Une pièce jointe Amazon Virtual Private Cloud (VPC) à une passerelle de transit vous permet d'acheminer le trafic vers et depuis 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 passerelle de transit. Le trafic ne peut atteindre les ressources des autres sous-réseaux de la même zone de disponibilité que si les sous-réseaux rattaché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é comportant des pièces jointes à une 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 les 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 des noms pour les zones hébergées privées pour tous les VPC connectés à une passerelle de transit, consultez la section 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 dotés de CIDR identiques, ou si un CIDR d'une plage chevauche un CIDR d'un VPC rattaché. 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 attaché 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 aux tables de routage pour les pièces jointes VPC

Les pièces jointes VPC de la passerelle de transit nécessitent des configurations de table de routage spécifiques pour fonctionner correctement :

Tables de routage du sous-réseau de pièces jointes : les sous-réseaux associés à la passerelle de transit doivent comporter 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 routes vers d'autres sous-réseaux, les passerelles Internet, les passerelles NAT et les 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 à une passerelle de transit n'active pas automatiquement la communication entre les sous-réseaux au sein d'un même VPC. Les règles de routage VPC standard s'appliquent, et la route locale (VPC CIDR) doit être présente dans les tables de routage pour les communications intra-VPC.

Note

Le fait que des itinéraires soient configurés dans des sous-réseaux sans rattachement au sein de la même zone de disponibilité n'active pas le flux de 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 available a é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.

Cross-account Cycle de vie des pièces jointes VPC pour lequel l'acceptation automatique des pièces jointes partagées est désactivée

Pending-acceptance: La demande de pièce jointe 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 acceptance a é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 available ou pending acceptance a é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 cet attachement VPC pendant toute la durée de vie du flux de trafic entre une source et une destination. Cela permet également à une passerelle de transit d'envoyer du trafic vers n'importe quelle zone de disponibilité du VPC, à condition 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 connexion 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 préalables au AZ-aware routage : la propagation des itinéraires 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 à la sélection de zones de disponibilité basée sur le hachage de flux. Cela signifie que le trafic au sein d'une même zone de disponibilité peut être acheminé vers une autre zone de disponibilité dans le VPC de l'appliance, rompant ainsi l'isolation de la zone de disponibilité.

Le mode appliance dans 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 à travers un VPC en mode appliance. Cette approche améliore l'efficacité et réduit le temps de latence. Le comportement varie en fonction de la configuration spécifique et des modèles de trafic.

Les scénarios suivants supposent que la propagation des itinéraires 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 une sélection de zone de disponibilité basée sur le hachage de 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 à la fois dans us-east-1a et us-east-1b, Transit Gateway sélectionne une interface réseau parmi us-east-1a au sein du 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 vers 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 de l'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, 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 parmi 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 entre les VPC attaché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 pour les pièces jointes VPC des passerelles 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 limitations 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 points de PrivateLink terminaison. 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é autorisant toutes les sorties est configurée pour les interfaces EFS du VPC.
Pour la connectivité aux zones locales via une passerelle de transit, seules les zones locales suivantes sont prises en charge : us-east-1-atl-2a, us-east-1-iah-2a, us-west-2-lax-1a, us-west-2-lax-1b, us-east-1-mia-2a, us-east-1-chi-2a et us-west-2-phx-2a.
Nous recommandons de désactiver cette fonctionnalité au niveau de l'attachement aux VPC pour les VPC dotés de sous-réseaux situés dans des zones Local, AWS Outposts et AWS Wavelength Zones non pris en charge, car cela pourrait entraîner une interruption de service.
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 Gateway AWS Load Balancer ou sur un Network Firewall. AWS

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 :

Affecte 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 vers la table de routage de la passerelle de transit lorsque la propagation des itinéraires est configurée.

Lorsque vous désactivez le support IPv6, les comportements suivants s'appliquent toujours :

Vous pouvez toujours créer des itinéraires 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 possède 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 routes ; il ne filtre pas les paquets.

Tâches

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Support de chiffrement

Création d'une pièce jointe VPC