Mise en cache API Gateway vs CloudFront
Je suis un peu confus par la façon dont API Gateway et CloudFront fonctionnent ensemble. En fin de compte, je veux pouvoir avoir un en-tête et une valeur personnalisés à considérer comme faisant partie de ma clé de cache. Je sais que cela peut être fait par liste blanche (si j'utilise CloudFront).
Alors quand je fais la demande suivante:
GET /pagesRead/4
Some-Header: fizz
Cela renvoie, par exemple, '29 pages'
Ensuite, il y a un article qui met à jour id 4 à '45 pages '
Si je fais cette demande
GET /pagesRead/4
Some-Header: buzz
Il retournera maintenant '45 pages'
Mais j'utilise API Gateway, qui a évidemment son propre CloudFront dans les coulisses. Existe-t-il un moyen de configurer API Gateway pour utiliser son CloudFront `` en coulisses '' pour mettre en liste blanche mon en-tête personnalisé? Cela doit-il même être fait?
Selon cette documentation: AWS-API-Gatway , il semble que je puisse simplement activer la mise en cache de l'API dans API Gateway , et il considérera mes en-têtes comme faisant partie de la clé de cache.
Suis-je bien comprendre? Si tout ce que je veux, c'est que mes en-têtes fassent partie de la clé de cache, quelle est la différence entre 'Activation de la mise en cache API' dans API Gateway et ajouter une instance CloudFront au-dessus d'API Gateway et une liste blanche dans CloudFront?
MISE À JOUR:
J'ai ajouté un en-tête comme celui-ci dans API Gateway: 
Mais sur GET, je reçois des données périmées du cache.
GET /pagesRead/4 test-header: buzz
La différence est que l'API Gateway n'utilise pas réellement le cache CloudFront. CloudFront fournit certains services frontaux pour toutes les API API Gateway Points de terminaison API optimisés pour les bords¹, mais la mise en cache ne semble pas être l'un d'eux, sur la base des éléments suivants:
API Gateway permet la mise en cache en créant une instance de cache dédiée.
...et...
Vous ne devez pas utiliser le
X-Cacheen-tête de la réponse CloudFront pour déterminer si votre API est servie à partir de votre instance de cache API Gateway.https://docs.aws.Amazon.com/apigateway/latest/developerguide/api-gateway-caching.html
Il est possible de mettre en cascade un point de terminaison Edge Optimized API Gateway derrière une distribution CloudFront que vous créez, mais cela n'est pas sans inconvénients. La latence augmente quelque peu, car vous passez par plus de systèmes. Compte tenu de cette configuration, le CloudFront-Is-*-Viewer et CloudFront-Viewer-Country en-têtes, et probablement toute notion de l'adresse IP du client sera invalide, car le déploiement de la passerelle API verra les attributs de la distribution CloudFront supplémentaire qui se trouve devant, plutôt que du vrai client. X-Forwarded-For aura toujours raison, mais devra être manipulé avec précaution, car il contiendra un bond supplémentaire qui devra être correctement manipulé.
Pour une application dans laquelle vous souhaitez placer API Gateway derrière votre propre distribution CloudFront, utilisez l'un des nouveaux points de terminaison régionaux pour déployer votre étape API.
il considérera mes en-têtes comme faisant partie de la clé de cache.
Vous devez configurer la clé de cache de manière explicite, en fonction du document que vous avez cité, mais oui, le cache API Gateway mettra en cache les réponses en fonction de la valeur de cet en-tête et d'autres attributs de la clé de cache.
¹ Points de terminaison optimisés pour les bords . API Gateway a désormais deux types de points de terminaison différents . La conception originale est maintenant appelée Optimisée pour les bords , et la nouvelle option est appelée régionale . Les points de terminaison régionaux n'utilisent pas les services frontaux de CloudFront et peuvent offrir une latence plus faible lorsqu'ils sont accessibles depuis EC2 dans la même région AWS. Tous les points de terminaison existants ont été classés comme optimisés pour Edge lors du déploiement de la nouvelle fonctionnalité régionale. Avec un point de terminaison régional, le CloudFront-* les en-têtes ne sont pas présents dans la demande, sauf si vous utilisez votre propre distribution CloudFront et que vous mettez en liste blanche ces en-têtes pour les transférer vers l'origine.
Lorsque vous activez la mise en cache dans API Gateway,
Vous pouvez également éventuellement ajouter,
RequestPath
QueryStringParameters
Http Headers
Par exemple.,
http://example.com/api/ {feature} /? queryparam = queryanswer [avec en-tête customheader = value1]
L'URL ci-dessus vous donne la possibilité de mettre en cache en fonction,
Juste l'URL sans PathParameters: http://example.com/api/
Incluez éventuellement PathParameter: http://example.com/api/ {feature} /
Incluez éventuellement QueryStrings: http://example.com/api/ {feature} /? queryparam = queryanswer
Inclure éventuellement des en-têtes Http: vous pouvez inclure un en-tête normal comme User-Agent ou des en-têtes personnalisés
Quel que soit le mode de mise en cache que vous avez dans API-Gateway, vous pouvez également l'avoir sous CloudFront.
Aussi pour vider le cache , dans votre réponse http envoyer Cache-Control: max-age = 0
J'espère que ça aide.
