AWS Account Strategies for Enterprises

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 sometime and decide how many AWS accounts are needed and for what purpose. AWS account strategies need to be tuned to an organisation and fit with their needs now and in the future.

Before examining the strategies, it’s important to note that 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. An account could have 1 EC2 instance or 10,000.

When deciding on your account structure, it’s good to consider a few aspects –

One Account (to rule them all)

Having one account is simple and easy to administrator. However, what happens as your organisations 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 comprised all your AWS services are vulnerable. An example could be, you backup your application data to S3 in the same account as your applications servers. If the account is comprised, the intruders can delete your backups and servers, leaving you without any protected copies of the application data.

– Administrative overhead, having many teams operating in the same account can lead to additional management overhead and complexity. Many different teams operating in the same account can lead to effective chaos when trying to understand which teams are using which resources. Tagging polices can help with this, as long as all the teams abide by the policy. The same policy. The increased administrative overhead tends to require a central team to managed permissions, which increases lead times for the application teams operating in the account and adds low value tasks to the central team.

– Service Limits, each AWS account has a set of Service Limits, http://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html.

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, 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 effect 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, the permissions and restrictions to isolate team services, ensuring that other teams cannot control, change or view another teams services 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 polices leads to 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 difficult to track untagged servers down to a cost centre. It’s much easier to have a single accountable cost centre owner that absorbs any unallocated cost in their own account.

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”.

Accounts, Accounts, Accounts for everybody

The contrary position to having 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 organisation. This approach is great for isolation, innovation, and enablement, but can lead to these issues.

– Account Sprawl, many accounts become difficult to manage and support. With many accounts, support and engineer teams need to understand which accounts to deploy into, the limits need to be managed for each account, account ownership can become fluid, especially in the organisation re-organises. Which they never do! Accounts may become abandoned as projects end, or initiatives loss momentum.

– 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 fast to create a new VPC in AWS, but can take a much longer period 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 setup and manage through a networking team becomes a challenge.

Goldilock Zone

The AWS account strategy tends to become a practice to fitting the right number of accounts to your organisation. You want enough accounts to enable isolation and encourage innovation, but not too many accounts to cause operational headaches.

Below is our approach to defining the account strategy for an organisation. It starts by grouping the accounts together and defining their purpose.

Control Group

Organisational wide accounts used to collect and isolate critical datasets. For example, CloudTrail, AWS Config, Application backups, Programmetic billing and Consolidate billing reports. These accounts tend to not run any services, they collect and store the critical datasets generated in and by AWS. Application services can write the 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.

Often one control account can cater for all the data. Organisations may split up the Control Group into a audit account, backup account and 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. Theses services are analogous to common infrastructure services, such as forward proxies, reverse proxies, DNS services, Active Directory, Malware Services, Centralised 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 organisations websites or CRM system. These accounts grow with the demands of the enterprise, with new accounts being added as different areas of the organisation are migrated to AWS. How to determine what defines a service account needs to be defined within an enterprise. Here are a couple of tips:

– Don’t link it to the organisational 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 organisation and have less 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.

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 and accountability, can control your costs, and protect your organisations data and service.