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 章 · DEA-C01 ─ 試験の全体像試験形式・出題ドメイン・他 AWS データ系認定との位置付けを整理します。
- 第 2 章 · S3 とデータレイク基礎S3 ストレージクラス ・ パーティション ・ ファイルフォーマットを整理します。
- 第 3 章 · AWS Glue ─ ETL の中核Glue Data Catalog ・ ETL Job ・ Crawler ・ DataBrew を整理します。
- 第 4 章 · Athena と Redshiftサーバレス分析 Athena と DWH の Redshift を整理します。
- 第 5 章 · EMR と Spark / Hadoop エコシステムEMR の構成 ・ Hadoop / Spark / Hive / Presto を整理します。
- 第 6 章 · ストリーム処理 ─ Kinesis と MSKKinesis Data Streams / Firehose / Managed Service for Apache Flink ・ MSK を整理します。
- 第 7 章 · オーケストレーション ─ Step Functions / MWAA / EventBridgeワークフローオーケストレーションの 3 大選択肢を整理します。
- 第 8 章 · Apache Iceberg / Hudi / Delta Lake と Lakehouseオープンテーブルフォーマットと Lakehouse 概念を整理します。
- 第 9 章 · オペレーション ・ 監視CloudWatch ・ CloudTrail ・ CloudFormation ・ コスト管理を整理します。
- 第 10 章 · セキュリティ ・ ガバナンスIAM ・ KMS ・ VPC Endpoint ・ PII マスキングを整理します。
第 1 章 · DEA-C01 ─ 試験の全体像
試験の位置付け
DEA-C01 は 2024 年 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)
出題ドメインと推奨学習プラン
公式試験ガイドのドメイン
- Domain 1: Data Ingestion and Transformation(34%): 取込 ・ 変換
- Domain 2: Data Store Management(26%): データレイク / DWH 設計
- Domain 3: Data Operations and Support(22%): オーケストレーション ・ 監視
- Domain 4: Data Security and Governance(18%): IAM ・ 暗号化 ・ Lake Formation
100 〜 200 時間プラン
- Week 1〜2: AWS 基本 + S3 + IAM の復習
- Week 3〜4: Glue + Athena + Redshift
- Week 5〜6: Kinesis + MSK + Lambda + Step Functions
- Week 7〜8: Lake Formation + Data Mesh + DataZone
- Week 9〜10: 模擬試験 + Skill Builder
AWS のデータエンジニアリングは S3 をデータレイクの中心に据え、目的別に Glue / EMR / Redshift / Athena / Kinesis を組み合わせる設計が王道。試験では 『この要件で最適なサービスは何か』 という選び分けが頻出。各サービスの 得意 ・ 不得意 ・ 価格モデル を頭に入れることが鍵。
第 2 章 · S3 とデータレイク基礎
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 単位』 で柔軟に絞り込み可能
ファイルフォーマットとパーティショニング
列指向 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 問題)
Kinesis Firehose や Streaming Glue で大量の小ファイルが S3 に書かれる とクエリが激遅になる。Glue の compactionジョブ ・ Athena CTAS による Parquet 変換 ・ Apache Iceberg / Hudi の OPTIMIZE で 128MB 〜 1GB 単位に圧縮するのが定石。
第 3 章 · AWS Glue ─ ETL の中核
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 万オブジェクトまで無料、超過分は月額制
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 完結
第 4 章 · Athena と Redshift
Athena
Athena は S3 上のデータに直接 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 クエリで可能
Redshift
Redshift は AWS の 列指向 MPP 型 DWH。Provisioned(クラスタ管理) と 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 から直接マテビューに取込
アドホック ・ 探索的 ・ 月数 GB 〜 TB なら Athena。継続 BI ・ ダッシュボード ・ 同時実行多 ・ TB 〜 PB なら Redshift。両者の境界が曖昧 で、Spectrum 経由で両方併用するのが実務的。
第 5 章 · EMR と Spark / Hadoop エコシステム
EMR のクラスタ構成
- Master Node: クラスタ管理 ・ NameNode / ResourceManager 兼務
- Core Node: HDFS データ + 計算
- Task Node: 計算のみ(HDFS なし)、Spot で安く拡張
- EMR Serverless: クラスタレスで Spark / Hive を実行、運用ゼロ
- EMR on EKS: Kubernetes 上で EMR を動かし、リソース共有
S3 と HDFS の使い分け
EMR では HDFS よりも S3 を直接読み書きするのが標準(EMRFS)。HDFS は シャッフルや一時ファイル用 に短期で使う。
- EMRFS Consistent View: S3 の結果整合性問題を吸収(現在は S3 自身が強整合のため不要)
- EMRFS S3 Select: クエリ条件を S3 にプッシュダウン
- Hive on Tez / Spark / Presto から S3 上のテーブルへ直接アクセス
サーバレス ・ 短時間 ・ 軽量 なら Glue。長時間 ・ 大規模 ・ 細かいチューニング なら EMR。EMR Serverless が両者の中間 を埋める存在。
第 6 章 · ストリーム処理 ─ Kinesis と MSK
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 が得意
MSK(Managed Streaming for Apache Kafka)
- Provisioned: ブローカー数 ・ サイズを指定
- MSK Serverless: 自動スケール、運用ゼロ
- MSK Connect: Kafka Connect マネージド版、Debezium 等のコネクタ実行
- 統合: Kinesis Data Firehose / Lambda / Glue Streaming
AWS ネイティブ ・ サーバレス完結 なら Kinesis。Kafka エコシステム(Schema Registry / Connect / KSQL)を活かしたい ・ オンプレ Kafka からの移行 なら MSK。料金 ・ 運用負荷 ・ スキル相性 で判断。
第 7 章 · オーケストレーション ─ Step Functions / MWAA / EventBridge
Step Functions
- ステートマシン定義(Amazon States Language / JSON) でワークフローを記述
- Standard Workflow: 最大 1 年実行、ETL ・ バッチ向け
- Express Workflow: 5 分以内 ・ 高頻度、リアルタイム ・ Lambda 連携向け
- 直接統合: Glue / EMR / Athena / SageMaker / Lambda などをコードレスで呼び出し
- 並列処理(Map state)・ エラーリトライ ・ Catch / Choice がネイティブ
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 の中核
AWS サービス連携 ・ サーバレス ・ コスト なら Step Functions。Python DAG ・ コミュニティオペレータ ・ ハイブリッドクラウド なら MWAA。両者を併用(MWAA から Step Functions を呼ぶ)も実務では一般的。
第 8 章 · Apache Iceberg / Hudi / Delta Lake と Lakehouse
オープンテーブルフォーマット
Apache Iceberg / Hudi / Delta Lake は S3 + 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 テーブルへ直接配信
Lake Formation と Lakehouse
Lake Formation の役割
- 列レベル / 行レベル / セル レベル のアクセス制御
- LF-Tag によるタグベースポリシー: 部署 ・ センシティビティ単位の権限管理
- クロスアカウントデータ共有: アカウント間での安全な共有
- Glue Data Catalog 上に重ねて使う(IAM 単独より細かい制御)
DataZone(Data Mesh)
- ドメイン単位のデータカタログ ・ ガバナンス
- Data Producer ・ Consumer のセルフサービス
- Data Mesh アーキテクチャ を AWS で実装する標準サービス
Data Lake(柔軟だが弱整合)+ DWH(整合だが固い)= Lakehouse(両方を兼ねる) という思想。AWS では『S3 + Iceberg + Glue Catalog + Athena / Redshift Spectrum』 が Lakehouse の標準スタック。
第 9 章 · オペレーション ・ 監視
CloudWatch と CloudTrail
- CloudWatch Metrics: ジョブ実行数 ・ エラー率 ・ Glue DPU 使用率 ・ Redshift CPU など
- CloudWatch Logs: Glue / Lambda / EMR のログ
- CloudWatch Alarms: 閾値超過で SNS 通知 → Lambda / Slack
- CloudWatch Logs Insights: ログを SQL ライクにクエリ
- CloudTrail: API コール監査(誰がいつ何を実行したか)
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: クラスタ非利用時にコンピュート停止
第 10 章 · セキュリティ ・ ガバナンス
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)
ネットワーク隔離と 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: クエリ時にロールベースで列をマスク
直前 1 週間: Skill Builder の DEA-C01 公式問題集を 2 周。サービス選び分け表(Glue vs EMR、Athena vs Redshift、Kinesis vs MSK、Step Functions vs MWAA)を自分の言葉でまとめ直す。当日: 問題文の 『リアルタイム』『コスト最小』『運用ゼロ』『大規模』 といったキーワードに反応してサービスを瞬時に選別。