You need to enable JavaScript to run this app.
优惠活动
大模型
产品
解决方案
定价
更多

Auto Scaling Group重新挂载卷及ECS实例停止防终止咨询

Fixing Auto Scaling Group (ASG) Instance Termination & Persistent Volume Data Loss

Hey there, let's work through this problem together—since you're running a single Docker container on ECS and need it to run only a few hours a day, we need to tweak some ASG and EC2 settings to keep your data safe while letting instances stop instead of getting terminated.

1. Stop ASG from terminating stopped instances

By default, ASGs treat stopped instances as unhealthy and will terminate them, or automatically delete instances when you scale desired capacity to 0. Here's how to change that:

  • First, set your EC2 instances' Instance Initiated Shutdown Behavior to stop (it defaults to terminate). This ensures that when you manually stop an instance, it doesn't get deleted right away.
  • Next, enable Instance Protection on your ASG. This prevents the ASG from replacing or terminating stopped instances automatically, even if it detects the instance is in a stopped state.
  • If you're using scheduled scaling, avoid setting desired capacity to 0. Instead, use scheduled actions to stop the instances directly during off-hours, and start them back up when you need the container to run.

2. Guarantee EBS volumes persist after instance termination

You mentioned you already started configuring BlockDeviceMappings in CloudFormation—great start! Just make sure you explicitly set DeleteOnTermination to false for every EBS volume you want to keep, especially the root volume (which defaults to true). Here's what that looks like in a CloudFormation snippet:

BlockDeviceMappings:
  - DeviceName: /dev/xvda
    Ebs:
      DeleteOnTermination: false
      VolumeSize: 30
      VolumeType: gp3
  - DeviceName: /dev/xvdf
    Ebs:
      DeleteOnTermination: false
      VolumeSize: 100
      VolumeType: gp3

This ensures that even if an instance does get terminated (accidentally or intentionally), your EBS volumes stick around ready to reattach later.

3. Make sure ECS containers use persistent storage

Don't forget to map your Docker container's data directories to the persistent EBS volume on the instance:

  • In your ECS task definition, add a volumes entry pointing to the EBS mount path on the instance (e.g., /data), then set up mountPoints inside the container definition to link the container's data folder to that volume.
  • To ensure the EBS volume mounts automatically when the instance starts, add this to your EC2 user data (cloud-init script):
echo "/dev/xvdf /data ext4 defaults,nofail 0 2" >> /etc/fstab
mount -a

This way, every time your instance starts back up, the volume is ready for the container to use.

4. Adjust ASG health checks to avoid false replacements

If your ASG uses EC2 health checks, it might mark stopped instances as unhealthy and spin up new ones. To fix this:

  • Switch the ASG's Health Check Type to ELB if you're using a load balancer with ECS. This way, the ASG only considers instances unhealthy if they fail the ELB health check (not just being stopped).
  • If you don't use an ELB, you can tweak the health check grace period or rely on instance protection to prevent the ASG from replacing stopped instances.

Putting all these pieces together, you'll be able to stop your instances during off-hours without losing data, and start them back up whenever you need your Docker container to run.

内容的提问来源于stack exchange,提问作者Mugetsu

相关产品推荐
方舟 Agent Plan

超全模态模型 × Harness 升级,最新支持 Deepseek-V4.1-Flash、GLM-5.3 系列、Doubao-Seedream-5.0-pro、Kimi-K3 (部分), 限时 9.9 元起

最近更新时间:2026.05.25 07:06:29