本文へスキップ
統計ロードマップ
Textbook

AWS Certified Data Engineer - Associate(DEA-C01)教科書

**AWS Certified Data Engineer - Associate(DEA-C01)** は **2024 年に GA された AWS の新 Associate 認定** で、**Glue ・ EMR ・ Athena ・ Redshift ・ Kinesis ・ MSK ・ Lambda ・ Step Functions ・ Lake Formation** など AWS のデータエンジニアリングサービスを **データパイプライン設計 ・ データレイク / DWH 構築 ・ ストリーム処理 ・ オペレーション** の 4 ドメインで体系的に問います。**SAA(設計)・ MLA-C01 / MLS-C01(ML)** と並ぶ AWS 認定の重要 Associate で、**データエンジニアの登竜門** です。本教科書は 10 章で出題範囲を体系的にカバーします。

目次

  1. 1 章 · DEA-C01 ─ 試験の全体像
    試験形式・出題ドメイン・他 AWS データ系認定との位置付けを整理します。
  2. 2 章 · S3 とデータレイク基礎
    S3 ストレージクラス ・ パーティション ・ ファイルフォーマットを整理します。
  3. 3 章 · AWS Glue ─ ETL の中核
    Glue Data Catalog ・ ETL Job ・ Crawler ・ DataBrew を整理します。
  4. 4 章 · Athena と Redshift
    サーバレス分析 Athena と DWH の Redshift を整理します。
  5. 5 章 · EMR と Spark / Hadoop エコシステム
    EMR の構成 ・ Hadoop / Spark / Hive / Presto を整理します。
  6. 6 章 · ストリーム処理 ─ Kinesis と MSK
    Kinesis Data Streams / Firehose / Managed Service for Apache Flink ・ MSK を整理します。
  7. 7 章 · オーケストレーション ─ Step Functions / MWAA / EventBridge
    ワークフローオーケストレーションの 3 大選択肢を整理します。
  8. 8 章 · Apache Iceberg / Hudi / Delta Lake と Lakehouse
    オープンテーブルフォーマットと Lakehouse 概念を整理します。
  9. 9 章 · オペレーション ・ 監視
    CloudWatch ・ CloudTrail ・ CloudFormation ・ コスト管理を整理します。
  10. 10 章 · セキュリティ ・ ガバナンス
    IAM ・ KMS ・ VPC Endpoint ・ PII マスキングを整理します。
Chapter 1

1 章 · DEA-C01 ─ 試験の全体像


§1.1

試験の位置付け

DEA-C012024 年 3 月に GA した AWS の新 Associate 認定。旧 AWS Data Analytics Specialty(DAS-C01)の後継 とも言える位置付けで、データレイクハウス時代 の AWS エンジニアに必要な 取込 ・ 変換 ・ 保管 ・ 分析 ・ ガバナンス を測ります。

  • 主催: Amazon Web Services(AWS)
  • 形式: CBT(Pearson VUE)or オンライン監督受験
  • 問題数 / 時間: 65 問 / 130 分
  • 回答方式: 単一選択 + 複数選択 + 順序問題
  • 合格スコア: 720 / 1000
  • 有効期限: 3 年
  • 受験料: 150 USD(参考)
  • 前提知識: SQL ・ Python ・ AWS 基本(CLF レベル以上)

AWS データ系認定の階層

  • Foundational: AI Practitioner(AIF-C01)
  • Associate: Data Engineer Associate(DEA-C01、本資格) / ML Engineer Associate(MLA-C01) / SAA
  • Specialty: ML Specialty(MLS-C01)
§1.2

出題ドメインと推奨学習プラン

公式試験ガイドのドメイン

  1. Domain 1: Data Ingestion and Transformation(34%): 取込 ・ 変換
  2. Domain 2: Data Store Management(26%): データレイク / DWH 設計
  3. Domain 3: Data Operations and Support(22%): オーケストレーション ・ 監視
  4. Domain 4: Data Security and Governance(18%): IAM ・ 暗号化 ・ Lake Formation

100 〜 200 時間プラン

  1. Week 1〜2: AWS 基本 + S3 + IAM の復習
  2. Week 3〜4: Glue + Athena + Redshift
  3. Week 5〜6: Kinesis + MSK + Lambda + Step Functions
  4. Week 7〜8: Lake Formation + Data Mesh + DataZone
  5. Week 9〜10: 模擬試験 + Skill Builder
DEA-C01 の本質は『S3 中心 + サービス選び分け』

AWS のデータエンジニアリングは S3 をデータレイクの中心に据え、目的別に Glue / EMR / Redshift / Athena / Kinesis を組み合わせる設計が王道。試験では 『この要件で最適なサービスは何か』 という選び分けが頻出。各サービスの 得意 ・ 不得意 ・ 価格モデル を頭に入れることが鍵。

Chapter 2

2 章 · S3 とデータレイク基礎


§2.1

S3 ストレージクラスとライフサイクル

ストレージクラス

  • S3 Standard: 高頻度アクセス、最高コスト
  • S3 Standard-IA / One Zone-IA: 低頻度アクセス、最低 30 日 ・ 128KB 制約
  • S3 Intelligent-Tiering: アクセスパターンを自動学習し最適階層へ移動、月額モニタリング料あり
  • S3 Glacier Instant Retrieval: ミリ秒取得 ・ 月数回
  • S3 Glacier Flexible / Deep Archive: 数分〜数時間 ・ 数時間〜半日 で取り出し、長期アーカイブ用

Lifecycle Rule

  • Transition: 一定日数経過後に低コスト階層へ移動
  • Expiration: 一定日数経過後にオブジェクト削除
  • バージョニング有効時: 過去バージョンも別ルールで管理
  • 実装は『prefix / tag 単位』 で柔軟に絞り込み可能
§2.2

ファイルフォーマットとパーティショニング

列指向 vs 行指向

  • Parquet: 列指向 ・ Snappy / GZIP 圧縮 ・ プレディケートプッシュダウン対応、分析最適
  • ORC: 列指向 ・ Hive 系で歴史的に優位 ・ ACID 対応
  • Avro: 行指向 ・ スキーマ進化に強い、ストリーム取込に最適
  • JSON / CSV: テキスト ・ パース重い ・ 圧縮非効率、変換中継のみ

Hive 形式パーティショニング

  • `s3://bucket/table/year=2026/month=05/day=09/` のキー設計
  • Athena / Glue / Spark で自動認識(AWS Glue の MSCK REPAIR / Partition Projection)
  • Partition Projection: パーティションメタデータをカタログに保持せず、テンプレートから動的解決(高速 ・ 低運用)
  • 過剰パーティション(秒単位など)は逆効果(small files 問題)
Small Files 問題と Compaction

Kinesis Firehose や Streaming Glue で大量の小ファイルが S3 に書かれる とクエリが激遅になる。Glue の compactionジョブ ・ Athena CTAS による Parquet 変換 ・ Apache Iceberg / Hudi の OPTIMIZE128MB 〜 1GB 単位に圧縮するのが定石

Chapter 3

3 章 · AWS Glue ─ ETL の中核


§3.1

Glue Data Catalog と Crawler

Glue Data Catalog は AWS のデータカタログ(Hive Metastore 互換)。Athena ・ Redshift Spectrum ・ EMR ・ Lake Formation すべてが共通のメタデータとして参照する。

  • Database / Table / Partition / Connection の 4 階層
  • Crawler: S3 / RDS をスキャンしてスキーマを自動推論
  • スキーマバージョニング: Crawler 実行のたびに新バージョン
  • 料金: 100 万オブジェクトまで無料、超過分は月額制
§3.2

Glue ETL Job と DataBrew

Glue ETL Job の種類

  • Spark Job: PySpark / Scala、最も一般的
  • Python Shell Job: 軽量 Python スクリプト、Spark なしで動作
  • Streaming Job: Kinesis / MSK からのストリーム ETL
  • Ray Job: 分散 Python 処理

Glue DPU と性能

  • DPU(Data Processing Unit): 4 vCPU + 16GB RAM = 1 DPU
  • Standard / G.1X / G.2X / G.4X / G.8X の Worker タイプ
  • Auto Scaling: 動的に DPU を増減
  • Job Bookmarks: 既処理データをスキップ、増分処理を可能に

Glue DataBrew

  • ノーコード ・ ビジュアル ETL: 250 種以上の組込変換
  • プロファイリング: データ品質メトリクスを自動算出
  • Recipe: 変換手順を再利用可能なレシピとして保存
  • Glue Studio との違い: Studio は Spark コード生成、DataBrew は GUI 完結
Chapter 4

4 章 · Athena と Redshift


§4.1

Athena

AthenaS3 上のデータに直接 SQL を投げるサーバレス分析サービス(Presto / Trino エンジン)。スキャン量 5 USD / TB という従量課金。

コスト最適化テクニック

  • 列指向(Parquet / ORC)で書く → 不要列をスキップ
  • パーティション + Predicate Pushdown → 必要パーティションのみスキャン
  • 圧縮(Snappy / GZIP / ZSTD) → スキャン量 30〜80% 削減
  • CTAS で集計表を Parquet 化 → 後続クエリ高速化
  • Workgroup でクエリ単位の上限 → 暴走クエリ防止

Athena Federated Query

  • RDBMS / DocumentDB / Redshift / DynamoDB / CloudWatch Logs などに対し SQL でクエリ
  • Lambda コネクタ経由で実装
  • S3 + 他データソースの JOIN が 1 クエリで可能
§4.2

Redshift

Redshift は AWS の 列指向 MPP 型 DWHProvisioned(クラスタ管理)Serverless(自動スケール) の 2 モード。

分散方式とソートキー

  • Distribution Style: KEY(指定列でハッシュ分散)/ ALL(全ノードに複製)/ EVEN(ラウンドロビン)/ AUTO
  • Sort Key: COMPOUND(複合)/ INTERLEAVED(複数列の優先度同等)
  • JOIN するテーブル間で同じ KEY 分散 → コロケート JOIN(高速)
  • マスター(小)+ ディメンション = ALLファクト(大)= KEY が定石

Redshift Spectrum と Federated Query

  • Spectrum: S3 を Redshift クラスタから外部テーブルとして読む(Athena と同等のエンジン)
  • Federated Query: RDS / Aurora を直接 SQL でクエリ
  • Data Sharing: クラスタ間でデータを共有(コピー不要)
  • Streaming Ingestion: Kinesis / MSK から直接マテビューに取込
Athena か Redshift か

アドホック ・ 探索的 ・ 月数 GB 〜 TB なら Athena。継続 BI ・ ダッシュボード ・ 同時実行多 ・ TB 〜 PB なら Redshift。両者の境界が曖昧 で、Spectrum 経由で両方併用するのが実務的。

Chapter 5

5 章 · EMR と Spark / Hadoop エコシステム


§5.1

EMR のクラスタ構成

  • Master Node: クラスタ管理 ・ NameNode / ResourceManager 兼務
  • Core Node: HDFS データ + 計算
  • Task Node: 計算のみ(HDFS なし)、Spot で安く拡張
  • EMR Serverless: クラスタレスで Spark / Hive を実行、運用ゼロ
  • EMR on EKS: Kubernetes 上で EMR を動かし、リソース共有
§5.2

S3 と HDFS の使い分け

EMR では HDFS よりも S3 を直接読み書きするのが標準(EMRFS)。HDFS は シャッフルや一時ファイル用 に短期で使う。

  • EMRFS Consistent View: S3 の結果整合性問題を吸収(現在は S3 自身が強整合のため不要)
  • EMRFS S3 Select: クエリ条件を S3 にプッシュダウン
  • Hive on Tez / Spark / Presto から S3 上のテーブルへ直接アクセス
Glue Spark Job vs EMR

サーバレス ・ 短時間 ・ 軽量 なら Glue。長時間 ・ 大規模 ・ 細かいチューニング なら EMR。EMR Serverless が両者の中間 を埋める存在。

Chapter 6

6 章 · ストリーム処理 ─ Kinesis と MSK


§6.1

Kinesis Family

Kinesis Data Streams

  • Provisioned mode: シャード単位課金、シャード = 1MB/s in / 2MB/s out
  • On-demand mode: 自動スケール、運用楽 ・ 高単価
  • 保持期間: 1 日〜365 日
  • Enhanced Fan-Out: コンシューマごとに 2MB/s 専有(複数 Lambda などで活用)

Kinesis Data Firehose

  • フルマネージド ・ サーバレス な配信サービス
  • 宛先: S3 / Redshift / OpenSearch / Splunk / カスタム HTTP
  • バッファリング: サイズ(MB)or 時間(秒)で出力
  • 変換: Lambda で行単位変換、Parquet / ORC への変換も組込対応
  • Apache Iceberg テーブルへの直接配信 にも対応(2024 GA)

Managed Service for Apache Flink

  • 旧 Kinesis Data Analytics、Apache Flink ベースのリアルタイム ETL / 集計 / 結合
  • SQL / Python / Java / Scala で実装
  • ステートフル処理 ・ ウィンドウ集計 ・ JOIN が得意
§6.2

MSK(Managed Streaming for Apache Kafka)

  • Provisioned: ブローカー数 ・ サイズを指定
  • MSK Serverless: 自動スケール、運用ゼロ
  • MSK Connect: Kafka Connect マネージド版、Debezium 等のコネクタ実行
  • 統合: Kinesis Data Firehose / Lambda / Glue Streaming
Kinesis vs MSK

AWS ネイティブ ・ サーバレス完結 なら Kinesis。Kafka エコシステム(Schema Registry / Connect / KSQL)を活かしたい ・ オンプレ Kafka からの移行 なら MSK。料金 ・ 運用負荷 ・ スキル相性 で判断。

Chapter 7

7 章 · オーケストレーション ─ Step Functions / MWAA / EventBridge


§7.1

Step Functions

  • ステートマシン定義(Amazon States Language / JSON) でワークフローを記述
  • Standard Workflow: 最大 1 年実行、ETL ・ バッチ向け
  • Express Workflow: 5 分以内 ・ 高頻度、リアルタイム ・ Lambda 連携向け
  • 直接統合: Glue / EMR / Athena / SageMaker / Lambda などをコードレスで呼び出し
  • 並列処理(Map state)・ エラーリトライ ・ Catch / Choice がネイティブ
§7.2

MWAA(Managed Workflows for Apache Airflow)と EventBridge

MWAA

  • Apache Airflow のフルマネージド版(Python の DAG)
  • 長年の Airflow 資産 ・ オープンソース連携 を活かしたい場合に最適
  • コスト: ワーカー ・ スケジューラ常時稼働で Step Functions より高め

EventBridge

  • Event Bus: AWS / SaaS / カスタムイベントを集約
  • Scheduler: cron / rate での定期実行(Cron 専用に EventBridge Scheduler が GA)
  • Pipes: ソース → 任意の変換 → ターゲット の no-code 連携
  • S3 イベント駆動 ETL の中核
Step Functions vs MWAA

AWS サービス連携 ・ サーバレス ・ コスト なら Step Functions。Python DAG ・ コミュニティオペレータ ・ ハイブリッドクラウド なら MWAA。両者を併用(MWAA から Step Functions を呼ぶ)も実務では一般的。

Chapter 8

8 章 · Apache Iceberg / Hudi / Delta Lake と Lakehouse


§8.1

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

Apache Iceberg / Hudi / Delta LakeS3 + Parquet を ACID トランザクション + スキーマ進化 + タイムトラベル + マージ に対応させるオープンテーブルフォーマット。AWS は Iceberg をファースト にサポート。

Iceberg の主要機能

  • ACID トランザクション: 同時書込での整合性保証
  • スキーマ進化: 列追加 ・ 名前変更 ・ 型変更が安全
  • Time Travel: 過去スナップショットへのクエリ
  • Hidden Partitioning: パーティション式を内部で管理(クエリ時の SQL で意識不要)
  • Row-Level Operations: UPDATE / DELETE / MERGE INTO サポート

AWS での Iceberg 統合

  • Glue Data Catalog: Iceberg テーブルをネイティブ管理
  • Athena Engine v3: Iceberg DDL / DML 対応
  • EMR Spark / Glue Spark: Iceberg ライブラリ込みで起動可能
  • Redshift: 外部 Iceberg テーブル読込対応
  • Firehose: Iceberg テーブルへ直接配信
§8.2

Lake Formation と Lakehouse

Lake Formation の役割

  • 列レベル / 行レベル / セル レベル のアクセス制御
  • LF-Tag によるタグベースポリシー: 部署 ・ センシティビティ単位の権限管理
  • クロスアカウントデータ共有: アカウント間での安全な共有
  • Glue Data Catalog 上に重ねて使う(IAM 単独より細かい制御)

DataZone(Data Mesh)

  • ドメイン単位のデータカタログ ・ ガバナンス
  • Data Producer ・ Consumer のセルフサービス
  • Data Mesh アーキテクチャ を AWS で実装する標準サービス
Lakehouse の本質

Data Lake(柔軟だが弱整合)+ DWH(整合だが固い)= Lakehouse(両方を兼ねる) という思想。AWS では『S3 + Iceberg + Glue Catalog + Athena / Redshift Spectrum』 が Lakehouse の標準スタック。

Chapter 9

9 章 · オペレーション ・ 監視


§9.1

CloudWatch と CloudTrail

  • CloudWatch Metrics: ジョブ実行数 ・ エラー率 ・ Glue DPU 使用率 ・ Redshift CPU など
  • CloudWatch Logs: Glue / Lambda / EMR のログ
  • CloudWatch Alarms: 閾値超過で SNS 通知 → Lambda / Slack
  • CloudWatch Logs Insights: ログを SQL ライクにクエリ
  • CloudTrail: API コール監査(誰がいつ何を実行したか)
§9.2

IaC とコスト管理

IaC の選択肢

  • CloudFormation: AWS ネイティブ、宣言的 YAML / JSON
  • AWS CDK: TypeScript / Python から CloudFormation 生成、抽象度高
  • Terraform: マルチクラウド標準
  • SAM: サーバレス特化(Lambda / API Gateway / Step Functions)

コスト最適化

  • S3 Storage Lens: 全アカウント横断のストレージ可視化
  • Cost Explorer / Budgets: 月次コストとアラート
  • Trusted Advisor: 未使用リソースの提案
  • Athena Workgroup の課金タグ: チーム単位コスト集計
  • Redshift RA3 + 自動 Pause: クラスタ非利用時にコンピュート停止
Chapter 10

10 章 · セキュリティ ・ ガバナンス


§10.1

IAM と暗号化

  • IAM Role + Bucket Policy の組み合わせで S3 アクセス制御
  • KMS(SSE-KMS): AWS マネージド or Customer-Managed キー
  • S3 Bucket Keys: KMS 呼び出し回数を削減しコスト最適化
  • Glue / Athena / Redshift すべて KMS 統合
  • Field-Level Encryption: アプリ層で機微列のみ暗号化(Lambda + KMS)
§10.2

ネットワーク隔離と PII マスキング

VPC Endpoint(PrivateLink)

  • Gateway Endpoint: S3 / DynamoDB(無料)
  • Interface Endpoint: その他 AWS サービス(時間課金 + データ転送)
  • インターネットを通さず VPC 内から AWS API を呼ぶ
  • Glue Connection で Redshift / RDS を VPC 内から接続

PII / 機微情報の取り扱い

  • Amazon Macie: S3 内の PII / 機微情報を ML ベースで自動検出
  • Glue DataBrew: マスキング ・ ハッシュ化の組込変換
  • Lake Formation 列レベル制御: PII 列を見える人だけに開示
  • Redshift Dynamic Data Masking: クエリ時にロールベースで列をマスク
DEA-C01 受験の最終チェック

直前 1 週間: Skill Builder の DEA-C01 公式問題集を 2 周。サービス選び分け表(Glue vs EMR、Athena vs Redshift、Kinesis vs MSK、Step Functions vs MWAA)を自分の言葉でまとめ直す。当日: 問題文の 『リアルタイム』『コスト最小』『運用ゼロ』『大規模』 といったキーワードに反応してサービスを瞬時に選別。