AWS is one of the most popular cloud platforms out there and is used widely. The thing is, AWS comes with 200+ services, and knowing all of them is quite a big task on its own.
But for the majority of users, they are only going to use a handful of services most of the time. The aim of this article is to give a brief idea about those services.
In case you are already a champ in AWS, then you can also use this as a quick revision.
Once you log in to your AWS account, you will see a dashboard looking like a space shuttle operating system. So many things to look at.
But trust me on this one, you are majorly going to use the SEARCH bar to navigate through different services.
On the same nav bar, you will see REGION, which is a drop-down list of regions available to choose from.
These are actual AWS regions. Assuming you created some service in Region A, then you have to select that region to work with it. If you choose any other region, that service won't show up there.
So, make sure you remember which regions you are working in.
Otherwise, it may happen that you spin up a service in Region A and completely forget about it.
But the AWS billing team will not forget it. They will still charge you for it. 🙂
Now let's start with our services.
1. IAM — Identity and Access Management
Imagine you are running a team of 20 people, including interns.
Now you want to give access to your company's AWS account to other users. Here you can't just pass down your root credentials, because then that person could potentially have full access and authority to do whatever they want.
For that, we have IAM.
IAM is used to control who can access your AWS resources and what they are allowed to do.
Here we can work with users, groups, roles and policies.
For example, I don't want an intern to have permission to manage a database. But I want them to access database logs.
So, I can assign the appropriate permissions/policies to that user or group.
Now I don't have to worry about them accidentally doing something they shouldn't.
Even if you are working on a solo project, you should avoid using the root account for everyday work and use appropriate IAM access instead.
AWS permissions can get complicated very quickly, but the basic idea is simple:
IAM = Who can do what?
2. EC2 — Elastic Compute Cloud
"Virtual servers in the cloud."
In any cloud, we need servers where we can do our tasks. It can be running something on the cloud, deploying projects, hosting an API, running a backend, etc.
These are virtual machines and AWS calls them EC2 instances.
We can create multiple EC2 instances, subject to AWS service quotas. And remember, these are billed resources; they aren't just free machines sitting there waiting for you.
If you are eligible for a free tier offer, some instance types/usage may be covered depending on the current AWS terms.
The good thing is the flexibility AWS provides.
From choosing the operating system to choosing the type of machine, storage, networking and other configurations, we get a lot of control.
These machines come in different sizes and configurations. From a small machine enough to run a simple application to powerful CPU/GPU instances for demanding workloads.
Then we can configure the storage as per our needs.
If you aren't using a free offering and your instance is billable, running the instance can incur compute charges based on the instance type and pricing model you choose.
Security Groups
Now comes the concept of Security Groups for EC2 instances.
Here we can specify which ports and traffic are allowed to reach our instance and which outbound traffic is allowed.
It works somewhat like a firewall for our instance.
For example, we might allow:
- Port
22for SSH - Port
80for HTTP - Port
443for HTTPS
And block everything else that isn't needed.
Elastic IP
The moment an EC2 instance is spun up, it can have a public IPv4 address through which it can be accessed.
Now the thing is, the public IPv4 address can change when the instance is stopped and started.
For that, we have Elastic IP.
It provides a static public IPv4 address that we can associate with an AWS resource.
But there is one important thing to keep in mind:
AWS charges for public IPv4 addresses, including public IPv4 addresses associated with resources. So don't allocate addresses you don't actually need.
Load Balancer
Imagine we have several EC2 machines running, but users' requests are hitting only one machine.
This will create issues because each machine has limited capacity to cater to users. All requests hitting a single machine can overwhelm it and the machine may eventually crash.
For that, we have a Load Balancer.
Its job is to distribute incoming traffic across multiple healthy machines according to the configured routing rules.
So no single machine has to do all the heavy lifting.
For example:
Users
|
Load Balancer
/ | \
/ | \
EC2 #1 EC2 #2 EC2 #3
Auto Scaling
Now imagine only 5 machines are being used for a project.
But suddenly traffic increases.
If the existing machines aren't enough to handle the extra requests, Auto Scaling can automatically launch additional EC2 instances according to predefined scaling policies.
And when the load decreases, it can reduce the number of instances again.
The important part is that we have to define these scaling rules beforehand.
For example:
If average CPU usage goes above 70%, add more instances.
And when the traffic comes back down:
If the load stays low, remove some instances.
The best thing about EC2 is the flexibility given to the user to create and configure their own machines.
From operating system to storage to networking and security, there is a lot in the user's hands.
3. S3 — Simple Storage Service
S3 provides a storage solution on the cloud provided by AWS.
Now we have deployed our project on EC2, but where will we store our data?
On the same EC2 machine?
No.
For that, we have S3 buckets.
Think of S3 as highly scalable object storage on the cloud.
We can manually store data in it or we can do it programmatically too.
We can store things like:
- Images
- Videos
- PDFs
- Backups
- Logs
- Application files
- Static website assets
We can also control who can access the objects using IAM policies, bucket policies, access controls and other mechanisms.
For example, an object could be private and accessible only through authenticated access or a pre-signed URL.
One important thing to remember:
Creating a bucket doesn't mean you're suddenly paying for a giant storage drive.
You are primarily charged based on things such as the amount of data stored and requests/data transfer depending on the usage and storage class.
The beauty of S3 is that it is highly scalable and designed to store huge amounts of data.
Also, the name of a general-purpose S3 bucket has to be globally unique within the AWS partition.
No two general-purpose buckets can have the same name in that namespace, even if they are in different AWS regions.
4. ECR — Elastic Container Registry
Prerequisite — Docker
Since Docker is now widely used in the development world, and it makes sense too because it makes development and deployment relatively easy.
Now, if you have knowledge of Docker, then you must know about Docker Hub.
It is a container registry where we can push and store our Docker images.
The same basic idea is provided by Amazon ECR, but it is part of AWS.
We can push our Docker images to ECR and then use those images with AWS services such as ECS and EKS.
So ECR primarily does two things:
- Stores our container images.
- Makes those images available for our AWS container workloads.
For example:
Dockerfile
↓
Docker Image
↓
ECR
↓
ECS / EKS
↓
Running Container
Same as S3, the cost is primarily related to things like storing and transferring images rather than simply creating a repository.
5. ECS — Elastic Container Service
Running an image creates a container.
Now, once the container is up and running, we need to manage it.
For that, we have ECS.
ECS is AWS's container orchestration service. It makes it easier to run, stop, manage and scale containers.
For example, imagine you have an application running inside a Docker container.
You don't want to manually log into a server every time you need to:
- Start a container
- Stop a container
- Run multiple copies
- Replace a failed container
- Scale the application
ECS helps manage all of this.
It can work with other AWS services to handle things like load balancing, service discovery and scaling.
For example, if traffic increases, ECS can run more copies of your container.
If a container fails, ECS can start a replacement according to the configuration you provide.
So instead of manually managing individual containers, ECS manages them as part of a service.
6. EKS — Elastic Kubernetes Service
Now we have ECS.
But what if you already know Kubernetes and want to use Kubernetes on AWS?
Enter EKS.
EKS is AWS's managed Kubernetes service.
If you already know Kubernetes, then much of your existing Kubernetes knowledge, YAML manifests and tooling can be used with EKS.
AWS manages the Kubernetes control plane for you, while you still get the Kubernetes ecosystem and flexibility.
So a very simple way to remember this:
ECS → AWS's container orchestration service
EKS → Managed Kubernetes on AWS
If you don't want to deal with Kubernetes and want something more AWS-native, ECS can be a simpler choice.
If your team already uses Kubernetes or needs the Kubernetes ecosystem, EKS can make more sense.
7. VPC — Virtual Private Cloud
Now we have EC2, RDS, load balancers, containers, etc.
But where do all these resources actually live?
That's where VPC comes in.
VPC allows us to create our own private network inside AWS.
We can control things like:
- IP ranges
- Subnets
- Route tables
- Internet access
- Private/public networking
- Network-level security
For example, imagine we have a web application.
We can put the application/load balancer in a public-facing part of the network while keeping our database in a private subnet.
So users can access the application, but they can't directly access the database from the internet.
A very simple mental model:
Internet
|
Load Balancer
|
Application
|
Private DB
VPC becomes extremely important once your application starts becoming more than just a simple server.
For now, just remember:
VPC = Your private network inside AWS.
8. Lambda
Okay, we talked about EC2.
But what if I don't want to manage a server at all?
That's where AWS Lambda comes in.
Lambda allows us to run code without managing the underlying servers ourselves.
For example, imagine you have an application where a user uploads an image to S3.
You want to automatically resize that image after it is uploaded.
Instead of keeping an EC2 server running 24/7 just for this task, you can trigger a Lambda function whenever a new image is uploaded.
User uploads image
↓
S3
↓
Lambda
↓
Image gets resized
AWS handles the underlying compute infrastructure and the function runs when it is invoked.
So a simple way to remember it:
EC2 → You manage the server
Lambda → AWS manages the underlying server infrastructure
Lambda is especially useful for event-driven workloads, APIs, automation and small pieces of backend logic.
9. CloudWatch
Since now we have talked about several services that AWS offers, how do we know if they are working the way they are supposed to?
How do we check if a server failed or is facing some issue?
For that, we have CloudWatch.
CloudWatch is AWS's monitoring and observability service.
It can work with things like:
- Metrics
- Logs
- Alarms
- Dashboards
- Application monitoring
We can also set alarms.
For example:
If CPU usage of an EC2 instance stays above 80% for 5 minutes, trigger an alarm.
Or:
If the number of errors suddenly increases, notify the team.
We can also use CloudWatch to monitor application logs and help developers pinpoint issues customers are facing.
So remember:
CloudWatch → What is happening with my applications and AWS resources?
10. CloudTrail
Now imagine someone created a new database.
Or someone spun up 20 EC2 machines.
Or an intern deleted an entire database. 💀
Now how do we see who did this?
For this, we have CloudTrail.
CloudTrail records activity in your AWS account, including actions performed through the AWS Management Console, CLI, SDKs and AWS APIs.
So we can use it to investigate things like:
Who created this resource?
Who deleted it?
When did they do it?
Which API call was made?
This becomes extremely important when multiple people are working on the same AWS account.
So the easiest way to remember the difference is:
CloudWatch → What is happening?
CloudTrail → Who did what?
11. RDS — Relational Database Service
Now our application is up and running.
But we don't have a database to store our data.
For that, we have RDS.
RDS stands for Relational Database Service and it is a managed service for relational databases.
We can choose from multiple database engines depending on our requirements.
We can configure things like:
- Database engine
- Instance size
- Storage
- Networking
- Backups
- Availability
- Security
The good thing is that AWS manages a lot of the underlying database infrastructure for us.
For example, instead of manually setting up a PostgreSQL database on an EC2 machine and then worrying about backups, patching and other maintenance tasks, RDS can handle many of those responsibilities for us.
One thing to keep in mind:
RDS can become a significant part of your AWS bill, depending on the instance, storage, backups, availability configuration and other options you choose.
12. DocumentDB
Need a document database?
That's where Amazon DocumentDB comes in.
DocumentDB is AWS's managed document database service and provides MongoDB compatibility.
So if you're coming from the MongoDB world, many concepts will feel familiar.
But one important thing:
DocumentDB isn't simply MongoDB running on AWS.
It is a separate AWS service with MongoDB compatibility and there are differences between the two.
For now, the simple thing to remember is:
RDS → Relational databases
DocumentDB → Document database
13. ElastiCache
You might think databases are done.
But what about one more important thing?
Caching.
Sometimes we don't want to repeatedly query our database for the same data.
Imagine your application has a popular product page.
Thousands of users are requesting the same product information.
Instead of hitting the database every single time, we can keep frequently accessed data in a cache.
That's where Amazon ElastiCache comes in.
It is AWS's managed caching service and supports caching engines such as Valkey and Memcached.
For example:
User
↓
Application
↓
Is data in cache?
↙ ↘
YES NO
↓ ↓
Cache Database
↓
Save in cache
Cache is generally much faster to access than going all the way to the database.
So remember:
RDS → Store your application's data
ElastiCache → Keep frequently accessed data ready for fast access
That's pretty much it!
These are some of the AWS services that you are likely to encounter frequently when building and deploying applications.
Obviously, AWS has a lot more services than these.
But you don't need to memorize every single AWS service before you can start building things.
Start with the services you actually need and learn the others as you encounter them.
For a quick revision, here is a simple cheat sheet:
| AWS Service | Think of it as |
|---|---|
| IAM | Who can access what? |
| EC2 | Virtual server |
| S3 | Cloud object storage |
| ECR | Docker image registry |
| ECS | AWS container orchestration |
| EKS | Managed Kubernetes |
| VPC | Your private network in AWS |
| Lambda | Run code without managing servers |
| CloudWatch | Monitoring and observability |
| CloudTrail | Who did what in your AWS account |
| RDS | Managed relational database |
| DocumentDB | Managed document database |
| ElastiCache | Managed caching |
And that's it.
I tried to keep these explanations small enough for quick revision, but detailed enough to give you an idea of what each service actually does.
Hopefully, this helps you understand AWS without feeling like you have to memorize an entire spaceship control panel. 🚀
I hope you liked it!
Top comments (0)