Qu'est-ce qu'Amazon VPC ?
Amazon Virtual Private Cloud (Amazon VPC) nous permet de lancer des ressources AWS dans un réseau virtuel définie. Est en effet, l’une des premières briques d’un projet AWS. Il permet de lancer des ressources dans un réseau virtuel isolé. De nombreux services comme EC2, ECS, RDS reposent dessus. Bien que primordial, AWS VPC s’avère assez compliqué à appréhender tant par la richesse des ressources manipulées (table de routage, gateway, subnet …) que par le domaine de compétences qu’il implique.
Tout en démystifiant les VPC et en exposant les éléments pertinents dans le choix de création d’un réseau dédié.
pourquoi créer un VPC alors qu’AWS en fournit un par défaut ? Avant de répondre à cette question revenons quelques instants sur la genèse du réseau sur AWS. Il fut un temps où seul EC2-classic existait, un temps que les comptes de moins de 4 ans (créés après le 4 décembre 2013) ne peuvent pas connaître.
En ce temps là, toutes les instances EC2 étaient dans un seul réseau public avec des adresses IP publiques auto-générées. C’était un modèle simple, mais insuffisant pour offrir de l’infrastructure privée et isolée. AWS introduisit donc la notion de VPC afin d’offrir un réseau virtuel configurable par l’utilisateur. EC2-VPC permet par exemple de sélectionner une plage d’adresses IP, de créer des sous-réseaux, de configurer des tables de routage et des passerelles réseau. C’est une architecture riche, paramétrable, flexible qui apporte néanmoins une certaine complexité. C’est pour cela qu’AWS propose un VPC par défaut qui a l’avantage de comprendre les fonctions avancées offertes par EC2-VPC, tout en étant prêt à être utilisé.
Comme le montre cette image VPC par defaut (configuration d'une instance)
Pour faire simple dans tout projet :
• impliquant des interconnexions avec d’autres réseaux (entreprise, VPC peering, VPN)
• nécessitant un désir accru de sécurité en isolant des instances dans des sous réseaux privés inaccessibles depuis internet.
Le VPC par défaut arrive avec un adressage IP prédéfini 172.31.0.0/16 qui entraine des complications dans l’interconnexion avec un VPN d’entreprise en raison de la plage IP imposée. Il s’avère par ailleurs impossible à appairer (peering) avec un autre VPC par défaut. De plus la configuration initiale du VPC par défaut comprend uniquement un sous-réseau public dans chaque zone de disponibilité alors que la pratique courante est de créer des sous-réseaux publics et privés pour isoler au mieux les instances.
Le VPC par défaut est un bon compromis entre la complexité et la sécurité. Il permet de démarrer rapidement sans se poser de question tout en bénéficiant des avantages de EC2-VPC. Mais pour plus de souplesse, la création d’un VPC personnalisé est obligatoire.
Dans le but de comprendre cette partie est consacrée aux composants clés d’un VPC. Pour les détails techniques, la documentation AWS est en lien.
Sous-réseaux : plage d’adresses IP dans un VPC. Le bloc d’adresse CIDR (Classless Inter-Domain Routing) est un sous-ensemble du bloc CIDR du VPC. Chaque sous-réseau doit résider entièrement dans une zone de disponibilité et ne peut pas s’étendre sur plusieurs zones. Pour diminuer la surface d’attaque des ressources (instances EC2, base de données …), une bonne pratique consiste à utiliser un sous-réseau public pour les ressources qui reçoivent directement du trafic depuis nternet, et un sous-réseau privé pour les autres.
•Public : Si le trafic est acheminé vers une Internet gateway, le sous-réseau est reconnu comme un sous-réseau public. Dans cette zone, pour avoir accès à Internet, les instances doivent posséder une IP publique ou utiliser un proxy.
•Privé : Si un sous-réseau ne comporte pas de route vers la passerelle Internet, il est reconnu comme un sous-réseau privé. L’accès à Internet s’effectue grâce à une NAT gateway ou une NAT instance.
NAT gateway: passerelle de traduction d’adresses réseau pour autoriser les instances dans un sous-réseau privé à se connecter à Internet tout en empêchant l’initialisation de connexions entrantes provenant d’Internet.
NAT instance : instance EC2 ayant le même objectif que les NAT gateway. Contrairement à ces dernières, elles ne prennent pas en charge le trafic IPV6 et ne sont pas managées ce qui demande donc plus de configuration et de maintenance. Il est maintenant conseillé d’utiliser des NAT gateway.
Internet gateway : composant qui permet la communication entre des instances et Internet.
La subtilité réside dans le paramètre “HAMode” qui crée plus ou moins de NAT gateway en fonction de sa valorisation. Bien que les schémas illustrent une région à deux zones de disponibilités, la configuration gère également les régions.
. Le choix de l’adressage réseau est restreint à 10.X.0.0/16 mais rien n’interdit de l’amender pour prendre en compte des besoins plus riches.
Chaque zone de disponibilité AZ dispose de sous-réseaux publics et privés. Par défaut (paramètre HAMode = true), une NAT Gateway est créée dans chaque réseau public de chaque AZ. Les tables de routage des sous-réseaux privés sont donc différentes les unes des autres : une pour sortir par la NAT gateway 1 et l’autre par la NAT gateway 2.
Dans sa version non HA, une seule NAT Gateway est utilisée pour l’ensemble des Availability Zone. Tout le trafic sortant des sous-réseaux privés est donc routé vers cette dernière. Cela est bien évidemment déconseillé en production car la NAT Gateway devient un point de défaillance unique (single point of failure ou SPOF en anglais). De plus, en cas d’une défaillance de l’AZ concernée, l’ensemble des sous-réseaux privés n’a plus accès à Internet.
Mais alors, pourquoi créer un VPC en mode non HA ?
Tout simplement car une NAT gateway coûte cher, à savoir un VPC par environnement (dev, demo, preprod, bench …) la facture peut être salée. Pour ces environnements et selon vos contraintes, il peut être acceptable de troquer de la disponibilité au profit de quelques économies. D’autant plus que les défaillances au niveau des AZ sont rares.
Vous avez à présent les éléments nécessaires pour créer facilement des VPC et ainsi isoler vos applications les unes des autres. En prime, avec le paramètre HAMode = false
Vous pouvez créer vos VPC, y accéder et les gérer à l'aide D'AWS Management Console(offre une interface web que vous pouvez utiliser pour accéder à vos VPC).
Connecter vous a votre compte AWS
https://portal.aws.amazon.com/billing/signup.
Suivez les instructions en ligne.
aller sur AWS Management Console en cliquant sur l’icône
Nous avons une vue globale de ce service
cliquer sur selectionner
Étape 1 : Sélectionner une configuration VPC
Nous allons créer un VPC avec un seul sous-réseau public (la premiere option)
La configuration de ce scénario comprend un Virtual Private Cloud (VPC) avec un seul sous-réseau public et une passerelle Internet pour permettre la communication sur Internet. cette configuration est recommander si vous avez besoin d'exécuter une application Web à un seul niveau et destinée au public, telle qu'un blog ou un simple site Web.Présentation Le schéma suivant illustre les principaux composants pour la configuration de ce scénario
La configuration de ce scénario est la suivante :
• Un Virtual Private Cloud (VPC) avec bloc d'adresse CIDR IPv4 de taille /16 (par exemple : 10.0.0.0/16).Cela permet d'obtenir 65 536 adresses IPv4 privées.
• Un sous-réseau avec bloc d'adresse CIDR IPv4 de taille /24 (par exemple : 10.0.0.0/24). Cela permet d'obtenir 256 dresses IPv4 privées.
• une passerelle Internet ; Celle-ci connecte le VPC à Internet et aux autres services AWS.
• Une instance dotée d'une adresse IPv4 privée dans la plage de sous-réseaux qui permet à l'instance de communiquer avec d'autres instances dans le VPC, et une adresse IPv4 Elastic , c'est-à-dire une adresse IPv4 publique qui permet d'accéder à l'instance depuis Internet.
• Table de routage personnalisée associée au sous-réseau Les entrées de la table de routage permettent aux instances du sous-réseau d'utiliser IPv4 pour communiquer avec d'autres instances du VPC et de communiquer directement via Internet. Un sous-réseau associé à une table de routage comportant une route vers une passerelle Internet est appelé sous-réseau public.
Étape 2 : VPC avec un seul sous-réseau public
VPC créé avec succés
La deuxième étant celle créé par défaut.
Vérification des sous réseaux
Une instance dotée d'une adresse IPv4 privée
une adresse IPv4 Elastic allouer a une instance
Table de routage personnalisée associée au sous-réseau
Après avoir créé un VPC, vous pouvez consulter des informations sur le sous-réseau, la passerelle Internet et les tables de routage. Le VPC que vous avez créé inclut deux tables de routage — une table de routage principale (incluse dans tous les VPC par défaut) et une table de routage personnalisée, créée par l'assistant. La table de routage personnalisée est associée à votre sous-réseau. En d'autres termes,les routes figurant dans cette table déterminent comment le trafic circule vers le sous-réseau. Si vous choisissez d'ajouter un nouveau sous-réseau à votre VPC,il utilisera la table de routage principale par défaut.
Un groupe de sécurité fonctionne comme un pare-feu virtuel contrôlant le trafic vers les instances qui lui sont associées. Pour utiliser un groupe de sécurité, vous devez ajouter les règles entrantes pour contrôler le trafic entrant vers l'instance et les règles sortantes pour contrôler le trafic sortant de votre instance. Pour associer un groupe de sécurité à une instance, vous devez le spécifier lors du lancement de cette dernière.Lorsque vous ajoutez ou supprimez des règles dans votre groupe de sécurité, ces changements sont automatiquement appliqués aux instances associées au groupe. Votre VPC est associé à un groupe de sécurité par défaut. Toute instance qui n'est pas spécifiquement associée à un autre groupe de sécurité lors du lancement est affectée au groupe de sécurité par défaut.Dans cet exercice, vous allez créer un groupe de sécurité (WebServerSG) et le spécifier lors du lancement d'une instance dans votre VPC.
Quand vous ajoutez ou supprimez des règles, elles sont automatiquement appliquées à toutes les instances associées au groupe de sécurité.
Le type de règles que vous ajoutez peut dépendre de l'objectif du groupe de sécurité. Le tableau suivant décrit des exemples de règles pour un groupe de sécurité associé à des serveurs web. Les serveurs web peuvent recevoir du trafic HTTP et HTTPS de toutes les adresses IPv4 et IPv6, et envoyer du trafic SQL ou MySQL vers un serveur de base de données.
Une liste de contrôle d'accès (ACL) réseau est une couche de sécurité facultative pour votre VPC, qui fait office de pare-feu pour le contrôle du trafic entrant et sortant d'un ou plusieurs sous-réseaux. Vous pouvez définir des listes ACL réseau à l'aide de règles similaires à vos groupes de sécurité afin d'ajouter une couche de sécurité supplémentaire à votre VPC, et Permet une seconde couche de sécurité au dessus des groupes de sécurité pour limiter globalement des flux.
Le système de noms de domaine (DNS) est un standard permettant la résolution entre les noms utilisés sur Internet et les dresses IP correspondantes. Un nom d'hôte DNS est un nom attribué de façon unique et absolue à un ordinateur. Il est composé d'un nom d'hôte et d'un nom de domaine. Les serveurs DNS résolvent les noms d'hôte DNS en adresses IP correspondantes.Les adresses IPv4 publiques permettent de communiquer via Internet, tandis que les adresses IPv4 privées permettent de communiquer au sein du réseau de l'instance (EC2-Classic ou VPC).
Il s'agit d'un service régional qui permet d'acheminer des requêtes DNS entre les VPC et le réseau.
Amazon Virtual Private Cloud (Amazon VPC) permet de provisionner une section isolée logiquement du cloud Amazon Web Services (AWS) où lancer des ressources AWS dans un réseau virtuel définis.
Permet un contrôle complet sur l'environnement du réseau virtuel, y compris la sélection de la plage d'adresses IP, la création de sous-réseaux et la configuration des tables de routage et des passerelles réseau.
Facilite personnalisation et la configuration du réseau Amazon VPC. Par exemple, créer un sous-réseau public pour des serveurs Web qui ont accès à Internet et placer les systèmes dorsaux, tels que des bases de données ou des serveurs d'applications, dans un sous-réseau privé sans accès à Internet.
Tirer parti de plusieurs couches de sécurité, y compris des groupes de sécurité et des listes de contrôle d'accès réseau (ACL), pour aider à contrôler l'accès aux instances Amazon EC2 dans chaque sous-réseau.