Blog
TerraformInfrastructure as CodeDevOpsCloud Security

Two Terraform 1.10 Features Worth Knowing: Ephemeral Blocks and S3-Native Locking

·Ankit Bhardwaj

Most of us use the same 20% of Terraform every single day and never touch the rest. That's efficient — until you realise the other 80% quietly shipped a feature that would have saved you hours, or closed a security gap your team has been living with for years.

Recently I made myself read through the changelog end to end instead of skimming for the bits I already use. Two features stood out, both landing in Terraform 1.10+, and neither had been on my radar in day-to-day work. That's exactly the point.

Ephemeral blocks: keep secrets out of state

If you've ever worried about what's sitting inside your .tfstate file, this one matters.

State is one of the most overlooked secret-leak vectors in infrastructure work. Passwords, tokens, generated credentials — anything Terraform manages can end up persisted in plaintext in state, and that file gets copied to backends, pulled locally, and shared across a team.

Ephemeral blocks let you handle sensitive values that are never written to state at all. They exist only in memory during the apply, do their job, and disappear — so a token or password used during a run doesn't get serialised into .tfstate afterwards. It's a clean structural fix for a problem most teams have been patching with conventions and crossed fingers.

The first thing I did after learning this was obvious in hindsight: start a pass over our existing workspaces to find values currently exposed in state that ephemeral blocks could replace.

S3-native state locking: drop the DynamoDB table

For years, the standard recipe for an S3 remote backend has included a DynamoDB table for state locking — a second resource whose only job is to stop two applies from stomping on each other.

Terraform 1.10 added native locking directly on the S3 backend, no DynamoDB required. That sounds minor, but it removes a whole moving part:

  • One fewer resource to provision, pay for, and reason about.
  • One fewer thing to forget when you're standing up a brand-new environment — and forgetting the lock table is exactly the kind of omission that bites you later, under concurrency, at the worst possible time.

Less surface area is almost always a win in infrastructure. This is a clean example of the tooling absorbing complexity you used to carry yourself.

The real lesson: read the changelog

Here's what actually changed my mind. It's easy to be skeptical of features you've never needed — to assume the tool you know is the tool there is. But deliberately reading beyond your daily 20% forces you to discover what's new, and every so often that 80% contains something that meaningfully improves security or saves real time.

Neither ephemeral blocks nor S3-native locking was on my radar. Both are now changing how I'd set up a backend or handle secrets from scratch. The features were there the whole time — I just hadn't gone looking.

So if you run Terraform regularly: pick a recent release, read the full changelog, and ask which of those features map onto problems you've been solving the hard way. Mine turned up two. Yours probably will too.

AB

About the Author

Ankit Bhardwaj

Site Reliability Engineer with 12+ years in software engineering and 4+ years operating production cloud infrastructure on AWS and Kubernetes. Currently running six Kubernetes clusters at 99.99% uptime.

Get in touch