cloud-infrastructure

Prefer official terraform-aws-modules sources first, trusted community modules like cloudposse second, and raw aws_* resources only where no module fits. Pin versions with ~>, call modules directly at root without wrapper layers, and apply tags once via default_tags on the provider.

Only when something genuinely requires a private network, such as ElastiCache, RDS, or a private ALB. A Lambda reaching DynamoDB, S3, SES, or Cognito over public AWS endpoints with IAM can run non-VPC, avoiding the NAT Gateway cost of roughly $33 per month per environment.

NAT Gateway gives one flat egress path to all AWS services and the internet for about $33 per month. Interface endpoints keep traffic on the AWS backbone at roughly $7 per endpoint per AZ, so they suit few services needing privacy, while NAT suits many services or internet egress.

Give every variable a type and a validation block so bad values fail at plan time. Use can(regex(...)) for formats, contains([...]) for enums, and cidrhost() for network CIDRs, with one concern per validation block and a clear error message.

Yes, through one canonical Terraform root with per-environment tfvars files and one Terraform Cloud workspace per environment selected via TF_WORKSPACE. Per-environment differences use var.environment conditionals rather than duplicated configuration trees.

Do not use it for the CI/CD pipeline that runs plan and apply, branching strategy, or the OIDC permission model, which belong to the devops skill. It also documents AWS specifically and is not multi-cloud guidance despite the provider-agnostic name.