Cloudformation-coverage-roadmap: AWS::EC2::Instance -BlockDeviceMapping-Ebs should allow volume changes without replacing the instance

[sturdiva]

1. AWS::EC2::Instance -BlockDeviceMapping-Ebs should allow volume changes without replacing the instance

2. Scope of request

It should be possible to change EBS volume attributes (such as VolumeSize or VolumeType) for volumes specified in the BlockDeviceMappings property of an AWS::EC2::Instance resource without re-creating the instance. For example, being able to re-size (via CloudFormation) the root volume of an instance.

This is currently possible via the API/Console, but not via CloudFormation.

3. Expected behavior

On modification of (at least the VolumeSize and VolumeType properties) the AWS::EC2::Instance resource should not be re-created, just the underlying volume properties modified.

4. Suggest specific test cases

Common use case: pass VolumeSize andVolumeType parameters as a string, or as a !Ref

5. Helpful Links to speed up research and evaluation

https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyVolume.html

6. Category (required) - Will help with tagging and be easier to find by other users to +1

1. Compute (EC2, ECS, EKS, Lambda...)

[webframp]

Hit this exact problem right now. Had to do an emergency volume growth on a running system, but now I can't retroactively update the cloudformation stack to match the new volume config since it wants to trigger an instance replacement.

[luiseduardocolon]

Not that it resolves the issue above, and it is a bit involved, but you could use the recently released import feature to a) change the retention policy of the instance to Retain first, b) delete the instance from the stack (but retaining it), and c) reimporting it into the stack. It should have the effect of syncing up with your change (or, said another way, remediating the configuration drift). More info on the import feature here: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resource-import.html - and, you could use https://former2.com/ to help generating the required template snippet. Worth experimenting, but do it outside of production first :)

[webframp]

Great suggestion @luiseduardocolon I’ll try it out in a separate account

[webframp]

Based on initial testing I can confirm that the workaround from @luiseduardocolon using a resource import works.

[rgoltz]

@PatMyron @luiseduardocolon - Do you have a chance to look at this? - Our team has been constantly challenged and overworked by this limitation of BlockDeviceMapping: VolumeSize via CFN-change triggers an EC2 instance replacement.

Could you possibly already classify this on the CloudFormation Roadmap? In case you like to get more details, please let me know. We would love to share our experience. Thanks!

[GrahamLea]

I just stumbled upon this while looking for something else, and I can't believe this is how it works. There also seems to be no indication of this behaviour in the docs, where Ebs.VolumeSize (for example) says "Update requires: No interruption".

Is there a workaround for this using just CloudFormation? e.g. Will creating a Volume and attaching it to the Instance create a similar setup but without the recreate-on-resize behaviour?

[sturdiva]

The docs are un-clear here, if you look at BlockDeviceMappings it will show "Some interruptions", but the paragraph above has:

After the instance is running, you can modify only the DeleteOnTermination settings of the attached EBS volumes.

[wimsymons]

Changing Iops should be included as well.

[Nico-DB]

We need this feature, too.
+1

[RaoM24]

Having the same issue with the root volume. CFT is trying to replace the EC2 instance. Any timelines on fix please.

[wimsymons]

Changing Throughput (for gp3) should not trigger a replacement either. But that is, when Throughput is supported on AWS::EC2::Instance Ebs (https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-blockdev-template.html) first. See #824

[RaoM24]

It's been waiting to fix since 2019. Please may I know if there is any update or timelines. Thanks.

[Benjamin-L]

It would be very helpful if the docs were updated to reflect the current behavior until this is implemented. Even if we include the "Some Interruptions" annotation on BlockDeviceMappings, it still doesn't cover what actually happens, which is instance replacement.

I read "Some Interruptions" on BlockDeviceMappings as "adding or removing mappings may temporarily interrupt the instance", which is not the case.