AWS DevOps Master Workshop
Zero to Production in 8 Weeks
The workshop is currently closed for enrollment.
The Master Workshop is an online, 8-Week Program that equips you with ALL of the skills needed to PROFESSIONALLY work in AWS and DevOps.
What's in the Workshop?
Development Environment for Teams

Development Environment for Teams

Set up a portable development environment for everyone

Networks on AWS

Networks on AWS

Build scalable, secure networks on AWS

Security on AWS

Security on AWS

Understand the ins-and-outs of IAM and Security

Servers, Load Balancing, and Auto Scaling on AWS

Servers, Load Balancing, and Auto Scaling on AWS

Create and manage fleets of servers on AWS

Containers on AWS

Containers on AWS

Create production deploys using Docker and AWS ECS

Continuous Integration and Deployment

Continuous Integration and Deployment

Create a lightning fast pipeline to automate your deployments

Storage and CDN on AWS

Storage and CDN on AWS

Store your content and give it infinite, speedy availability

Infrastructure as Code on AWS

Infrastructure as Code on AWS

Learn CloudFormation and start building things with nothing but text

the Master Workshop Certificate of Completion

Workshop Graduates Receive PROOF of Their Expertise

Students who complete the full workshop content, projects, and requirements recieve the Master Workshop Certificate of Completion

But what do other people think?

What Others Think:

"The workshop is absurdly good, props to you sir. I consume a decent amount of resources and this one definitely stands out. I used parts of this workshop to study for an for an SRE (Site Reliability Engineer) - provisioning job. Keep the goodness coming!"

- Sterling Houghton, Site Reliability Engineer (Nike)

"I learned even more than I thought I would in the AWS DevOps Master Workshop - seeing programming, docker, and development environments all in context of AWS was very helpful. From an engineering point of view, I enjoyed the CloudFormation and Infrastructure-as-Code sections. Fom a personal point of view - The engaging teaching style made it much easier to follow along."

- Stuart Pike, Infrastructure Engineer (Think Money Group)

"The tone and clarity of the workshop's content was great and was exactly how I'd want to progress through these topics. Whenever I'd have a skepticism around why something worked the way it did, the instructor would have an in-depth explanation ready. Maybe I got lucky, but the teaching style really matched the way I learn."

- Cara Pacifico, Quality Assurance Engineer (SimpliSafe)

"The workshop is very good, you get to know and understand from the basics. Coming from a non-networking background it helped me to understand the different components and their connections. The separation of How-To's and the Why videos makes it easier to come up with the reasoning of why we do certain tasks in the workshop. The teaching analogies to real life concepts give a good perspective to visualize what we are trying to build - especially the building of a city relating to the VPC, subnets, Gateway, Router table, NACLs and the space analogy for the Docker concepts. The final test helps to recap and pull the learning from the workshop together."

- Inthrakumar Palanivel, Senior Technical Architect (Hexaware Technologies)

"I'm a developer who wears many hats, and especially over the past year or more I've been getting into DevOps and managing my AWS environment. I've consumed several other AWS resources/courses, but they are usually tailored to a single AWS service at a time. I appreciate you taking the time to bring several AWS services together. It's easy to follow along."

- Alexander Bihary, Senior Software Engineer (Syndigo)

"I have enjoyed the workshop very much. I am teaching a web module to our final years, so I will be using a lot of knowledge gained from your workshop for that. I find your style and pace clear and easy to follow."

- Dr. Torbjorn Dahl, Associate Head for Computing (University of Plymouth, UK)

"The workshop is a savior. Learning new technologies is like learning calculus when everything's in French. When you find guidance in English, it's golden. I really like the way you link to the docs. You present the material to a good level of depth, but there are times, as a student, you need to dig deeper. Having links to relevant documentation really helps."

- Andrew Meyer, Senior DevOps Engineer (

Trusted by Engineers From:

What else do you get?

A master stack and toolchain for usage in any professional product or project.

85% of all jobs are filled via networking. Workshop enrollees get free membership into our private community of seasoned engineers.

The ULTIMATE step-by-step to out a professional infrastructure in AWS

Why do the AWS DevOps Master Workshop?

Everyone's background, upbringing, goals, and experiences are different. So instead of me sitting here rambling off every nuance, let me tell you what I do know - why this workshop, and what it teaches, has worked for me and other people.

The Origins

In early 2015, I was bouncing back from a string of failures. One startup in particular, that I'd put together while working full time, had just failed entirely. And this wasn't some random shower idea... it was something that I'd been set on for a couple of years. Something that I thought was "what I was meant to do." (If you're interested, you can hear more about it here).

Nearly 2 years of trying to work full time while juggling these side projects was getting to me. I don't think I'd ever felt burn out so hard. And one of the largest side effects of these projects? I hadn't been keeping up with the latest trends in technology. Sure, I continued to get better at what I did know, but that only takes you so far.

In mid 2015 I joined a startup that was solving employee wellness. I figured, "hey, maybe it'd be better to learn from some experienced founders," and decided to make the move. This startup had it all. The founder was extremely experienced, we had over a million in financial runway, the product's problem space was exceptionally noble, and the team? Not only were they incredibly talented but we formed such deep bonds with each other that we still keep in contact to this day.

The founder made the decision to put the engineering entirely in our team's hands. We got to choose what we'd work with. So we chose what we wanted to work with: Angular 1.x; Ruby on Rails 4; CoffeeScript; and Rackspace (the managed servers, before their cloud solution).

A large part of what drove those decisions was simple - it was what we knew and it was what was comfortable. At the time, it seemed like an incredible decision. We were extremely productive and chopped through features and bugs at light speed.

The end of the year came and the whole company took an amazing getaway out to Manly, Australia. We had an incredible AirBnB and a full week of time to just get to know each other, chop through even more work, and enjoy the success we were having. I don't think I'd ever had so much pride in the company that I worked for. I remember on the plane ride sitting next to one of the Atlassian Product Managers. Up until this point, I'd always defined myself by whatever startup I was in pursuit of, but that time I introduced myself as an engineer from this company.

And then December came and things got weird. A company decided to sue us over trademark infringement (apparently near names are close enough...). Things got scattered and the founder starts going silent.

January comes around and we get the word - the company is closing down. We don't get much more than that either. Aside from the "sorry, but this is the end" and about a weeks worth of pay, all that was left was radio silence and another failed startup on all of our resumes.

But there was another major problem. If you were around in early 2016 then you KNOW that Angular 1.x, Rails, CoffeeScript, and Rackspace were pretty much dead. Everyone wanted microservices. Everyone wanted Node. Everyone wanted React. And so here's our whole team with probably the worst position we could be in - having outdated skills.

So we all start retraining. One goes Python. Another Objective-C. Another Rails 5. Another React. And months pass. Months and months of us bouncing job applications between each other while learning on the side and encouraging each other through our little slack channel we kept in contact with.

Though I was proficient in JavaScript, I knew that the path before me was not an easy one. I needed to learn React. I needed to deepen my knowledge in Node. I needed to pick up cloud computing. I needed to step into the modern web scene.

This search cost me nearly every penny of my savings. At one point my partner and I had to go crawling back to our families to help us out, but since neither are from well-off backgrounds... well... it just barely helped. If you've never been in that situation before, I envy you. Because everything becomes an argument. Hard times make everything hard.

But we make it. I get a job that I wasn't quite qualified for because the company looked past my immediate skill set and instead looked at my general experience. It took nearly 60 interviews, but I was alive.

I think at this point, most people would be happy, but I remember coming out of my home office and angrily declaring:

"Never again."

Never again am I going to let this happen.

The Stack

"How can put together a skill set that doesn't need to be relearned every few months?"

That was the core mindset I had when I went to figure this stuff out. I had no intention of teaching it. I had no intention of making it into a company. I just wanted to NOT retrain every few months. I just wanted something that would last.

First was to figure out the application stack. I'd made the mistake FAR too many times of just picking based on Github stars, popularity, or quick-start convenience. I'd given far too much attention to the loud advocates that would go haywire if you mentioned something other than what they used.

And so I decided to go all in with JavaScript. Both for the front and the back. And even for scripting.


A lot of enthusiasts out there will jump at how X language is the next thing, or Y language is more elegant, or Z language is the world's savior. But my logic was simple:

As long as JavaScript is the only scripting language in browsers, it will be king of the web.

Until browsers start shipping with a different scripting language, JavaScript isn't going anywhere. And even if they do? I'd still wait 10 years before switching, because it'd be missing battle tested frameworks, proof of performance from companies, and community knowledge. (*cough* Dart *cough*). Not to mention it's about 100x easier to find someone who knows JavaScript... since everyone has to use it.

With that out of the way, Node was the only option for the server side. And so that was simple enough. Based on an engine by Google. Supported by nearly every company. Huge track record. Easy peasy.

Next came the front-end framework. This was probably the most annoying, because it seems like every year there's a new kid on the block who can solve all the problems. And it also seems like every year an older player, who appears rock solid, would evaporate. I'd experienced it with Backbone. I'd experienced it with Angular.

But there was a subtle clue about Angular 1.x that everyone should've seen coming. It wasn't used in any major products inside of Google. The best they could show was that it was being used for YouTube for PS4. HA. And other than that, it was just a bunch of different companies left and right that I'm not sure anyone knew of. And if a company isn't using its own damn framework for its SERIOUS and CORE products? Why the hell would I? (and yet, I did use Angular 1.x haha)

And so I went with React. Here was something backed by a big company... AND USED by the company. This was such a huge win, and it's turned out well. Since making that decision, I haven't had to learn another framework. Every time they make a huge update, they do so without breaking every past pattern they've come up with...unlike Angular.

As far as hosting, scalability, and network? That choice was pretty straight forward. One of the best engineers I've ever worked with sold me on it indirectly. We were having a converstion about the infrastructure setup he was using and this guy just LOVED it. He loved being able to automate things. He loved not being kept up until 3am wondering if a feature was going to cause a crash. AND he tells me...

"And it's not going anywhere. At least not until I'm out of the tech scene."

With that, AWS became my choice for infrastructure.

There was still one more problem though. I'm a person who juggles and launches many projects. And if you're doing this all on one machine? You environment gets messy REALLY fast. It's probably the best way to make sure that it doesn't work on your servers when you push them up. I also hated the idea of developing on a remote server full time, because though it can be cleaner, it's more costly and honestly kind of ridiculous. I just want to sit down and work on my code.

Docker became the solution here. Clean separation of application stacks. Incredibly easy deployments. One-to-one translations to other machines. Tons of tooling and community support / knowledge.

These 4 things became the heart of The Stack.

The Workflow

But just having these technologies in hand wasn't enough. There was one more critical piece that almost always gets overlooked: a productive workflow.

One of the most CONFUSING onboarding experiences I ever had was at a midsize company on an engineering team of 8 developers. I come on board, and I'm ready to start coding, and the first thing they do is give me list. This list has about 30 different technolgoies on it. And they tell me, "Just go through each one of those and put, on a scale of 1 to 10, how comfortable you are with each of them."

I do the whole thing. I know some of them. Others no so much. But I finish it, and the onboarding engineer looks through the list, sighs, and then says, "okay, we'll set your work environment up tomorrow."

Tomorrow became a week's worth of set up. This company's application was so confusing, that every time they'd set up someone's work environment, they'd have to do the whole thing custom. There were so many moving parts ... and because all of it depended on direct installs to the machine itself (as opposed to something like Docker), everyone's case was different. Some people would fail at the database part. Others the networking. It was crazy.

The sad part is - that's the way it is for a lot of the companies. You come in and they have this rain dance you have to complete just get the main page live. And then when you go to deploy? HAHAHA. Yeah right. It becomes this ritualistic gathering of the developers where everyone's praying that the testing pipeline stays green.

That's not what I wanted. I wanted an EXTREMELY simple workflow:

Write Code -> Push to Github -> Deploy to AWS

And that workflow needed to involve two other critical factors:

1. Extendable to more team members

In the 2018 Stack Overflow Survey, 70% of developers said that they expect a new team member with 4 years or relevant experience to take anywhere from 1 month to a year to hit full productivity. Sound about right? Sure, some of it's always going to just be getting familiar with the craze of being in a new place and learning a new app.... but things like your development environment and infrastructure DON'T have to be a circus.

Because I knew that I'd want to work with others in future projects of my own, this was a key. I wanted a development environment that was protected from my machines own local dependencies, easily transferred to other machines, and EASY FOR PEOPLE TO SET UP AND START CODING.

2. Control of the Infrastructure

I've got a pretty big write up on why I don't use PaaS anymore, so I won't go too much in depth. But for me, CONTROL was critical. To extend my infrastructure. To contract it. To add different services to it. To make sure that it could be what I needed it to be. This was equally as important.

This went beyond just convenience - it was SECURITY. Not just security of the technology, but security for myself. Security in knowing that I understood modern cloud computing for any future job. Security in my mind that would let me sleep knowing that I don't have hundreds of blackboxes that may or may not be breaking.

The Result

The result is THE STACK I now teach in AWS DevOps. It took me almost 2 years to refine and solidfy the Stack. And it took even longer to learn all of the knowledge I needed to get it done. The hoops that I had to jump through and the miserable documentation that I had to consume... well, let's just say I'm never getting that time back.

But the results have been worth it. In my personal life I went from struggling to find a job in 2015, to Senior FullStack Developer in 2016, to Lead Engineer in 2017, to being able to quit my job at the end of 2018.

Throughout this journey, I was able to use and implement this Stack professionally which further refined it. And when I started teaching it in 2017? It got even better. By helping so many developers learn it, it grew even more powerful through their feedback.

Since then it's gone on to help out all sorts of people in companies both large and small. From solopreneur ventures all the way to major companies. From independent contractors to high-powered unicorn startups with millions in funding and traffic. From curious learners to University classrooms. It's flattering really to see people say the things that they do...

How the Workshop is Structured

Unlike most programs, bootcamps and the like, we don't just dump you into the deep end. We also don't narrate documentation like a drone. I've taken enough of those miserable courses and read enough of the official documentation to know that doing so results in ... insanity?

The first Udemy course I ever bought was something on Nginx. The instructor, who was well-intentioned, just didn't know how to teach. I know that having been a certified master tutor of Economics probably makes me biased...but I was half-convinced the guy was trying to cast a sleeping spell. Not to mention that most of the course was just him reciting documentation.

On the other hand, sometimes you find a great resource - but the content is outdated. And so you get really deep into learning and you're ready to try it out... and then you realize that everything is different now.

Because of this, each module in this Workshop has two components:

1. The "How to"

2. The "Why"

The "How To" is the raw steps that show you, with light explanation, everything to get the Stack up and going now. The great part of my Stack is that once you've got it under your belt? It only takes a couple of hours at most to get it set up (though I can do it in about an hour).

Because of this, before each new set of members come through, I update the "How To" sections. This way the consoles you see, the frameworks you work with, and the steps you take are all up to date. The really awesome part is that once you enroll this workshop, you get lifetime access. So every time I update the "How To" you're right up to speed.

But we both know that blindly following steps doesn't get us anywhere in the long term. And so the "Why" videos are split out separately. In these we walk through WHY we make the decisions we do. WHY we push the buttons that we do. WHY we write the scripts as we do. This is the real meat that empowers you to improvise and mold the Stack to your own needs.

Finally, each week we do live question and answer with current members. We dive in and I'll answer any and every question that students have. And if there's a recurring question that's big enough? Then I go and make a video for it, put it up, and you have full access to that for life as well.

The end result? An evergreen stack that you can always use. Something that's always up to date. And if you ever get out of touch or behind? You just log back in, watch the "How To" videos and you're off to the races.

Who's Teaching

My name is J. Cole Morrison, but you can call me Cole. I've been in the startup and engineering scene for the past 10 years - as a founder, lead engineer, senior developer, and educator. I've built, or been a part of teams that have built, everything from real-time social networking apps for small communities, all the way up to internet-of-things platforms that deal with millions in traffic monthly. And I've also been fortunate enough to work with some of the best entrepreneurs and developers in the industry.

Ever since starting AWS DevOps, I've had the privilege of working with, teaching, and consulting over 5000 engineers and entrepreneurs. I've helped all types - solo ventures with just a burning idea, professional engineers in household name companies, and high-powered startups with tens of millions in funding. And what I teach? It works for all of them.

But this was not where I began.

Out of college I was on track to work in insurance for Northwestern Mutual. My education had been in Economics and Marketing. All of my extracurriculars revolved around getting into the big machine and staying there. And if I wasn't doing those, I was working a job, tutoring economics, or playing in my 'okay' college rock band.

At one of the business school celebrations for scholarship holders, one of the biggest donors, Brant, gave his speech. This guy had dominated the business world and was giving back to the school that had helped get him there.

After the celebration died down, I saw Brant walking to his car with his older father. So I slipped away from my parents, ran out, stopped him and said "Hi Brant, my name's Cole Morrison. I go to the school of business and I loved your speech. I was wondering if we could meet up some time, I'd love to pick your brain. You seem like you know what's up."

Honestly, I was probably being a little cocky, but he seemed to like me. So he indulged and we met up at his favorite spot in Louisville - Amici. A cozy little Italian restaurant that, to this day, is probably still an undiscovered gem.

During the meeting we talked about all sorts of stuff. His journey through corporate America. His rise to vice president in his business. His systematic way of managing people. The whole time I'm scribbling notes left and right trying to keep up while he's happily eating his meal and recalling all sorts of experiences.

The whole time I'm just fascinated. Here's a guy that seems to get it. Here's a guy that knows what's up. And so the lunch comes to an end and I ask him, "So Brant, what's the biggest piece of advice you think a college kid should know?"

Brant gets quiet, stares off into the distance, and then looks at me with an intensity that I didn't expect. He says, "Start your own thing. Don't work for other people. They'll always dangle a carrot in front of you and you'll never get it."

I really didn't know what to say. This person, one of the biggest names in our school of business, was telling me not to do what he did. And the advice stuck. The shock stuck. More so than I think than he intended.

About two weeks out from when my insurance training began that advice really started to germinate. Between what he'd said AND my mentor being one of the professors of entrepreneurship, things just didn't seem like they were going right. I had a massive anxiety attack during one of my study sessions for the training and decided, that night, that I wasn't going to do it. I called up my representative the next morning and told them I wasn't going to be attending training.

And why? It wasn't just entrepreneurship. But I grew up taking a part computers and putting them back together. Surfing the web and making goofy little websites when I was in middle school. Remember A+ Certifications? Remember Visual Basic? That's what I was reading in high school. And so between all of my influences and past history, I decided I was going to get into software and do a startup, or at the very least join one.

And so, much to my family's disappointment, I started learning software on my own. I was taking all of that education I'd invested in... and throwing it down the drain. And it was tough path. You know how the education resources are out there. They're just barely tolerable. Monotone speakers. Crappy hello world examples. And tons of "you shouldn't do this in production" statements. Most of the time it felt like searching for a needle in a haystack.

But here I am alive and well. Despite my lack of traditional training, I've had a great career in software. I've met so many great individuals and had so many opportunities. I've been in so many hard times and faced a lot of conflict. But I wouldn't take any of it back. Otherwise, who knows where I'd be. Who knows if I'd have the chance to help developers like yourself?

I never met with or saw Brant again. And I never got to say thank you for the advice. It turned out that he'd moved back because of health problems and I later figured out that he passed away a little under a year after we'd met. But it did teach me something important - kindness and guidance at the RIGHT time from the RIGHT person can change your life, stranger or not.

-J Cole Morrison

What is adding AWS to your skill set and becoming an EXPERT worth to you?
Zero to Production in 8 Weeks
The workshop is currently closed for enrollment.