Construire son réseau sur AWS

Introduction

Dans les chapitres précédents, nous avons disséqué la gouvernance multicomptes, l’Infrastructure as Code et la posture sécurité. Reste à bâtir la colonne vertébrale qui transporte les paquets, isole les environnements et dirige chaque requête vers la bonne ressource : le réseau. AWS fournit un arsenal d’outils, du simple VPC privé jusqu’à la diffusion mondiale avec des latences à deux chiffres. Les quatre présentent les principes essentiels pour concevoir, sécuriser, raccorder et optimiser vos flux réseau.

Amazon VPC : créer et segmenter son réseau AWS

Un Virtual Private Cloud dépasse le simple regroupement d’instances : il définit l’espace réseau de votre application, isole les composants sensibles et contrôle la circulation du trafic. Sa conception repose sur trois décisions : le bloc d’adresses à réserver, la façon de le découper en sous-réseaux et les règles qui régissent les échanges entre ces zones.

1. Choisir l’espace d’adressage : l’art de penser large sans gaspiller

Un bloc CIDR doit être choisi avec méthode : il servira de référence lorsque vous devrez raccorder le VPC à votre réseau interne, à un VPC partenaire ou à un nouvel environnement dans la même région. Commencez donc par dresser l’inventaire des plages déjà utilisées. Si le réseau du siège occupe tout le 10.0.0.0/8, sélectionnez plutôt un espace comme 172.20.0.0/16 ; vous éviterez ainsi tout chevauchement d’adresses quand viendra le moment de créer des liaisons privées ou des VPN.

L’autre écueil est de sous-dimensionner. Un /24 (256 IP) paraît suffisant pour un petit service, jusqu’à ce qu’un cluster Kubernetes réclame trois fois plus d’adresses pour...

Sécurisation réseau : Security Group, NACL et Bastion Host

Dès qu’un VPC commence à héberger des applications réelles, la question n’est plus seulement de savoir « où » circulent les paquets, mais « qui » a le droit d’en émettre et « quand » ils peuvent franchir une frontière. Sur AWS, cette police du trafic s’exerce à deux profondeurs (l’interface réseau et le sous-réseau) puis s’achève par une porte d’accès humain soigneusement contrôlée : le bastion host ou, de plus en plus, le tunnel chiffré de Systems Manager.

1. Security Group : la garde rapprochée de chaque ressource

Un security group se comporte comme un pare-feu à états collé à chaque interface (ENI) ou à chaque service managé capable de vivre dans un VPC. On spécifie la provenance du flux entrant, le port concerné et, optionnellement, le protocole ; si la requête est admise, la réponse sortante passe sans qu’il soit nécessaire d’ouvrir la règle inverse. Cette logique « stateful » simplifie la déclaration : autoriser HTTPS depuis le load balancer vers les instances d’application suffit ; les paquets retour trouveront naturellement leur chemin.

La syntaxe encourage la lisibilité : on référence un autre security group plutôt qu’une...

VPN, Direct Connect et Transit Gateway : connecter AWS au reste du monde

La frontière d’un VPC ne doit pas rester imperméable ; tôt ou tard, vos applications devront dialoguer avec un datacenter, un siège social ou un second VPC. AWS propose trois mécanismes complémentaires pour établir ces liaisons : le VPN site-à-site, le circuit privé Direct Connect et l’orchestrateur central Transit Gateway. Chacun répond à un besoin précis ; les combiner permet d’obtenir à la fois la souplesse d’Internet et la prévisibilité d’un lien dédié.

1. Site-à-site VPN : démarrer en quelques minutes

Le VPN AWS repose sur un tunnel IPsec établi entre votre passerelle on-premise (Customer Gateway) et la passerelle virtuelle du VPC (Virtual Private Gateway) ou, plus récemment, un attachement Transit Gateway. La mise en service se limite à quelques champs : l’adresse IP de la passerelle cliente, le type de BGP ou de routage statique, le pré-partagé IKE. Deux tunnels redondants sont créés par défaut ; si l’un tombe, le trafic bascule en moins de trente secondes. La bande passante est plafonnée à 1,25 Gb/s par tunnel, la latence dépend du chemin Internet, et le coût se contente d’un tarif à l’heure plus...

Load Balancers, Route 53 et Global Accelerator : optimiser la distribution du trafic

Une fois le réseau posé et les interconnexions établies, reste à guider chaque requête vers la bonne cible, à absorber les pointes de charge et à maintenir la qualité de service quand un nœud, une zone ou même une région devient indisponible. Sur AWS, la répartition du trafic repose sur trois niveaux complémentaires : le load balancing régional, la résolution DNS intelligente et une accélération réseau globale.

1. Équilibrer dans la région : de l’ALB au NLB

Au premier niveau, Elastic Load Balancing fournit trois variantes. L’Application Load Balancer pilote les flux HTTP et HTTPS. Il déchiffre TLS, inspecte l’en-tête Host ou le chemin de l’URL, puis oriente la requête vers la cible adéquate : un groupe d’instances, des tâches ECS ou des pods EKS. Il sert également de point d’authentification ; en activant l’intégration OIDC, on peut forcer un utilisateur à passer par SSO avant de toucher la moindre page.

Le Network Load Balancer, lui, se concentre sur la performance brute. Placé au niveau du transport, il gère les protocoles TCP ou UDP sans inspecter le contenu. Sa latence est quasi nulle et il conserve l’adresse IP source jusqu’à la cible, indispensable pour certains schémas de chiffrement point-à-point ou pour l’enregistrement...