Cloud DevOps and Developer Tools: AWS vs Azure vs Google Cloud
Source repos, CI builds, continuous delivery, CLIs and dev environments: what each cloud-native DevOps tool does and how AWS, Azure and Google Cloud compare.
Ask ten teams what CI/CD tool they use and you’ll get GitHub Actions, GitLab, Jenkins, Azure DevOps, and maybe one lonely CodePipeline. That’s the honest state of this category. The cloud providers’ native DevOps tools compete with very good third-party platforms, and plenty of teams mix and match. This post explains each piece of the developer toolchain, what the native AWS, Azure and Google Cloud services do well, and when you’d still reach for something else.
What the DevOps category covers
The developer tools category supports the path from a commit to running software:
%%{init: {"themeVariables": {"fontSize": "14px"}, "flowchart": {"useMaxWidth": false, "nodeSpacing": 30, "rankSpacing": 40, "padding": 8, "wrappingWidth": 150}}}%%
flowchart TB
subgraph CI["Integrate"]
direction LR
R[Source repo] --> B[Build and test] --> A[Artifact /<br/>image registry]
end
subgraph CD["Deliver"]
direction LR
D[Deploy to<br/>staging] --> P[Approve and<br/>promote to prod]
end
CI --> CD
- Source control. Git repositories, pull requests and branch policies.
- Continuous integration. Build, test, scan and package on every change.
- Continuous delivery. Promote artifacts through environments with approvals, safe rollout strategies and rollback.
- CLIs and shells. How engineers and scripts drive the cloud.
- Dev and test environments. Self-service, cost-controlled places to work and experiment.
Artifact and container registries are covered in the containers post, and infrastructure as code in the monitoring and management post. For the general practice, see the DevOps introduction and CI/CD posts.
Source code repositories
Most teams keep code in GitHub or GitLab, and that’s a perfectly good choice on any cloud. The native repositories make sense when you want everything inside one cloud account boundary, under the provider’s IAM and compliance controls, or when data residency rules out SaaS Git hosting.
The landscape has shifted more than once. AWS paused CodeCommit for new customers in 2024 and reversed that in November 2025. Google retired Cloud Source Repositories for new customers in favour of Secure Source Manager. And Microsoft’s long-term investment goes into GitHub, with Azure Repos still fully supported.
AWS CodeCommit
Managed private Git repositories integrated with IAM. AWS stopped onboarding new customers in 2024, then returned CodeCommit to general availability in November 2025, with Git LFS support on the roadmap.
Unlimited private Git repositories with branch policies, required reviewers, build validation and pull requests, as part of Azure DevOps Services. GitHub (also Microsoft) is the strategic direction for new projects.
Secure Source Manager
A regionally deployed, single-tenant managed Git service with IAM integration and VPC Service Controls support. It replaced Cloud Source Repositories, which closed to new customers in 2024.
Continuous integration and builds
CI runs on every commit or pull request: compile, run unit tests, lint, scan dependencies and containers, and produce a versioned artifact. The native build services are serverless (no build servers to maintain), billed per minute, and run with cloud identities, so builds can push to registries or read secrets without stored credentials.
That last point is the main reason to use them even if your pipelines live elsewhere. For example, CodeBuild can act as a managed runner for GitHub Actions jobs that need private VPC access.
AWS CodeBuild Soon
Fully managed build service that runs builds in containers you choose and bills per build minute. Can serve as GitHub Actions and GitLab runners, with Lambda compute for fast short builds and reserved capacity fleets.
Azure Pipelines (Azure DevOps)
YAML or classic pipelines for any language and platform, with Microsoft-hosted agents on Linux, Windows and macOS or self-hosted agents, environments with approvals, and deep Azure integration.
Cloud Build Soon
Serverless builds defined as container steps in cloudbuild.yaml, with triggers from GitHub, GitLab, Bitbucket and Secure Source Manager. Private pools run builds inside your VPC; SLSA build provenance is generated automatically.
Continuous delivery and deployment
CD takes a tested artifact and rolls it out: dev, then staging, then production, with approvals, automated verification and a rollout strategy (rolling, blue/green, canary) that limits the blast radius of a bad release.
Cloud Deploy and CodeDeploy are focused deployment engines. Azure Pipelines handles CI and CD in one YAML file with environments and checks. For Kubernetes specifically, many teams use GitOps (Argo CD or Flux) instead, where the cluster pulls desired state from Git. See the GitOps posts for that model.
AWS CodePipeline Soon
Release pipelines that orchestrate source, build, test and deploy stages, with V2 pipelines adding Git-based triggers and variables. Integrates with CodeBuild, CodeDeploy, CloudFormation, ECS and third-party tools.
AWS CodeDeploy Soon
Automated deployments to EC2, on-premises servers, Lambda and ECS, with in-place, rolling and blue/green strategies and automatic rollback on alarms.
Azure Pipelines release stages
Multi-stage YAML pipelines deploy to App Service, AKS, VMs and more, with environments, approvals and checks, deployment strategies (rolling, canary) and service connections using workload identity federation.
Cloud Deploy Soon
Managed continuous delivery to GKE, Cloud Run and GKE Enterprise, with promotion across targets, approvals, canary and parallel deployments, rollbacks and deployment verification.
Whatever tool you use, authenticate pipelines to the cloud with workload identity federation (OIDC) rather than stored access keys or client secrets. All three clouds support it for GitHub Actions, GitLab and their own pipelines, and it removes the most commonly leaked credential in CI.
Command-line tools
The CLI is how most engineers actually work with a cloud day to day, and how scripts glue things together. All three CLIs are mature, support SSO sign-in, and have a browser-based cloud shell with everything preinstalled. That’s handy when you’re on a locked-down laptop.
The unified aws CLI (v2) for every AWS service, with SSO sign-in through IAM Identity Center, profiles, output filtering with JMESPath queries, and a browser-based AWS CloudShell.
The cross-platform az CLI with extensions, interactive mode and JMESPath queries. Azure PowerShell (the Az module) is the PowerShell alternative, and Azure Cloud Shell gives both in the browser.
gcloud CLI Soon
The gcloud CLI from the Google Cloud SDK, alongside gsutil (now superseded by gcloud storage) and bq. Cloud Shell provides a browser terminal with tools preinstalled and a built-in editor.
The AWS CLI cheat sheet and Azure CLI cheat sheet collect the commands I use most.
Development and test environments
Developers need places to try things without touching production or waiting for tickets. The challenge is cost and sprawl: forgotten dev VMs running all weekend. Dev/test services give self-service environments from approved templates, with auto-shutdown and spending limits built in.
No dedicated dev/test lab service. Teams typically publish approved environments with AWS Service Catalog or CloudFormation templates, and use EC2 instance scheduling and budgets to control cost.
Self-service labs of VMs from approved images and formulas, with auto-shutdown, cost thresholds and per-user limits. Microsoft Dev Box offers managed developer workstations for the same need.
Cloud Workstations
Fully managed, container-based development environments accessed through the browser or a local IDE, defined centrally by admins and running inside your VPC.
Native tools or third-party?
My rule of thumb:
| Situation | Reasonable choice |
|---|---|
| Code already on GitHub, mostly one cloud | GitHub Actions with OIDC to the cloud, native deploy tools where useful |
| Microsoft shop, Azure-heavy, need boards and test plans | Azure DevOps (or GitHub Enterprise) |
| All-AWS, strict account boundary, regulated | CodeCommit/CodeBuild/CodePipeline, or GitHub with CodeBuild runners |
| GKE and Cloud Run delivery on Google Cloud | Cloud Build for CI, Cloud Deploy for promotion |
| Many clouds, many teams | One SaaS platform (GitHub, GitLab) plus each cloud’s identity federation |
The native tools’ biggest strengths are identity integration, private networking and staying inside one billing and compliance boundary. Third-party platforms usually win on developer experience, marketplace ecosystems and multi-cloud consistency.
Common pitfalls
- Long-lived cloud credentials in CI. Replace them with OIDC federation and short-lived tokens.
- Pipelines with admin rights. Give each pipeline the minimum roles for its environment, and separate production deploy identities.
- No artifact immutability. Build once, promote the same artifact everywhere. Rebuilding per environment means production runs something you never tested.
- Manual production fixes. Hotfixes in the portal create drift your next pipeline run will either undo or fight. Make the fast path go through the pipeline.
- Ignoring supply-chain security. Scan dependencies and images, sign artifacts and generate provenance (SLSA), and restrict deployments to signed images.
Conclusion
The cloud-native DevOps tools are solid, particularly for builds and deployments that need tight identity and network integration, but they aren’t the only option, and mixing them with GitHub or GitLab is normal. Decide where your code lives, use federated identity for every pipeline, build once and promote the same artifact, and pick the deployment engine that fits your runtime. A quick next step: audit your pipelines for stored cloud credentials and replace the first one with OIDC this week. Every service side by side is in the DevOps comparison.