組織全体のデータ分析基盤を構築する上で中心となるのがデータレイクという考え方です。本記事では、S3を中心としたデータレイクと、それを支える分析サービスを整理します。

SAA レベル：基礎概念

データレイクとDWHの違い

項目	データレイク（S3）	データウェアハウス（Redshift）
データ形式	構造化・半構造化・非構造化を問わず生データのまま保存	スキーマが定義された構造化データ
コスト	保存コストが低い	演算リソースを含むためやや高コスト
主な用途	生データの一元保管、探索的分析	高速な集計・BIツール連携

SAA 試験のポイント

「まず全データをそのままの形でS3に貯めておき、必要に応じて加工・分析する」というのがデータレイクの考え方です。Redshiftのような構造化されたDWHとは異なり、**スキーマオンリード（読み取り時にスキーマを適用する）**という柔軟性が特徴です。

Amazon Athenaの基本

S3上のデータに対して、テーブルを作成せずに直接SQLクエリを実行できるサーバーレスクエリサービス
クエリでスキャンしたデータ量に応じた従量課金

SAP レベル：高度な設計シナリオ

Lake Formationによる列/行レベル権限管理

SAP 試験のポイント

複数の部門がデータレイクを共有する組織では、単純なS3バケットポリシーだけではきめ細かいアクセス制御が困難です。AWS Lake Formationを使うと、テーブルの**列単位・行単位（Row-level Security）**でのアクセス許可を一元的に定義でき、「営業部門は顧客テーブルの氏名・連絡先は見られるが、与信情報の列は見られない」といった詳細な統制が可能になります。

Redshift Spectrumとの連携

SAP 試験のポイント

Redshift Spectrumを使うと、Redshiftクラスター内に取り込んでいないS3上の生データに対しても、Redshiftから直接SQLクエリを実行できます。これにより、「頻繁に使う集計済みデータはRedshiftクラスター内に、大量の生ログデータはS3に置いたまま」というコストと性能を両立したハイブリッド構成が実現できます。

観点	Redshiftクラスター内データ	Redshift Spectrum（S3外部テーブル）
クエリ速度	高速（列指向ストレージに最適化）	やや低速（S3からのスキャンが発生）
ストレージコスト	クラスターのストレージコストがかかる	S3の低コストストレージのまま

設計上の落とし穴

「すべてのデータをRedshiftクラスターに取り込むべき」という判断は、大量の生ログデータなど、アクセス頻度が低いデータに対してはコスト効率が悪くなります。SAPレベルでは、アクセス頻度・クエリ性能要件に応じて、Redshiftクラスター内データとRedshift Spectrum経由のS3データを使い分ける階層設計が問われます。

データカタログの一元管理（AWS Glue Data Catalog）

Athena、Redshift Spectrum、EMR、Lake Formationはすべて共通のGlue Data Catalogを参照する
Glue Crawlerを使い、S3上のデータのスキーマを自動検出してカタログに登録することで、分析サービス間でのメタデータの一貫性を保てる

まとめ

SAA: データレイクとDWHの違い、Athenaのサーバーレスクエリの基本を理解する。
SAP: Lake Formationによる列/行レベルのきめ細かい権限管理、Redshift Spectrumによるコストと性能を両立したハイブリッド構成の設計ができる。

次は **EFS／FSx（用途別ファイルストレージ）**を見ていきましょう。