Serverless Patterns: Creating Deployment Environments in AWS with Organizations

Jacob Orshalick

Deployment environments are necessary for any software project.  Serverless computing eliminates the need to manage or provision hardware, but it’s not immediately obvious how we can safely separate development, testing, and production environments with AWS. AWS Organizations provides a simple, secure, and effective way of managing your deployment environments.

Deployment Environments with AWS Organizations

When you create your first AWS account, the Control Panel makes it easy to get started with your first Lambda and some DynamoDB tables to support it.  But, what happens when you’re ready to release something to production for general use?  We need environment that looks something like this:

Fig. 1: Standard Deployment Environments

The creation of multiple environments is a necessity in any product that you plan to release. I will get you up and running quickly here, but if you want an in-depth answer to this problem, you can read this AWS whitepaper. In summary:

Using multiple AWS accounts to help isolate and manage your business applications and data can help you optimize across most of the AWS Well-Architected Framework pillars, including operational excellence, security, reliability, and cost optimization.

AWS Docs

You can setup entirely different AWS accounts, or you can use Organizations to create these accounts.  As a developer, I like hierarchies and structure.  It just makes things so much easier to understand and can help simplify something that’s complicated.  The AWS explanation of Organizations is:

AWS Organizations lets you create new AWS accounts at no additional charge. More easily allocate resources, group accounts, and apply governance policies to accounts or groups.

AWS Docs

With Organizations you can visualize each account you create as analogous to an environment:

Fig. 2: AWS Accounts as Environments structured under an Organization.

In fact, when you login as a newly created account, you’ll notice that any Lambdas, DynamoDB tables, Cognito User Pools, really anything you’ve created in another account won’t be there.  This account is effectively a fresh environment, ready to be setup.

Some quick advantages to this approach over creating completely separate accounts:

  • Your accounts (i.e. environments) can all be seen in a hierarchical view in one place.  This makes it easy to know what environments exist and how they are accessed.
  • All billing rolls up to the Organization level allowing you easier management of AWS costs.
  • Later you can define shared security policies and other configurations that apply to all environments at the organizational level.

Now that we understand what needs to be done, let’s see how we can do it.

Setting up an Organization

The first step is to create your Organization.  Simply search for AWS Organizations at the top of the console and navigate there.  If you haven’t created an Organization yet, you will see the following screen.  Simply click, “Create an Organization” to get started.

Fig. 3: Creating an Organization in the Control Panel.

This will initially create a Root Organization with your current AWS account as the root management account.  To create an Organization for your environment accounts, do the following:

  1. Select the checkbox for the Root Organization
  2. Expand Actions and select “Create New” under Organizational Unit
  3. Now enter the information for your Organizational Unit

Fig. 4: Creating an Organizational Unit in the Control Panel.

Setting up your Accounts

Now back on the AWS Accounts screen, you can start creating the Accounts for each environment.  Select the “Add an AWS Account” button and fill in the information under the “Create an AWS Account” tab:

Fig. 5: Creating an AWS Account within AWS Organizations.

A couple of pro tips here:

  • Name your accounts according to the environment it represents (e.g. my-company-dev, my-company-test, my-company-prod).  A naming convention makes it clear what company and environment each account represents.
  • Each account requires a unique email address.  I like to use my email address appended with a number (e.g. jacob+1@company.dev, jacob+2@company.dev, etc).  This will go to your standard email and you can setup a rule for these emails to go to a specific folder for organizational purposes.

Now you can organize these accounts into the Organizational Unit you created. On the AWS Accounts screen:

  1. Select the checkbox next to the accounts you just created
  2. Expand Actions and select “Move”
  3. Check the Organizational Unit you just created and select “Move AWS accounts”

Fig. 6: Moving environment accounts under an Organizational Unit.

Now your Organizational Unit will look something like the following with all of your accounts organized underneath.

Fig. 7: The Organization to accounts hierarchy in AWS Organizations.

Login to your Accounts

This one baffled me the first time I went through this process.  I didn’t receive an email or any login information for the accounts I just created.  The solution is simple:

  1. Logout of the Control Panel
  2. Start the login flow with the email address of one of your newly created accounts
  3. Use the “Forgot Password” link to receive a link to change your password
  4. After changing your password, you can now login

Next Steps

Now that we have our Organizational Unit and Accounts setup, we can deploy our code.  Doing this through the Control Panel is not only tedious, but error prone.  It’s possible to automate the creation of your Serverless components, Lambdas, DynamoDB tables, Cognito User Pools, etc. In my next Serverless Patterns installment, we’ll walk through using CloudFormation to automate your environment setup.

Learn more:

Follow me to get notified when my next installment is released.