Azure Pipelines can build and deploy to Azure, and it can reach other clouds as well. The difficult part is rarely the YAML. It is how the pipeline proves who it is to each cloud, and how releases are controlled once they reach production. This article covers both, using Microsoft’s and AWS’s own documentation.
How a pipeline is structured
An Azure Pipelines pipeline defines a workflow for build, test and deployment. It is made up of stages, which contain jobs, which contain steps. A stage is a logical boundary such as build, test or production. A job is a set of steps that run in order on the same agent, and an agent runs one job at a time. A step is the smallest building block, either a script or a task.
Pipelines can start manually, on a schedule, on a code push or when another build completes. In YAML pipelines, build and release stages live together in one multi-stage definition, which is different from Classic pipelines, where releases are separate versioned artifacts.
Connecting to Azure without secrets
Azure Pipelines connects to Azure resources through Azure Resource Manager service connections. Microsoft recommends workload identity federation, because it removes the need to create and manage secrets. In order of preference, the options are:
- an app registration created automatically, with workload identity federation;
- a managed identity with workload identity federation, for when you cannot create app registrations;
- a manually created app registration or managed identity, with federation or a secret, when the automatic options fail.
Secret-based options such as a service principal with a secret or certificate, a publish profile, or an agent-assigned managed identity remain available for backwards compatibility, but Microsoft lists them as not recommended. Existing secret-based connections can be converted to workload identity federation. Microsoft also notes that service connections can be disabled after 100 days of non-use.
One date to plan for: new federated connections in the Azure public cloud now default to the Microsoft Entra issuer, and Microsoft is deprecating the Azure DevOps issuer, which retires on 1 July 2027. If you have older federated connections, check which issuer they use.
Connecting to AWS
AWS documents how to federate into AWS from Azure DevOps using OpenID Connect, replacing static IAM access keys with temporary, limited-privilege credentials from AWS Security Token Service. The process has four steps: create a pipeline and note the organisation GUID, add an OIDC identity provider in AWS IAM, create an IAM role, and run the pipeline to confirm it works.
The role’s trust policy is where the security comes from. It checks the token’s audience and restricts the subject to a single named Azure DevOps service connection, so only that connection can assume the role. AWS’s walkthrough was written around the issuer URL for an Azure DevOps organisation, so read it alongside Microsoft’s current issuer guidance above.
Controlling releases with environments
An environment in Azure Pipelines is a group of resources that acts as a logical deployment target, such as dev, test, staging or production. Environments currently support Kubernetes and virtual machines, and they are not available in Classic pipelines.
- Deployment history records which pipeline runs deployed to an environment, with the commits and work items involved.
- Approvals and checks let resource owners require manual approval before a stage uses the environment, for example before production.
- Permissions control who can use or administer an environment, and which pipelines are allowed to deploy to it.
A short checklist
- Use workload identity federation for new Azure service connections, and convert old secret-based ones.
- Use OpenID Connect rather than stored access keys when a pipeline deploys to AWS.
- Scope each service connection narrowly, and restrict which pipelines can use it.
- Put approvals on the environments that matter, such as production.
Where we can help
If your pipelines deploy across Azure and other clouds and you want them reviewed, see our DevOps automation and engineering service, or get in touch.
Sources, checked October 2026: Microsoft Learn, connect to Azure with an Azure Resource Manager service connection; Microsoft Learn, key Azure Pipelines concepts; Microsoft Learn, Azure Pipelines environments; AWS, federating into AWS from Azure DevOps with OpenID Connect.
