AWS重要知識(AWS-SAA,SAP対策) 〜S3篇(ストレージ)〜

注意

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

AWS S3のSLAおよびサービスクレジット

重要度⭐️⭐️⭐️⭐️
下記資料にS3のSLAが記載
https://d1.awsstatic.com/legal/amazons3service/Amazon_S3_Service_Level_Agreement_2023-11-28)_JP.pdf

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

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

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

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

S3バケットポリシーの制限事項

重要度⭐️⭐️⭐️

⚫︎バケットポリシーに関する公式ドキュメント
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/add-bucket-policy.html

注記
バケットポリシーのサイズは 20 KB に制限されています。

S3バケットポリシーのポリシーサイズは20,480バイト（20 KB）以内である必要がある

他の記事を見てると、大規模開発のような場合だとこの制約に当たることが多いみたいです。
⚫︎CTC様の参考記事
https://www.ctc-g.co.jp/solutions/cloud/column/article/118.html

S3バケットポリシーはあくまで『アクセスコントロール』

重要度⭐️⭐️⭐️

例えば、
『S3バケットにアップロードされるファイルのサイズが512MB以上だったら拒否する。』
をS3バケットポリシーで記述することは難しいです。
S3バケットポリシーは『アクセスコントロール』用に用意されたものです。

どうしても実現したい場合は『POST Policy』を使用することで実現可能(らしい)
⚫︎POST Policyに関する公式ドキュメント
https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-HTTPPOSTConstructPolicy.html

(POST Policyは自分も使ったことないのでなんとも言えない。)

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日間

⚫︎署名付きURLの公式ドキュメント
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/using-presigned-url.html#who-presigned-url

署名付き URL は、URL の生成時に指定した期間にわたって有効です。Amazon S3 コンソールで署名付き URL を作成した場合、有効期限は 1 分から 12 時間の間で設定できます。AWS CLI または AWS SDK を使用する場合、有効期限は最大 7 日間に設定できます。

署名付き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のレプリケーション

バケットのバージョニング設定必須

重要度⭐️⭐️⭐️

送信元:送信先両方でバージョニング設定がないとエラーとなります。

オブジェクトロック機能

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

リテンション期間を設定することで一定期間、オブジェクトの削除・上書きを防止する機能

オブジェクトロックには2つのモードがあるz

コンプライアンスモード

『絶対に削除できない』モード

IAMの管理権限やAWS管理者でも削除は不可能

ガバナンスモード

s3:BypassGovernanceRetention権限が付与されたユーザーだけは削除可能

S3　インベントリレポート機能

重要度⭐️⭐️⭐️⭐️

S3バケット内のオブジェクト情報を一覧で取得できる機能(CSV等で出力)

・暗号化されていないオブジェクト
・特定にタグがついているオブジェクト
だけのような出力も可能

⚫︎S3 インベントリレポート機能に関するドキュメント
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/storage-inventory.html

S3 バッチオペレーション機能

重要度⭐️⭐️⭐️

バケット内オブジェクトに対して一括で操作が可能な機能

オブジェクトのコピー
AWS Lambda 関数の呼び出し
すべてのオブジェクトタグを置換する
すべてのオブジェクトタグを削除する
アクセスコントロールリスト (ACL) を置き換える
バッチオペレーションを使ってオブジェクトを復元する
S3 オブジェクトロックの保持

⚫︎S3 バッチオペレーションに関するドキュメント
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/batch-ops-operations.html

S3 Replication Time Control (S3 RTC)機能

重要度⭐️⭐️⭐️⭐️
要件によってはS3バケットのレプリケーションにかかる時間をコントロールしたいことがあります。

⚫︎S3 Replication Time Control (S3 RTC)機能に関するドキュメント↓
https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication-time-control.html

S3 Replication Time Control (S3 RTC) では、データレプリケーションに関するコンプライアンス要件 (またはビジネス要件) への対応をサポートします。また、Amazon S3 レプリケーション時間を可視化します。S3 RTC は、Amazon S3 にアップロードしたほとんどのオブジェクトを数秒でレプリケートし、これらのオブジェクトの 99.99% を 15 分以内にレプリケートします。

オブジェクトを15分以内でレプリケーションすることを保証し、万が一15分以上かかっている場合はアラートを出せる。

Amazon S3 Transfer Acceleration

重要度⭐️⭐️⭐️⭐️

⚫︎Amazon S3 Transfer Accelerationに関するドキュメント
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/transfer-acceleration.html

Amazon S3 Transfer Acceleration は、クライアントと S3 バケットの間で長距離にわたるファイル転送を高速、簡単、安全に行えるようにするバケットレベルの機能です。Transfer Acceleration は、世界各地から S3 バケットへの転送速度を最適化するように設計されています。Transfer Acceleration は、Amazon CloudFront の世界中に点在するエッジロケーションを利用します。エッジロケーションに到着したデータは、最適化されたネットワークパスで Amazon S3 にルーティングされます。

S3 TransferAccessのエンドポイント

⚫︎TransferAccessのエンドポイントURL
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/transfer-acceleration-examples.html

TransferAccessを有効化すると、通常のS3エンドとは異なる下記エンドポイントが作成される
https://testbucket.s3-accelerate.amazonaws.com