7.4 Provider-native IaC and when to use it

What this is and why it exists

Terraform is not the only way to describe infrastructure, and on any real team you will meet the provider's own tool — in a repository you inherit, in a tutorial, in a colleague's preference. This lesson is so that those templates are readable rather than alien, and so that the choice between them is made for a team's reasons rather than for yours.

The vocabulary

• Native tool — the infrastructure-as-code tool the provider ships and supports. Amazon has CloudFormation, with CDK as a programmatic layer above it; Azure has ARM templates, with Bicep as a friendlier language over the same engine; Google has Deployment Manager and Config Connector.
• Template — the declarative document a native tool applies.
• Stack — a deployed instance of a template, which the provider manages as one unit.
• Managed state — the provider keeping the record of what exists, rather than you keeping a state file.
• Drift detection — the provider comparing a stack against reality and reporting differences.
• Lock-in — the cost of leaving, measured in work rather than in principle.
• Day-one support — a new service being usable by a tool the day it launches.

The mental model

The genuine advantages of a native tool are three, and they are not marketing. The provider keeps the state for you, which removes the whole backend-and-locking problem from the previous lesson. New services usually work on the day they launch, because the tool ships from the same organisation as the service — third-party providers follow, usually quickly, sometimes not. And support is one conversation: when a deployment misbehaves, the tool and the service belong to the same vendor and nobody can pass the problem sideways.

The genuine cost is exactly one thing, and it is smaller than people assume: the templates do not travel. A CloudFormation template is not a description you can point at Azure. But be honest about what actually creates lock-in — it is the services, not the syntax. A design built on one provider's managed database, its identity model and its messaging service is a design you cannot move whichever tool wrote it down. Rewriting the descriptions is usually the cheapest part of a migration nobody actually performs.

Which is why the real decision is about people rather than portability. Choose the native tool when your team is deep in one provider, values day-one service support, and prefers not to run state. Choose Terraform when you genuinely operate across providers, when you use it for things outside a cloud as well, or — often the deciding reason — when the people you can hire already know it. Both are defensible; what is not defensible is choosing on taste and then arguing about it for a year.

Mixing them is where the actual damage happens, and the rule is short: one resource, one owner. Two tools describing the same resource means each will faithfully undo the other, on a schedule, forever — the resource flips between two shapes and both tools report success. If you must run both, split by boundary rather than by resource: this account, this stack, this layer belongs to that tool, and the seam between them is an output from one read as an input to the other. Write the boundary down where somebody will find it, because the person who breaks it will be the one who never knew it existed.

One reading skill is worth building deliberately, because it makes every native template legible. They all express the same four things: parameters (the inputs), resources (the things), references between resources (how one gets another's address), and outputs (what the stack publishes). Find those four in a template you have never seen and you can follow it, whatever the syntax around them looks like.

What you should now be able to explain or do

Name the native tool for each of the three major providers, and the friendlier layer above two of them. Give the three real advantages of a native tool and the one real cost. Say what actually creates lock-in, and why the templates are the smaller part. Make a defensible choice for a described team. State the rule for mixing tools and the failure it prevents. Read an unfamiliar template by finding its four parts.

Check yourself