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?

Improve this question

1 Answer 1

Reset to default
7

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.

Improve this answer
7
  • 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, 2018 at 1: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, 2018 at 1: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, 2018 at 2: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, 2019 at 17:26
  • "It's not a bug, it's a feature". Well, quite confusing!
    – bersling
    Oct 2, 2019 at 8:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .