Skip to content
Terraform Module for AWS Landing Zone
JavaScript HCL Smarty
Branch: master
Clone or download
euliancom Merge pull request #117 from TerraHubCorp/dev
Fixing bug related to dynamic backend definition
Latest commit f65909b Aug 27, 2019
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
components
docs minor improvement Jun 6, 2019
examples
modules minor fix to backend path Aug 27, 2019
tests add missing folder Jun 5, 2019
.codeclimate.yml
.eslintignore Remove package.json from scripts Jul 15, 2019
.gitignore
.terrahub.yml refactoring Aug 23, 2019
LICENSE.md
README.md
ROADMAP.md add roadmap skeleton Aug 19, 2019
main.tf fix issue 110 Aug 22, 2019
outputs.tf
package.json add description related to landing_zone_backend Aug 27, 2019
terraform.tfvars remove trailing slash Aug 26, 2019
variables.tf

README.md

terraform-aws-landing-zone

AWS Landing Zone is a solution that helps customers more quickly set up a secure, multi-account AWS environment based on AWS best practices. This repository contains terraform module landing_zone that dynamically deploys components of AWS Landing Zone solution based on input list of .tfvars files.

Additionally, there are 2 more terraform modules: landing_zone_reader_config and landing_zone_reader. They allow AWS Landing Zone consumers to reuse terraform outputs programmatically. This way administrators of AWS Landing Zone control who can manage landing_zone module and who can consume landing_zone module's outputs in read-only mode.

NOTE: Current implementation is fully compatible with terraform v0.12+. Switch to branch v0.11 if you still using terraform v0.11.x and below.

Quick Links: How Does This Module Work | What Components Are Available | Why to Use This Solution

How Does This Module Work

Terraform module landing_zone is based on standard module structure guidelines and contains the following folders:

  • root folder - module's standard terraform configuration
  • components - yaml-based and terraform compatible configurations
  • examples - different ways to combine components as part of this module
  • modules - standalone, reusable and production-ready modules
  • tests - set of automated tests to use in CI/CD pipelines

This terraform module requires the following prerequisites / dependencies:

To get started, simply include main.tf into your terraform codebase:

module "landing_zone" {
  source    = "TerraHubCorp/landing-zone/aws"
  version   = "0.1.5"
  root_path = path.module
  landing_zone_providers  = var.landing_zone_providers
  landing_zone_components = var.landing_zone_components
  landing_zone_backend    = var.landing_zone_backend
}

NOTE: Make sure to include variables.tf and whatever makes sense from outputs.tf

To simplify and make it easier to understand, we included default values in terraform.tfvars:

landing_zone_providers = {
  default = {
    account_id = "123456789012"
    region     = "us-east-1"
  }
  [...]
}
landing_zone_components = {
  landing_zone_vpc = "s3://terraform-aws-landing-zone/mycompany/landing_zone_vpc/default.tfvars"
  [...]
}
landing_zone_backend = {
  backend = "local"
  path    = "/tmp/.terrahub/landing_zone"
}

NOTE: Placeholder [...] from above is used to suggest that similar syntax can be added. Remove it or update in order to have valid HCL / terraform configuration.

This means that before you use this terraform module, you will need to:

  1. Change landing_zone_providers to values that describe your AWS Organization account
    • default reflects the default setup corresponding to AWS Organization account; add more providers by extending landing_zone_providers map with extra AWS accounts and/or AWS regions
      • account_id reflects the AWS account used to deploy AWS resources; prevents provisioning AWS resources into wrong AWS account in case of valid AWS credentials
      • region reflects the AWS region used to deploy AWS resources; create 2 different providers for the same AWS account, but different AWS regions
  2. Change landing_zone_components to values that fit into your AWS Landing Zone use case
    • each key from landing_zone_components map represents the name of the component from this list of available components
    • each value from landing_zone_components map represents the path to .tfvars file on S3 and/or local disk
      • each .tfvars file must use HCL format; DO NOT USE other formats like JSON or YAML
  3. Change landing_zone_backend to values that reflect your terraform backend where .tfstate files are stored (in variables.tf default parameter value is defined as local)

NOTE: Terraform module landing_zone can have tens, hundreds or thousands of deployable components, but not all of them should be and will be deployed. At runtime, components that are not part of landing_zone_components variable will be ignored.

Landing Zone Reader

Terraform module for AWS Landing Zone can create, retrieve, update and destroy resources in your AWS accounts. But in some cases, your teams will need ONLY retrieve capability with implicit deny of all the other capabilities like create, update or destroy resources. In order to achieve this feature, we have created 2 extra terraform modules: landing_zone_reader_config and landing_zone_reader.

Module landing_zone_reader_config must be executed first by passing the same parameters as in module landing_zone:

module "landing_zone_reader_config" {
  source    = "./modules/landing_zone_reader_config"
  root_path = path.module
  landing_zone_providers  = var.landing_zone_providers
  landing_zone_components = var.landing_zone_components
}

After landing_zone_reader_config module configures everything, second step is to use the landing_zone_reader module:

module "landing_zone_reader" {
  source = "./modules/landing_zone_reader"
}

IMPORTANT: landing_zone_reader_config module must write output results into .tfstate files before landing_zone_reader module can execute successfully terraform init. Therefore these two modules cannot be used in parallel or combined with depends_on argument. We recommend to use them sequentially.

More Examples

What Components Are Available

AWS Landing Zone solution is defined by the following strategy:

  1. Multi-Account Structure
    • AWS Organization Account
    • Shared Services Account
    • Log Archive Account
    • Security Account
  2. Account Vending Machine
  3. User Access and Identity Management
  4. Monitoring and Notifications

NOTE: Current implementation of this terraform module covers only Multi-Account Structure components (work in progress).

Multi-Account Structure

AWS Landing Zone Multi-Account Architecture

Based on the multi-account architecture, here below are currently available components:

  1. landing_zone_pipeline_s3_bucket
  2. landing_zone_pipeline_artifact_s3_bucket
  3. landing_zone_code_pipeline
  4. landing_zone_code_pipeline_role
  5. landing_zone_code_pipeline_role_policy
  6. landing_zone_code_build
  7. landing_zone_code_build_role
  8. landing_zone_code_build_role_policy
  9. landing_zone_organization
  10. landing_zone_organization_policy
  11. landing_zone_organization_policy_attachment
  12. landing_zone_organization_accounts
  13. landing_zone_organization_unit

Account Vending Machine

AWS Landing Zone Account Vending Machine Architecture

Based on the account vending machine architecture, here below are currently available components:

  1. Coming soon ...

User Access and Identity Management

AWS Landing Zone User Access and Identity Management Architecture

Based on the user access architecture, here below are currently available components:

  1. Coming soon ...

NOTE: This solution is relying on cross-account role called OrganizationAccountAccessRole. Follow this link to learn more and/or create missing IAM role(s)...


Monitoring and Notifications

AWS Landing Zone Monitoring and Notifications Architecture

Based on the notifications architecture, here below are currently available components:

  1. Coming soon ...

Why to Use This Solution

No need for code changes

Terraform module for AWS Landing Zone solution is up to 10 lines of code that receives a list of .tfvars files as input variables which describe providers (to be read: AWS accounts and AWS regions) and configs (to be read: AWS resources)

No need for code rewrites

This implementation engages microservices architecture, allowing any component to be replaced with another component (or multiple components)

No need for hard-coded values

Existing AWS resources created by your team can be reused programmatically as read only values by other teams' terraform configurations

No need to rebuild from scratch

Existing AWS resources in your current AWS account(s) can be imported and reused without downtime by this terraform module via terraform import command

No need to exclude pieces of account(s) baseline

Some customers were avoiding in the past AWS Landing Zone because it doesn't support some kind of 3rd party SSO solution or 3rd party Logging solution. By using terraform, we can easily bring those solutions into AWS Landing Zone as a set of components and empower customers to continue using best practices of both worlds

Additionally, this module helps enforce best practices

  • By removing the need for access to AWS root account(s)
  • By using IAM cross-account roles and/or STS temporary credentials
  • By enabling centralized CloudTrail logs and cross-region replication of CloudTrail logs
  • By empowering complex organizations to separate roles and responsibilities (e.g. InfoSec team can place explicit deny on IAM, VPC, SG and STS for other teams and/or other environments like production or pre-production)
You can’t perform that action at this time.