AWS Account Structure Strategies for Enterprises

Enterprises typically need a multi-account strategy to support the requirements of running their AWS ecosystem. It’s important to set up the accounts in a consistent fashion at the start, to ensure simple management and tracking of many AWS accounts in the future. 

After you have rushed out and created that first AWS account (to gain an understanding of AWS and play with Lambda!), it’s important to take some time and decide how many AWS accounts are needed and for what purpose they will be used. AWS account strategies need to be tuned to an organization and fit with its current and future needs.

Before examining the possible strategies, let’s remind ourselves: an AWS account is the complete logical grouping of resources on AWS. Effectively, each account is an independent customer on the AWS platform. The AWS account is the first thing you create to access AWS capabilities. From there you can build and deploy virtual resources on AWS, whether a single EC2 instance or 10,000.

When deciding on your account structure, it’s good to first consider a few factors. As companies scale, if they’re lucky, they’ll create a Cloud Centre of Excellence to make the big decisions about the organization’s account strategy and tagging strategy.

But if you’re just starting out, it’s good to chat with your development teams about what they think their needs are before you get too far down one road or another. If you end up with too much in a single account, it can be hard to work out who ‘owns’ what. But if you have too many accounts, things can get a bit fast and loose and that can be even harder to manage. Here are the main strategies and considerations when setting your strategy.

1. One Account (to Rule Them All)

Having one account is simple to set up and easy to administrator at first. You create whatever you need in one spot, there’s very initial overhead when setting things up. It’s a bit like using Microsoft Excel to manage your inventory. If it’s just you and one other person, it’ll probably be good enough for what you need. But what happens as your organization's use of AWS grows? Do all services end up in the one AWS account? Both production and non-production services? Having one account can lead to several risks and limitations.

Concentration Risk

If the account is compromised for any reason, all your AWS services are vulnerable. Maybe you back up your application data to S3 in the same account as your application’s servers. If the account is compromised, the intruders can delete your backups and servers, leaving you without any protected copies of the application data.

Service Limits:

Each AWS account has a set of Service Limits. While you may never hit these limits, the probability increases as more teams use the account. Many of the limits can be increased, but this can take time to be uplifted (generally up to 48 hours), and some limits cannot be raised. Hitting the “security groups per region” limit during a production deployment is not a great place to be. If your production and non-production systems run the same account, API rate limits can affect the production workload. Non-production accounts often have a higher level of change occurring within the account, making it more likely to hit a rate limit. Service Limits should be set to provide cost, service and geographic restrictions. If many teams share one account then the limits have little protection.

Permission and Visibility

Permissions and restrictions isolate team services, ensuring that other teams cannot control, change or view another team’s services. In a single account, these rules can become complex to define. Additionally, some services are shared on the AWS platform and cannot be isolated to a single team. Configuring large permissions policies often leads to unnecessary complexity and often in this complexity the ruleset becomes less effective.

Cost Allocation

When all application teams are in the same account, cost allocation is more difficult. It is hard to track untagged servers down to a cost center. It’s much easier to have a single accountable cost center owner that absorbs any unallocated cost in their own account.

Ownership

If your tagging isn’t very good, besides having issues with cost allocation, you’ll also have problems with ownership and accountability. Who is responsible for the EC2 that’s costing 6k a day? If we nuke it, will it break something else? Who should we even ask before nuking?

The one account model can be manageable at the start, but ongoing it tends to become analogous to putting “all your servers in one basket”.

2. Accounts, Accounts, Accounts for Everybody!

The polar opposite position to using one account is to create accounts for any purpose, enabling teams to create their own accounts, and having a large number of accounts around the organization. This approach is great for isolation, innovation, and enablement, but can lead to its own issues.

Account Sprawl:

An organization with so many accounts soon becomes difficult to manage and support. With many accounts, support and engineering teams need to understand which accounts to deploy into, the limits need to be managed for each account, and account ownership can become fluid, especially in the case when an organization reorganizes. Accounts may become abandoned as projects end, initiatives lose momentum, or people move on to other areas.

Networking

It’s unlikely that AWS accounts are used in isolation and for enterprises it’s unlikely that many of the services will be public facing. This creates the issue that each account needs a VPC, with a routable interface to the corporate network and a defined set of IP addresses that do not overlap an existing range. It can be very easy to create a new VPC in AWS, but it can take much longer to connect it to the corporate network, or peer it with another AWS account. If you have too many AWS accounts and require VPCs in each account, the overhead to set up and manage through a networking team can become a challenge.

3. Accounts with Purpose

This method is a little from column A and a little from column B. We don’t create new accounts just because someone asks for one, we do create one where it makes business sense to. Here, organization-wide accounts are used to collect and isolate critical datasets. For example, CloudTrail, AWS Config, Application backups, Programmatic billing and Consolidate billing reports. These accounts tend to not run any services, rather they collect and store the critical datasets generated in and by AWS.

Application services can write to this data, but they cannot delete the data. Access to these accounts should be highly restrictive and the deletion of data should be protected with MFA. They shouldn’t run any operational systems.

Control Group

Often one control account can cater for all the data. Organizations may split up the Control Group into an audit account, a backup account and a finance account, to enable granular control of the accounts by the respective teams. The Control Group accounts are fixed in nature and do not grow over time.

Ops Group

A set of accounts that host enterprise wide services. These services are analogous to common infrastructure services, such as forward proxies, reverse proxies, DNS services, Active Directory, Malware Services, Centralized logging, termination of the DirectConnect interface, etc.

It is common for two or three AWS accounts to make up the Ops Group of accounts. A production account servicing the other production accounts, a non-production account servicing the other non-production accounts, and a build account for AMI baking and other infrastructure only build tasks. The Ops Group of accounts are fixed in nature and do not grow overtime.

Service or Domain Group

Service or domain accounts host the application workload, such as the organization's websites or CRM system. These accounts grow with the demands of the enterprise, with new accounts being added as different areas of the organization are migrated to AWS. Determining what defines a service account needs to be defined within an enterprise. Here are some tips:

• Don’t link it to the organizational structure.
• Try to have one senior manager as the accountable owner.
• Try to group similar applications together.
• Don’t create too many.
• Don’t create them all at the start. Create the ones you need, and add new accounts as the need arises.

Service accounts generally consist of two or three AWS accounts, a production account, a non-production account and a build account. The build account can be optional, it is used to test and define application infrastructure scripts before releasing into non-production.

Unmanaged Group

Unmanaged accounts are useful for containing proof-of-concepts, individual accounts and other special purposes. Generally, they should have little overhead from the organization and have fewer controls in place. For example, the unmanaged accounts may be able to directly connect to the internet, but not the corporate network. This accelerates the PoC or pilots, while limiting the enterprise exposure. These accounts should not contain any critical data and only stay around for the short-term.

In Summary

These account strategies can aid you in setting up your AWS account structure to ensure it is manageable in the future. Having a clear structure will ensure that you have ownership, accountability, and that you can control your costs and protect your organization's data and service. Just because you settled on the ‘right’ strategy a month or so ago doesn’t mean that’s going to be the ‘right’ strategy forever. As your organization’s AWS strategy matures, it’s important to review your decisions to make sure they still meet your needs. Changes in business structure, acquisitions or divestments are great opportunities to assess what’s working, what’s not and how you can improve things.

Whichever strategy is ‘right’ for you right now, Stax will help make the task of governance and maintenance easier. Good luck strategizing!