Automatically Deleting a Failed CloudFormation Stack in a Rollback State
ACM.92 Reducing manual actions to get things deployed with CloudFormation
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
⚙️ Check out my series on Automating Cybersecurity Metrics. The Code.
🔒 Related Stories: Cloud Architecture | Application Security | CloudFormation
💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I was attempting to auto-generate a password for a new user in the last post with proper non-repudiation.
Along the way I got tired of not being able to re-deploy a CloudFormation stack stuck in a failed state. That led me to write some code and this post to automatically delete the stack and redeploy it. I don’t know why CloudFormation doesn’t do this for you or have better options to control it.
Here’s what I did:
![](https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*szueUtSQOIVl9PLVTgzVUA.png)
The first command above does the following:
- Describe the stack
- Get the status value
- Added or true (|| true) to ignore errors
- Added 2>/dev/ null to not print out errors — — something I generally tell people not to do but in this case it makes sense.
The next command checks if the stack is in a ROLLBACK_COMPLETE state and deletes the stack if it is. I’m presuming here you waited for your rollback to complete before trying to redeploy a stack. :)
Now the problem is…the stack is still trying to delete. We have to wait until it gets into a state where we can proceed, or it could end up in a failure state of some kind. The easiest thing to do is probably wait until the stack is not in this state: DELETE_IN_PROGRESS.
Since I now have to check the status multiple times, using the principal of abstraction I’ve written about many times in this blog, I moved the status check to it’s own function. I also realized that I needed the /dev/null in a different place to prevent getting the error message when the stack does not exist.
![](https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*ncI_sqQn3gmySjwVkhwH_Q.png)
Then I end up with this code in my deploy stack function:
![](https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*ffeFsjKRsGEycNfVhPOAYw.png)
That should save me a little time at least.
Now back to what I really want to be doing. Testing out our user’s ability to log into an EC2 instance with the key we created.
Follow for updates.
Teri Radichel | © 2nd Sight Lab 2022
About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab
Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation
Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab
![](https://cdn-images-1.readmedium.com/v2/resize:fit:800/0*H9Ew1KCl-29nZiPR.jpeg)