A lot of integrations that previously had to be built out manually are now natively supported by many AWS services. While this greatly improves the development velocity, it also leads to less maintenance of code and an increase in efficiency. Landing Zone implementations heavily depend on services such as AWS Step Functions , AWS Organizations, Lambda, and IAM, to name a few. In recent times, AWS Step Functions, a workflow management service, has launched native integrations with AWS Organizations, Lambda, and many other services. So, an action such as moving an account to a different OU, which previously required a Lambda function to assume a role in the management account, can now directly be executed by AWS Step Functions, without you having to write any code.
Sending out platform notifications is another example where the developers had to leverage a combination of services such as Lambda, events, SNS, or SES. With AWS User Notifications, you can leverage automatic notifications for selected EventBridge events, and the entire responsibility of event capturing, payload parsing, and notification triggers are offloaded to the service. It sends out notifications on multiple channels, such as Microsoft Teams, Slack, and Email.
Having discussed a few best practices when building out your Landing Zone foundations, let’s discuss what this looks like in practice when combining a service such as AWS Control Tower with CfCT, an AWS-offered solution for deploying resources across multiple accounts.
Building a Landing Zone with Control Tower and CfCT
AWS Control Tower gives users a jumpstart in establishing their Landing Zone foundations, in contrast to building everything from scratch. Starting from a basic OU structure to host the security and workload accounts, it offers an account factory – an abstraction on top of Service Catalog that is used to create new accounts and provision resources in them. From a logging and security standpoint, it automatically rolls out organizational trails with AWS CloudTrail and also aggregates the compliance status by leveraging AWS Config’s features. At its core, it orchestrates account-related activities across several other AWS services to realize the benefits of a multi-account structure. Furthermore, it defines a security and compliance baseline that is composed of AWS Config rules, IAM policies, and SCPs. These sane defaults block actions such as making an S3 bucket public, disabling CloudTrail logs, or switching off Config recorder logs, thereby ensuring a good security posture out of the box.
For enterprises that are just getting started with building their AWS foundations, AWS Control Tower does a lot of heavy lifting for them and reduces the implementation effort and time. Others, who are more hands-on and well-versed with the AWS technology stack, might still decide to go ahead and build a customized version of the Landing Zone as it gives them more control and choice of tooling. This is because, as a service, Control Tower on its own doesn’t do much. It’s based on the best practices that most customers follow when establishing a cloud structure that can be safely used to launch applications with the least resistance and delays. For account management, it depends on AWS Organizations, for policies, it depends on SCPs, and for compliance, it depends on AWS Config; deploying resources in target accounts is entirely offloaded to CloudFormation. To benefit from the readymade prescriptive foundation that it offers, it is still a good idea to use it for that and fill the gaps with another deployment solution or framework that complements it.
At the time of writing this book, there are also some areas where the service doesn’t shine as much. Due to its lack of API support, I would suggest exercising caution before building any hard dependencies on the service for features that require frequent invocations. Carrying out actions over the web console simply does not scale, and you need to give someone access to the management account (the service can only be deployed there), which is not desirable. It’s important to highlight that the service operations are single-threaded, which means they can only work on one thing at a time. This limit does not exist for some features, such as account requests, where you can go up to a maximum of five, but these limitations can be a blocker for some organizations that are going to provision and manage accounts at scale.