For Amazon CloudFront, don't use this call. Instead, use your CloudFront distribution configuration. To
* associate a web ACL, in the CloudFront call UpdateDistribution, set the web ACL ID
* to the Amazon Resource Name (ARN) of the web ACL. For information, see UpdateDistribution in the Amazon CloudFront Developer Guide.
When you make changes to web ACLs or web ACL components, like rules and rule groups, WAF propagates the changes everywhere that the web ACL and its components are stored and used. Your changes are applied within seconds, but there might be a brief period of inconsistency when the changes have arrived in some places and not in others. So, for example, if you change a rule action setting, the action might be the old action in one area and the new action in another area. Or if you add an IP address to an IP set used in a blocking rule, the new address might briefly be blocked in one area while still allowed in another. This temporary inconsistency can occur when you first associate a web ACL with an Amazon Web Services resource and when you change a web ACL that is already associated with a resource. Generally, any inconsistencies of this type last only a few seconds.
+ *+ * Required permissions for customer-managed IAM policies + *
+ *This call requires permissions that are specific to the protected resource type. + * For details, see Permissions for AssociateWebACL in the WAF Developer Guide.
+ *+ * Temporary inconsistencies during updates + *
+ *When you create or change a web ACL or other WAF resources, the changes take a small amount of time to propagate to all areas where the resources are stored. The propagation time can be from a few seconds to a number of minutes.
+ *The following are examples of the temporary inconsistencies that you might notice during change propagation:
+ *After you create a web ACL, if you try to associate it with a resource, you might get an exception indicating that the web ACL is unavailable.
+ *After you add a rule group to a web ACL, the new rule group rules might be in effect in one area where the web ACL is used and not in another.
+ *After you change a rule action setting, you might see the old action in some places and the new action in others.
+ *After you add an IP address to an IP set that is in use in a blocking rule, the new address might be blocked in one area while still allowed in another.
+ *For Amazon CloudFront, don't use this call. Instead, use your CloudFront distribution configuration. To
* disassociate a web ACL, provide an empty web ACL ID in the CloudFront call
* UpdateDistribution. For information, see UpdateDistribution in the Amazon CloudFront API Reference.
+ * Required permissions for customer-managed IAM policies + *
+ *This call requires permissions that are specific to the protected resource type. + * For details, see Permissions for DisassociateWebACL in the WAF Developer Guide.
* @example * Use a bare-bones client and the command you need to make an API call. * ```javascript diff --git a/clients/client-wafv2/src/commands/GetWebACLForResourceCommand.ts b/clients/client-wafv2/src/commands/GetWebACLForResourceCommand.ts index 97de8ca8636e..b07ce3d0201c 100644 --- a/clients/client-wafv2/src/commands/GetWebACLForResourceCommand.ts +++ b/clients/client-wafv2/src/commands/GetWebACLForResourceCommand.ts @@ -38,6 +38,16 @@ export interface GetWebACLForResourceCommandOutput extends GetWebACLForResourceR /** * @public *Retrieves the WebACL for the specified resource.
+ *This call uses GetWebACL, to verify that your account has permission to access the retrieved web ACL.
+ * If you get an error that indicates that your account isn't authorized to perform wafv2:GetWebACL on the resource,
+ * that error won't be included in your CloudTrail event history.
For Amazon CloudFront, don't use this call. Instead, call the CloudFront action
+ * GetDistributionConfig. For information, see GetDistributionConfig in the Amazon CloudFront API Reference.
+ * Required permissions for customer-managed IAM policies + *
+ *This call requires permissions that are specific to the protected resource type. + * For details, see Permissions for GetWebACLForResource in the WAF Developer Guide.
* @example * Use a bare-bones client and the command you need to make an API call. * ```javascript diff --git a/clients/client-wafv2/src/commands/ListResourcesForWebACLCommand.ts b/clients/client-wafv2/src/commands/ListResourcesForWebACLCommand.ts index b001b244ccf4..bfb61eedfea4 100644 --- a/clients/client-wafv2/src/commands/ListResourcesForWebACLCommand.ts +++ b/clients/client-wafv2/src/commands/ListResourcesForWebACLCommand.ts @@ -38,8 +38,15 @@ export interface ListResourcesForWebACLCommandOutput extends ListResourcesForWeb /** * @public *Retrieves an array of the Amazon Resource Names (ARNs) for the regional resources that
- * are associated with the specified web ACL. If you want the list of Amazon CloudFront resources, use
- * the CloudFront call ListDistributionsByWebACLId.
For Amazon CloudFront, don't use this call. Instead, use the CloudFront call
+ * ListDistributionsByWebACLId. For information, see ListDistributionsByWebACLId
+ * in the Amazon CloudFront API Reference.
+ * Required permissions for customer-managed IAM policies + *
+ *This call requires permissions that are specific to the protected resource type. + * For details, see Permissions for ListResourcesForWebACL in the WAF Developer Guide.
* @example * Use a bare-bones client and the command you need to make an API call. * ```javascript diff --git a/clients/client-wafv2/src/commands/UpdateIPSetCommand.ts b/clients/client-wafv2/src/commands/UpdateIPSetCommand.ts index fc5cbc92441f..06663a5da9b8 100644 --- a/clients/client-wafv2/src/commands/UpdateIPSetCommand.ts +++ b/clients/client-wafv2/src/commands/UpdateIPSetCommand.ts @@ -54,7 +54,25 @@ export interface UpdateIPSetCommandOutput extends UpdateIPSetResponse, __Metadat * * * - *When you make changes to web ACLs or web ACL components, like rules and rule groups, WAF propagates the changes everywhere that the web ACL and its components are stored and used. Your changes are applied within seconds, but there might be a brief period of inconsistency when the changes have arrived in some places and not in others. So, for example, if you change a rule action setting, the action might be the old action in one area and the new action in another area. Or if you add an IP address to an IP set used in a blocking rule, the new address might briefly be blocked in one area while still allowed in another. This temporary inconsistency can occur when you first associate a web ACL with an Amazon Web Services resource and when you change a web ACL that is already associated with a resource. Generally, any inconsistencies of this type last only a few seconds.
+ *+ * Temporary inconsistencies during updates + *
+ *When you create or change a web ACL or other WAF resources, the changes take a small amount of time to propagate to all areas where the resources are stored. The propagation time can be from a few seconds to a number of minutes.
+ *The following are examples of the temporary inconsistencies that you might notice during change propagation:
+ *After you create a web ACL, if you try to associate it with a resource, you might get an exception indicating that the web ACL is unavailable.
+ *After you add a rule group to a web ACL, the new rule group rules might be in effect in one area where the web ACL is used and not in another.
+ *After you change a rule action setting, you might see the old action in some places and the new action in others.
+ *After you add an IP address to an IP set that is in use in a blocking rule, the new address might be blocked in one area while still allowed in another.
+ *When you make changes to web ACLs or web ACL components, like rules and rule groups, WAF propagates the changes everywhere that the web ACL and its components are stored and used. Your changes are applied within seconds, but there might be a brief period of inconsistency when the changes have arrived in some places and not in others. So, for example, if you change a rule action setting, the action might be the old action in one area and the new action in another area. Or if you add an IP address to an IP set used in a blocking rule, the new address might briefly be blocked in one area while still allowed in another. This temporary inconsistency can occur when you first associate a web ACL with an Amazon Web Services resource and when you change a web ACL that is already associated with a resource. Generally, any inconsistencies of this type last only a few seconds.
+ *+ * Temporary inconsistencies during updates + *
+ *When you create or change a web ACL or other WAF resources, the changes take a small amount of time to propagate to all areas where the resources are stored. The propagation time can be from a few seconds to a number of minutes.
+ *The following are examples of the temporary inconsistencies that you might notice during change propagation:
+ *After you create a web ACL, if you try to associate it with a resource, you might get an exception indicating that the web ACL is unavailable.
+ *After you add a rule group to a web ACL, the new rule group rules might be in effect in one area where the web ACL is used and not in another.
+ *After you change a rule action setting, you might see the old action in some places and the new action in others.
+ *After you add an IP address to an IP set that is in use in a blocking rule, the new address might be blocked in one area while still allowed in another.
+ *When you make changes to web ACLs or web ACL components, like rules and rule groups, WAF propagates the changes everywhere that the web ACL and its components are stored and used. Your changes are applied within seconds, but there might be a brief period of inconsistency when the changes have arrived in some places and not in others. So, for example, if you change a rule action setting, the action might be the old action in one area and the new action in another area. Or if you add an IP address to an IP set used in a blocking rule, the new address might briefly be blocked in one area while still allowed in another. This temporary inconsistency can occur when you first associate a web ACL with an Amazon Web Services resource and when you change a web ACL that is already associated with a resource. Generally, any inconsistencies of this type last only a few seconds.
*A rule group defines a collection of rules to inspect and control web requests that you can use in a WebACL. When you create a rule group, you define an immutable capacity limit. If you update a rule group, you must stay within the capacity. This allows others to reuse the rule group with confidence in its capacity requirements.
+ *+ * Temporary inconsistencies during updates + *
+ *When you create or change a web ACL or other WAF resources, the changes take a small amount of time to propagate to all areas where the resources are stored. The propagation time can be from a few seconds to a number of minutes.
+ *The following are examples of the temporary inconsistencies that you might notice during change propagation:
+ *After you create a web ACL, if you try to associate it with a resource, you might get an exception indicating that the web ACL is unavailable.
+ *After you add a rule group to a web ACL, the new rule group rules might be in effect in one area where the web ACL is used and not in another.
+ *After you change a rule action setting, you might see the old action in some places and the new action in others.
+ *After you add an IP address to an IP set that is in use in a blocking rule, the new address might be blocked in one area while still allowed in another.
+ *When you make changes to web ACLs or web ACL components, like rules and rule groups, WAF propagates the changes everywhere that the web ACL and its components are stored and used. Your changes are applied within seconds, but there might be a brief period of inconsistency when the changes have arrived in some places and not in others. So, for example, if you change a rule action setting, the action might be the old action in one area and the new action in another area. Or if you add an IP address to an IP set used in a blocking rule, the new address might briefly be blocked in one area while still allowed in another. This temporary inconsistency can occur when you first associate a web ACL with an Amazon Web Services resource and when you change a web ACL that is already associated with a resource. Generally, any inconsistencies of this type last only a few seconds.
*A web ACL defines a collection of rules to use to inspect and control web requests. Each rule has a statement that defines what to look for in web requests and an action that WAF applies to requests that match the statement. In the web ACL, you assign a default action to take (allow, block) for any request that does not match any of the rules. The rules in a web ACL can be a combination of the types Rule, RuleGroup, and managed rule group. You can associate a web ACL with one or more Amazon Web Services resources to protect. The resources can be an Amazon CloudFront distribution, an Amazon API Gateway REST API, an Application Load Balancer, an AppSync GraphQL API, an Amazon Cognito user pool, an App Runner service, or an Amazon Web Services Verified Access instance.
+ *+ * Temporary inconsistencies during updates + *
+ *When you create or change a web ACL or other WAF resources, the changes take a small amount of time to propagate to all areas where the resources are stored. The propagation time can be from a few seconds to a number of minutes.
+ *The following are examples of the temporary inconsistencies that you might notice during change propagation:
+ *After you create a web ACL, if you try to associate it with a resource, you might get an exception indicating that the web ACL is unavailable.
+ *After you add a rule group to a web ACL, the new rule group rules might be in effect in one area where the web ACL is used and not in another.
+ *After you change a rule action setting, you might see the old action in some places and the new action in others.
+ *After you add an IP address to an IP set that is in use in a blocking rule, the new address might be blocked in one area while still allowed in another.
+ *The parts of the cookies to inspect with the rule inspection criteria. If you specify
- * All, WAF inspects both keys and values.
ALL, WAF inspects both keys and values.
+ *
+ * All does not require a match to be found in the keys
+ * and a match to be found in the values. It requires a match to be found in the keys
+ * or the values or both. To require a match in the keys and in the values, use a logical AND statement
+ * to combine two match rules, one that inspects the keys and another that inspects the values.
The parts of the headers to match with the rule inspection criteria. If you specify
- * All, WAF inspects both keys and values.
ALL, WAF inspects both keys and values.
+ *
+ * All does not require a match to be found in the keys
+ * and a match to be found in the values. It requires a match to be found in the keys
+ * or the values or both. To require a match in the keys and in the values, use a logical AND statement
+ * to combine two match rules, one that inspects the keys and another that inspects the values.
The parts of the JSON to match against using the MatchPattern. If you
- * specify All, WAF matches against keys and values.
ALL, WAF matches against keys and values.
+ *
+ * All does not require a match to be found in the keys
+ * and a match to be found in the values. It requires a match to be found in the keys
+ * or the values or both. To require a match in the keys and in the values, use a logical AND statement
+ * to combine two match rules, one that inspects the keys and another that inspects the values.
- * HeaderOrder: The comma-separated list of header names to match for. WAF creates a
+ * HeaderOrder: The list of header names to match for. WAF creates a
* string that contains the ordered list of header names, from the headers in the web request, and then matches against that string.
Associates a web ACL with a regional application resource, to protect the resource.\n A regional application can be an Application Load Balancer (ALB), an Amazon API Gateway REST API, an AppSync GraphQL API, an Amazon Cognito user pool, an App Runner service, or an Amazon Web Services Verified Access instance.
\nFor Amazon CloudFront, don't use this call. Instead, use your CloudFront distribution configuration. To\n associate a web ACL, in the CloudFront call UpdateDistribution, set the web ACL ID\n to the Amazon Resource Name (ARN) of the web ACL. For information, see UpdateDistribution in the Amazon CloudFront Developer Guide.
When you make changes to web ACLs or web ACL components, like rules and rule groups, WAF propagates the changes everywhere that the web ACL and its components are stored and used. Your changes are applied within seconds, but there might be a brief period of inconsistency when the changes have arrived in some places and not in others. So, for example, if you change a rule action setting, the action might be the old action in one area and the new action in another area. Or if you add an IP address to an IP set used in a blocking rule, the new address might briefly be blocked in one area while still allowed in another. This temporary inconsistency can occur when you first associate a web ACL with an Amazon Web Services resource and when you change a web ACL that is already associated with a resource. Generally, any inconsistencies of this type last only a few seconds.
" + "smithy.api#documentation": "Associates a web ACL with a regional application resource, to protect the resource.\n A regional application can be an Application Load Balancer (ALB), an Amazon API Gateway REST API, an AppSync GraphQL API, an Amazon Cognito user pool, an App Runner service, or an Amazon Web Services Verified Access instance.
\nFor Amazon CloudFront, don't use this call. Instead, use your CloudFront distribution configuration. To\n associate a web ACL, in the CloudFront call UpdateDistribution, set the web ACL ID\n to the Amazon Resource Name (ARN) of the web ACL. For information, see UpdateDistribution in the Amazon CloudFront Developer Guide.
\n Required permissions for customer-managed IAM policies\n
\nThis call requires permissions that are specific to the protected resource type. \n For details, see Permissions for AssociateWebACL in the WAF Developer Guide.
\n\n Temporary inconsistencies during updates\n
\nWhen you create or change a web ACL or other WAF resources, the changes take a small amount of time to propagate to all areas where the resources are stored. The propagation time can be from a few seconds to a number of minutes.
\nThe following are examples of the temporary inconsistencies that you might notice during change propagation:
\nAfter you create a web ACL, if you try to associate it with a resource, you might get an exception indicating that the web ACL is unavailable.
\nAfter you add a rule group to a web ACL, the new rule group rules might be in effect in one area where the web ACL is used and not in another.
\nAfter you change a rule action setting, you might see the old action in some places and the new action in others.
\nAfter you add an IP address to an IP set that is in use in a blocking rule, the new address might be blocked in one area while still allowed in another.
\nA string value that you want WAF to search for. WAF searches only in the part of\n web requests that you designate for inspection in FieldToMatch. The\n maximum length of the value is 200 bytes.
\nValid values depend on the component that you specify for inspection in\n FieldToMatch:
\n Method: The HTTP method that you want WAF to search for. This\n indicates the type of operation specified in the request.
\n UriPath: The value that you want WAF to search for in the URI path,\n for example, /images/daily-ad.jpg.
\n JA3Fingerprint: Match against the request's JA3 fingerprint. The JA3 fingerprint is a 32-character hash derived from the TLS Client Hello of an incoming request. This fingerprint serves as a unique identifier for the client's TLS configuration. You can use this choice only with a string match ByteMatchStatement with the PositionalConstraint set to \n EXACTLY.
You can obtain the JA3 fingerprint for client requests from the web ACL logs. \n\t\t\t\t\t\tIf WAF is able to calculate the fingerprint, it includes it in the logs. \n\t\t\t\t\t\tFor information about the logging fields, \nsee Log fields in the WAF Developer Guide.
\n\n HeaderOrder: The comma-separated list of header names to match for. WAF creates a \n string that contains the ordered list of header names, from the headers in the web request, and then matches against that string.
If SearchString includes alphabetic characters A-Z and a-z, note that the\n value is case sensitive.
\n If you're using the WAF API\n
\nSpecify a base64-encoded version of the value. The maximum length of the value before\n you base64-encode it is 200 bytes.
\nFor example, suppose the value of Type is HEADER and the value\n of Data is User-Agent. If you want to search the\n User-Agent header for the value BadBot, you base64-encode\n BadBot using MIME base64-encoding and include the resulting value,\n QmFkQm90, in the value of SearchString.
\n If you're using the CLI or one of the Amazon Web Services SDKs\n
\nThe value that you want WAF to search for. The SDK automatically base64 encodes the\n value.
", + "smithy.api#documentation": "A string value that you want WAF to search for. WAF searches only in the part of\n web requests that you designate for inspection in FieldToMatch. The\n maximum length of the value is 200 bytes.
\nValid values depend on the component that you specify for inspection in\n FieldToMatch:
\n Method: The HTTP method that you want WAF to search for. This\n indicates the type of operation specified in the request.
\n UriPath: The value that you want WAF to search for in the URI path,\n for example, /images/daily-ad.jpg.
\n JA3Fingerprint: Match against the request's JA3 fingerprint. The JA3 fingerprint is a 32-character hash derived from the TLS Client Hello of an incoming request. This fingerprint serves as a unique identifier for the client's TLS configuration. You can use this choice only with a string match ByteMatchStatement with the PositionalConstraint set to \n EXACTLY.
You can obtain the JA3 fingerprint for client requests from the web ACL logs. \n\t\t\t\t\t\tIf WAF is able to calculate the fingerprint, it includes it in the logs. \n\t\t\t\t\t\tFor information about the logging fields, \nsee Log fields in the WAF Developer Guide.
\n\n HeaderOrder: The list of header names to match for. WAF creates a \n string that contains the ordered list of header names, from the headers in the web request, and then matches against that string.
If SearchString includes alphabetic characters A-Z and a-z, note that the\n value is case sensitive.
\n If you're using the WAF API\n
\nSpecify a base64-encoded version of the value. The maximum length of the value before\n you base64-encode it is 200 bytes.
\nFor example, suppose the value of Type is HEADER and the value\n of Data is User-Agent. If you want to search the\n User-Agent header for the value BadBot, you base64-encode\n BadBot using MIME base64-encoding and include the resulting value,\n QmFkQm90, in the value of SearchString.
\n If you're using the CLI or one of the Amazon Web Services SDKs\n
\nThe value that you want WAF to search for. The SDK automatically base64 encodes the\n value.
", "smithy.api#required": {} } }, @@ -2230,7 +2230,7 @@ "MatchScope": { "target": "com.amazonaws.wafv2#MapMatchScope", "traits": { - "smithy.api#documentation": "The parts of the cookies to inspect with the rule inspection criteria. If you specify\n All, WAF inspects both keys and values.
The parts of the cookies to inspect with the rule inspection criteria. If you specify\n ALL, WAF inspects both keys and values.
\n All does not require a match to be found in the keys\n and a match to be found in the values. It requires a match to be found in the keys \n or the values or both. To require a match in the keys and in the values, use a logical AND statement\n to combine two match rules, one that inspects the keys and another that inspects the values.
Disassociates the specified regional application resource from any existing web ACL\n association. A resource can have at most one web ACL association. A regional application can be an Application Load Balancer (ALB), an Amazon API Gateway REST API, an AppSync GraphQL API, an Amazon Cognito user pool, an App Runner service, or an Amazon Web Services Verified Access instance.
\nFor Amazon CloudFront, don't use this call. Instead, use your CloudFront distribution configuration. To\n disassociate a web ACL, provide an empty web ACL ID in the CloudFront call\n UpdateDistribution. For information, see UpdateDistribution in the Amazon CloudFront API Reference.
Disassociates the specified regional application resource from any existing web ACL\n association. A resource can have at most one web ACL association. A regional application can be an Application Load Balancer (ALB), an Amazon API Gateway REST API, an AppSync GraphQL API, an Amazon Cognito user pool, an App Runner service, or an Amazon Web Services Verified Access instance.
\nFor Amazon CloudFront, don't use this call. Instead, use your CloudFront distribution configuration. To\n disassociate a web ACL, provide an empty web ACL ID in the CloudFront call\n UpdateDistribution. For information, see UpdateDistribution in the Amazon CloudFront API Reference.
\n Required permissions for customer-managed IAM policies\n
\nThis call requires permissions that are specific to the protected resource type. \n For details, see Permissions for DisassociateWebACL in the WAF Developer Guide.
" } }, "com.amazonaws.wafv2#DisassociateWebACLRequest": { @@ -6532,7 +6532,7 @@ } ], "traits": { - "smithy.api#documentation": "Retrieves the WebACL for the specified resource.
" + "smithy.api#documentation": "Retrieves the WebACL for the specified resource.
\nThis call uses GetWebACL, to verify that your account has permission to access the retrieved web ACL. \n If you get an error that indicates that your account isn't authorized to perform wafv2:GetWebACL on the resource, \n that error won't be included in your CloudTrail event history.
For Amazon CloudFront, don't use this call. Instead, call the CloudFront action\n GetDistributionConfig. For information, see GetDistributionConfig in the Amazon CloudFront API Reference.
\n Required permissions for customer-managed IAM policies\n
\nThis call requires permissions that are specific to the protected resource type. \n For details, see Permissions for GetWebACLForResource in the WAF Developer Guide.
" } }, "com.amazonaws.wafv2#GetWebACLForResourceRequest": { @@ -6767,7 +6767,7 @@ "MatchScope": { "target": "com.amazonaws.wafv2#MapMatchScope", "traits": { - "smithy.api#documentation": "The parts of the headers to match with the rule inspection criteria. If you specify\n All, WAF inspects both keys and values.
The parts of the headers to match with the rule inspection criteria. If you specify\n ALL, WAF inspects both keys and values.
\n All does not require a match to be found in the keys\n and a match to be found in the values. It requires a match to be found in the keys \n or the values or both. To require a match in the keys and in the values, use a logical AND statement\n to combine two match rules, one that inspects the keys and another that inspects the values.
The parts of the JSON to match against using the MatchPattern. If you\n specify All, WAF matches against keys and values.
The parts of the JSON to match against using the MatchPattern. If you\n specify ALL, WAF matches against keys and values.
\n All does not require a match to be found in the keys\n and a match to be found in the values. It requires a match to be found in the keys \n or the values or both. To require a match in the keys and in the values, use a logical AND statement\n to combine two match rules, one that inspects the keys and another that inspects the values.
Retrieves an array of the Amazon Resource Names (ARNs) for the regional resources that\n are associated with the specified web ACL. If you want the list of Amazon CloudFront resources, use\n the CloudFront call ListDistributionsByWebACLId.
Retrieves an array of the Amazon Resource Names (ARNs) for the regional resources that\n are associated with the specified web ACL.
\nFor Amazon CloudFront, don't use this call. Instead, use the CloudFront call\n ListDistributionsByWebACLId. For information, see ListDistributionsByWebACLId\n in the Amazon CloudFront API Reference.
\n Required permissions for customer-managed IAM policies\n
\nThis call requires permissions that are specific to the protected resource type. \n For details, see Permissions for ListResourcesForWebACL in the WAF Developer Guide.
" } }, "com.amazonaws.wafv2#ListResourcesForWebACLRequest": { @@ -11785,7 +11785,7 @@ } ], "traits": { - "smithy.api#documentation": "Updates the specified IPSet.
\nThis operation completely replaces the mutable specifications that you already have for the IP set with the ones that you provide to this call.
\nTo modify an IP set, do the following:
\nRetrieve it by calling GetIPSet\n
\nUpdate its settings as needed
\nProvide the complete IP set specification to this call
\nWhen you make changes to web ACLs or web ACL components, like rules and rule groups, WAF propagates the changes everywhere that the web ACL and its components are stored and used. Your changes are applied within seconds, but there might be a brief period of inconsistency when the changes have arrived in some places and not in others. So, for example, if you change a rule action setting, the action might be the old action in one area and the new action in another area. Or if you add an IP address to an IP set used in a blocking rule, the new address might briefly be blocked in one area while still allowed in another. This temporary inconsistency can occur when you first associate a web ACL with an Amazon Web Services resource and when you change a web ACL that is already associated with a resource. Generally, any inconsistencies of this type last only a few seconds.
" + "smithy.api#documentation": "Updates the specified IPSet.
\nThis operation completely replaces the mutable specifications that you already have for the IP set with the ones that you provide to this call.
\nTo modify an IP set, do the following:
\nRetrieve it by calling GetIPSet\n
\nUpdate its settings as needed
\nProvide the complete IP set specification to this call
\n\n Temporary inconsistencies during updates\n
\nWhen you create or change a web ACL or other WAF resources, the changes take a small amount of time to propagate to all areas where the resources are stored. The propagation time can be from a few seconds to a number of minutes.
\nThe following are examples of the temporary inconsistencies that you might notice during change propagation:
\nAfter you create a web ACL, if you try to associate it with a resource, you might get an exception indicating that the web ACL is unavailable.
\nAfter you add a rule group to a web ACL, the new rule group rules might be in effect in one area where the web ACL is used and not in another.
\nAfter you change a rule action setting, you might see the old action in some places and the new action in others.
\nAfter you add an IP address to an IP set that is in use in a blocking rule, the new address might be blocked in one area while still allowed in another.
\nUpdates the specified RegexPatternSet.
\nThis operation completely replaces the mutable specifications that you already have for the regex pattern set with the ones that you provide to this call.
\nTo modify a regex pattern set, do the following:
\nRetrieve it by calling GetRegexPatternSet\n
\nUpdate its settings as needed
\nProvide the complete regex pattern set specification to this call
\nWhen you make changes to web ACLs or web ACL components, like rules and rule groups, WAF propagates the changes everywhere that the web ACL and its components are stored and used. Your changes are applied within seconds, but there might be a brief period of inconsistency when the changes have arrived in some places and not in others. So, for example, if you change a rule action setting, the action might be the old action in one area and the new action in another area. Or if you add an IP address to an IP set used in a blocking rule, the new address might briefly be blocked in one area while still allowed in another. This temporary inconsistency can occur when you first associate a web ACL with an Amazon Web Services resource and when you change a web ACL that is already associated with a resource. Generally, any inconsistencies of this type last only a few seconds.
" + "smithy.api#documentation": "Updates the specified RegexPatternSet.
\nThis operation completely replaces the mutable specifications that you already have for the regex pattern set with the ones that you provide to this call.
\nTo modify a regex pattern set, do the following:
\nRetrieve it by calling GetRegexPatternSet\n
\nUpdate its settings as needed
\nProvide the complete regex pattern set specification to this call
\n\n Temporary inconsistencies during updates\n
\nWhen you create or change a web ACL or other WAF resources, the changes take a small amount of time to propagate to all areas where the resources are stored. The propagation time can be from a few seconds to a number of minutes.
\nThe following are examples of the temporary inconsistencies that you might notice during change propagation:
\nAfter you create a web ACL, if you try to associate it with a resource, you might get an exception indicating that the web ACL is unavailable.
\nAfter you add a rule group to a web ACL, the new rule group rules might be in effect in one area where the web ACL is used and not in another.
\nAfter you change a rule action setting, you might see the old action in some places and the new action in others.
\nAfter you add an IP address to an IP set that is in use in a blocking rule, the new address might be blocked in one area while still allowed in another.
\nUpdates the specified RuleGroup.
\nThis operation completely replaces the mutable specifications that you already have for the rule group with the ones that you provide to this call.
\nTo modify a rule group, do the following:
\nRetrieve it by calling GetRuleGroup\n
\nUpdate its settings as needed
\nProvide the complete rule group specification to this call
\nWhen you make changes to web ACLs or web ACL components, like rules and rule groups, WAF propagates the changes everywhere that the web ACL and its components are stored and used. Your changes are applied within seconds, but there might be a brief period of inconsistency when the changes have arrived in some places and not in others. So, for example, if you change a rule action setting, the action might be the old action in one area and the new action in another area. Or if you add an IP address to an IP set used in a blocking rule, the new address might briefly be blocked in one area while still allowed in another. This temporary inconsistency can occur when you first associate a web ACL with an Amazon Web Services resource and when you change a web ACL that is already associated with a resource. Generally, any inconsistencies of this type last only a few seconds.
\nA rule group defines a collection of rules to inspect and control web requests that you can use in a WebACL. When you create a rule group, you define an immutable capacity limit. If you update a rule group, you must stay within the capacity. This allows others to reuse the rule group with confidence in its capacity requirements.
" + "smithy.api#documentation": "Updates the specified RuleGroup.
\nThis operation completely replaces the mutable specifications that you already have for the rule group with the ones that you provide to this call.
\nTo modify a rule group, do the following:
\nRetrieve it by calling GetRuleGroup\n
\nUpdate its settings as needed
\nProvide the complete rule group specification to this call
\nA rule group defines a collection of rules to inspect and control web requests that you can use in a WebACL. When you create a rule group, you define an immutable capacity limit. If you update a rule group, you must stay within the capacity. This allows others to reuse the rule group with confidence in its capacity requirements.
\n\n Temporary inconsistencies during updates\n
\nWhen you create or change a web ACL or other WAF resources, the changes take a small amount of time to propagate to all areas where the resources are stored. The propagation time can be from a few seconds to a number of minutes.
\nThe following are examples of the temporary inconsistencies that you might notice during change propagation:
\nAfter you create a web ACL, if you try to associate it with a resource, you might get an exception indicating that the web ACL is unavailable.
\nAfter you add a rule group to a web ACL, the new rule group rules might be in effect in one area where the web ACL is used and not in another.
\nAfter you change a rule action setting, you might see the old action in some places and the new action in others.
\nAfter you add an IP address to an IP set that is in use in a blocking rule, the new address might be blocked in one area while still allowed in another.
\nUpdates the specified WebACL. While updating a web ACL, WAF provides\n continuous coverage to the resources that you have associated with the web ACL.
\nThis operation completely replaces the mutable specifications that you already have for the web ACL with the ones that you provide to this call.
\nTo modify a web ACL, do the following:
\nRetrieve it by calling GetWebACL\n
\nUpdate its settings as needed
\nProvide the complete web ACL specification to this call
\nWhen you make changes to web ACLs or web ACL components, like rules and rule groups, WAF propagates the changes everywhere that the web ACL and its components are stored and used. Your changes are applied within seconds, but there might be a brief period of inconsistency when the changes have arrived in some places and not in others. So, for example, if you change a rule action setting, the action might be the old action in one area and the new action in another area. Or if you add an IP address to an IP set used in a blocking rule, the new address might briefly be blocked in one area while still allowed in another. This temporary inconsistency can occur when you first associate a web ACL with an Amazon Web Services resource and when you change a web ACL that is already associated with a resource. Generally, any inconsistencies of this type last only a few seconds.
\nA web ACL defines a collection of rules to use to inspect and control web requests. Each rule has a statement that defines what to look for in web requests and an action that WAF applies to requests that match the statement. In the web ACL, you assign a default action to take (allow, block) for any request that does not match any of the rules. The rules in a web ACL can be a combination of the types Rule, RuleGroup, and managed rule group. You can associate a web ACL with one or more Amazon Web Services resources to protect. The resources can be an Amazon CloudFront distribution, an Amazon API Gateway REST API, an Application Load Balancer, an AppSync GraphQL API, an Amazon Cognito user pool, an App Runner service, or an Amazon Web Services Verified Access instance.
" + "smithy.api#documentation": "Updates the specified WebACL. While updating a web ACL, WAF provides\n continuous coverage to the resources that you have associated with the web ACL.
\nThis operation completely replaces the mutable specifications that you already have for the web ACL with the ones that you provide to this call.
\nTo modify a web ACL, do the following:
\nRetrieve it by calling GetWebACL\n
\nUpdate its settings as needed
\nProvide the complete web ACL specification to this call
\nA web ACL defines a collection of rules to use to inspect and control web requests. Each rule has a statement that defines what to look for in web requests and an action that WAF applies to requests that match the statement. In the web ACL, you assign a default action to take (allow, block) for any request that does not match any of the rules. The rules in a web ACL can be a combination of the types Rule, RuleGroup, and managed rule group. You can associate a web ACL with one or more Amazon Web Services resources to protect. The resources can be an Amazon CloudFront distribution, an Amazon API Gateway REST API, an Application Load Balancer, an AppSync GraphQL API, an Amazon Cognito user pool, an App Runner service, or an Amazon Web Services Verified Access instance.
\n\n Temporary inconsistencies during updates\n
\nWhen you create or change a web ACL or other WAF resources, the changes take a small amount of time to propagate to all areas where the resources are stored. The propagation time can be from a few seconds to a number of minutes.
\nThe following are examples of the temporary inconsistencies that you might notice during change propagation:
\nAfter you create a web ACL, if you try to associate it with a resource, you might get an exception indicating that the web ACL is unavailable.
\nAfter you add a rule group to a web ACL, the new rule group rules might be in effect in one area where the web ACL is used and not in another.
\nAfter you change a rule action setting, you might see the old action in some places and the new action in others.
\nAfter you add an IP address to an IP set that is in use in a blocking rule, the new address might be blocked in one area while still allowed in another.
\n