【AWS】“Aws::S3::Errors::AccessDenied in 〇〇sController#create”エラー（AWSのS3に保存されない）

エラー内容

AWSのS3を使い、画像データを保存できるように実装していたが、

1. ローカル環境においてエラー
2. 本番環境においてエラー
3. AWSのS３上のバケットにはデータなし（保存されていない）
   という事象が発生。

ローカル環境↓

本番環境↓

エラーが起こったときのターミナルのログ↓

エラーが起こったときの設定の状況

• macOS Catalina バージョン10.15.7
• Rails Rails 6.0.3.4
• Herokuを使ってデプロイ
• AWSのアカウント・IAMユーザー・S3のバケットの３つを新規作成したばかり

解決した方法（結論）

「AWSのアカウント削除→作成し直し」を行ったところ、エラー解決。
（保存できるようになった）

解決方法の補足

• AWSアカウント作成時、Googleのシステム障害が発生していた。
• メンターさんにも見てもらいタイポや記述もれが無いのにも関わらず、保存ができなかった。
• アカウントの新規作成から1日以上、保存できない状況が続いた。（時間をおいても反映されない）
• AWSアカウントを削除して、新規登録し直す際、前回登録していたメールアドレスが９０日間以内であれば再開できる対象になるからか、使えない状況になる。（前回のメールアドレス以外を選択しないといけない）
• こちらの方法を試すも、今回は上手くいかなかった。

AWSアカウント作成し直す前の確認作業

####　（１）AWS上のバケットポリシーは適切か？

結果：①②あたる部分は、ともに適切だった。

{
   "Version": "2012-10-17",
   "Id": "Policy1544152951996",
   "Statement": [
       {
           "Sid": "Stmt1544152948221",
           "Effect": "Allow",
           "Principal": {
               "AWS": "①今回のIAMユーザーのARNをここに記述"
           },
           "Action": "s3:*",
           "Resource": "arn:aws:s3:::②今回のバケット名をここに記述"
       }
   ]
}

####　（２）ブロックパブリックアクセスのバケット設定は適切か？

結果：適切だった。

####　（3）VSコード上の、保存先は適切か？

結果：適切だった。

:amazonになっているのでOK。（開発環境）

config/environments/development.rb

  # Store uploaded files on the amazon file system (see config/storage.yml for options).
  config.active_storage.service = :amazon

:amazonになっているのでOK。（本番環境）

config/environments/production.rb

  # Store uploaded files on the amazon file system (see config/storage.yml for options).
  config.active_storage.service = :amazon

”今回のバケット名”にあたる部分について、合っていたためOK。

config/storage.yml

amazon:
  service: S3
  region: ap-northeast-1
  bucket: 今回のバケット名
  access_key_id: <%= ENV['AWS_ACCESS_KEY_ID'] %>
  secret_access_key: <%= ENV['AWS_SECRET_ACCESS_KEY'] %>

####　（４）環境変数は適切か？

結果：適切だった。

環境変数の確認方法(MacOSがCatalina以降の場合)

terminal

vim ~/.zshrc

• :wqで閉じる。
• もし誤っていた場合にはiを押して編集し、escを押してから、:wqで閉じる。

コンソール確認

• rails cで立ち上げ。
• storage.ymlに記載の変数名を入力。
  

確認した内容は以上。

AWSアカウント（ルートユーザー）を作り直し

上記の通り、確認したが誤りはない様子。
思い当たる仮説としては、「Googleの調子が悪い頃、ちょうどアカウント登録していた」だったため、アカウントを作り直すことにした。

1. 請求がゼロか確認
2. バケットの削除
3. IAMユーザーの削除（今回はルートユーザーに紐づけて作成したため、無し）
4. AWSアカウント（ルートユーザー）の削除
   （補足）リンク先は、１と同じ。

AWSを作り直したあとは、

• 環境変数の設定し直し
• バケットポリシーの設定し直し
  が必要となる。

感想

• 今回のケースは、因果関係が定かではないが、「システム障害が起きている前後は、アカウントの作成をしないほうがよい」ことを学んだ。
• 今回はアカウントを新規作成したばかりで、作り直しの手間はかかるが、他に消えると困る設定をしていなかったのでラッキーだった。
• ２回作成したので、AWS作成の復習になった。

以上です。
同じように困った人の解決になれば幸いです。
（間違いあった時は、教えてください！）