DEV Community: Adam Divall

Creating a Multi-Account CI/CD Pipeline with AWS CodePipeline

Adam Divall — Sun, 06 Nov 2022 14:55:29 +0000

Whenever I've tried to learn a particular service or functionality within AWS, I find the best way is to do the ClickOps approach (i.e. Good Old Point and Click in the Console). Once I've figured out how to get it working via that method, I then go through the process of trying to automate it through Infrastructure as Code and in my case thats using AWS CloudFormation.

One particular example of this was getting a bit more familiar with AWS CodePipeline so that I could try to automate the delivery of CloudFormation Templates across multiple AWS Accounts in a similar manner as to how you would deploy solutions in a Software Delivery Lifecycle (SDLC). When I was learning how to do this through the management console, I found out that its not possible to do it all within the console and therefore you have to also leverage the AWS CLI for specific parts.

This blog post aims to walkthrough the steps that you'd need to take to create a relatively simple CI/CD pipeline using the AWS CodeCommit, AWS CodeBuild and AWS CodePipeline so that we can deploy a simple CloudFormation template into multiple AWS Accounts via an automated manner.

The flow of the CI/CD pipeline will be as follows:

A CloudFormation template gets committed to a CodeCommit repository.
Upon the detection of changes in that repository the CodePipeline will trigger a deployment run.
CodeBuild will run a linting check against the CloudFormation Template using cfn-lint and will then run cfn-nag to check for patterns that indicate insecure resources within the CloudFormation template.
The CloudFormation template will then be deployed into the same AWS Account as where the CI/CD pipeline is.
Finally the CloudFormation template will then be deployed into a different AWS Account.

For the purpose of this blog post I'm going to use 3 AWS Accounts - Tooling, Development & Production. I'll be configuring the pipeline within the Tooling Account that will then deploy the CloudFormation Template into Development and then once an approval has been granted will then deploy to Production.

Create the CodeCommit Repository

In the Tooling Account, Login to the AWS Management Console using an Account with administrative permissions and navigate to the CodeCommit Service.
Click Create repository.

On the Create repository page, Enter a CloudFormation-Repository and Click Create.

Configure an AWS CLI Profile to the Tooling Account

Establish an AWS CLI Profile to the Management Account with administrative credentials via the AWS CLI using either a Command Prompt or from Powershell:

aws configure sso

In the SSO start URL, type the URL of the SSO Login page. For example., https://d-1234567890.awsapps.com/start This can be found by logging into the IAM Identity Center Console and looking for the AWS access portal URL in the Settings.
In the SSO Region, type the AWS Region that was used for the Home Region when deploying Control Tower. For example., eu-west-2

A Web Browser will then Open prompting for Login Credentials if you're not already logged in.

Login with your Username and Password.
Click Allow.
Select the Tooling Account using the cursor keys.
Press Return for the default client Region and the default output format.
For the Profile name use something memorable as this can be anything. For example., tooling

Clone the CodeCommit Repository

Install the git-remote-codecommit module via either a Command Prompt or Powershell.

pip install git-remote-codecommit

Clone the CodeCommit repository via either a Command Prompt or Powershell.

git clone codecommit://tooling@CloudFormation-Repository CloudFormation-Repository

Note: You'll need to ensure that you use the name of you AWS CLI profile prior to the @ as shown in the example above.

Create the CloudFormation Template and Push to CodeCommit

Create a file named cloudformation.yaml with the below content in CloudFormation-Repository folder, where you cloned the repository to.

AWSTemplateFormatVersion: 2010-09-09
Resources:
  S3Bucket:
    Type: AWS::S3::Bucket
    Properties: 
      BucketName: automated-deployment-${AWS::Region}-${AWS::AccountId}
      BucketEncryption:
        ServerSideEncryptionConfiguration:
          - ServerSideEncryptionByDefault:
              SSEAlgorithm: 'AES256'
      PublicAccessBlockConfiguration:
          BlockPublicAcls: true
          BlockPublicPolicy: true
          IgnorePublicAcls: true
          RestrictPublicBuckets: true

Commit the Code to the CodeCommit Repository via either a Command Prompt or Powershell.

git add .
git commit -m "Initial Commit"
git push

Create the CloudFormation Service Role

For both the Development and Production AWS Accounts follow the below steps.
Login to the AWS Management Console using an Account with administrative permissions and navigate to the IAM Service.
Click Roles.
Click Create Role.

On the Select trusted entity page, Ensure that the trusted entity is set to AWS service and then under Use cases for other AWS services, Select CloudFormation from the dropdown list and then Click Next.

On the Add permission page, Select the AdministratorAccess from the Permissions policies and then Click Next.

On the Name, review and create page, In the Role Name type CloudFormation-Admin and then Click Create role.

Create the KMS Key for Pipeline Artifacts

In the Tooling Account, Login to the AWS Management Console using an Account with administrative permissions and navigate to the KMS Service.
Click Create a key.

On the Configure key page, Leave the default options and Click Next.

On the Alias page, Create an Alias named Pipeline-Artifacts and Click Next.

On the Define key administrative permissions page, Select the Role that begins with the prefix of AWSReservedSSO_AdministratorAccess.
Ensure that the Checkbox for Allow key administrators to delete this key is Selected and Click Next.

On the Define key usage permissions page, Click Add another AWS Account.
Enter the 12 Digit Account ID of the Development Account and then Click Add another AWS Account.
Enter the 12 Digit Account ID of the Production Account and then Click Next.

On the Review page, Click Finish.

Create the S3 Bucket for Pipeline Artifacts

In the Tooling Account, Login to the AWS Management Console using an Account with administrative permissions and navigate to the S3 Service.
Click Create bucket.

On the Create bucket pagec, Enter a globall unique Bucket name. In this example, I've suffixed the name pipeline-artifacts with the region and the AWS Account ID.
Set the Bucket Versioning to Enable.
Set the Default encryption to Enable, Select AWS Key Management Service key (SSE-KMS), Select Choose from your AWS KMS keys and then Choose the KMS Key that we previously created.
Click Create bucket.

In the S3 Service Console, Click Buckets.

Click the pipeline-artifacts Bucket that we previously created.

Click the Permissions Tab.

Under the Bucket policy section, Click Edit.

Enter the below JSON Policy.

{
        "Version": "2012-10-17",
        "Statement": [
          {
            "Effect": "Deny",
            "Principal": "*",
            "Action": [
              "s3:PutObject"
            ],
            "Resource": [
              "arn:aws:s3:::pipeline-artifacts-eu-west-2-<Tooling-Account-ID>/*"
            ],
            "Condition": {
              "StringNotEquals": {
                "s3:x-amz-server-side-encryption": "aws:kms"
              }
            }
          },
          {
            "Action": "s3:*",
            "Effect": "Deny",
            "Principal": "*",
            "Resource": [
              "arn:aws:s3:::pipeline-artifacts-eu-west-2-<Tooling-Account-ID>",
              "arn:aws:s3:::pipeline-artifacts-eu-west-2-<Tooling-Account-ID>/*"
            ],
            "Condition": {
              "Bool": {
                "aws:SecureTransport": false
              }
            }
          },
          {
            "Effect": "Allow",
            "Principal": {
              "AWS": [
                "arn:aws:iam::<Development-Account-ID>:root",
                "arn:aws:iam::<Production-Account-ID>:root"
              ],
              "Service": "codebuild.amazonaws.com"
            },
            "Action": [
              "s3:Get*",
              "s3:Put*"
            ],
            "Resource": [
              "arn:aws:s3:::pipeline-artifacts-eu-west-2-<Tooling-Account-ID>/*"
            ]
          },
          {
            "Effect": "Allow",
            "Principal": {
              "AWS": [
                "arn:aws:iam::<Development-Account-ID>:root",
                "arn:aws:iam::<Production-Account-ID>:root"
              ],
              "Service": "codebuild.amazonaws.com"
            },
            "Action": [
              "s3:ListBucket"
            ],
            "Resource": [
              "arn:aws:s3:::pipeline-artifacts-eu-west-2-<Tooling-Account-ID>"
            ]
          }
        ]
      }

Click Save changes.

Create the IAM Role for Cross-Account Access

For both the Development and Production AWS Accounts follow the below steps.
Login to the AWS Management Console using an Account with administrative permissions and navigate to the IAM Service.
Click Roles.
Click Create Role.

On the Select trusted entity page, Ensure that the trusted entity is set to AWS account and then under Another AWS account enter the 12 Digit Account ID for the Tooling Account and then Click Next.

On the Add permission page, Click Create policy.

On the Create policy page, Click the JSON Tab.

Replace everything in the existing JSON Policy with the below.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "kms:DescribeKey",
                "kms:GenerateDataKey*",
                "kms:Encrypt",
                "kms:ReEncrypt*",
                "kms:Decrypt"
            ],
            "Resource": [
                "arn:aws:kms:eu-west-2:<Tooling-Account-ID>:key/*"
            ],
            "Effect": "Allow"
        },
        {
            "Action": [
                "cloudformation:*",
                "iam:PassRole"
            ],
            "Resource": [
                "*"
            ],
            "Effect": "Allow"
        },
        {
            "Action": [
                "s3:Get*",
                "s3:Put*",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::pipeline-artifacts-eu-west-2-<Tooling-Account-ID>/*",
                "arn:aws:s3:::pipeline-artifacts-eu-west-2-<Tooling-Account-ID>"
            ],
            "Effect": "Allow"
        }
    ]
}

Note: In the above IAM Policy, replace <Tooling-Account-ID> with the Account ID of your own Tooling Account.

Click Next: Tags.
Click Next: Review.
On the Review policy page, In the Policy name type Pipeline-Cross-Account-Access and Click Create policy.

Return to the Browser Tab for the Creation of the IAM Role and Click the Refresh Button. The button with 2 Arrows on and then the IAM Policy that was just created will be visible.

Select the Pipeline-Cross-Account-Access permissions policies and then Click Next.

On the Name, review, and create page, In the role name type Cross-Account-Role and Click Create role.

Create the CloudFormation Tests Build Project in CodeBuild

In the Tooling Account, Login to the AWS Management Console using an Account with administrative permissions and navigate to the CodeBuild Service.
Click Create build project.

On the Create build project page under the Project configuration section, In the Project name type CloudFormation-Tests.
Under the Source section, In the Source provider select AWS CodeCommit.
In the Repository select CloudFormation-Repository.
In the Branch select main.

Under the Environment section, Select Managed image.
In the Operating system, Select Ubuntu.
In the Runtimes, Select Standard.
In the Image, Select aws/codebuild/standard:6.0.
In the Image version, Select Always use the latest image for this runtime version.
In the Environment type, Select Linux.
In the Service role, Select New service role.
In the Role name, Type CodeBuild-CloudFormation-Tests.

Under the BuildSpec section, Select Insert build commands.
Click Switch to editor.
In the Build commands, replace everything in there with the below.

version: 0.2
phases:
  install:
    runtime-versions:
      ruby: 3.1
      # name: version
    on-failure: ABORT
    commands:
      - pip3 install cfn-lint --quiet
      - apt-get install jq git -y -q
      - gem install cfn-nag
  build:
    on-failure: ABORT
    commands:
      - cd ./
      - cfn-lint cloudformation.yaml
      - cfn_nag_scan -i cloudformation.yaml

Click Create build project.

Update the KMS Key Policy to Allow the CodeBuild Service Permissions

In the Tooling Account, Login to the AWS Management Console using an Account with administrative permissions and navigate to the KMS Service.
Click Customer managed keys.
Click Pipeline-Artifacts.
Click Switch to policy view
Click Edit.
Replace everything in the existing JSON Policy with the below.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Enable IAM User Permissions",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::<Tooling-Account-ID>:root"
            },
            "Action": "kms:*",
            "Resource": "*"
        },
        {
            "Sid": "Allow access for Key Administrators",
            "Effect": "Allow",
            "Principal": {
                "AWS": "<ARN-of-AWSReservedSSO_AdministratorAccess-IAM-Role>"
            },
            "Action": [
                "kms:Create*",
                "kms:Describe*",
                "kms:Enable*",
                "kms:List*",
                "kms:Put*",
                "kms:Update*",
                "kms:Revoke*",
                "kms:Disable*",
                "kms:Get*",
                "kms:Delete*",
                "kms:TagResource",
                "kms:UntagResource",
                "kms:ScheduleKeyDeletion",
                "kms:CancelKeyDeletion"
            ],
            "Resource": "*"
        },
        {
            "Sid": "Allow use of the key",
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::<Development-Account-ID>:root",
                    "arn:aws:iam::<Production-Account-ID>:root"
                ],
                "Service": "codebuild.amazonaws.com"
            },
            "Action": [
                "kms:Encrypt",
                "kms:Decrypt",
                "kms:ReEncrypt*",
                "kms:GenerateDataKey",
                "kms:DescribeKey"
            ],
            "Resource": "*"
        }
    ]
}

Note: In the above IAM Policy, replace <Tooling-Account-ID> with the Account ID of your own Tooling Account, replace <Development-Account-ID> with the Account ID of your own Development Account, replace <Production-Account-ID> with the Account ID of your own Production Account and replace <ARN-of-AWSReservedSSO_AdministratorAccess-IAM-Role> wih the ARN of the AWSReservedSSO_AdministratorAccess IAM Role that can be obtained from the IAM Console within the Tooling Account.

Click Save changes.

Update the CodeBuildBasePolicy-CloudFormation-Tests-eu-west-2 IAM Policy

In the Tooling Account, Login to the AWS Management Console using an Account with administrative permissions and navigate to the IAM Service.
Click Policies.

Click the CodeBuildBasePolicy-CloudFormation-Tests-eu-west-2 IAM Policy.
Click Edit policy.
Click the JSON Tab.
Replace everything in the existing JSON Policy with the below.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Resource": [
                "arn:aws:logs:eu-west-2:<Tooling-Account-ID>:log-group:/aws/codebuild/CloudFormation-Tests",
                "arn:aws:logs:eu-west-2:<Tooling-Account-ID>:log-group:/aws/codebuild/CloudFormation-Tests:*"
            ],
            "Action": [
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:PutLogEvents"
            ]
        },
        {
            "Effect": "Allow",
            "Resource": [
                "arn:aws:s3:::pipeline-artifacts-eu-west-2-<Tooling-Account-ID>/*"
            ],
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:GetObjectVersion",
                "s3:GetBucketAcl",
                "s3:GetBucketLocation"
            ]
        },
        {
            "Effect": "Allow",
            "Resource": [
                "arn:aws:codecommit:eu-west-2:<Tooling-Account-ID>:CloudFormation-Repository"
            ],
            "Action": [
                "codecommit:GitPull"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "codebuild:CreateReportGroup",
                "codebuild:CreateReport",
                "codebuild:UpdateReport",
                "codebuild:BatchPutTestCases",
                "codebuild:BatchPutCodeCoverages"
            ],
            "Resource": [
                "arn:aws:codebuild:eu-west-2:<Tooling-Account-ID>:report-group/CloudFormation-Tests-*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "kms:DescribeKey",
                "kms:GenerateDataKey",
                "kms:Encrypt",
                "kms:ReEncrypt*",
                "kms:Decrypt"
            ],
            "Resource": [
                "<ARN-of-Pipeline-Artifacts-KMS-Key>"
            ]
        }        
    ]
}

Note: In the above IAM Policy, replace <Tooling-Account-ID> with the Account ID of your own Tooling Account, replace <Development-Account-ID> with the Account ID of your own Development Account, replace <Production-Account-ID> with the Account ID of your own Production Account and replace <ARN-of-Pipeline-Artifacts-KMS-Key> wih the ARN of the Pipeline-Artifacts KMS Key that can be obtained from the KMS Console within the Tooling Account.

Click Review policy.
Click Save changes.

Create the Deployment Pipeline in CodePipeline

In the Tooling Account, Login to the AWS Management Console using an Account with administrative permissions and navigate to the CodePipeline Service.
Click Create pipeline.

On the Choose pipeline settings page under the Pipeline settings section, In the Pipeline name type CloudFormation-Pipeline.
In the Service role, Select New service role.
In the Role name, Type CloudFormation-Pipeline.
Ensure that Allow AWS CodePipeline to create a service role so it can be used with this new pipeline is selected.
Expand the Advanced settings, Select Custom location for the Artifact Store.
In the Bucket, Select the pipeline-artifacts bucket that we previously created.
Select Customer Managed Key for the Encryption key.
In the KMS customer master key, Select the Pipeline-Artifacts KMS Key that we previously created.

Click Next.
On the Add source stage page, In the Source provider select AWS CodeCommit.
In the Repository name, Select CloudFormation-Repository.
In the Branch name, Select main.
Leave all other settings as the defaults and Click Next.

On the Add build stage page, In the Build provider select AWS CodeBuild.
In the Project name, Select CloudFormation-Tests and Click Next.

On the Add deploy stage page, In the Deploy provider select AWS CloudFormation.
In the Action mode, Select Create or update a stack.
In the Stack name, Type Automated-CloudFormation-Deployment. Note: This can be named anything you'd like.
In the Artifact name, Select BuildArtifact and in the File name type cloudformation.yaml.
In the Capabilities - optional select CAPABILITY_NAMED_IAM.
In the Role name, Enter the ARN of the Development Accounts CloudFormation-Admin IAM Role and then Click Next.

On the Review page, Click Create Pipeline.

Update the KMS Key Policy to Allow the CloudFormation-Pipeline IAM Role Permissions

In the Tooling Account, Login to the AWS Management Console using an Account with administrative permissions and navigate to the KMS Service.
Click Customer managed keys.
Click Pipeline-Artifacts.
Click Switch to policy view
Click Edit.
Replace everything in the existing JSON Policy with the below.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Enable IAM User Permissions",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::<Tooling-Account-ID>:root"
            },
            "Action": "kms:*",
            "Resource": "*"
        },
        {
            "Sid": "Allow access for Key Administrators",
            "Effect": "Allow",
            "Principal": {
                "AWS": "<ARN-of-AWSReservedSSO_AdministratorAccess-IAM-Role>"
            },
            "Action": [
                "kms:Create*",
                "kms:Describe*",
                "kms:Enable*",
                "kms:List*",
                "kms:Put*",
                "kms:Update*",
                "kms:Revoke*",
                "kms:Disable*",
                "kms:Get*",
                "kms:Delete*",
                "kms:TagResource",
                "kms:UntagResource",
                "kms:ScheduleKeyDeletion",
                "kms:CancelKeyDeletion"
            ],
            "Resource": "*"
        },
        {
            "Sid": "Allow use of the key",
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::<Development-Account-ID>:root",
                    "arn:aws:iam::<Production-Account-ID>:root",
                    "arn:aws:iam::<Tooling-Account-ID>:role/CloudFormation-Pipeline"
                ],
                "Service": "codebuild.amazonaws.com"
            },
            "Action": [
                "kms:Encrypt",
                "kms:Decrypt",
                "kms:ReEncrypt*",
                "kms:GenerateDataKey",
                "kms:DescribeKey"
            ],
            "Resource": "*"
        }
    ]
}

Click Save changes.

Update the CloudFormation-Pipeline IAM Role Permissions

In the Tooling Account, Login to the AWS Management Console using an Account with administrative permissions and navigate to the IAM Service.
Click Policies.
Click AWSCodePipelineServiceRole-eu-west-2-CloudFormation-Pipeline.
Click Edit policy.
Click the JSON Tab.
Replace everything in the existing JSON Policy with the below.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "sts:AssumeRole"
            ],
            "Resource": [
                "arn:aws:iam::<Development-Account-ID>:role/*",
                "arn:aws:iam::<Production-Account-ID>:role/*"
            ],
            "Effect": "Allow"
        },
        {
            "Condition": {
                "StringEqualsIfExists": {
                    "iam:PassedToService": [
                        "cloudformation.amazonaws.com"
                    ]
                }
            },
            "Action": [
                "iam:PassRole"
            ],
            "Resource": [
                "*"
            ],
            "Effect": "Allow"
        },
        {
            "Action": [
                "codecommit:CancelUploadArchive",
                "codecommit:GetBranch",
                "codecommit:GetCommit",
                "codecommit:GetRepository",
                "codecommit:GetUploadArchiveStatus",
                "codecommit:UploadArchive"
            ],
            "Resource": [
                "*"
            ],
            "Effect": "Allow"
        },
        {
            "Action": [
                "cloudwatch:*",
                "s3:*",
                "sns:*",
                "cloudformation:*"
            ],
            "Resource": [
                "*"
            ],
            "Effect": "Allow"
        },
        {
            "Action": [
                "cloudformation:CreateStack",
                "cloudformation:DeleteStack",
                "cloudformation:DescribeStacks",
                "cloudformation:UpdateStack",
                "cloudformation:CreateChangeSet",
                "cloudformation:DeleteChangeSet",
                "cloudformation:DescribeChangeSet",
                "cloudformation:ExecuteChangeSet",
                "cloudformation:SetStackPolicy",
                "cloudformation:ValidateTemplate"
            ],
            "Resource": [
                "*"
            ],
            "Effect": "Allow"
        },
        {
            "Action": [
                "codebuild:BatchGetBuildBatches",
                "codebuild:StartBuild",
                "codebuild:BatchGetBuilds",
                "codebuild:StartBuildBatch"
            ],
            "Resource": [
                "*"
            ],
            "Effect": "Allow"
        }
    ]
}

Note: In the above IAM Policy, replace <Development-Account-ID> with the Account ID of your own Development Account and replace <Production-Account-ID> with the Account ID of your own Production Account

Click Review policy.
Click Save changes.

Update the Deployment Pipeline in CodePipeline to Add the Production Stage

In the Tooling Account, Login to the AWS Management Console using an Account with administrative permissions and navigate to the CodePipeline Service.

Click on CloudFormation-Pipeline.

Click Edit.

Click on Add stage after the Deploy stage.
In the Stage name, Type Production and Click Add stage.

Under the Production stage, Click Add action group.
On the Edit action page, In Action name type Production.
In the Action provider, Select AWS CloudFormation.
In the Input artifacts, Select BuildArtifact.
In the Action mode, Select Create or update a stack.
In the Stack name, Type Automated-CloudFormation-Deployment.
In the Artifact name, Select BuildArtifact.
In the File name, Type cloudformation.yaml.
In Capabilities - optional, Select CAPABILITY_NAMED_IAM.
In the Role name, Enter the ARN of the Production Accounts CloudFormation-Admin IAM Role and then Click Done.

Click Save.

Edit the Deployment Pipeline for Cross-Account Access

Execute a Get-Pipeline API Call using a Tooling Account profile via the AWS CLI using either a Command Prompt or from Powershell:

aws codepipeline get-pipeline --name CloudFormation-Pipeline --profile tooling >> pipeline.json

Edit pipeline.json in a Code Editor to look something like the below:

{
    "pipeline": {
        "name": "CloudFormation-Pipeline",
        "roleArn": "arn:aws:iam::<Tooling-Account-ID>:role/service-role/CloudFormation-Pipeline",
        "artifactStore": {
            "type": "S3",
            "location": "pipeline-artifacts-eu-west-2-<Tooling-Account-ID>",
            "encryptionKey": {
                "id": "arn:aws:kms:eu-west-2:<Tooling-Account-ID>:alias/Pipeline-Artifacts",
                "type": "KMS"
            }
        },
        "stages": [
            {
                "name": "Source",
                "actions": [
                    {
                        "name": "Source",
                        "actionTypeId": {
                            "category": "Source",
                            "owner": "AWS",
                            "provider": "CodeCommit",
                            "version": "1"
                        },
                        "runOrder": 1,
                        "configuration": {
                            "BranchName": "main",
                            "OutputArtifactFormat": "CODE_ZIP",
                            "PollForSourceChanges": "false",
                            "RepositoryName": "CloudFormation-Repository"
                        },
                        "outputArtifacts": [
                            {
                                "name": "SourceArtifact"
                            }
                        ],
                        "inputArtifacts": [],
                        "region": "eu-west-2",
                        "namespace": "SourceVariables"
                    }
                ]
            },
            {
                "name": "Build",
                "actions": [
                    {
                        "name": "Build",
                        "actionTypeId": {
                            "category": "Build",
                            "owner": "AWS",
                            "provider": "CodeBuild",
                            "version": "1"
                        },
                        "runOrder": 1,
                        "configuration": {
                            "ProjectName": "CloudFormation-Tests"
                        },
                        "outputArtifacts": [
                            {
                                "name": "BuildArtifact"
                            }
                        ],
                        "inputArtifacts": [
                            {
                                "name": "SourceArtifact"
                            }
                        ],
                        "region": "eu-west-2",
                        "namespace": "BuildVariables"
                    }
                ]
            },
            {
                "name": "Development-Environment",
                "actions": [
                    {
                        "name": "Deploy-to-Development",
                        "actionTypeId": {
                            "category": "Deploy",
                            "owner": "AWS",
                            "provider": "CloudFormation",
                            "version": "1"
                        },
                        "runOrder": 1,
                        "configuration": {
                            "ActionMode": "CREATE_UPDATE",
                            "Capabilities": "CAPABILITY_NAMED_IAM",
                            "RoleArn": "arn:aws:iam::<Development-Account-ID>:role/CloudFormation-Admin",
                            "StackName": "Automated-CloudFormation-Deployment",
                            "TemplatePath": "SourceArtifact::cloudformation.yaml"
                        },
                        "outputArtifacts": [],
                        "inputArtifacts": [
                            {
                                "name": "SourceArtifact"
                            }
                        ],
                        "roleArn": "arn:aws:iam::<Development-Account-ID>:role/Cross-Account-Role",
                        "region": "eu-west-2"
                    }
                ]
            },
            {
                "name": "Production-Environment",
                "actions": [
                    {
                        "name": "Deploy-to-Production",
                        "actionTypeId": {
                            "category": "Deploy",
                            "owner": "AWS",
                            "provider": "CloudFormation",
                            "version": "1"
                        },
                        "runOrder": 2,
                        "configuration": {
                            "ActionMode": "CREATE_UPDATE",
                            "Capabilities": "CAPABILITY_NAMED_IAM",
                            "RoleArn": "arn:aws:iam::<Production-Account-ID>:role/CloudFormation-Admin",
                            "StackName": "Automated-CloudFormation-Deployment",
                            "TemplatePath": "SourceArtifact::cloudformation.yaml"
                        },
                        "outputArtifacts": [],
                        "inputArtifacts": [
                            {
                                "name": "SourceArtifact"
                            }
                        ],
                        "roleArn": "arn:aws:iam::<Production-Account-ID>:role/Cross-Account-Role",
                        "region": "eu-west-2"
                    }
                ]
            }
        ],
        "version": 1
    }
}

Note: In the above JSON, replace <Tooling-Account-ID> with the Account ID of your own Tooling Account, <Development-Account-ID> with the Account ID of your own Development Account and <Production-Account-ID> with the Account ID of your own Production Account. We have also renamed the Stage that was originally displayed as Deploy to Development and we have also added the variable roleArn to both the Development and Production stages with the ARN of the Cross-Account-Role.

Execute a Get-Pipeline API Call using a Tooling Account profile via the AWS CLI using either a Command Prompt or from Powershell:

aws codepipeline update-pipeline --cli-input-json file://pipeline.json --profile tooling

If you then go into the CodePipeline Console and Click Release change, the pipeline will then trigger successfully.

Hope this helps.

Customising AWS Control Tower with CfCT

Adam Divall — Sat, 24 Sep 2022 12:20:32 +0000

If you missed the previous posts on Deploying a Landing Zone with AWS Control Tower or you've not had much experience with the service, I'd recommend going back through and reading those firstly before continuing.

In this post, I'm going to walkthrough how you can start customising Control Tower using the Security Reference Architecture (SRA). The SRA utilises Customisations for Control Tower (CfCT) which deploys a DevOps pipeline that works with CloudFormation templates and Control Tower lifecycle events.

By no means is this the only way of customising the Landing Zone that Control Tower deploys but its my personal preference, as this was also how the previous version of AWS Landing Zones was based upon and therefore I'm more familiar with its setup and configuration. It does have some drawbacks though, in that it is only single threaded and therefore slow in large environments. There are alternatives though including:

Why would I want to customise Control Tower?

I think the easiest way to answer this question is simply because whilst Control Tower provides the foundations for a Well-Architected Multi-Account Landing Zone, it's not completely perfect.

In terms of AWS Services, Control Tower is still in it infancy and whilst AWS are constantly adding new functionality and guardrails; there are still some basic best practices that aren't there natively. For example, in my previous post, I mentioned that AWS Config doesn't get configured in the Management Account but it is in every other Member AWS Account.

On the other hand, the majority of organisations need to tailor the Landing Zone to meet there specific security and governance requirements. Therefore the reality is that there is no one size fits all, but there are synergies between them.

Enable Trusted Access for CloudFormation StackSets in AWS Organizations

I personally didn't need to do this since Control Tower had already enabled this for me, however it's worth double checking just to play safe.

Login to the AWS Management Console using an Account with administrative permissions and navigate to the AWS Organizations Console. This should be done within the Management Account.

Click Services.

Scroll down to CloudFormation StackSets and check that its Trusted Access is set to Access enabled. If not, then Click CloudFormation StackSets and then Click Enable trusted access.

Configure an AWS CLI Profile to the Management Account

Establish an AWS CLI Profile to the Management Account with administrative credentials via the AWS CLI using either a Command Prompt or from Powershell:

aws configure sso

In the SSO start URL, type the URL of the SSO Login page. For example., https://d-1234567890.awsapps.com/start This can be found by logging into the IAM Identity Center Console and looking for the AWS access portal URL in the Settings.
In the SSO Region, type the AWS Region that was used for the Home Region when deploying Control Tower. For example., eu-west-2

A Web Browser will then Open prompting for Login Credentials if you're not already logged in.

Login with your Username and Password.
Click Allow.
Select the AWS Management Account using the cursor keys.
Press Return for the default client Region and the default output format.
For the Profile name use something memorable as this can be anything. For example., ct-mgmt

Deploying the SRA Common Pre-Requisites

There are a few things that we need installed on our local device as a pre-cursor for this part including Git, Bash Shell (which in my case I needed to install GitBash for Windows), the AWS CLI v2 and 7-Zip. Since I'm running a Windows Device the instructions will be based on that.

Clone the SRA Source Files from GitHub via either a Command Prompt or from Powershell:

git clone https://github.com/aws-samples/aws-security-reference-architecture-examples.git .

Now that we have the SRA source files locally we need to start creating some CloudFormation Stacks in our Management Account using the YAML templates within the source. These templates setup the functionality for SRA to work before we even install the Customisations for Control Tower solution.

Launch the sra-common-prerequisites-staging-s3-bucket.yaml via the AWS CLI using either a Command Prompt or from Powershell:

aws cloudformation deploy --template-file /aws_sra_examples/solutions/common/common_prerequisites/templates/sra-common-prerequisites-staging-s3-bucket.yaml --stack-name sra-common-prerequisites-staging-s3-bucket --capabilities CAPABILITY_NAMED_IAM --profile ct-mgmt

Package and upload all the SRA Solutions to the Staging S3 Bucket via GitBash:

sh ./aws_sra_examples/utils/packaging_scripts/stage_solution.sh --profile ct-mgmt

Launch the sra-common-prerequisites-management-account-parameters.yaml via the AWS CLI using either a Command Prompt or from Powershell:

aws cloudformation deploy --template-file /aws_sra_examples/solutions/common/common_prerequisites/templates/sra-common-prerequisites-management-account-parameters.yaml --stack-name sra-common-prerequisites-management-account-parameters --capabilities CAPABILITY_NAMED_IAM --profile ct-mgmt

Launch the sra-common-prerequisites-main-ssm.yaml via the AWS CLI using either a Command Prompt or from Powershell:

aws cloudformation deploy --template-file /aws_sra_examples/solutions/common/common_prerequisites/templates/sra-common-prerequisites-main-ssm.yaml --stack-name sra-common-prerequisites-main-ssm --capabilities CAPABILITY_NAMED_IAM --profile ct-mgmt

Deploy the Customisations for Control Tower Solution

The team at AWS that have developed the SRA utilised Customisations for Control Tower (CfCT) as the delivery mechanism for there customisations but since they don't maintain that solution itself, it's strongly recommended to check the current version of CfCT here prior to launching the CloudFormation Template.

You may find that you wish to edit sra-common-cfct-setup-main.yaml to reflect the following change instead:

# TemplateURL: !Sub https://${pSRAStagingS3BucketName}.s3.${AWS::Region}.${AWS::URLSuffix}/${pSRASolutionName}/templates/customizations-for-aws-control-tower.template
TemplateURL: https://s3.amazonaws.com/solutions-reference/customizations-for-aws-control-tower/latest/custom-control-tower-initiation.template

The architecture that is deployed by CfCT is shown below.

Launch the sra-common-cfct-setup-main.yaml via the AWS CLI using either a Command Prompt or from Powershell:

aws cloudformation deploy --template-file /aws_sra_examples/solutions/common/common_cfct_setup/templates/sra-common-cfct-setup-main.yaml --stack-name sra-common-cfct-setup-main --capabilities CAPABILITY_NAMED_IAM --profile ct-mgmt

What Customisations should I make?

This is always very subjective and there are many things that may factor into the answer. That being said here is my personal list in no particular order and best of all it's all included within the SRA Source Files with the exceptions of the SCPs. There are also other CloudFormation Templates available within the SRA source files that could be used or alternatively you may wish to create your own.

CloudFormation

Enable Config in the Management Account
Enable CloudTrail Organizational Trail for Data Events
Enable EC2 Default EBS Encryption
Configure a Hardened IAM Account Password Policy
Enable S3 Block Public Access at the Account Level
Configure AWS Account Alternate Contacts
Enable IAM Access Analyzer and Configure for Delegated Administration
Enable GuardDuty and Configure for Delegated Administration
Enable Macie and Configure for Delegated Administration
Enable Security Hub and Configure for Delegated Administration

Service Control Policies

Prevent Accounts from Leaving the Organisation
Prevent the Disabling of any Security Tooling
Prevent IAM User Creation

Time to Customise our Control Tower Setup

This section will go through customising Control Tower based on my own personal recommendation

Install the git-remote-codecommit module via either a Command Prompt or Powershell.

pip install git-remote-codecommit

Clone the CodeCommit repository that is deployed by CfCT via either a Command Prompt or Powershell.

git clone codecommit://sra-mgmt@custom-control-tower-configuration custom-control-tower-configuration

Note: You'll need to ensure that you use the name of you AWS CLI profile prior to the @ as shown in the example above.

Within your IDE of choice, under the custom-control-tower-configuration folder delete the example-configuration folder.
Under the custom-control-tower-configuration fodler create 3 new folders named parameters, policies and templates.

Copy the following files from the SRA source files to custom-control-tower-configuration\templates.
- sra-account-alternate-contacts-main-ssm.yaml
- sra-cloudtrail-org-main-ssm.yaml
- sra-config-management-account-main-ssm.yaml
- sra-ec2-default-ebs-encryption-main-ssm.yaml
- sra-guardduty-org-main-ssm.yaml
- sra-iam-access-analyzer-main-ssm.yaml
- sra-iam-password-policy-main-ssm.yaml
- sra-macie-org-main-ssm.yaml
- sra-securityhub-org-main-ssm.yaml
Copy the following files from the SRA source files to custom-control-tower-configuration\parameters.
- sra-account-alternate-contacts-main-ssm.json
- sra-cloudtrail-org-main-ssm.json
- sra-config-management-account-main-ssm.json
- sra-ec2-default-ebs-encryption-main-ssm.json
- sra-guardduty-org-main-ssm.json
- sra-iam-access-analyzer-main-ssm.json
- sra-iam-password-policy-main-ssm.json
- sra-macie-org-main-ssm.json
- sra-s3-block-account-public-access-main-ssm.json
- sra-securityhub-org-main-ssm.json
Amend the values as required in each of the JSON files above to customise the configuration of each of the different templates. For example., IAM Password Policy configuration will be defined in the sra-iam-password-policy-main-ssm.json.
Create scp-prevent-accounts-leaving-org.json in custom-control-tower-configuration\policies and paste in the below contents.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PreventMemberLeavingOrg",
            "Effect": "Deny",
            "Action": [
                "organizations:LeaveOrganization"
            ],
            "Resource": "*"
        }
    ]
}

Create scp-prevent-disabling-security-tooling.json in custom-control-tower-configuration\policies and paste in the below contents.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PreventMemberLeavingOrg",
            "Effect": "Deny",
            "Action": [
                "organizations:LeaveOrganization"
            ],
            "Resource": "*"
        }
    ]
}

Create scp-prevent-iam-users-creation.json in custom-control-tower-configuration\policies and paste in the below contents.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PreventIAMUserCreation",
            "Effect": "Deny",
            "Action": [
                "iam:CreateUser",
                "iam:CreateAccessKey"
            ],
            "Resource": [
                "*"
            ]
        }
    ]
}

Modify the contents of manifest.yaml as per below.

---
#Default region for deploying Custom Control Tower: Code Pipeline, Step functions, Lambda, SSM parameters, and StackSets
region: eu-west-2
version: 2021-03-15

# Control Tower Custom Resources (Service Control Policies or CloudFormation)
resources:
  # -----------------------------------------------------------------------------
  # Account Alternate Contacts
  # -----------------------------------------------------------------------------
  - name: sra-account-alternate-contacts-main-ssm
    resource_file: templates/sra-account-alternate-contacts-main-ssm.yaml
    parameter_file: parameters/sra-account-alternate-contacts-main-ssm.json
    deploy_method: stack_set
    deployment_targets:
      accounts:
        - CT Management

  # -----------------------------------------------------------------------------
  # Config Management Account
  # -----------------------------------------------------------------------------
  - name: sra-config-management-account-main-ssm
    resource_file: templates/sra-config-management-account-main-ssm.yaml
    parameter_file: parameters/sra-config-management-account-main-ssm.json
    deploy_method: stack_set
    deployment_targets:
      accounts:
        - CT Management

  # -----------------------------------------------------------------------------
  # Organization CloudTrail
  # -----------------------------------------------------------------------------
  - name: sra-cloudtrail-org-main-ssm
    resource_file: templates/sra-cloudtrail-org-main-ssm.yaml
    parameter_file: parameters/sra-cloudtrail-org-main-ssm.json
    deploy_method: stack_set
    deployment_targets:
      accounts:
        - CT Management

  # -----------------------------------------------------------------------------
  # S3 Block Account Public Access Solution
  # -----------------------------------------------------------------------------
  - name: sra-s3-block-account-public-access-main-ssm
    resource_file: templates/sra-s3-block-account-public-access-main-ssm.yaml
    parameter_file: parameters/sra-s3-block-account-public-access-main-ssm.json
    deploy_method: stack_set
    deployment_targets:
      accounts:
        - CT Management

  # -----------------------------------------------------------------------------
  # EC2 Default EBS Encryption Solution
  # -----------------------------------------------------------------------------
  - name: sra-ec2-default-ebs-encryption-main-ssm
    resource_file: templates/sra-ec2-default-ebs-encryption-main-ssm.yaml
    parameter_file: parameters/sra-ec2-default-ebs-encryption-main-ssm.json
    deploy_method: stack_set
    deployment_targets:
      accounts:
        - CT Management

  # -----------------------------------------------------------------------------
  # IAM Password Policy
  # -----------------------------------------------------------------------------
  - name: sra-iam-password-policy-main-ssm
    resource_file: templates/sra-iam-password-policy-main-ssm.yaml
    parameter_file: parameters/sra-iam-password-policy-main-ssm.json
    deploy_method: stack_set
    deployment_targets:
      accounts:
        - CT Management

  # -----------------------------------------------------------------------------
  # IAM Access Analyzer Solution
  # -----------------------------------------------------------------------------
  - name: sra-iam-access-analyzer-main-ssm
    resource_file: templates/sra-iam-access-analyzer-main-ssm.yaml
    parameter_file: parameters/sra-iam-access-analyzer-main-ssm.json
    deploy_method: stack_set
    deployment_targets:
      accounts:
        - CT Management

  # -----------------------------------------------------------------------------
  # Organization GuardDuty
  # -----------------------------------------------------------------------------
  - name: sra-guardduty-org-main-ssm
    resource_file: templates/sra-guardduty-org-main-ssm.yaml
    parameter_file: parameters/sra-guardduty-org-main-ssm.json
    deploy_method: stack_set
    deployment_targets:
      accounts:
        - CT Management

  # -----------------------------------------------------------------------------
  # Organization SecurityHub
  # -----------------------------------------------------------------------------
  - name: sra-securityhub-org-main-ssm
    resource_file: templates/sra-securityhub-org-main-ssm.yaml
    parameter_file: parameters/sra-securityhub-org-main-ssm.json
    deploy_method: stack_set
    deployment_targets:
      accounts:
        - CT Management

  # -----------------------------------------------------------------------------
  # Organization Macie
  # -----------------------------------------------------------------------------
  - name: sra-macie-org-main-ssm
    resource_file: templates/sra-macie-org-main-ssm.yaml
    parameter_file: parameters/sra-macie-org-main-ssm.json
    deploy_method: stack_set
    deployment_targets:
      accounts:
        - CT Management

  # -----------------------------------------------------------------------------
  # SCP Prevent Member Account Leaving Organization
  # -----------------------------------------------------------------------------
  - name: scp-prevent-accounts-leaving-org
    description: "This SCP prevents users or roles in any affected account from leaving AWS Organizations, either directly as a command or through the console."
    resource_file: policies/scp-prevent-accounts-leaving-org.json
    deploy_method: scp
    deployment_targets:
      organizational_units:
        - Root

  # -----------------------------------------------------------------------------
  # SCP Prevent Creation IAM Users
  # -----------------------------------------------------------------------------
  - name: scp-prevent-iam-users-creation
    description: "This SCP restricts IAM principals from creating new IAM users or IAM Access Keys in an AWS account."
    resource_file: policies/scp-prevent-iam-users-creation.json
    deploy_method: scp
    deployment_targets:
      organizational_units:
        - Root

Commit the files that we've previously just copied, modified and deleted to CodeCommit via either a Command Prompt or Powershell.

git add .
git commit -m "Committing Changes"
git push

This will now trigger the DevOps Pipeline and assuming that no issues have occurred will show as Succeeded.

Hope this helps and enables you to customise your own Control Tower Environments.

Deploying a Landing Zone with AWS Control Tower - Part 3

Adam Divall — Tue, 06 Sep 2022 20:30:30 +0000

Previously in Part 2 of this Walkthrough, I showed you how to create the organisational structure and enable guardrails within Control Tower.

In this post, I'm going to walkthrough some of the remaining post configuration task including configuring IAM Identity Center and provisioning a new AWS Account through Account Factory.

Configuring IAM Identity Center for Single Sign-On

AWS IAM Identity Center (formerly known as AWS SSO) is a service that enables you to have a single point of entry for managing resources within all of your AWS Accounts in an organisation.

As part of the Control Tower deployment this gets enabled using the native Identity Center directory. This allows you to create Users, Groups and Permission Sets that when assigned to an AWS Account would allow you to authenticate and have authorisation to different resources based on the policies defined in the Permission Set. Whilst the Identity Center directory is the default configuration, a post deployment activity is typically to change this to either a 3rd Party Identity Provider such as Azure Active Directory or to perhaps an on-premise Active Directory Domain (AAD).

Since I don't have access to an Azure Active Directory Domain please refer to the instructions below:

Azure Active Directory

When IAM Identity Center is integrated with a 3rd Party Solution such as AAD, you add your AAD Groups to the Azure Enterprise Application. As part of the System for Cross-domain Identity Provisioning (SCIM), Groups and the Users that are member of those Groups will be replicated and created within IAM Identity Center. This provides the User the ability to then login through the AWS access portal URL to authenticate using there standard login details that they'll use for other business workloads such as E-Mail etc.

Since all the identity management is now connected to the corporate AAD, things such as password policies are handled by AAD. However, Multi Factor Authentication (MFA) could be handled either by AAD or alternatively you may decide to handle that within IAM Identity Center.

Enabling MFA in IAM Identity Center

Click Settings.

Click the Network & security tab.

Click Configure under Multi-factor authentication section.

Select Every time they sign in (always-on) under the "Prompt users for MFA" section.
Select Security keys and built-in authenticators and Authenticator apps under the "Users can authenticate with these MFA types" section.
Select Require them to register an MFA device at sign in under the "If a user does not yet have a registered MFA device" section.
Click Save changes.

Creating a Permission Set

As a best practice, permissions should follow the principle of least privilege access. An enabler of this is through the use of Permission Sets with IAM Identity Center. There are several default Permission Sets created by Control Tower although these don't always meet all requirements.

Behind the scenes one you've created a Permission Set and you've assigned it to the AWS Account(s) that you want that applied to and the Groups you want to associate, an IAM Role is created hwhich has a Trust policy configured to only allow the role to be assumed using SAML and it must have come via the IAM Identity Provider within that Account which was also created by IAM Identity Center.

Click Permission sets.

Click Create permission set.

Select Custom permission set and then Click Next.

Depending on what you're trying to achieve from a permissions allocation perspective, you might attach different types of policies or a combination of them all. This could include AWS Managed Policies, Customer Managed Policies, Inline Policies and or Permissions Boundaries. In this example, I'm going to show it just using an AWS Managed Policy as I only want to give S3 Full Access to people via SSO.

Expand AWS Managed Policies.

Filter by AmazonS3, Select AmazonS3FullAccess and then Click Next.

Give the Permission Set a name and then Click Next.

On the Review and create page, Click Create.

Assigning a Permission Set to a Group

Click AWS Accounts.

Select the AWS Account that you wish to allow Groups access to and Click Assign users or groups.
Click the Groups tab.

Select the Group(s) that you wish to assign the Permission Set too and Click Next.

Select the Permission Sets that you wish to assign and Click Next.

Click Submit.

The next time the user authenticates through Single Sign-On they'll be able to leverage the new permissions as they'll see another role available to them.

Working with the Account Factory

One of the capabilities that Control Tower provides is the Account Factory. Account Factory is used for provisioning new AWS Accounts that will in turn be governed via Control Tower and will be configured with all the baselines that Control Tower will provide such as CloudTrail, Config, CloudWatch as well as guardrails.

The Account Factory provides the ability to create a VPC as part of the Account provisioning. A key challenge of this functionality is that the Network configuration is controlled within the Control Tower Console. This configuration allows you to have the choose whether you have Public Subnets and/or Private Subnets and up to a maximum of 2 Private Subnets per Availability Zone and deployed based on a Well-Architected design. One of the configuration choices is the CIDR range that you select for the entire VPC, but you have no option as to how this is then utilised for the Subnets - it's simply split evenly across them all. Another is the region(s) that this same VPC configuration is implemented in which is determined by the regions that are governed by Control Tower. In situations where you have multiple regions that require VPC's and the Account is provisioned via the Account Factory, this goes against best practices since you end up with overlapping CIDR ranges which would cause network routing issues should these VPC's need to communicate with each other.

Therefore I would recommend disabling this functionality in the Account Factory, by unchecking any regions in the Account Factory Network Configuration. This can be done by:

Click Account factory.

Click Edit.

Unchek all Regions to disable the VPC provisioning element of the Account Factory and then Click Save.

Creating a New AWS Account

Click Account factory.

Click Create account.

Under the Account email section, enter the E-Mail address that you want to associated with the root user of the new AWS Account.
Under the Display name section, enter the Name that you want to assign to the new AWS Account.
Under the Identity Center user email section, Enter the first name and surname of the IAM Identity Center user. This user will then be granted the AdministratorAccess Permission to the new AWS Account.
Under the Organization unit section, Select the OU that you want the new AWS Account to be provisioned in. This will then determine both the Preventative and Detective Guardrails that will be applied to it as part of the Account Baseline.

Once the AWS Account has been fully provisioned the Account will show as Governed within the Control Tower console.

That's all for the basic configuration of AWS Control Tower. In an upcoming post, I'll walkthrough how you can customise Control Tower.

Deploying a Landing Zone with AWS Control Tower - Part 2

Adam Divall — Tue, 06 Sep 2022 20:29:21 +0000

Previously in Part 1 of this Walkthrough, I touched on what a Landing Zone was and a brief background on them before going through how to launch AWS Control Tower as the foundation of a Multi-Account Architecture.

In this , I'm going to walkthrough through some of the initial post configuration activities with Control Tower including setting up the organisational structure and enabling guardrails.

What has Control Tower deployed?

As part of the setup, Control Tower has utilised a number of other AWS Services including:

AWS CloudFormation: This has been utilised for provisioning resources through Infrastructure as Code (IaC) across the multiple AWS Accounts using a combination of both Stacks and StackSets.
AWS CloudTrail: An Organizational Trail has been configured in the Management AWS Account. This Trail is configured to monitor all AWS regions, send its logs to an S3 Bucket that is in the Log Archive account, is encrypted using the KMS CMK that was created during the Control Tower setup, has Log File Validation Enabled, is integrated with CloudWatch Logs and also configured to send notifications to an SNS Topic in the Audit Account when new logs files are sent to the S3 Bucket.
Amazon CloudWatch: CloudWatch Log Groups are created as part of the integration with the CloudTrail Trail, as well as any execution of the Lambda Functions deployed by the Control Tower setup.
AWS Config: An Organization Config Aggregator is created within the Management Account and Config Recorders are created in all AWS Accounts within the AWS Organization with the exception of the Management Account. In addition, several Config Rules will be created as part of the Mandatory Guardrails configured during the setup process.

AWS Config is something that we should have enabled in all AWS Accounts and since Control Tower doesn't create a Config Recorder in the Management Account we'll need to do this. I'll explain how this can be done later using Customisations for Control Tower.
Amazon EventBridge: An EventBridge Rule is created within all AWS Accounts with the exception of the Management Account to trigger a Lambda Function on any Config Rule Compliance Change.
AWS IAM: Several IAM Roles are created including IAM Service Roles. The IAM Roles have IAM Permissions Policies added to them to grant the relevant level of permissions and the Trust Policies are configured to allow the Role Assumption by only specific Source AWS Accounts, AWS Services or via the SSO Identity Provider using SAML.
AWS IAM Identity Center: This service gets enabled within the Home Region of Control Tower to provide Single Sign-On. Several Groups & Permission Sets are created and those Groups then have a Permission Set assigned to them against the provisioned AWS Accounts within the AWS Organization (Management, Audit and Log Archive Accounts). A User is also created that maps to the e-mail address of the root user of the Management AWS Account.
AWS KMS: AWS Managed KMS keys are utilised for the encryption of data at rest in conjunction with the creation of the S3 Buckets. In addition, as part of our setup configuration we also created a Customer Managed Key (CMK) to encrypt the CloudTrail Trail.
AWS Lambda: A Lambda Function is created within all AWS Accounts with the exception of the Management Account. This Function used as part of the mechanism for forwarding notifications of Config Rule compliance changes.
AWS Organizations: This has been used to create the Organization which is crucial to a Multi-Account setup. As part of the Organization it has then setup two Organizational Units (OU) that were defined during the Shared Accounts page of the Control Tower setup. Typically these OUs will be named Security (in previous versions of the Control Tower service it was named Core) and the other Sandbox. In addition, several Service Control Policies (SCP) will have been created as part of the Mandatory Guardrails configured during the setup process.
Amazon S3: Two S3 Buckets are deployed within the Log Archive account.
- One Bucket is used for the storage of CloudTrail and Config logs as part of a Centralised Logging Solution. It is configured with Default Encryption using KMS (AWS Managed Keys), has Versioning enabled, a Bucket Policy to restrict access, is configured to Block Public Access, Access Logging enabled and is configured with a Lifecycle Policy.
- The other S3 bucket is used for the storage of the S3 Access Logs. It is configured with Default Encryption using KMS (AWS Managed Keys), has Versioning enabled, a Bucket Policy to restrict access, is configured to Block Public Access, Access Logging enabled and is configured with a Lifecycle Policy.
AWS Service Catalog: A Portfolio is created with a Product added that provides Control Tower with Account Factory component.
Amazon SNS: An SNS Topic is created within all AWS Accounts with the exception of the Management Account. That Topic has a destination of a Lambda Function that then forwards the message to another SNS Topic in the Audit Account which in turn then sends an e-mail to the the e-mail address assigned to the root user of the Audit Account.
AWS Step Functions: Whilst the Control Tower setup implements State Machines that is used as part of the wider orchestration and for the Account Factory element, these are not visible within any of the AWS Accounts that exist in the AWS Organization. These are under the control and management of AWS as part of the Service Offering.

Organisational Structure

There is a really good blog post from AWS on the Best Practices for Organizational Units that describes each of the OU's and there purpose. However, these are just guidelines and should be tailored to meet the needs of your particular Business.

The diagram below is based on what I typically see when working with Clients.

Creating the OU Structure

Click Organization.

Click Create resources and then Select Create organizational unit.

On the Add an OU page; Enter the OU Name, Click Parent OU and then Select the OU Name to replicate the high level organization layout.

Once configured it will look something similar to the below screenshot.

Only Organisation Units that have been created through the Control Tower Console will show a state of "Registered" on the Organization page in Control Tower. If the Organisation Unit was created either via the AWS CLI or within AWS Organizations, it will show a state of "Unregistered" and will therefore need to be registered by selecting the OU in question on the Organization page in the Control Tower console, selecting "Actions" and then Clicking "Register organizational unit".

Configuring Guardrails in Control Tower

Guardrails are rules that enable you to provide ongoing governance and oversight across your environment. In terms of guardrails within Control Tower there are 2 different types - preventative and detective.

Preventative guardrails are implemented through Service Control Policies (SCP) and stop you from going outside of a specific set of boundaries as defined within the SCP. Since SCPs are implemented at the Organisation level, it provides a layer of control over all AWS Accounts within the organisation without needing to implement something directly in every single AWS Account.

Detective guardrails on the other hand are implemented through Config Rules and will send notifications if a resource within the individual AWS Account doesn't adhere to the settings within the rule. For example, if the rule says that all EBS Volumes must be encrypted and there is an EBS Volume within the Account that isn't it will notify you.

Control Tower guardrails can only be implemented on Organisation Units and not directly on AWS Accounts. Thats not to say you couldn't create something customised, but in that case you'd need to write some automation to do this and it wouldn't be shown within the Control Tower console if something was non-compliant.

When enabling a guardrail in Control Tower, it creates a CloudFormation StackSet in the Management Account and leveraging the integration with AWS Organizations it adds a CloudFormation Stack Instance for each AWS Account that resides within the hierarchy of the OU that the guardrail was enabled on to the StackSet, that in turn creates a CloudFormation Stack within the corresponding AWS Account. Similarly with the disabling of a guardrail, it deletes the Stack Instance from the StackSet and in turn then deletes the Stack from the corresponding AWS Account.

Enabling Guardrails

Click Guardrails.

Find the guardrail that you're want to implement by either scrolling through the pages until you locate it or by using the filter mechanism.

Click the Name of the Guardrail. For example, "Detect whether public read access to Amazon S3 buckets is allowed".

Click Enable guardrail on OU.

Select the OU that you want to enable the guardrail on and then Click Enable guardrail on OU.
Repeat the process again for each OU that you want to enable the guardrail on. Unfortunately at this moment in time it can't be added to multiple OUs at the same time, so has to be repeated.
Repeat the process for all guardrails that you want to enable.

Disabling Guardrails

Click Guardrails.

Find the guardrail that you're want to implement by either scrolling through the pages until you locate it or by using the filter mechanism.

Click the Name of the Guardrail. For example, "Detect whether public read access to Amazon S3 buckets is allowed".

Select the OU where the guardrail has been applied and Click Disable guardrail.
Repeat the process again for each OU that you want to disable the guardrail on. Unfortunately at this moment in time it can't be removed from multiple OUs at the same time, so has to be repeated.
Repeat the process for all guardrails that you want to disable.

In Part 3 of this Walkthrough, I'll continue with the remaining post-deployment activities within Control Tower including configuring IAM Identity Center and provisioning a new AWS Account through Account Factory.

Deploying a Landing Zone with AWS Control Tower - Part 1

Adam Divall — Tue, 06 Sep 2022 20:28:48 +0000

One of the first starting points for many organisations using Public Cloud is the establishment of a Landing Zone. A Landing Zone is a well-architected, multi-account environment that's based on security and compliance best practices..

There are several reasons why organisations leverage a multi-account strategy including but not limited to:

Service Quotas: Each AWS Service typically has a number of different quotas; some of these are soft limits that can be increased by requesting an increase in the limit through a support ticket whilst others have hard limits that cannot be increased.
Limiting the Blast Radius: As an AWS Account is a boundary of isolation, potential risks and threats can be contained within an account without affecting others.
Security Controls: Workloads may have different complianye needs based on the Industry or the Geographical location. Whilst there are synergies between the different compliancy frameworks, the Security Controls that are implemented to help achieve the compliance may need to be implemented in a slightly different manner or may not be required at all.
Billing Separation: AWS Accounts are the only real way to separate items at a billing level e.g. Data Transfer costs.

When I first started using AWS in 2016 there was no pre-packaged solution for a Landing Zone; there were several recommendations provided by AWS but in essence it was something that organizations had to build themselves.

The Landing Zone Implementation was then developed by several different teams at AWS to help Clients expedite the setup and creation of their Landing Zones through the use of automation. This solution accelerator provided extensible capabilities to manage the most complex and advanced environments. However, one of the downsides of it was the fact that it was not officially supported by AWS Support meaning that any issues typically required costly engagements with Professional Services or Partners to remediate.

AWS Control Tower came about as the successor to the AWS Landing Zone solution which is currently in Long-term Support and will not receive any additional features which technically was never officially supported by AWS Support. It's still a relatively new service in AWS Terms having only been made GA in June 2019, although since then it has been enhanced considerably with new features and functionality as well as being made available in more regions. A key differential of Control Tower is that its an AWS Managed Service whilst providing parity with the functionality of what the Landing Zone Implementation does.

Prior to setting up Control Tower, there is a dependency on having 2 unique e-mail addresses that aren't already associated with an AWS Account. These will be used for creation of the Audit and Log Archive Accounts that Control Tower will provision during the setup. The following section will walk you through the setup of Control Tower within an AWS Account that is not part of an existing AWS Organization.

Setting up Control Tower

Login to the AWS Management Console using an Account with administrative permissions and switch to the AWS Region that you're going to use as the Home Region e.g., eu-west-2 (London).
Navigate to the Control Tower Service.

Click Set up landing zone

On the Review pricing and select Regions page, Ensure that the Home Region is set to the region that you want.
Under the Region deny settings section, Click Disabled. If you wish to change this setting later it can be easily modified.
Under the Additional AWS Regions for governance section , leave it as it is for the time being. If you wish to add additional regions to be governed later it can be easily modified.
Click Next.

On the Configure organizational units (OUs) page, Click Next.

On the Configure shared accounts page, Under the Log archive account and Audit account sections enter the corresponding e-mail addresses that you created as a pre-requisite for the deployment and then Click Next.

On the Configure CloudTrail and encryption page; Under the AWS CloudTrail configuration section, Ensure that its set to Enabled.
Under the Log configuration for Amazon S3 section, Configure the retention policy as per your requirements.
Under the KMS Encryption section, Select Enable and customize encryption settings and then Click Create a KMS Key.

This will now open a new browser tab and start the process of creating a Customer Managed Key.

On the Configure key page, Click Next.

On the Add labels page; Under the Alias section, Enter an Alias for the CMK. In this case I've used ControlTowerEncryptionKey.
Under the Description section, Enter a description. In this case I've used Control Tower Encryption Key for CloudTrail.
Click Next.

On the Define key administrative permissions page, Click Next.

On the Define key usage permissions page, Click Next.
On the Review page, Click Finish.

Switch back to the browser tab with the Control Tower Setup.

Under the KMS Encryption section; Select the KMS CMK that was just created and then Click Next.
On the Review and set up landing zone page, Review the configuration settings and Ciick Set up landing zone.

Control Tower will then start the process of setting up the Landing Zone and will take approximately 30-45 minutes.

In Part 2 of this Walkthrough, I'll continue with the initial post-deployment activities within Control Tower including Organisations and Guardrails.

My AWS Certification Journey from 1 to 11

Adam Divall — Fri, 02 Sep 2022 21:21:15 +0000

How did I first get into Technology and AWS?

As a child I always loved playing computer games back in the days when you had to load games via tape cassettes on the Amstrad CPC-464.

I was never particularly academic at school. After completing my GCSE's and quitting my A-Levels after a year; I went to college where I did a BTEC National Diploma in Computer Studies where I found my passion for IT.

After completing college, I got my first full-time job doing Desktop Support just prior to the dotcom era in the late 90’s. Following several internal moves within the company I found myself working more with Internet Technologies but in those days, virtualization was unheard of.

Having worked in the IT Industry since 1998, one thing that has been inevitable is that technology continues to evolve at a rapid pace. I’ve always taken a proactive approach to learning modern technologies as I believe you must continuously keep learning or you become stale and you’re no longer relevant within the industry.

One of those learning curves was the adoption of Cloud Technologies. Fast forward around 10 years, and I then started getting experience with a few different hypervisors such as Virtual Server, Hyper-V and VMware. The majority of my working career has been in the Managed Services arena and a key component of that is helping Clients deliver there strategic outcomes with technology being an enabler.

I’d read a lot about AWS but had never really learnt about it nor had I even used the platform since the company where I was working at the time hadn’t started adopting Public Cloud Services. However, I noticed that the pace of innovation on the AWS platform was gaining significant momentum year on year and thought about how my current role was going to evolve over the next few years. I took the decision to start focusing on the formal AWS Certifications in 2016.

What order did I tackle the exams?

Initially when I began studying for the certifications, there were only 5 in existence and they were the 3 Associates (Architect, Developer & SysOps Administrator) and the 2 Professionals (Architect & DevOps Engineer).

I began with Solution Architect Associate and actually failed the exam by probably a single question. At that stage there was no defined pass mark and AWS also used a bell curve to determine the pass/fail. E.g. 1 Day someone may score 70% and pass and the following day 70% may have been a fail. That being said, I resat the exam 2 weeks later and passed. Following that I then took the SysOps Administrator Associate and the Developer Associate with the next 4 weeks so had completed all 3 associate level exams within the space of a month.

Next I progressed on to the Solution Architect Professional which I spent approximately 6 months studying for by watching hours of AWS re:Invent videos on YouTube, reading the AWS Whitepapers and FAQ's for alot of the AWS Services. I successfully passed that exam on the last day of re:Invent in Las Vegas back in 2017.

AWS then released the Cloud Practitioner exam so I decided to go back and pick that one up which in my personal opinion is more suited to individuals that want to understand the AWS terminology and at a high level the different types of services offered within the platform. Around the same sort of timeline, AWS also began releasing the Specialty track for Certifications.

Following on from the release of the Specialty exams I tackled the Advanced Networking Specialty. I’d read a lot of blog posts around it being the toughest exam behind the Solution Architect Professional so saw it as a bit of challenge given I came from an Infrastructure background and not a Networking one.

Not long after passing the Advanced Networking exam I received an email from AWS Training & Certification advising that my SysOps Administrator and Developer Associate certifications were due to expire in 6 months and rather than have to re-sit both of those I decided to focus on the DevOps Engineer Professional next as to recertify those at the same time. This was at the time when the certifications had to be recertified every 2 years.

After successfully passing the DevOps Engineer Professional, I realised that there were only 2 more specialty exams left that I could take and so decided to pursue the Security Specialty. Security is always top of mind when I’m speaking with Clients and therefore thought this would provide more value in my role.

I did attempt the Big Data Specialty but in no uncertain terms, I crashed and burned on the result and stayed at 8 of the 9 available certifications for a several years. I never tried to reattempt the Big Data Specialty or even consider the Alexa Skill Specialty (both of which have subsequently been retired by AWS).

Moving forward to 2020, I recertified my Solution Architect Professional that then recertified the Solution Architect Associate and the Cloud Practitioner for another 3 years as the renewal requirements had been subsequently changed.

Then last year was renewal year for the rest of my certifications I had. Firstly, I renewed the Advanced Networking Specialty, followed by the DevOps Engineer Professional and then the Security Specialty but also renewing the SysOps Administrator Associate and Developer Associate as a result of the DevOps pass.

I was then due to work on a Client Project relating to Data Lakes and as my AWS knowledge and hands-on experience had increased massively from when I did the Big Data exam, I decided to study for the Data Analytics Specialty that was the sucessor for the Big Data Specialty in order to be more effective on my upcoming project. Again, I sucessfully passed the exam and from speaking with a few colleagues I was advised that there was a lot of overlap with the Database Specialty and therefore studied the varying material to brush up on my knowledge gaps and passed the exam at the first attempt.

Finally, with there only being a single exam left out of the available certifications I tackled the Machine Learning Specialty. Personally I found it the hardest of the lot as I have zero experience of Machine Learning or Data Science but at a high level knew the varying AWS Services relating to Machine Learning. One thing that is significantly different about that exam in comparison to the others was that it more about Machine Learning in the Industry, the different types of algorithms and there use cases.

Has getting Certifications helped advance my career?

Yes. Whilst certifications aren’t the be all and end all, they provide a level of differentiation especially when looking at changing roles be that internally or externally. THat being said though, experience is just as important.

I started in the industry at the bottom in IT and have worked my way up. When I first started back my first full time job back in 1998, I’d obtained my Microsoft MCSE on Windows NT 4 within 6 months, and that allowed me to progress through the varying support functions as I was seen as a Subject Matter Expert and this has continued throughout my career.

What resources did I use to study for those exams?

One thing that I'm an advocate for is to learn by doing although I appreciate thats not always possible. I’ve utilised a number of different resources across the years since starting on the AWS certification path but my current recommendations are:

Cloud Practioner: AAWS Skill builder
Solution Architect - Associate: Adrian Cantrill's Course on Teachable
SysOps Administrator - Associate: Adrian Cantrill's Course on Teachable
Developer - Associate: Adrian Cantrill's Course on Teachable
Solution Architect - Professional: Adrian Cantrill's Course on Teachable
DevOps Engineer - Professional: Adrian Cantrill's Course on Teachable
Advanced Networing - Specialty: Adrian Cantrill's Course on Teachable
Security - Specialty: Adrian Cantrill's Course on Teachable
Data Analytics - Specialty: Stephane Maarek & Frank Kane's Course on Udemy
Database - Specialty: Stephane Maarek & Riyaz Sayyad's Course on Udemy
Machine Learning - Specialty: Mike Chambers (AWS Hero) Course on Teachable

Also there are a number of other great resources such as the AWS and AWS Events Channels on YouTube, AWS Stash, AWS Whitepapers, the AWS Documentation & FAQ's and last but not least Tutorials Dojo for some really good practice exams.

How do I balance work, training, and my personal life?

It can certainly be challenging to try and balance the three, but it requires discipline to come home after a long day at work and then focus on the study without watching any television or socialising. I also have an extremely understanding wife and an impressive set of noise cancelling headphones for when she’s not quite as understanding (only joking!) that block out any noise and distractions.

What is the best advice you have for someone else who is preparing for an AWS certification?

Understand what your objective is and create a plan to achieve it. Learn and understand the material as it'll be more valuable in your career than the certification itself.
Practice exams are invaluable as give you a good indication as to where your weak areas are as well as whether you can handle the time allowance. If you’re not sure about something, research the subject until you feel confident about it and practice playing around with it until it becomes second nature.
Don't be afraid to ask questions if you're unsure on something or don't understand a specific area. There are no stupid questions in my opinion as at some point in our career we've all been in a similar position of starting from no knowledge. TechStudySlack is a great place to ask questions and is completely free as is the AWS Certified Global Community.
For Professional and Specialty exams, a key skill is question technique. What I mean is being able to pick out the key points from the both the questions and the answers to understand what is being asked.
This one may not be applicable to everyone, but its an approach I've used throughout the years not just with AWS exams but others vendors too. I look to understand the total number of questions in the exam and the passing score e.g., 75 Questions and 75% pass mark. In that case I work on the basis of aiming for a minimum of an 80% pass mark so that there is some flexibility. Doing some simple maths 80% of 75 Questions means I'd need to get 60 questions correct to achieve that 80% pass mark. If I've marked more than 15 questions during the exam process, I spend significantly more time reviewing those questions than I would if I'd marked less for review. Note: I only do that because there are no bonuses for getting 100% on an exam over an exact passing score.

What certification am I planning next?

Well as AWS released the SAP on AWS Specialty earlier in the year, I'm going to be aiming for that. I've not seen much available training for it other than on Cloud Academy so am planning on utilising that. Other than that, I need to recertify the Solution Architect Associate and Professional exams both in 2023.

I hope this helps anyone else on there journey. Happy Learning!

Creating a Blog With Hugo and AWS Amplify

Adam Divall — Tue, 30 Aug 2022 19:18:45 +0000

This post is a Walkthrough Guide of how I've created this Blog using Hugo and AWS Amplify.

I'm not a Developer by trade and therefore when determining on what to use for the Blog Software I had the following high-level requirements:

Simple to Setup & Configure
Easy to Use & Maintain on an ongoing Basis
Cost Effective

After reviewing a number of different options following a few hours of reading on Google, I settled on Hugo. What is Hugo, you may ask? Well in short, it's a static site generator. It allows you to create files in markdown format and using some magic it converts it into HTML.

The other thing that I also had little to no experience with, was also AWS Amplify. I'd come across it a few times on Client Engagements in the past but not needed to know much about it other than how it's being used within their Solution. Reading the homepage for AWS Amplify it stated "Build, deploy, and host static websites, single-page web apps, and server-side rendered apps in just a few clicks.". This appeared to hit all the my high-level requirements on the head from the outset in conjunction with Hugo so I got started.

Lets Get Started with Hugo

These instructions are based on using a Windows device, therefore some of the steps may not be applicable if you are using another Operating System.

Install Chocolatey by following the instructions here.
Download the Windows Installer for Go from here and run the Installer by accepting all the default settings.
Download the Windows Installer for GitBash from here and run the Installer by accepting all the default settings.
Install Hugo from either a Command Prompt or from Powershell:

choco install hugo -confirm

From the Command Prompt or Powershell navigate to a location where you wish to store a copy of the Site locally e.g., C:\Data\. For future purposes, I'll assume this is the folder where the Site is going to be placed.
Create a New Site. Replace MyBlog with the name of you want to call your Site. This can be absolutely anything you want it to be, but for future purpose I'll assume the Site is named MyBlog.

hugo new site MyBlog

Change Directory to the MyBlog Directory.

cd MyBlog

Create an empty Git repository.

git init

We now need to choose a theme to use with Hugo. I chose one from Jamstack Themes, specifically Bilberry Hugo. Once chosen, we add the theme as a Git Submodule.

git submodule add https://github.com/Lednerb/bilberry-hugo-theme.git themes/bilberry-hugo-theme

The theme that you choose may have some additional configuration steps required. In the case of the theme that I've used in this example there are some additional steps that are required that are documented on the GitHub Repository. Specifically I needed to do the following:
- Delete the default.md from C:\Data\MyBlog\archetypes.
- Copy the config.toml from C:\Data\MyBlog\themes\bilberry-hugo-theme\ to C:\Data\MyBlog\.

Most of the Site configuration is handled within config.toml. I won't go into the details of the specific settings within it as it'll be different for every person.

Create a Post.

hugo new article/my-first-post.md

Edit my-first-post.md in your IDE of choice. You should find this located in C:\Data\MyBlog\content\article\ and put some content in there.

Run Hugo locally.

hugo server -D

Open a web browser and view how the content is rendered by navigating to http://localhost:1313

Configure GitHub and Commit Code

Login to GitHub within a web browser and create a new repository.
From the Command Prompt, we now need to add the GitHub repository as an origin. This is done by running the following command:

git remote add origin https://github.com/<UserName>/<RepositoryName>.git

Note: Replace <UserName> and <RepositoryName> using the details specific to your GitHub repository.

Select the branch that you're going to associate the current folder with e.g., master and then run the following:

git branch -M master

We now need to stage the content that we want to push to GitHub, Commit those Changes and then Push the files to the repository. This is done by doing the following:

git add *
git commit -m "Initial Commit to Master"
git push -u origin master`

Finally, It's Time to Setup & Configure AWS Amplify

Log in to the AWS Management Console and Navigate to AWS Amplify.
On the All apps page, Click New App & Select Host web app.

On the Getting Started with Amplify Hosting page, Select GitHub & Click Continue.

On the Install & Authorize AWS Amplify page, Choose Only select repositories, and Select the Repositories that you want to provide AWS Amplify with access too and then Click Install & Authorize.

On the Add repository branch page, Select the Repository of the Blog that we've previously committed to and Select the Branch master.

On the Configure build settings page, Click Next.

On the Review page, Click Save and deploy.

AWS Amplify will now deploy the Site for the first time to the master environment and once complete it will look something like the screenshot below.

Before we can continue with any of the additional we need to create a new branch on our repository for staging changes before deploying them to production.

From a Command Prompt or Powershell, Create an additional branch on our repository, Stage the Changes, Commit the Changes and Push to GitHub

git checkout -b development
git add *
git commit -m "Initial Commit to Development"
git push -u origin development

Back in the AWS Console within the App Settings, Expand Learn how to get the most out of Amplify Hosting and Click Set up a test version of your site by connecting a feature branch.

On the Add repository branch page, Select the Branch development and Click Next.

On the Review page, Click Save and deploy.
AWS Amplify will now deploy the Site for the first time to the dev environment and once complete it will look something like the screenshot below.

As both of these sites (master & dev) are both publically available, we may want to password protect the dev environment whilst we're testing new features.

Back in the AWS Console within the App Settings, Click Password-protect your site.

Click Manage Access.

Change the dev Access setting to Restricted - password required. Provide a Username and Password, then Confirm the Password. Click Save.
Back in the AWS Console within the App Settings, Click Enable pull request previews.

Click Enable previews.

Click Install GitHub app. Under Repository Access, Select only selected repositories, Choose the Repository that was created earlier and then Click Save. Close the GitHub tab that is opened.

On the Previews page, Select the master environment and Click Manage.

On the Manage preview settings for master branch page, Enable Pull Request Previews and Click Confirm.

When we now make commits to our dev branch on GitHub, we can now create Pull Requests (PR) from within GitHub and AWS Amplify will run some checks against the PR prior to it being manually approved for merging into the master branch.

Before completing the next steps you must have a domain registered. In this case I had already registered a Domain in Amazon Route 53 and Created a Hosted Zone.

Back in the AWS Console within the App Settings, Click Add a custom domain with a free SSL certificate.

Click Add domain.

On the Domain management page, Select your registered Domain Name and then Click Configure domain.

On the Domain management page, Add the Subdomains as per your requirements and Click Save.

AWS Amplify will then create some DNS Records (A & CNAME) within the Hosted Zone in Amazon Route 53, Register an SSL/TLS Certificate in AWS Certificate Manager and also Create and Configure an Amazon CloudFront Distribution.

Happy Blogging!