Azure SDK for Rust: one crate per service, and a User-Agent you can strip

The problem: Rust against Azure without hand-written plumbing

Every Azure service has a REST API, and every REST API has the same tedious parts: a request builder, a serialiser, a credential to attach, a retry policy, an error type and a way to page through results. Writing that by hand for a dozen services is a bad trade, and writing it once in a shared internal crate is a project in itself.

This repository is for the active development of the Azure SDK for Rust, and the project is explicit about its role. It is the development home, and consumers are pointed at docs.rs to look up the documentation for any of the libraries in the SDK. That split is the right one: the repository is where the crates are built, and the published docs on docs.rs are where a user reads them.

The audience is a Rust developer whose application talks to Azure, and the scale of the workspace tells you how far along the project is. The Cargo manifest lists more than thirty members, covering the core plumbing and the services: azure_core and its AMQP, macros, OpenTelemetry, examples and test crates, the TypeSpec core crates, the Cosmos DB family with its driver, emulator, macros, observability harness and performance crates, azure_identity, azure_messaging_eventhubs with a blob checkpoint store, the three key vault crates for certificates, keys and secrets, azure_messaging_servicebus, the canary crates, and the storage crates for blob, common, queue, SAS and stress testing.

The licence is MIT, the language is Rust, and the last push was on 2026-10-22, with the Cosmos DB crates reaching 1.0.0 on 2026-10-08.

One crate per service, and a core that carries the shared machinery

The project structure is stated as a rule rather than a convention: each supported Azure service is its own separate crate. All Azure SDK for Rust crates are published on crates.io, under the azure-sdk user, and the crates.io page for that user is the index of the whole SDK.

That means the dependency graph follows the service boundary. An application that only reads blobs does not compile the key vault client, and a change to one service does not force a version bump across an estate that never used it. For a platform team that is the difference between one upgrade and a dozen.

Underneath the services sits the core. The workspace members show the shape of the shared layer: azure_core, azure_core_amqp for the AMQP transport, azure_core_macros, azure_core_opentelemetry for tracing, plus the typespec, typespec_client_core and typespec_macros crates and a set of core test and example crates. The dependency on TypeSpec is the tell for how the code is produced: the service definitions come from Microsoft's TypeSpec descriptions, and the clients are generated from them, which is why the crates can be exhaustive and consistent across services rather than being a set of hand-written clients.

The build itself is ordinary. Building each crate should be as straight forward as cargo build, with the caveat that you should check each crate's README for more specific information, which is a sensible instruction given that the core crates have transport features and the service crates have authentication modes.

For a first look, the examples are the best entry point. Each library project folder has an examples directory, and the documentation points at a concrete path such as /sdk/identity/azure_identity/examples. The repository also carries a samples/ directory with cosmos and storage samples, and a samples/AGENTS.md that tells coding agents how to work in that tree.

Installing: cargo add, and the crate you actually need

Adding a client is a single cargo command, because the crates are on crates.io:

cargo add azure_identity azure_security_keyvault_secrets tokio

That example is worth reading as a pattern rather than a recipe. You add the identity crate, the service crate you want, and the async runtime yourself, because the SDK does not force a runtime choice on you. The crate naming also encodes the service grouping: azure_identity for the credential, azure_security_keyvault_secrets for one key vault operation, and the same pattern for the rest.

The alternative to a published crate is a source build from the workspace, and the documentation points at the library project folders grouped by service in the /sdk directory for that. Each has its own README with the more specific instructions.

Two further resources are worth knowing about before you file a question. The examples subdirectory in any library's project folder holds full file code examples, and for questions there is a StackOverflow tag combination, azure and rust, alongside previous questions and the GitHub issue tracker for bugs and feature requests.

The workspace metadata also tells you the toolchain the project expects: the Rust edition is 2021 and the minimum Rust version is 1.88, and the workspace uses resolver 2 with a rust-toolchain.toml at the root. The dependency list is a short one, with TypeSpec and its client core and macro crates pinned at version 1.1.0 as workspace dependencies.

Telemetry: the User-Agent header arrives by default

The data collection section is the part of this documentation every adopter should read, and it is unusually specific.

The software may collect information about you and your use of the software and send it to Microsoft, which may use that information to provide services and improve its products. You can turn the telemetry off, and the policy is described on the Azure SDK telemetry guidelines page.

What is actually sent is a User-Agent header, present by default, with a value in this shape:

> azsdk-rust-security_keyvault_secrets/0.4.0 (1.86.0; linux; aarch64)

You can assign an optional application ID for your own telemetry by setting UserAgentOptions::application_id, and it appears at the beginning of the User-Agent header.

To disable sending the User-Agent header entirely you write a Policy that removes it, and the documentation gives the whole thing:

use azure_core::http::{
    policies::{Policy, PolicyResult},
    Context, Request,
};
use std::sync::Arc;

// Define a policy that will remove the User-Agent header.
#[derive(Debug)]
struct RemoveUserAgent;

The policy hooks into the request pipeline, takes the headers, removes the user-agent entry, and passes the request on to the next policy in the chain. A complete example is in the azure_core crate, core_remove_user_agent.rs.

The reason this is worth an article rather than a footnote is the cost of the alternative. Removing the header is not a configuration setting, it is a piece of code that has to be written, tested and maintained in every application that needs it. For a regulated environment that is the whole decision, and it is cheaper to know before you build than after.

Licence, contribution terms and the deprecated predecessor

The licence is MIT, recorded in the workspace package metadata with the licence text in LICENSE.txt and a NOTICE.txt alongside it. For a vendor SDK that is the expected choice and a low friction one.

The contribution terms are worth reading. Most contributions require you to agree to a Contributor License Agreement declaring that you have the right to, and actually do, grant the rights to use your contribution, and a CLA bot will automatically determine whether you need to provide one and decorate the pull request accordingly. You only need to do this once across all the repositories using that CLA.

The project has also adopted the Microsoft Open Source Code of Conduct, with the FAQ and a contact address linked. Security issues and bugs should be reported privately by email to the Microsoft Security Response Center, with a response expected within 24 hours and a request to follow up if that does not arrive. The PGP key and further details are in the Security TechCenter, and the repository carries a SECURITY.md, an FAQ.md, a SUPPORT.md and an AGENTS.md giving guidance on how AI agents should interact with the repository.

There is a predecessor to be aware of. This project is the successor to the azure_sdk crates from the MindFlavor AzureSDKForRust project. The crates have been renamed, so those older crates should be considered fully deprecated. That matters for anyone with existing code: the migration is a rename of the crate names and a review of the API, and the old crates will not receive fixes.

The project also runs an open design discussion process, with a label for design discussions and a list of open feature requests sorted by the number of thumbs up, which is a reasonable way to let the community influence a generated SDK.

Where the Azure SDK for Rust is the wrong tool

The boundaries are mostly about coverage and about the generated nature of the code.

If the Azure service you need is not in the workspace, this SDK does not help. The crate list is the entire surface, and the list currently ends at Cosmos DB, Event Hubs, Service Bus, Key Vault, Storage, Identity and the canary and core crates. Azure has a large service catalogue, and most of it is not here yet.

If your application is not written in Rust, none of this applies, and the Azure SDKs for other languages are the relevant comparison. The difference in approach there is not incremental: the clients here are generated from TypeSpec descriptions, which buys coverage and consistency at the cost of a certain genericness in the surface.

There is also the practical cost of a generated client that nobody much wants to admit: when the generated API does not match what you would have written, you work around it, and the workaround is a piece of code that only your team understands. A hand-written client is more pleasant to use and more pleasant to change, and for a small integration that is often the better trade.

And if your requirement is a low latency path with a custom protocol, the generated client will not be the bottleneck you are worried about anyway.

The judgement is that this is a good SDK to reach for when the service is on the list and the team wants generated, typed clients with the shared Azure plumbing already solved. Before committing, check two things: that your service is covered, and that the default telemetry behaviour is acceptable to your organisation.

Editorial conclusion

Adopt the Azure SDK for Rust if your team is writing Rust against Azure and you want a generated, typed client rather than hand-rolled HTTP calls against the REST APIs. Do not adopt it if you need a service that is not in the workspace yet, because the crate list is the whole surface, and do not copy the user agent pattern from older examples without checking, since the azure_sdk crates from the predecessor project are deprecated. Before you ship, read the telemetry section and decide whether the default User-Agent header is acceptable, because removing it takes a custom policy rather than a configuration flag.

Frequently asked questions

Official sources

1. Azure/azure-sdk-for-rust on GitHub
2. Issues
3. License: MIT
4. README
5. Releases