https://aws.amazon.com/ecs/ (ECS) now supports mounting Amazon Elastic Block Store (EBS) volumes to containers running as non-root users. With this launch, ECS automatically configures the EBS volume’s file system permissions to allow non-root users to read and write data securely, while preserving the root-level ownership of the volume. This enhancement simplifies security-first container deployments by removing the need for manual permission management or custom entrypoint scripts. This feature enhances container security by allowing tasks to run as non-root users, reducing the risk of privilege escalation and unauthorized access to data. Previously, for a container in a task to write to a mounted Amazon EBS volume, it had to run as the root user. ECS now automatically manages EBS volume permissions, simplifying workflows and ensuring that all containers within a task — regardless of user ID — can securely read and write to the mounted volume. This feature is now available in all https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/ where Amazon ECS and Amazon EBS are supported, for EC2, AWS Fargate, and ECS Managed Instances launch types. To learn more, see https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ebs-volumes.html in the Amazon ECS Developer Guide.

Amazon Elastic Container Services (Amazon ECS) now allows you to run Firelens containers as a non-root user, by specifying a User ID in your Task Definition. Specifying a non-root user with a specific user ID reduces the potential attack footprint by users who may gain access to such software, a security best practice and a compliance requirement by some industries and security services such as the AWS Security Hub. With this release, Amazon ECS allows you to specify a user ID in the "user" field of your Firelens containerDefinition element of your Task Definition, instead of only allowing "user": "0" (root user). The new capability is supported in all AWS Regions. See the documentation for using Firelens for more details on how to set up your Firelens container to run as non-root.

Amazon Elastic Container Service (Amazon ECS) has extended the length of the container exit reason message from 255 to 1024 characters. The enhancement helps you debug more effectively by providing more complete error messages when containers fail. Amazon ECS customers use container exit reason messages to troubleshoot their running or stopped tasks. Error messages can be accessed through the “reason” field in the DescribeTasks API response, which is a short, human-readable string that provides details about a running or stopped container. Previously, error messages beyond 255 characters were truncated. With the increased limit to 1024 characters, customers can now surface and view richer error details, making troubleshooting faster. Customers can access longer container exit reason messages through the AWS Management Console and the DescribeTasks API. This improvement is available in all AWS regions for tasks deployed on Fargate Platform 1.4.0 or container instances with ECS Agent v1.92.0 or later. To learn more, refer to the documentation and release notes.

https://aws.amazon.com/ecs/ (Amazon ECS) announces support for linear and canary deployment strategies, giving you more flexibility and control when deploying containerized applications. These new strategies complement ECS built-in blue/green deployments, enabling you to choose the traffic shifting approach that best matches your application's risk profile and validation requirements. With linear deployments, you can gradually shift traffic from your current service revision to the new revision in equal percentage increments over a specified time period. You configure the step percentage (for example, 10%) to control how much traffic shifts at each increment, and set a step bake time to wait between each traffic shift for monitoring and validation. This allows you to validate your new application version at multiple stages with increasing amounts of production traffic. With canary deployments, you can route a small percentage of production traffic to your new service revision while the majority of traffic remains on the current stable version. You set a canary bake time to monitor the new revision's performance, after which Amazon ECS shifts the remaining traffic to the new revision. Both strategies support a deployment bake time that waits after all production traffic has shifted to the new revision before terminating the old revision, enabling quick rollback without downtime if issues are detected. You can configure deployment lifecycle hooks to perform custom validation steps, and use Amazon CloudWatch alarms to automatically detect failures and trigger rollbacks. The feature is available in all commercial https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/ where Amazon ECS is available. You can use linear and canary deployment strategies for new and existing Amazon ECS services that use Application Load Balancer (ALB) or ECS Service Connect, using the Console, SDK, CLI, CloudFormation, CDK, and Terraform. To learn more, see our documentation on https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-type-linear.html and https://docs.aws.amazon.com/AmazonECS/latest/developerguide/canary-deployment.html.

https://aws.amazon.com/ecs/ (Amazon ECS) has extended the length of the container exit reason message from 255 to 1024 characters. The enhancement helps you debug more effectively by providing more complete error messages when containers fail. Amazon ECS customers use container exit reason messages to troubleshoot their running or stopped tasks. Error messages can be accessed through the “reason” field in the DescribeTasks API response, which is a short, human-readable string that provides details about a running or stopped container. Previously, error messages beyond 255 characters were truncated. With the increased limit to 1024 characters, customers can now surface and view richer error details, making troubleshooting faster. Customers can access longer container exit reason messages through the AWS Management Console and the DescribeTasks API. This improvement is available in all AWS regions for tasks deployed on Fargate Platform 1.4.0 or container instances with ECS Agent v1.92.0 or later. To learn more, refer to the https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeTasks.html and https://github.com/aws/amazon-ecs-agent/releases/tag/v1.92.0.  

AWS for Fluent Bit announces version 3.0.0, based on Fluent Bit version 4.1.0 and Amazon Linux 2023. Container logging using AWS for Fluent Bit is now more performant and more feature-rich for AWS customers, including those using https://aws.amazon.com/ecs/ (Amazon ECS) and https://aws.amazon.com/eks/ (Amazon EKS). AWS for Fluent Bit enables Amazon ECS and Amazon EKS customers to collect, process, and route container logs to destinations including Amazon CloudWatch Logs, Amazon Data Firehose, Amazon Kinesis Data Streams, and Amazon S3 without changing application code. AWS for Fluent Bit 3.0.0 upgrades the Fluent Bit version to 4.1.0, and upgrades the base image to Amazon Linux 2023. These updates deliver access to the latest Fluent Bit features, significant performance improvements, and enhanced security. New features include native OpenTelemetry (OTel) support for ingesting and forwarding OTLP logs, metrics, and traces with AWS SigV4 authentication—eliminating the need for additional sidecars. Performance improvements include faster JSON parsing, processing more logs per vCPU with lower latency. Security enhancements include TLS min version and cipher controls, which enforce your TLS policy on outputs from AWS for Fluent Bit for stronger protocol posture. You can use AWS for Fluent Bit 3.0.0 on both ECS and EKS. On ECS, update the FireLens log-router container image in your task definition to the 3.0.0 tag from the Amazon ECR Public Gallery. On EKS, upgrade by either updating the Helm release or setting the DaemonSet image to the 3.0.0 version. The https://docs.aws.amazon.com/AmazonECS/latest/developerguide/firelens-using-fluentbit.html is available in the https://gallery.ecr.aws/aws-observability/aws-for-fluent-bit and in the Amazon ECR repository. You can also find it on https://github.com/aws/aws-for-fluent-bit for source code and additional guidance.

Amazon ECS Managed Instances is a new compute option that eliminates infrastructure management overhead while giving you access to the broad suite of EC2 capabilities including the flexibility to select...

Amazon Elastic Container Service (Amazon ECS) Service Connect now supports Envoy access logs, providing deeper observability into request-level traffic patterns and service interactions. This new capability captures detailed per-request telemetry for end-to-end tracing, debugging, and compliance monitoring. Amazon ECS Service Connect makes it simple to build secure, resilient service-to-service communication across clusters, VPCs, and AWS accounts. It integrates service discovery and service mesh capabilities by automatically injecting AWS-managed Envoy proxies as sidecars that handle traffic routing, load balancing, and inter-service connectivity. Envoy Access logs capture detailed traffic metadata enabling request-level visibility into service communication patterns. This enables you to perform network diagnostics, troubleshoot issues efficiently, and maintain audit trails for compliance requirements. You can now configure access logs within ECS Service Connect by updating the ServiceConnectConfiguration to enable access logging. Query strings are redacted by default to protect sensitive data. Envoy access logs will output to the standard output (STDOUT) stream alongside application logs and flow through the existing ECS log pipeline without requiring additional infrastructure. This configuration supports all existing application protocols (HTTP, HTTP2, GRPC and TCP). This feature is available in all regions where Amazon ECS Service Connect is supported. To learn more, visit the Amazon ECS Developer Guide.

Amazon Web Services (AWS) has introduced Amazon ECS Optimized Windows AMIs compatible with Windows Server 2025, offering two distinct platforms: 2025-Core and 2025-Full. These AMIs are specifically engineered to support Windows container deployments on Amazon ECS. Each AMI comes ready-to-use with essential components and optimizations tailored for running containerized workloads, streamlining the container deployment process. Windows Server 2025 provides enhanced performance optimization and improved resource utilization compared to previous versions, allowing for more efficient container operations. It features advanced security capabilities, including better isolation between containers to prevent container escape attacks and stronger kernel boundaries between containers and host. Windows Server 2025 also introduces enhanced networking capabilities like network namespace isolation and better integration with the Host Netwroking Service (HNS) that enable faster container communication and reduced latency. Customers can find and launch Windows ECS instances directly from the Amazon EC2 Console or through API or CLI commands. Windows ECS Optimized AMIs can be run with all available https://aws.amazon.com/ecs/pricing/ for windows ECS instances and are enabled across all Public, AWS GovCloud (US) and China Regions of AWS. For more details on getting the best out of AWS EC2 instances running Windows Server 2025 check out the https://aws.amazon.com/windows/?blog-posts-content-windows.sort-by=item.additionalFields.createdDate&blog-posts-content-windows.sort-order=desc page and the guide on https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_windows_AMI.html.

https://aws.amazon.com/ecs/ (Amazon ECS) now supports AWS CloudTrail data events, providing detailed visibility into Amazon ECS Agent API activities. This new capability enables customers to monitor, audit, and troubleshoot container instance operations. With CloudTrail data event support, security and operations teams can now maintain comprehensive audit trails of ECS Agent API activities, detect unusual access patterns, and troubleshoot agent communication issues more effectively. Customers can opt in to receive detailed logging through the new data event resource type AWS::ECS::ContainerInstance for ECS agent activities, including when the ECS agent polls for work (ecs:Poll), starts telemetry sessions (ecs:StartTelemetrySession), and submits https://aws.amazon.com/ecs/managed-instances/ logs (ecs:PutSystemLogEvents). This enhanced visibility enables teams to better understand how container instance roles are utilized, meet compliance requirements for API activity monitoring, and quickly diagnose operational issues related to agent communications. This new feature is available for Amazon ECS on EC2 in all AWS Regions and ECS Managed Instances in https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ManagedInstances.html. Standard CloudTrail data event charges apply. To learn more, visit the https://docs.aws.amazon.com/AmazonECS/latest/developerguide/logging-using-cloudtrail.html.

https://aws.amazon.com/ecs/ (Amazon ECS) today introduced GPU-optimized Amazon Machine Image (AMI) for Amazon Linux 2023 (AL2023). This new offering enables customers to run GPU-accelerated containerized workloads on Amazon ECS while leveraging improved security features and newer kernel version available on AL2023. The new ECS GPU-optimized AMI is built on the minimal AL2023 base AMI and includes NVIDIA drivers, NVIDIA Fabric Manager, NVIDIA Container Toolkit, and other essential packages needed to run GPU-accelerated container workloads. The new AMI supports a wide range of NVIDIA GPU architectures including Ampere, Turing, Volta, Maxwell, Hopper, and Ada Lovelace, and works out-of-the-box with no additional configuration required. The new AMI is designed for GPU-accelerated applications such as machine learning (ML) and artificial intelligence (AI) workloads running on Amazon ECS. The ECS GPU-optimized AL2023 AMI is now available in all AWS regions. For additional information about running GPU-accelerated workloads with Amazon ECS, refer to the https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html and https://github.com/aws/amazon-ecs-ami/releases.  

Amazon Elastic Container Service (Amazon ECS) now allows you to view the service revision and deployment history for your long-running applications deployed as Amazon ECS services. This capability makes it easier for you to track and view changes to applications deployed using Amazon ECS, monitor on-going deployments, and debug deployment failures. Typically, customers deploy long running applications as Amazon ECS services and deploy software updates using a rolling update mechanism where tasks running the old software version are gradually replaced by tasks running the new version. With today’s release, you can now view the deployment history for your Amazon ECS services on the AWS Management Console as well as using the new listServiceDeployments API. You can look at the details of a specific deployment, including whether it succeeded, when it started and completed, and service revision information before and after the deployment using the Console and describeServiceDeployment API. Furthermore, you can look at the immutable configuration for a specific service version, including the task definition, container image digests, load balancer, service connect configuration, etc. using the Console and describeServiceRevision API. You can view the service version and deployment history for their services deployed on or after October 25, 2024 using the AWS Management Console, API, SDK, and CLI in all AWS Regions. To learn more, visit this blog post and documentation.

Today, AWS announces support for predictive scaling for Amazon Elastic Container Service (Amazon ECS). Predictive scaling leverages advanced machine learning algorithms to proactively scale your Amazon ECS services ahead of demand surges, reducing overprovisioning costs while improving application responsiveness and availability. Amazon ECS offers a rich set of service auto scaling options, including target tracking and step scaling policies, that automatically adjust task counts in response to observed load, as well as scheduled scaling to manually define rules to adjust capacity for routine demand patterns. Many applications observe recurring patterns of steep demand changes, such as early morning spikes when business resumes, wherein a reactive scaling policy can be slow to respond. Predictive scaling is a new capability that harnesses advanced machine learning algorithms, pre-trained on millions of data points, to proactively scale out ECS services ahead of anticipated demand surges. You can use predictive scaling alongside your existing auto scaling policies, such as target tracking or step scaling, so that your applications scale based on both real-time and historic patterns. You can also choose a “forecast only” mode to evaluate its accuracy and suitability, before enabling it to “forecast and scale“. Predictive scaling enhances responsiveness and availability for applications with recurring demand patterns, while also reducing the operational effort of manually configuring scaling policies and the costs from overprovisioning. You can use AWS management console, SDK, CLI, CloudFormation, and CDK to configure predictive auto scaling for your ECS services. For a list of supported AWS Regions, see documentation. To learn more, visit this blog post and documentation.

AWS App Runner now supports IPv6-based inbound and outbound traffic on both public and private App Runner service endpoints. This helps customers meet IPv6 compliance requirements, and removes the need for handling address translation between IPv4 and IPv6. App Runner is a fully-managed service that makes it easier for developers to quickly deploy containerized web applications and APIs to the cloud, at scale, and without managing infrastructure. Previously, IPv6 was only supported on incoming traffic through public endpoints. You can configure IPv6 by selecting the dual-stack option in your networking configuration on new or existing services.  AWS App Runner support for IPv6 is available in all AWS Regions where AWS App Runner is available. For more information about how to manage dual-stack support for your App Runner service, see Networking with App Runner in the AWS App Runner Developer Guide.

https://aws.amazon.com/ecs/(Amazon ECS) launches its networking capability called ECS Service Connect in the AWS GovCloud (US-West) and AWS GovCloud (US-East) Regions. Amazon ECS is a fully managed container orchestration service that makes it easier for you to deploy, manage, and scale containerized applications. With ECS Service Connect, customers can easily configure service discovery, connectivity, traffic observability, and encryption for services running in Amazon ECS. This enables more efficient application development by allowing you to focus on writing application code instead of managing complex networking infrastructure To learn more about how to get started with Amazon ECS Service Connect and how it works, see https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-connect.html.

Amazon Elastic Container Service (Amazon ECS) now includes enhancements that improve service availability during rolling deployments. These enhancements help maintain availability when new application version tasks are failing, when current tasks are unexpectedly terminated, or when scale-out is triggered during deployments. Previously, when tasks in your currently running version became unhealthy or were terminated during a rolling deployment, ECS would attempt to replace them with the new version to prioritize deployment progress. If the new version could not launch successfully—such as when new tasks fail health checks or fail to start—these replacements would fail and your service availability could drop. ECS now replaces unhealthy or terminated tasks using the same service revision they belong to. Unhealthy tasks in your currently running version are replaced with healthy tasks from that same version, independent of the new version's status. Additionally, when Application Auto Scaling triggers during a rolling deployment, ECS applies scale-out to both service revisions, ensuring your currently running version can handle increased load even if the new version is failing. These improvements respect your service's maximumPercent and minimumHealthyPercent settings. These enhancements are enabled by default for all services using the rolling deployment strategy and are available in all AWS Regions. To learn more about rolling-update deployments, refer Link.

Amazon VPC Lattice now provides native integration with Amazon ECS, Amazon's fully managed container orchestration service that makes it easy for you to deploy, manage, and scale containerized applications. This launch enables VPC Lattice to offer comprehensive support across all major AWS compute services, including Amazon Elastic Compute Cloud (Amazon EC2), Amazon Elastic Kubernetes Service (Amazon EKS), AWS Lambda, Amazon ECS, and AWS Fargate. VPC Lattice is a managed application networking service that simplifies the process of connecting, securing, and monitoring applications across AWS compute services, allowing developers to focus on building applications that matter to their business while reducing time and resources spent on network setup and maintenance. With native ECS integration, you can now directly associate your ECS services with VPC Lattice target groups, eliminating the need for an intermediate Application Load Balancer (ALB). This streamlined integration reduces cost, operational overhead, and complexity, while enabling you to leverage the complete feature sets of both ECS and VPC Lattice. Organizations with diverse compute infrastructure, such as a mix of Amazon EC2, Amazon EKS, AWS Lambda, and Amazon ECS workloads, can benefit from this launch by unifying service-to-service connectivity, security, and observability across all compute platforms. This new feature is available in all AWS Regions where Amazon VPC Lattice is available. To get started, see the following resources: AWS News Blog: Streamline Container Application Networking with native Amazon ECS support in Amazon VPC Lattice Amazon ECS Developer Guide Amazon VPC Lattice User Guide VPC Lattice related blog posts

Amazon Elastic Container Services (Amazon ECS) now allows you to perform network fault injection experiments on your applications deployed on AWS Fargate. Fault injection experiments create disruptions to test how your applications behave, helping you improve application performance, observability, and resilience. AWS Fault Injection Service (AWS FIS) now supports 6 actions for ECS on both EC2 and Fargate: network latency, network blackhole, network packet loss, CPU stress, I/O stress, and kill process. Developers and operators can now verify the response of their application to potential network errors, some of which may also be required for regulatory compliance. By reproducing network behaviors that may cause applications to fail, you can identify gaps in application configurations, monitoring, alarms, and operational response. Amazon ECS is introducing the ability to opt-in to allow tasks to use a fault injector such as AWS FIS to perform network experiments for increasing network latency, increasing packet loss, and blackhole port testing (dropping inbound or outbound traffic) to test how your applications perform, in addition to existing resource stress experiments. The new experience is now automatically enabled in all AWS Regions and integration with the AWS Fault Injection Service in those regions where AWS FIS is available. For more details, go to Amazon ECS fault Injection documentation and the AWS FIS user guide.

Today, AWS announces the launch of Amazon Elastic Container Service (Amazon ECS) Managed Instances, a new fully managed compute option designed to eliminate infrastructure management overhead while giving you access to the full capabilities of Amazon EC2. By offloading infrastructure operations to AWS, ECS Managed Instances helps you quickly launch and scale your workloads, while enhancing performance and reducing your total cost of ownership. With ECS Managed Instances, you get the application performance you want and the simplicity you need. Simply define your task requirements such as the number of vCPUs, memory size, and CPU architecture, and Amazon ECS automatically provisions, configures and operates most optimal EC2 instances within your AWS account using AWS-controlled access. You can also specify desired instance types in Managed Instances Capacity Provider configuration, including GPU-accelerated, network-optimized, and burstable performance, to run your workloads on the instance families you prefer. ECS Managed Instances dynamically scales EC2 instances to match your workload requirements and continuously optimizes task placement to reduce infrastructure costs. It also enhances your security posture through regular security patching initiated every 14 days. You can use EC2 event windows to schedule patching to occur within weekly maintenance windows, minimizing the risk of interruptions during critical hours. ECS Managed Instances is now available in six AWS regions: US East (North Virginia), US West (Oregon), Europe (Dublin), Africa (Cape Town), Asia Pacific (Singapore), and Asia Pacific (Tokyo). To get started with ECS Managed Instances, use the AWS Console, Amazon ECS MCP Server, or your favorite infrastructure-as-code tooling to enable it in a new or existing Amazon ECS cluster. You will be charged for the management of compute provisioned, in addition to your regular Amazon EC2 costs. To learn more about ECS Managed Instances, visit the feature page, documentation, and AWS News launch blog.

https://aws.amazon.com/ecs/ (Amazon ECS) now makes it easier to troubleshoot unhealthy tasks by adding the Task ID in service action events generated due to health failures. Amazon ECS is designed to help easily launch and scale your applications. When your Amazon ECS task fails Elastic Load Balancing (ELB) health checks, Amazon ECS produces an unhealthy service action event. With today’s launch, the Task ID is also included as part of the generated event, so you can quickly pinpoint the Task in question for faster troubleshooting. The new experience is now automatically enabled in all https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/ See more details regarding https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-unhealthy-event-messages.html and how to set up Amazon EventBridge rules to capture https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_service_events.html.  

Amazon ECS Service Connect now supports seamless communication between services residing in different AWS accounts through integration with AWS Resource Access Manager (AWS RAM). This enhancement simplifies resource sharing, reduces duplication, and promotes consistent service-to-service communication across environments for organizations with multi-account architectures. Amazon ECS Service Connect leverages AWS Cloud Map namespaces for storing information about ECS services and tasks. To enable seamless cross-account communication between Amazon ECS Service Connect services, you can now share the underlying AWS Cloud Map namespaces using AWS RAM with individual AWS accounts, specific Organizational Units (OUs), or your entire AWS Organization. To get started, create a resource share in AWS RAM, add the namespaces you want to share, and specify the principals (accounts, OUs, or the organization) that should have access. This enables platform engineers to use the same namespace to register Amazon ECS Service Connect services residing in multiple AWS accounts, simplifying service discovery and connectivity. Application developers can then build services that rely on a consistent, shared registry without worrying about availability or synchronization across accounts. Cross-account connectivity support improves operational efficiency and makes it easier to scale Amazon ECS workloads as your organization grows by reducing duplication and streamlining access to common services. This feature is available with both Fargate and EC2 launch modes in AWS GovCloud (US-West) and AWS GovCloud (US-East) regions via the AWS Management Console, API, SDK, CLI, and CloudFormation. To learn more, please refer to the Amazon ECS Service Connect documentation.

http://aws.amazon.com/ecsnow allows you to configure software version consistency for specific containers within your Amazon ECS services. By default, Amazon ECS resolves container image tags to the image digest (SHA256 hash of the image manifest) when you create a new Amazon ECS service or deploy an update to the service. This enforces that all tasks in the service are identical and launched with this image digest(s). However, for certain containers within the task (e.g. telemetry sidecars provided by a 3rd party) customers may prefer to not enforce consistency and intead use a mutable container image tag (e.g. LATEST). Now, you can disable software version consistency for one or more containers in your ECS service by configuring the new versionConsistency attribute in the container definition. ECS applies changes to version consistency when you redeploy your ECS service with the task definition revision. You can disable software version consistency for your Amazon ECS services running on AWS Fargate platform version 1.4.0 or higher and/or version v1.70.0 or higher of the Amazon ECS Agent in all commercial and the AWS GovCloud (US) Regions. To learn more, please visit our https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-type-ecs.html#deployment-container-image-stability.  

Today, AWS announces the launch of Amazon Elastic Container Service (Amazon ECS) Managed Instances, a new fully managed compute option designed to eliminate infrastructure management overhead while giving you access to the full capabilities of Amazon EC2. By offloading infrastructure operations to AWS, ECS Managed Instances helps you quickly launch and scale your workloads, while enhancing performance and reducing your total cost of ownership. With ECS Managed Instances, you get the application performance you want and the simplicity you need. Simply define your task requirements such as the number of vCPUs, memory size, and CPU architecture, and Amazon ECS automatically provisions, configures and operates most optimal EC2 instances within your AWS account using AWS-controlled access. You can also specify desired instance types in Managed Instances Capacity Provider configuration, including GPU-accelerated, network-optimized, and burstable performance, to run your workloads on the instance families you prefer. ECS Managed Instances dynamically scales EC2 instances to match your workload requirements and continuously optimizes task placement to reduce infrastructure costs. It also enhances your security posture through regular security patching initiated every 14 days. You can use EC2 event windows to schedule patching to occur within weekly maintenance windows, minimizing the risk of interruptions during critical hours. ECS Managed Instances is now available in six AWS regions: US East (North Virginia), US West (Oregon), Europe (Dublin), Africa (Cape Town), Asia Pacific (Singapore), and Asia Pacific (Tokyo). To get started with ECS Managed Instances, use the AWS Console, Amazon ECS MCP Server, or your favorite infrastructure-as-code tooling to enable it in a new or existing Amazon ECS cluster. You will be charged for the management of compute provisioned, in addition to your regular Amazon EC2 costs. To learn more about ECS Managed Instances, visit the https://aws.amazon.com/ecs/managed-instances/, https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ManagedInstances.html, and https://aws.amazon.com/blogs/aws/announcing-amazon-ecs-managed-instances-for-containerized-applications.