Cloud Landing Zone

Summary

The customer needed an approach that would allow them to maintain a central definition of their entire cloud platform as code, and provide a robust, versioned deployment pipeline. Implementing a Landing Zone for their cloud platform would enable their utilisation of the cloud to grow without creating an additional burden of management for each additional account or resource. A solid deployment pipeline would also have to be incorporated to provide assurance of conformity and security for the landing zone's automation.

The Challenge

A complete picture of the current deployment practices had to be painted in order to correctly implement a suitable landing zone. The customers particular requirements had to be understood so that a customised landing zone solution could be designed and implemented. The current practices had to be fully documented to ensure that nothing would be missing from the new implementation. Furthermore, the new architecture was designed to encompass all the current features of the customers environment while incorporating a new way-of-working based on the GitOps paradigm - every change to the super-infrastructure or its components should be initiated from the code repo acting as a single-source-of-truth. Using the framework of the AWS Landing Zone solution, an appropriate design for their current and future infrastructure was drawn up.

During the implementation of the landing zone, several issues were encountered that added challenges to the project. Many of the baseline resources utilised in the customers accounts were using cloudformation incompatible AWS API calls, so a way had to be found way around that. In the end, custom resources were heavily utilised to provision the necessary resources and configurations, which required careful design of the resource CREATE, UPDATE and DELETE methods to ensure that proper idempotency was maintained throughout.

Some of the baseline resources required a synchronised procedure of steps with core accounts. In order to maintain the immutability and idempotency of the baseline resources, this was provisioned using cross-account roles, allowing the baseline resources to be self-contained resource definitions.

The existing code repository of the customer did not provide or integrate well with any suitable CI/CD tooling, so the code repo was moved to a self-hosted Gitlab server. This meant that Gitlab's native CI/CD could be leveraged to complete the deployment pipeline, using several custom-made components to complement the customers particular use cases.

The Solution

The final implementation of the Landing Zone allowed the customer to provision new accounts in a simple way using an Account Vending Machine. This collection of lambda backed custom resources allowed the automated creation of AWS organisation accounts which had a baseline of AWS resources. These baseline resources provided for such things as:

• Managed account access via ADFS single-sign-on
• A choice of several default network topologies e.g. VPC with 2 private and 2 public subnets
• Several baseline security measures e.g. AWS Config rules, IAM boundary policies, Guardduty