aws about graphic
Amazon Web Services closed out 2020 with more than $13.5 billion in annual operating profits... AWS is arguably the most profitable, important, technical technology company in the world.

AWS has a lot of services. Here's a brief guide to understanding how they work.

First, you don't have to learn every service. Even people who work at AWS can't name every service. It isn't that kind of business, where you need to know every single thing they offer for every specialized use case.

I think of AWS as being like a hardware store.

In a hardware store, it would take a long time to wander down the aisles and inspect everything on the shelves. As a buyer, you go in with an idea of what you want, and then you go straight to the area that sells it.

AWS is like that too.

For overview purposes, it's helpful to cover the biggest services, and also the ones that an independent developer would most need.

It's also the case that you usually don't use one, and only one, AWS service ("that's how they get you," as the expression goes). You use several, in conjunction. Famously, you only pay for what you use.

From their webpage:

aws value

For now, let's start at the top, the very top, and then work our way down.

EC2 and Related Services

EC2, or Elastic Computer Cloud (Elastic because you can create more or less of them, as you need), has a whole ecosystem around it, since you can use it in combination with so many other services.


The biggest moneymaker is EC2. Most other services pale in comparison to it - or don't even register.

These are virtual servers. You 'spin up', or start, individual ones.

Running an EC2 server is very DIY, or do-it-yourself. You should know that, if you decide to run one.

You pick the size you want (pay special attention to memory), you pick the operating system, set some other configuration options(there are many), and when you've approved your choices, it starts up, with a small charge by the hour. As long as it's running, you're charged. If you don't want it anymore, you destroy it.

Anything a server can do, EC2 can do. A classic use case for EC2 would be setting up a web host.

If you're a JavaScript developer, you might install node on your server. You then upload your web app to the right directory. You install Nginx, and configure it. Presto - your site is up and running.

You can configure your EC2 instance to maximally server your needs: it's a computer, in the cloud, that's yours, as long as you run it. The downside is that you're also responsible for every aspect of this to run correctly (the DIY part).

As AWS itself will tell you, you can't expect EC2 instances to run forever. In fact they recommend you have some kind of strategy in case it stops running - say, because it fills up with logs, or becomes unreachable. It's wise to think about this before you start your app, to have more than 1 server or backup plan in case something goes wrong.

If node stops running, your server goes down. If the server fills up with logs and crashes, your server goes down. If Nginx generates a serious error due to bad configuration, your server goes down.

There are multiple reasons why your server, and web app, could go down - so monitoring, and alerting, can help. Of course, AWS has services to help with this also.


A service often used with EC2 is EBS - elastic block store - basically the storage, or 'hard drive', on your EC2 instance.

You pick the amount of storage on your hard drive, you 'attach' it your instance during the setup process, and now you have a computer, with a lot of space if you need it, in the cloud. If you want to detach the hard drive and use with a different EC2 instance, you can do this too.


Another 'combination' service you'll often use with EC2 is Amazon's Virtual Private Cloud, or VPC.

If you started up a few servers, VPC is how they would communicate with each other.

Load Balancer

Yet another is Load Balancer, to send traffic between your servers.

Basically it's like this. Say you set up an EC2 server, to host your website. But as AWS itself will tell you, you shouldn't count on a single server to run forever, without errors.

What if your server stops running? What if it gets too much traffic, and still runs, but at an unacceptable slow rate?

This is where Load Balancer can help. You set up rules to direct traffic - maybe based on location (example, European users get sent to a server located in Germany, to reduce latency). If one of your servers 'falls over', or stops working, you direct traffic to one of your other servers, through this.


There's also S3, once described as the 'crown jewel' of AWS. This is for storage - images, videos, even web files.

One thing that makes S3 impressive is its incredible availability: it's almost always (like 99.99% of the time) up and running.

So when you put a thing on S3, unlike EC2, you can almost be sure it will run forever.


Next up, databases.

This is a big topic, and AWS has a huge range of options here: almost anything you want, they can do.

I use DynamoDB myself, for most of my DB needs. It's a NoSQL database that operates like most these do, in a standardized way, that I usually communicate with through an API.

I also use Route 53, their Internet routing service. You know how you type in "" in your browser address bar, and that takes you to whatever is hosted on Google's servers?

That's the same function Route 53 does.

For authorization - another important topic - there's Cognito.

Related to that is Amazon IAM, for Identity and Access Management. When you want to adjudicate what servers can access which resources, IAM is how you do it.

What this means is that, if you have an app, and people sign up with a username and password, that all needs to be stored somewhere. That somewhere is Cognito.

Managing users, adding users, subtracting users, adding policies and privileges for what users can do - that's Cognito.

Cloudwatch is for logs, so that's one you'll see, and interact with, too.

These are the heavyweights, from my indepdendent developer's perspective.

Normally, you would use many of these in combination.

Other notable heavyweight services would be ECS, Amazon's container service; Amazon Glacier, for long-term storage; Amazon SNS, for messages; and Amazon SQS, their queueing service; and Elasticache, if you need a cache.

The picture below shows a pretty plausible combo you would expect to find a modern-day startup - say, a Bay Area SaaS company.

aws diagram

Beyond this, there are many hundreds of services, too many to list here. AI, gaming, workspaces, even video calls... AWS has a service, and a solution, for it.

Of the many smaller services, I'll mention two.

One that gets a lot of press is Lambda, a 'serverless' service. Basically instead of running an EC2 service, yo just upload some code, and Amazon handles the rest.

While Lambda hasn't yet been adopted universally, it's seen as the wave of the future, and one to follow.

Another useful service is Elastic Beanstalk, which gives you more control over your server, a kind of halfway point between running and configuring everything yourself and 'serverless'. You pick the language and server type, and AWS does the rest.

And that concludes our tour! Now you know a little bit about AWS. Hopefully this will help you in your journey.