Every landing zone conversation eventually lands on the same fork: subscription-per-team or subscription-per-environment. Pick one, defend it in the design review, move on. I used to think that fork was the decision. It isn't. It's a proxy for a question nobody actually asks, which is whether your environments are things you *have* or things you *make*.

We hit this a few weeks back building out a branching strategy for a product that needed to ship in phases — not one big release, several overlapping ones, each needing its own slice of infrastructure to validate against before merging up the chain. The instinct in every Azure reference architecture I'd read was to stand up a fixed set of subscriptions — dev, qa, uat, prod — and let teams queue for access to the shared ones. Clean org chart. Terrible fit for what we were actually doing, which was running three or four release branches at once, each wanting its own isolated environment for a week or two and then wanting to disappear.

So, we didn't fix the environments. We templated them.

The branching strategy and the environment strategy ended up being the same decision, which surprised me at the time. Every release branch got a corresponding environment spun up from Terraform, wired into the pipeline automatically the moment the branch existed, torn down automatically once it merged or went stale. No ticket. No "can I borrow QA for the afternoon." The subscription-per-environment debate assumes environments are scarce and long-lived enough to be worth governing carefully as static things. Once provisioning is cheap and repeatable, that assumption just stops holding.

Here's the number that made the case for me, not some theoretical justification. Before this, we were running four non-prod subscriptions, always on, mostly idle outside business hours, because nobody wanted to be the one who tore down an environment someone might still need. After moving to on-demand provisioning tied to branch lifecycle, we typically had one to two environments alive at any given moment instead of four sitting there permanently. That's not a rounding error. That's roughly half the standing footprint gone, for infrastructure that was doing the same job.

I won't pretend this is free. Ephemeral environments push a lot of discipline requirements onto your IaC that a static model lets you get lazy about. If your Terraform templates aren't actually idempotent — if there's some manual step, some hand-configured firewall rule, some secret someone pasted in once and forgot to script — dynamic provisioning will find that gap for you, repeatedly, at the worst time. We found ours in a Key Vault access policy that had been set by hand eight months earlier and never made it into the template. First time a fresh environment failed a smoke test, it took an afternoon to figure out why "prod-like" environment #3 didn't behave like the original.

There's also a real counterpoint here, and it's not a strawman: audit and compliance people like fixed environments. A subscription that's existed for two years with a known history is easier to reason about for a SOC 2 review than one that spins up Tuesday and dies Friday. If your organization's compliance posture depends on long-lived resource identity — not just "the config was correct" but "this specific resource has been continuously monitored since provisioning" — ephemeral environments genuinely complicate your story. That's a real cost. I'm not going to hand-wave it away with better logging. You need to decide whether your compliance framework cares about resource continuity or just about proving the right controls were in place at time of use and design your audit trail around whichever one it actually is.

For us, it wasn't. The controls mattered, the specific subscription's birthdate didn't. So, the trade-off was worth making.

What I'd push back on is treating subscription-per-team vs subscription-per-environment as the primary architectural decision in the first place. It's a structural question about naming and boundaries. The actual lever — the one that changes your cost profile, your pipeline design, and how fast a team can validate a branch before it merges — is whether "environment" means a durable thing you provision once and then manage, or a disposable output of your pipeline that happens every time you need it. Landing zone docs spend pages on the former and barely mention the latter, probably because it's harder to draw on a slide. A static subscription topology is easy to diagram. "Environments are ephemeral outputs of the release pipeline" doesn't fit neatly into an org chart, so it gets left out of the reference architecture even when it's the more honest answer for a fast-phased release model.

If you're mid-debate on subscription topology right now, my actual advice is to shelve that question for a week and instead ask whether your team could provision a working non-prod environment from scratch, unattended, in under half an hour. If the answer is no, fix that first — the subscription boundary question becomes almost irrelevant once you can. If the answer is yes, you've probably already made the topology decision without realizing it, because ephemeral environments don't care much which subscription boundary they sit inside. They just need somewhere to land and a template that doesn't lie about what production actually looks like.

Every landing zone conversation eventually lands on the same fork: subscription-per-team or...

Subscription-per-environment was never the real question

Tummala Krishna Kishore

We had a gitflow pipeline that looked clean on paper: develop feeds a release branch, the same build artifact promotes through dev, qa, sit, uat, and prod, and once prod is green we tag the commit on main. Textbook. Then a production bug showed up on a Tuesday afternoon, and the diagram stopped mattering.

The standard gitflow answer is to branch a hotfix off the tag, PR it back into release, run it through the pipeline, and once it's proven in UAT, merge to main and cherry-pick the same commit back into develop. We built exactly that. It works. Until you ask the question nobody wants to answer out loud: release still has whatever was mid-flight when you cut the last tag. Untested code. Feature work three sprints deep in QA, sitting on the same branch you're now supposed to route your hotfix through.

So the real question we ended up arguing about wasn't "how do we release a hotfix." It was "do we trust the release branch enough to put a hotfix through it." Most of the time, the honest answer is no.

**The gate everyone obsesses over is the wrong one**

Five environments, five sign-offs, a change ticket for each one: that's the smell people point at first when a pipeline feels slow. It's real. It's just not the dangerous one. A slow gate costs you time. A gate you route around because you didn't trust your own process costs you an incident.

Here's what we landed on after the argument: release the hotfix directly from the hotfix branch, not through release. On Azure, that means deploying to the UAT slot, smoke-testing against production data shape, then toggling the slot. Same infrastructure, same config, none of release's baggage riding along. Once it's live, cherry-pick the commit into both develop and main, retag, and let the normal pipeline catch up on its own schedule whenever it gets there.

That's a smaller number of gates (one real test in the slot, one human sign-off) that actually mean something, instead of five theatrical ones inherited from a process built for planned releases, not for a Tuesday-afternoon incident.

**Cherry-picking backward is the part that actually breaks**

Cherry-picking isn't free. It's a manual merge decision, done twice, under time pressure, by whoever's on call. Miss a file, resolve a conflict wrong, and you've silently reintroduced the bug three weeks later when release finally catches up to main. We've had this happen. Not often. Twice in about eighteen months. Both times the root cause was identical: the hotfix touched a file that had also changed on develop, and the person doing the cherry-pick trusted the diff instead of running the test suite against the merged result.

The fix wasn't "be more careful." Telling people to be careful under incident pressure doesn't work. The fix was making the cherry-pick a PR like any other, gated by the same CI as a normal merge, instead of a git command someone runs from their laptop at 6pm. One automated check catches what a tired engineer won't.

**The trade-off nobody states plainly**

Deploying straight from a hotfix branch means shipping less-tested code than your normal pipeline would allow. That's the actual cost, and it's worth saying plainly instead of dressing it up. If your org's risk appetite says every production deploy needs the full five-stage gauntlet, this approach is wrong for you. Don't adopt it because it sounds efficient. Adopt it because you've decided the trade-off is acceptable for a defined, narrow class of change.

But when the choice is "wait six hours for a full pipeline run while the bug keeps costing money" versus "deploy a scoped, reviewed, slot-tested fix in twenty minutes," speed usually wins the math. We're not skipping testing. We're skipping the parts of testing that exist to catch problems unrelated to the fix: the ones baked into whatever else happens to be sitting on release that particular week.

**What I'd tell a team setting this up today**

Don't design your hotfix path as a stripped-down version of your normal release path. Design it as its own thing: its own artifact, its own single meaningful gate, its own explicit rule for re-entering the trunk.

Ours is three rules. Hotfix branches from the last production tag, never from release. It deploys through slot swap, never through the shared release pipeline. It re-enters develop and main through a real PR with CI attached, not a raw cherry-pick run from someone's terminal.

Three rules. They fit on a sticky note. The gitflow diagram we started with had no room for any of them, because it assumed every deploy was a planned one, and incidents don't wait for the plan to catch up.

If your next incident retro says "we need more approval gates," check first whether the actual failure was a rushed cherry-pick nobody tested. In our case, it always was — and no amount of extra sign-off in the normal pipeline would have caught it, because the bug never went through the normal pipeline at all.

We had a gitflow pipeline that looked clean on paper: develop feeds a release branch, the same build...