Is this project in maintenance mode?

[jgrant-sms]

There was an AWS blog post stating that this project was going in to maintenance mode.
https://aws.amazon.com/blogs/developer/announcing-end-of-support-for-aws-copilot-cli-effective-february-3-2025/ (link does not work because the post was deleted)

There was also an approved PR that updated the README.md to confirm this.
#5974

The README.md file had the maintenance mode disclaimer removed a few hours later.
#5975

Is this project in maintenance mode? Are there plans for it to go in to maintenance mode.

Please do not announce something is in maintenance mode then just delete all of those announcements without any explanation.

[craigjbass]

Really bad move if true. Using ECS directly via IaC tools is much more work for teams.

You'd think the connection between "easier way to deploy applications to AWS cloud resources" and "revenue" would be an easy one to make.

[PedroAlvarado]

See the previous discussion: #5925 (comment)

Safe to say that copilot is in maintenance mode. Safer to stay away from it.

[ShanikaEdiriweera]

Has been a great tool for us. How can we express the our unhappiness with the decision as customers/partners?

[bkaws]

As pointed out under a similar discussion: "We are not actively developing any new features for Copilot but we still do maintenance work." We are working on broader messaging that will be shared across all available channels in the coming months.

[xinye2005]

Appreciate the great work the team has been doing! Just disappointed that AWS doesn't want to invest resources in this any more which is short-sighted for the ECS service.

[cristobalmackenzie]

Any update on this broader messaging? We're running several production workloads on AWS Fargate using copilot and will sadly have to look for alternatives.

[jgrant-sms]

🦗

[jgrant-sms]

I work in AWS every day and have used most of the popular infrastructure as code tools. A suitable replacement for copilot really depends on your use case and team experience.

The lack of updates or clarity from AWS on this does not inspire confidence that they would be able to resolve a regression or security incident in this project within a timely manner. I don't even know if the team that worked on this application is even still at AWS.

I am actively migrating projects away from copilot before I am forced to with a tight deadline due to a bug/error/security issue. Here are the two ecosystems I am moving to for various projects.

Alternatives

SST/Pulumi

For projects that utilized copilot as a way for development teams to manage their own infrastructure I am switching to SST. This allows them to define their infrastructure in a general purpose programming language they are already familiar with (TypeScript) and has a broad range of resources available.

The learning curve is not very steep, as soon as you start using CloudFormation addons in copilot I would say you are having a worse time than learning and using SST/Pulumi.

Terraform/OpenTofu

I use this more often when separate teams are managing infrastructure and application development. This utilizes a simple domain specific language that is easy to pick up. Complexity typically comes from creating generic module libraries to serve multiple teams. If you are building a platform for multiple application teams you might want to start exploring Terraform before SST.

There are so many variables and I do not know anyones specific context reading this so look at both and other tools before making a decision.

Pipelines

I have never been a fan of the pipeline deployed by Copilot, if you are currently using it you will likely be better off building a new deployment pipeline with your new IaC tool.

A common pattern I have been using is GitHub Actions workflow with an OIDC Provider setup so I can deploy to my AWS environments or using CodeBuild as managed GitHub Action runners with appropriate permissions inside of their AWS accounts.

[ShanikaEdiriweera]

Why don't you see AWS CDK as an alternative?
What's SST/Pulumi doing better than CDK?

[jgrant-sms]

CDK is certainly an alternative. I mentioned the two ecosystems that I am moving projects to.

The first difference to me is the ability to work with other providers. I have heard of, but never used CDKTF, which appears to solve that problem, but I do not know anyone who uses it.

I prefer to stay away from Cloudformation, ultimately CDK is always going to transpile to Cloudformation and deploy with the AWS Cloudformation service. Pulumi is interacting with the AWS APIs directly, it is much faster. I am not saying Cloudformation/CDK does any magic, but Pulumi feels more natural. I have a CLI making API calls to a service, I can view the log of those API calls.