The definition is overly broad because literally anything the user doesn't like can be blamed on bad UX design. It's too broad to be useful in understanding specific problems. It's like saying anything a person doesn't like in a restaurant was not cooked well.

Also user experience follows pretty heavily from UI design, you cannot separate the two without losing something. But "experience" is also much more subjective: Some might have a bad experience digging through menus while another person might have a good experience, like the way it's all organized. As an example, I found the notification for this issue perfectly acceptable: it let the user know a copy would be made. That is a pretty clear indication that the originals will still exist, and new ones would end up in Glacier. My experience there would be fine.

User experience is unhelpful in this respect because you cannot design your system to satisfy the experience of every user.

There's an entire discipline of UX best practices. Some of it is subjective but some of it more generally agreed upon. I don't think you'd find many UX designers who say AWS follows these, and it's up for debate the degree to which it's intentional.

Yep, but none of that means this particular issue was poor UX. Maybe if this particular issue was a very common problem then I would see things differently, but this story also comes from a person who failed to review billing statements from AWS or their bank account transactions for most of a year. It's simply not a situation I can easily blame on AWS.

This.

If it doesn't operate like Dropbox under the hood, don't make it look like Dropbox in your interface.

If an action creates a copy of objects, call it "Copy Objects" or whatever.

I think that presenting an S3 bucket as a set of files that you can select and perform operations on sets up false expectations here. And not showing incomplete multipart uploads in the file listing or having any way to see they are there isn't great.