sydepsystem design atlas

Infrastructure as Code

Define infrastructure in version-controlled, reviewable declarations.

StarterPlatform
IaC RepositoryDevOps & DeliveryPlan & Apply PipelineDevOps & DeliveryIaC EngineDevOps & DeliveryProvisioned InfrastructureCompute

Infrastructure is described in code, reviewed like any other change, and applied through a pipeline -- giving reproducible environments, a diffable change history, and no more configuration drift from manual console changes.

When to use it

  • You need reproducible environments across dev/staging/prod
  • Manual console changes have caused configuration drift or unrecoverable environments

Trade-offs

  • State management (drift, locking, imports of existing resources) is its own discipline
  • Adds a review/apply cycle even for small infrastructure tweaks

Components used

Source ControlCI/CD PipelineInfrastructure as CodeContainer Service

How it works

  • Infrastructure is declared in version-controlled files describing desired state rather than the steps to reach it.
  • A planning step diffs desired state against reality and shows exactly what will change before anything is applied.
  • State is tracked so the tool knows what it owns, which is what makes deletion and drift detection possible.

Used in the wild

  • Reproducing identical staging and production environments.
  • Disaster recovery, where the environment can be rebuilt from source rather than from memory.
  • Peer review of infrastructure changes through the same pull request process used for application code.

Good to know

  • Manual console changes are the enemy. Once real infrastructure drifts from the declared state, the next apply may attempt to 'correct' something that is deliberately different, occasionally by destroying it.
  • The state file typically contains secrets in plaintext and must be stored remotely with encryption and locking. Committing it to Git is a rite of passage nobody wants to repeat.