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

Related implementation resources: Cursor Rules Template: Monorepo Turborepo PNPM Shared Packages, AI Agent Use Case for Industrial Plants Using Sensor Logs To Monitor and Flag Workplace Noise Levels Exceeding Regulatory Limits, and Environment Variable Rules as Reusable AI Skills for Production-Grade Projects.

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.