Yep, it is an actual word. Pronounced neph·e·lo·coc·cy·gia. According to, it means “the act of seeking and finding shapes in the clouds.”

Just like that word, the cloud journey can be overwhelming and even a tad bit scary at first. But if you take it step-by-step, get the terminology down and find a solution provider that will help guide you through the modernization maze, the cloud can be a satisfying place.

The cloud can be fantastic. It’s a scalable, flexible and elastic powerhouse that lets you do almost anything. That’s the draw.

The challenge comes when we realize that, to use it properly, we have to gain a set of skills we haven’t needed before. It’s NEW and it’s DIFFERENT, but that’s okay! That departure from normalcy is part of the reason the cloud is so appealing.

Today I am going to walk you through the very first step for any company beginning their AWS cloud journey: Account Creation and Organization Design. This may seem like a very simple topic, but if this step is done incorrectly it can seriously impact the growth and scalability of an organization.

First things first: we want to start consuming AWS. Consumption is probably the most important concept to remember when working with cloud. Realize that you are moving from a CapEx model where you plan and buy whatever you need ahead of time, to an OpEx model where you get and pay for whatever you want on-demand.

This is what gets MANY organizations into trouble. Cloud can be cheaper, and it can save you money if you do it right. But it can also cost a whole lot if you do it wrong.

So, let’s jump right in.

First, navigate over to Once there, click Create an AWS Account located in the upper right-hand corner of the page.



One thing to keep in mind before we continue is that you WILL have multiple AWS accounts. In fact, multiple accounts is an AWS best practice. Why? Because if an unauthorized something or someone happens to gain access to an individual AWS account, not everything can be accessed. This practice is referred to as “limiting blast radius,” and it is tied to one of the most important decisions in your early AWS configurations: What accounts are going to be created? And the answer is not a one-size-fits-all decision. I have personally started this journey with numerous clients of all sizes in all types of verticals, and the best advice I can provide here is this: Do not conform your organization to a prescriptive strategy. Develop your own, unique strategy.

Next, enter the details as requested.


Since this is the first account for our organization, we are going to call this the “Master” account. Master, root; whatever nomenclature you determine, this will be the parent account for all of your other AWS accounts. You will want to use a distribution list or alias for the email address. Do not use a specific individual. AWS best practice is to lock away AWS account root user access keys, and instead, create individual users and utilize groups to assign permissions to users. Why? Because the master account is where billing information is kept, and all charges roll up to it. Another good reason to use multiple AWS accounts is the ease of charge-back and show-back on your AWS bill. Each account is broken out on the bill itself for easier understanding.

A couple of options for account breakout would be one account for production workloads and a separate account for non-production workloads. For instance, if you have a PCI compliance requirement you can break that out into its own account that can be secured individually. Another scenario is if there are several departments using AWS, those departments can be broken out by account in order to align with the charge-back and show-back models available on the AWS billing.

Once Continue is selected on the account creation page shown above, you will be prompted to enter company details and credit card information. If you wish to switch to invoice billing you can do that here, but it will need to be manually requested after a few billing cycles.

Next, you will be asked to confirm your identity.



Finally, you will be prompted to select a support plan:



There are four types of support plans, and they can be changed at any time.

  1. Basic gives you email and best-effort support on service limit increases but does NOT allow you to open technical support cases.
  2. Developer is for testing and allows you to open a small number of technical support questions with a 12-hour response SLA.
  3. Business Support allows you to open an unlimited number of tech support cases.
  4. Enterprise Support requires a $15K monthly minimum but comes with a dedicated Technical Account Manager (TAM) who provides personal support at any time. I’ve met a lot of the TAMs over the years, and these folks are very smart individuals, so if you are a large enterprise this option is very much worth the spend.

Once you have selected a plan, you will be returned to the console login page:



From here you can use the credentials you provided to login. It may take a minute, but in my experience it is almost always instantly ready to go. Click on Sign in to the Console located at the top right of the page.

Welcome to AWS!



Notice that the account name you chose is displayed in the upper right-hand corner, along with your current region.

Click on the name of your account and select My Organization from the dropdown menu. From here you can click on Create organization and then Create organization again.



Then you will be asked to verify your email address. Just click on the link provided in the email to verify.

Now you have the ability to invite other accounts (Bob from HR probably has one, so does Sally from the infrastructure team), or you can add other accounts as outlined above.



The IAM role name field is optional. AWS Organizations creates this role to grant the organization full administrative control over the new account. This role is created automatically, and this field is simply to rename the role if needed.

Once you click Create, you will see the new account in your Accounts tab.



Wait a few seconds and then refresh the page. The account should be active.

You will NOT get an email to activate the account at this point. In order to gain access to this account, you will be required to go through the password reset procedure again. But before we do that, by default AWS has a service limit of two accounts in an organization, and we will have to request a service limit increase with support. You know you are hitting this limit when you try to add another account and see this error.



Click on Support in the top right-hand corner, and then select Support Center from the dropdown menu.

Next, click on Create case.

Now select Service limit increase and choose Organizations from the Case classification Limit type drop down. Next, under Number of Accounts, select a reasonable amount for your design. In the case description, make sure you include the words Landing Zone. I have discovered that support will deny the request because the MPA is too new unless you tell them this is a Landing Zone architecture (which is multi-account). For the final requirement, leave Web as your selection, and then hit the Submit button. The request will be answered within two to 24 hours.


Before we access the sub account, and while we wait for our service limit increase, there are a couple of things that should be done.

First, click on the Organize Accounts tab at the top of the page.



This section allows you to enable service control policies and organize a hierarchy in your account structure. If you have many accounts, you can organize them into Organizational Units (OUs), and you can also limit the AWS services to which each account or OU has access. Maybe you don’t want a specific account to access S3 or DynamoDB?

First, you will need to enable Service control policies on the right-hand side of the page.


Then you can create OUs by selecting + New organizational unit.


Next, select the NonProd account and then click on Move in order to move it into the new OU.


Now you can see the tree view on the left. Here you can nest OUs under OUs for a full hierarchy as needed. To attach a service policy, click on POLICIES ATTACHED/AVAILABLE on the right side of the page, and then select the policy you would like to attach to this OU. By default, FullAWSAccess is allowed in all sub accounts.



To create a new Policy, click on the Policies tab at the top, and then Create policy.



You can read the Service Control Policies guide at

Lastly, you will want to implement some governance and security controls around your new organization. There are a number of AWS Organizations options we can enable around this, but be aware that some options may mean additional costs.

Click on Settings in the top right corner and scroll down to Trusted access for AWS services.



These are all the services that you can enable Org-wide. I strongly recommend that CloudTrail, Single Sign-On (SSO), AWS Resource Access Manager (RAM), and AWS Config are enabled. If you aren’t familiar with these services, go take a look at their documentation. In order to access the new sub-account that you created, you will need to go through the password reset process.

Go to and click on Sign In to the Console in the top right.

If you still see your master account, click the Sign in to a different account button located below the Sign In button.



Select Next and then click on Forgot Password?

Enter the characters as requested.



Click the link sent to you in the email.


Click on the Sign In button and log in with your new credentials.


That’s it for AWS initial setup and organization design. Once you get an email that your service limit is increased, go ahead and create your other accounts.

I will use this base organizational design on all my future posts.

Regardless of where you are in your AWS journey, Sirius cloud experts can help architect, implement and manage an optimal solution designed to enable and accelerate your business outcomes. For more details on how Sirius can help accelerate your cloud journey, contact a Sirius cloud expert today.

Read Step 2: Enabling AWS SSO >