Devenez un architecte de solutions AWS

Voyons à quoi ressemble la configuration du réseau pour le site web de The Green Earth Post :

Comme vous le voyez, il faut s'assurer que les blocs communiquent entre eux correctement. Le but de ce chapitre est de vous expliquer comment configurer un réseau dans le cloud AWS (encadré en rouge) et, ainsi, mettre en place l’architecture réseau pour le site web de The Green Earth Post.

Je vais également vous présenter tous les composants réseau chez AWS pour vous préparer à la certification. À la fin de la partie trois, vous serez capable de comprendre l’architecture réseau suivante :

Pour faciliter les explications, nous partirons d’un diagramme vierge que nous enrichirons au fur et à mesure des composants que nous étudierons, avec les explications associées. C’est parti !

Configurez les réseaux virtuels dans le cloud AWS

Commençons par les bases. Amazon Virtual Private Cloud (VPC) est le socle du réseau dans un compte AWS. 

En effet, il vous fournit des réseaux virtuels dans lesquels des ressources pourront être déployées et pourront communiquer entre elles et avec l’extérieur.

• Un VPC est créé à partir d’un bloc d'adresse CIDR IPv4 et, optionnellement, d’un bloc d'adresse CIDR IPv6.

• Par région et par compte, plusieurs VPC peuvent être créés.

• Chaque VPC peut couvrir toutes les AZ.

Chaque VPC peut se voir attribuer jusqu’à 5 CIDR (plage d’adresse IPv4), qui ne doivent pas se chevaucher !

• La taille d’un CIDR IPv4 est de /28 (=16 adresses IP) à /16 (=65536 adresses IP).

• Chaque VPC n’est composé que d’adresses IPv4 privées (ci-dessous les plages officielles) et les adresses IPv6 sont toutes publiques.

  • 10.0.0.0/8 : 10.0.0.0 – 10.255.255.255

  •  172.16.0.0/12 : 172.16.0.0 – 172.31.255.255

  • 192.168.0.0/16 : 192.168.0.0 – 192.168.255.255

Certaines ressources auront besoin d’un accès à Internet. Pour cela, les plages d’adresses IP d’un VPC peuvent être découpées en sous-plages. Certaines seront destinées aux ressources avec un accès public à Internet (serveur d’API) et d’autres pour un accès privé (bases de données). Ces sous-plages sont appelées sous-réseaux (subnets) publics ou privés. Chaque sous-réseau réside entièrement et uniquement dans une seule AZ.

Connectez à Internet

Pour cela, il faut lui attribuer une adresse IPv4 publique ! Une passerelle internet (Internet gateway) est un composant de VPC dimensionné horizontalement, redondant et hautement disponible, permettant la communication entre votre VPC et Internet. Créée séparément du VPC, elle prend en charge le trafic IPv4 et IPv6 et ne peut être attachée qu’à un seul VPC et réciproquement.

Toutefois, les passerelles internet, seules, ne permettent pas l'accès à Internet aux sous-réseaux. Vous devez créer une table de routage personnalisée (custom route table) pour chaque sous-réseau et y configurer une route qui dirige le trafic destiné à l'extérieur du VPC vers la passerelle internet.

Par défaut, une table de routage principale est créée et associée automatiquement au VPC, permettant aux instances dans le VPC de communiquer entre elles.

Une ressource installée dans un sous-réseau privé peut avoir besoin d’accès à Internet, par exemple pour télécharger un correctif (patch). Dans une même AZ, installez un périphérique NAT, dans un sous-réseau public, pour autoriser des ressources dans des sous-réseaux privés à se connecter à Internet. Ces instances peuvent communiquer avec des services extérieurs au VPC, mais ne peuvent pas recevoir de demandes de connexion non sollicitées.

2 périphériques NAT existent :

• Instance NAT

• Passerelle NAT

Instance NAT (ancienne génération)

Vous devez créer une instance EC2 (en désactivant les source/destination checks) par AZ à partir d’une AMI pré-configurée pour la lancer en tant qu'instance NAT. Il est possible de créer l’instance avec une adresse IP publique, mais qui risque de changer à chaque redémarrage. Optez pour une adresse IP Elastic ! Une route dans la table de routage du sous-réseau privé doit être créée pour diriger le trafic destiné à Internet vers l’instance NAT. Finalement, une route dans la table de routage du sous-réseau public doit être créée pour diriger le trafic destiné à Internet vers la passerelle internet.

Utiliser une instance NAT comporte plusieurs contraintes que vous devez gérer :

• l’installation et la disponibilité de l’instance EC2 ;

• la bande passante du trafic internet, qui dépend du type d'instance EC2 ;

• les groupes de sécurité ; 

• créer un script pour gérer le basculement entre instances NAT en cas de panne.

Passerelle NAT

C’est la nouvelle génération de périphérique NAT, géré par AWS, qui s’installe dans une AZ au sein d’un sous-réseau public. Vous pouvez lui attacher une adresse IP Elastic, puis une table de routage doit être créée pour le sous-réseau privé de même AZ afin de diriger le trafic destiné à Internet vers cette passerelle. Pour assurer une tolérance aux pannes dans votre VPC, il faut créer une passerelle NAT dans chaque AZ.

Cette passerelle offre de meilleures performances qu’une instance NAT :

• elle prend en charge jusqu'à 5 Gbit/s de bande passante et augmente automatiquement jusqu'à 100 Gbit/s ;

• aucune maintenance à réaliser ;

• aucun groupe de sécurité à gérer ;

• hautement disponible dans la AZ.

Pour les adresses IPv6, une ressource dans un sous-réseau public peut accéder et on peut y avoir accès via Internet si une route vers Internet existe dans la table de routage de ce sous-réseau. Dans le cas d’un sous-réseau privé, seul l’accès vers Internet doit être possible, il faudra créer une route vers une passerelle internet de sortie uniquement (egress-only internet gateway).

Regardez ici comment je crée un VPC et des sous-réseaux publics et privés :

Contrôlez le trafic vers les ressources

Dans la partie 2, nous avons étudié les groupes de sécurité qui jouent le rôle de pare-feu en contrôlant le trafic entrant et sortant d’une ressource. Il est possible d’appliquer un pare-feu au niveau des sous-réseaux grâce à une Liste de Contrôle d'Accès Réseau (Network Access Control List - NACL). NACL est généralement utilisé pour bloquer une adresse IP spécifique au niveau d’un sous-réseau. 

Un NACL par défaut, autorisant tout trafic entrant et sortant, est attaché à tout nouveau sous-réseau.

Entrant

Sortant

*0.0.0.0/0 = n’importe quelle adresse IPv4

Vous pouvez créer un NACL personnalisé avec des règles spécifiques et l’attacher à ce sous-groupe, en détachant celui par défaut car un sous-groupe ne peut avoir qu’un NACL. Les règles sont évaluées en commençant par la règle comportant le numéro le plus bas. Lorsqu'une règle correspond au trafic, elle s'applique même si une règle avec un numéro plus élevé la contredit.

Entrant

Sortant

• Les règles 100 et 110 se contredisent, mais comme 100 est le plus petit numéro, alors cette règle s’applique.

Même chose entre les règles 120 et 130, qui voient la règle 120 s’appliquer.

Pour se connecter à la base de données du site web, le serveur d’API établit une connexion vers l’IP et un port. Il attend une réponse de la base sur un port éphémère choisi dans une plage qui varie selon le système d’exploitation du serveur d’API. 

• Linux : 32768-61000

• Windows Server : 1025-5000

Des règles entrantes et sortantes doivent être configurées dans les NACL pour permettre au serveur d’API et à la base de données de communiquer !

À vous de jouer !

Dans la partie précédente, nous avons installé le serveur d’API et la base de données RDS dans le VPC par défaut. Ceci constitue une mauvaise pratique. Dans cet exercice, nous allons installer ces deux composants dans un nouveau VPC à créer.

Dans un premier temps, il faut créer un VPC comme vous l’avez vu dans la section “Configurez les réseaux virtuels dans le cloud AWS”.

Puis, en utilisant ce même VPC, il faudra :

• créer un groupe de sécurité avec accès internet ;

• créer un rôle IAM qui doit être assumé par l’instance EC2, avec une politique qui permet de décrire les instances de bases de données RDS “DescribeDBInstances” ;

• créer une instance EC2, pour héberger le serveur d’API, avec : 

  • une image Amazon Linux,

  • type t2.micro comme type d’instance,

  • le groupe de sécurité créé,

  • un profil d’instance correspondant au rôle IAM créé,

  • et un script que vous retrouverez dans le registre GitHub à insérer dans la section données utilisateur ;

• vérifier que le serveur d’API est disponible sur Internet en testant le point de terminaison /api/health ;

• créer un groupe de sécurité qui accepte le trafic entrant sur le port 3306 pour le groupe de sécurité du serveur d’API ;

• créer une base de données avec le service Amazon RDS, avec les caractéristiques suivantes : 

  • méthode de création : Standard ;

  • moteur SQL : MySQL ;

  • modèle : Offre gratuite ;

  • identifiant d'instance : thegreenearthpost ;

  • identifiant principal : admin (vous pouvez mettre autre chose) ;

  • mot de passe : password (vous pouvez mettre autre chose) ;

  • réseau : 

    • VPC que l’on vient de créer,

    • groupe de sécurité créé ;

  • authentification par mot de passe ;

  • création d’une base de données nommé thegreenearthpost.

Vous pouvez vérifier si vous l’avez fait correctement en regardant ce screencast :

Évolution du diagramme réseau

Félicitations ! Vous avez réussi à configurer le réseau du site web de manière à ce que tous les composants puissent communiquer entre eux. Voici à quoi cela ressemble maintenant :

En résumé

• Un VPC est défini à partir de blocs d’adresses CIDR IPv4 et IPv6 et peut être découpé en sous-réseaux publics et privés.

• Une passerelle internet et les périphériques NAT permettent à un sous-réseau public d’avoir un accès internet.

• Un groupe de sécurité est un pare-feu niveau ressource. Un NACL est un pare-feu niveau sous-réseau. Voici un tableau comparatif : 

Voyons dans le prochain chapitre comment faire communiquer des ressources hébergées dans différents VPC.