Cloud Environments Are Not Interchangeable -- And Your Job Descriptions Are Proving It
Disclosure up front: I have strong opinions about these platforms. I hold an AWS certification, use GCP for my personal infrastructure, and I actively turn down Azure roles. I’ll tell you why as we go. Factor that into how you read this.
I’ve worked in AWS, Azure, and GCP. Not dabbled — actually shipped things in all three. And the single most persistent misconception I see from job descriptions, recruiters, and even some engineering managers is this: cloud experience transfers automatically between providers.
It doesn’t.
This matters whether you’re a recruiter trying to find the right candidate, an engineer trying to evaluate a role, or a CTO deciding what to optimize for when you’re building a team.
The Hidden Cost Nobody Budgets For
Every time an engineer switches cloud environments, there’s a ramp-up cost. Not just a learning curve — a real productivity tax that lasts weeks to months depending on the depth of the work.
This is the same reason you’d distinguish between Ansible and SaltStack experience in a job description. They’re both configuration management tools. They are not the same thing. The fact that we hold that distinction for toolchains but collapse it for cloud providers is an inconsistency worth examining.
And if you’re going to exclude Ansible experience when you need SaltStack, apply the same logic to your cloud requirement. Be specific in the job description. It respects the candidate’s time and your own.
Side note: if we’re treating cloud skills as interchangeable, why aren’t we including Linode, Digital Ocean, and on-prem management in the same bucket? The line we’ve drawn is arbitrary, and most people drawing it haven’t thought about why.
Let Me Show You What “The Same” Actually Looks Like
Take a basic architecture: one load balancer, three application servers, a two-node DB cluster with room to expand. Simple. Now let’s look at what it takes to deploy this in Terraform across all three providers.
AWS:
Consistent, well-documented, stable API surface. This is what I mean when I say AWS is developer-friendly — the toolchain works and it stays working.
Azure:
Azure ARM — deprecated in favor of Azure ARM 4.64.0
Azure VM? The widely-used module is now archived. The alternative depends on whether you’re running Windows or Linux, and that changes your path entirely.
Azure’s own documentation doesn’t surface cleanly in search results for these workflows.
I’m not editorializing here — the deprecation trail is documented above. The practical effect is that Azure engineers spend a meaningful portion of their time tracking API churn rather than building. That’s the real cost that doesn’t show up in cloud pricing calculators.
GCP:
GCP’s SaltStack integration is worth noting separately: a single GCE module handles the full scope of what AWS requires three separate boto modules to cover. That kind of surface area difference compounds over time.
The same pattern holds across Puppet, SaltStack, and Ansible — separate implementations, separate documentation, separate failure modes for every cloud provider.
My Actual Take on Each
AWS is where I’m most fluent. Developer-friendly, consistent, broad language support, stable toolchain. Not the most cost-effective option, but you know what you’re getting. My bias here is real — I’ll name it.
Azure I avoid. The deprecation cycle creates ongoing friction that I find disproportionate to the value. This is a personal and professional stance, not a recommendation for your organization. If your team is already invested in the Microsoft ecosystem, that calculus may look different for you.
GCP is where I run my personal infrastructure. Cost-effective, integrates cleanly with Google Workspace, straightforward to manage. For solo and small-team work, it’s hard to beat. Enterprise tooling (SAML, SSO, IAM) is available without the overhead I associate with larger providers.
What This Means for Hiring
There are two things worth optimizing for when you write a cloud requirement into a job description:
Specific platform experience — if your entire infrastructure is on Azure and you need someone operational on day 30, say that. It’s a legitimate requirement.
Adaptability — an engineer who has shipped in two or three different cloud environments has demonstrated something different and arguably more durable: the ability to learn a new system at depth. That’s not the same as platform expertise, but it’s not lesser either. It depends on what you actually need.
The engineers I’ve seen perform best in ambiguous, fast-moving environments are the ones who optimize for getting things done over knowing the right answer in advance. That’s a different hire than a platform specialist, and both have a place. But conflating them in your job description means you’ll filter out one or the other without meaning to.
Be specific about what you’re actually optimizing for. Your candidate pool will be better for it.