TL;DR
- Non-tech career changers and in-tech laterals (software engineers, DevOps engineers) both search this topic - your starting points are different enough that one roadmap misleads both. This guide gives each reader their own path.
- The shared failure mode is cert-rich-project-poor: collecting AWS certifications without deploying real infrastructure is the fastest way to spend 18 months and still fail architecture interviews.
- Certification sequence - Cloud Practitioner first, then Solutions Architect Associate (SAA). Those two, in that order, are the entry-level cloud engineering hiring bar. Stop certifying after SAA until you have deployed work on GitHub.
- Timeline ranges: 9-18 months for non-tech readers, 3-9 months for in-tech laterals. The range depends on how consistently you pair certifications with deployed infrastructure.
- What a mentor changes specifically: architecture decision feedback and interview calibration - not exam prep. Good self-study resources for Cloud Practitioner and SAA are cheap. The gap mentors close is harder to simulate alone.
Is cloud engineering right for you?
Cloud engineers provision and manage infrastructure - not products end users touch. If you've been imagining building features that customers interact with, I'd clarify that before spending a year certifying. The work: provision a VPC, configure security groups, deploy an EC2 instance running a web app behind a load balancer, set up CloudWatch alerts, and respond when they fire at 2am. You're building the plumbing that lets other engineers build features.
| Level | Base salary | Total comp |
|---|---|---|
| Entry / median | $95,360 (BLS data) | N/A |
| Mid-level | $135K-$152K (Kore1 Cloud Engineer Salary Guide 2026) | Often exceeds $175K |
Demand is strong in the US, UK, and EU.
If you're coming from non-tech: the shift is into a specialist infrastructure role. You're not building what the customer sees - you're building the cloud equivalent of the data centre. The "user" is the application team, not the end user. This reframe matters for whether you'll find the work satisfying.
If you're already in software or DevOps: the shift is from feature delivery to infrastructure reliability. Your KPIs change. Sprint velocity stops mattering. Uptime, latency, and cost per request become the measure. That's a genuine mental model shift, not just a new set of tools.
Wrong-fit signal: if you want a role where your deliverable is a finished product end users touch, cloud engineering is probably not it. The user is the application team, not the customer. If building the plumbing that enables other people's features sounds frustrating rather than satisfying, that is worth taking seriously before spending 12 months certifying.
Wrong-fit signal: if you're choosing cloud engineering primarily because of the salary, and you genuinely dislike infrastructure troubleshooting, reconsider. Incident response at 2am is not optional - it is the job.
Ifeanyi Otuonye was a professional athlete and sports event manager before he became a 10x AWS Certified Technical Account Manager at AWS. His story on the AWS Training Blog is worth reading as proof that the path is genuinely open from non-technical starting points.
What does a cloud engineer actually do?
A cloud engineer is not a software engineer who happens to work on infrastructure - it's a distinct role with its own operational patterns, failure modes, and KPIs. The day-to-day is infrastructure provisioning (VPCs, EC2, RDS, S3, Lambda), writing and maintaining IaC (Terraform or CloudFormation), monitoring system health, and responding to incidents. The job is infrastructure reliability, not feature delivery.
One ordinary work sequence: you receive a request to deploy a new web application. You spin up a VPC, configure public and private subnets, set up security groups, provision an EC2 instance behind an application load balancer, attach an RDS database in the private subnet, configure CloudWatch for metrics and alerts, and write the Terraform module to make it reproducible. Nothing cinematic - that's what the job looks like from input to output.
If you're coming from non-tech: think of it as building the data centre in the cloud. The concepts of servers, networking, and storage are the same physical realities - the interface is a console and a CLI rather than a server room. This analogy helps with the learning curve more than most tutorials will admit.
If you're already in software or DevOps: the shift is from feature-first to infrastructure-reliability thinking. The IaC-first mindset and immutability patterns feel familiar if you've done infrastructure work, but the AWS operational model - IAM scope, multi-AZ design thinking, managed service selection - requires deliberate study rather than pattern-matching from prior experience.
What you need before you start - honest prerequisites
Prerequisites for non-tech and in-tech readers are different enough that an averaged list would undersell both. The shared point: neither path starts with AWS certifications. Both have a foundation layer that needs to be in place first, or the certification material won't stick.
For non-tech readers transitioning into cloud engineering
You need three things before AWS-specific study makes sense: Linux command line basics, basic scripting, and networking fundamentals. Not mastery - a functional floor that lets you work through the cert material without getting lost at every example.
- Linux: file system navigation, process management, SSH into a remote server you provisioned yourself
- Scripting: Python or Bash, basic loops and file operations - the bar is automating a simple task, not software engineering
- Networking: TCP/IP, DNS, subnets - the bar is not getting lost when someone mentions security group rules
AWS Cloud Practitioner prep courses cover some of this. The rest is two to three weeks of focused self-study.
Milestone test: you're ready to move to certifications when you can SSH into a Linux server you provisioned yourself, write a basic Python or Bash script that reads a file and loops through it, and explain what subnetting is and why it matters. Observable pass/fail - can do it, not "understand it."
Check out AWS certifications for an overview of the cert landscape once you've hit this baseline.
For in-tech readers moving laterally into cloud engineering
If you're already a developer or DevOps engineer, you have more foundation than you think - and more specific gaps than you expect. The gaps aren't Linux or networking basics; they're AWS-specific: the IAM policy model, VPC topology, managed services landscape, and cost management patterns.
The IAM model specifically: it's not just "permissions exist." The principals, policies, and permission boundary conditions are distinct from how most application developers think about auth. VPC topology (subnets, routing tables, security groups, NACLs) is an area experienced engineers consistently underestimate. The managed services landscape - knowing when to use RDS versus self-managed, ECS versus EKS versus Lambda - is its own decision framework.
Harry Zhou documented his transition from network engineer to SRE/cloud engineer in a first-person account on AWS in Plain English. He came with solid networking knowledge but still spent significant time building the AWS-specific mental model.
Milestone test: you're ready to treat your path as accelerated when you can draw a VPC diagram from memory, name at least five managed services and explain their tradeoffs, and articulate the difference between IAM roles and IAM users with a real use case.
If your background is DevOps-heavy, a DevOps mentor who's made a similar lateral move can review your specific gaps before you start certifying.
The AWS certification roadmap
The cert sequence is Cloud Practitioner first, then Solutions Architect Associate (SAA). Those two, in that order, are the entry-level cloud engineering hiring bar. The failure mode that affects both reader types is cert-collecting beyond SAA before deploying real infrastructure. Pass SAA, deploy two projects, then apply - not cert-collecting until month eighteen.
For non-tech readers - AWS certification sequence
Cloud Practitioner is the baseline for everything that follows. For non-tech readers, this cert is not optional - it establishes the cloud vocabulary that makes SAA study tractable. Four to six weeks of self-study is realistic. Stephane Maarek's Udemy course and A Cloud Guru are both strong preparation resources.
After Cloud Practitioner, register for Solutions Architect Associate. Eight to twelve weeks of prep time is typical. This is the threshold cert - the one that appears most consistently in cloud engineering job requirements at the entry level. Pass this, then deploy, then apply.
Milestone test: Cloud Practitioner passed. You can now register for Solutions Architect Associate. Do not register for any other AWS cert before SAA.
SysOps Administrator and Developer Associate aren't prerequisites for your first job - add them after you're hired. Every week spent on a third cert before you've deployed is a week you're not closing the gap between "cert holder" and "hired engineer."
For in-tech readers - AWS certification sequence
If you're already technical, you have a decision to make about Cloud Practitioner. Here's the concrete criterion: score 80% or higher on a Cloud Practitioner practice exam on your first attempt and you can skip it. Below 80% on first attempt, do the cert. Not "if you feel confident" - if you hit 80%.
Regardless of whether you skip Cloud Practitioner, SAA is mandatory. The hiring bar doesn't flex because the candidate has software experience. Architecture interviews test AWS-specific mental models, not general engineering ability. Experienced engineers who skip SAA - assuming their SE skills transfer directly - are the ones who blank on the multi-AZ deployment question in interviews.
Milestone test: if you score below 80% on a Cloud Practitioner practice exam on first attempt, do the cert. If you score 80%+, you can skip it. But do not skip SAA - that is the hiring bar regardless of background.
Solutions Architect Professional and DevOps Engineer Professional are the natural next steps after your first cloud role. They're appropriate for in-tech laterals targeting senior cloud positions - worth planning for, not pursuing before you're hired.
Building the portfolio - what deployed infrastructure actually looks like
The portfolio is the primary output of your cloud engineering transition. Not the certifications - those prove you studied. The portfolio proves you can do it. When I talk to cloud engineering hiring managers, they ask you to walk through your architecture decisions, not recite your cert stack. The cert doesn't answer that question. The portfolio does.
Shared requirements:
- At least two deployed projects on AWS with source code on GitHub
- At least one project uses IaC (Terraform or CloudFormation)
- You can explain every architectural decision - why X instead of Y
Milestone test: your portfolio is ready to show when you have at least two deployed projects on AWS with source code on GitHub, at least one uses IaC, and you can explain every architectural decision.
Ryan Almeida documented his mechanical engineer to Solutions Architect transition in a 6-month memoir on Medium - a non-tech-to-cloud story that centres deployed projects as the bridge from cert holder to hired engineer. Worth reading for a realistic timeline and what "show your work" means for non-technical career changers.
If you're coming from non-tech: start with the complexity ramp. S3 static site first - understand storage, public access, and cost. Then an EC2-hosted web app. Then add RDS integration. Then a load balancer and auto-scaling. Don't attempt a multi-service architecture first. Use AWS Free Tier for the first twelve months - cost awareness is part of the job from day one.
If you're already in software or DevOps: your expected starting point is more complex. CI/CD pipeline, containerised deployment, Terraform-managed infrastructure. Match portfolio complexity to the seniority level you're targeting. If you're applying for a mid-level cloud role, your portfolio should demonstrate IaC, multi-AZ thinking, and at least one Terraform module you wrote yourself.
How long it takes and what can go wrong
Timeline and failure modes differ for the two reader types. The shared failure mode is cert-rich-project-poor: collecting certifications without deploying infrastructure affects both non-tech and in-tech readers, though it shows up differently. The ranges below show both paths, with the failure signal included.
For non-tech readers - realistic timeline and common failure modes
Nine to eighteen months is the realistic range for non-tech readers. The range depends entirely on how consistently you pair certifications with deployed projects. Cert work alone won't get you there. The most common failure signal is approaching month twelve with multiple certifications and nothing deployed on a public GitHub.
| Milestone | Target timeframe |
|---|---|
| Cloud Practitioner earned | Month 4-6 |
| SAA in progress, first project deployed | Month 6 |
| SAA earned, two portfolio projects live | Month 12 |
| Application-ready - portfolio and cert stack complete | Month 15-18 |
Ryan Almeida's 6-month memoir is worth reading for what's possible with sustained intensity - though treat his timeline as the optimistic end of the range, not the baseline.
Failure signal: if you're approaching 12 months with multiple certifications but nothing deployed on a public GitHub, this is the failure mode. The next six months should be zero certifications and maximum deployment.
For in-tech readers - realistic timeline and common failure modes
Three to nine months is the realistic range for in-tech laterals. The compressor is your existing foundation. The expander is the specific AWS gaps you underestimate. Those gaps are usually the IAM policy model and VPC topology - areas experienced engineers consistently rate as familiar until they actually study them.
| Milestone | Target timeframe |
|---|---|
| Cloud Practitioner decision made, SAA in progress, first AWS project underway | Month 3 |
| SAA earned, portfolio deployed | Month 6 |
| Application-ready | Month 9 |
Failure signal: if you're confident enough in your existing skills to skip foundational AWS study and go straight to job applications, check this assumption. Can you explain a multi-AZ deployment and why it costs more? Can you name three IAM permission boundary scenarios? If those questions pause you, your timeline needs foundation work first.
Common roadblocks (and how to get past them)
The top roadblocks aren't motivation problems - one pattern we keep seeing at MentorCruise is that clarity, not motivation, is what career changers run out of first. The structural issues are scope creep and the cert-collection spiral, with a reader-specific failure mode underneath each.
Scope creep: cloud engineering is broad. IAM, networking, compute, storage, databases, serverless, containers - all feel important simultaneously. Pick a lane. Compute and networking first, then expand per the cert roadmap. Cert-collection spiral: each AWS certification page suggests two more. SAA is the bar - stop certifying until you have deployed infrastructure.
If you're coming from non-tech: foundation gaps re-emerge unexpectedly mid-SAA. The fix is pairing each certification phase with a deployment project that forces you to use what you just studied, not just answer multiple-choice questions about it.
If you're already in tech: the "I know this already" trap. AWS-specific mental models get downgraded because the concepts feel familiar. Run a practice architecture interview at month two or three, not month eight. Surface the gaps before they cost you an offer.
In my experience, engineers come to us after using Claude or Copilot to build cloud infrastructure - and the AI does it. But when the deployment breaks, or someone asks why you made that architecture choice, the AI isn't in the room. That's the gap mentors close.
What a mentor does that self-study can't
A mentor in cloud engineering closes two specific gaps that self-study materials can't simulate: architecture decision feedback and interview calibration. Every good study resource explains how AWS services work. None of them tell you whether your architecture choice makes sense for the problem you described, or whether your explanation of a multi-AZ deployment would satisfy a senior engineer running a cloud interview.
I've watched hundreds of career transitions through MentorCruise. The successful ones follow a pattern: they start with internal clarity (what do I actually want?), move to skill mapping (what gaps exist?), and only then go external (networking, applications). Most people start with step three and wonder why they're stuck.
Wrong-helper signal: if what you need is cheaper AWS exam prep, a mentor is not the right tool. Good self-study resources for Cloud Practitioner and SAA are inexpensive. What mentors on MentorCruise do is close the two gaps that self-study can't: architecture decision review and interview simulation.
If you're coming from non-tech: the mentor's role is pacing and foundational gap identification. A mentor who made the same non-tech-to-cloud transition can tell you which foundational gaps actually trip people in interviews - the specific routing table question that SAA prep glossed over, the IAM confusion that shows up in the technical screen.
If you're already in tech: the mentor's role is architecture pattern review and AWS-specific interview calibration. Dan Ford spent 15 years in tech recruiting before becoming a career coach. He's seen thousands of resumes and conducted hundreds of interviews, and his MentorCruise mentees get insider knowledge most candidates never access. Dan Ford's mentor profile. The cloud mentors on MentorCruise aren't just certified - they've made the transition themselves. We accept fewer than 5% of mentor applicants, which means when you're matched, they've been vetted for both expertise and mentoring ability.
Tools, mentors, and next steps
The tools that actually move the needle for the AWS path are a short list - everything else is noise. AWS Free Tier for deployment practice, Stephane Maarek's Udemy courses and A Cloud Guru for Cloud Practitioner and SAA prep, Terraform Registry and HashiCorp Learn for IaC fundamentals, and GitHub for portfolio hosting. Public repos are expected.
If you're transitioning into cloud engineering, finding a mentor who's already made the jump - from non-tech or from software - cuts years off the path. The architecture decision gap and the interview calibration gap are the two places where self-study consistently breaks down; both are the exact territory an experienced cloud mentor works through with you. Find an AWS mentor on MentorCruise. 7-day free trial on all plans, so you're not committing to months of subscription before you know the fit.
The cert-rich-project-poor pattern is solvable - the path is documented, the failure mode is named, and the only thing left is execution. You can also explore cloud coaching for a broader look at cloud-adjacent mentoring.
FAQs
Do I need a computer science degree to become a cloud engineer?
No. AWS explicitly states that some cloud roles require no technical experience via their careers page. The hiring bar is certifications (Cloud Practitioner plus SAA) and a portfolio of deployed infrastructure on GitHub. A degree doesn't hurt, but it isn't what interviewers ask about. What they ask about is your architecture choices in your deployed projects.
What AWS certifications should I get first?
Cloud Practitioner first, then Solutions Architect Associate. Those two, in that order, are the entry-level cloud engineering hiring bar. Don't collect certifications beyond SAA before you have deployed infrastructure. After your first cloud role, SysOps Administrator and Developer Associate are worth adding - but those are post-hire goals, not prerequisites.
How long does it take to become an AWS cloud engineer?
Nine to eighteen months for non-tech entrants; three to nine months for in-tech laterals (software engineers, DevOps engineers). The range depends on how consistently you pair certifications with deployed projects on AWS. Collecting certifications without deploying is the failure mode - it extends the timeline without moving you closer to an offer.
Can a software engineer become a cloud engineer?
Yes, and it's one of the cleaner lateral moves in tech. Your software engineering foundation transfers - Linux familiarity, scripting, and systems thinking all carry over. The gap is AWS-specific: the IAM policy model, VPC topology, and managed services tradeoffs. Solutions Architect Associate is still the certification you need regardless of software background - it's the hiring bar.
What does a cloud engineer do day to day?
Cloud engineers provision and manage infrastructure (VPCs, EC2, RDS, S3, Lambda), write and maintain IaC (Terraform or CloudFormation), monitor system health, and respond to incidents. The deliverable is infrastructure that enables other engineers - not features end users touch. Rough split across a typical week: most time goes to design, IaC build, and maintenance, with incident response a smaller but non-optional slice.
Is AWS cloud engineering a good career change?
The market data says yes: US base salaries run $95,360 median (BLS data) to $135K-$152K at the mid-level, with total comp often exceeding $175K (Kore1 2026). There are over 18,200 annual openings in the US alone, with strong demand in the UK and EU. The honest filter is role fit - cloud engineering is infrastructure-first. If building the plumbing that enables other people's features sounds satisfying, the demand is real and the path is documented.
