TL;DR

cliコマンドで、
s3 cpなら403としか出ないが、
s3api get-objectで、

IAMの権限不足なら

no identity-based policy allows the s3:GetObject action

Backet policyなら

denied by a resource-based policy

403エラー

s3 cpした時に403エラーが出たことはありませんか？

私は、CICDの実装や実際にテストをしているときなどにこのエラーにたまに直面します。

この時、どの権限(バケットポリシー、IAM)で落ちたのか？、ログに出してくれよ、、と思いませんか。

そこでs3apiを使うことを推奨できます。

s3 cp のとき

s3 cpをしたときには、このエラーしか出ません。

fatal error: An error occurred (403) when calling the HeadObject operation: Forbidden
Build step 'Execute shell' marked build as failure

s3api get-object のとき

aws s3api put-object --bucket my-bucket --key test.txt --body test.txt

このようなログが出力されます。（ログはマスキングしています）

An error occurred (AccessDenied) when calling the GetObject operation: User: arn:aws:sts::111111111:assumed-role/AAAAA-Role/i-111111111 is not authorized to perform: s3:GetObject on resource: "arn:aws:s3:::AAAAbacket/AAAAfile.tar.gz" because no identity-based policy allows the s3:GetObject action

どのロールでどのバケットに掴みに行っているのか、がよりわかりやすいログが出ました。
このエラーによって、

no identity-based policy allows the s3:GetObject action

とあるので、
IAMが原因で、どのIAMが原因か、まで、わかることができます。
S3が原因のときは、

denied by a resource-based policy

のようなエラーになるので切り分けできます。

また、より詳細には、
--debugオプションを使うことで、
verboseなログを確認することもできますが、こちらはヘッダーなどの確認も含める場合に使えます。

できれば、どのポリシーや、条件で弾かれたのか、までわかるといいなと思いますが、s3apiを使うだけでも特定のロールに着目してポリシーを確認できるので、原因特定までかなり近いですね。

そもそもこれらの違いは何か。

s3 cpの方は、高レベルコマンド、と呼ばれ、よりunixライクな形で、日常使いできるコマンドです。
s3apiの方はapiを直接実行するような形なので、より詳細なエラーログが出せるようになっています。

参考リンク

以上