内容

試験には次の内容ドメインと重み付けがあります。

ドメイン 1: データの取り込みと変換 (34%)
ドメイン 2: データストア管理 (26%)
ドメイン 3: データの運⽤とサポート (22%)
ドメイン 4: データセキュリティとガバナンス (18%)

ドメイン 1: データの取り込みと変換

1.1: データの取り込みを実⾏

データを取り込むAWSサービスのスループットとレイテンシの特性

Kinesis Data Streams - TB/時のスループットで、数十万のソースから大量のデータを取り込むことができます。データは1秒以内に処理できるため、待ち時間が短くなります。KCLまたは Spark Streamingなどのフレームワークを使用したカスタムストリーム処理をサポートします。
Kinesis Data Firehose - 低レイテンシーでS3やRedshiftなどのAWSデータストアにストリーミングデータを取り込むために使用されます。スループット要件に合わせて自動的にスケーリングします。

データ取り込みパターン(頻度やデータ履歴など)

バッチ取り込み - 大量のデータが時間ごと、日ごと、または週ごとのバッチのように定期的に取り込まれます。これにより、履歴データを分析用に処理できるようになります。
継続的な取り込み - ストリーミングデータは、生成時に継続的に取り込まれます。これによりリアルタイム処理が可能になりますが、順序付けとデータの一貫性に関する課題が伴います。
ハイブリッドアプローチ - バッチ処理とストリーム処理を組み合わせます。たとえば、ストリーミングデータは、一括処理の前に、まず短いバッチで収集されます。これにより、低遅延のニーズとバッチ効率のバランスが取れます。

ストリーミングデータの取り込み

Kinesis Data Streamsは、数十万のデータソースから大規模なストリーミングデータを継続的に取り込んで処理できます。リアルタイムアプリケーションに低遅延のデータアクセスを提供します。
Kinesis Data Firehoseは、バッチ処理や分析のためにストリーミングデータをS3やRedshiftなどのデータストアに確実にロードできます。
MSK(Managed Streaming for Apache Kafka)を使用すると、Apache Kafkaプラットフォームを使用してスケーラブルなストリーミングデータパイプラインを簡単に構築できます。ストリーミングデータの取り込みと処理において、高スループットと低遅延を実現します。
Managed Service for Apache Flink（旧Kinesis Data Analytics）は、Apache Flinkを使用してストリーミングデータをリアルタイムで変換および分析できます。複雑なイベント処理、時間枠での集計、長期にわたる状態の維持の機能を提供します。

バッチデータ取り込み (スケジュールされた取り込み、イベント駆動型の取り込みなど)

スケジュールされた取り込み - データは、時間ごと、毎日、毎週などの定義されたスケジュールでソースシステムからS3、Redshift などのAWSサービスに取り込まれます。これにより、分析用に大量の履歴データを処理できるようになります。LambdaとEventBridegeの活用はコスト効率が高い
イベント駆動型の取り込み - 取り込みは、S3バケットに配置されたファイルやデータベーステーブルに表示されたレコードなどのイベントによってトリガーされます。これにより、固定スケジュールなしで利用可能になったデータをバッチで取り込むことができます。

イベントトリガーの設定(例: S3 イベント通知、EventBridge)
S3イベント通知は、新しいファイルがアップロードされたときに、フィルタールールを使用してLambda関数のARNをイベント通知の宛先としてLambdaに即座にトリガーされるため、プロセスが効率的かつリアルタイムになります。

データ取り込みパイプラインの再生可能性
データ取り込みパイプラインの再生可能性とは、データ取り込みパイプラインを再実行して、以前に取り込まれたデータを取り込む機能を指します。これは、元の取り込みが失敗した場合や、後でさらにデータを追加する必要がある場合に便利です。
Step Functionsを使用して、取り込みワークフローの進行状況を調整および追跡します。Step Functionsは、パイプラインを再生可能にするのに役立つ再試行ポリシーや冪等性などの機能を提供します。

ステートフルおよびステートレスデータトランザクション

ステートフルトランザクションでは、アプリケーションはサーバー側で各ユーザーセッションまたはトランザクションに関する状態またはデータを維持する必要があります。これには、ショッピングカートの内容、ユーザープロフィールなどが含まれる可能性があります。
ステートレストランザクションでは、アプリケーションはサーバーに状態を保存しません。状態を独立して維持するために、データベースやキャッシュなどの外部データストアに依存します。

バッチソースからのデータの読み取り (例: S3、Glue、EMR、DMS、Redshift、Lambda、AppFlow）
AppFlowを使用すると、フローは送信元と宛先の間でデータを転送します。最小限の運用オーバーヘッドでSaaSアプリケーションからS3、Redshiftなどにデータを継続的に送信できます。

データソースへの接続を許可するIPアドレスのホワイトリストを作成
セキュリティグループを使用して、DBインスタンスへのネットワークアクセスを制御します。特定のIPアドレスまたは範囲からデータベースポート(MySQLの3306など)への接続を許可する受信ルールを追加します。

スロットルの実装とレート制限の克服(DynamoDB、RDS、Kinesisなど)

可能な場合は自動スケーリング機能を使用して、実際の使用パターンに基づいてスループットを動的に調整します。予期しないトラフィックの急増時のスロットリングを防ぐのに役立ちます。
読み取り/書き込み操作をパーティション、シャード、またはAZ全体に均等に分散して、ホットスポットを防ぎます。分散が不均一であると、過負荷のユニットでスロットルが発生する可能性があります。
再試行が有効になっているサービスの場合、構成されたタイムアウト以内に再試行が成功した場合、アクションは必要ありません。ただし、永続的なスロットルには容量の調整が必要です。
同期ワークフローの場合、コード内で非同期/ノンブロッキングパターンとバックオフ/再試行ロジックを使用して、リクエストが失敗する代わりに時折発生するスロットルを適切に処理します。

KinesisからのLambda関数の呼び出し

予想されるデータ量と処理要件に基づいて、より多くのメモリ割り当てを使用してLambda関数を構成します。メモリを増やすと、リソース不足によるスロットリングを回避できます。
複数のLambda関数を使用し、Kinesisストリーム内の異なるシャードからそれらの関数をトリガーして処理を並列化します。これは、複数の機能間で負荷を分散するのに役立ちます。
Lambda関数コードに再試行ロジックを実装して、一時的なエラーと再試行を適切に処理します。たとえば、レコード処理を中止する前に数回再試行します。
呼び出し時間、スロットル、遅延（IteratorAge）などのLambda関数のメトリクスを監視して、ボトルネックを特定します。必要に応じて処理を調整するために利用できるレコードなどのKinesisメトリクスも監視します。
一度に1つのレコードを処理するのではなく、Kinesis Client Library（KCL）を使用してレコードをバッチ処理することにより、レコードごとのオーバーヘッドが削減され、スループットが向上します。
Lambda関数がKinesis Data Streamsからデータを受け取る際に、Lambda関数のトリガーであるKinesisイベントソースのバッチサイズとバッチウィンドウの設定を検討します。バッチサイズが小さすぎると遅延が発生し、大きすぎるとトリガーごとに処理されるデータの量が多くなります。

1.2: データの変換および処理

形式間でのデータの変換 (たとえば.csvからParquet)
データセットを行指向のCSV形式から列指向のParquet形式に変換すると、特定の列に頻繁にアクセスするGlueジョブのパフォーマンス効率が向上します。

パフォーマンスのニーズに合わせてコンテナの使⽤を最適化します(例: EKS、ECS)

EKSにアプリケーションをデプロイし、Kubernetes クラスター内のGPU高速化されたEC2インスタンスを活用します。
水平ポッド自動スケーリングを使用して、リアルタイムのCPUとメモリ使用量に基づいてポッド数を動的に調整します。
パフォーマンスメトリックに基づいて自動スケールポリシーを実装し、必要に応じてリソースを動的にスケールアップまたはスケールダウンします。

様々なデータソースへの接続 (JDBC、ODBC)

JDBC（Java Database Connectivity）：JavaアプリケーションがRDBと対話できるようにするJavaベースのAPI
ODBC：データベースに接続するための標準インターフェイス。特定のプログラミング言語に限定されません。ドライバーマネージャーとドライバーを使用して、さまざまなデータベースに接続します。

中間データのステージング場所
中間データのステージングロケーションは、変換されたデータをターゲットデータベースまたはデータウェアハウスにロードする前に一時的に保存するために、パイプラインで一般的に使用されます。
ステージング領域の一般的なストレージオプション：S3、EFSファイルシステム、FSxファイルシステムなど

パフォーマンス - ステージング領域を使用すると、ターゲットデータベースのパフォーマンスに影響を与えることなく、オフラインでデータを変換および準備できます。これにより、リソース使用量の急増が防止されます。
エラー処理 - データのロードプロセス中にエラーが発生した場合は、問題のあるデータをターゲットにロードする前に、ステージング領域でエラーを捕捉する方が安全です。ステージング領域により、データの検証とクレンジングが容易になります。
データの分離 - データをターゲットデータベースから分離してステージングすると、ETLプロセスが分離され、ロード中に問題が発生した場合でもターゲットデータが破損しないことが保証されます。

1.3: データパイプラインの調整

オーケストレーションサービスを使用してデータETLパイプラインのワークフローを構築する(例: Lambda、EventBridge、MWAA、Step Functions、Glueワークフロー)

Step Functionsを使用すると、ステートマシンを視覚的に作成して、Lambda、Glue、RedshiftなどのAWSサービス間のワークフローを調整できます。複数ステップのETLプロセスを調整するためのサーバーレスな方法が提供されます。
Glueワークフローを使用すると、ワークフローに連結できるPythonまたはScalaベースのETLジョブを構築できます。Glueは、基盤となるリソースのスケジューリング、監視、スケーリングを処理します。
LambdaとS3、DynamoDB、Kinesisなどのサービスを使用して、イベント駆動型のETLパイプラインを構築できます。たとえば、S3アップロードによってLambda関数をトリガーして、データを処理してRedshiftにロードできます。
これらのサービスからのCloudWatchメトリクスとアラートにより、ETLジョブのステータスとパフォーマンスを可視化できます。

スケジュールまたは依存関係に基づいてデータパイプライン用にAWSサービスを構成する方法

Step Functions - ワークフローは、EventBridgeルールを使用してスケジュールに従ってトリガーできます。
Glueワークフロー - ジョブ間の依存関係は、ワークフローの構築中に定義されます。
Data Pipeline - データを操作または生成するアクティビティを含むパイプラインを定義するために使用できます。パイプラインは定期的に実行するようにスケジュールできます。
イベントソースを備えたLambda - S3、DynamoDB、Kinesisなどのサービスからのイベントによってトリガーされ、イベント駆動型のデータパイプラインを構築できます。関数は完了に基づいて相互に呼び出すこともできます。

サーバーレスワークフローの実装と保守

Step Functionsを使用すると、ステートマシンを視覚的に作成して、サーバーレスアプリケーションのコンポーネントをオーケストレーションおよび調整できます。個々のステップでは、Lambda関数、DynamoDBなどのAWSサービスを呼び出すことができます。Step Functionsは、依存関係に基づいてステップが正しい順序で実行されることを保証します。
失敗した場合は自動的に再試行され、エラーが処理されます。これにより、アプリケーションでのカスタムエラー処理コードの必要性が減ります。
Step Functionsのメトリクスとトレースにより、ワークフローの実行を可視化できます。これは、ワークフローの監視とトラブルシューティングに役立ちます。
Lambda、SQS、SNSなどのサービス上の独立した分離されたコンポーネントで構築されたサーバーレスアプリケーションは、Step Functionsを使用して統合できます。

通知サービスを使⽤してアラートを送信する（SNS、SQS）
SNS通知をSQSキューに送信するには、SQSを指定してトピックをサブスクライブします。トランスポートとして使用し、エンドポイントとしてSQSキューARNを提供します。
メッセージを正常に配信するには、SQSキューの所有者がキューをSNSトピックにサブスクライブする必要があります。通知は自動的にSQSキューに配信されます。

1.4: プログラミングの概念

CI/CD（実装、データパイプラインのテストとデプロイ）

CodePipelineは、ビルド、テスト、デプロイなどの複数の段階を含むワークフローを調整するのに最適です。ソース管理のためにGitHubと統合でき、ビルドとテストのためにCodeBuildを組み込むことができます。
CodeBuild、CodePipeline、CodeDeployなどのAWSサービスは、AWSでのCI/CDパイプラインのセットアップと管理に役立ちます。コード変更の構築、テスト、展開のプロセスを自動化するため、組織は新機能をより迅速かつ確実にリリースできるようになります。

反復可能なデプロイメントのためのIaC

AWS SAM：AWSでサーバーレスアプリケーションを定義できるフレームワーク。SAMを使用すると、いくつかのコマンドを実行するだけで、Lambda 関数、API Gateway API、DynamoDBテーブルで構成されるアプリケーションを構築してデプロイできます。
単一のSAMテンプレートを開発し、SAMの組み込みパラメータと環境変数設定を使用して、環境ごとに異なる設定を管理します。CodePipelineとCodeBuildを使用してデプロイプロセスを自動化し、デプロイ段階で環境固有のパラメータを統合します。
AWS CDKは、開発者がプログラミング言語（TypeScript、Python、Java、C#）を使用してクラウドインフラストラクチャを定義およびデプロイするためのフレームワークです。
CloudFormation：JSONまたはYAML形式のテンプレートを使用してAWSリソースを定義し、スタックとしてデプロイできるサービス

SQLクエリの最適化

パフォーマンスを向上させる可能性がある欠落しているインデックスがないか
不要な結合や派生テーブルなどの非効率性がないか
テーブルに大量のデータが含まれている場合は、テーブルをパーティション分割して、特定の範囲の値でフィルター処理するクエリを最適化する
フィルタリングや結合で頻繁に使用される列にソートキーを実装する
先頭文字と末尾文字を指定する正規表現
複合キーの使い方
述語に必要なデータブロックのみをフェッチすることで、I/Oコストが削減される

Lambda関数内からのストレージボリュームの使用とマウント

Lambda関数からEFSファイルシステムにアクセスできます。EFSファイルシステムを作成し、Lambda関数が設定されているのと同じVPCにターゲットをマウントします。
ファイルシステムIDとマウントポイントのパスを指定して、EFSファイルシステムに接続するようにLambda関数を設定します。これは、LambdaコンソールまたはAWS CLI/SDKを介して実行できます。
設定が完了すると、Lambda関数コードは関数の実行中にEFSファイルシステムに保存されているファイルの読み取り・書き込み・変更ができるようになり、安全な方法でLambdaの同時呼び出し間でデータを共有できる

ドメイン 2: データストア管理

2.1: データストアの選択

データ保存形式(.csv、.txt、Parquetなど)

S3内のデータをParquetなどの効率的な列指向形式に変換すると、Athenaでのクエリのパフォーマンスが大幅に向上し、クエリのコストを削減できます。
AthenaでCTASを使用してETLタスクのSQLクエリを実行します。CREATE TABLE AS SELECT(CTAS)クエリは、別のクエリからのSELECTステートメントの結果から、Athenaで新しいテーブルを作成します。

CREATE TABLE new_table AS 
SELECT * 
FROM old_table 
WHERE condition;

Athenaワークグループにより、Sparkを使用してAthenaにアクセスできます。
Athenaでクエリを再実行する場合、オプションで最後に保存されたクエリ結果を再利用することを選択できます。このオプションにより、パフォーマンスが向上し、スキャンされるバイト数によりコストが削減されます。

データ移⾏またはリモートアクセス⽅法の実装

Redshiftフェデレーテッドクエリ - データを移動せずに運用データベース、データウェアハウス、データレイク全体でデータのクエリと分析を行います。
Redshiftマテリアライズドビュー - クエリの結果を保存し、基になるデータが変更されると自動的に更新されます。これにより、毎回複雑なクエリを再実行することなく、事前計算された結果にアクセスできるようになります。Lambdaユーザー定義関数(UDF)を使用して、マテリアライズドビューを更新できます。
Redshift Spectrum - 標準SQLを使用して、S3内の外部データをクエリします。 Redshiftはユーザーに代わってすべてのインフラストラクチャとクエリの実行を管理するため、データをデータウェアハウスに移動する必要はありません。
Redshiftデータ共有 - データをコピーせずに、Redshiftクラスターまたは読み取りアクセス用のアカウント全体でライブトランザクションデータを共有します。データベース、スキーマ、テーブルレベルなどできめ細かなアクセスを提供できます。
Redshift Data API：Redshiftに対してクエリを実行するためにJDBCまたはODBCドライバーを使用する代わりとなる軽量のHTTPSベースのAPI。アプリケーション内から直接SQLクエリを実行できるようになる
Redshiftの同時実行スケーリングにより、Redshiftクラスターはワークロードの需要に応じてコンピューティングリソースを自動的に追加および削除できます。機械学習を用いたWLM（ワークロード管理）キューレベルで同時実行スケーリングを有効にすると、クエリワークロードに基づいて同時実行スケーリングの恩恵を受けるキューを指定できます。
DMS - オンプレミスとAWSデータベース間の異種データベース移行には、DMSを使用します。 MySQL、Oracle、PostgreSQL、MongoDB、および Microsoft SQL Server を移行できます。ソースデータベースからのデータ転送が最も重要な要素であるため、移行元のリージョンにレプリケーションインスタンスを配置することが推奨

データへのアクセスを防ぐためにロックを管理する方法(Redshift、RDSなど)

Redshift - テーブルレベルのロックを使用して、DDL ステートメント、COPY、INSERTなどの操作中のテーブルへのアクセスを制御します。ブロックの原因となる可能性のあるロックを保持しているセッションを特定し、それらのセッションを終了してロックの問題を解決します。
RDS - データベースエンジンでサポートされているロックメカニズムと、ロックの管理に関するベストプラクティスを理解します。MySQL、PostgreSQLなどの異なるデータベースは、行レベルまたはテーブルレベルで異なるロック戦略を使用します。

2.2: データカタログシステムの理解

データカタログを使用してデータソースからデータを消費する

データカタログは、すべてのデータ資産に関するメタデータの中央リポジトリとして機能します。これには、テーブル定義、物理的な場所、スキーマ、属性が含まれます。
ほとんどのソースでは、そこから読み取るジョブを作成する前に、テーブルがソースタイプに対応するデータカタログに存在する必要があります。テーブルスキーマは、データ構造に関する情報を提供します。
テーブルは、クローラー、Glueコンソール、またはAPIを使用してカタログに追加できます。S3バケットなどのデータソースをクロールすると、テーブル定義が自動的に生成されます。
テーブルが追加されると、メタデータはGlueなどのサービスのETLジョブでソースから読み取ることができるほか、AthenaやRedshift Spectrumなどのデータレイクでのクエリにも使用できるようになります。

データカタログの構築と参照(Glueデータカタログ、Apache Hiveメタストアなど)

Glueデータカタログは、テーブル定義、スキーマ、場所、その他のデータ属性を保存する中央リポジトリとして機能します。クローラーを使用すると、データソースを自動的にスキャンし、カタログにテーブル定義とパーティションを追加できます。
カタログは、さまざまなAWS分析サービスにわたるデータの共通ビューを提供します。テーブルには、Hiveメタストアと互換性のあるサードパーティツールからもアクセスできます。
カタログ内のメタデータは、基になるデータの場所が変更された場合でも引き続き利用できます。新しいパーティションは、クローラーを通じて自動的に追加することもできます。
Data Exchange：サードパーティのデータプロバイダーからデータセットを簡単に見つけて購入できるクラウドベースのデータマーケットプレイスサービス

スキーマを検出し、Glue クローラーを使用してデータカタログを設定する

クローラーは、S3バケットやデータベーステーブルなどのデータソースをスキャンするように構成されています。
CSV、JSONなどのさまざまな形式のファイルのスキーマと構造を推測する分類子を実行します。
クローラーはデータソースに接続し、ファイルのメタデータとサンプルを読み取ります。
推論されたスキーマに基づいて、データ構造、場所、その他のメタデータの詳細を含む対応するテーブルがGlueデータカタログ内に作成されます。

パーティションとデータカタログの同期

ETLプロセス中にデータから年、月、日などのパーティションキーを抽出します。
ターゲットのGlueカタログテーブルにこれらのパーティションキー列を作成し、パーティションとしてマークします。
ジョブ構成で、enableUpdateCatalogをTrueに設定してAdditionalOptionsパラメーターを追加します。また、AdditionalOptions[partitionKeys]にパーティションキーを指定することにより、新しいパーティションが作成されるとカタログを更新するようにGlueジョブに指示されます。
クローラーを再実行するか、カタログにクエリを実行して、ETLジョブの実行から設定された新しいパーティションを確認できます。

2.3: データライフサイクルの管理

S3とRedshiftの間でデータを移動するためのロードおよびアンロード操作の実⾏
COPYコマンドを実行して、S3バケットからRedshiftテーブルにサンプルデータをロードします。次に、UNLOADコマンドを実行して、データをS3バケットにアンロードします。

S3 データのストレージ層を変更するためのS3ライフサイクルポリシーの管理

S3 Infrequent-Accessストレージクラスでは、AthenaでSQLを使用することで、コスト効率よくデータを不定期分析に利用できるようになる。
データをS3 Glacier Flexible Retrievalストレージクラスに移行するライフサイクルルールにより、データを12時間以内に利用できるようになる。
デフォルトのアクセス層でS3 Intelligent-Tiering(アクセス頻度に基づいてデータを最も費用対効果の高いアクセス階層に自動的に移動する)を使用することにより、ストレージコストの最適化に対する手動のアプローチが提供される。

S3バージョン管理とDynamoDB TTLの管理
S3バージョニングを有効にすると、意図しない削除または上書きから回復する手段が提供されます。これをライフサイクルと組み合わせるポリシーにより、定義された期間の経過後に古いバージョンのオブジェクトを自動的に削除できるため、ストレージコストを効果的に管理できます。
DynamoDBのTTL機能は、一定の期間を過ぎたアイテムを自動的に削除するため、テーブルのサイズとコストを制御できます。

2.4: データモデルとスキーマの進化を設計

データリネージを使用してデータの正確性と信頼性を確保する方法

Glueデータカタログを利用して、スキーマ、パーティション、データプロファイリング結果などのメタデータを保存します。これにより、データがパイプラインを通過する際にどのように関連し、変換されるかを可視化できます。
Glue DataBrewを使用すると、データ品質をプロファイリングし、問題を特定できます。加えられた変更はすべて追跡され、データ系統が維持されます。
ETLジョブの場合、Glueワークフローを使用してジョブ間の依存関係を追跡し、ソースとターゲットの間でデータがどのように流れるかを理解します。
Glueクローラーを利用して再クロールをスケジュールし、スキーマまたは構造の変更を検出します。これにより、系統グラフが常に最新の状態に保たれます。
SageMaker ML Lineage Trackingは、MLワークフローのステップに関する情報を作成して保存します。モデルのガバナンスと監査基準を確立できます。データリネージ（Data Lineage）：利用されるデータがどこで登録され、どのシステムを経由し、なおかつどのように加工されて眼前に至っているのか、源泉から現在地点までのデータの変遷

Redshift、DynamoDB、Lake Formationのスキーマの設計

DynamoDB - 関連データが複数のテーブルに分割されるのではなく、同じテーブルに一緒に保存される非正規化データモデルを使用⇨結合の必要がなくなり、パフォーマンスが向上します。
Lake Formation - 正しいデータ型とパーティション化キーを使用して明確に定義されたスキーマを用意⇨スキーマの適用、セキュリティ、クエリの最適化などの機能が有効になります。
Redshift - 列指向データストレージを活用して、大規模なデータセットに対する高性能分析を行うことができます。主キーと外部キーを使用して正規化された形式でテーブルを設計し、関係を表します。また、ファクトテーブルとディメンションテーブルに分けます。

スキーマ変換の実行(例: SCTおよびDMS Schema Conversionを使用)
SCTとDMSスキーマ変換は両方とも移行のために連携して機能します。SCTはスキーマをコピー/変換し、DMSはデータベース/データウェアハウス間で進行中のデータレプリケーションを処理します。DMSでの変換により、移行中にスキーマ、テーブル、または列を変更できます。

スキーマ進化テクニック

スキーマ進化手法には、時間の経過に伴うデータ特性の変化にシームレスに対応するアプローチが含まれます。AWSサービスを使用したスキーマ管理は、Cloud Directory、Glue Schema Registryなどがあります。
ステージング領域があると、データの前処理が可能になり、Glueを使用して変換やスキーマを処理できます。

ドメイン 3: データの運⽤とサポート

3.1: AWS のサービスを使⽤してデータ処理を⾃動化

コードからAmazonの機能にアクセスするためのSDKの呼び出し

AWS SDK for Javaを使用すると、S3、EC2、LambdaなどのAWSサービスをJavaコードから呼び出すことができます。 SDKの依存関係をプロジェクトに追加し、サービスクライアントを呼び出すことができます。
Node.jsアプリケーションの場合は、AWS SDK for JavaScriptを使用してサービスに非同期的にアクセスします。必要なクライアントをインポートし、それらのメソッドを呼び出します。
Pythonの場合は、AWS SDK for Python(Boto3)を使用すると、PythonのコードからプログラムでAWSのサービスにアクセスできます。

データ処理のための API 呼び出し
API GatewayとLambdaを活用すると、自動スケーリングで変動する負荷を処理するのに最適なサーバーレスアーキテクチャが提供されます。

データパイプラインのオーケストレーション(MWAA、Step Functionsなど)

Step Functionsを使用すると、複数のAWSサービスをサーバーレスワークフローに調整できます。コンソールまたはSDKを使用して、ステートマシンを視覚的に設計できます。 ETLジョブなどの一般的なタスクは、Lambda、Glueなどを呼び出すステップに分割できます。Step Functionsはエラー、再試行を処理し、ステップが順番に実行されることを保証します。
MWAA(Amazon Managed Workflows for Apache Airflow)は、Apache Airflowワークフローの実行と管理を簡素化します。Airflow環境の展開、パッチ適用、スケーリングを処理します。使い慣れたAirflow UI/UXを使用してワークフローを開発し、さまざまな AWSサービスをタスクとして統合できます。
どちらのオプションでも、CloudWatchを通じてパイプラインの実行を可視化できます。 Step Functionsは線形ワークフローに最適ですが、条件付きロジックを備えた複雑なDAGベースのワークフローにはMWAAの方が適している場合があります。

3.2: AWSサービスを使⽤したデータ分析

プロビジョニングされたサービスとサーバーレスサービスの間のトレードオフ

プロビジョニングされたサービスでは、サーバーが使用中かアイドル状態かに関係なく、サーバーの料金を支払う必要があります。サーバーレスでは、実際の使用量と処理されたリクエストに基づいて支払います。サーバーレスは、予測不可能なワークロードや断続的なワークロードに対して、よりコスト効率が高い可能性があります。
通常、サーバーレスサービスにはAuto Scalingが組み込まれているため、トラフィックの増減に応じてアプリケーションを動的にスケーリングできます。プロビジョニングされたサーバーでは、フリートを手動でスケールアップまたはスケールダウンする必要があります。
年中無休のワークロードを伴う一部の複雑なアプリケーションでは、完全な制御のためにプロビジョニングされたインフラストラクチャが依然として必要な場合があります。ただし、サーバーレスは、ほとんどのイベント駆動型、断続的、または予測不可能なワークロードに適しています。

AWSサービスとツール(DataBrew、QuickSight、Glue など)を使⽤したデータの視覚化

Glue DataBrew：分析用にデータをクリーンアップ、正規化、変換するのに役立つ視覚的なデータ準備ツール。コードを記述することなく、対話型のプロファイリング、探索、高度な変換を提供します。
NEST_TO_MAP変換は、ユーザーが選択した列を、列名を表すキーと行の値を表す値を含むキーと値のペアに変換します。
例）

    "RecipeAction": {
        "Operation": "NEST_TO_MAP",
        "Parameters": {
            "sourceColumns": "[\"age\",\"weight_kg\",\"height_cm\"]",
            "targetColumn": "columnName",
            "removeSourceColumns": "true"
        }
    }

QuickSight：大規模なインタラクティブなデータ視覚化のためのフルマネージド型ビジネスインテリジェンスサービス。ユーザーはさまざまなデータソースに接続し、ダッシュボードやレポートを構築して洞察を得ることができます。

データの検証とクリーニング (Lambda、Athena、QuickSight、Jupyter Notebooks、SageMaker Data Wranglerなど)

15分未満の小規模なワークロードの場合は、Lambdaを使用して軽量のデータの準備とクリーニングを行います。Lambdaは小規模なジョブではコスト効率が高くなります。
Athenaは、S3などのオブジェクトストレージ内のデータに対するインタラクティブなクエリに使用でき、スキーマの検証や異常の検出に役立ちます。
SageMaker Data Wranglerは、機械学習用のデータの選択、クレンジング、探索、変換を支援するビジュアルインターフェイスを提供します。
高度に安全なデータの場合は、AWSに移行する前に、Outpostsを使用してクレンジングと変換をオンプレミスで直接実行します。

Apache Sparkを使用するAthenaノートブックを使用してデータを探索する

Apache SparkでAthenaノートブックを使用すると、Athenaコンソールから直接Spark SQLおよびSpark DataFrame APIを使用してデータを探索および分析できます。S3、GlueデータカタログなどのさまざまなAWSデータソースのデータに、個別にロードすることなくアクセスできます。
Glueを使ってデータソースからデータを取り込み、Apache Sparkベースのデータ処理パイプラインでデータを加工・変換した上で、処理済みのデータをS3に出力する

3.3: データパイプラインを維持および監視

パフォーマンスの問題のトラブルシューティング

S3に保存されているGlueジョブログを分析して、スクリプトエラーやデータの不整合を正確に特定する可能性のあるエラーメッセージや警告を見つける。
CloudWatchでGlueジョブ実行メトリクスを検査し、データ処理時間の増加のパターンやディスクへの過剰なデータの流出のインスタンスがないか確認する。
ETLスクリプトをリファクタリングして、シャッフル操作を最小限に抑え、データパーティショニング戦略を強化し、特定されたオーバーヘッドに対処する。
コードに非効率な変換、不必要な結合、フィルターがないか確認する。
Athenaパーティション射影を使用することで、パーティション管理を自動化できます。Athenaがクエリ実行時にS3オブジェクトを効率的にグループ化できるようになります。

TBLPROPERTIES (
  'projection.enabled'='true',
  'projection.partition_date.type' = 'date',
  'projection.partition_date.range' = '2020/10/01,NOW',
  'projection.partition_date.format' = 'yyyy/MM/dd/HH',
  'projection.partition_date.interval' = '1',
  'projection.partition_date.interval.unit' = 'HOURS',
  'storage.location.template' = 's3://<S3バケットのパス>/${partition_date}'
)

STL_ALERT_EVENT_LOG は、クエリまたはユーザー定義のパフォーマンスしきい値に関連するアラート/通知を記録します。

AWSサービスを使用したログの分析(Athena、EMR、OpenSearch Service、CloudWatch Logs Insights、ビッグデータアプリケーションログなど)

CloudWatch Logs Insights - CloudWatch Logsに保存されているログデータを対話的に検索および分析します。クエリを実行して、運用上の問題に対応できます。
OpenSearch Service - 一元化されたログソリューションを使用して、EC2 インスタンス、EKSクラスター、S3、syslogなどのさまざまなソースからログをOpenSearchに取り込みます。次に、SQLのようなクエリを使用してログを分析します。
EMR - Hadoop/Sparkを使用して、S3に保存されている大量のログデータを処理します。ログデータに対してMapReduceジョブまたはSparkアプリケーションを実行することで、洞察を抽出できます。大規模なETLはEMR、小規模はGlue
EMRクラスターにおけるHiveメタストアのシームレスな移行を実現する。 Hiveメタストア：Hiveで使用されるデータベースの構造、テーブル、パーティションなどのメタデータを格納する場所

3.4: データ品質の確保

データサンプリング⼿法

ランダムサンプリング - より大きなデータセットからデータポイントのサブセットをランダムに選択します。これにより、データ全体が公平に表現されます。
層化（stratified）サンプリング - 母集団を同種のグループまたは層に分割し、各層から比例してサンプルをランダムに選択します。これにより、重要なサブグループが確実に表現されます。
体系的（systematic）サンプリング - データセットから一定の間隔でデータポイントを選択します。
クラスターサンプリング - 母集団からクラスターをランダムに選択し、選択したクラスター全体からデータを収集します。
多段階サンプリング - サンプリングが複数の段階で行われる層別設計。たとえば、都市をランダムに選択し、次に都市内の近隣地域を選択し、次に近隣地域内の世帯を選択します。

データスキューメカニズムを実装する⽅法

Glue Data Qualityを使用して、データ内の異常や異常なパターンを自動的に検出します。機械学習アルゴリズムを使用して、時間の経過とともにパターンを学習します。
Glue Studio内で、データ品質チェック変換を適用して、データパイプライン全体のデータ品質を評価します。これにより、ソース間でデータが移動する際のスキューを監視できます。
スキューが検出された場合にパイプラインを停止できるデータ品質ルールを定義し、不良データがデータレイクに取り込まれるのを防ぎます。
Glue ETLを使用すると、検出されたデータ品質の問題やスキューを簡単に修復し、クリーンなデータをデータレイクに取り込むことができます。
CloudWatchを使用してデータ品質のメトリクスとスコアを監視します。

データ検証(データの完全性、⼀貫性、正確性、完全性)
データの⼀貫性の調査(Glue DataBrewなど)
DataBrewの組み込みデータプロファイリング機能を使用して、欠落データや一貫性のないデータなどのデータ品質の問題を自動的に分析および特定します。

ドメイン 4: データセキュリティとガバナンス

4.1: 認証メカニズム

IAMグループ、ロール、エンドポイント、サービスの作成と更新
ユーザーロールごとにIAMグループを作成し、必要な権限をこれらのグループに付与します。（最小権限の原則）

4.2: 承認メカニズムの適⽤

Lake Formationによるアクセス許可の管理(Redshift、EMR、Athena、およびS3の場合)

データにアクセスするユーザーとアプリケーションに対して、データベース、テーブル、列、セルレベルでセキュリティポリシーベースのルールを定義し、データガバナンスとアクセス制御を実現します。
Lake Formationを使用すると、S3でのデータアクセスのアクセス許可を管理できます。S3ロケーションをLake Formationに登録する場合、そのロケーションに対する既存の権限を確認することを選択できます。これにより、Lake Formationユーザーがアクセスしたときに既存のデータが安全に保たれるようになります。
Redshift - Lake Formationは各データ共有を対応するGlueデータカタログデータベースにマッピングします。その後、これらのフェデレーションデータベースを共有し、Lake Formation権限を使用してアクセスを制御できます。
EMR - Lake Formation統合により、Glueデータカタログオブジェクトにアクセスするための認可ポリシーを定義できます。これにより、インタラクティブなEMRジョブにポリシーが適用され、監査イベントがCloudTrailに送信されます。

データベースユーザー、グループ、ロールにデータベースへのアクセスと権限を付与する(Redshiftなど)

データベースロールを作成し、システムレベルとオブジェクトレベルの権限を各ロールに割り当てます。
ロールを使用すると、GRANTおよびREVOKE権限を通じて、データベース、スキーマ、テーブル、列レベルでのきめ細かいアクセス制御が可能になります。個々のユーザーまたはグループがアクセスできるデータとアクションを制御できます。
行レベルのセキュリティポリシーでは、さまざまなロールの行レベルでデータアクセスをさらにフィルタリングできます。

アプリケーションとデータベースの認証情報の保存(例: Secrets Manager、Systems Manager Parameter Store)

Secrets Managerはシークレット管理用に特別に設計されており、データベースパスワードの自動ローテーションのサポートが組み込まれています。
パラメーターストアはシークレットの保存にも使用できますが、自動ローテーションはサポートされていません。ただし、Secrets Managerに保存されているシークレットを参照できるため、ローテーションはSecrets Managerによって処理されます。
Secrets Managerに保存されているシークレットは、複数のリージョン、アカウント、サービスにわたって簡単に参照できますが、パラメーターストアのシークレットは単一リージョンのみに限定されます。
データベース資格情報や自動ローテーションが必要なその他のシークレットにはSecrets Managerを、非シークレット構成データや自動ローテーションを必要としないシークレットにはパラメータストアを使用します。

4.3: データの暗号化とマスキング

AWS分析サービスで利用可能なデータ暗号化オプション(Redshift、EMR、Glueなど)

Redshiftは、KMSキーを使用した静置中の暗号化をサポートしています。クラスター内のデータと自動または手動のスナップショットの両方を暗号化できます。
EMRは、EBSボリュームを暗号化して使用することができます。EMRクラスターを起動する際にEBSボリュームの暗号化を有効にできます。
Glueデータが格納されているS3バケットを暗号化することができます。これにはサーバーサイド暗号化（SSE）を使用し、SSE-S3、SSE-KMS、またはSSE-C（ユーザー提供のキー）を選択できます。
QuickSightは、データソースのデータの静置中の暗号化にKMSを使用します。データはS3に格納されている場合、S3サーバーサイド暗号化を使用できます。

クライアント側の暗号化とサーバー側の暗号化の違い

SSE-KMSによるサーバー側暗号化を使用することにより、AWS管理キーを使用して保存データが暗号化されます。
S3暗号化クライアントなどのクライアント側の暗号化ライブラリを活用することにより、顧客が提供したキーを使用してアップロードする前にデータが暗号化されます。

AWSアカウントの境界を越えた暗号化の構成

暗号化にはAWS管理キーの代わりにカスタマー管理キー(CMK)を使用します。CMKはアカウント間で共有できますが、AWS管理キーは共有できません。
AWS Backupを使用したクロスアカウントバックアップをサポートするサービスでは、カスタマー管理キーとAWS管理キーの両方を使用できます。
EC2ボリュームなど、AWS Backupでクロスアカウントバックアップをサポートしていないサービスの場合は、AWS管理キーがサポートされていないため、CMKを使用する必要があります。

データの匿名化、マスキング、キーソルティング

Glueは、データを変換するときにマスキングや変換を適用することができます。これにより、データの一部を匿名化したり、個人情報をマスキングしたりできます。
Redshiftは、データを格納およびクエリする際にマスキングや変換を行うことができます。ビューを使用して必要なデータのみを公開し、機微な情報を保護することができます。

暗号化キーを使用してデータを暗号化または復号(例: AWS KMS)
KMS暗号化キーを使用してRDSインスタンスと関連するすべてのスナップショット、バックアップ、レプリカを暗号化できます。

4.4: 監査⽤のログを準備

CloudTrail Lakeを使用した一元的なロギングクエリ

CloudTrail Lakeを使用すると、AWS環境全体でCloudTrailによって記録されたすべてのアクションを1か所でクエリすることで、インシデント調査が簡素化されます。
CloudTrail Lakeは、構造化されたログデータの最適化された処理により、ログを分析するためのほぼリアルタイムのクエリ機能を提供し、インシデント対応に役立ちます。
一元化されたアクセスログにより、組織のAWSリソース全体のログ管理、コンプライアンスレポート、監査が1つのシステムで可能になります。

4.5: データのプライバシーとガバナンスの理解

許可されていないリージョンへのデータのバックアップやレプリケーションを防ぐデータプライバシー戦略の実装

IAMポリシーを使用して、aws:RequestedRegion条件キーを使用して、許可されたリージョン外のアクションやサービスへのアクセスを拒否します。
AWS Organizations - SCPを作成して、リージョンに基づいて特定のAWSサービスまたはリソースへのアクセスを制限します。
AWS Control Towerの「リージョン拒否」を実装する組織単位レベルでガードレールを設定し、特定のIAMプリンシパルおよびサービスに対して選択されたリージョンへのアクセスを拒否します。
RDS - DBインスタンス作成時に、create-db-instance コマンドの --availability-zone パラメータを使用して、許可されたリージョン内のAZを指定します。これにより、バックアップとレプリカも同じリージョン内に作成されるようになります。
DynamoDB - CreateTable APIのRegionalパラメータを使用して、許可されたリージョンにのみテーブルを作成します。

データ共有のアクセス許可の付与(Redshiftのデータ共有など)
Redshiftでのデータ共有に関しては、通常、IAMとRedshift固有の権限を使用してアクセス許可を管理します。Redshiftでのデータ共有は、多くの場合、クロスアカウントアクセスを使用して、または同じAWSアカウント内で異なるRedshiftクラスター内で行われます。

PII識別の実装(例: Lake Formation)

検出された機密データは、さらなる分析とガバナンスのためにLake Formationデータレイクに取り込まれます。Lake Formationは、この機密データの安全を確保するために、行レベルのセキュリティ、監査、アクセス制御などの機能を提供します。
Glueクローラー、DataBrew、Athenaなどのツールを使用すると、Lake Formationデータレイク内のデータをさらに分析し、データ品質を目的として重複または一致するPIIレコードを特定できます。
S3オブジェクトLambda関数内に編集ロジックを実装して、データにアクセスする各アプリケーションのニーズに基づいてPIIを動的に編集します。

組み込みのLambda関数を編集関数として使用し、S3 Object Lambdaアクセスポイントにアタッチします。
アプリケーション(Analyticsアプリケーションなど)が標準S3 GETリクエストを送信する場合、S3 Object Lambdaアクセスポイントを介して行われたこれらのリクエストは、事前作成された編集用Lambda関数を呼び出し、サポートしているS3アクセスポイントを介してS3バケットから取得したPIIデータを検出して修正します。
S3 Object Lambdaアクセスポイントは、編集された結果をアプリケーションに返します。