Landing zone solution helps to save time by re-using best practices for AWS cloud. Multi-account strategy is an enabler of secure and scalable workloads providing:
- Identity and access management
- Governance
- Data security
- Robust networking
- Logging
There are different approaches for accomplish this however we consider that one of the most effective is AVM (Account Vending Machine) for the following reasons:
- Isolates - It can be deployed as a separate and individual workload
- Decoupled - There is no dependency with the LZ however it depends on other AWS Services
- Repeatable - Each account is a template and can be applied over different accounts, useful for mid-size companies that divide groups in more than one account.
- Easy for modify - Based on clear phases applied over an account it is easy to modify the process, however we must be careful due to different version of baseline account can drive to vulnerabilities (*).
Some of the pitfalls that we found are:
- Add or remove in a tailored fashion components is not part of the main use cases. That mean after you got it is hard to change it.
- AWS dependencies on Cloud Formation and Service Catalog. There is no alternative for replacing those using this approach.
- Currently Control Tower can do it however baseline accounts will differ so we can be in the scenario described before (*).
There are different flavors on implementations but all have point described above in common.
├── terraform
│ ├── main.tf [RO File Autogenerated] Entry point for Terraform
│ ├── variables.tf [RO File Autogenerated] Variables in TF
│ ├── output.tf [RO File Autogenerated] Outputs in TF
│ ├── implementations
| | ├── imports.txt Reference of all files to be merged.
│ | └── core
│ | ├── security Directory will security elements
│ | | └── security-*-.tf
│ | ├── logarchive Directory will logarchive elements
│ | | └── logarchive-*-.tf
│ | ├── sharedservices Directory will sharedservices elements
│ | | └── sharedservices-*-.tf
│ | ├── network Directory will network elements
│ | | └── network-*-.tf
│ | ├── *-template.tf Files to be used as modules instanciations
│ | ├── *-variables.tf Files to be used as modules variables
│ | └── *-outputs.tf Files to be used as modules outputs
│ └── modules Module dirctory where you can have modules and submodules
│ ├── organizations
│ ├── common Services modules use by other services
│ │ ├── s3
│ │ └── iam
│ ├── config
│ └── guard-duty
├── automation
│ ├── cicd (CI/CD scripts)
│ │ ├── terraform-pre-run.py
│ │ ├── prepare.sh
│ │ └── provision.sh
│ ├── credentials (Credentials generated and used by scripts)
│ └── deploy (Deployment scripts)
└── config
└── main.config.yml Main configuration
1 - Export your environment variables to be used by terraform
export AWS_ACCESS_KEY_ID=[your access ID ]
export AWS_SECRET_ACCESS_KEY=[your secret key]2- Execute pre run in which all files are going to be merged
python3 automation/cicd/terrraform-pre-run.py3- Execute terraform initialization command
terraform init ./terraform4- Execute terraform plan command
terraform plan ./terraform5- Execute terraform plan command
terraform apply ./terraform-
Read carefully names used in AWS LZ and try to follow the same convention.
-
Modules has to represent a module in our application.
-
Modules promotes reusability and are part of building pattern if you think that your module cannot be part of a module or your module will not be generic enough please discuss first doing any implementation of it.
-
Modules with submodules is allowed but make sure if that module has to be tied with main module and not be part of more generic / common service if more than one module use it.
-
Each template must have a header with a reference of what is instantiating in that block of code and it dependencies.
-
Inner modules variables generic because can be used in differents intantiations
-
Outter variables uses by templates must to be very specific to make reference to what is being store on them.
-
Module required variables must match with Provider API values not provided can be default.
-
All resources in which provider accept tags must follow our tagging convention
-
Naming for resouces in modules are the following
aws_lz_[module] aws_lz_[sub-element] aws_lz_[sub-element]_[custom implementation] -
Naming for module instance is more specific to give context of it using
module "aws_lz_organizations_ou_core" { -
Tags conventions must to be provided in all AWS element that support them.
- ProjectID Project ID
- Environment Environment in which that componets was created
- AccountID Account ID
- Key Name Key name to identify that item in the cloud
Make sure to respect names and case
| Module | Completeness | Documentation |
|---|---|---|
| cloudtrail | WIP | README |
| config | WIP | README |
| security | WIP | README |
| extension | WIP | README |
| common | WIP | README |
| guarddutty | WIP | README |
| iam | WIP | README |
| s3 | WIP | README |
| kms | WIP | README |
| ram | WIP | README |
| organizations | WIP | README |
| sns | WIP | README |
| security | WIP | README |
| transit-gateway | WIP | README |
| Module | common | shared-services | organizations | security | config |
|---|---|---|---|---|---|
| common | |||||
| shared-services | |||||
| security | |||||
| organizations | |||||
| config |