从 AWS App Runner 迁移到 Amazon ECS Express Mode

来源: AWS 容器

原文

After careful consideration, we have made the decision to stop accepting new customers for AWS App Runner, effective April 1, 2026. Existing AWS App Runner customers can continue to use the service as normal, including creating new resources and services. AWS continues to invest in security and availability for AWS App Runner, but we do not plan to introduce new features. We recommend customers learn about and explore Amazon ECS Express Mode, which preserves App Runner’s simplicity while providing access to the complete Amazon ECS feature set.

At re:Invent 2025, AWS introduced Amazon Elastic Container Service (Amazon ECS) Express Mode, a new capability that empowers developers to rapidly launch containerized applications, with the ability to utilize the full power of ECS if required. Amazon ECS Express Mode is a simplified deployment capability that allows you to launch production-ready containerized applications on Amazon ECS with a single API. It abstracts the complex manual setup of infrastructure by automatically provisioning a complete application stack aligned to AWS best practices. If you need to deploy containerized applications quickly without managing infrastructure components like load balancers, networking, or scaling policies, while still retaining the flexibility to access underlying resources when your requirements evolve, ECS Express Mode is the solution.

In this post, I’ll show you how to migrate your containerized applications from AWS App Runner to Amazon ECS Express Mode using a blue/green deployment strategy. This approach helps to eliminate downtime during the migration, allowing you to shift traffic gradually and roll back if needed. You’ll learn how to set up ECS Express Mode and configure custom domain.

What ECS Express Mode brings to your application environment

ECS Express Mode preserves App Runner’s ease of use while providing access to advanced ECS features. Here’s what this means for your deployment strategy:

  1. Simplicity: ECS Express Mode delivers the same streamlined deployment experience you’re familiar with. Just provide your container image and two IAM roles, and AWS automatically provisions your complete infrastructure (ECS cluster, Application Load Balancer (ALB), auto-scaling, and public URL) with a single command. Your applications run on the same proven AWS Fargate serverless compute that powers thousands of production workloads.
  2. Infrastructure visibility & control: Unlike App Runner, ECS Express Mode creates all resources directly in your AWS account. This means you have full visibility and control; you can access the ECS console, modify task definitions, adjust networking configurations, or integrate with your existing Infrastructure as Code (IaC) tools whenever your requirements evolve.
  3. Advanced deployment strategies: ECS Express Mode takes advantage of Amazon ECS’s native canary deployment strategy by default, enabling you to safely roll out changes by gradually shifting traffic to new versions. This production-grade deployment strategy is automatically available without additional configuration.
  4. Cost efficiency at Scale: For teams managing multiple services, ECS Express Mode delivers significant infrastructure cost savings, up to 25 services can share a single Application Load Balancer, reducing overhead as your application portfolio grows. The shared infrastructure model becomes increasingly cost-effective with each additional service you deploy.
  5. Multi-service architecture: All your services operate within your AWS account using Amazon ECS, with direct Amazon Virtual Private Cloud (Amazon VPC) connectivity to resources like Amazon Relational Database Service (Amazon RDS) databases, and Amazon ElastiCache, without the VPC connector configuration that App Runner requires. Your services share clusters, networking infrastructure, and consistent access control. This architecture naturally supports service-to-service communication, shared observability, and centralized governance across your entire application landscape.
  6. Container-first approach: ECS Express Mode works with container images, aligning with modern DevOps practices and giving you complete control over your build pipeline. For teams currently deploying from source code, you can replicate App Runner’s continuous deployment experience using GitHub Actions and Amazon Elastic Container Registry (Amazon ECR).

Migrate to ECS Express Mode using blue/green deployment

A blue/green deployment is a strategy where you create two separate environments running different versions of your application. You then shift traffic between them, which reduces downtime during the migration and provides the ability to roll back quickly if issues arise.

For this migration, we’ll use DNS weighted routing through Amazon Route 53 record updates to shift traffic between two environments. Your App Runner service will be the “blue” environment, and your new ECS Express Mode service will be the “green” environment. By configuring weighted routing policies, you can gradually shift traffic from App Runner to ECS Express Mode, starting with a small percentage to validate the new service, then progressively increasing the weight until all traffic flows to ECS Express Mode, or back to App Runner if you need to roll back.

Prerequisites

Before starting this migration, make sure you have:

Estimated time: 20-30 minutes
Estimated cost: Costs vary based on usage. You’ll incur charges for Amazon ECS tasks, Application Load Balancer, and data transfer. Remember to clean up resources after testing to avoid ongoing charges.

Migration walkthrough

The following simplified diagram shows how the migration works using Route 53 to shift DNS records between your App Runner service and your ECS Express Mode service:

Figure - Migration of image-based service from App Runner to ECS Express Mode

Figure – Migration of image-based service from App Runner to ECS Express Mode

Step 1: Create an App Runner service

If you already have an App Runner service running, you can skip this step. For this post, I’m using the AWS Retail Store Sample UI container image already built and pushed to Amazon ECR public repositories. You can replace this with your own container image.

First, define your environment variables:

export APP_NAME=express-web-application
export AWS_REGION=eu-west-1
export ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)

Next, create a configuration file for your App Runner service. This file specifies your container image location, runtime configuration, and compute resources:

cat << EOF > input.json
{
    "ServiceName": "${APP_NAME}",
    "SourceConfiguration": {
        "ImageRepository": {
            "ImageIdentifier": "public.ecr.aws/aws-containers/retail-store-sample-ui:1.3.0",
            "ImageConfiguration": {
                "Port": "8080",
                "RuntimeEnvironmentVariables": {"RETAIL_UI_THEME": "teal"}
            },
            "ImageRepositoryType": "ECR_PUBLIC"
        }
    },
    "InstanceConfiguration": {
        "Cpu": "1 vCPU",
        "Memory": "2 GB"
    }
}
EOF

Create your App Runner service using the AWS CLI:

aws apprunner create-service \
    --cli-input-json file://input.json

This command creates an App Runner service based on your Amazon ECR container image. The service automatically provisions a load balancer, configures HTTPS, and sets up auto-scaling.

Verify your service by navigating to the AWS App Runner console. Wait until the service Status shows Running. Then copy the Default domain value, this is the URL where your application is accessible (it looks like xxxxx.region.awsapprunner.com).

Test your application by opening the default domain in your browser. You should see your application running.

Step 2: Associate a custom domain name with App Runner

When you create an App Runner service, AWS assigns it a default domain in the awsapprunner.com namespace. To use your own domain name, you need to associate it with your service.

In this example, I’m using Route 53 as the DNS provider. If you own a domain name, you can associate it with your App Runner service. After App Runner validates your domain, you can access your application using your custom domain in addition to the App Runner default domain.

To configure this in Route 53:

  • Open the App Runner console and navigate to your service
  • Choose the Custom domains tab
  • Choose Link domain
  • Enter your domain name (for example, app.example.com)
  • If you’re using Route 53, App Runner automatically creates the required certificate validation and DNS records

Route 53 creates either a CNAME record or an ALIAS record pointing to your App Runner service. This DNS configuration routes traffic from your custom domain to your App Runner service.Verify the custom domain works by visiting your custom domain in a browser. You should see your application running with a valid SSL certificate.

Migration to ECS Express Mode

Now that your App Runner service is running with a custom domain, you can create the ECS Express Mode service and gradually shift traffic to it.

Step 1: Create an Amazon ECS Express Mode service

Use the same container image stored in Amazon ECR that you used for your App Runner service. This aids consistency between environments. Define your environment parameters:

export APP_NAME=express-web-application
export AWS_REGION=eu-west-1
export ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)

Create your Express Mode service with this command:

aws ecs create-express-gateway-service \
    --execution-role-arn arn:aws:iam::${ACCOUNT_ID}:role/ecsTaskExecutionRole \
    --infrastructure-role-arn arn:aws:iam::${ACCOUNT_ID}:role/ecsInfrastructureRoleForExpressServices \
    --primary-container '{
        "image": "public.ecr.aws/aws-containers/retail-store-sample-ui:1.3.0",
        "containerPort": 8080,
        "environment": [{
            "name": "RETAIL_UI_THEME",
            "value": "orange"
        }]
    }' \
    --service-name "${APP_NAME}" \
    --health-check-path "/" \
    --scaling-target '{"minTaskCount":1,"maxTaskCount":4}' \
    --monitor-resources 

This single command provisions your complete application stack: – An Amazon ECS service with tasks launched on AWS Fargate, an Application Load Balancer with target groups and health checks, Auto-scaling policies based on CPU utilization, Security groups and networking configuration, and a custom domain with an AWS provided URL (it looks like xxxxx.ecs.region.on.aws).

You can track the progress in the Amazon ECS console under the Resources tab. The provisioning typically takes about 3-5 minutes.

Once complete, test your new ECS Express Mode service using the default application URL shown in the console. Make sure your application works correctly before proceeding with the traffic shift.

Step 2: Shift traffic from App Runner to ECS Express Mode

Now you’ll configure ECS Express Mode to accept traffic from your custom domain, then update DNS to shift traffic. This blue/green approach lets you validate everything works before fully cutting over.

Configure the Application Load Balancer for your custom domain:

Follow the detailed instructions in Adding a custom domain to your service.

The following diagram shows how to add your custom domain as a host header condition in the listener rule. Use the same domain name you associated with your App Runner service (for example, app.example.com). This tells the Application Load Balancer to route traffic from your domain to the ECS Express Mode target group.

Figure - Configuring ECS Express Mode ALB

Figure – Configuring ECS Express Mode ALB

Add your SSL certificate to the Application Load Balancer:

Follow the detailed instructions in Adding a custom domain to your service.

Update your DNS record to shift traffic:

Now update your custom domain’s DNS record to point to the ECS Express Mode Application Load Balancer. This is where the actual traffic shift happens.Convert the existing App Runner record to a weighted record

  • Open the Route 53 console
  • Choose Hosted zones, then select your domain’s hosted zone
  • Find the record for your custom domain (the one currently pointing to App Runner)
  • Choose Edit record
  • Change the Routing policy to Weighted
  • Set Weight to 100 (this directs all initial traffic to App Runner)
  • Under Record ID, enter a descriptive identifier like `app-runner-blue`
  • Choose Save changes

In the same hosted zone, create a weighted record for ECS Express Mode, and enter the same Record name as your App Runner record (for example, `app.example.com`)

  • Under Route traffic to, choose Alias to Application and Classic Load Balancer
  • Choose your ECS Express Mode Application Load Balancer from the dropdown
  • Set Weight to 10 (this starts with about 10% of traffic going to ECS Express Mode.
  • Under Record ID, enter a descriptive identifier like `ecs-express-green`
  • Choose Create records

Monitor your ECS Express Mode service to confirm that 10% of traffic flows correctly to the new environment. Once you validate the service handles requests successfully, you can proceed with your traffic shift strategy. For a gradual migration, progressively increase the ECS Express Mode weight (from 10 to 25, then 50, 75, and finally 100) while proportionally decreasing the App Runner weight, allowing you to validate at each stage. You can use the colour theme of the UI application to monitor which service responds to your traffic. Alternatively, for a complete cutover, immediately set the ECS Express Mode record to 100 and reduce App Runner weight to 0. If you encounter issues at any point, roll back by adjusting the weights back to their previous values.

DNS propagation typically takes a few minutes. You can test the migration by visiting your custom domain. Traffic now flows to your ECS Express Mode service instead of App Runner.

Important: Keep your App Runner service running for a period (such as 24-48 hours) to confirm DNS changes have propagated globally and to provide a rollback option if needed. If you encounter issues, you can quickly revert the Route 53 record back to App Runner.

Cleaning up

To avoid incurring future charges, delete the resources you created during this tutorial:

Delete the App Runner service:

aws apprunner delete-service --service-arn <your-app-runner-service-arn>

Delete the ECS Express Mode service:

aws ecs delete-express-gateway-service –service-arn <service-arn>

To unset those environment variables, use the unset command:

unset APP_NAME AWS_REGION ACCOUNT_ID

Delete associated resources:

  • Remove custom domain configurations from Route 53
  • Delete the Application Load Balancer (if no longer needed)
  • Remove unused container images from Amazon ECR
  • Delete IAM roles created specifically for this migration (if no longer needed)

Note: If you’re keeping the ECS Express Mode service in production, only delete the App Runner service and its associated Route 53 records.

Conclusion

In this post, we showed you how to migrate your containerized applications from AWS App Runner to Amazon ECS Express Mode using a blue/green deployment strategy. This approach provides near-zero downtime migration while opening doors to more advanced container orchestration capabilities.The key advantages of this migration path include:

  • Near-zero downtime: Blue/green deployment is designed to help your applications remain available throughout the migration
  • Simplified operations: ECS Express Mode maintains the operational simplicity of App Runner while providing access to full Amazon ECS features
  • Future scalability: You can now implement complex networking and improve your architecture without another migration. All underlying AWS resources remain accessible for direct management when you need fine-grained control or advanced features.
  • Risk mitigation: The traffic shift approach provides a safe, controlled migration with easy rollback

As your applications grow in complexity, ECS Express Mode provides a natural progression path while maintaining deployment simplicity. Whether you need advanced networking features, advanced scaling policies, or greater infrastructure control, this migration strategy gives your containerized applications room to grow.

For more information on this feature, please check out the following resources:

About the authors

Olawale Olaleye is a Sr. Specialist Solutions Architect for Containers at AWS, based in Ireland, and a certified Kubestronaut. With extensive experience architecting enterprise-scale containerized workloads, he specializes in helping organizations modernize their infrastructure across containers, GenAI/ML operations, and cloud security. Connect with him on LinkedIn.