Purpose

This user guide provides a detailed overview of the process of creating an AWS landing zone. It helps in understanding the steps required to deploy the AWS landing zone as per the below functional architecture.

This guide is written for a Dev(Sec)Ops engineer who will be performing an installation and maintenance of the landing zone. The guide may also be useful for Business Security and Compliance users who are seeking to understand how the Landing Zone adds to their overall compliance posture.

• The client operates in a highly regulated industry
• The transit gateway is going to auto-accept a join requests *All communication with a public internet is going to happen only through a Network Firewall

• The deployer - the engineer deploying the landing zone using this user guide
• The approver - somebody with an authority to approve requested action

• AWS CLI v2.8.2
• Terraform v1.4.5
• git v2.38.1

1. AWS Account which will be used as a Management Account.
2. Setup of AWS SSO by any supported Identity Provider.
3. Setup of AWS Organizasion (This will be done automatically while setting up SSO)
4. Deployer should be a part of admin permission set for Management account.
5. Complete authentication with aws credentials i.e. AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN
   1. Go on AWS access portal url.
   2. Select Management account.
   3. Click on Command line or programmatic access.
   4. Copy the environment variable and paste on AWS cli to get authenticated.
6. Increase limit to create AWS account API calls. This landing zone deployment requires at least 18 accounts including the management account.
7. There are few steps which require manual approval and deployer should be approving them appropriately.

Follow the steps to fork/clone the awslz git repo on your local machine.

1. Create a personal access token (PAT) on GitHub. Goto GitHub profile > Settings > Developer Settings > Personal Access Tokens > Generate New Token.
2. Set username and generated PAT in your machine.
3. Clone the repo: git clone https://github.com/cldcvr/aws-landing-zone.git

Make sure the configuration parameters inside the file lzconfig.yaml are properly set.

This can be done in two ways:

1. By manually editing lzconfig.yaml.
2. By filling the form on the UI

NOTE: The UI is supposed to push whatever values entered by the user to the lzconfig.yaml and commit the changes to Git only.

Authenticate the shell with AWS IAM credentials belonging to the administrator user of the management account and trigger the script 0-bootstrap/bootstrap.sh

#!/bin/sh
# Create S3 bucket and dynamodb table in master account for terraform
terraform -chdir=tf-prerequisites init
terraform -chdir=tf-prerequisites apply --auto-approve
# Apply terraform to the bootstap directory and fetch Account Id of newly created account in a variable
terraform -chdir=bootstrap init -backend-config=backend.conf
terraform -chdir=bootstrap apply --auto-approve
# Assume role inside newly created account and apply terraform to create CICD stack
terraform -chdir=cicd init -backend-config=backend.conf
terraform -chdir=cicd apply --auto-approve

The script will do terraform apply in 0-bootstrap/tf-prerequisites directory first which will create an S3 bucket and DynamoDB table which will be used by Terraform to store the state and state locking mechanism respectively in management account.

Afterwards, 0-bootstrap/bootstrap directory will get triggered which will create and Organization Unit as well as AWS Account called LZ CICD. This newly created account will hold our CICD automation stack.

In the wake of best practices, we will not be maintaining keys or passwords or anything sensitive for authentication to the GitHub repo. The user have to manually perform the below steps for the authentication part:

1. Go into the newly created LZ CICD web console
2. Go into AWS CodePipeline
3. Search for Connections in the Settings
4. Approve the connection as shown on the screen which will transition to the Available state from the Pending one.

NOTE: Approval needs to happen on the GitHub side.

After Step 2 is successful, we have to go to AWS Console and manually trigger the pipeline as shown below. The video on how to trigger a pipeline.

In order to know what is happening with our pipeline in real-time, we can view logs of the same in AWS CodePipeline UI as shown below. The pipeline will run in this fashion.

1. Log terraform plan to the CodePipeline

2. Wait for manual approval of authorized approvers only (the notification for approval can be sent to Email or AWS SNS, but the example below shows approving from AWS CodePipeline GUI without any notification to the user being sent) The video on how to view the logs on the various stages.

3. Approve the pipeline as shown below The video on how to approve the pipeline step.

There are a total of 6 Manual approvals in the entire pipeline. Listed below :

• ApprovalOrgHierarchy (Stage OrgPrerequisites)
• ApprovalLoggingBuckets (Stage OrgPrerequisites)
• ApprovalVPC (Stage OrgPrerequisites)
• ApprovalDNSResolver (Stage OrgPrerequisites)
• ApprovalWorkloadVPC (Stage OrgPrerequisites)
• ORGMAINApproval (Stage OrgMain)

├── 0-bootstrap
│   ├── bootstrap.sh
│   ├── bootstrap
│   ├── cicd
│   │   ├── inventories
│   │   └── modules
│   │       └── cicd
│   │           └── templates
│   └── tf-prerequisites
├── 1-org
|   ├── aws-secure-baseline
│   │   ├── alarm-baseline
│   │   ├── iam-ebs-secure-baselines
│   │   └── s3-baseline
│   ├── billing
│   ├── cloudtrail
│   ├── cloudwatch-s3-exporters
│   │   ├── Dev
│   │   ├── Prod
│   │   └── Staging
│   ├── config
│   ├── detective
│   ├── guardduty
│   ├── infra-cicd
│   ├── kms
│   ├── logging-buckets
│   ├── permission-sets
│   ├── rego-s3-sync
│   ├── securityhub
│   ├── shared-service
├── 2-network
│   ├── dns-hub
│   │   ├── dns-securtiylogging
│   │   ├── firewall
│   │   ├── route53resolver
│   │   ├── transit-gateway
│   │   └── vpc
│   └── network-hub
│       ├── firewall
│       ├── high-trust
│       ├── transit-gateway
│       └── vpc
├── 3-env
│   ├── dev
│   │   ├── transit-gateway
│   │   └── vpc
│   ├── prod
│   │   ├── transit-gateway
│   │   └── vpc
│   └── staging
│       ├── transit-gateway
│       └── vpc
├── permissionset-compliance
│   ├── report
│   └── validation
├── rego
│   └── rules
├── terraform
│    ├── modules
│    └── scp-stored    
├── Dockerfile
├── apply.sh
├── destroy.sh
├── destroy-all.sh
├── global-lz-state-backend.conf
├── lzconfig.yaml
├── nuke.sh
├── plan.sh
├── prebuild.sh
├── regula-prebuild.sh
├── regula-spec.yaml
├── regula.sh
├── terraform
├── terraform-exec.sh
└── terraform-spec.yaml

As of now, you have to alter the existing terraform code to be able to alter the landing zone compartments. The landing zone customizability is the whole goal of the version three of the landing zone.

Firstly, you have to decide where to deploy your workload as the landing zone has three pre-configured compartments: development, staging, and production. Once you made a decision, you should utilize a deployment pipeline to release your workload.

The high-level breakdown looks as below:

Total cost per month - around USD 1159.

NOTE: Please, take note that the above breakdown is given for indicative purposes.

The detailed price breakdown could be found here.

Our team has thoroughly tested the landing zone and achieved almost 100% compliance for the below frameworks:

1. AWS Foundational Security Best Practices v1.0.0
2. CIS AWS Foundations Benchmark v1.4.0
3. NIST Special Publication 800-53 Revision 5
4. PCI DSS v3.2.1

The complete report is available here. The security scan is executed on a regular basis to ensure that there is no any breaks.

Don’t worry, we are always ready to lend you a hand! Send us an email at lzhelp@ollion.com with your problem and our support team will reach out to you shortly.

Obviously! If you would like to fix the landing zone your self, please submit a pull request into the landing zone repository. Otherwise, please email to the lzadmin@ollion.com with the detailed problem description.

The system has a set of connectors for the other VCS system, but an additional configuration has to be made.

Please, describe the problem clearly and send an email to lzhelp@ollion.com.

There is no known bug so far, but you’ll be able to raise a bug in our public repository.

To report a bug, please create an issue in GitHub repository. Depends on the bug type, please use appropriate label:

Please, spend some time in writing a good problem statement and clear title. The well written description will drastically increase chance for the issue to be picked and fixed. Here is a good article on how to write a good GitHub issue.

• Brendon Byrne, Ollion, VP - Compliance Solutions
• Sachi Dubey, Ollion, Senior Project Manager
• Gourav Joshi, Ollion, Lead DevOps Engineer
• Leslie Dsouza, Ollion, DevOps Engineer
• Mahek Katariya, Ollion, DevOps Engineer
• Bhushan Rane, Ollion, Sr. DevOps Engineer
• Kangwei Wong, Ollion, Solutions Architect
• Sachin Gupta, Ollion, Solutions Architect
• Aishwarya Srivastava, Ollion, UX Designer
• Vivek Yadav, Ollion, Developer
• Alexander Makarov, Ollion, Technical Product Owner
• Akash Jaiswal, Ollion, Sr. DevOps Engineer

• Getting started: Are you a first-time AWS user?
• Getting Started with AWS Organizations
• Tutorial: Creating and configuring an organization