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 (#31145)
Updates the L1 CloudFormation resource definitions with the latest changes from `@aws-cdk/aws-service-spec` **L1 CloudFormation resource definition changes:** ``` ├[~] service aws-apigatewayv2 │ └ resources │ └[~] resource AWS::ApiGatewayV2::Integration │ ├ properties │ │ ├ RequestParameters: - json │ │ │ + Map<string, string> ⇐ json │ │ ├ RequestTemplates: - json │ │ │ + Map<string, string> ⇐ json │ │ └ ResponseParameters: - json │ │ + Map<string, Array<ResponseParameter>> ⇐ json │ ├ attributes │ │ └[+] IntegrationId: string │ └ types │ └[~] type ResponseParameter │ ├ - documentation: undefined │ │ + documentation: response parameter │ └ properties │ ├ Destination: - string (required) │ │ + string │ └ Source: - string (required) │ + string ├[~] service aws-bedrock │ └ resources │ ├[~] resource AWS::Bedrock::DataSource │ │ └ types │ │ ├[~] type ChunkingConfiguration │ │ │ └ properties │ │ │ ├ HierarchicalChunkingConfiguration: (documentation changed) │ │ │ └ SemanticChunkingConfiguration: (documentation changed) │ │ ├[~] type CustomTransformationConfiguration │ │ │ ├ - documentation: Settings for customizing steps in the data source content ingestion pipeline. │ │ │ │ + documentation: Settings for customizing steps in the data source content ingestion pipeline. │ │ │ │ You can configure the data source to process documents with a Lambda function after they are parsed and converted into chunks. When you add a post-chunking transformation, the service stores chunked documents in an S3 bucket and invokes a Lambda function to process them. │ │ │ │ To process chunked documents with a Lambda function, define an S3 bucket path for input and output objects, and a transformation that specifies the Lambda function to invoke. You can use the Lambda function to customize how chunks are split, and the metadata for each chunk. │ │ │ └ properties │ │ │ ├ IntermediateStorage: (documentation changed) │ │ │ └ Transformations: (documentation changed) │ │ ├[~] type HierarchicalChunkingConfiguration │ │ │ └ - documentation: Configurations for when you choose hierarchical chunking. If you set the chunkingStrategy as NONE, exclude this field. │ │ │ + documentation: Settings for hierarchical document chunking for a data source. Hierarchical chunking splits documents into layers of chunks where the first layer contains large chunks, and the second layer contains smaller chunks derived from the first layer. │ │ │ You configure the number of tokens to overlap, or repeat across adjacent chunks. For example, if you set overlap tokens to 60, the last 60 tokens in the first chunk are also included at the beginning of the second chunk. For each layer, you must also configure the maximum number of tokens in a chunk. │ │ ├[~] type IntermediateStorage │ │ │ └ properties │ │ │ └ S3Location: (documentation changed) │ │ ├[~] type ParsingConfiguration │ │ │ └ - documentation: Settings for parsing document contents │ │ │ + documentation: Settings for parsing document contents. By default, the service converts the contents of each document into text before splitting it into chunks. To improve processing of PDF files with tables and images, you can configure the data source to convert the pages of text into images and use a model to describe the contents of each page. │ │ │ To use a model to parse PDF documents, set the parsing strategy to `BEDROCK_FOUNDATION_MODEL` and specify the model to use by ARN. You can also override the default parsing prompt with instructions for how to interpret images and tables in your documents. The following models are supported. │ │ │ - Anthropic Claude 3 Sonnet - `anthropic.claude-3-sonnet-20240229-v1:0` │ │ │ - Anthropic Claude 3 Haiku - `anthropic.claude-3-haiku-20240307-v1:0` │ │ │ You can get the ARN of a model with the [ListFoundationModels](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_ListFoundationModels.html) action. Standard model usage charges apply for the foundation model parsing strategy. │ │ ├[~] type S3Location │ │ │ └ properties │ │ │ └ URI: (documentation changed) │ │ ├[~] type SemanticChunkingConfiguration │ │ │ └ - documentation: Configurations for when you choose semantic chunking. If you set the chunkingStrategy as NONE, exclude this field. │ │ │ + documentation: Settings for semantic document chunking for a data source. Semantic chunking splits a document into into smaller documents based on groups of similar content derived from the text with natural language processing. │ │ │ With semantic chunking, each sentence is compared to the next to determine how similar they are. You specify a threshold in the form of a percentile, where adjacent sentences that are less similar than that percentage of sentence pairs are divided into separate chunks. For example, if you set the threshold to 90, then the 10 percent of sentence pairs that are least similar are split. So if you have 101 sentences, 100 sentence pairs are compared, and the 10 with the least similarity are split, creating 11 chunks. These chunks are further split if they exceed the max token size. │ │ │ You must also specify a buffer size, which determines whether sentences are compared in isolation, or within a moving context window that includes the previous and following sentence. For example, if you set the buffer size to `1` , the embedding for sentence 10 is derived from sentences 9, 10, and 11 combined. │ │ ├[~] type Transformation │ │ │ └ - documentation: A Lambda function that processes documents. │ │ │ + documentation: A custom processing step for documents moving through a data source ingestion pipeline. To process documents after they have been converted into chunks, set the step to apply to `POST_CHUNKING` . │ │ ├[~] type TransformationFunction │ │ │ └ properties │ │ │ └ TransformationLambdaConfiguration: (documentation changed) │ │ └[~] type VectorIngestionConfiguration │ │ └ properties │ │ ├ CustomTransformationConfiguration: (documentation changed) │ │ └ ParsingConfiguration: (documentation changed) │ └[~] resource AWS::Bedrock::Guardrail │ └ types │ ├[~] type ContextualGroundingFilterConfig │ │ ├ - documentation: A config for grounding filter. │ │ │ + documentation: The filter configuration details for the guardrails contextual grounding filter. │ │ └ properties │ │ ├ Threshold: (documentation changed) │ │ └ Type: (documentation changed) │ └[~] type ContextualGroundingPolicyConfig │ └ - documentation: Contextual grounding policy config for a guardrail. │ + documentation: The policy configuration details for the guardrails contextual grounding policy. ├[~] service aws-codebuild │ └ resources │ ├[~] resource AWS::CodeBuild::Project │ │ └ types │ │ ├[~] type Source │ │ │ └ properties │ │ │ └ Auth: (documentation changed) │ │ └[~] type SourceAuth │ │ ├ - documentation: `SourceAuth` is a property of the [AWS CodeBuild Project Source](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-codebuild-project-source.html) property type that specifies authorization settings for AWS CodeBuild to access the source code to be built. │ │ │ `SourceAuth` is for use by the CodeBuild console only. Do not get or set it directly. │ │ │ + documentation: `SourceAuth` is a property of the [AWS CodeBuild Project Source](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-codebuild-project-source.html) property type that specifies authorization settings for AWS CodeBuild to access the source code to be built. │ │ └ properties │ │ ├ Resource: (documentation changed) │ │ └ Type: (documentation changed) │ └[~] resource AWS::CodeBuild::SourceCredential │ └ properties │ ├ AuthType: (documentation changed) │ └ Token: (documentation changed) ├[~] service aws-ec2 │ └ resources │ ├[~] resource AWS::EC2::IPAM │ │ └ properties │ │ └[+] EnablePrivateGua: boolean │ ├[~] resource AWS::EC2::LaunchTemplate │ │ └ properties │ │ └ TagSpecifications: (documentation changed) │ ├[~] resource AWS::EC2::SubnetCidrBlock │ │ └ attributes │ │ ├ IpSource: (documentation changed) │ │ └ Ipv6AddressAttribute: (documentation changed) │ └[~] resource AWS::EC2::VPCCidrBlock │ └ attributes │ ├[+] IpSource: string │ └[+] Ipv6AddressAttribute: string ├[~] service aws-ecs │ └ resources │ ├[~] resource AWS::ECS::Service │ │ └ types │ │ ├[~] type LogConfiguration │ │ │ └ - documentation: The log configuration for the container. This parameter maps to `LogConfig` in the [Create a container](https://docs.aws.amazon.com/https://docs.docker.com/engine/api/v1.35/#operation/ContainerCreate) section of the [Docker Remote API](https://docs.aws.amazon.com/https://docs.docker.com/engine/api/v1.35/) and the `--log-driver` option to [`docker run`](https://docs.aws.amazon.com/https://docs.docker.com/engine/reference/commandline/run/) . │ │ │ By default, containers use the same logging driver that the Docker daemon uses. However, the container might use a different logging driver than the Docker daemon by specifying a log driver configuration in the container definition. For more information about the options for different supported log drivers, see [Configure logging drivers](https://docs.aws.amazon.com/https://docs.docker.com/engine/admin/logging/overview/) in the Docker documentation. │ │ │ Understand the following when specifying a log configuration for your containers. │ │ │ - Amazon ECS currently supports a subset of the logging drivers available to the Docker daemon. Additional log drivers may be available in future releases of the Amazon ECS container agent. │ │ │ For tasks on AWS Fargate , the supported log drivers are `awslogs` , `splunk` , and `awsfirelens` . │ │ │ For tasks hosted on Amazon EC2 instances, the supported log drivers are `awslogs` , `fluentd` , `gelf` , `json-file` , `journald` , `syslog` , `splunk` , and `awsfirelens` . │ │ │ - This parameter requires version 1.18 of the Docker Remote API or greater on your container instance. │ │ │ - For tasks that are hosted on Amazon EC2 instances, the Amazon ECS container agent must register the available logging drivers with the `ECS_AVAILABLE_LOGGING_DRIVERS` environment variable before containers placed on that instance can use these log configuration options. For more information, see [Amazon ECS container agent configuration](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-agent-config.html) in the *Amazon Elastic Container Service Developer Guide* . │ │ │ - For tasks that are on AWS Fargate , because you don't have access to the underlying infrastructure your tasks are hosted on, any additional software needed must be installed outside of the task. For example, the Fluentd output aggregators or a remote host running Logstash to send Gelf logs to. │ │ │ + documentation: The log configuration for the container. This parameter maps to `LogConfig` in the docker conainer create command and the `--log-driver` option to docker run. │ │ │ By default, containers use the same logging driver that the Docker daemon uses. However, the container might use a different logging driver than the Docker daemon by specifying a log driver configuration in the container definition. │ │ │ Understand the following when specifying a log configuration for your containers. │ │ │ - Amazon ECS currently supports a subset of the logging drivers available to the Docker daemon. Additional log drivers may be available in future releases of the Amazon ECS container agent. │ │ │ For tasks on AWS Fargate , the supported log drivers are `awslogs` , `splunk` , and `awsfirelens` . │ │ │ For tasks hosted on Amazon EC2 instances, the supported log drivers are `awslogs` , `fluentd` , `gelf` , `json-file` , `journald` , `syslog` , `splunk` , and `awsfirelens` . │ │ │ - This parameter requires version 1.18 of the Docker Remote API or greater on your container instance. │ │ │ - For tasks that are hosted on Amazon EC2 instances, the Amazon ECS container agent must register the available logging drivers with the `ECS_AVAILABLE_LOGGING_DRIVERS` environment variable before containers placed on that instance can use these log configuration options. For more information, see [Amazon ECS container agent configuration](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-agent-config.html) in the *Amazon Elastic Container Service Developer Guide* . │ │ │ - For tasks that are on AWS Fargate , because you don't have access to the underlying infrastructure your tasks are hosted on, any additional software needed must be installed outside of the task. For example, the Fluentd output aggregators or a remote host running Logstash to send Gelf logs to. │ │ └[~] type ServiceConnectConfiguration │ │ └ properties │ │ └ LogConfiguration: (documentation changed) │ ├[~] resource AWS::ECS::TaskDefinition │ │ ├ - documentation: Registers a new task definition from the supplied `family` and `containerDefinitions` . Optionally, you can add data volumes to your containers with the `volumes` parameter. For more information about task definition parameters and defaults, see [Amazon ECS Task Definitions](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_defintions.html) in the *Amazon Elastic Container Service Developer Guide* . │ │ │ You can specify a role for your task with the `taskRoleArn` parameter. When you specify a role for a task, its containers can then use the latest versions of the AWS CLI or SDKs to make API requests to the AWS services that are specified in the policy that's associated with the role. For more information, see [IAM Roles for Tasks](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html) in the *Amazon Elastic Container Service Developer Guide* . │ │ │ You can specify a Docker networking mode for the containers in your task definition with the `networkMode` parameter. The available network modes correspond to those described in [Network settings](https://docs.aws.amazon.com/https://docs.docker.com/engine/reference/run/#/network-settings) in the Docker run reference. If you specify the `awsvpc` network mode, the task is allocated an elastic network interface, and you must specify a `NetworkConfiguration` when you create a service or run a task with the task definition. For more information, see [Task Networking](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-networking.html) in the *Amazon Elastic Container Service Developer Guide* . │ │ │ + documentation: Registers a new task definition from the supplied `family` and `containerDefinitions` . Optionally, you can add data volumes to your containers with the `volumes` parameter. For more information about task definition parameters and defaults, see [Amazon ECS Task Definitions](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_defintions.html) in the *Amazon Elastic Container Service Developer Guide* . │ │ │ You can specify a role for your task with the `taskRoleArn` parameter. When you specify a role for a task, its containers can then use the latest versions of the AWS CLI or SDKs to make API requests to the AWS services that are specified in the policy that's associated with the role. For more information, see [IAM Roles for Tasks](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html) in the *Amazon Elastic Container Service Developer Guide* . │ │ │ You can specify a Docker networking mode for the containers in your task definition with the `networkMode` parameter. If you specify the `awsvpc` network mode, the task is allocated an elastic network interface, and you must specify a [NetworkConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_NetworkConfiguration.html) when you create a service or run a task with the task definition. For more information, see [Task Networking](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-networking.html) in the *Amazon Elastic Container Service Developer Guide* . │ │ ├ properties │ │ │ ├ IpcMode: (documentation changed) │ │ │ ├ NetworkMode: (documentation changed) │ │ │ ├ PidMode: (documentation changed) │ │ │ └ TaskRoleArn: (documentation changed) │ │ └ types │ │ ├[~] type ContainerDefinition │ │ │ └ properties │ │ │ ├ Command: (documentation changed) │ │ │ ├ Cpu: (documentation changed) │ │ │ ├ DisableNetworking: (documentation changed) │ │ │ ├ DnsSearchDomains: (documentation changed) │ │ │ ├ DnsServers: (documentation changed) │ │ │ ├ DockerLabels: (documentation changed) │ │ │ ├ DockerSecurityOptions: (documentation changed) │ │ │ ├ EntryPoint: (documentation changed) │ │ │ ├ Environment: (documentation changed) │ │ │ ├ EnvironmentFiles: (documentation changed) │ │ │ ├ ExtraHosts: (documentation changed) │ │ │ ├ HealthCheck: (documentation changed) │ │ │ ├ Hostname: (documentation changed) │ │ │ ├ Image: (documentation changed) │ │ │ ├ Interactive: (documentation changed) │ │ │ ├ Links: (documentation changed) │ │ │ ├ MemoryReservation: (documentation changed) │ │ │ ├ MountPoints: (documentation changed) │ │ │ ├ Name: (documentation changed) │ │ │ ├ Privileged: (documentation changed) │ │ │ ├ PseudoTerminal: (documentation changed) │ │ │ ├ ReadonlyRootFilesystem: (documentation changed) │ │ │ ├ SystemControls: (documentation changed) │ │ │ ├ User: (documentation changed) │ │ │ ├ VolumesFrom: (documentation changed) │ │ │ └ WorkingDirectory: (documentation changed) │ │ ├[~] type DockerVolumeConfiguration │ │ │ └ properties │ │ │ ├ Driver: (documentation changed) │ │ │ ├ DriverOpts: (documentation changed) │ │ │ └ Labels: (documentation changed) │ │ ├[~] type HealthCheck │ │ │ ├ - documentation: The `HealthCheck` property specifies an object representing a container health check. Health check parameters that are specified in a container definition override any Docker health checks that exist in the container image (such as those specified in a parent image or from the image's Dockerfile). This configuration maps to the `HEALTHCHECK` parameter of [docker run](https://docs.aws.amazon.com/https://docs.docker.com/engine/reference/run/) . │ │ │ │ > The Amazon ECS container agent only monitors and reports on the health checks specified in the task definition. Amazon ECS does not monitor Docker health checks that are embedded in a container image and not specified in the container definition. Health check parameters that are specified in a container definition override any Docker health checks that exist in the container image. │ │ │ │ If a task is run manually, and not as part of a service, the task will continue its lifecycle regardless of its health status. For tasks that are part of a service, if the task reports as unhealthy then the task will be stopped and the service scheduler will replace it. │ │ │ │ The following are notes about container health check support: │ │ │ │ - Container health checks require version 1.17.0 or greater of the Amazon ECS container agent. For more information, see [Updating the Amazon ECS Container Agent](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-agent-update.html) . │ │ │ │ - Container health checks are supported for Fargate tasks if you are using platform version 1.1.0 or greater. For more information, see [AWS Fargate Platform Versions](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/platform_versions.html) . │ │ │ │ - Container health checks are not supported for tasks that are part of a service that is configured to use a Classic Load Balancer. │ │ │ │ + documentation: The `HealthCheck` property specifies an object representing a container health check. Health check parameters that are specified in a container definition override any Docker health checks that exist in the container image (such as those specified in a parent image or from the image's Dockerfile). This configuration maps to the `HEALTHCHECK` parameter of docker run. │ │ │ │ > The Amazon ECS container agent only monitors and reports on the health checks specified in the task definition. Amazon ECS does not monitor Docker health checks that are embedded in a container image and not specified in the container definition. Health check parameters that are specified in a container definition override any Docker health checks that exist in the container image. │ │ │ │ If a task is run manually, and not as part of a service, the task will continue its lifecycle regardless of its health status. For tasks that are part of a service, if the task reports as unhealthy then the task will be stopped and the service scheduler will replace it. │ │ │ │ The following are notes about container health check support: │ │ │ │ - Container health checks require version 1.17.0 or greater of the Amazon ECS container agent. For more information, see [Updating the Amazon ECS Container Agent](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-agent-update.html) . │ │ │ │ - Container health checks are supported for Fargate tasks if you are using platform version 1.1.0 or greater. For more information, see [AWS Fargate Platform Versions](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/platform_versions.html) . │ │ │ │ - Container health checks are not supported for tasks that are part of a service that is configured to use a Classic Load Balancer. │ │ │ └ properties │ │ │ └ Command: (documentation changed) │ │ ├[~] type KernelCapabilities │ │ │ ├ - documentation: The Linux capabilities to add or remove from the default Docker configuration for a container defined in the task definition. For more information about the default capabilities and the non-default available capabilities, see [Runtime privilege and Linux capabilities](https://docs.aws.amazon.com/https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities) in the *Docker run reference* . For more detailed information about these Linux capabilities, see the [capabilities(7)](https://docs.aws.amazon.com/http://man7.org/linux/man-pages/man7/capabilities.7.html) Linux manual page. │ │ │ │ + documentation: The Linux capabilities to add or remove from the default Docker configuration for a container defined in the task definition.. For more detailed information about these Linux capabilities, see the [capabilities(7)](https://docs.aws.amazon.com/http://man7.org/linux/man-pages/man7/capabilities.7.html) Linux manual page. │ │ │ └ properties │ │ │ ├ Add: (documentation changed) │ │ │ └ Drop: (documentation changed) │ │ ├[~] type LinuxParameters │ │ │ └ properties │ │ │ ├ Devices: (documentation changed) │ │ │ ├ InitProcessEnabled: (documentation changed) │ │ │ ├ MaxSwap: (documentation changed) │ │ │ ├ SharedMemorySize: (documentation changed) │ │ │ ├ Swappiness: (documentation changed) │ │ │ └ Tmpfs: (documentation changed) │ │ └[~] type SystemControl │ │ └ - documentation: A list of namespaced kernel parameters to set in the container. This parameter maps to `Sysctls` in the [Create a container](https://docs.aws.amazon.com/https://docs.docker.com/engine/api/v1.35/#operation/ContainerCreate) section of the [Docker Remote API](https://docs.aws.amazon.com/https://docs.docker.com/engine/api/v1.35/) and the `--sysctl` option to [docker run](https://docs.aws.amazon.com/https://docs.docker.com/engine/reference/run/#security-configuration) . For example, you can configure `net.ipv4.tcp_keepalive_time` setting to maintain longer lived connections. │ │ We don't recommend that you specify network-related `systemControls` parameters for multiple containers in a single task that also uses either the `awsvpc` or `host` network mode. Doing this has the following disadvantages: │ │ - For tasks that use the `awsvpc` network mode including Fargate, if you set `systemControls` for any container, it applies to all containers in the task. If you set different `systemControls` for multiple containers in a single task, the container that's started last determines which `systemControls` take effect. │ │ - For tasks that use the `host` network mode, the network namespace `systemControls` aren't supported. │ │ If you're setting an IPC resource namespace to use for the containers in the task, the following conditions apply to your system controls. For more information, see [IPC mode](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#task_definition_ipcmode) . │ │ - For tasks that use the `host` IPC mode, IPC namespace `systemControls` aren't supported. │ │ - For tasks that use the `task` IPC mode, IPC namespace `systemControls` values apply to all containers within a task. │ │ > This parameter is not supported for Windows containers. > This parameter is only supported for tasks that are hosted on AWS Fargate if the tasks are using platform version `1.4.0` or later (Linux). This isn't supported for Windows containers on Fargate. │ │ + documentation: A list of namespaced kernel parameters to set in the container. This parameter maps to `Sysctls` in tthe docker conainer create command and the `--sysctl` option to docker run. For example, you can configure `net.ipv4.tcp_keepalive_time` setting to maintain longer lived connections. │ │ We don't recommend that you specify network-related `systemControls` parameters for multiple containers in a single task that also uses either the `awsvpc` or `host` network mode. Doing this has the following disadvantages: │ │ - For tasks that use the `awsvpc` network mode including Fargate, if you set `systemControls` for any container, it applies to all containers in the task. If you set different `systemControls` for multiple containers in a single task, the container that's started last determines which `systemControls` take effect. │ │ - For tasks that use the `host` network mode, the network namespace `systemControls` aren't supported. │ │ If you're setting an IPC resource namespace to use for the containers in the task, the following conditions apply to your system controls. For more information, see [IPC mode](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#task_definition_ipcmode) . │ │ - For tasks that use the `host` IPC mode, IPC namespace `systemControls` aren't supported. │ │ - For tasks that use the `task` IPC mode, IPC namespace `systemControls` values apply to all containers within a task. │ │ > This parameter is not supported for Windows containers. > This parameter is only supported for tasks that are hosted on AWS Fargate if the tasks are using platform version `1.4.0` or later (Linux). This isn't supported for Windows containers on Fargate. │ └[~] resource AWS::ECS::TaskSet │ └ - documentation: Create a task set in the specified cluster and service. This is used when a service uses the `EXTERNAL` deployment controller type. For more information, see [Amazon ECS deployment types](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-types.html) in the *Amazon Elastic Container Service Developer Guide* . │ > On March 21, 2024, a change was made to resolve the task definition revision before authorization. When a task definition revision is not specified, authorization will occur using the latest revision of a task definition. │ For information about the maximum number of task sets and otther quotas, see [Amazon ECS service quotas](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-quotas.html) in the *Amazon Elastic Container Service Developer Guide* . │ + documentation: Create a task set in the specified cluster and service. This is used when a service uses the `EXTERNAL` deployment controller type. For more information, see [Amazon ECS deployment types](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-types.html) in the *Amazon Elastic Container Service Developer Guide* . │ > On March 21, 2024, a change was made to resolve the task definition revision before authorization. When a task definition revision is not specified, authorization will occur using the latest revision of a task definition. │ For information about the maximum number of task sets and other quotas, see [Amazon ECS service quotas](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-quotas.html) in the *Amazon Elastic Container Service Developer Guide* . ├[~] service aws-glue │ └ resources │ └[~] resource AWS::Glue::Trigger │ └ attributes │ └[-] Id: string ├[~] service aws-lambda │ └ resources │ └[~] resource AWS::Lambda::Function │ └ properties │ └[+] RecursiveLoop: string ├[~] service aws-redshift │ └ resources │ └[~] resource AWS::Redshift::Cluster │ └ types │ └[~] type LoggingProperties │ └ properties │ ├ LogDestinationType: (documentation changed) │ └ LogExports: (documentation changed) └[~] service aws-systemsmanagersap └ resources └[~] resource AWS::SystemsManagerSAP::Application └ properties └ DatabaseArn: (documentation changed) ```
- Loading branch information
1 parent
76e7af6
commit 5387605