Managing Azure AI Services with PowerShell - A Practical Guide for Teams Who Automate

There is a moment in every growing AI project where the portal stops being your friend. The first Azure AI Services resource is easy: you click through the portal, spin up a resource, grab the key, and you are away. The tenth one, across three environments, with keys that need rotating and access that needs to match your security policy, is a different story. Clicking through the portal ten times is how mistakes creep in, and how you end up with a dev resource in the wrong region because someone was tired at 5pm on a Friday.

That is where PowerShell earns its keep. The Az.CognitiveServices module for Azure AI Services gives you scriptable control over creating, configuring and managing these resources. If you are doing anything at scale, or you care about being able to rebuild your environment the same way twice, this is the toolset worth knowing. I want to walk through where it actually helps, based on the work we do standing up Azure AI for Australian businesses.

What the module gives you

Az.CognitiveServices is the PowerShell module for managing what used to be called Cognitive Services and now sits under the Azure AI Services banner. It covers the account-level operations: creating an AI Services resource, listing what you have, retrieving and regenerating keys, checking which SKUs and kinds are available in a region, and cleaning things up when you are done.

The mental model is straightforward if you have used any Azure PowerShell before. You authenticate, you set your subscription context, and then you have a set of commands that map onto the things you would otherwise do in the portal. New-AzCognitiveServicesAccount to create one. Get-AzCognitiveServicesAccount to see what exists. Get-AzCognitiveServicesAccountKey and New-AzCognitiveServicesAccountKey for the keys. Remove-AzCognitiveServicesAccount when it is time to tear down. Nothing exotic, and that is the point. It is predictable, and predictable is what you want when you are scripting infrastructure.

The reason to reach for it over the portal is repeatability. A script that stands up your AI Services resources is a script you can run again in another environment, hand to a colleague, check into source control, and read six months later to remember exactly what you did. The portal gives you none of that. Every portal action is a one-off that lives only in the memory of whoever clicked it, which is fine right up until it very much is not.

Where this matters for Australian businesses

Two things make this relevant beyond the "automation is nice" platitude.

The first is data residency, which comes up in nearly every conversation we have with Australian clients, and always the serious ones. If your data needs to stay in Australia, your AI Services resources need to be in the Australian regions, full stop. Doing that consistently across every resource, every environment, every time someone spins something up, is exactly the kind of thing scripting protects you from getting wrong. A script with the region hard-coded and reviewed does not have a bad Friday. A human clicking through the portal does. When the compliance question comes, "it is in our deployment script and here it is" is a much better answer than "let me check each resource".

The second is that real AI projects have more than one environment. You have dev, you have test, you have production, and ideally they are as close to identical as you can make them. The only sane way to keep three environments in sync is to define them in code and deploy the same way to each. PowerShell scripting of your AI Services resources is a big part of that. It is the difference between "production behaves differently and nobody knows why" and "all three environments came from the same script, so they are the same".

We build this kind of automation as standard when we do Azure AI consulting and Azure AI Foundry work. It is not glamorous, and clients rarely ask for it by name, but it is a big part of why the projects we run do not fall over the first time someone needs to make a change or prove where the data lives.

A few honest notes from using it

I like PowerShell for this, but let me be straight about a few things.

Where PowerShell sits versus Bicep, Terraform and the ARM templates is a real question, not a settled one. For pure infrastructure that you provision once and rarely touch, a declarative tool like Bicep or Terraform is often the better fit, because it describes the desired state rather than the steps to get there. PowerShell shines for the operational stuff: rotating keys on a schedule, running a check across all your resources, doing something conditional that is awkward to express declaratively. In practice we use both. We define the resources declaratively and use PowerShell for the operations around them. If you are choosing one hammer for everything, you will be fighting it half the time.

Key management deserves a specific mention. Az.CognitiveServices can retrieve and regenerate keys, and it is tempting to build scripts that pull keys and stash them somewhere. Resist the lazy version of that. Keys in a script, or worse in a log, or worst of all committed to a repo, is how credentials leak. The better pattern is managed identities where you can use them, so there is no key to leak, and Azure Key Vault for the cases where you genuinely need a key. PowerShell is great for automating key rotation. It is a terrible place to store the keys themselves.

And authentication in automation contexts takes a bit of thought. Running these commands interactively on your machine is easy. Running them from a pipeline or a scheduled job means service principals or managed identities, and getting that set up correctly, with the least privilege it actually needs and nothing more, is where a bit of care upfront saves you a security headache later. We have cleaned up more than one environment where the automation account had far more access than it needed because someone granted owner to make an error message go away.

The bottom line

If you are running Azure AI Services at any real scale, learning the Az.CognitiveServices module is worth the afternoon it takes. Not because scripting is inherently virtuous, but because it makes your environments repeatable, your data residency provable, and your operations something you can hand to someone else without a two-hour handover. Use it alongside declarative infrastructure tools rather than instead of them, keep your keys out of your scripts, and get your automation identity's permissions tight from the start.

If you would rather have someone set this foundation up properly the first time, so your Azure AI environment is scripted, compliant and consistent from day one, that is exactly the kind of work we do. Have a look at our Azure AI consulting services, see how we approach custom AI builds, or get in touch and we will help you get the plumbing right before it becomes a problem.

Microsoft's Az.CognitiveServices module reference is the place to go for the full command list once you are ready to build.