Containers

Announcing the end-of-support for the AWS Copilot CLI

We are announcing that AWS Copilot CLI will reach end of support on June 12, 2026. Copilot simplified building, releasing, and operating production-ready containerized applications on Amazon Elastic Container Service (ECS) or AWS App Runner by providing a command-line interface (CLI) tool. While AWS Copilot CLI will continue to be available as an open-source project on GitHub, it will no longer receive new features or security updates from AWS.

Over time AWS has evolved its container deployment offerings to provide newer alternatives. This post describes how to migrate your existing Copilot applications to Amazon ECS Express Mode or AWS Cloud Development Kit (CDK) Layer 3 (L3) constructs through practical examples. If you currently use AWS Copilot CLI for container deployments, the information provided in this post can be used as guidance to plan your migration strategy. The concepts outlined here apply to both simple web applications and complex multi-service architectures.

Understanding AWS Copilot CLI

AWS Copilot CLI provides a simplified workflow for deploying containerized applications. A typical Copilot deployment involves initializing an application, creating a service, and deploying to environments using a declarative manifest file. Each environment contains a set of resources shared between all the deployed services.

Copilot Service Types Overview

Copilot supports six distinct service patterns; each designed for specific workload types:

  1. Load Balanced Web Service – Internet-facing applications with an Application Load Balancer, running on ECS Fargate with automatic scaling and health checks.
  2. Request-Driven Web Service – Serverless web applications running on AWS App Runner with automatic scaling based on incoming HTTP requests.
  3. Backend Service – Internal services running within your VPC without public endpoints, accessible only by other services through service discovery.
  4. Worker Service – Asynchronous message processors that consume from Amazon SQS queues and scale based on queue depth.
  5. Scheduled Job – Containerized tasks that run on a schedule using cron expressions for batch processing or maintenance operations.
  6. Static Site – Static website hosting with a dedicated CloudFront distribution and S3 bucket for global content delivery.

Copilot also helps setting up scheduled jobs and release pipelines that deploy your services whenever you push to your git repositories.

  • Job – Scheduled jobs containerized as ECS Tasks, which can be triggered either on a fixed schedule or periodically by providing a rate.
  • Pipeline – AWS CodePipeline based deployment pipelines that automatically build your code when you push to a git repository like AWS CodeCommit.

Application initialization

Copilot applications were initialized and services created using CLI commands. The following example shows two common service types:

The command below creates a Copilot application and initializes a service running on ECS Fargate. It creates resources such as VPC, Subnets and Security Groups, the ECS Cluster, and the load balancer. If you deploy two load-balanced web services to a shared environment, both services will share the same network and cluster:

# Initialize the application and create a load-balanced web service

copilot init \ 
--app my-app \ 
--name loadbalanced-svc \ 
--type "Load Balanced Web Service" \ 
--dockerfile ./Dockerfile \ 
--port 80

The following command creates a Request-Driven Web Service in the same app, which creates an App Runner service that autoscales based on incoming traffic. App Runner services are not connected by default to a VPC. However egress traffic can be routed through a VPC by configuring the network field in the manifest generated for the service:

# Create a Request-driven web service in the same app

copilot svc init \ 
--name request-driven-svc \ 
--app my-app \ 
--svc-type "Request-Driven Web Service" \ 
--ingress-type "Internet" \ 
--dockerfile "./Dockerfile"

Service configuration – Copilot generates a manifest.yml file that defines service properties. Below you can see the manifest files generated by Copilot for our example Load Balanced Web Service and Request-Driven Web Service respectively:

name: loadbalanced-svc
type: Load Balanced Web Service

image:
  build: Dockerfile
  port: 80

cpu: 256
memory: 512
count: 1

http:
  path: '/'

variables:
  LOG_LEVEL: info

name: request-driven-svc
type: Request-Driven Web Service

image:
  build: Dockerfile
  port: 80

cpu: 256
memory: 512

Copilot uses AWS CloudFormation to create stacks that correspond to the app (representing the ECS cluster with networking information) and for each service (which may be deployed on Fargate or App Runner).

While Copilot provided simplicity, it had limitations in infrastructure visibility and required learning a dedicated CLI tool with custom manifest syntax. Customization beyond the built-in patterns often required additional CloudFormation based enhancements, and troubleshooting required understanding both Copilot abstractions and the underlying AWS resources it created.

Choosing your migration approach

The migration approaches described below address these limitations while maintaining deployment simplicity. While we use the term migration here, you will notice that it is about providing options to continue deploying and managing your applications without depending on Copilot. The approaches proposed here require least overhead and are closest to the experience ECS Copilot offered.

Adopting Copilot resources: Since Copilot generates standard CloudFormation templates and stacks, they can be adopted and managed by your teams. You can continue to use the generated CloudFormation templates to update your application stacks. Further, you also have the option to continue using Copilot CLI in its current state, without AWS support.

Amazon ECS Express Mode: This option is recommended for teams that want the fastest path from container to production. If you are are building web applications or APIs with standard requirements, you can use ECS Express Mode’s simplified and opinionated approach, allowing AWS to handle infrastructure decisions automatically with sensible defaults.

AWS CDK: This option is preferable for teams who need fine-grained control over infrastructure. CDK is useful when you are building complex multi-service architectures and want infrastructure-as-code in familiar programming languages. It also helps you integrate with existing CDK stacks and achieve specific compliance and security requirements.

Solution Overview

In this post we demonstrate migrating the two services we created using Copilot with newer deployment mechanisms. The solution shows two migration paths available through Amazon ECS Express Mode and AWS CDK. Both provide similar functionality to Copilot, while offering improved integration within your AWS environment and enhanced operational visibility.

Migration path 1: Amazon ECS Express Mode

Let’s first see how we can create a typical containerized web application that includes an Application Load Balancer, auto-scaling policies and Amazon CloudWatch logging using Amazon ECS Express Mode. Express Mode simplifies container application deployment by automating the configuration of supporting AWS services. Express Mode requires only a container image, task execution role, and infrastructure role to deploy production-ready applications.

Express Mode provides additional advantages including automatic HTTPS/TLS termination at the AWS Application Load Balancer with AWS-provided SSL certificates using AWS Certificate Manager (ACM), eliminating the need for manual certificate management. Express Mode also integrates seamlessly with Infrastructure as Code tools like CloudFormation, CDK, and Terraform, providing familiar deployment patterns for teams already using these tools. This eliminates the need to learn a custom manifest format.

Copilot is cost optimized through shared Application Load Balancers, allowing up to 25 services per load balancer. It also provides production-ready defaults with HTTPS and auto-scaling, full transparency of all AWS resources, and availability in all AWS Regions with no additional charges.

Console deployment – You can create an Express Mode service through the Amazon ECS console by navigating to Express Mode, clicking Create, and providing your container image URI from Amazon Elastic Container Registry (ECR). You also need specify your task execution role and infrastructure role. If you don’t already have these roles, you can use the Create new role in the drop down to have one created for you using AWS Identity and Access Management (IAM) managed policy. Express Mode automatically provisions an ECS cluster, task definition, Application Load Balancer, auto-scaling policies, and provides a unique HTTPS URL.

Programmatic deployment – You can use the AWS CLI to create Express Mode services. Running the following command with the “- -monitor-resources” flag presents a visual representation of your service and the associated resources being provisioned in your AWS account:

# Create an Express Mode service
aws ecs create-express-gateway-service \
    --execution-role-arn "arn:aws:iam::012345678901:role/ecsTaskExecutionRole" \
    --infrastructure-role-arn "arn:aws:iam::012345678901:role/ecsInfrastructureRoleForExpressServices" \
    --primary-container '{
        "image": "012345678901.dkr.ecr.us-east-1.amazonaws.com/my-app/loadbalanced-svc",
        "containerPort": 80,
        "environment": [
            {"name": "ENV", "value": "production"},
            {"name": "DEBUG", "value": "false"}
        ]
    }' \
   --monitor-resources

Although ECS Express Mode makes use of several sensible defaults to get you up and running quickly, you can optionally specify additional parameters like cluster name, custom log group name, custom log stream prefix, etc.

Migration path 2: AWS CDK constructs

AWS CDK constructs provide infrastructure-as-code (IaC) capabilities with high-level abstractions that simplify complex deployments. This can be used to migrate both ECS Fargate services you have created with Copilot. CDK constructs provide several advantages including type-safe infrastructure definitions, full customization of AWS service properties, reusable patterns that can be shared across teams, multi-language support (Python, TypeScript, Java, C#, Go), testing capabilities for infrastructure code, and version control integration with application code.

For Copilot’s Request-Driven Web Service pattern, we use ECS Express Mode again. This time we will use the CfnExpressGatewayService CDK L1 construct to create the ECS Express Mode Service. We set up scaling based on request count per target, which allows you to scale based on incoming traffic, the same way Copilot Request-Driven Web Services could. You can configure the actual values for scaling based on the needs of your application.

from aws_cdk import (
    Stack,
    CfnOutput,
    aws_ecs as ecs,
)
from constructs import Construct
class EcsExpressStack(Stack):
    def __init__(self, scope: Construct, construct_id: str, **kwargs) -> None:
        super().__init__(scope, construct_id, **kwargs)
        # Use the managed execution role ARN
        execution_role_arn = f"arn:aws:iam::{self.account}:role/ecsTaskExecutionRole"
        
        # Use the managed infrastructure role ARN
        infrastructure_role_arn = f"arn:aws:iam::{self.account}:role/ecsInfrastructureRoleForExpressServices"
        # Create Express Gateway Service (ECS Express Mode)
        # Uses "default" cluster, auto-generated service name, and default VPC network configuration
        express_service = ecs.CfnExpressGatewayService(
            self, "ExpressGatewayService",
            execution_role_arn=execution_role_arn,
            infrastructure_role_arn=infrastructure_role_arn,
            primary_container=ecs.CfnExpressGatewayService.ExpressGatewayContainerProperty(
                image=f"{self.account}.dkr.ecr.{self.region}.amazonaws.com/my-app/request-driven-svc:latest"
            ),
            cpu="1024",
            memory="2048",
            scaling_target=ecs.CfnExpressGatewayService.ExpressGatewayScalingTargetProperty(
                min_task_count=1,
                max_task_count=10,
                auto_scaling_metric="REQUEST_COUNT_PER_TARGET",
                auto_scaling_target_value=1000
            )
        )
        # Outputs
        CfnOutput(
            self, "ServiceArn",
            value=express_service.attr_service_arn,
            description="Service ARN"
        )
        CfnOutput(
            self, "ServiceEndpoint",
            value=express_service.attr_endpoint,
            description="Service Endpoint URL"
        )
        CfnOutput(
            self, "LoadBalancerArn",
            value=express_service.attr_ecs_managed_resource_arns_ingress_path_load_balancer_arn,
            description="Managed Load Balancer ARN"
        )

Copilot’s Load Balanced Service pattern can also use CfnExpressGatewayService CDK construct. We are demonstrating an alternate approach that may be suitable for scenarios which require advanced configuration. The following example shows how to recreate Copilot functionality using CDK L3 constructs in Python. The ApplicationLoadBalancedFargateService construct represents a Load Balanced Web Service on ECS Fargate service, like Copilot provided, but with full customization capabilities and type-safe infrastructure definitions:

from aws_cdk import (
    Stack,
    Duration,
    CfnOutput,
    aws_ec2 as ec2,
    aws_ecs as ecs,
    aws_ecs_patterns as ecs_patterns,
    aws_logs as logs,
    aws_iam as iam,
)
from constructs import Construct
class MyAppStack(Stack):
    def __init__(self, scope: Construct, construct_id: str, **kwargs) -> None:
        super().__init__(scope, construct_id, **kwargs)
        # Create VPC with public and private subnets
        vpc = ec2.Vpc(
            self, "MyAppVpc",
            max_azs=2,
            nat_gateways=1
        )
        # Create ECS Cluster
        cluster = ecs.Cluster(
            self, "MyAppCluster",
            vpc=vpc,
            cluster_name="my-app-cluster",
            container_insights=True
        )
        # Create the load-balanced Fargate service
        load_balanced_service = ecs_patterns.ApplicationLoadBalancedFargateService(
            self, "MyAppLoadBalancedService",
            cluster=cluster,
            service_name="my-app-loadbalanced-svc",
            cpu=256,
            memory_limit_mib=512,
            desired_count=2,
            task_image_options=ecs_patterns.ApplicationLoadBalancedTaskImageOptions(
                image=ecs.ContainerImage.from_registry(
                    "01234567890.dkr.ecr.us-east-1.amazonaws.com/my-app/loadbalanced-svc:latest"
                ),
                container_port=80,
                environment={
                    "LOG_LEVEL": "info"
                },
                log_driver=ecs.LogDrivers.aws_logs(
                    stream_prefix="my-app",
                    log_retention=logs.RetentionDays.ONE_WEEK
                )
            ),
            public_load_balancer=True,
            listener_port=80
        )
        # Add ECR permissions to task execution role
        load_balanced_service.task_definition.execution_role.add_to_policy(
            iam.PolicyStatement(
                effect=iam.Effect.ALLOW,
                actions=[
                    "ecr:GetAuthorizationToken",
                    "ecr:BatchGetImage",
                    "ecr:GetDownloadUrlForLayer"
                ],
                resources=["*"]
            )
        )
        # Configure health check
        load_balanced_service.target_group.configure_health_check(
            path="/",
            interval=Duration.seconds(15),
            healthy_threshold_count=3,
            unhealthy_threshold_count=2,
            timeout=Duration.seconds(5)
        )
        # Configure auto-scaling
        scaling = load_balanced_service.service.auto_scale_task_count(
            min_capacity=2,
            max_capacity=10
        )
        scaling.scale_on_cpu_utilization(
            "CpuScaling",
            target_utilization_percent=70,
            scale_in_cooldown=Duration.seconds(60),
            scale_out_cooldown=Duration.seconds(60)
        )
        # Output the load balancer URL
        CfnOutput(
            self, "LoadBalancerURL",
            value=f"http://{load_balanced_service.load_balancer.load_balancer_dns_name}",
            description="URL of the load balancer"
        )
        # Output the service name
        CfnOutput(
            self, "ServiceName",
            value=load_balanced_service.service.service_name,
            description="Name of the ECS service"
        )

Planning your migration

The migration from AWS Copilot CLI can be accomplished systematically by following these steps:

  • Inventory existing applications – Use Copilot CLI commands to list all applications and services, then export service configurations for reference during migration.
# List all Copilot applications
copilot app ls

# For each app, list services
copilot svc ls --app <app-name>

# Export service configuration
copilot svc show --app <app-name> --name <service-name> --json > service-config.json
  • Prepare container images – Ensure your container images are available in your container registry for use with selected migration approach.
  • Pick your migration approach – As we have described in this blog post, ECS Express Mode and CDK very closely mirror the Copilot experience. Adopting Copilot CLI without AWS support or adopting Copilot generated CloudFormation templates and stacks is an option applicable to all Copilot applications. Similarly, you can also choose to build your own custom CloudFormation templates, Terraform modules or create the application with another IaC solution.
  • Deploy using chosen approach – Following is a rundown of recommended options for the different Copilot constructs:
    • Load Balanced Web Service – You can decide between Fargate ECS Service with CDK or an ECS Express Mode Service.
    • Request-Driven Web Service – Fargate ECS Service or an ECS Express Mode Service with autoscaling configured based on requests per target.
    • Static Site – AWS CDK CloudFront constructs with S3 origin configuration or AWS Amplify Hosting for simplified deployment with built-in CI/CD pipelines.
    • Worker Service – AWS CDK QueueProcessingFargateService construct, which provides built-in integration between SQS and ECS with automatic scaling. You can also use CDK to create Standard ECS Service with custom CloudWatch alarms and auto-scaling policies targeting SQS metrics
    • Backend Service – AWS CDK L3 constructs using ApplicationLoadBalancedFargateService with internal load balancer configuration. You can also use CDK to configure your ECS Services with ECS Service Connect for service discovery across multiple services.
    • Job – Amazon EventBridge Scheduler with ECS RunTask, or AWS CDK ScheduledFargateTask construct. You can consider using CDK to configure AWS Batch for complex job orchestration with dependencies and retry logic.
    • Pipeline – AWS CDK Pipeline constructs for infrastructure-as-code approach with programmatic stage definitions, approval workflows, and deployment strategies.
  • Validate functionality – Test application functionality, auto-scaling behavior, health checks, CloudWatch logs and metrics, and SSL/TLS certificates to ensure feature parity with your Copilot deployment.
  • Update CI/CD pipelines – Replace any Copilot commands in your deployment pipelines with AWS CLI commands for Express Mode or CDK deploy commands for infrastructure-as-code approaches.
  • Decommission Copilot resources – After validating the new deployment, use Copilot CLI to delete services, environments, and applications to avoid any duplicate resource charges.

Conclusion

This post outlined the recommended approaches for migrating from AWS Copilot CLI to modern AWS container deployment solutions. Amazon ECS Express Mode provides the simplicity and ease-of-use that made Copilot popular, while offering better cost optimization, operational visibility, and integration with the broader AWS ecosystem. AWS CDK L3 constructs enable infrastructure-as-code approaches with type-safe definitions and full customization capabilities.

The migration approaches described in this post ensure that teams can continue to deploy containerized applications efficiently on Amazon ECS, while taking advantage of the latest AWS capabilities and recommendations.

Further reading

About the authors

Sushanth Mangalore is a Solutions Architect at Amazon Web Services, based in Chicago, IL. He is a technologist helping organizations build solutions on AWS to achieve their key business objectives. He is passionate about software architecture and advocates modern technologies like containers and serverless. Sushanth is a speaker at AWS events like re:Invent and summits, and enjoys writing technical content. Prior to AWS, Sushanth spent several years as a developer and architect for large enterprises, building solutions across many technologies and business domains.

Bhupendra Washishtha is a Senior Product Manager – Technical, External Services at AWS, focusing on Serverless Compute within the Amazon Elastic Container Service. Since joining AWS in July 2025, he has worked on product strategy and customer experience for ECS’s container and serverless offerings, focusing on DevEx and Storage. When not diving deep into product enhancements, you can find him on the badminton court or debating the finer points of Harry Potter and Marvel Comics’ theories with anyone willing to engage!