FAQ sur Amazon VPC

Il n'y a pas de frais supplémentaires pour la création et l'utilisation du VPC lui-même. Les frais d'utilisation pour d'autres solutions Amazon Web Services, y compris Amazon EC2, s'appliquent selon les tarifs en vigueur pour ces ressources, notamment pour les frais de transfert de données. Si vous connectez votre VPC au datacenter de votre entreprise en utilisant la connexion VPN matérielle facultative, le tarif est calculé par heure de connexion VPN consommée (la durée pendant laquelle l'état de votre connexion VPN indique qu'elle est disponible). Les heures partiellement consommées seront facturées comme des heures entières. Les données transférées au-delà des connexions VPN seront facturées aux taux standard de transfert de données AWS. Pour obtenir des informations sur la tarification VPC-VPN, consultez la section de tarification de la page produit Amazon VPC.

Les frais d'utilisation pour d'autres Amazon Web Services, y compris Amazon EC2, s'appliquent aux taux publiés pour ces ressources. Les frais de transfert de données ne sont pas facturés au moment de l'accès aux Amazon Web Services, tels que Amazon S3, via votre passerelle Internet de VPC.

Si vous accédez aux ressources AWS via votre connexion VPN, vous encourrez des frais pour vos transferts de données Internet.

Vous pouvez connecter votre Amazon VPC à :

• Internet (via une passerelle Internet) ;
• votre centre de données d’entreprise à partir d'une connexion VPN entre les sites AWS (via la passerelle réseau privé virtuel) ;
• Internet et à votre centre de données d’entreprise (en utilisant à la fois une passerelle Internet et une passerelle réseau privé virtuel) ;
• d'autres services AWS (via une passerelle Internet, une NAT, une passerelle privée virtuelle ou des points de terminaison de VPC) ;
• d'autres Amazon VPC (via des connexions d'appairage entre VPC).

Amazon VPC prend en charge la création d'une passerelle Internet. Cette passerelle active les instances Amazon EC2 dans le VPC pour accéder directement à Internet. Vous pouvez aussi utiliser une passerelle Internet de sortie uniquement qui est une passerelle avec état qui fournit un accès sortant uniquement pour le trafic IPv6 du VPC vers Internet.

Une passerelle Internet est mise à l'échelle horizontalement, et est redondante et hautement disponible. Elle n'impose aucune restriction en matière de bande passante.

Vous pouvez utiliser des adresses IP publiques, notamment des adresses IP Elastic (EIP) et des adresses IPv6 Global Unique (GUA) pour permettre aux instances du VPC de communiquer directement vers l'extérieur par Internet et de recevoir un trafic entrant non sollicité à partir d'Internet (par ex. des serveurs Web). Vous pouvez également utiliser les solutions citées dans la réponse à la prochaine question.

Toute adresse IP attribuée à une instance ou à un service hébergé dans un VPC accessible via Internet est considérée comme une adresse IP publique. Seules les adresses IPv4 publiques, y compris les adresses IP Elastic (EIP) et IPv6 GUA peuvent être routables sur Internet. Pour ce faire, vous devez d'abord connecter le VPC à Internet, puis mettre à jour la table de routage pour les rendre accessibles depuis/vers Internet.

Les instances sans adresse IP publique peuvent accéder à Internet de deux façons :

1. Les instances sans adresse IP publique peuvent acheminer leur trafic via une passerelle NAT ou une instance NAT pour accéder à Internet. Ces instances utilisent l'adresse IP publique de la passerelle ou instance NAT pour traverser Internet. La passerelle ou instance NAT permet une communication sortante, mais n'autorise pas les machines sur Internet à initier une connexion vers des instances à adresse privée.
2. Pour les VPC équipés d'une connexion VPN hardware ou d'une connexion Direct Connect, les instances peuvent acheminer leur trafic Internet jusqu'à votre centre de données, via la passerelle privée virtuelle. A partir de là, il est possible d'accéder à Internet via vos points de sortie existants et les périphériques de surveillance/sécurité du réseau.

Oui. Vous pouvez utiliser un logiciel VPN tiers pour créer une connexion VPN site à site ou d'accès distant avec votre VPC via l'Internet gateway.

Non. Lorsque vous utilisez des adresses IP publiques, toutes les communications entre les instances et les services hébergés sur AWS utilisent le réseau privé d'AWS. Les paquets qui proviennent du réseau AWS et dont la destination se trouve sur le réseau AWS restent sur le réseau mondial d'AWS, à l'exception du trafic à destination ou en provenance des régions AWS en Chine.

De plus, toutes les données circulant sur le réseau mondial AWS qui interconnectent nos centres de données et nos régions sont chiffrées automatiquement au niveau de la couche physique avant de quitter nos installations sécurisées. Des couches de chiffrement supplémentaires existent également : par exemple, pour tout le trafic de l'appairage de VPC entre régions et les connexions Transport Layer Security (TLS) client ou de service à service. 

Une connexion VPN entre sites AWS connecte votre VPC à votre centre de données. Amazon prend en charge les connexions VPN utilisant l'Internet Protocol Security (IPsec). Les données transférées entre votre VPC et votre centre de données empruntent une connexion VPN chiffrée pour maintenir la confidentialité et l'intégrité des données en transit. Aucune passerelle Internet n’est requise pour établir une connexion VPN entre sites AWS.

Vous pouvez utiliser n'importe quelle plage d'adresses IPv4, dont RFC 1918 ou des plages d'adresses IP publiquement routables pour le bloc d'adresse CIDR primaire. Pour les blocs d'adresse CIDR secondaires, certaines restrictions s'appliquent. Les blocs IP pouvant être acheminés publiquement ne sont accessibles qu'à partir de la passerelle VPN et ne le sont pas sur Internet, par le biais de la passerelle Internet. AWS n'annonce pas les blocs d'adresses IP des clients sur Internet. Vous pouvez allouer jusqu'à 5 blocs d'adresse CIDR d'adresse unique globale IPv6 fournis par Amazon ou BYOIP à un VPC en appelant l'API correspondante ou par le biais de la console de gestion AWS.

Lorsque vous créez un VPC, vous attribuez une seule plage d'adresses IP Classless Internet Domain Routing (CIDR) comme bloc d'adresse CIDR primaire et vous pouvez ajouter jusqu'à quatre (4) blocs CIDR secondaires une fois le VPC créé. Vous adressez les sous-réseaux au sein d'un VPC depuis ces plages CIDR. Même si vous pouvez créer plusieurs VPC avec des chevauchements de plages d'adresses IP, le faire ne vous permettra pas de connecter ces VPC à un réseau de base commun par le biais de la connexion VPN matérielle. C'est pourquoi nous recommandons d'utiliser des plages d'adresses IP non superposées. Vous pouvez allouer jusqu'à 5 blocs d'adresse CIDR IPv6 fournis par Amazon ou BYOIP à votre VPC.

La plage CIDR 172.31.0.0/16 est affectée aux VPC par défaut. Les sous-réseaux par défaut au sein d'un VPC par défaut se voient affectés les netblocks /20 au sein de la plage CIDR du VPC. 

Oui, vous pouvez transférer vos adresses IPv4 publiques et vos adresses IPv6 GUA dans AWS VPC et les allouer de manière statique aux sous-réseaux et aux instances EC2. Pour accéder à ces adresses via Internet, vous devrez les publier sur Internet à partir de votre réseau local. Vous devrez également acheminer le trafic sur ces adresses entre votre VPC et votre réseau local à l'aide d'une connexion AWS DX ou AWS VPN. Vous pouvez acheminer le trafic depuis votre VPC à l'aide de la passerelle privée virtuelle. De même, vous pouvez acheminer le trafic de votre réseau local vers votre VPC à l'aide de vos routeurs.

Actuellement, Amazon VPC prend en charge cinq (5) plages d'adresses IP, une (1) primaire et quatre (4) secondaires pour IPv4. Chacune de ces plages peut présenter une taille comprise entre /28 (en rotation CIDR) et /16. Les plages d'adresses IP de votre VPC ne doivent pas se superposer aux plages d'adresses IP de votre réseau existant.

Pour IPv6, le VPC a une taille fixe de /56 (en notation CIDR). Les blocs IPv4 et IPv6 peuvent être tous les deux associés à un VPC.

Oui. Vous pouvez étendre votre VPC existant en y ajoutant quatre (4) plages d'adresses IPv4 secondaires (CIDR). Vous pouvez réduire votre VPC en supprimant les blocs d'adresse CIDR secondaires que vous avez ajoutés à votre VPC.   De même, vous pouvez ajouter jusqu'à cinq (5) plages IPv6 supplémentaires (CIDR) à votre VPC.  Vous pouvez réduire votre VPC en supprimant ces plages supplémentaires.

À l'heure actuelle, vous pouvez créer 200 sous-réseaux par VPC. Si vous souhaitez en créer davantage, soumettez une demande auprès du Centre de support.

La taille minimum d'un sous-réseau est de /28 (ou 14 adresses IP) pour IPv4. Les sous-réseaux ne peuvent pas être supérieurs au VPC dans lequel ils sont créés.

Pour IPv6, la taille du sous-réseau est fixée à /64. Seul un bloc IPv6 CIDR peut être alloué à un sous-réseau.

Amazon réserve les quatre (4) premières adresses IP et la dernière (1) adresse IP de chaque sous-réseau pour le réseau IP.

Lorsque vous lancez une instance Amazon EC2 au sein d'un sous-réseau qui n’est pas exclusivement IPv6, vous pouvez, éventuellement, indiquer l'adresse IPv4 privée principale de cette instance. Si vous n'indiquez rien, AWS récupère automatiquement cette adresse à partir de la plage d'adresses IPv4 que vous attribuez à ce sous-réseau. Vous pouvez attribuer des adresses IPv4 privées secondaires lorsque vous lancez une instance, lorsque vous créez une interface réseau Elastic ou à tout moment après le lancement de l'instance ou la création de l'interface. Si vous lancez une instance Amazon EC2 dans un sous-réseau IPv6 uniquement, AWS l'aborde automatiquement à partir du CIDR IPv6 GUA de ce sous-réseau fourni par Amazon. L'IPv6 GUA de l'instance restera privée à moins que vous ne la rendiez accessible depuis/vers Internet avec le groupe de sécurité, la NACL et la configuration de table de routage appropriés.

Pour une instance lancée dans un sous-réseau IPv4 ou à double pile, l'adresse IPv4 privée principale est conservée pendant toute la durée de vie de l'instance ou de l'interface. Les adresses IPv4 privées secondaires peuvent être associées, dissociées ou déplacées entre différentes interfaces ou instances, à tout moment. Pour une instance lancée dans un sous-réseau IPv6 uniquement, l'IPv6 GUA attribuée, qui est également la première adresse IP sur l'interface réseau principale de l'instance, peut être modifiée en associant une nouvelle IPv6 GUA et en supprimant l'IPv6 GUA existante à tout moment.

Une adresse IPv4 attribuée à une instance en cours d'exécution peut être réutilisée par une autre instance seulement lorsque cette instance est dans un état « terminé ». Cependant, l'IPv6 GUA attribuée à une instance en cours d'exécution peut être réutilisée par une autre instance, après avoir été supprimée de la première instance.

Vous pouvez indiquer l'adresse IP d'une instance au moment du lancement de l'instance.

Vous pouvez attribuer n'importe quelle adresse IP à votre instance tant qu'elle :

• figure dans la plage d'adresses IP du sous-réseau associé ;
• n'est pas réservée par Amazon pour un réseau IP ;
• n'est pas actuellement attribuée à une autre interface.

Oui. Vous pouvez attribuer une ou plusieurs adresses IP privées secondaires à une Elastic Network Interface ou à une instance EC2 au sein d'Amazon VPC. Le nombre d'adresses IP privées secondaires que vous pouvez attribuer dépend du type d'instance. Pour en savoir plus sur le nombre d'adresses IP privées secondaires pouvant être attribuées à chaque type d'instance, consultez le Guide de l'utilisateur d'Amazon EC2.

Oui. Néanmoins, ces adresses IP élastiques seront accessibles uniquement à partir d'Internet (et non par le biais de la connexion VPN). Chaque adresse EIP doit être associée à une adresse IP privée unique sur l'instance. Les adresses EIP doivent seulement être utilisées sur des instances dans des sous-réseaux pour acheminer leur trafic directement vers la passerelle Internet. Les EIP ne peuvent pas être utilisées sur des instances dans des sous-réseaux configurés pour l'utilisation d'une passerelle NAT ou une instance NAT afin d'accéder à Internet. Ce n'est applicable que pour IPv4. Les Amazon VPC ne prennent pas en charge les EIP pour IPv6 à l'heure actuelle.

Bring Your Own IP (BYOIP) permet aux clients de déplacer tout ou partie de leur espace d'adresse IPv4 ou IPv6 public existant vers AWS pour l'utiliser avec leurs ressources AWS. Les clients continueront d’être propriétaires de leur plage d’adresses IP. Les clients peuvent créer des adresses IP Elastic à partir de l'espace IPv4 qu'ils apportent à AWS et les utiliser avec des instances EC2, des passerelles NAT et des Network Load Balancer. Les clients peuvent également associer jusqu'à cinq (5) blocs d'adresse CIDR à un VPC à partir de l'espace IPv6 qu'ils apportent à AWS. Les clients continuent d'avoir accès aux adresses IP fournies par Amazon et peuvent choisir d'utiliser des adresses IP Elastic BYOIP, les adresses IP fournies par Amazon, ou les deux.

Vous pouvez apporter vos propres adresses IP à AWS pour les raisons suivantes :
Réputation de l'IP : de nombreux clients considèrent la réputation de leurs adresses IP comme un atout stratégique et veulent les utiliser sur AWS avec leurs ressources. Par exemple, les clients qui maintiennent des services tels que les MTA de courrier électronique sortant et qui ont des IP réputés, peuvent maintenant apporter leur espace IP et maintenir avec succès leur taux de réussite d'envoi existant.

Liste blanche des clients : BYOIP permet également aux clients de déplacer les charges de travail qui dépendent de la liste blanche des adresses IP vers AWS sans avoir besoin de rétablir les listes blanches avec de nouvelles adresses IP.

Dépendances codées en dur : plusieurs clients ont des IP codées en dur dans les appareils ou ont pris des dépendances architecturales sur leurs IP. BYOIP permet à ces clients de migrer sans tracas vers AWS.

Réglementation et conformité : de nombreux clients sont tenus d'utiliser certaines adresses IP pour des raisons de réglementation et de conformité. Elles aussi sont déverrouillées par BYOIP.

Règle de réseau IPv6 sur site : De nombreux clients peuvent acheminer uniquement leur trafic IPv6 sur leur réseau sur site. Grâce à BYOIP, ces clients peuvent désormais attribuer leur plage d’adresses IPv6 à leur VPC et choisir d’acheminer via Internet ou Direct Connect leur trafic vers le réseau sur site.

Lorsque vous diffusez une IP BYOIP élastique, elle retourne dans le groupe d'IP BYOIP à partir duquel elle a été attribuée.

Veuillez consulter notre documentation d' pour plus de détails sur la disponibilité de BYOIP.

Oui. Vous pouvez utiliser le préfixe BYOIP avec n'importe quel nombre de VPC dans le même compte.

Vous pouvez apporter un maximum de cinq plages d'adresses IP à votre compte.

Via BYOIP, le préfixe IPv4 le plus spécifique que vous pouvez apporter est un préfixe /24 IPv4 et un préfixe /56 IPv6. Si vous avez l'intention de faire connaître votre préfixe Ipv6 sur l'internet, le préfixe IPv6 le plus spécifique est /48.

Vous pouvez utiliser les préfixes enregistrés ARIN, RIPE et APNIC.

Nous n'acceptons pas les préfixes réaffectés ou réattribués pour le moment. Les plages IP devraient être de type net d'attribution directe ou d'assignation directe.

Oui. Vous pouvez le faire en désactivant le préfixe BYOIP de la région actuelle et en le mettant ensuite en service dans la nouvelle région.

Amazon VPC IP Address Manager (IPAM) est un service géré qui vous permet de simplifier la planification, le suivi et la surveillance des adresses IP de vos charges de travail AWS. IPAM vous permet d'organiser facilement les adresses IP en fonction de vos besoins de routage et de sécurité et de définir des règles métier simples pour régir l'attribution des adresses IP. Vous pouvez également automatiser l'attribution des adresses IP aux VPC. Ainsi, vous n'avez plus besoin d'utiliser des applications de planification d'adresses IP basées sur des feuilles de calcul ou développées en interne, qui peuvent être difficiles à gérer et chronophages. IPAM fournit une vue opérationnelle unifiée, qui peut être utilisée en tant que source unique de vérité afin d'effectuer plus efficacement et plus rapidement la gestion quotidienne des adresses IP, comme les activités de suivi de l'utilisation des adresses IP, le dépannage et l'audit.

Utilisez IPAM pour rendre la gestion des adresses IP plus efficace. Les mécanismes existants qui exploitent des feuilles de calcul ou des outils développés en interne nécessitent du travail manuel et sont source d'erreurs. Avec IPAM, par exemple, vous pouvez déployer des applications plus rapidement, car vos développeurs n'ont plus besoin d'attendre que l'équipe chargée de l'administration des adresses IP attribue des adresses IP. Vous pouvez également détecter des chevauchements d'adresses IP et les corriger avant qu'une panne réseau ne se produise. De plus, vous pouvez créer des alarmes pour qu'IPAM vous informe dès que des groupes d'adresses sont presque épuisés ou dès que des ressources ne respectent pas les règles d'attribution définies dans un groupe. Il existe bien d'autres raisons pour lesquelles vous devriez utiliser IPAM.

AWS IPAM offre les fonctionnalités suivantes :
 

• Attribution d'adresses IP pour les réseaux à grande échelle : IPAM peut automatiser les attributions d'adresses IP sur des centaines de comptes et de VPC en fonction de règles métier configurables.
   
• Surveillance de l'utilisation des adresses IP dans votre réseau : IPAM peut surveiller les adresses IP et vous permettre de recevoir des alertes lorsqu'IPAM détecte de potentiels problèmes, comme l'épuisement d'adresses IP pouvant paralyser la croissance de votre réseau ou un chevauchement d'adresses IP pouvant entraîner des erreurs de routage.
   
• Dépannage de votre réseau : IPAM vous permet d'identifier rapidement si des problèmes de connectivité proviennent d'adresses IP mal configurées ou d'autres erreurs.
   
• Audit des adresses IP : IPAM conserve automatiquement les données de surveillance de vos adresses IP (jusqu'à trois ans maximum). Vous pouvez utiliser ces données historiques pour effectuer des analyses rétrospectives et des audits de votre réseau.

Voici les principaux composants d'IPAM :

• Une portée est le conteneur de plus haut niveau dans IPAM. Un IPAM contient deux portées par défaut. Chaque portée représente l'espace IP d'un réseau unique. La portée privée est destinée à tous les espaces privés. La portée publique est destinée à tous les espaces publics. Les portées vous permettent de réutiliser les adresses IP sur plusieurs réseaux non connectés sans provoquer de chevauchement ou de conflit d'adresses IP. Dans une portée, vous créez des groupes IPAM.
   
• Un groupe est un ensemble de plages d'adresses IP contiguës (ou CIDR). Les groupes IPAM vous permettent d'organiser vos adresses IP selon vos besoins de routage et de sécurité. Vous pouvez avoir plusieurs groupes au sein d'un groupe de niveau supérieur. Par exemple, si vous avez des besoins de routage et de sécurité distincts pour les applications de développement et de production, vous pouvez créer un groupe pour chacune d'entre elles. Dans les groupes IPAM, vous allouez des CIDR aux ressources AWS.
• Une allocation est une affectation CIDR d'un groupe IPAM vers un autre groupe de ressources ou IPAM. Lorsque vous créez un VPC et que vous choisissez un groupe IPAM pour le CIDR du VPC, le CIDR est alloué à partir du CIDR alloué au groupe IPAM. Vous pouvez contrôler et gérer l'allocation à l'aide d'IPAM.

Oui. IPAM prend en charge les adresses BYOIPv4 et BYOIPv6. BYOIP est une fonctionnalité d'EC2 qui vous permet d'apporter vos adresses IP sur AWS. Avec IPAM, vous pouvez directement allouer et partager leurs blocs d'adresses IP entre les comptes et l'organisation. Les clients existants BYOIP qui utilisent IPv4 peuvent migrer leurs groupes dans IPAM afin de simplifier la gestion des adresses IP.

Oui, Amazon fournit des blocs CIDR IPv6 contigus pour l'allocation des VPC. Les blocs CIDR contigus vous permettent de regrouper les CIDR dans une entrée unique au sein de structures de sécurité et de réseau comme des listes de contrôle d'accès, des tables de routage, des groupes de sécurité et des pare-feu. Vous pouvez allouer les CIDR IPv6 d'Amazon dans un groupe à portée publique et utiliser l'ensemble des fonctionnalités d'IPAM pour gérer et surveiller l'utilisation des adresses IP. L'allocation de ces blocs CIDR commence par des incréments de /52 et de plus grands blocs sont disponibles sur demande. Par exemple, vous pouvez allouer /52 CIDR depuis Amazon et utiliser IPAM pour les partager entre les comptes et créer des VPC dans ces comptes.

Non, les blocs CIDR IPv6 contigus fournis par Amazon ne sont actuellement pris en charge que dans IPAM.

Vous pouvez partager des groupes IPAM avec d'autres comptes dans votre AWS Organization à l'aide d'AWS Resource Access Manager (RAM). Vous pouvez également partager des groupes IPAM avec des comptes en dehors de votre AWS Organization principale. Par exemple, ces comptes peuvent représenter un autre secteur d'activité de votre entreprise ou un service géré hébergé par un partenaire en votre nom, dans une autre AWS Organization.

Oui. Vous pouvez créer un itinéraire par défaut pour chaque sous-réseau. L'itinéraire par défaut peut acheminer le trafic hors du VPC via la passerelle Internet, le virtual private gateway ou la passerelle NAT.

Les groupes de sécurité Amazon EC2 peuvent être utilisés pour sécuriser les instances au sein de Amazon VPC. Les groupes de sécurité dans un VPC vous permettent de spécifier le trafic réseau entrant et sortant, autorisé vers et à partir de chaque instance Amazon EC2. Le trafic qui n'est pas autorisé de façon explicite vers ou à partir d'une instance est automatiquement refusé.

En plus des groupes de sécurité, le trafic réseau entrant et sortant de chaque sous-réseau peut être autorisé ou rejeté via les listes de contrôle d'accès (ACL) réseau.

Les groupes de sécurité dans un VPC spécifient quel trafic est autorisé vers et à partir d'une instance Amazon EC2. Les ACL réseau fonctionnent au niveau du sous-réseau et évaluent le trafic entrant et sortant dans un sous-réseau. Les ACL réseau peuvent être utilisées pour déterminer à la fois les règles d'autorisation et de refus. Les ACL réseau ne filtrent pas le trafic entre les instances dans le même sous-réseau. De plus, les ACL réseau pratiquent un filtrage statique alors que les groupes de sécurité pratiquent un filtrage dynamique.

Le filtrage dynamique suit l'origine d'une demande et peut automatiquement autoriser le retour de la réponse à une demande vers l'ordinateur d'origine. Par exemple, un filtre dynamique qui autorise un trafic entrant vers un port TCP 80 sur un serveur web autorisera le trafic de retour, habituellement sur un port dont le chiffre est élevé (par ex, port de destination TCP 63 912) pour le transmettre à un filtre dynamique entre le client et le serveur web. Le dispositif de filtrage maintient un tableau d'état qui suit les numéros de port et d'adresses IP d'origine et de destination. Une seule règle est requise sur le dispositif de filtrage : autoriser le trafic entrant vers le serveur web sur le port TCP 80.

Le filtrage statique, quant à lui, examine seulement la source ou la destination d'une adresse IP et le port de destination, ignorant si le trafic correspond à une nouvelle demande ou à une réponse à une demande. Dans l'exemple ci-dessus, deux règles auraient besoin d'être mises en œuvre sur le dispositif de filtrage : une règle pour autoriser le trafic entrant vers le serveur web sur le port TCP 80, et une autre pour autoriser le trafic sortant à partir du serveur web (plage de ports TCP 49 152 à 65 535).

Oui. Si une passerelle Internet a été configurée, le trafic Amazon VPC lié aux instances Amazon EC2 et qui n'est pas au sein d'un VPC traverse la passerelle Internet et entre ensuite dans le réseau AWS public pour atteindre l'instance EC2. Si aucune passerelle Internet n'a été configurée, ou si l'instance est dans un sous-réseau configuré pour un routage vers une passerelle réseau privé virtuel, le trafic traverse la connexion VPN, sort du centre de données, puis entre à nouveau dans le réseau AWS public.

Oui. Les instances au sein d'une région donnée peuvent communiquer les unes avec les autres à l'aide de l'appairage de VPC entre régions, les adresses IP publiques, la passerelle NAT, les instances NAT, les connexions VPN ou les connexions Direct Connect.

Oui. Il existe plusieurs possibilités pour permettre à vos ressources au sein d'un VPC de communiquer avec Amazon S3. Vous pouvez utiliser un point de terminaison d'un VPC pour Amazon S3, ce qui permet de s'assurer que l'ensemble du trafic reste dans le réseau d'Amazon et vous donne la possibilité d'appliquer des politiques supplémentaires de gestion des accès à votre trafic Amazon S3. Vous pouvez utiliser la passerelle Internet pour autoriser l'accès à Internet depuis votre VPC tout en permettant aux instances du VPC de communiquer avec Amazon S3. Vous pouvez également faire en sorte que l'ensemble du trafic vers Amazon S3 traverse la connexion VPN ou Direct Connect, sorte de votre data center, puis entre à nouveau dans le réseau AWS public.

Oui. Vous pouvez utiliser la mise en miroir du trafic Amazon VPC et les journaux de flux Amazon VPC pour surveiller le trafic réseau dans votre Amazon VPC.

Les journaux de flux VPC sont une fonctionnalité qui vous permet de collecter les informations relatives au trafic IP entrant et sortant dans les interfaces réseau de votre VPC. Les données des journaux de flux peuvent être publiés soit dans Amazon CloudWatch Logs ou sur Amazon S3. Vous pouvez surveiller vos journaux de flux VPC pour obtenir une visibilité opérationnelle sur vos dépendances réseau et vos modèles de trafic, détecter les anomalies et empêcher les fuites de données, ou résoudre les problèmes de connectivité et de configuration du réseau. Les métadonnées enrichies dans les journaux de flux vous aident à obtenir des informations supplémentaires concernant qui a initié vos connexions TCP et la source et la destination réelles au niveau des paquets pour le trafic passant par des couches intermédiaires telles que la passerelle NAT. Vous pouvez également archiver vos journaux de flux pour répondre aux exigences de conformité. Pour en savoir plus sur les journaux de flux VPC, veuillez consulter la documentation.

Vous pouvez créer un journal de flux pour un VPC, un sous-réseau ou une interface réseau. Si vous créez un journal de flux pour un sous-réseau ou un VPC, chaque interface réseau de ce sous-réseau ou VPC est surveillée. Lors de la création d'un abonnement de journaux de flux, vous pouvez choisir les champs de métadonnées que vous souhaitez capturer, l'intervalle d'agrégation maximum et votre destination préférée pour le journal. Vous pouvez également choisir de capturer le trafic en totalité ou uniquement le trafic accepté ou rejeté. Vous pouvez utiliser des outils tels que CloudWatch Log Insights ou CloudWatch Contributor Insights pour analyser vos journaux de flux VPC envoyés à CloudWatch Logs. Vous pouvez utiliser des outils tels qu'Amazon Athena ou AWS QuickSight pour interroger et visualiser vos journaux de flux VPC envoyés à Amazon S3. Vous pouvez également créer une application en aval personnalisée pour analyser vos journaux ou utiliser des solutions partenaires telles que Splunk, Datadog, Sumo Logic, Cisco StealthWatch, Checkpoint CloudGuard, New Relic, etc.

Oui, vous pouvez créer un journal de flux VPC pour une passerelle de transit ou pour un attachement de la passerelle de transit. Grâce à cette fonctionnalité, Transit Gateway peut exporter des informations détaillées telles que les adresses IP source ou de destination, les ports, le protocole, les compteurs de trafic, les horodatages et diverses métadonnées pour tous ses flux réseau traversants par la passerelle de transit. Pour en savoir plus sur la prise en charge des journaux de flux Amazon VPC pour la passerelle de transit, veuillez consulter la documentation.

Les données des journaux de flux sont collectées en dehors du chemin du trafic de votre réseau, et n'affectent donc pas le débit ou la latence du réseau. Vous pouvez créer ou supprimer des journaux de flux sans risque d'impact sur les performances du réseau.

Les frais d'ingestion et d'archivage des données pour les journaux de flux VPC s'appliquent lorsque vous publiez les journaux de flux sur CloudWatch Logs ou sur Amazon S3. Pour plus d'informations et des exemples, consultez la page Tarification Amazon CloudWatch. Vous pouvez également suivre les frais de publication des journaux de flux à l'aide de balises de répartition des coûts.

La mise en miroir du trafic Amazon VPC permet aux clients de dupliquer facilement le trafic réseau vers et depuis une instance Amazon EC2 et de le transférer vers des appareils de sécurité et de surveillance hors bande pour des cas d’utilisation tels que l’inspection du contenu, la surveillance des menaces et le dépannage. Ces appareils peuvent être déployés sur une instance individuelle Amazon EC2 ou une flotte d’instances derrière un Network Load Balancer (équilibreur de charge de réseau - NLB) avec un écouteur UDP (User Datagram Protocol).

La mise en miroir du trafic prend en charge les captures de paquets réseau au niveau de l’interface réseau ENI (Elastic Network Interface) pour les instances EC2. Veuillez vous référer à la documentation sur la mise en miroir du trafic pour connaître les instances EC2 qui prennent en charge la mise en miroir du trafic Amazon VPC.

Les clients peuvent utiliser des outils en accès libre, ou choisir parmi une large gamme de solutions de surveillance disponibles sur AWS Marketplace. La mise en miroir du trafic permet aux clients de diffuser en continu le trafic dupliqué vers n’importe quel collecteur/broker de paquets de réseau ou outil d’analyse, sans qu’ils aient besoin d’installer des agents propres au fournisseur.

Les journaux de flux Amazon VPC permettent aux clients de collecter, stocker et analyser des journaux de flux réseau. Les informations capturées dans les journaux de flux incluent des informations sur le trafic autorisé et refusé, les adresses IP source et de destination, les ports, le numéro de protocole, le nombre de paquets et d’octets, ainsi qu’une action (accepter ou rejeter). Vous pouvez utiliser cette fonctionnalité pour résoudre les problèmes de connectivité et de sécurité et pour vous assurer que les règles d’accès au réseau fonctionnent comme prévu.

La mise en miroir du trafic Amazon VPC fournit des informations plus détaillées sur le trafic réseau en vous permettant d’analyser le contenu du trafic réel, y compris la charge utile. Elle est également ciblée pour les cas d’utilisation où vous devez analyser les paquets réels pour déterminer la cause profonde d’un problème de performance, procéder à l’ingénierie inverse d’une attaque réseau sophistiquée, ou détecter et bloquer les charges de travail compromises ou les abus commis par des initiés.

Amazon VPC est actuellement disponible dans plusieurs zones de disponibilité dans toutes les régions couvertes par Amazon EC2.

Oui. 

Un sous-réseau doit résider au sein d'une seule zone de disponibilité.

Lorsque vous lancez une instance Amazon EC2, vous devez spécifier le sous-réseau dans lequel la lancer. L'instance sera lancée dans la zone de disponibilité associée au sous-réseau spécifié.

Lorsque vous créez un sous-réseau, vous devez spécifier la zone de disponibilité à utiliser. Lorsque vous utilisez l'assistant VPC, vous pouvez sélectionner la zone de disponibilité du sous-réseau dans l'écran de confirmation de l'assistant. Lorsque vous utilisez l'API ou l'interface de ligne de commande, vous pouvez spécifier la zone de disponibilité du sous-réseau au moment de sa création. Si vous ne spécifiez aucune zone de disponibilité, l'option par défaut « No Preference » est sélectionnée et le sous-réseau est créé dans une zone de disponibilité libre de la région.

Si les instances résident dans des sous-réseaux (subnets) dans différentes Zones de Disponibilité (AZ), vous serez facturé 0,01 USD par Go pour le transfert de données.

Oui. DescribeInstances() retournera toutes les instances Amazon EC2 en cours d'exécution. Vous pouvez différencier les instances EC2-Classic des instances EC2-VPC en consultant la valeur du champ relatif au sous-réseau. S'il y a un ID de sous-réseau indiqué, l'instance figure au sein d'un VPC.

Oui. DescribeVolumes() retournera tous vos volumes EBS.

Pour des instances nécessitant un adressage IPv4, vous pouvez exécuter un nombre illimité d'instances Amazon EC2 au sein d'un VPC, aussi longtemps que la taille de votre VPC est appropriée pour qu'une adresse IPv4 soit attribuée à chaque instance. La limite initiale de lancement est de 20 instances Amazon EC2 en simultané et la limite de taille du VPC de /16 (65 536 adresses IP). Si ces limites vous semblent trop contraignantes, remplissez le formulaire suivant. Pour les instances IPv6 uniquement, la taille VPC de /56 vous permet de lancer un nombre pratiquement illimité d'instances Amazon EC2.

Vous pouvez utiliser des AMI dans Amazon VPC, qui sont enregistrées au sein de la même région que votre VPC. Par exemple, vous pouvez utiliser des AMI enregistrées dans la région usa-est-1 avec un VPC dans la région usa-est-1. Plus d'informations sont disponibles dans la FAQ sur les régions et zones de disponibilité d'Amazon EC2.

Oui, vous pouvez utiliser des instantanés Amazon EBS s'ils sont situés dans la même région que votre VPC. Plus de détails sont disponibles dans la FAQ sur les régions et zones de disponibilité d'Amazon EC2.

Oui, cependant, une instance, lancée dans un VPC utilisant une AMI d'Amazon EBS, conserve la même adresse IP lorsqu'elle est arrêtée et redémarrée, contrairement aux instances similaires lancées en dehors d'un VPC, qui obtiennent une nouvelle adresse IP. Les adresses IP pour des instances arrêtées dans un sous-réseau sont considérées comme non disponibles.

Oui.

Oui. 

Oui. Les instances en cluster sont prises en charge dans Amazon VPC, mais certains types d'instances ne sont pas disponibles dans toutes les régions et zones de disponibilité (AZ).

Lorsque vous lancez une instance, un nom d'hôte lui est attribué. Deux options sont disponibles : un nom basé sur une adresse IP ou un nom basé sur une ressource ; ce paramètre peut être configuré au lancement de l'instance. Le nom basé sur une adresse IP utilise une forme de l'adresse IPv4 privée, tandis que le nom basé sur une ressource utilise une forme de l'ID d'instance.

Oui, vous pouvez modifier le nom d'hôte d'une instance, d'un nom basé sur une adresse IP en un nom basé sur une ressource ou vice versa. Ce processus se déroule en arrêtant l'instance, puis en modifiant les options de nommage basées sur les ressources.

Oui, le nom d'hôte de l'instance peut être utilisé comme nom d'hôte DNS. Pour les instances lancées dans un sous-réseau IPv4 uniquement ou à double pile, le nom basé sur une adresse IP se résout toujours sur l'adresse IPv4 privée de l'interface réseau principale de l'instance ; cette fonction ne peut pas être désactivée. De plus, le nom basé sur la ressource peut être configuré, afin d'être résolu en adresse IPv4 privée sur l'interface réseau principale, ou en première adresse unique globale IPv6 sur l'interface réseau principale, ou les deux. Pour les instances lancées dans un sous-réseau uniquement IPv6, le nom basé sur les ressources sera configuré pour être résolu en première adresse unique globale IPv6 sur l'interface réseau principale. 

Un VPC par défaut est un réseau virtuel isolé de manière logique dans le cloud AWS, qui est créé automatiquement pour votre compte AWS lorsque vous mettez en service des ressources Amazon EC2 pour la première fois. Lorsque vous lancez une instance sans indiquer aucun ID de sous-réseau, celle-ci s'exécute dans votre VPC par défaut.

Lorsque vous lancez des ressources dans un VPC par défaut, vous pouvez bénéficier des fonctions avancées de mise en réseau d'Amazon VPC (EC2-VPC) associées à la simplicité d'utilisation d'Amazon EC2 (EC2-Classic). Vous pouvez profiter de fonctionnalités comme la modification immédiate des membres d'un groupe de sécurité, le filtrage des sorties de groupes de sécurité, l'utilisation de plusieurs adresses IP et de plusieurs interfaces réseau, sans avoir à explicitement créer un VPC et à y lancer des instances.

Si votre compte AWS a été créé après le 18 mars 2013, vous pouvez l'utiliser pour lancer des ressources dans un VPC par défaut. Consultez cette annonce sur le forum pour savoir quelles régions permettent d'utiliser l'ensemble des fonctionnalités du VPC par défaut. Par ailleurs, les comptes créés à une date antérieure permettent d'utiliser des VPC par défaut dans toutes les régions compatibles avec cette fonctionnalité et dans lesquelles vous n'avez pas encore lancé d'instances EC2 ou mis en service des ressources Amazon Elastic Load Balancing, Amazon RDS, Amazon ElastiCache ou Amazon Redshift.

Vous pouvez utiliser AWS Management Console, l'interface de ligne de commande AWS EC2 ou l'API Amazon EC2 pour lancer et gérer des instances EC2, ainsi que d'autres ressources AWS dans un VPC par défaut. AWS crée automatiquement un VPC par défaut pour vous, ainsi qu'un sous-réseau (subnet) par défaut dans chaque Zone de Disponibilité (AZ) de la région AWS. Votre VPC par défaut est connecté à une Internet gateway et vos instances reçoivent automatiquement des adresses IP publiques, comme c'est le cas dans EC2-Classic.

Consultez la section Différences entre EC2-Classic et EC2-VPC du Guide de l'utilisateur d'Amazon EC2.

Les VPC par défaut sont connectés à Internet et toutes les instances lancées dans les sous-réseaux par défaut du VPC par défaut reçoivent automatiquement une adresse IP publique. Toutefois, vous pouvez ajouter une connexion VPN à votre VPC par défaut si vous le souhaitez.

Oui. Pour lancer une instance dans un VPC autre que votre VPC par défaut, vous devez indiquer un ID de sous-réseau lors du lancement de l'instance.

Oui. Pour utiliser un autre sous-réseau, vous pouvez cibler votre lancement en utilisant la console ou l'option --subnet de la ligne de commande, de l'API ou du kit SDK.

Vous pouvez utiliser un VPC par défaut dans chacune des régions AWS pour lesquelles l'attribut Supported Platforms est défini sur « EC2-VPC ».

Dans votre VPC par défaut, un sous-réseau par défaut est créé pour chaque zone de disponibilité (AZ).

Pas à l'heure actuelle.

Pas à l'heure actuelle.

Oui, vous pouvez supprimer un VPC par défaut. Une fois que vous l'avez supprimé, vous pouvez créer un nouveau VPC par défaut directement à partir de la console VPC ou à l'aide d'une interface de ligne de commande. Vous pourrez ainsi créer un nouveau VPC par défaut dans la région. Ceci ne permet pas de restaurer l'ancien VPC supprimé.

Oui, vous pouvez supprimer un sous-réseau par défaut. Une fois ce sous-réseau supprimé, vous pouvez en créer un nouveau par défaut dans la zone de disponibilité grâce à la CLI ou un kit SDK. Cette action créera un nouveau sous-réseau par défaut dans la zone de disponibilité spécifiée. Ceci ne permet pas de restaurer l'ancien sous-réseau supprimé.

Pour obtenir un VPC par défaut, le plus simple est de créer un nouveau compte dans une région autorisant les VPC par défaut, ou d'utiliser un compte existant dans une région que vous n'avez pas encore utilisée, à condition que l'attribut Supported Platforms soit défini sur « EC2-VPC » pour ce compte et dans cette région.

Oui, néanmoins, nous ne pouvons permettre l'utilisation d'un VPC par défaut sur un compte existant que dans la mesure où vous ne possédez pas de ressources EC2-Classic pour ce compte dans la région concernée. De plus, vous devez mettre fin à toutes les ressources Elastic Load Balancer, Amazon RDS, Amazon ElastiCache et Amazon Redshift n'étant pas mises en service dans un VPC pour cette région. Une fois votre compte configuré pour utiliser un VPC par défaut, toutes les ressources, y compris les instances lancées via Auto Scaling, seront lancées dans votre VPC par défaut. Pour demander que votre compte existant soit configuré avec un VPC par défaut, rendez-vous sur Account and Billing → Service: Account → Category: Convert EC2 Classic to VPC et faites votre demande. Nous examinerons votre demande, vos services AWS existants et votre présence EC2-Classic et vous guiderons dans les prochaines étapes.

Si votre compte AWS possède un VPC par défaut, tous les comptes IAM associés à votre compte AWS utiliseront le même VPC par défaut que celui-ci.

EC2-Classic est un réseau plat que nous avons lancé avec EC2 à l'été 2006. Avec EC2-Classic, vos instances s'exécutent dans un réseau unique et plat que vous partagez avec d'autres clients. Toutefois, pour prendre en compte l'évolution des besoins de nos clients au fil du temps, nous avons lancé Amazon Virtual Private Cloud (VPC) en 2009 pour leur permettre d'exécuter des instances dans un cloud privé virtuel logiquement isolé de votre compte AWS. Bien que la majorité de nos clients utilisent Amazon VPC aujourd'hui, nous avons quelques-uns utilisent encore EC2-Classic.

Nous désactivons Amazon EC2-Classic le 15 août 2022 et vous devriez avoir migré toutes les instances EC2 et autres ressources AWS qui s'exécutent sur EC2-Classic vers Amazon VPC avant cette date. La section suivante fournit de plus amples informations sur le retrait d'EC2-Classic ainsi que des outils et des ressources pour vous aider dans la migration.

Vous n'êtes concerné par ce changement que si vous avez activé EC2-Classic sur votre compte dans une région AWS. Vous pouvez utiliser la console ou la commande describe-account-attributes pour vérifier si vous avez activé EC2-Classic pour une Région AWS. Veuillez consulter ce document pour plus de détails.

Si vous n'avez pas de ressources AWS actives qui s'exécutent sur EC2-Classic dans une région, nous vous demandons de désactiver EC2-Classic de votre compte pour cette région. En désactivant EC2-Classic dans une région, vous pouvez y lancer le VPC par défaut. Pour ce faire, rendez-vous dans AWS Support Center ici console.aws.amazon.com/support, choisissez « Créer un ticket de support », puis « Support de compte et facturation ». Pour « Type », choisissez « Compte ». Pour « Catégorie », choisissez « Convertir EC2-Classic en VPC ». Fournissez les autres détails demandés, puis cliquez sur « Envoyer ».

Nous désactiverons automatiquement EC2-Classic de votre compte le 30 octobre 2021 pour toute région AWS où vous n'avez pas eu de ressources AWS (instances EC2, base de données relationnelle Amazon, AWS Elastic Beanstalk, Amazon Redshift, AWS Data Pipeline, Amazon EMR, AWS OpsWorks) sur EC2-Classic depuis le 1er janvier 2021.

En revanche, si vous disposez de ressources AWS qui s'exécutent sur EC2-Classic, nous vous demandons de planifier leur migration vers Amazon VPC dès que possible. Vous ne pourrez pas lancer d'instances ou de services AWS sur la plateforme EC2-Classic après le 15 août 2022. Les applications ou services en cours d'exécution perdront progressivement l'accès à tous les services AWS sur EC2-Classic au fur et à mesure de leur retrait à partir du 16 août 2022.

Vous pouvez trouver les guides de migration pour vos ressources AWS dans la question suivante.

Amazon VPC vous donne un contrôle total sur votre environnement réseau virtuel sur AWS, lequel est logiquement isolé de votre compte AWS. Dans l'environnement EC2-Classic, vos applications partagent un seul réseau plat avec d'autres clients. L'environnement Amazon VPC offre de nombreux autres avantages par rapport à l'environnement EC2-Classic, notamment la possibilité de sélectionner votre propre espace d'adresse IP, la configuration des sous-réseaux publics et privés et la gestion des tables de routage et des passerelles réseau. Tous les services et instances actuellement disponibles dans EC2-Classic ont des services comparables disponibles dans l'environnement Amazon VPC. Amazon VPC offre également une génération d'instances beaucoup plus large et plus récente qu'EC2-Classic. De plus amples informations sur Amazon VPC sont disponibles sur ce lien.

Pour vous aider à migrer vos ressources, nous avons publié des playbooks et créé des solutions que vous trouverez ci-dessous. Pour migrer, vous devez recréer vos ressources EC2-Classic dans votre VPC. Vous pouvez commencer par utiliser ce script pour identifier toutes les ressources allouées dans EC2-Classic dans toutes les régions d'un compte. Vous pouvez ensuite utiliser le guide de migration pour les ressources AWS concernées ci-dessous :

• Instances et groupes de sécurité
• Classic Load Balancer
• Amazon Relational Database Service
• AWS Elastic Beanstalk
• Amazon Redshift pour la migration des clusters DC1 et pour d'autres types de nœuds
• AWS Data Pipeline 
• Amazon EMR 
• AWS OpsWorks

Outre les guides de migration susmentionnés, nous proposons AWS Application Migration Service (AWS MGN), une solution de lift-and-shift (réhébergement) hautement automatisée qui simplifie, accélère et réduit le coût de la migration des applications. Des ressources pertinentes sur AWS MGN sont disponibles ici :

• Démarrage avec AWS Application Migration Service. 
• Formation technique à la demande sur AWS Application Migration Service
• Documentation pour explorer les fonctions et fonctionnalités du service de migration d'applications AWS.
• Vidéo sur l'architecture des services et l'architecture des réseaux

Pour les migrations simples d'instances EC2 individuelles de EC2-Classic vers VPC, outre AWS MGN ou le Guide de migration des instances, vous pouvez également utiliser le runbook « AWSSupport-MigrateEC2 ClassicToVPC » à partir de « AWS Systems Manager > Automatisation ». Ce runbook automatise les étapes nécessaires à la migration d'une instance d'EC2-Classic vers VPC en créant une AMI de l'instance dans EC2-Classic, en créant une nouvelle instance à partir de l'AMI dans VPC et en résiliant éventuellement l'instance EC2-Classic.

Si vous avez des questions ou des préoccupations, vous pouvez contacter l'équipe AWS Support viaAWS Premium Support.

Remarque : si vous avez des ressources AWS qui s'exécutent sur EC2-Classic dans plusieurs régions AWS, nous vous recommandons de désactiver EC2-Classic pour chacune de ces régions dès que vous aurez migré toutes vos ressources vers VPC dans celles-ci.

Nous prendrons les deux mesures suivantes avant la date du retrait fixée au 15 août 2022 :

• Nous cesserons d'émettre des instances réservées (IR) de 3 ans et des IR d'un an pour l'environnement EC2-Classic le 30 octobre 2021. Les IR déjà disponibles sur l'environnement EC2-Classic ne seront pas affectées à cette date. Les IR qui doivent expirer après le 15 août 2022 devront être modifiées pour utiliser l'environnement Amazon VPC pour la période restante du bail. Pour savoir comment modifier vos IR, veuillez consulter notre document.
• Le 15 août 2022, nous n'autoriserons plus la création de nouvelles instances (Spot ou à la demande) ou d'autres services AWS dans l'environnement EC2-Classic. Les applications ou services en cours d'exécution perdront progressivement l'accès à tous les services AWS sur EC2-Classic au fur et à mesure de leur retrait à partir du 16 août 2022.

Oui.

Les interfaces réseau ne peuvent être rattachées qu'à des instances situées dans la même zone de disponibilité.

Les interfaces réseau ne peuvent être rattachées qu'à des instances de VPC du même compte.

Oui, toutefois, ce scénario d'utilisation ne convient pas idéalement à des interfaces multiples. Attribuez plutôt les adresses IP privées supplémentaires à l'instance, puis associez les adresses IP élastiques aux adresses IP privées selon vos besoins.

Vous pouvez associer les interfaces secondaires (eth1-ethn) à une instance EC2 ou les dissocier, mais vous ne pouvez pas dissocier l'interface eth0.

Oui. Des connexions d'appairage peuvent être créées avec des VPC situés dans des régions différentes. L’appairage de VPC inter-régions est disponible dans les régions commerciales du monde entier (sauf la Chine).

Oui, à condition que le propriétaire de ce VPC accepte votre demande de connexion d'appairage.

La création de connexions d'appairage entre VPC est gratuite, mais les transferts de données via ces connexions vous sont facturés. Référez vous à la section Transfert de données de la page Tarification Amazon EC2 pour connaître les tarifs applicables.

Les connexions d'appairage entre VPC ne nécessitent pas de passerelle Internet.

Le trafic entre instances de VPC appairées reste privé et isolé, de la même manière que le trafic entre deux instances d'un même VPC est privé et isolé.

Les deux parties de la connexion d'appairage peuvent mettre fin à cette connexion à tout moment. Dans ce cas, plus aucun trafic ne circule entre les deux VPC.

Les relations d'appairage ne sont pas transmissibles.

AWS utilise l'infrastructure existante du VPC pour créer la connexion d'appairage de VPC ; il ne s'agit ni d'une passerelle ni d'une connexion VPN, et elle ne repose pas sur un équipement matériel distinct. Il n'y a donc pas de point unique de défaillance pour la communication, ni de goulet d'étranglement en termes de bande passante.

L'appairage de VPC entre régions repose sur la même technologie hautement disponible, redondante et dimensionnée horizontalement qui alimente VPC aujourd'hui. Le trafic de l'appairage de VPC entre régions passe par le réseau fédérateur AWS qui dispose d'une redondance intégrée et d'une allocation dynamique de la bande passante. Il n'existe donc pas de point unique de défaillance pour la communication.

Si une connexion d'appairage entre régions est interrompue, le trafic ne sera pas acheminé via Internet.

La bande passante entre les instances de VPC appairées est identique à celle que l'on peut observer entre des instances d'un même VPC. Remarque : un groupe de placement peut intégrer des VPC appairés ; cependant, dans ce cas, vous n'obtiendrez pas une bande passante entièrement bisectionnelle entre les instances des VPC pairs. En savoir plus sur les groupes de placement.

Le trafic est chiffré à l'aide d'algorithmes AEAD (Authenticated Encryption with Associated Data ou Chiffrement authentifié avec données supplémentaires) modernes. La négociation et la gestion des clés sont gérées par AWS.

Par défaut, une requête pour un nom d'hôte public d'une instance d'un VPC appairé situé dans une région différente sera résolue en une adresse IP publique. Le DNS privé de Route 53 peut être utilisé pour être résolu en une adresse IP privée avec appairage de VPC entre régions.

Les groupes de sécurité ne peuvent pas être référencés dans une connexion d'appairage de VPC entre régions.

Oui. L'appairage de VPC entre régions prend en charge le protocole IPv6.

L'appairage de VPC entre régions ne peut pas être utilisé avec EC2 ClassicLink.

Amazon Virtual Private Cloud (VPC) ClassicLink permet aux instances EC2 dans la plate-forme EC2-Classic de communiquer avec les instances dans un VPC à l'aide d'adresses IP privées. Pour utiliser ClassicLink, activez-le pour un VPC dans votre compte et associez un groupe de sécurité à une instance dans EC2-Classic depuis ce VPC. Toutes les règles de votre groupe de sécurité VPC s'appliquent aux communications entre les instances dans EC2-Classic et les instances dans le VPC. 

L'utilisation de ClassicLink n'engendre pas de frais supplémentaires. En revanche, les frais inhérents au transfert de données entre plusieurs zones de disponibilité existantes s'appliquent. Pour plus d'informations, consultez la page Tarification Amazon EC2.

Pour utiliser ClassicLink, vous devez d'abord activer au moins un VPC dans votre compte pour ClassicLink. Puis, vous associez un groupe de sécurité à l'instance EC2-Classic souhaitée depuis le VPC. L'instance EC2-Classic est désormais liée au VPC et fait partie du groupe de sécurité sélectionné dans le VPC. Votre instance EC2-Classic ne peut être liée qu'à un seul VPC à la fois.

L'instance EC2-Classic ne fera pas partie du VPC. Elle fera simplement partie du groupe de sécurité VPC associé à l'instance. Toutes les règles et références au groupe de sécurité VPC s'appliquent aux communications entre les instances dans l'instance EC2-Classic et les ressources internes au VPC.

Le nom d'hôte DNS public EC2 ne résout pas l'adresse IP privée de l'instance EC2-VPC lorsque la requête est effectuée depuis une instance EC2-Classic, et vice versa.

Oui. ClassicLink ne peut pas être activé pour un VPC présentant un routage inter-domaine sans classe (CIDR) situé au sein de la plage 10.0.0.0/8, à l'exception de 10.0.0.0/16 et de 10.1.0.0/16. De plus, ClassicLink ne peut pas être activé pour un VPC doté d'une entrée de table de routage pointant sur l'espace CIDR 10.0.0.0/8, vers une cible non locale.

Le trafic provenant d'une instance EC2-Classic peut être acheminé uniquement vers des adresses IP privées au sein du VPC. Il ne peut pas être acheminé vers des destinations situées hors du VPC, notamment vers la passerelle Internet, le virtual private gateway ou les VPC pairs.

ClassicLink ne modifie pas le contrôle des accès défini pour une instance EC2-Classic via ses groupes de sécurité existants depuis la plate-forme EC2-Classic.

La connexion ClassicLink n'est pas maintenue lors des cycles d'interruption/de mise en route de l'instance EC2-Classic. L'instance EC2-Classic doit de nouveau être liée à un VPC lorsqu'elle est interrompue et mise en route. Cependant, la connexion ClassicLink est préservée durant les cycles de redémarrage de l'instance.

ClassicLink ne permet pas aux règles du groupe de sécurité EC2-Classic de faire référence à des groupes de sécurité VPC, ou vice versa.

AWS PrivateLink permet aux clients d'accéder à des services hébergés sur AWS avec une haute disponibilité et de manière évolutive tout en conservant le trafic réseau dans le réseau AWS. Les utilisateurs du service peuvent l'utiliser pour accéder de manière privée aux services fournis par PrivateLink depuis leur Amazon Virtual Private Cloud (VPC) ou leur propre centre de données sans avoir à utiliser d'IP publiques et sans avoir besoin de faire passer le trafic par Internet. Les propriétaires du service peuvent enregistrer leurs équilibreurs de charge réseau auprès des services PrivateLink et fournir ces services à d'autres clients AWS.

En tant qu'utilisateur du service, vous devrez créer des points de terminaison d'un VPC de type interface pour les services fournis par PrivateLink. Ces points de terminaison de service apparaîtront en tant qu'interface réseau Elastic (ENI) avec des IP privées dans vos VPC. Une fois ces points de terminaison créés, tout trafic destiné à ces IP sera routé de manière privée vers les services AWS correspondants.

En tant que propriétaire du service, vous pouvez embarquer votre service sur AWS PrivateLink en créant un Network Load Balancer pour mettre en avant votre service et créer un service PrivateLink pour s'enregistrer auprès du NLB. Vos clients pourront créer des points de terminaison dans leurs propres VPC pour se connecter à votre service une fois que vous aurez établi une liste blanche de leurs comptes et de leurs rôles IAM.

Les services AWS suivants prennent en charge cette fonctionnalité : Amazon Elastic Compute Cloud (EC2), Elastic Load Balancing (ELB), Kinesis Streams, Service Catalog, EC2 Systems Manager, Amazon SNS et AWS DataSync. De nombreuses solutions SaaS prennent également cette fonctionnalité en charge. Consultez AWS Marketplace pour plus de produits SaaS à technologie AWS PrivateLink.

Oui. L'application dans votre propre centre de données peut se connecter aux points de terminaison de service dans Amazon VPC via AWS Direct Connect. Les points de terminaison de service dirigeront automatiquement le trafic vers les services AWS à technologie AWS PrivateLink.

Oui. Vous pouvez utiliser AWS Management Console pour gérer les objets Amazon VPC, comme des VPC, des sous-réseaux (subnets), des tables de routage, des passerelles Internet et des connexions VPN utilisant IPSec. De plus, vous pouvez utiliser un simple assistant pour créer un VPC.

Consultez le Guide de l'utilisateur d'Amazon VPC pour en savoir plus sur les restrictions de VPC.

Oui. Cliquez ici pour plus d'informations sur AWS Support.

ElasticFox n'est plus officiellement pris en charge pour la gestion de votre Amazon VPC. La prise en charge d'Amazon VPC est disponible via les API AWS, les outils de ligne de commande et AWS Management Console, tout comme une variété de services tiers.