Déploiement de plusieurs régions avec politique basée sur la géolocalisation v/s Cloudfront

Question

J'ai une origine personnalisée, c'est-à-dire une application Web, sur une instance EC2. Comment puis-je décider si je dois opter pour :

1. un CDN Cloudfront

ou,

2. déployer plusieurs instances dans différentes régions et configurer une politique de routage basée sur la géolocalisation/proximité

La confusion vient du fait que les deux visent à acheminer la demande vers l'emplacement le plus proche (emplacement du bord dans le cas de l'option Cloudfront et une instance EC2 spécifique à une région lorsqu'il s'agit de déploiements multirégionaux avec politique basée sur la géolocalisation avec Route 53 ) en fonction de l'origine de la demande.

Answer 1

Il n'y a aucune raison pour que vous ne puissiez pas faire les deux.

CloudFront achemine automatiquement les demandes vers un emplacement périphérique le plus proche du spectateur. Lorsqu'une demande ne peut pas être servie à partir de cet emplacement ou du cache régional le plus proche, CloudFront effectue une recherche DNS pour le nom de domaine d'origine et récupère le contenu depuis l'origine.

Jusqu'à présent, je n'ai fait que constater l'évidence. Mais le suivant est un détail subtil mais important :

CloudFront effectue cette recherche du DNS du serveur d'origine. à partir d'un endroit proche de l'observateur -- Cela signifie que si le nom de domaine d'origine est un ensemble d'enregistrements basés sur la latence dans Route 53, pointant vers des déploiements dans deux régions EC2 ou plus, alors la requête que CloudFront fait pour "trouver" l'origine sera acheminée vers le déploiement d'origine le plus proche du bord, qui sera aussi par définition proche du spectateur.

Ainsi, un déploiement CloudFront unique et global peut sélectionner automatiquement et de manière transparente la meilleure origine, en utilisant une configuration basée sur la latence pour la configuration DNS du backend.

Si les optimisations de mise en cache et de transport fournies par CloudFront ne vous donnent pas les performances globales dont vous avez besoin, puis vous pouvez déployer dans plusieurs régions, derrière CloudFront... en gardant toujours à l'esprit qu'un déploiement multirégional est presque toujours un environnement plus complexe, en fonction des bases de données qui soutiennent votre application et de la façon dont elles sont équipées pour gérer la réplication interrégionale pour les lectures et/ou les écritures.

L'utilisation de CloudFront comme frontal est également une meilleure solution pour la tolérance aux pannes entre les déploiements régionaux multiples, car CloudFront respecte correctement le TTL du DNS sur l'enregistrement DNS de votre serveur d'origine, et si vous avez configuré les contrôles de santé de Route 53 pour retirer une région malsaine de la réponse DNS sur le nom de domaine d'origine, CloudFront cessera rapidement de lui envoyer d'autres requêtes. Les navigateurs sont notoirement indignes de confiance à cet égard, mettant parfois en cache une réponse DNS jusqu'à ce que tous les onglets/fenêtres soient fermés.

Et si CloudFront est votre frontal, vous pouvez décharger des parties de votre logique vers Lambda@Edge si vous le souhaitez.

Answer 2

Vous pouvez utiliser le multi région pour de nombreuses raisons,

1. Proximité
2. Failover (en cas de défaillance de la première région, les demandes peuvent être envoyées à une autre région).

Le déploiement lambda multirégional est clairement documenté ici. Vous pouvez également appliquer la même logique à toutes les ressources AWS. (DynamoDB, S3)

https://aws.amazon.com/blogs/compute/building-a-multi-region-serverless-application-with-amazon-api-gateway-and-aws-lambda/

Vous pouvez également exécuter Lambda@Edge pour forcer toutes vos requêtes / splits à une seule région sur le bord.

J'espère que cela vous aidera.