AWS Multi-Account Strategy Case Study
AWS multi-account strategy and implementation for an electronics manufacturer
Background:
A consumer electronics hardware manufacturer with a rapidly growing user base runs the APIs for its products using multiple AWS services. With little devops expertise on staff, they needed someone to architect their services using best practices, improve security and ensure reliability for devices that were increasingly being used in mission critical situations.
Challenges:
The company started with a small development team and each unit built their own product independently. Some services were in AWS and some were with third-party providers like Digital Ocean. They had grown beyond their ability to manage them effectively and with organic growth came configuration drift, decentralized knowledge and security vulnerabilities. With siloed departments that often needed to move independently of each other, a solution that allowed isolation of resources was required. It was equally important to implement an architecture that followed best practices and AWS well-architected principles. Continued growth would require us to create processes and methods they could use well into the future.
Solution:
- Discovery and Future Planning
Previous developers left a patchwork of documentation and the existing team did not know where all the services were. We interviewed each member and reverse engineered systems to discover everything running, how critical it was and who owned it. It was clear they would be adding new resources in the same independent manner as each team worked at their own pace, so we recommended Control Tower, an AWS service to manage a multi-account environment. With individual accounts controlled by a master organization, they could create isolated, secure environments for any product or stage of development.
- Build a Secure, Multi-Account Architecture
Execution consisted of moving the services that comprised each existing product in AWS into its own account. Accounts were isolated by environment so there was staging and production for each product. We rebuilt all the manually created resources using configuration management with CloudFormation StackSets so they could be consistently deployed. Access privileges were defined so users had fine-grained access to only the systems they needed and even non-technical users could be granted privileges to manage their own domain. In this architecture, systems were isolated such that a malicious compromise or errors in one account could not affect any other system.
- Train the new Devops Team
While we were building this environment, the company hired an excellent full-time devops team that fit seamlessly with our plan and working style. As Stern Devops Group consolidated all third-party systems into AWS and finalized the migration to the new accounts, the client teams worked side-by-side with us to learn and deploy the new environments. When the engagement completed, the client engineers had a strong understanding of their new architecture and a smooth handoff was completed.
Result:
The company devops environment evolved from a disorganized jumble of services to a well organized, multi-account architecture that was scalable for massive growth. The client devops team was fully trained in the new systems and supported throughout the transition to autonomous ownership of their new environment.