I meet with a lot of customers that need Cloud training.
They often have someone wearing multiple hats who is responsible for Cloud as well as a bunch of other stuff. What’s tough about this is that these employees have to learn Cloud piecemeal, and often never get a strong fundamental base for it.
I empathize with both individuals and organizations that are up against this. Upskilling is hard, but with Cloud I think it’s a worthy investment and absolutely necessary for long-term success.
Does it have to be expensive? No! It doesn’t.
In fact, there’s so much cheap training that it’s hard for me to justify spending a lot more unless there’s a short time requirement. I think it’s possible now for someone to significantly upskill in Cloud on a small budget.
Today, I’m going to show you how. But first, a little backstory…
Backstory
Back in 2020, I decided I needed a change. At the time I was multi-hatting as an IT Manager and a Systems Engineer but feeling stagnant in my growth. I had a lot of traditional skillsets, but I wanted to do something new, challenging, and preferably affordable too!
I decided that within a year I’d be make myself cloud fluent in AWS. So where was I to begin?
In this article, I’ll talk you through my approach to getting educated in Cloud in the hopes that it helps you or someone you know with training and learning a Cloud platform.
This is not intended to help someone get a cloud role, although it could certainly be used that way. This is for training proficiency in Cloud for someone who is expecting to work with it on a daily basis.
Hope you enjoy.
What You’ll Need
No fluff, this is what you need:
Time: Minimum 2 hours per day minimum for studying and labs. You can do less, but it will take twice as long and your retention will likely struggle as a result. If you can have uninterrupted time, even better.
Budget: $150.00-200.00. Likely less. I know for some that sounds like a lot, but I see the ROI here as ridiculous and well worth it. For organizations training their people, this should be the easiest money you’ve ever spent.
Strategy: Know what you’re studying for and training for, with the role and work involved in mind. More clarity = better outcomes.
Course: Invest in one great course, stick to it, and finish it. Get an instructor that matches your learning style and go with that course. $40-150.
YouTube: Everyone uses this right? You’ll use it to watch videos from conferences and hear from those in industry. Free.
Documentation: Use the Cloud Service Provider’s documentation. No excuses. Free.
Workshops/Labs: Use either AWS Workshops or Azure Learn. GCP people if you’re reading this, feel free to let me know the best site for this in the comments. Free to access, can cost to set up.
Notetaking Software: Whatever you work best with. I use OneNote. You’ll use this to build a library for the rest of your career. Free options, some paid.
Account/Subscription: Get an AWS account or Azure subscription. It’s free to set up so don’t worry about getting billed yet. It’s PAYG after all. If for some reason you can’t get one of these, there are sandboxes available but typically as part of an Enterprise learning subscription for a major learning platform. Here’s another one for Whizlabs that’s subscription-based if that’s more your angle. Do not recommend personally.
LinkedIn or Social*: You’ll use this to follow other people in similar roles and get in the conversations you’ll be having as a cloud engineer or architect. It will also double as a place to post for you. Free.
Blog*: Could be Medium, could be self-hosted as a first project, but whatever you end up on it’s important to write articles and document your work somewhere. Also makes you publicly available to other people to collaborate with you! Free options, some paid.
I put an asterisk on 2 of these because this isn’t up to an organization to do, but from an individual perspective I think they’re necessary to get better.
Additionally, if you have any aspiration to one day go out on your own, if you don’t have proof of work, you’ll be struggling to recreate all the things you’ve done before. An easy way to get ahead of this is—you guessed it—write things and post publicly. There’s a method to my madness.
What You Don’t Need
Here are the things I found I didn’t need on my path:
Certification Books. This is a shocker, I know. For anyone who uses books like I do for most everything else, I wouldn’t buy too many cloud certification books unless you intend for them to be desktop references. The certification ones will be outdated by the time you finish. Things change often in this world.
Expensive Bootcamps. 95% of the time—stay away. Not worth it. The ROI isn’t there. You won’t be any more of a cloud pro than someone who simply put their head down and grinded doing self-study methods.
Niche Courses. Buying an AWS Lambda course on Udemy unless you plan on becoming a Lambda SME is not going to do much for you. Save your money and come back to them if you actually need them for your work.
Bonus, although I chose to do it: Test. You don’t need to test. You can upskill without testing. While I think it’s a great way to motivate yourself and help learn the material and have something to show for it at the end, you don’t have to test. The tests are typically somewhere between $100-200 to take unless you get them on discount, so if you do opt to test, just know it will be the most expensive item on your list.
My Method
First off, I’m not original in the slightest even if this method seems a little different.
When I was a child, I learned violin at the age of 3 through something called the Suzuki method. Unsurprisingly, much of how I learn is based on this method because it works extremely well.
Here’s how I’ve adopted it to learning Cloud:

Hear the Language of the Industry. You can only get this through exposure to people talking or writing about the thing you’re learning about. Being involved in the conversation whether in-person or via online materials is crucial to being effective in real life. Developing an ear for it will make you more credible.
Learn from a Great Teacher. Use only the best and skip the rest. Spend your money wisely so you don’t have to spend it again.
Build Sooner. The time from learning something to the application of it needs to be brief. In the case of cloud learning, you will learn the concepts best if you’re able to build them and see how things respond to the actions you take. This also gets you hands-on with documentation which is invaluable.
Share in Public/Learn Out Loud. Get used to writing about the things you built and explaining your understanding of them in public. Find other people doing similar things and bounce ideas off them. Steel sharpens steel.
Record Information for Yourself. Take notes for every lesson you do, and for labs as well. Organize your notetaking so you can use it as a reference later and modify as you learn more. For added points, practice teaching to others or to a camera. You will build a library of knowledge and evidence for yourself.
Find Mentors. Seek out those who’ve achieved what you want to achieve and align yourself with them. You don’t need to be personally mentored by them, but it helps.
Learning the Industry - Hear the Language
This is my unique twist on most learning approaches and let me explain why I think it’s so important.
It is inevitable that when you start talking about Cloud with others, you’ll need to be able to speak the language of an engineer or architect. Part of that is encompassed in coursework like those mentioned above. But what goes missing from that is industry-speak, which is much harder to obtain than theoretical knowledge.
If you’re bound to coursework, you’ll see much of the world through that lens where every problem is a nail with which to hit with the CSP-provided hammer. That hammer can be useful, but it can also be hurtful.
You’ll need to make the Cloud work with your business or someone else’s business wherever you end up. Rarely will that involve only the CSP, and even more rarely will that conversation happen between a bunch of Cloud SMEs all in one room. More likely you have to help an organization make Cloud decisions with the help of people from all sorts of IT backgrounds.
So how do you learn the language?
I think a mixed approach is necessary. Here are the most important ingredients:
Conference Recordings on YouTube: Events like Re:Invent, Re:Inforce, Microsoft Ignite, etc. are great things to watch especially for the aspiring engineer or architect. They’re the epicenter of expertise, so great people to learn from all around. In particular, I love the videos where they speak about a particular service and then have an organization on stage who actually implemented it. Here’s one about finding the measurable value of cloud where they spotlight Adobe explaining how they did it using AWS tools. Also, I’ve found great content on Twitch. AWS has their own channel and posts frequently.
Vendors Built on Cloud: Vendors have massive utility and you’re 99% going to run into them and need to know how to integrate them, work with them, and support them. This will help widen the boundaries imposed by CSP-driven coursework and help you see how Cloud supports a lot more than just cloud-native services. If you’re upskilling in a role, I recommend finding something tied to work you’ll have to do or are interested in doing, or if you’re coming from the outside into a Cloud role then just find something interesting to you and go from there. Whether it’s documentation, videos, demos, workshops, or articles, dig into vendors and learn how they help businesses solve real-world problems. Here’s a video I found of Prisma Cloud for AWS in the vein of what I’m talking about.
LinkedIn: Follow a bunch of people who work in Cloud roles and post about it. You don’t have to understand half of what they’re saying when you start. As you hear more people talk about different topics, you’ll notice the same themes over and over again. You’ll hear terms thrown around that gradually make more sense. Pretty soon you’ll start making connections to what you’re learning and realize that it makes more sense. Cast a wide net and add/remove appropriately.
Podcasts: Actually hearing people talk about it makes a huge difference. There are a number of good podcasts floating around out there. CloudZero summed up a list of great ones for you. Find one or two that you enjoy listening to and just put it on while you’re eating lunch or driving somewhere. It will get you used to hearing the conversations and make everything more familiar to your ears.
There are so many other resources to consider here, but I want to emphasize something important for all of them: listen actively and passively. Do both. You’re trying to recreate the conditions you’d expect to hear on a daily basis, so make it realistic.
When you learn to listen, you eventually learn to speak. Your brain is primed to do that. It hears patterns, puts them together, and enables you to piece them together and repeat them. Use it to your advantage to help you with your overall learning.
Sorting Through the Noise - Courses
Identifying what’s good versus what is actually valuable is a task in itself.
There are a zillion Cloud courses available. Many people are well-intentioned in this department, but the standouts in this field are standouts because they’re actually helpful and provide valuable content.
Instructors
The top people in my opinion in both AWS and Azure, in no particular order:
Adrian Cantrill - AWS Courses - $40-80/per course or bundle for less
Stephane Maarek - AWS Courses - $110/per course or $21.00/month Udemy subscription
Andrew Brown - AWS Courses - $60/per course or bundle for less
Neil Davis - AWS Courses - $150/per course or Udemy subscription
John Savill - Azure Courses - Free!
James Lee - Azure Courses - $40-80/per course or bundle for less
Scott Duffy - Azure Courses - $125/per course or Udemy subscription
What sets these people apart is their willingness to provide top-level content that is updated and based on customer feedback actually gets results. This is not to deny how many great creators are out there (and I’ve likely missed some) but who I know is a safe investment for you to consider.
For organizations, it’s probably more likely that using a big training provider like Pluralsight or CBT Nuggets is an option to provide education to the workforce. While I’ve only used them for other materials (Cisco, Linux, etc.) I can see the benefit of having a more wide-ranging and flexible option like this and I view them as competitive options.
Also, there are so many free resources available to learn from. Between YouTube and the wider content creator universe, you can just google “Free X Course” and find something. I can’t promise it will always be high quality but there are definitely great contenders out there. MadeByGPS and Andrew Brown are two such creators.
Please drop any other recommendations in the comments—preferably within the budget I put above!
Starter Courses
For anyone upskilling in Cloud, I recommend a course close to the work you’ll be doing in role. Generally, I believe the AWS Solutions Architect Associate and Azure Administrator Associate (AZ-104) are the best starting point and the easiest to achieve first. They get you familiar with the CSP portfolio without overwhelming you or trying to pigeon-hole you into a niche area either.
I do NOT recommend trying to go for a niche cert as the first one, unless you have extensive experience in that discipline outside of Cloud. You’ll spend more time spinning your wheels trying to figure out what the Cloud services are than taking in what the material is actually about.
Both the AWS and Azure equivalent Associates take roughly 90-120 days to study and test for starting with minimal to no Cloud experience. For someone with familiarity, probably a lot less.
You don’t have to test. If you’re doing this to upskill, then maybe the test isn’t necessary for you. That’s fine if so. I wrote this guide to help you upskill, not test.
Lastly, whoever you decide to use and whatever course you opt for, take course notes. Make a notebook for it and write down every lesson. Don’t skip anything. Snip visuals to help you with some of the more conceptual things and create a structure for your notes that’s going to be easy to refer back to in the future.
Get Your Hands Dirty - Build Sooner
If there was only 1 thing you did on here to get better, this would be it. Using the CSP platform is the most important thing you can do to improve. Everything else is a supporting function to actually working.
Why is that?
Ultimately, you need evidence that you know what you’re doing to be able to speak about this confidently no matter what role you’re in. If you can’t at a bare minimum navigate around your console/CLI of choice, that confidence won’t set in. You need to be able to get around and build stuff.
The Learning and Hearing supports this by providing you with theory and knowledge while also giving you an understanding of applicability. That put together with hands-on practice is a strong force multiplier.
There are 3 things you need to do to get experience:
Use your own CSP account/subscription and build things. Doesn’t need to be complicated. Give yourself a task and do it, piece by piece. Document your steps. Redo it again to help cement it in your brain. Then a few weeks later, do it again to see if you’ve remembered and taken good notes. Fortunately free tier exists, so you can do this for the most part on the cheap.
Do some workshops. Workshops are nice because they have pre-built environments that would be expensive for you to build and time consuming. This will allow you to try harder things and practice using tools that otherwise might be out of reach, and get you exposure to some of the most crucial services in your CSP.
Document, document, document. This is just good practice in general, but being able to document your work will make your life 10x easier down the road when you’ll need to do it for someone else. Here’s an excellent LinkedIn article about this topic if you’re interested. A little goes a long way. Additionally, it will help cement some of the things you’ve learned in the process.
Extra bonus points if you want to go far…practice diagramming your builds. Make a simple design diagram for what you’re going to configure and build it out like you drew it. Here’s one I did awhile back for a simple VPC peering config that I ended up building in Terraform:
You’re going to have to read diagrams to learn how to make things in your CSP of choice, so it’s not a bad idea to start making them yourself to get familiar with the icons and general layout.
Outputs - Public, Private, Mentor
Hear => Learn => Build is a virtuous flywheel of effort that drives outputs for you.
These outputs go in 3 separate areas: to the public, to your private notes and documentation, and to a mentor (if applicable).
Public
This scares most people because it finally puts your name out there to be critiqued. Someone will finally be able to comment on your work. Don’t worry, almost no one is thinking of you as much as yourself!
99.9% of what you put out there will be met with either no comment at all or general support, and the occasional nod of approval. If you’re good at it, people will actually go out of their way to compliment you and will likely want to help you. So to me, that’s huge upside potential with little downside.
Your public facing persona should always reflect professionalism and be focused on helping you improve. If it’s not doing that for you, you’re spinning your wheels. The best way to go public is:
Blog about your work. This is an easy, low-bar effort that anyone can do to get started. It can be as simple as documenting a lesson, writing up a summary of something you learned, or doing analysis on a problem you solved.
Post relevant information. Share where you’re at in your new journey and find people aligned with you on your goals. Don’t force anything but make some friends and find people who can help you get better.
Collaborate. A handful of people will inevitably want to work with you in some capacity or ask you for help. Don’t be shy, help out. This could also get you experience that’s valuable.
There are many opposed to going public like this because they think it’s egotistical or attention-seeking. I strongly disagree.
The reality is that you’re an amateur, and you need practice getting up there and “playing” in front of others. The more you do it, the better you get. Soon enough you’ll be able to present on the material and sound pretty good doing it, but that only comes with practice. There are zero people who have gone far in their career without getting in front of others and presenting at some point. It would be a disservice for me to tell you otherwise.
Personally, I created multiple blogs, posted a lot of posts and articles on LinkedIn, and did as much as I could to make friends and find people to follow in the space. It wasn’t comfortable all the time, but it helped me immensely.
Private
This is no less important, but it’s for you and you alone. Notetaking is a vital skill to grow and maintain your Cloud knowledge. Can I bang this drum any louder?
Taking what you get from the Hear => Learn => Build and putting it in writing is a valuable skill to build. It will help you become a better communicator, and a better contributor.
I use my notes on a daily basis. I haven’t gone a single day at my job without looking at them. Sometimes I reference them before customer meetings, or for when I forgot about the capability of a service I don’t talk about very often. Nevertheless, my notes are there.
I have a library that covers every IT course I’ve ever taken, most of my personal projects, and for every conference recording I’ve seen. My only regret is that I didn’t take more of them. If you need help doing this in OneNote, I wrote an article back in 2020 about it. Check it out.
The most important thing is that you follow a method that works for you and allows you to continue using them for years. You shouldn’t spend more than a few seconds getting oriented to your notebook if you haven’t looked at for a while. It should all just make sense.
You will thank yourself time and time again for taking great notes. It’s high ROI, I promise.
Mentor
A mentor can make all the difference. So where to begin?
I touched on it earlier, but a mentor doesn’t have to be someone you personally meet with every week. At the beginning, it can be a person you look up to and try to emulate who has achieved what you want to achieve. I had many of these when I began. I saw people having the conversations I wanted to have in Cloud and took after them.
The mentorship I had when I started consisted of me looking at what “right” looked like and dressing off of it. I started with people like the CTO at AWS, Werner Vogels, and worked my way down. I followed Principal Architects, Senior Solutions Architects, Staff Engineers, etc. I saw the way they wrote and talked about things they were doing and tried to emulate it. Like an amateur of course, but I did.
However, there’s another half to it that I didn’t receive until later on, and that was feedback.
Fortunately, I posted a lot, so I started to get people talking to me about Cloud and eventually I found some people to talk with me about my intentions and guide me to the right place.
Getting that feedback is valuable. I won’t say it’s necessary right away because I didn’t need it immediately to be successful, but over the long-term it is. You’re bound to make more mistakes if you don’t. Although I think making mistakes is not a bad thing per se, avoiding unnecessary ones is helpful. There’s no reason to wind up doing something that doesn’t help you if you can avoid it.
If you can find someone personally from the beginning, that’s excellent. For someone upskilling in an organization, maybe a Cloud SME works with you. Or maybe you’ve run into one on your path before going to Cloud. Maybe you find them on LinkedIn and hit it off. But the “how” is less important than the fact that you actively seek mentorship in one way or another.
My Experience Using This Method
Here’s how I did it to show you a way of going about this. My method has improved since then and there are things I would have done differently now, but it is mostly intact.
I decided I wanted to be a Cloud Engineer. I booked my test date for the AWS Solutions Architect Associate in August of 2020 and passed my test in late December 2020.
I studied for minimum 2 hours a day and leveraged my free time to listen to and watch videos about Cloud. I wasn’t allocated time for it, so I found some.
Using my own method during those 4 months:
Hear
Got on LinkedIn and began following names in the space, engaged with them and read their content
Listened to podcasts including the Cloud Security podcast and CloudCast when I drove to work in the morning
Watched Re:Invent videos on YouTube during lunch and on breaks, mostly for essential services
Learn
Bought both the Stephane Maarek and Adrian Cantrill courses, ended up only using Adrian after that (Stephane was charging ~$20 back then so no big deal) (<$60)
Watched YouTube video tutorials for set up guides for most common AWS services on channels like Be a Better Dev, Serverless Guru, etc.
Bought a study guide for the SAA exam and digital books ($80)
Used WhizLabs and Tutorials Dojo for practice exams, mostly Dojo ($15.00)
Read a ton of documentation
Build
Got myself an AWS account and immediately started building with it (~$40.00 spent headed into the exam)
Used Adrian Cantrill’s provided demos included with the coursework
Leveraged AWS workshops
Used QwikLabs for convenient AWS sandboxes
Created a blog site called trobsec hosted on AWS
Built a CI/CD pipeline with SAM
Practiced building VPCs into a 3-tier architecture
Outputs
Public
LinkedIn articles and posting about what I was learning, about topics of interest, etc.
Blog articles (Trobsec)
Connecting with others at a similar level
Private
Built a note library
Documented my labs that I did for Adrian and for the DIYs
Laminated some reference sheets for me to use
Mentor
Started by looking up the CTOs and CIOs of important organizations and followed them
Looked up “Cloud Solutions Architect” and “Cloud Architect” and “Cloud Engineer” and looked for people to follow
Connected with some of them, and had some comments back and forth and the occasional message
My Study Schedule
5:15 AM: Wake Up
5:45-6:15 AM: Drive to work and listen to Podcast
8:30-9:30 AM: Morning study (watching videos, reading, LI posting)
12:00-1:00 PM: Watch videos/listen to podcasts
5:00-5:30 PM: Drive home and listen to Podcast
7:00-9:00 PM: Evening study (coursework, building, documenting, blogging)
For context I was in the Army so there were weird pockets of time available to do things. I decided to use time after our mandatory workout time and hygiene period to go back to my office or go get coffee and study. All in all, I was getting roughly 4 hours a day of exposure to the material, at least half of it passive and the other active. On the weekends, I tried to squeeze in a longer session on a Saturday evening, maybe 2-4 hours if I could.
I didn’t get it every day perfect, and there were some days I just didn’t. No excuse. But I stuck at it long enough that it didn’t matter.
Whatever you schedule is as an individual, I promise you have time to squeeze it in. A great way to identify it is to install Screen Time on your iPhone or the equivalent for Android, and see how many hours you spend scrolling. If it’s anything more than 10-20 minutes a day, you have time available to study.
For organizations trying to upskill your staff, please allocate time during the day for it. If you’re serious, you’ll understand the ROI is massive for your organization proportionate to how much it will cost.
What I’d Do Differently
Here’s a list of things I could have implemented or improved on to get better results:
Spend more time on my strategy—I started wanting to be a cloud engineer without understanding the job landscape (granted, there were no cloud roles in my organization, so I was fishing with little knowledge of what was in the lake)
Allocate time to explore vendor tools that work on AWS around certain areas of focus (storage, logging, security, etc.)
Draw diagrams as part of my documentation
Stick to a single course for study
Skip buying books until later
Be more consistent, I missed quite a few days of blogging out what I was learning
Add more variety to my consumption (more vendor integrations and tools)
Record myself teaching a topic
Find a mentor earlier on (I found some to talk to but didn’t have anything consistent)
Do more of the following hands-on exercises:
Modifying IAM policies and permissions (run into it all the time)
Using the SDK (far more versatile than ClickOps)
Using the CLI (it’s robust)
Building VPCs (more specifically the routing and services that connect them)
Integrating a vendor solution (something lightweight but on AWS Marketplace0
Connecting on-prem to Cloud (simple VPN connection, maybe try BIND DNS on-prem, on-prem identity store, etc.)
Experiment more often, be willing to play vs. build something easy to lookup
All told, it cost me < $200 (not including the exam) and that includes things I didn’t need. The ROI for me personally was extraordinary and nowadays my organization directly benefits from my knowledge. Win-win for everyone.
Conclusion
Anyone can seriously upskill themselves in Cloud in a matter of months. I did it.
Using my above method consistently for 6 months, you can become proficient at Cloud and become a better professional in the process. If you only do the certifications and practice exams, you’ll wind up with weak fundamentals and won’t be able to hold a conversation outside of exam talking points. It all has to go together.
For organizations still ruminating on whether or not to pay for and support training for your personnel on Cloud—just do it. It will only help you achieve better outcomes and potentially save you hours of headaches due to lack of knowledge or expertise.
I hope this guide was helpful to you, and if it was, please share it around. Thanks!