Amazon Data Firehose に関するよくある質問

Firehose API は Amazon Web Services SDK で使用できます。Amazon Web Services SDK 用のプログラミング言語またはプラットフォームのリストについては、Amazon Web Services のツールをご参照ください。

Kinesis Agent は、データを収集して Firehose ストリームに送信する機能を簡単に実現する、事前に構築された Java アプリケーションです。このエージェントは、ウェブサーバー、ログサーバー、データベースサーバーなど、Linux ベースのサーバー環境にインストールできます。エージェントによって特定のファイルがモニタリングされ、データが継続的に Firehose ストリームに送信されます。現在、Amazon Kinesis Agent では Amazon Linux、Red Hat Enterprise Linux、および Microsoft Windows がサポートされています。詳細については、Writing with Agents を参照してください。

次のコマンドとリンクを使用して Kinesis Agent をダウンロードおよびインストールできます:

• Amazon Linux の場合: sudo yum install –y aws-kinesis-agent
• Red Hat Enterprise Linux の場合: sudo yum install –y https://s3.amazonaws.com/streaming-data-agent/aws-kinesis-agent-latest.amzn1.noarch.rpm
• GitHub から: awlabs/amazon-kinesis-agent
• Windows の場合: https://docs.aws.amazon.com/kinesis-agent-windows/latest/userguide/getting-started.html#getting-started-installation

Firehose ストリームにデータを追加するには、Kinesis Agent を使用するか、Firehose の PutRecord オペレーションや PutRecordBatch オペレーションを使用します。PutRecord オペレーションは、1 度の API コールで単一のデータレコードを許可し、PutRecordBatch オペレーションは、1 度の API 呼び出しで複数のデータレコードを許可します。詳細については、PutRecord と PutRecordBatch を参照してください。

AWS コンソールまたは Firehose API を通じてFirehose ストリームを作成または更新する場合、Amazon MSK クラスター/トピックを Firehose ストリームのソースとして設定できます。設定が完了すると、Firehose は MSK のトピックからデータを自動的に読み取り、そのデータを指定された S3 バケットにロードします。

コードを必要とすることなく、Amazon MSK トピックから供給されたストリーミングデータを変換して Amazon S3 にロードすることで、アプリケーションのオペレーションの複雑さとオーバーヘッドを軽減できます。例えば、Amazon MSK と Firehose では、コードが不要で、Parquet/ORC 形式の変換、データバッファリング、サービス側のデータ検証などのデータ変換および変換機能が組み込まれています。自動配信の再試行、データ保持、自動スケーリング、冗長性も活用できるため、データは高い信頼性をもって配信されます。

この機能を使用するには、MSK クラスターでパブリックエンドポイントまたはプライベートリンクが有効になっている必要があります。

はい。Firehose は、さまざまな AWS アカウントで利用できる Amazon MSK クラスターに接続できます。Firehose は、異なるアカウントに属する S3 バケットに配信することもできます。

Amazon MSK トピックからのデータの消費を開始するチェックポイント時間は、Firehose ストリームの作成時間です。Firehose はカスタムオフセット値を読み込まない。

AWS コンソールまたは Firehose API によって配信の作成や更新を行っている場合、Kinesis ストリームを Firehose ストリームのソースとして設定できます。設定が完了すると、Firehose ストリームから Firehose によって自動的にデータが読み取られ、指定された送信先にロードされます。

Firehose では、各 Kinesis シャードにつき毎秒 1 回 Kinesis データストリーム GetRecords() が呼び出されます。

Firehoseは、 Firehose ストリームのソースとして設定されている場合、Kinesis データストリームの最も新しい位置からデータの読み取りを開始します。Kinesis のデータストリームの位置の詳細については、Kinesis Data Streams サービス API リファレンスの GetShardIterator を参照してください。

はい、できます。ただし、Firehose からの GetRecords() コールはカウントされ、Kinesis シャード全体に対するスロットリング上限に関係することに注意してください。スロットリングが発生しないよう、他の Kinesis アプリケーションと Firehose ストリームを合わせて計画を立てることが必要になります。詳細については、Kinesis データストリームデベロッパーガイドの Kinesis データストリームの制限を参照してください。

いいえ、できません。Kinesis データストリームが Firehose ストリームのソースに設定されると、Firehose の PutRecord オペレーションと PutRecordBatch オペレーションが無効になります。その代わり、Kinesis Data Streams の PutRecord オペレーションと PutRecords オペレーションを使用して Kinesis のデータストリームにデータを追加できます。

AWS IoT から Firehose ストリームにデータを追加するには、Firehose ストリームにイベントを送信する AWS IoT アクションを作成します。詳細については、Firehose 開発者ガイドの AWS IoT を使用した Amazon Data Firehose への書き込みを参照してください。

AWS コンソールまたは Firehose API によって Firehose ストリームの作成や更新を行っている場合、Direct PUT を Firehose ストリームのソースとして設定できます。ストリームを作成すると、VPC フローログコンソールの Vended Logs セクションで、作成された Firehose ストリームをFirehose ストリームとして設定することができます。

CloudWatch Logs から Firehose ストリームにデータを追加するには、Firehose ストリームにイベントを送信する CloudWatch Logs サブスクリプションフィルターを作成します。詳細については、Amazon CloudWatch ユーザーガイドの 「CloudWatch Logs サブスクリプションフィルターの使用」を参照してください。

CloudWatch Events から Firehose ストリームにデータを追加するには、Firehose ストリームをターゲットとして CloudWatch Events ルールを作成します。詳細については、Firehose 開発者ガイドのCloudWatch Events を使用した Amazon Data Firehose への書き込み を参照してください。

AWS イベントブリッジコンソールから Firehose ストリームにデータを追加します。詳細については、AWS EventBridge のドキュメントを参照してください。

Firehose では、Amazon S3 バケットに送信されたデータを暗号化できます。Firehose ストリームを作成する際に、お客様が所有する AWS Key Management Service (KMS) キーによるデータの暗号化を選択できます。KMS の詳細については、AWS Key Management Service を参照してください。

Firehose では、Amazon S3 バケットや Amazon OpenSearch ドメインなどのリソースにアクセスするために、お客様が IAM ロールを指定することを前提としています。詳細については、Firehose デベロッパーガイドの Firehose によるアクセスの制御を参照してください。

はい。Firehose は AWS PrivateLink を使用して VPC 内にあるデータベースに接続します。

はい。Firehose 配信ストリームを設定すると、ソースデータベースの特定のテーブルと列を選択できます。Firehose は、選択したテーブルと列の CDC アップデートのみを配信します。

はい。CDC ストリームを Amazon S3 の Apache Iceberg テーブルに配信するように Firehose を設定すると、さまざまなソーステーブルからさまざまな Apache Iceberg テーブルにレコードを配信するようにストリームを設定できます。

Firehose では、データ raw や Json から、送信先のデータストアで必要な形式 (Apache Parquet や Apache ORC など) への組み込み型のデータ形式変換がサポートされています。独自のデータ処理パイプラインを構築する必要はありません。Firehose では、S3 に配信する前に、[customer_id] や [transaction_id] などの静的または動的に定義されたキーを使用して、ストリーミングデータを動的にパーティションすることもできます。Firehose は、これらのキーによってデータをグループ化し、キーに固有の S3 プレフィックスに配信することで、Athena、EMR、Redshift Spectrum を使用した S3 でのハイパフォーマンスでコスト効率の高い分析を容易に行うことができます。

Amazon Data Firehose 内蔵されている形式変換のオプションに加え、Firehose ストリーム内で受信する raw データを AWS Lambda 関数を使用して準備および変換し、送信先にロードできます。データ変換用の AWS Lambda 関数は、Firehose ストリームを新規作成するとき、または既存のFirehose ストリームを編集する際に設定できます。Amazon は、クイックスタートのために選択できる複数の Lambda Blue プリントを作成しています。完全なリストは、Amazon Data Firehose デベロッパーガイドをご参照ください。

Amazon Data Firehose では、Amazon S3 への配信前にデータを圧縮できます。このサービスでは現在、GZIP、ZIP、SNAPPY の圧縮形式がサポートされています。さらにデータを Amazon Redshift にロードする場合は、GZIP のみがサポートされています。

CloudWatch Logs のサブスクリプション機能を使用して、CloudWatch Logs から Firehose にデータをストリーミングできます。CloudWatch Logs のすべてのログイベントは、既に gzip 形式で圧縮されています。二重に圧縮することを防ぐため、Firehose では圧縮しないように設定してださい。CloudWatch Logs のサブスクリプション機能の詳細については、Amazon CloudWatch Logs ユーザーガイドの 「Amazon Data Firehose のサブスクリプションフィルター」を参照してください。

Lambda 関数で変換されたすべてのレコードは、以下の 3 つのパラメーターとともに Firehose に戻す必要があります。そうしないと Firehose はレコードを拒否してデータ変換エラーとして処理します。

• recordId: Lambda 関数の呼び出し中、recordId は各レコードと共に Firehose から Lambda 関数に渡されます。変換された各レコードは、recordId を完全に同じ値に保ったまま返される必要があります。元の recordId と返された recordId が一致しない場合、データ変換エラーとして処理されます。
   
• result: 各レコードの変換結果のステータス。このパラメータには次の値を使用できます。"Ok": レコードが期待どおり正しく変換された場合。"Dropped": ユーザーの処理ロジックによりレコードが期待どおりドロップされた場合。"ProcessingFailed": レコードを期待どおりに変換することができなかった場合。Firehose は SucceedProcessing.Records および SucceedProcessing.Bytes メトリクスを作成するとき、「Ok」および「Dropped」ステータスで返されたレコードを処理成功レコードとして扱い、「ProcessingFailed」ステータスで返されたレコードを処理失敗レコードとして扱います。
   
• data: based64 エンコード後の変換済みデータペイロード。

Lambda 関数によるデータ変換を使用する場合、Firehose では Lambda 呼び出しとデータ配信のすべてのエラーを Amazon CloudWatch Logs のログに記録できます。Lambda 呼び出しまたはデータ配信が失敗した場合、ユーザーは特定のエラーログをここで確認できます。詳細については、「Amazon CloudWatch Logs を使用したモニタリング」を参照してください。

Lambda 関数によるデータ変換を使用する場合、ソースレコードバックアップを有効にすると、Amazon Data Firehose で未変換の受信データは別の S3 バケットに送信されます。Firehose によって生成される「YYYY/MM/DD/HH」形式の UTC 時刻の接頭辞の前に、別の接頭辞を追加することを指定できます。

Firehose の動的パーティショニングは、ソースでの手動パーティショニング、またはデータ保存後の手動パーティショニングの複雑さや遅延を解消し、最適化されたデータセットをクエリする高速な分析を可能にします。これにより、データセットがすぐに利用できるようになることで分析ツールが効率的にクエリを実行でき、データへのきめ細かいアクセス制御が強化されます。例えば、マーケティングオートメーションをご利用のお客様は、お客様 ID によってオンザフライでデータをパーティショニングすることができます。これにより、お客様専用のクエリで最適化されたデータセットをクエリし、結果を迅速に得ることができます。IT オペレーションやセキュリティモニタリングを行うお客様は、ログに埋め込まれたイベントのタイムスタンプに基づいてグループ化を作成することで、最適化されたデータセットをクエリし、結果を迅速に得ることができます。この機能と Amazon Data Firehose の既存の JSON-to-parquet 形式への変換機能を組み合わせることで、Amazon Data Firehose は S3 の理想的なストリーミング ETL オプションとなります。

Firehose のデータパーティショニング機能は、AWS マネジメントコンソール、CLI、SDK から設定できます。Firehose ストリームを作成または更新する際に、 Firehose ストリームの配信先として Amazon S3 を選択し、動的パーティショニングを有効にします。パーティショニングに使用するキーを定義するために、キーを指定したり、ランタイム時に評価される式を作成することができます。例えば、受信ストリームのデータフィールド (customer id など) を選択し、S3 プレフィックス式 (customer_id=!{partitionKey:customer_id}/ など) を定義できます。この式は、取り込まれたレコードに基づいてランタイム時に評価され、どの S3 プレフィックスにレコードを配信するかを定義します。

Firehose は、Amazon S3 にデータを書き込む際に、追加設定なしで parquet/orc 変換をサポートします。Firehose は Lambda 関数とも連携しているので、独自の変換コードの書き込みも可能です。Firehose には、JSON 形式のレコードからキーデータフィールドを抽出するサポートも組み込まれています。また、Firehose は、これらのパーティションキーに対する変換を可能にする JQ パース言語もサポートしています。詳細については、Firehose デベロッパーガイドを参照してください。

はい。Firehose では、変換されたレコードを送信先に送信するのと並行して、未変換のすべてのレコードを S3 バケットにバックアップできます。Firehose ストリームを作成または更新するときにソースレコードバックアップを有効にすることができます。

Amazon S3 へのデータ配信頻度は、Firehose ストリーム作成時に設定された S3 バッファサイズとバッファ間隔値によって決定します。Firehose では、Amazon S3 にデータを配信する前に受信データがバッファされます。S3 バッファサイズ (1 MB～128 MB) またはバッファ間隔 (0～900 秒) の値を設定できます。最初に満たされた条件によって Amazon S3 へのデータ配信がトリガーされます。Apache Parquet または動的パーティショニングを有効にしている場合、バッファサイズは MB 単位で、Amazon S3 送信先の場合は 64 MB から 128 MB の範囲で、デフォルト値は 128 MB です。送信先へのデータ配信が Firehose ストリームへのデータの取り込みより遅くなった場合、Firehose では、バッファサイズを自動的に拡大して遅れを取り戻し、すべてのデータが送信先に配信されるようにします。

バッファサイズは圧縮前に適用されます。そのため、データの圧縮を選択した場合、ご利用の Amazon S3 バケット内の対象データのサイズは、指定したバッファサイズよりも小さくすることが可能です。

Amazon Redshift ユーザーは、お客様のデータを Amazon S3 バケットから Redshift インスタンスにコピーするために、Redshift INSERT 権限を持っている必要があります。

Amazon Redshift インスタンスが VPC 内にある場合は、VPC から Firehose の IP アドレスのブロックを解除して、Amazon Data Firehose から Redshift インスタンスにアクセスできるようにする必要があります。VPC への IP のブロックを解除する方法の詳細については、Amazon Data Firehose デベロッパーガイドの Amazon Redshift の送信先へのアクセス権を Firehose に付与するを参照してください。

Amazon Redshift を送信先として選択した場合、Amazon Data Firehose ではまず Amazon S3 バケットにデータが送信されます。その後 Redshift COPY コマンドが実行され、S3 バケットから Redshift インスタンスにデータがロードされます。

現在、1つの Firehose ストリームは1つの Snowflake テーブルにのみデータを配信できます。複数の Snowflake テーブルにデータを配信するには、複数の Firehose ストリームを作成する必要があります。

Firehoseは、Snowflake に1回限りの配信セマンティクスを使用します。つまり、エラーや再試行があった場合でも、各レコードは一度だけ Snowflake に配信されます。ただし、データがプロデューサーや ETL パイプラインの他の部分によって重複する可能性があるため、1 回だけ配信しても、データの端から端まで重複がないことが保証されるわけではありません。

ほとんどのデータストリームは 5 秒以内に配信されると予想しています。

Amazon OpenSearch Service を使用すると、インタラクティブなログ分析、リアルタイムのアプリケーションモニタリング、ウェブサイト検索などを簡単に実行できます。OpenSearch は、Elasticsearch から派生したオープンソースの分散検索および分析スイートです。Amazon OpenSearch Service は、OpenSearch の最新バージョン、Elasticsearch の 19 バージョン (1.5〜7.10 バージョン) のサポート、および OpenSearch Dashboards と Kibana (1.5〜7.10 バージョン) を利用した視覚化機能を提供します。Amazon OpenSearch の詳細についてはこちらをクリックしてください。

Firehose では、Amazon OpenSearch Service インデックスを一定の期間でローテーションさせることができます。この期間は、Firehose ストリームの作成時に設定できます。詳細については、Amazon Data Firehose デベロッパーガイドの Amazon OpenSearch 送信先のインデックスのローテーションを参照してください。

Firehose では、Amazon OpenSearch Service にデータをロードする際に、すべてのデータまたは配信に失敗したデータのみをバックアップできます。この機能を利用してデータの損失を防ぐためには、バックアップの Amazon S3 バケットを提供する必要があります。

Firehose ストリームの設定は、作成後いつでも変更できます。Firehose コンソールを使用するか、UpdateDestination オペレーションを実行して、設定を変更できます。設定を変更している間も Firehose ストリームは ACTIVE 状態のままであるため、継続的にデータを Firehose ストリームに送信できます。変更後の設定は通常、数分で適用されます。

VPC の宛先に配信するときに、同じ VPC、サブネット、セキュリティグループ内で新しい宛先にアクセスできる限り、宛先エンドポイント URL を変更できます。VPC、サブネット、セキュリティグループを変更するには、Firehose ストリームを再作成する必要があります。

Firehose の配信を Amazon OpenSearch Service の別のアカウントに配信できるのは、Firehose と Amazon OpenSearch Service がパブリックエンドポイント経由で接続されている場合のみです。

Firehose と Amazon OpenSearch Service がプライベート VPC で接続されている場合です。その場合、Firehose ストリームと送信先の Amazon OpenSearch Service のドメイン VPC は同じアカウントにある必要があります。

いいえ、Firehose ストリームと宛先の Amazon OpenSearch Service のドメインは同じリージョンにある必要があります。

Amazon OpenSearch Service へのデータ配信頻度は、Firehose ストリーム作成時に設定された OpenSearch バッファサイズとバッファ間隔値によって決定されます。Firehose では、Amazon OpenSearch Service にデータを配信する前に受信データがバッファされます。OpenSearch バッファサイズの値 (1 MB～100 MB) またはバッファ間隔 (0～900 秒) の値を設定し、Amazon OpenSearch Service へのデータ配信を最初にトリガーするために満たす条件を設定できます。送信先へのデータ配信が Firehose ストリームへのデータの取り込みより遅くなった場合、Amazon Data Firehose では、バッファサイズを自動的に拡大して遅れを取り戻し、すべてのデータが送信先に配信されるようにします。

送信先が Amazon Redshift の場合、Amazon S3 オブジェクトを Redshift インスタンスにまとめてロードするために、Amazon Data Firehose にマニフェストファイルが作成されます。マニフェストフォルダには、Firehose により生成されたマニフェストファイルが格納されます。

"すべてのドキュメント" モードが使用されている場合、Amazon Data Firehose により Firehose ストリームのバッファリングに基づいて複数の受信レコードが連結され、S3 オブジェクトとして S3 バケットに配信されます。設定されているバックアップモードを問わず、失敗したドキュメントは特定の JSON 形式を使用して S3 バケットに配信されます。この形式により、エラーコード、配信試行回数などの追加情報が提供されます。詳細については、「Amazon Data Firehose デベロッパーガイド」の「Amazon S3 Backup for the Amazon OpenSearch Destination」(Amazon OpenSearch の送信先の Amazon S3 のバックアップ) を参照してください。

現在、単一の Firehose ストリームがデータを配信できるのは単一の Amazon S3 バケットに対してのみです。複数の S3 バケットにデータを配信する場合は、複数の Firehose ストリームを作成できます。

現在、1 つの Firehose ストリームでは 1 つの Redshift インスタンスと 1 つのテーブルにのみデータを配信できます。複数の Redshift インスタンスまたはテーブルにデータを配信する場合は、複数の Firehose ストリームを作成できます。

現在、単一の Firehose ストリームがデータを配信できるのは単一の Amazon OpenSearch Service ドメインおよびインデックスのみです。複数の Amazon OpenSearch ドメインまたはインデックスにデータを配信する場合は、複数の Firehose ストリームを作成できます。

Firehose が VPC の Amazon OpenSearch Service の送信先にデータを配信できるようにすると、Amazon Data Firehose は、選択したサブネットごとに VPC に 1 つ以上のクロスアカウント Elastic Network Interface (ENI) を作成します。Amazon Data Firehose はこれらの ENI を使用してデータを VPC に配信します。ENI の数は、サービス要件に合わせて自動的にスケールします。

はい。1 つの Firehose ストリームで複数の Apache Iceberg テーブルにデータを配信できます。

はい。Firehose は、別のアカウント内、または別の AWS リージョン内にある AWS Glue データカタログへの接続をサポートしています。

はい。Apache Iceberg テーブルへの配信時には、Lambda を使用するデータ変換を利用できます。 

初期設定では、各 Firehose ストリームで、毎秒 2,000 件のトランザクション、毎秒 5,000 件および毎秒 5 MB のレコードの取り込みが可能です。この制限は、サービス上限緩和申請を送信することにより簡単に引き上げることができます。

Amazon Data Firehose では、データの配信に少なくとも 1 回のセマンティクスが使用されます。データの配信のリクエストの試行がタイムアウトして、配信が Firehose によって再試行されるなど、ごくまれに以前のリクエストが実行されて重複が発生する場合があります。

データソースが Direct PUT で、Amazon S3 バケットへのデータ配信が失敗した場合、Amazon Data Firehose では、最大 24 時間、5 秒ごとにデータの配信が再試行されます。24 時間の保持期間が経過しても問題が継続する場合、Amazon Data Firehose はデータを破棄します。

データソースが Kinesis データストリームで、Amazon S3 バケットへのデータ配信が失敗した場合、Amazon Data Firehose では、Kinesis Data Streams で設定されている最大期間まで、5 秒ごとにデータの配信が再試行されます。

Amazon Redshift インスタンスへのデータ配信が失敗した場合、Amazon Data Firehose では最大 120 分間、5 分ごとにデータの配信が再試行されます。120 分後、Amazon Data Firehose では COPY の準備が整っている S3 オブジェクトの現在のバッチをスキップし、次のバッチの処理に進みます。スキップされたオブジェクトに関する情報はエラーフォルダ内のマニフェストファイルとして S3 バケットに送信されるため、手動によるバックフィルに使用できます。マニフェストファイルを使って手動でデータをコピーする方法について詳しくは、マニフェストを使用し、データファイルを指定するを参照してください。

送信先が Amazon OpenSearch Service である場合、Firehose ストリームの作成時に 0～7200 秒の間再試行期間を指定することができます。Amazon OpenSearch ドメインへのデータ配信が失敗した場合、Amazon Data Firehose では、指定された期間にデータ配信が再試行されます。再試行期間の経過後、Amazon Data Firehose ではデータの現在のバッチをスキップし、次のバッチの処理に進みます。スキップされたドキュメントに関する情報は opensearch_failed フォルダ内の S3 バケットに送信されるため、手動によるバックフィルに使用できます。

Firehose がデータ変換のための Lambda 関数を呼び出す場合、2 つのタイプの失敗シナリオがあります。

• 最初のタイプは、ネットワークのタイムアウトに到達して Lambda の呼び出し制限に達したなどの理由で関数の呼び出しが失敗する場合です。この失敗シナリオでは、Firehose はデフォルトで呼び出しを 3 回再試行し、そのあと問題のレコードのバッチをスキップします。スキップされたレコードは処理失敗レコードとして扱われます。呼び出しの再試行回数は、CreateDeliveryStream API および UpdateDeliveryStream API を使用して 0 から 300 の間で設定できます。このタイプの失敗では、Firehose のエラーログ機能を使用して、呼び出しエラーを CloudWatch Logs に書き出すことができます。詳細については、「Amazon CloudWatch Logs を使用したモニタリング」を参照してください。
   
• 2 つ目のタイプの失敗シナリオは、レコードが Lambda 関数から返されるときにレコードの変換結果が "ProcessingFailed" に設定される場合に発生します。Firehose ではこれらのレコードは処理失敗レコードとして扱われます。このタイプの失敗では、Lambda 関数のログ機能を使用して、エラーログを CloudWatch Logs に書き出すことができます。詳細については、「AWS Lambda の Amazon CloudWatch Logs へのアクセス」を参照してください。

どちらのタイプの失敗シナリオでも、処理失敗レコードは S3 バケットの processing_failed フォルダに送信されます。

バッファ間隔の条件より先にバッファサイズの条件が満たされている場合は大抵、配信された S3 オブジェクトのサイズに指定されたバッファサイズが反映されます。ただし、送信先へのデータ配信が Firehose ストリームへのデータ書き込みより遅くなった場合、Firehose では、バッファサイズを動的に拡大して遅れを取り戻し、すべてのデータが送信先に配信されるようにします。このような場合、配信された S3 オブジェクトのサイズが指定されたバッファサイズより大きくなる可能性があります。

エラーフォルダには、Amazon Redshift インスタンスにロードできなかった S3 オブジェクトの情報が格納されたマニフェストファイルが保存されます。Redshift COPY コマンドを使用して、これらのオブジェクトを手動で再ロードできます。マニフェストファイルを使って手動でデータをコピーする方法について詳しくは、マニフェストを使用し、データファイルを指定するを参照してください。

opensearch_failed フォルダには、Amazon OpenSearch へのロードに失敗したドキュメントが保存されています。 Amazon OpenSearch ドメインへのデータ配信に失敗した場合はどうなりますか?ドメイン。バックフィルのために手動でこれらのドキュメントのインデックスを再作成することができます。

processing_failed フォルダは AWS Lambda 関数で変換に失敗したレコードが保管されるフォルダです。これらのレコードは再度手動で処理することができます。

Firehose コンソールには、受信データボリュームや配信データボリュームなど、オペレーションとパフォーマンスに重要なメトリクスが表示されます。また Amazon Data Firehose は Amazon CloudWatch メトリクスとも統合されているためFirehose ストリームのメトリクスを収集、表示、分析できます。Amazon Data Firehose のメトリクスの詳細については、Amazon Data Firehose デベロッパーガイドの 「Amazon CloudWatch Metrics のモニタリング」を参照してください。

Amazon Data Firehose は Amazon CloudWatch Logs と統合されているため、データの変換または送信が失敗した場合に特定のエラーログを確認できます。エラーログは Firehose ストリームの作成時に有効にできます。詳細については、Amazon Data Firehose デベロッパーガイドの 「Amazon CloudWatch Logs を使用したモニタリング」を参照してください。

Amazon Data Firehose は、AWS のサービスとリソースへのユーザーアクセスを安全に制御できる AWS Identity and Access Management というサービスに統合されています。例えば、Firehose ストリームへのデータの追加を特定のユーザーまたはグループのみに許可するポリシーを作成できます。ストリーミングのアクセスの管理と制御に関する詳細については、「Amazon Data Firehose によるアクセスの制御」 を参照してください。

Amazon Data Firehose は AWS CloudTrail と統合されています。AWS CloudTrail は、ユーザーのアカウントに対する AWS API コールを記録してログファイルを提供するサービスです。API コールのログおよびサポートされる Amazon Data Firehose API オペレーションのリストの詳細については、「AWS CloudTrail を使用した Amazon Data Firehose API コールのログ記録」を参照してください。

現時点で、Firehose は AWS 無料利用枠の対象になっていません。AWS 無料利用枠は、AWS サービスのグループの試用を無料で提供するプログラムです。詳細については、AWS 無料利用枠を参照してください。

Firehose ではシンプルな従量課金制を採用しています。前払い料金や最低料金はなく、使用したリソースに対してのみお支払いいただきます。Amazon Data Firehose の料金は、Firehose によって取り込まれたデータボリューム (GB) に基づいています。各レコードは、Direct PUT および Kinesis データストリームをソースとする場合、直近の 5 KB の倍数に切り上げた数値となります。Vended Logs をソースとする場合、料金は Firehose で取り込んだデータ量 (GB) に基づいて決定されます。Amazon Data Firehose の費用の詳細については、Amazon Data Firehose 料金をご覧ください。

5 KB への切り上げは、API オペレーションのレベルではなく、レコードのレベルで計算されます。例えば、PutRecordBatch 呼び出しに 1 KB のレコードが 2 件含まれている場合、その呼び出しのデータボリュームは 10 KB となります(レコードごとに 5 KB)。

いいえ、ストレージやリクエストコストを含む Amazon S3、Amazon Redshift、Amazon OpenSearch Service、AWS Lambda の使用量に関する料金は別途請求されます。詳細については、Amazon S3 の料金、Amazon Redshift の料金、Amazon OpenSearch Service の料金、AWS Lambda の料金を参照してください。

Amazon Data Firehose SLA では、Amazon Data Firehose について少なくとも 99.9% の月間稼働率を保証しています。

同じリージョン内の複数のアベイラビリティーゾーンでタスクを実行しており、任意の月間課金期間中に月間稼働率が 99.9% 未満であった場合、Amazon Data Firehose SLA に基づいて Amazon Data Firehose に対する SLA クレジットを受け取る資格があります。

SLA の利用規約に関するすべての詳細、およびクレジット請求方法の詳細については、Amazon Data Firehose SLA の詳細ページを参照してください。