API网关缓存与CloudFront [英] API Gateway Caching vs CloudFront
问题描述
我对API Gateway和CloudFront如何协同工作感到有些困惑。最终，我希望能够将自定义标头和值视为我的缓存键的一部分。我知道这可以通过将其列入白名单（如果我使用的是CloudFront）来完成。
因此，当我发出以下请求时：
GET / pagesRead / 4
Some-Header：嘶嘶声
这将返回例如 '29个页面'
然后有一个帖子更新 id 4到 45页
如果我提出此请求
GET / pagesRead / 4
Some-Header：buzz
现在它将返回 45页
但是我使用的是API Gateway，它显然是在幕后拥有自己的CloudFront。有没有一种方法可以配置API Gateway以使用其幕后 CloudFront将我的自定义标头列入白名单？
根据此文档：
但是在GET上，我得到的数据已过时
GET / pagesRead / 4测试标题：buzz
区别在于API网关实际上并未使用CloudFront缓存。 CloudFront确实为所有API网关API 边缘优化的API端点提供了一些前端服务，但基于以下条件，缓存似乎不是其中之一：
API网关通过创建专用的缓存实例来启用缓存。
。 ..and ...
您不应使用
X-Cache标头从CloudFront响应中确定是否从API网关缓存实例提供API。
https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-caching.html
可以将Edge Optimized API Gateway端点级联到您创建的CloudFront发行版之后，但这并非没有一定的麻烦。由于您要通过更多的系统，因此延迟会有所增加。在这种配置下， CloudFront-Is-*-Viewer 和 CloudFront-Viewer-Country 标头以及可能的任何概念客户端IP的ID无效，因为API网关部署将看到其前面的其他CloudFront分发的属性，而不是真实客户端的属性。 X-Forwarded-For 仍然是正确的，但是必须谨慎处理，因为它将包含一个额外的跃点，必须正确处理。
对于要在自己的CloudFront发行版后面放置API网关的应用程序，请使用新的Regional端点之一来部署您的API阶段。
它将把我的标头作为缓存键的一部分。
必须根据引用的文档显式配置缓存键，但是，是的，API Gateway缓存将根据该标头的值以及缓存键中的其他属性来缓存响应。
¹ 边缘优化端点。 API网关现在具有两种不同的端点。现在，原始设计称为边缘优化，而新选项称为 regional 。区域终端节点不使用CloudFront的前端服务，并且从同一AWS区域内的EC2访问时，可能会提供较低的延迟。推出新的区域功能时，所有现有端点均被归类为边缘优化。对于区域性终结点，除非您使用自己的CloudFront分发并将这些标头白名单转发到源，否则 CloudFront-* 标头不存在于请求中。
I'm a bit confused by how API Gateway and CloudFront work together. Ultimately, I want to be able to have a custom header and value be considered part of my cache key. I know this can be done by whitelisting (if I'm using CloudFront).
So when I make the following request:
GET /pagesRead/4
Some-Header: fizz
This returns, for instance, '29 pages'
Then there's a post that updates id 4 to '45 pages'
If I make this request
GET /pagesRead/4
Some-Header: buzz
It will now return '45 pages'
But I'm using API Gateway, which obviously has it's own CloudFront behind the scenes. Is there a way I can configure API Gateway to use its 'behind-the-scenes' CloudFront to whitelist my custom header? Does this even need to be done?
According to this documentation: AWS-API-Gatway, It seems like I can just enable API caching in API Gateway, and it will consider my headers as part of the cache key.
Am I understanding this correctly? If all I want is for my headers to be a part of the cache key, what's the difference between 'Enabling API Caching' in API Gateway and adding a CloudFront instance on top of API Gateway and white-listing in CloudFront?
UPDATE:
I've added a header like this in API Gateway:
But on GET, I am getting stale data from the cache.
GET /pagesRead/4 test-header: buzz
The difference is that API Gateway doesn't actually use the CloudFront cache. CloudFront does provide some front-end services for all API Gateway APIs edge-optimized API endpoints¹, but caching does not appear to be one of them, based on the following:
API Gateway enables caching by creating a dedicated cache instance.
...and...
You should not use the
X-Cacheheader from the CloudFront response to determine if your API is being served from your API Gateway cache instance.https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-caching.html
It is possible to cascade an Edge Optimized API Gateway endpoint behind a CloudFront distribution that you create, but it's not without certain inconveniences. Latency increases somewhat, since you're passing through more systems. Given that configuration, the CloudFront-Is-*-Viewer and CloudFront-Viewer-Country headers, and probably any notion of the client IP will be invalid, because the API Gateway deployment will see attributes of the additional CloudFront distribution that is in front of it, rather than of the real client. X-Forwarded-For will still be right, but will have to be handled with care, because it will contain one extra hop that will have to be correctly handled.
For an application where you want to put API Gateway behind your own CloudFront distribution, use one of the new Regional endpoints to deploy your API stage.
it will consider my headers as part of the cache key.
You do have to configure the cache key explicitly, based on the document you cited, but yes, the API Gateway cache will then cache responses based on the value of that header, and other attributes in the cache key.
¹ edge optimized endpoints. API Gateway now has two different kinds of endpoints. The original design is now called edge-optimized, and the new option is called regional. Regional endpoints do not use front-end services from CloudFront, and may offer lower latency when accessed from EC2 within the same AWS region. All existing endpoints were categorized as edge-optimized when the new regional capability was rolled out. With a regional endpoint, the CloudFront-* headers are not present in the request, unless you use your own CloudFront distribution and whitelist those headers for forwarding to the origin.
这篇关于API网关缓存与CloudFront的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
