Creating Isolated AWS Accounts for Testing and Experimentation

Strange as it seems, some AWS users are not much aware about AWS Organizations announced back in November 2016, and how it helps in the creation and use of separate and isolated AWS accounts. Such separate accounts are really helpful to isolate and organize your production, testing and experimentation activities, and to ensure that your production resources are safe from any surprises, while still ensuring that central billing and management at organization level is available.

In short, this means having multiple AWS accounts under which you run your production, testing and experimentation activities, which are billed together under the same organization, but which allows you finer control over access, security and budgets.

Of course one can always create multiple and independent AWS accounts, and also utilize the AWS Free Tier to learn about AWS and experiment with the various services, which offers almost an year with: an EC2 instance, RDS database, 5GB of S3 capacity, and best of all, a million Lambda requests per month. However, that might not work best for organizations with multiple users and teams, although it might be good for a freelancer.


AWS has a detailed tutorial and general documentation on how to convert your current AWS account into an AWS Organization. While reading through the above tutorial is recommended, if you follow through this article, most of the key aspects would still be covered at a high level. The basic step is to select AWS Organizations from your Services menu of your “primary” or “root” AWS account, and then opting to create a new Organization for it — if you have not done so already. We suggest to enable all features of AWS organizations, instead of just consolidated billing. After you have created an AWS Organization, you can create separate and isolated sub AWS accounts — while still under your current billing and management.

There are two ways to get sub accounts. If you already have another standalone AWS account that you have created previously, you can invite it to become a part of your organization; or you can create a brand new account by signing up here, and then invite that as the second step. Else, the second options is to create a new account right from within your new AWS Organization.


Creating a sub-account from within the AWS Console of the primary account

Creating a new account from within AWS Organizations

You need to provide a name for your account and an email address as shown above.

Note:

  1. Sometimes, AWS may limit the number of accounts you can create from within your organization — and if so, create the new account independently and try to invite it. In the worst case, request support to increase your account limit.
  2. If you created the account from within organizations, you will need to reset the account password and set a new password, before you can login to the AWS console under the new account. You will be able to do this via password recovery.

Creating a budget for a sub-account

One of the first things you would want to do with the new sub-account is set a budget, to ensure any costs incurred are limited. For this, you would login to your AWS console under the sub-account (you created or invited), and go to its Billing dashboard, and create a budget. A ‘Cost’ budget can limit your total spend, and you can create an alert when a certain threshold, say 50% of this spend, is reached. Feel free to try out and learn about the other types of budgets and alerts.

Creating a Cost budget in AWS

Creating IAM users under the sub-account

Next, navigate to the IAM dashboard from Services, and create individual IAM user accounts to be used for testing and experimentation. Lets create five IAM users for our example, under the sub-account.

Creating IAM users for testing

Lets add all of these users to a group, say ‘DemoAccountGroup’, and grant them Administrator access via the pre-existing AWS policy. Do not be worried about granting Administrator access, as the access will only apply to the AWS services within the sub-account, but further restricted and enforced by the Organization wide policies we will enforce in a few steps more.

We now have 5 user accounts with AWS keys for our use, with full access for testing and experimentation.

Generated keys and passwords for the test accounts

Inviting an already existing AWS account to be a sub-account under a primary account

Next, lets see how you would invite an AWS account you’ve already created under your organization. To do this, go to your AWS organizations, and select ‘Add account’ and then select ‘Invite account’.

Inviting an AWS account under your Organization

You will then receive an email at your email address provided for the invited account, which will take you to https://console.aws.amazon.com/organizations/home#/invites.

Accepting the invitation to join the AWS organization

Account isolation and management under the root Organization

Next go to your root account of the organization, and you will see the new sub account listed under ‘Accounts’. Now go to ‘Organizational Units’ and create a new Organizational Unit (OU) called ‘Demo Accounts’

Creating an Organizational Unit (OU)

Next, navigate to the Root and select the newly invited account, and select the ‘Move’ link, to bring the newly invited account under the OU we created.

Moving the newly invited account

Next, we need to create the needed Policies to control access. So move onto the ‘Policies’ option, and select ‘Create policy’. Here we can provide a ‘Deny’ policy or an ‘Allow’ policy. For this article, we will use an Allow policy to prevent usage of services such as EC2, and allow only AWS services required for Serverless computing to be used within our Demo accounts.

Allowing a subset of AWS services via a Policy

Now navigate back to Organize accounts and select the Demo Accounts OU and navigate to Policies from the right hand side pane, click Service control policies.

Attaching a Service Control Policy in AWS

Next attach the Demo Accounts Policy we created to this OU, and detach the FullAWSAccess policy attached by default.

Assigning a custom Service Control Policy, and removing the default

Now if you login to the sub account, and try to navigate to its EC2 service from the AWS console, you will see that the permission is denied, although for example, S3 access is being allowed. This way, your Service Control Policy can be enforced over each of the sub accounts, and ensure that your sub-account and its users abide by the organization policy enforced.


This article has been written based on the sub-accounts we have created and used to provide demo accounts to the Sigma IDE for Serverless Computing.