aws-cloudformation / aws-cloudformation/cloudformation-coverage-roadmap

AWS::ECS::Volume should support update of `SnapshotId` with a volume replacement

Open
#1,505 0 comments 2 reactions 0 assignees View on GitHub
enhancement
Dominant language
No language data
Stars
1.1k
Forks
62
PR merge metrics
No merged PRs in 30d

Description

### Name of the resource

AWS::EC2::Volume

### Resource name

_No response_

### Description

Currently, AWS::EC2::Volume disallows any update to SnapshotId. This should be supported with the volume replaced whenever the SnapshotId changed.

The reason being Cloud Formation should support a workflow that makes the recovery from an EBS snapshot reasonably easy.
Unfortunately, this is not the case right now. Recovery from an EBS snapshot currently involves two stack updates chronologically.
1. Update the stack with the existing AWS::EC2::Volume and AWS::EC2::VolumeAttach resources removed
2. Update the stack by re-adding a new AWS::EC2::Volume with the target SnapshotId and its corresponding AWS::EC2::VolumeAttach resource.

Combining the two steps into a single step does not work.
1. For one, this requires a change to the volume's logical id to something different than the existing one. This breaks the semantics of the resource's logical name.
2. Secondly, I don't have any control over the device name for the nvme disk (i.e. /dev/nvme1n1) since the naming of nvme EBS volumes is based on their order of attachment. I can't control whether the detachment of the existing or the attachment of the new volume will happen first. This causes all sorts of additional headaches. How do you partition and format the volume without knowing its device name first? So some extra probing will be required to figure out the current device name.

Even when this does work, please remember a workaround is just a workaround. Your customers use your product to make their life easier, the workaround does not deliver that.

All in all, a key selling point of Cloud Formation is it's declarative. But in this case, I can't simply declare a desired state and call it a day. Rather I am forced to use a declarative tool to mimic some procedural changes.

Allowing an EBS volume to update its SnapshotId in Cloudformation will significantly improve its usability making it work much much nicer with EBS snapshot.

### Other Details

_No response_

Contributor guide

Open the contributing guide

Research direction

Start by reconciling the title's AWS::ECS::Volume reference with the body, which requests AWS::EC2::Volume support for changing SnapshotId. Review the existing CloudFormation coverage-roadmap entry and determine how replacement semantics are recorded for this resource. Done means the requested SnapshotId update and volume replacement behavior are clearly captured for consideration.

Written by the indexing model from the issue text.

Assessment

Tech stack
aws
Domain
cloud
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.