It is not possible to explicitly tell CloudFront to cache only 2XX, and not to cache 3XX if you cannot configure the source to set the Cache-Control header accordingly. CloudFront considers 2XX and 3XX “successful” and processes them the same. (It has different rules for 4XX and 5XX only, and there is an explicit exception for answer 304 to a conditional request.)
In the case of S3 redirection, the problem is that S3 redirection rules do not allow setting the Cache-Control header.
However, if you correctly set the Cache-Control headers on objects when they are created on S3 - as it should be, then you can probably & sup1; rely on the CloudFront Default TTL parameter to completely solve the problem by telling CloudFront that responses that do not contain a Cache-Control header should not be cached. This would mean setting the Default TTL to 0 and, of course, requiring the Minimum TTL also be set to 0, since a minimum of <= default is required.
Maximum TTL should be left by default, as it is used to reduce CloudFront caching time for objects with a max-age that is greater than Maximum TTL . You are unlikely to want to reduce the cacheability of responses in 2XX.
Assuming that browsers behave correctly and do not cache redirection (which they do not need for 307 or 302), then your problem is fixed because CloudFront behaves as expected in this configuration - observing Cache-Control when it is present , and do not cache responses when they are missing.
However, you may need to be more aggressive if you find that browsers or other downstream caches support your redirects.
The only way to explicitly add Cache-Control (or other headers) in the responses when the source doesn't provide them would be with Lambda @Edge. The following code used as Origin Response & sup2; the trigger will add Cache-Control: no-cache, no-store, private (yes, this is a bit redundant) to any HTTP 3XX response received from the source server. If any Cache-Control header is present in the original response, it will be overwritten. Any other answer (e.g. 2XX) will not be changed.
'use strict';
With this trigger, 2XX responses do not change their headers, but 302/307 responses will be changed as shown. This will tell CloudFront and the browser not to cache the response.
& AML1; probably ... does not mean that CloudFront can just do the right thing. CloudFront behaves exactly as expected. This probably refers to the fact that this is the only action required. You can probably consider this solution sufficient, because browsers probably won't cache the redirect. Browser behavior, as usual, is a pattern that may require more aggressive addition of explicit Cache-Control headers to prevent browser redirection caching.
? sup2; Origin Response triggers examine and can modify certain aspects of responses before they are cached (if cached) and returned to the observer. Changing or adding Cache-Control headers at this point in the stream will prevent the response from being stored in the CloudFront cache and will also prevent browser caching.