Amazon S3 によるデータレイク

は、AWS のの中心になるです。形式を問わずデータを安く大量に置け、・・・などの分析サービスが同じデータを直接読めます。DEA-C01 では、分析しやすいプレフィックスとパーティションの設計、リクエストの性能、の選択、S3 イベント通知によるパイプラインの起動が問われます。

Point

プレフィックス (prefix): オブジェクトキーの先頭部分です。sales/year=2026/month=10/ のように、フォルダのように見える区切りを作ります。
パーティション: 列の値 (日付など) ごとにデータを分けて置くことです。S3 ではプレフィックスで表します。
和訳
- Prefix: 接頭辞
- Weblio英和辞書「prefix」

概要

は、のにデータを置き、 Data Catalog にテーブル定義 (スキーマ、場所、パーティション) を登録して、で読める状態にしたものです。

単位	意味
バケット	オブジェクトを入れる入れ物。名前は全世界で一意
オブジェクト	データ本体とメタデータ。1オブジェクト最大 5 TB
キー	バケット内のオブジェクトの名前。プレフィックスを含む

試験では、「どう置けば速く安く読めるか」「新しいファイルが届いたら何で処理を起動するか」「どのに置くか」を判断します。

主要技術

①ゾーンとバケットの分け方

は、加工の段階ごとにゾーンを分けます。

ゾーン	中身	形式の例	主な読み手
raw (landing)	取り込んだままのデータ	CSV、、ログ	変換ジョブだけ
cleansed (staging)	型をそろえ重複を除いたデータ		変換ジョブ、データエンジニア
curated (analytics)	結合・集計済みのデータ	Parquet、	アナリスト、、ML

ゾーンをまたはプレフィックスで分けると、ライフサイクルルール、暗号化、アクセス権限をゾーン単位で設定できます。raw は再処理の元になるため消さずに残し、古いものはライフサイクルルールで安いクラスへ移します。

②プレフィックスとパーティションの設計 ⚠️ 頻出

クエリが絞り込みに使う列でパーティションを切ると、やが読むファイルを減らせます (パーティション)。スキャン量が減るため、速くなり、スキャン量で課金される Athena では費用も下がります。

s3://lake/curated/sales/year=2026/month=10/day=17/part-0000.snappy.parquet

列名=値 の形 (Hive 形式) で置くと、や Athena の MSCK REPAIR TABLE が列名と値を自動で読み取れます。

設計の観点	よい例	悪い例
パーティション列	WHERE 句でよく使う日付・地域	ほぼ一意な ID (パーティションが膨大になる)
粒度	1パーティションに数百 MB 以上がたまる粒度	1パーティションに数 KB のファイルが1つ
ファイルサイズ	128 MB〜1 GB 程度の	数 KB のが数百万個 ()
形式	列指向 (Parquet、) + 圧縮	圧縮していない CSV

パーティションを細かく切りすぎると、パーティションの一覧取得に時間がかかり、かえって遅くなります。パーティションの同期と射影は「 Data Catalog とクローラー」の章、パーティション戦略の詳細は「パーティショニング・インデックス・圧縮の最適化」の章で扱います。

③リクエストの性能

は、パーティション分割されたプレフィックスごとに、毎秒少なくとも 3,500 件のと 5,500 件の GET/HEAD を処理できます。プレフィックスの数に上限はないため、プレフィックスを分けて並列に読み書きすれば全体の性能を伸ばせます。

症状	原因	対処
503 Slow Down が返る	1つのプレフィックスへ急にリクエストが集中した	で再試行し、プレフィックスを分散する。S3 側の拡張は徐々に進む
大きなファイルのアップロードが遅い・失敗する	1回の PUT で送っている	マルチパートアップロードで並列に送る
大きなファイルの一部だけ読みたい	全体を GET している	バイト範囲を指定した GET (Range) で並列に読む
遠隔地からのアップロードが遅い	長距離のネットワーク	S3 Transfer Acceleration
一桁ミリ秒の応答が必要な中間データ	汎用の遅延	S3 Express One Zone (ディレクトリバケット)

S3 Express One Zone は、単一のに置く高性能なです。ML のやの中間データのように、繰り返し速く読みたいデータに向きます。単一 AZ のため、唯一の保管先にはしません。

④ストレージクラスの選択 ⚠️ 頻出

	向くデータ	最小保存期間	取り出し
Standard	頻繁に読むデータ (curated、直近の raw)	なし	すぐ
S3 Intelligent-Tiering	読まれ方が読めない・変わるデータ	なし	頻度に応じて自動で階層を移す
S3 Standard-	月に1回程度しか読まないが、すぐ必要	30日	すぐ (取り出し料金あり)
S3 One Zone-IA	作り直せる二次データ	30日	すぐ (単一 )
Instant Retrieval	四半期に1回程度、読むときはすぐ	90日	ミリ秒
S3 Glacier Flexible Retrieval	年に数回、数分〜数時間待てる	90日	復元が必要
S3 Glacier Deep Archive	法令で長期保管、ほぼ読まない	180日	復元に最も時間がかかる

Glacier Deep Archive の標準の取り出しは12時間以内で、取り出しに半日待てるならで最も安いクラスです。S3 Intelligent-Tiering のアーカイブ層 (Archive Access・Deep Archive Access) は有効にしたときだけ使われ、その層へ移ったオブジェクトは Glacier と同じく復元してから読みます。

やは、Glacier Flexible Retrieval と Deep Archive のオブジェクトを復元せずには読めません。分析に使うデータを Glacier へ移すと、クエリが失敗するかそのデータが結果から抜けます。移行の自動化は「S3 のライフサイクル・・」の章で扱います。

⑤S3 イベント通知とパイプラインの起動 ⚠️ 頻出

新しいファイルが届いたら変換を始める、というのパイプラインはのイベントから組み立てます。

方式	送り先	向くケース
S3 イベント通知 (直接)	、、	1つの処理を素早く起動する。プレフィックスとサフィックスで絞り込む
経由	EventBridge のルールで多数のターゲット	内容による細かい絞り込み、複数の宛先、やワークフローの起動、と再実行

ファイルが大量に届く場合は、S3 → SQS → Lambda のように SQS を挟むと、処理側の数を超えた分をキューにためられます。も S3 イベント (SQS 経由) を使い、変更のあったフォルダだけを読み直せます。は S3 イベント統合による自動コピー () で、新しいファイルを自動でロードできます (「Redshift へのロードとアンロード」の章)。

⑥アクセス制御の入り口

のは、部門やアプリごとに読める範囲を分けます。

手段	使いどころ
バケットポリシー	バケット全体への許可・拒否、他アカウントへの許可
アクセスポイント	アプリや部門ごとに入口を分け、それぞれにポリシーを持たせる。共有バケットのポリシーが肥大化するのを防ぐ
S3 ブロックパブリックアクセス	データレイクを誤って公開しない
	Data Catalog のテーブルを通じて、表・列・行の単位で権限を管理する

アクセスポイントとの詳細は「データのネットワークセキュリティ」の章、表・列・行の権限は「AWS Lake Formation」の章、暗号化は「とデータの暗号化」の章で扱います。

試験対策

①判断マトリクス

問題文のキーワード	選ぶもの
のスキャン量と費用を減らしたい	日付などでパーティション分割 + + 圧縮
数 KB のファイルが大量でクエリが遅い	ファイルをまとめる ()、のバッファを大きくする
503 Slow Down が出る	プレフィックスの分散と
数 GB のファイルのアップロードを速く確実に	マルチパートアップロード
ファイルが届いたらすぐ変換を始める	イベント通知 → 、または → /
届くファイルが多く処理側があふれる	S3 → → Lambda
読まれ方が読めない	S3 Intelligent-Tiering
作り直せるデータを安く	S3 One Zone-
一桁ミリ秒で繰り返し読む中間データ	S3 Express One Zone
部門ごとに共有の入口を分けたい	S3 アクセスポイント

②よくある誤答

ユーザー ID のようなほぼ一意な値でパーティションを切ること。パーティションが膨大になり遅くなります。
分析対象のデータを Glacier Flexible Retrieval へ移すこと。から直接は読めません。
のイベント通知を使わずに、数分おきにを一覧して新しいファイルを探すこと。リクエストの費用と遅れが増えます。
raw ゾーンを変換後すぐに削除すること。変換ロジックの誤りを直して作り直せなくなります。