Amazon S3 運用の要点｜ストレージクラスとセキュリティの勘所

はじめに

Amazon S3 は、AWS で最も広く使われるオブジェクトストレージで、バックアップ、データレイク、静的コンテンツ配信、ログ保管など用途は多岐にわたります。手軽に使い始められる一方、運用ではストレージクラスの選定、セキュリティ設定、データ保護、コスト管理といった複数の領域を継続的に押さえる必要があります。設定の既定値もこの数年で変わっており、古い前提のままだと過剰なコストやセキュリティリスクにつながることがあります。

結論として、S3 運用の要点は、アクセス頻度に応じたストレージクラスの選定とライフサイクルによるコスト最適化、Block Public Access と暗号化を前提とした安全な設計、そしてバージョニングと Object Lock によるデータ保護の 3 点に集約されます。

Amazon S3 運用管理の全体像

Amazon S3 は、バケット（コンテナ）にオブジェクト（データ本体とメタデータ）を格納するオブジェクトストレージです。データは指定した AWS リージョン内に保存され、用途に応じてバケット単位で設定を分けて管理します。

汎用バケットとディレクトリバケット

一般的な用途では汎用バケット（general purpose bucket）を使います。高い性能が必要な場合は、Express One Zone ストレージクラスで使うディレクトリバケット（directory bucket）という種別があり、単一の AZ 内で低レイテンシのアクセスを提供します。

管理手段

日常の確認や設定はマネジメントコンソール、定型作業や自動化は AWS CLI（aws s3 / aws s3api）や各言語の SDK から行います。スクリプトや IaC（CloudFormation など）と組み合わせると、設定の再現性を確保できます。

ストレージクラスとコスト最適化

S3 には、アクセス頻度やレイテンシ要件に応じた複数のストレージクラスがあります。代表的なものは次のとおりです。

S3 Standard

頻繁にアクセスするデータ向け。複数 AZ に冗長化され、可用性と性能のバランスが良い既定的な選択肢です。

S3 Intelligent-Tiering

アクセスパターンが不明・変動するデータ向け。アクセス状況に応じて自動的に最適な階層へ移動し、取り出し手数料が発生しません（モニタリング費用がかかります）。

S3 Standard-IA / One Zone-IA

アクセス頻度が低いデータ向け。Standard-IA は複数 AZ、One Zone-IA は単一 AZ でコストを抑えます。

S3 Glacier 各クラス（Instant Retrieval / Flexible Retrieval / Deep Archive）

アーカイブ向け。取り出しの速さとコストのバランスで使い分けます。

S3 Express One Zone

単一 AZ・ディレクトリバケットで、一桁ミリ秒の低レイテンシを提供する高性能クラスです。機械学習やリアルタイム分析など、レイテンシが重要なワークロード向けです。

参考: Amazon S3 storage classes（AWS 公式ドキュメント）
“S3 Express One Zone is the lowest latency cloud object storage class available today”
（S3 Express One Zone は、現時点で最も低レイテンシなクラウドオブジェクトストレージクラス）
https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage-class-intro.html

コスト最適化の中心はライフサイクルポリシーです。 オブジェクトの経過日数に応じて、より低コストなクラスへ自動的に移行（transition）したり、不要になったオブジェクトを失効（expire）させたりできます。アクセス頻度が読みにくいデータには Intelligent-Tiering、明確に頻度が下がっていくデータにはライフサイクルでの段階的な移行、という使い分けが基本になります。

セキュリティの要点

S3 のセキュリティは、公開範囲の制御、暗号化、アクセス権限の最小化が基本です。既定値はこの数年で安全側に変わっており、現行の前提を押さえておくことが重要です。

公開範囲の制御

2023 年以降、新規バケットでは Block Public Access（パブリックアクセスのブロック）が既定で有効、ACL が既定で無効になりました。意図的な公開が不要なら、アカウントレベルとバケットレベルの Block Public Access を有効のまま維持します。静的サイト配信などで公開が必要な場合は、バケットは非公開のまま CloudFront（Origin Access Control）経由で配信する構成が推奨されます。

暗号化

新規オブジェクトは SSE-S3（S3 管理キー）で自動的に暗号化されます。監査性や細かなアクセス制御が必要なら SSE-KMS、より高い要件には二重暗号化の DSSE-KMS を選びます。2025 年 1 月の Codefinger ランサムウェアが、盗まれた認証情報と SSE-C（顧客提供キー）を悪用してオブジェクトを攻撃者のキーで暗号化した事案を受け、2026 年 4 月から新規の汎用バケット（および SSE-C を使っていないアカウントの既存バケット）では SSE-C が既定で無効化されます。 SSE-C が必要な場合のみ、PutBucketEncryption API で明示的に有効化します。

通信の保護

バケットポリシーで aws:SecureTransport を条件に使い、HTTPS（TLS）以外のアクセスを拒否します。

アクセス権限

IAM とバケットポリシーで最小権限を徹底し、レガシーな ACL は無効化します。

監査・検知

CloudTrail のデータイベントで操作を記録し、GuardDuty や IAM Access Analyzer で不審なアクセスや過剰な公開を検知します。

参考: Advanced notice — Amazon S3 to disable SSE-C by default（AWS Storage Blog）
“SSE-C will be disabled by default on all new S3 general purpose buckets”
（新規の S3 汎用バケットでは SSE-C が既定で無効化される）
https://aws.amazon.com/blogs/storage/advanced-notice-amazon-s3-to-disable-the-use-of-sse-c-encryption-by-default-for-all-new-buckets-and-select-existing-buckets-in-april-2026/

データ保護とランサムウェア対策

S3 のデータ保護は、バージョニングを土台に、Object Lock とレプリケーションを組み合わせて多層で考えます。

バージョニング

オブジェクトの上書きや削除のたびに、以前のバージョンを保持します。誤操作やアプリケーション障害からの復旧の基盤になります。

Object Lock（WORM）

指定した保持期間中、オブジェクトバージョンの削除・上書きを禁止します。Object Lock にはガバナンスモードとコンプライアンスモードがあり、コンプライアンスモードでは保持期間中はルートユーザーを含む誰も削除・上書きできません。 ランサムウェアや誤削除に対する強力な防御になります。Object Lock はバケット作成時に有効化し、バージョニングの有効化が前提です。保持期間（retain-until-date）に加え、期限のないリーガルホールドも併用できます。

レプリケーション

クロスリージョン（CRR）または同一リージョン（SRR）に複製し、リージョン障害や局所的な被害に備えます。

参考: Locking objects with Object Lock（AWS 公式ドキュメント）
“a protected object version can’t be overwritten or deleted by any user”
（保護されたオブジェクトバージョンは、いかなるユーザーも上書き・削除できない）
https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html

ランサムウェア対策の観点では、作業用バケットに直接 Object Lock を強くかけるのではなく、別アカウントの専用イミュータブルバケットへレプリケーションする設計が、復旧性と運用性のバランスに優れます。 認証情報の窃取に備え、削除権限の分離（別アカウント・MFA Delete）も組み合わせます。具体的な設定手順は、関連記事『AWS S3 Object Lock でランサムウェア対策｜設定手順と注意点』で扱っています。より広いバックアップ構成の比較は、関連記事『ランサムウェア対策の基本と全体像｜3-2-1-1-0 で守るバックアップ設計』も参考になります。

ファイルアクセスと他サービスとの違い

S3 はオブジェクトストレージで、HTTP(S) や API を介してアクセスします。OS から通常のファイルシステムとして扱う用途には、必ずしも最適ではありません。ファイル共有が目的の場合は、用途に応じて他のサービスと比較して選びます。

Amazon S3

オブジェクトストレージ。大容量・高耐久で、バックアップ、データレイク、静的コンテンツ配信などに向きます。API ベースのアクセスが基本です。

Amazon EFS

NFS ベースのマネージドファイルシステム。複数の EC2 から同時にマウントする Linux 系のファイル共有に向きます。

Amazon FSx

用途別のマネージドファイルシステム群です。Windows File Server（SMB）、Lustre（HPC・高スループット）、NetApp ONTAP、OpenZFS などから選べます。

S3 をファイルのように扱いたい場合は、Mountpoint for Amazon S3（S3 をファイルシステムのようにマウント）や S3 File Gateway（オンプレミスからファイルプロトコルで S3 へ）といった選択肢もあります。POSIX や SMB のファイル共有が必要なら EFS・FSx、オブジェクトとしての保管や API アクセスが中心なら S3、という切り分けが基本です。詳細は関連記事『Amazon S3 Files の仕組みと設定手順｜EFS・FSx との違い』で扱っています。

運用・操作とトラブルシューティング

日常運用では、CLI による操作と、つまずきやすいポイントの把握が役立ちます。

CLI 操作: AWS CLI には、高レベルの aws s3（cp・sync・ls・rm など、ファイル感覚の操作）と、低レベルの aws s3api（個々の API を直接呼ぶ操作）があります。フォルダーやファイルの一括ダウンロードには aws s3 sync や aws s3 cp --recursive が便利です。具体的な手順は、関連記事『AWS CLI で S3 のフォルダを一括ダウンロードする手順｜cp と sync』で扱っています。

バケット削除のつまずき: バケットは空でないと削除できません。バージョニングが有効な場合は、過去のバージョンや削除マーカーが残っているために削除できないことがあります。また、Object Lock で保護されたオブジェクトは保持期間中は削除できず、MFA Delete が有効だと追加の認証が必要になります。これらが「バケットが削除できない」原因の典型です。原因別の対処は、関連記事『Amazon S3 バケットが削除できない 5 つの原因と対処法』で詳しく扱っています。

まとめ

本記事では、Amazon S3 の運用で押さえるべき要点を、ストレージクラスとコスト最適化、セキュリティ、データ保護とランサムウェア対策、ファイルアクセスや運用トラブルの観点から整理しました。S3 は手軽に使える一方で、既定値の変化や保護設計の勘所を押さえているかで、コストと安全性が大きく変わります。要点を以下にまとめます。

• ストレージクラスはアクセス頻度で選びライフサイクルでコスト最適化
• Block Public Access と既定の SSE-S3 暗号化を前提にした安全な設計
• 2026 年 4 月以降は SSE-C が新規バケットで既定無効
• データ保護はバージョニングを土台に Object Lock とレプリケーションで多層化
• ランサムウェア対策は別アカウントの不変バケットへのレプリケーションが有効
• ファイル共有が必要なら S3 ではなく EFS・FSx を選択
• バケット削除はバージョンや Object Lock の保持が妨げになる点に注意

以上、最後までお読みいただきありがとうございました。