Unlocking cloud success: Why a multi-account strategy is essential for innovation, security, and cost optimization .

I have a customer I’ve worked with for a while now. They have their business-critical applications in the cloud - in a single account.  This has kind of been doable until now, but the cracks are starting to appear.  We’ve talked about implementing changes on numerous occasions, but the time has never been right for the customer.

Anyway, it’s been top of mind recently, so I thought I’d somewhat summarize.
 

Why a multi-account strategy is crucial for cloud success

We’ll use AWS for the sake of this article, but the principles are transferable.  As with building a home, you need a solid foundation. In the cloud, this means following several best practice concepts and getting some technical cornerstones in place early. One such principle is that of multiple accounts within your environment.

By default, you start with a single account (a logical container of your infrastructure, applications, and data). Initially, you may begin your journey with a simple web application (frontend, business logic, persistence layer). For a while, the development team is building together, using new services as they see fit. Soon enough, colleagues from elsewhere in the organization are invited to start testing.  Things go well and the application is made publicly available to customers. Still utilizing the same, single, account.

Weeks pass and the business has ideas for new functionality.  The dev team get to it and start building.  Changes are deployed and bang - the application goes down for customers.  The new feature changed the data model breaking existing functionality.  Had a multi-account strategy been followed from the start - an account for Dev, one for Test and a third for Production - the issues above would have been confined to Dev - with no impact on customers.
 

The power of multi-account environments: innovation unleashed

The ability for organizations to innovate quickly is linked to the foundation they build upon. Speed is of course an important parameter.  The separation of Dev/Test/Production allows for quicker iterations and more experimentation - without the fear of sinking Production.  This type of agility is critical.

Another crucial aspect of a multi-account strategy is the opportunity created for development teams to manage their own resources, tools, work process etc.  This can result in faster decision making and a greater sense of ownership of the products being built.

Then there is the ability to scale based on demand, without the risk of impacting other applications/accounts…

The story does not stop with innovation though.
 

Enhancing security: benefits of isolated cloud environments

By default, no access is allowed between AWS accounts. What happens in Test has no impact on Production. By implementing isolation of environments, we can significantly lower the risk of unauthorized access and the potential for security breaches, accidental changes, non-production ready code etc.

In addition to the segregation of our environments, we can implement additional best practices in regard to Identity and Access Management (IAM) policies where, amongst other benefits, we ensure the principle of least privilege is applied as appropriate in each account.  This helps to reduce the overall attack surface of our applications.  Depending on the business needs/requirements from regulatory bodies (applicable to some industries) we also benefit from numerous tools and features that provide auditing capabilities on-tap.
 

Cost optimization made easy: multi-account tracking and forecasting

The cloud can offer incredible opportunities for reducing the overall costs associated with building, running and supporting applications over time.  However, that doesn't mean we can take our eyes off the ball.  Active cost control and optimization is an important part of running workloads in the cloud.

We’ve talked about our accounts in terms of “environment” - it could just as easily have been “Marketing”, “HR”, “Sales”. Running a multi-account strategy allows for precise tracking of costs per environment / product / department in the organization.  We can also forecast costs and implement budgets in a highly transparent fashion.
 

Getting started: implementing best practices with Epical's landing zone

How you go about implementing the numerous best practices prescribed by AWS, or Microsoft, or Google, is well documented. It requires a level of technical know-how not possessed by all organizations. There are also exceptions to every rule - slight adjustments to the recipe - which are learnt over time.

At Epical, we have baked these best practices and lessons learned from countless customer interactions into our own “Landing Zone” implementation. To quote AWS, “A landing zone is a well-architected, multi-account AWS environment that is a starting point from which you can deploy workloads and applications. It provides a baseline to get started with multi-account architecture, identity and access management, governance, data security, network design, and logging.” (1)

Our Landing Zone is helping customers be innovative, secure and cost optimized on a daily basis. Don’t take my word for it - listen to our customers instead.
 

Need guidance? Let's talk multi-account strategies over coffee?

If you would like to know more about how a multi-account strategy could help your business, or you are curious about Epical’s Landing Zone concept just drop me a line. 15 minutes + a coffee is a good place to start. 
 

Author
Tom Lehane, Manager within CODE at Epical
tom.lehane@epicalgroup.com
LinkedIn

References
1. Creating a landing zone, AWS