In the previous blog post, we looked at the core principles of establishing a successful cloud foundation – the pathway to Public Cloud victory. These principles investigated both the business and technical aspects of success, with one technical aspect covering the ‘AWS Platform’.
In this post, we dive deeper into the AWS Platform concept and look at some best practices and considerations for defining an AWS account ecosystem. As we elaborated in the Cloud Foundation discussion, business outcomes and requirements should drive the technology selection and decisions – think of both riding the stagecoach of strategic success, with business being in the driver seat and technology riding shotgun. For this same reason, choosing your AWS account ecosystem is based on several business factors, and although best practices offer guidance, your unique position and future aspirations will guide the AWS account definition process.
Let us explore some of the common consideration categories when defining an AWS Account strategy. I use the term categories deliberately here as each of these have more aspects that will ultimately define a best-fit multi-account strategy.
Billing: Many small to medium enterprises have a requirement for billing isolation to allocate costs to a specific business unit (BU), environment, application, or project cost centre. In these scenarios, it is a good starting point for defining the multi-account strategy. Smaller organisations may not require such isolation, however, should be considered to ensure the multi-account strategy offers longer term benefits.
Team or Organisational Structure: One of the most debated considerations for choosing a multi-account strategy and although somewhat related to billing, the team structure adds another axis to the decision tree. Let’s consider an organisation where each business unit run dedicated accounts for billing purposes and encourages autonomy across their project teams. To enable as much autonomy, there may be a good reason to isolate each team within a dedicated AWS account and offering each team a playground or sandbox to experiment in.
Security or Compliance: When certain applications process Personal Health Information (PHI) or credit card information (requiring PCI Compliance) – would it not be far more efficient to point your QSA or penetration testing vendor to a dedicated AWS-account? These dedicated accounts will enable security teams to focus on the necessary controls and detailed data-access threat-models, rather than having to apply all the stringent security controls across every moving part of a single-account ecosystem. This will not only make your architecture approval process simpler and streamlined, but also enable and encourage innovation within other areas of the organisation.
Workload separation and SaaS services: In the scenario where you have a high-performance workload that processes events through various event-driven AWS Lambda pipelines that should not be impacted by service limits and concurrent Lambda execution thresholds utilised by other applications, you may have a very good use-case to isolate this workload in a specific AWS account. Another key consideration is where you make use of SaaS services such as Databricks or Elasticsearch that require elevated permissions to deploy and manage infrastructure in your AWS account. In this scenario, your security team and compliance auditor will be more forgiving when these SaaS vendors have been given keys to only one room and not the whole castle.
AWS furthermore offers extremely powerful mechanisms to allocate costs through fine-grained reports and filters using AWS resource tags, and although very rich in function it may not be the easiest mechanism for cost allocation on large and diverse sets of workloads across an enterprise. A second aspect to consider is that not every type of resource supports tagging for detailed billing.
A quick scan of the above-mentioned categories quickly reveals that each cannot be considered in isolation but do weigh-in on the most appropriate AWS account structure for your organisation.
Account Management
You may be thinking that managing a mountain of AWS accounts may seem like a daunting task? The good news is that AWS offers various techniques and tools to facilitate management of multiple accounts should you need to expand your account horizon.
In this blog, we will be focusing on AWS Organizations to make this job a little bit easier. AWS Organizations can be used on its own and it also forms the basis of any other multi-account solution offered by AWS. These capabilities are also continuously being improved to meet customer requirements. Ensure to keep an eye out on any updates on this front.
AWS Organisations
AWS Organisations is a service that assists platform teams to manage various aspects of a multi-account ecosystem, covering the creation, grouping, and permission aspects of accounts. With AWS Organizations you can construct a multi-level organisational-unit structure to manage base-level permissions, called Service Control Policies (SCPs) and thus ensure that only certain services or actions can be executed within an AWS account. A typical structure of an AWS organization is depicted in the diagram below.