翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# サブスクリプションを使用したログデータのリアルタイム処理
サブスクリプションを使用して CloudWatch Logs からログイベントのリアルタイムフィードにアクセスし、カスタム処理、分析、他のシステムへのロードを行うために、Amazon Kinesis ストリーム、Amazon Data Firehose ストリーム、 AWS Lambda などの他のサービスに配信することができます。ログイベントが宛先サービスに送信されると、base64 でエンコードされ、gzip 形式で圧縮されます。
CloudWatch Logs の一元化を使用して、複数のアカウントとリージョンのログデータを一元的にレプリケートすることもできます。詳細については、「[クロスアカウントクロスリージョンログの一元化](CloudWatchLogs_Centralization.md)」を参照してください。
ログイベントのサブスクライブを開始するには、イベントが配信される Amazon Kinesis Data Streams ストリームなどの受信リソースを作成します。サブスクリプションフィルターは、 AWS リソースに配信されるログイベントをフィルタリングするために使用するフィルターパターンと、一致するログイベントの送信先に関する情報を定義します。ログイベントは、取り込み後すぐに (通常は 3 分未満) 受信側リソースに送信されます。
**注記**
サブスクリプションを持つロググループがログ変換を使用する場合、フィルターパターンは変換されたバージョンのログイベントと比較されます。詳細については、「[取り込み中のログの変換](CloudWatch-Logs-Transformation.md)」を参照してください。
サブスクリプションは、アカウントレベルとロググループレベルで作成できます。各アカウントには、リージョンごとに 1 つのアカウントレベルのサブスクリプションフィルターを含めることができます。ロググループごとに、最大 2 つのサブスクリプションフィルターを関連付けることができます。
**注記**
送信先のサービスが、スロットリングの例外や再試行可能なサービス例外 (HTTP 5xx など) の再試行可能なエラーを返した場合、CloudWatch Logs は最大 24 時間配信を再試行し続けます。AccessDeniedException や ResourceNotFoundException などの再試行不可能なエラーの場合、CloudWatch Logs は再配信を試みません。このような場合、サブスクリプションフィルターは最大 10 分間無効になり、CloudWatch Logs は送信先へのログの送信を再試行します。この無効化期間中、ログはスキップされます。
また、CloudWatch Logs は、サブスクリプションへのログイベントの転送に関する CloudWatch メトリクスを作成します。詳細については、「[CloudWatch メトリクスによるモニタリング](CloudWatch-Logs-Monitoring-CloudWatch-Metrics.md)」を参照してください。
CloudWatch Logs サブスクリプションを使用して、Amazon OpenSearch Service クラスターにほぼリアルタイムでログデータをストリーミングすることもできます。詳細については、「[Amazon OpenSearch Service への CloudWatch Logs データのストリーミング](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_OpenSearch_Stream.html)」を参照してください。
サブスクリプションは、標準ログクラスのロググループでのみサポートされます。ログクラスの詳細については、「[ログクラス](CloudWatch_Logs_Log_Classes.md)」を参照してください。
**注記**
サブスクリプションフィルターは、ログイベントをバッチ処理して送信を最適化し、送信先への呼び出しの量を減らすことができます。バッチ処理は必ず行われるわけではありませんが、可能な場合は使用されます。
スケジュールに従ってログデータをバッチ処理および分析するには、 の使用を検討してください[スケジュールされたクエリによるログ分析の自動化](ScheduledQueries.md)。スケジュールされたクエリは CloudWatch Logs Insights クエリを自動的に実行し、Amazon S3 バケットや Amazon EventBridge イベントバスなどの送信先に結果を配信します。
**注記**
サブスクリプションフィルターは、少なくとも 1 回イベントを確実に配信しますが、重複イベントが発生することがあります。
**Topics**
+ [概念](subscription-concepts.md)
+ [ロググループレベルのサブスクリプションフィルター](SubscriptionFilters.md)
+ [アカウントレベルのサブスクリプションフィルター](SubscriptionFilters-AccountLevel.md)
+ [クロスアカウント、クロスリージョンのサブスクリプション](CrossAccountSubscriptions.md)
+ [混乱した代理の防止](Subscriptions-confused-deputy.md)
+ [ログの再帰防止](Subscriptions-recursion-prevention.md)
# 概念
各サブスクリプションフィルタは以下のキー要素で構成されています。
**フィルタパターン**
CloudWatch Logs が各ログイベントのデータを解釈する方法のシンボリックな説明と、宛先 AWS リソースに配信される内容を制限するフィルタリング式。フィルタパターンの構文の詳細については、「[メトリクスフィルター、サブスクリプションフィルター、フィルターログイベント、およびライブテールのフィルターパターン構文](FilterAndPatternSyntax.md)」を参照してください。
**destination arn**
サブスクリプションフィードの送信先として使用する Amazon Kinesis Data Streams ストリーム、Firehose ストリーム、または Lambda 関数の Amazon リソースネーム (ARN)。
**role arn**
選択された宛先にデータを置くのに必要な権限を CloudWatch Logs に付与する IAM ロール。CloudWatch Logs は Lambda 関数自体のアクセスコントロール設定から必要なアクセス権限を取得できるため、Lambda の送信先にはこのロールは必要ありません。
**ディストリビューション**
送信先にログデータを配信するのに使用する方法。この場合、宛先は Amazon Kinesis Data Streams です。デフォルトでは、ログデータは、ログストリームによってグループ化されています。さらに詳細に分散する場合でも、ログデータはランダムにグループ化することができます。
ロググループレベルのサブスクリプションには、次のキー要素も含まれます。
**log group name**
サブスクリプションフィルタを関連付けるロググループ。このロググループにアップロードされたすべてのログイベントにはサブスクリプションフィルターが適用され、フィルターに一致するログイベントは、一致するログイベントを受信する宛先サービスに配信されます。
アカウントレベルのサブスクリプションには、次のキー要素も含まれます。
**選択基準**
アカウントレベルのサブスクリプションフィルターが適用されているロググループを選択するために使用される基準。これを指定しない場合、アカウントレベルのサブスクリプションフィルターは、アカウントのすべてのロググループに適用されます。このフィールドは、無限のログループを防ぐために使用します。無限ログループの問題の詳細については、「[ログの再帰防止](Subscriptions-recursion-prevention.md)」を参照してください。
選択基準のサイズ制限は 25 KB です。
一元化されたロググループには、次の主要な要素も含まれます。これらの要素は、ログデータのソースを識別するのに役立つフィールド選択基準として使用でき、一元化されたログから派生したメトリクスのフィルタリングと分析をさらに細かく行えるようになります。
**@aws.account**
このフィールドは、ログイベントの発生元の AWS アカウント ID を識別します。
**@aws.region**
このフィールドは、ログイベントが生成された AWS リージョンを識別します。
# ロググループレベルのサブスクリプションフィルター
Amazon Kinesis Data Streams、、Amazon Data Firehose AWS Lambda、または Amazon OpenSearch Service でサブスクリプションフィルターを使用できます。サブスクリプションフィルターを介してサービスに送信されるログは、base64 でエンコードされ、gzip 形式で圧縮されます。で集中ログを使用している場合は AWS Organizations、 `@aws.account`および `@aws.region`システムフィールドを出力して、組織内のどのアカウントとリージョンからどのデータを取得するかを特定できます。このセクションでは、Firehose、Lambda、Amazon Kinesis Data Streams、OpenSearch Service にログデータを送信する CloudWatch Logs サブスクリプションフィルターを作成する例を示します。
**注記**
ログデータを検索する場合は、「[Filter and pattern syntax](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/FilterAndPatternSyntax.html)」を参照してください。
**Topics**
+ [例 1: Amazon Kinesis Data Streams を使用したサブスクリプションフィルター](#DestinationKinesisExample)
+ [例 2: を使用したサブスクリプションフィルター AWS Lambda](#LambdaFunctionExample)
+ [例 3: Amazon Data Firehose を使用したサブスクリプションフィルター](#FirehoseExample)
+ [例 4: Amazon OpenSearch Service を使用したサブスクリプションフィルター](#OpenSearchExample)
## 例 1: Amazon Kinesis Data Streams を使用したサブスクリプションフィルター
次の例では、 AWS CloudTrail イベントを含むロググループにサブスクリプションフィルターを関連付けます。サブスクリプションフィルターは、「Root AWS 」認証情報によって行われたすべての記録されたアクティビティを、「RootAccess」と呼ばれる Amazon Kinesis Data Streams のストリームに配信します。RootAccess." CloudWatch Logs に AWS CloudTrail イベントを送信する方法の詳細については、*AWS CloudTrail 「 ユーザーガイド*[」のCloudTrail イベントを CloudWatch Logs に送信する](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cw_send_ct_events.html)」を参照してください。
**注記**
ストリームを作成する前に、生成するログデータのボリュームを計算します。このボリュームを処理するために十分なシャードで ストリームを作成するように注意してください。ストリームに十分なシャードがないと、ログストリームはスロットリングされます。ストリームボリューム制限に関する詳細は、「[クォータと制限](https://docs.aws.amazon.com/streams/latest/dev/service-sizes-and-limits.html)」を参照してください。
スロットリングされた成果物は、最大 24 時間再試行されます。24 時間が経過すると、失敗した成果物は破棄されます。
スロットリングのリスクを軽減するには、次のステップに従います。
[PutSubscriptionFilter](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutSubscriptionFilter.html#CWL-PutSubscriptionFilter-request-distribution) または [put-subscription-filter](https://awscli.amazonaws.com/v2/documentation/api/2.4.18/reference/logs/put-subscription-filter.html) を使用してサブスクリプションフィルターを作成するときは、`distribution` に `random` を指定します。デフォルトでは、ストリームフィルターディストリビューションはログストリームによって行われ、スロットリングが発生する可能性があります。
CloudWatch メトリクスを使用したストリームのモニタリング これにより、スロットリングを特定し、必要に応じて構成を調整できます。たとえば、`DeliveryThrottling` メトリクスを使用してデータをサブスクリプション送信先に転送するときに CloudWatch Logs がスロットルされたログイベントの数を追跡できます。モニタリングの詳細については、「[CloudWatch メトリクスによるモニタリング](CloudWatch-Logs-Monitoring-CloudWatch-Metrics.md)」をご参照ください。
Amazon Kinesis Data Streams のストリームにオンデマンドキャパシティモードを使用します。オンデマンドモードは、ワークロードが増加または縮小すると、即座にワークロードに対応します。オンデマンドキャパシティモードの詳細については、「[オンデマンドモード](https://docs.aws.amazon.com/streams/latest/dev/how-do-i-size-a-stream.html#ondemandmode)」を参照してください。
Amazon Kinesis Data Streams のストリームの容量と一致するように CloudWatch サブスクリプションフィルターパターンを制限します。ストリームに送信するデータが多すぎる場合、フィルターサイズを小さくするか、フィルター条件を調整する必要があります。
**Amazon Kinesis Data Streams のサブスクリプションフィルターを作成するには**
1. 次のコマンドを使用して送信先ストリームを作成します。
```
$ C:\> aws kinesis create-stream --stream-name "RootAccess" --shard-count 1
```
1. ストリームが [アクティブ] になるまで待ちます (これには 1～2 分かかる可能性があります)。次の Amazon Kinesis Data Streams [describe-stream](https://docs.aws.amazon.com/cli/latest/reference/kinesis/describe-stream.html) コマンドを使用して、**StreamDescription.StreamStatus** プロパティを確認できます。さらに、後のステップで必要になるため **StreamDescription.StreamARN** 値を書き留めます。
```
aws kinesis describe-stream --stream-name "RootAccess"
```
出力例を次に示します。
```
{
"StreamDescription": {
"StreamStatus": "ACTIVE",
"StreamName": "RootAccess",
"StreamARN": "arn:aws:kinesis:us-east-1:123456789012:stream/RootAccess",
"Shards": [
{
"ShardId": "shardId-000000000000",
"HashKeyRange": {
"EndingHashKey": "340282366920938463463374607431768211455",
"StartingHashKey": "0"
},
"SequenceNumberRange": {
"StartingSequenceNumber":
"49551135218688818456679503831981458784591352702181572610"
}
}
]
}
}
```
1. ストリームにデータを置くアクセス許可を CloudWatch Logs に付与する IAM ロールを作成します。まず、ファイル (`~/TrustPolicyForCWL-Kinesis.json` など) で信頼ポリシーを作成する必要があります。テキストエディタを使用してこのポリシーを作成します。IAM コンソールを使用してポリシーを作成しないでください。
このポリシーには、「混乱した代理」のセキュリティ上の問題を防止するための `aws:SourceArn` グローバル条件コンテキストキーが含まれています。詳細については、「[混乱した代理の防止](Subscriptions-confused-deputy.md)」を参照してください。
```
{
"Statement": {
"Effect": "Allow",
"Principal": { "Service": "logs.amazonaws.com" },
"Action": "sts:AssumeRole",
"Condition": {
"StringLike": { "aws:SourceArn": "arn:aws:logs:region:123456789012:*" }
}
}
}
```
1. **create-role** コマンドを使用し、信頼ポリシーファイルを指定して IAM ロールを作成します。後のステップで必要になるため、返された **Role.Arn** 値も書き留めます。
```
aws iam create-role --role-name CWLtoKinesisRole --assume-role-policy-document file://~/TrustPolicyForCWL-Kinesis.json
```
次は出力の例です。
```
{
"Role": {
"AssumeRolePolicyDocument": {
"Statement": {
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Principal": {
"Service": "logs.amazonaws.com"
},
"Condition": {
"StringLike": {
"aws:SourceArn": { "arn:aws:logs:region:123456789012:*" }
}
}
}
},
"RoleId": "AAOIIAH450GAB4HC5F431",
"CreateDate": "2015-05-29T13:46:29.431Z",
"RoleName": "CWLtoKinesisRole",
"Path": "/",
"Arn": "arn:aws:iam::123456789012:role/CWLtoKinesisRole"
}
}
```
1. 権限ポリシーを作成し、CloudWatch Logs がアカウントで実行できるアクションを定義します。まず、ファイル (`~/PermissionsForCWL-Kinesis.json` など) で権限ポリシーを作成します。テキストエディタを使用してこのポリシーを作成します。IAM コンソールを使用してポリシーを作成しないでください。
```
{
"Statement": [
{
"Effect": "Allow",
"Action": "kinesis:PutRecord",
"Resource": "arn:aws:kinesis:region:123456789012:stream/RootAccess"
}
]
}
```
1. 次の [put-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-policy.html) コマンドを使用して、アクセス許可ポリシーをロールに関連付けます。
```
aws iam put-role-policy --role-name CWLtoKinesisRole --policy-name Permissions-Policy-For-CWL --policy-document file://~/PermissionsForCWL-Kinesis.json
```
1. ストリームが [**アクティブ**] 状態になり、IAM ロールを作成したら、CloudWatch Logs サブスクリプションフィルタを作成できます。サブスクリプションフィルタにより、選択されたロググループから ストリームへのリアルタイムログデータの流れがすぐに開始されます。
```
aws logs put-subscription-filter \
--log-group-name "CloudTrail/logs" \
--filter-name "RootAccess" \
--filter-pattern "{$.userIdentity.type = Root}" \
--destination-arn "arn:aws:kinesis:region:123456789012:stream/RootAccess" \
--role-arn "arn:aws:iam::123456789012:role/CWLtoKinesisRole"
```
1. サブスクリプションフィルタを設定したら、CloudWatch Logs によりフィルタパターンに一致するすべての受信ログイベントがストリームに転送されます。Amazon Kinesis Data Streams シャードイテレーターを取得し、Amazon Kinesis Data Streams get-records コマンドを使用して Amazon Kinesis Data Streams レコードを取得することで、これが起こっていることを確認できます。
```
aws kinesis get-shard-iterator --stream-name RootAccess --shard-id shardId-000000000000 --shard-iterator-type TRIM_HORIZON
```
```
{
"ShardIterator":
"AAAAAAAAAAFGU/kLvNggvndHq2UIFOw5PZc6F01s3e3afsSscRM70JSbjIefg2ub07nk1y6CDxYR1UoGHJNP4m4NFUetzfL+wev+e2P4djJg4L9wmXKvQYoE+rMUiFq+p4Cn3IgvqOb5dRA0yybNdRcdzvnC35KQANoHzzahKdRGb9v4scv+3vaq+f+OIK8zM5My8ID+g6rMo7UKWeI4+IWiK2OSh0uP"
}
```
```
aws kinesis get-records --limit 10 --shard-iterator "AAAAAAAAAAFGU/kLvNggvndHq2UIFOw5PZc6F01s3e3afsSscRM70JSbjIefg2ub07nk1y6CDxYR1UoGHJNP4m4NFUetzfL+wev+e2P4djJg4L9wmXKvQYoE+rMUiFq+p4Cn3IgvqOb5dRA0yybNdRcdzvnC35KQANoHzzahKdRGb9v4scv+3vaq+f+OIK8zM5My8ID+g6rMo7UKWeI4+IWiK2OSh0uP"
```
Amazon Kinesis Data Streams がデータを返す前に、この呼び出しを数回行う必要がある場合があります。
レコードの配列を含むレスポンスが表示されます。Amazon Kinesis Data Streams レコードのデータ****属性は base64 でエンコードされ、gzip 形式で圧縮されます。raw データは、コマンドラインから次の UNIX コマンドを使用して調べることができます。
```
echo -n "" | base64 -d | zcat
```
base64 でデコードおよび解凍されたデータは、次の構造を使用して JSON としてフォーマットされます。
```
{
"owner": "111111111111",
"logGroup": "CloudTrail/logs",
"logStream": "111111111111_CloudTrail/logs_us-east-1",
"subscriptionFilters": [
"Destination"
],
"messageType": "DATA_MESSAGE",
"logEvents": [
{
"id": "31953106606966983378809025079804211143289615424298221568",
"timestamp": 1432826855000,
"message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}"
},
{
"id": "31953106606966983378809025079804211143289615424298221569",
"timestamp": 1432826855000,
"message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}"
},
{
"id": "31953106606966983378809025079804211143289615424298221570",
"timestamp": 1432826855000,
"message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}"
}
]
}
```
上のデータ構造の主な要素は次のとおりです。
**owner (オーナー)**
元のログデータの AWS アカウント ID。
**logGroup**
発行元ログデータのロググループ名。
**logStream**
発行元ログデータのログストリーム名。
**subscriptionFilters**
発行元ログデータと一致したサブスクリプションフィルタ名のリスト。
**messageType**
データメッセージは、"DATA\$1MESSAGE" 型を使用します。CloudWatch Logs は、主に送信先に到達可能かどうかを確認するために、「CONTROL\$1MESSAGE」タイプの Amazon Kinesis Data Streams レコードを出力することがあります。
**logEvents**
ログイベントレコードの配列として表される実際のログデータ。"id" プロパティは、各ログイベントの一意識別子です。
## 例 2: を使用したサブスクリプションフィルター AWS Lambda
この例では、ログデータを AWS Lambda 関数に送信する CloudWatch Logs サブスクリプションフィルターを作成します。
**注記**
Lambda 関数を作成する前に、生成するログデータのボリュームを計算します。このボリュームを処理できる関数を作成するように注意してください。関数に十分なボリュームがないと、ログストリームはスロットリングされます。Lambda の制限の詳細については、「[AWS Lambda の制限](https://docs.aws.amazon.com/lambda/latest/dg/limits.html)」を参照してください。
**Lambda のサブスクリプションフィルタを作成するには**
1. AWS Lambda 関数を作成します。
Lambda 実行ロールをセットアップ済みであることを確認します。詳細については、*AWS Lambda デベロッパーガイド*の「[ステップ 2.2: IAM ロール (実行ロール) を作成する](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html)」を参照してください。
1. テキストエディターを開き、以下の内容で `helloWorld.js` という名前のファイルを作成します。
```
var zlib = require('zlib');
exports.handler = function(input, context) {
var payload = Buffer.from(input.awslogs.data, 'base64');
zlib.gunzip(payload, function(e, result) {
if (e) {
context.fail(e);
} else {
result = JSON.parse(result.toString());
console.log("Event Data:", JSON.stringify(result, null, 2));
context.succeed();
}
});
};
```
1. helloWorld.js ファイルを圧縮して `helloWorld.zip` という名前で保存します。
1. 次のコマンドを使用します。ロールは、最初のステップで設定した Lambda 実行ロールです。
```
aws lambda create-function \
--function-name helloworld \
--zip-file fileb://file-path/helloWorld.zip \
--role lambda-execution-role-arn \
--handler helloWorld.handler \
--runtime nodejs12.x
```
1. CloudWatch Logs に、関数を実行するためのアクセス権限を付与します。次のコマンドを使用します。プレースホルダーは自身のアカウントに置き換え、プレースホルダーロググループは処理するロググループに置き換えます。
```
aws lambda add-permission \
--function-name "helloworld" \
--statement-id "helloworld" \
--principal "logs.amazonaws.com" \
--action "lambda:InvokeFunction" \
--source-arn "arn:aws:logs:region:123456789123:log-group:TestLambda:*" \
--source-account "123456789012"
```
1. 次のコマンドを使用してサブスクリプションフィルタを作成します。プレースホルダーアカウントは自身のアカウントに置き換え、プレースホルダーロググループは処理するロググループに置き換えます。
```
aws logs put-subscription-filter \
--log-group-name myLogGroup \
--filter-name demo \
--filter-pattern "" \
--destination-arn arn:aws:lambda:region:123456789123:function:helloworld
```
1. (オプション) サンプルのログイベントを使用してテストします。コマンドプロンプトで、次のコマンドを実行します。これにより、サブスクライブしたストリームに単純なログメッセージが送信されます。
Lambda 関数の出力を確認するには、Lambda 関数に移動して、/aws/lambda/helloworld にある出力を参照します。
```
aws logs put-log-events --log-group-name myLogGroup --log-stream-name stream1 --log-events "[{\"timestamp\": , \"message\": \"Simple Lambda Test\"}]"
```
Lambda の配列を含むレスポンスが表示されます。Lambda レコードの **[Data]** (データ) 属性は、base64 でエンコードされており、gzip 形式で圧縮されています。Lambda が受け取る実際のペイロードは、`{ "awslogs": {"data": "BASE64ENCODED_GZIP_COMPRESSED_DATA"} }` の形式になります。raw データは、コマンドラインから次の UNIX コマンドを使用して調べることができます。
```
echo -n "" | base64 -d | zcat
```
base64 でデコードおよび解凍されたデータは、次の構造を使用して JSON としてフォーマットされます。
```
{
"owner": "123456789012",
"logGroup": "CloudTrail",
"logStream": "123456789012_CloudTrail_us-east-1",
"subscriptionFilters": [
"Destination"
],
"messageType": "DATA_MESSAGE",
"logEvents": [
{
"id": "31953106606966983378809025079804211143289615424298221568",
"timestamp": 1432826855000,
"message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}"
},
{
"id": "31953106606966983378809025079804211143289615424298221569",
"timestamp": 1432826855000,
"message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}"
},
{
"id": "31953106606966983378809025079804211143289615424298221570",
"timestamp": 1432826855000,
"message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}"
}
]
}
```
上のデータ構造の主な要素は次のとおりです。
**owner (オーナー)**
元のログデータの AWS アカウント ID。
**logGroup**
発行元ログデータのロググループ名。
**logStream**
発行元ログデータのログストリーム名。
**subscriptionFilters**
発行元ログデータと一致したサブスクリプションフィルタ名のリスト。
**messageType**
データメッセージは、"DATA\$1MESSAGE" 型を使用します。CloudWatch Logs は、主に送信先が到達可能であるかどうかをチェックするために、"CONTROL\$1MESSAGE" 型の Lambda レコードを発行することがあります。
**logEvents**
ログイベントレコードの配列として表される実際のログデータ。"id" プロパティは、各ログイベントの一意識別子です。
## 例 3: Amazon Data Firehose を使用したサブスクリプションフィルター
この例では、CloudWatch Logs サブスクリプションを作成して、定義されたフィルターに一致する受信ログイベントを Amazon Data Firehose 配信ストリームに送信します。CloudWatch Logs から Amazon Data Firehose に送信されたデータは、既に gzip レベル 6 圧縮で圧縮されているため、Firehose 配信ストリーム内で圧縮を使用する必要はありません。その後、Firehose の解凍機能を使用して、ログを自動的に解凍できます。詳細については、「[CloudWatch Logs を Firehose に送信する](https://docs.aws.amazon.com/logs/SubscriptionFilters.html#FirehoseExample)」を参照してください。
**注記**
Firehose ストリームを作成する前に、生成するログデータのボリュームを計算します。このボリュームを処理できる Firehose ストリームを作成するように注意してください。ストリームがこのボリュームを処理できない場合、ログストリームはスロットリングされます。Firehose ストリームボリュームの制限事項の詳細については、「[Amazon Data Firehose Data Limits](https://docs.aws.amazon.com/firehose/latest/dev/limits.html)」をご参照ください。
**Firehose のサブスクリプションフィルターを作成するには**
1. Amazon Simple Storage Service (Amazon S3) バケットを作成します。CloudWatch Logs 専用に作成したバケットを使用することをお勧めします。ただし、既存のバケットを使用する場合は、ステップ 2 に進みます。
次のコマンドを実行します。プレースホルダーリージョンは、使用するリージョンに置き換えます。
```
aws s3api create-bucket --bucket amzn-s3-demo-bucket2 --create-bucket-configuration LocationConstraint=region
```
出力例を次に示します。
```
{
"Location": "/amzn-s3-demo-bucket2"
}
```
1. Amazon S3 バケットにデータを置くためのアクセス許可を Amazon Data Firehose に付与する IAM ロールを作成します。
詳細については、「*Amazon Data Firehose 開発者ガイド*」の「[Controlling Access with Amazon Data Firehose](https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html)」を参照してください。
まず、テキストエディタを使用して、次のようにファイル `~/TrustPolicyForFirehose.json` で信頼ポリシーを作成します。
```
{
"Statement": {
"Effect": "Allow",
"Principal": { "Service": "firehose.amazonaws.com" },
"Action": "sts:AssumeRole"
}
}
```
1. **create-role** コマンドを使用し、信頼ポリシーファイルを指定して IAM ロールを作成します。後のステップで必要になるため、返された **Role.Arn** 値を書き留めます。
```
aws iam create-role \
--role-name FirehosetoS3Role \
--assume-role-policy-document file://~/TrustPolicyForFirehose.json
{
"Role": {
"AssumeRolePolicyDocument": {
"Statement": {
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Principal": {
"Service": "firehose.amazonaws.com"
}
}
},
"RoleId": "AAOIIAH450GAB4HC5F431",
"CreateDate": "2015-05-29T13:46:29.431Z",
"RoleName": "FirehosetoS3Role",
"Path": "/",
"Arn": "arn:aws:iam::123456789012:role/FirehosetoS3Role"
}
}
```
1. アクセス許可ポリシーを作成し、Firehose がアカウントで実行できるアクションを定義します。まず、テキストエディタを使用してファイル `~/PermissionsForFirehose.json` で権限ポリシーを作成します。
```
{
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:AbortMultipartUpload",
"s3:GetBucketLocation",
"s3:GetObject",
"s3:ListBucket",
"s3:ListBucketMultipartUploads",
"s3:PutObject" ],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket2",
"arn:aws:s3:::amzn-s3-demo-bucket2/*" ]
}
]
}
```
1. 次の put-role-policy コマンドを使用して、アクセス許可ポリシーをロールに関連付けます。
```
aws iam put-role-policy --role-name FirehosetoS3Role --policy-name Permissions-Policy-For-Firehose --policy-document file://~/PermissionsForFirehose.json
```
1. 次のように、送信先 Firehose 配信ストリームを作成します。**RoleARN** と **BucketARN** のプレースホルダー値を、作成したロールおよびバケット ARN に置き換えます。
```
aws firehose create-delivery-stream \
--delivery-stream-name 'my-delivery-stream' \
--s3-destination-configuration \
'{"RoleARN": "arn:aws:iam::123456789012:role/FirehosetoS3Role", "BucketARN": "arn:aws:s3:::amzn-s3-demo-bucket2"}'
```
Firehose は、配信された Amazon S3 オブジェクトに対して、YYYY/MM/DD/HH UTC 時間形式のプレフィックスを自動的に使用することに注意してください。時間形式プレフィックスの前に、追加のプレフィックスを指定できます。プレフィックスの最後がフォワードスラッシュ (/) の場合は、Amazon S3 バケット内のフォルダとして表示されます。
1. ストリームがアクティブになるまで待ちます (これには数分かかる可能性があります)。Firehose **describe-delivery-stream** コマンドを使用して、**DeliveryStreamDescription.DeliveryStreamStatus** プロパティをチェックできます。さらに、後のステップで必要になるため、**DeliveryStreamDescription.DeliveryStreamARN** 値を書き留めます。
```
aws firehose describe-delivery-stream --delivery-stream-name "my-delivery-stream"
{
"DeliveryStreamDescription": {
"HasMoreDestinations": false,
"VersionId": "1",
"CreateTimestamp": 1446075815.822,
"DeliveryStreamARN": "arn:aws:firehose:us-east-1:123456789012:deliverystream/my-delivery-stream",
"DeliveryStreamStatus": "ACTIVE",
"DeliveryStreamName": "my-delivery-stream",
"Destinations": [
{
"DestinationId": "destinationId-000000000001",
"S3DestinationDescription": {
"CompressionFormat": "UNCOMPRESSED",
"EncryptionConfiguration": {
"NoEncryptionConfig": "NoEncryption"
},
"RoleARN": "delivery-stream-role",
"BucketARN": "arn:aws:s3:::amzn-s3-demo-bucket2",
"BufferingHints": {
"IntervalInSeconds": 300,
"SizeInMBs": 5
}
}
}
]
}
}
```
1. Firehose 配信ストリームにデータを置くためのアクセス許可を CloudWatch Logs に付与する IAM ロールを作成します。まず、テキストエディタを使用してファイル `~/TrustPolicyForCWL.json` で信頼ポリシーを作成します。
このポリシーには、「混乱した代理」のセキュリティ上の問題を防止するための `aws:SourceArn` グローバル条件コンテキストキーが含まれています。詳細については、「[混乱した代理の防止](Subscriptions-confused-deputy.md)」を参照してください。
```
{
"Statement": {
"Effect": "Allow",
"Principal": { "Service": "logs.amazonaws.com" },
"Action": "sts:AssumeRole",
"Condition": {
"StringLike": {
"aws:SourceArn": "arn:aws:logs:region:123456789012:*"
}
}
}
}
```
1. **create-role** コマンドを使用し、信頼ポリシーファイルを指定して IAM ロールを作成します。後のステップで必要になるため、返された **Role.Arn** 値を書き留めます。
```
aws iam create-role \
--role-name CWLtoKinesisFirehoseRole \
--assume-role-policy-document file://~/TrustPolicyForCWL.json
{
"Role": {
"AssumeRolePolicyDocument": {
"Statement": {
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Principal": {
"Service": "logs.amazonaws.com"
},
"Condition": {
"StringLike": {
"aws:SourceArn": "arn:aws:logs:region:123456789012:*"
}
}
}
},
"RoleId": "AAOIIAH450GAB4HC5F431",
"CreateDate": "2015-05-29T13:46:29.431Z",
"RoleName": "CWLtoKinesisFirehoseRole",
"Path": "/",
"Arn": "arn:aws:iam::123456789012:role/CWLtoKinesisFirehoseRole"
}
}
```
1. 権限ポリシーを作成し、CloudWatch Logs がアカウントで実行できるアクションを定義します。まず、テキストエディタを使用して権限ポリシーファイル (例: `~/PermissionsForCWL.json`) を作成します。
```
{
"Statement":[
{
"Effect":"Allow",
"Action":["firehose:PutRecord"],
"Resource":[
"arn:aws:firehose:region:account-id:deliverystream/delivery-stream-name"]
}
]
}
```
1. put-role-policy コマンドを使用して、権限ポリシーをロールに関連付けます。
```
aws iam put-role-policy --role-name CWLtoKinesisFirehoseRole --policy-name Permissions-Policy-For-CWL --policy-document file://~/PermissionsForCWL.json
```
1. Amazon Data Firehose 配信ストリームがアクティブ状態になり、IAM ロールを作成したら、CloudWatch Logs サブスクリプションフィルターを作成できます。サブスクリプションフィルターにより、選択されたロググループから Amazon Data Firehose 配信ストリームへのリアルタイムログデータのフローがすぐに開始されます。
```
aws logs put-subscription-filter \
--log-group-name "CloudTrail" \
--filter-name "Destination" \
--filter-pattern "{$.userIdentity.type = Root}" \
--destination-arn "arn:aws:firehose:region:123456789012:deliverystream/my-delivery-stream" \
--role-arn "arn:aws:iam::123456789012:role/CWLtoKinesisFirehoseRole"
```
1. サブスクリプションフィルターを設定したら、CloudWatch Logs からフィルタパターンに一致するすべての受信ログイベントが Amazon Data Firehose 配信ストリームに転送されます。Amazon Data Firehose 配信ストリームに設定された時間バッファ間隔に基づいて、Amazon S3 にデータが表示されるようになります。十分な時間が経過すると、Amazon S3 バケットをチェックしてデータを確認できます。
```
aws s3api list-objects --bucket 'amzn-s3-demo-bucket2' --prefix 'firehose/'
{
"Contents": [
{
"LastModified": "2015-10-29T00:01:25.000Z",
"ETag": "\"a14589f8897f4089d3264d9e2d1f1610\"",
"StorageClass": "STANDARD",
"Key": "firehose/2015/10/29/00/my-delivery-stream-2015-10-29-00-01-21-a188030a-62d2-49e6-b7c2-b11f1a7ba250",
"Owner": {
"DisplayName": "cloudwatch-logs",
"ID": "1ec9cf700ef6be062b19584e0b7d84ecc19237f87b5"
},
"Size": 593
},
{
"LastModified": "2015-10-29T00:35:41.000Z",
"ETag": "\"a7035b65872bb2161388ffb63dd1aec5\"",
"StorageClass": "STANDARD",
"Key": "firehose/2015/10/29/00/my-delivery-stream-2015-10-29-00-35-40-7cc92023-7e66-49bc-9fd4-fc9819cc8ed3",
"Owner": {
"DisplayName": "cloudwatch-logs",
"ID": "1ec9cf700ef6be062b19584e0b7d84ecc19237f87b6"
},
"Size": 5752
}
]
}
```
```
aws s3api get-object --bucket 'amzn-s3-demo-bucket2' --key 'firehose/2015/10/29/00/my-delivery-stream-2015-10-29-00-01-21-a188030a-62d2-49e6-b7c2-b11f1a7ba250' testfile.gz
{
"AcceptRanges": "bytes",
"ContentType": "application/octet-stream",
"LastModified": "Thu, 29 Oct 2015 00:07:06 GMT",
"ContentLength": 593,
"Metadata": {}
}
```
Simple Storage Service (Amazon S3) オブジェクトのデータは、gzip 形式で圧縮されます。raw データは、コマンドラインから次の UNIX コマンドを使用して調べることができます。
```
zcat testfile.gz
```
## 例 4: Amazon OpenSearch Service を使用したサブスクリプションフィルター
この例では、CloudWatch Logs サブスクリプションを作成して、定義されたフィルターに一致する受信ログイベントを OpenSearch Service ドメインに送信します。
**OpenSearch Service のサブスクリプションフィルターを作成するには**
1. OpenSearch Service ドメインを作成します。詳細については、「[OpenSearch Service ドメインの作成](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/createupdatedomains.html#createdomains)」を参照してください。
1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。
1. ナビゲーションペインで、**[Log groups]** (ロググループ) を選択します。
1. ロググループの名前を選択します。
1. **[Actions]** (アクション)、**[Subscription filters]** (サブスクリプションフィルター)、**[Create Amazon OpenSearch Service subscription filter]** (Amazon OpenSearch Service サブスクリプションフィルターを作成) の順に選択します。
1. このアカウントのクラスターにストリーミングするか、別のアカウントにストリーミングするかを選択します。
+ **[このアカウント]** を選択した場合は、ステップ 1 で作成したドメインを選択します。
+ **[別のアカウント]** を選択した場合は、そのドメインの ARN とエンドポイントを入力します。
1. 別のアカウントを選択した場合は、ドメイン ARN とエンドポイントを指定します。
1. Amazon OpenSearch Service クラスターの場合、ロググループデータが配信されるクラスターの名前を選択します。
1. ログ形式を選択します。
1. [**サブスクリプションフィルターのパターン**] に、ログイベントで検索する用語やパターンを入力します。これにより、関心のあるデータだけが OpenSearch Service クラスターに送信されるようになります。詳細については、「[メトリクスフィルターのフィルターパターン構文](FilterAndPatternSyntaxForMetricFilters.md)」を参照してください。
1. (オプション) [**Select log data to test**] (テストするログデータの選択) を開き、ログストリームを選択してから、[**Test pattern**] (パターンをテスト) を選択して、期待通りの結果が出ることを確認します。
1. [**Start streaming**] (ストリーミングの開始) を選択します。
# アカウントレベルのサブスクリプションフィルター
**重要**
サブスクリプションフィルターで無限の再帰ループが発生するリスクがあり、対処しなければ取り込みにかかる料金が大幅に増加する可能性があります。このリスクを軽減するには、アカウントレベルのサブスクリプションフィルターで選択基準を使用して、サブスクリプション配信ワークフローの一部であるリソースからログデータを取り込むロググループを除外することをお勧めします。この問題および除外するロググループを判断する方法については、「[ログの再帰防止](Subscriptions-recursion-prevention.md)」を参照してください。
アカウント内のロググループのサブセットを含むアカウントレベルのサブスクリプションポリシーを設定できます。アカウントサブスクリプションポリシーは、Amazon Kinesis Data Streams AWS Lambda、または Amazon Data Firehose と連携できます。アカウントレベルのサブスクリプションポリシーを介してサービスに送信されるログは、base64 でエンコードされ、gzip 形式で圧縮されます。このセクションでは、Amazon Kinesis Data Streams、Lambda、Firehose のアカウントレベルのサブスクリプションを作成するための例を示します。
**注記**
アカウント内のすべてのサブスクリプションフィルターポリシーのリストを表示するには、`--policy-type` パラメータに `SUBSCRIPTION_FILTER_POLICY` の値を持つ `describe-account-policies` コマンドを使用します。詳細については、「[describe-account-policies](https://docs.aws.amazon.com/cli/latest/reference/logs/describe-account-policies.html)」を参照してください。
**Topics**
+ [例 1: Amazon Kinesis Data Streams を使用したサブスクリプションフィルター](#DestinationKinesisExample-AccountLevel)
+ [例 2: を使用したサブスクリプションフィルター AWS Lambda](#LambdaFunctionExample-AccountLevel)
+ [例 3: Amazon Data Firehose を使用したサブスクリプションフィルター](#FirehoseExample-AccountLevel)
## 例 1: Amazon Kinesis Data Streams を使用したサブスクリプションフィルター
アカウントレベルのサブスクリプションポリシーで使用する Amazon Kinesis Data Streams データストリームを作成する前に、生成されるログデータのボリュームを計算します。このボリュームを処理するために十分なシャードで ストリームを作成するように注意してください。ストリームに十分なシャードがない場合は、スロットリングされます。ストリームボリュームの制限の詳細については、Amazon Kinesis Data Streams ドキュメント[の「クォータと制限](https://docs.aws.amazon.com/streams/latest/dev/service-sizes-and-limits.html)」を参照してください。
**警告**
複数のロググループのログイベントは宛先に転送されるため、スロットリングのリスクがあります。スロットリングされた成果物は、最大 24 時間再試行されます。24 時間が経過すると、失敗した成果物は破棄されます。
スロットリングのリスクを軽減するには、次のステップに従います。
CloudWatch メトリクスを使用して Amazon Kinesis Data Streams ストリームをモニタリングします。これにより、スロットリングを特定し、必要に応じて構成を調整することができます。例えば、`DeliveryThrottling` メトリクスはデータをサブスクリプション送信先に転送するときに CloudWatch Logs がスロットリングされたログイベントの数を追跡できます。詳細については、「[CloudWatch メトリクスによるモニタリング](CloudWatch-Logs-Monitoring-CloudWatch-Metrics.md)」を参照してください。
Amazon Kinesis Data Streams のストリームにオンデマンドキャパシティモードを使用します。オンデマンドモードは、ワークロードが増加または縮小すると、即座にワークロードに対応します。詳細については、「[On-demand mode](https://docs.aws.amazon.com/streams/latest/dev/how-do-i-size-a-stream.html#ondemandmode)」をご参照ください。
Amazon Kinesis Data Streams のストリームの容量と一致するように CloudWatch Logs サブスクリプションフィルターパターンを制限します。ストリームに送信するデータが多すぎる場合、フィルターサイズを小さくするか、フィルター条件を調整する必要があります。
次の例では、アカウントレベルのサブスクリプションポリシーを使用して、すべてのログイベントを Amazon Kinesis Data Streams のストリームに転送します。フィルターパターンは、すべてのログイベントをテキストと照合`Test`し、Amazon Kinesis Data Streams のストリームに転送します。
**Amazon Kinesis Data Streams のアカウントレベルのサブスクリプションポリシーを作成するには**
1. 次のコマンドを使用して送信先ストリームを作成します。
```
$ C:\> aws kinesis create-stream —stream-name "TestStream" —shard-count 1
```
1. ストリームがアクティブになるまで数分待ちます。ストリームがアクティブ化どうか確認するには、[describe-stream](https://docs.aws.amazon.com/cli/latest/reference/kinesis/describe-stream.html) コマンドを使用して、**StreamDescription.StreamStatus** プロパティをチェックできます。
```
aws kinesis describe-stream --stream-name "TestStream"
```
出力例を次に示します。
```
{
"StreamDescription": {
"StreamStatus": "ACTIVE",
"StreamName": "TestStream",
"StreamARN": "arn:aws:kinesis:region:123456789012:stream/TestStream",
"Shards": [
{
"ShardId": "shardId-000000000000",
"HashKeyRange": {
"EndingHashKey": "EXAMPLE8463463374607431768211455",
"StartingHashKey": "0"
},
"SequenceNumberRange": {
"StartingSequenceNumber":
"EXAMPLE688818456679503831981458784591352702181572610"
}
}
]
}
}
```
1. ストリームにデータを置くアクセス許可を CloudWatch Logs に付与する IAM ロールを作成します。まず、ファイル (`~/TrustPolicyForCWL-Kinesis.json` など) で信頼ポリシーを作成する必要があります。テキストエディタを使用してこのポリシーを作成します。
このポリシーには、「混乱した代理」のセキュリティ上の問題を防止するための `aws:SourceArn` グローバル条件コンテキストキーが含まれています。詳細については、「[混乱した代理の防止](Subscriptions-confused-deputy.md)」を参照してください。
```
{
"Statement": {
"Effect": "Allow",
"Principal": { "Service": "logs.amazonaws.com" },
"Action": "sts:AssumeRole",
"Condition": {
"StringLike": { "aws:SourceArn": "arn:aws:logs:region:123456789012:*" }
}
}
}
```
1. **create-role** コマンドを使用し、信頼ポリシーファイルを指定して IAM ロールを作成します。後のステップで必要になるため、返された **Role.Arn** 値も書き留めます。
```
aws iam create-role --role-name CWLtoKinesisRole --assume-role-policy-document file://~/TrustPolicyForCWL-Kinesis.json
```
次は出力の例です。
```
{
"Role": {
"AssumeRolePolicyDocument": {
"Statement": {
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Principal": {
"Service": "logs.amazonaws.com"
},
"Condition": {
"StringLike": {
"aws:SourceArn": { "arn:aws:logs:region:123456789012:*" }
}
}
}
},
"RoleId": "EXAMPLE450GAB4HC5F431",
"CreateDate": "2023-05-29T13:46:29.431Z",
"RoleName": "CWLtoKinesisRole",
"Path": "/",
"Arn": "arn:aws:iam::123456789012:role/CWLtoKinesisRole"
}
}
```
1. 権限ポリシーを作成し、CloudWatch Logs がアカウントで実行できるアクションを定義します。まず、ファイル (`~/PermissionsForCWL-Kinesis.json` など) で権限ポリシーを作成します。テキストエディタを使用してこのポリシーを作成します。IAM コンソールを使用してポリシーを作成しないでください。
```
{
"Statement": [
{
"Effect": "Allow",
"Action": "kinesis:PutRecord",
"Resource": "arn:aws:kinesis:region:123456789012:stream/TestStream"
}
]
}
```
1. 次の [put-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-policy.html) コマンドを使用して、アクセス許可ポリシーをロールに関連付けます。
```
aws iam put-role-policy --role-name CWLtoKinesisRole --policy-name Permissions-Policy-For-CWL --policy-document file://~/PermissionsForCWL-Kinesis.json
```
1. ストリームが **[アクティブ]** 状態になり、IAM ロールを作成したら、CloudWatch Logs サブスクリプションフィルターポリシーを作成できます。ポリシーは、ストリームへのリアルタイムログデータのフローをすぐに開始します。この例では、文字列 `ERROR` を含むすべてのログイベントがストリーミングされます。ただし、`LogGroupToExclude1` および `LogGroupToExclude2` という名前のロググループ内のイベントは除外されます。
```
aws logs put-account-policy \
--policy-name "ExamplePolicy" \
--policy-type "SUBSCRIPTION_FILTER_POLICY" \
--policy-document '{"RoleArn":"arn:aws:iam::123456789012:role/CWLtoKinesisRole", "DestinationArn":"arn:aws:kinesis:region:123456789012:stream/TestStream", "FilterPattern": "Test", "Distribution": "Random"}' \
--selection-criteria 'LogGroupName NOT IN ["LogGroupToExclude1", "LogGroupToExclude2"]' \
--scope "ALL"
```
1. サブスクリプションフィルターを設定したら、CloudWatch Logs によりフィルタパターンと選択基準に一致するすべての受信ログイベントがストリームに転送されます。
`selection-criteria` フィールドはオプションですが、サブスクリプションフィルターから無限のログ再帰を引き起こす可能性のあるロググループを除外するための重要なフィールドです。この問題および除外するロググループを判断する方法については、「[ログの再帰防止](Subscriptions-recursion-prevention.md)」を参照してください。現在、NOT IN は `selection-criteria` でサポートされている唯一の演算子です。
Amazon Kinesis Data Streams シャードイテレーターを使用し、Amazon Kinesis Data Streams `get-records` コマンドを使用して Amazon Kinesis Amazon Kinesis Data Streams レコードを取得することで、ログイベントのフローを確認できます。
```
aws kinesis get-shard-iterator --stream-name TestStream --shard-id shardId-000000000000 --shard-iterator-type TRIM_HORIZON
```
```
{
"ShardIterator":
"AAAAAAAAAAFGU/kLvNggvndHq2UIFOw5PZc6F01s3e3afsSscRM70JSbjIefg2ub07nk1y6CDxYR1UoGHJNP4m4NFUetzfL+wev+e2P4djJg4L9wmXKvQYoE+rMUiFq+p4Cn3IgvqOb5dRA0yybNdRcdzvnC35KQANoHzzahKdRGb9v4scv+3vaq+f+OIK8zM5My8ID+g6rMo7UKWeI4+IWiK2OSh0uP"
}
```
```
aws kinesis get-records --limit 10 --shard-iterator "AAAAAAAAAAFGU/kLvNggvndHq2UIFOw5PZc6F01s3e3afsSscRM70JSbjIefg2ub07nk1y6CDxYR1UoGHJNP4m4NFUetzfL+wev+e2P4djJg4L9wmXKvQYoE+rMUiFq+p4Cn3IgvqOb5dRA0yybNdRcdzvnC35KQANoHzzahKdRGb9v4scv+3vaq+f+OIK8zM5My8ID+g6rMo7UKWeI4+IWiK2OSh0uP"
```
Amazon Kinesis Data Streams がデータを返す前に、このコマンドを数回使用する必要がある場合があります。
レコードの配列を含むレスポンスが表示されます。Amazon Kinesis Data Streams レコードのデータ****属性は base64 でエンコードされ、gzip 形式で圧縮されます。raw データは、コマンドラインから次の UNIX コマンドを使用して調べることができます。
```
echo -n "" | base64 -d | zcat
```
base64 でデコードおよび解凍されたデータは、次の構造を使用して JSON としてフォーマットされます。
```
{
"messageType": "DATA_MESSAGE",
"owner": "123456789012",
"logGroup": "Example1",
"logStream": "logStream1",
"subscriptionFilters": [
"ExamplePolicy"
],
"logEvents": [
{
"id": "31953106606966983378809025079804211143289615424298221568",
"timestamp": 1432826855000,
"message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}"
},
{
"id": "31953106606966983378809025079804211143289615424298221569",
"timestamp": 1432826855000,
"message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}"
},
{
"id": "31953106606966983378809025079804211143289615424298221570",
"timestamp": 1432826855000,
"message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}"
}
],
"policyLevel": "ACCOUNT_LEVEL_POLICY"
}
```
データ構造の主な要素は次のとおりです。
**messageType**
データメッセージは、"DATA\$1MESSAGE" 型を使用します。CloudWatch Logs は、主に送信先に到達可能かどうかを確認するために、「CONTROL\$1MESSAGE」タイプの Amazon Kinesis Data Streams レコードを出力することがあります。
**owner (オーナー)**
元のログデータの AWS アカウント ID。
**logGroup**
発行元ログデータのロググループ名。
**logStream**
発行元ログデータのログストリーム名。
**subscriptionFilters**
発行元ログデータと一致したサブスクリプションフィルタ名のリスト。
**logEvents**
ログイベントレコードの配列として表される実際のログデータ。"id" プロパティは、各ログイベントの一意識別子です。
**policyLevel**
ポリシーが適用されたレベル。「ACCOUNT\$1LEVEL\$1POLICY」は、アカウントレベルのサブスクリプションフィルターポリシーの `policyLevel` です。
## 例 2: を使用したサブスクリプションフィルター AWS Lambda
この例では、ログデータを AWS Lambda 関数に送信する CloudWatch Logs アカウントレベルのサブスクリプションフィルターポリシーを作成します。
**警告**
Lambda 関数を作成する前に、生成するログデータのボリュームを計算します。このボリュームを処理できる関数を作成するように注意してください。関数がこのボリュームを処理できない場合、ログストリームはスロットリングされます。すべてのロググループまたはアカウントのロググループのサブセットのログイベントは送信先に転送されるため、スロットリングのリスクがあります。Lambda の制限の詳細については、「[AWS Lambda の制限](https://docs.aws.amazon.com/lambda/latest/dg/limits.html)」を参照してください。
**Lambda のアカウントレベルのサブスクリプションフィルターポリシーを作成するには**
1. AWS Lambda 関数を作成します。
Lambda 実行ロールをセットアップ済みであることを確認します。詳細については、*AWS Lambda デベロッパーガイド*の「[ステップ 2.2: IAM ロール (実行ロール) を作成する](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html)」を参照してください。
1. テキストエディターを開き、以下の内容で `helloWorld.js` という名前のファイルを作成します。
```
var zlib = require('zlib');
exports.handler = function(input, context) {
var payload = Buffer.from(input.awslogs.data, 'base64');
zlib.gunzip(payload, function(e, result) {
if (e) {
context.fail(e);
} else {
result = JSON.parse(result.toString());
console.log("Event Data:", JSON.stringify(result, null, 2));
context.succeed();
}
});
};
```
1. helloWorld.js ファイルを圧縮して `helloWorld.zip` という名前で保存します。
1. 次のコマンドを使用します。ロールは、最初のステップで設定した Lambda 実行ロールです。
```
aws lambda create-function \
--function-name helloworld \
--zip-file fileb://file-path/helloWorld.zip \
--role lambda-execution-role-arn \
--handler helloWorld.handler \
--runtime nodejs18.x
```
1. CloudWatch Logs に、関数を実行するためのアクセス権限を付与します。次のコマンドを使用して、プレースホルダーアカウントを独自のアカウントに置き換えます。
```
aws lambda add-permission \
--function-name "helloworld" \
--statement-id "helloworld" \
--principal "logs.amazonaws.com" \
--action "lambda:InvokeFunction" \
--source-arn "arn:aws:logs:region:123456789012:log-group:*" \
--source-account "123456789012"
```
1. 次のコマンドを使用してアカウントレベルのサブスクリプションフィルターポリシーを作成し、プレースホルダーアカウントを独自のアカウントに置き換えます。この例では、文字列 `ERROR` を含むすべてのログイベントがストリーミングされます。ただし、`LogGroupToExclude1` および `LogGroupToExclude2` という名前のロググループ内のイベントは除外されます。
```
aws logs put-account-policy \
--policy-name "ExamplePolicyLambda" \
--policy-type "SUBSCRIPTION_FILTER_POLICY" \
--policy-document '{"DestinationArn":"arn:aws:lambda:region:123456789012:function:helloWorld", "FilterPattern": "Test", "Distribution": "Random"}' \
--selection-criteria 'LogGroupName NOT IN ["LogGroupToExclude1", "LogGroupToExclude2"]' \
--scope "ALL"
```
サブスクリプションフィルターを設定したら、CloudWatch Logs によりフィルタパターンと選択基準に一致するすべての受信ログイベントがストリームに転送されます。
`selection-criteria` フィールドはオプションですが、サブスクリプションフィルターから無限のログ再帰を引き起こす可能性のあるロググループを除外するための重要なフィールドです。この問題および除外するロググループを判断する方法については、「[ログの再帰防止](Subscriptions-recursion-prevention.md)」を参照してください。現在、NOT IN は `selection-criteria` でサポートされている唯一の演算子です。
1. (オプション) サンプルのログイベントを使用してテストします。コマンドプロンプトで、次のコマンドを実行します。これにより、サブスクライブしたストリームに単純なログメッセージが送信されます。
Lambda 関数の出力を確認するには、Lambda 関数に移動して、/aws/lambda/helloworld にある出力を参照します。
```
aws logs put-log-events --log-group-name Example1 --log-stream-name logStream1 --log-events "[{\"timestamp\":CURRENT TIMESTAMP MILLIS , \"message\": \"Simple Lambda Test\"}]"
```
Lambda の配列を含むレスポンスが表示されます。Lambda レコードの **[Data]** (データ) 属性は、base64 でエンコードされており、gzip 形式で圧縮されています。Lambda が受け取る実際のペイロードは、`{ "awslogs": {"data": "BASE64ENCODED_GZIP_COMPRESSED_DATA"} }` の形式になります。raw データは、コマンドラインから次の UNIX コマンドを使用して調べることができます。
```
echo -n "" | base64 -d | zcat
```
base64 でデコードおよび解凍されたデータは、次の構造を使用して JSON としてフォーマットされます。
```
{
"messageType": "DATA_MESSAGE",
"owner": "123456789012",
"logGroup": "Example1",
"logStream": "logStream1",
"subscriptionFilters": [
"ExamplePolicyLambda"
],
"logEvents": [
{
"id": "31953106606966983378809025079804211143289615424298221568",
"timestamp": 1432826855000,
"message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}"
},
{
"id": "31953106606966983378809025079804211143289615424298221569",
"timestamp": 1432826855000,
"message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}"
},
{
"id": "31953106606966983378809025079804211143289615424298221570",
"timestamp": 1432826855000,
"message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}"
}
],
"policyLevel": "ACCOUNT_LEVEL_POLICY"
}
```
**注記**
アカウントレベルのサブスクリプションフィルターは、送信先の Lambda 関数のロググループには適用されません。これは、取り込み料金の増加につながる可能性のある無限のログ再帰を防ぐためです。この問題の詳細については、「[ログの再帰防止](Subscriptions-recursion-prevention.md)」を参照してください。
データ構造の主な要素は次のとおりです。
**messageType**
データメッセージは、"DATA\$1MESSAGE" 型を使用します。CloudWatch Logs は、主に送信先に到達可能かどうかを確認するために、「CONTROL\$1MESSAGE」タイプの Amazon Kinesis Data Streams レコードを出力することがあります。
**owner (オーナー)**
元のログデータの AWS アカウント ID。
**logGroup**
発行元ログデータのロググループ名。
**logStream**
発行元ログデータのログストリーム名。
**subscriptionFilters**
発行元ログデータと一致したサブスクリプションフィルタ名のリスト。
**logEvents**
ログイベントレコードの配列として表される実際のログデータ。"id" プロパティは、各ログイベントの一意識別子です。
**policyLevel**
ポリシーが適用されたレベル。「ACCOUNT\$1LEVEL\$1POLICY」は、アカウントレベルのサブスクリプションフィルターポリシーの `policyLevel` です。
## 例 3: Amazon Data Firehose を使用したサブスクリプションフィルター
この例では、CloudWatch Logs のアカウントレベルのサブスクリプションフィルターポリシーを作成して、定義されたフィルタに一致する受信ログイベントを Amazon Data Firehose 配信ストリームに送信します。CloudWatch Logs から Amazon Data Firehose に送信されたデータは、既に gzip レベル 6 圧縮で圧縮されているため、Firehose 配信ストリーム内で圧縮を使用する必要はありません。その後、Firehose の解凍機能を使用して、ログを自動的に解凍できます。詳細については、「[Writing to Kinesis Data Firehose Using CloudWatch Logs](https://docs.aws.amazon.com/firehose/latest/dev/writing-with-cloudwatch-logs.html)」を参照してください。
**警告**
Firehose ストリームを作成する前に、生成するログデータのボリュームを計算します。このボリュームを処理できる Firehose ストリームを作成するように注意してください。ストリームがこのボリュームを処理できない場合、ログストリームはスロットリングされます。Firehose ストリームボリュームの制限事項の詳細については、「[Amazon Data Firehose Data Limits](https://docs.aws.amazon.com/firehose/latest/dev/limits.html)」をご参照ください。
**Firehose のサブスクリプションフィルターを作成するには**
1. Amazon Simple Storage Service (Amazon S3) バケットを作成します。CloudWatch Logs 専用に作成したバケットを使用することをお勧めします。ただし、既存のバケットを使用する場合は、ステップ 2 に進みます。
次のコマンドを実行します。プレースホルダーリージョンは、使用するリージョンに置き換えます。
```
aws s3api create-bucket --bucket amzn-s3-demo-bucket2 --create-bucket-configuration LocationConstraint=region
```
出力例を次に示します。
```
{
"Location": "/amzn-s3-demo-bucket2"
}
```
1. Amazon S3 バケットにデータを置くためのアクセス許可を Amazon Data Firehose に付与する IAM ロールを作成します。
詳細については、「*Amazon Data Firehose 開発者ガイド*」の「[Controlling Access with Amazon Data Firehose](https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html)」を参照してください。
まず、テキストエディタを使用して、次のようにファイル `~/TrustPolicyForFirehose.json` で信頼ポリシーを作成します。
```
{
"Statement": {
"Effect": "Allow",
"Principal": { "Service": "firehose.amazonaws.com" },
"Action": "sts:AssumeRole"
}
}
```
1. **create-role** コマンドを使用し、信頼ポリシーファイルを指定して IAM ロールを作成します。後のステップで必要になるため、返された **Role.Arn** 値を書き留めます。
```
aws iam create-role \
--role-name FirehosetoS3Role \
--assume-role-policy-document file://~/TrustPolicyForFirehose.json
{
"Role": {
"AssumeRolePolicyDocument": {
"Statement": {
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Principal": {
"Service": "firehose.amazonaws.com"
}
}
},
"RoleId": "EXAMPLE50GAB4HC5F431",
"CreateDate": "2023-05-29T13:46:29.431Z",
"RoleName": "FirehosetoS3Role",
"Path": "/",
"Arn": "arn:aws:iam::123456789012:role/FirehosetoS3Role"
}
}
```
1. アクセス許可ポリシーを作成し、Firehose がアカウントで実行できるアクションを定義します。まず、テキストエディタを使用してファイル `~/PermissionsForFirehose.json` で権限ポリシーを作成します。
```
{
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:AbortMultipartUpload",
"s3:GetBucketLocation",
"s3:GetObject",
"s3:ListBucket",
"s3:ListBucketMultipartUploads",
"s3:PutObject" ],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket2",
"arn:aws:s3:::amzn-s3-demo-bucket2/*" ]
}
]
}
```
1. 次の put-role-policy コマンドを使用して、アクセス許可ポリシーをロールに関連付けます。
```
aws iam put-role-policy --role-name FirehosetoS3Role --policy-name Permissions-Policy-For-Firehose --policy-document file://~/PermissionsForFirehose.json
```
1. 次のように、送信先 Firehose 配信ストリームを作成します。**RoleARN** と **BucketARN** のプレースホルダー値を、作成したロールおよびバケット ARN に置き換えます。
```
aws firehose create-delivery-stream \
--delivery-stream-name 'my-delivery-stream' \
--s3-destination-configuration \
'{"RoleARN": "arn:aws:iam::123456789012:role/FirehosetoS3Role", "BucketARN": "arn:aws:s3:::amzn-s3-demo-bucket2"}'
```
NFirehose は、配信された Amazon S3 オブジェクトに対して、YYYY/MM/DD/HH UTC 時間形式のプレフィックスを自動的に使用します。時間形式プレフィックスの前に、追加のプレフィックスを指定できます。プレフィックスの最後がフォワードスラッシュ (/) の場合は、Amazon S3 バケット内のフォルダとして表示されます。
1. ストリームがアクティブになるまで数分待ちます。Firehose **describe-delivery-stream** コマンドを使用して、**DeliveryStreamDescription.DeliveryStreamStatus** プロパティをチェックできます。さらに、後のステップで必要になるため、**DeliveryStreamDescription.DeliveryStreamARN** 値を書き留めます。
```
aws firehose describe-delivery-stream --delivery-stream-name "my-delivery-stream"
{
"DeliveryStreamDescription": {
"HasMoreDestinations": false,
"VersionId": "1",
"CreateTimestamp": 1446075815.822,
"DeliveryStreamARN": "arn:aws:firehose:us-east-1:123456789012:deliverystream/my-delivery-stream",
"DeliveryStreamStatus": "ACTIVE",
"DeliveryStreamName": "my-delivery-stream",
"Destinations": [
{
"DestinationId": "destinationId-000000000001",
"S3DestinationDescription": {
"CompressionFormat": "UNCOMPRESSED",
"EncryptionConfiguration": {
"NoEncryptionConfig": "NoEncryption"
},
"RoleARN": "delivery-stream-role",
"BucketARN": "arn:aws:s3:::amzn-s3-demo-bucket2",
"BufferingHints": {
"IntervalInSeconds": 300,
"SizeInMBs": 5
}
}
}
]
}
}
```
1. Firehose 配信ストリームにデータを置くためのアクセス許可を CloudWatch Logs に付与する IAM ロールを作成します。まず、テキストエディタを使用してファイル `~/TrustPolicyForCWL.json` で信頼ポリシーを作成します。
このポリシーには、「混乱した代理」のセキュリティ上の問題を防止するための `aws:SourceArn` グローバル条件コンテキストキーが含まれています。詳細については、「[混乱した代理の防止](Subscriptions-confused-deputy.md)」を参照してください。
```
{
"Statement": {
"Effect": "Allow",
"Principal": { "Service": "logs.amazonaws.com" },
"Action": "sts:AssumeRole",
"Condition": {
"StringLike": {
"aws:SourceArn": "arn:aws:logs:region:123456789012:*"
}
}
}
}
```
1. **create-role** コマンドを使用し、信頼ポリシーファイルを指定して IAM ロールを作成します。後のステップで必要になるため、返された **Role.Arn** 値を書き留めます。
```
aws iam create-role \
--role-name CWLtoKinesisFirehoseRole \
--assume-role-policy-document file://~/TrustPolicyForCWL.json
{
"Role": {
"AssumeRolePolicyDocument": {
"Statement": {
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Principal": {
"Service": "logs.amazonaws.com"
},
"Condition": {
"StringLike": {
"aws:SourceArn": "arn:aws:logs:region:123456789012:*"
}
}
}
},
"RoleId": "AAOIIAH450GAB4HC5F431",
"CreateDate": "2015-05-29T13:46:29.431Z",
"RoleName": "CWLtoKinesisFirehoseRole",
"Path": "/",
"Arn": "arn:aws:iam::123456789012:role/CWLtoKinesisFirehoseRole"
}
}
```
1. 権限ポリシーを作成し、CloudWatch Logs がアカウントで実行できるアクションを定義します。まず、テキストエディタを使用して権限ポリシーファイル (例: `~/PermissionsForCWL.json`) を作成します。
```
{
"Statement":[
{
"Effect":"Allow",
"Action":["firehose:PutRecord"],
"Resource":[
"arn:aws:firehose:region:account-id:deliverystream/delivery-stream-name"]
}
]
}
```
1. put-role-policy コマンドを使用して、権限ポリシーをロールに関連付けます。
```
aws iam put-role-policy --role-name CWLtoKinesisFirehoseRole --policy-name Permissions-Policy-For-CWL --policy-document file://~/PermissionsForCWL.json
```
1. Amazon Data Firehose 配信ストリームがアクティブ状態になり、IAM ロールを作成したら、CloudWatch Logs のアカウントレベルのサブスクリプションフィルタポリシーを作成できます。ポリシーにより、選択されたロググループから Amazon Data Firehose 配信ストリームへのリアルタイムログデータのフローがすぐに開始されます。
```
aws logs put-account-policy \
--policy-name "ExamplePolicyFirehose" \
--policy-type "SUBSCRIPTION_FILTER_POLICY" \
--policy-document '{"RoleArn":"arn:aws:iam::123456789012:role/CWLtoKinesisFirehoseRole", "DestinationArn":"arn:aws:firehose:us-east-1:123456789012:deliverystream/delivery-stream-name", "FilterPattern": "Test", "Distribution": "Random"}' \
--selection-criteria 'LogGroupName NOT IN ["LogGroupToExclude1", "LogGroupToExclude2"]' \
--scope "ALL"
```
1. サブスクリプションフィルターを設定したら、CloudWatch Logs からフィルターパターンに一致するすべての受信ログイベントが Amazon Data Firehose 配信ストリームに転送されます。
`selection-criteria` フィールドはオプションですが、サブスクリプションフィルターから無限のログ再帰を引き起こす可能性のあるロググループを除外するための重要なフィールドです。この問題および除外するロググループを判断する方法については、「[ログの再帰防止](Subscriptions-recursion-prevention.md)」を参照してください。現在、NOT IN は `selection-criteria` でサポートされている唯一の演算子です。
Amazon Data Firehose 配信ストリームに設定された時間バッファ間隔に基づいて、Amazon S3 にデータが表示されるようになります。十分な時間が経過すると、Amazon S3 バケットをチェックしてデータを確認できます。
```
aws s3api list-objects --bucket 'amzn-s3-demo-bucket2' --prefix 'firehose/'
{
"Contents": [
{
"LastModified": "2023-10-29T00:01:25.000Z",
"ETag": "\"a14589f8897f4089d3264d9e2d1f1610\"",
"StorageClass": "STANDARD",
"Key": "firehose/2015/10/29/00/my-delivery-stream-2015-10-29-00-01-21-a188030a-62d2-49e6-b7c2-b11f1a7ba250",
"Owner": {
"DisplayName": "cloudwatch-logs",
"ID": "1ec9cf700ef6be062b19584e0b7d84ecc19237f87b5"
},
"Size": 593
},
{
"LastModified": "2015-10-29T00:35:41.000Z",
"ETag": "\"a7035b65872bb2161388ffb63dd1aec5\"",
"StorageClass": "STANDARD",
"Key": "firehose/2023/10/29/00/my-delivery-stream-2023-10-29-00-35-40-EXAMPLE-7e66-49bc-9fd4-fc9819cc8ed3",
"Owner": {
"DisplayName": "cloudwatch-logs",
"ID": "EXAMPLE6be062b19584e0b7d84ecc19237f87b6"
},
"Size": 5752
}
]
}
```
```
aws s3api get-object --bucket 'amzn-s3-demo-bucket2' --key 'firehose/2023/10/29/00/my-delivery-stream-2023-10-29-00-01-21-a188030a-62d2-49e6-b7c2-b11f1a7ba250' testfile.gz
{
"AcceptRanges": "bytes",
"ContentType": "application/octet-stream",
"LastModified": "Thu, 29 Oct 2023 00:07:06 GMT",
"ContentLength": 593,
"Metadata": {}
}
```
Simple Storage Service (Amazon S3) オブジェクトのデータは、gzip 形式で圧縮されます。raw データは、コマンドラインから次の UNIX コマンドを使用して調べることができます。
```
zcat testfile.gz
```
# クロスアカウント、クロスリージョンのサブスクリプション
別の AWS アカウントの所有者と協力して、Amazon Kinesis または Amazon Data Firehose ストリーム (これはクロスアカウントデータ共有と呼ばれます) などの AWS リソースでログイベントを受信できます。たとえば、このログイベントデータは、一元化された Amazon Kinesis Data Streams または Firehose ストリームから読み取り、カスタム処理と分析を実行できます。カスタム処理は、多数のアカウントが協力しデータを分析する場合に特に便利です。
たとえば、ある会社の情報セキュリティグループがリアルタイムで侵入または異常な挙動を検出するためにデータを分析するとします。この場合、会社の全部署のアカウントのフェデレーションされた本稼働ログを中央処理のために収集することによって、これらのアカウントの監査を行うことができます。これらのアカウント全体のイベントデータのリアルタイムストリームをアセンブルして情報セキュリティグループに配信できます。情報セキュリティグループは、Amazon Kinesis Data Streams を使用して既存のセキュリティ分析システムにデータをアタッチできます。
**注記**
ロググループと送信先は同じ AWS リージョンにある必要があります。ただし、送信先が指す AWS リソースは、別のリージョンに配置することができます。次のセクションの例では、リージョン固有のリソースはすべて米国東部 (バージニア北部) で作成されます。
メンバーアカウントを設定 AWS Organizations して操作している場合は、ログの一元化を使用して、ソースアカウントから中央モニタリングアカウントにログデータを収集できます。
一元化されたロググループを使用する場合は、サブスクリプションフィルターを作成する際にこれらのシステムフィールドのディメンションを使用できます。
+ `@aws.account` - このディメンションは、ログイベントの発生元の AWS アカウント ID を表します。
+ `@aws.region` - このディメンションは、ログイベントが生成された AWS リージョンを表します。
これらのディメンションはログデータのソースを特定するのに役立ちます。これにより、一元化されたログから派生したメトリクスのフィルタリングと分析をさらに細かく行えるようになります。
**Topics**
+ [Amazon Kinesis Data Streams を使用したクロスアカウントクロスリージョンログデータ共有](CrossAccountSubscriptions-Kinesis.md)
+ [Firehose を使用したクロスアカウント、クロスリージョンのログデータ共有](CrossAccountSubscriptions-Firehose.md)
+ [Amazon Kinesis Data Streams を使用したクロスアカウントクロスリージョンアカウントレベルのサブスクリプション](CrossAccountSubscriptions-Kinesis-Account.md)
+ [Firehose を使用したクロスアカウント、クロスリージョン、アカウントレベルのサブスクリプション](CrossAccountSubscriptions-Firehose-Account.md)
# Amazon Kinesis Data Streams を使用したクロスアカウントクロスリージョンログデータ共有
クロスアカウントサブスクリプションを作成するときに、単一のアカウントまたは組織を送信者として指定できます。組織を指定した場合、この手順により組織内のすべてのアカウントがレシーバーアカウントにログを送信できるようになります。
複数のアカウントでログデータを共有するには、ログデータの送信者と受信者を確立する必要があります。
+ **[Log data sender] **(ログデータの送信者) — 受信者から送信先情報を取得し、そのログイベントを特定の送信先に送信する準備が完了していることを CloudWatch Logs に通知します。このセクションの残りの手順では、ログデータ送信者は架空の AWS アカウント番号 111111111111 で表示されます。
1 つの組織で複数のアカウントを 1 つの受信者アカウントにログを送信する場合は、組織内のすべてのアカウントに対して受信者アカウントにログを送信するアクセス許可を付与するポリシーを作成することができます。引き続き、送信者アカウントごとに個別のサブスクリプションフィルターを設定する必要があります。
+ **ログデータ受信者** - Amazon Kinesis Data Streams ストリームをカプセル化する送信先を設定し、受信者がログデータを受信したいことを CloudWatch Logs に知らせます。この後、受信者は自分の送信先に関する情報を送信者と共有します。このセクションの残りの手順では、ログデータ受信者は架空の AWS アカウント番号 999999999999 で表示されます。
クロスアカウントのユーザーからのログイベントの受け取りを開始するには、ログデータの受取人がまず CloudWatch Logs 送信先を作成する必要があります。各送信先は以下のキー要素で構成されています。
**送信先名**
作成する送信先の名前。
**ターゲット ARN**
サブスクリプションフィードの送信先として使用するリソースの Amazon AWS リソースネーム (ARN)。
**ロールの ARN**
選択したストリームにデータを配置するために必要なアクセス許可を CloudWatch Logs に付与する AWS Identity and Access Management (IAM) ロール。
**アクセスポリシー**
送信先に書き込むことが許可されている一連のユーザーを管理する IAM ポリシードキュメント (IAM ポリシー構文を使用して記述された JSON 形式のドキュメント）。
**注記**
ロググループと送信先は同じ AWS リージョンにある必要があります。ただし、送信先が指す AWS リソースは、別のリージョンに配置することができます。次のセクションの例では、リージョン固有のリソースはすべて米国東部 (バージニア北部) で作成されます。
**Topics**
+ [新しいクロスアカウントサブスクリプションの設定](Cross-Account-Log_Subscription-New.md)
+ [既存のクロスアカウントサブスクリプションの更新](Cross-Account-Log_Subscription-Update.md)
# 新しいクロスアカウントサブスクリプションの設定
次のセクションの手順に従って、新しいクロスアカウントログサブスクリプションを設定します。
**Topics**
+ [ステップ 1: 送信先を作成する](CreateDestination.md)
+ [ステップ 2: IAM ロールを作成する (組織を使用している場合のみ)](CreateSubscriptionFilter-IAMrole.md)
+ [ステップ 3: クロスアカウント宛先の IAM アクセス許可を追加/検証する](Subscription-Filter-CrossAccount-Permissions.md)
+ [ステップ 4: サブスクリプションフィルターを作成する](CreateSubscriptionFilter.md)
+ [ログイベントの送信を検証](ValidateLogEventFlow.md)
+ [ランタイムの送信先のメンバーシップを変更](ModifyDestinationMembership.md)
# ステップ 1: 送信先を作成する
**重要**
この手順のステップは、ログデータの受取人アカウントで行われます。
この例では、ログデータ受信者アカウントの AWS アカウント ID は 999999999999 で、ログデータ送信者 AWS アカウント ID は 111111111111 です。
この例では、RecipientStream という Amazon Kinesis Data Streams ストリームと、CloudWatch Logs によるデータの書き込みを可能にするロールを使用して送信先を作成します。
送信先が作成されると、CloudWatch Logs は受信者アカウントに代わってテストメッセージを宛先に送信します。サブスクリプションフィルターが後でアクティブになると、CloudWatch Logs はソースアカウントに代わってログイベントを宛先に送信します。
**送信先を作成するには**
1. 受信者アカウントで、Amazon Kinesis Data Streams で送信先ストリームを作成します。コマンドプロンプトで、次のように入力します。
```
aws kinesis create-stream --stream-name "RecipientStream" --shard-count 1
```
1. ストリームがアクティブになるまで待ちます。**aws kinesis describe-stream** コマンドを使用して、**StreamDescription.StreamStatus** プロパティをチェックできます。さらに、**StreamDescription.StreamARN** の値は、後で CloudWatch Logs に渡すので書き留めておいてください。
```
aws kinesis describe-stream --stream-name "RecipientStream"
{
"StreamDescription": {
"StreamStatus": "ACTIVE",
"StreamName": "RecipientStream",
"StreamARN": "arn:aws:kinesis:us-east-1:999999999999:stream/RecipientStream",
"Shards": [
{
"ShardId": "shardId-000000000000",
"HashKeyRange": {
"EndingHashKey": "34028236692093846346337460743176EXAMPLE",
"StartingHashKey": "0"
},
"SequenceNumberRange": {
"StartingSequenceNumber": "4955113521868881845667950383198145878459135270218EXAMPLE"
}
}
]
}
}
```
ストリームがアクティブ状態で表示されるまでに 1～2 分かかる場合があります。
1. ストリームにデータを置くアクセス権限を CloudWatch Logs に付与する IAM ロールを作成します。まず、ファイル **\$1/TrustPolicyForCWL.json** で信頼ポリシーを作成する必要があります。このポリシーの作成にはテキストエディタを使用します。IAM コンソールは使用しないでください。
このポリシーには、「混乱した代理」のセキュリティ上の問題を防止するための `sourceAccountId` が指定された `aws:SourceArn` グローバル条件コンテキストキーが含まれています。最初の呼び出しでソースアカウント ID が不明な場合は、送信元 ARN フィールドに送信先 ARN を指定することをお勧めします。後続の呼び出しでは、送信元 ARN を、最初の呼び出しで取得した実際の送信元 ARN に設定する必要があります。詳細については、「[混乱した代理の防止](Subscriptions-confused-deputy.md)」を参照してください。
```
{
"Statement": {
"Effect": "Allow",
"Principal": {
"Service": "logs.amazonaws.com"
},
"Condition": {
"StringLike": {
"aws:SourceArn": [
"arn:aws:logs:region:sourceAccountId:*",
"arn:aws:logs:region:recipientAccountId:*"
]
}
},
"Action": "sts:AssumeRole"
}
}
```
1. **aws iam create-role** コマンドを使用して、信頼ポリシーファイルを指定する IAM ロールを作成します。返された Role.Arn 値を書き留めておきます。これも後で CloudWatch Logs に渡されるからです。
```
aws iam create-role \
--role-name CWLtoKinesisRole \
--assume-role-policy-document file://~/TrustPolicyForCWL.json
{
"Role": {
"AssumeRolePolicyDocument": {
"Statement": {
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Condition": {
"StringLike": {
"aws:SourceArn": [
"arn:aws:logs:region:sourceAccountId:*",
"arn:aws:logs:region:recipientAccountId:*"
]
}
},
"Principal": {
"Service": "logs.amazonaws.com"
}
}
},
"RoleId": "AAOIIAH450GAB4HC5F431",
"CreateDate": "2015-05-29T13:46:29.431Z",
"RoleName": "CWLtoKinesisRole",
"Path": "/",
"Arn": "arn:aws:iam::999999999999:role/CWLtoKinesisRole"
}
}
```
1. CloudWatch Logs がアカウントで実行できるアクションを定義するアクセス許可ポリシーを作成します。まず、テキストエディタを使用してファイル **\$1/PermissionsForCWL.json** でアクセス許可ポリシーを作成します。
```
{
"Statement": [
{
"Effect": "Allow",
"Action": "kinesis:PutRecord",
"Resource": "arn:aws:kinesis:region:999999999999:stream/RecipientStream"
}
]
}
```
1. **aws iam put-role-policy** コマンドを使用して、アクセス許可ポリシーをロールに関連付けます。
```
aws iam put-role-policy \
--role-name CWLtoKinesisRole \
--policy-name Permissions-Policy-For-CWL \
--policy-document file://~/PermissionsForCWL.json
```
1. ストリームがアクティブ状態になり、IAM ロールが作成されたら、CloudWatch Logs の送信先を作成できます。
1. このステップでは、アクセスポリシーと送信先は関連付けられません。送信先の作成を完了するには 2 つのステップを行う必要がありますが、このステップはその最初のステップです。ペイロードで返された **DestinationArn** を書き留めておいてください。
```
aws logs put-destination \
--destination-name "testDestination" \
--target-arn "arn:aws:kinesis:region:999999999999:stream/RecipientStream" \
--role-arn "arn:aws:iam::999999999999:role/CWLtoKinesisRole"
{
"DestinationName" : "testDestination",
"RoleArn" : "arn:aws:iam::999999999999:role/CWLtoKinesisRole",
"DestinationArn" : "arn:aws:logs:us-east-1:999999999999:destination:testDestination",
"TargetArn" : "arn:aws:kinesis:us-east-1:999999999999:stream/RecipientStream"
}
```
1. ステップ 7a が完了したら、ログデータの受取人アカウントで、アクセスポリシーを送信先に関連付けます。このポリシーでは、送信者アカウントが送信先にアクセスするためのアクセス許可が付与され、**logs:PutSubscriptionFilter** アクションが指定されている必要があります。
このポリシーは、ログを送信する AWS アカウントにアクセス許可を付与します。ポリシーの中で対象のアカウントを 1 つだけ指定してもよいですが、送信者アカウントが組織のメンバーのものである場合は組織 ID を指定することもできます。このように、ポリシーを 1 つ作成するだけで、1 つの組織内の複数のアカウントが送信先アカウントにログを送信できるように設定できます。
テキストエディタを使用して `~/AccessPolicy.json` という名前のファイルを作成し、以下のいずれかのポリシーステートメントを使用します。
この最初の例のポリシーでは、組織内で `o-1234567890` という ID を持つすべてのアカウントが、受信者アカウントにログを送信することを許可します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": "*",
"Action": "logs:PutSubscriptionFilter",
"Resource": "arn:aws:logs:us-east-1:999999999999:destination:testDestination",
"Condition": {
"StringEquals": {
"aws:PrincipalOrgID": [
"o-1234567890"
]
}
}
}
]
}
```
------
次の例では、ログデータの送信者アカウント (111111111111) がログデータの受信者アカウントにログを送信できるようにします。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"AWS": "111111111111"
},
"Action": "logs:PutSubscriptionFilter",
"Resource": "arn:aws:logs:us-east-1:999999999999:destination:testDestination"
}
]
}
```
------
1. 前のステップで作成したポリシーを送信先に添付します。
```
aws logs put-destination-policy \
--destination-name "testDestination" \
--access-policy file://~/AccessPolicy.json
```
このアクセスポリシーにより、ID 111111111111 の AWS アカウントのユーザーは、ARN arn:aws:logs:*region*:999999999999:destination:testDestination の送信先に対して **PutSubscriptionFilter** を呼び出すことができます。他のユーザーがこの送信先に対して PutSubscriptionFilter を呼び出そうとしても、それは却下されます。
アクセスポリシーに照らし合わせてユーザーの権限を検証するには、「*IAM ユーザーガイド*」の「[Using Policy Validator](https://docs.aws.amazon.com/IAM/latest/UserGuide/policies_policy-validator.html)」(Policy Validator の使用) を参照してください。
完了したら、クロスアカウントアクセス許可 AWS Organizations に を使用している場合は、「」の手順に従います[ステップ 2: IAM ロールを作成する (組織を使用している場合のみ)](CreateSubscriptionFilter-IAMrole.md)。組織を使用せずに他のアカウントに直接アクセス許可を付与する場合は、そのステップを飛ばして「[ステップ 4: サブスクリプションフィルターを作成する](CreateSubscriptionFilter.md)」に進みます。
# ステップ 2: IAM ロールを作成する (組織を使用している場合のみ)
前のセクションで アカウント `111111111111` に直接アクセス許可を付与するのではなく、アカウント `111111111111` が属する組織にアクセス許可を付与するアクセスポリシーを使用することにより送信先を作成した場合は、このセクションのステップを実行します。それ以外の場合は、「[ステップ 4: サブスクリプションフィルターを作成する](CreateSubscriptionFilter.md)」に進みます。
このセクションのステップにより、CloudWatch が想定する IAM ロールを作成し、送信者アカウントが受信者の送信先に対してサブスクリプションフィルターを作成する権限を持っているかどうかを検証できます。
このセクションの手順は、送信者アカウントで実行してください。ロールは送信者アカウントに存在する必要があり、このロールの ARN はサブスクリプションフィルターで指定します。この例では、送信者アカウントは `111111111111` です。
**を使用してクロスアカウントログサブスクリプションに必要な IAM ロールを作成するには AWS Organizations**
1. 以下の信頼ポリシーを作成し、`/TrustPolicyForCWLSubscriptionFilter.json` という名前のテキストファイルに保存します。このポリシーの作成にはテキストエディタを使用します。IAM コンソールは使用しないでください。
```
{
"Statement": {
"Effect": "Allow",
"Principal": { "Service": "logs.amazonaws.com" },
"Action": "sts:AssumeRole"
}
}
```
1. このポリシーを使用する IAM ロールを作成します。下記のコマンドが返す `Arn` の値は後ほど必要になるため、書き留めておきます。この例では、作成するロールに `CWLtoSubscriptionFilterRole` という名前を付けます。
```
aws iam create-role \
--role-name CWLtoSubscriptionFilterRole \
--assume-role-policy-document file://~/TrustPolicyForCWLSubscriptionFilter.json
```
1. アクセス許可ポリシーを作成して、CloudWatch Logs がアカウントで実行できるアクションを定義します。
1. まず、テキストエディタを使用して、`~/PermissionsForCWLSubscriptionFilter.json` という名前のファイルに以下のようなアクセス許可ポリシーを作成します。
```
{
"Statement": [
{
"Effect": "Allow",
"Action": "logs:PutLogEvents",
"Resource": "arn:aws:logs:region:111111111111:log-group:LogGroupOnWhichSubscriptionFilterIsCreated:*"
}
]
}
```
1. 次のコマンドを入力して、先ほど作成したアクセス許可ポリシーを、ステップ 2 で作成したロールに関連付けます。
```
aws iam put-role-policy
--role-name CWLtoSubscriptionFilterRole
--policy-name Permissions-Policy-For-CWL-Subscription-filter
--policy-document file://~/PermissionsForCWLSubscriptionFilter.json
```
終了したら、「[ステップ 4: サブスクリプションフィルターを作成する](CreateSubscriptionFilter.md)」に進みます。
# ステップ 3: クロスアカウント宛先の IAM アクセス許可を追加/検証する
AWS クロスアカウントポリシーの評価ロジックに従って、クロスアカウントリソース (サブスクリプションフィルターの送信先として使用される Kinesis または Firehose ストリームなど) にアクセスするには、クロスアカウントの送信先リソースへの明示的なアクセスを提供する ID ベースのポリシーを送信アカウントに含める必要があります。ポリシーの評価論理の詳細については、「[クロスアカウントポリシーの評価論理](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html)」を参照してください。
ID ベースのポリシーは、サブスクリプションフィルターの作成に使用している IAM ロールまたは IAM ユーザーにアタッチできます。送信アカウントにこのポリシーが存在する必要があります。管理者ロールを使用してサブスクリプションフィルタを作成している場合は、このステップをスキップして [ステップ 4: サブスクリプションフィルターを作成する](CreateSubscriptionFilter.md) に進んでください。
**クロスアカウントに必要な IAM アクセス許可を追加または検証するには**
1. 次のコマンドを入力して、 AWS ログコマンドの実行に使用されている IAM ロールまたは IAM ユーザーを確認します。
```
aws sts get-caller-identity
```
このコマンドにより、以下のような出力が返されます。
```
{
"UserId": "User ID",
"Account": "sending account id",
"Arn": "arn:aws:sending account id:role/user:RoleName/UserName"
}
```
*RoleName* または *UserName* で表される値を書き留めておいてください。
1. 送信アカウント AWS マネジメントコンソール で にサインインし、ステップ 1 で入力したコマンドの出力で返された IAM ロールまたは IAM ユーザーを使用して、アタッチされたポリシーを検索します。
1. このロールまたはユーザーにアタッチされたポリシーが、クロスアカウントの宛先リソースで `logs:PutSubscriptionFilter` を呼び出すための明示的なアクセス許可が付与されていることを確認します。
次のポリシーは、1 つの AWS アカウント、アカウント でのみ、任意の送信先リソースにサブスクリプションフィルターを作成するアクセス許可を提供します`999999999999`。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowSubscriptionFiltersOnAccountResources",
"Effect": "Allow",
"Action": "logs:PutSubscriptionFilter",
"Resource": [
"arn:aws:logs:*:*:log-group:*",
"arn:aws:logs:*:123456789012:destination:*"
]
}
]
}
```
------
次のポリシーは、単一の AWS アカウント、アカウント `sampleDestination`で という名前の特定の送信先リソースに対してのみサブスクリプションフィルターを作成するアクセス許可を提供します`123456789012`。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowSubscriptionFiltersonAccountResource",
"Effect": "Allow",
"Action": "logs:PutSubscriptionFilter",
"Resource": [
"arn:aws:logs:*:*:log-group:*",
"arn:aws:logs:*:123456789012:destination:sampleDestination"
]
}
]
}
```
------
# ステップ 4: サブスクリプションフィルターを作成する
送信先を作成したら、ログデータの受信者アカウントは、送信先の ARN (arn:aws:logs:us-east-1:999999999999:destination:testDestination) を他の AWS アカウントと共有できるようになります。これにより、これらのアカウントは同じ送信先にログイベントを送信できます。この後、これらの他の送信アカウントのユーザーは、この送信先に対するサブスクリプションフィルタをそれぞれのロググループに作成します。サブスクリプションフィルタは、特定のロググループから特定の送信先へのリアルタイムログデータの送信をすぐに開始します。
**注記**
サブスクリプションフィルターのためのアクセス許可を組織全体に付与する際は、[ステップ 2: IAM ロールを作成する (組織を使用している場合のみ)](CreateSubscriptionFilter-IAMrole.md) で作成した IAM ロールの ARN を使用する必要があります。
次の例では、サブスクリプションフィルターが送信アカウントに作成されます。フィルターはイベントを含む AWS CloudTrail ロググループに関連付けられ、「ルート AWS 」認証情報によって行われたすべてのログアクティビティが、以前に作成した送信先に配信されます。この送信先は、「RecipientStream」という ストリームをカプセル化します。
以降のセクションの残りのステップは、「AWS CloudTrail ユーザーガイド**」の「[CloudWatch Logs への CloudTrail イベントの送信](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/send-cloudtrail-events-to-cloudwatch-logs.html)」の指示に従って、CloudTrail イベントを含むロググループが作成済みであることを前提としています。そのステップでは、ロググループに `CloudTrail/logs` という名前を付けることになっています。
次のコマンドを入力するときは、必ず IAM ユーザーとしてサインインしているか、[ステップ 3: クロスアカウント宛先の IAM アクセス許可を追加/検証する](Subscription-Filter-CrossAccount-Permissions.md) にポリシーを追加した IAM ロールを使用してサインインしていることを確認してください。
```
aws logs put-subscription-filter \
--log-group-name "CloudTrail/logs" \
--filter-name "RecipientStream" \
--filter-pattern "{$.userIdentity.type = Root}" \
--destination-arn "arn:aws:logs:region:999999999999:destination:testDestination"
```
ロググループと送信先は同じ AWS リージョンにある必要があります。ただし、送信先は、別のリージョンにある Amazon Kinesis Data Streams ストリームなどの AWS リソースを指すことができます。
# ログイベントの送信を検証
サブスクリプションフィルタを作成したら、CloudWatch Logs が、フィルタパターンと一致するすべての受信ログイベントを、送信先ストリーム内でカプセル化されている「**RecipientStream**」という名前のストリームに転送します。送信先所有者は、**aws kinesis get-shard-iterator** コマンドを使用して Amazon Kinesis Data Streams シャードを取得し、**aws kinesis get-records** コマンドを使用して Amazon Kinesis Data Streams レコードを取得することで、これが起こっていることを確認できます。
```
aws kinesis get-shard-iterator \
--stream-name RecipientStream \
--shard-id shardId-000000000000 \
--shard-iterator-type TRIM_HORIZON
{
"ShardIterator":
"AAAAAAAAAAFGU/kLvNggvndHq2UIFOw5PZc6F01s3e3afsSscRM70JSbjIefg2ub07nk1y6CDxYR1UoGHJNP4m4NFUetzfL+wev+e2P4djJg4L9wmXKvQYoE+rMUiFq+p4Cn3IgvqOb5dRA0yybNdRcdzvnC35KQANoHzzahKdRGb9v4scv+3vaq+f+OIK8zM5My8ID+g6rMo7UKWeI4+IWiKEXAMPLE"
}
aws kinesis get-records \
--limit 10 \
--shard-iterator
"AAAAAAAAAAFGU/kLvNggvndHq2UIFOw5PZc6F01s3e3afsSscRM70JSbjIefg2ub07nk1y6CDxYR1UoGHJNP4m4NFUetzfL+wev+e2P4djJg4L9wmXKvQYoE+rMUiFq+p4Cn3IgvqOb5dRA0yybNdRcdzvnC35KQANoHzzahKdRGb9v4scv+3vaq+f+OIK8zM5My8ID+g6rMo7UKWeI4+IWiKEXAMPLE"
```
**注記**
Amazon Kinesis Data Streams がデータを返す前に、get-records コマンドを数回再実行する必要がある場合があります。
Amazon Kinesis Data Streams レコードの配列を含むレスポンスが表示されます。Amazon Kinesis Data Streams レコードのデータ属性は gzip 形式で圧縮され、base64 でエンコードされます。raw データは、コマンドラインから次の UNIX コマンドを使用して調べることができます。
```
echo -n "" | base64 -d | zcat
```
base64 でデコードおよび解凍されたデータは、次の構造を使用して JSON としてフォーマットされます。
```
{
"owner": "111111111111",
"logGroup": "CloudTrail/logs",
"logStream": "111111111111_CloudTrail/logs_us-east-1",
"subscriptionFilters": [
"RecipientStream"
],
"messageType": "DATA_MESSAGE",
"logEvents": [
{
"id": "3195310660696698337880902507980421114328961542429EXAMPLE",
"timestamp": 1432826855000,
"message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}"
},
{
"id": "3195310660696698337880902507980421114328961542429EXAMPLE",
"timestamp": 1432826855000,
"message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}"
},
{
"id": "3195310660696698337880902507980421114328961542429EXAMPLE",
"timestamp": 1432826855000,
"message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}"
}
]
}
```
このデータ構造のキー要素は以下のとおりです。
**owner (オーナー)**
元のログデータの AWS アカウント ID。
**logGroup**
発行元ログデータのロググループ名。
**logStream**
発行元ログデータのログストリーム名。
**subscriptionFilters**
発行元ログデータと一致したサブスクリプションフィルタ名のリスト。
**messageType**
データメッセージは、「DATA\$1MESSAGE」型を使用します。CloudWatch Logs は、主に送信先に到達可能かどうかを確認するために、「CONTROL\$1MESSAGE」タイプの Amazon Kinesis Data Streams レコードを出力することがあります。
**logEvents**
ログイベントレコードの配列として表される実際のログデータ。ID プロパティは、各ログイベントの一意の識別子です。
# ランタイムの送信先のメンバーシップを変更
所有する送信先のユーザーのメンバーシップを追加または削除する必要がある場合があります。新しいアクセスポリシーを使用して、送信先で `put-destination-policy` コマンドを使用できます。次の例では、先ほど追加したアカウント **111111111111** がログデータの送信を停止し、アカウント **222222222222** が有効になります。
1. 現在 **testDestination** という送信先に関連付けられているポリシーをフェッチし、**AccessPolicy** を書き留めておきます。
```
aws logs describe-destinations \
--destination-name-prefix "testDestination"
{
"Destinations": [
{
"DestinationName": "testDestination",
"RoleArn": "arn:aws:iam::999999999999:role/CWLtoKinesisRole",
"DestinationArn": "arn:aws:logs:region:999999999999:destination:testDestination",
"TargetArn": "arn:aws:kinesis:region:999999999999:stream/RecipientStream",
"AccessPolicy": "{\"Version\": \"2012-10-17\", \"Statement\": [{\"Sid\": \"\", \"Effect\": \"Allow\", \"Principal\": {\"AWS\": \"111111111111\"}, \"Action\": \"logs:PutSubscriptionFilter\", \"Resource\": \"arn:aws:logs:region:999999999999:destination:testDestination\"}] }"
}
]
}
```
1. アカウント **111111111111** が停止したこととアカウント **222222222222** が有効になったことを反映させるためにポリシーを更新します。このポリシーを **\$1/NewAccessPolicy.json** ファイルに配置します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"AWS": "222222222222"
},
"Action": "logs:PutSubscriptionFilter",
"Resource": "arn:aws:logs:us-east-1:999999999999:destination:testDestination"
}
]
}
```
------
1. **PutDestinationPolicy** を呼び出して、**NewAccessPolicy.json** ファイルで定義されているポリシーを送信先に関連付けます。
```
aws logs put-destination-policy \
--destination-name "testDestination" \
--access-policy file://~/NewAccessPolicy.json
```
これにより、最終的には、アカウント ID **111111111111** からのログイベントが無効になります。アカウント ID **222222222222** の所有者がサブスクリプションフィルターを作成すると、すぐに **222222222222** からのログイベントが送信先に送信されるようになります。
# 既存のクロスアカウントサブスクリプションの更新
送信先アカウントが特定の送信者アカウントにのみアクセス許可を付与しているクロスアカウントのログサブスクリプションがあり、このサブスクリプションを更新して送信先アカウントが組織内のすべてのアカウントにアクセスできるようにする場合は、このセクションのステップを実施します。
**Topics**
+ [ステップ 1: サブスクリプションフィルターを更新する](Cross-Account-Log_Subscription-Update-filter.md)
+ [ステップ 2: 既存の送信先アクセスポリシーを更新する](Cross-Account-Log_Subscription-Update-policy.md)
# ステップ 1: サブスクリプションフィルターを更新する
**注記**
この手順は、[AWS サービスからのログ記録を有効にする](AWS-logs-and-resource-policy.md) に記載されているサービスによって作成されたログのクロスアカウントのサブスクリプションにのみ必要です。これらのロググループのいずれかで作成されたログを操作していない場合は、[ステップ 2: 既存の送信先アクセスポリシーを更新する](Cross-Account-Log_Subscription-Update-policy.md) にスキップできます。
場合によっては、送信先アカウントにログを送信する、すべての送信者アカウントのサブスクリプションフィルターを更新する必要があります。この更新により IAM ロールが追加されます。IAM ロールは CloudWatch が引き受けることができ、送信者アカウントが受信者アカウントにログを送信する権限を持っていることを検証できます。
すべての送信者アカウントについてクロスアカウントサブスクリプションのアクセス許可に組織 ID を使用するように更新するには、このセクションのステップを実施します。
このセクションの例では、2 つのアカウント `111111111111` と `222222222222` は、アカウント `999999999999` にログを送信するために作成されたサブスクリプションフィルターをすでに持っています。既存のサブスクリプションフィルター値は次のとおりです。
```
## Existing Subscription Filter parameter values
\ --log-group-name "my-log-group-name"
\ --filter-name "RecipientStream"
\ --filter-pattern "{$.userIdentity.type = Root}"
\ --destination-arn "arn:aws:logs:region:999999999999:destination:testDestination"
```
現在のサブスクリプションフィルターパラメータ値を見つける必要がある場合は、次のコマンドを入力します。
```
aws logs describe-subscription-filters
\ --log-group-name "my-log-group-name"
```
**サブスクリプションフィルターを更新して、クロスアカウントログの権限で組織 ID の使用をスタートする方法**
1. 以下の信頼ポリシーを作成し、`~/TrustPolicyForCWL.json` という名前のテキストファイルに保存します。このポリシーの作成にはテキストエディタを使用します。IAM コンソールは使用しないでください。
```
{
"Statement": {
"Effect": "Allow",
"Principal": { "Service": "logs.amazonaws.com" },
"Action": "sts:AssumeRole"
}
}
```
1. このポリシーを使用する IAM ロールを作成します。下記のコマンドが返す `Arn` 値の `Arn` の値は後ほど必要になるため、書き留めておきます。この例では、作成するロールに `CWLtoSubscriptionFilterRole` という名前を付けます。
```
aws iam create-role
\ --role-name CWLtoSubscriptionFilterRole
\ --assume-role-policy-document file://~/TrustPolicyForCWL.json
```
1. アクセス許可ポリシーを作成して、CloudWatch Logs がアカウントで実行できるアクションを定義します。
1. まず、テキストエディタを使用して、`/PermissionsForCWLSubscriptionFilter.json` という名前のファイルに以下のようなアクセス許可ポリシーを作成します。
```
{
"Statement": [
{
"Effect": "Allow",
"Action": "logs:PutLogEvents",
"Resource": "arn:aws:logs:region:111111111111:log-group:LogGroupOnWhichSubscriptionFilterIsCreated:*"
}
]
}
```
1. 次のコマンドを入力して、先ほど作成したアクセス許可ポリシーを、ステップ 2 で作成したロールに関連付けます。
```
aws iam put-role-policy
--role-name CWLtoSubscriptionFilterRole
--policy-name Permissions-Policy-For-CWL-Subscription-filter
--policy-document file://~/PermissionsForCWLSubscriptionFilter.json
```
1. 次のコマンドを入力して、サブスクリプションフィルターを更新します。
```
aws logs put-subscription-filter
\ --log-group-name "my-log-group-name"
\ --filter-name "RecipientStream"
\ --filter-pattern "{$.userIdentity.type = Root}"
\ --destination-arn "arn:aws:logs:region:999999999999:destination:testDestination"
\ --role-arn "arn:aws:iam::111111111111:role/CWLtoSubscriptionFilterRole"
```
# ステップ 2: 既存の送信先アクセスポリシーを更新する
すべての送信者アカウントのサブスクリプションフィルターを更新した後、受信者アカウントの送信先アクセスポリシーを更新できます。
以下の例では、受信者アカウントは `999999999999`、送信先は `testDestination` となっています。
この更新により、ID `o-1234567890` を持つ組織に属するすべてのアカウントが、受信者アカウントにログを送信できるようになりました。サブスクリプションフィルターが作成されたアカウントのみが、実際に受信者アカウントにログを送信します。
**受信者アカウントの送信先アクセスポリシーを更新して、権限の組織 ID の使用をスタートする方法**
1. 受信者アカウントで、テキストエディタを使用して、以下の内容の `~/AccessPolicy.json` ファイルを作成します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": "*",
"Action": "logs:PutSubscriptionFilter",
"Resource": "arn:aws:logs:us-east-1:999999999999:destination:testDestination",
"Condition": {
"StringEquals": {
"aws:PrincipalOrgID": [
"o-1234567890"
]
}
}
}
]
}
```
------
1. 次のコマンドを入力して、先ほど作成したポリシーを既存の送信先にアタッチします。特定の AWS アカウント ID を一覧表示するアクセスポリシーではなく、組織 ID を持つアクセスポリシーを使用するように送信先を更新するには、 `force`パラメータを含めIDs。
**警告**
にリストされている AWS サービスによって送信されたログを使用している場合は[AWS サービスからのログ記録を有効にする](AWS-logs-and-resource-policy.md)、このステップを実行する前に、「」で説明されているように、まずすべての送信者アカウントのサブスクリプションフィルターを更新しておく必要があります[ステップ 1: サブスクリプションフィルターを更新する](Cross-Account-Log_Subscription-Update-filter.md)。
```
aws logs put-destination-policy
\ --destination-name "testDestination"
\ --access-policy file://~/AccessPolicy.json
\ --force
```
# Firehose を使用したクロスアカウント、クロスリージョンのログデータ共有
複数のアカウントでログデータを共有するには、ログデータの送信者と受信者を確立する必要があります。
+ [**Log data sender (ログデータの送信者)**] — 受取人から送信先情報を取得し、そのログイベントを特定の送信先に送信する準備が完了していることを CloudWatch Logs に通知します。このセクションの残りの手順では、ログデータ送信者は架空の AWS アカウント番号 111111111111 で表示されます。
+ **ログデータ受信者** — Amazon Kinesis Data Streams ストリームをカプセル化する送信先を設定し、受信者がログデータを受信したいことを CloudWatch Logs に知らせます。この後、受信者は自分の送信先に関する情報を送信者と共有します。このセクションの残りの手順では、ログデータ受信者は架空の AWS アカウント番号 222222222222 で表示されます。
このセクションの例では、Amazon S3 ストレージで Firehose 配信ストリームを使用しています。異なる設定で Firehose 配信ストリームを設定することもできます。詳細については、「[Creating a Firehose Delivery Stream](https://docs.aws.amazon.com/firehose/latest/dev/basic-create.html)」を参照してください。
**注記**
ロググループと送信先は同じ AWS リージョンにある必要があります。ただし、送信先が指す AWS リソースは、別のリージョンに配置することができます。
**注記**
***[同じアカウント]*** と ***[クロスリージョン]*** 配信ストリームに対して Firehose サブスクリプションフィルターがサポートされています。
**Topics**
+ [ステップ 1: Firehose 配信ストリームを作成する](CreateFirehoseStream.md)
+ [ステップ 2: 送信先を作成する](CreateFirehoseStreamDestination.md)
+ [ステップ 3: クロスアカウント宛先の IAM アクセス許可を追加/検証する](Subscription-Filter-CrossAccount-Permissions-Firehose.md)
+ [ステップ 4: サブスクリプションフィルターを作成する](CreateSubscriptionFilterFirehose.md)
+ [ログイベントの送信の検証](ValidateLogEventFlowFirehose.md)
+ [実行時の送信先のメンバーシップの変更](ModifyDestinationMembershipFirehose.md)
# ステップ 1: Firehose 配信ストリームを作成する
**重要**
以下の手順を実行する前に、Firehose が Amazon S3 バケットにアクセスできるように、アクセスポリシーを使用する必要があります。詳細については、「[Amazon Data Firehose 開発者ガイド](https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html#using-iam-s3)」の「*Controlling Access*」を参照してください。
このセクションのすべての手順 (ステップ 1) は、ログデータの受取人アカウントで行われます。
次のサンプルコマンドでは、米国東部 (バージニア北部) が使用されています。このリージョンを、デプロイに適したリージョンに置き換えます。
**送信先として使用する Firehose 配信ストリームを作成するには**
1. Amazon S3 バケットの作成
```
aws s3api create-bucket --bucket amzn-s3-demo-bucket --create-bucket-configuration LocationConstraint=us-east-1
```
1. バケットにデータを配置するためのアクセス許可を Firehose に付与する IAM ロールを作成します。
1. まず、テキストエディタを使用して、ファイル `~/TrustPolicyForFirehose.json` で信頼ポリシーを作成します。
```
{ "Statement": { "Effect": "Allow", "Principal": { "Service": "firehose.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId":"222222222222" } } } }
```
1. 作成したばかりの信頼ポリシーファイルを指定して、IAM ロールを作成します。
```
aws iam create-role \
--role-name FirehosetoS3Role \
--assume-role-policy-document file://~/TrustPolicyForFirehose.json
```
1. このコマンドの出力は、次のようになります。ロール名とロール ARN を書き留めます。
```
{
"Role": {
"Path": "/",
"RoleName": "FirehosetoS3Role",
"RoleId": "AROAR3BXASEKW7K635M53",
"Arn": "arn:aws:iam::222222222222:role/FirehosetoS3Role",
"CreateDate": "2021-02-02T07:53:10+00:00",
"AssumeRolePolicyDocument": {
"Statement": {
"Effect": "Allow",
"Principal": {
"Service": "firehose.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "222222222222"
}
}
}
}
}
}
```
1. アクセス許可ポリシーを作成し、Firehose がアカウントで実行できるアクションを定義します。
1. まず、テキストエディタを使用して、`~/PermissionsForFirehose.json` という名前のファイルに以下のようなアクセス許可ポリシーを作成します。ユースケースによっては、このファイルにさらにアクセス権限を追加する必要がある場合があります。
```
{
"Statement": [{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:PutObjectAcl",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
}]
}
```
1. 次のコマンドを入力して、先ほど作成したアクセス権限ポリシーを IAM ロールに関連付けます。
```
aws iam put-role-policy --role-name FirehosetoS3Role --policy-name Permissions-Policy-For-Firehose-To-S3 --policy-document file://~/PermissionsForFirehose.json
```
1. 次のコマンドを入力して、Firehose 配信ストリームを作成します。*my-role-arn* および *amzn-s3-demo-bucket2-arn* をデプロイに適した値に置き換えます。
```
aws firehose create-delivery-stream \
--delivery-stream-name 'my-delivery-stream' \
--s3-destination-configuration \
'{"RoleARN": "arn:aws:iam::222222222222:role/FirehosetoS3Role", "BucketARN": "arn:aws:s3:::amzn-s3-demo-bucket"}'
```
出力は次の例に類似したものになります:
```
{
"DeliveryStreamARN": "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream"
}
```
# ステップ 2: 送信先を作成する
**重要**
この手順のステップは、ログデータの受取人アカウントで行われます。
送信先が作成されると、CloudWatch Logs は受信者アカウントに代わってテストメッセージを宛先に送信します。サブスクリプションフィルターが後でアクティブになると、CloudWatch Logs はソースアカウントに代わってログイベントを宛先に送信します。
**送信先を作成するには**
1. [ステップ 1: Firehose 配信ストリームを作成する](CreateFirehoseStream.md) で作成した Firehose ストリームがアクティブになるまで待ちます。次のコマンドを使用して、**StreamDescription.StreamStatus** プロパティを確認できます。
```
aws firehose describe-delivery-stream --delivery-stream-name "my-delivery-stream"
```
さらに、後の手順で使用する必要があるため、**DeliveryStreamDescription.DeliveryStreamARN** 値を書き留めます。このコマンドの出力例:
```
{
"DeliveryStreamDescription": {
"DeliveryStreamName": "my-delivery-stream",
"DeliveryStreamARN": "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream",
"DeliveryStreamStatus": "ACTIVE",
"DeliveryStreamEncryptionConfiguration": {
"Status": "DISABLED"
},
"DeliveryStreamType": "DirectPut",
"VersionId": "1",
"CreateTimestamp": "2021-02-01T23:59:15.567000-08:00",
"Destinations": [
{
"DestinationId": "destinationId-000000000001",
"S3DestinationDescription": {
"RoleARN": "arn:aws:iam::222222222222:role/FirehosetoS3Role",
"BucketARN": "arn:aws:s3:::amzn-s3-demo-bucket",
"BufferingHints": {
"SizeInMBs": 5,
"IntervalInSeconds": 300
},
"CompressionFormat": "UNCOMPRESSED",
"EncryptionConfiguration": {
"NoEncryptionConfig": "NoEncryption"
},
"CloudWatchLoggingOptions": {
"Enabled": false
}
},
"ExtendedS3DestinationDescription": {
"RoleARN": "arn:aws:iam::222222222222:role/FirehosetoS3Role",
"BucketARN": "arn:aws:s3:::amzn-s3-demo-bucket",
"BufferingHints": {
"SizeInMBs": 5,
"IntervalInSeconds": 300
},
"CompressionFormat": "UNCOMPRESSED",
"EncryptionConfiguration": {
"NoEncryptionConfig": "NoEncryption"
},
"CloudWatchLoggingOptions": {
"Enabled": false
},
"S3BackupMode": "Disabled"
}
}
],
"HasMoreDestinations": false
}
}
```
配信ストリームがアクティブ状態で表示されるまでに 1～2 分かかる場合があります。
1. 配信ストリームがアクティブになったら、Firehose ストリームにデータを置くためのアクセス許可を CloudWatch Logs に付与する IAM ロールを作成します。まず、ファイル **\$1/TrustPolicyForCWL.json** で信頼ポリシーを作成する必要があります。テキストエディタを使用してこのポリシーを作成します。CloudWatch Logs エンドポイントの詳細については、[Amazon CloudWatch Logs エンドポイントおよびクォータ](https://docs.aws.amazon.com/general/latest/gr/cwl_region.html)を参照してください。
このポリシーには、「混乱した代理」のセキュリティ上の問題を防止するための `sourceAccountId` が指定された `aws:SourceArn` グローバル条件コンテキストキーが含まれています。最初の呼び出しでソースアカウント ID が不明な場合は、送信元 ARN フィールドに送信先 ARN を指定することをお勧めします。後続の呼び出しでは、送信元 ARN を、最初の呼び出しで取得した実際の送信元 ARN に設定する必要があります。詳細については、「[混乱した代理の防止](Subscriptions-confused-deputy.md)」を参照してください。
```
{
"Statement": {
"Effect": "Allow",
"Principal": {
"Service": "logs.region.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringLike": {
"aws:SourceArn": [
"arn:aws:logs:region:sourceAccountId:*",
"arn:aws:logs:region:recipientAccountId:*"
]
}
}
}
}
```
1. **aws iam create-role** コマンドを使用して、作成した信頼ポリシーファイルを指定して IAM ロールを作成します。
```
aws iam create-role \
--role-name CWLtoKinesisFirehoseRole \
--assume-role-policy-document file://~/TrustPolicyForCWL.json
```
以下は出力例です。後のステップで使用する必要があるため、`Role.Arn` の戻り値を書き留めます。
```
{
"Role": {
"Path": "/",
"RoleName": "CWLtoKinesisFirehoseRole",
"RoleId": "AROAR3BXASEKYJYWF243H",
"Arn": "arn:aws:iam::222222222222:role/CWLtoKinesisFirehoseRole",
"CreateDate": "2021-02-02T08:10:43+00:00",
"AssumeRolePolicyDocument": {
"Statement": {
"Effect": "Allow",
"Principal": {
"Service": "logs.region.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringLike": {
"aws:SourceArn": [
"arn:aws:logs:region:sourceAccountId:*",
"arn:aws:logs:region:recipientAccountId:*"
]
}
}
}
}
}
}
```
1. CloudWatch Logs がアカウントで実行できるアクションを定義するアクセス許可ポリシーを作成します。まず、テキストエディタを使用してファイル **\$1/PermissionsForCWL.json** でアクセス許可ポリシーを作成します。
```
{
"Statement":[
{
"Effect":"Allow",
"Action":["firehose:*"],
"Resource":["arn:aws:firehose:region:222222222222:*"]
}
]
}
```
1. 次のコマンドを入力して、アクセス権限ポリシーをロールに関連付けます。
```
aws iam put-role-policy --role-name CWLtoKinesisFirehoseRole --policy-name Permissions-Policy-For-CWL --policy-document file://~/PermissionsForCWL.json
```
1. Firehose 配信ストリームがアクティブ状態になり、IAM ロールが作成されたら、CloudWatch Logs の送信先を作成できます。
1. このステップでは、アクセスポリシーと送信先は関連付けられません。送信先の作成を完了するには 2 つのステップを行う必要がありますが、このステップはその最初のステップです。後のステップでこれを `destination.arn` として使用するため、ペイロードで返される新しい宛先の ARN を書き留めます。
```
aws logs put-destination \
--destination-name "testFirehoseDestination" \
--target-arn "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream" \
--role-arn "arn:aws:iam::222222222222:role/CWLtoKinesisFirehoseRole"
{
"destination": {
"destinationName": "testFirehoseDestination",
"targetArn": "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream",
"roleArn": "arn:aws:iam::222222222222:role/CWLtoKinesisFirehoseRole",
"arn": "arn:aws:logs:us-east-1:222222222222:destination:testFirehoseDestination"}
}
```
1. 前のステップが完了したら、ログデータ受取人アカウント (222222222222) で、アクセスポリシーを送信先に関連付けます。
このポリシーにより、ログデータの送信者アカウント (111111111111) に対し、ログデータの受信者アカウント (222222222222) にある送信先にアクセスすることを許可します。テキストエディタを使用して、このポリシーを **\$1/AccessPolicy.json** ファイルに配置できます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement" : [
{
"Sid" : "",
"Effect" : "Allow",
"Principal" : {
"AWS" : "111111111111"
},
"Action" : "logs:PutSubscriptionFilter",
"Resource" : "arn:aws:logs:us-east-1:222222222222:destination:testFirehoseDestination"
}
]
}
```
------
1. これにより、誰が送信先に書き込むことができるかを定義するポリシーが作成されます。このポリシーでは、送信先にアクセスするための **logs:PutSubscriptionFilter** アクションが指定されている必要があります。クロスアカウントのユーザーは、**PutSubscriptionFilter** アクションを使用して送信先にログイベントを送信します。
```
aws logs put-destination-policy \
--destination-name "testFirehoseDestination" \
--access-policy file://~/AccessPolicy.json
```
# ステップ 3: クロスアカウント宛先の IAM アクセス許可を追加/検証する
AWS クロスアカウントポリシーの評価ロジックに従って、クロスアカウントリソース (サブスクリプションフィルターの送信先として使用される Kinesis または Firehose ストリームなど) にアクセスするには、クロスアカウントの送信先リソースへの明示的なアクセスを提供する ID ベースのポリシーを送信アカウントに含める必要があります。ポリシーの評価論理の詳細については、「[クロスアカウントポリシーの評価論理](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html)」を参照してください。
ID ベースのポリシーは、サブスクリプションフィルターの作成に使用している IAM ロールまたは IAM ユーザーにアタッチできます。送信アカウントにこのポリシーが存在する必要があります。管理者ロールを使用してサブスクリプションフィルタを作成している場合は、このステップをスキップして [ステップ 4: サブスクリプションフィルターを作成する](CreateSubscriptionFilter.md) に進んでください。
**クロスアカウントに必要な IAM アクセス許可を追加または検証するには**
1. 次のコマンドを入力して、 AWS ログコマンドの実行に使用されている IAM ロールまたは IAM ユーザーを確認します。
```
aws sts get-caller-identity
```
このコマンドにより、以下のような出力が返されます。
```
{
"UserId": "User ID",
"Account": "sending account id",
"Arn": "arn:aws:sending account id:role/user:RoleName/UserName"
}
```
*RoleName* または *UserName* で表される値を書き留めておいてください。
1. 送信アカウント AWS マネジメントコンソール で にサインインし、ステップ 1 で入力したコマンドの出力で返された IAM ロールまたは IAM ユーザーを使用して、アタッチされたポリシーを検索します。
1. このロールまたはユーザーにアタッチされたポリシーが、クロスアカウントの宛先リソースで `logs:PutSubscriptionFilter` を呼び出すための明示的なアクセス許可が付与されていることを確認します。
次のポリシーは、1 つの AWS アカウント、アカウント でのみ、任意の送信先リソースにサブスクリプションフィルターを作成するアクセス許可を提供します`999999999999`。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowSubscriptionFiltersOnAnyResourceInOneSpecificAccount",
"Effect": "Allow",
"Action": "logs:PutSubscriptionFilter",
"Resource": [
"arn:aws:logs:*:*:log-group:*",
"arn:aws:logs:*:123456789012:destination:*"
]
}
]
}
```
------
次のポリシーは、単一の AWS アカウント、アカウント `sampleDestination`で という名前の特定の送信先リソースに対してのみサブスクリプションフィルターを作成するアクセス許可を提供します`123456789012`。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowSubscriptionFiltersOnSpecificResource",
"Effect": "Allow",
"Action": "logs:PutSubscriptionFilter",
"Resource": [
"arn:aws:logs:*:*:log-group:*",
"arn:aws:logs:*:123456789012:destination:amzn-s3-demo-bucket"
]
}
]
}
```
------
# ステップ 4: サブスクリプションフィルターを作成する
送信側のアカウント (この例では 111111111111) に切り替えます。次に、送信側のアカウントにサブスクリプションフィルターを作成します。この例では、フィルターは AWS CloudTrail イベントを含むロググループに関連付けられているため、「ルート AWS 」認証情報によって行われたログに記録されたすべてのアクティビティが、以前に作成した送信先に配信されます。CloudWatch Logs に AWS CloudTrail イベントを送信する方法の詳細については、*AWS CloudTrail 「 ユーザーガイド*[」のCloudTrail イベントを CloudWatch Logs に送信する](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/send-cloudtrail-events-to-cloudwatch-logs.html)」を参照してください。
次のコマンドを入力するときは、必ず IAM ユーザーとしてサインインしているか、[ステップ 3: クロスアカウント宛先の IAM アクセス許可を追加/検証する](Subscription-Filter-CrossAccount-Permissions-Firehose.md) にポリシーを追加した IAM ロールを使用してサインインしていることを確認してください。
```
aws logs put-subscription-filter \
--log-group-name "aws-cloudtrail-logs-111111111111-300a971e" \
--filter-name "firehose_test" \
--filter-pattern "{$.userIdentity.type = AssumedRole}" \
--destination-arn "arn:aws:logs:us-east-1:222222222222:destination:testFirehoseDestination"
```
ロググループと送信先は同じ AWS リージョンにある必要があります。ただし、送信先は、別のリージョンにある Firehose ストリームなどの AWS リソースを指すことができます。
# ログイベントの送信の検証
サブスクリプションフィルターを作成すると、CloudWatch Logs は、フィルタパターンに一致するすべての受信ログイベントを Firehose 配信ストリームに転送します。データは、Firehose 配信ストリームに設定されている時間バッファ間隔に基づいて、Amazon S3 バケットに順次表示されます。十分な時間が経過すると、Amazon S3 バケットをチェックしてデータを確認できます。バケットを確認するには、次のコマンドを入力します。
```
aws s3api list-objects --bucket 'amzn-s3-demo-bucket'
```
そのコマンドの出力は、次のようになります。
```
{
"Contents": [
{
"Key": "2021/02/02/08/my-delivery-stream-1-2021-02-02-08-55-24-5e6dc317-071b-45ba-a9d3-4805ba39c2ba",
"LastModified": "2021-02-02T09:00:26+00:00",
"ETag": "\"EXAMPLEa817fb88fc770b81c8f990d\"",
"Size": 198,
"StorageClass": "STANDARD",
"Owner": {
"DisplayName": "firehose+2test",
"ID": "EXAMPLE27fd05889c665d2636218451970ef79400e3d2aecca3adb1930042e0"
}
}
]
}
```
その後、次のコマンドを入力して、バケットから特定のオブジェクトを取得できます。`key` の値を、前のコマンドで検索した値に置き換えます。
```
aws s3api get-object --bucket 'amzn-s3-demo-bucket' --key '2021/02/02/08/my-delivery-stream-1-2021-02-02-08-55-24-5e6dc317-071b-45ba-a9d3-4805ba39c2ba' testfile.gz
```
Simple Storage Service (Amazon S3) オブジェクトのデータは、gzip 形式で圧縮されます。raw データは、コマンドラインから次のコマンドを使用して調べることができます。
Linux:
```
zcat testfile.gz
```
macOS:
```
zcat
所有している送信先からログ送信者を追加または削除しなければならない状況が発生することがあります。新しいアクセスポリシーが関連付けられている送信先に対して **PutDestinationPolicy** アクションを使用できます。次の例では、先ほど追加したアカウント **111111111111** がログデータの送信を停止し、アカウント **333333333333** が有効になります。
1. 現在 **testDestination** という送信先に関連付けられているポリシーをフェッチし、**AccessPolicy** を書き留めておきます。
```
aws logs describe-destinations \
--destination-name-prefix "testFirehoseDestination"
{
"destinations": [
{
"destinationName": "testFirehoseDestination",
"targetArn": "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream",
"roleArn": "arn:aws:iam:: 222222222222:role/CWLtoKinesisFirehoseRole",
"accessPolicy": "{\n \"Version\" : \"2012-10-17\",\n \"Statement\" : [\n {\n \"Sid\" : \"\",\n \"Effect\" : \"Allow\",\n \"Principal\" : {\n \"AWS\" : \"111111111111 \"\n },\n \"Action\" : \"logs:PutSubscriptionFilter\",\n \"Resource\" : \"arn:aws:logs:us-east-1:222222222222:destination:testFirehoseDestination\"\n }\n ]\n}\n\n",
"arn": "arn:aws:logs:us-east-1: 222222222222:destination:testFirehoseDestination",
"creationTime": 1612256124430
}
]
}
```
1. アカウント **111111111111** が停止したこととアカウント **333333333333** が有効になったことを反映させるためにポリシーを更新します。このポリシーを **\$1/NewAccessPolicy.json** ファイルに配置します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement" : [
{
"Sid" : "",
"Effect" : "Allow",
"Principal" : {
"AWS" : "333333333333 "
},
"Action" : "logs:PutSubscriptionFilter",
"Resource" : "arn:aws:logs:us-east-1:222222222222:destination:testFirehoseDestination"
}
]
}
```
------
1. 次のコマンドを使用して、**NewAccessPolicy.json** ファイルで定義されたポリシーを送信先に関連付けます。
```
aws logs put-destination-policy \
--destination-name "testFirehoseDestination" \
--access-policy file://~/NewAccessPolicy.json
```
これにより、最終的には、アカウント ID **111111111111** からのログイベントが無効になります。アカウント ID **333333333333** の所有者がサブスクリプションフィルターを作成すると、すぐに **333333333333** からのログイベントが送信先に送信されるようになります。
# Amazon Kinesis Data Streams を使用したクロスアカウントクロスリージョンアカウントレベルのサブスクリプション
クロスアカウントサブスクリプションを作成するときに、単一のアカウントまたは組織を送信者として指定できます。組織を指定した場合、この手順により組織内のすべてのアカウントがレシーバーアカウントにログを送信できるようになります。
複数のアカウントでログデータを共有するには、ログデータの送信者と受信者を確立する必要があります。
+ **[Log data sender] **(ログデータの送信者) — 受信者から送信先情報を取得し、そのログイベントを特定の送信先に送信する準備が完了していることを CloudWatch Logs に通知します。このセクションの残りの手順では、ログデータ送信者は架空の AWS アカウント番号 111111111111 で表示されます。
1 つの組織で複数のアカウントを 1 つの受信者アカウントにログを送信する場合は、組織内のすべてのアカウントに対して受信者アカウントにログを送信するアクセス許可を付与するポリシーを作成することができます。引き続き、送信者アカウントごとに個別のサブスクリプションフィルターを設定する必要があります。
+ **ログデータ受信者** - Amazon Kinesis Data Streams ストリームをカプセル化する送信先を設定し、受信者がログデータを受信したいことを CloudWatch Logs に知らせます。この後、受信者は自分の送信先に関する情報を送信者と共有します。このセクションの残りの手順では、ログデータ受信者は架空の AWS アカウント番号 999999999999 で表示されます。
クロスアカウントのユーザーからのログイベントの受け取りを開始するには、ログデータの受取人がまず CloudWatch Logs 送信先を作成する必要があります。各送信先は以下のキー要素で構成されています。
**送信先名**
作成する送信先の名前。
**ターゲット ARN**
サブスクリプションフィードの送信先として使用するリソースの Amazon AWS リソースネーム (ARN)。
**ロールの ARN**
選択したストリームにデータを配置するために必要なアクセス許可を CloudWatch Logs に付与する AWS Identity and Access Management (IAM) ロール。
**アクセスポリシー**
送信先に書き込むことが許可されている一連のユーザーを管理する IAM ポリシードキュメント (IAM ポリシー構文を使用して記述された JSON 形式のドキュメント）。
**注記**
ロググループと送信先は同じ AWS リージョンにある必要があります。ただし、送信先が指す AWS リソースは、別のリージョンに配置することができます。次のセクションの例では、リージョン固有のリソースはすべて米国東部 (バージニア北部) で作成されます。
**Topics**
+ [新しいクロスアカウントサブスクリプションの設定](Cross-Account-Log_Subscription-New-Account.md)
+ [既存のクロスアカウントサブスクリプションの更新](Cross-Account-Log_Subscription-Update-Account.md)
# 新しいクロスアカウントサブスクリプションの設定
次のセクションの手順に従って、新しいクロスアカウントログサブスクリプションを設定します。
**Topics**
+ [ステップ 1: 送信先を作成する](CreateDestination-Account.md)
+ [ステップ 2: IAM ロールを作成する (組織を使用している場合のみ)](CreateSubscriptionFilter-IAMrole-Account.md)
+ [ステップ 3: アカウントレベルのサブスクリプションフィルタポリシーを作成する](CreateSubscriptionFilter-Account.md)
+ [ログイベントの送信を検証](ValidateLogEventFlow-Account.md)
+ [ランタイムの送信先のメンバーシップを変更](ModifyDestinationMembership-Account.md)
# ステップ 1: 送信先を作成する
**重要**
この手順のステップは、ログデータの受取人アカウントで行われます。
この例では、ログデータ受信者アカウントの AWS アカウント ID は 999999999999 で、ログデータ送信者 AWS アカウント ID は 111111111111 です。
この例では、RecipientStream という Amazon Kinesis Data Streams ストリームと、CloudWatch Logs によるデータの書き込みを可能にするロールを使用して送信先を作成します。
送信先が作成されると、CloudWatch Logs は受信者アカウントに代わってテストメッセージを宛先に送信します。サブスクリプションフィルターが後でアクティブになると、CloudWatch Logs はソースアカウントに代わってログイベントを宛先に送信します。
**送信先を作成するには**
1. 受信者アカウントで、Amazon Kinesis Data Streams で送信先ストリームを作成します。コマンドプロンプトで、次のように入力します。
```
aws kinesis create-stream --stream-name "RecipientStream" --shard-count 1
```
1. ストリームがアクティブになるまで待ちます。**aws kinesis describe-stream** コマンドを使用して、**StreamDescription.StreamStatus** プロパティをチェックできます。さらに、**StreamDescription.StreamARN** の値は、後で CloudWatch Logs に渡すので書き留めておいてください。
```
aws kinesis describe-stream --stream-name "RecipientStream"
{
"StreamDescription": {
"StreamStatus": "ACTIVE",
"StreamName": "RecipientStream",
"StreamARN": "arn:aws:kinesis:us-east-1:999999999999:stream/RecipientStream",
"Shards": [
{
"ShardId": "shardId-000000000000",
"HashKeyRange": {
"EndingHashKey": "34028236692093846346337460743176EXAMPLE",
"StartingHashKey": "0"
},
"SequenceNumberRange": {
"StartingSequenceNumber": "4955113521868881845667950383198145878459135270218EXAMPLE"
}
}
]
}
}
```
ストリームがアクティブ状態で表示されるまでに 1～2 分かかる場合があります。
1. ストリームにデータを置くアクセス権限を CloudWatch Logs に付与する IAM ロールを作成します。まず、ファイル **\$1/TrustPolicyForCWL.json** で信頼ポリシーを作成する必要があります。このポリシーの作成にはテキストエディタを使用します。IAM コンソールは使用しないでください。
このポリシーには、「混乱した代理」のセキュリティ上の問題を防止するための `sourceAccountId` が指定された `aws:SourceArn` グローバル条件コンテキストキーが含まれています。最初の呼び出しでソースアカウント ID が不明な場合は、送信元 ARN フィールドに送信先 ARN を指定することをお勧めします。後続の呼び出しでは、送信元 ARN を、最初の呼び出しで取得した実際の送信元 ARN に設定する必要があります。詳細については、「[混乱した代理の防止](Subscriptions-confused-deputy.md)」を参照してください。
```
{
"Statement": {
"Effect": "Allow",
"Principal": {
"Service": "logs.amazonaws.com"
},
"Condition": {
"StringLike": {
"aws:SourceArn": [
"arn:aws:logs:region:sourceAccountId:*",
"arn:aws:logs:region:recipientAccountId:*"
]
}
},
"Action": "sts:AssumeRole"
}
}
```
1. **aws iam create-role** コマンドを使用して、信頼ポリシーファイルを指定する IAM ロールを作成します。返された Role.Arn 値を書き留めておきます。これも後で CloudWatch Logs に渡されるからです。
```
aws iam create-role \
--role-name CWLtoKinesisRole \
--assume-role-policy-document file://~/TrustPolicyForCWL.json
{
"Role": {
"AssumeRolePolicyDocument": {
"Statement": {
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Condition": {
"StringLike": {
"aws:SourceArn": [
"arn:aws:logs:region:sourceAccountId:*",
"arn:aws:logs:region:recipientAccountId:*"
]
}
},
"Principal": {
"Service": "logs.amazonaws.com"
}
}
},
"RoleId": "AAOIIAH450GAB4HC5F431",
"CreateDate": "2023-05-29T13:46:29.431Z",
"RoleName": "CWLtoKinesisRole",
"Path": "/",
"Arn": "arn:aws:iam::999999999999:role/CWLtoKinesisRole"
}
}
```
1. CloudWatch Logs がアカウントで実行できるアクションを定義するアクセス許可ポリシーを作成します。まず、テキストエディタを使用してファイル **\$1/PermissionsForCWL.json** でアクセス許可ポリシーを作成します。
```
{
"Statement": [
{
"Effect": "Allow",
"Action": "kinesis:PutRecord",
"Resource": "arn:aws:kinesis:region:999999999999:stream/RecipientStream"
}
]
}
```
1. **aws iam put-role-policy** コマンドを使用して、アクセス許可ポリシーをロールに関連付けます。
```
aws iam put-role-policy \
--role-name CWLtoKinesisRole \
--policy-name Permissions-Policy-For-CWL \
--policy-document file://~/PermissionsForCWL.json
```
1. ストリームがアクティブ状態になり、IAM ロールが作成されたら、CloudWatch Logs の送信先を作成できます。
1. このステップでは、アクセスポリシーと送信先は関連付けられません。送信先の作成を完了するには 2 つのステップを行う必要がありますが、このステップはその最初のステップです。ペイロードで返された **DestinationArn** を書き留めておいてください。
```
aws logs put-destination \
--destination-name "testDestination" \
--target-arn "arn:aws:kinesis:region:999999999999:stream/RecipientStream" \
--role-arn "arn:aws:iam::999999999999:role/CWLtoKinesisRole"
{
"DestinationName" : "testDestination",
"RoleArn" : "arn:aws:iam::999999999999:role/CWLtoKinesisRole",
"DestinationArn" : "arn:aws:logs:us-east-1:999999999999:destination:testDestination",
"TargetArn" : "arn:aws:kinesis:us-east-1:999999999999:stream/RecipientStream"
}
```
1. ステップ 7a が完了したら、ログデータの受取人アカウントで、アクセスポリシーを送信先に関連付けます。このポリシーでは、送信者アカウントが送信先にアクセスするためのアクセス許可が付与され、**logs:PutSubscriptionFilter** アクションが指定されている必要があります。
このポリシーは、ログを送信する AWS アカウントにアクセス許可を付与します。ポリシーの中で対象のアカウントを 1 つだけ指定してもよいですが、送信者アカウントが組織のメンバーのものである場合は組織 ID を指定することもできます。このように、ポリシーを 1 つ作成するだけで、1 つの組織内の複数のアカウントが送信先アカウントにログを送信できるように設定できます。
テキストエディタを使用して `~/AccessPolicy.json` という名前のファイルを作成し、以下のいずれかのポリシーステートメントを使用します。
この最初の例のポリシーでは、組織内で `o-1234567890` という ID を持つすべてのアカウントが、受信者アカウントにログを送信することを許可します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": "*",
"Action": [
"logs:PutSubscriptionFilter",
"logs:PutAccountPolicy"
],
"Resource": "arn:aws:logs:us-east-1:999999999999:destination:testDestination",
"Condition": {
"StringEquals": {
"aws:PrincipalOrgID": [
"o-1234567890"
]
}
}
}
]
}
```
------
次の例では、ログデータの送信者アカウント (111111111111) がログデータの受信者アカウントにログを送信できるようにします。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"AWS": "111111111111"
},
"Action": [
"logs:PutSubscriptionFilter",
"logs:PutAccountPolicy"
],
"Resource": "arn:aws:logs:us-east-1:999999999999:destination:testDestination"
}
]
}
```
------
1. 前のステップで作成したポリシーを送信先に添付します。
```
aws logs put-destination-policy \
--destination-name "testDestination" \
--access-policy file://~/AccessPolicy.json
```
このアクセスポリシーにより、ID 111111111111 の AWS アカウントのユーザーは、ARN arn:aws:logs:*region*:999999999999:destination:testDestination の送信先に対して **PutSubscriptionFilter** を呼び出すことができます。他のユーザーがこの送信先に対して PutSubscriptionFilter を呼び出そうとしても、それは却下されます。
アクセスポリシーに照らし合わせてユーザーの権限を検証するには、「*IAM ユーザーガイド*」の「[Using Policy Validator](https://docs.aws.amazon.com/IAM/latest/UserGuide/policies_policy-validator.html)」(Policy Validator の使用) を参照してください。
完了したら、クロスアカウントのアクセス許可 AWS Organizations に を使用している場合は、「」の手順に従います[ステップ 2: IAM ロールを作成する (組織を使用している場合のみ)](CreateSubscriptionFilter-IAMrole-Account.md)。組織を使用せずに他のアカウントに直接アクセス許可を付与する場合は、そのステップを飛ばして「[ステップ 3: アカウントレベルのサブスクリプションフィルタポリシーを作成する](CreateSubscriptionFilter-Account.md)」に進みます。
# ステップ 2: IAM ロールを作成する (組織を使用している場合のみ)
前のセクションで アカウント `111111111111` に直接アクセス許可を付与するのではなく、アカウント `111111111111` が属する組織にアクセス許可を付与するアクセスポリシーを使用することにより送信先を作成した場合は、このセクションのステップを実行します。それ以外の場合は、「[ステップ 3: アカウントレベルのサブスクリプションフィルタポリシーを作成する](CreateSubscriptionFilter-Account.md)」に進みます。
このセクションのステップにより、CloudWatch が想定する IAM ロールを作成し、送信者アカウントが受信者の送信先に対してサブスクリプションフィルターを作成する権限を持っているかどうかを検証できます。
このセクションの手順は、送信者アカウントで実行してください。ロールは送信者アカウントに存在する必要があり、このロールの ARN はサブスクリプションフィルターで指定します。この例では、送信者アカウントは `111111111111` です。
**を使用してクロスアカウントログサブスクリプションに必要な IAM ロールを作成するには AWS Organizations**
1. 以下の信頼ポリシーを作成し、`/TrustPolicyForCWLSubscriptionFilter.json` という名前のテキストファイルに保存します。このポリシーの作成にはテキストエディタを使用します。IAM コンソールは使用しないでください。
```
{
"Statement": {
"Effect": "Allow",
"Principal": { "Service": "logs.amazonaws.com" },
"Action": "sts:AssumeRole"
}
}
```
1. このポリシーを使用する IAM ロールを作成します。下記のコマンドが返す `Arn` の値は後ほど必要になるため、書き留めておきます。この例では、作成するロールに `CWLtoSubscriptionFilterRole` という名前を付けます。
```
aws iam create-role \
--role-name CWLtoSubscriptionFilterRole \
--assume-role-policy-document file://~/TrustPolicyForCWLSubscriptionFilter.json
```
1. アクセス許可ポリシーを作成して、CloudWatch Logs がアカウントで実行できるアクションを定義します。
1. まず、テキストエディタを使用して、`~/PermissionsForCWLSubscriptionFilter.json` という名前のファイルに以下のようなアクセス許可ポリシーを作成します。
```
{
"Statement": [
{
"Effect": "Allow",
"Action": "logs:PutLogEvents",
"Resource": "arn:aws:logs:region:111111111111:log-group:LogGroupOnWhichSubscriptionFilterIsCreated:*"
}
]
}
```
1. 次のコマンドを入力して、先ほど作成したアクセス許可ポリシーを、ステップ 2 で作成したロールに関連付けます。
```
aws iam put-role-policy
--role-name CWLtoSubscriptionFilterRole
--policy-name Permissions-Policy-For-CWL-Subscription-filter
--policy-document file://~/PermissionsForCWLSubscriptionFilter.json
```
終了したら、「[ステップ 3: アカウントレベルのサブスクリプションフィルタポリシーを作成する](CreateSubscriptionFilter-Account.md)」に進みます。
# ステップ 3: アカウントレベルのサブスクリプションフィルタポリシーを作成する
送信先を作成したら、ログデータの受信者アカウントは、送信先の ARN (arn:aws:logs:us-east-1:999999999999:destination:testDestination) を他の AWS アカウントと共有できるようになります。これにより、これらのアカウントは同じ送信先にログイベントを送信できます。この後、これらの他の送信アカウントのユーザーは、この送信先に対するサブスクリプションフィルタをそれぞれのロググループに作成します。サブスクリプションフィルタは、特定のロググループから特定の送信先へのリアルタイムログデータの送信をすぐに開始します。
**注記**
サブスクリプションフィルターのためのアクセス許可を組織全体に付与する際は、[ステップ 2: IAM ロールを作成する (組織を使用している場合のみ)](CreateSubscriptionFilter-IAMrole-Account.md) で作成した IAM ロールの ARN を使用する必要があります。
次の例では、アカウントレベルのサブスクリプションフィルターポリシーが送信アカウントで作成されます。フィルターは送信者アカウント `111111111111` に関連付けられ、フィルターと選択基準に一致するすべてのログイベントが以前に作成した送信先に配信されます。この送信先は、「RecipientStream」という ストリームをカプセル化します。
`selection-criteria` フィールドはオプションですが、サブスクリプションフィルターから無限のログ再帰を引き起こす可能性のあるロググループを除外するための重要なフィールドです。この問題および除外するロググループを判断する方法については、「[ログの再帰防止](Subscriptions-recursion-prevention.md)」を参照してください。現在、NOT IN は `selection-criteria` でサポートされている唯一の演算子です。
```
aws logs put-account-policy \
--policy-name "CrossAccountStreamsExamplePolicy" \
--policy-type "SUBSCRIPTION_FILTER_POLICY" \
--policy-document '{"DestinationArn":"arn:aws:logs:region:999999999999:destination:testDestination", "FilterPattern": "", "Distribution": "Random"}' \
--selection-criteria 'LogGroupName NOT IN ["LogGroupToExclude1", "LogGroupToExclude2"]' \
--scope "ALL"
```
送信者アカウントのロググループと送信先は同じ AWS リージョンに存在している必要があります。ただし、送信先は、別のリージョンにある Amazon Kinesis Data Streams ストリームなどの AWS リソースを指すことができます。
# ログイベントの送信を検証
アカウントレベルのサブスクリプションフィルターポリシーを作成したら、CloudWatch Logs が、フィルタパターンおよび選択基準と一致するすべての受信ログイベントを、送信先ストリーム内でカプセル化されている「**RecipientStream**」という名前のストリームに転送します。送信先所有者は、**aws kinesis get-shard-iterator** コマンドを使用して Amazon Kinesis Data Streams シャードを取得し、**aws kinesis get-records** コマンドを使用して Amazon Kinesis Data Streams レコードを取得することで、これが起こっていることを確認できます。
```
aws kinesis get-shard-iterator \
--stream-name RecipientStream \
--shard-id shardId-000000000000 \
--shard-iterator-type TRIM_HORIZON
{
"ShardIterator":
"AAAAAAAAAAFGU/kLvNggvndHq2UIFOw5PZc6F01s3e3afsSscRM70JSbjIefg2ub07nk1y6CDxYR1UoGHJNP4m4NFUetzfL+wev+e2P4djJg4L9wmXKvQYoE+rMUiFq+p4Cn3IgvqOb5dRA0yybNdRcdzvnC35KQANoHzzahKdRGb9v4scv+3vaq+f+OIK8zM5My8ID+g6rMo7UKWeI4+IWiKEXAMPLE"
}
aws kinesis get-records \
--limit 10 \
--shard-iterator
"AAAAAAAAAAFGU/kLvNggvndHq2UIFOw5PZc6F01s3e3afsSscRM70JSbjIefg2ub07nk1y6CDxYR1UoGHJNP4m4NFUetzfL+wev+e2P4djJg4L9wmXKvQYoE+rMUiFq+p4Cn3IgvqOb5dRA0yybNdRcdzvnC35KQANoHzzahKdRGb9v4scv+3vaq+f+OIK8zM5My8ID+g6rMo7UKWeI4+IWiKEXAMPLE"
```
**注記**
Amazon Kinesis Data Streams がデータを返す前に、`get-records`コマンドを数回再実行する必要がある場合があります。
Amazon Kinesis Data Streams レコードの配列を含むレスポンスが表示されます。Amazon Kinesis Data Streams レコードのデータ属性は gzip 形式で圧縮され、base64 でエンコードされます。raw データは、コマンドラインから次の UNIX コマンドを使用して調べることができます。
```
echo -n "" | base64 -d | zcat
```
base64 でデコードおよび解凍されたデータは、次の構造を使用して JSON としてフォーマットされます。
```
{
"owner": "111111111111",
"logGroup": "CloudTrail/logs",
"logStream": "111111111111_CloudTrail/logs_us-east-1",
"subscriptionFilters": [
"RecipientStream"
],
"messageType": "DATA_MESSAGE",
"logEvents": [
{
"id": "3195310660696698337880902507980421114328961542429EXAMPLE",
"timestamp": 1432826855000,
"message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}"
},
{
"id": "3195310660696698337880902507980421114328961542429EXAMPLE",
"timestamp": 1432826855000,
"message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}"
},
{
"id": "3195310660696698337880902507980421114328961542429EXAMPLE",
"timestamp": 1432826855000,
"message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}"
}
]
}
```
データ構造の主な要素は次のとおりです。
**messageType**
データメッセージは、"DATA\$1MESSAGE" 型を使用します。CloudWatch Logs は、主に送信先に到達可能かどうかを確認するために、「CONTROL\$1MESSAGE」タイプの Amazon Kinesis Data Streams レコードを出力することがあります。
**owner (オーナー)**
元のログデータの AWS アカウント ID。
**logGroup**
発行元ログデータのロググループ名。
**logStream**
発行元ログデータのログストリーム名。
**subscriptionFilters**
発行元ログデータと一致したサブスクリプションフィルタ名のリスト。
**logEvents**
ログイベントレコードの配列として表される実際のログデータ。"id" プロパティは、各ログイベントの一意識別子です。
**policyLevel**
ポリシーが適用されたレベル。「ACCOUNT\$1LEVEL\$1POLICY」は、アカウントレベルのサブスクリプションフィルターポリシーの `policyLevel` です。
# ランタイムの送信先のメンバーシップを変更
所有する送信先のユーザーのメンバーシップを追加または削除する必要がある場合があります。新しいアクセスポリシーを使用して、送信先で `put-destination-policy` コマンドを使用できます。次の例では、先ほど追加したアカウント **111111111111** がログデータの送信を停止し、アカウント **222222222222** が有効になります。
1. 現在 **testDestination** という送信先に関連付けられているポリシーをフェッチし、**AccessPolicy** を書き留めておきます。
```
aws logs describe-destinations \
--destination-name-prefix "testDestination"
{
"Destinations": [
{
"DestinationName": "testDestination",
"RoleArn": "arn:aws:iam::999999999999:role/CWLtoKinesisRole",
"DestinationArn": "arn:aws:logs:region:999999999999:destination:testDestination",
"TargetArn": "arn:aws:kinesis:region:999999999999:stream/RecipientStream",
"AccessPolicy": "{\"Version\": \"2012-10-17\", \"Statement\": [{\"Sid\": \"\", \"Effect\": \"Allow\", \"Principal\": {\"AWS\": \"111111111111\"}, \"Action\": \"logs:PutSubscriptionFilter\", \"Resource\": \"arn:aws:logs:region:999999999999:destination:testDestination\"}] }"
}
]
}
```
1. アカウント **111111111111** が停止したこととアカウント **222222222222** が有効になったことを反映させるためにポリシーを更新します。このポリシーを **\$1/NewAccessPolicy.json** ファイルに配置します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"AWS": "222222222222"
},
"Action": [
"logs:PutSubscriptionFilter",
"logs:PutAccountPolicy"
],
"Resource": "arn:aws:logs:us-east-1:999999999999:destination:testDestination"
}
]
}
```
------
1. **PutDestinationPolicy** を呼び出して、**NewAccessPolicy.json** ファイルで定義されているポリシーを送信先に関連付けます。
```
aws logs put-destination-policy \
--destination-name "testDestination" \
--access-policy file://~/NewAccessPolicy.json
```
これにより、最終的には、アカウント ID **111111111111** からのログイベントが無効になります。アカウント ID **222222222222** の所有者がサブスクリプションフィルターを作成すると、すぐに **222222222222** からのログイベントが送信先に送信されるようになります。
# 既存のクロスアカウントサブスクリプションの更新
送信先アカウントが特定の送信者アカウントにのみアクセス許可を付与しているクロスアカウントのログサブスクリプションがあり、このサブスクリプションを更新して送信先アカウントが組織内のすべてのアカウントにアクセスできるようにする場合は、このセクションのステップを実施します。
**Topics**
+ [ステップ 1: サブスクリプションフィルターを更新する](Cross-Account-Log_Subscription-Update-filter-Account.md)
+ [ステップ 2: 既存の送信先アクセスポリシーを更新する](Cross-Account-Log_Subscription-Update-policy-Account.md)
# ステップ 1: サブスクリプションフィルターを更新する
**注記**
この手順は、[AWS サービスからのログ記録を有効にする](AWS-logs-and-resource-policy.md) に記載されているサービスによって作成されたログのクロスアカウントのサブスクリプションにのみ必要です。これらのロググループのいずれかで作成されたログを操作していない場合は、[ステップ 2: 既存の送信先アクセスポリシーを更新する](Cross-Account-Log_Subscription-Update-policy-Account.md) にスキップできます。
場合によっては、送信先アカウントにログを送信する、すべての送信者アカウントのサブスクリプションフィルターを更新する必要があります。この更新により IAM ロールが追加されます。IAM ロールは CloudWatch が引き受けることができ、送信者アカウントが受信者アカウントにログを送信する権限を持っていることを検証できます。
すべての送信者アカウントについてクロスアカウントサブスクリプションのアクセス許可に組織 ID を使用するように更新するには、このセクションのステップを実施します。
このセクションの例では、2 つのアカウント `111111111111` と `222222222222` は、アカウント `999999999999` にログを送信するために作成されたサブスクリプションフィルターをすでに持っています。既存のサブスクリプションフィルター値は次のとおりです。
```
## Existing Subscription Filter parameter values
{
"DestinationArn": "arn:aws:logs:region:999999999999:destination:testDestination",
"FilterPattern": "{$.userIdentity.type = Root}",
"Distribution": "Random"
}
```
現在のサブスクリプションフィルターパラメータ値を見つける必要がある場合は、次のコマンドを入力します。
```
aws logs describe-account-policies \
--policy-type "SUBSCRIPTION_FILTER_POLICY" \
--policy-name "CrossAccountStreamsExamplePolicy"
```
**サブスクリプションフィルターを更新して、クロスアカウントログの権限で組織 ID の使用をスタートする方法**
1. 以下の信頼ポリシーを作成し、`~/TrustPolicyForCWL.json` という名前のテキストファイルに保存します。このポリシーの作成にはテキストエディタを使用します。IAM コンソールは使用しないでください。
```
{
"Statement": {
"Effect": "Allow",
"Principal": { "Service": "logs.amazonaws.com" },
"Action": "sts:AssumeRole"
}
}
```
1. このポリシーを使用する IAM ロールを作成します。下記のコマンドが返す `Arn` 値の `Arn` の値は後ほど必要になるため、書き留めておきます。この例では、作成するロールに `CWLtoSubscriptionFilterRole` という名前を付けます。
```
aws iam create-role
\ --role-name CWLtoSubscriptionFilterRole
\ --assume-role-policy-document file://~/TrustPolicyForCWL.json
```
1. アクセス許可ポリシーを作成して、CloudWatch Logs がアカウントで実行できるアクションを定義します。
1. まず、テキストエディタを使用して、`/PermissionsForCWLSubscriptionFilter.json` という名前のファイルに以下のようなアクセス許可ポリシーを作成します。
```
{
"Statement": [
{
"Effect": "Allow",
"Action": "logs:PutLogEvents",
"Resource": "arn:aws:logs:region:111111111111:log-group:LogGroupOnWhichSubscriptionFilterIsCreated:*"
}
]
}
```
1. 次のコマンドを入力して、先ほど作成したアクセス許可ポリシーを、ステップ 2 で作成したロールに関連付けます。
```
aws iam put-role-policy
--role-name CWLtoSubscriptionFilterRole
--policy-name Permissions-Policy-For-CWL-Subscription-filter
--policy-document file://~/PermissionsForCWLSubscriptionFilter.json
```
1. 次のコマンドを入力して、サブスクリプションフィルターポリシーを更新します。
```
aws logs put-account-policy \
--policy-name "CrossAccountStreamsExamplePolicy" \
--policy-type "SUBSCRIPTION_FILTER_POLICY" \
--policy-document '{"DestinationArn":"arn:aws:logs:region:999999999999:destination:testDestination", "FilterPattern": "{$.userIdentity.type = Root}", "Distribution": "Random"}' \
--selection-criteria 'LogGroupName NOT IN ["LogGroupToExclude1", "LogGroupToExclude2"]' \
--scope "ALL"
```
# ステップ 2: 既存の送信先アクセスポリシーを更新する
すべての送信者アカウントのサブスクリプションフィルターを更新した後、受信者アカウントの送信先アクセスポリシーを更新できます。
以下の例では、受信者アカウントは `999999999999`、送信先は `testDestination` となっています。
この更新により、ID `o-1234567890` を持つ組織に属するすべてのアカウントが、受信者アカウントにログを送信できるようになりました。サブスクリプションフィルターが作成されたアカウントのみが、実際に受信者アカウントにログを送信します。
**受信者アカウントの送信先アクセスポリシーを更新して、権限の組織 ID の使用をスタートする方法**
1. 受信者アカウントで、テキストエディタを使用して、以下の内容の `~/AccessPolicy.json` ファイルを作成します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": "*",
"Action": [
"logs:PutSubscriptionFilter",
"logs:PutAccountPolicy"
],
"Resource": "arn:aws:logs:us-east-1:999999999999:destination:testDestination",
"Condition": {
"StringEquals": {
"aws:PrincipalOrgID": [
"o-1234567890"
]
}
}
}
]
}
```
------
1. 次のコマンドを入力して、先ほど作成したポリシーを既存の送信先にアタッチします。特定の AWS アカウント ID を一覧表示するアクセスポリシーではなく、組織 ID を持つアクセスポリシーを使用するように送信先を更新するには、 `force`パラメータを含めIDs。
**警告**
にリストされている AWS サービスによって送信されたログを使用している場合は[AWS サービスからのログ記録を有効にする](AWS-logs-and-resource-policy.md)、このステップを実行する前に、「」で説明されているように、まずすべての送信者アカウントのサブスクリプションフィルターを更新しておく必要があります[ステップ 1: サブスクリプションフィルターを更新する](Cross-Account-Log_Subscription-Update-filter-Account.md)。
```
aws logs put-destination-policy
\ --destination-name "testDestination"
\ --access-policy file://~/AccessPolicy.json
\ --force
```
# Firehose を使用したクロスアカウント、クロスリージョン、アカウントレベルのサブスクリプション
複数のアカウントでログデータを共有するには、ログデータの送信者と受信者を確立する必要があります。
+ [**Log data sender (ログデータの送信者)**] — 受取人から送信先情報を取得し、そのログイベントを特定の送信先に送信する準備が完了していることを CloudWatch Logs に通知します。このセクションの残りの手順では、ログデータ送信者は架空の AWS アカウント番号 111111111111 で表示されます。
+ **ログデータ受信者** — Amazon Kinesis Data Streams ストリームをカプセル化する送信先を設定し、受信者がログデータを受信したいことを CloudWatch Logs に知らせます。この後、受信者は自分の送信先に関する情報を送信者と共有します。このセクションの残りの手順では、ログデータ受信者は架空の AWS アカウント番号 222222222222 で表示されます。
このセクションの例では、Amazon S3 ストレージで Firehose 配信ストリームを使用しています。異なる設定で Firehose 配信ストリームを設定することもできます。詳細については、「[Creating a Firehose Delivery Stream](https://docs.aws.amazon.com/firehose/latest/dev/basic-create.html)」を参照してください。
**注記**
ロググループと送信先は同じ AWS リージョンにある必要があります。ただし、送信先が指す AWS リソースは、別のリージョンに配置することができます。
**注記**
***[同じアカウント]*** と ***[クロスリージョン]*** 配信ストリームに対して Firehose サブスクリプションフィルターがサポートされています。
**Topics**
+ [ステップ 1: Firehose 配信ストリームを作成する](CreateFirehoseStream-Account.md)
+ [ステップ 2: 送信先を作成する](CreateFirehoseStreamDestination-Account.md)
+ [ステップ 3: アカウントレベルのサブスクリプションフィルタポリシーを作成する](CreateSubscriptionFilterFirehose-Account.md)
+ [ログイベントの送信の検証](ValidateLogEventFlowFirehose-Account.md)
+ [実行時の送信先のメンバーシップの変更](ModifyDestinationMembershipFirehose-Account.md)
# ステップ 1: Firehose 配信ストリームを作成する
**重要**
以下の手順を実行する前に、Firehose が Amazon S3 バケットにアクセスできるように、アクセスポリシーを使用する必要があります。詳細については、「[Amazon Data Firehose 開発者ガイド](https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html#using-iam-s3)」の「*Controlling Access*」を参照してください。
このセクションのすべての手順 (ステップ 1) は、ログデータの受取人アカウントで行われます。
次のサンプルコマンドでは、米国東部 (バージニア北部) が使用されています。このリージョンを、デプロイに適したリージョンに置き換えます。
**送信先として使用する Firehose 配信ストリームを作成するには**
1. Amazon S3 バケットの作成
```
aws s3api create-bucket --bucket amzn-s3-demo-bucket --create-bucket-configuration LocationConstraint=us-east-1
```
1. バケットにデータを配置するためのアクセス許可を Firehose に付与する IAM ロールを作成します。
1. まず、テキストエディタを使用して、ファイル `~/TrustPolicyForFirehose.json` で信頼ポリシーを作成します。
```
{ "Statement": { "Effect": "Allow", "Principal": { "Service": "firehose.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId":"222222222222" } } } }
```
1. 作成したばかりの信頼ポリシーファイルを指定して、IAM ロールを作成します。
```
aws iam create-role \
--role-name FirehosetoS3Role \
--assume-role-policy-document file://~/TrustPolicyForFirehose.json
```
1. このコマンドの出力は、次のようになります。ロール名とロール ARN を書き留めます。
```
{
"Role": {
"Path": "/",
"RoleName": "FirehosetoS3Role",
"RoleId": "AROAR3BXASEKW7K635M53",
"Arn": "arn:aws:iam::222222222222:role/FirehosetoS3Role",
"CreateDate": "2021-02-02T07:53:10+00:00",
"AssumeRolePolicyDocument": {
"Statement": {
"Effect": "Allow",
"Principal": {
"Service": "firehose.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "222222222222"
}
}
}
}
}
}
```
1. アクセス許可ポリシーを作成し、Firehose がアカウントで実行できるアクションを定義します。
1. まず、テキストエディタを使用して、`~/PermissionsForFirehose.json` という名前のファイルに以下のようなアクセス許可ポリシーを作成します。ユースケースによっては、このファイルにさらにアクセス権限を追加する必要がある場合があります。
```
{
"Statement": [{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:PutObjectAcl",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
}]
}
```
1. 次のコマンドを入力して、先ほど作成したアクセス権限ポリシーを IAM ロールに関連付けます。
```
aws iam put-role-policy --role-name FirehosetoS3Role --policy-name Permissions-Policy-For-Firehose-To-S3 --policy-document file://~/PermissionsForFirehose.json
```
1. 次のコマンドを入力して、Firehose 配信ストリームを作成します。*my-role-arn* および *amzn-s3-demo-bucket2-arn* をデプロイに適した値に置き換えます。
```
aws firehose create-delivery-stream \
--delivery-stream-name 'my-delivery-stream' \
--s3-destination-configuration \
'{"RoleARN": "arn:aws:iam::222222222222:role/FirehosetoS3Role", "BucketARN": "arn:aws:s3:::amzn-s3-demo-bucket"}'
```
出力は次の例に類似したものになります:
```
{
"DeliveryStreamARN": "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream"
}
```
# ステップ 2: 送信先を作成する
**重要**
この手順のステップは、ログデータの受取人アカウントで行われます。
送信先が作成されると、CloudWatch Logs は受信者アカウントに代わってテストメッセージを宛先に送信します。サブスクリプションフィルターが後でアクティブになると、CloudWatch Logs はソースアカウントに代わってログイベントを宛先に送信します。
**送信先を作成するには**
1. [ステップ 1: Firehose 配信ストリームを作成する](CreateFirehoseStream-Account.md) で作成した Firehose ストリームがアクティブになるまで待ちます。次のコマンドを使用して、**StreamDescription.StreamStatus** プロパティを確認できます。
```
aws firehose describe-delivery-stream --delivery-stream-name "my-delivery-stream"
```
さらに、後の手順で使用する必要があるため、**DeliveryStreamDescription.DeliveryStreamARN** 値を書き留めます。このコマンドの出力例:
```
{
"DeliveryStreamDescription": {
"DeliveryStreamName": "my-delivery-stream",
"DeliveryStreamARN": "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream",
"DeliveryStreamStatus": "ACTIVE",
"DeliveryStreamEncryptionConfiguration": {
"Status": "DISABLED"
},
"DeliveryStreamType": "DirectPut",
"VersionId": "1",
"CreateTimestamp": "2021-02-01T23:59:15.567000-08:00",
"Destinations": [
{
"DestinationId": "destinationId-000000000001",
"S3DestinationDescription": {
"RoleARN": "arn:aws:iam::222222222222:role/FirehosetoS3Role",
"BucketARN": "arn:aws:s3:::amzn-s3-demo-bucket",
"BufferingHints": {
"SizeInMBs": 5,
"IntervalInSeconds": 300
},
"CompressionFormat": "UNCOMPRESSED",
"EncryptionConfiguration": {
"NoEncryptionConfig": "NoEncryption"
},
"CloudWatchLoggingOptions": {
"Enabled": false
}
},
"ExtendedS3DestinationDescription": {
"RoleARN": "arn:aws:iam::222222222222:role/FirehosetoS3Role",
"BucketARN": "arn:aws:s3:::amzn-s3-demo-bucket",
"BufferingHints": {
"SizeInMBs": 5,
"IntervalInSeconds": 300
},
"CompressionFormat": "UNCOMPRESSED",
"EncryptionConfiguration": {
"NoEncryptionConfig": "NoEncryption"
},
"CloudWatchLoggingOptions": {
"Enabled": false
},
"S3BackupMode": "Disabled"
}
}
],
"HasMoreDestinations": false
}
}
```
配信ストリームがアクティブ状態で表示されるまでに 1～2 分かかる場合があります。
1. 配信ストリームがアクティブになったら、Firehose ストリームにデータを置くためのアクセス許可を CloudWatch Logs に付与する IAM ロールを作成します。まず、ファイル **\$1/TrustPolicyForCWL.json** で信頼ポリシーを作成する必要があります。テキストエディタを使用してこのポリシーを作成します。CloudWatch Logs エンドポイントの詳細については、[Amazon CloudWatch Logs エンドポイントおよびクォータ](https://docs.aws.amazon.com/general/latest/gr/cwl_region.html)を参照してください。
このポリシーには、「混乱した代理」のセキュリティ上の問題を防止するための `sourceAccountId` が指定された `aws:SourceArn` グローバル条件コンテキストキーが含まれています。最初の呼び出しでソースアカウント ID が不明な場合は、送信元 ARN フィールドに送信先 ARN を指定することをお勧めします。後続の呼び出しでは、送信元 ARN を、最初の呼び出しで取得した実際の送信元 ARN に設定する必要があります。詳細については、「[混乱した代理の防止](Subscriptions-confused-deputy.md)」を参照してください。
```
{
"Statement": {
"Effect": "Allow",
"Principal": {
"Service": "logs.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringLike": {
"aws:SourceArn": [
"arn:aws:logs:region:sourceAccountId:*",
"arn:aws:logs:region:recipientAccountId:*"
]
}
}
}
}
```
1. **aws iam create-role** コマンドを使用して、作成した信頼ポリシーファイルを指定して IAM ロールを作成します。
```
aws iam create-role \
--role-name CWLtoKinesisFirehoseRole \
--assume-role-policy-document file://~/TrustPolicyForCWL.json
```
以下は出力例です。後のステップで使用する必要があるため、`Role.Arn` の戻り値を書き留めます。
```
{
"Role": {
"Path": "/",
"RoleName": "CWLtoKinesisFirehoseRole",
"RoleId": "AROAR3BXASEKYJYWF243H",
"Arn": "arn:aws:iam::222222222222:role/CWLtoKinesisFirehoseRole",
"CreateDate": "2023-02-02T08:10:43+00:00",
"AssumeRolePolicyDocument": {
"Statement": {
"Effect": "Allow",
"Principal": {
"Service": "logs.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringLike": {
"aws:SourceArn": [
"arn:aws:logs:region:sourceAccountId:*",
"arn:aws:logs:region:recipientAccountId:*"
]
}
}
}
}
}
}
```
1. CloudWatch Logs がアカウントで実行できるアクションを定義するアクセス許可ポリシーを作成します。まず、テキストエディタを使用してファイル **\$1/PermissionsForCWL.json** でアクセス許可ポリシーを作成します。
```
{
"Statement":[
{
"Effect":"Allow",
"Action":["firehose:*"],
"Resource":["arn:aws:firehose:region:222222222222:*"]
}
]
}
```
1. 次のコマンドを入力して、アクセス権限ポリシーをロールに関連付けます。
```
aws iam put-role-policy --role-name CWLtoKinesisFirehoseRole --policy-name Permissions-Policy-For-CWL --policy-document file://~/PermissionsForCWL.json
```
1. Firehose 配信ストリームがアクティブ状態になり、IAM ロールが作成されたら、CloudWatch Logs の送信先を作成できます。
1. このステップでは、アクセスポリシーと送信先は関連付けられません。送信先の作成を完了するには 2 つのステップを行う必要がありますが、このステップはその最初のステップです。後のステップでこれを `destination.arn` として使用するため、ペイロードで返される新しい宛先の ARN を書き留めます。
```
aws logs put-destination \
--destination-name "testFirehoseDestination" \
--target-arn "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream" \
--role-arn "arn:aws:iam::222222222222:role/CWLtoKinesisFirehoseRole"
{
"destination": {
"destinationName": "testFirehoseDestination",
"targetArn": "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream",
"roleArn": "arn:aws:iam::222222222222:role/CWLtoKinesisFirehoseRole",
"arn": "arn:aws:logs:us-east-1:222222222222:destination:testFirehoseDestination"}
}
```
1. 前のステップが完了したら、ログデータ受取人アカウント (222222222222) で、アクセスポリシーを送信先に関連付けます。このポリシーにより、ログデータの送信者アカウント (111111111111) に対し、ログデータの受信者アカウント (222222222222) にある送信先にアクセスすることを許可します。テキストエディタを使用して、このポリシーを `~/AccessPolicy.json` ファイルに配置できます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement" : [
{
"Sid" : "",
"Effect" : "Allow",
"Principal" : {
"AWS" : "111111111111"
},
"Action" : ["logs:PutSubscriptionFilter","logs:PutAccountPolicy"],
"Resource" : "arn:aws:logs:us-east-1:222222222222:destination:testFirehoseDestination"
}
]
}
```
------
1. これにより、誰が送信先に書き込むことができるかを定義するポリシーが作成されます。このポリシーでは、送信先にアクセスするための `logs:PutSubscriptionFilter` および `logs:PutAccountPolicy` アクションを指定する必要があります。クロスアカウントのユーザーは、`PutSubscriptionFilter` および `PutAccountPolicy` アクションを使用して送信先にログイベントを送信します。
```
aws logs put-destination-policy \
--destination-name "testFirehoseDestination" \
--access-policy file://~/AccessPolicy.json
```
# ステップ 3: アカウントレベルのサブスクリプションフィルタポリシーを作成する
送信側のアカウント (この例では 111111111111) に切り替えます。次に、送信側のアカウントにアカウントレベルのサブスクリプションフィルターポリシーを作成します。この例では、フィルターにより、2 つを除くすべてのロググループに含まれる文字列 `ERROR` を含むすべてのログイベントが、以前に作成した送信先に配信されます。
```
aws logs put-account-policy \
--policy-name "CrossAccountFirehoseExamplePolicy" \
--policy-type "SUBSCRIPTION_FILTER_POLICY" \
--policy-document '{"DestinationArn":"arn:aws:logs:us-east-1:222222222222:destination:testFirehoseDestination", "FilterPattern": "{$.userIdentity.type = AssumedRole}", "Distribution": "Random"}' \
--selection-criteria 'LogGroupName NOT IN ["LogGroupToExclude1", "LogGroupToExclude2"]' \
--scope "ALL"
```
送信アカウントのロググループと送信先は同じ AWS リージョンに存在している必要があります。ただし、送信先は、別のリージョンにある Firehose ストリームなどの AWS リソースを指すことができます。
# ログイベントの送信の検証
サブスクリプションフィルターを作成すると、CloudWatch Logs から、フィルタパターンと選択基準に一致するすべての受信ログイベントが Kinesis Data Firehose 配信ストリームに転送されます。データは、Firehose 配信ストリームに設定されている時間バッファ間隔に基づいて、Amazon S3 バケットに順次表示されます。十分な時間が経過すると、Amazon S3 バケットをチェックしてデータを確認できます。バケットを確認するには、次のコマンドを入力します。
```
aws s3api list-objects --bucket 'amzn-s3-demo-bucket'
```
そのコマンドの出力は、次のようになります。
```
{
"Contents": [
{
"Key": "2021/02/02/08/my-delivery-stream-1-2021-02-02-08-55-24-5e6dc317-071b-45ba-a9d3-4805ba39c2ba",
"LastModified": "2023-02-02T09:00:26+00:00",
"ETag": "\"EXAMPLEa817fb88fc770b81c8f990d\"",
"Size": 198,
"StorageClass": "STANDARD",
"Owner": {
"DisplayName": "firehose+2test",
"ID": "EXAMPLE27fd05889c665d2636218451970ef79400e3d2aecca3adb1930042e0"
}
}
]
}
```
その後、次のコマンドを入力して、バケットから特定のオブジェクトを取得できます。`key` の値を、前のコマンドで検索した値に置き換えます。
```
aws s3api get-object --bucket 'amzn-s3-demo-bucket' --key '2021/02/02/08/my-delivery-stream-1-2021-02-02-08-55-24-5e6dc317-071b-45ba-a9d3-4805ba39c2ba' testfile.gz
```
Simple Storage Service (Amazon S3) オブジェクトのデータは、gzip 形式で圧縮されます。raw データは、コマンドラインから次のコマンドを使用して調べることができます。
Linux:
```
zcat testfile.gz
```
macOS:
```
zcat
所有している送信先からログ送信者を追加または削除しなければならない状況が発生することがあります。新しいアクセスポリシーが関連付けられている送信先に対して **PutDestinationPolicy** および `PutAccountPolicy` アクションを使用できます。次の例では、先ほど追加したアカウント **111111111111** がログデータの送信を停止し、アカウント **333333333333** が有効になります。
1. 現在 **testDestination** という送信先に関連付けられているポリシーをフェッチし、**AccessPolicy** を書き留めておきます。
```
aws logs describe-destinations \
--destination-name-prefix "testFirehoseDestination"
```
返されたデータは、次のように表示される場合があります。
```
{
"destinations": [
{
"destinationName": "testFirehoseDestination",
"targetArn": "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream",
"roleArn": "arn:aws:iam:: 222222222222:role/CWLtoKinesisFirehoseRole",
"accessPolicy": "{\n \"Version\" : \"2012-10-17\",\n \"Statement\" : [\n {\n \"Sid\" : \"\",\n \"Effect\" : \"Allow\",\n \"Principal\" : {\n \"AWS\" : \"111111111111 \"\n },\n \"Action\" : \"logs:PutSubscriptionFilter\",\n \"Resource\" : \"arn:aws:logs:us-east-1:222222222222:destination:testFirehoseDestination\"\n }\n ]\n}\n\n",
"arn": "arn:aws:logs:us-east-1: 222222222222:destination:testFirehoseDestination",
"creationTime": 1612256124430
}
]
}
```
1. アカウント **111111111111** が停止したこととアカウント **333333333333** が有効になったことを反映させるためにポリシーを更新します。このポリシーを **\$1/NewAccessPolicy.json** ファイルに配置します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement" : [
{
"Sid" : "",
"Effect" : "Allow",
"Principal" : {
"AWS" : "333333333333 "
},
"Action" : ["logs:PutSubscriptionFilter","logs:PutAccountPolicy"],
"Resource" : "arn:aws:logs:us-east-1:222222222222:destination:testFirehoseDestination"
}
]
}
```
------
1. 次のコマンドを使用して、**NewAccessPolicy.json** ファイルで定義されたポリシーを送信先に関連付けます。
```
aws logs put-destination-policy \
--destination-name "testFirehoseDestination" \
--access-policy file://~/NewAccessPolicy.json
```
これにより、最終的には、アカウント ID **111111111111** からのログイベントが無効になります。アカウント ID **333333333333** の所有者がサブスクリプションフィルターを作成すると、すぐに **333333333333** からのログイベントが送信先に送信されるようになります。
# 混乱した代理の防止
混乱した代理問題は、アクションを実行する許可を持たないエンティティが、より特権のあるエンティティにアクションを実行するように強制できるセキュリティの問題です。では AWS、サービス間のなりすましにより、混乱した代理問題が発生する可能性があります。サービス間でのなりすましは、1 つのサービス (呼び出し元サービス) が、別のサービス (呼び出し対象サービス) を呼び出すときに発生する可能性があります。呼び出し元サービスは、本来ならアクセスすることが許可されるべきではない方法でその許可を使用して、別のお客様のリソースに対する処理を実行するように操作される場合があります。これを防ぐために、 は、アカウント内のリソースへのアクセス権が付与されたサービスプリンシパルを持つすべてのサービスのデータを保護するのに役立つツール AWS を提供します。
リソースポリシーで [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn)、[https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount)、[https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceorgid](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceorgid)、[https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceorgpaths](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceorgpaths) のグローバル条件コンテキストキーを使用し、別のサービスに付与するアクセス許可をそのリソースに制限することをお勧めします。1 つのリソースだけをクロスサービスのアクセスに関連付ける場合は、`aws:SourceArn` を使用します。アカウント内の任意のリソースをクロスサービスの使用に関連付ける場合は、`aws:SourceAccount` を使用します。組織内の任意のアカウントの任意のリソースをクロスサービスの使用に関連付ける場合は、`aws:SourceOrgID` を使用します。 AWS Organizations パス内の任意のアカウントのリソースをクロスサービスの使用に関連付ける場合は、`aws:SourceOrgPaths` を使用します。パスの使用と理解の詳細については、[AWS Organizations 「エンティティパスを理解する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_last-accessed-view-data-orgs.html#access_policies_last-accessed-viewing-orgs-entity-path)」を参照してください。
混乱した代理問題から保護するための最も効果的な方法は、リソースの完全な ARN を指定して、`aws:SourceArn` グローバル条件コンテキストキーを使用することです。リソースの完全な ARN が不明な場合や、複数のリソースを指定する場合には、グローバルコンテキスト条件キー `aws:SourceArn` で、ARN の未知部分を示すためにワイルドカード文字 (`*`) を使用します。例えば、`arn:aws:servicename:*:123456789012:*`。
`aws:SourceArn` の値に Amazon S3 バケット ARN などのアカウント ID が含まれていない場合は、両方の `aws:SourceAccount` と `aws:SourceArn` を使用して、アクセス許可を制限する必要があります。
混乱した代理問題から保護するために、リソースベースポリシー内のリソースの組織 ID または組織パスを指定しながら、`aws:SourceOrgID` または `aws:SourceOrgPaths` のグローバル条件コンテキストキーを使用してください。`aws:SourceOrgID` または `aws:SourceOrgPaths` キーを含むポリシーには正しいアカウントが自動的に組み込まれるため、組織のアカウントを追加、削除、移動する際には手動で更新する必要はありません。
で Amazon Kinesis Data Streams と Firehose にデータを書き込むための CloudWatch Logs へのアクセスを許可[ステップ 1: 送信先を作成する](CreateDestination.md)し、グローバル`aws:SourceArn`条件コンテキストキーを使用して混乱した代理問題を防ぐ方法[ステップ 2: 送信先を作成する](CreateFirehoseStreamDestination.md)を示すポリシー。
# ログの再帰防止
サブスクリプションフィルターの使用によって無限のログ再帰が引き起こされるリスクがあります。これを防止しなければ CloudWatch Logs と送信先の両方で取り込み料金が大幅に増加する可能性があります。これは、サブスクリプション配信ワークフローの結果としてログイベントを受信するロググループにサブスクリプションフィルターが関連付けられている場合に発生する可能性があります。ロググループに取り込まれたログは宛先に配信され、ロググループがより多くのログを取り込むようになり、その後再び宛先に転送され、再帰ループが作成されます。
例えば、Amazon S3 にログイベントを配信する送信先を Firehose とするサブスクリプションフィルターがあるとします。さらに、Amazon S3 に配信された新しいイベントを処理し、一部のログ自体を生成する Lambda 関数もあります。サブスクリプションフィルターが Lambda 関数のロググループに適用されると、関数によって生成されたログイベントは送信先で Firehose と Amazon S3 に転送され、その後再び関数が呼び出されます。これにより、より多くのログが生成されて Firehose と Amazon S3 に転送され、関数が次々と呼び出されます。その結果、無限ループが発生し、ログの取り込み、Firehose、Amazon S3 で利用料金の不測の増加につながります。
Lambda 関数が CloudWatch Logs でフローログが有効になっている VPC にアタッチされている場合、VPC のロググループもログの再帰を引き起こす可能性があります。
サブスクリプション配信ワークフローの一部であるロググループには、サブスクリプションフィルターを適用しないことをお勧めします。アカウントレベルのサブスクリプションフィルターでは、`PutAccountPolicy` API の `selectionCriteria` パラメータを使用して、これらのロググループをポリシーから除外します。
ロググループを除外する場合は、ログを生成し、サブスクリプション配信ワークフローの一部である可能性がある以下の AWS サービスを検討してください。
+ Amazon EC2 と Fargate
+ Lambda
+ AWS Step Functions
+ CloudWatch Logs で有効になっている Amazon VPC フローログ
**注記**
Lambda 送信先のロググループによって生成されたログイベントは、アカウントレベルのサブスクリプションフィルターポリシーの Lambda 関数には転送されません。この場合、アカウントサブスクリプションポリシーでは、`selectionCriteria` を使用する送信先 Lambda 関数のロググループを除外する必要はありません。