Azure SDK for Go: the client and management split that decides your import paths

Two module families that answer different questions

The single most useful fact in this README is the split the project draws between client modules and management modules. Each service can have both.

Client modules are used to consume the service. Management modules are used to configure and manage the service. Concretely, the README gives uploading a blob as the example of client-module work: using, consuming and interacting with existing resources.

The naming encodes the split as well. All management modules live under `sdk/resourcemanager`, one directory per service area: `sdk/resourcemanager/compute/armcompute`, `sdk/resourcemanager/network/armnetwork`, `sdk/resourcemanager/monitor/armmonitorworkspaces` in the recent tag list. Client modules sit elsewhere under `sdk/`, and `azcore` is the shared foundation they build on.

If you are porting code, this distinction is where the friction lives. A script that provisions a load balancer and a script that connects to a running load balancer use different module families, and the README routes each to its own documentation. Before choosing an import path, decide which of the two jobs your code is doing.

azcore is the shared runtime: pipeline, policies, retries, telemetry

Client modules are not standalone. The README says they share core functionalities including retries, logging, transport protocols and authentication protocols, and that all of this can be found in the `azcore` module.

Management modules have their own list of shared capabilities, and the list is worth reading because it tells you what you no longer have to hand-write: the Azure Identity module for credentials, an HTTP pipeline with custom policies, error handling, and distributed tracing.

The custom policy mechanism is the part with real leverage for a production service. A policy can be inserted into the pipeline to add retry behaviour, logging or request shaping once, rather than at every call site. Distributed tracing being in the shared layer means context propagates without each service package inventing it.

Telemetry is on by default, which is the one shared behaviour with an operational consequence. The README describes it in the Data Collection section: the software may collect information about you and your use and send it to Microsoft, and you can turn it off. To opt out, you disable telemetry at client and credential construction by setting `Disabled` to true in `ClientOptions.Telemetry`, which disables it for all methods on that client. You have to do this for every new client and credential you create, which is why it is worth wiring into your own constructor helpers rather than remembering call by call.

Track 1 is deprecated: what to do with old import paths

The README carries a warning about the root `azure-sdk-for-go` Go module, which contains subpaths of `/services/**/mgmt/**`, also known as track 1. That module is deprecated and no longer receiving support.

The historical packages section says the same thing from the other direction. If you are using packages with the prefixes `github.com/Azure/azure-sdk-for-go/services`, `github.com/Azure/azure-sdk-for-go/storage` or `github.com/Azure/azure-sdk-for-go/profiles`, the README asks you to consider migrating to the latest modules, and points to a mapping table from the historical releases to their equivalents.

So there are two families of legacy import path: the track 1 subpaths under `services/**/mgmt/**`, and the older top-level prefixes. Neither receives support. Code that predates the module split cannot simply be left alone, because a security fix in the current modules will not reach it.

The migration guides named in the README are the route: the ARM migration guide in the repository under `documentation/development/ARM/MIGRATION_GUIDE.md` for track 1, and a separate management migration guide for the `sdk/resourcemanager` move. Note that these are different migrations; an internal service may need both.

Beta tags are everywhere in the release list, so pin deliberately

Look at the recent releases the repository produced: `sdk/azidentity/v1.15.0`, `sdk/resourcemanager/monitor/armmonitorworkspaces/v1.1.0-beta.1` and `sdk/resourcemanager/compute/armbulkactions/v0.7.0`. One carries a beta suffix, while the others have stable version labels but remain below version 1.0.

The README addresses this twice with the same advice. For client modules: if you need to ensure your code is ready for production use, choose one of the stable, non-beta modules. For management modules, the same sentence appears again.

That guidance matters because the recent list includes both stable and beta module versions. The tag list is a record of work in progress, not a curated release channel. `armbulkactions` is listed at v0.7.0 without a pre-release suffix, so check the module's release notes before deciding whether it is suitable for production.

The practical approach is to check the suffix before adding an import, not after the first build failure. The README also points to a page listing the most up-to-date new modules, separately for client modules and for management modules, which is where you confirm what stable currently exists.

Getting started means reading the module's own README

The Getting Started instruction is short and points at a directory rather than a snippet: to get started with a module, see the README.md file located in the module's project folder, and find those module folders grouped by service in the `/sdk` directory.

That is an honest answer for a repository with one directory per Azure service, and it has a practical consequence: there is no single canonical snippet in the root README, because `sdk/resourcemanager/compute/armcompute` and a storage client module have nothing in common beyond `azcore`. The quickstart the README links for management modules lives at `https://aka.ms/azsdk/go/mgmt`, and the migration path is at `https://aka.ms/azsdk/go/mgmt/migration`.

For samples, there are three places. The Go SDK Code Samples repository at `https://aka.ms/azsdk/go/mgmt/samples`, example files under each package, and the concrete example the README names for Network packages, a `loadbalancernetworkinterfaces_client_example_test.go` file inside `sdk/resourcemanager/network/armnetwork`. Reading a `_test.go` example file is often the fastest way to see the intended call shape for a specific client, because it is compiled as part of the module rather than maintained separately.

A first session therefore means opening the module's own README and consulting its example files.

Go version policy and the authentication trap after an upgrade

Two constraints bound what you can run and what can break.

The first is the Go version policy. The README states that the libraries are compatible with the two most recent major Go releases, following the same policy the Go language itself uses, and it encourages projects to use the latest version of Go so the product has the latest security fixes and stays inside Go's support lifecycle. In practice that means an old toolchain eventually stops being supported by the SDK as well as by Go, and the trigger is a Go release rather than an SDK release.

The second is authentication after a management module upgrade, and the README flags it explicitly. If you are experiencing authentication issues with the management modules after upgrading certain packages, it is possible you upgraded to the new versions of the SDK without changing the authentication code. The fix is in the migration guide.

That failure mode is worth understanding rather than memorising. Credential handling moved: the Azure Identity module is now the shared path, and code that constructs credentials the pre-Identity way can compile against a newer module while authenticating incorrectly. A compile that succeeds is not evidence that the migration was complete, which is why the README repeats the pointer to the migration guide rather than listing specific symptoms.

What this repository is not: docs, samples and support all live elsewhere

The root README is short, and the reason is stated in the repository description: this repository is for active development of the Azure SDK for Go, and consumers are pointed to public developer docs.

So the actual reference material sits outside the code. The overview is at `https://docs.microsoft.com/azure/developer/go/`, the SDK reference is at `https://pkg.go.dev/github.com/Azure/azure-sdk-for-go/sdk`, code samples for the Go SDK live in the separate azure-samples repository, and the underlying REST API documentation is at `https://docs.microsoft.com/rest/api/`. The home page recorded for the project is the Go developer docs site.

Security issues are handled outside GitHub issues as well: they should be reported privately by email to the Microsoft Security Response Center at [email protected], with a stated expectation of a response within 24 hours, and further information including the MSRC PGP key at the Security TechCenter page. Ordinary help goes to GitHub Issues, previous questions on Stack Overflow under the `azure` and `go` tags, and a feedback survey.

Licensing is MIT with a NOTICE.txt alongside LICENSE.txt at the repository root. That is the terms of the licence itself rather than a view on how it applies to a given product.

Editorial conclusion

Adopt the current `sdk/` modules, client modules under `sdk/` for service consumption and `sdk/resourcemanager` modules for management, if you are starting new Go work against Azure today. Do not copy imports from older code samples: packages with the `github.com/Azure/azure-sdk-for-go/services`, `storage` and `profiles` prefixes are identified as historical releases for which migration should be considered. Verify first, per module, that you picked a stable non-beta tag rather than a `-beta` or `-alpha` version, and confirm your Go toolchain sits on one of the two most recent major releases, which is the compatibility policy the README states.

Frequently asked questions

Official sources

1. Azure/azure-sdk-for-go on GitHub
2. License: MIT
3. Project website
4. README
5. Releases