Put Account Policy
| cloudwatchlogs_put_account_policy | R Documentation |
Creates an account-level data protection policy, subscription filter policy, field index policy, transformer policy, or metric extraction policy that applies to all log groups, a subset of log groups, or a data source name and type combination in the account¶
Description¶
Creates an account-level data protection policy, subscription filter policy, field index policy, transformer policy, or metric extraction policy that applies to all log groups, a subset of log groups, or a data source name and type combination in the account.
For field index policies, you can configure indexed fields as facets to enable interactive exploration of your logs. Facets provide value distributions and counts for indexed fields in the CloudWatch Logs Insights console without requiring query execution. For more information, see Use facets to group and explore logs.
To use this operation, you must be signed on with the correct permissions depending on the type of policy that you are creating.
-
To create a data protection policy, you must have the
logs:PutDataProtectionPolicyandlogs:PutAccountPolicypermissions. -
To create a subscription filter policy, you must have the
logs:PutSubscriptionFilterandlogs:PutAccountPolicypermissions. -
To create a transformer policy, you must have the
logs:PutTransformerandlogs:PutAccountPolicypermissions. -
To create a field index policy, you must have the
logs:PutIndexPolicyandlogs:PutAccountPolicypermissions. -
To configure facets for field index policies, you must have the
logs:PutIndexPolicyandlogs:PutAccountPolicypermissions. -
To create a metric extraction policy, you must have the
logs:PutMetricExtractionPolicyandlogs:PutAccountPolicypermissions.
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.
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 use put_account_policy to 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-level 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 get_log_events or
filter_log_events 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 use the put_account_policy operation for a data protection policy,
you must be signed on with the logs:PutDataProtectionPolicy and
logs:PutAccountPolicy permissions.
The put_account_policy operation applies to all log groups in the
account. You can use put_data_protection_policy to 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 Amazon Web Services 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
put_destination, for cross-account delivery. Kinesis Data Streams and Firehose are supported as logical destinations.
Each account can have one account-level subscription filter policy per
Region. If you are updating an existing filter, you must specify the
correct name in PolicyName. To perform a put_account_policy
subscription filter operation for any destination except a Lambda
function, you must also have the iam:PassRole permission.
Transformer policy
Creates or updates a log transformer policy for your account. You use log transformers to transform 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 Amazon Web Services 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 transformer policy filtered to my-logpprod or
my-logging.
You can also set up a transformer at the log-group level. For more
information, see put_transformer. If there is both a log-group level
transformer created with put_transformer 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.
Field index policy
You can use field index policies to create indexes on fields found in log events for a log group or data source name and type combination. Creating field indexes can help lower 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 and fields or values that match only a small fraction of the total log events. 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
To find the fields that are in your log group events, use the
get_log_group_fields operation. To find the fields for a data source
use the get_log_fields operation.
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
using LogGroupNamePrefix with the selectionCriteria parameter. You
can have another 20 account-level field index policies using
DataSourceName and DataSourceType for the selectionCriteria
parameter. If you have multiple account-level index policies with
LogGroupNamePrefix 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.
Similarly, if you have multiple account-level index policies with
DataSourceName and DataSourceType selection criteria, no two of them
can use the same data source name and type combination. For example, if
you have one policy filtered to the data source name amazon_vpc and
data source type flow you cannot create another policy with this
combination.
If you create an account-level field index policy in a monitoring account in cross-account observability, the policy is applied only to the monitoring account and not to any source accounts.
CloudWatch Logs provides default field indexes for all log groups in the Standard log class. Default field indexes are automatically available for the following fields:
-
@logStream -
@aws.region -
@aws.account -
@source.log -
@data_source_name -
@data_source_type -
@data_format -
traceId -
severityText -
attributes.session.id
CloudWatch Logs provides default field indexes for certain data source name and type combinations as well. Default field indexes are automatically available for the following data source name and type combinations as identified in the following list:
amazon_vpc.flow
-
action -
logStatus -
region -
flowDirection -
type
amazon_route53.resolver_query
-
transport -
rcode
aws_waf.access
-
action -
httpRequest.country
aws_cloudtrail.data, aws_cloudtrail.management
-
eventSource -
eventName -
awsRegion -
userAgent -
errorCode -
eventType -
managementEvent -
readOnly -
eventCategory -
requestId
Default field indexes are in addition to any custom field indexes you define within your policy. Default field indexes are not counted towards your field index quota.
If you want to create a field index policy for a single log group, you
can use put_index_policy instead of put_account_policy. If you do
so, that log group will use that log-group level policy and any
account-level policies that match at the data source level; any
account-level policy that matches at the log group level (for example,
no selection criteria or log group name prefix selection criteria) will
be ignored.
Metric extraction policy
A metric extraction policy controls whether CloudWatch Metrics can be created through the Embedded Metrics Format (EMF) for log groups in your account. By default, EMF metric creation is enabled for all log groups. You can use metric extraction policies to disable EMF metric creation for your entire account or specific log groups.
When a policy disables EMF metric creation for a log group, log events in the EMF format are still ingested, but no CloudWatch Metrics are created from them.
Creating a policy disables metrics for Amazon Web Services features that
use EMF to create metrics, such as CloudWatch Container Insights and
CloudWatch Application Signals. To prevent turning off those features by
accident, we recommend that you exclude the underlying log-groups
through a selection-criteria such as
LogGroupNamePrefix NOT IN ["/aws/containerinsights", "/aws/ecs/containerinsights", "/aws/application-signals/data"].
Each account can have either one account-level metric extraction policy
that applies to all log groups, or up to 5 policies that are each scoped
to a subset of log groups with the selectionCriteria parameter. The
selection criteria supports filtering by LogGroupName and
LogGroupNamePrefix using the operators IN and NOT IN. You can
specify up to 50 values in each IN or NOT IN list.
The selection criteria can be specified in these formats:
LogGroupName IN ["log-group-1", "log-group-2"]
LogGroupNamePrefix NOT IN ["/aws/prefix1", "/aws/prefix2"]
If you have multiple account-level metric extraction policies with
selection criteria, no two of them can have overlapping criteria. For
example, if you have one policy with selection criteria
LogGroupNamePrefix IN ["my-log"], you can't have another metric
extraction policy with selection criteria
LogGroupNamePrefix IN ["/my-log-prod"] or
LogGroupNamePrefix IN ["/my-logging"], as the set of log groups
matching these prefixes would be a subset of the log groups matching the
first policy's prefix, creating an overlap.
When using NOT IN, only one policy with this operator is allowed per
account.
When combining policies with IN and NOT IN operators, the overlap
check ensures that policies don't have conflicting effects. Two policies
with IN and NOT IN operators do not overlap if and only if every
value in the INpolicy is completely contained within some value in
the NOT IN policy. For example:
-
If you have a
NOT INpolicy for prefix"/aws/lambda", you can create anINpolicy for the exact log group name"/aws/lambda/function1"because the set of log groups matching"/aws/lambda/function1"is a subset of the log groups matching"/aws/lambda". -
If you have a
NOT INpolicy for prefix"/aws/lambda", you cannot create anINpolicy for prefix"/aws"because the set of log groups matching"/aws"is not a subset of the log groups matching"/aws/lambda".
Usage¶
cloudwatchlogs_put_account_policy(policyName, policyDocument,
policyType, scope, selectionCriteria)
Arguments¶
policyName |
[required] A name for the policy. This must be unique within the
account and cannot start with |
policyDocument |
[required] Specify the policy, in JSON. Data protection policy A data protection policy must include two JSON blocks:
For an example data protection policy, see the Examples section on this page. The contents of the two In addition to the two JSON blocks, the The JSON specified in Subscription filter policy A subscription filter policy can include the following attributes in a JSON block:
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. Field index policy A field index filter policy can include the following attribute in a JSON block:
It must contain at least one field index. The following is an example of an index policy document that creates indexes with different types.
You can use |
policyType |
[required] The type of policy that you're creating or updating. |
scope |
Currently the only valid value for this parameter is
|
selectionCriteria |
Use this parameter to apply the new policy to a subset of log groups in the account or a data source name and type combination. Specifying
The Using the |
Value¶
A list with the following syntax:
list(
accountPolicy = list(
policyName = "string",
policyDocument = "string",
lastUpdatedTime = 123,
policyType = "DATA_PROTECTION_POLICY"|"SUBSCRIPTION_FILTER_POLICY"|"FIELD_INDEX_POLICY"|"TRANSFORMER_POLICY"|"METRIC_EXTRACTION_POLICY",
scope = "ALL",
selectionCriteria = "string",
accountId = "string"
)
)
Request syntax¶
svc$put_account_policy(
policyName = "string",
policyDocument = "string",
policyType = "DATA_PROTECTION_POLICY"|"SUBSCRIPTION_FILTER_POLICY"|"FIELD_INDEX_POLICY"|"TRANSFORMER_POLICY"|"METRIC_EXTRACTION_POLICY",
scope = "ALL",
selectionCriteria = "string"
)