starter.wikiSearch⌘K

Infrastructure

Infrastructure as Code

Choose how resource changes are defined, reviewed, applied, tracked, and recovered by state model, provider scope, language, workflow, and ownership.

Recommendation

Choose the state and change-control model before the syntax.

Declarative configuration, general-purpose-language programs, AWS-native synthesis, and application-oriented composition create different provider, state, abstraction, and exit boundaries.12

For: Engineering and platform teams standardizing repeatable infrastructure changes

Main trade-off

Infrastructure definitions improve repeatability and review while adding state, provider, version, abstraction, policy, and recovery responsibilities.12

Four infrastructure definition models

The routes differ in provider breadth, language model, deployment engine, state ownership, and abstraction level.

  1. Provider and resource scope

    List clouds, SaaS providers, resource types, accounts, regions, environments, and unsupported surfaces.1

  2. State and lifecycle

    Choose backend, locking, secrets, import, refresh, drift, deletion, recovery, and state-access ownership.12

  3. Change workflow

    Define preview or plan, review, policy, approvals, apply, promotion, rollback, audit, and break-glass procedures.1

  4. Language and abstraction

    Balance declarative visibility, general-purpose code reuse, construct maturity, testing, versioning, and debugging.2

IaC routes

Choose the smallest model that covers the real resource graph and governance requirements.

Provider breadth and declarative plans matter

Evaluate Terraform.

A provider-neutral configuration and explicit state, plan, and apply workflow can standardize broad infrastructure graphs.

Verify: Validate licensing, provider quality, state operations, module governance, and managed-run requirements.12

The team wants familiar languages and abstractions

Evaluate Pulumi.

General-purpose languages enable reuse, tests, and abstraction while retaining a resource-state engine.

Verify: Program complexity, SDK versions, state backend, secrets, preview behavior, and abstraction governance remain explicit.12

The organization is AWS-centered

Evaluate AWS CDK.

Language constructs and AWS libraries can reduce boilerplate while synthesizing to CloudFormation.

Verify: CloudFormation lifecycle, bootstrapping, IAM, construct versions, accounts, regions, and AWS coupling remain.123

A small product team wants application-oriented composition

Evaluate SST.

Higher-level application components can connect supported cloud resources and framework workflows with less assembly.

Verify: Provider scope, component maturity, state, versioning, Console choices, and migration must fit the production boundary.124

Boundary: Infrastructure as Code defines desired resources and change state. CI/CD owns the runner and promotion workflow; application portability and safe migration are separate outcomes.

What the IaC system owns

Language preference matters less than resource coverage, state safety, change review, and the long-term operating boundary.

State
Backends, locking, secrets, imports, refresh, drift, and recovery determine operational safety.12
Abstraction
Configuration, programs, constructs, and application components expose different review and debugging surfaces.4
Provider boundary
Broad providers, Pulumi packages, CloudFormation, and SST-supported components create different coverage and exit paths.12
Change control
Preview, policy, approval, apply, audit, rollback, and break-glass procedures must be designed around the engine.12

Official resources

Use the primary documentation to verify runtime behavior, operating limits, service boundaries, and current commercial terms.

DocumentationPulumi IaC concepts
DocumentationAWS CDK v2 guide
DocumentationSST documentation

Sources

Official documentation supporting the routes and decision boundaries on this page.

  1. 1
    Terraform core workflow

    HashiCorp · Accessed Official

  2. 2
    Pulumi IaC concepts

    Pulumi · Accessed Official

  3. 3
    AWS CDK v2 guide

    Amazon Web Services · Accessed Official

  4. 4
    SST documentation

    SST · Accessed Official