feat(sources): update documentation

[aws-cdk-automation]

⚠️ This Pull Request updates daily and will overwrite all manual changes pushed to the branch

Updates the documentation source from upstream. See details in workflow run.

---

Automatically created by projen via the "update-source-documentation" workflow

[github-actions]

To work on this Pull Request, please create a new branch and PR. This prevents your work from being deleted by the automation.

Run the following commands inside the repo:

gh co 658
git switch -c fix-pr-658 && git push -u origin HEAD
gh pr create -t "fix: PR #658" --body "Fixes https://github.com/cdklabs/awscdk-service-spec/pull/658"

[github-actions]

@aws-cdk/aws-service-spec: Model database diff detected

├[~] service aws-internetmonitor
│ └ resources
│    └[~] resource AWS::InternetMonitor::Monitor
│      └ types
│         ├[~] type InternetMeasurementsLogDelivery
│         │ └ properties
│         │    └ S3Config: (documentation changed)
│         └[~] type S3Config
│           ├  - documentation: The configuration for publishing Amazon CloudWatch Internet Monitor internet measurements to Amazon S3. The configuration includes the bucket name and (optionally) prefix for the S3 bucket to store the measurements, and the delivery status. The delivery status is `ENABLED` or `DISABLED` , depending on whether you choose to deliver internet measurements to S3 logs.
│           │  + documentation: The configuration for publishing Amazon CloudWatch Internet Monitor internet measurements to Amazon S3. The configuration includes the bucket name and (optionally) bucket prefix for the S3 bucket to store the measurements, and the delivery status. The delivery status is `ENABLED` if you choose to deliver internet measurements to S3 logs, and `DISABLED` otherwise.
│           │  The measurements are also published to Amazon CloudWatch Logs.
│           └ properties
│              ├ BucketName: (documentation changed)
│              ├ BucketPrefix: (documentation changed)
│              └ LogDeliveryStatus: (documentation changed)
├[~] service aws-networkmanager
│ └ resources
│    └[~] resource AWS::NetworkManager::Device
│      └ attributes
│         └ CreatedAt: (documentation changed)
├[~] service aws-rds
│ └ resources
│    └[~] resource AWS::RDS::DBCluster
│      └ properties
│         ├ KmsKeyId: (documentation changed)
│         └ RestoreToTime: (documentation changed)
├[~] service aws-rolesanywhere
│ └ resources
│    ├[~] resource AWS::RolesAnywhere::Profile
│    │ ├  - documentation: Creates a *profile* , a list of the roles that Roles Anywhere service is trusted to assume. You use profiles to intersect permissions with IAM managed policies.
│    │ │  *Required permissions:* `rolesanywhere:CreateProfile` .
│    │ │  + documentation: Creates a Profile.
│    │ └ properties
│    │    ├ DurationSeconds: (documentation changed)
│    │    ├ Enabled: (documentation changed)
│    │    ├ ManagedPolicyArns: (documentation changed)
│    │    ├ Name: (documentation changed)
│    │    ├ RequireInstanceProperties: (documentation changed)
│    │    ├ RoleArns: (documentation changed)
│    │    ├ SessionPolicy: (documentation changed)
│    │    └ Tags: (documentation changed)
│    └[~] resource AWS::RolesAnywhere::TrustAnchor
│      ├  - documentation: Creates a trust anchor to establish trust between IAM Roles Anywhere and your certificate authority (CA). You can define a trust anchor as a reference to an AWS Private Certificate Authority ( AWS Private CA ) or by uploading a CA certificate. Your AWS workloads can authenticate with the trust anchor using certificates issued by the CA in exchange for temporary AWS credentials.
│      │  *Required permissions:* `rolesanywhere:CreateTrustAnchor` .
│      │  + documentation: Creates a TrustAnchor.
│      └ types
│         ├[~] type Source
│         │ ├  - documentation: The trust anchor type and its related certificate data.
│         │ │  + documentation: Object representing the TrustAnchor type and its related certificate data.
│         │ └ properties
│         │    ├ SourceData: (documentation changed)
│         │    └ SourceType: (documentation changed)
│         └[~] type SourceData
│           └  - documentation: The data field of the trust anchor depending on its type.
│              + documentation: A union object representing the data field of the TrustAnchor depending on its type
├[~] service aws-route53
│ └ resources
│    ├[~] resource AWS::Route53::RecordSet
│    │ └ properties
│    │    └ Name: (documentation changed)
│    └[~] resource AWS::Route53::RecordSetGroup
│      └ types
│         └[~] type RecordSet
│           └ properties
│              └ Name: (documentation changed)
├[~] service aws-servicecatalogappregistry
│ └ resources
│    ├[~] resource AWS::ServiceCatalogAppRegistry::AttributeGroupAssociation
│    │ └ attributes
│    │    └ Id: (documentation changed)
│    └[~] resource AWS::ServiceCatalogAppRegistry::ResourceAssociation
│      └ attributes
│         └ Id: (documentation changed)
└[~] service aws-wafv2
  └ resources
     ├[~] resource AWS::WAFv2::WebACL
     │ ├  - documentation: > This is the latest version of *AWS WAF* , named AWS WAF V2, released in November, 2019. For information, including how to migrate your AWS WAF resources from the prior release, see the [AWS WAF developer guide](https://docs.aws.amazon.com/waf/latest/developerguide/waf-chapter.html) . 
     │ │  Use an `WebACL` to define a collection of rules to use to inspect and control web requests. The rules in a web ACL can contain rule statements that you define explicitly and rule statements that reference rule groups and managed rule groups.
     │ │  Each rule has an action defined, such as Allow, Block, or CAPTCHA, for requests that match the statement of the rule. In the web ACL, you specify the default action to take for any request that doesn't match any of the rules. The default action can be Allow or Block.
     │ │  You can associate a web ACL with one or more AWS resources to protect. The resources can be an Amazon CloudFront distribution, an Amazon API Gateway REST API, an Application Load Balancer , an AWS AppSync GraphQL API , an Amazon Cognito user pool, an AWS App Runner service, or an AWS Verified Access instance.
     │ │  For more information, see [Web access control lists (web ACLs)](https://docs.aws.amazon.com/waf/latest/developerguide/web-acl.html) in the *AWS WAF developer guide* .
     │ │  *Web ACLs used in AWS Shield Advanced automatic application layer DDoS mitigation*
     │ │  If you use Shield Advanced automatic application layer DDoS mitigation, the web ACLs that you use with automatic mitigation have a rule group rule whose name starts with `ShieldMitigationRuleGroup` . This rule is used for automatic mitigations and it's managed for you in the web ACL by Shield Advanced and AWS WAF . You'll see the rule listed among the web ACL rules when you view the web ACL through the AWS WAF interfaces.
     │ │  When you manage the web ACL through AWS CloudFormation interfaces, you won't see the Shield Advanced rule. AWS CloudFormation doesn't include this type of rule in the stack drift status between the actual configuration of the web ACL and your web ACL template.
     │ │  Don't add the Shield Advanced rule group rule to your web ACL template. The rule shouldn't be in your template. When you update the web ACL template in a stack, the Shield Advanced rule is maintained for you by AWS WAF in the resulting web ACL.
     │ │  For more information, see [Shield Advanced automatic application layer DDoS mitigation](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-automatic-app-layer-response.html) in the *AWS Shield Advanced developer guide* .
     │ │  + documentation: > This is the latest version of *AWS WAF* , named AWS WAF V2, released in November, 2019. For information, including how to migrate your AWS WAF resources from the prior release, see the [AWS WAF developer guide](https://docs.aws.amazon.com/waf/latest/developerguide/waf-chapter.html) . 
     │ │  Use an `WebACL` to define a collection of rules to use to inspect and control web requests. Each rule in a web ACL has a statement that defines what to look for in web requests and an action that AWS 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 doesn't match any of the rules.
     │ │  The rules in a web ACL can be a combination of explicitly defined rules and rule groups that you reference from the web ACL. The rule groups can be rule groups that you manage or rule groups that are managed by others.
     │ │  You can associate a web ACL with one or more AWS resources to protect. The resources can be an Amazon CloudFront distribution, an Amazon API Gateway REST API, an Application Load Balancer , an AWS AppSync GraphQL API , an Amazon Cognito user pool, an AWS App Runner service, or an AWS Verified Access instance.
     │ │  For more information, see [Web access control lists (web ACLs)](https://docs.aws.amazon.com/waf/latest/developerguide/web-acl.html) in the *AWS WAF developer guide* .
     │ │  *Web ACLs used in AWS Shield Advanced automatic application layer DDoS mitigation*
     │ │  If you use Shield Advanced automatic application layer DDoS mitigation, the web ACLs that you use with automatic mitigation have a rule group rule whose name starts with `ShieldMitigationRuleGroup` . This rule is used for automatic mitigations and it's managed for you in the web ACL by Shield Advanced and AWS WAF . You'll see the rule listed among the web ACL rules when you view the web ACL through the AWS WAF interfaces.
     │ │  When you manage the web ACL through AWS CloudFormation interfaces, you won't see the Shield Advanced rule. AWS CloudFormation doesn't include this type of rule in the stack drift status between the actual configuration of the web ACL and your web ACL template.
     │ │  Don't add the Shield Advanced rule group rule to your web ACL template. The rule shouldn't be in your template. When you update the web ACL template in a stack, the Shield Advanced rule is maintained for you by AWS WAF in the resulting web ACL.
     │ │  For more information, see [Shield Advanced automatic application layer DDoS mitigation](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-automatic-app-layer-response.html) in the *AWS Shield Advanced developer guide* .
     │ ├ properties
     │ │  └ Rules: (documentation changed)
     │ └ types
     │    └[~] type ManagedRuleGroupStatement
     │      └  - documentation: A rule statement used to run the rules that are defined in a managed rule group. To use this, provide the vendor name and the name of the rule group in this statement. You can retrieve the required names through the API call `ListAvailableManagedRuleGroups` .
     │         You cannot nest a `ManagedRuleGroupStatement` , for example for use inside a `NotStatement` or `OrStatement` . It can only be referenced as a top-level statement within a rule.
     │         > You are charged additional fees when you use the AWS WAF Bot Control managed rule group `AWSManagedRulesBotControlRuleSet` , the AWS WAF Fraud Control account takeover prevention (ATP) managed rule group `AWSManagedRulesATPRuleSet` , or the AWS WAF Fraud Control account creation fraud prevention (ACFP) managed rule group `AWSManagedRulesACFPRuleSet` . For more information, see [AWS WAF Pricing](https://docs.aws.amazon.com/waf/pricing/) .
     │         + documentation: A rule statement used to run the rules that are defined in a managed rule group. To use this, provide the vendor name and the name of the rule group in this statement. You can retrieve the required names through the API call `ListAvailableManagedRuleGroups` .
     │         You cannot nest a `ManagedRuleGroupStatement` , for example for use inside a `NotStatement` or `OrStatement` . You cannot use a managed rule group statement inside another rule group. You can only use a managed rule group statement as a top-level statement in a rule that you define in a web ACL.
     │         > You are charged additional fees when you use the AWS WAF Bot Control managed rule group `AWSManagedRulesBotControlRuleSet` , the AWS WAF Fraud Control account takeover prevention (ATP) managed rule group `AWSManagedRulesATPRuleSet` , or the AWS WAF Fraud Control account creation fraud prevention (ACFP) managed rule group `AWSManagedRulesACFPRuleSet` . For more information, see [AWS WAF Pricing](https://docs.aws.amazon.com/waf/pricing/) .
     └[~] resource AWS::WAFv2::WebACLAssociation
       └  - documentation: > This is the latest version of *AWS WAF* , named AWS WAF V2, released in November, 2019. For information, including how to migrate your AWS WAF resources from the prior release, see the [AWS WAF developer guide](https://docs.aws.amazon.com/waf/latest/developerguide/waf-chapter.html) . 
          Use a web ACL association to define an association between a web ACL and a regional application resource, to protect the resource. A regional application can be an Application Load Balancer (ALB), an Amazon API Gateway REST API, an AWS AppSync GraphQL API, an Amazon Cognito user pool, an AWS App Runner service, or an AWS Verified Access instance.
          For Amazon CloudFront , don't use this resource. Instead, use your CloudFront distribution configuration. To associate a web ACL with a distribution, provide the Amazon Resource Name (ARN) of the `WebACL` to your CloudFront distribution configuration. To disassociate a web ACL, provide an empty ARN. For information, see [AWS::CloudFront::Distribution](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-cloudfront-distribution.html) .
          When you create a web ACL or make changes to a web ACL or web ACL components, like rules and rule groups, AWS 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 AWS 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.
          + documentation: > This is the latest version of *AWS WAF* , named AWS WAF V2, released in November, 2019. For information, including how to migrate your AWS WAF resources from the prior release, see the [AWS WAF developer guide](https://docs.aws.amazon.com/waf/latest/developerguide/waf-chapter.html) . 
          Use a web ACL association to define an association between a web ACL and a regional application resource, to protect the resource. A regional application can be an Application Load Balancer (ALB), an Amazon API Gateway REST API, an AWS AppSync GraphQL API, an Amazon Cognito user pool, an AWS App Runner service, or an AWS Verified Access instance.
          For Amazon CloudFront , don't use this resource. Instead, use your CloudFront distribution configuration. To associate a web ACL with a distribution, provide the Amazon Resource Name (ARN) of the `WebACL` to your CloudFront distribution configuration. To disassociate a web ACL, provide an empty ARN. For information, see [AWS::CloudFront::Distribution](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-cloudfront-distribution.html) .
          *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](https://docs.aws.amazon.com/waf/latest/developerguide/security_iam_service-with-iam.html#security_iam_action-AssociateWebACL) in the *AWS WAF Developer Guide* .
          *Temporary inconsistencies during updates*
          When you create or change a web ACL or other AWS 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.