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).

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.

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. 

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.

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.

À 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.

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.

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.

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

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.

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.

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).

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.

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 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 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 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.

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.

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.

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

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.

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.

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

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.

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.

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.

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.

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.