DEA-#16

データフィルターの管理

「行レベルのフィルター」を使用することで、国がカナダの行へのユーザーアクセスを防止できるため正解です。

具体的には、「AWS Lake Formation」の 行レベルのフィルター を設定することで、条件に基づいてデータへのアクセスを制限できます。この場合、カナダのお客様のデータ行をフィルターし、それに基づいてユーザーのアクセスを防止します。AWS Lake Formation はこの機能を提供しており、特定の行に対するアクセス制御が可能です。

※データフィルターの管理
列レベル、行レベル、およびセルレベルのセキュリティを実装するには、データフィルターを作成して維持することができます。各データフィルターは、Data Catalog テーブルに属します。テーブル用に複数のデータフィルターを作成してから、そのテーブルに対する許可を付与するときに 1 つ、または複数のデータフィルターを使用できます。また、struct データ型を持つネストされた列にデータフィルターを定義して適用し、ネストされた列のサブ構造のみへのアクセスをユーザーに許可することもできます。
参考URL : データフィルターの管理

※行レベルと列レベル

フィルターの種類	定義	範囲	使用例	一般的な使用方法
行レベルフィルター	特定の条件を満たす行に基づいてフィルタリングを行います (例 : 国がカナダである行へのアクセス制限) 。	属性や条件に基づいて、テーブル内の個々の行へのアクセスを制御します。	顧客の国が「カナダ」である行へのアクセスを拒否する。	ユーザーやグループの権限に基づいて、特定のレコードへのアクセスを制御する必要がある場合に使用します。
列レベルフィルター	特定の列に基づいてフィルタリングを行い、特定のデータフィールドへのアクセスを許可または拒否します (例 : SSN のような機密列を非表示にする) 。	テーブルの特定の列へのアクセスを制御し、行に関係なく列を管理します。	SSN 列を非表示にして機密情報を保護し、他の列にはアクセスを許可する。	プライバシーや法規制の理由で特定のフィールドを非表示にするが、他のデータにはアクセスを許可する場合に使用します。

■以下は間違いです。
・国がカナダであるすべての行にタグを適用します。タグが「カナダ」に等しいユーザーアクセスを防止します。
→「タグ」はデータに対するアクセス制御を直接提供するものではないため間違いです。

具体的には、AWS リソースタグ は、リソースの管理や分類に使用されるものであり、タグそのものがデータへのアクセスを制御する機能を持っていません。データのアクセス制御には、AWS Lake Formation のようなサービスの「行レベルのフィルター」や「列レベルのフィルター」が必要です。タグ付けのみでデータのアクセスを制限することはできません。

・列レベルのフィルターを設定して、国がカナダである行へのユーザアクセスを禁止します。
→「列レベルのフィルター」は、データの列単位でのアクセス制御に使うため、行単位での制御には不適切なため間違いです。

具体的には、「AWS Lake Formation」の 列レベルのフィルター は、データの特定の列に対するアクセスを制御する機能です。今回の要件は特定の行 (カナダの行) へのアクセス制限なので、列レベルの制御では条件を満たすことができません。行単位のアクセス制御には、「行レベルのフィルター」が必要です。

・国名がカナダである住所へのユーザーアクセスを制限する IAM ロールを作成します。
→「IAM ロール」は、行単位でデータアクセスを制御する機能を提供しないため間違いです。

具体的には、IAM ロール は、ユーザーやグループに対してリソース全体のアクセス権限を付与または制限するものです。「AWS Lake Formation」が提供する「行レベルのフィルター」のような細かな行単位でのアクセス制御はできません。

AWS Lake Formation FindMatches

「AWS Lake Formation FindMatches」変換を使用することで、「一意の識別子がなくても」一致するレコードを識別できるため正解です。

具体的には、AWS Lake Formation FindMatches 変換は、機械学習アルゴリズムを利用して、「一意の識別子がない」場合でも類似レコードを自動的に照合します。FindMatches は、重複データやレコードの照合を容易にするために、データクレンジングやデータ統合の一環として使用されます。ユーザーは、FindMatches 変換をトレーニングすることで、手動で一部のデータの一致パターンを定義し、それをもとに他のレコードを照合させることが可能です。これにより、同社は重複レコードの統合や、クレンジングされたデータを Amazon S3 のデータレイクに保存し、Amazon Athena で効率的にクエリを実行できます。

※AWS Glue で、データセット内の一致するレコードの重複排除および検索を行う FindMatches ML 変換の提供を開始
一致するレコードを特定するカスタム機械学習変換である、新しい FindMatches ML 変換を使用して、AWS Glue でデータセット (識別子のないものを含む) 全体から、一致するレコードを検索できるようになりました。FindMatches 変換を Glue ETL ジョブに追加することにより、関連する製品、場所、サプライヤー、お客様などを見つけることができます。

FindMatches 変換を Glue ETL ジョブに追加することで重複排除します。

画像引用 :Glue の概念図
参考URL : AWS Glue で、データセット内の一致するレコードの重複排除および検索を行う FindMatches ML 変換の提供を開始

■以下は間違いです。
・テーブルをパーティショニングし、ETL ジョブで一意の識別子でデータをパーティショニングします。
→「テーブルのパーティショニング」は、データクエリの効率を上げるために使用されますが、「一意の識別子がない場合」のレコード一致には役立たないため間違いです。

具体的には、テーブルのパーティショニング は、データを物理的に分割してクエリのパフォーマンスを最適化する手法です。しかし、これはデータの物理的な整理に過ぎず、異なるレコード間の類似性を分析したり、「重複データや識別子なしのレコードの一致を自動的に検出する」能力を持っていません。パーティショニングはクエリを高速化しますが、データ照合のためのロジックは含まれていません。

・ETL ジョブで AWS Glue PySpark Filter クラスをトレーニングして使用します。
→「AWS Glue PySpark Filter クラス」は、特定の条件に基づいてデータをフィルタリングするためのツールであり、「一意の識別子がない」場合のレコード照合には使用できないため間違いです。

具体的には、AWS Glue PySpark Filter クラス は、データセット内の行を条件に基づいて選別するための機能であり、複数のレコードを機械学習を使って類似性を比較するような高度な照合アルゴリズムを持っていません。フィルタリングは、既知の基準に基づいて特定のデータを抽出する操作に適しており、「データ間の類似性や重複を検出する」役割を果たすものではありません。
「AWS Glue PySpark Filter クラス」は、Apache Spark フレームワークの DataFrame API の一部であり、filter 関数はデータフレームに対して特定の条件式を指定し、その条件を満たす行だけを抽出します。例えば、特定の値を持つ列を基準にデータを選別するために使用されます。しかし、これは単純な条件式によるデータ選別であり、複数のレコードの一致や類似性を判断する機能ではなく、高度なパターンマッチングや重複検出に適していません。

・ETL ジョブの一部として Amazon Macie のパターンマッチングを使用します。
→「Amazon Macie」はパターンマッチングのためのサービスですが、これは機密データの検出と分類を主目的としており、「一意の識別子がなくても一致するレコードを識別」する機能はないため間違いです。

具体的には、Amazon Macie は、データプライバシーとセキュリティに重点を置いており、「機密データの自動検出やデータ分類」に特化しています。そのため、レコード同士の照合やデータの類似性を判断する機能を提供しておらず、重複データや一意の識別子のないレコードの一致を検出する用途には適していません。この機能はデータ分類やセキュリティ分析には役立つものの、レコード照合のためのツールではありません。

CloudTrail イベント

「AWS CloudTrail」でデータイベントの証跡を作成し、トランザクション S3 バケットからのデータをログ S3 バケットに自動的に記録するため正解です。

具体的には、AWS CloudTrail は、データイベント を追跡できる機能を提供しており、これにより S3 バケットのオブジェクトレベルでの操作 (例 :PUT、POST、DELETE など) の記録が可能です。この機能は 管理イベント とは異なり、バケット内の具体的なファイルやデータの変更そのものを記録することができます。証跡は、特定の S3 バケットを対象とし、すべての書き込みイベントを自動的にキャプチャしてログ用 S3 バケットに保存します。

この設定は、イベント駆動のアーキテクチャや他の手動のイベント処理を必要とせず、最小限の運用労力でシステムの要件を満たし、信頼性の高いソリューションを提供します。CloudTrail の証跡は継続的に監視・記録されるため、手間が少なく、効率的なログ管理が可能です。

※AWS CloudTrail イベント比較

イベントタイプ	追跡対象	デフォルトの状態	用途
管理イベント	AWS リソースの作成、削除、設定変更 (例 :IAM ユーザーの作成、EC2 インスタンスの起動)	有効 (デフォルトでオン)	AWS アカウント全体の管理操作を追跡し、リソースの変更や管理を監視。
データイベント	S3 オブジェクトや Lambda 関数のオブジェクトレベルの操作 (例 :PUT、POST、DELETE)	無効 (手動で有効化が必要)	詳細な操作履歴を取得するため。主に監査、セキュリティ、法的要件のために使用。
インサイトイベント	異常な API 使用のパターンを追跡し、潜在的なセキュリティインシデントを検出	有効 (CloudTrail Insights を有効化する必要あり)	異常な活動を検知し、セキュリティやオペレーショナルな問題を迅速に発見。

参考URL : CloudTrail イベントについて

■以下は間違いです。
・トランザクション S3 バケット上のすべてのアクティビティに対して、AWS Lambda 関数を呼び出す S3 イベント通知ルールを設定します。イベントをログ S3 バケットに書き込むように Lambda 関数をプログラムします。
→「AWS Lambda」 と 「S3 イベント通知」 を利用するソリューションは、冗長な実装を含むため間違いです。

具体的には、S3 イベント通知 をトリガーとして AWS Lambda 関数を使い、トランザクションの変更をログ用 S3 バケットに書き込むという構成は、ログ記録のために追加の Lambda 関数を設定し管理する必要があります。この方法はイベント駆動で適切に動作しますが、「CloudTrail のデータイベント」を用いる方が効率的で、運用労力が少なく済むため、Lambda の設定は冗長であり不要です。

・AWS CloudTrail で管理イベントの証跡を作成します。トランザクション S3 バケットからデータを受信するように証跡を設定します。空のプレフィックスと書き込み専用イベントを指定します。宛先バケットとして ログ S3 バケットを指定します。
→「AWS CloudTrail の 管理イベント」を使用することは、S3 バケットのデータ変更を追跡できないため間違いです。

具体的には、CloudTrail の 管理イベント は S3 バケット に対する API 呼び出しを追跡できますが、ファイルの変更や書き込みといった「データイベント」は対象外です。そのため、バケット内の個々のファイルやオブジェクトの操作履歴を残すことができません。この選択肢ではトランザクションデータの完全なログが取得できないため、要件を満たしていません。

・トランザクション S3 バケット上のすべてのアクティビティに対して、AWS Lambda 関数を呼び出す S3 イベント通知ルールを設定します。Amazon Kinesis Data Firehose にイベントを書き込むように Lambda 関数をプログラムします。ログ S3 バケットにイベントを書き込むように Kinesis Data Firehose を設定します。
→「AWS Lambda」 と 「Amazon Kinesis Data Firehose」 を用いるソリューションは、不要な複雑さを追加するため間違いです。

具体的には、トランザクション S3 バケットの書き込みイベントをトリガーとして AWS Lambda を使用し、さらに Amazon Kinesis Data Firehose を設定する構成は、要件である S3 間のログの記録に対して過剰です。この方法では「CloudTrail」を使うよりも複雑な処理と運用コストが発生し、バケット間でのデータ転送だけでなく、イベント通知や変換が不要なため、最小限の運用労力という条件を満たしていません。

機密データを検出して処理する

「AWS Glue Studio の Detect PII 変換」 と 「AWS Step Functions」 により、PII 検出と難読化が自動化され、データパイプラインが効率的に構築されるため正解です。

具体的には、AWS Glue Studio の Detect PII 変換 は、データセット内の PII を自動的に検出し、規定に基づいて難読化する機能です。この変換は、視覚的に構築できるため、コードなしで実行可能です。さらに、AWS Step Functions によりデータ処理のフロー全体が自動化され、各ステップを簡単にオーケストレーションでき、結果としてデータを Amazon S3 に安全に取り込みます。

※機密データを検出して処理する
Detect PII 変換は、データ ソース内の個人識別情報 (PII) を識別します。識別する PII エンティティ、データのスキャン方法、および Detect PII 変換によって識別された PII エンティティの処理方法を選択します。
参考URL : 機密データを検出して処理する

(引用) ※AWS Glue Studio で PII データを SHA-256 でハッシュ化してみた
以下のように Glue Studio から Glue Job を作成して、ある S3 にある個人情報を含むデータを読み込み、別の S3 に該当の情報を SHA-256 でハッシュ化して出力できます。

文章・画像引用 : AWS Glue Studio で PII データを SHA-256 でハッシュ化してみた

■以下は間違いです。
・データセットを Amazon DynamoDB に取り込みます。AWS Lambda 関数を作成して、DynamoDB テーブル内の PII を識別して難読化し、データを変換します。同じ Lambda 関数を使用して、データを S3 データレイクに取り込みます。
→「Amazon DynamoDB」 と 「AWS Lambda」 を使ったデータ処理では、複数のサービス間でデータを移動させる必要があり、コストと運用が複雑になるため間違いです。

具体的には、Amazon DynamoDB にデータを一時的に保存し、AWS Lambda で PII を識別・難読化した後、Amazon S3 にデータを移行する手法は、サービス間のデータ移動により処理が複雑になり、運用コストが増加します。このため、効率が悪くなり、運用労力が増えます。

・AWS Glue Studio の Detect PII 変換を使用して PII を識別します。AWS Glue Data Quality でルールを作成して、PII を難読化します。AWS Step Functions ステートマシンを使用して、データパイプラインを調整し、データを S3 データレイクに取り込みます。
→「AWS Glue Data Quality」 はデータ品質検証に特化しているため、PII の難読化には最適ではないため間違いです。

具体的には、AWS Glue Data Quality は主にデータの品質検証や検証ルールの設定に使用され、PII の難読化のために特化した機能は提供していません。これにより、PII の処理を行う際に設定の複雑さが増し、運用負荷が高まります。

・Amazon Kinesis Data Firehose 配信ストリームを使用してデータセットを処理します。AWS Lambda 変換関数を作成して、PII を識別します。AWS SDK を使用して PII を難読化します。S3 データレイクを配信ストリームのターゲットとして設定します。
→「Amazon Kinesis Data Firehose」 と 「AWS Lambda」 では、リアルタイム処理が適しているが、PII 検出と難読化のプロセスが複雑になり、管理が難しいため間違いです。

具体的には、Amazon Kinesis Data Firehose はリアルタイムデータストリーミングに優れているが、AWS Lambda を用いた PII の識別と難読化は、特に大量データの場合、Lambda のタイムアウト制限やスケーリングの制約が問題となる可能性があります。また、SDK を使った手動処理は運用労力が増します。

AWS Glue での Python シェルジョブの概要

「小規模なデータ処理に適したコスト効率の高い方法」であり、100 MB 未満のデータ処理に最適なため正解です。

具体的には、AWS Glue Python シェルジョブ を使用し、pandas でデータを変換する方法は、メモリ内でのデータ処理に特化しており、100 MB 未満のデータサイズでは高速で効率的に処理が可能です。AWS Glue Python シェルジョブ は、シンプルなスクリプトベースで動作し、処理が小規模である場合には、フルマネージドサービスとしての利便性を生かしつつ低コストで運用できます。pandas は、軽量で直感的なデータ操作ライブラリとして、少量データの変換に特化しています。
たとえば、pandas を用いて 100 MB 未満のデータセットを扱う場合、Spark のような分散処理フレームワークを利用するオーバーヘッドは発生せず、より少ない計算リソースでデータを処理できるため、運用コストを削減できます。Spark を用いた場合、クラスタの管理やスケーリングに対して追加のコストがかかるため、pandas の方がはるかにコスト効率が高くなります。

※AWS Glue での Python シェルジョブの概要
AWS Glue で Python スクリプトを使用して、しばしば ETL (抽出、変換、読み込み) ワークフローの一部となる、中小規模 の一般的なタスクを実行できるようになりました。以前の AWS Glue ジョブは、サーバーレスの Apache Spark 環境で実行されるジョブに限定されていました。Amazon Redshift、Amazon Athena、Amazon EMR などのサービスに SQL クエリを送信したり、機械学習および化学分析を実行するなどの Python シェルジョブを使用できるようになりました。
参考URL : AWS Glue での Python シェルジョブの概要
参考URL : AWS Glue での Python シェルジョブ - AWS Glue

■以下は間違いです。
・AWS Glue PySpark ジョブを作成します。Apache Spark を使用してデータを変換します。
→「Apache Spark」 を使用して大規模なデータセットを処理するため、現在のデータ量では必要以上にリソースを使用するため間違いです。

具体的には、AWS Glue PySpark ジョブ は Apache Spark を利用して分散処理を行いますが、100 MB 未満のデータを処理するにはオーバースペックです。Spark は分散処理のための追加のリソースを使用するため、小規模なデータ処理にはコストがかかりすぎます。これにより、効率的とは言えない選択となります。

・PySpark の ETL スクリプトを作成します。Amazon EMR クラスターでスクリプトをホストします。
→「Amazon EMR」 クラスタでホストするため、大規模データセットには適しているものの、小規模なデータにはオーバースペックでコストが高いため間違いです。

具体的には、Amazon EMR は大規模なデータ処理に向いていますが、100 MB 未満のデータを処理する場合は、設定や運用に無駄なリソースが必要です。EMR クラスタの立ち上げやスケーリングのコストが発生し、小規模データ処理ではこのオーバーヘッドが不必要な負担となります。

・カスタム Python アプリケーションを作成します。Amazon Elastic Kubernetes Service (Amazon EKS) クラスターでアプリケーションをホストします。
→「Amazon Elastic Kubernetes Service (Amazon EKS)」 を使用してカスタム Python アプリケーションをホストするため、クラスタ管理やスケーリングに関する運用コストが高くなるため間違いです。

具体的には、Amazon EKS を使用してアプリケーションをホストすると、クラスタの設定や運用、スケーリングの手間が増えます。フルマネージドなサービスに比べて運用負荷が高く、特に小規模なデータ処理には不必要なオーバーヘッドが発生します。これにより、運用コストも増加し、選択肢として適切ではありません。

ジョブデータの再処理

job.commit () が含まれていないため正解です。

具体的には、AWS Glue ジョブがブックマーク機能を正しく利用するためには、ジョブの最後に job.commit () を記述する必要があります。このステートメントが欠如していると、以前に処理されたデータが再度処理されることがあります。job.commit () によって、AWS Glue はどのデータがすでに処理されたかを記録し、次回の実行時に重複処理を防ぎます。

※(要約) エラー : ジョブのブックマークが有効なときにジョブがデータを再処理しています
このページでは、AWS Glue ジョブが以前に処理したデータを再度処理してしまう場合、原因として job.commit () の欠如があると説明しています。このステートメントは、ジョブが処理済みデータを追跡し、次回の実行で重複処理を防ぐために必要です。もし job.commit () がスクリプトに含まれていないと、ブックマーク機能が正しく動作しないため、データの再処理が発生します。
参考URL : エラー : ジョブのブックマークが有効なときにジョブがデータを再処理しています

■以下は間違いです。
・データエンジニアが、Glue ジョブに古いバージョンの AWS Glue を誤って指定しました。
→「AWS Glue のバージョン」は、ブックマーク機能の再処理問題に直接影響を与えないため間違いです。

具体的には、「AWS Glue のブックマーク機能」は、バージョン に依存せずに動作します。AWS Glue バージョン 2 以降では、ジョブの起動が高速化され、メモリ管理やパフォーマンスに改善が加えられましたが、ブックマーク機能自体はこれらのバージョン変更の影響を受けません。そのため、古いバージョンの AWS Glue を使用していても、再処理の問題はブックマークの設定不備が原因であり、バージョン自体が直接の要因ではありません。

・AWS Glue ジョブの最大同時実行数が 1 に設定されています。
→「最大同時実行数の設定」は、ブックマーク機能の動作には影響しないため間違いです。

具体的には、「AWS Glue のブックマーク機能」は、処理済みデータの追跡を管理し、次回実行時に重複処理を防ぎます。最大同時実行数 は、AWS Glue ジョブが同時に処理できるタスクの数を決定しますが、ジョブの並列処理に関係するものであり、ブックマーク機能には影響を与えません。最大同時実行数が 1 であっても、ブックマーク機能が正しく設定されていれば、データの重複処理を回避することができます。

・AWS Glue ジョブに、ブックマークが正しく機能するために必要な s3:GetObjectAcl 権限がありません。
→s3:GetObjectAcl 権限は、ブックマーク機能には不要なため間違いです。

具体的には、「AWS Glue のブックマーク機能」は、処理済みデータを追跡するために s3:GetObject 権限を必要とします。この権限がない場合、AWS Glue は Amazon S3 バケット内のオブジェクトにアクセスできず、ファイルのメタデータを取得できないため、どのファイルが処理済みか判断できません。一方で、s3:GetObjectAcl 権限は不要です。s3:GetObjectAcl はオブジェクトのアクセス制御リスト (ACL) を取得するためのものであり、ジョブの重複処理防止とは関係がありません。

Amazon Managed Service for Apache Flink を使用してコンシューマーを開発する

「Amazon Managed Service for Apache Flink」 と 「Amazon Kinesis Data Firehose」 の組み合わせを使用し、5 秒のバッファ間隔でデータを低レイテンシーで Amazon S3 バケットに配信できるため正解です。

具体的には、Amazon Managed Service for Apache Flink は、リアルタイムのストリーミングデータ処理に特化したフルマネージドサービスです。センサーからのデータは、Apache Flink を使ってリアルタイムで複雑な処理を施し、その後、Amazon Kinesis Data Firehose を使用して Amazon S3 に配信されます。このサービスの強力な点は、スケーラブルなデータ処理を自動的に行い、特定のビジネスロジックに従ってデータを迅速に処理できることです。

また、Amazon Kinesis Data Firehose は、処理されたデータを最小 1 秒のバッファ間隔で直接 Amazon S3 に配信可能です。この組み合わせにより、複雑なデータ処理が行われ、かつ短い間隔でデータが迅速に保存されるため、低レイテンシーでのデータ配信が実現します。

※Amazon Managed Service for Apache Flink を使用してコンシューマーを開発する
Amazon Managed Service for Apache Flink アプリケーションを使用して、、JavaSQL、または Scala を使用して Kinesis ストリーム内のデータを処理および分析できます。Managed Service for Apache Flink アプリケーションは、リファレンスソースを使用したデータの強化、データの経時的な集約、または機械学習を使用したデータ異常の検出を行うことができます。その後、分析結果を別の Kinesis ストリーム、Firehose 配信ストリーム、または Lambda 関数に書き込むことができます。
参考URL : Amazon Managed Service for Apache Flink を使用してコンシューマーを開発する

※BufferingHints
有効範囲 : 最小値は 0、最大値は 900
受信データを宛先に配信する前に、指定された時間 (秒単位) バッファリングします。デフォルト値は 300 です。
参考URL : BufferingHints

■以下は間違いです。
・Amazon Kinesis Data Streams を使用して、Kinesis Client Library を呼び出し、データを S3 バケットに配信します。アプリケーションから 5 秒のバッファ間隔を使用します。
→「Kinesis Client Library」 を使用しても Amazon Kinesis Data Streams のデータを直接 Amazon S3 に保存することはできないため間違いです。

具体的には、Kinesis Client Library (KCL) は Amazon Kinesis Data Streams からデータを取得するライブラリですが、データを Amazon S3 に保存するためには、別途アプリケーション内で保存ロジックを実装する必要があります。したがって、「Kinesis Client Library を呼び出し、データを S3 バケットに配信します」という記述は正しくありません。

・Amazon Kinesis Data Streams を使用して、S3 バケットにデータを配信します。プロビジョニングされた 5 つのシャードを使用するようにストリームを設定します。
→「Amazon Kinesis Data Streams」 はデータを直接 Amazon S3 に保存する機能がないため間違いです。

具体的には、Amazon Kinesis Data Streams は、データをリアルタイムで処理およびストリーミングするためのサービスですが、データを直接 Amazon S3 に保存する機能がありません。データを Amazon S3 に保存するためには、「Amazon Kinesis Data Firehose」 のような追加のサービスを利用する必要があります。この選択肢ではそれが記載されていないため、要件に合致しません。

・Amazon Kinesis Data Streams と Amazon Kinesis Data Firehose を使用して、データを S3 バケットに配信します。Kinesis Data Firehose のデフォルトのバッファ間隔を使用します。
→「Amazon Kinesis Data Firehose のデフォルトのバッファ間隔は 300 秒」であるため、最も少ないレイテンシーでのデータ配信ができないため間違いです。

具体的には、Amazon Kinesis Data Firehose のデフォルトバッファ間隔が 300 秒 で設定されており、これはセンサーが 10 秒ごとにデータを送信する状況ではレイテンシーが高すぎます。したがって、指定されたレイテンシー要件に対応できず、Amazon S3 へのデータ配信に時間がかかりすぎます。