Oofta... Finally back for re:Invent

After 11 months, here are the updates, heartaches, and lessons learned from AWS Management at scale.

Happy re:Invent Kick-off!!! This is Unlimited Leave, the AWS Management and Governance newsletter that takes almost a year off and then asks a giant favor of you.
I hope you haven’t forgotten about me.

If you’ve subscribed since the last issue back in January — Welcome!
I’m so happy you clicked that button. I’m sorry I’ve been MIA.

If you’re enjoying AWS re:Invent in person this week, I envy you. This is the second year in a row I have not been able to make the trip. Although this year, being present at home far outweighs my desire to be in Las Vegas.

Let’s get into it…

Bottom line up front - I’m building something:

If you have followed along through the issues of this newsletter, you’d know that I have a somewhat unique lens through which I view AWS Management & Governance. Over the last 10 years of my career working in AWS environments, I’ve never found myself working solely within a single AWS Organization. AWS documentation, marketing, AMs, TAMs, SAs, etc., will all make you believe this is the only way. At the very least, the preferred way.

The support for a Multi-Org configuration is not on the roadmap and will likely never be. This has remained true, and all the while, I’ve stated that this cannot continue to be the case. Please read more at the end of this issue.

This week's topics

  • What have I been up to

  • The future of the newsletter

  • One AWS Management Plane, Dashboard, or Single-Pane-of-Glass to rule them all

The last 12 months of AWS M&G

Since July 2022, I have been working within a company that, through a merger and acquisition, grew from three (3) AWS organizations to nine (9). Granted, even though one of those organizations never had viable workloads present, it still needed to be properly maintained.

Why did we grow to (or ‘require’) 9 AWS Organizations? The company I work for has three unique product lines and services. There was very little in shared AWS resources across the products. Each of the three services was an individually specific implementation of AWS that all had unique compliance requirements and security posture. Additionally, the teams working on the products had no overlap, so having three different Identity Center implementations meant that no one inadvertently got access to the wrong accounts.

Most importantly, when deciding to go the route of an individual AWS Organization for each product line, there was a very small probability (but a high possibility) of the sale of one or more business units in the future. Since I was essentially hired to take over approximately 100 AWS accounts from the entity being acquired, I took it upon myself to convince management, as well as our AWS SA/TAM, that dropping each account in an Organization specific to the product line was the safest bet. While they pushed back a little bit for understandable reasons, they essentially agreed that with my model and level of understanding, the design could work.

I know putting all accounts in a single organization has considerable benefits. I understand that the proper and mindful consideration of the AWS Organization structure could accommodate hundreds of accounts that each have unique compliance requirements. Every company needs to make this decision up-front. The risk is having the requirement to consolidate or break part an Organization in the future. Neither of these are Type 1 decisions. Whichever path you decide to go can be changed or reversed.

In August of 2022, I began the deployment of 4 net-new AWS Organizations. One each to support the individual product lines and a central management organization for the over-arching role assumption, automation, log aggregation, and sharing of central resources if required (Direct Connect, Transit Gateway, Central NAT Egress, and more).

Fast forward to the beginning of September 2024, the company I am employed by has filed Chapter 11 Bankruptcy. While a sale of one, some, or all of the company’s product lines were in the works, time ran out when the money ran out. Today, our largest competitor is in the process of acquiring our customers and contracts for one of the core product lines. One of them remains intact. The other may likely be divested through other means.

All of this is to say that I didn’t have a crystal ball at the time. I got lucky with my bet that, at some point, one or all of these organizations may end up being transferred elsewhere through a divestiture or another acquisition. (Being acquired for a quality product as a medium-to-large business is always the desired outcome). The amount of work required by the company that held the 100-ish accounts acquired in 2022 was significant. In their case, having multiple AWS Organizations may have never been a viable option. However, being able to support the acquisition of each account in a clean environment allowed me, through this process, to continue to maintain an active workload environment while very easily handing over existing customers or tearing down environments.

Today, of the greater than 300 AWS Accounts, roughly 40-50 will just continue to exist unaffected. To support this transition, I don’t need to log into this AWS Organization at all. Moving or terminating services and suspending or repurposing other accounts will have zero impact on the accounts in the Organization for the product line remaining intact and operational for the new owner.

The Future of Unlimited Leave

While the theme of this newsletter has been me documenting my journey for consolidating accounts and managing compliance for 9 AWS Organizations and 300-400 accounts depending on the month, now I will be shifting to the backside of this process.

Along the way, I’ve mentioned some of the lumps and bruises I’ve taken through this process. Nothing has been a major show-stopper, and I regret nothing through the management of these organizations so far. Going forward, I plan on sharing the lumps and lessons learned during the process of divestiture and closing down a very large-scale AWS environment.

Additionally, this newsletter will change a little bit around the content shared. In the last year, AI content generation has created considerable concern for me. The quality and the ability to generate content, tutorials, or how-tos for the greater AWS community have both diminished as well as generated a bunch of noise. The amount of content that overlaps with another individual’s blog post or tutorial course continues to grow exponentially. Generating a general newsletter sharing AWS service updates and insight, I believe, has lost considerable value. I’ve always taken to generating this newsletter with a very specific and niche twist. I do not plan on changing that. However, continuing to provide value to the community will now require additional due diligence.

Your time, the time you take to review this newsletter, is very valuable. I recognize that, and I want to make sure that the content I provide here continues to provide you the value you’d expect from an AWS Management & Governance-themed newsletter.

Starting today, this newsletter will continue to be themed for AWS M&G. However, the content will be even more focused on tooling and processes around making multi-organization management, discoverability, observability, and configuration more palatable.

The Dashboard that AWS Wouldn’t Give You

I’ve created dozens of tools over the last decade that I need to dig up from time to time to gather information or configuration details across one or hundreds of accounts across one or multiple AWS Organizations. I’ve recently decided to productize these tools into a single solution.

A little over a year ago, I started generating written, video, and audio content along with templates to consolidate into a course for the best-practice and compliant deployment of a “Greenfield” AWS Organization. The deeper I got into the content, the more I realized that the real value wasn’t in supplying content that, in the world of AWS, is almost outdated the moment it is released. The value is in providing the community resources that can shave minutes, hours, or potentially days from their AWS Management and Governance workflow.

Many of you had built enough trust with me and my content here in the newsletter to generously purchase that content ahead of release. For that, I am forever humbled and grateful.

Over the last 12 months, I’ve been working on something that helps me better do my job more efficiently.

I have completed a 10-week SaaS Accelerator program at which the culmination required nine other B2B SaaS software solutions (not related to AWS) to pitch and be judged by local and national angel investors and VCs. I received extremely positive feedback.

Today, I am preparing for a competitive pitch for $5,000 and to compete at the state level at the beginning of next year for $20,000.

I would like to introduce you to Sentri Cloud.

I intend to bootstrap this solution until growth or functionality requires additional funding. I have spent the last 12 months very slowly building this out to an MVP worthy of sharing early with this community. I am very close to being able to release it for feedback, feature requests, and testing in a minimal capacity.

At the time of sending this issue of the newsletter, my full-time employment is scheduled to end on January 15th, 2025. While I have some options lined up, I believe there is no better time than now to commit to the development of these tools that I use daily to make my job easier.

So, who is Sentri Cloud for?

Sentri Cloud is for anyone managing multiple AWS Accounts. Ideally, they are managing, or at the very least requiring, access to one or more AWS Accounts across one or more AWS Organizations.

These AWS Organizations could be owned and managed by a single company, employer, or an AWS enthusiast.

If you are an individual AWS Consultant working with your customers and contracts, Sentri Cloud is for you. You could be finding clients through AWS IQ, UpWork, NerdRabbit, or the like and juggling multiple IAM users and passwords. Then Sentri Cloud will allow you to centrally manage role-switching access to those accounts and give up your long-term credentials. Your customers will no longer need to credential you in their own Identity Provider.

On the far end of the spectrum, if you are an enterprise-level Managed or Professional Service provider, Sentri Cloud will allow you to manage, inventory, and monitor your client’s Organization and Account landscape through a single-pane-of-glass.

I am extremely excited to be announcing this solution today and to start gathering use cases and feedback from all of you who could find tremendous value in a tool like this.

Your continued support of this newsletter, your trust in my content, and your commitment to AWS Management and Governance warrant heavily discounted access to this solution.

While I know I’m breaking all the rules of email marketing, content sharing, and product sales by not first warming this newsletter up and getting you all reacquainted with me, I believe the worst thing I can do for myself is sit on this much longer.

If you find yourself interested in this product or believe it could also say you hours of time a week, I’m offering a 90% discount for a year of service to the subscribers of this newsletter.

Just visit https://www.sentri.cloud, join the waitlist, and get the prompt for early access.

Happy re:Invent!!!!

Review past issues HERE | Share with others HERE
Start your newsletter with this link
Disclaimer: The resources and topics shared within this newsletter are for informational use only. Any resources deployed or tools implemented are done so at your own risk. Do your research and testing before the implementation of any resource or service deployed for any workload.