При ошибках в работе с #S3 бакетами есть некоторый набор вещей, что требуется проверить, чтобы найти причину и всё исправить. Очевидные проблемы доступа (не настроенные права) не в счёт, как и вопросы шифрования (это отдельная тема). Далее выстраданные болью и болью вещи.

===
Некоторые достаточно очевидные, что нужно перебрать и проверить.
===

• регион бакета - он может отличаться от того, из которого идёт доступ

• в современных регионах - только Signature Version 4

• популярные ошибки в #IAM: не стоит политика на бакет без * (звёздочки, wildcard):

"Action": [
    "s3:GetObject",
    "s3:ListBucket",
],
"Resource": [
    "arn:aws:s3:::my-bucket",
]

... или наоборот (только с *)

"Action": [
    "s3:GetObject",
    "s3:ListBucket",
],
"Resource": [
    "arn:aws:s3:::my-bucket/*",
]

• есть операция с каталогом, а нет политики 's3:ListBucket'

===
Некоторые не самые и совсем неочевидные (из серии #magic).
===

• сильно отличается время на инстансе (в любую сторону - несколько минут и больше), что часто даёт #error:

A client error (403) occurred when calling the HeadObject operation: Forbidden

• версия #aws_cli старая (локально на старых виртуалках)

• стоит флажок --recursive, а работа идёт с файлом (может возникнуть после копипаста в скриптах) — в результате ничего не будет - ни ошибки (что самое противное), ни копирования файла

• при операциях с https - нужно учитывать заголовки в CORS (что есть HEAD среди них, который часто по дефолту не стоит)

<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<CORSRule>
    <AllowedOrigin>*</AllowedOrigin>
    <AllowedMethod>HEAD</AllowedMethod>
    <AllowedMethod>PUT</AllowedMethod>
    <AllowedMethod>POST</AllowedMethod>
    <AllowedMethod>GET</AllowedMethod>
    <AllowedHeader>*</AllowedHeader>
</CORSRule>
</CORSConfiguration>

• проверяем доступ на конкретный файл с помощью

aws s3api get-object-acl --bucket my-bucket --key my-path/some.file

... если получаем ошибку:

An error occurred (AccessDenied) when calling the GetObjectAcl operation: Access Denied

... хотя точно есть все права/роли для бакета (на другой аккаунт, нужные операции и путь), то значит файлы в бакете имеют хозяина, недоступного запрашиваемому — см. выше про #shared_bucket
В нормальной ситуации был бы ответ типа:

{
"Owner": {
"DisplayName": "my-dev",
"ID": "c0123f42b8a1bed065b8a1b2fdbf76c1b6acda99e0778822e3cece21a8c71058"
},
"Grants": [
{
"Grantee": {
"Type": "CanonicalUser",
"DisplayName": "my-dev",
"ID": "c0123f42b8a1bed065b8a1b2fdbf76c1b6acda99e0778822e3cece21a8c71058"
},
"Permission": "FULL_CONTROL"
},
{
"Grantee": {
"Type": "CanonicalUser",
"DisplayName": "jenkins",
"ID": "8933ecf5e61d2b67a525edee13f7667ab45d2be85b1fdb82a9338a60609ee5f9"
},
"Permission": "FULL_CONTROL"
}
]
}

... где перечислены все owner-ы файла. Итого (при такой ошибке) нужно перезалить файл с owner-ом аккаунта, откуда идёт чтение, либо изменить (добавить) owner-а или же переключаться в роль аккаунта, где есть права для операции чтения.

#s3_debug