For the purpose of example testing, the backend is set to be local. For production, it's advised to switch to a remote backend like S3 for better state management.
Enterprise-grade AWS Landing Zone automation with Terragrunt
A comprehensive Terraform module for deploying secure, scalable AWS multi-account environments following AWS best practices and Control Tower governance.
This Terragrunt module provides a complete solution for establishing an AWS Landing Zone with Control Tower, enabling organizations to deploy secure, well-architected multi-account environments at scale. Built by CCL Consulting, this module implements AWS best practices for enterprise cloud governance.
- AWS Control Tower Integration - Automated Landing Zone deployment with guardrails
- Multi-Account Architecture - Secure account isolation following AWS best practices
- Multi-Region Support - Deploy across multiple AWS regions with centralized governance
- Organizational Units - Structured account organization with workload separation
- Security by Design - Built-in security controls and compliance frameworks
- Cross-Account Backup - Automated backup policies across all accounts
- Comprehensive Tagging - Cost allocation and governance through standardized tagging
- Extensive Examples - Production-ready configurations for various use cases
graph TB
subgraph "AWS Organization"
ROOT[Management Account]
subgraph "Security OU"
SEC[Security Account]
LOG[Logging Account]
end
subgraph "Common Services OU"
BACKUP[Backup Account]
SHARED[Shared Services]
end
subgraph "Workloads OU"
subgraph "Production OU"
PROD1[Production App 1]
PROD2[Production App 2]
end
subgraph "Staging OU"
STAGE1[Staging App 1]
STAGE2[Staging App 2]
end
subgraph "Development OU"
DEV1[Development App 1]
DEV2[Development App 2]
end
end
subgraph "Suspended OU"
SUSP[Suspended Accounts]
end
end
ROOT --> SEC
ROOT --> LOG
ROOT --> BACKUP
ROOT --> SHARED
ROOT --> PROD1
ROOT --> PROD2
ROOT --> STAGE1
ROOT --> STAGE2
ROOT --> DEV1
ROOT --> DEV2
ROOT --> SUSP
- AWS Management Account with administrative access
- Email Domain for account creation (supports
+addressing) - Terraform >= 1.2.0
- Terragrunt >= 0.50.0
-
Clone and Configure
git clone https://github.com/YOUR_GITHUB_USERNAME/aws-account-module-terragrunt.git cd aws-account-module-terragrunt cp examples/simple-startup.hcl terragrunt.hcl -
Customize Configuration
# terragrunt.hcl inputs = { email_domain = "your-company.com" region = "us-east-1" org_accounts = { workloads = { prod = ["production-web", "production-api"] staging = ["staging-web", "staging-api"] dev = ["development"] } common_services = ["shared-services", "monitoring"] } }
-
Deploy
terragrunt init terragrunt plan terragrunt apply
| Variable | Description | Type | Example |
|---|---|---|---|
email_domain |
Domain for account emails | string |
"company.com" |
| Variable | Description | Type | Default |
|---|---|---|---|
region |
Primary AWS region | string |
"eu-west-3" |
backup_region |
Secondary region for backups | string |
"eu-west-1" |
governed_regions |
Control Tower managed regions | list(string) |
["eu-west-3"] |
email_local_part |
Email prefix for accounts | string |
"aws" |
org_accounts |
Account structure definition | object |
See examples |
tags |
Resource tags | map(string) |
Basic CCL tags |
Accounts are created using the format: {email_local_part}_{account-name}@{email_domain}
Examples:
aws_production-web@company.comaws_security@company.comaws_logging@company.com
We provide comprehensive examples for different organizational needs:
| Example | Use Case | Features |
|---|---|---|
| Simple Startup | Small organizations | Single region, basic accounts, cost-optimized |
| Development Environment | Dev/Test environments | Team-based accounts, auto-shutdown policies |
| Production Landing Zone | Large production | Multi-region, comprehensive governance |
| Enterprise Multi-Region | Global enterprises | Multi-region, business unit organization |
View Detailed Examples Documentation
- AWS Control Tower Guardrails - Preventive and detective controls
- IAM Best Practices - Least privilege access with proper role separation
- CloudTrail Logging - Centralized audit logging across all accounts
- AWS Config - Configuration compliance monitoring
- Cross-Account Backup - Automated backup policies with encryption
- Network Security - VPC isolation and security group controls
This module helps achieve compliance with:
- SOC 2 Type II - Security, availability, and confidentiality controls
- ISO 27001 - Information security management systems
- PCI DSS - Payment card industry data security standards
- HIPAA - Healthcare information protection (when properly configured)
- GDPR - General Data Protection Regulation compliance
tags = {
# Governance
"Owner" = "CCL Consulting"
"Provisioned by" = "Terraform"
"Environment" = "Production"
"CostCenter" = "Infrastructure"
# Security
"DataClass" = "Internal"
"SecurityLevel" = "High"
"Backup" = "true"
# Operations
"Monitoring" = "Enhanced"
"AutoShutdown" = "false"
}inputs = {
region = "us-east-1"
backup_region = "us-west-2"
governed_regions = [
"us-east-1",
"us-west-2",
"eu-west-1"
]
}inputs = {
org_accounts = {
workloads = {
prod = [
"prod-web-frontend",
"prod-api-backend",
"prod-data-analytics"
]
staging = [
"stage-web-frontend",
"stage-api-backend"
]
dev = [
"dev-shared",
"dev-team-alpha",
"dev-team-beta"
]
}
common_services = [
"shared-networking",
"shared-monitoring",
"shared-cicd",
"shared-dns"
]
}
}Run the complete test suite:
# Validate configuration
terragrunt validate
# Security scan
checkov -d . --framework terraform
# Lint code
tflint --recursive
# Test examples
terragrunt plan --terragrunt-config-path examples/simple-startup.hcl- Cross-Account Dashboards - Centralized monitoring across all accounts
- Automated Alerting - Cost, security, and operational alerts
- Cost Analytics - Detailed cost breakdown by account and tag
- S3 Bucket Encryption - Ensure all buckets are encrypted
- Root Access Monitoring - Alert on root account usage
- Security Group Rules - Validate security group configurations
- IAM Policy Compliance - Check for overly permissive policies
This module includes a comprehensive GitHub Actions workflow:
- Terraform Validation - Syntax and configuration validation
- Security Scanning - Checkov security analysis
- Code Linting - TFLint code quality checks
- Example Testing - Validate all example configurations
- Automated Releases - Semantic versioning and release notes
# Import existing accounts
terragrunt import aws_organizations_account.example 123456789012
# Validate configuration
terragrunt plan# Update module version
git fetch --tags
git checkout v2.0.0
# Review changes
terragrunt plan
# Apply updates
terragrunt apply| Issue | Solution |
|---|---|
| Control Tower not available | Verify region support and account eligibility |
| Email conflicts | Use unique email addresses or subdomain |
| Permission errors | Ensure proper IAM permissions for Organizations |
| State locking | Check DynamoDB table access and state bucket |
# Enable detailed logging
export TF_LOG=DEBUG
export TERRAGRUNT_LOG_LEVEL=debug
terragrunt applyWe welcome contributions! Please see our Contributing Guide for details on:
- Development workflow
- Code standards and formatting
- Testing requirements
- Pull request process
- Enterprise Support: Contact our cloud architecture team
- Email: rsinien@ccl-consulting.com
- Website: ccl-consulting.com
- Issues: GitHub Issues
- Discussions: GitHub Discussions
This project is licensed under the MIT License - see the LICENSE file for details.
- HashiCorp - For Terraform and Terragrunt
- AWS - For Control Tower and Organizations
- Gruntwork - For Terragrunt development
- CCL Consulting - For module development and maintenance
If this module helped you, please consider giving it a star!
Made with care by CCL Consulting