Qu’est ce qu’un VPC ? À quoi ça sert ? Dois-je en créer un ? Par où commencer ? Que de questions techniques pour démarrer un projet AWS.

Le VPC (Virtual Private Cloud) 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. Il est vrai que pour nous développeurs, le réseau n’est pas notre zone de confort !

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é, cet article fournit un template CloudFormation implémentant les bonnes pratiques d’un VPC pour démarrer sereinement vos projets.

Pourquoi créer son VPC ?

Tout d’abord, 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é.

Plus précisément, dans quel cas utiliser son propre VPC ?
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.

Pour faciliter cette tâche souvent complexe, vous trouverez un template CloudFormation dans le paragraphe ”Template CloudFormation”.

Composants d’un VPC

Dans le but de comprendre le template CloudFormation, 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 Internet, 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.

Template CloudFormation

Chose promise chose due, voici le template CloudFormation que j’utilise pour créer des VPC : essayez le en un clic sur la console AWS. 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 à trois AZ telle que l’Irlande.

Ce template est inspiré en partie du site cloudonaut.io et est adapté à nos contraintes. 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.

Version High Availability

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.

Version non High Availability

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 SPOF. 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 : 35$ par mois pour une AZ en Irlande, soit la bagatelle de 105$ pour couvrir les trois AZ. Si vous optez pour une isolation complète, à 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 en développement, faites plaisir à votre portefeuille et ne soyez plus freinés par les coûts.