Variables and Outputs: Parameterize Without Duplicating

The first parameterization reflex is almost always the wrong one: you copy the production directory to staging, change three values, and end up with two configurations that silently drift apart over six months. The day a production incident has to be reproduced in staging, nobody knows which differences are intentional and which are oversights. Duplicated code is not a matter of elegance; it is a guarantee of drift.

Variables solve this problem, but they introduce another if you treat them as simple blanks to fill in. An untyped variable accepts anything, and the error doesn't show up at declaration: it surfaces fifteen seconds later as an unreadable provider API message, or worse, it slips through and creates a machine of type t3.medum, which doesn't exist in the target region. A well-declared variable, with a type, a thoughtful default value, and a validation, turns a runtime failure into an input error caught before any network call.

Declaring a variable

By convention, a declaration lives in a variables.tf file:

variable "environment" {
  description = "Nom de l'environnement cible, utilisé dans les étiquettes et les noms."
  type        = string
}

variable "instance_type" {
  description = "Type de machine pour les serveurs applicatifs."
  type        = string
  default     = "t3.small"
}

variable "instance_count" {
  description = "Nombre de serveurs applicatifs."
  type        = number
  default     = 2
}

variable "enable_deletion_protection" {
  description = "Interdit la suppression de la base par un appel d'API."
  type        = bool
  default     = true
}