How to Move From Cloud Support to Cloud Engineering

You already spend your day inside AWS, Azure, or GCP consoles. You resolve tickets about failed deployments, misconfigured security groups, and latency spikes. You understand these systems better than most people with "engineer" in their title. What you are missing is not skill, it is a specific, verifiable set of artifacts that let a hiring manager see what you already know.

Quick Answer: certify, build, then move laterally before external

Get one foundational certification (AWS Cloud Practitioner, Azure AZ-900, or GCP Associate Cloud Engineer) within 60-90 days, then build two to three portfolio projects that provision real infrastructure with code, not console clicks. Use that combination to request internal lateral movement first. Internal transfers convert faster than cold external applications because your ticket history already proves the hands-on part.

Why cloud support experience does not automatically read as engineering

The core problem is not a skills gap, it is an evidence gap. Cloud support work is reactive: you are handed a broken state and you restore it. Cloud engineering work is generative: you design the state before anything breaks, usually by writing infrastructure as code that a team can review, version, and reuse. A hiring manager scanning a resume cannot see the reactive troubleshooting depth behind a "Cloud Support Engineer" title, so the title itself works against you even when the underlying skill is close.

This is compounded by how cloud engineering roles actually get filled. Most are not screened purely on certifications; recruiters and hiring managers look for a portfolio or GitHub history showing Terraform, CloudFormation, or Bicep code that provisions something real, plus at least one certification that proves the vendor-specific knowledge is current. Support experience alone, without that artifact, reads as adjacent rather than qualifying.

The day-to-day tooling gap reinforces this. Support work happens mostly inside a web console or a ticketing system: you look at what exists, compare it to what it should be, and fix the difference. Engineering work happens mostly inside a code editor and a version control system: you write a definition of what infrastructure should look like, review it with teammates before it touches anything live, and let automation apply it. These are learnable skills, not innate ones, but they are genuinely different daily habits, which is why simply doing more support work for more years does not by itself produce an engineering resume. The gap closes through deliberate practice with the engineering tools, not through tenure in the support queue.

The market timing favors making this move now. AWS holds roughly 28-30% of the cloud infrastructure services market, Microsoft Azure roughly 21-24%, and Google Cloud roughly 13-14%, per Synergy Research Group's most recent tracking, with the three combined controlling close to two-thirds of that infrastructure market. The broader cloud computing industry, including software and platform spending on top of core infrastructure, is estimated at roughly $900 billion or more in 2026. Demand for people who can operate and automate that infrastructure has not slowed even as individual company hiring cycles fluctuate.

Your realistic paths, compared

There is more than one way to make this transition, and the right one depends on how much time and money you can put in before you need the new title.

Self-study is the cheapest path and works well because you already have daily hands-on access to the platform through your support role. The main risk is direction: without a plan, it is easy to watch broad "cloud fundamentals" content indefinitely without ever producing the specific artifact (a certification, a Terraform repo) that a hiring manager actually screens for.

A paid bootcamp buys structure and a cohort, which helps people who struggle to stay consistent alone, but the cost is hard to justify when your current job already gives you live infrastructure exposure most bootcamp students have to simulate. An internal lateral move is the fastest and cheapest option when it is available, because it replaces a resume screen with a direct conversation, but it depends entirely on your company actually running a cloud engineering function you can move into.

LearnPath sits inside the self-study path: it takes the same free YouTube content you would otherwise have to sequence yourself, ranks it by relevance to your stated goal, and gates each video behind a short transcript-based quiz so you cannot skip ahead without demonstrating recall. It does not replace certification study or hands-on labs, but it removes the sequencing and retention problems that make unstructured self-study slower than it needs to be.

How to make the move: step by step

1. Pick one platform and go deep, not three platforms shallow. Use whichever cloud your current support role already covers most, since that experience already compounds. Splitting attention across AWS, Azure, and GCP simultaneously is the single most common reason self-taught transitions stall before month two.

2. Open a free-tier sandbox account outside your work environment. Your production access at work is monitored and restricted; a personal free-tier account is where you break things safely. Provision a virtual machine, a storage bucket, and a basic network from scratch, by hand first, so you understand what infrastructure-as-code will later automate.

3. Earn one foundational certification within 60-90 days. AWS Certified Cloud Practitioner ($100), Microsoft AZ-900 ($99), and Google Cloud Associate Cloud Engineer ($125) are the standard entry points, and each has a published, current exam guide on its vendor's site. Pick the one matching your platform from step 1 and set a fixed exam date immediately, before you start studying, to force a deadline. A foundational certification is deliberately shallow by design; treat it as proof of vocabulary and breadth, not as the finish line.

4. Build two to three projects using infrastructure as code, not the console. Rebuild the sandbox environment from step 2 using Terraform or your platform's native IaC tool (CloudFormation for AWS, Bicep for Azure), commit it to a public repository, and write a short README explaining the design decisions. This single artifact is what separates a support resume from an engineering one. A strong first project is a small, complete environment (one network, one compute resource, one storage bucket, wired together) rather than an ambitious multi-service architecture you abandon halfway through. Two finished small projects beat one unfinished large one on every resume screen.

5. Bring the certification and one project to your current manager before you look externally. Ask directly what an internal transfer or a title change would require, and volunteer for any automation or infrastructure ticket that comes through your support queue in the meantime. Internal hiring managers already trust your troubleshooting history; you are only closing the "have they built anything" gap.

6. If no internal path exists, apply externally with the certification and repository link on page one of your resume. Lead with the artifacts, not the support job title. Recruiters filtering cloud engineer applications are scanning for exactly these two signals, and burying them under a generic support-role bullet list is the most common reason qualified candidates get filtered out automatically.

Realistically, expect the certification to take 6-8 weeks of evening study if you are starting from your existing support-role exposure, and expect each portfolio project to take one to two weekends once you know the tool. That puts most support engineers at a job-ready portfolio somewhere between month three and month six, with the internal-transfer conversation happening as soon as the first certification and first project both exist, not after everything is finished. Waiting for a fully polished portfolio before raising the conversation is the most common way people delay a move they were already qualified to make.

The transition rarely requires quitting your support role first. The certification and the portfolio projects are both things you build in evenings and weekends while your day job keeps paying you and keeps your hands-on access current. For a structured sequence of free cloud fundamentals content to pair with steps 1 and 2, our roadmap for learning cloud computing from YouTube and our ranked list of cloud engineering YouTube channels cover AWS, Azure, and GCP fundamentals in the order most self-taught engineers actually need them. If your support queue leans toward deployment pipelines and container issues more than raw infrastructure, the adjacent DevOps YouTube channels list is worth reviewing too, since the two skill sets overlap heavily at the associate level.

Frequently Asked Questions

How long does it take to move from cloud support to cloud engineering?

Most cloud support engineers who already troubleshoot AWS, Azure, or GCP daily can reach job-ready in four to nine months. That means one foundational certification within 60 to 90 days, two or three portfolio projects using infrastructure as code, and either an internal transfer conversation or external applications once both exist.

Which cloud certification should I get first: AWS, Azure, or GCP?

Get certified on whichever platform your current employer already runs, since that experience compounds fastest. With no strong employer signal, start with AWS Certified Cloud Practitioner or Microsoft AZ-900. AWS holds roughly 28-30% of cloud infrastructure market share and Azure roughly 21-24%, so both open the most job listings.

Do I need a computer science degree to become a cloud engineer?

No. Cloud engineering hires overwhelmingly on demonstrated skills: certifications, a portfolio of infrastructure-as-code projects, and hands-on platform experience. Support-to-engineering transitions are common precisely because daily support work already builds the troubleshooting instincts and platform familiarity that a traditional degree program does not teach nearly as directly.

Is an internal transfer easier than applying externally for a cloud engineer role?

Usually yes. An internal transfer skips the resume-screening stage entirely, since a hiring manager can see your ticket history and escalations directly. Build a case with your manager once you hold one certification and one internal automation project, rather than waiting until you feel fully ready.

Do cloud engineers need to know how to code?

Basic scripting is required, not full software engineering. Most cloud engineer roles expect comfort with Python or Bash for automation, plus a declarative infrastructure-as-code tool like Terraform or CloudFormation. You do not need data structures and algorithms depth, but you do need to read and modify existing scripts confidently.

What is the realistic salary jump from cloud support to cloud engineering?

Expect a meaningful but not dramatic increase, typically in the 10-20% range for a like-for-like level, more for a level-up move. The bigger long-term gain is ceiling: cloud engineering has a wider band and more paths to senior and architect roles than the support track.