AWSデータ基盤選定マトリクス

周辺資料: 学習インデックス · AWSサービス一覧（2026） · Kinesisストリーム処理 · S3データレイク設計

データ基盤サービスを要件ベースで選定するための決定表。

1. データアーキテクチャの全体像

[データソース]
  業務DB / SaaS / IoT / ログ / API
       │
       ├─── リアルタイム ──────────────────────────────────┐
       │    Kinesis Data Streams / MSK (Kafka)            │
       │         │                                        │
       │    Flink (KDA) / Lambda                          │
       │         │                                        │
       │    OpenSearch / Timestream / DynamoDB ←──────────┘
       │    （リアルタイム可視化・アラート）
       │
       └─── バッチ ───────────────────────────────────────┐
            DMS / Snow Family / S3 Transfer               │
                 │                                        │
            S3 Raw Zone (Parquet/ORC/Iceberg)             │
                 │                                        │
            Glue ETL / EMR Spark                          │
                 │                                        │
            S3 Processed Zone ──────────────────────────  │
                 │                                        │
            ┌───┴────────────────────┐                   │
            Athena (アドホック)      Redshift (DWH)       │
            QuickSight (可視化)      SageMaker (ML)       │
            └───────────────────────────────────────────-─┘

[ガバナンス層]
  Lake Formation（アクセス制御・カタログ）
  Glue Data Catalog（メタデータ）
  DataZone（データメッシュ）
  Macie（PII検出）

2. 取り込み（Ingestion）選定

バッチ取り込み

リアルタイム取り込み

Kinesis vs MSK 詳細比較

3. 変換・処理（Transform）選定

バッチ ETL

ストリーム処理

Glue vs EMR の使い分け

Glue を選ぶ場合:
  - サーバーレスで運用したい（クラスター管理不要）
  - Glue Data Catalog との連携を重視する
  - ジョブ実行頻度が低い（コールドスタート許容）
  - Python / Scala でシンプルな ETL

EMR を選ぶ場合:
  - 大量データを継続処理（長時間クラスター）
  - Spark のカスタムライブラリが必要
  - Presto / Hive / HBase / Flink を使いたい
  - コスト最適化が最優先（Spot活用）

4. ストレージ選定

データレイク・DWH

オープンテーブルフォーマット

推奨: Iceberg（2024〜2025年時点でAWSネイティブサポートが最も充実）

S3 ストレージクラス最適化

5. 分析・クエリ選定

Athena vs Redshift の使い分け

Athena を選ぶ場合:
  - クエリ頻度が低い（アドホック分析）
  - サーバーレスで運用コストを最小化したい
  - スキャン量が少ないParquet/ORC形式で保管している
  - 既存の S3 Data Lake をすぐにクエリしたい

Redshift を選ぶ場合:
  - 定型レポートを毎日大量に実行する
  - BI ツールから高同時実行アクセスがある
  - 複雑な結合・集計を高速に実行したい
  - Redshift ML（SageMaker統合）を使いたい

Athena コスト最適化

パーティションプルーニング: WHERE year='2024' AND month='01'
  → スキャンデータ量を削減（コスト ∝ スキャン量）

Parquet/ORC 形式:
  → CSV比で5〜10倍のスキャン削減（列指向圧縮）

Athena Federated Query:
  → RDS/DynamoDB/Redshift をまたいだ統合クエリ
  → ETLなしでリアルタイム結合可能

Workgroup + 利用制限:
  → クエリあたりスキャン量上限を設定（コスト暴走防止）

6. ガバナンス・セキュリティ選定

Lake Formation vs 従来のS3 + IAM

DataZone（データメッシュ）

DataZone が有効な場合:
  - 複数チーム/ドメインが独立してデータを管理・公開したい
  - データプロデューサーとコンシューマーを分離したい
  - データポータル（検索・申請・承認）が必要
  - Redshift / Athena / SageMaker をまたいだデータアクセス統制

7. 可視化選定

8. アーキテクチャパターン早見表

パターン A: シンプル Data Lake（小〜中規模）

• データソース → S3 (Raw) → Glue ETL → S3 (Parquet) → Athena → QuickSight
• Glue Data Catalog（メタデータ）

向いている規模: TB〜数十TB / 分析クエリ中心 / チーム小規模

パターン B: DWH 中心（BI 高同時実行）

• データソース → S3 (Staging) → Glue/DMS → Redshift (DWH)
• → QuickSight / BI Tool
• → Redshift ML (SageMaker)

向いている規模: 数十TB〜PB / 定型レポート多数 / 高同時実行

パターン C: リアルタイム + バッチ (Lambda Architecture)

[リアルタイム層]
  IoT/App → Kinesis Streams → Flink → OpenSearch/DynamoDB

[バッチ層]
  S3 (Raw) → EMR Spark → S3 (Processed/Iceberg) → Athena/Redshift

[サービング層]
  Athena / Redshift → QuickSight
  OpenSearch → Dashboards

向いている規模: PB級 / リアルタイム + 深い分析の両立

パターン D: データメッシュ（大規模組織）

[ドメイン A]                [ドメイン B]
  S3 + Redshift               S3 + Athena
       │                           │
       └────── DataZone ───────────┘
                    （データカタログ・アクセス制御）
                    │
              分析チーム / ML チーム

9. コスト観点の比較

10. 選定チェックリスト

□ データ量と増加率を見積もった（TB/月）
□ アクセスパターン（読み取り頻度・クエリ複雑度）を定義した
□ リアルタイム性の要件を確認した（秒 / 分 / 時間 / 日次）
□ 複数チームのデータアクセス制御要件を確認した
□ コンプライアンス要件（PII / GDPR / 業界規制）を確認した
□ 既存技術スタック（Kafka / Spark / dbt等）の継続利用要否を確認した
□ 初年度コストとスケール後コストの両方を見積もった
□ データ品質チェックの実装方針を決めた（Glue DQ / カスタム検査）
□ スキーマ進化・後方互換性の方針を決めた
□ Lake Formation による列/行レベルアクセス制御が必要か判断した