@awboost/cfn-resource-types 0.1.390 → 0.1.392

package/lib/AWS-EC2-Instance.d.ts

@@ -300,7 +300,7 @@ export type Ebs = {
  */
 export type ElasticGpuSpecification = {
     /**
-     * The type of Elastic Graphics accelerator.
+     * The type of Elastic Graphics accelerator. Amazon Elastic Graphics is no longer available.
      */
     Type: string;
 };
@@ -310,12 +310,12 @@ export type ElasticGpuSpecification = {
  */
 export type ElasticInferenceAccelerator = {
     /**
-     * The number of elastic inference accelerators to attach to the instance.
+     * The number of elastic inference accelerators to attach to the instance. Amazon Elastic Inference is no longer available.
      * @min `0`
      */
     Count?: number;
     /**
-     * The type of elastic inference accelerator.
+     * The type of elastic inference accelerator. Amazon Elastic Inference is no longer available.
      */
     Type: string;
 };

package/lib/AWS-ECS-Service.d.ts

@@ -51,7 +51,7 @@ export type ECSServiceProperties = {
      */
     DeploymentConfiguration?: DeploymentConfiguration;
     /**
-     * The deployment controller to use for the service. If no deployment controller is specified, the default value of ``ECS`` is used.
+     * The deployment controller to use for the service.
      */
     DeploymentController?: DeploymentController;
     /**
@@ -62,7 +62,7 @@ export type ECSServiceProperties = {
     DesiredCount?: number;
     /**
        * Specifies whether to turn on Amazon ECS managed tags for the tasks within the service. For more information, see [Tagging your Amazon ECS resources](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-using-tags.html) in the *Amazon Elastic Container Service Developer Guide*.
-       When you use Amazon ECS managed tags, you need to set the ``propagateTags`` request parameter.
+       When you use Amazon ECS managed tags, you must set the ``propagateTags`` request parameter.
        */
     EnableECSManagedTags?: boolean;
     /**
@@ -175,12 +175,25 @@ export type ECSServiceAttributes = {
 };
 /**
  * Type definition for `AWS::ECS::Service.AdvancedConfiguration`.
+ * The advanced settings for a load balancer used in blue/green deployments. Specify the alternate target group, listener rules, and IAM role required for traffic shifting during blue/green deployments. For more information, see [Required resources for Amazon ECS blue/green deployments](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/blue-green-deployment-implementation.html) in the *Amazon Elastic Container Service Developer Guide*.
  * @see {@link https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-advancedconfiguration.html}
  */
 export type AdvancedConfiguration = {
+    /**
+     * The Amazon Resource Name (ARN) of the alternate target group for Amazon ECS blue/green deployments.
+     */
     AlternateTargetGroupArn: string;
+    /**
+     * The Amazon Resource Name (ARN) that that identifies the production listener rule (in the case of an Application Load Balancer) or listener (in the case for an Network Load Balancer) for routing production traffic.
+     */
     ProductionListenerRule?: string;
+    /**
+     * The Amazon Resource Name (ARN) of the IAM role that grants Amazon ECS permission to call the Elastic Load Balancing APIs for you.
+     */
     RoleArn?: string;
+    /**
+     * The Amazon Resource Name (ARN) that identifies ) that identifies the test listener rule (in the case of an Application Load Balancer) or listener (in the case for an Network Load Balancer) for routing test traffic.
+     */
     TestListenerRule?: string;
 };
 /**
@@ -235,7 +248,7 @@ export type CapacityProviderStrategyItem = {
  * Type definition for `AWS::ECS::Service.DeploymentAlarms`.
  * One of the methods which provide a way for you to quickly identify when a deployment has failed, and then to optionally roll back the failure to the last working deployment.
  When the alarms are generated, Amazon ECS sets the service deployment to failed. Set the rollback parameter to have Amazon ECS to roll back your service to the last completed deployment after a failure.
- You can only use the ``DeploymentAlarms`` method to detect failures when the ``DeploymentController`` is set to ``ECS`` (rolling update).
+ You can only use the ``DeploymentAlarms`` method to detect failures when the ``DeploymentController`` is set to ``ECS``.
  For more information, see [Rolling update](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-type-ecs.html) in the *Amazon Elastic Container Service Developer Guide*.
  * @see {@link https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-deploymentalarms.html}
  */
@@ -281,15 +294,23 @@ export type DeploymentConfiguration = {
      */
     Alarms?: DeploymentAlarms;
     /**
-     * @min `0`
-     * @max `1440`
-     */
+       * The duration when both blue and green service revisions are running simultaneously after the production traffic has shifted.
+       The following rules apply when you don't specify a value:
+        +  For rolling deployments, the value is set to 3 hours (180 minutes).
+        +  When you use an external deployment controller (``EXTERNAL``), or the ACD blue/green deployment controller (``CODE_DEPLOY``), the value is set to 3 hours (180 minutes).
+        +  For all other cases, the value is set to 36 hours (2160 minutes).
+       * @min `0`
+       * @max `1440`
+       */
     BakeTimeInMinutes?: number;
     /**
        * The deployment circuit breaker can only be used for services using the rolling update (``ECS``) deployment type.
         The *deployment circuit breaker* determines whether a service deployment will fail if the service can't reach a steady state. If you use the deployment circuit breaker, a service deployment will transition to a failed state and stop launching new tasks. If you use the rollback option, when a service deployment fails, the service is rolled back to the last deployment that completed successfully. For more information, see [Rolling update](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-type-ecs.html) in the *Amazon Elastic Container Service Developer Guide*
        */
     DeploymentCircuitBreaker?: DeploymentCircuitBreaker;
+    /**
+     * An array of deployment lifecycle hook objects to run custom logic at specific stages of the deployment lifecycle.
+     */
     LifecycleHooks?: DeploymentLifecycleHook[];
     /**
        * If a service is using the rolling update (``ECS``) deployment type, the ``maximumPercent`` parameter represents an upper limit on the number of your service's tasks that are allowed in the ``RUNNING`` or ``PENDING`` state during a deployment, as a percentage of the ``desiredCount`` (rounded down to the nearest integer). This parameter enables you to define the deployment batch size. For example, if your service is using the ``REPLICA`` service scheduler and has a ``desiredCount`` of four tasks and a ``maximumPercent`` value of 200%, the scheduler may start four new tasks before stopping the four older tasks (provided that the cluster resources required to do this are available). The default ``maximumPercent`` value for a service using the ``REPLICA`` service scheduler is 200%.
@@ -318,6 +339,11 @@ export type DeploymentConfiguration = {
         If a service is using either the blue/green (``CODE_DEPLOY``) or ``EXTERNAL`` deployment types and is running tasks that use the Fargate launch type, the minimum healthy percent value is not used, although it is returned when describing your service.
        */
     MinimumHealthyPercent?: number;
+    /**
+       * The deployment strategy for the service. Choose from these valid values:
+        +  ``ROLLING`` - When you create a service which uses the rolling update (``ROLLING``) deployment strategy, the Amazon ECS service scheduler replaces the currently running tasks with new tasks. The number of tasks that Amazon ECS adds or removes from the service during a rolling update is controlled by the service deployment configuration.
+        +  ``BLUE_GREEN`` - A blue/green deployment strategy (``BLUE_GREEN``) is a release methodology that reduces downtime and risk by running two identical production environments called blue and green. With Amazon ECS blue/green deployments, you can validate new service revisions before directing production traffic to them. This approach provides a safer way to deploy changes with the ability to quickly roll back if needed.
+       */
     Strategy?: "ROLLING" | "BLUE_GREEN";
 };
 /**
@@ -327,21 +353,87 @@ export type DeploymentConfiguration = {
  */
 export type DeploymentController = {
     /**
-       * The deployment controller type to use. There are three deployment controller types available:
-        + ECS The rolling update (ECS) deployment type involves replacing the current running version of the container with the latest version. The number of containers Amazon ECS adds or removes from the service during a rolling update is controlled by adjusting the minimum and maximum number of healthy tasks allowed during a service deployment, as specified in the DeploymentConfiguration. + CODE_DEPLOY The blue/green (CODE_DEPLOY) deployment type uses the blue/green deployment model powered by , which allows you to verify a new deployment of a service before sending production traffic to it. + EXTERNAL The external (EXTERNAL) deployment type enables you to use any third-party deployment controller for full control over the deployment process for an Amazon ECS service.
+       * The deployment controller type to use.
+       The deployment controller is the mechanism that determines how tasks are deployed for your service. The valid options are:
+        +  ECS
+       When you create a service which uses the ``ECS`` deployment controller, you can choose between the following deployment strategies:
+        +  ``ROLLING``: When you create a service which uses the *rolling update* (``ROLLING``) deployment strategy, the ECS service scheduler replaces the currently running tasks with new tasks. The number of tasks that ECS adds or removes from the service during a rolling update is controlled by the service deployment configuration.
+       Rolling update deployments are best suited for the following scenarios:
+        +  Gradual service updates: You need to update your service incrementally without taking the entire service offline at once.
+        +  Limited resource requirements: You want to avoid the additional resource costs of running two complete environments simultaneously (as required by blue/green deployments).
+        +  Acceptable deployment time: Your application can tolerate a longer deployment process, as rolling updates replace tasks one by one.
+        +  No need for instant roll back: Your service can tolerate a rollback process that takes minutes rather than seconds.
+        +  Simple deployment process: You prefer a straightforward deployment approach without the complexity of managing multiple environments, target groups, and listeners.
+        +  No load balancer requirement: Your service doesn't use or require a load balancer, ALB, NLB, or Service Connect (which are required for blue/green deployments).
+        +  Stateful applications: Your application maintains state that makes it difficult to run two parallel environments.
+        +  Cost sensitivity: You want to minimize deployment costs by not running duplicate environments during deployment.
+        
+       Rolling updates are the default deployment strategy for services and provide a balance between deployment safety and resource efficiency for many common application scenarios.
+        +  ``BLUE_GREEN``: A *blue/green* deployment strategy (``BLUE_GREEN``) is a release methodology that reduces downtime and risk by running two identical production environments called blue and green. With ECS blue/green deployments, you can validate new service revisions before directing production traffic to them. This approach provides a safer way to deploy changes with the ability to quickly roll back if needed.
+       ECS blue/green deployments are best suited for the following scenarios:
+        +  Service validation: When you need to validate new service revisions before directing production traffic to them
+        +  Zero downtime: When your service requires zero-downtime deployments
+        +  Instant roll back: When you need the ability to quickly roll back if issues are detected
+        +  Load balancer requirement: When your service uses ALB, NLB, or Service Connect
+        
+        
+        +  External
+       Use a third-party deployment controller.
+        +  Blue/green deployment (powered by ACD)
+       ACD installs an updated version of the application as a new replacement task set and reroutes production traffic from the original application task set to the replacement task set. The original task set is terminated after a successful deployment. Use this deployment controller to verify a new deployment of a service before sending production traffic to it.
+        
+       When updating the deployment controller for a service, consider the following depending on the type of migration you're performing.
+        +  If you have a template that contains the ``EXTERNAL`` deployment controller information as well as ``TaskSet`` and ``PrimaryTaskSet`` resources, and you remove the task set resources from the template when updating from ``EXTERNAL`` to ``ECS``, the ``DescribeTaskSet`` and ``DeleteTaskSet`` API calls will return a 400 error after the deployment controller is updated to ``ECS``. This results in a delete failure on the task set resources, even though the stack transitions to ``UPDATE_COMPLETE`` status. For more information, see [Resource removed from stack but not deleted](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html#troubleshooting-errors-resource-removed-not-deleted) in the CFNlong User Guide. To fix this issue, delete the task sets directly using the ECS``DeleteTaskSet`` API. For more information about how to delete a task set, see [DeleteTaskSet](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DeleteTaskSet.html) in the ECSlong API Reference.
+        +  If you're migrating from ``CODE_DEPLOY`` to ``ECS`` with a new task definition and CFN performs a rollback operation, the ECS``UpdateService`` request fails with the following error:
+       Resource handler returned message: "Invalid request provided: Unable to update task definition on services with a CODE_DEPLOY deployment controller.
+        +  After a successful migration from ``ECS`` to ``EXTERNAL`` deployment controller, you need to manually remove the ``ACTIVE`` task set, because ECS no longer manages the deployment. For information about how to delete a task set, see [DeleteTaskSet](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DeleteTaskSet.html) in the ECSlong API Reference.
        */
     Type?: "CODE_DEPLOY" | "ECS" | "EXTERNAL";
 };
 /**
  * Type definition for `AWS::ECS::Service.DeploymentLifecycleHook`.
+ * A deployment lifecycle hook runs custom logic at specific stages of the deployment process. Currently, you can use Lambda functions as hook targets.
+ For more information, see [Lifecycle hooks for Amazon ECS service deployments](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-lifecycle-hooks.html) in the *Amazon Elastic Container Service Developer Guide*.
  * @see {@link https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-deploymentlifecyclehook.html}
  */
 export type DeploymentLifecycleHook = {
+    /**
+       * The Amazon Resource Name (ARN) of the hook target. Currently, only Lambda function ARNs are supported.
+       You must provide this parameter when configuring a deployment lifecycle hook.
+       */
     HookTargetArn: string;
     /**
-     * @minLength `1`
-     */
+       * The lifecycle stages at which to run the hook. Choose from these valid values:
+        +  RECONCILE_SERVICE
+       The reconciliation stage that only happens when you start a new service deployment with more than 1 service revision in an ACTIVE state.
+       You can use a lifecycle hook for this stage.
+        +  PRE_SCALE_UP
+       The green service revision has not started. The blue service revision is handling 100% of the production traffic. There is no test traffic.
+       You can use a lifecycle hook for this stage.
+        +  POST_SCALE_UP
+       The green service revision has started. The blue service revision is handling 100% of the production traffic. There is no test traffic.
+       You can use a lifecycle hook for this stage.
+        +  TEST_TRAFFIC_SHIFT
+       The blue and green service revisions are running. The blue service revision handles 100% of the production traffic. The green service revision is migrating from 0% to 100% of test traffic.
+       You can use a lifecycle hook for this stage.
+        +  POST_TEST_TRAFFIC_SHIFT
+       The test traffic shift is complete. The green service revision handles 100% of the test traffic.
+       You can use a lifecycle hook for this stage.
+        +  PRODUCTION_TRAFFIC_SHIFT
+       Production traffic is shifting to the green service revision. The green service revision is migrating from 0% to 100% of production traffic.
+       You can use a lifecycle hook for this stage.
+        +  POST_PRODUCTION_TRAFFIC_SHIFT
+       The production traffic shift is complete.
+       You can use a lifecycle hook for this stage.
+        
+       You must provide this parameter when configuring a deployment lifecycle hook.
+       * @minLength `1`
+       */
     LifecycleStages: ("RECONCILE_SERVICE" | "PRE_SCALE_UP" | "POST_SCALE_UP" | "TEST_TRAFFIC_SHIFT" | "POST_TEST_TRAFFIC_SHIFT" | "PRODUCTION_TRAFFIC_SHIFT" | "POST_PRODUCTION_TRAFFIC_SHIFT")[];
+    /**
+       * The Amazon Resource Name (ARN) of the IAM role that grants Amazon ECS permission to call Lambda functions on your behalf.
+       For more information, see [Permissions required for Lambda functions in Amazon ECS blue/green deployments](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/blue-green-permissions.html) in the *Amazon Elastic Container Service Developer Guide*.
+       */
     RoleArn: string;
 };
 /**
@@ -374,6 +466,9 @@ export type EBSTagSpecification = {
  * @see {@link https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-loadbalancer.html}
  */
 export type LoadBalancer = {
+    /**
+     * The advanced settings for the load balancer used in blue/green deployments. Specify the alternate target group, listener rules, and IAM role required for traffic shifting during blue/green deployments.
+     */
     AdvancedConfiguration?: AdvancedConfiguration;
     /**
        * The name of the container (as it appears in a container definition) to associate with the load balancer.
@@ -524,6 +619,9 @@ export type ServiceConnectClientAlias = {
        To avoid changing your applications in client Amazon ECS services, set this to the same port that the client application uses by default. For more information, see [Service Connect](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-connect.html) in the *Amazon Elastic Container Service Developer Guide*.
        */
     Port: number;
+    /**
+     * The configuration for test traffic routing rules used during blue/green deployments with Amazon ECS Service Connect. This allows you to route a portion of traffic to the new service revision of your service for testing before shifting all production traffic.
+     */
     TestTrafficRules?: ServiceConnectTestTrafficRules;
 };
 /**
@@ -599,9 +697,14 @@ export type ServiceConnectService = {
 };
 /**
  * Type definition for `AWS::ECS::Service.ServiceConnectTestTrafficRules`.
+ * The test traffic routing configuration for Amazon ECS blue/green deployments. This configuration allows you to define rules for routing specific traffic to the new service revision during the deployment process, allowing for safe testing before full production traffic shift.
+ For more information, see [Service Connect for Amazon ECS blue/green deployments](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-connect-blue-green.html) in the *Amazon Elastic Container Service Developer Guide*.
  * @see {@link https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-serviceconnecttesttrafficrules.html}
  */
 export type ServiceConnectTestTrafficRules = {
+    /**
+     * The HTTP header-based routing rules that determine which requests should be routed to the new service version during blue/green deployment testing. These rules provide fine-grained control over test traffic routing based on request headers.
+     */
     Header: ServiceConnectTestTrafficRulesHeader;
 };
 /**

package/lib/AWS-MediaPackageV2-OriginEndpoint.d.ts

@@ -403,6 +403,10 @@ export type DrmSystem = "CLEAR_KEY_AES_128" | "FAIRPLAY" | "PLAYREADY" | "WIDEVI
  * @see {@link https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-mediapackagev2-originendpoint-encryption.html}
  */
 export type Encryption = {
+    /**
+     * <p>Excludes SEIG and SGPD boxes from segment metadata in CMAF containers.</p> <p>When set to <code>true</code>, MediaPackage omits these DRM metadata boxes from CMAF segments, which can improve compatibility with certain devices and players that don't support these boxes.</p> <p>Important considerations:</p> <ul> <li> <p>This setting only affects CMAF container formats</p> </li> <li> <p>Key rotation can still be handled through media playlist signaling</p> </li> <li> <p>PSSH and TENC boxes remain unaffected</p> </li> <li> <p>Default behavior is preserved when this setting is disabled</p> </li> </ul> <p>Valid values: <code>true</code> | <code>false</code> </p> <p>Default: <code>false</code> </p>
+     */
+    CmafExcludeSegmentDrmMetadata?: boolean;
     /**
      * <p>A 128-bit, 16-byte hex value represented by a 32-character string, used in conjunction with the key for encrypting content. If you don't specify a value, then MediaPackage creates the constant initialization vector (IV).</p>
      * @minLength `32`

package/lib/AWS-NetworkFirewall-FirewallPolicy.d.ts

@@ -150,6 +150,7 @@ export type StatefulRuleGroupOverride = {
  * @see {@link https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-networkfirewall-firewallpolicy-statefulrulegroupreference.html}
  */
 export type StatefulRuleGroupReference = {
+    DeepThreatInspection?: boolean;
     Override?: StatefulRuleGroupOverride;
     /**
      * @min `1`

package/lib/AWS-NetworkFirewall-RuleGroup.d.ts

@@ -19,6 +19,9 @@ export type NetworkFirewallRuleGroupProperties = {
      * @pattern `^[a-zA-Z0-9-]+$`
      */
     RuleGroupName: string;
+    SummaryConfiguration?: {
+        RuleOptions?: SummaryRuleOption[];
+    };
     Tags?: Tag[];
     Type: "STATELESS" | "STATEFUL";
 };
@@ -294,6 +297,11 @@ export type StatelessRulesAndCustomActions = {
     CustomActions?: CustomAction[];
     StatelessRules: StatelessRule[];
 };
+/**
+ * Type definition for `AWS::NetworkFirewall::RuleGroup.SummaryRuleOption`.
+ * @see {@link https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-networkfirewall-rulegroup-summaryruleoption.html}
+ */
+export type SummaryRuleOption = "SID" | "MSG" | "METADATA";
 /**
  * Type definition for `AWS::NetworkFirewall::RuleGroup.Tag`.
  * @see {@link https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-networkfirewall-rulegroup-tag.html}

package/lib/AWS-RDS-DBCluster.d.ts

@@ -465,6 +465,7 @@ export type RDSDBClusterProperties = {
        Valid for: Aurora DB clusters and Multi-AZ DB clusters
        */
     SourceDBClusterIdentifier?: string;
+    SourceDbClusterResourceId?: string;
     /**
        * The AWS Region which contains the source DB cluster when replicating a DB cluster. For example, ``us-east-1``.
        Valid for: Aurora DB clusters only

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@awboost/cfn-resource-types",
-  "version": "0.1.390",
+  "version": "0.1.392",
   "publishConfig": {
     "access": "public"
   },