AWS ECS集群实操：如何创建第二台实例并迁移production容器

Alright, let's break this down step by step—you've got a single-instance ECS cluster running 2 staging and 2 production containers, and you want to spin up a second instance and move those production containers over. Here's how to pull this off smoothly:

First, you need to register a new EC2 instance to your existing ECS cluster. Here are the two most common ways:

• Using EC2 Launch Template/Configuration: If you already have a template set up for your existing ECS instance, just launch a new instance using that template. Make sure the user data in the template includes the correct cluster name for the ECS agent, like this:

  #!/bin/bash
  echo "ECS_CLUSTER=your-cluster-name" >> /etc/ecs/ecs.config
  

  Wait a few minutes, then check your ECS console under Clusters > [Your Cluster] > Instances—you should see the new instance show up as active.
• Using AWS CLI: Run the aws ec2 run-instances command, specifying an ECS-optimized AMI, your preferred instance type, security groups, and the same user data snippet above to link it to your cluster.

Assuming your 2 production containers are part of one or more ECS services (the standard setup for long-running containers), you'll adjust service configurations to steer tasks to the new instance.

If your production containers are in a single service (2 tasks total): #

1. Go to your ECS console, find the production service, and click Update Service.
2. First, set up a task placement strategy to spread tasks across instances—this ensures ECS won't pile both production tasks on the old instance. Under Task Placement, add a rule:
   • Key: instanceId
   • Type: spread
   • Value: *
3. Choose your migration approach:
   • No-downtime rolling update: Tweak a minor detail in your task definition (like adding a harmless environment variable description) and trigger the service update. Set Minimum healthy percentage to 50% and Maximum percentage to 200%—ECS will spin up new production tasks on the empty new instance first, then shut down the old ones on the original instance.
   • Stop-and-restart (faster, but brief downtime): Temporarily set the service's Desired tasks to 0, update the service to stop all production tasks. Then set it back to 2—with the spread strategy, ECS will prioritize the new empty instance for the restarted tasks.

If your production containers are two separate services (1 task each): #

Repeat the steps above for each production service: update the placement strategy, then use either rolling update or stop-and-restart to move each service's task to the new instance.

• Check your ECS console under Clusters > [Your Cluster] > Services—click into each production service, then view the Tasks tab to confirm the tasks are running on the new instance ID.
• Double-check the original instance's tasks—you should only see the 2 staging containers left.
• Test your production application to ensure everything's running as expected post-migration.

If you want to guarantee staging containers never move to the new instance, add a custom tag (e.g., environment=staging) to the original EC2 instance. Then, for your staging services, add a task placement constraint:

• Key: environment
• Type: memberOf
• Value: staging
  This tells ECS only to schedule staging tasks on instances with that tag.

内容的提问来源于stack exchange，提问作者kostukp96