cloudless
by skunxicat
terraform-modules infrastructure-as-code terraform-best-practices composable-infrastructure

Terraform Modules Best Practices for Production Systems

The Pattern We Found

Every cloudless foundation needs the same building blocks:

  1. Foundation (cloudless-infra) - labeling, environment, consistency
  2. Compute (terraform-aws-lambda-runtime) - ECR + SSM for custom runtimes
  3. Interface (terraform-aws-rest-api or terraform-aws-website) - how users reach your system

Terraform Module Design Principles

Single Responsibility Principle: Each terraform module does one thing perfectly

  • terraform-aws-website = CloudFront + S3 + SSL + Route53 from FQDN
  • terraform-aws-lambda-runtime = ECR + SSM for runtime sharing
  • terraform-aws-rest-api = API Gateway + keys + usage plans

Infrastructure as Code Best Practices:

  • CloudPosse Compatible: All modules use context.tf for consistent labeling
  • Git Sourceable: Direct GitHub references for version control
  • Minimal Interface: Expose only what users need, abstract the complexity
module "website" {
  source = "git::https://github.com/ql4b/terraform-aws-website.git"
  fqdn = "example.com"
  context = module.label.context
}

The Abstraction Strategy

We’re not reinventing AWS services. We’re wrapping complexity with sensible defaults:

  • terraform-aws-website wraps CloudPosse’s cloudfront-s3-cdn + ACM + Route53
  • terraform-aws-lambda-runtime wraps CloudPosse’s ecr + SSM parameters
  • terraform-aws-rest-api wraps raw API Gateway resources

Why This Works

Composability: Mix and match modules as needed Upgradability: Replace modules when you outgrow them
Transparency: Every resource is explicit in the module code Reusability: Same patterns across all cloudless foundations

Module Naming Convention

terraform-aws-{purpose}

  • terraform-aws-website - complete website infrastructure
  • terraform-aws-lambda-runtime - custom runtime support
  • terraform-aws-rest-api - API Gateway setup

The Network Effect

Each module makes the others more valuable:

  • cloudless-api uses lambda-runtime + rest-api
  • cloudless-web uses website
  • Future foundations can mix and match

Repository Strategy

Each module is its own repo for:

  • Independent versioning
  • Clear ownership
  • Focused documentation
  • Git source references

What’s Next

  • terraform-aws-database - RDS + connection pooling
  • terraform-aws-queue - SQS + DLQ setup
  • terraform-aws-storage - S3 + lifecycle policies
  • terraform-aws-monitoring - CloudWatch + alarms

The goal: Every common AWS pattern becomes a 5-line module call.