4

I want to set the "Object Caching" of my CloudFront distribution with S3 origin to "Customize".

I follow these steps on the console:

  1. go to the "behavior" tab of the relevant distribution
  2. "Edit Behavior" of the relevant behavior(s)
  3. change the radio button for "Object Caching" from "Use Origin Cache Headers" to "Customize"
  4. leave the default values for "Minimum TTL", "Maximum TTL", and "Default TTL" untouched
  5. click "Yes, Edit"

When I go back to the behavior the "Object Caching" is reverted back to "Use Origin Cache Headers", even after allowing time to sync the settings across the edge servers.

Is this expected behavior, and, if so, why? Or is this a bug?

If it's expected behavior, what steps should I take instead?

chrisvdb
  • 1,199
  • 2
  • 10
  • 15

1 Answers1

6

It's not a bug.

It's more like a case of imprecise descriptions of what the radio buttons actually mean.

  • Use Origin Cache Headers actually means "Use origin cache headers constrained by standard values for CloudFront internal TTLs."

  • Customize actually means "Use origin cache headers constrained by custom values for CloudFront internal TTLs."

The origin cache headers are always used, with either selection. The only difference is whether you're using the standard 0/86400/31536000 values or custom values... so "Customize" with no customized values is exactly the same behavior as "Use Origin Cache Headers," which is why the UI reverts the way it does.

It is not clear why the UI uses descriptions that are somewhat at odds with the actual behavior.

Michael - sqlbot
  • 21,988
  • 1
  • 57
  • 81
  • Understood. Yes, not a bug but UX could be improved. As I'm serving the files from an S3 bucket (*without* static website hosting enabled) it might not be possible to set the cache-control headers without using Lambda@Edge. Right? – chrisvdb Dec 20 '18 at 01:05
  • To answer my own comment: it *is* possible to set the cache-control headers when using an S3 bucket without website hosting without using Lambda@Edge by adding Cache-Control metadata with content "max-age=NNN" on the S3 objects. On the console this needs to be done object per object, though. – chrisvdb Dec 20 '18 at 01:26
  • 1
    @chrisvdb that's correct -- setting `Cache-Control` on an S3 object works with or without the website hosting feature enabled. Note that you may want `Cache-Control: max-age=x, s-maxage=y` where `x` is how long the browser is allowed to cache the object and `y` is how long you want CloudFront to cache the object. If `s-maxage` is omitted, CloudFront uses `max-age` if present, and if neither is present, it uses Default TTL unless it finds `Cache-Control` values of `no-cache`, `no-store`, or `private` -- in which case, CloudFront uses Minimum TTL internally. – Michael - sqlbot Dec 20 '18 at 02:07
  • The AWS Cloudfront distribution behavior UI is quite misleading. Indeed, setting cache-control on S3 object did the trick. If png files do not change much so : ```aws s3 cp ./dist s3://you-bucket --recursive --exclude "*" --include "*png" --metadata-directive REPLACE --cache-control max-age=31557600``` would set all and only png files with a max-age of a year (enjoyed by Google PageSpeed) – stockersky Aug 28 '19 at 17:26
  • "It's not a bug, it's a feature". Well, quite confusing! – bersling Oct 02 '19 at 08:37
  • Based on this, wouldn't you expect a new CF distro with default settings (I.e. Object Caching set to "Use Origin Cache Headers") and an S3 origin that is *not* setting any cache headers, to use a 24 hour TTL? But I am seeing results that contradict that, as a file I updated in S3 more than 24 hours ago is still not being picked up by CF. I am going to try the Customize setting to see if that does the trick, but I'm still puzzled by what I'm seeing. – Danny Dec 12 '19 at 13:11
  • @Danny yes, I would expect CloudFront to check back with S3 on the next request after the object has been in the cache for 24 hours. Check the `Age` response header you're getting back. That's the time, in seconds, since CloudFront cached the object it's currently returning to you. This doesn't apply to changing only the object *metadata* in S3, since metadata doesn't impact the ETag. – Michael - sqlbot Dec 12 '19 at 17:50