It’s worth repeating – no AWS solution, service, or framework is going to fulfill all your Landing Zone needs as-is. Every customer is different, and every use case requires in-depth analysis, leading to custom implementations. The good part of all the services and frameworks is that they might be limited in what they do, but they do it well. So, it will always help to think of them as complementing technologies that can be wired together to build up your Landing Zone. To take a concrete example, the AWS Control Tower service will help you build the initial 30-40% of what every company needs in less than an hour. You then need to focus on coupling this service with another framework that helps you build the remaining 60-70%.
Ideally, the only code that you should be developing yourself is an orchestrator across all these services and frameworks while leveraging the best of what they can offer.
On the other side of the spectrum, some organizations are heavily invested in technologies such as CloudFormation and Terraform. Depending on their expertise and comfort level, they might alsodecide on building the entire Landing Zone from scratch, which is also fine, so long as they are clear on the tradeoffs between maintaining those frameworks on their own and more control that they will benefit from in the long run.
Invest in building an Account Vending Machine
When it comes to managing the Landing Zone as code, most organizations focus on building the IaC layer, which directly interacts with the cloud provider APIs and deploys resources into the AWS accounts. They miss two key things as part of the overall foundation they are building:
- First is the over-arching layer that integrates this framework with existing tools and processes within the company
- Secondly, overlooking the fact that there is a life cycle associated with the entire IaC layer, it’s never a one-step thing
Even before IaC deploys something into the account, certain prerequisites must be met. After the accounts are provisioned, you might need some post- installation procedures to be carried out, which might deal with notifications, ticket closures, or anything else. This is where the concept of an Account Vending Machine (AVM) comes in. It takes care of these two requirements and acts as a glue between the organization processes, actual IaC itself, and the stages in the life cycle of AWS account management. Its core responsibility is to vend accounts as if they are coming out of a factory and immediately ready to host production-grade workloads. Let’s see an example.
Enterprises typically have ticketing processes or some other mechanisms using which AWS accounts are requested and approved. Some examples are ServiceNow, Jira, or a home-grown custom solution. Once the requests are in, you will want an event-driven invocation of the AVM, which you can do by passing a payload that reflects the input from the ticketing system. The AVM then manages the life cycle of the account creation process, starting with ensuring that prerequisites are in place, deploying resources via the IaC stack, and finally carrying out post-deployment procedures.