Les bases des réseaux cloud

Une application cloud a besoin d’un réseau en plus des ordinateurs. Un réseau virtuel est un réseau privé défini par logiciel. Tu choisis ses adresses et ses connexions sans installer de commutateurs ni de câbles. Des réseaux distincts permettent de séparer le travail en production des tests.

Lire les adresses

AWS appelle son réseau Amazon VPC ; Microsoft utilise Azure Virtual Network, ou VNet ; Google Cloud utilise réseau VPC. Un VPC AWS ou un VNet Azure possède une plage d’adresses globale. Ses sous-réseaux en prélèvent des plages plus petites. Un VPC Google Cloud n’a pas de plage globale : chaque sous-réseau reçoit la sienne.

L’écriture 10.0.0.0/16 est une notation CIDR. Le nombre après la barre oblique indique le nombre de bits initiaux fixes de l’adresse. Plus ce nombre est petit, plus la plage est grande. Ce /16 couvre les adresses de 10.0.0.0 à 10.0.255.255 : 65 536 adresses. Les blocs privés sont 10.0.0.0/8, 172.16.0.0/12 et 192.168.0.0/16. L’Internet public ne route pas ces adresses privées.

Un sous-réseau fournit des adresses à une partie d’un réseau. Par exemple, 10.0.3.0/24 couvre les adresses de 10.0.3.0 à 10.0.3.255. Une base de données qui s’y trouve pourrait recevoir 10.0.3.20. Des sous-réseaux distincts pour le web, les applications et les bases de données permettent aux équipes d’appliquer des routes et des règles de sécurité différentes. Les plages des sous-réseaux d’un même réseau ne doivent pas se chevaucher. Les fournisseurs réservent des adresses pour les services réseau : AWS et Azure en réservent cinq par sous-réseau ; Google Cloud en réserve quatre dans la plage principale d’un sous-réseau. Un sous-réseau de 256 adresses laisse donc 251 adresses sur AWS ou Azure.

Répartir les ressources entre les zones

Prenons une boutique sur AWS qui utilise 10.0.0.0/16. Dans la zone A, elle place les serveurs web dans 10.0.1.0/24, les serveurs d’application dans 10.0.2.0/24 et sa base de données dans 10.0.3.0/24. Pour continuer à servir les utilisateurs en cas de panne d’une zone, elle reproduit les niveaux dans la zone B avec 10.0.11.0/24, 10.0.12.0/24 et 10.0.13.0/24. Les sous-réseaux séparent les rôles ; l’utilisation de deux zones sépare les lieux de défaillance. La création de plusieurs sous-réseaux dans une seule zone ne le permettrait pas.

Connecter les réseaux de manière délibérée

Les réseaux virtuels assurent une isolation logique vis-à-vis des autres clients et des autres réseaux. Pour communiquer, il faut un chemin réseau et une autorisation. Une connexion d’appairage permet à deux réseaux de communiquer par adresse privée sur le réseau du fournisseur. L’appairage peut relier des régions, des comptes, des abonnements ou des projets différents, mais les plages d’adresses ne doivent pas se chevaucher.

Vérifie les plages des bureaux et des partenaires avant de choisir celles du cloud. Si un bureau et un VPC utilisent tous deux 10.0.0.0/16, une destination comme 10.0.3.20 pourrait appartenir à l’un ou à l’autre. Choisir 10.1.0.0/16 pour le cloud évite ce conflit. Corriger un plan d’adressage après le déploiement des serveurs peut perturber leur fonctionnement.

L’appairage n’est pas transitif. Si A est appairé à B et B à C, A a toujours besoin de sa propre connexion à C. De plus, un chemin privé ne chiffre pas les données : utilise le chiffrement à cette fin. La création du réseau virtuel lui-même est gratuite chez ces fournisseurs ; les passerelles, les adresses IPv4 publiques et le transfert de données peuvent entraîner des frais.

Une adresse de destination indique à un réseau où le trafic cherche à aller. Une table de routage lui indique la prochaine étape à laquelle envoyer ce trafic. Le routage fournit un chemin ; les règles de sécurité déterminent si le trafic peut l’emprunter.

Choisir la route correspondante

Chaque route associe une plage de destination à une cible. Une route locale relie les sous-réseaux d’un même réseau virtuel. La route par défaut IPv4, 0.0.0.0/0, correspond à toutes les adresses, mais une route correspondante plus précise est prioritaire. Un numéro de préfixe plus grand après la barre oblique indique une plage plus précise.

Supposons qu’un sous-réseau d’application AWS utilise ces routes :

Une requête de 10.0.2.15 vers la base de données 10.0.3.20 correspond aux deux plages. Le /16 est plus précis que le /0, la requête reste donc locale. Une requête vers le serveur de mises à jour 203.0.113.50 ne correspond qu’à la route par défaut et va vers la passerelle NAT. Les règles de sécurité doivent autoriser chaque connexion.

Autoriser délibérément l’accès public

Sur AWS, une passerelle Internet relie un VPC à Internet. Un sous-réseau dont la route par défaut mène à cette passerelle est un sous-réseau public. Sa plage d’adresses peut néanmoins être une plage privée comme 10.0.1.0/24. « Public » décrit son routage, pas la notation de son adresse.

Pour atteindre un serveur depuis Internet, trois éléments doivent être réunis : un chemin vers Internet, une adresse IP publique sur le serveur ou sur un répartiteur de charge placé devant lui, et des règles de sécurité autorisant la connexion. Un sous-réseau AWS peut être public alors qu’un serveur donné de ce sous-réseau n’a pas d’accès public direct.

Azure et Google Cloud fournissent des chemins intégrés vers Internet sans passerelle Internet à créer comme sur AWS. Leurs règles de sécurité et leur adressage public restent importants. Un sous-réseau privé, au sens général, ne fournit aux utilisateurs d’Internet aucun chemin direct vers ses ressources. Il est donc utile pour les bases de données et les serveurs d’application internes.

Donner un accès sortant aux serveurs privés

Une passerelle NAT permet à un serveur privé d’initier une connexion Internet. Elle remplace l’adresse source privée par une adresse publique, suit la connexion et remet la réponse au bon serveur. Elle n’accepte pas une nouvelle connexion initiée par un utilisateur d’Internet vers ce serveur privé.

Sur AWS, une passerelle NAT publique se trouve dans un sous-réseau public. La route par défaut du sous-réseau privé d’application pointe vers elle, et le sous-réseau de la passerelle NAT possède une route vers la passerelle Internet. L’application peut récupérer des mises à jour tandis que son sous-réseau de base de données, qui ne possède qu’une route locale, n’a aucun chemin vers Internet. Azure NAT Gateway s’attache à un sous-réseau ; Google Cloud propose Cloud NAT. Les services NAT facturent la durée de fonctionnement et le traitement des données.

Vérifier les paramètres par défaut du fournisseur

Les sous-réseaux des VPC AWS par défaut sont publics et attribuent normalement des adresses publiques aux nouvelles instances. Un VPC que tu crées toi-même nécessite l’ajout d’une passerelle Internet. Les adresses publiques statiques réservées restent stables ; AWS appelle l’une d’elles Elastic IP. Les adresses attribuées automatiquement peuvent changer après l’arrêt et le redémarrage d’une machine. Depuis février 2024, AWS facture chaque adresse IPv4 publique, y compris celles qui sont utilisées.

Azure emploie « sous-réseau privé » précisément pour un sous-réseau dont l’accès sortant par défaut est désactivé. Il a besoin d’une méthode de sortie explicite, comme NAT ou une adresse IP publique attribuée, et ce paramètre ne bloque pas à lui seul le trafic entrant. Le portail crée par défaut des sous-réseaux privés. Pour la version de l’API publiée après le 31 mars 2026, les nouveaux réseaux virtuels reçoivent aussi des sous-réseaux privés par défaut ; les versions antérieures de l’API conservent l’ancien comportement et les réseaux existants ne sont pas modifiés.

Un service managé peut fonctionner en dehors de ton réseau virtuel. Un point de terminaison est l’adresse que les clients utilisent pour l’atteindre, généralement par un nom DNS. Le chemin réseau du point de terminaison et les permissions sur les données du service répondent à des besoins différents.

Distinguer l’accès public de l’accès aux données

Un point de terminaison public se résout en adresse IP publique. Les clients sur Internet peuvent tenter de s’y connecter, mais cela ne rend pas les données stockées publiques. Les informations d’identification et les permissions contrôlent normalement l’accès. Certains services autorisent aussi l’accès anonyme lorsqu’ils sont configurés à cette fin ; une erreur de permission dans le stockage en mode objet peut exposer des fichiers.

Utilise HTTPS, qui repose sur le chiffrement TLS, pour le trafic de service. Lorsque c’est possible, impose HTTPS et limite les adresses ou les réseaux autorisés à se connecter. L’accessibilité publique, les permissions d’accès et le chiffrement sont des paramètres distincts. Une application autorisée peut utiliser un point de terminaison public en toute sécurité, tandis qu’un service mal configuré peut laisser fuiter des données même sur un réseau privé.

Ajouter une adresse privée

Un point de terminaison privé donne à un service compatible une adresse privée dans ton réseau. Le fournisseur crée une interface réseau dans un sous-réseau et le trafic vers cette adresse reste sur son réseau.

Les systèmes des bureaux peuvent aussi atteindre les points de terminaison privés par un VPN ou une connexion dédiée. Les réseaux appairés peuvent les atteindre lorsque les paramètres de routage, DNS et de sécurité permettent ce chemin.

Faire correspondre le nom du service au point de terminaison

Les applications se connectent généralement à l’aide d’un nom de service, et non d’une adresse IP codée en dur. Le DNS privé fait correspondre ce nom à l’adresse privée du point de terminaison à l’intérieur du réseau. Par exemple, un client interne pourrait résoudre le nom de son service de stockage en 10.0.2.40. Les clients extérieurs peuvent toujours recevoir l’adresse publique.

La seule création du point de terminaison ne modifie pas la réponse DNS reçue par chaque client. Si un client interne continue à résoudre le nom en adresse publique, il continue à emprunter le chemin public. Relie la zone DNS privée au réseau et prévois un transfert DNS pour les clients sur site. Pour imposer un accès privé, désactive ou restreins aussi le point de terminaison public du service. La création d’un point de terminaison privé laisse les paramètres d’accès public en place.

Reconnaître les options associées

Un point de terminaison de passerelle AWS atteint S3 ou DynamoDB au moyen d’une entrée de table de routage. Il ne crée pas l’interface réseau privée utilisée par un point de terminaison d’interface et n’entraîne aucun frais de point de terminaison supplémentaire. Un point de terminaison de service Azure identifie un sous-réseau autorisé et transporte son trafic de service sur le réseau Microsoft, mais le service conserve une adresse IP publique. Private Google Access permet aux machines qui possèdent des adresses internes d’accéder aux API et aux services Google.

Prenons un serveur d’analyse qui lit chaque jour 500 Go depuis un stockage en mode objet régional. Si ces lectures passent par NAT, le service NAT traite les 500 Go. Sur AWS, un point de terminaison de passerelle S3 adapté fait passer ce trafic de service par la route du point de terminaison sans frais supplémentaires pour celui-ci. Les points de terminaison d’interface et privés ont leurs propres frais : compare donc le chemin complet et ses coûts. Le point de terminaison modifie la connectivité ; TLS assure toujours le chiffrement en transit.

Un serveur peut disposer d’une route vers un autre réseau et refuser quand même son trafic. Un groupe de sécurité agit comme un pare-feu virtuel pour les ressources. Les règles entrantes contrôlent le trafic qui arrive à une ressource ; les règles sortantes contrôlent le trafic qui la quitte.

Lire une règle

Pour TCP ou UDP, lis ensemble le protocole, le port et la source ou la destination. La règle « autoriser TCP 443 depuis 198.51.100.7/32 » autorise le trafic HTTPS depuis une seule adresse. La source 0.0.0.0/0 désigne toutes les adresses IPv4. Une source entrante peut aussi désigner un groupe de sécurité : l’accès suit ainsi le rôle d’un serveur lorsque son adresse IP change.

Parmi les ports utiles figurent SSH 22, RDP 3389, HTTP 80, HTTPS 443, DNS 53, MySQL 3306, PostgreSQL 5432 et Microsoft SQL Server 1433. ICMP, utilisé par ping, possède des types de messages au lieu de ports TCP ou UDP.

Comprendre le filtrage avec suivi d’état

Un filtre avec suivi d’état mémorise les connexions autorisées. Si une règle entrante autorise une nouvelle connexion HTTPS, les réponses sont autorisées à sortir sans règle sortante distincte. Cela n’autorise pas le serveur à initier une connexion sortante sans rapport avec celle-ci. Les nouvelles connexions nécessitent toujours leur propre autorisation.

Les groupes de sécurité AWS s’attachent aux interfaces réseau. Plusieurs ressources peuvent partager un groupe et une ressource peut avoir plusieurs groupes. Leurs règles d’autorisation se combinent : le trafic passe si une règle applicable l’autorise. L’ordre des règles n’a aucun effet et aucune règle de refus explicite ne peut annuler une autorisation générale. Un groupe nouvellement créé n’autorise aucun trafic entrant et autorise le trafic sortant jusqu’à sa modification.

Construire une chaîne de rôles autorisés

Pour une application à trois niveaux, donne à chaque niveau uniquement les connexions entrantes dont il a besoin :

1. Le répartiteur de charge autorise TCP 443 depuis les utilisateurs d’Internet.
2. Les serveurs web autorisent TCP 443 depuis le groupe du répartiteur de charge. L’administration sur TCP 22 est limitée à l’adresse du bureau de l’administrateur.
3. La base de données MySQL autorise TCP 3306 depuis le groupe des serveurs web.

Lorsqu’un serveur web de remplacement rejoint le groupe des serveurs web, il obtient l’accès prévu à la base de données sans nouvelle règle fondée sur l’adresse. Une requête directe d’Internet vers la base de données échoue, car sa source n’est pas autorisée. Si un second groupe attaché autorise largement ce même port de base de données, cette autorisation générale s’applique néanmoins ; aucun refus plus restrictif dans le premier groupe ne peut l’annuler.

Comparer les filtres des fournisseurs

Un groupe de sécurité réseau Azure, ou NSG, peut être attaché à un sous-réseau, à une interface réseau ou aux deux. Les priorités personnalisées vont de 100 à 4 096, avant les règles intégrées par défaut aux priorités 65 000, 65 001 et 65 500. Les règles entrantes par défaut autorisent le trafic du réseau virtuel et celui du répartiteur de charge Azure, puis refusent les autres trafics entrants. Google Cloud sélectionne les machines cibles à l’aide de balises ou de comptes de service ; ses règles implicites refusent le trafic entrant et autorisent le trafic sortant.

Applique le principe du moindre privilège : autorise uniquement les ports nécessaires depuis le plus petit ensemble de sources utile. Ouvrir SSH ou RDP à tout Internet expose les services de connexion administratifs à des attaques automatisées. Les solutions d’accès managées comprennent AWS Systems Manager Session Manager, Azure Bastion et Google Cloud Identity-Aware Proxy. Un filtre de port ne peut pas reconnaître une attaque cachée dans un trafic HTTPS autorisé ; les défenses de l’application et les contrôles d’authentification protègent cette couche.

Une liste de contrôle d’accès réseau AWS filtre le trafic qui franchit la frontière d’un sous-réseau. Elle s’applique à toutes les ressources de ce sous-réseau. Chaque sous-réseau possède une liste de contrôle d’accès réseau et une même liste peut servir à plusieurs sous-réseaux.

Suivre la première règle correspondante

Les règles des listes de contrôle d’accès réseau peuvent autoriser ou refuser le trafic. AWS les vérifie en commençant par le numéro le plus bas et s’arrête à la première correspondance. Une règle finale * refuse le trafic sans correspondance. La liste par défaut du VPC autorise le trafic entrant et sortant ; une liste personnalisée nouvellement créée refuse le trafic jusqu’à ce que tu ajoutes des règles d’autorisation.

Supposons que la règle 100 autorise TCP 443 depuis toutes les adresses IPv4, tandis que la règle 110 refuse le trafic depuis 203.0.113.0/24. Une requête de 203.0.113.77 vers le port 443 correspond d’abord à la règle 100 et passe. Le refus placé plus loin n’est jamais appliqué. Déplace ce refus à la règle 90 pour bloquer la plage avant l’autorisation générale HTTPS.

Suivre la réponse comme un paquet distinct

Une liste de contrôle d’accès fonctionne sans suivi d’état : elle ne mémorise pas qu’une connexion a été autorisée. Une requête web utilise le port de destination 443 du serveur, mais la réponse revient vers le port temporaire, ou éphémère, du client. Il peut s’agir d’un numéro élevé comme 50432.

Pour un site web dont la route et le groupe de sécurité fonctionnent :

1. Un client envoie une requête depuis son port temporaire vers le port 443 du serveur.
2. La liste du sous-réseau autorise le paquet entrant à l’aide de sa règle HTTPS.
3. Le serveur répond vers le port temporaire du client.
4. La liste vérifie indépendamment ce port de destination pour le trafic sortant.

Une règle sortante qui n’autorise que le port de destination 443 ne couvre pas cette réponse. Celle-ci nécessite une autorisation sortante qui couvre son port de destination ; TCP 1024–65535 est une large plage de ports éphémères couramment utilisée. La plage nécessaire dépend des clients et du trafic pris en charge. L’autorisation d’un groupe de sécurité avec suivi d’état ne dispense pas de la décision distincte de la liste de contrôle d’accès.

Comparer les deux couches AWS

Le trafic entrant d’Internet doit franchir les deux couches. Le trafic entre deux ressources d’un même sous-réseau ne franchit pas sa frontière : la liste de ce sous-réseau ne le filtre donc pas. Les groupes de sécurité des ressources continuent à s’appliquer.

Utiliser des couches indépendantes

La défense en profondeur limite les dommages causés par un paramètre erroné. Les groupes de sécurité donnent à chaque rôle applicatif des permissions précises. Les listes de contrôle d’accès ajoutent des garde-fous pour tout le sous-réseau, par exemple le refus d’une plage connue comme malveillante. Les pare-feu des systèmes d’exploitation, les pare-feu réseau managés, les pare-feu applicatifs web, TLS et les contrôles d’identité protègent d’autres parties du chemin. Les journaux de flux enregistrent les flux réseau autorisés et rejetés ; Amazon Inspector aide à identifier les vulnérabilités des charges de travail et les expositions involontaires.

Azure ne possède pas de liste de contrôle d’accès réseau distincte comme AWS : les groupes de sécurité réseau des sous-réseaux et des interfaces assurent ces couches, et les deux effectuent un suivi d’état. Pour le trafic entrant Azure, le groupe du sous-réseau puis celui de l’interface doivent l’autoriser. Google Cloud utilise des règles de pare-feu VPC avec suivi d’état et des politiques de pare-feu plus larges, notamment des politiques d’organisation et de dossier.

Les personnes retiennent des noms comme www.example.com ; les ordinateurs envoient le trafic à des adresses IP. Le DNS, système de noms de domaine, relie les deux. Les fournisseurs cloud hébergent des enregistrements au moyen d’Amazon Route 53, d’Azure DNS et de Google Cloud DNS.

Suivre la recherche d’un nom

Un client demande une adresse à un résolveur. Si celui-ci n’a pas de réponse en cache, il demande à un serveur racine où trouver les serveurs de .com. Ces serveurs indiquent les serveurs de noms faisant autorité pour le domaine. Un serveur faisant autorité contient les enregistrements du domaine et renvoie la réponse, que le résolveur met en cache pour les clients suivants. Route 53 attribue quatre serveurs de noms faisant autorité à une zone hébergée publique. Le client se connecte ensuite à l’adresse renvoyée. Le DNS ne transporte pas le trafic applicatif du site web.

Une zone est l’ensemble managé des enregistrements d’un domaine. Pour utiliser la zone publique d’un nouveau fournisseur, configure les serveurs de noms de ce fournisseur auprès du bureau d’enregistrement du domaine. L’hébergement de zone et l’enregistrement de domaine sont des services distincts : Route 53 propose les deux, tandis qu’Azure DNS héberge des zones sans vendre d’enregistrements de noms de domaine.

Choisir l’enregistrement

Le sommet de zone est le domaine seul, comme example.com. Un CNAME standard ne peut pas y être placé, car le sommet doit aussi contenir des enregistrements NS et SOA. Les enregistrements d’alias Route 53 et les ensembles d’enregistrements d’alias Azure peuvent faire pointer les enregistrements compatibles du sommet vers des ressources cloud et suivre les changements de leurs adresses.

Tenir compte des réponses en cache

La durée de vie d’un enregistrement indique le nombre de secondes pendant lesquelles un résolveur peut mettre la réponse en cache. Supposons qu’un résolveur mette en cache à 9 h 55 une réponse dont la durée de vie est de 3 600 secondes. Modifier l’enregistrement à 10 h 00 n’efface pas cette copie : elle peut rester valide jusqu’à 10 h 55. Réduis la durée de vie à 300 secondes au moins une ancienne durée de vie avant une migration prévue, afin que les anciennes copies à longue durée de vie aient le temps d’expirer. La réduire au moment même de la migration ne peut pas raccourcir la durée de vie des copies déjà en cache.

Les politiques de routage DNS influencent les réponses aux recherches. Le routage simple donne une réponse directe. Le routage pondéré donne des réponses selon les proportions choisies, par exemple 90 % pour la version actuelle et 10 % pour une nouvelle version ; le routage fondé sur la latence favorise la latence mesurée la plus faible ; le routage par géolocalisation choisit selon l’emplacement de l’utilisateur ; le routage par basculement passe d’un point principal à un point de secours lorsque les contrôles d’état indiquent une défaillance. Chaque système de contrôle d’état Route 53 effectue normalement une vérification toutes les 30 secondes. Azure Traffic Manager et Google Cloud DNS proposent aussi des options de routage fondées sur le DNS.

Pour une boutique dont le site principal est à Francfort et le site de secours en Irlande, l’échec d’un contrôle d’état du site principal dirige les nouvelles réponses vers le site de secours. Les réponses déjà en cache restent valides jusqu’à leur expiration ; une durée de vie courte, par exemple 60 secondes, réduit cette attente. De même, le routage pondéré répartit les réponses DNS, pas des nombres exacts d’utilisateurs ou de requêtes applicatives : une réponse en cache peut servir à de nombreux utilisateurs. Un répartiteur de charge agit sur le trafic entrant à une autre couche.

Résoudre les noms internes

Une zone DNS privée fournit des réponses aux réseaux virtuels qui lui sont reliés. Elle peut faire correspondre db.internal.example.com à l’adresse privée d’une base de données ou diriger un nom de service vers un point de terminaison privé. Les clients sur site ont besoin d’un chemin de transfert DNS adapté sur leur VPN ou leur connexion dédiée, à l’aide de solutions comme les points de terminaison Route 53 Resolver ou Azure DNS Private Resolver. Un tunnel réseau fonctionnel ne suffit pas à indiquer à un résolveur de bureau où chercher les noms privés du cloud.

Route 53 et Azure DNS publient des accords de niveau de service garantissant une disponibilité de 100 % pour leurs services DNS. Un accord de niveau de service est un engagement contractuel ; une réponse en cache peut néanmoins pointer vers un serveur d’application indisponible.

Un réseau de diffusion de contenu, ou CDN, conserve des copies temporaires du contenu à proximité des utilisateurs. Son origine contient les fichiers originaux ou produit les réponses de l’application. Amazon CloudFront, Azure Front Door et Google Cloud CDN fournissent ce service grâce à des emplacements périphériques dans le monde entier.

Suivre une requête

Le navigateur résout le nom du CDN et se connecte à un emplacement périphérique proche. CloudFront peut diriger les utilisateurs à l’aide de réponses DNS ; Azure Front Door et Google Cloud CDN utilisent l’adressage anycast : plusieurs emplacements annoncent la même adresse IP et le routage dirige les utilisateurs vers un emplacement proche. Un emplacement périphérique n’est pas une région cloud complète, et les fournisseurs exploitent bien plus d’emplacements périphériques que de régions.

Un succès de cache se produit lorsque l’emplacement périphérique possède une copie utilisable et encore valide et la sert. En cas de défaut de cache, il récupère le contenu à l’origine, le renvoie et peut le mettre en cache pour les requêtes suivantes. Les images, scripts, feuilles de style, fichiers à télécharger et vidéos s’y prêtent souvent bien, car de nombreux utilisateurs demandent le même contenu.

Mesurer l’avantage

Les requêtes sur de longues distances prennent plus de temps à chaque aller-retour réseau. Une page consultée depuis Sydney nécessite quatre allers-retours successifs vers son origine à Francfort. À 250 ms par trajet, elle attend 1 000 ms pour ces trajets. Avec un emplacement périphérique à Sydney nécessitant 15 ms par trajet, les quatre trajets prennent 60 ms. Cet exemple mesure le délai des allers-retours, pas le temps complet de chargement de la page.

Le taux de succès du cache est :

Avec 9 200 succès sur 10 000 requêtes, le taux est de 92 %. Dans cet exemple simple, les 800 défauts atteignent l’origine. Un taux de succès élevé réduit le travail de l’origine et les données qu’elle envoie, ce qui aide lors d’une hausse soudaine du nombre de visiteurs.

Contrôler la fraîcheur du contenu

La durée de vie d’un CDN contrôle pendant combien de temps le contenu peut être réutilisé. L’origine peut envoyer Cache-Control: max-age=86400, ce qui autorise une journée de mise en cache, ou les paramètres du CDN peuvent contrôler cette durée. Modifier un fichier à l’origine ne remplace pas immédiatement les copies en cache encore valides.

Pour publier une correction urgente, invalide ou purge le chemin mis en cache. Une autre méthode consiste à publier un nouveau nom de fichier, comme app.v2.js, et à mettre à jour la page pour qu’elle le demande. Le nouveau nom désigne un objet différent. Empêche le partage des pages personnalisées, comme une page de compte ou un panier d’achat, en tant que contenu mis en cache publiquement. Même lorsqu’une réponse ne peut pas être mise en cache, l’emplacement périphérique peut améliorer sa transmission en terminant la connexion TLS à proximité et en réutilisant les connexions vers l’origine.

Distinguer la mise en cache des autres services réseau

Les répartiteurs de charge peuvent être régionaux ou mondiaux. Global Accelerator fournit des adresses anycast fixes et peut convenir au trafic de jeux ou de communications vocales qui ne bénéficie pas de la mise en cache de contenu web.

L’emplacement périphérique peut aussi appliquer des certificats HTTPS et des règles de pare-feu applicatif web. Son vaste réseau absorbe de nombreuses attaques DDoS ; CloudFront inclut AWS Shield Standard. Les restrictions à l’origine, comme le contrôle d’accès à l’origine de CloudFront pour S3, peuvent empêcher les utilisateurs de contourner le CDN. Les frais dépendent principalement des données transmises et du nombre de requêtes. Les utilisateurs déjà proches de l’origine ou les applications dont les réponses sont presque toutes uniques bénéficient moins de la mise en cache. Les copies périphériques sont temporaires et peuvent être retirées du cache : l’origine a donc toujours besoin de son propre stockage fiable et de sa propre sauvegarde.

Un bureau peut avoir besoin d’utiliser une application à une adresse cloud privée. Un réseau hybride relie les réseaux sur site aux réseaux cloud. Un VPN, ou réseau privé virtuel, transporte ce trafic dans un tunnel chiffré sur l’Internet public.

Choisir ce qui se connecte

Un VPN site à site connecte tout un réseau de bureau ou de centre de données. Un routeur ou un pare-feu compatible VPN gère le tunnel pour ce site. Un VPN point à site, ou VPN d’accès distant, connecte un appareil individuel équipé d’un logiciel client. AWS Client VPN et les connexions point à site d’Azure VPN Gateway prennent en charge les utilisateurs à distance.

Les VPN site à site utilisent IPsec. Les extrémités du tunnel s’authentifient mutuellement, souvent à l’aide d’une clé partagée ou de certificats. IKE négocie les clés de chiffrement ; IPsec protège ensuite les paquets dans le tunnel. Un VPN utilise un chemin Internet partagé même si son contenu est chiffré.

Identifier les deux extrémités

Sur AWS, une passerelle privée virtuelle s’attache à un VPC ; une passerelle de transit peut desservir plusieurs VPC. Azure déploie sa passerelle VPN dans un sous-réseau dédié nommé GatewaySubnet. Google Cloud propose des passerelles HA VPN. Au bureau, un routeur ou un pare-feu doté d’une adresse publique fournit l’autre extrémité ; AWS l’appelle l’équipement de passerelle client.

Les passerelles ont aussi besoin de routes. Celles-ci peuvent être configurées de façon statique ou apprises avec BGP. BGP permet aux routeurs d’échanger les plages d’adresses qu’ils peuvent atteindre. Un tunnel chiffré sans les bonnes routes ne fournit pas à une application de chemin utilisable de bout en bout.

Suivre une requête privée

Prenons un bureau utilisant 192.168.10.0/24 et un VPC AWS utilisant 10.0.0.0/16 :

1. L’équipe crée la passerelle cloud et configure le routeur du bureau pour le VPN.
2. La route du bureau pour 10.0.0.0/16 pointe vers le tunnel.
3. La route cloud pour 192.168.10.0/24 renvoie le trafic par la passerelle VPN.
4. Le groupe de sécurité de l’application autorise le trafic nécessaire depuis le bureau.

L’appareil du bureau 192.168.10.25 peut maintenant se connecter à l’application 10.0.2.15. Son trafic est chiffré entre les extrémités du VPN. Les plages qui ne se chevauchent pas permettent à chaque côté de distinguer les destinations locales des destinations distantes. Les noms de services privés nécessitent en plus un transfert DNS ; le tunnel ne le configure pas automatiquement.

Éliminer les points uniques de défaillance

Une connexion AWS Site-to-Site VPN fournit deux tunnels vers des points de terminaison AWS différents. Configure les deux pour que l’un puisse transporter le trafic pendant la maintenance ou la panne de l’autre. Azure prend en charge les passerelles actif-actif. Google Cloud HA VPN peut fournir un accord de niveau de service garantissant une disponibilité de 99,99 % avec la configuration redondante de tunnels requise sur les deux interfaces. Un second routeur de bureau et un second fournisseur d’accès Internet protègent contre les pannes que deux tunnels côté cloud ne peuvent pas résoudre à eux seuls.

Les VPN peuvent généralement être mis en place en quelques heures à l’aide de l’accès Internet existant. Les coûts comprennent principalement la durée de connexion et le transfert de données. La congestion d’Internet et la distance influent sur la latence et le débit ; un tunnel AWS standard prend en charge jusqu’à 1,25 Gbps, ce qui ne garantit pas un débit de transfert soutenu. Un VPN fournit souvent un accès initial pendant l’installation d’un circuit dédié et reste ensuite disponible comme chemin de secours chiffré. Un site web public déjà destiné aux utilisateurs d’Internet n’a pas besoin d’un VPN site à site pour ces visiteurs.

Certaines organisations ont besoin d’une liaison cloud aux performances plus régulières que celles d’un chemin Internet. Une connexion privée dédiée relie le réseau de l’organisation au fournisseur sans passer par l’Internet public. Les services correspondants sont AWS Direct Connect, Azure ExpressRoute et Google Cloud Interconnect.

Suivre le chemin physique

Les fournisseurs cloud rencontrent leurs clients et les réseaux télécoms dans des centres de colocation, des centres de données où de nombreux réseaux disposent d’équipements. Si le routeur du client s’y trouve déjà, un raccordement croisé, un câble physique court, le relie à l’équipement du fournisseur. Sinon, un opérateur télécom ou un partenaire de connectivité prolonge un circuit depuis le bureau ou le centre de données jusqu’à ce point de rencontre.

L’achat du port côté cloud ne supprime pas la nécessité de rejoindre ce centre. L’installation peut impliquer une lettre d’autorisation, la commande d’un raccordement croisé, un circuit télécom et des tests coordonnés. Prévois des semaines de préparation. Les frais peuvent comprendre le port, le service du partenaire, le circuit télécom et les données transférées.

Adapter le service à la capacité

Un port dédié est proposé en grandes capacités fixes. AWS Direct Connect propose des connexions dédiées à 1, 10, 100 et 400 Gbps. Les options fournies par des partenaires, comme les connexions hébergées AWS et Google Partner Interconnect, offrent des paliers de capacité plus petits, à partir d’environ 50 Mbps. ExpressRoute est généralement fourni par un fournisseur de connectivité.

Une liaison hébergée à 50 Mbps a une capacité inférieure à celle d’un tunnel VPN AWS standard limité à 1,25 Gbps. Le mot « dédié » décrit le mode de connexion ; il ne garantit pas une bande passante supérieure à celle de tous les VPN. Compare la capacité réellement achetée et le débit mesuré.

Distinguer confidentialité du chemin et chiffrement

Éviter l’Internet partagé améliore la régularité des performances et fournit un chemin privé. Les circuits à haute capacité prennent en charge des transferts réguliers volumineux, et les chemins privés peuvent satisfaire aux exigences imposant que le trafic reste hors de l’Internet public. Les transferts de données sortants d’AWS par Direct Connect bénéficient aussi de tarifs par gigaoctet inférieurs à ceux des transferts sortants par Internet, même si les coûts fixes du circuit restent importants.

Un circuit privé n’est pas chiffré par défaut. Si la confidentialité exige un chiffrement, choisis une méthode adaptée : TLS dans les applications, un VPN IPsec sur la liaison privée ou MACsec sur les ports dédiés compatibles. TLS protège les sessions applicatives ; IPsec protège le trafic IP dans le tunnel ; MACsec chiffre les trames sur les liaisons compatibles. Une exigence de chemin privé et une exigence de chiffrement du trafic doivent chacune être respectées.

Prévoir une rupture de liaison

Un circuit physique unique peut tomber en panne à cause d’un câble coupé, d’une panne de routeur ou d’une interruption du centre. Un circuit ExpressRoute possède deux connexions vers deux routeurs périphériques Microsoft, mais les charges de travail critiques bénéficient toujours de connexions passant par deux emplacements. Deux liaisons passant par le même centre conservent ce centre comme point de défaillance commun.

Un VPN site à site peut fournir une solution de secours moins coûteuse si la liaison privée tombe en panne. Ses routes et ses permissions doivent être prêtes, et son débit plus faible ou plus variable doit suffire au trafic essentiel. Le chemin Internet du secours peut ne pas satisfaire à une exigence stricte imposant que le trafic reste toujours hors d’Internet ; les exigences de disponibilité et de chemin influent toutes deux sur le choix.

Les liaisons dédiées atteignent les ressources des réseaux virtuels par adressage privé. Avec une configuration supplémentaire, elles peuvent aussi atteindre les services cloud publics compatibles, par exemple à l’aide d’une interface virtuelle publique AWS ou de l’appairage Microsoft ExpressRoute. Ce sont des liaisons réseau vers le cloud ; les serveurs existants de l’organisation restent là où ils sont.

Le choix d’une connexion commence par le travail qu’elle doit prendre en charge. Détermine qui a besoin d’un accès, le volume de données transféré, l’échéance, la régularité requise, la date de mise en place, les exigences de sécurité et les conséquences d’une panne. Des réponses différentes conduisent à des liaisons différentes.

Restreindre le choix

Une entreprise de 40 salariés au bureau qui doit être prête la semaine prochaine peut commencer par un VPN site à site. Pour 300 salariés travaillant chacun à domicile, un VPN d’accès distant donne à chaque appareil accès aux outils internes. Pour une banque qui transfère des téraoctets chaque jour, des connexions dédiées empruntant des chemins distincts et le chiffrement peuvent se justifier. Un fabricant qui attend un circuit peut d’abord utiliser un VPN et le conserver comme secours.

Vérifier la fenêtre de transfert

La bande passante est la capacité de la liaison ; le débit est la vitesse réellement obtenue. La latence est le délai d’un trajet. Une liaison de grande capacité peut transférer rapidement un gros fichier alors qu’une longue distance rend toujours chaque aller-retour lent.

Utilise les unités de données décimales : 1 Go représente un milliard d’octets et 1 To représente mille milliards d’octets. Chaque octet contient 8 bits. Exprime la quantité de données et le débit dans des unités compatibles en bits :

Une sauvegarde de 2 To contient 16 mille milliards de bits. À un débit effectif de 500 Mbps, divise par 500 millions de bits par seconde pour obtenir 32 000 secondes, soit environ 8,9 heures. Cela dépasse une fenêtre de 8 heures. À un débit soutenu de 10 Gbps, le calcul donne 1 600 secondes, soit environ 27 minutes. Utilise le débit effectif pour une estimation pratique ; la vitesse annoncée d’un port ne tient pas compte à elle seule du surdébit des protocoles, de la concurrence pour les ressources ou d’un disque source lent.

Pour une migration ponctuelle exceptionnellement volumineuse, un réseau peut prendre trop de temps même lorsqu’il est pleinement utilisé. Envoyer 500 To à 1 Gbps prend 4 000 000 secondes, soit environ 46 jours. Des services de transfert physique comme Azure Data Box peuvent déplacer des données en masse par l’expédition d’un appareil rempli. Compare le calendrier complet de la migration, pas seulement le transfert réseau.

Vérifier la sécurité et le comportement en cas de panne

Un VPN fournit un transport chiffré sur Internet. Une liaison dédiée fournit un chemin privé et nécessite l’ajout d’un chiffrement lorsque celui-ci est requis. Une exigence portant sur les deux propriétés appelle les deux contrôles. Si une liaison dédiée tombe en panne, un VPN de secours rétablit un chemin, mais ne permet pas forcément de transférer les mêmes données dans la fenêtre initiale. Détermine quelles applications doivent continuer à fonctionner et ce que le secours peut transporter.

Quel que soit le transport, vérifie que les plages d’adresses ne se chevauchent pas, les routes dans les deux sens, les permissions des pare-feu des ressources et le transfert DNS pour les noms privés. Un circuit de plus grande capacité ne peut pas corriger un conflit d’adresses ou une route de retour manquante. De même, un tunnel fonctionnel ne peut pas résoudre un nom privé sans le chemin approprié vers le résolveur.

Pour la décision finale, relie chaque choix à un besoin explicite. « VPN parce que le bureau a besoin d’un accès privé demain et que le trafic est modeste » est une explication exploitable. « Connexion dédiée parce qu’elle est plus rapide » omet la capacité achetée, la fenêtre de transfert, le délai de mise en place et le plan en cas de panne.