FAQ sur Amazon VPC

Amazon VPC vous permet de provisionner une section isolée du Cloud Amazon Web Services (AWS) de manière logique, au sein de laquelle vous pouvez lancer des ressources AWS dans un réseau virtuel que vous définissez. Vous conservez la totale maîtrise de votre environnement de mise en réseau virtuel, y compris pour la sélection de vos propres plages d'adresses IP, la création de sous-réseaux et la configuration de tables de routage et de passerelles réseau. De plus, vous pouvez créer une connexion VPN (Virtual Private Network) matérielle entre le data center de votre entreprise et votre VPC, et exploiter le cloud AWS comme une extension de votre datacenter d'entreprise.

Vous pouvez facilement adapter la configuration du réseau à votre nuage Amazon VPC. Par exemple, vous pouvez créer un sous-réseau destiné au public pour vos serveurs Web : un sous-réseau qui a accès à Internet et place vos systèmes principaux, comme les bases de données ou les serveurs d'application, dans un sous-réseau non destiné au public sans accès Internet. Vous pouvez exploiter plusieurs couches de sécurité, y compris les groupes de sécurité et les listes de contrôles d’accès au réseau, afin de renforcer le contrôle des accès aux instances Amazon EC2 dans chaque sous-réseau.

Amazon VPC comprend une variété d’objets bien connus des clients déjà équipés de réseaux :

• Cloud privé virtuel : un réseau virtuel isolé de manière logique au sein du Cloud AWS. Vous définissez un espace d'adresse IP d'un VPC depuis des plages que vous sélectionnez.
• Sous-réseau : un segment de plage d’adresses IP d’un VPC dans lequel vous pouvez placer des groupes de ressources isolées.
• Passerelle Internet : le côté Amazon VPC d’une connexion à l’Internet public.
• Passerelle NAT : un service géré de traduction d’adresses réseau (NAT) à disponibilité élevée qui permet à vos ressources d’accéder à Internet depuis un sous-réseau privé.
• Passerelle privée virtuelle : le côté Amazon VPC d’une connexion VPN.
• Connexion d’appairage : une connexion d’appairage vous permet d’acheminer le trafic via des adresses IP privées entre deux VPC appairés.
• Points de terminaisons de VPC : ils permettent une connectivité privée aux services hébergés sur AWS depuis votre VPC sans utiliser de passerelle Internet, de VPN, d’appareils de traduction d’adresses réseau (NAT) ou de proxy de pare-feu.
• Passerelle Internet de sortie uniquement : une passerelle avec état qui fournit un accès sortant uniquement pour le trafic IPv6 du VPC vers Internet.

Vos ressources AWS sont automatiquement provisionnées dans un VPC par défaut prêt à l’emploi. Vous pouvez créer des VPC supplémentaires. Pour cela, rendez-vous sur la page Amazon VPC sur AWS Management Console et sélectionnez « Start VPC Wizard ».

Vous vous verrez proposer quatre options basiques pour les architectures réseau. Après avoir sélectionné une option, vous pouvez modifier la taille et la plage des adresses IP du VPC et ses sous-réseaux. Si vous sélectionnez une option avec l'accès au matériel VPN, vous devrez spécifier l'adresse IP du matériel VPN sur votre réseau. Vous pouvez modifier le VPC pour ajouter ou supprimer des plages d'adresse IP et des passerelles secondaires, ou pour ajouter davantage de sous-réseaux aux plages d'adresses IP.

Voici les quatre options disponibles :

1. Amazon VPC avec un sous-réseau public uniquement
2. Amazon VPC avec des sous-réseaux publics et privés
3. Amazon VPC avec des sous-réseaux publics et privés et un accès VPN entre les sites AWS
4. Amazon VPC avec un sous-réseau privé uniquement et un accès AWS Site-to-Site VPN

Les points de terminaison de VPC vous permettent de connecter en privé votre VPC à des services hébergés sur AWS sans avoir besoin d’une passerelle Internet, d’un appareil NAT ou de proxys de pare-feu. Les points de terminaison sont des appareils virtuels dimensionnables à l'horizontale et hautement disponibles qui permettent les communications entre les instances de votre VPC et des services AWS. Amazon VPC propose deux types de points de terminaison : des points de terminaison de type passerelle et d'autres de type interface.

Les points de terminaison de type passerelle sont disponibles uniquement pour les services AWS dont S3 et DynamoDB. Ces points de terminaison ajoutent une entrée à la table de routage que vous avez sélectionnée et routent le trafic vers les services pris en charge via le réseau privé d'Amazon.

Les points de terminaison de type interface fournissent une connectivité privée à des services fournis par PrivateLink, qui sont des services AWS, vos propres services ou des solutions SaaS, et prennent en charge la connectivité à Direct Connect. Dans l'avenir, d'autres solutions AWS et SaaS seront prises en charge par ces points de terminaison. Veuillez consulter la tarification VPC pour connaître le prix des points de terminaison de type interface.

Il n’y a aucuns 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 services 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 de 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. D’autres couches de chiffrement existent également : par exemple, tout le trafic d’appairage interrégional de VPC ainsi que les connexions de protocole TLS (Transport Layer Security), qu’elles soient entre un client et un service ou entre services. 

Pour le bloc CIDR primaire, vous pouvez utiliser n’importe quelle plage d’adresses IPv4, y compris les plages RFC 1918 ou d’adresses IP publiquement routables. Pour les blocs 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. En appelant l’API appropriée ou par le biais de la Console de gestion AWS, vous pouvez allouer à un VPC jusqu’à cinq blocs CIDR GUA IPv6, qu’ils soient fournis par Amazon ou via la fonctionnalité BYOIP.

Lorsque vous créez un VPC, vous attribuez une seule plage d’adresses IP Classless Internet Domain Routing (CIDR) comme bloc CIDR primaire. Une fois le VPC créé, vous pouvez ajouter jusqu’à quatre (4) blocs CIDR secondaires. 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 qui ne se chevauchent pas. Vous pouvez allouer à votre VPC jusqu’à cinq blocs CIDR IPv6, qu’ils soient fournis par Amazon ou via la fonctionnalité BYOIP.

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 CIDR 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 CIDR IPv6 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 d’utilisation d’EC2.

Il peut être intéressant d’utiliser vos propres adresses IP sur 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ées, 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 à la fonctionnalité BYOIP, ces clients peuvent désormais attribuer leur plage d’adresses IPv6 à leur VPC et choisir d’acheminer via Internet ou Direct Connect le trafic vers leur réseau sur site.

Consultez notre documentation pour plus de détails sur la disponibilité de la fonctionnalité BYOIP.

AWS IPAM offre les fonctionnalités suivantes :
 

• Allocation d’adresses IP pour les réseaux à grande échelle : IPAM peut automatiser les allocations 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 générer des alertes lorsque de potentiels problèmes sont détectés, tels que l’épuisement des adresses IP pouvant freiner la croissance du réseau, ou des adresses IP chevauchantes 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 représente 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 attribution 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 d’un VPC Amazon. 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 avec état suit l’origine d’une demande et peut automatiquement autoriser le retour de la réponse vers l’ordinateur ayant émis la demande. 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 capturer les informations relatives au trafic IP entrant et sortant des 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 Amazon 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 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 Transit Gateway, veuillez consulter la documentation.

Les frais d’ingestion et d’archivage des données pour les journaux fournis s’appliquent lorsque vous publiez des journaux de flux sur CloudWatch Logs ou Amazon S3. Pour plus d’informations et des exemples, consultez la page de 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 fonctionnalité Mise en miroir du trafic prend en charge les captures de paquets réseau au niveau de l’interface réseau Elastic (ENI) 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 fonctionnalité 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 fonctionnalité Mise en miroir du trafic Amazon VPC fournit des informations analytiques plus détaillées sur le trafic réseau en vous permettant d’analyser le contenu du trafic réel, y compris les données utiles. Elle est destinée aux cas d’utilisation où il est nécessaire d’analyser les paquets réels pour déterminer la cause racine d’un problème de performance, analyser par rétro‑ingénierie une attaque réseau sophistiquée ou détecter et arrêter un abus interne ou des charges de travail compromises.

Amazon VPC est actuellement disponible dans plusieurs zones de disponibilité dans toutes les régions 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 de 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 us-east-1 avec un VPC dans la région us-east-1. Plus d’informations sont disponibles dans la FAQ sur les régions et les zones de disponibilité 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 les zones de disponibilité Amazon EC2.

Si votre compte AWS a été créé après le 18 mars 2013, il se peut que vous puissiez lancer des ressources dans un VPC par défaut. Consultez cette annonce sur le forum pour savoir quelles régions permettent d’utiliser les fonctionnalités de VPC par défaut. Les comptes créés avant les dates indiquées peuvent utiliser des VPC par défaut dans n’importe quelle région où cette option est activée, à condition que vous n’y ayez jamais lancé d’instances EC2 ni provisionné de 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 d’utilisation d’EC2.

Oui, cependant, 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 aucune ressource 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 utilisation EC2-Classic, et nous vous guiderons à travers les étapes suivantes.

Ce changement vous concerne uniquement si EC2-Classic est activé sur votre compte dans l’une des régions 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 le centre AWS Support ici console.aws.amazon.com/support, choisissez « Créer un dossier », puis « Support de compte et facture ». Pour « Type », choisissez « Compte ». Pour « Catégorie », choisissez « Convertir EC2-Classic en VPC ». Fournissez les autres détails demandés, puis cliquez sur « Soumettre ».

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 via ce lien.

Pour vous aider à migrer vos ressources, nous avons publié des guides 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 provisionné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 dossier d’exploitation « 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 via AWS Premium Support.

Remarque : si vous avez des ressources AWS fonctionnant 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 avez migré toutes vos ressources vers un VPC dans ces régions.

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 instances réservées, veuillez consulter ce 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 charges de travail 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.

Non, les interfaces réseau ne peuvent être associées qu'à des instances de VPC du même compte.

La création de connexions d’appairage de 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 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 interrégionale tombe en panne, le trafic ne transitera pas par Internet.

La bande passante entre des instances de VPC appairés est identique à celle entre des instances d’un même VPC. Remarque : un groupe de placement peut s’étendre sur des VPC appairés, mais vous n’obtiendrez pas une bande passante entièrement bisectionnelle entre les instances des VPC appairés. En savoir plus sur les groupes de placement.

L’utilisation de ClassicLink n’engendre aucuns frais supplémentaires. Cependant, 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 EC2.

En tant qu’utilisateur du service, vous devrez créer des points de terminaison de 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 NBL. 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. Accédez à AWS Marketplace pour plus de produits SaaS fonctionnant avec AWS PrivateLink.

Consultez le guide d’utilisation 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 la Console de gestion AWS, tout comme une variété de services tiers.

Une fonctionnalité de sécurité et de conformité qui fournit un contrôle centralisé pour surveiller et appliquer le chiffrement des flux de trafic à l’intérieur et entre les VPC d’une région. Pour plus d’informations, veuillez consulter la documentation ici.

Le mode Surveillance (pour surveiller, évaluer et initier la migration) et le mode Application (pour empêcher tout trafic non chiffré).

Les administrateurs de sécurité et les architectes cloud, en particulier dans les secteurs nécessitant la conformité à des normes telles que HIPAA, FedRamp et PCI DSS.

Ils utilisent à la fois le chiffrement au niveau applicatif et les capacités de chiffrement intégrées du matériel AWS Nitro System pour garantir l’application du chiffrement.

Le mode Surveillance fournit une visibilité sur le statut de chiffrement des flux de trafic, aide à identifier les ressources non conformes et alimente les journaux de flux de VPC avec les informations sur le statut de chiffrement. Les ressources telles que les Network Load Balancers, les Application Load Balancers, les clusters Fargate, et le plan de contrôle EKS migreront automatiquement et progressivement vers du matériel supportant nativement le chiffrement dès que vous activez le mode Surveillance.

Par :

• les journaux de flux de VPC contenant le champ encryption-status
• le tableau de bord de la console
• la commande GetVpcResourcesBlockingEncryptionEnforcement

Non, vous devez créer de nouveaux journaux de flux en ajoutant manuellement le champ encryption-status. Il est également recommandé d’ajouter les champs traffic-path et flow-direction.

Une fois qu’un VPC est en mode Application, il empêche la création ou l’attachement de ressources autorisant du trafic non chiffré à l’intérieur du périmètre du VPC. Vous ne pourrez pas exécuter des instances ne prenant pas en charge le chiffrement natif Nitro.

Non, vous devez d’abord :

• Activer le mode Surveillance
• Identifier les ressources non conformes
• Modifier ou créer des exclusions pour les ressources non conformes
• Puis passer au mode Application

Vous devez créer une exclusion pour cette ressource parmi les huit types d’exclusion pris en charge. Les autres ressources non prises en charge doivent être migrées hors du VPC ou supprimées avant l’activation du mode Application. Les ressources prises en charge par les contrôles de chiffrement doivent être migrées vers des instances conformes au chiffrement avant l’activation du mode Application.

Procédez comme suit :

• Examinez les journaux de flux et la conformité des ressources
• Planifiez les migrations de ressources nécessaires
• Configurez les exclusions requises lors du passage en mode Application

Oui, sauf dans le cas où un appairage de VPC est établi entre deux VPC sans aucune exclusion. Dans ce cas, vous devez supprimer l’appairage de VPC entre les deux VPC, puis passer au mode Surveillance.

Utilisez la commande GetVpcResourcesBlockingEncryptionEnforcement pour identifier les ressources qui bloqueraient l’application. Vous pouvez également utiliser la console pour trouver les ressources non chiffrées.

Huit exclusions sont prises en charge :

• Passerelle Internet
• Passerelle NAT
• Passerelle Internet de sortie uniquement
• Connexions d’appairage de VPC vers des VPC sans chiffrement obligatoire
• Passerelle privée virtuelle
• Fonctions Lambda
• VPC Lattice
• Elastic File System

0 : non chiffré
1 : chiffré par Nitro
2 : chiffré par l’application
3 : chiffré à la fois par Nitro ET par l’application
(-) : inconnu/contrôles de chiffrement de VPC désactivés

Pour chiffrer le trafic entre vos VPC ayant les contrôles de chiffrement activés, vous pouvez utiliser l’appairage de VPC ou Transit Gateway. Lorsque vous utilisez Transit Gateway, vous devez activer explicitement la prise en charge du chiffrement via la console ou la commande modify-transit-gateway. L’activation du chiffrement sur Transit Gateway n’entraîne pas de frais supplémentaires. En revanche, les coûts standards liés aux contrôles de chiffrement de VPC s’appliquent à tous les VPC associés à la passerelle de transit, même si ces VPC n’ont pas eux-mêmes les contrôles de chiffrement activés.

Utilisez la commande modify-transit-gateway ou activez-le via la console AWS. Vous devez activer explicitement la prise en charge du chiffrement sur une passerelle de transit pour chiffrer le trafic entre vos VPC ayant les contrôles de chiffrement activés.

L’activation du chiffrement sur une passerelle de transit existante n’affecte pas les flux de trafic existants. La migration des attachements de VPC vers des voies chiffrées se fera automatiquement et sans perturbation. Vous pouvez activer la prise en charge du chiffrement sur une passerelle de transit pour chiffrer le trafic entre vos VPC. Le trafic entre deux VPC en mode Application (sans exclusions) est chiffré de bout en bout via la passerelle de transit. Le chiffrement sur Transit Gateway permet également de connecter deux VPC qui sont dans des modes de contrôles de chiffrement différents.

Cela dépend. Le trafic entre deux VPC en mode Application (sans exclusions) est chiffré de bout en bout via la passerelle de transit. Le chiffrement sur Transit Gateway vous permet également de connecter deux VPC qui sont dans des modes de contrôle de chiffrement différents. Vous devez l’utiliser lorsque vous souhaitez appliquer les contrôles de chiffrement dans un VPC connecté à un VPC dont le chiffrement n’est pas appliqué. Dans un tel scénario, tout le trafic à l’intérieur de votre VPC soumis au chiffrement est chiffré, y compris le trafic inter-VPC. Le trafic inter-VPC est chiffré entre les ressources du VPC soumis au chiffrement et la passerelle de transit. Au-delà, le chiffrement dépend des ressources vers lesquelles le trafic se dirige dans le VPC non soumis au chiffrement. Dans ce cas, puisque le VPC n’est pas en mode Application, le chiffrement n’est pas garanti. L’ensemble des VPC doivent se situer dans la même région.

Oui, le trafic restera chiffré jusqu’à ce qu’il atteigne l’attachement de passerelle de transit dans le VPC sans chiffrement imposé. Le trafic reste chiffré depuis la source jusqu’à l’attachement de passerelle de transit dans le VPC de destination, indépendamment du statut de chiffrement de ce VPC.

Activez le chiffrement sur la passerelle de transit tout en conservant les connexions existantes, la transition est gérée automatiquement. L’activation du chiffrement sur Transit Gateway n’affecte pas les flux de trafic existants.

Oui, Transit Gateway prend en charge une migration progressive en gérant à la fois le trafic chiffré et non chiffré durant la transition.

Non. Private Link avec les contrôles de chiffrement de VPC est uniquement pris en charge pour les services AWS. Les points de terminaison de VPC assurant la liaison vers des services externes à AWS ne peuvent pas rester dans des VPC où vous souhaitez imposer le chiffrement. Vous devrez supprimer ces points de terminaison avant de passer le VPC en mode Application. Les VPC fonctionnant en mode Application peuvent être connectés via appairage de VPC ou Transit Gateway pour garantir un chiffrement de bout en bout.