Amazon DEA-C01: データワークロードのコスト最適化 — 学習ガイド

By Laurynas Brazys · 2 August 2026 · #amazon #dea-c01 #certification #exam-prep #study-guide

こちらの一部です： Amazon Data Engineer Associate DEA-C01 — 学習ガイド. 検証済みの解答で練習： Amazon試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

データワークロードのコスト最適化は、ストレージ、コンピューティング、データ処理パイプラインが想定外の支出を伴わずに価値を提供できるようにするためのものです。データエンジニアは、サービスや利用パターンによって異なる料金モデルを考慮しつつ、クエリパフォーマンス、データの耐久性、可用性のバランスを取る必要があります。この分野では、ストレージクラスとライフサイクルポリシー、クエリおよびクラスターレベルの制御、スポットキャパシティとリザーブドキャパシティ、そしてサーバーレスとプロビジョニングのトレードオフに関する知識が求められます。

S3ストレージのコスト最適化

S3 Intelligent-Tieringは、アクセスパターンが予測不可能なデータセットに対して推奨されるデフォルト設定です。オブジェクトのアクセス頻度が確実に予測できない場合は、コンソールまたはAWS CLI経由でIntelligent-Tieringを有効にします。Intelligent-Tieringを設定する際は、適切なモニタリング/自動化料金（オブジェクトごとに少額の月次モニタリング料金がかかります）を認識し、自動階層移行の適切な最短日数を設定します（高頻度アクセス階層から低頻度アクセス階層への移行は30日）。オブジェクトタグとライフサイクルルールを使用して、モニタリング料金が節約額を上回ってしまうような、小さくてリクエスト数の多いオブジェクトを除外します。

S3の支出を削減するために、以下の運用パターンを使用します：

• ライフサイクルルールを作成する前に、S3 Storage Class Analysis（コンソール > 管理 > 分析、または

undefined

）を実行して、プレフィックス/タグレベルのアクセスパターンを特定します。

• ライフサイクルトランジションを使用して、大規模な履歴データセットをアーカイブクラス（Glacier Flexible RetrievalまたはGlacier Deep Archive）に変換します。ビジネスSLAに合わせてライフサイクルトランジションのタイミングを設定し、頻繁なExpedited retrievals（迅速な取り出し）を避けます。
• 分析ワークロードでは、多数の小さなオブジェクト（スモールファイル問題）をより大きなオブジェクト（Parquetコンテナファイルなど）に統合し、リクエストごとおよびGETごとのコストを削減します。

判断基準：

• 予測不可能で、中程度のアクセスがあり、取り出しタイミングが柔軟なデータセットにはIntelligent-Tieringを使用します。
• アクセス頻度は低いが、迅速な取り出しが必要で、取り出しが予測可能なデータにはStandard-IAまたはOne Zone-IAを使用します。
• 取り出しがまれで、数分から数時間のレイテンシを許容できる長期保存にはGlacier Standard/Bulk/Deep Archiveを使用します。高額な料金を避けるため、ExpeditedよりもBulk/Standardでの取り出しを優先します。

AthenaとRedshiftのコスト管理

Athenaのコストはスキャンされたバイト数に応じて増加します。ワークグループ制御（コンソールまたは

undefined

）を適用して、クエリごとのデータスキャン上限とワークグループごとの月次予算を実装します。「ワークグループ設定の強制」を有効にすると、クエリごとのデータ上限を超えたクエリは実行されずに失敗します。ソースファイルをカラムナ（列指向）圧縮フォーマット（Parquet/ORC）に変換し、日付や一般的なフィルター列でパーティショニングし、述語プッシュダウンを適用し、CTASまたはCREATE TABLE ASを使用して最適化されたデータセットをマテリアライズすることで、スキャンされるバイト数を削減します。クエリ結果の再利用や、ワークロードを別々のワークグループに分離することで、チーム間のコスト漏洩を防ぎます。

Redshiftのコストに関する決定は、ワークロードの予測可能性とストレージの選択に依存します。安定的で予測可能なデータウェアハウスのコンピューティング利用には、Reserved Nodes（1年または3年契約、一部/全額前払いオプションあり）を購入し、オンデマンドに比べて割引価格を確保します。変動するワークロードの場合：

• Redshift Serverlessまたはマネージドストレージ付きのRA3ノードを使用して、コンピューティングとストレージを分離します。
• コンカレンシースケーリングは控えめに使用し（追加料金が発生しますが、自動スケーリングを提供します）、クレジットを監視します。

比較のハイライト：

• Reserved Nodes: 定常状態の長期的なクラスターに最適。コミットメントが必要ですが、大幅な割引が得られます。
• On-demand: 予測不可能なプロジェクトや短期プロジェクトに柔軟に対応。時間あたりのコストは高くなります。
• Serverless/RA3 with Spectrum: ストレージをS3に移行し、アクティブなときにコンピューティング料金を支払うことで、大規模なリザーブドコミットメントを回避します。

GlueとEMRのコスト戦略

AWS Glueは、複数のコスト削減手段を持つサーバーレスETLを提供します。レイテンシに敏感でないバッチジョブには、Glueのフレキシブル実行（Glue Flexジョブ）を使用します。これにより、標準のGlue実行と比較してコストを最大約34%削減できます。Glue StudioまたはCLI（

undefined

）でGlueジョブのパラメータを設定し、ワーカータイプと最大DPU数を選択し、無制限のオートスケーリングを防ぐために適切な最大DPU上限を設定し、ジョブブックマークを使用して完全な再処理を回避します。インタラクティブなワークロードやレイテンシに敏感なワークロードでは、ワーカータイプ（Standard/G.1X/G.2X）を選択し、並列度を責任を持って調整します。

EMRのコスト削減は、マスターノードとコアノードをオンデマンドに保ちつつ、タスクノードにスポットインスタンスを使用することにかかっています（コンソールまたは

undefined

でインスタンスフリートまたはインスタンスグループを設定）。タスクノードにのみスポットを使用し、容量最適化割り当て戦略を選択し、入札付きスポットを使用する場合は適切な入札/最大価格を設定します。以下の方法でクラスターの状態とジョブの耐障害性を保護します：

• スポットのタスクノードを使用する場合、永続データはHDFSではなくS3に保存します（EMRFSを使用）。
• スポットの中断に対処するために、自動リトライとステップベースのワークフローを使用します。
• EMR Managed Scalingを利用してクラスターをライトサイジングします。スケーリングポリシーを監視して（スケーリングの）振動を防ぎます。

判断基準：

• 優先度が低く、コストを重視し、起動時間の長さを許容できるETLにはGlue Flexを使用し、最大DPU数に上限を設定します。
• 大規模な一時的処理（例：夜間バッチ）には、タスクノードにスポットインスタンスを使用したEMRを使用しますが、マスター/コアはオンデマンドにするか、混合割り当てのインスタンスフリートを使用します。

データサービスにおけるリザーブドキャパシティとSavings Plans

リザーブドキャパシティとSavings Plansは、データサービスごとに適用方法が異なります。EC2ベースのサービス（EMR、セルフマネージドHBase、カスタムHadoop）では、コンピューティング費用をカバーするためにEC2 Savings Plansまたはリザーブドインスタンスを使用します。モビリティのニーズに応じて、リージョンまたはゾーンのオプションを選択します。Redshiftは、プロビジョニングされたクラスター向けにリザーブドノードの購入をサポートしており、予測可能なウェアハウスワークロードの時間単位コストを削減します。サーバーレスサービス（Glue、Athena）にはリソース予約の仕組みはありません。代わりに、ワークロードのスケジューリングやデータフォーマットの変更によって最適化します。

実践的な購入ガイダンス：

• 使用率が既知の定常的なデータウェアハウスワークロードには、Redshiftリザーブドノードを購入します（1年または3年の期間、および全前払い/一部前払い/前払いなしを評価します）。
• インスタンスファミリーをまたがる予測可能なEMR/EC2の費用をカバーするために、EC2 Savings Plansを使用します。Savings Plansは、インスタンスファミリーやリージョンが変更された場合に柔軟性を提供します。
• サーバーレスサービスのためにリザーベーションを購入しないでください。代わりに、使用パターン、スケジューリング、およびデータレイアウトを最適化します。

よくある落とし穴と判断基準

• Athenaはパーティショニングなしでテーブル全体をスキャンします — 大規模な時系列テーブルは、常に日付やその他のカーディナリティが高く、頻繁にフィルタリングされる列でパーティション分割し、スキャンされるバイト数を最小限に抑えるためにParquet/ORCに変換します。
• GlueのDPUオートスケーリングは過剰にプロビジョニングされる可能性があります — ジョブ設定（コンソールまたはaws glue update-job）でDPUの最大上限を設定し、適切なワーカータイプを選択してコストを予測可能に保ちます。
• S3 Glacierの取り出し料金 — ビジネス上不可欠でない限り、迅速（Expedited）な取り出しは避けます。標準（Standard）またはバルク（Bulk）の取り出しを計画し、現実的なSLAでライフサイクル移行を設定します。
• EMRのマスターノードとコアノードではスポットインスタンスを使用すべきではありません — マスター/コアはオンデマンドとして設定し、HDFSの状態を回避または複製したタスクノードにのみスポットを割り当てます。
• 多数の小さなS3オブジェクトはリクエストコストを増大させ、分析を遅くします — インジェスト中に小さなファイルをより大きなカラムナフォーマットのファイルにまとめます。
• コンカレンシースケーリングや管理されていないオートスケーリングに過度に依存すると、時間単位の料金が増加する可能性があります — スケーリングのメトリクスを監視し、制限を設定し、ワークロードが予測可能な場合はリザーブドキャパシティを使用します。

実践的な問題：Acme Analyticsの夜間ETLコスト削減

Acme Analyticsは夜間のETLと日次のアドホック分析を実行していますが、生のS3ストレージの増加とオンデマンドのRedshift時間により、月々のクラウド費用が急増しています。同社は、夜間のSLAに影響を与えることなく35%のコスト削減を必要としています。

1. S3ストレージクラス分析を実行し、ライフサイクルルールを設定して、90日以上経過したコールドな生ファイルをGlacier Flexible Retrievalに移動します（バルク/標準の取り出しを計画）。
2. 生のCSVをパーティション分割された圧縮Parquetに変換し、小さなファイルをまとめます。最適化されたデータセットは、Athena/Redshift Spectrum用に別のプレフィックスで保存します。
3. クエリごとのデータスキャン上限を持つAthenaワークグループを作成し、ワークグループ設定を強制します。クエリ結果の再利用を有効にし、ワークグループごとの月次予算を設定します。
4. 緊急でない変換のためにバッチETLをGlue Flexジョブに移行し、DPUの最大上限を設定し、オフピーク時間にスケジュールします。緊急のジョブのためには、より小規模な標準のGlueフリートを維持します。
5. Redshiftのサイジングを適正化します：安定したベースラインのコンピューティングのために1年間のリザーブドノードを購入し、履歴データをS3に移動して頻度の低いクエリにはSpectrumを使用し、コンカレンシースケーリングは監視下でのみ有効にします。

論理的根拠：この戦略は、データフォーマットとライフサイクルの最適化（ストレージとスキャンコストの削減）、柔軟なジョブのためのサーバーレスの低コスト実行（Glue Flex）、クエリガバナンス（Athenaワークグループ）、および持続的なコンピューティングのためのリザーブドキャパシティを組み合わせ、可用性とパフォーマンスを維持しながら割引を最大化します。

← データパイプラインの監視とトラブルシューティング · すべてのドメイン · データ品質、検証、可観測性 →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →

Amazonを閲覧 →