注意

2025/2時点での情報となります。

バケット名は『全世界でユニーク』でないといけない

重要⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️
S3はグローバルサービスです。
アカウントごとにバケットは紐付けられてこそいますが、名前空間はグローバル。
そのため、
誰かがバケット名『Test-backet』を作っていた場合、自分のアカウントで『Test-backet』という名前のバケットは作れなくなります。

S3の名前解決は以下のようなURLがDNSに登録される
<バケット名>.s3.amazonaws.com

このことからも重複は許されないのが分かる

ACLはほぼ使わない

重要度⭐️⭐️⭐️

下記はS3のセキュリティに関するベストプラクティスです。
アクセスコントロールリストはバケット単位の制御であれば使わなくてもいいと推奨されています。
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/security-best-practices.html

パブリックアクセスは不必要なら閉じる

重要度⭐️⭐️⭐️⭐️⭐️
当然ですね。

静的WEBホスティングぐらいでしか用途はない気がしますが...
静的WEBホスティングでも前段階でNLBやALBを挟んでいるのでそんな使うイメージはない...

S3のサーバーアクセスログ機能

S3バケットに対するアクセスログを取得する機能
ログは別のS3バケットに出力される
デフォルトだと無効になっている
機能自体は無料だがログの保存に関する料金は発生

S3サーバーアクセスログに関する公式ドキュメント
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/enable-server-access-logging.html

S3のアクセスログ出力先S3バケットは同じリージョンでないといけない

重要度⭐️⭐️

アクセスログを別のリージョンに保管することは単体では不可能
S3のレプリケーション機能で他のリージョンにコピーするしかない

S3のアクセスログはベストエフォート型

重要度⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️

つまり、『全てのログが残ることは保障されない』
重大なデータをS3に保管していて誰がいつ取得したかなどの監査用のログが欲しいなどのユースケースではS3のアクセスログは不適切です
ログを確実に取得したい場合は、CloudTrail S3オブジェクトレベルログを使いましょう。

S3を静的WEBホスティングで使っていてどの時間帯にアクセスが多いか？どのデータにアクセスが多いか？といった分析用データとして使うならCloudTrailよりこっちに軍配が上がります。

送信先のS3バケットポリシーにログ配信の許可が必要

重要度⭐️⭐️⭐️⭐️⭐️

Amazon S3 は特別なログ配信アカウントを使用してサーバーアクセスログを書き込みます。このような書き込みは、通常のアクセスコントロールの制約に従います。アクセスログを配信するには、ロギングサービスプリンシパル (logging.s3.amazonaws.com) に送信先バケットへのアクセス権を付与する必要があります。

バケットポリシーを使用したアクセスの付与
送信先バケットでバケットポリシーを使用してアクセスを許可するには、バケットポリシーを更新して、ログ記録サービスプリンシパルに s3:PutObject アクセス許可を付与します。Amazon S3 コンソールを使用してサーバーアクセスのログ記録を有効にすると、コンソールは、送信先バケットのバケットポリシーを自動的に更新して、ログ記録サービスプリンシパルにこのようなアクセス許可を付与します。プログラムでサーバーアクセスのログ記録を有効にする場合、送信先バケットのバケットポリシーを手動で更新して、アクセスログ配信用のログ記録サービスプリンシパルへのアクセス権を付与する必要があります。

つまり、送信先バケットは
logging.s3.amazonaws.com に
s3:PutObject を許可する必要がある

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "logging.s3.amazonaws.com"
      },
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::your-log-bucket-name/AWSLogs/your-source-bucket-name/*",
      "Condition": {
        "ArnLike": {
          "aws:SourceArn": "arn:aws:s3:::your-source-bucket-name"
        }
      }
    }
  ]
}

アクセスログの送信先バケットはオブジェクトロックができない

重要度⭐️⭐️⭐️

これも公式ドキュメントに明記

S3 オブジェクトロックが有効になっている S3 バケットは、サーバーアクセスログの送信先バケットとして使用できません。送信先バケットにはデフォルト保持期間設定を指定できません。

どうしてもオブジェクトロックしたい場合は送信先S3バケットのレプリケーション機能のレプリケーション先でオブジェクトロックする
(そこまでやるならCloudTrailでよくね？)

S3で暗号化通信でのアクセスのみ許可する

重要度⭐️⭐️⭐️⭐️⭐️⭐️

俗に言う、HSTS的な奴
バケットポリシーのCondition句で制御可能

  "Condition": {
        "Bool": {
          "aws:SecureTransport": "false"
        }

S3のバージョニングは上限なし

重要度⭐️⭐️⭐️

S3のバージョニングは上限なし。
ライフサイクルルールで世代管理しないとオブジェクトの全てのバージョンを無期限に保持する

コスト的に無駄なので基本的に何世代管理するか、アーカイブに移すかどうかは考慮しておくべきだろう。

マルチパートアップロード

重要度⭐️⭐️⭐️⭐️⭐️

マルチパートアップロードとは？
大容量ファイルをS3にアップロードする際に分割してアップロードしてくれる機能

マルチパートアップロードのユースケース

重要度⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️

マルチパートアップロードは、5GB以上のファイルアップロードで必須！
(5GB以上だとPUTでS3アップロード不可)

ただし、AWSでは100MB以上でマルチパートアップロードを使用するように推奨されている模様。
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/qfacts.html

マルチパートアップロードを使用すると、単一のオブジェクトをパートのセットとしてアップロードすることができます。各パートは、オブジェクトのデータの連続する部分です。オブジェクトのすべてのパートがアップロードされたら、Amazon S3 はこれらのパートを組み立ててオブジェクトを作成します。通常、オブジェクトサイズが 100 MB 以上の場合は、単一のオペレーションでオブジェクトをアップロードする代わりに、マルチパートアップロードを使用することを考慮してください。マルチパートアップロードの詳細については、「マルチパートアップロードを使用したオブジェクトのアップロードとコピー」を参照してください。

不完全なマルチパートアップロードの削除設定

重要度⭐️⭐️⭐️⭐️

マルチパートアップロードが途中で中断/失敗されるとアップロード途中の残骸ファイルがs3に残ってしまう。
さらに、この分はS3のストレージ課金対象となる。

S3ライフサイクルルールで「未完了のマルチパートアップロード」の削除設定を忘れないようにしよう。

署名付きURL

署名付きURLとは？
S3バケットに期間限定でアクセスできるURLを発行できる機能

署名付きURL発行

重要度⭐️⭐️⭐️

発行には　s3:GetObject が必要。
まぁ普通は大抵アタッチされているはず

署名付きURLの期間

重要度⭐️⭐️⭐️

署名付きURLはコンソール作成とCLI作成で最大の期間指定が異なる。

コンソール作成:最大12時間
CLI作成　　　:最大7日間

参考
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/using-presigned-url.html#who-presigned-url

署名付きURLのアクセス制限

重要度⭐️⭐️⭐️⭐️⭐️

署名付きURLはURLさえ共有すれば基本的に誰でもアクセス可能となる。(発行したユーザーのIAM認証情報を借りる形になる)

しかし、うまくやるとIPアドレス制限などもできるらしい。
S3バケットポリシーで署名付きURLの場合の制御構文を記載することで実現可能。
下記記事を参考にさせて頂いた。
https://dev.classmethod.jp/articles/s3-pre-signed-url-ip-restriction/

S3のCORS

CORS（Cross-Origin Resource Sharing）は、Webブラウザが異なるオリジン（ドメイン、プロトコル、ポートの組み合わせ）間でリソースをやり取りする際の制約を管理する仕組み

S3でもCORSが採用されているため、他ドメインからS3にGET/PUTでアクセスしようとするとエラーが発生する可能性がある。
静的WEBホスティングや、署名付きURLでも同様。

S3でCORSを許可する設定を追加する必要あり。

バケットのCORS設定
[
    {
        "AllowedHeaders": [
            "*"
        ],
        "AllowedMethods": [
            "GET"
        ],
        "AllowedOrigins": [
            "*"
        ],
        "ExposeHeaders": [],
        "MaxAgeSeconds": 3000
    }
]

S3のレプリケーション

レプリケーションでは、バケットのバージョニング設定必須

重要度⭐️⭐️⭐️
バージョニング設定がないとエラーとなります。

レプリケーションはプレフィックスとタグでも指定可能

重要度⭐️
プレフィックスは一般的だが、タグでもレプリケーション指定できるみたい。
タグつけるのが面倒臭そう...