The AWS Landing Zone is a great way to provision the foundation for your consumption of AWS, with guardrails and management via infrastructure as code. Further details can be found on the AWS site: https://aws.amazon.com/solutions/aws-landing-zone/, or Cevo’s factsheet here.
In this blog I’ll walk you through the following three actions that you may find useful when managing your AWS Landing Zone:
- Fixing a common deployment issue
- Applying some basic source code management for the Landing Zone codebase
- Creating new roles and deploying across the Landing Zone organization via code
Fixing a common deployment issue with Landing Zone
Deployment of the Landing Zone is pretty straightforward, however there is one issue you may hit along the way – causing the Landing Zone stack to fail and roll back:
This is caused by an errant region in the mix that appears not to support stacksets. To be honest I haven’t delved too deeply into this as all the organisations I’ve done deployments with have not wanted any workloads outside of Australia, so we lock down foreign regions anyway.
Let’s open up the base template for the Landing Zone and ‘fix’ the code base before it deploys the pipeline for the first time. We do this by changing the BuildLandingZone default to No
BuildLandingZone:
Description: Do you want to trigger the pipeline right away to build the Landing Zone?
AllowedValues:
– ‘Yes’
– ‘No’
Default: ‘No’
Type: String
Or, if you’re using the console, use this field
Now we deploy the Landing Zone as usual from the base template, however it won’t create the Landing Zone, instead will load the Landing Zone source into an S3 bucket – we will update this bucket to make sure we’re not including any dodgy regions.
- side note, when we disable Auto Build there is an underscore (‘_’) prepended to the configuration zip file – we simply remove the _ when we want to deploy
As the bucket is protected by encryption, you’ll first need to head over to KMS and update the policy on the Customer managed key – AwsLandingZoneKMSKey – to allow your user to download. Make sure you clean this up after once you have your proper roles in place. For the sake of this blog, I’ve used a temporary user which I’ll be deleting after.
Once you’ve given yourself access to the configuration zip file and downloaded – open manifest.yaml to view the regions
I strongly suspect that it is Hong Kong causing some of the issues but as I don’t want anything in many of these regions I mostly just remove them and leave our region and the US regions.
So this:
Goes to this:
And we repeat for the region lists in manifest.yaml
Now, we could just upload this back to the bucket as a new version of the zip file, remove the underscore from the name the pipeline will kickoff and deploy the Landing Zone. However first I’d like to put my infrastructure-as-code in source control so we can version, manage and collaborate on the Landing Zone codebase.
Applying some basic source code management for the Landing Zone codebase
I’ll be using GitHub, but you may like to use CodeCommit or something like Bitbucket or GiLlab, in which case the steps will be a little different.
I’ll add all the Landing Zone source files to my git repo:
And then update the source settings of the CodePipeline to use Github
Once this is done, you are ready to release the change and the Landing Zone will proceed to build – hopefully successfully now that we’ve altered the regions
Creating new roles and deploying across the Landing Zone organization via code
Once the Landing Zone is complete, we will want an admin role to use to navigate through the accounts, not use local IAM users. In real life we would create roles to use with federation, but this will serve as a simple example.
First we open our manifest.yaml file and enter the following piece of code:
#THis is a customization to add a central role for all LZ accounts
#relies on new CF template and folder
– name: LZCentralAdminRole
baseline_products:
– AWS-Landing-Zone-Account-Vending-Machine
template_file: templates/custom/add-lzadmin-role.yml
deploy_method: stack_set
Then we add a new folder under templates called ‘custom’ and create a new template under there for the new role – add-lzadmin-role.yml
In this file we create the following code:
AWSTemplateFormatVersion: 2010–09–09
Resources:
AWSTemplateFormatVersion: 2010-09-09
Resources:
LZRole:
Type: AWS::IAM::Role
Properties:
RoleName: LZCentralAdminRole
ManagedPolicyArns:
– arn:aws:iam::aws:policy/AdministratorAccess
AssumeRolePolicyDocument:
Version: 2012-10-17
Statement:
– Effect: Allow
Principal:
AWS: arn:aws:iam::<your root account>:root
Action: sts:AssumeRole
Add the template in your source control and push the change
git add .\templates\custom\add-lzadmin-role.yml
git commit -m “adding new role for central admin”
git push
CodePipeline will pick up the update in GitHub and kick off the pipeline. Once the pipeline has completed the deployment we can check the change by assuming this role in any of the accounts:
https://signin.aws.amazon.com/switchrole?roleName=LZCentralAdminRole&account=<targetaccount>
I hope these examples are useful, let me know if you have better/different ways of managing some of these scenarios, or if there are other things you’d like us to cover in this blog – hit me up on twitter or contact the team at Cevo.
