Comment by mikeyla85 | Hacker News Reader

Comment by mikeyla85 | Hacker News Reader

OP here. Thanks to some of the helpful comments, it seems that the creation of a copy when I chose "Edit storage class" may have been the culprit.

I didn't suspect that because in all my correspondence with Amazon, they always said the issue was incomplete multipart uploads.

So I assumed, based on the dialog box called "Edit storage class", that the net result of this action would be the same files but with a different storage class. This led me to read the warning as "We will create a copy of your objects and delete the old one, so please be aware you will be charged for the cost of the copy" rather than "We will create a copy of your objects and two versions of them will exist forever."

So it does seem like Amazon tried to warn people. But why on earth would a dialog box labeled "Edit storage class" not do anything of the sort? Are there actual legitimate reasons someone would want to have two versions of their objects sitting around?

Say what you will about my billing awareness (and you are saying it. Feeling the hate, all, thanks) but this is not good UX.

If there's any legitimate reason to duplicate objects in the name of changing the storage class, I'd love to hear it.

> This led me to read the warning as "We will create a copy of your objects and delete the old one, so please be aware you will be charged for the cost of the copy" rather than "We will create a copy of your objects and two versions of them will exist forever."

First, the same warning you are referring to also says, exactly: “You can change the storage class without making a new copy of the object using a lifecycle rule.”

Second, to answer your prompt, the reason why the object is duplicated during a storage class change is because S3 is an object store and not a filesystem like you may assume. Performing a modification operation on an object does not change the object itself; instead a copy is made with modifications. When changing storage class, a copy is thus made. If you had used the lifecycle rule as the warning suggested, it would have performed your assumption: make the copy and delete the original object in the background.

P.S. Not trying to be abrasive :) I do though think you should considering hiring a real devops/cloud/sysadmin to manage AWS for you. If that is really not feasible for you, I suggest at the very least looking into setting up budget anomaly detection and alerting. You then might be able to have some visibility into your budget.

Thanks for the information!

Re your first note -- because I assumed that this operation was being treated similarly to a move (which is a copy and delete in S3), I assumed that I would be dinged for the cost of copying (minimal when on the same location) but the original would be deleted.

Reference: https://forums.aws.amazon.com/thread.jspa?messageID=455101#j...

Second -- this makes sense to me that this is how it works. But I still don't understand why anyone would have a use case for this "Edit Storage Class" dialog box. Is there ever a moment in the administering of an object where you would want to duplicate that object but with a different storage class?

Unfortunately hiring a sysadmin is way out of our budget. We had a friend helping with some AWS stuff and they may have done some of this for us if I'd asked, but I do remember it being a fairly mind-numbing task and he wasn't co-located with the files.

Reply on news.ycombinator.com