The benefits of AWS organizations

This article is meant for CEOs, CTOs, and managers who want to understand the benefits of managing AWS infrastructure using Organizations. I will answer a common question clients have: Why spend the time setting up AWS Organizations?

Why I wrote this article

I have worked with countless clients on recurring issues that leave them feeling trapped and struggling to:

• build new features
• understand where they are
• figure out whether their infrastructure is secure
• run a stable product
• understand their costs

I am confident that this article will help you understand how important it is to use AWS Organizations at the outset so that you start off organized and thus avoid the extra time and costs involved in having to later reorganize.

Key features of AWS Organizations

• You have one bill to pay for all of your AWS accounts within Organizations.
• You get a detailed breakdown of your bill per AWS account, which helps showcase where your money goes. AWS Cost Explorer can view usage and track costs across all accounts.
• You can create new AWS accounts programmatically with the CLI, SDKs, or API - no new credit cards, no new sign-ups.
• You can control access to AWS resources for each individual AWS account from the main Organizations account.
• You can apply policies from the Organizations account down to all the sub-accounts.
• You can organize the sub-accounts in Organization Units (OU) to help you further organize the company in AWS and improve security.

The policy toolbox

Policies are where Organizations really pays off. Each type is applied centrally and flows down to every account or OU you attach it to:

• Service control policies (SCPs) set the maximum permissions for an account: which services, actions, and Regions anyone in that account can use. A developer account simply cannot start resources you've blocked - no matter what their IAM user allows.
• Resource control policies (RCPs) work from the other side: they centrally prevent unintended use of your resources, whoever is calling them.
• Tag policies enforce consistent tagging across accounts, which is what makes cost tracking and attribute-based access control actually work at scale.
• Backup policies enforce backups on the schedule you define, through AWS Backup, across every account.
• Declarative policies, chat applications policies, and AI services opt-out policies round out the set for baseline configuration, Slack/Teams access, and AI data usage.

Built-in integrations worth knowing

• IAM Identity Center gives your team single sign-on into all accounts with permissions based on job roles - no more juggling IAM users per account.
• Delegated administration lets you hand responsibility for a service (security tooling, for example) to a member account, so not everything has to run through the management account.
• Organization-wide CloudTrail creates a log of all activity in every account that member accounts cannot turn off or modify - your auditors will love it.
• AWS Control Tower packages governance rules for security, operations, and compliance on top of Organizations if you'd rather not assemble the pieces yourself.

The benefits

It's much easier to:

• Do audits
• Set the right policies and access resources
• Create test environments
• Understand what each AWS account has for newcomers
• Lower costs by exposing hidden costs

The bare-minimum setup

I always recommend this setup to my clients:

• In Development you test and work on the project. Here you have the most freedom to use different resources.
• The Demo account is where you can showcase the latest features that are ready to go into production. This is your last chance to see if you like what's been done. It can also be used to perform demos for clients.
• On the other hand, Production is for your customers with live data.

The Demo and Production environments are locked down to the point that no one but the main admin has access to them.

All accounts have 100 percent automatic deployment and do not have access to the servers over SSH or other means – no exceptions.

A word of caution

Having said all this, here's an example of what will happen if you start the wrong way, based on interacting with clients over the years.

Depending on project size, creating a CloudFormation from scratch takes an average of one month, and then it takes two more weeks to create all the AWS accounts to deploy the stack using the created CloudFormation files. This is the stage where all the final testing and final tuning happens.

Lastly, you'll start running your code in the new environment with a new work flow. A lot of the project's bugs will surface at this stage, because up to this point no one could log into the servers to perform ad hoc changes (also known as massaging the code). Now all the work a developer told himself he'd copy later in the repository shows up at this stage. How long will it take to fix everything? It depends on the project. From my experience, it takes a team of developers three months to normalize everything and adapt to the more organized environment.

What else should I know?

• You're limited to five levels of OU nesting under a root, so design your infrastructure accordingly.
• You can describe your organization in CloudFormation - accounts, OUs, and policies are all supported resource types (AWS::Organizations::*).
• You can request quota increases (like the maximum number of accounts) through the Service Quotas console or API.
• Converting the main account to an Organization won't make any changes to what you already have in the account.

An example of a more complex Organization

This is an example for once you get your project off the ground. You could extend your Organization this way later on:

• Application (OU):
  • Development - (AWS Account)
  • Demo - (AWS Account)
  • Production - (AWS Account)
• Information security (OU):
  • Log Collection - (AWS Account)
  • Auditing - (AWS Account)
• Infrastructure (OU):
  • DNS - (AWS Account)
  • Build Tools - (AWS Account)
  • Repos - (AWS Account)
• Office (OU):
  • Work Mail - (AWS Account)
  • VPN - (AWS Account)
  • NAS - (AWS Account)
  • AppStream - (AWS Account)
• Etc.

To sum it up

I hope this explanation helps you organize your thoughts around AWS Organizations so that you can know exactly what to ask for when talking to contractors or your team.