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 Organizations
AWS Organizations 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.
At a high-level, AWS Organizations offer the following benefits and capabilities:
- Consolidated billing for all child-accounts into the root (or master) account with detailed reporting offered to determine actual spend per account.
- AWS accounts can leave or become part of an AWS Organization should business structures change, or certain projects or divisions be acquired by another enterprise.
- When aggregating the usage of all the member accounts across a larger enterprise, certain volume discounts become very favourable. Consider all the egress-data traffic, or S3-storage being utilised in each account. Another benefit is the optimal utilisation of Reserved Instances (RIs) across the member accounts or make use of Saving Plans. Savings Plans is a brand new service launched in November 2019, offering up to 72% discount on the premise of you committing to a certain amount of compute-usage or dollar-spend.
- Several AWS Services, such as AWS Firewall Manager and AWS CloudTrail integrates neatly with AWS Organizations to offer a single pane of glass for audit and security related activities.
AWS Organizations is not a must have for every multi-account scenario. If you are in the position where an AWS Partner is performing your AWS bill management as part of your Managed Services arrangement, many of the day to day challenges with billing across multiple accounts may have already been taken care, which does make AWS Organizations a less essential requirement from a billing perspective.
Conclusion
The advice we can offer is to not generate a war-and-peace multi-account strategy when you start out. If you are unsure or would like a second opinion to validate your multi-account strategy, reach out to our professional services team to offer expert advice in cloud foundation journey. Although not a walk in the park as the saying goes, with a little bit of effort your organisation will benefit greatly from a well-defined multi-account strategy.