Amazon ECS introduces Early Success Criteria for service deployments - devamazonaws.blogspot.com

Amazon Elastic Container Service (Amazon ECS) now supports Early Success Criteria for rolling service deployments, giving you the flexibility to define when a deployment is considered successful based on your confidence level and the operational needs of your workload. This can help you complete deployments sooner and unblock subsequent deployments, CI/CD pipelines, and other dependent operations.

With Early Success Criteria, you configure the healthy percent - the proportion of desired tasks that must be running and healthy on the target service revision before the deployment is marked successful. For example, with a desired count of 100 and a healthy percent of 90%, Amazon ECS marks the deployment successful after 90 tasks are healthy and continues launching the remaining tasks through regular service scaling, outside the deployment lifecycle. This can benefit workloads running on specialized or constrained capacity, such as GPU-accelerated inference workloads, where hardware availability can extend task launch times. Early Success Criteria also gives you more control over how long deployment rollback monitoring applies, allowing it to protect the deployment until your configured success criteria are met while subsequent scale-out continues through regular service scaling. You can also choose how Amazon ECS handles source service revision cleanup using BLOCKING or DEFERRED. With BLOCKING, Amazon ECS completes source revision cleanup before declaring success. With DEFERRED, Amazon ECS declares success when the criteria are met and drains source revision tasks asynchronously outside the deployment. This benefits services with active long-lived connections or task scale-in protection, where source revision tasks may need to remain running without holding the deployment open.

The feature is available with the rolling deployment strategy in all AWS Commercial and AWS GovCloud (US) Regions. You can configure Early Success Criteria for new and existing Amazon ECS services using the AWS Management Console, AWS CLI, AWS SDKs, and infrastructure as code (IaC) tools. To learn more, see our documentation.

Post Updated on September 4, 2026 at 06:00PM

Comments

Post a Comment

Popular posts from this blog

[MS] Boosting Azure DevOps Security with GHAS Code Scanning - devamazonaws.blogspot.com

Image
Debjyoti Ganguly shares insights on the security benefits and configuration of GHAS Code Scanning with Azure DevOps. Boosting Azure DevOps Security with GHAS Code Scanning Code scanning, a pipeline-based tool available in GitHub Advanced Security, is designed to detect code vulnerabilities and bugs within the source code of ADO (Azure DevOps) repositories. Utilizing CodeQL as a static analysis tool, it performs query analysis and variant analysis. When vulnerabilities are found, it generates security alerts. CodeQL CodeQL is a powerful static analysis tool used for showing vulnerabilities and bugs in source code. It enables developers to write custom queries that analyze codebases, searching for specific patterns and potential security issues. By converting code into a database format, CodeQL allows for sophisticated, database-like queries to detect flaws. CodeQL in Action 1. Preparing the Code Create a CodeQL Database : Extract and structure the code into a database for analy...
Read more

[MS] Pulling a single item from a C++ parameter pack by its index, remarks - devamazonaws.blogspot.com

In my earlier discussion of pulling a single item from a C++ parameter pack by its index , I noted that with the Pack Indexing proposal, you would be able to write this to pull an item from a parameter pack while preserving its reference category. template<int index, typename...Args> void example(Args&&... args) { auto&& arg = (Args...[index]&&)args...[index]; using Arg = Args...[index]&&; } Why did I need to apply the (Args...[index]&&) cast ? Why can't I just write this: auto&& arg = args...[index]; or possibly decltype(auto) arg = args...[index]; Well, when you write the name of a variable, the result is an lvalue reference, even if the variable is an rvalue reference . Watch: struct S { S(S&); // construct from lvalue S(S&&); // construct from rvalue }; void whathappens(S&& s) { S t = s; // which will it use? } Try it out in your favorite compiler. This code construc...
Read more

[MS] GitHub Copilot upgrade assistant for Java技术预览发布 - devamazonaws.blogspot.com

随着人工智能和大型语言模型（LLMs）的不断发展，Agent(“智能代理”)和智能代理化工作流程正在迅速成为AI领域的下一个前沿。这些自主系统带来了巨大的好处，它们可以创建计划、执行单个任务、使用外部工具、与用户互动，甚至自行修复错误。 凭借这些功能，代理化工作流程可以解决一些企业客户在开发周期中经常遇到的复杂、关键任务，甚至是一些极其繁琐的任务。对于使用Java的企业客户来说，升级JDK、框架、依赖项等一直是一个挑战。这些挑战覆盖的范围相当地广，开发者可能会需要经常面对重复且繁琐的场景，例如API签名发生变化等等。我们见过一些企业在将代码库从Java 8升级到Java 17时，花费了几天甚至几周的时间，这是一项巨大的资源和人力投入。 今天，我们很高兴宣布 GitHub Copilot upgrade assistant Java的技术预览版 。这是一个基于AI的解决方案，它使用智能代理化工作流程和多代理框架帮助您更新Java应用程序。通过安装 Visual Studio Code 插件，您可以从本地Java项目开始，GitHub Copilot将自动处理大部分升级过程。以下是该产品的一些关键功能。 创建一个智能的计划 GitHub Copilot upgrade assistant for Java 会分析您当前的项目，并提示用户输入JDK和Maven路径、分支名称等参数。点击“Start(开始)”后，工具将进一步评估该项目的依赖项，例如Spring Boot和JUnit等框架。您还可以选择生成一个GitHub Issue，记录升级过程中的任务。 您可以在执行计划前，审核即将执行的任务。以下是一个演示。 [video width="1920" height="1080" mp4="https://devblogs.microsoft.com/java/wp-content/uploads/sites/51/2024/10/plan.mp4"][/video] 可视化每一步操作 当升级开始后，工具的信息面板(Dashboard)将成为主要信息中心，您可以在此查看每个任务的实时详情，包括运行 OpenRewrite 工具的命令、查看选择的配方、审查修改的文件和错误详情、每个步骤日志等。您还可以深入探索每个...
Read more