• Unlimited Leave
  • Posts
  • ⚾ If you build it, they will come? Complaint Greenfield AWS Organization(s) 🧢

⚾ If you build it, they will come? Complaint Greenfield AWS Organization(s) 🧢

That's not always true in the product space. So if I do this, will you use it?

Happy Super Bowl LVII. This is Unlimited Leave, the AWS Governance and Management Newsletter that always roots for the NFC. Since the Vikings never make it, we just watch for the commercials 👇

This week's topics

  • an·nounce·ments

  • Compliant Greenfield AWS Organization(s)

  • Resource of the week

an·nounce·ments

Some good ones here. Long awaited…

Compliant Greenfield AWS Organization(s)

It should be obvious here I have a passion for building robust, “compliant” (whatever that looks like at the time) and automated AWS Organizations.

Humble Brag… but I think I’m pretty good at it. In my previous position I built a Github Workflow automation that deployed and configured standardized Organizations but using a single JSON Config File for new organizations.

The config file had things like Root Account ID, license keys, and other customer specific details for deploying resource into (all accounts of) the organization. By the time I left, it was far from perfect and had a long ways to go, but it was the start of what I thought to be a very robust deployment process. Obviously I'm a little bias. I built it.

We used it to deploy easily a dozen organizations. Sometimes one or two a week. I have no idea if it is still in use. However, it enabled a team of 2-3 to build out baseline AWS Organizations pretty quickly, minimizing human error and misconfigurations.

Today I personally manage 4 Organizations, which will be used over the next year or so to consolidate and combine down about a half-dozen more. There are over 400 accounts across all organizations.

I have no concerns of being able to do this all myself. I have a teammate who’s primary focus is deployment of workload/application enablement, resources, pipelines, etc. I’m primarily responsible for the governance and standardization of the Organizations and Infrastructure as a whole. Which includes things like:

  • Control Tower configs for each organization

  • SCPs, Tagging, Contact Info, Budget Alarms, and other CT Guardrails/Controls

  • Standard resource deployment (e.g. backup, shared resources, networking, etc)

  • Monitoring and Security using Delegated Security Hub, Guard Duty, and Inspector configured with our Incident Response Solution

  • Authentication (of dozens of users) using Azure and AWS Identity Center (permissions set and group assignment to individual accounts.)

  • New Account Provisioning and Automation

At some point the team will grow and the organization will benefit greatly from the velocity that will create. However, I’m pretty sure the 2 of us can handle most all of this just fine on our own. Simply because of processes and the way we have deployed our automation.

I think these processes and lessons learned could have profound impact for the right organizations. They could save a lot of heartache, resources, and most importantly - budget.

So… If I build it, will you come?

Rough Draft Syllabus

Module 1: New Organization

While a new organization isn’t required, I’d walk through how to set up a new one or the steps to modify an AWS Organization for proper management.

Topics Include:

  • Email/Root Account Management

  • Initial Control Tower Deployment

  • Home region selection

  • Initial Controls

Module 2: Authentication

  • Configuring AWS Identity Center

  • Using External IDP (Azure, Okta, etc.)

  • Permission Set Management

Module 3: Delegated Administrator Configuration

The configuration and delegation of administrative access to core services like:

  • CloudFormation StackSet

  • Security Hub

  • GuardDuty

  • Identity Center

  • Service Catalog

Module 4: Customizations for Control Tower (CfCT)

The Process for bootstrapping and baselining configuration of the CfCT Solution

  • Deploy CfCT

  • Initial manifest configuration

  • StackSet Resource deployment

  • SCP Deployment

Module 5: Account Factory for Terraform (AFT)

The process for bootstrapping and baselining configuration of the AFT Solution

  • Configure AFT Management and Repos

  • Deploy new accounts with Account Request Module

  • Deploy Account level and Global Customizations

  • Using AFT to set and reset drifted account configuration and details

Module 6: Service Catalog Portfolio

Creating, sharing, and deploying standard solutions through the use of a shared Service Catalog Portfolio

  • Central resource storage (S3) for Organization Access

  • Delegation of Portfolio

  • Providing Access

  • Enabling Developers

Module 7: Baselining Security Posture

Use foundational resources to close or acknowledge open AWS Best Practice checks and set a baseline security posture.

  • Close or disable global Security Hub Checks

  • Configure and deploy AWS Config Rules and/or Conformance Packs

  • Set up proper prioritization, alerting, and notification of non-compliant resources.

Possibly more modules and resources as needed

Well… would you?

As you can see, there is a lot here. Before I decide to take on such a massive undertaking, I’d really like to know if this is of interest to any of you. I’m not sure what percentage of you would actually be interested in this content.

Using the response to that poll over the next couple weeks, I will determine if this will be something I dive into. I personally think there is a lot of potential value provided there. I need you amazing subscribers to validate that.

Will it cost money? It pretty much has to. I have to host it somewhere and also start making this newsletter pay for itself.

Of course, all of my subscribers will get a heavily discounted rate, early access, and naturally bonuses that will likely just sit in your inbox.

I look forward to you telling me what you think.

Resource of the week

This week I stumbled upon CloudGlance from a fellow AWS Community Builder and AWS [HERO].

While the AWS Profiles setup doesn’t directly fit my use case the way Leapp.Cloud (which I’ve shared previously) does, there is significant benefit in using this tool to check the status of CFN Stacks across Management accounts and delegated CFN administrator accounts.

I’ve just started playing with it and what I like the most is it’s ability to store and share team configurations in a Git Repo. With proper setup, this will take care of my complaints over Leapp but still offers the bonus CloudFormation status.

There is a lot of potential here for sure. Right now it is free but it won’t always be. You best check it out.
 
#NOTASPONSOR

Review past issues HERE | Share with others HERE
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 own research and testing prior to the implementation of any resource or service deployed for any workload.