How to start with AWS (for beginner)?
AWS (Amazon Web Services) is overwhelming. If you’re new to AWS you’ll know the feeling of being lost and not knowing where to start. But today, We’re going to clear all uncertainties and discuss everything you need to know to start your learning journey on AWS.
AWS stands for Amazon Web Services. AWS is a range of computing products that allow you to operate tasks in the cloud, on demand. And currently, AWS have the biggest service offering of the cloud market, so you have everything from databases, to event queues, to basic website hosting.
But, AWS is designed to be quite low-level. It’s not designed for the casual website builder. AWS is built for large enterprises to build their entire business on. And for that reason, it’s not particularly easy to get started with.
Not only is AWS low-level, but there are many different services, and lots of the services even substitute each other. All this choice is only useful when you understand enough about the services and how they work.
With all these different AWS services, you might be wondering: Where do I even start? And if you are, it’s a very valid question that most newcomers to AWS have. Let me start to break down this puzzle some more so it makes more sense…
WHERE TO START LEARNING AWS?
Do you remember that I mentioned that there are three things you should focus on when learning AWS? Well now is a good time to introduce them, so let’s do that. The three areas you should focus on when starting AWS are:
- Learn core AWS services first
- Prioritise hands-on learning
- Structure your learning
Don’t worry if these seem a bit high level right now, because I’ll go through each one of them in a lot of detail. Let’s start right away with the first bullet point: learning core services first.
TIP 1: LEARN CORE AWS SERVICES FIRST
Within AWS many services are built on, or around a set of core services. But what do I mean by “core services”? And how is it possible for services to be “built on” other ones? The best way to understand how services built on one another is to take an example, so let’s do that.
In fact, just quickly, before I introduce this example let me stress an important point: try to not get too caught up on the specifics like the service abbrevations or how they work. It’s easy to get lost in these details. Just try to get the concept in your head. But — I digress — let’s get back to it.
AWS has a service called ECS (Elastic Container Service). ECS allows you to run container based services. When you run services on ECS, you can configure the host for your containers to run on. And one of the options is to run your host on EC2 (Elastic Cloud Compute). In this scenario, EC2 is the core service. And if you don’t know EC2 well, it’ll make working with ECS more difficult.
See what I mean? Once you learn certain services interacting with these other services becomes easier. Many, many services in AWS are just these sort-of periphery services which compliment and build on the others.
Which is why when it comes to learning AWS it’s really important to learn the core services first. If you spend too much effort learning periphery services you’ll struggle to see how the pieces fit together and you’ll have a much slower, more frustrating time learning AWS, trust me.
So I imagine by now you must be thinking: what are those core services? And let me get straight to the point and answer that question. The core services are: EC2, IAM and S3. But, I promised you we’d go into details, so let’s go through and understand what each of those service does, and why it’s a core service…
WHAT IS EC2?
We had to start with EC2.
EC2 is the flagship AWS product, it’s where most of AWS revenue comes from. Which begs the question, why is EC2 so popular?
Let’s start with the name: EC2 stands for Elastic Compute Cloud (I won’t get caught up discussing the terrible name). Think of EC2 as a way to run a computer in the cloud. You can launch Linux machines, or Windows machines all on top of EC2. EC2 is (literally) having a computer at the push of a button.
So why is EC2 so popular? The answer is: flexibility. On EC2 you can run many different types of workloads. You can install WordPress, to run a website. Or you can install a database and store data, all directly on an EC2 machine. In fact, nearly everything you can imagine can be ran on EC2.
But you might be wondering: If EC2 is so flexible, why don’t we run everything on EC2 and not have all these other services? And that’s a big question! The short answer though is that the other services are more focussed. For instance, you can run a database on EC2, but if you do that you’ll also need to manage it yourself. So AWS offer a service, RDS which takes away some of the headache of maintaining your own database. But guess what? AWS run it under the hood on EC2!
We could talk for a long time about EC2, but take my word for it: EC2 is very much a core service, and it’s worth your time to understand the nuances of how it works. But, we don’t only run machines in the cloud, and in AWS, we need other features such as permissions. And that’s where IAM comes in…
WHAT IS IAM?
AWS IAM is how you manage permissions and access in AWS. In order to launch your EC2 instance from before, you need to have a user that has the appropriate access to do so. And to get access you need to use AWS IAM.
But, IAM is deceptively complex. IAM isn’t only how users get access to do things in AWS, it’s also how you grant machines to talk to each other. For instance, if we look at EC2 again, an EC2 machine can be assigned a role. And that role then governs what that EC2 can and can’t do. Do you see what I mean about IAM being a core service?
So let’s say that you do start digging into IAM, what should you be looking to learn? And the answer is: understanding the different IAM objects and their relationships. Within IAM you’ve got: users, groups, roles and policies and they’re all related somehow. Let me give you an example…
A user can be in a group, and that group can have access policies which are granted to the user. But, a user can also have policies directly. Both of these approaches have pro’s and con’s. For instance, attaching a policy to a user directly means that you’ll have to update many users if you want to give them the same permissions. Understanding these nuances is key to getting your head around IAM.
