docs(client-wafv2): Updates the descriptions for the calls that manage web ACL associations, to provide information for customer-managed IAM policies.

awstools · awstools · commit 2e086ef5a0cf · 2023-10-27T19:46:05.000Z
diff --git a/clients/client-wafv2/src/commands/AssociateWebACLCommand.ts b/clients/client-wafv2/src/commands/AssociateWebACLCommand.ts
@@ -42,7 +42,30 @@ export interface AssociateWebACLCommandOutput extends AssociateWebACLResponse, _
  *          <p>For Amazon CloudFront, don't use this call. Instead, use your CloudFront distribution configuration. To
  *          associate a web ACL, in the CloudFront call <code>UpdateDistribution</code>, set the web ACL ID
  *          to the Amazon Resource Name (ARN) of the web ACL. For information, see <a href="https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html">UpdateDistribution</a> in the <i>Amazon CloudFront Developer Guide</i>. </p>
- *          <p>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.</p>
+ *          <p>
+ *             <b>Required permissions for customer-managed IAM policies</b>
+ *          </p>
+ *          <p>This call requires permissions that are specific to the protected resource type.
+ *     For details, see <a href="https://docs.aws.amazon.com/waf/latest/developerguide/security_iam_service-with-iam.html#security_iam_action-AssociateWebACL">Permissions for AssociateWebACL</a> in the <i>WAF Developer Guide</i>. </p>
+ *          <p>
+ *             <b>Temporary inconsistencies during updates</b>
+ *          </p>
+ *          <p>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. </p>
+ *          <p>The following are examples of the temporary inconsistencies that you might notice during change propagation: </p>
+ *          <ul>
+ *             <li>
+ *                <p>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. </p>
+ *             </li>
+ *             <li>
+ *                <p>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.</p>
+ *             </li>
+ *             <li>
+ *                <p>After you change a rule action setting, you might see the old action in some places and the new action in others. </p>
+ *             </li>
+ *             <li>
+ *                <p>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.</p>
+ *             </li>
+ *          </ul>
  * @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/DisassociateWebACLCommand.ts b/clients/client-wafv2/src/commands/DisassociateWebACLCommand.ts
@@ -42,6 +42,11 @@ export interface DisassociateWebACLCommandOutput extends DisassociateWebACLRespo
  *          <p>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
  *             <code>UpdateDistribution</code>. For information, see <a href="https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html">UpdateDistribution</a> in the <i>Amazon CloudFront API Reference</i>. </p>
+ *          <p>
+ *             <b>Required permissions for customer-managed IAM policies</b>
+ *          </p>
+ *          <p>This call requires permissions that are specific to the protected resource type.
+ *     For details, see <a href="https://docs.aws.amazon.com/waf/latest/developerguide/security_iam_service-with-iam.html#security_iam_action-DisassociateWebACL">Permissions for DisassociateWebACL</a> in the <i>WAF Developer Guide</i>.</p>
  * @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
@@ -38,6 +38,16 @@ export interface GetWebACLForResourceCommandOutput extends GetWebACLForResourceR
 /**
  * @public
  * <p>Retrieves the <a>WebACL</a> for the specified resource. </p>
+ *          <p>This call uses <code>GetWebACL</code>, 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 <code>wafv2:GetWebACL</code> on the resource,
+ *               that error won't be included in your CloudTrail event history. </p>
+ *          <p>For Amazon CloudFront, don't use this call. Instead, call the CloudFront action
+ *             <code>GetDistributionConfig</code>. For information, see <a href="https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_GetDistributionConfig.html">GetDistributionConfig</a> in the <i>Amazon CloudFront API Reference</i>. </p>
+ *          <p>
+ *             <b>Required permissions for customer-managed IAM policies</b>
+ *          </p>
+ *          <p>This call requires permissions that are specific to the protected resource type.
+ *     For details, see <a href="https://docs.aws.amazon.com/waf/latest/developerguide/security_iam_service-with-iam.html#security_iam_action-GetWebACLForResource">Permissions for GetWebACLForResource</a> in the <i>WAF Developer Guide</i>.</p>
  * @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
@@ -38,8 +38,15 @@ export interface ListResourcesForWebACLCommandOutput extends ListResourcesForWeb
 /**
  * @public
  * <p>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 <code>ListDistributionsByWebACLId</code>. </p>
+ *       are associated with the specified web ACL. </p>
+ *          <p>For Amazon CloudFront, don't use this call. Instead, use the CloudFront call
+ *           <code>ListDistributionsByWebACLId</code>. For information, see <a href="https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_ListDistributionsByWebACLId.html">ListDistributionsByWebACLId</a>
+ *           in the <i>Amazon CloudFront API Reference</i>. </p>
+ *          <p>
+ *             <b>Required permissions for customer-managed IAM policies</b>
+ *          </p>
+ *          <p>This call requires permissions that are specific to the protected resource type.
+ *     For details, see <a href="https://docs.aws.amazon.com/waf/latest/developerguide/security_iam_service-with-iam.html#security_iam_action-ListResourcesForWebACL">Permissions for ListResourcesForWebACL</a> in the <i>WAF Developer Guide</i>.</p>
  * @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
@@ -54,7 +54,25 @@ export interface UpdateIPSetCommandOutput extends UpdateIPSetResponse, __Metadat
  *                </li>
  *             </ol>
  *          </note>
- *          <p>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.</p>
+ *          <p>
+ *             <b>Temporary inconsistencies during updates</b>
+ *          </p>
+ *          <p>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. </p>
+ *          <p>The following are examples of the temporary inconsistencies that you might notice during change propagation: </p>
+ *          <ul>
+ *             <li>
+ *                <p>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. </p>
+ *             </li>
+ *             <li>
+ *                <p>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.</p>
+ *             </li>
+ *             <li>
+ *                <p>After you change a rule action setting, you might see the old action in some places and the new action in others. </p>
+ *             </li>
+ *             <li>
+ *                <p>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.</p>
+ *             </li>
+ *          </ul>
  * @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/UpdateRegexPatternSetCommand.ts b/clients/client-wafv2/src/commands/UpdateRegexPatternSetCommand.ts
@@ -54,7 +54,25 @@ export interface UpdateRegexPatternSetCommandOutput extends UpdateRegexPatternSe
  *                </li>
  *             </ol>
  *          </note>
- *          <p>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.</p>
+ *          <p>
+ *             <b>Temporary inconsistencies during updates</b>
+ *          </p>
+ *          <p>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. </p>
+ *          <p>The following are examples of the temporary inconsistencies that you might notice during change propagation: </p>
+ *          <ul>
+ *             <li>
+ *                <p>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. </p>
+ *             </li>
+ *             <li>
+ *                <p>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.</p>
+ *             </li>
+ *             <li>
+ *                <p>After you change a rule action setting, you might see the old action in some places and the new action in others. </p>
+ *             </li>
+ *             <li>
+ *                <p>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.</p>
+ *             </li>
+ *          </ul>
  * @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/UpdateRuleGroupCommand.ts b/clients/client-wafv2/src/commands/UpdateRuleGroupCommand.ts
@@ -54,8 +54,26 @@ export interface UpdateRuleGroupCommandOutput extends UpdateRuleGroupResponse, _
  *                </li>
  *             </ol>
  *          </note>
- *          <p>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.</p>
  *          <p> A rule group defines a collection of rules to inspect and control web requests that you can use in a <a>WebACL</a>. 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. </p>
+ *          <p>
+ *             <b>Temporary inconsistencies during updates</b>
+ *          </p>
+ *          <p>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. </p>
+ *          <p>The following are examples of the temporary inconsistencies that you might notice during change propagation: </p>
+ *          <ul>
+ *             <li>
+ *                <p>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. </p>
+ *             </li>
+ *             <li>
+ *                <p>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.</p>
+ *             </li>
+ *             <li>
+ *                <p>After you change a rule action setting, you might see the old action in some places and the new action in others. </p>
+ *             </li>
+ *             <li>
+ *                <p>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.</p>
+ *             </li>
+ *          </ul>
  * @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/UpdateWebACLCommand.ts b/clients/client-wafv2/src/commands/UpdateWebACLCommand.ts
@@ -55,8 +55,26 @@ export interface UpdateWebACLCommandOutput extends UpdateWebACLResponse, __Metad
  *                </li>
  *             </ol>
  *          </note>
- *          <p>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.</p>
  *          <p> 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 <a>Rule</a>, <a>RuleGroup</a>, 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.  </p>
+ *          <p>
+ *             <b>Temporary inconsistencies during updates</b>
+ *          </p>
+ *          <p>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. </p>
+ *          <p>The following are examples of the temporary inconsistencies that you might notice during change propagation: </p>
+ *          <ul>
+ *             <li>
+ *                <p>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. </p>
+ *             </li>
+ *             <li>
+ *                <p>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.</p>
+ *             </li>
+ *             <li>
+ *                <p>After you change a rule action setting, you might see the old action in some places and the new action in others. </p>
+ *             </li>
+ *             <li>
+ *                <p>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.</p>
+ *             </li>
+ *          </ul>
  * @example
  * Use a bare-bones client and the command you need to make an API call.
  * ```javascript
diff --git a/clients/client-wafv2/src/models/models_0.ts b/clients/client-wafv2/src/models/models_0.ts
diff --git a/codegen/sdk-codegen/aws-models/wafv2.json b/codegen/sdk-codegen/aws-models/wafv2.json
