The Organisation’s Control Tower Managed Landing Zone Is Finally Here. What More Is There to Think About?


Enterprises and organisations have been having exciting journeys on modern clouds. In recent years, Governance at Scale (G@S, or GaS as an immediately memorable name!) is something many organisations have been seeing tremendous values in. By introducing automation in areas like account management, policy enforcement, security controls, budget and resource management, G@S helps to drive down manual processes and eliminate all the flaws that come with them in clouds. 

In AWS cloud, Control Tower managed Landing Zone is the native toolset on this aspect. As people say, you do not really need Control Tower for setting up a landing zone, particularly if you would like to play around in a lab environment. But without Control Tower the setup would quickly bend under its own weight on the manual administration, provision and management. So for use cases of enterprises, you may well say, yes I do, in fact, really need Control Tower.

Now let’s imagine we are from an organization that completed an initial Control Tower project in recent times. It was a solid project and the milestone is truly beautiful. A lot of hurrays are genuinely deserved by all the team members involved as well as your trusted AWS partner. (I am not necessarily writing a story - I have witnessed and shared such moments.)

Then, as true modern ‘cloudifiers’, we ask: hey, modern clouds are all agile, all about continuous improvement, so what would it be like to continuously make the Control Tower setup better? 

Indeed, Control Tower is an ongoing cloud apparatus. Its continuous improvement consideration can start before it is deployed, but more so while its setup is introduced. 

There can be various approaches in this space. Here, I would like to discuss an AWS native solution - Customizations for AWS Control Tower. 

Customizations for AWS Control Tower (CfCT) is what you will consider when you further automate the management of the Control Tower Managed Landing Zone. 

Let’s review how CfCT is deployed; this will help to disclose what benefits it brings, before quickly discussing some typical scenarios in which an organisation would leverage CfCT.

CfCT Deployment

CfCT is a combined automated workflow solution deployed into the Management Account of a Control Tower setup, where the Control Tower Managed Landing Zone resides.      

There are two workflows in CfCT:

1. The AWS CodePipeline workflow - leverages CodePipeline, CodeBuild and Step Functions to orchestrate the management of AWS CloudFormation StackSets and SCPs (Service Control Policies).

This CfCT Code Pipeline workflow runs through three stages:

  • Build Stage: The contents of the configuration package are validated
  • SCP Stage: SCPs are created / deployed through API calling to either targeted individual accounts, or to an entire OU (organizational unit). 
  • CloudFormation Stage: CloudFormation stack sets are deployed to either targeted individual accounts, or to an entire OU. The resources deployed are specified by a user-provided file - The Manifest File. 

2. The AWS Control Tower lifecycle event workflow -  Leverages Amazon EventBridge, Amazon SQS FIFO queue, and an AWS Lambda Function acting as a lifecycle event handler. This workflow is invoked when there are Control Tower lifecycle events - events that mark the completion of the change of the state of resources.  The resources here are those that Control Tower creates or manages (such as OUs, accounts, and controls).

The above mentioned Lambda Function in turn invokes the CodePipeline workflow to complete the provisioning. 

An AWS CloudFormation template is provided by CfCT. The template launches all the components necessary to build the workflows.

Below is a diagram provided by AWS on CfCT workflows:



The Manifest File and The Configuration Package


A manifest.yaml file is a text file that describes the AWS resources. The following example shows the structure of the manifest file.

---
region: String
version: 2021-03-15

resources: # List of resources
  - name: [String]
    resource_file: [String] [Local File Path, S3 URL] 
    deployment_targets: # account and/or organizational unit names
      accounts: # array of strings, [0-9]{12}
        - 012345678912
        - AccountName1
      organizational_units: #array of strings
        - OuName1
        - OuName2 
    deploy_method: scp | stack_set
    parameters: # List of parameters [SSM, Alfred, Values]
      - parameter_key: [String]
        parameter_value: [String]  
    export_outputs: # list of ssm parameters to store output values
      - name: /org/member/test-ssm/app-id
        value: $[output_ApplicationId]    
...

The first two lines of the manifest file specify the values of the region and the version keywords. region specifies the AWS Control Tower home Region. When custom AWS Control Tower resources are created, this is the default region used, unless a more resource-specific region is specified.

The resources section of the manifest file is highly structured. It contains a detailed list of AWS resources, which will be deployed automatically by the CfCT pipeline. 

The manifest file should be checked over to make sure it accurately describes the correct target accounts. Unintended changes to account resources may occur if there are errors in the manifest file.

AWS Control Tower configuration is defined with the manifest file, as well as the accompanying set of templates, and other JSON files. These source files are packaged into a folder structure and placed at a storage location. Below is an example of the custom configuration folder structure:

- manifest.yaml
- policies/                                                [optional]
   - service control policies files (*.json)
- templates/                                               [optional]
   - template files for AWS CloudFormation Resources (*.template)


Either a S3 bucket or an AWS CodeCommit repository can be used as the source storage location. The folder structure stays the same. If S3 is used, all the folders and files need to be compressed into a custom-control-tower-configuration.zip file. Only this zip file is to be uploaded to the designated S3 bucket. If CodeCommit is used, place the files in the repository without zipping the files.

Typical CfCT Scenarios

There are many ways in which CfCT can be beneficial to the Control Tower Landing Zone management. An exhaust list of use cases may not ever be there. Here I will just use a quick case study to demonstrate several typical CfCT scenarios. 

In our initial Control Tower project above, let’s say careful considerations had been given to the structure of the OUs and accounts. Our organisation decided to go for the structured workload OU model instead of the Production / Non Production OU model based on a range of considerations. The following structure was established:

  • A Landing Zone management account
  • A Security OU with Log Archive and Audit accounts
  • The X and Y workload OUs, each with nested OUs
  • A Shared Services OU
  • An ungoverned OU


A number of existing AWS accounts are put under the Ungoverned OU (which acts as a ‘parking lot’), before they will be moved to the most appropriate OU location in subsequent projects. This is done because these accounts are not as ready as accounts already in the X and Y OUs. 

The diagram has Service Control Policies (SCPs) - the preventive guardrails and detective guardrails - depicted, making the diagram a bit busier than I usually like. But in this case, there is merit showing them.

Since the completion of the initial Control Tower Landing Zone project, the organisation has experienced following growth and changes:

- Another entity will be merging into the organisation in the coming months. Their AWS environment is most suited to be slotted into the X OU that we have got. However, the most desired structure for X OU would be that another layer of nested OUs being created - the current workload in X OU is to be put under X1 OU, while, when the time comes, the future incoming entity will be the X2 OU. For now, it is a good idea to sort out the new nested OU structure. 

- Accounts in the Ungoverned OU are progressively moved into Control Tower governed structure. In this case it means that additional accounts would be established in the Y OU. SCPs also need to be carefully updated so both the working order and security are properly maintained. 

- A wide range of AWS resources (be it EC2s, containers, serverless or databases) need to be provisioned to some of the accounts from time to time, while being properly governed by respective SCPs.



CfCT will be able to provide an automated approach to all these activities, while: 

  • eliminates manual processes (and their vulnerability to errors)
  • has agile and CI/CD coverage to Landing Zone changes and Control Tower governance customisation 
  • improves posture health in the Well Architected Framework


                                                                                                        -- Simon Wang 25 June 2023



Comments

Post a Comment

Popular posts from this blog

Fairness Evaluation and Model Explainability In AI

Image
Artificial Intelligence (AI) relies on machine learning and its modelling to provide outcomes. Imagine a credit card company receives hundreds of thousands of applications each year and would like to use AI to do the first round of application filtering. If it is not developed properly, the AI decisions will be skewed with unfairness – such as rejecting a lot more applications from a certain age group, from a certain gender, or from a certain employment history pattern – UNFAIRLY. Please note unfairness is the key issue here – in other words, AI and machine learning inference that is not reflecting the due course in actual situations. This is typically called bias in AI and machine learning. Biases can come from various stages of a machine learning life cycle: • Biases may exist in the pre-training data -  e.g., the dataset to be used in machine learning training has biases in it • Biases may be introduced by the machine learning exercise  Below is a machine learning lifecycle char
Read more

AWS and Generative AI

Image
 Generative Artificial Intelligence, or Generative AI, GenAI, is one of the hottest topics in the recent months. You would ‘have to be living under a rock to not notice this massive topic’.  ‘Generative AI is a branch of AI that focuses on creating new data. It is a subset of machine learning. The goal of generative AI is to create new data that is similar to the data that was used to train the model.’ – texts generated by an AI tool.  Recently I experimented a couple of random text-to-image GenAI tools to observe how generative AI can create contents and how the data generated by different GenAI tools trained by different models is different. My experiment was straightforward: text-to-image GenAI tools ask you to provide some texts as a prompt, and then use this input to generate an image. So that was what I did. The prompt I supplied was: ‘female student graduation photo in front of a white building with flowers in hand in Paris’. Both GenAI tools I tested could output an image withi
Read more

Amazon CloudFront and Its Primary and Secondary Origins

Nowadays most of the online contents are web service based. A user accesses a specific content, for example a web page, by connecting their client end application (like a web browser) running on their desktop or mobile computing device to the server that hosts the web page. There are billions of websites and webpages. DNS services, online search engines and links on well known ‘portal’ websites help people to find and locate the contents they would like to visit.  A user’s web client device and the server it visits can be worldly apart: for example, let’s think of a user in Tasmania, Australia that uses its smart phone to visit a website hosted on a server that locates in a data centre in Montreal, Canada, which is more than sixteen thousand kilometres away. They are connected by the Internet. The Internet comprises of millions of inter-connected networks. Traffic on the Internet is routed between the users and the servers through those inter-connected networks in-between. Using the ab
Read more