AWS::Logs::AccountPolicy
Creates or updates an account-level data protection policy or subscription filter policy that applies to all log groups or a subset of log groups in the account.
Data protection policy
A data protection policy can help safeguard sensitive data that's ingested by your log groups by auditing and masking the sensitive log data. Each account can have only one account-level data protection policy.
Important
Sensitive data is detected and masked when it is ingested into a log group. When you set a data protection policy, log events ingested into the log groups before that time are not masked.
If you create a data protection policy for your whole account, it applies to both existing log groups and all log groups that are created later in this account. The account policy is applied to existing log groups with eventual consistency. It might take up to 5 minutes before sensitive data in existing log groups begins to be masked.
By default, when a user views a log event that includes masked data, the sensitive data is replaced by asterisks.
A user who has the logs:Unmask
permission can use a
GetLogEvents or
FilterLogEvents
operation with the unmask
parameter set to true
to view the unmasked
log events. Users with the logs:Unmask
can also view unmasked data in the CloudWatch Logs
console by running a CloudWatch Logs Insights query with the unmask
query command.
For more information, including a list of types of data that can be audited and masked, see Protect sensitive log data with masking.
To create an account-level policy, you must be signed on with the logs:PutDataProtectionPolicy
and logs:PutAccountPolicy
permissions.
An account-level policy applies to all log groups in the account. You can also create a data protection policy that applies to just one log group. If a log group has its own data protection policy and the account also has an account-level data protection policy, then the two policies are cumulative. Any sensitive term specified in either policy is masked.
Subscription filter policy
A subscription filter policy sets up a real-time feed of log events from CloudWatch Logs to other AWS services. Account-level subscription filter policies apply to both existing log groups and log groups that are created later in this account. Supported destinations are Kinesis Data Streams, Firehose, and Lambda. When log events are sent to the receiving service, they are Base64 encoded and compressed with the GZIP format.
The following destinations are supported for subscription filters:
-
An Kinesis Data Streams data stream in the same account as the subscription policy, for same-account delivery.
-
An Firehose data stream in the same account as the subscription policy, for same-account delivery.
-
A Lambda function in the same account as the subscription policy, for same-account delivery.
-
A logical destination in a different account created with PutDestination, for cross-account delivery. Kinesis Data Streams and Firehose are supported as logical destinations.
Each account can have one account-level subscription filter policy.
If you are updating an existing filter, you must specify the correct name in PolicyName
.
To perform a PutAccountPolicy
subscription filter operation for any destination except a Lambda
function, you must also have the iam:PassRole
permission.
Field index policy
You can use field index policies to create indexes on fields found in log events in the log group. Creating field indexes lowers the scan volume for CloudWatch Logs Insights queries that reference those fields, because these queries attempt to skip the processing of log events that are known to not match the indexed field. Good fields to index are fields that you often need to query for. Common examples of indexes include request ID, session ID, user IDs, or instance IDs. For more information, see Create field indexes to improve query performance and reduce costs
For example, suppose you have created a field index for requestId
. Then, any
CloudWatch Logs Insights query on that log group that includes requestId = value
or requestId IN [value, value, ...]
will attempt to process only the log events where
the indexed field matches the specified value.
Matches of log events to the names of indexed fields are case-sensitive. For example, an indexed field
of RequestId
won't match a log event containing requestId
.
You can have one account-level field index policy that applies to all log groups in the account.
Or you can create as many as 20 account-level field index policies that are each scoped to a subset of log groups with
the SelectionCriteria
parameter. If you have multiple
account-level index policies with selection criteria, no two of them can use the same or overlapping log group name prefixes.
For example, if you have one policy filtered to log groups that start with my-log
, you can't have another field index
policy filtered to my-logpprod
or my-logging
.
Transformer policy
A log transformer policy transforms ingested log events into a different format, making them easier for you to process and analyze. You can also transform logs from different sources into standardized formats that contain relevant, source-specific information. After you have created a transformer, CloudWatch Logs performs this transformation at the time of log ingestion. You can then refer to the transformed versions of the logs during operations such as querying with CloudWatch Logs Insights or creating metric filters or subscription filters.
You can also use a transformer to copy metadata from metadata keys into the log events themselves. This metadata can include log group name, log stream name, account ID and Region.
A transformer for a log group is a series of processors, where each processor applies one type of transformation to the log events ingested into this log group. For more information about the available processors to use in a transformer, see Processors that you can use.
Having log events in standardized format enables visibility across your applications for your log analysis, reporting, and alarming needs. CloudWatch Logs provides transformation for common log types with out-of-the-box transformation templates for major AWS log sources such as VPC flow logs, Lambda, and Amazon RDS. You can use pre-built transformation templates or create custom transformation policies.
You can create transformers only for the log groups in the Standard log class.
You can have one account-level transformer policy that applies to all log groups in the account.
Or you can create as many as 20 account-level transformer policies that are each scoped to a subset of log groups with
the selectionCriteria
parameter. If you have multiple
account-level transformer policies with selection criteria, no two of them can use the same or overlapping log group name prefixes.
For example, if you have one policy filtered to log groups that start with my-log
, you can't have another field index
policy filtered to my-logpprod
or my-logging
.
You can also set up a transformer at the log-group level. For more information, see
AWS::Logs::Transformer. If there is both a
log-group level transformer created with PutTransformer
and an account-level transformer that could apply to the same log
group, the log group uses only the log-group level transformer. It ignores the account-level transformer.
Syntax
To declare this entity in your AWS CloudFormation template, use the following syntax:
JSON
{ "Type" : "AWS::Logs::AccountPolicy", "Properties" : { "PolicyDocument" :
String
, "PolicyName" :String
, "PolicyType" :String
, "Scope" :String
, "SelectionCriteria" :String
} }
YAML
Type: AWS::Logs::AccountPolicy Properties: PolicyDocument:
String
PolicyName:String
PolicyType:String
Scope:String
SelectionCriteria:String
Properties
PolicyDocument
-
Specify the policy, in JSON.
Data protection policy
A data protection policy must include two JSON blocks:
-
The first block must include both a
DataIdentifer
array and anOperation
property with anAudit
action. TheDataIdentifer
array lists the types of sensitive data that you want to mask. For more information about the available options, see Types of data that you can mask.The
Operation
property with anAudit
action is required to find the sensitive data terms. ThisAudit
action must contain aFindingsDestination
object. You can optionally use thatFindingsDestination
object to list one or more destinations to send audit findings to. If you specify destinations such as log groups, Firehose streams, and S3 buckets, they must already exist. -
The second block must include both a
DataIdentifer
array and anOperation
property with anDeidentify
action. TheDataIdentifer
array must exactly match theDataIdentifer
array in the first block of the policy.The
Operation
property with theDeidentify
action is what actually masks the data, and it must contain the"MaskConfig": {}
object. The"MaskConfig": {}
object must be empty.
Important
The contents of the two
DataIdentifer
arrays must match exactly.In addition to the two JSON blocks, the
policyDocument
can also includeName
,Description
, andVersion
fields. TheName
is different than the operation'spolicyName
parameter, and is used as a dimension when CloudWatch Logs reports audit findings metrics to CloudWatch.The JSON specified in
policyDocument
can be up to 30,720 characters long.Subscription filter policy
A subscription filter policy can include the following attributes in a JSON block:
-
DestinationArn The ARN of the destination to deliver log events to. Supported destinations are:
-
An Kinesis Data Streams data stream in the same account as the subscription policy, for same-account delivery.
-
An Firehose data stream in the same account as the subscription policy, for same-account delivery.
-
A Lambda function in the same account as the subscription policy, for same-account delivery.
-
A logical destination in a different account created with PutDestination, for cross-account delivery. Kinesis Data Streams and Firehose are supported as logical destinations.
-
-
RoleArn The ARN of an IAM role that grants CloudWatch Logs permissions to deliver ingested log events to the destination stream. You don't need to provide the ARN when you are working with a logical destination for cross-account delivery.
-
FilterPattern A filter pattern for subscribing to a filtered stream of log events.
-
DistributionThe method used to distribute log data to the destination. By default, log data is grouped by log stream, but the grouping can be set to
Random
for a more even distribution. This property is only applicable when the destination is an Kinesis Data Streams data stream.
Field index policy
A field index filter policy can include the following attribute in a JSON block:
-
Fields The array of field indexes to create.
The following is an example of an index policy document that creates two indexes,
RequestId
andTransactionId
."policyDocument": "{ \"Fields\": [ \"RequestId\", \"TransactionId\" ] }"
Transformer policy
A transformer policy must include one JSON block with the array of processors and their configurations. For more information about available processors, see Processors that you can use.
Required: Yes
Type: String
Minimum:
1
Maximum:
30720
Update requires: No interruption
-
PolicyName
-
A name for the policy. This must be unique within the account.
Required: Yes
Type: String
Pattern:
^[^:*]{1,256}$
Minimum:
1
Maximum:
256
Update requires: Replacement
PolicyType
-
The type of policy that you're creating or updating.
Required: Yes
Type: String
Allowed values:
DATA_PROTECTION_POLICY | SUBSCRIPTION_FILTER_POLICY | FIELD_INDEX_POLICY | TRANSFORMER_POLICY
Update requires: Replacement
Scope
-
Currently the only valid value for this parameter is
ALL
, which specifies that the policy applies to all log groups in the account. If you omit this parameter, the default ofALL
is used. To scope down a subscription filter policy to a subset of log groups, use theSelectionCriteria
parameter.Required: No
Type: String
Allowed values:
ALL
Update requires: No interruption
SelectionCriteria
-
Use this parameter to apply the new policy to a subset of log groups in the account.
You need to specify
SelectionCriteria
only when you specifySUBSCRIPTION_FILTER_POLICY
,FIELD_INDEX_POLICY
orTRANSFORMER_POLICY
forPolicyType
.If
PolicyType
isSUBSCRIPTION_FILTER_POLICY
, the only supportedSelectionCriteria
filter isLogGroupName NOT IN []
If
PolicyType
isFIELD_INDEX_POLICY
orTRANSFORMER_POLICY
, the only supportedSelectionCriteria
filter isLogGroupNamePrefix
The
SelectionCriteria
string can be up to 25KB in length. The length is determined by using its UTF-8 bytes.Using the
SelectionCriteria
parameter withSUBSCRIPTION_FILTER_POLICY
is useful to help prevent infinite loops. For more information, see Log recursion prevention.Required: No
Type: String
Update requires: No interruption
Return values
Fn::GetAtt
The Fn::GetAtt
intrinsic function returns a value for a specified attribute of this type. The following are the available attributes and sample return values.
For more information about using the Fn::GetAtt
intrinsic function, see Fn::GetAtt
.
AccountId
-
The account ID of the account where this policy was created. For example,
123456789012
.
Examples
Create an account-level field index policy
The following example creates an account-level field index policy that creates an index on the RequestId
and TransactionId
fields
for log groups with names with the /aws/
prefix.
JSON
"IndexingAccountPolicy": { "Type": "AWS::Logs::AccountPolicy", "Properties": { "PolicyName": "test-fieldindexing-policy", "PolicyDocument": { "Fn::Sub": "{\"Fields\": [\"RequestId\", \"TransactionId\"]}" }, "SelectionCriteria": { "Fn::Sub": "LogGroupNamePrefix=\"/aws/\"" }, "PolicyType": "FIELD_INDEX_POLICY", "Scope": "ALL" } }
YAML
IndexingAccountPolicy: Type: AWS::Logs::AccountPolicy Properties: PolicyName: "test-fieldindexing-policy" PolicyDocument: !Sub "{\"Fields\": [\"RequestId\", \"TransactionId\"]}" SelectionCriteria: !Sub "LogGroupNamePrefix = \"/aws/\"" PolicyType: "FIELD_INDEX_POLICY" Scope: "ALL"
Create an account-level data protection policy
The following example creates an account-level data protection policy that finds and masks email addresses in log events.
It also sends audit findings to the EXISTING_LOG_GROUP_NAME
log group in CloudWatch Logs.
JSON
{ "Resources": { "AccountPolicy": { "Type": "AWS::Logs::AccountPolicy", "Properties": { "PolicyName": "TestPolicy", "PolicyDocument": "{ \"Name\": \"data-protection-policy\", \"Description\": \"\", \"Version\": \"2021-06-01\", \"Statement\": [ { \"Sid\": \"audit-policy\", \"DataIdentifier\": [ \"arn:aws:dataprotection::aws:data-identifier/EmailAddress\" ], \"Operation\": { \"Audit\": { \"FindingsDestination\": { \"CloudWatchLogs\": { \"LogGroup\": \"EXISTING_LOG_GROUP_NAME\" } } } } }, { \"Sid\": \"redact-policy\", \"DataIdentifier\": [ \"arn:aws:dataprotection::aws:data-identifier/EmailAddress\" ], \"Operation\": { \"Deidentify\": { \"MaskConfig\": {} } } } ] }", "PolicyType": "DATA_PROTECTION_POLICY", "Scope": "ALL" } } } }
YAML
Resources: AccountPolicy: Type: AWS::Logs::AccountPolicy Properties: PolicyName: "TestPolicy" PolicyDocument: '{ "Name": "data-protection-policy", "Description": "", "Version": "2021-06-01", "Statement": [ { "Sid": "audit-policy", "DataIdentifier": [ "arn:aws:dataprotection::aws:data-identifier/EmailAddress" ], "Operation": { "Audit": { "FindingsDestination": { "CloudWatchLogs": { "LogGroup": "EXISTING_LOG_GROUP_NAME" } } } } }, { "Sid": "redact-policy", "DataIdentifier": [ "arn:aws:dataprotection::aws:data-identifier/EmailAddress" ], "Operation": { "Deidentify": { "MaskConfig": {} } } } ] }' PolicyType: "DATA_PROTECTION_POLICY" Scope: "ALL"
Create an account-level subscription filter policy
The following example creates an account-level subscription filter policy that forwards the
log events matching the FilterPattern
from all the log groups in an account to the specified
ak Kinesis Data Streams stream. It forwards the log events from all the log groups except the ones that are
specified in the SelectionCriteria
field.
JSON
{ "Resources": { "AccountPolicy": { "Type": "AWS::Logs::AccountPolicy", "Properties": { "PolicyName": "test-subscriptionfilter-policy", "PolicyDocument": { "Fn::Sub": "{\"RoleArn\":\"arn:${AWS::Partition}:iam::${AWS::AccountId}:role/MyCWLtoKinesisRole\", \"DestinationArn\":\"arn:${AWS::Partition}:kinesis:${AWS::Region}:${AWS::AccountId}:stream/MyKinesisStream\", \"FilterPattern\": \"Test\", \"Distribution\": \"Random\"}" }, "SelectionCriteria": { "Fn::Sub": "LogGroupName NOT IN [\"MyLogGroup\", \"MyAnotherLogGroup\"]" }, "PolicyType": "SUBSCRIPTION_FILTER_POLICY", "Scope": "ALL" } } } }
YAML
Resources: AccountPolicy: Type: AWS::Logs::AccountPolicy Properties: PolicyName: test-subscriptionfilter-policy PolicyDocument: !Sub "{\"RoleArn\":\"arn:${AWS::Partition}:iam::${AWS::AccountId}:role/MyCWLtoKinesisRole\", \"DestinationArn\":\"arn:${AWS::Partition}:kinesis:${AWS::Region}:${AWS::AccountId}:stream/MyKinesisStream\", \"FilterPattern\": \"Test\", \"Distribution\": \"Random\"}" SelectionCriteria: !Sub "LogGroupName NOT IN [\"MyLogGroup\", \"MyAnotherLogGroup\"]" PolicyType: "SUBSCRIPTION_FILTER_POLICY" Scope: "ALL"