Terraform HCL AWS Multi-Region Cursor Rules Template

Overview

Direct answer: This Cursor Rules Template provides a complete, copyable Cursor AI workspace for Terraform HCL AWS multi-region deployments. Paste the .cursorrules block into your project root to enforce provider aliases per region, remote state backends, and modular architecture across AWS Regions.

What it covers: multi-region provider configuration, backend state management, modular module layout, and safety constraints for secure IaC with Cursor AI.

When to Use These Cursor Rules

• Provisioning across multiple AWS regions with Terraform HCL
• Enforcing explicit provider aliases and region-specific backends
• Gating changes in CI/CD with Cursor AI for secure IaC
• Maintaining consistent module usage and state management

Copyable .cursorrules Configuration

// Cursor Rules Template: Terraform HCL AWS Multi-Region
FRAMEWORK: Terraform-HCL-AWS
ROLE_AND_CONTEXT: You are an IaC automation assistant for multi-region AWS deployments using Terraform. Produce modular, readable configurations with provider aliases per region and a secure backend.
CODE_STYLE: terraform fmt; align attributes; use modules; avoid inline credentials; variables typed
ARCHITECTURE_AND_DIRECTORY_RULES: 
  environments/
    prod/
      us-east-1/
      eu-west-1/
    staging/
      us-east-1/
      eu-west-1/
  modules/
    network
    compute
    security
BACKEND_STATE: 
  BACKEND: s3
  BUCKET: prod-tf-state
  KEY: global/terraform.tfstate
  REGION: us-east-1
  ENCRYPT: true
  LOCKING: dynamodb
PROVIDERS_AND_REGIONS: 
  AWS_US_EAST_1_ALIAS: us_east_1
  AWS_EU_WEST_1_ALIAS: eu_west_1
  REGION_US_EAST_1: us-east-1
  REGION_EU_WEST_1: eu-west-1
MODULES_AND_RESOURCES: 
  network_module: source ../modules/network
  compute_module: source ../modules/compute
AUTHENTICATION_AND_SECURITY: 
  DO_NOT_HARD_CODE_CREDENTIALS: yes
  USE_IAM_ROLES: yes
  CI_SECRETS: external
TESTING_AND_CI_CD: 
  - terraform fmt -check
  - terraform validate
  - terraform plan
  - tfsec
  - tflint
  - Terratest / Kitchen-Terraform for integration testing
PROHIBITED_ACTIONS: 
  - do not hard-code secrets or credentials in configuration files
  - do not bypass remote state backend or use local state in prod
  - do not rely on a single-region default provider without alias
  - do not store secrets in plaintext in repo

Recommended Project Structure

environments/
  prod/
    us-east-1/
      main.tf
      backend.tf
      variables.tf
    eu-west-1/
      main.tf
      backend.tf
  staging/
    us-east-1/
      main.tf
      backend.tf
modules/
  network/
    main.tf
  compute/
    main.tf
  security/
    main.tf
scripts/
  ci-cd/
    plan-and-apply.sh
.gitignore

Core Engineering Principles

• Idempotent and declarative IaC with Terraform
• Modular design using reusable modules
• Explicit, per-region provider aliases
• Least-privilege IAM and secure credential handling
• Remote state with locking for safe collaboration
• Environment parity and reproducible builds
• Observability and auditable changes to infrastructure

Code Construction Rules

• Use provider aliases for every region and reference them in modules
• Parameterize region values via variables and maps, not literals
• Place infrastructure in modules and compose with environments
• Configure a centralized S3 backend with DynamoDB locking
• Leverage data sources for ephemeral AMIs and dynamic resources
• Validate with terraform fmt, terraform validate, and lint with tfsec and tflint
• Do not hard-code credentials or secrets in code or state files

Security and Production Rules

• Enable encryption at rest for backend and state files
• Use IAM roles and temporary credentials for CI/CD access
• Do not reuse the same credentials across environments
• Limit module permissions to the minimum required for each region
• Audit changes with a reproducible plan before apply
• Suppress sensitive outputs in logs and CI output

Testing Checklist

• Run terraform fmt -check and terraform validate locally
• Execute terraform plan and review changes in a safe plan view
• Run tfsec and tflint to catch security and style issues
• In CI, gate merges on plan output and run Terratest or Kitchen-Terraform for integration tests
• Test remote state configuration in a non-prod environment before production rollout

Common Mistakes to Avoid

• Relying on a single region default provider without aliases
• Storing credentials in repository or environment variables without protection
• Skipping remote state or state locking in multi-team environments
• Inline AMI IDs or region-specific values without parameterization
• Flat, monolithic Terraform configurations instead of modular design

FAQ

What is the Terraform HCL AWS Multi-Region Cursor Rules Template?

It is a Cursor Rules Template designed to guide Terraform HCL usage across multiple AWS regions. It provides copyable instructions and a copyable .cursorrules block to enforce provider aliases, remote state, modules, and security practices while enabling Cursor AI assisted development.

How do I configure providers for multiple regions in .cursorrules?

Use provider aliases for each region and reference them in modules. The template demonstrates an alias per region and a centralized backend configuration to prevent drift between regions.

Can Cursor AI enforce best practices for remote state and backend config?

Yes. The rules include backend S3 configuration with encryption and a DynamoDB table for locking, ensuring consistent state storage and safe concurrent applies across regions.

How does this template handle IAM and security for multi-region deployments?

The template emphasizes least privilege, IAM roles for Terraform operations, and avoiding hard-coded credentials. It also recommends CI secrets management and auditing of access policies used by deployment pipelines.

What testing should I run with this template?

Run terraform fmt and terraform validate locally, followed by terraform plan to preview changes. Integrate tfsec and tflint in CI, and consider Terratest or Kitchen-Terraform for deeper integration testing.