- Unlimited Leave
- Posts
- ClickOps vs. Automation and Repeatability
ClickOps vs. Automation and Repeatability
New APIs for CloudFormation StackSets
Ross Wickman
June 09, 2023
Good day. This is Unlimited Leave, the AWS Management and Governance newsletter that recognizes it’s tough out there in IT right now.
Not only has the workload for what keeps the lights on around here been higher than normal, this week the organization I work for announced another round of layoffs knocking off roughly 12% of our Global Workforce. My team dropped from 5 to 2 with major initiatives underway.
This work takes priority over the newsletter and the Greenfield Orgs Course. I enjoy what I do daily but this newsletter and side consulting act as a pilot-light/warm standby for my career.
Saying I’m grateful to be spared is an understatement but it doesn’t come without costs. Lots of great and talented people(developers, network engineers, SREs, and more) are looking for work right now. If you have any leads please forward them over.
This week's topics
Management & Governance Announcements
Deciding when to automate
Refund Status for Greenfield Course
Management & Governance Announcements
AWS Control Tower increases account access configuration flexibility - this update allows users to decide if a vended account will use AWS Identity Center or if they’d like to use IAM instead. Beyond that, you can select when and how to adopt more of the core features of Control Tower when you are ready. AWS is leaning toward making Control Tower more flexible to increase adoption. I’m on board.
AWS Config advanced queries support 30 new resource types - only a couple of queries here that I will leverage but anything that helps keep an eye on configuration compliance for your teams and their environments is a win. Keep the resource types coming. Creating custom Config Rules is not all that fun. Having the SSM Run Docs on hand is always a plus, however.
AWS CloudFormation StackSets skips suspended accounts for faster deployments - an extremely helpful update for StackSet. Large organizations have account closures all of the time. Setting an increased failure tolerance simply doesn’t cut it at scale, especially if some accounts in a failed state are still active and should have updated resources.
AWS CloudFormation StackSets launches APIs to allow programmatic trust access with AWS Organizations - this one always got me. The ability to programmatically enabled trusted access for StackSets is a huge win for automation. See below.
Deciding when to automate
In my previous role, the organization I worked for was an AWS Managed Service Provider and Account Reseller. Every customer received their own AWS Organization even if they only needed one workload account. There were many benefits to this, but the initial setup took some time and was prone to steps being missed. There should have been only one manual step required when creating a new Organization - Deploying an execution role that was used to do everything with scripts and automation.
The reality was we couldn’t deploy stages resource until we manually clicked the Trusted Access from the CloudFormation StackSets Console. There was no (documented/supported) API. The benefit was after the account was created since we were already in the CloudFormation console deploying the template to launch our role, we just had to complete 3 additional clicks to enable the trust.
Seems easy right? Nope. There was a chicken and egg problem. First, you had to create the AWS Organization in the account to enable the Trusted Service. This could be done via CLI or script automation.
So the question becomes, at what point do you automate? Do you automate everything you can to the point you can’t, do the manual process, then pick up automation where you left off?
Or…
Do you heavily document and manually complete all steps to the point where you can do everything with automation?
In this situation at the time, it made the most sense to manually do everything past the point of automation.
You can see here, where a simple and yet trivial feature enhancement saves boatloads of manual labor and human configuration error.
Shoehorning this new API into the old process could potentially save hundreds of hours of work going forward.
Refund Status for Greenfield Course
The refunds are underway. Unfortunately, the service I am using to host the course appears to have some limitations on the number of refunds I can initiate in a given amount of time. I’ve completed exactly 50% so far and I’ve opened a support ticket to be able to complete the rest. Any hangups I will reach out to each of you individually.
A big thank you to those willing to let me hold on to your payments. At this moment it feels like the course will never get done. That will pass I know. As I stated earlier, this project is a passion as well as something I’d like to devote 100% of my time to. At the moment, that doesn’t seem like a reality so I want to make sure everyone gets their refund and has an opportunity to get the course when it is ready.
If time permits, I may modify what I’ve completed and release some of it here or on YouTube when things slow down.
I never planned on making the newsletter subscription-based and I’m not going to change my mind on that. However, if you would like to support the Newsletter in a different way you can do so here:
