Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
feat: update L1 CloudFormation resource definitions (#29349)
Updates the L1 CloudFormation resource definitions with the latest changes from `@aws-cdk/aws-service-spec`
**L1 CloudFormation resource definition changes:**
```
├[~] service aws-amazonmq
│ └ resources
│ └[~] resource AWS::AmazonMQ::Broker
│ └ attributes
│ ├ AmqpEndpoints: (documentation changed)
│ ├ IpAddresses: (documentation changed)
│ ├ MqttEndpoints: (documentation changed)
│ ├ OpenWireEndpoints: (documentation changed)
│ ├ StompEndpoints: (documentation changed)
│ └ WssEndpoints: (documentation changed)
├[~] service aws-amplify
│ └ resources
│ ├[~] resource AWS::Amplify::App
│ │ ├ properties
│ │ │ ├ AccessToken: (documentation changed)
│ │ │ ├ BuildSpec: (documentation changed)
│ │ │ ├ CustomHeaders: (documentation changed)
│ │ │ ├ Description: (documentation changed)
│ │ │ ├ IAMServiceRole: (documentation changed)
│ │ │ ├ Name: (documentation changed)
│ │ │ ├ OauthToken: (documentation changed)
│ │ │ └ Repository: (documentation changed)
│ │ └ types
│ │ ├[~] type AutoBranchCreationConfig
│ │ │ └ properties
│ │ │ ├ BuildSpec: (documentation changed)
│ │ │ └ PullRequestEnvironmentName: (documentation changed)
│ │ ├[~] type BasicAuthConfig
│ │ │ └ properties
│ │ │ ├ Password: (documentation changed)
│ │ │ └ Username: (documentation changed)
│ │ ├[~] type CustomRule
│ │ │ └ properties
│ │ │ ├ Condition: (documentation changed)
│ │ │ ├ Source: (documentation changed)
│ │ │ ├ Status: (documentation changed)
│ │ │ └ Target: (documentation changed)
│ │ └[~] type EnvironmentVariable
│ │ └ properties
│ │ ├ Name: (documentation changed)
│ │ └ Value: (documentation changed)
│ ├[~] resource AWS::Amplify::Branch
│ │ ├ properties
│ │ │ ├ Backend: (documentation changed)
│ │ │ ├ BranchName: (documentation changed)
│ │ │ ├ BuildSpec: (documentation changed)
│ │ │ ├ Description: (documentation changed)
│ │ │ ├ PullRequestEnvironmentName: (documentation changed)
│ │ │ └ Stage: (documentation changed)
│ │ └ types
│ │ ├[~] type BasicAuthConfig
│ │ │ └ properties
│ │ │ ├ Password: (documentation changed)
│ │ │ └ Username: (documentation changed)
│ │ └[~] type EnvironmentVariable
│ │ └ properties
│ │ ├ Name: (documentation changed)
│ │ └ Value: (documentation changed)
│ └[~] resource AWS::Amplify::Domain
│ ├ - documentation: The AWS::Amplify::Domain resource allows you to connect a custom domain to your app.
│ │ + documentation: Specifies the AWS::Amplify::Domain resource that enables you to connect a custom domain to your app.
│ ├ properties
│ │ ├ AppId: (documentation changed)
│ │ ├ AutoSubDomainIAMRole: (documentation changed)
│ │ ├[+] Certificate: Certificate
│ │ ├[+] CertificateSettings: CertificateSettings
│ │ ├ DomainName: (documentation changed)
│ │ └[+] UpdateStatus: string
│ ├ attributes
│ │ └ AutoSubDomainCreationPatterns: (documentation changed)
│ └ types
│ ├[+] type Certificate
│ │ ├ documentation: Describes the SSL/TLS certificate for the domain association. This can be your own custom certificate or the default certificate that Amplify provisions for you.
│ │ │ If you are updating your domain to use a different certificate, `Certificate` points to the new certificate that is being created instead of the current active certificate. Otherwise, `Certificate` points to the current active certificate.
│ │ │ name: Certificate
│ │ └ properties
│ │ ├CertificateType: string
│ │ ├CertificateArn: string
│ │ └CertificateVerificationDNSRecord: string
│ ├[+] type CertificateSettings
│ │ ├ documentation: The type of SSL/TLS certificate to use for your custom domain. If a certificate type isn't specified, Amplify uses the default `AMPLIFY_MANAGED` certificate.
│ │ │ name: CertificateSettings
│ │ └ properties
│ │ ├CertificateType: string
│ │ └CustomCertificateArn: string
│ └[~] type SubDomainSetting
│ └ properties
│ └ Prefix: (documentation changed)
├[~] service aws-appstream
│ └ resources
│ └[~] resource AWS::AppStream::Fleet
│ └ properties
│ └ DisconnectTimeoutInSeconds: (documentation changed)
├[~] service aws-aps
│ └ resources
│ ├[~] resource AWS::APS::RuleGroupsNamespace
│ │ ├ - documentation: The `AWS::APS::RuleGroupsNamespace` resource creates or updates a rule groups namespace within a Amazon Managed Service for Prometheus workspace. For more information, see [Recording rules and alerting rules](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-Ruler.html) .
│ │ │ + documentation: The definition of a rule groups namespace in an Amazon Managed Service for Prometheus workspace. A rule groups namespace is associated with exactly one rules file. A workspace can have multiple rule groups namespaces. For more information about rules files, seee [Creating a rules file](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-ruler-rulesfile.html) , in the *Amazon Managed Service for Prometheus User Guide* .
│ │ ├ properties
│ │ │ ├ Data: (documentation changed)
│ │ │ ├ Name: (documentation changed)
│ │ │ ├ Tags: (documentation changed)
│ │ │ └ Workspace: (documentation changed)
│ │ └ attributes
│ │ └ Arn: (documentation changed)
│ └[~] resource AWS::APS::Workspace
│ ├ - documentation: The `AWS::APS::Workspace` type specifies an Amazon Managed Service for Prometheus ( Amazon Managed Service for Prometheus ) workspace. A *workspace* is a logical and isolated Prometheus server dedicated to Prometheus resources such as metrics. You can have one or more workspaces in each Region in your account.
│ │ + documentation: An Amazon Managed Service for Prometheus workspace is a logical and isolated Prometheus server dedicated to ingesting, storing, and querying your Prometheus-compatible metrics.
│ ├ properties
│ │ ├ AlertManagerDefinition: (documentation changed)
│ │ ├ Alias: (documentation changed)
│ │ ├ KmsKeyArn: (documentation changed)
│ │ ├ LoggingConfiguration: (documentation changed)
│ │ └ Tags: (documentation changed)
│ ├ attributes
│ │ ├ Arn: (documentation changed)
│ │ ├ PrometheusEndpoint: (documentation changed)
│ │ └ WorkspaceId: (documentation changed)
│ └ types
│ └[~] type LoggingConfiguration
│ ├ - documentation: The LoggingConfiguration attribute sets the logging configuration for the workspace.
│ │ + documentation: Contains information about the logging configuration for the workspace.
│ └ properties
│ └ LogGroupArn: (documentation changed)
├[~] service aws-b2bi
│ └ resources
│ └[~] resource AWS::B2BI::Transformer
│ └ attributes
│ └[+] ModifiedAt: string
├[~] service aws-backup
│ └ resources
│ ├[~] resource AWS::Backup::BackupPlan
│ │ └ types
│ │ └[~] type BackupRuleResourceType
│ │ └ properties
│ │ └ ScheduleExpressionTimezone: (documentation changed)
│ ├[~] resource AWS::Backup::Framework
│ │ └ types
│ │ └[~] type ControlScope
│ │ └ properties
│ │ └ Tags: (documentation changed)
│ └[~] resource AWS::Backup::RestoreTestingPlan
│ └ properties
│ └ Tags: (documentation changed)
├[~] service aws-batch
│ └ resources
│ ├[~] resource AWS::Batch::ComputeEnvironment
│ │ └ types
│ │ └[~] type ComputeResources
│ │ └ properties
│ │ ├ Ec2Configuration: (documentation changed)
│ │ ├ Ec2KeyPair: (documentation changed)
│ │ ├ SecurityGroupIds: (documentation changed)
│ │ ├ Subnets: (documentation changed)
│ │ └ Tags: (documentation changed)
│ ├[~] resource AWS::Batch::JobDefinition
│ │ ├ properties
│ │ │ ├ ContainerProperties: (documentation changed)
│ │ │ ├ EksProperties: (documentation changed)
│ │ │ ├ NodeProperties: (documentation changed)
│ │ │ └ Type: (documentation changed)
│ │ └ types
│ │ ├[~] type ContainerProperties
│ │ │ └ properties
│ │ │ ├ FargatePlatformConfiguration: (documentation changed)
│ │ │ ├ LogConfiguration: (documentation changed)
│ │ │ ├ Memory: (documentation changed)
│ │ │ ├ NetworkConfiguration: (documentation changed)
│ │ │ └ Vcpus: (documentation changed)
│ │ ├[~] type EksContainer
│ │ │ └ properties
│ │ │ └ Args: (documentation changed)
│ │ ├[~] type FargatePlatformConfiguration
│ │ │ └ - documentation: The platform configuration for jobs that are running on Fargate resources. Jobs that run on EC2 resources must not specify this parameter.
│ │ │ + documentation: The platform configuration for jobs that are running on Fargate resources. Jobs that run on Amazon EC2 resources must not specify this parameter.
│ │ ├[~] type NetworkConfiguration
│ │ │ └ - documentation: The network configuration for jobs that are running on Fargate resources. Jobs that are running on EC2 resources must not specify this parameter.
│ │ │ + documentation: The network configuration for jobs that are running on Fargate resources. Jobs that are running on Amazon EC2 resources must not specify this parameter.
│ │ ├[~] type NodeRangeProperty
│ │ │ └ - documentation: An object that represents the properties of the node range for a multi-node parallel job.
│ │ │ + documentation: This is an object that represents the properties of the node range for a multi-node parallel job.
│ │ └[~] type ResourceRequirement
│ │ └ properties
│ │ └ Value: (documentation changed)
│ └[~] resource AWS::Batch::JobQueue
│ └ types
│ └[~] type ComputeEnvironmentOrder
│ └ - documentation: The order that compute environments are tried in for job placement within a queue. Compute environments are tried in ascending order. For example, if two compute environments are associated with a job queue, the compute environment with a lower order integer value is tried for job placement first. Compute environments must be in the `VALID` state before you can associate them with a job queue. All of the compute environments must be either EC2 ( `EC2` or `SPOT` ) or Fargate ( `FARGATE` or `FARGATE_SPOT` ); EC2 and Fargate compute environments can't be mixed.
│ > All compute environments that are associated with a job queue must share the same architecture. AWS Batch doesn't support mixing compute environment architecture types in a single job queue.
│ + documentation: The order that compute environments are tried in for job placement within a queue. Compute environments are tried in ascending order. For example, if two compute environments are associated with a job queue, the compute environment with a lower order integer value is tried for job placement first. Compute environments must be in the `VALID` state before you can associate them with a job queue. All of the compute environments must be either EC2 ( `EC2` or `SPOT` ) or Fargate ( `FARGATE` or `FARGATE_SPOT` ); Amazon EC2 and Fargate compute environments can't be mixed.
│ > All compute environments that are associated with a job queue must share the same architecture. AWS Batch doesn't support mixing compute environment architecture types in a single job queue.
├[~] service aws-cloudformation
│ └ resources
│ └[~] resource AWS::CloudFormation::Stack
│ └ attributes
│ └ Outputs: (documentation changed)
├[~] service aws-cloudfront
│ └ resources
│ └[~] resource AWS::CloudFront::Distribution
│ └ types
│ └[~] type CacheBehavior
│ └ - documentation: A complex type that describes how CloudFront processes requests.
│ You must create at least as many cache behaviors (including the default cache behavior) as you have origins if you want CloudFront to serve objects from all of the origins. Each cache behavior specifies the one origin from which you want CloudFront to get objects. If you have two origins and only the default cache behavior, the default cache behavior will cause CloudFront to get objects from one of the origins, but the other origin is never used.
│ For the current quota (formerly known as limit) on the number of cache behaviors that you can add to a distribution, see [Quotas](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cloudfront-limits.html) in the *Amazon CloudFront Developer Guide* .
│ If you don't want to specify any cache behaviors, include only an empty `CacheBehaviors` element. Don't include an empty `CacheBehavior` element because this is invalid.
│ To delete all cache behaviors in an existing distribution, update the distribution configuration and include only an empty `CacheBehaviors` element.
│ To add, change, or remove one or more cache behaviors, update the distribution configuration and specify all of the cache behaviors that you want to include in the updated distribution.
│ For more information about cache behaviors, see [Cache Behavior Settings](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesCacheBehavior) in the *Amazon CloudFront Developer Guide* .
│ + documentation: A complex type that describes how CloudFront processes requests.
│ You must create at least as many cache behaviors (including the default cache behavior) as you have origins if you want CloudFront to serve objects from all of the origins. Each cache behavior specifies the one origin from which you want CloudFront to get objects. If you have two origins and only the default cache behavior, the default cache behavior will cause CloudFront to get objects from one of the origins, but the other origin is never used.
│ For the current quota (formerly known as limit) on the number of cache behaviors that you can add to a distribution, see [Quotas](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cloudfront-limits.html) in the *Amazon CloudFront Developer Guide* .
│ If you don't want to specify any cache behaviors, include only an empty `CacheBehaviors` element. For more information, see [CacheBehaviors](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CacheBehaviors.html) . Don't include an empty `CacheBehavior` element because this is invalid.
│ To delete all cache behaviors in an existing distribution, update the distribution configuration and include only an empty `CacheBehaviors` element.
│ To add, change, or remove one or more cache behaviors, update the distribution configuration and specify all of the cache behaviors that you want to include in the updated distribution.
│ For more information about cache behaviors, see [Cache Behavior Settings](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesCacheBehavior) in the *Amazon CloudFront Developer Guide* .
├[~] service aws-cognito
│ └ resources
│ ├[~] resource AWS::Cognito::UserPool
│ │ └ properties
│ │ └ DeletionProtection: (documentation changed)
│ └[~] resource AWS::Cognito::UserPoolIdentityProvider
│ └ properties
│ └ ProviderDetails: (documentation changed)
├[~] service aws-datasync
│ └ resources
│ └[~] resource AWS::DataSync::Task
│ └ attributes
│ ├ DestinationNetworkInterfaceArns: (documentation changed)
│ └ SourceNetworkInterfaceArns: (documentation changed)
├[~] service aws-directoryservice
│ └ resources
│ ├[~] resource AWS::DirectoryService::MicrosoftAD
│ │ └ attributes
│ │ └ DnsIpAddresses: (documentation changed)
│ └[~] resource AWS::DirectoryService::SimpleAD
│ └ attributes
│ └ DnsIpAddresses: (documentation changed)
├[~] service aws-dynamodb
│ └ resources
│ ├[~] resource AWS::DynamoDB::GlobalTable
│ │ └ types
│ │ ├[~] type AttributeDefinition
│ │ │ └ - documentation: Represents an attribute for describing the key schema for the table and indexes.
│ │ │ + documentation: Represents an attribute for describing the schema for the table and indexes.
│ │ └[~] type Projection
│ │ └ properties
│ │ └ ProjectionType: (documentation changed)
│ └[~] resource AWS::DynamoDB::Table
│ └ types
│ ├[~] type AttributeDefinition
│ │ └ - documentation: Represents an attribute for describing the key schema for the table and indexes.
│ │ + documentation: Represents an attribute for describing the schema for the table and indexes.
│ └[~] type Projection
│ └ properties
│ └ ProjectionType: (documentation changed)
├[~] service aws-ec2
│ └ resources
│ ├[~] resource AWS::EC2::EC2Fleet
│ │ └ types
│ │ └[~] type FleetLaunchTemplateOverridesRequest
│ │ └ properties
│ │ └ WeightedCapacity: (documentation changed)
│ ├[~] resource AWS::EC2::NetworkInsightsAnalysis
│ │ └ attributes
│ │ ├ AlternatePathHints: (documentation changed)
│ │ ├ Explanations: (documentation changed)
│ │ ├ ForwardPathComponents: (documentation changed)
│ │ ├ ReturnPathComponents: (documentation changed)
│ │ └ SuggestedAccounts: (documentation changed)
│ ├[~] resource AWS::EC2::NetworkInterface
│ │ └ attributes
│ │ └ SecondaryPrivateIpAddresses: (documentation changed)
│ ├[~] resource AWS::EC2::NetworkInterfaceAttachment
│ │ ├ properties
│ │ │ └[+] EnaSrdSpecification: EnaSrdSpecification
│ │ └ types
│ │ ├[+] type EnaSrdSpecification
│ │ │ ├ documentation: ENA Express uses AWS Scalable Reliable Datagram (SRD) technology to increase the maximum bandwidth used per stream and minimize tail latency of network traffic between EC2 instances. With ENA Express, you can communicate between two EC2 instances in the same subnet within the same account, or in different accounts. Both sending and receiving instances must have ENA Express enabled.
│ │ │ │ To improve the reliability of network packet delivery, ENA Express reorders network packets on the receiving end by default. However, some UDP-based applications are designed to handle network packets that are out of order to reduce the overhead for packet delivery at the network layer. When ENA Express is enabled, you can specify whether UDP network traffic uses it.
│ │ │ │ name: EnaSrdSpecification
│ │ │ └ properties
│ │ │ ├EnaSrdEnabled: boolean
│ │ │ └EnaSrdUdpSpecification: EnaSrdUdpSpecification
│ │ └[+] type EnaSrdUdpSpecification
│ │ ├ documentation: ENA Express is compatible with both TCP and UDP transport protocols. When it's enabled, TCP traffic automatically uses it. However, some UDP-based applications are designed to handle network packets that are out of order, without a need for retransmission, such as live video broadcasting or other near-real-time applications. For UDP traffic, you can specify whether to use ENA Express, based on your application environment needs.
│ │ │ name: EnaSrdUdpSpecification
│ │ └ properties
│ │ └EnaSrdUdpEnabled: boolean
│ ├[~] resource AWS::EC2::VPC
│ │ └ attributes
│ │ ├ CidrBlockAssociations: (documentation changed)
│ │ └ Ipv6CidrBlocks: (documentation changed)
│ └[~] resource AWS::EC2::VPCEndpoint
│ └ attributes
│ ├ DnsEntries: (documentation changed)
│ └ NetworkInterfaceIds: (documentation changed)
├[~] service aws-ecs
│ └ resources
│ └[~] resource AWS::ECS::TaskSet
│ ├ - tagInformation: undefined
│ │ + tagInformation: {"tagPropertyName":"Tags","variant":"standard"}
│ └ properties
│ └[+] Tags: Array<tag>
├[~] service aws-elasticache
│ └ resources
│ ├[~] resource AWS::ElastiCache::ParameterGroup
│ │ └ attributes
│ │ └[-] CacheParameterGroupName: string
│ └[~] resource AWS::ElastiCache::ReplicationGroup
│ └ attributes
│ ├ ReadEndPoint.Addresses.List: (documentation changed)
│ └ ReadEndPoint.Ports.List: (documentation changed)
├[~] service aws-elasticloadbalancingv2
│ └ resources
│ ├[~] resource AWS::ElasticLoadBalancingV2::LoadBalancer
│ │ └ attributes
│ │ └ SecurityGroups: (documentation changed)
│ ├[~] resource AWS::ElasticLoadBalancingV2::TargetGroup
│ │ └ attributes
│ │ └ LoadBalancerArns: (documentation changed)
│ └[~] resource AWS::ElasticLoadBalancingV2::TrustStoreRevocation
│ └ attributes
│ └ TrustStoreRevocations: (documentation changed)
├[~] service aws-fsx
│ └ resources
│ └[~] resource AWS::FSx::Volume
│ └ types
│ └[~] type OntapConfiguration
│ └ properties
│ ├ SecurityStyle: (documentation changed)
│ └ SizeInMegabytes: (documentation changed)
├[~] service aws-globalaccelerator
│ └ resources
│ └[~] resource AWS::GlobalAccelerator::Accelerator
│ └ attributes
│ ├ Ipv4Addresses: (documentation changed)
│ └ Ipv6Addresses: (documentation changed)
├[~] service aws-iam
│ └ resources
│ └[~] resource AWS::IAM::Policy
│ └ attributes
│ └ Id: (documentation changed)
├[~] service aws-iot
│ └ resources
│ ├[~] resource AWS::IoT::DomainConfiguration
│ │ └ attributes
│ │ └ ServerCertificates: (documentation changed)
│ └[~] resource AWS::IoT::TopicRule
│ └ properties
│ └ RuleName: (documentation changed)
├[~] service aws-iotsitewise
│ └ resources
│ ├[~] resource AWS::IoTSiteWise::Asset
│ │ ├ properties
│ │ │ └[+] AssetExternalId: string
│ │ └ types
│ │ ├[~] type AssetHierarchy
│ │ │ └ properties
│ │ │ ├[+] ExternalId: string
│ │ │ ├[+] Id: string
│ │ │ └ LogicalId: - string (required)
│ │ │ + string
│ │ └[~] type AssetProperty
│ │ └ properties
│ │ ├[+] ExternalId: string
│ │ ├[+] Id: string
│ │ └ LogicalId: - string (required)
│ │ + string
│ └[~] resource AWS::IoTSiteWise::AssetModel
│ ├ properties
│ │ ├[+] AssetModelExternalId: string
│ │ └[+] AssetModelType: string (immutable)
│ └ types
│ ├[~] type AssetModelCompositeModel
│ │ └ properties
│ │ ├[+] ComposedAssetModelId: string
│ │ ├[+] ExternalId: string
│ │ ├[+] Id: string
│ │ ├[+] ParentAssetModelCompositeModelExternalId: string
│ │ └[+] Path: Array<string>
│ ├[~] type AssetModelHierarchy
│ │ └ properties
│ │ ├[+] ExternalId: string
│ │ ├[+] Id: string
│ │ └ LogicalId: - string (required)
│ │ + string
│ ├[~] type AssetModelProperty
│ │ └ properties
│ │ ├[+] ExternalId: string
│ │ ├[+] Id: string
│ │ └ LogicalId: - string (required)
│ │ + string
│ ├[+] type PropertyPathDefinition
│ │ ├ documentation: The definition for property path which is used to reference properties in transforms/metrics
│ │ │ name: PropertyPathDefinition
│ │ └ properties
│ │ └Name: string (required)
│ └[~] type VariableValue
│ └ properties
│ ├[+] HierarchyExternalId: string
│ ├[+] HierarchyId: string
│ ├[+] PropertyExternalId: string
│ ├[+] PropertyId: string
│ ├ PropertyLogicalId: - string (required)
│ │ + string
│ └[+] PropertyPath: Array<PropertyPathDefinition>
├[~] service aws-iotwireless
│ └ resources
│ └[~] resource AWS::IoTWireless::WirelessDevice
│ └ properties
│ └[+] Positioning: string
├[~] service aws-kinesisfirehose
│ └ resources
│ └[~] resource AWS::KinesisFirehose::DeliveryStream
│ └ types
│ └[~] type ExtendedS3DestinationConfiguration
│ └ properties
│ ├[+] CustomTimeZone: string
│ └[+] FileExtension: string
├[~] service aws-mediaconnect
│ └ resources
│ └[~] resource AWS::MediaConnect::FlowVpcInterface
│ └ attributes
│ └ NetworkInterfaceIds: (documentation changed)
├[~] service aws-medialive
│ └ resources
│ ├[~] resource AWS::MediaLive::Channel
│ │ └ attributes
│ │ └ Inputs: (documentation changed)
│ └[~] resource AWS::MediaLive::Input
│ └ attributes
│ ├ Destinations: (documentation changed)
│ └ Sources: (documentation changed)
├[~] service aws-mediapackagev2
│ └ resources
│ └[~] resource AWS::MediaPackageV2::Channel
│ └ attributes
│ └ IngestEndpoints: (documentation changed)
├[~] service aws-networkfirewall
│ └ resources
│ └[~] resource AWS::NetworkFirewall::Firewall
│ └ attributes
│ └ EndpointIds: (documentation changed)
├[~] service aws-networkmanager
│ └ resources
│ └[~] resource AWS::NetworkManager::CoreNetwork
│ └ attributes
│ ├ Edges: (documentation changed)
│ └ Segments: (documentation changed)
├[~] service aws-nimblestudio
│ └ resources
│ └[~] resource AWS::NimbleStudio::StreamingImage
│ └ attributes
│ └ EulaIds: (documentation changed)
├[~] service aws-opensearchserverless
│ └ resources
│ └[~] resource AWS::OpenSearchServerless::Collection
│ └ properties
│ └ StandbyReplicas: (documentation changed)
├[~] service aws-osis
│ └ resources
│ └[~] resource AWS::OSIS::Pipeline
│ └ attributes
│ └ IngestEndpointUrls: (documentation changed)
├[~] service aws-quicksight
│ └ resources
│ ├[~] resource AWS::QuickSight::Analysis
│ │ └ attributes
│ │ └ DataSetArns: (documentation changed)
│ ├[~] resource AWS::QuickSight::Dashboard
│ │ └ properties
│ │ └ LinkEntities: (documentation changed)
│ └[~] resource AWS::QuickSight::VPCConnection
│ └ attributes
│ └ NetworkInterfaces: (documentation changed)
├[~] service aws-rds
│ └ resources
│ └[~] resource AWS::RDS::DBInstance
│ └ properties
│ └ DBClusterSnapshotIdentifier: (documentation changed)
├[~] service aws-redshift
│ └ resources
│ ├[~] resource AWS::Redshift::EndpointAccess
│ │ └ attributes
│ │ └ VpcSecurityGroups: (documentation changed)
│ └[~] resource AWS::Redshift::EventSubscription
│ └ attributes
│ └ EventCategoriesList: (documentation changed)
├[~] service aws-redshiftserverless
│ └ resources
│ ├[~] resource AWS::RedshiftServerless::Namespace
│ │ ├ properties
│ │ │ └[+] SnapshotCopyConfigurations: Array<SnapshotCopyConfiguration>
│ │ ├ attributes
│ │ │ ├ Namespace.IamRoles: (documentation changed)
│ │ │ └ Namespace.LogExports: (documentation changed)
│ │ └ types
│ │ └[+] type SnapshotCopyConfiguration
│ │ ├ name: SnapshotCopyConfiguration
│ │ └ properties
│ │ ├DestinationRegion: string (required)
│ │ ├DestinationKmsKeyId: string
│ │ └SnapshotRetentionPeriod: integer
│ └[~] resource AWS::RedshiftServerless::Workgroup
│ ├ properties
│ │ └ MaxCapacity: (documentation changed)
│ ├ attributes
│ │ ├ Workgroup.MaxCapacity: (documentation changed)
│ │ ├ Workgroup.SecurityGroupIds: (documentation changed)
│ │ └ Workgroup.SubnetIds: (documentation changed)
│ └ types
│ └[~] type Workgroup
│ └ properties
│ └ MaxCapacity: (documentation changed)
├[~] service aws-route53
│ └ resources
│ └[~] resource AWS::Route53::HostedZone
│ └ attributes
│ └ NameServers: (documentation changed)
├[~] service aws-route53recoverycontrol
│ └ resources
│ └[~] resource AWS::Route53RecoveryControl::Cluster
│ └ attributes
│ └ ClusterEndpoints: (documentation changed)
├[~] service aws-route53recoveryreadiness
│ └ resources
│ └[~] resource AWS::Route53RecoveryReadiness::Cell
│ └ attributes
│ └ ParentReadinessScopes: (documentation changed)
├[~] service aws-route53resolver
│ └ resources
│ └[~] resource AWS::Route53Resolver::ResolverRule
│ └ attributes
│ └ TargetIps: (documentation changed)
├[~] service aws-s3outposts
│ └ resources
│ └[~] resource AWS::S3Outposts::Endpoint
│ └ attributes
│ └ NetworkInterfaces: (documentation changed)
├[~] service aws-sagemaker
│ └ resources
│ └[~] resource AWS::SageMaker::AppImageConfig
│ └ types
│ └[~] type JupyterLabAppImageConfig
│ └ - documentation: The configuration for the file system and kernels in a SageMaker image running as a JupyterLab app.
│ + documentation: The configuration for the file system and kernels in a SageMaker image running as a JupyterLab app. The `FileSystemConfig` object is not supported.
├[~] service aws-ssm
│ └ resources
│ ├[~] resource AWS::SSM::Association
│ │ ├ properties
│ │ │ ├ SyncCompliance: (documentation changed)
│ │ │ └ Targets: (documentation changed)
│ │ └ types
│ │ └[~] type Target
│ │ └ - documentation: `Target` is a property of the [AWS::SSM::Association](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ssm-association.html) resource that specifies the targets for an SSM document in Systems Manager . You can target all instances in an AWS account by specifying the `InstanceIds` key with a value of `*` . To view a JSON and a YAML example that targets all instances, see "Create an association for all managed instances in an AWS account " on the Examples page.
│ │ + documentation: `Target` is a property of the [AWS::SSM::Association](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ssm-association.html) resource that specifies the targets for an SSM document in Systems Manager . You can target all instances in an AWS account by specifying the `InstanceIds` key with a value of `*` . To view a JSON and a YAML example that targets all instances, see the example "Create an association for all managed instances in an AWS account " later in this page.
│ ├[~] resource AWS::SSM::Document
│ │ ├ - documentation: The `AWS::SSM::Document` resource creates a Systems Manager (SSM) document in AWS Systems Manager . This document defines the actions that Systems Manager performs on your AWS resources.
│ │ │ > This resource does not support AWS CloudFormation drift detection.
│ │ │ + documentation: The `AWS::SSM::Document` resource creates a Systems Manager (SSM) document in AWS Systems Manager . This document d efines the actions that Systems Manager performs on your AWS resources.
│ │ │ > This resource does not support AWS CloudFormation drift detection.
│ │ └ properties
│ │ └ DocumentFormat: (documentation changed)
│ ├[~] resource AWS::SSM::MaintenanceWindow
│ │ └ - documentation: The `AWS::SSM::MaintenanceWindow` resource represents general information about a maintenance window for AWS Systems Manager . Maintenance Windows let you define a schedule for when to perform potentially disruptive actions on your instances, such as patching an operating system (OS), updating drivers, or installing software. Each maintenance window has a schedule, a duration, a set of registered targets, and a set of registered tasks.
│ │ For more information, see [Systems Manager Maintenance Windows](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-maintenance.html) in the *AWS Systems Manager User Guide* and [CreateMaintenanceWindow](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreateMaintenanceWindow.html) in the *AWS Systems Manager API Reference* .
│ │ + documentation: The `AWS::SSM::MaintenanceWindow` resource represents general information about a maintenance window for AWS Systems Manager . Maintenance windows let you define a schedule for when to perform potentially disruptive actions on your instances, such as patching an operating system (OS), updating drivers, or installing software. Each maintenance window has a schedule, a duration, a set of registered targets, and a set of registered tasks.
│ │ For more information, see [Systems Manager Maintenance Windows](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-maintenance.html) in the *AWS Systems Manager User Guide* and [CreateMaintenanceWindow](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreateMaintenanceWindow.html) in the *AWS Systems Manager API Reference* .
│ ├[~] resource AWS::SSM::Parameter
│ │ ├ - documentation: The `AWS::SSM::Parameter` resource creates an SSM parameter in AWS Systems Manager Parameter Store.
│ │ │ > To create an SSM parameter, you must have the AWS Identity and Access Management ( IAM ) permissions `ssm:PutParameter` and `ssm:AddTagsToResource` . On stack creation, AWS CloudFormation adds the following three tags to the parameter: `aws:cloudformation:stack-name` , `aws:cloudformation:logical-id` , and `aws:cloudformation:stack-id` , in addition to any custom tags you specify.
│ │ │ >
│ │ │ > To add, update, or remove tags during stack update, you must have IAM permissions for both `ssm:AddTagsToResource` and `ssm:RemoveTagsFromResource` . For more information, see [Managing Access Using Policies](https://docs.aws.amazon.com/systems-manager/latest/userguide/security-iam.html#security_iam_access-manage) in the *AWS Systems Manager User Guide* .
│ │ │ For information about valid values for parameters, see [Requirements and Constraints for Parameter Names](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-paramstore-su-create.html#sysman-parameter-name-constraints) in the *AWS Systems Manager User Guide* and [PutParameter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutParameter.html) in the *AWS Systems Manager API Reference* .
│ │ │ + documentation: The `AWS::SSM::Parameter` resource creates an SSM parameter in AWS Systems Manager Parameter Store.
│ │ │ > To create an SSM parameter, you must have the AWS Identity and Access Management ( IAM ) permissions `ssm:PutParameter` and `ssm:AddTagsToResource` . On stack creation, AWS CloudFormation adds the following three tags to the parameter: `aws:cloudformation:stack-name` , `aws:cloudformation:logical-id` , and `aws:cloudformation:stack-id` , in addition to any custom tags you specify.
│ │ │ >
│ │ │ > To add, update, or remove tags during stack update, you must have IAM permissions for both `ssm:AddTagsToResource` and `ssm:RemoveTagsFromResource` . For more information, see [Managing Access Using Policies](https://docs.aws.amazon.com/systems-manager/latest/userguide/security-iam.html#security_iam_access-manage) in the *AWS Systems Manager User Guide* .
│ │ │ For information about valid values for parameters, see [About requirements and constraints for parameter names](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-paramstore-su-create.html#sysman-parameter-name-constraints) in the *AWS Systems Manager User Guide* and [PutParameter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PutParameter.html) in the *AWS Systems Manager API Reference* .
│ │ └ properties
│ │ ├ Name: (documentation changed)
│ │ └ Type: (documentation changed)
│ ├[~] resource AWS::SSM::ResourceDataSync
│ │ ├ - documentation: The `AWS::SSM::ResourceDataSync` resource creates, updates, or deletes a resource data sync for AWS Systems Manager . A resource data sync helps you view data from multiple sources in a single location. Systems Manager offers two types of resource data sync: `SyncToDestination` and `SyncFromSource` .
│ │ │ You can configure Systems Manager Inventory to use the `SyncToDestination` type to synchronize Inventory data from multiple AWS Regions to a single Amazon S3 bucket.
│ │ │ You can configure Systems Manager Explorer to use the `SyncFromSource` type to synchronize operational work items (OpsItems) and operational data (OpsData) from multiple AWS Regions . This type can synchronize OpsItems and OpsData from multiple AWS accounts and Regions or from an `EntireOrganization` by using AWS Organizations .
│ │ │ A resource data sync is an asynchronous operation that returns immediately. After a successful initial sync is completed, the system continuously syncs data.
│ │ │ By default, data is not encrypted in Amazon S3 . We strongly recommend that you enable encryption in Amazon S3 to ensure secure data storage. We also recommend that you secure access to the Amazon S3 bucket by creating a restrictive bucket policy.
│ │ │ For more information, see [Configuring Inventory Collection](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-inventory-configuring.html#sysman-inventory-datasync) and [Setting Up Systems Manager Explorer to Display Data from Multiple Accounts and Regions](https://docs.aws.amazon.com/systems-manager/latest/userguide/Explorer-resource-data-sync.html) in the *AWS Systems Manager User Guide* .
│ │ │ Important: The following *Syntax* section shows all fields that are supported for a resource data sync. The *Examples* section below shows the recommended way to specify configurations for each sync type. Please see the *Examples* section when you create your resource data sync.
│ │ │ + documentation: The `AWS::SSM::ResourceDataSync` resource creates, updates, or deletes a resource data sync for AWS Systems Manager . A resource data sync helps you view data from multiple sources in a single location. Systems Manager offers two types of resource data sync: `SyncToDestination` and `SyncFromSource` .
│ │ │ You can configure Systems Manager Inventory to use the `SyncToDestination` type to synchronize Inventory data from multiple AWS Regions to a single Amazon S3 bucket.
│ │ │ You can configure Systems Manager Explorer to use the `SyncFromSource` type to synchronize operational work items (OpsItems) and operational data (OpsData) from multiple AWS Regions . This type can synchronize OpsItems and OpsData from multiple AWS accounts and Regions or from an `EntireOrganization` by using AWS Organizations .
│ │ │ A resource data sync is an asynchronous operation that returns immediately. After a successful initial sync is completed, the system continuously syncs data.
│ │ │ By default, data is not encrypted in Amazon S3 . We strongly recommend that you enable encryption in Amazon S3 to ensure secure data storage. We also recommend that you secure access to the Amazon S3 bucket by creating a restrictive bucket policy.
│ │ │ For more information, see [Configuring Inventory Collection](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-inventory-configuring.html#sysman-inventory-datasync) and [Setting Up Systems Manager Explorer to Display Data from Multiple Accounts and Regions](https://docs.aws.amazon.com/systems-manager/latest/userguide/Explorer-resource-data-sync.html) in the *AWS Systems Manager User Guide* .
│ │ │ > The following *Syntax* section shows all fields that are supported for a resource data sync. The *Examples* section below shows the recommended way to specify configurations for each sync type. Refer to the *Examples* section when you create your resource data sync.
│ │ └ properties
│ │ └ KMSKeyArn: (documentation changed)
│ └[~] resource AWS::SSM::ResourcePolicy
│ └ properties
│ └ ResourceArn: (documentation changed)
├[~] service aws-ssmcontacts
│ └ resources
│ └[~] resource AWS::SSMContacts::Contact
│ └ properties
│ └ Type: (documentation changed)
├[~] service aws-ssmincidents
│ └ resources
│ ├[~] resource AWS::SSMIncidents::ReplicationSet
│ │ ├ - documentation: The `AWS::SSMIncidents::ReplicationSet` resource specifies a set of Regions that Incident Manager data is replicated to and the AWS Key Management Service ( AWS KMS key used to encrypt the data.
│ │ │ + documentation: The `AWS::SSMIncidents::ReplicationSet` resource specifies a set of AWS Regions that Incident Manager data is replicated to and the AWS Key Management Service ( AWS KMS key used to encrypt the data.
│ │ └ types
│ │ ├[~] type RegionConfiguration
│ │ │ ├ - documentation: The `RegionConfiguration` property specifies the Region and KMS key to add to the replication set.
│ │ │ │ + documentation: The `RegionConfiguration` property specifies the Region and AWS Key Management Service key to add to the replication set.
│ │ │ └ properties
│ │ │ └ SseKmsKeyId: (documentation changed)
│ │ └[~] type ReplicationRegion
│ │ └ - documentation: The `ReplicationRegion` property type specifies the Region and KMS key to add to the replication set.
│ │ + documentation: The `ReplicationRegion` property type specifies the Region and AWS Key Management Service key to add to the replication set.
│ └[~] resource AWS::SSMIncidents::ResponsePlan
│ └ types
│ ├[~] type ChatChannel
│ │ └ properties
│ │ └ ChatbotSns: (documentation changed)
│ ├[~] type DynamicSsmParameter
│ │ └ - documentation: When you add a runbook to a response plan, you can specify the parameters the runbook should use at runtime. Response plans support parameters with both static and dynamic values. For static values, you enter the value when you define the parameter in the response plan. For dynamic values, the system determines the correct parameter value by collecting information from the incident. Incident Manager supports the following dynamic parameters:
│ │ *Incident ARN*
│ │ When Incident Manager creates an incident, the system captures the Amazon Resource Name (ARN) of the corresponding incident record and enters it for this parameter in the runbook.
│ │ > This value can only be assigned to parameters of type `String` . If assigned to a parameter of any other type, the runbook fails to run.
│ │ *Involved resources*
│ │ When Incident Manager creates an incident, the system captures the ARNs of the resources involved in the incident. These resource ARNs are then assigned to this parameter in the runbook.
│ │ > This value can only be assigned to parameters of type `StringList` . If assigned to a parameter of any other type, the runbook fails to run.
│ │ + documentation: When you add a runbook to a response plan, you can specify the parameters for the runbook to use at runtime. Response plans support parameters with both static and dynamic values. For static values, you enter the value when you define the parameter in the response plan. For dynamic values, the system determines the correct parameter value by collecting information from the incident. Incident Manager supports the following dynamic parameters:
│ │ *Incident ARN*
│ │ When Incident Manager creates an incident, the system captures the Amazon Resource Name (ARN) of the corresponding incident record and enters it for this parameter in the runbook.
│ │ > This value can only be assigned to parameters of type `String` . If assigned to a parameter of any other type, the runbook fails to run.
│ │ *Involved resources*
│ │ When Incident Manager creates an incident, the system captures the ARNs of the resources involved in the incident. These resource ARNs are then assigned to this parameter in the runbook.
│ │ > This value can only be assigned to parameters of type `StringList` . If assigned to a parameter of any other type, the runbook fails to run.
│ ├[~] type IncidentTemplate
│ │ └ properties
│ │ └ NotificationTargets: (documentation changed)
│ ├[~] type NotificationTargetItem
│ │ ├ - documentation: The SNS topic that's used by AWS Chatbot to notify the incidents chat channel.
│ │ │ + documentation: The Amazon SNS topic that's used by AWS Chatbot to notify the incidents chat channel.
│ │ └ properties
│ │ └ SnsTopicArn: (documentation changed)
│ ├[~] type SsmAutomation
│ │ ├ - documentation: The `SsmAutomation` property type specifies details about the Systems Manager automation document that will be used as a runbook during an incident.
│ │ │ + documentation: The `SsmAutomation` property type specifies details about the Systems Manager Automation runbook that will be used as the runbook during an incident.
│ │ └ properties
│ │ ├ DocumentVersion: (documentation changed)
│ │ └ Parameters: (documentation changed)
│ └[~] type SsmParameter
│ ├ - documentation: The key-value pair parameters to use when running the automation document.
│ │ + documentation: The key-value pair parameters to use when running the Automation runbook.
│ └ properties
│ ├ Key: (documentation changed)
│ └ Values: (documentation changed)
├[~] service aws-wafv2
│ └ resources
│ ├[~] resource AWS::WAFv2::RuleGroup
│ │ └ types
│ │ ├[~] type FieldToMatch
│ │ │ └ - documentation: The part of the web request that you want AWS WAF to inspect. Include the single `FieldToMatch` type that you want to inspect, with additional specifications as needed, according to the type. You specify a single request component in `FieldToMatch` for each rule statement that requires it. To inspect more than one component of the web request, create a separate rule statement for each component.
│ │ │ Example JSON for a `QueryString` field to match:
│ │ │ `"FieldToMatch": { "QueryString": {} }`
│ │ │ Example JSON for a `Method` field to match specification:
│ │ │ `"FieldToMatch": { "Method": { "Name": "DELETE" } }`
│ │ │ + documentation: Specifies a web request component to be used in a rule match statement or in a logging configuration.
│ │ │ - In a rule statement, this is the part of the web request that you want AWS WAF to inspect. Include the single `FieldToMatch` type that you want to inspect, with additional specifications as needed, according to the type. You specify a single request component in `FieldToMatch` for each rule statement that requires it. To inspect more than one component of the web request, create a separate rule statement for each component.
│ │ │ Example JSON for a `QueryString` field to match:
│ │ │ `"FieldToMatch": { "QueryString": {} }`
│ │ │ Example JSON for a `Method` field to match specification:
│ │ │ `"FieldToMatch": { "Method": { "Name": "DELETE" } }`
│ │ │ - In a logging configuration, this is used in the `RedactedFields` property to specify a field to redact from the logging records. For this use case, note the following:
│ │ │ - Even though all `FieldToMatch` settings are available, the only valid settings for field redaction are `UriPath` , `QueryString` , `SingleHeader` , and `Method` .
│ │ │ - In this documentation, the descriptions of the individual fields talk about specifying the web request component to inspect, but for field redaction, you are specifying the component type to redact from the logs.
│ │ ├[~] type RateBasedStatement
│ │ │ └ - documentation: A rate-based rule counts incoming requests and rate limits requests when they are coming at too fast a rate. The rule categorizes requests according to your aggregation criteria, collects them into aggregation instances, and counts and rate limits the requests for each instance.
│ │ │ You can specify individual aggregation keys, like IP address or HTTP method. You can also specify aggregation key combinations, like IP address and HTTP method, or HTTP method, query argument, and cookie.
│ │ │ Each unique set of values for the aggregation keys that you specify is a separate aggregation instance, with the value from each key contributing to the aggregation instance definition.
│ │ │ For example, assume the rule evaluates web requests with the following IP address and HTTP method values:
│ │ │ - IP address 10.1.1.1, HTTP method POST
│ │ │ - IP address 10.1.1.1, HTTP method GET
│ │ │ - IP address 127.0.0.0, HTTP method POST
│ │ │ - IP address 10.1.1.1, HTTP method GET
│ │ │ The rule would create different aggregation instances according to your aggregation criteria, for example:
│ │ │ - If the aggregation criteria is just the IP address, then each individual address is an aggregation instance, and AWS WAF counts requests separately for each. The aggregation instances and request counts for our example would be the following:
│ │ │ - IP address 10.1.1.1: count 3
│ │ │ - IP address 127.0.0.0: count 1
│ │ │ - If the aggregation criteria is HTTP method, then each individual HTTP method is an aggregation instance. The aggregation instances and request counts for our example would be the following:
│ │ │ - HTTP method POST: count 2
│ │ │ - HTTP method GET: count 2
│ │ │ - If the aggregation criteria is IP address and HTTP method, then each IP address and each HTTP method would contribute to the combined aggregation instance. The aggregation instances and request counts for our example would be the following:
│ │ │ - IP address 10.1.1.1, HTTP method POST: count 1
│ │ │ - IP address 10.1.1.1, HTTP method GET: count 2
│ │ │ - IP address 127.0.0.0, HTTP method POST: count 1
│ │ │ For any n-tuple of aggregation keys, each unique combination of values for the keys defines a separate aggregation instance, which AWS WAF counts and rate-limits individually.
│ │ │ You can optionally nest another statement inside the rate-based statement, to narrow the scope of the rule so that it only counts and rate limits requests that match the nested statement. You can use this nested scope-down statement in conjunction with your aggregation key specifications or you can just count and rate limit all requests that match the scope-down statement, without additional aggregation. When you choose to just manage all requests that match a scope-down statement, the aggregation instance is singular for the rule.
│ │ │ You cannot nest a `RateBasedStatement` inside another statement, for example inside a `NotStatement` or `OrStatement` . You can define a `RateBasedStatement` inside a web ACL and inside a rule group.
│ │ │ For additional information about the options, see [Rate limiting web requests using rate-based rules](https://docs.aws.amazon.com/waf/latest/developerguide/waf-rate-based-rules.html) in the *AWS WAF Developer Guide* .
│ │ │ If you only aggregate on the individual IP address or forwarded IP address, you can retrieve the list of IP addresses that AWS WAF is currently rate limiting for a rule through the API call `GetRateBasedStatementManagedKeys` . This option is not available for other aggregation configurations.
│ │ │ AWS WAF tracks and manages web requests separately for each instance of a rate-based rule that you use. For example, if you provide the same rate-based rule settings in two web ACLs, each of the two rule statements represents a separate instance of the rate-based rule and gets its own tracking and management by AWS WAF . If you define a rate-based rule inside a rule group, and then use that rule group in multiple places, each use creates a separate instance of the rate-based rule that gets its own tracking and management by AWS WAF .
│ │ │ + documentation: A rate-based rule counts incoming requests and rate limits requests when they are coming at too fast a rate. The rule categorizes requests according to your aggregation criteria, collects them into aggregation instances, and counts and rate limits the requests for each instance.
│ │ │ > If you change any of these settings in a rule that's currently in use, the change resets the rule's rate limiting counts. This can pause the rule's rate limiting activities for up to a minute.
│ │ │ You can specify individual aggregation keys, like IP address or HTTP method. You can also specify aggregation key combinations, like IP address and HTTP method, or HTTP method, query argument, and cookie.
│ │ │ Each unique set of values for the aggregation keys that you specify is a separate aggregation instance, with the value from each key contributing to the aggregation instance definition.
│ │ │ For example, assume the rule evaluates web requests with the following IP address and HTTP method values:
│ │ │ - IP address 10.1.1.1, HTTP method POST
│ │ │ - IP address 10.1.1.1, HTTP method GET
│ │ │ - IP address 127.0.0.0, HTTP method POST
│ │ │ - IP address 10.1.1.1, HTTP method GET
│ │ │ The rule would create different aggregation instances according to your aggregation criteria, for example:
│ │ │ - If the aggregation criteria is just the IP address, then each individual address is an aggregation instance, and AWS WAF counts requests separately for each. The aggregation instances and request counts for our example would be the following:
│ │ │ - IP address 10.1.1.1: count 3
│ │ │ - IP address 127.0.0.0: count 1
│ │ │ - If the aggregation criteria is HTTP method, then each individual HTTP method is an aggregation instance. The aggregation instances and request counts for our example would be the following:
│ │ │ - HTTP method POST: count 2
│ │ │ - HTTP method GET: count 2
│ │ │ - If the aggregation criteria is IP address and HTTP method, then each IP address and each HTTP method would contribute to the combined aggregation instance. The aggregation instances and request counts for our example would be the following:
│ │ │ - IP address 10.1.1.1, HTTP method POST: count 1
│ │ │ - IP address 10.1.1.1, HTTP method GET: count 2
│ │ │ - IP address 127.0.0.0, HTTP method POST: count 1
│ │ │ For any n-tuple of aggregation keys, each unique combination of values for the keys defines a separate aggregation instance, which AWS WAF counts and rate-limits individually.
│ │ │ You can optionally nest another statement inside the rate-based statement, to narrow the scope of the rule so that it only counts and rate limits requests that match the nested statement. You can use this nested scope-down statement in conjunction with your aggregation key specifications or you can just count and rate limit all requests that match the scope-down statement, without additional aggregation. When you choose to just manage all requests that match a scope-down statement, the aggregation instance is singular for the rule.
│ │ │ You cannot nest a `RateBasedStatement` inside another statement, for example inside a `NotStatement` or `OrStatement` . You can define a `RateBasedStatement` inside a web ACL and inside a rule group.
│ │ │ For additional information about the options, see [Rate limiting web requests using rate-based rules](https://docs.aws.amazon.com/waf/latest/developerguide/waf-rate-based-rules.html) in the *AWS WAF Developer Guide* .
│ │ │ If you only aggregate on the individual IP address or forwarded IP address, you can retrieve the list of IP addresses that AWS WAF is currently rate limiting for a rule through the API call `GetRateBasedStatementManagedKeys` . This option is not available for other aggregation configurations.
│ │ │ AWS WAF tracks and manages web requests separately for each instance of a rate-based rule that you use. For example, if you provide the same rate-based rule settings in two web ACLs, each of the two rule statements represents a separate instance of the rate-based rule and gets its own tracking and management by AWS WAF . If you define a rate-based rule inside a rule group, and then use that rule group in multiple places, each use creates a separate instance of the rate-based rule that gets its own tracking and management by AWS WAF .
│ │ └[~] type Statement
│ │ └ properties
│ │ └ RateBasedStatement: (documentation changed)
│ └[~] resource AWS::WAFv2::WebACL
│ └ types
│ ├[~] type FieldToMatch
│ │ └ - documentation: The part of the web request that you want AWS WAF to inspect. Include the single `FieldToMatch` type that you want to inspect, with additional specifications as needed, according to the type. You specify a single request component in `FieldToMatch` for each rule statement that requires it. To inspect more than one component of the web request, create a separate rule statement for each component.
│ │ Example JSON for a `QueryString` field to match:
│ │ `"FieldToMatch": { "QueryString": {} }`
│ │ Example JSON for a `Method` field to match specification:
│ │ `"FieldToMatch": { "Method": { "Name": "DELETE" } }`
│ │ + documentation: Specifies a web request component to be used in a rule match statement or in a logging configuration.
│ │ - In a rule statement, this is the part of the web request that you want AWS WAF to inspect. Include the single `FieldToMatch` type that you want to inspect, with additional specifications as needed, according to the type. You specify a single request component in `FieldToMatch` for each rule statement that requires it. To inspect more than one component of the web request, create a separate rule statement for each component.
│ │ Example JSON for a `QueryString` field to match:
│ │ `"FieldToMatch": { "QueryString": {} }`
│ │ Example JSON for a `Method` field to match specification:
│ │ `"FieldToMatch": { "Method": { "Name": "DELETE" } }`
│ │ - In a logging configuration, this is used in the `RedactedFields` property to specify a field to redact from the logging records. For this use case, note the following:
│ │ - Even though all `FieldToMatch` settings are available, the only valid settings for field redaction are `UriPath` , `QueryString` , `SingleHeader` , and `Method` .
│ │ - In this documentation, the descriptions of the individual fields talk about specifying the web request component to inspect, but for field redaction, you are specifying the component type to redact from the logs.
│ ├[~] type RateBasedStatement
│ │ └ - documentation: A rate-based rule counts incoming requests and rate limits requests when they are coming at too fast a rate. The rule categorizes requests according to your aggregation criteria, collects them into aggregation instances, and counts and rate limits the requests for each instance.
│ │ You can specify individual aggregation keys, like IP address or HTTP method. You can also specify aggregation key combinations, like IP address and HTTP method, or HTTP method, query argument, and cookie.
│ │ Each unique set of values for the aggregation keys that you specify is a separate aggregation instance, with the value from each key contributing to the aggregation instance definition.
│ │ For example, assume the rule evaluates web requests with the following IP address and HTTP method values:
│ │ - IP address 10.1.1.1, HTTP method POST
│ │ - IP address 10.1.1.1, HTTP method GET
│ │ - IP address 127.0.0.0, HTTP method POST
│ │ - IP address 10.1.1.1, HTTP method GET
│ │ The rule would create different aggregation instances according to your aggregation criteria, for example:
│ │ - If the aggregation criteria is just the IP address, then each individual address is an aggregation instance, and AWS WAF counts requests separately for each. The aggregation instances and request counts for our example would be the following:
│ │ - IP address 10.1.1.1: count 3
│ │ - IP address 127.0.0.0: count 1
│ │ - If the aggregation criteria is HTTP method, then each individual HTTP method is an aggregation instance. The aggregation instances and request counts for our example would be the following:
│ │ - HTTP method POST: count 2
│ │ - HTTP method GET: count 2
│ │ - If the aggregation criteria is IP address and HTTP method, then each IP address and each HTTP method would contribute to the combined aggregation instance. The aggregation instances and request counts for our example would be the following:
│ │ - IP address 10.1.1.1, HTTP method POST: count 1
│ │ - IP address 10.1.1.1, HTTP method GET: count 2
│ │ - IP address 127.0.0.0, HTTP method POST: count 1
│ │ For any n-tuple of aggregation keys, each unique combination of values for the keys defines a separate aggregation instance, which AWS WAF counts and rate-limits individually.
│ │ You can optionally nest another statement inside the rate-based statement, to narrow the scope of the rule so that it only counts and rate limits requests that match the nested statement. You can use this nested scope-down statement in conjunction with your aggregation key specifications or you can just count and rate limit all requests that match the scope-down statement, without additional aggregation. When you choose to just manage all requests that match a scope-down statement, the aggregation instance is singular for the rule.
│ │ You cannot nest a `RateBasedStatement` inside another statement, for example inside a `NotStatement` or `OrStatement` . You can define a `RateBasedStatement` inside a web ACL and inside a rule group.
│ │ For additional information about the options, see [Rate limiting web requests using rate-based rules](https://docs.aws.amazon.com/waf/latest/developerguide/waf-rate-based-rules.html) in the *AWS WAF Developer Guide* .
│ │ If you only aggregate on the individual IP address or forwarded IP address, you can retrieve the list of IP addresses that AWS WAF is currently rate limiting for a rule through the API call `GetRateBasedStatementManagedKeys` . This option is not available for other aggregation configurations.
│ │ AWS WAF tracks and manages web requests separately for each instance of a rate-based rule that you use. For example, if you provide the same rate-based rule settings in two web ACLs, each of the two rule statements represents a separate instance of the rate-based rule and gets its own tracking and management by AWS WAF . If you define a rate-based rule inside a rule group, and then use that rule group in multiple places, each use creates a separate instance of the rate-based rule that gets its own tracking and management by AWS WAF .
│ │ + documentation: A rate-based rule counts incoming requests and rate limits requests when they are coming at too fast a rate. The rule categorizes requests according to your aggregation criteria, collects them into aggregation instances, and counts and rate limits the requests for each instance.
│ │ > If you change any of these settings in a rule that's currently in use, the change resets the rule's rate limiting counts. This can pause the rule's rate limiting activities for up to a minute.
│ │ You can specify individual aggregation keys, like IP address or HTTP method. You can also specify aggregation key combinations, like IP address and HTTP method, or HTTP method, query argument, and cookie.
│ │ Each unique set of values for the aggregation keys that you specify is a separate aggregation instance, with the value from each key contributing to the aggregation instance definition.
│ │ For example, assume the rule evaluates web requests with the following IP address and HTTP method values:
│ │ - IP address 10.1.1.1, HTTP method POST
│ │ - IP address 10.1.1.1, HTTP method GET
│ │ - IP address 127.0.0.0, HTTP method POST
│ │ - IP address 10.1.1.1, HTTP method GET
│ │ The rule would create different aggregation instances according to your aggregation criteria, for example:
│ │ - If the aggregation criteria is just the IP address, then each individual address is an aggregation instance, and AWS WAF counts requests separately for each. The aggregation instances and request counts for our example would be the following:
│ │ - IP address 10.1.1.1: count 3
│ │ - IP address 127.0.0.0: count 1
│ │ - If the aggregation criteria is HTTP method, then each individual HTTP method is an aggregation instance. The aggregation instances and requ…- Loading branch information
1 parent
704f596
commit 8b01f45