はじめに
AWS CLIを導入して、うまいことAPI叩けるかなーなんてとりあえずaws s3 lsを打ったりしますよね。
しませんか。そうですか。
打ったは良いが応答が返ってこない。
何かの権限が足りてない？
せめてエラーか何か返してよ、と思ったことが最近(1年半前)ありました。
いきなり結論
「--region <リージョン>」オプションを付けて打ってください。
例）
aws s3 ls --region ap-northeast-1
権限足りてなかったりしたら、ひとまずそういう趣旨のエラーが返ってきます。
状況が変わらなかったら、ごめんなさい。
蛇足
ちなみに、応答が返ってこない状態でも、数分待ってれば以下のようなエラーが返って来ます。
返ってこなかったら、ごめんなさい。
原因
CLIコマンドを実行したときに、アクセスする先のS3エンドポイントへの通信が行えないため起こります。
（ちなみに本事象はVPCエンドポイント経由でS3へのアクセスを試みる際に起こることを想定しています。）
（単純にセキュリティグループでアウトバウンドがふさがれている時などに同じ事象が起こるか？昔調べた気がしますが忘れました。優しい方教えてください。）
補足
VPCエンドポイント経由で通信を行う際には、ルートテーブルにはターゲットにプレフィックスリストID、ゲートウェイにVPCエンドポイントを指定することになります。
エンドポイントを作成または変更するときは、エンドポイントを通じてサービスにアクセスするために使用する VPC ルートテーブルを指定します。ルートは自動的に各ルートテーブルに追加されて、送信先としてサービス (pl-xxxxxxxx) のプレフィックスリスト ID、ターゲットとしてエンドポイント ID (vpce-xxxxxxxx) が登録されます。その例を以下に示します。
| 送信先 | Target |
|---|---|
| 10.0.0.0/16 | ローカル |
| pl-1a2b3c4d | vpce-11bb22cc |
プレフィックスリストIDはリージョン単位でのパブリックIPの集まりを表すものです。例えば東京リージョンのS3が取りうるIPの集まりを表しているとします。この場合、上記のルートテーブルにおいては、東京リージョン以外のS3への通信は定義されていません。リージョンを指定しないでaws s3 lsを打った場合、アクセス先のS3エンドポイントが東京リージョン以外だと解釈されると、うまく通信が行えないため、エラーが生じます。
（aws ls s3を打った時にどこに向けて通信を行うは、OSにより挙動が異なるようです。後述の参考サイト参照。aws configureの実行など、プロファイルでデフォルトリージョンを明示的に指定することでも回避できる事象です。）
終わりに
事象の切り分けの一助になれば幸いです。
当時自分がハマったのはHTTPプロキシがあったりVPCを跨いだりする構成だったので、泣きたくなりました。
参考サイト
VPC エンドポイント経由で S3 へアクセスする時の注意点
https://dev.classmethod.jp/cloud/aws/sugano-031-vpc-endpoint-to-s3/
追記:手動実行だとうまくいくがシステムユーザによる自動実行だとうまくいかない
例えばWindowsのタスクスケジューラにスクリプトを仕込んで、S3向けのスクリプトを定期実行させるような場合。OSユーザでログオンして手動実行するとうまくいくが、ビルトインのSYSTEMユーザにタスクスケジューラで実行させると失敗してしまう。そんなケースに最近ハマりました。
これも根っこは同じで、スクリプト内のS3コマンドでリージョンを明示的に指定しなかったことが原因でした。OSユーザのホームディレクトリ¥.aws配下にConfigファイルがあり、そこでデフォルトリージョンを指定していたため、実行ユーザによって挙動が変わるという状態に陥っていた訳です。
スクリプト内で--regionオプションをつけることで、デフォルトリージョンがなんであろうとそこに通信が向くので、事象を回避できます。
繰り返しになりますが、ここでOS全体の設定としてhttp_proxyを設定していたりすると、さらに切り分けポイントが増えるので困ったりします。（SYSTEMユーザにだけ環境変数が適用されていなかったり。）がんばれ。