AWS Cross Accounts Access: Part 1

Here at Flux7, as AWS partners, we perform hundreds of AWS account reviews and we always start at the same place: AWS Account Architecture.  The reason is as simple as it is critical; properly setting up AWS accounts can be a game-changer, particularly for enterprises with many teams helping to bring solutions to market.


Starting with the right architecture that is designed to fit your technology and business needs can make all the difference in ensuring security, compliance, operational efficiency and creating a development environment that inspires innovation. As a result, let’s kick-off this article in the same place we kick-off our assessments, with AWS accounts.

What is an AWS account?

To access any AWS web service, you must first create an AWS account at http://aws.amazon.com. An AWS account is simply an Amazon.com account typically associated with a payment instrument (credit card or invoicing) that is enabled to use AWS products. It is also called root or master or parent account and you should not confuse it with creating user accounts in an AWS account. These user accounts are called Identity and Access Management (IAM) accounts.

When you create an AWS account, you can sign in to the AWS Management Console and access a variety of AWS services, view your AWS account activity, view usage reports, and manage your AWS Security Credentials.

While most users start with creating a single master/root/parent AWS account, you can also create separate AWS sub-accounts (child) and link them to a master account for payments. There are trade-offs between using single or multiple accounts.

Using IAM Users and Groups within a Single Account

Single Account is the simplest way to get started in AWS. You create an account and start spinning up services. You can create a single account per application and then use IAM users, groups, and permissions to manage permissions for development, test, and production environments or for one or multiple projects. This simplifies the task of managing users and permissions and simplifies the user’s experience of working with applications.

AWS provides a few benefits when  running your entire load in one account:

• Tag your resources: AWS lets you tag most resources with key-value pairs, and further allows you to utilize those tags for configurations and billing. This means that you can easily label a set of resources as belonging to project A or project B. For example, you could tag all your production EC2 instances that run <application 1> as “App1-prod”. The instances in your test and development environments could be “App1-test”, “App1-dev”, etc. You can then assign different permissions to different IAM groups to make sure only a subset of your administrators has permissions to resources in the various AWS environments.
  
• Size up your apps: Size in the sense of how many resources (EC2 instances, RDS, IAM configurations, etc.) does each app need? If the number is small, and you don’t expect it to get large, you can easily get away with running all of them on a single account.
• Share resources across applications: Do your two apps really need two distinct RDS instances? You could instead run one instance with two (3, 4 … n) databases configured on it. The same goes for your EC2 instances. If your apps are not consuming significant server resources you can place multiple apps on a single server (Docker is great for this) and save the costs and management overhead of two servers.

However, this single account approach does not offer you the benefits of billing and control separation.

Using Multiple Sub-Accounts

Many customers start by creating separate AWS accounts for each environment for each application. This helps create strong separation between all resources in each account:

• Separation of costs: what you pay for in infrastructure costs related to various projects. Separate accounts are the way to do that because not all AWS services are separate. AWS is making leaps and bounds of progress to generate billing accounts but not all services are separable. If you want a P&L item, simply put in separate accounts. Want to know R&D costs vs operations? Make separate accounts. If you have ten different apps, and one of them becomes a huge hit that you want to sell, then having it in its own isolated AWS account will make your life much easier.  Consolidated Billing will simplify paying for everything. You can just have lots of AWS accounts to isolate billing to individual projects, and then link these to one parent account with AWS consolidated billing.
  
  
• Separation of responsibilities: Unlike permissions for a parent or single accounts, you cannot specify granular permissions for specific instances within sub-accounts. You can only set permissions to an entire account. That means if you have permissions to delete servers, you could delete any server, not just the ones you are managing. For example, if you only work on app A, you could delete the server for app B. Maybe you don’t want that, you want to separate development and production boundaries. Or by app duties.
  
  
• Developer freedom: developers desire the agility to create/ delete servers, but IT understandably doesn’t want development to delete production servers. With AWS sub-accounts, you can give developers their own account and if something goes wrong it will not affect operations.  Multiple AWS accounts help keep a clear separation between development and production resources. Having multiple accounts helps ensure production applications are stable, secure, and there is less chance that a new developer accidentally clicks the wrong button and brings down the application.
• Simple Email Server (SES): Sub-accounts are especially useful if you are using AWS SES. They can keep your spam/bounce rate low if you are sending a lot of emails (say, in the millions). Indeed, it is one of the best practices mentioned in AWS SES documentation. For example, you might send marketing emails from one account and transactional emails from another account, or you might use separate accounts to send an email on behalf of different clients.

However, this multiple accounts approach can create operational challenges.

• Extra overhead: For example, if you have separate AWS accounts (development, test, and production), you will need to re-create IAM users, groups, and policies under each account in order to manage user permissions. As you create additional applications, the number of accounts, IAM users and credentials can be difficult to manage.  
• Extra user management: Just as there is additional overhead to manage the accounts, users experience extra overhead, too. Multiple sub-accounts can be inconvenient for employees who need to work in all three environments and then have to sign in to each account separately.  
• Logistical: Additionally, if you are working in one account, and want to go to another, you must log out. If you need to compare, this can be hard, since you can’t put side by side and view.
• Billing: Using multiple accounts might also mean that you need to consolidate billing across your accounts to aggregate costs for the entire application. In this example, we’d need to consolidate billing for our three accounts, development, test and production.
• Configuration (mis) management: Spreading your apps across multiple accounts adds an extra dimension of configuration overhead. There will be two sets of AWS keys you need to maintain, and ensure that each app consumes the right one. You will have to configure twice as many VPCs, etc. and then maintain them. One of the biggest sources for bugs in production in the cloud is configuration mismanagement.

While there are pros and cons to both single and multi-account approaches, we most often recommend a hybrid, multiple account strategy that maintains as many of the benefits from both scenarios. And, indeed, this has been achieved with a new feature introduced by AWS called Cross-Account Access.

In our next installment, we’ll discuss this new feature in-depth and explore what a multi-account approach could look like.