AWS のデータ分析とデータレイク - Athena・Glue・Lake Formation・Redshift の統合エコシステム
AWS の Athena、Glue、Lake Formation、Redshift、Amazon Quick (旧 Amazon QuickSight) による統合データ分析スタックの構成を、Azure Synapse Analytics / Microsoft Fabric や GCP BigQuery との具体的な違いとあわせて整理し、選定の軸を解説します。
データ分析基盤に求められる「統合」の意味
現代のデータ分析基盤は、単一のクエリエンジンだけでは完結しません。データの収集、カタログ化、変換、蓄積、クエリ、可視化、アクセス制御という一連のパイプラインを、一貫した体験で構築・運用できることが求められます。AWS はこの一連のパイプラインを構成する専門サービスを個別に提供しつつ、それらが密に連携する統合エコシステムを構築しています。Athena でアドホッククエリを実行し、Glue でデータの ETL を行い、Lake Formation でアクセス制御を一元管理し、Redshift で大規模な分析を実行し、Amazon Quick の BI 機能 (Quick Sight・旧 Amazon QuickSight) で可視化する。各サービスが独立して進化しながらも、S3 をデータレイクの中心として統合されている点が AWS のデータ分析戦略の核心です。
S3 を中心としたデータレイクアーキテクチャ
AWS のデータ分析エコシステムの中心には S3 があります。S3 はデータレイクのストレージ層として、構造化データ、半構造化データ、非構造化データを区別なく格納できます。Parquet、ORC、Avro、JSON、CSV など多様なフォーマットに対応します。コスト最適化には S3 Intelligent-Tiering が使えますが、これは「Intelligent-Tiering ストレージクラスを指定して格納する」か「ライフサイクル設定で既存オブジェクトを移行する」ことが前提で、S3 に置くだけで自動的に適用されるわけではありません。またオブジェクト単位で監視・自動化の料金がかかり、128 KB 未満のオブジェクトはライフサイクルによる移行の対象にならず、手動で移した場合も常に高頻度アクセス階層の料金で課金されます (2026 年 8 月時点・公式ドキュメント記載の条件)。Glue Data Catalog は S3 上のデータのメタデータを管理するカタログサービスで、Athena、Redshift Spectrum、EMR から共通のカタログとして参照されます。Lake Formation は Glue Data Catalog の上に構築されたアクセス制御レイヤーで、テーブル単位、カラム単位、行単位のきめ細かいアクセス権限を一元管理します。この「S3 + Glue Data Catalog + Lake Formation」の 3 層構造が、AWS データレイクの基盤です。データを S3 に集約し、メタデータをカタログで管理し、アクセス制御を Lake Formation で統制するという明確な責務分離が、大規模環境でのガバナンスを実現します。この 3 層構造は現在も基盤として有効ですが、その上に「レイクハウス」の層が加わっているのが現行世代の姿です (2026 年 8 月時点)。Amazon SageMaker のレイクハウスアーキテクチャは、S3 のデータレイクと Redshift のデータウェアハウスを 1 つのカタログから扱えるようにし、Apache Iceberg のオープン標準に準拠することで Athena や Redshift Spectrum をはじめとする Iceberg 互換のエンジンから同じデータを参照できるようにします。クエリ実行時の権限チェックは Lake Formation が担い、Iceberg REST API のインターフェースは Glue Data Catalog の一部として提供されるため、既存の「S3 + カタログ + Lake Formation」の資産をそのまま活かせます。テーブル形式を前提にしたストレージとしては Amazon S3 Tables があり、テーブルバケットの中にテーブルを S3 の第一級リソースとして作成でき、S3 側が Iceberg のメタデータ維持と圧縮 (コンパクション)、古いスナップショットの失効を自動で処理します。加えて運用データベースや業務アプリケーションからのデータ取り込みは zero-ETL 統合で近リアルタイムに行えるため、ETL パイプラインを自前で組む前提も崩れつつあります。新規に設計する場合は、素の S3 にファイルを置いて Athena で読む形から始めるのか、最初からテーブル形式を前提にするのかを先に決めておくと後戻りが少なくなります。
Athena と Redshift - 2 つのクエリエンジンの使い分け
AWS はデータ分析のクエリエンジンとして、Athena と Redshift という 2 つの選択肢を提供しています。Athena は S3 上のデータに対して直接 SQL クエリを実行するサーバーレスサービスです。インフラのプロビジョニングが不要で、スキャンしたデータ量に応じた従量課金のため、アドホッククエリやデータ探索に最適です。Redshift はペタバイト規模のデータウェアハウスで、大量のデータに対する複雑な分析クエリを高速に実行します。Redshift Serverless によりプロビジョニング不要の利用も可能になりましたが、本質的には大規模な定常的分析ワークロード向けです。Redshift Spectrum を使えば、Redshift クラスターから S3 上のデータに直接クエリを実行でき、ホットデータは Redshift に、コールドデータは S3 に配置するハイブリッド構成が可能です。この 2 つのエンジンの使い分けにより、ワークロードの特性に応じた最適なコストパフォーマンスを実現できます。
GCP BigQuery との比較
GCP の BigQuery は、サーバーレスデータウェアハウスとして広く使われているサービスです。ストレージとコンピュートの分離、スロットベースの自動スケーリング、ML モデルの SQL 内での学習 (BigQuery ML) など、単体のサービスとしての完成度は極めて高いです。BigQuery の強みは「1 つのサービスで多くのことができる」点にあります。AWS のアプローチは、Athena、Redshift、Glue、Lake Formation を独立したサービスとして提供し、組織のニーズに応じて組み合わせる設計です。両者の差は優劣ではなく、課金モデルと構成の粒度に現れます。BigQuery のコンピュート料金は、クエリが処理したバイト数に対して課金される「オンデマンド」と、スロット (仮想 CPU) 単位で処理能力を確保する「容量ベース」の 2 モデルから選ぶ形です (2026 年 8 月時点・公式料金ページ記載)。AWS 側は同じ役割が複数のサービスに分かれているため、S3 上のデータをその場でスキャンする Athena はスキャンしたデータ量に応じた課金、Redshift Serverless は処理量に応じた RPU 課金、プロビジョンド型の Redshift はノードの稼働時間課金と、ワークロードごとに課金モデルの異なるエンジンを選び分けることになります。選定の軸は、1 つのサービスに寄せて運用と課金をまとめたいのか、ワークロード別にエンジンと課金モデルを分けて最適化したいのか、という運用方針の違いです。
Azure の分析サービス (Synapse Analytics と Microsoft Fabric) との比較
Azure Synapse Analytics は、データウェアハウス、データレイク、データ統合、BI を 1 つのワークスペースに統合したサービスです。Synapse Studio という統合開発環境から、SQL プール (データウェアハウス)、Spark プール (ビッグデータ処理)、Data Explorer (ログ分析)、パイプライン (ETL) を一元的に操作できます。公式ドキュメントで確認できる具体的な違いを押さえておくと比較しやすくなります (2026 年 8 月時点)。Synapse SQL には、あらかじめリソースを確保する専用 (dedicated) SQL プールと、確保なしでストレージ上のファイルに問い合わせるサーバーレス SQL プールという 2 つのリソースモデルがあり、パイプラインは Azure Data Factory と同じデータ統合エンジンで 90 を超えるデータソースに接続できます。Data Explorer はドキュメント上プレビューの位置づけです。また Microsoft は Synapse とは別に Microsoft Fabric を提供しており、こちらは SaaS として提供される分析プラットフォームで、OneLake という 1 つの論理データレイク (Azure Data Lake Storage Gen2 上に構築) をテナント全体の共通ストレージとし、データウェアハウスはコンピュートとストレージを分離したうえでデータをオープンな Delta Lake 形式でネイティブに保持します。OneLake のショートカットを使うと、Amazon S3 や Google Cloud Storage 上のデータをコピーせずに参照でき、ガバナンスは Microsoft Purview が担います。AWS と比べたときの構造的な違いは、AWS が S3 という汎用オブジェクトストレージを共通の置き場にして専門サービスを組み合わせる形をとる一方、Fabric はプラットフォーム側が用意した OneLake を各ワークロードが共有する形をとる点です。どちらが優れているかではなく、共通ストレージとカタログを自分で設計して統制したいのか、プラットフォームが前提として用意した論理データレイクに合わせたいのか、という設計の出発点の違いとして捉えるのが実務的です。
データ分析基盤の設計指針
AWS のデータ分析エコシステムを活用する際の基本方針は、S3 をデータレイクの中心に据え、ワークロードに応じてクエリエンジンを使い分けることです。探索的なアドホッククエリには Athena、定常的な大規模分析には Redshift、リアルタイムストリーミング分析には Amazon Managed Service for Apache Flink (旧 Kinesis Data Analytics)、機械学習パイプラインとの連携には SageMaker を組み合わせます。Glue でデータの ETL を自動化し、Lake Formation でカラムレベルのアクセス制御を実装し、Amazon Quick でビジネスユーザー向けのダッシュボードを構築します。
まとめ
AWS のデータ分析エコシステムは、Athena、Glue、Lake Formation、Redshift、Amazon Quick という専門サービスが S3 を中心に統合され、その上に Iceberg 互換のレイクハウス層が重なった構成です。GCP の BigQuery は 1 つのサービスに機能をまとめ、オンデマンドと容量ベースという 2 つの課金モデルを選ぶ形をとります。Azure は Synapse Analytics の統合ワークスペースと、OneLake を共通の論理データレイクに据える SaaS の Microsoft Fabric という 2 つの選択肢を提供しています。データ分析基盤の選定では、1 つのサービスに寄せて運用と課金をまとめたいのかワークロードごとにエンジンを分けたいのか、共通ストレージとカタログを自分で設計したいのかプラットフォームの前提に合わせたいのか、カラム単位・行単位のアクセス制御をどこで統制するのか、といった軸で自分たちの運用体制に照らして評価することが重要です。
参考資料 (AWS 公式)
本ページの一次情報は AWS 公式サイトおよび公式ドキュメントです。最新の仕様 / 料金は次の公式ページで確認できます。
本ページと公式ドキュメントの記述が食い違う場合は、公式ドキュメントを正としてください。