In the AWS CLI we already have aws cloudformation delete-stack --stack-name <value> where we can only delete ONE stack at a time.
Since the AWS back-end should already have a pretty good idea of what resource depends one what other resource , I want to propose the ability to delete CloudFormation stacks in bulk (or batches).
I believe such a feature will be greatly beneficial to many AWS users.
The command (AWS CLI) syntax could then be something like aws cloudformation delete-stacks --stack-names <list-of-values>
Other Details
I have played with parallel delete of several CloudFormation stacks at the same time, and sometimes it works, but sometimes things also go wrong. The parallel action is done with my program, but I guess it's not parallel on the AWS side as these commands probably come into some queue.
One side effect is that even though a random CloudFormation stack in this batch may be deleted (success state), not all resources may be deleted because of some API throttling that happened on the back-end which was not transparent/visible to me (not even in CloudTrail). After some back-and-forth with AWS Support I came to find out that when you delete CloudFomration templates in parallel (effectively calling many instances of aws cloudformation delete-stack --stack-name <value> commands), strange things can sometimes happen, as described.
Some stacks do fail, for example, when you try to delete EKS NodeGroups at the same time as the Cluster stack, the cluster stack will end in a fail state because it has some dependencies in the NodeGroup stack(s).
I am just wondering why the AWS back-end cannot detect the dependency before any action is taken and then run the delete in the right sequence where needed and where API throttling does occur, just handle it like they tell the customers to handle it..
Obviously this will not be possible when submitting individual delete-stack calls, but a bulk command (like delete-stacks) might enable such dependency detection and proper processing of all the deletion of stacks in the right order.
Name of the resource
Other
Resource name
CloudFormation API
Description
In the AWS CLI we already have
aws cloudformation delete-stack --stack-name <value>where we can only delete ONE stack at a time.Since the AWS back-end should already have a pretty good idea of what resource depends one what other resource , I want to propose the ability to delete CloudFormation stacks in bulk (or batches).
I believe such a feature will be greatly beneficial to many AWS users.
The command (AWS CLI) syntax could then be something like
aws cloudformation delete-stacks --stack-names <list-of-values>Other Details
I have played with parallel delete of several CloudFormation stacks at the same time, and sometimes it works, but sometimes things also go wrong. The parallel action is done with my program, but I guess it's not parallel on the AWS side as these commands probably come into some queue.
One side effect is that even though a random CloudFormation stack in this batch may be deleted (success state), not all resources may be deleted because of some API throttling that happened on the back-end which was not transparent/visible to me (not even in CloudTrail). After some back-and-forth with AWS Support I came to find out that when you delete CloudFomration templates in parallel (effectively calling many instances of
aws cloudformation delete-stack --stack-name <value>commands), strange things can sometimes happen, as described.Some stacks do fail, for example, when you try to delete EKS NodeGroups at the same time as the Cluster stack, the cluster stack will end in a fail state because it has some dependencies in the NodeGroup stack(s).
I am just wondering why the AWS back-end cannot detect the dependency before any action is taken and then run the delete in the right sequence where needed and where API throttling does occur, just handle it like they tell the customers to handle it..
Obviously this will not be possible when submitting individual
delete-stackcalls, but a bulk command (likedelete-stacks) might enable such dependency detection and proper processing of all the deletion of stacks in the right order.