While I cannot reproduce this issue I have an idea about what might be going on.
Go to the Configuration page of your backup profile and click the Configure button next to the Post-processing Engine. Set the "Bucket access" setting to "Path access (legacy)". If I recall correctly, your region (US West 2) doesn't work properly with Virtual Hosting bucket access for some buckets created before Amazon S3 started asking developer to use the Virtual Hosting access.
As for the HTTP 413 message, according to Amazon's documentation it cannot happen, meaning that it's not a documented HTTP status their REST API should ever return. It literally means Payload Too Large (the data sent to the server exceed its capacity to process information) which doesn't make sense in the context as you're trying to upload a file less than 5MB when the size limit for Amazon S3 is 5GB i.e. more than a thousand times bigger. I also see in your log that there's a subsequent 500 Internal Server Error from Amazon when we're trying to delete files. All these together make me thing that the problem may indeed be the "Bucket access" setting.
If you're wondering why this started happening now: Amazon S3 deprecated the "Path access" method for accessing bucket. As a result we changed our code to use virtual hosting bucket access by default, following Amazon's advice. I had already bumped into cases similar to yours in the past, hence the option in the configuration to keep using the legacy method that Amazon says we shouldn't be using (but requires us using for some older buckets -- go figure). It's one of those changes that you're damned if you do and damn if you don't, all because the third party vendor is exhibiting a behavior its documentation says it shouldn't be exhibiting. In other words yet another day in the life of an IT person...
Nicholas K. Dionysopoulos
Lead Developer and Director