API Gateway Authorised Cache Invalidation not working as expected

Question

Hi there, I am researching the use API Gateway Caching for a task I am doing, and maybe there is a gap in my understanding and not finding enough information in the [docs](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-caching.html)

I have a very basic setup, a gateway with two Lambdas (GET and POST) behind an authoriser. All of that works as expected, and the response is cached correctly (enabling stage caching and method caching for the POST method) but I am battling with invalidation. Without authorisation, the `Cache-Control: max-age=0` works as intended - only respective methods are invalidated. With authorisation, I have another lambda, outside the gateway, making a request to the endpoints. This lambda has the following policy attached:
```
{
  "Version": "2012-10-17",
  "Statement": [
   	{
		"Effect": "Allow",
		"Action": [
			"execute-api:InvalidateCache"
		],
		"Resource": [
			"arn:aws:execute-api:{{region}}:{{id}}:{{api-id}}/*/*/"
		]
	},
	{
		"Effect": "Allow",
		"Action": [
			"apigateway:DELETE"
		],
		"Resource": [
			arn:aws:apigateway:{{region}}::/restapis/{{api-id}}/stages/{{stage}}/cache/data
		]
	}
  ]
}
```

Now this can flush the stage cache using the [SDK](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/api-gateway/command/FlushStageCacheCommand/) but only GET methods inherit from the stage cache, so this does not invalidate the POST method's cache. I would have thought that with the above policy and authorisation on for cache invalidation, you could also just send the `Cache-Control: max-age=0` header to invalidate as this lambda should be authorised, but that header is always ignored in this scenario. My two main questions (which go hand in hand) then are:
1. It does not seem possible for me to invalidate the method override caching programmatically, or am I missing something? I want my calling client to be able to tell my lambda it needs new information, but I can only flush the stage cache with the SDK, not my specific method, so with authorisation on it seems the POST method's cache can't be invalidated. 
2. Do I have to turn off the authorisation to invalidate all my POST endpoints? These methods still sit behind an authoriser so they aren't open to the world, but I only want specific calling clients to invalidate, and this should not be coupled with the authoriser.

Accepted Answer

Hello!

To begin with, for request with cache invalidations to be accepted by API Gateway, the request has to be Sigv4 signed and the client should also have the permissions to perform this operation as mentioned in this [documentation](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-caching.html#invalidate-method-caching).

If either of the two is missing, cache invalidations will not be successful if 'Require authorization' is enabled for Per-key cache invalidation in the API's stage settings. I have also tested this over a setup similar to the one you have.

It is also important to know the configurations of Per-key cache invalidation at both stage and method level, when you have method overrides.

Also the [SDK reference](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/api-gateway/command/FlushStageCacheCommand/) shared is on 'FlushStageCacheCommand', which as the name says, is to flush stage level caching. Invalidations and flushing of cache are different operations and the 'FlushStageCacheCommand' will flush the entire stage level cache every time this API operation occurs. Whereas, invalidations are for specific cache entry only and they do not flush the entire cache, it just avoids serving the cached response for that particular request.

Addressing your queries :

1. It is possible for the Lambda function to place requests to the API requesting latest/new response by passing the ```Cache-Control: max-age=0``` header in a 'signed' request. I would like to emphasise again on the request signing part, without which API Gateway will not be able to recognize the request's authenticity. Programmatically achieving the same would involve making use of Sigv4 libraries in the Lambda function code for the function to get credentials based on its execution role (which has the necessary 'execute-api:InvalidateCache' permission) and place a signed request to the invoke URI of the API. You may find this [example](https://gist.github.com/marcogrcr/6f0645b20847be4ef9cd6742427fc97b) helpful in achieving the same. Please note that AWS does not endorse any third-party link(s) and is shared for your reference only.

2. You do not need to turn off authorisation for invalidations to be successful for any of the HTTP methods. If 'Require authorization' is enabled for Per-key cache invalidation in the stage settings, API Gateway expects that the request from client has the following :
+ ```Cache-Control: max-age=0``` header
+ Signed request with necessary credentials/tokens
+ 'execute-api:InvalidateCache' permission for the identity whose credentials are used to sign the request.

Finally, the permissions that you have shared above seem invalid. I have also tested the operation at my end using the same policy and it was unsuccessful. Please note that the ARN format can contain wildcard (*) for the entries but they have to cover all the entries in the ARN. The working ARN you can specify as the value for 'Resource' would be ```arn:aws:execute-api:{region}:{account-id}:{api-id}/*/*/*```. I have also tested this at my end and was able to successfully invalidate the cache entry by placing a signed request satisfying all the conditions mentioned above in (2).

In case you have additional or follow-up queries, we may require details that are non-public information. Please open a support case with AWS using the following [link](https://support.console.aws.amazon.com/support/home#/case/create).

Answer

Where can I find information about creating the "user" that the invalidate cache policy needs to be attached to?

This is the one step that is confusing me, and its not talked about anywhere. All the docs simply state "attach this policy to the user" with no explanation as to what this "user" is exactly.

We have a headless SPA, and we need to be able to invalidate the cache for certain paths as part of a build process, on an open API Gateway endpoint. As we cannot disable the authorisation option via Cloudformation, we need to be able to reliably invalidate the cache some other way.

API Gateway Authorised Cache Invalidation not working as expected

Relevant content