# Lambda がストリームおよびキューベースのイベントソースからのレコードを処理する方法
*イベントソースマッピング*は、ストリームおよびキューベースのサービスからアイテムを読み取り、レコードのバッチを使用して関数を呼び出す Lambda リソースです。イベントソースマッピング内では、*イベントポーラー*と呼ばれるリソースが新しいメッセージをアクティブにポーリングし、関数を呼び出します。デフォルトでは、Lambda はイベントポーラーを自動的にスケーリングしますが、特定のイベントソースタイプでは、[プロビジョニングモード](#invocation-eventsourcemapping-provisioned-mode)を使用して、イベントソースマッピング専用のイベントポーラーの最小数と最大数を制御できます。
以下のサービスは、イベントソースマッピングを使用して Lambda 関数を呼び出します。
+ [Amazon DocumentDB (MongoDB 互換) (Amazon DocumentDB)](with-documentdb.md)
+ [Amazon DynamoDB](with-ddb.md)
+ [Amazon Kinesis](with-kinesis.md)
+ [Amazon MQ](with-mq.md)
+ [Amazon Managed Streaming for Apache Kafka (Amazon MSK)](with-msk.md)
+ [セルフマネージド Apache Kafka](with-kafka.md)
+ [Amazon Simple Queue Service](with-sqs.md) (Amazon SQS)
**警告**
Lambda イベントソースマッピングは各イベントを少なくとも 1 回処理し、レコードの重複処理が発生する可能性があります。重複するイベントに関連する潜在的な問題を避けるため、関数コードを冪等にすることを強くお勧めします。詳細については、AWS ナレッジセンターの「[Lambda 関数を冪等にするにはどうすればよいですか?](https://repost.aws/knowledge-center/lambda-function-idempotent)」を参照してください。
## イベントソースマッピングと直接トリガーの違い
一部の AWS のサービスは、*トリガー*を使用して Lambda 関数を直接呼び出すことができます。これらのサービスはイベントを Lambda にプッシュし、指定されたイベントが発生すると即時に関数が呼び出されます。トリガーは、個別のイベントやリアルタイム処理に適しています。[Lambda コンソールを使用してトリガーを作成する](lambda-services.md#lambda-invocation-trigger)と、コンソールは対応する AWS サービスと連携して、そのサービスでイベント通知を設定します。実際には、トリガーは Lambda ではなく、イベントを生成するサービスによって保存および管理されます。トリガーを使用して Lambda 関数を呼び出すサービスの例をいくつか示します。
+ **Amazon Simple Storage Service (Amazon S3):** オブジェクトがバケット内で作成、削除、または変更されたときに関数を呼び出します。詳細については、「[チュートリアル: Amazon S3 トリガーを使用して Lambda 関数を呼び出す](with-s3-example.md)」を参照してください。
+ **Amazon Simple Notification Service (Amazon SNS):** メッセージが SNS トピックに発行されたときに関数を呼び出します。詳細については、「[チュートリアル: Amazon Simple Notification Service での AWS Lambda の使用](with-sns-example.md)」を参照してください。
+ **Amazon API Gateway:** API リクエストが特定のエンドポイントに対して行われたときに関数を呼び出します。詳細については、「[Amazon API Gateway エンドポイントを使用した Lambda 関数の呼び出し](services-apigateway.md)」を参照してください。
イベントソースマッピングは、Lambda サービス内で作成および管理される Lambda リソースです。イベントソースマッピングは、大量のストリーミングデータやキューからのメッセージを処理できるように設計されています。ストリームまたはキューからのレコードをバッチで処理すると、レコードを個別に処理するよりも効率的です。
## バッチ処理動作
デフォルトで、イベントソースマッピングは、Lambda が関数に送信する単一のペイロードにレコードをまとめてバッチ処理します。バッチ処理の動作を微調整するには、バッチ処理ウィンドウ ([MaximumBatchingWindowInSeconds](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-MaximumBatchingWindowInSeconds)) とバッチサイズ ([BatchSize](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-response-BatchSize)) を設定します。バッチ処理ウィンドウとは、レコードを単一のペイロードにまとめるための最大時間です。バッチサイズとは、単一のバッチ内にあるレコードの最大数です。Lambda は、以下の 3 つの条件のいずれかが満たされたときに関数を呼び出します。
+ **バッチ処理ウィンドウが最大値に到達した。**デフォルトのバッチ処理ウィンドウの動作は、特定のイベントソースによって異なります。
+ **Kinesis、DynamoDB、および Amazon SQS イベントソースの場合:** デフォルトのバッチ処理ウィンドウは 0 秒です。つまり、Lambda はレコードが使用可能になると同時に関数を呼び出します。バッチ処理ウィンドウを設定するには、`MaximumBatchingWindowInSeconds` を設定します。このパラメータは、秒単位で 0 秒から 300 秒までの任意の値に設定できます。バッチ処理ウィンドウを設定する場合、前の関数の呼び出しが完了するとすぐに次のウィンドウが開始されます。
+ **Amazon MSK、セルフマネージド Apache Kafka、Amazon MQ、および Amazon DocumentDB イベントソースの場合:** バッチ処理ウィンドウはデフォルトで 500 ミリ秒に設定されます。`MaximumBatchingWindowInSeconds` は、秒単位で 0 秒から 300 秒までの任意の値に設定できます。Kafka イベントソースマッピングのプロビジョンドモードでバッチウィンドウを設定すると、前のバッチが完了すると同時に次のウィンドウが開始されます。プロビジョニングされていない Kafka イベントソースマッピングでバッチウィンドウを設定すると、前の関数呼び出しが完了すると同時に次のウィンドウが開始されます。プロビジョンドモードで Kafka イベントソースマッピングを使用するときのレイテンシーを最小限に抑えるには、`MaximumBatchingWindowInSeconds` を 0 に設定します。この設定は、現在の関数呼び出しの完了後、Lambda が直ちに次のバッチの処理を開始することを確実にします。低レイテンシー処理の詳細については、「[低レイテンシー Apache Kafka](with-kafka-low-latency.md)」を参照してください。
+ **Amazon MQ と Amazon DocumentDB のイベントソースの場合:** デフォルトのバッチウィンドウは 500 ミリ秒です。`MaximumBatchingWindowInSeconds` は、秒単位で 0 秒から 300 秒までの任意の値に設定できます。バッチ処理ウィンドウは、最初のレコードが到着するとすぐに開始されます。
**注記**
`MaximumBatchingWindowInSeconds` は秒単位の増分でしか変更できないため、いったん変更すると、デフォルトのバッチ処理ウィンドウである 500 ミリ秒に戻すことはできません。デフォルトのバッチ処理ウィンドウを復元するには、新しいイベントソースマッピングを作成する必要があります。
+ **バッチサイズに適合した。**最小バッチサイズは 1 です。デフォルトのバッチサイズと最大バッチサイズは、イベントソースに応じて異なります。これらの値の詳細については、`CreateEventSourceMapping` API オペレーションの [BatchSize](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html#lambda-CreateEventSourceMapping-request-BatchSize) の仕様を参照してください。
+ **ペイロードサイズが [6 MB](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html) に到達した。**この上限を変更することはできません。
以下の図は、これら 3 つの条件を説明するものです。バッチ処理ウィンドウが `t = 7` 秒で開始されるとします。最初のシナリオでは、バッチ処理ウィンドウが 5 個のレコードを蓄積した後、`t = 47` 秒の時点で最大値の 40 秒に到達します。2 番目のシナリオでは、バッチ処理ウィンドウの期限が切れる前にバッチサイズが 10 個になるため、バッチ処理ウィンドウが早く終了します。3 番目のシナリオでは、バッチ処理ウィンドウの期限が切れる前に最大ペイロードサイズに到達するため、バッチ処理ウィンドウが早く終了します。
![\[\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/batching-window.png)
バッチおよびレコードの各種サイズのテストにより、関数がタスクを完了できるスピードに合わせて各イベントソースのポーリング間隔を調整することをおすすめします。[CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html) `BatchSize` パラメータにより、各呼び出しで関数に送信できるレコードの最大数を制御します。通常、バッチサイズが大きいほど、大きなレコードセット全体での呼び出しのオーバーヘッドをより効率的に吸収し、スループットを増大できます。
Lambda は、設定された[拡張機能](lambda-extensions.md)の完了を待たずに、次のバッチを処理のために送信します。つまり、Lambda がレコードの次のバッチを処理する間も拡張機能を実行し続けることができます。アカウントの[同時実行](lambda-concurrency.md)設定または制限に違反すると、スロットリングの問題が発生する可能性があります。これが潜在的な問題であるかどうかを検出するには、関数を監視し、イベントソースマッピングで予想よりも高い[同時実行メトリクス](monitoring-concurrency.md#general-concurrency-metrics)が表示されているかどうかを確認します。呼び出しの間隔が短いため、Lambda はシャードの数よりも高い同時実行使用量を一時的に報告する場合があります。これは、拡張機能のない Lambda 関数にも当てはまります。
関数がエラーを返す場合は、デフォルトで、イベントソースマッピングは関数が成功するまで、またはバッチ内の項目の期限が切れるまでバッチ全体を再処理します。処理が順序正しく行われることを確実にするため、イベントソースマッピングは、エラーが解決されるまで影響を受けたシャードの処理を一時停止します。ストリームソース (DynamoDB と Kinesis) については、関数がエラーを返すときに Lambda が再試行する最大回数を設定できます。バッチが関数に到達しないサービスエラーまたはスロットルは、再試行としてカウントされません。イベントバッチを破棄したときに呼び出しレコードを[送信先](invocation-async-retain-records.md#invocation-async-destinations)に送信するように、イベントソースマッピングを設定することもできます。
## プロビジョンドモード
Lambda イベントソースマッピングは、イベントポーラーを使用して、新しいメッセージのイベントソースをポーリングします。デフォルトでは、Lambda はメッセージ量に基づいてこれらのポーラーの自動スケーリングを管理します。メッセージトラフィックが増加すると、Lambda は負荷に対応するためにイベントポーラーの数を自動的に増やし、トラフィックが減少すると減らします。
プロビジョニングモードでは、引き続き予想されるトラフィックパターンを処理する準備ができている専用ポーリングリソースの最小制限と最大制限を定義することで、イベントソースマッピングのスループットをファインチューニングできます。これらのリソースは、イベントトラフィックの急増を処理するために 3 倍速く自動スケーリングされ、数百万のイベントを処理を可能にする 16 倍の処理容量を提供します。これにより、厳格なパフォーマンス要件を持つ、応答性の高いイベント駆動型ワークロードを構築できます。
Lambda では、イベントポーラーは、イベントソースタイプによって異なるスループット機能を備えたコンピューティングユニットです。Amazon MSK およびセルフマネージド Apache Kafka の場合、各イベントポーラーは最大 5 MB/秒のスループットまたは最大 5 個の同時呼び出しを処理できます。例えば、イベントソースが 1 MB の平均ペイロードを生成し、関数の平均時間が 1 秒の場合、単一の Kafka イベントポーラーは 5 MB/秒のスループットと 5 個の同時 Lambda 呼び出しをサポートできます (ペイロード変換がないと仮定)。Amazon SQS の場合、各イベントポーラーは最大 1 MB/秒のスループットまたは最大 10 個の同時呼び出しを処理できます。プロビジョンドモードを使用すると、イベントポーラーの使用状況に基づいて追加コストが発生します。料金の詳細については、「[AWS Lambda の料金](https://aws.amazon.com/lambda/pricing/)」を参照してください。
プロビジョンドモードは、Amazon MSK、セルフマネージド Apache Kafka、および Amazon SQS のイベントソースで利用可能です。同時実行設定では関数のスケーリングを制御できますが、プロビジョニングモードではイベントソースマッピングのスループットを制御できます。最大のパフォーマンスを確保するには、両方の設定を個別に調整する必要がある場合があります。
プロビジョンドモードは、マーケットデータフィードを処理する金融サービス会社、リアルタイムでパーソナライズされたお薦め情報を提供する e コマースプラットフォーム、ライブプレイヤーインタラクションを管理するゲーム会社など、安定したイベント処理レイテンシーが求められるリアルタイムアプリケーションに最適です。
イベントポーラーごとに異なるスループットキャパシティがサポートされます。
+ Amazon MSK およびセルフマネージド Apache Kafka の場合: 最大 5 MB/秒のスループット、または最大 5 回の同時呼び出し
+ Amazon SQS の場合: 最大 1 MB/秒のスループット、最大 10 回の同時呼び出し、または 1 秒あたり最大 10 回の SQS ポーリング API コール。
Amazon SQS イベントソースマッピングでは、ポーラーの最小数は 2〜200 の範囲で設定でき、デフォルトは 2、最大数は 2～2,000 の範囲で設定でき、デフォルトは 200 になります。Lambda は、設定された最小値と最大値の間でイベントポーラーの数をスケーリングし、1 分あたり最大 1,000 個の同時実行数をすばやく追加して、一貫した低レイテンシーのイベント処理を実現します。
Kafka イベントソースマッピングでは、ポーラーの最小数を 1～200 の範囲で設定でき、デフォルトは 1、最大数を 1～2,000 の範囲で設定でき、デフォルトは 200 になります。Lambda は、トピック内のイベントバックログに基づいて、設定された最小値と最大値の間でイベントポーラーの数をスケーリングし、低レイテンシーのイベントの処理を実現します。
Amazon SQS イベントソースの場合、最大同時実行数の設定をプロビジョニングモードで使用することはできないことにご留意ください。プロビジョンドモードを使用する場合、最大イベントポーラー設定を使用して同時実行を制御します。
プロビジョニングモードの設定の詳細については、以下のセクションを参照してください。
+ [Configuring provisioned mode for Amazon MSK event source mappings](kafka-scaling-modes.md)
+ [Configuring provisioned mode for self-managed Apache Kafka event source mappings](kafka-scaling-modes.md#kafka-provisioned-mode)
+ [Amazon SQS イベントソースマッピングでのプロビジョンドモードの使用](with-sqs.md#sqs-provisioned-mode)
プロビジョンドモードでレイテンシーを最小限に抑えるには、`MaximumBatchingWindowInSeconds` を 0 に設定します。この設定は、現在の関数呼び出しの完了後、Lambda が直ちに次のバッチの処理を開始することを確実にします。低レイテンシー処理の詳細については、「[低レイテンシー Apache Kafka](with-kafka-low-latency.md)」を参照してください。
プロビジョニングモードを設定すると、`ProvisionedPollers` メトリクスをモニタリングすることで、ワークロードのイベントポーラーの使用状況を確認できます。詳細については、「[イベントソースマッピングメトリクス](monitoring-metrics-types.md#event-source-mapping-metrics)」を参照してください。
## イベントソースマッピング API
[AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) または [AWS SDK](https://aws.amazon.com/getting-started/tools-sdks/) を使用してイベントソースを管理するには、以下の API 操作を使用できます。
+ [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)
+ [ListEventSourceMappings](https://docs.aws.amazon.com/lambda/latest/api/API_ListEventSourceMappings.html)
+ [GetEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_GetEventSourceMapping.html)
+ [UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html)
+ [DeleteEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteEventSourceMapping.html)
# イベントソースマッピングでのタグの使用
イベントソースマッピングにタグを付けて、リソースを整理および管理できます。タグは、AWS のサービス間でサポートされているリソースに関連付けられた自由形式のキーと値のペアです。タグのユースケースの詳細については、「*タグ付け AWS リソースとタグエディタガイド*」の「[一般的なタグ付け戦略](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#tag-strategies)」を参照してください。
イベントソースマッピングは、独自のタグを持つことができる関数に関連付けられています。イベントソースマッピングは、関数からタグを自動的に継承しません。AWS Lambda API を使用して、タグを表示および更新できます。Lambda コンソールで特定のイベントソースマッピングを管理しながら、Amazon SQS のプロビジョンドモードを使用しているものを含め、タグの表示と更新を行うこともできます。
## タグの操作に必要なアクセス許可
AWS Identity and Access Management (IAM) ID (ユーザー、グループ、ロール) がリソースのタグを読み取るまたは設定できるようにするには、以下の対応するアクセス許可を付与します。
+ **lambda:ListTags** – リソースがタグ付けされている場合は、そのリソースで `ListTags` を呼び出す必要があるすべてのユーザーに対し、このアクセス許可を付与します。タグ付き関数の場合、このアクセス許可は `GetFunction` にも必要です。
+ **lambda:TagResource** – 作成時に `TagResource` を呼び出すかタグを実行する必要があるすべてのユーザーにこのアクセス許可を付与します。
必要に応じて、**Lambda:UntagResource** アクセス許可も付与して、リソースへの `UntagResource` 呼び出しを許可することを検討してください。
詳細については、「[Lambda のアイデンティティベースの IAM ポリシー](access-control-identity-based.md)」を参照してください。
## Lambda コンソールでのタグの使用
Lambda コンソールを使用して、Amazon SQS のプロビジョンドモードで設定されているものを含め、タグを持つイベントソースマッピングを作成し、既存のイベントソースマッピングにタグを追加して、イベントソースマッピングをタグでフィルタリングできます。
Lambda コンソールを使用してサポートされているストリームおよびキューベースのサービスのトリガーを追加すると、Lambda は自動的にイベントソースマッピングを作成します。これらのイベントソースの詳細については、「[Lambda がストリームおよびキューベースのイベントソースからのレコードを処理する方法](invocation-eventsourcemapping.md)」を参照してください。コンソールでイベントソースマッピングを作成するには、次の前提条件が必要です。
+ 関数。
+ 影響を受けるサービスのイベントソース。
タグは、トリガーの作成や更新に使用するのと同じユーザーインターフェイスの一部として追加できます。
**イベントソースマッピングの作成時にタグを追加するには**
1. Lambda コンソールの [[関数]](https://console.aws.amazon.com/lambda/home#/functions) ページを開きます。
1. 関数の名前を選択します。
1. **[関数の概要]** で **[トリガーを追加]** をクリックします。
1. **[トリガーの設定]** のドロップダウンリストで、イベントソースの取得元となるサービスの名前を選択します。
1. イベントソースのコア設定を指定します。イベントソースの設定の詳細については、「[他の AWS サービスからのイベントを使用した Lambda の呼び出し](lambda-services.md)」の関連サービスのセクションを参照してください。
1. **[イベントソースマッピング設定]** で、**[追加設定]** を選択します。
1. **[タグ]** で **[新しいタグを追加]** を選択します。
1. **[キー]** フィールドにタグキーを入力します。タグ付け制限の詳細については、「*タグ付け AWS リソースとタグエディタユーザーガイド*」の「[タグの命名制限と要件](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#id_tags_naming_best_practices)」を参照してください。
1. **[Add]** (追加) を選択します。
**既存のイベントソースマッピングにタグを追加するには**
1. Lambda コンソールの [[イベントソースマッピング]](https://console.aws.amazon.com/lambda/home#/event-source-mappings) を開きます。
1. リソースリストから、**[関数]** と **[イベントソース ARN]** に対応するイベントソースマッピングの **UUID** を選択します。
1. **[一般設定]** ペインの下のタブリストから、**[タグ]** を選択します。
1. [**Manage tags (タグの管理)**] を選択します。
1. **新しいタグを追加**を選択します。
1. **[キー]** フィールドにタグキーを入力します。タグ付け制限の詳細については、「*タグ付け AWS リソースとタグエディタユーザーガイド*」の「[タグの命名制限と要件](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#id_tags_naming_best_practices)」を参照してください。
1. **[保存]** を選択します。
**タグでイベントソースマッピングをフィルタリングするには**
1. Lambda コンソールの [[イベントソースマッピング]](https://console.aws.amazon.com/lambda/home#/event-source-mappings) を開きます。
1. 検索ボックスを選択します。
1. ドロップダウンリストで、**[タグ]** の小見出しの下からタグキーを選択します。
1. **[使用: "tag-name"]** を選択して、このキーでタグ付けされたすべてのイベントソースマッピングを表示するか、**[演算子]** を選択して、値でさらにフィルタリングします。
1. タグキーと値の組み合わせでフィルタリングするタグ値を選択します。
検索ボックスは、タグキーの検索もサポートしています。キーの名前を入力し、リスト内で見つけます。
## AWS CLIでのタグの使用
Lambda API を使用して、イベントソースマッピングを含む既存の Lambda リソースにタグを追加および削除できます。イベントソースマッピングの作成時にタグを追加することもできます。これにより、ライフサイクル全体を通じてリソースにタグを付けることができます。
### Lambda タグ API を使用したタグの更新
サポートされている Lambda リソースのタグを追加または削除するには、[TagResource](https://docs.aws.amazon.com/lambda/latest/api/API_TagResource.html) および [UntagResource](https://docs.aws.amazon.com/lambda/latest/api/API_UntagResource.html) API オペレーションを使用します。
これらの操作は AWS CLI を使用して呼び出すことができます。既存のリソースにタグを追加するには、`tag-resource` コマンドを使用します。この例では、2 つのタグを追加します。1 つはキー *Department* を持つタグで、もう 1 つはキー *CostCenter* を持つタグです。
```
aws lambda tag-resource \
--resource arn:aws:lambda:us-east-2:123456789012:resource-type:my-resource \
--tags Department=Marketing,CostCenter=1234ABCD
```
タグを削除するには、`untag-resource` コマンドを使用します。この例では、キー *Department* を持つタグを削除します。
```
aws lambda untag-resource --resource arn:aws:lambda:us-east-1:123456789012:resource-type:resource-identifier \
--tag-keys Department
```
### イベントソースマッピング作成時のタグの追加
タグを使用して新しい Lambda イベントソースマッピングを作成するには、[CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html) API オペレーションを使用します。`Tags` パラメータを指定します。このオペレーションは、`create-event-source-mapping` AWS CLI コマンドと `--tags` オプションを使用して呼び出すことができます。CLI コマンドの詳細については、「*AWS CLI コマンドリファレンス*」の「[create-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-event-source-mapping.html)」を参照してください。
`CreateEventSourceMapping` で `Tags` パラメータを使用する前に、このオペレーションに必要な通常のアクセス許可と共に、リソースにタグを付けるアクセス許可をロールが有していることを確認してください。タグ付けのアクセス許可の詳細については、「[タグの操作に必要なアクセス許可](#esm-tags-required-permissions)」を参照してください。
### Lambda タグ API を使用したタグの表示
特定の Lambda リソースに適用されるタグを表示するには、`ListTags` API オペレーションを使用します。詳細については、「[ListTags](https://docs.aws.amazon.com/lambda/latest/api/API_ListTags.html)」を参照してください。
このオペレーションは、ARN (Amazon リソースネーム) を指定することで `list-tags` AWS CLI コマンドで呼び出すことができます。
```
aws lambda list-tags --resource arn:aws:lambda:us-east-1:123456789012:resource-type:resource-identifier
```
### タグによるリソースのフィルタリング
AWS Resource Groups Tagging API [GetResources](https://docs.aws.amazon.com/resourcegroupstagging/latest/APIReference/API_GetResources.html) API オペレーションを使用すると、リソースをタグでフィルタリングできます。この `GetResources` オペレーションは、それぞれにタグキーと最大 10 個のタグ値が含まれているフィルタを、最大 10 個まで受け取ります。特定のリソースタイプでフィルタリングするには、`GetResources` で `ResourceType` を指定します。
このオペレーションは、`get-resources` AWS CLI コマンドを使用して呼び出すことができます。`get-resources` の使用例については、「*AWS CLI コマンドリファレンス*」の「[get-resources](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/resourcegroupstaggingapi/get-resources.html#examples)」を参照してください。