Update services based on release-2025-10-28 of AWS Go SDK

Reference: https://github.com/aws/aws-sdk-go-v2/releases/tag/release-2025-10-28

Author: web-flow

.latest-tag-aws-sdk-go

@@ -1 +1 @@
-release-2025-10-27
+release-2025-10-28

lib/aws/generated/application_signals.ex

@@ -1079,6 +1079,17 @@ defmodule AWS.ApplicationSignals do
 
   @typedoc """
 
+  ## Example:
+
+      canary_entity() :: %{
+        "CanaryName" => [String.t() | atom()]
+      }
+
+  """
+  @type canary_entity() :: %{(String.t() | atom()) => any()}
+
+  @typedoc """
+
   ## Example:
 
       list_audit_findings_output() :: %{
@@ -1581,10 +1592,14 @@ defmodule AWS.ApplicationSignals do
   end
 
   @doc """
-  Deletes the grouping configuration for this account.
+  Deletes a grouping configuration that defines how services are grouped and
+  organized in Application Signals.
+
+  Once deleted, services will no longer be grouped according to the specified
+  configuration rules.
 
-  This removes all custom grouping attribute definitions that were previously
-  configured.
+  This operation is irreversible. After deletion, you must recreate the grouping
+  configuration if you want to restore the same grouping behavior.
   """
   @spec delete_grouping_configuration(map(), %{}, list()) ::
           {:ok, delete_grouping_configuration_output(), any()}
@@ -1700,13 +1715,14 @@ defmodule AWS.ApplicationSignals do
   end
 
   @doc """
-  Returns a list of audit findings that provide automated analysis of service
-  behavior and root cause analysis.
+  Retrieves a list of audit findings for Application Signals resources.
 
-  These findings help identify the most significant observations about your
-  services, including performance issues, anomalies, and potential problems. The
-  findings are generated using heuristic algorithms based on established
-  troubleshooting patterns.
+  Audit findings identify potential issues, misconfigurations, or compliance
+  violations in your observability setup.
+
+  You can filter findings by time range, auditor type, and target resources to
+  focus on specific areas of concern. This operation supports pagination for large
+  result sets.
   """
   @spec list_audit_findings(map(), list_audit_findings_input(), list()) ::
           {:ok, list_audit_findings_output(), any()}
@@ -1741,11 +1757,14 @@ defmodule AWS.ApplicationSignals do
   end
 
   @doc """
-  Returns the current grouping configuration for this account, including all
-  custom grouping attribute definitions that have been configured.
+  Retrieves the available grouping attribute definitions that can be used to
+  create grouping configurations.
 
-  These definitions determine how services are logically grouped based on
-  telemetry attributes, Amazon Web Services tags, or predefined mappings.
+  These definitions specify the attributes and rules available for organizing
+  services.
+
+  Use this operation to discover what grouping options are available before
+  creating or updating grouping configurations.
   """
   @spec list_grouping_attribute_definitions(
           map(),
@@ -1988,11 +2007,15 @@ defmodule AWS.ApplicationSignals do
   end
 
   @doc """
-  Returns information about the last deployment and other change states of
-  services.
+  Retrieves the current state information for services monitored by Application
+  Signals.
+
+  Service states include health status, recent change events, and other
+  operational metadata.
 
-  This API provides visibility into recent changes that may have affected service
-  performance, helping with troubleshooting and change correlation.
+  You can filter results by time range, AWS account, and service attributes to
+  focus on specific services or time periods. This operation supports pagination
+  and can include data from linked accounts.
   """
   @spec list_service_states(map(), list_service_states_input(), list()) ::
           {:ok, list_service_states_output(), any()}
@@ -2130,13 +2153,12 @@ defmodule AWS.ApplicationSignals do
   end
 
   @doc """
-  Creates or updates the grouping configuration for this account.
+  Creates or updates a grouping configuration that defines how services are
+  organized and grouped in Application Signals dashboards and service maps.
 
-  This operation allows you to define custom grouping attributes that determine
-  how services are logically grouped based on telemetry attributes, Amazon Web
-  Services tags, or predefined mappings. These grouping attributes can then be
-  used to organize and filter services in the Application Signals console and
-  APIs.
+  Grouping configurations allow you to logically organize services based on
+  attributes such as environment, team ownership, or business function, making it
+  easier to monitor and manage related services together.
   """
   @spec put_grouping_configuration(map(), put_grouping_configuration_input(), list()) ::
           {:ok, put_grouping_configuration_output(), any()}

lib/aws/generated/ec2.ex

@@ -4098,6 +4098,21 @@ defmodule AWS.EC2 do
 
   @typedoc """
 
+  ## Example:
+      
+      describe_capacity_reservation_topology_request() :: %{
+        optional("CapacityReservationIds") => list(String.t() | atom()),
+        optional("DryRun") => boolean(),
+        optional("Filters") => list(filter()),
+        optional("MaxResults") => integer(),
+        optional("NextToken") => String.t() | atom()
+      }
+      
+  """
+  @type describe_capacity_reservation_topology_request() :: %{(String.t() | atom()) => any()}
+
+  @typedoc """
+
   ## Example:
 
       launch_template_license_configuration() :: %{
@@ -13969,6 +13984,24 @@ defmodule AWS.EC2 do
 
   @typedoc """
 
+  ## Example:
+      
+      capacity_reservation_topology() :: %{
+        "AvailabilityZone" => String.t() | atom(),
+        "AvailabilityZoneId" => String.t() | atom(),
+        "CapacityBlockId" => String.t() | atom(),
+        "CapacityReservationId" => String.t() | atom(),
+        "GroupName" => String.t() | atom(),
+        "InstanceType" => String.t() | atom(),
+        "NetworkNodes" => list(String.t() | atom()),
+        "State" => String.t() | atom()
+      }
+      
+  """
+  @type capacity_reservation_topology() :: %{(String.t() | atom()) => any()}
+
+  @typedoc """
+
   ## Example:
 
       reject_capacity_reservation_billing_ownership_result() :: %{
@@ -16381,6 +16414,18 @@ defmodule AWS.EC2 do
 
   @typedoc """
 
+  ## Example:
+      
+      describe_capacity_reservation_topology_result() :: %{
+        "CapacityReservations" => list(capacity_reservation_topology()),
+        "NextToken" => String.t() | atom()
+      }
+      
+  """
+  @type describe_capacity_reservation_topology_result() :: %{(String.t() | atom()) => any()}
+
+  @typedoc """
+
   ## Example:
 
       attribute_value() :: %{
@@ -37303,6 +37348,54 @@ defmodule AWS.EC2 do
     Request.request_post(client, meta, "DescribeCapacityReservationFleets", input, options)
   end
 
+  @doc """
+  Describes a tree-based hierarchy that represents the physical host placement of
+  your
+  pending or active Capacity Reservations within an Availability Zone or Local
+  Zone.
+
+  You
+  can use this information to determine the relative proximity of your capacity
+  within the
+  Amazon Web Services network before it is launched and use this information to
+  allocate capacity
+  together to support your tightly coupled workloads.
+
+  Capacity Reservation topology is supported for specific instance types only. For
+  more
+  information, see [Prerequisites for Amazon EC2 instance
+  topology](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-topology-prerequisites.html)
+  in the
+  *Amazon EC2 User Guide*.
+
+  The Amazon EC2 API follows an eventual consistency model due to the
+  distributed nature of the system supporting it. As a result, when you call the
+  DescribeCapacityReservationTopology API command immediately after launching
+  instances, the response might return a `null` value for
+  `capacityBlockId` because the data might not have fully propagated
+  across all subsystems. For more information, see [Eventual consistency in the Amazon EC2
+  API](https://docs.aws.amazon.com/ec2/latest/devguide/eventual-consistency.html)
+  in the *Amazon EC2 Developer
+  Guide*.
+
+  For more information, see [Amazon EC2 topology](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-topology.html)
+  in
+  the *Amazon EC2 User Guide*.
+  """
+  @spec describe_capacity_reservation_topology(
+          map(),
+          describe_capacity_reservation_topology_request(),
+          list()
+        ) ::
+          {:ok, describe_capacity_reservation_topology_result(), any()}
+          | {:error, {:unexpected_response, any()}}
+          | {:error, term()}
+  def describe_capacity_reservation_topology(%Client{} = client, input, options \\ []) do
+    meta = metadata()
+
+    Request.request_post(client, meta, "DescribeCapacityReservationTopology", input, options)
+  end
+
   @doc """
   Describes one or more of your Capacity Reservations.
 
@@ -38312,10 +38405,10 @@ defmodule AWS.EC2 do
 
   Instance topology is supported for specific instance types only. For more
   information,
-  see [
-  Prerequisites for Amazon EC2 instance
+  see [Prerequisites for Amazon EC2 instance
   topology](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-topology-prerequisites.html)
-  in the *Amazon EC2 User Guide*.
+  in the
+  *Amazon EC2 User Guide*.
 
   The Amazon EC2 API follows an eventual consistency model due to the
   distributed nature of the system supporting it. As a result, when you call the
@@ -38327,8 +38420,9 @@ defmodule AWS.EC2 do
   in the *Amazon EC2 Developer
   Guide*.
 
-  For more information, see [Amazon EC2 instance topology](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-topology.html)
-  in the *Amazon EC2 User Guide*.
+  For more information, see [Amazon EC2 topology](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-topology.html)
+  in
+  the *Amazon EC2 User Guide*.
   """
   @spec describe_instance_topology(map(), describe_instance_topology_request(), list()) ::
           {:ok, describe_instance_topology_result(), any()}

lib/aws/generated/ecs.ex

@@ -816,7 +816,9 @@ defmodule AWS.ECS do
       service_revision_summary() :: %{
         "arn" => String.t() | atom(),
         "pendingTaskCount" => integer(),
+        "requestedProductionTrafficWeight" => float(),
         "requestedTaskCount" => integer(),
+        "requestedTestTrafficWeight" => float(),
         "runningTaskCount" => integer()
       }
       
@@ -836,6 +838,18 @@ defmodule AWS.ECS do
 
   @typedoc """
 
+  ## Example:
+      
+      linear_configuration() :: %{
+        "stepBakeTimeInMinutes" => integer(),
+        "stepPercent" => float()
+      }
+      
+  """
+  @type linear_configuration() :: %{(String.t() | atom()) => any()}
+
+  @typedoc """
+
   ## Example:
       
       service_not_found_exception() :: %{
@@ -1241,8 +1255,10 @@ defmodule AWS.ECS do
       deployment_configuration() :: %{
         "alarms" => deployment_alarms(),
         "bakeTimeInMinutes" => integer(),
+        "canaryConfiguration" => canary_configuration(),
         "deploymentCircuitBreaker" => deployment_circuit_breaker(),
         "lifecycleHooks" => list(deployment_lifecycle_hook()),
+        "linearConfiguration" => linear_configuration(),
         "maximumPercent" => integer(),
         "minimumHealthyPercent" => integer(),
         "strategy" => list(any())
@@ -2500,6 +2516,18 @@ defmodule AWS.ECS do
 
   @typedoc """
 
+  ## Example:
+      
+      canary_configuration() :: %{
+        "canaryBakeTimeInMinutes" => integer(),
+        "canaryPercent" => float()
+      }
+      
+  """
+  @type canary_configuration() :: %{(String.t() | atom()) => any()}
+
+  @typedoc """
+
   ## Example:
       
       submit_container_state_change_response() :: %{
@@ -4594,6 +4622,57 @@ defmodule AWS.ECS do
   service uses Application Load Balancer, Network Load Balancer, or Service
   Connect
 
+      *
+
+  `LINEAR`: A *linear* deployment strategy (`LINEAR`) gradually shifts traffic
+  from the current production environment to a new environment in equal percentage
+  increments over a specified time period. With Amazon ECS linear deployments, you
+  can control the pace of traffic shifting and validate new service revisions with
+  increasing amounts of production traffic.
+
+  Linear deployments are best suited for the following scenarios:
+
+        *
+  Gradual validation: When you want to gradually validate your new service version
+  with increasing traffic
+
+        *
+  Performance monitoring: When you need time to monitor metrics and performance
+  during the deployment
+
+        *
+  Risk minimization: When you want to minimize risk by exposing the new version to
+  production traffic incrementally
+
+        *
+  Load balancer requirement: When your service uses Application Load Balancer,
+  Network Load Balancer, or Service Connect
+
+      *
+
+  `CANARY`: A *canary* deployment strategy (`CANARY`) shifts a small percentage of
+  traffic to the new service revision first, then shifts the remaining traffic all
+  at once after a specified time period. This allows you to test the new version
+  with a subset of users before full deployment.
+
+  Canary deployments are best suited for the following scenarios:
+
+        *
+  Feature testing: When you want to test new features with a small subset of users
+  before full rollout
+
+        *
+  Production validation: When you need to validate performance and functionality
+  with real production traffic
+
+        *
+  Blast radius control: When you want to minimize blast radius if issues are
+  discovered in the new version
+
+        *
+  Load balancer requirement: When your service uses Application Load Balancer,
+  Network Load Balancer, or Service Connect
+
     *
   External