+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.
Most helpful comment
Agree, please re-open.