Post a job for a cloud engineer and you'll attract five different jobs across three different platforms. Plenty of job specs don't separate either. One hiring guide's requirement is simply "AWS, Azure, or Google Cloud", as if the three were interchangeable line items. They aren't. Hire for the platform you actually run and the role you actually need, and in our experience the rest of the skill set transfers well enough to fill the gaps.
This guide is one entry in Hire developers by tech stack: rates, vetting and interview guides. It has no cloud engineer rate, because we couldn't find a primary, dated source for one.
Which cloud engineer do you actually need?
"Cloud engineer" covers four jobs that get written into one job description.
A cloud engineer builds and operates infrastructure on one provider: networks, compute, storage, identity, and the managed services on top. A cloud architect designs the system before anyone builds it and owns the trade-offs between cost, resilience and complexity. A cloud security engineer owns IAM and network posture, meaning who can touch what and where traffic is allowed to go. A cost owner (the FinOps role, in industry shorthand) watches the bill, commitments and idle resources.
A team of ten rarely needs four people. It needs one strong engineer who does the first job well and can hold a conversation about the other three. Write the job description for that person, and state which of the other three you expect them to cover.
The vendor certification names roughly follow the same split. AWS has Associate certifications for Solutions Architect, Developer, Data Engineer, CloudOps Engineer and Machine Learning Engineer. Microsoft has an Azure Administrator Associate for the operator and an Azure Solutions Architect Expert for the designer. A CloudOps or Administrator credential roughly maps to the engineer role. An architect credential roughly maps to the architect role. Neither tells you about security or cost ownership, so test those directly.
If the role is CI/CD pipelines, on-call or platform tooling, that's a different search. The DevOps, SRE and platform-engineering split has its own guide, and this one won't repeat it.
AWS, Azure or GCP: which platform should you hire for?
Match the platform you already run
Hire for your platform, not for a favorite. In our experience, an engineer with three years on AWS can learn Azure's naming and console, but you'll pay for that ramp in the first quarter, and the mistakes will happen in your production account. If you're mid-migration, hire for the destination platform and pair that person with someone who knows the source.
What adoption data says
In Stack Overflow's 2025 developer survey, all respondents reported using AWS at 43.3%, Azure at 26.3% and Google Cloud at 24.6%. That's usage share among developers, not the size of the hiring pool. It does tell you AWS is the most common platform to have touched. It doesn't tell you how many people have run it in production at your scale.
Multi-cloud and hybrid roles
Buyers do search for hybrid and multi-cloud engineers. Be careful with the job description. "Experience with AWS, Azure and GCP" attracts people who've used each once. Name a primary platform, then name the second one and the reason: an acquired company's workloads, a customer requirement, or an on-premises footprint. Ask candidates for depth on the primary and a sound mental model of the second. Decide whether you need real depth on two clouds or just someone who won't panic when the second cloud shows up.
What AWS, Azure and GCP certifications prove (and what they don't)
A certification shows that someone passed an exam covering a defined set of services. It doesn't show production judgment. The vendors themselves are clear that experience is a separate axis, and AWS lists recommended experience next to each credential, and Microsoft lists a level or prerequisite.
| Vendor | Credential | Level and recommended experience | Validity or renewal |
|---|---|---|---|
| AWS | Solutions Architect - Associate | At least 1 year of hands-on experience designing cloud solutions that use AWS services | Valid for 3 years |
| AWS | Solutions Architect - Professional | 2 or more years of experience using AWS services to design and implement cloud solutions | 3 years |
| Azure | Administrator Associate | Intermediate level | Renewal every 12 months, free, through an online assessment on Microsoft Learn |
| Azure | Solutions Architect Expert (AZ-305) | Requires the Administrator Associate first | Expires unless renewed; free renewal assessment on Microsoft Learn |
| Google Cloud | Associate Cloud Engineer | 6+ months hands-on experience with Google Cloud | 3 years |
| Google Cloud | Professional Cloud Architect | 3+ years of industry experience including 1+ years designing and managing solutions using Google Cloud | 2 years |
The figures come from AWS's Solutions Architect Associate and Solutions Architect Professional pages, and Microsoft's pages for the Azure Administrator Associate and the Azure Solutions Architect Expert. The Google Cloud rows come from Google's pages for the Associate Cloud Engineer and the Professional Cloud Architect.
Two things follow from the table. Microsoft's certification pages say an Azure Administrator Associate certification has to be renewed every 12 months, so an active credential tells you something current, while an expired one tells you very little either way. And Azure's Expert credential has a prerequisite, so someone holding it must have earned the Administrator Associate first.
Ask candidates to share the credential through the vendor's own verification, not a PDF or a resume line. And don't let a certificate substitute for the hands-on screening below. Someone with an Associate credential and no production time can pass an exam and still ship a security group open to the world.
How to hire a cloud engineer
1. Write the job description around one platform and one outcome
State the primary platform, the outcome for the first six months (a migration landed, a network rebuilt, the bill brought under control), and which of the four roles you're hiring. If the work is a migration, what a migration project costs when you need extra cloud hands covers the budget side, which this guide doesn't.
2. Screen for hands-on depth before the interview
Ask every candidate for a written, one-page architecture walk-through of a system they built end to end: what ran where, what the network looked like, who had access, what it cost roughly and what they'd change. Strong candidates write specifics: the names of services, the failure that taught them something, the decision they'd reverse. Weak ones write a service list. Two paragraphs of that is enough to sort a stack of applications.
3. Run a platform-specific review exercise
Pick one of the exercises in the next section and run it in the interview, using the candidate's platform vocabulary. Ask for a written review, not a live fix, so you see what they notice first.
4. Check the credential and scope of access
If the candidate lists a certification, verify it with the vendor. Then decide what access the hire gets on day one. A new engineer who needs production IAM permissions before they've shipped anything is a scoping problem, not a trust problem. Start with read access and a sandbox account, and widen it as they deliver.
5. Decide the engagement model
Cloud work often starts as a defined project: a migration, a network rebuild, a cost clean-up. That favors a contractor or staff augmentation over a permanent seat. Once someone needs to own on-call and infrastructure-as-code long term, hire full-time and scope that ownership explicitly in the offer.
Cloud vetting exercises that separate senior from mid-level
A certification can't test judgment. These four exercises can. Each works on any of the three platforms; use AWS IAM, Azure RBAC or Google Cloud IAM terms depending on the role.
IAM review
Hand the candidate a role or policy with wildcard permissions on all actions and all resources, attached to a service that only reads from one storage bucket. Ask what's wrong and what could break if they tighten it.
A strong candidate names the blast radius first: if that service is compromised, the attacker has the whole account. Then they raise the risk of the fix, that narrowing permissions can break a job that quietly relied on the extra access, and they suggest checking access logs before changing anything. A weak candidate says "use least privilege" and stops there.
Network and blast-radius design
Describe a two-tier application: a web front end and a database. Ask where public traffic should stop, in a VPC on AWS, a VNet on Azure or a VPC network on Google Cloud.
Strong answers put only the load balancer in a public subnet, keep the database with no public route, and explain how the application tier reaches the outside for updates without opening inbound access. Ask what an attacker on the web tier can reach. Weak answers rely on a security group alone or say "it's behind a firewall" without saying which one.
Cost and quota review
Give them a description of a monthly bill with one large idle resource and a purchase commitment that isn't being used. Ask what they'd check first. Don't ask for percentages.
Strong candidates ask what the resource is for and who owns it before deleting anything, then look at usage over a period, not a snapshot. They ask whether the commitment matches steady workloads or a one-off spike. Weak candidates say "turn it off." The more useful signal is whether they think about who gets paged if the thing they deleted mattered.
Managed versus self-run
Ask when they'd choose a managed database or container service over running it themselves on a cluster or virtual machines.
A senior engineer starts from the team: how many people are on call, and what does the extra control buy? They'll say the managed option is usually right until a specific limit shows up, and name one. A mid-level engineer picks by taste, and often the more complicated option. For managed data services specifically, data engineers who own the warehouse side of your cloud are a separate hire.
Cloud engineer interview questions
1. Walk me through the last outage or near-miss where the cloud provider's behavior surprised you.
Tests whether they've run something real. Listen for the specific service, the limit or default they hadn't known about, and what they changed afterward.
2. How do you decide what goes in one account or subscription versus several?
Tests isolation thinking. A strong answer separates environments and blast radius, and mentions who pays for what and how access is granted.
3. What would you check if a service can't reach a database it could reach yesterday?
Tests debugging order: routes, security rules, DNS, then recent changes. Weak answers jump to "restart it."
4. How do you keep the cloud bill from growing faster than usage?
Listen for tagging, ownership and reviewing commitments against actual steady-state use. Beware answers that are only about turning things off.
5. If the role is AWS: how would you let one account's workload read from another account's storage safely?
Listen for roles assumed across accounts instead of long-lived keys, and for scoping the permission to specific resources.
6. If the role is Azure or GCP: how do you grant a workload access to a secret or storage without a stored credential?
On Azure, listen for managed identities. On Google Cloud, listen for service accounts attached to the workload instead of downloaded keys. On either, the tell is that credentials stay off disk.
Sourcing cloud engineers in Europe
HighCircl's covered stacks are React, Node.js, Python, iOS, Android, Flutter, Go and DevOps. It doesn't list AWS, Azure or GCP-specific placement, so treat this section as a description of how it hires engineers, not a promise of a cloud-platform match. HighCircl matches within 72 hours and shortlists 3-5 candidates. Four stages of engineer-led vetting (background and experience verification, a communication and product-thinking assessment, a take-home project mirroring real work, and a live session on architectural reasoning) pass roughly 1 in 10 applicants. The margin is 20%, capped and disclosed, with no minimum hour commitment. Delivery covers seven European countries. It's GDPR-native for engineers in EU member states, and Serbia isn't one.
FAQ
Do cloud engineers need to be certified?
No, but a certification is a fair first filter on the platform's basics. AWS lists recommended experience next to each credential, and Microsoft lists a level or prerequisite, so an Associate certificate tells you about exam coverage and not about years in production. Treat it as a reason to ask deeper questions, not a reason to skip the exercises above.
Should I hire for AWS, Azure or GCP if we might switch or go multi-cloud?
Hire for the platform you run today. Core skills such as networking, identity, cost control and reading logs transfer well in our experience, and a good engineer learns the second platform's naming quickly. If a second cloud is already committed, name it in the job description with the reason, and screen for depth on the first and a sound mental model of the second.
What is the difference between a cloud engineer and a DevOps engineer?
A cloud engineer builds and operates infrastructure on a provider. A DevOps engineer owns the path code takes to production, including pipelines, automation and often on-call. The two overlap in tooling but not in what each is accountable for. The DevOps hiring guide covers that split in full.
How much does a cloud engineer cost?
There's no single sourced figure worth printing here. Cost depends on the platform, seniority, country, whether the person is a contractor or an employee, and whether the role includes security or architecture duties. Any rate quoted without a dated national salary source is a guess. For HighCircl's general senior engineer range, the hire page is the place to check.
How long does it take to hire a cloud engineer?
For its covered stacks, which include DevOps, HighCircl delivers a vetted shortlist in 72 hours. Direct hiring can take several weeks once sourcing, interviews and notice periods are counted. The largest delay is usually a job description that doesn't name a platform or a role.