Aws-cli: Add ability to invalidate cloudfront assets

Created on 24 Sep 2014  路  16Comments  路  Source: aws/aws-cli

Using s3cmd I can write:

s3cmd -P --cf-invalidate put filename s3://bucket/path/filename

A similar option for aws s3 cp/sync would be helpful.

feature-request

Most helpful comment

Agree, please re-open.

All 16 comments

+1

+1

The workaround IIUC is aws cloudfront create-invalidation

aws cloudfront create-invalidation --distribution-id XXXXXXXXXXXXX \
--invalidation-batch "{ \"Paths\": { \"Quantity\": 1, \"Items\": [ \"/*\" ] }, \"CallerReference\": \"$(shell date +%s)\" }"

http://docs.aws.amazon.com/cli/latest/reference/cloudfront/create-invalidation.html

Which is _awkward_ to use.

I am now using the cloudfront-invalidator command line. It's crazy that this issue remains unresolved for aws-cli. No, I don't want to create JSON for a simple task.

+1

+1

:+1:

Thanks for the feature request. Just want to let you know that we hear you and have added a note to our backlog to look into this.

+1

+1, that would be super awesome to use the official tool instead of s3cmd.

Looks like the PR wasn't linked to this issue.

PR: https://github.com/aws/aws-cli/pull/1662

If you have any feedback on the proposed interface, feel free to comment on the PR.

I was hoping that say upon a aws s3 sync it could invalidate the paths that changed. I usually invalidate the whole cache since I am too lazy to find the path of what changed manually.

I'm not sure what or if there is a cost associated to invalidating the whole cache as opposed to the path.

Thanks for the suggestion @kaihendry . We did think about the possibility of closer integration with the aws s3 sync. One of the potential concern is about the price. Imagining you sync thousands of objects to your S3 bucket, if your tool literally invalidate all these objects for you, you could possibly end up with extra cost. (See "Paying for Object Invalidation" for details.) On the contrary, manually sending only one invalidation request with wildcard is sometimes a better choice.

We will definitely keep seeking better solution for the this feature. Meanwhile we are also exciting to provide the long-awaited fundamental feature as a solid first step. Thank you everyone again, for all your support and patience.

Thanks for tackling this issue!

Just like @kaihendry I want to point out, that this issue is not fixed in the sense of the original request and the people :+1:'ing. The "fix" added some syntactic sugar to aws cloudfront create-invalidation, nothing more.

This ticket is actually about not needing to deal with manual invalidation. Exactly the opposite, aws s3 sync --cf-invalidate should invalidate CloudFront if files were synced. That would be really helpful.

Should I create a separate ticket for that?

@aronwoost is exactly right! This issue should not have been closed.

Agree, please re-open.

Was this page helpful?
0 / 5 - 0 ratings