Amazon S3 (Simple Storage Service)

は、にオブジェクトを保存するマネージドなサービスです。画像、ログ、バックアップ、、静的 Web サイト、アプリケーションデータなど、大量のを高いで保存する用途に向いています。

SAA では、単に「ファイルを置くサービス」としてではなく、アクセス頻度、復旧要件、公開範囲、暗号化、コスト、他サービスとの連携を踏まえて、適切な S3 機能を選べるかが問われます。

Point

S3 = Simple Storage Service の略です。
「Simple」は「シンプルな」、「Storage」は「保管場所」という意味です。
つまり、S3 は「データをシンプルに保管するサービス」と覚えると入りやすいです。
和訳
- Simple: 単純な、簡単な
- Storage: 保管、貯蔵
- Weblio英和辞書「storage」

概要

は、画像、ログ、バックアップファイル、分析用データなどを入れておくための大容量ストレージです。身近な言い方をすると、「たくさんのファイルを安全に保管して、必要なときに取り出せる場所」と考えると理解しやすいです。

S3 では、データをという入れ物に保存します。バケットの中に入る 1 つ 1 つのファイルのようなデータを、オブジェクトと呼びます。たとえば、images/logo.png や logs/2026/01/app.log のような単位で保存します。

SAA の学習では、S3 そのものの細かいよりも、「どの保存方法を選ぶか」「公開してよいか」「暗号化やバックアップをどうするか」「コストをどう下げるか」を判断できることが重要です。特に、、アクセス制御、暗号化、、ライフサイクル、はよく問われます。

見るポイント	代表的な判断
どれくらい読むか	よく読むデータか、ほとんど読まないデータかでストレージクラスを選びます。
誰に見せるか	非公開にするか、経由で公開するかを考えます。
消えたら困るか	バージョニング、レプリケーション、バックアップを検討します。
長く安く保管したいか	ライフサイクルで安いストレージクラスへ移します。
守るべきデータか	暗号化、、アクセスログ、などを検討します。

主要技術

①バケット、オブジェクト、キー

名はパーティション内で一意です。また、バケット名とは作成後に変更できません。一般的な SAA の設計問題では、多くの場合は汎用バケットを前提に考えます。

バケット種別	主な用途	SAA での見方
汎用バケット	通常のオブジェクト保存	ほとんどの設計問題で基本になります。
ディレクトリバケット	S3 Express One Zone などの低用途	単一配置や低遅延要件が明示された場合に検討します。
テーブルバケット	形式の表データ	分析基盤寄りの文脈で登場しますが、SAA では汎用バケットとの違いを押さえます。
バケット	ベクトルデータの保存・検索	生成 AI や検索の文脈で使われます。SAA では深掘りより用途の区別を意識します。

S3 Express One Zone のような低レイテンシ用途ではディレクトリバケットが関係します。ただし、単一 AZ 内に保存する特性があるため、標準的なマルチ AZ が必要なデータとは選択基準が異なります。

オブジェクトキーには、フォルダのように見えるプレフィックスを含められます。ただし、S3 は階層型ファイルシステムそのものではありません。ファイルロック、ブロック更新、からの通常マウントを前提にした要件では、やと比較します。

⚠️ 頻出: 「複数 AZ にまたがる高耐久なオブジェクト保存」は S3 Standard、「のルートボリュームや低遅延」は EBS、「複数 EC2 から共有する Linux ファイルシステム」は EFS を選びます。

②ストレージクラス

のは、アクセス頻度、可用性、取り出し時間、コストで選択します。頻繁にアクセスする本番データは S3 Standard、アクセス頻度が低いが即時アクセスが必要なデータは S3 Standard-、単一でよく再作成可能な低頻度アクセスデータは S3 One Zone-IA が候補になります。

ストレージクラス	主な用途	可用性・配置の考え方	取り出し	試験での判断ポイント
S3 Standard	頻繁にアクセスする本番データ	複数 AZ を前提にした汎用クラス	即時	迷ったら基本形です。高耐久・高可用な通常データに向きます。
S3 Standard-IA	低頻度だが即時アクセスが必要なデータ	複数 AZ	即時	バックアップや災害対策データなど、読む頻度は低いがすぐ必要な場合に選びます。
S3 One Zone-IA	再作成可能な低頻度アクセスデータ	単一 AZ	即時	AZ 障害時の損失を許容できる場合だけ選びます。
S3 Intelligent-Tiering	アクセスパターンが不明または変動するデータ	複数 AZ	階層により異なります	自動階層化でしたい場合に選びます。
Instant Retrieval	ほとんど読まないが即時取得が必要な	複数 AZ	ミリ秒	アーカイブでも即時取得が必要な場合に選びます。
S3 Glacier Flexible Retrieval	長期アーカイブ	複数 AZ	数分から数時間	取り出し待ちを許容できるバックアップに向きます。
S3 Glacier Deep Archive	最低コスト重視の長期保管	複数 AZ	長時間	法定保管など、ほぼ読まないデータに向きます。
S3 Express One Zone	高頻度・低アクセス	単一 AZ	低レイテンシ	コンピュートと同じ AZ に寄せる性能要件で検討します。

Point

IA = Infrequent Access（低頻度アクセス） の略です。
つまり、名前の意味は次のように読みます。
- S3 Standard = 頻繁にアクセスするデータ向け
- S3 Standard-IA = あまりアクセスしないデータ向け
- S3 One Zone-IA = 1 つの AZ に置く、あまりアクセスしないデータ向け
Intelligent-Tiering は「賢く階層を切り替える」という意味です。
- アクセス頻度が読めないときに、自動で階層を調整するイメージです。
Glacier は「氷河」という意味です。
- すぐには使わないデータを、冷凍保存のように長く安く保管するイメージです。
和訳
- Infrequent: たまの、まれな
- Weblio英和辞書「Infrequent」
- Glacier: 氷河
- Weblio英和辞書「glacier」

アクセスパターンが読めない場合は S3 Intelligent-Tiering を使うと、アクセス状況に応じて階層を自動移動できます。長期アーカイブでは、S3 Glacier Instant Retrieval、S3 Glacier Flexible Retrieval、S3 Glacier Deep Archive を使い分けます。取り出しが即時か、数分から数時間か、さらに長くてもよいかで選択が変わります。

S3 Express One Zone は、単一 AZ 内で低レイテンシアクセスを狙う特殊なストレージクラスです。標準的なバックアップやではなく、コンピュートと同じ AZ に配置して高頻度・低遅延でアクセスするワークロード向けに考えます。 S3 のまま使え、1 桁ミリ秒のアクセスを安定して得られる一方、データは選んだ 1 つの AZ の中だけに保存されます。

S3 の転送性能は、ストレージクラスを変えなくても並列化で伸ばせます。 S3 は 1 つのプレフィックスあたり毎秒 3,500 件以上のと 5,500 件以上の GET/HEAD を処理でき、プレフィックスの数に上限はないため、キーを複数のプレフィックスに分けて並列に読み書きすれば合計の性能が伸びます。新しい高いリクエストレートへのスケールは徐々に進み、その間は 503 Slow Down が返ることがあります。 1 回の PUT で送れるのは 5 GB までで、大きなオブジェクトはマルチパートアップロードでパートを並列に送ります。読み取りは Range ヘッダーを付けた GET (バイト範囲フェッチ) で 1 つのオブジェクトの異なる範囲を並列に取得でき、失敗時も範囲単位で再試行できます。一方、Transfer Acceleration は遠く離れたクライアントとの距離による遅延を縮める機能で、同じのからの転送は速くなりません。

低頻度・アーカイブ系のクラスは、保存単価が安い代わりに料金の条件があります。 Standard-IA は月に1回程度、Glacier Instant Retrieval は四半期に1回程度読むデータを想定しており、どちらも GB 単位の取り出し料金がかかります。最低保存期間は Standard-IA と One Zone-IA が 30 日、Glacier Instant Retrieval と Glacier Flexible Retrieval が 90 日、Glacier Deep Archive が 180 日で、期間内に削除・上書き・移行すると残りの日数分も課金されます。 Standard-IA、One Zone-IA、Glacier Instant Retrieval は 128 KB 未満のオブジェクトも 128 KB として課金します。 Glacier Flexible Retrieval と Deep Archive はオブジェクトごとに 40 KB の管理用メタデータ (うち 8 KB は Standard の料金) が加わるため、小さなオブジェクトは多数のまま送らず、まとめて大きなオブジェクトにしてから保存すると、保存の上乗せとリクエスト料金を抑えられます。

クラス・階層	料金の条件	判断ポイント
Intelligent-Tiering	オブジェクトごとの監視・自動化料金。取り出し料金はなし	30 日アクセスがないと低頻度層、90 日でアーカイブインスタント層へ自動で下がります。128 KB 未満は監視対象外で高頻度層に残ります。
Intelligent-Tiering のアーカイブ層	有効化した場合だけ使われる (任意)	Archive Access は 90 日以上、Deep Archive Access は 180 日以上アクセスがないと移り、読むには復元が必要です。
Glacier Flexible Retrieval の取り出し	迅速 (1〜5 分)、標準 (3〜5 時間)、大容量 (5〜12 時間)	大容量 (Bulk) は最も安く、Flexible Retrieval では無料です。
Glacier Deep Archive の取り出し	標準 (12 時間以内)、大容量 (48 時間以内)	迅速取り出しはありません。

⚠️ 頻出: 「アクセスパターン不明でコスト最適化」は Intelligent-Tiering、「めったに読まないが即時取り出し」は Glacier Instant Retrieval、「最安の長期保管で取り出しに時間を許容」は Glacier Deep Archive が選択肢になりやすいです。

③バージョニング、ライフサイクル、削除保護

を有効にすると、同じキーの過去世代を保持できます。誤削除や誤上書きから戻す要件では、バージョニングが基本対策になります。削除操作では削除マーカーが作成され、過去バージョン自体は残ります。完全削除には、過去バージョンの削除も考慮します。

機能	目的	何を防ぐ・最適化するか	注意点
バージョニング	過去世代の保持	誤削除、誤上書きからの復旧	古いバージョン分の保存コストが発生します。
ライフサイクル	自動移行・自動削除	、保持期限管理	移行先クラスの取り出し時間と料金を確認します。
Object Lock	保護	改ざん、削除、上書きの防止	モードでは解除制約が強くなります。
Delete	削除操作の追加保護	重要オブジェクトの不用意な削除	運用負荷が増えるため、試験では要件が明示された場合に考えます。
Replication	別への複製	、データ所在地、ログ集約	誤削除や誤更新も複製され得るため、保護策と組み合わせます。

Point

WORM = Write Once, Read Many の略です。
直訳すると「1 回書いて、何度も読む」です。
つまり、Object Lock は「一度保存したデータを、あとから勝手に変更・削除できないようにする」ための機能です。
Lifecycle は「ライフサイクル、寿命の流れ」という意味です。
- データを作成してから、安い保存先へ移し、最後に削除するまでの流れを管理します。
和訳
- Write: 書く
- Read: 読む
- Lifecycle: 生活環、寿命、ライフサイクル
- Weblio英和辞書「lifecycle」

ライフサイクルルールは、一定期間後に別のへ移行したり、期限切れのオブジェクトや古いバージョンを削除したりする機能です。ログ、バックアップ、分析用データのように時間経過でアクセス頻度が下がるデータでは、ライフサイクルでコストを下げる設計がよく問われます。ルールはバケット全体のほか、プレフィックス、タグ、オブジェクトサイズで対象を絞れ、既存のオブジェクトにも今後のオブジェクトにも効きます。 128 KB 未満のオブジェクトは、移行のリクエスト料金が保存料金の削減を上回りやすいため、既定では移行の対象になりません。有効期限による削除にはリクエスト料金がかからず、期限を過ぎた分の保存料金も発生しません。バージョニングを有効にしたバケットでは、NoncurrentVersionExpiration で古いバージョンを一定日数後に完全削除し、AbortIncompleteMultipartUpload で完了しなかったマルチパートアップロードのパートを削除します。どちらも放置すると見えないところで保存料金が増えるため、S3 Storage Lens の無料 (非現行バージョンのバイト数、不完全なマルチパートアップロードのバイト数) で、組織全体のどのバケットに溜まっているかを確認できます。

Object Lock は WORM 要件に使います。コンプライアンスや改ざん防止の要件がある場合は、バージョニングだけでなく Object Lock が必要かを判断します。 MFA Delete は削除操作の保護に使えますが、運用上の制約もあります。試験では、誤削除対策としてバージョニング、改ざん防止として Object Lock を切り分けます。

Object Lock の保持期間には 2 つのモードがあります。モードでは、s3:BypassGovernanceRetention 権限を持つ利用者が要求ヘッダーで明示したときだけ、保持設定の変更や削除ができます。コンプライアンスモードでは、を含めて誰も保持期間中のバージョンを削除・上書きできず、モードの変更や期間の短縮もできません (延長はできます)。保持期間とは別に、期限を持たないリーガルホールドを個々のバージョンに付けられます。リーガルホールドは s3:PutObjectLegalHold 権限を持つ利用者が外すまで有効で、訴訟や監査のように終わりが決まっていない保全に向きます。ライフサイクルの有効期限は、保持期間中のバージョンを削除できません。「7 年間は削除させず、その後は自動で消す」なら、Object Lock の既定の保持期間とライフサイクルの有効期限を組み合わせます。

⚠️ 頻出: 「誤削除から復旧」はバージョニング、「古いログを自動で安価な階層へ移す」はライフサイクル、「削除や上書きを一定期間禁止」は Object Lock です。

④アクセス制御と公開設定

とオブジェクトはデフォルトでプライベートです。アクセス制御はポリシー、バケットポリシー、アクセスポイント、必要に応じてで行います。現在の設計では ACL よりも IAM ポリシーやバケットポリシーを優先し、Object Ownership で ACL を無効化してバケット所有者が一元管理する構成が基本です。

制御方法	使う場面	試験での見方
IAM ポリシー	ユーザー、ロール、アプリケーションの権限管理	誰が S3 を実行できるかを制御します。
バケットポリシー	バケット単位のリソースベース制御	、、強制などで使います。
Block Public Access	意図しない公開の防止	原則有効です。公開要件がある場合だけ例外を考えます。
Object Ownership	ACL の無効化、所有権の単純化	ACL よりポリシーベース管理を優先する流れを押さえます。
ACL	古い互換性や限定的な制御	新規設計では優先度が低いです。
Access Point	大規模共有データのアクセス経路分離	チームや用途ごとにポリシーを分けたい場合に使います。

Point

IAM = Identity and Access Management の略です。
「誰が、どの AWS リソースに、何をしてよいか」を管理するサービスです。
ACL = Access Control List の略です。
- 直訳すると「アクセス制御リスト」です。
- S3 では古い権限制御の仕組みとして出てきます。
OAC = Origin Access Control の略です。
- CloudFront から S3 へだけアクセスさせたいときに使います。
VPC = Virtual Private Cloud の略です。
- AWS 上に作る、自分専用のネットワーク空間です。
和訳
- Identity: 身元、ID
- Access: アクセス、利用
- Management: 管理
- Weblio英和辞書「management」

Block Public Access は、意図しない公開を防ぐための重要な防御線です。静的 Web サイトホスティングなどで公開が必要な場合を除き、パブリックアクセスは閉じます。 CloudFront 経由で公開する場合は、S3 を直接公開せず、Origin Access Control を使って CloudFront からのアクセスだけを許可する構成がよく使われます。

クロスアカウントアクセスでは、IAM ロール、バケットポリシー、オブジェクト所有権を合わせて考えます。内から S3 へプライベートに到達したい場合は、経由ではなく Gateway VPC Endpoint を使います。

⚠️ 頻出: 「S3 を公開せず CloudFront だけから読ませる」は Origin Access Control、「VPC からインターネットを通らず S3 へアクセス」は Gateway VPC Endpoint、「意図しない公開防止」は Block Public Access です。

⑤暗号化と監査

は保存時暗号化に対応しています。代表的な選択肢は、S3 管理キーを使う、キーを使う、顧客が管理するキーを使うです。試験では、多くの場合、監査性や鍵管理の要件があるなら SSE-KMS、シンプルなサーバー側暗号化でよいなら SSE-S3 と判断します。

暗号化方式	鍵の管理主体	向いている要件	試験での注意点
SSE-S3	S3	シンプルなサーバー側暗号化	鍵管理を細かく問われない場合の基本候補です。
SSE-KMS	AWS KMS	監査、鍵ポリシー、キー管理が必要な場合	S3 権限に加えて KMS 権限も必要です。
DSSE-KMS	AWS KMS	二層のサーバー側暗号化が必要な場合	高い保護要件が明示された場合に検討します。
SSE-C	顧客	顧客側で鍵を完全管理したい場合	AWS は鍵を保存しないため、運用責任が重くなります。
クライアント側暗号化	顧客またはアプリケーション	AWS に平文を渡したくない場合	アプリ側の実装・鍵管理が必要です。

Point

SSE = Server-Side Encryption（サーバー側暗号化） の略です。
S3 に保存するとき、AWS 側でデータを暗号化する方式です。
KMS = Key Management Service の略です。
- 暗号化に使う鍵を管理する AWS サービスです。
DSSE = Dual-layer Server-Side Encryption の略です。
- 「二層のサーバー側暗号化」という意味です。
名前の読み方
- SSE-S3 = S3 管理の鍵で暗号化します。
- SSE-KMS = KMS の鍵で暗号化します。
- SSE-C = Customer、つまり顧客管理の鍵で暗号化します。
和訳
- Encryption: 暗号化
- Key: 鍵
- Management: 管理
- Weblio英和辞書「encryption」

にはを使います。ポリシーで aws:SecureTransport を条件にして、アクセスを拒否する設計もあります。 KMS キーを使う場合は、S3 への権限だけでなく KMS キーの使用権限も必要です。

2023 年 1 月以降、S3 はすべての新しいオブジェクトを既定で SSE-S3 により暗号化します。バケットの既定の暗号化を SSE-KMS と特定の KMS キーに変えると、暗号化ヘッダーを付けずにアップロードされたオブジェクトもそのキーで暗号化されます。アップロード時に暗号化ヘッダーを指定した要求は、既定の設定より要求の指定が優先されます。 SSE-KMS ではオブジェクトごとに KMS を呼ぶため、大量のオブジェクトを読み書きすると KMS の要求料金が増え、要求のにも近づきます。S3 バケットキーを有効にすると、S3 が短期間使うバケット単位の鍵から各オブジェクトのを作るため、KMS への要求を最大 99% 減らせます。アプリケーションの変更は不要ですが、有効化前からあるオブジェクトには効かず、KMS のイベントにはオブジェクトではなくバケットの ARN が記録されます。

監査では、CloudTrail で S3 操作を記録し、必要に応じてデータイベントも有効化します。サーバーアクセスログ、S3 Storage Lens、S3 Inventory、などを組み合わせると、アクセス状況、保管状況、機密データ検出の観点を補えます。

監査・可視化機能	何を見るか	向いている用途
CloudTrail	API 操作履歴	誰がいつ S3 操作を行ったかを追跡します。
S3 サーバーアクセスログ	バケットへのリクエスト	アクセス分析やセキュリティ監査に使います。
S3 Storage Lens	ストレージ利用状況	組織・アカウント・バケット単位で利用傾向を見ます。
S3 Inventory	オブジェクト一覧と属性	暗号化状態、状態、棚卸しに使います。
Amazon Macie	機密データ検出	などの検出・保護に使います。

⚠️ 頻出: 「KMS で暗号化した S3 オブジェクトにアクセスできない」問題では、S3 の権限だけでなく KMS キーポリシーや kms:Decrypt 権限を確認します。

⑥レプリケーションとデータ保護

Replication は、同一または別リージョンのへオブジェクトを複製する機能です。同一リージョンはログ集約や、クロスリージョンレプリケーションは、低配信、データ主権要件で使います。

レプリケーション種別	複製先	主な用途	試験での判断ポイント
Same-Region Replication	同一リージョン	ログ集約、コンプライアンス、同一リージョン内の分離	DR よりも運用・統制目的で考えます。
Cross-Region Replication	別リージョン	災害対策、データ所在地、低レイテンシ配信	リージョン障害や地理的要件がある場合に選びます。
Replication Time Control	別バケット	複製時間の予測可能性向上	新しいオブジェクトの 99.99% を 15 分以内に複製する設計で、複製の遅れをと通知で把握できます。目標が明示される場合に検討します。
Batch Replication	既存オブジェクトの複製	既存データの後追い複製	新規オブジェクトだけでなく既存分も対象にしたい場合に使います。

Point

DR = Disaster Recovery（災害復旧） の略です。
障害や災害が起きたときに、別の場所で復旧できるようにする考え方です。
RTO = Recovery Time Objective の略です。
- 「どれくらいの時間で復旧したいか」を表します。
RPO = Recovery Point Objective の略です。
- 「どの時点までのデータを復旧したいか」を表します。
CRR = Cross-Region Replication と SRR = Same-Region Replication もよく出ます。
- CRR は別リージョンへの複製です。
- SRR は同一リージョン内の複製です。
和訳
- Disaster: 災害
- Recovery: 復旧
- Objective: 目標
- Weblio英和辞書「recovery」

レプリケーションにはが必要です。既存オブジェクトの扱い、削除マーカーの扱い、暗号化オブジェクトの複製権限も確認します。で暗号化したオブジェクトは、既定では複製されません。レプリケーションルールで KMS 暗号化オブジェクトの複製を明示的に有効にし、複製先と同じリージョンの KMS キーを指定したうえで、レプリケーション用のロールに、元のキーの kms:Decrypt と複製先のキーの kms:Encrypt を許可します。レプリケーションはバックアップの代替として使える場面もありますが、誤削除や誤上書きをそのまま複製してしまう可能性があります。そのため、バージョニング、Object Lock、バックアップ戦略と組み合わせて考えます。

S3 は高耐久ですが、リージョン障害やデータ所在地要件への対策としては、クロスリージョンレプリケーションやとの組み合わせを検討します。 /RPO が厳しい場合は、レプリケーションの遅延や復旧手順まで含めて設計します。

⚠️ 頻出: 「別リージョンに自動複製して DR」はクロスリージョンレプリケーション、「誤削除から戻す」はまずバージョニングです。目的が違います。

⑦イベント連携、静的サイト、データ分析

イベント通知は、オブジェクト作成や削除を契機に、、、などへ連携できます。画像アップロード後のサムネイル生成、ログ到着後の処理、非同期ワークフローの起点として使います。高信頼な非同期処理では、Lambda を直接呼ぶだけでなく SQS を挟んでリトライやバッファリングを設計する選択肢もあります。

連携先	向いている用途	試験での判断ポイント
AWS Lambda	画像加工、メタデータ生成、小規模な即時処理	アップロード後に処理を開始する代表的な選択肢です。
Amazon SQS	非同期処理、バッファリング、リトライ	処理の信頼性や平準化が必要な場合に挟みます。
Amazon SNS	複数購読者への通知	通知や用途で使います。
Amazon EventBridge	イベントルーティング、複数サービス連携	より柔軟なイベント処理が必要な場合に使います。

S3 イベント通知の絞り込みはオブジェクトキーのプレフィックスとサフィックスだけで、同じイベントタイプにプレフィックスとサフィックスが重なる設定を複数作ることもできません。で EventBridge への送信を有効にすると、イベントはすべて既定のイベントバスへ届き、ルールのイベントパターンでオブジェクトのサイズやキーの値などを条件にして、Lambda、SQS、タスクなど複数のターゲットへ振り分けられます。宛先が 1 つで、キーの前方・後方一致だけで足りるなら S3 イベント通知、内容による振り分けや宛先の追加が要るなら EventBridge を選びます。

Point

SQS = Simple Queue Service の略です。
Queue は「待ち行列」という意味です。
- 処理待ちのメッセージを順番にためるイメージです。
SNS = Simple Notification Service の略です。
Notification は「通知」という意味です。
- 複数の相手に知らせる用途で使います。
EventBridge は、イベントを受け取り、条件に応じて別サービスへ渡すサービスです。
和訳
- Queue: 行列、待ち行列
- Notification: 通知
- Event: 出来事、イベント
- Weblio英和辞書「queue」

静的 Web サイトホスティングでは、S3 バケットを Web サイトとして使えます。ただし、独自ドメイン、、、グローバル配信が必要ならと組み合わせます。 S3 単体の静的 Web サイトエンドポイントは、CloudFront の設定や公開方式の制約に注意します。

分析用途では、S3 をの保存先として使い、 Data Catalog、、、、などと連携します。大量データの移行では、オンライン転送なら、物理デバイスを使う大容量移行なら、から継続的に保存するならと比較します。

用途	組み合わせるサービス	判断ポイント
S3 上のデータを分析	Athena + Glue Data Catalog	にログや CSV/ を分析します。
データレイク権限管理	Lake Formation	データアクセス制御を一元化します。
から S3 を参照	Redshift Spectrum	DWH と S3 データを組み合わせます。
大規模分散処理	EMR /	大量データを分散処理します。
オンライン移行	DataSync	ネットワーク経由で継続的に転送します。
物理デバイス移行	Snow Family	回線で送れない大容量データに使います。
オンプレミス連携	Storage Gateway	オンプレ環境から AWS ストレージを利用します。

Point

SQL = Structured Query Language の略です。
データを検索・集計するための言語です。
CSV = Comma-Separated Values の略です。
- カンマで区切られた表形式のデータです。
Parquet は、分析に向いた列指向のデータ形式です。
- Athena や分析基盤では、CSV より効率よく処理できることがあります。
和訳
- Query: 問い合わせ
- Structured: 構造化された
- Comma: カンマ
- Weblio英和辞書「query」

⚠️ 頻出: 「S3 に置いたログを SQL で直接分析」は Athena、「大量オンプレデータを物理的に移行」は Snowball 系、「アップロードをトリガーに処理」は S3 イベント通知と Lambda/SQS です。

試験対策

SAA では、を中心にしたアーキテクチャ選択が頻出です。まず、データがオブジェクトなのか、ブロックデバイスなのか、共有ファイルシステムなのかを切り分けます。オブジェクト保存なら S3、の低遅延ディスクなら、複数 EC2 から共有する Linux ファイルシステムなら、Windows ファイル共有ならが候補になります。

次に、アクセス頻度と復旧要件でを選びます。頻繁に読むなら Standard、低頻度だが即時アクセスなら Standard-、再作成可能で単一でもよいなら One Zone-IA、アクセス頻度が不明なら Intelligent-Tiering、なら Glacier 系を選びます。取り出し時間を許容できるかどうかが Glacier 系の重要な判断軸です。

セキュリティ問題では、デフォルトプライベート、Block Public Access、ポリシー、、、 Origin Access Control、 Endpoint を組み合わせて考えます。公開 Web 配信では、「S3 を直接公開する」よりも「CloudFront 経由で配信し、S3 は非公開にする」設計が望ましい場面が多いです。

問題文のキーワード	優先して考える機能	理由
アクセス頻度が不明	Intelligent-Tiering	自動階層化でコストを最適化できます。
誤削除から戻したい		過去バージョンを保持できます。
一定期間削除・上書きを禁止	Object Lock	要件に対応します。
古いログを安く保管	ライフサイクル + Glacier 系	時間経過に応じて安価な階層へ移せます。
S3 を直接公開したくない	CloudFront +	CloudFront からのアクセスだけ許可できます。
VPC から private に S3 へ到達	Gateway VPC Endpoint	インターネットを経由せずにアクセスできます。
KMS 暗号化オブジェクトにアクセス不可	KMS 権限とキーポリシー	S3 権限だけでは不足する場合があります。
別へ	Cross-Region Replication	地理的に分離した複製を作れます。

データ保護では、バージョニング、ライフサイクル、、Object Lock の目的を混同しないことが重要です。バージョニングは誤操作からの復旧、ライフサイクルは、レプリケーションは別バケットや別リージョンへの複製、Object Lock は改ざん防止です。

大容量の公開データセットを共有する場合は、リクエスタ支払い (Requester Pays) を検討します。有効にしたバケットでは、リクエストとダウンロードのデータ転送の料金を要求した側の AWS アカウントが支払い、所有者は保存料金だけを負担します。すべてのリクエストに認証が必要で匿名アクセスはできず、要求側は x-amz-request-payer ヘッダーなどで料金の負担を承諾します。

最後にコストを確認します。 S3 のコストは保存容量だけでなく、リクエスト数、データ転送、取り出し料金、ライフサイクル移行、レプリケーション、KMS リクエストなどにも影響されます。「最も安い」だけでなく、可用性、取り出し時間、再作成可否、運用負荷を含めて選ぶことが、SAA の正答に近づきます。

Amazon S3 (Simple Storage Service)

概要

主要技術

①バケット、オブジェクト、キー

②ストレージクラス

③バージョニング、ライフサイクル、削除保護

④アクセス制御と公開設定

⑤暗号化と監査

⑥レプリケーションとデータ保護

⑦イベント連携、静的サイト、データ分析

試験対策

参考文献