AWS Builder Center
What I Tell People Who Ask Me: How Do I Get Started in AWS?

What I Tell People Who Ask Me: How Do I Get Started in AWS?

A practical guide for anyone wondering how to get started with AWS. I share the simple approach I recommend to new builders: learn the fundamentals, build small projects, document what you learn, and connect with the AWS community.

Cloud Architect
One of the questions I get asked quite a bit is:
“How do I get started in AWS?”
Usually, the person asking is interested in cloud computing but is not sure where to begin. They see a long list of AWS services, certifications, videos, labs, and learning paths, and it can feel overwhelming very quickly.
My advice is usually pretty simple:
Don’t try to learn everything. Start with the basics, build something, and keep going.
I have worked in IT for more than 30 years, and I have seen a lot of technology come and go. One thing that has stayed consistent is that you really learn technology by using it.
You can watch videos and read documentation all day, but at some point, you have to get your hands on the keyboard.
Here is the approach I normally recommend.

Start With the Basics

Before worrying about advanced AWS services, spend some time understanding the basics of cloud computing.
Learn the general concepts behind compute, storage, networking, security, databases, scalability, and high availability.
You do not need to master any of these areas right away.
You just want to understand what they are and why they matter.
Once those basic concepts start to make sense, AWS becomes much easier to understand.

Learn a Few Services First

One of the biggest mistakes I see beginners make is trying to learn too many AWS services at once.
You do not need to know everything AWS offers.
Start with a few core services.
For example:
  • Amazon EC2 for compute
  • Amazon S3 for storage
  • AWS IAM for permissions and access
  • Amazon VPC for networking
  • AWS Lambda for serverless computing
The important thing is not memorizing every feature.
Try to understand the problem each service solves and when you might use it.
That knowledge goes a lot further than memorizing a long list of service names.

Build Something

This is probably the advice I emphasize the most.
Build something.
It does not have to be complicated.
Create an S3 bucket. Launch an EC2 instance. Build a simple static website. Create a small Lambda function.
The project itself is almost secondary.
The real value comes from going through the process.
You learn how to navigate AWS. You run into errors. You search the documentation. You fix something that did not work the first time.
That is where the real learning happens.
And yes, you are going to make mistakes.
That is normal.
I still believe some of the best learning happens when something does not work and you have to figure out why.

Learn Security and Cost Early

Security and cost should not be things you think about later.
They should be part of how you learn AWS from the beginning.
Learn how IAM works. Understand permissions. Use multi-factor authentication.
At the same time, pay attention to what your resources cost.
Set up billing alerts or AWS Budgets and get in the habit of shutting down resources you are not using.
It is easy to focus only on whether something works.
A better question is:
Does it work securely, and does it make sense from a cost perspective?
That mindset will serve you well as you grow.

Certifications Can Help, But Keep Building

I am a supporter of certifications because they can give you structure and help you understand AWS concepts.
For someone who is completely new, AWS Certified Cloud Practitioner can be a good starting point.
But I would never recommend making certification your only goal.
There is a big difference between knowing the answer to an exam question and knowing what to do when something breaks in a real environment.
If possible, do both.
Study the concepts and build alongside your learning.

Write Down What You Learn

This is another habit I encourage.
When you build something, write down what you did.
Document the services you used, what went wrong, how you fixed it, and what you learned.
It does not need to be formal.
You can keep notes for yourself, write a short blog post, post something on LinkedIn, or share it with your local AWS community.
One of the things I have learned over the years is that teaching or explaining something to someone else is one of the best ways to find out how well you really understand it.

Get Involved in the Community

I strongly recommend connecting with other AWS builders.
Attend an AWS User Group. Go to an AWS Community Day. Join an online community. Ask questions.
I have had the opportunity to run AWS User Groups, teach AWS sessions, and work with people at different stages of their cloud journey.
One thing you quickly realize is that nobody knows everything.
AWS is too large and changes too quickly for that.
Even people who have been working in cloud for years are still learning.
That is why community matters.
You get a chance to learn from other people, share what you know, and sometimes discover a new area of AWS that you might never have explored on your own.

Keep It Simple

If I had to boil all of this down to one simple formula, it would be:
Learn. Build. Document. Share.
Learn a concept.
Build something with it.
Document what happened.
Share what you learned.
Then do it again.
You do not need to know every AWS service.
You do not need to have multiple certifications before you begin.
And you definitely do not need to wait until you feel like an expert.
Just start.
Pick one service. Build something small.
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article