Cost, safety & isolation

Real resources cost money.

Advanced12 min · lesson 10 of 12

Real deploys mean real money and real blast radius, so cost and safety are first-class concerns, not afterthoughts. The foundational control is isolation: run all infra tests in a dedicated sandbox account/project, never a shared or production one, so a test can never touch real infrastructure and any leak is contained to a disposable environment you can sweep aggressively. This one decision removes most of the risk.

Minimize what you deploy

Beyond isolation, keep tests cheap: prefer the smallest resources that prove the point (a t3.micro, not a fleet), choose fast-to-create services where you have a choice, use ephemeral local clusters (kind) instead of cloud ones for Kubernetes tests, and avoid expensive slow-to-provision resources unless the test genuinely needs them. And enforce cleanup in depth — defer destroy, unique tags, and a scheduled cloud-nuke sweep — because the real cost risk is leaks, not the intended short-lived resources.

terminal

# scheduled sweep in the sandbox account: reap anything tagged terratest > 2h old
$ cloud-nuke aws --resource-type ec2,rds,elb \
    --older-than 2h --tag terratest=true
# a backstop so a failed defer-destroy never bills for weeks

Never point Terratest at a shared or production account

A misconfigured test, a wrong variable, or a bad module under test could create, modify, or (with the wrong data source) even affect real resources if it runs against a production account. Always use a dedicated sandbox account with its own credentials, scoped so it cannot reach production, and treat those credentials as test-only. Isolation at the account level is the single most important safety control for infra testing.

Strategy & the test pyramidTerratest in CI/CD