Amazon S3 を安全・低コスト・高パフォーマンスに運用するための推奨事項を、観点別にまとめたものです。
目次
1. セキュリティ
1.1 パブリックアクセスの防止
- S3 Block Public Access をアカウントレベルで有効化する（新規バケットはデフォルトで有効）。
- 静的サイトなどで公開が必要な場合も、S3 を直接公開せず CloudFront + OAC（Origin Access Control） 経由で配信する。
- AWS Organizations の SCP で Block Public Access の無効化を禁止する。
1.2 アクセス制御
- ACL は無効化する（Object Ownership を「バケット所有者の強制」に設定。新規バケットのデフォルト）。権限はポリシーで一元管理する。
- 最小権限の原則：IAM ポリシー・バケットポリシーで必要なアクション・プレフィックスに限定する。
- 多数のアプリ・チームが共有するバケットは S3 Access Points でアクセス経路を分離する。
- VPC 内からのアクセスは VPC エンドポイント（Gateway 型） を使い、バケットポリシーで
aws:SourceVpceを条件に制限する。 - IAM Access Analyzer for S3 で外部共有されているバケットを定期チェックする。
1.3 暗号化
- 保存時の暗号化はデフォルトで SSE-S3 が適用される。監査要件や鍵管理が必要な場合は SSE-KMS を使用する。
- SSE-KMS 利用時は S3 バケットキーを有効化し、KMS リクエストコストを削減する。
- 転送時の暗号化として、バケットポリシーで
aws:SecureTransport: falseを Deny し HTTPS を強制する。
1.4 データ保護
- バージョニングを有効化し、誤削除・上書きから復旧できるようにする。
- 重要データには MFA Delete や S3 Object Lock（WORM、コンプライアンス／ガバナンスモード）を検討する。
- ランサムウェア・誤操作対策として、別アカウントへの レプリケーションや AWS Backup による保護を行う。
2. 監視・監査
- CloudTrail で管理イベントを記録し、重要バケットはデータイベント（Get/Put/Delete）も記録する。
- S3 サーバーアクセスログで詳細なリクエスト履歴を取得する（ログ出力先は別バケットにする）。
- AWS Config ルール（例：
s3-bucket-public-read-prohibited、s3-bucket-ssl-requests-only）で設定逸脱を検出する。 - Amazon GuardDuty（S3 Protection） で不審なアクセスを検知する。
- Amazon Macie で個人情報などの機密データの所在を把握する。
- S3 Storage Lens でアカウント全体の利用状況・コスト効率・データ保護状況を可視化する。
- Security Hub で S3 関連のセキュリティ基準をまとめて評価する。
3. コスト最適化
3.1 ストレージクラスの選択
| ストレージクラス | 用途 |
|---|---|
| S3 Standard | 頻繁にアクセスするデータ |
| S3 Intelligent-Tiering | アクセスパターンが不明・変動するデータ |
| S3 Standard-IA / One Zone-IA | アクセス頻度は低いが即時取得が必要なデータ |
| S3 Glacier Instant Retrieval | 四半期に一度程度アクセスするアーカイブ |
| S3 Glacier Flexible Retrieval | 分〜時間単位の取り出しで良いアーカイブ |
| S3 Glacier Deep Archive | 長期保存（年単位）、取り出し頻度が極めて低いデータ |
- 迷ったら Intelligent-Tiering を検討する（ただし小さなオブジェクトはモニタリング料金・最小サイズに注意）。
- IA / Glacier 系は最小保存期間と最小課金サイズ、取り出し料金があるため、アクセスパターンを確認してから選ぶ。
3.2 ライフサイクルルール
- 一定期間経過したオブジェクトを低コストクラスへ自動移行・削除する。
- バージョニング有効時は 非現行バージョンの有効期限を設定し、古いバージョンの蓄積を防ぐ。
- 不完全なマルチパートアップロードの中止ルール（例：7日）を必ず設定する。
- 削除マーカーの期限切れ削除も設定しておく。
3.3 その他
- ストレージクラス分析や Storage Lens でアクセス傾向を把握する。
- 同一リージョン内の EC2 などからは VPC Gateway エンドポイント経由でアクセスし、NAT Gateway のデータ処理料金を回避する。
- 不特定多数へのダウンロード配信は CloudFront を使い、データ転送コストを抑える。
- コスト配分タグをバケットに付与し、部署・プロジェクト単位でコストを追跡する。
4. パフォーマンス
- S3 はプレフィックスごとに PUT/COPY/POST/DELETE 3,500 req/秒、GET/HEAD 5,500 req/秒 を処理できる。高スループットが必要な場合はプレフィックスを分散して並列化する。
- 大きなファイル（目安 100MB 以上）は マルチパートアップロードを使う。ダウンロードは Range GET で並列化する。
503 Slow Downに備え、SDK のエクスポネンシャルバックオフ付きリトライを有効にする。- 遠隔地からのアップロードは S3 Transfer Acceleration を検討する。
- 低レイテンシが必要なワークロードは S3 Express One Zone（ディレクトリバケット）を検討する。
- 必要な部分だけ取得したい場合は、Athena などのクエリサービスや列指向フォーマット（Parquet 等）を活用する。
- 小さなファイルが大量にある場合は、まとめて大きなファイルにすることでリクエスト数・コストを削減する。
- アプリケーションと S3 バケットは同じリージョンに配置する。
5. 可用性・耐障害性
- 標準のストレージクラスは複数 AZ にデータを保存するが、One Zone 系は単一 AZ のため再作成可能なデータのみに使う。
- リージョン障害や DR 対策には Cross-Region Replication (CRR) を使う。
- 既存オブジェクトのレプリケーションには S3 Batch Replication を使う。
- RTO/RPO 要件が厳しい場合は Replication Time Control (RTC) を有効化する。
- マルチリージョン構成では Multi-Region Access Points でアクセスを集約・フェイルオーバーする。
6. 運用・設計
6.1 バケット設計
- バケット名はグローバルに一意。推測されにくい命名（環境名・アカウント識別子などを含める）にし、ドットを避ける（TLS 証明書の問題を回避）。
- 用途・環境（dev/stg/prod）・データ分類ごとにバケットを分け、ポリシーをシンプルに保つ。
- タグ付け（Owner、Environment、DataClassification など）を標準化する。
6.2 Infrastructure as Code
- バケットやポリシーは CloudFormation / CDK / Terraform で管理し、手作業による設定ミスを防ぐ。
- セキュリティ設定（Block Public Access、暗号化、HTTPS 強制、バージョニング）をテンプレート化して標準化する。
6.3 大量オブジェクトの操作
- 大量のオブジェクトへのタグ付け・コピー・復元などは S3 Batch Operations を使う。
- オブジェクト一覧の把握には
ListObjectsを繰り返すより S3 Inventory を使う。
6.4 イベント駆動
- オブジェクト作成・削除をトリガーにした処理は S3 Event Notifications または EventBridge を使う。
- 通知の重複や順序の入れ替わりがあり得るため、処理側は冪等に実装する。
6.5 一時的なアクセス
- 外部ユーザーへのアップロード・ダウンロード許可は 署名付き URL（Presigned URL） を使い、有効期限を短く設定する。
7. チェックリスト
- Block Public Access がアカウントレベルで有効
- ACL が無効（バケット所有者の強制）
- HTTPS 以外のリクエストを Deny
- 暗号化方式を要件に合わせて選択（SSE-KMS の場合はバケットキー有効）
- バージョニング有効（重要データ）
- 非現行バージョン・不完全なマルチパートアップロードのライフサイクルルール設定済み
- CloudTrail / アクセスログ / Config ルールで監視
- GuardDuty S3 Protection / Macie の利用を検討
- 適切なストレージクラス・ライフサイクルでコスト最適化
- DR 要件に応じたレプリケーション設定
- IaC でバケット設定を管理
- タグ付けルールを統一