Devenez un architecte de solutions AWS

Maintenant regardons comment on peut améliorer les performances du site The Green Earth Post (partie en rouge dans l’image ci-dessous). En effet, une des exigences est que le site soit disponible partout sur le globe avec la même latence.

Avant tout, il faut lui attribuer un nom de domaine. Ensuite, nous verrons les outils pour rendre la navigation fluide et sécurisée partout dans le monde.

Donnez un nom de domaine

Naturellement, nous choisissons www.thegreenearthpost.com comme nom de domaine du site web. Nous devons l’enregistrer à l’url de la distribution CloudFront. C’est le rôle du serveur DNS joué par Amazon Route 53, un service global de système DNS qui permet :

• d’enregistrer des noms de domaine ;

• d’associer un domaine à une ressource pour y acheminer le trafic internet ;

• de vérifier l’état (health check) de vos ressources.

Avec Route 53, vous créez des zones hébergées (hosted zones), portant le même nom qu’un domaine ou sous-domaine de votre choix, dans lesquelles vous créez les enregistrements DNS.

Il existe deux types de zones hébergées :

• public : contient les enregistrements spécifiant la façon d’acheminer le trafic sur le réseau Internet. 

• privé : contient les enregistrements spécifiant la façon d’acheminer le trafic dans un VPC.

 Lors d’un enregistrement (record) DNS, vous devez renseigner :

• un domaine/sous-domaine (monsite.fr/sous-domaine.monsite.fr) ;

• un type d’enregistrement :

  • A : adresse IPv4 ;

  • AAAA : adresse IPv6 ;

  • CNAME : mappe un nom d'hôte à un autre nom d'hôte, exemple : CNAME “int.gift.sa” pointe sur “intranet.gift.sa” ;

  • NS : signifie “serveur de noms” et indique quel(s) serveur(s) contien(nen)t les enregistrements DNS réels ;

• une stratégie de routage ;

• un TTL, une durée pendant laquelle l'enregistrement est mis en cache dans le résolveur DNS.

Avant d’étudier les stratégies de routage, intéressons-nous à quel type d’enregistrement nous devons choisir pour notre site web. Comme évoqué plus haut, il faut associer le nom de domaine thegreenearthpost.com à l’url CloudFront. Bien que le type CNAME semble être le plus approprié, il ne peut être utilisé que pour les sous-domaines (exemple : api.thegreenearthpost.com).  

Pour y remédier, Route 53 met à disposition des alias qui permettent de mapper un nom de domaine ou un sous-domaine à une ressource AWS, par exemple : 

• thegreenearthpost.com ⇔ https://d111111abcdef8.CloudFront.net/

• api.thegreenearthpost.com ⇔ http://alb-demo-1234567890.us-west-2.elb.amazonaws.com/

Un enregistrement d’alias est toujours de type A ou AAAA, le TTL n’est pas configurable car utilisé par défaut et concerne uniquement les ressources AWS suivantes :

Les stratégies de routage (routing policies)

Il y a huit stratégies différentes qui déterminent la façon dont Route 53 répond aux requêtes :

• simple ;

• par basculement (failover) ;

• par géolocalisation (geolocation) ;

• par proximité géographique (geoproximity) ;

• avec latence (latency) ;

• basée sur IP (IP-based) ;

• réponse multi-valeur (multivalue answer) ;

• pondérée (weighted).

Étudions-les plus en détail :

Simple (simple)

Elle achemine le trafic vers une seule ressource où vous spécifiez une ou plusieurs valeurs. 

Cette stratégie est la seule qui n’effectue pas de vérification de l’état (health check).

Par basculement (failover)

Cette stratégie bascule le trafic vers une ressource secondaire si la ressource principale est indisponible (basculement actif-passif).

1 - Il faut réaliser un enregistrement DNS pour les deux instances avec le même nom de domaine ou sous-domaine. Une instance doit être désignée comme principale, et l’autre comme secondaire.
2 - L’adresse IP ou le DNS de l’instance principale si disponible, sinon de l’instance secondaire.
 

Par géolocalisation (geolocation)

Cette stratégie achemine le trafic en fonction de l'emplacement de vos utilisateurs.

1 - Il faut réaliser un enregistrement DNS pour chaque instance avec le même nom de domaine ou sous-domaine. Chaque instance est associée à une zone géographique. L’instance 1 est dédiée au continent européen, l’instance 2 à la Chine et l’instance 3 dédiée aux clients venant des autres pays.

2 - L’adresse IP ou le DNS de l’instance choisie en fonction de la géolocalisation du client (ici instance 1)

Par proximité géographique (geoproximity)

Elle permet de détourner le trafic des ressources d’une région donnée vers les ressources d'une autre région grâce au paramètre écart (biais). 

A - Les écarts sont nuls, les clients sont répartis équitablement.

B - L’écart de la région de l’instance B est à +50, le trafic est détourné vers cette région.

L’écart peut être négatif (=rétrécir) ou positif (agrandir).

Avec latence (latency)

Vous disposez de ressources dans plusieurs régions AWS et vous voulez acheminer le trafic vers la région fournissant la meilleure latence pour le client.

1 - Un enregistrement DNS pour chaque instance avec le même nom de domaine ou sous-domaine, en spécifiant la région AWS dans laquelle elle se trouve.

2 - Route 53 détermine la région AWS la plus proche du client, et les informations de l’instance de la région AWS sélectionnée.

Basée sur IP (IP-based)

Cette stratégie utilise l’adresse IP de la requête DNS pour déterminer la ressource de l’enregistrement correspondant.

1 - Il faut réaliser un enregistrement DNS pour chaque instance avec le même nom de domaine ou sous-domaine. Chaque instance est associée à une plage d’adresses CICR IPv4.  

Réponse multi-valeur (multivalue answer)

C’est une réponse à une requête DNS avec jusqu'à huit enregistrements sains sélectionnés de manière aléatoire.

Fonctionnement de la stratégie de routage par réponse multi-valeur

1 - Il faut réaliser un enregistrement DNS pour chaque instance avec le même nom de domaine ou sous-domaine.

Pondérée (weighted)

Cette stratégie achemine le trafic vers plusieurs ressources dont chacune est associée à une pondération contrôlant le pourcentage des requêtes à recevoir.

1 - Il faut réaliser un enregistrement DNS pour chaque instance avec le même nom de domaine ou sous-domaine. Chaque instance est associée à une pondération. Si la pondération est à 0 %, alors l’instance ne recevra aucun trafic. Si toutes les pondérations sont nulles, alors toutes les instances recevront le même pourcentage de trafic.

Cette stratégie de routage est adaptée pour faire de l’équilibrage de charge pondérée, ou tester une nouvelle version d’application en production sur un faible échantillon (ici, 10 %).

Réduisez la latence de votre site partout dans le monde avec Amazon CloudFront

La localisation où vous installez le site The Green Earth Post joue un rôle dans sa performance pour les visiteurs. Par exemple, s’il est installé en Irlande, notre site mettra plus de temps à charger pour un visiteur en Asie qu’en Europe.

Oui, et c’est un objectif important pour votre mission chez The Green Earth Post ! Utilisons le service Amazon CloudFront, un Content Delivery Network qui stocke une version mise en cache du contenu statique du site web dans plusieurs centaines d’endroits géographiques, dits emplacements périphériques (edge locations). Un visiteur récupère le contenu depuis l’emplacement le plus proche géographiquement.

CloudFront vous permet :

• d’établir des restrictions géographiques en mettant sur liste noire des pays si vous avez des contraintes légales ;

• de réduire  le nombre d'emplacements périphériques avec trois classes de prix (mais cela peut dégrader les performances) :

  • tous ⇒ toutes les régions ;

  • 200 ⇒ exclut les régions les plus chères ;

  • 100 ⇒ uniquement les régions les moins chères ;

• de réduire votre tarification en vous engageant sur un niveau de trafic par mois.

Pour récupérer un contenu et le mettre en cache, CloudFront s’appuie sur des emplacements, appelés origines :

• les compartiments S3 : 

  • Si un compartiment S3 n'autorise pas l'accès public, activez la fonction identité d'accès à l'origine (origin access identity - OAI) pour autoriser CloudFront à y accéder !

  • À partir de décembre 2022, utilisez la nouvelle fonction contrôle d’accès à l’origine (origin access control - OAC).

• les origines personnalisées exposant une application HTTP :

  • les équilibreurs de charge (ELB) ;

  • les sites web statiques basés sur S3 ;

  • les serveurs web s’exécutant sur des instances EC2, ECS.

Réduisez la latence de votre site partout dans le monde avec AWS Global Accelerator

CloudFront améliore les performances des contenus statiques mis en cache et des contenus dynamiques. Le service AWS Global Accelerator est une alternative pour rehausser les performances des contenus dynamiques. Il s’appuie sur les adresses IP Anycast allouées aux emplacements périphériques qui connectent les visiteurs aux applications servant les contenus dynamiques, diminuant ainsi la latence réseau. 

A - Le réseau AWS privé réduit la latence entre les visiteurs et l’application.

B - Global Accelerator fonctionne avec les instances EC2, les adresses IP Elastic, les équilibreurs de charge ALB et NLB privés ou publics.

C - Global Accelerator vous octroie deux adresses IP Anycast pour votre application, et elles sont affectées aux emplacements périphériques.

Améliorez la sécurité de votre site

Nous venons d’installer les principales briques de notre site web. Toutefois, il faut une protection contre les attaques web, comme par exemple : 

• l’injection SQL ;

• le Cross-Site Scripting ;

• le déni de service.

AWS propose deux services :

• AWS Web Application Firewall (WAF) : un pare-feu d'application web (couche 7) qui vous permet de bloquer le trafic des robots et les formes d'attaque courantes (l'injection SQL, le Cross-Site Scripting…), grâce à des règles web ACL (listes de contrôle d’accès).

• AWS Shield : possède une version Standard gratuite et une version Advanced (avancée en français) payante, pour les attaques sophistiquées. Elles fournissent des protections contre les attaques par déni de service distribué (DDoS) pour les ressources AWS au niveau des couches réseau et transport (les couches 3 et 4 du modèle OSI) et de la couche application (couche 7 du modèle OSI).

Les services API sans serveurs d’AWS à connaître

Le service sans serveur API Gateway permet de créer, de gérer, de surveiller et de sécuriser les API REST, HTTP et WebSocket à n'importe quelle échelle. Il s’intègre avec tous les services qui exposent des points de terminaisons HTTP (Lambda, EC2, ECS, ALB…). Une architecture back-end totalement sans serveur aurait été possible comme ci-dessous :

A - API Gateway remplace ALB.

B - Plusieurs fonctions Lambda peuvent s’exécuter en parallèle en fonction de la charge. Cela remplace les instances EC2.

C - DynamoDB et Aurora sont des bases de données sans serveur qui peuvent remplacer RDS.

Contrairement aux ELB, API Gateway permet de :

• limiter le nombre de requêtes (throttling) pour améliorer le débit ;

• mettre en cache ;

• authentifier des requêtes avec Cognito, des rôles IAM ou des clés d’API.

API Gateway offre trois types de points de terminaison : 

• optimisé pour les périphériques (Edge-optimized) : pour les clients internationaux ;

• régional : pour les clients autour de la région AWS utilisée ;

• privé : uniquement accessible dans un VPC.

Au lieu d’une API REST, nous aurions pu construire une API basée sur le langage GraphQL exposée grâce au service AWS AppSync, adapté pour les sites mobiles et web !

En résumé

• Exposez sur Internet le site web avec un nom de domaine via Route 53.

• CloudFront vous permet de servir plus rapidement le contenu de votre site.

• AWS WAF et AWS Shield permettent de se protéger contre des attaques web.

Découvrons dans le prochain chapitre comment surveiller l’infrastructure du site web !