「AWS Certified Data Engineer - Associate 認定」試験の対策記事

Last updated at 2025-03-16Posted at 2025-03-16

1. はじめに

この記事はAWS DEAの試験を受験しようと考えている（または悩んでいる）データアーキテクト、データエンジニア、データサイエンティストなどに向けたものです。
AWS Certified Cloud Practitioner(CLF)に関する知識がある前提で作成しています。

データサイエンティストにとってデータエンジニアリングが重要な理由
データアーキテクトやデータエンジニアだけでなく、データサイエンティストにもデータエンジニアリング能力が必要になる機会は多いはずです。データサイエンス業務では、データ利活用による意思決定や価値創出のフェーズが注目を集めやすいでしょう。一方で実際の業務では、機械学習モデルの開発や高度な分析に取り組む前段階の、データの収集・前処理・統合といったデータエンジニアリング業務に多くの時間を費やす ことが多いです。
データの品質が低いと、どれほど高度なアルゴリズムを用いても正確な分析はできません。
そのため、データサイエンティストが最もインパクトを出したいフェーズで適切にインパクトを残すためにはデータエンジニアリングのスキルが必要不可欠なことが多いです。

AWS DEAを取得するメリット

AWS Certified Data Engineer – Associate（AWS DEA）は、AWS環境におけるデータエンジニアリングのスキルを証明する資格です。この資格を取得することで、AWSのデータ関連サービス（S3、Glue、Redshift、Kinesis など）を活用し、データパイプラインの構築、ストリーミングデータ処理、データガバナンス管理といったスキルを体系的に習得できます。
つまりこの資格の取得は、アーキテクト的な目線では、AWSを活用したデータ基盤の設計・運用スキルを強化する手段となるし、データサイエンティスト的な目線では、データ処理の自動化やパフォーマンス最適化の知識を習得することで、よりスムーズに分析業務を進められるようになる手助けとなります。

この記事の新規性と有用性

AWS DEAは2024年3月に開始された新しい試験であるため、人気のある他の試験（CLFやSAAなど）と異なり、問題集や詳細な試験対策記事がまだ少ないというのが現状です（合格体験記はチラホラ見かける）。また、AWSのデータ関連サービスは種類が多く、すべてを学ぶのは非効率であるため、試験で特に重要なサービスや注意点を理解することが合格への近道となるでしょう。

本記事では、AWS DEA試験でよく出題されるサービスや、試験対策として押さえておくべきポイントを厳選し、効率的に学習できるよう整理しました（そのため、試験範囲のサービスを網羅しているわけではありません）。試験の合格を目指す方はもちろん、AWSを活用したデータエンジニアリングのスキルを磨きたい方にも役立つ内容となるよう構成しているため、ぜひ参考にしてください。（勉強方法についてはみちのくさんの合格体験記が非常に参考になります→こちら）

2. DEA試験で頻出のAWSサービスと要点

Redshift

Redshift DataAPI
- アプリケーション(StepFunctionsやLambda関数など…下画像を参照)からAmazon RedshiftへのアクセスをHTTPベースのAPI経由で提供する機能
- 呼び出しは非同期で行われ、AWS Secrets Managerに保存した認証情報を使って安全にクエリを実行できる
- 例：イベント駆動のLambda関数からDataAPIを利用することで、リアルタイムRedshiftにクエリを実行し分析結果を取得したい場合に、DataAPIを利用することで関数から直接HTTPS経由でクエリを送信できる。（イベント駆動のサーバーレスアプリケーションからRedshiftデータを活用したリアルタイム処理（例：イベント発生時に最新データを参照して判断を下す処理）が容易になる。)
- Redshift DataAPIが対応するサービス
- Get started with the Amazon Redshift Data API参照
Redshift Serverless
- クラスターの構築や管理を意識せずにRedshiftを利用できるサーバーレス形態のデータウェアハウス
- ワークロードに応じて必要なデータウェアハウス容量を自動でプロビジョニングし、数秒でスケーリングするため、負荷の変動が大きい場合でも安定した性能を発揮する
- 例: 新規プロジェクトでデータ量や利用パターンが未知の場合に、初期サイズの見積もりなしにデータウェアハウス利用を開始でき、必要なときだけスケールするため、効率的かつ安心してデータ分析基盤を立ち上げられる
システムテーブル（STL）
- 直近数日間（デフォルト7日）のRedshiftクラスターの動作状況を記録したログデータを問い合わせ可能な形式で提供するシステムテーブル群(クエリの実行履歴やエラー情報などシステムの過去の状態を確認することでモニタリングとトラブルシューティングに活用)
- 例: 特定のクエリが遅い場合にSTL_QUERYやSTL_EXPLAINを見ることでクエリの実行時間や実行計画を分析し、チューニングの手がかりを得ることができる。
負荷分散
- テーブルデータのクラスターノード間での配置方法を決定する設定で、クエリ時のデータ分散とネットワーク負荷に影響を与える（分散スタイルはCREATE TABLE時に指定）
  - EVEN（均等分散）
    - データをラウンドロビン方式で全ノードに均等に分散して格納するスタイル。キーに依存しないため、スキャン性能が安定する。大規模データ向き。
  - KEY（キー分散）
    - 指定した分散キーの値をもとに、同じキー値は同一ノードに格納するスタイル。結合やフィルタリングを頻繁に行う中規模データ向き。
  - ALL（全ノード複製）
    - 全ノードに全データを複製して格納するスタイル。小規模かつ更新頻度が低いデータ向き。
  - AUTO（自動分散）
    - 上記3スタイルをテーブル構造やクエリパターンに基づいて自動選択するスタイル。データ量やパフォーマンスに応じて再評価される場合がある。
- 例: 大規模な取引明細テーブルと顧客マスタテーブルを顧客IDで結合する場合、それぞれのテーブルを顧客IDをキーとするKEY分散に設定しておくと、同一の顧客IDを持つ行が同じノード上に配置されるため、結合処理を各ノード内で完結できる
- Amazon Redshift Best Practices for Performance参照
マテリアライズドビュー
- クエリの結果をあらかじめ計算してテーブルのように保存しておける機能。頻繁に繰り返し実行される予測可能なクエリ（例えばダッシュボード表示や定期レポート生成など）に対して大きな効果を発揮し、クエリ応答時間を短縮できる
- ビューの更新は基本的に手動更新REFRESH MATERIALIZED VIEWだが、増分更新可能な構造で作成されている場合には自動更新AUTO REFRESH YESが可能である。
  - 増分更新可能な条件
    - 元のテーブルの分散スタイルがDISTSTYLE ALLでないこと
    - 結合はOUTER JOINやCORSS JOIN、UNIONは不可（INNER JOINは場合による）
    - DISTINCTやHAVINGを使用しない
    - ORDER BYやLIMITを使用しない
- 例: 売上データを日次・月次で集計するダッシュボードにおいて、集計結果をマテリアライズドビューとして保持しておくことで高速な応答を実現できる。
手動更新
```
REFRESH MATERIALIZED VIEW mv_sales_summary
```
自動更新
```
CREATE MATERIALIZED VIEW mv_sales_summary
AUTO REFRESH YES
AS
SELECT 
    DATE_TRUNC('day', sale_date) AS sales_day,
    DATE_TRUNC('month', sale_date) AS sales_month,
    SUM(total_amount) AS total_sales,
    COUNT(sale_id) AS total_transactions
FROM sales
GROUP BY 1, 2;
```
データ共有
- Amazon Redshift間でデータをコピーせずに共有できる機能。プロデューサークラスター上のテーブルを他のコンシューマークラスターから参照可能にすることで、組織内の別部門や別環境から同一データセットをリアルタイムに利用できる
- データの所在は一元管理されるため、セキュリティやガバナンスを維持したまま複数の分析チームに読み取り専用アクセスを提供するといった活用が可能。（データメッシュ的活用）
- 例: ETL処理用の中央Redshiftクラスターで集約・整形したデータを各部門のRedshiftクラスターにデータ共有し、部門ごとに独立したリソースで分析できるようにする
Redshift Streaming Ingestion
- Amazon Kinesis Data StreamsやAmazon MSK（Kafka）からのデータを中間ストレージを経由せず直接Redshift（プロビジョンドまたはServerless）のデータベースに取り込める機能
- 取り込まれたデータは専用に設定したマテリアライズドビュー上に着地し、低レイテンシでクエリ可能となるため、外部データの到着から分析までの遅延を大幅に削減できる
- 例: IoTセンサーから継続的に発生するデータをMSKで受け取り、数秒～数分単位のニアリアルタイムでRedshiftに反映し、マテリアライズドビュー経由でダッシュボードを更新する。
- Best practices to implement near-real-time analytics using Amazon Redshift Streaming Ingestion with Amazon MSK参照
ソートキー再構築（VACUUM REINDEX）
- テーブルのソートキー順序を再構成し、性能を最適化する機能
- データ挿入や更新によってソート順序が崩れたテーブルに対してこの機能を実行することで、ソートキーによるデータスキップ効率を回復させ、テーブルスキャンやクエリの性能低下を改善できる
- 例: タイムスタンプをインターリーブドソートキーに設定した巨大なテーブル(時間範囲でフィルタするクエリ性能が悪い)にVACUUM REINDEXを実行することでソート順序を再整備し、本来の高速なクエリ性能を維持できる。
ワークロード管理（WLM）
- 複数ユーザーや多様なクエリが存在する環境下で、クエリ実行の優先度やリソース配分を調整する機能
- クエリ実行用のキューを複数設定でき、キューごとに同時実行数やメモリ割当てを制御することで、クエリそれぞれに適したリソースを割り当てられる
- Auto WLM（自動WLM）により、ワークロードに応じてメモリ配分や実行並列度を動的に調整し、クエリの優先度管理も自動化できる。
- 例: 日中はBIダッシュボード用の短いクエリが頻繁に実行され、夜間には大量データを集計するバッチクエリが走るようなケースにおいて、WLMで別々のキューを設定することで相互の干渉を防ぐ。

フェデレーテッドクエリ

Amazon Redshiftから外部のデータベースに対して直接クエリを実行し、その結果をRedshift内のクエリに統合できる機能
対応する外部DB
- RDS
  - MySQL
  - PostgreSQL
- Aurora
  - MySQL互換
  - PostgreSQL互換
例: 最新の売上トランザクションはAurora PostgreSQLに蓄積しつつ、過去数年間の履歴データはRedshiftに保存しているような場合に、フェデレーテッドクエリを使えば最新データと履歴データを一つのSQLで結合して分析できる。

フェデレーテッドクエリ例

-- 事前に外部スキーマを作成する必要あり（CREATE EXTERNAL SCHEMA）
SELECT 
    o.customer_id,
    SUM(o.amount) AS latest_sales,       -- Aurora（最新データ）
    SUM(h.amount) AS historical_sales    -- Redshift（過去データ）
FROM 
    aurora_db.public.orders o             -- Aurora の orders テーブル
LEFT JOIN 
    redshift_db.public.sales_history h    -- Redshift の過去売上テーブル
ON 
    o.customer_id = h.customer_id
GROUP BY 
    o.customer_id;

Redshift Spectrum

Amazon S3上のデータを直接クエリする機能（Spectrum専用の処理レイヤーがデータセットをスキャン・フィルタし、必要なデータのみをクラスタに取り込むため、高速にクエリ）
S3に保存されたパーティション化ファイル（CSV、Parquet、JSONなど）を外部テーブルとして定義し、Redshiftから通常のテーブルと同様にSQLで参照できる
例: 頻繁には参照しない過去数年分の巨大な事業データをRedshift本体ではなく安価なS3に保存し、必要なときだけSpectrum経由でクエリする（コスト削減とスケーラビリティを両立）。
Redshift SpectrumとAthenaの違い

項目	Redshift Spectrum	Athena
サーバレス	×（Redshiftクラスターが必要）	〇
料金体系	S3のスキャン量 + Redshiftクラスターのリソース使用料	S3のスキャン量
パフォーマンス	クラスターの性能に依存	スキャンデータ量が多いとクエリ時間が長くなる
ユースケース	RedshiftのデータとS3のデータの統合分析	S3のデータのアドホック的な分析

LakeFormation

データアクセス制御の一元管理
- 行・列レベル、さらにセルレベルでのアクセス制御が可能で、ユーザーごとに閲覧可能なデータ範囲を細かく設定できる。
- 例：営業部門のユーザーには「関東エリア」のデータのみを表示し、マーケティング部門のユーザーには「全国」のデータを閲覧可能にする。
2段階許可の設定
- データへのアクセスをメタデータ（GlueDataCatalog）へのアクセスと基盤（S3）へのアクセスを個別に制御できる。
- 例：Athena で S3 のデータにクエリを実行する際、Glue Data Catalog（スキーマ情報）へのアクセス許可と、S3（実データ）へのアクセス許可の両方が必要。例：あるユーザーが「売上データ」テーブルの構造は見えるが、データの中身は取得できないようにする場合、Glue Data Catalog のアクセスを許可し、S3 のアクセスをブロックすることで実現可能。
- AWS Lake Formation: How it works参照
クロスアカウントのデータ共有
- 異なる AWS アカウント間で S3 のデータを安全かつ効率的に共有できる。
- データメッシュアーキテクチャの実現に有用であり、各チームがデータを所有しつつ、必要なデータのみを共有することができる（参照Qiita記事→AWS Lake Formation と AWS Glue を使用して AWS でデータメッシュアーキテクチャをセットアップする）
- 例：親会社のデータレイクを子会社の AWS アカウントと共有し、必要なデータのみを閲覧可能にする。
FindMatches 変換
- 機械学習（ML）を活用した重複データマッチング機能であり、一意の識別子（ID）がないデータでも類似レコードを自動的に検出・統合できる。（→ルールベースのマッチングでは対応が難しいスペルミスや表記ゆれのあるデータの統合を容易にする）
- 例：顧客リストの統合時に、名前や住所が微妙に異なるレコードを自動で識別し、重複を排除する。

Lambda

プロビジョニング済み同時実行性
- 呼出頻度低めの場合にコールドスタートになることを避ける→リクエスト応答時間の改善
- レイテンシが重要なAPIのバックエンドに役立つ
予約済み同時実行性
- 使用できる同時実行リソースの上限を予約する→他の関数やシステムとのリソース競争を回避
- 特定の関数にリソースを確保できる
- 負荷の高いワークロードに対して大量のリソースを割かないように設定できる
LambdaLayers
- Layersに配置されたパッケージ（ライブラリやロジック）は複数のLambda関数で参照できる（同一リージョンかつ権限を有すること）

StepFunctions

アプリのワークフローを視覚的に構成。 AWS Step Functions をグラレコで解説参照
ワークフロー
- Standard ワークフロー
  - 長時間実行や高信頼性が求められるワークフロー向けのタイプ
  - 各ステップは重複なく一度だけ確実に実行される（Exactly-once実行）ことが保証されており、失敗時もワークフローが中断せずに継続できる耐久性を持つ（数時間〜数日（最大1年）のプロセスにも対応）
  - 例: 長時間かけて実行する一連のデータ処理ジョブを順序どおり確実に実行し、各段階の結果を記録・検証する
- Express ワークフロー
  - 短時間で終了し高頻度実行が求められるワークフロー向けのタイプ
  - 実行開始のオーバーヘッドが小さく即時に多数の実行を開始できる（1秒あたり最大で100,000件もの並行実行を処理できる）よう最適化されており、リアルタイム性が求められるワークロードに向いている
  - 例: 数万件/秒規模のデータを即座に分析・フィルタリングして次のサービスに渡すようなストリーミング処理
ステート種類
- Taskステート（タスク状態・サービス統合）
  - ワークフロー内の単一の処理単位を表す状態。Lambda関数の実行や外部で稼働するアクティビティ、あるいは他のAWSサービスのAPI呼び出しなどを1つのタスクとする。
  - 例: 最初のタスクでデータ変換用のAWS Lambda関数を実行し、次のタスクでAWS GlueのETLジョブを起動、その後のタスクで結果をAmazon Redshiftにロードする、といった一連のサービス呼び出しをStep Functions上で順次オーケストレーションできる。
- Choiceステート（条件分岐）
  - 条件評価に基づき処理の分岐を行う状態。あらかじめ定義した複数の条件式（Choiceルール）にもとづいて入力データを評価し、真と評価された条件に対応するブランチ（次の状態）へ遷移する
  - 例: 取り込んだレコードの種類に応じて別々の変換処理フローに振り分ける場合にChoiceステートで条件分岐を定義し、それぞれ対応する下流の処理（Lambda関数や別ステートマシン）を呼び出す。
- Parallelステート（並列実行）
  - 複数の処理ブランチを同時に実行するための状態。定義した各ブランチ（サブ状態マシン）を可能な限り並行に開始し、すべてのブランチが終了（成功または失敗の終端状態に到達）するまで次のステップに進まない（依存関係のない処理を同時並行で行い、ワークフロー全体の処理時間を短縮できる）。
  - 例: 異なるストレージから取得したデータを2つのブランチに分けて同時に変換処理し、全ブランチ完了後に結果を統合するようなデータパイプラインで使用する。
- Mapステート（繰り返し処理）
  - リスト（配列）形式の入力データに含まれる各要素に対して、同一の処理ステップ群（サブワークフロー）を繰り返し実行する状態。各要素の処理はデフォルトで可能な限り並列に実行されるため、データセット全体を高速に処理できる。
  - 例: S3に蓄積された数百のログファイルを入力リストとして受け取り、各ファイルに対する解析処理を平行に実行して全ファイルを効率よく処理する
- Waitステート（待機・遅延）
  - 指定した一定の待機時間が経過するか、指定した時刻になるまでワークフローの実行を一時停止する状態（待機時間は秒数（相対時間）または日時（絶対時間）で設定）。
  - 例: ダウンストリームのシステムが準備できるまで5分間待ってから次の処理を開始する、といったシナリオでWaitステートを用いることで、処理のタイミング調整（スケジューリング）できる
エラー処理とリトライ
- 各タスクが失敗した際にはデフォルトで再試行が行われ、ワークフロー全体が即座に停止しないようになっている（処理が数秒で完了する場合でも数ヶ月かかる場合でも、自動的にtry/catchとリトライを適用）
- 状態定義ごとに細かなリトライポリシー（最大再試行回数や待ち時間間隔、指数バックオフ等）を設定したり、Catchハンドラでエラー発生時に別の代替ステートへ遷移させることも可能
- 例: データ変換用Lambda関数が一時的なネットワーク障害で失敗した場合、数秒待って自動再実行を数回試み、それでも失敗する場合にはCatchでエラー通知用の処理（SNSでアラート送信等）に切り替える。
ワークフロー実行時に必要な権限
- ステートマシンで設定されるAWSサービスに対する権限
- ステートマシンで設定されたAWSサービスが使用するAWSリソースに対する権限
- 例：ステートマシンとして設定したEMRのタスクでS3データにアクセスする必要がある場合、StepFunctionsに必要な権限はEMRに関する権限とS3に関する権限である。

Glue

FindMatches変換
- パターン認識に基づく類似性分析により、データの重複削除やクリーニングを行う機能（ノーコード）
- ユニークな識別子が存在しない場合でも、名前や住所の表記揺れなどをファジーマッチさせて対応
- 例: 異なるシステム間で重複して存在する顧客情報の統合（例: 綴りや住所が多少異なる顧客レコードを同一人物と識別）や、不正防止のための多重アカウント検知（新規登録アカウントが過去の不正ユーザと類似していないか確認）
ジョブ実行クラス
- スタンダード：ジョブの起動が速く専有リソースを割り当てるため、時間厳守のワークロードに適している
- フレキシブル：空きリソースでジョブを実行するため起動に時間がかかる場合があるが、コスト最適化に有効
- 例: 本番環境のデータパイプラインのように処理開始の遅延が許されないジョブでは Standard クラスを使用し、毎夜実行されるバッチETLやテスト用途のジョブでは Flexible クラスを選択し、多少の遅延を許容してリソース使用量を弾力的に調整することでコストを削減する
SchemaRegistory
- ストリーミングデータのスキーマを中央管理し、バージョン管理や互換性のチェックを行う機能
- Apache Kafka、Amazon Kinesis Data Streams、Amazon MSK などと統合してスキーマを登録・管理し、データ生成時にスキーマ検証を適用することでプロデューサー・コンシューマー間のデータ構造の整合性を保証する
- 例: Kafkaに流れるデータをAvro形式で保存し、スキーマをGlue Schema Registryに登録することで、プロデューサー・コンシューマー間で一貫したデータ構造を維持できる。さらに、Kafka Connectのコンバーターを活用して、データのシリアライズやデシリアライズを自動化し、データの互換性を確保しながらストリーミングパイプラインを構築できる。
- Integrating with AWS Glue Schema Registry参照
DataBrew
- データ準備ツール（クレンジング、型変換、カラム編集、EDAなどをノーコードで行える）
- 準備したデータはRedshiftやRDS、Athenaに出力できる。
- 例: 大量のCSVやExcelから取り込んだ生データに対し、不要な記号を一括除去したり日時フォーマットを統一するといった前処理をGUI上で行い、短時間で分析や機械学習に利用できるデータセットを作成できる
ETLのジョブブックマーク
- データソース（S3やJDBC接続DB）に対するETLジョブの実行状況を保持し、差分処理を可能にする機能
- 例: 日次で新規アップロードされるログファイル群に対しジョブブックマークを有効にすると、前日までに処理済みのファイルをスキップし当日追加分のみETL処理できる
- AWS Glue AWS Black Belt Online Seminar参照
DataQuality
- データの品質検証とモニタリングを実施する機能（独自のDQDLを利用）
- Glue が自動でデータ統計を分析してルールの推奨を行うことが可能
- 例: 日次で集計する売上データに対し、「金額が負値でない」、「必須項目がNULLでない」などビジネスルールを設定し、チェックさせる。ルール違反のレコードが検出された場合、それらの問題データを特定・隔離して通知することで、ダウンストリームの分析や機械学習モデルに不適切なデータが入らないようにできる
- Set up alerts and orchestrate data quality rules with AWS Glue Data Quality参照
Studio DetectPII変換
- データセット内の個人特定情報（PII）を自動的に検出し、規定に基づいて難読化（SHA-256によるハッシュ化など）する機能
- 例: 分析用に顧客の行動ログをデータレイクに集約する前に、氏名やメールアドレスなどのPIIを自動検出して伏字化し、プライバシーに配慮したデータセットを生成する
ResolveChoice組み込み変換（ETLジョブのDynamicFrameで利用できる機能）
- GlueのDynamicFrameにおけるデータ型の不一致や曖昧さを解消するための組み込み変換（カラムの型不一致に対する変換機能やNULL値の置換機能など）
- 例: 異なるデータソースから集約したデータで「ID」フィールドの型がソースによって整数だったり文字列だったりする場合に、ResolveChoiceを適用して型を揃えてからデータを書き出す
パーティションインデックス
- AWS Glueデータカタログのテーブルに対してパーティション情報の検索を高速化するための索引機能
- Glueにパーティションインデックスを作成すると、指定したキーに基づく検索可能なインデックスがデータカタログ上に構築され、パーティションメタデータの取得・フィルタリング時間を短縮できる（GetPartitionAPIの呼び出し回数が減るため）
- 例: 10年以上にわたるログデータを日付別・地域別にパーティション管理しているテーブルでも、パーティションインデックスを作成しておけば Athena クエリ実行時に該当パーティションの検出が迅速に行われる

DMS

異種間データベース移行のサポート
- AWS DMSは、ソースとターゲットが異なるデータベースエンジン間（異種）のデータベース移行にも対応する（エンジンの違いによるデータ型やSQL方言の差異を自動で吸収）
- 異なるデータベースエンジン間の移行を支援するスキーマ変換機能（AWS DMS Schema Conversion）により、テーブル定義やストアドプロシージャといったデータベースオブジェクトを自動的に移行先エンジンの形式に変換できる
- 例: オンプレミスのOracleデータベースをAmazon Aurora PostgreSQLに移行する
継続的なデータレプリケーション (CDC)
- DMSでは、一度のデータ移行後もソースからターゲットへの継続的なデータ同期（変更データキャプチャによる増分レプリケーション）により、長期間にわたってリアルタイムまたはニアリアルタイムのデータ連携を実現できる
- 例: 本番のOLTPデータベースで発生する日々のトランザクションを継続的にキャプチャし、Amazon Redshiftなどのクラウド上のデータウェアハウスにほぼリアルタイムで反映するといったデータパイプラインにDMSを利用できる
最小ダウンタイムのデータ移行
- AWS DMSは移行中もソースデータベースを稼働状態に保ち、サービス停止時間（ダウンタイム）を最小限に抑えるよう設計されている
- 初回に全データを一括でロードした後、CDCにより移行作業の裏で本番システムを動かし続けることができる
- 例: 24時間稼働が求められる本番データベースをクラウドに移行する際にDMSを利用すれば、移行中もアプリケーションは平常通り稼働し続ける。データの変更内容がリアルタイムで新環境に取り込まれるため、最終的な切り替え時のダウンタイムを数分程度まで縮小でき、業務への影響を極力避けることができる。
幅広いソース・ターゲットへの対応
- ソースとして、オンプレミス環境で動作する自己管理型や商用データベース（Oracle、SQL Server、SAP など）や、Amazon RDSやAmazon Auroraなどのクラウド上のデータベースなどに対応
- ターゲットとして、上記のRDBのほかに、Amazon Redshift（データウェアハウス）やAmazon S3（データレイク）を指定することも可能
- 例: RDS(PostgreSQL)に保存された業務データを定期的にAmazon S3にレプリケートし、企業のデータレイクに取り込む
  Incremental Load from Postgres SQL RDS to S3 Using AWS DMS and Change Data Capture (CDC)参照
  参照
- 例: MySQLのデータを直接Amazon Redshiftに移行してクラウド上で分析を行う
シンプルなデータ変換とデータ検証
- AWS DMSはデータ移行時に基本的なデータ変換機能（特定のテーブルやカラムの除外・フィルタリング、データ型のマッピング変更など）を備えており、ソースとターゲットのデータ形式の違いを吸収できる。
- 移行したデータの検証機能もサポートしており、移行元と移行先のデータが正確に一致しているかをチェックすることで、レコードの欠落や不整合を検出する
- 例: データ移行の際に日時フォーマットをターゲットのデータベース仕様に合わせて変換したり、機密情報を含むカラムを除去してから移行したりする場合にDMSの組み込み変換機能が役立つ

ストリーミングデータ処理サービスの比較

試験では、提示されたユースケースにおいて最適なサービスを選択する能力が求められます。そのため、AWSが提供する4種類のストリーミング処理サービスそれぞれの特徴を適切に判別できていることは、試験の問題を解くうえで非常に重要です。下記にストリーミング処理サービスの比較表を作成したので、試験前に参考にしてください

項目	Amazon Kinesis Data Streams	Amazon Data Firehose	Amazon Managed Service for Apache Flink	Amazon MSK
用途	リアルタイムのストリーミングデータ取り込み・分配サービス	ニアリアルタイムでストリーミングデータをロードする全自動マネージドサービス	リアルタイムでストリーミングデータの分析・処理を行うフルマネージドApache Flink実行サービス	オープンソースのApache KafkaをAWS上で管理するサービス
特徴	多数プロデューサからGB/s規模のデータを連続取り込みし、複数コンシューマ（アプリや他サービス）の並行処理を可能にする	DLやDWH、分析サービスへのデータ変換・配信・バッファをすべて管理する	ストリーミングETL、ウィンドウ集計、異常検知などステートフルなストリーム処理をコードで実装して実行できる	Kafkaクラスタのプロビジョニングやスケーリング、メンテナンスを簡素化し、GUIで高可用なKafka環境を構築できる
データ処理方式	【逐次処理】データ送信されると即ストリームに取り込み、コンシューマはレコードまたは小バッチで処理	【マイクロバッチ処理】データを一定サイズor時間でバッファし、まとまった単位で宛先へ配信	【マイクロバッチ処理】Apache Flinkアプリによるイベント駆動型の連続データ処理（バッチ処理もウィンドウ設定次第で可能）	【逐次処理】プロデューサが送ったイベントがブローカで即時にトピックに追記され、コンシューマはリアルタイムで継続的にメッセージを取得
リアルタイム処理	〇（ミリ秒単位の処理）	△（数秒から数分の遅延あり）	〇（ミリ秒単位の分析・処理）	〇（リアルタイム処理が可能）
データ変換・加工	△ (サービス自体には変換機能なし。AWS Lambda関数やKCLアプリケーションなどカスタムコンシューマ側で実装)	〇（サービスに内蔵。例: Lambda関数組込処理、JSON→Parquet/ORC変換、圧縮処理、動的パーティション分割…）	〇（SQL・Flink APIを使ったデータ変換・集計が可能）	✕（MSKそのものはデータ中継・保管のみ実装。Kafka StreamsやFlinkとの連携で実装）
配信先例	Lambda, S3, Redshift, Data Firehose など	S3, Redshift, OpenSearch, Splunk, Snowflake など	Kinesis Data Streams, S3, DynamoDB, Redshift など	Lambda, S3, Redshift, DynamoDB, RDS など
スケーラビリティ	【シャード単位】シャード追加・削除で手動スケール（オンデマンドモードにより自動スケーリング可能）	【自動スケール】処理量に応じてバックエンドでスケール。指定したバッファ遅延要件内で低レイテンシを維持するよう調整される	【自動スケール】アプリのCPU使用率などを監視して自動でApache Flinkのタスク並列数（並列インスタンス数）を調整する。	【ブローカ単位】ブローカ追加によるクラスター拡張で手動水平スケール（MSK Serverless を利用すれば自動スケールが可能）
ユースケース	【アプリログのリアルタイム処理】一方向にLambdaで異常検知アラート、別方向にデータレイク保存など分岐処理が可能	【サーバログの収集】アプリサーバのログをFirehoseに送り、圧縮・変換しながら数分以内にSplunkインスタンスやS3に蓄積（※1）	【リアルタイム集計ダッシュボード】ウィンドウ集計による1分ごとの売上やセンサーレベルをAmazon Timestreamに出力し、Grafanaに秒単位の最新指標を可視化（※2）	【既存Kafka移行】オンプレミス運用のKafkaをMSKに移行し、サーバ管理をAWSに任せつつ既存のプロデューサ・コンシューマコードを活用

(※1)What is Amazon Data Firehose?参照

(※2)Near real-time processing with Amazon Kinesis, Amazon Timestream, and Grafana参照

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up