What you'll learn
Quick Answer
EC2 is a virtual machine, S3 is file storage, RDS is a managed database, Lambda runs functions without servers, IAM controls permissions, and VPC is your private network. Set a billing alarm before creating anything.
Do this before anything else
Three steps, in order, before creating a single resource.
1. Set a billing alarm. Not optional. Configure an alert at a low threshold — a few hundred rupees — so you find out about a mistake in hours rather than at the end of the month. AWS does not stop service when a bill grows.
2. Stop using the root account. The email you signed up with is the root user and can do anything including closing the account. Enable multi-factor authentication on it, create an IAM user for yourself, and use that.
3. Never put access keys in code. Committed AWS keys are found by automated scanners within minutes of reaching a public repository, and are used to run up enormous bills. If it ever happens, deactivate the key immediately — see secrets management.
These three prevent essentially every serious AWS accident students have.
EC2 and S3
EC2 is a virtual machine. You pick an operating system image and an instance size, and you get a server you connect to over SSH. You are then responsible for everything on it — updates, web server, firewall rules, monitoring.
Key concepts: an instance type is the size, a security group is a firewall around the instance, an AMI is the base image, and an elastic IP is a fixed address. Two common gotchas — a stopped instance keeps billing for its storage, and its public IP changes on restart unless you attach an elastic IP.
S3 is object storage: you put files in a bucket and get a URL. It is not a filesystem — there are no real directories, and you cannot mount it and edit files in place.
It is the right home for user uploads, images, backups and static site files, and it is exceptionally durable and cheap.
The one thing to be careful about: bucket permissions. Public S3 buckets are among the most common causes of real-world data leaks. Default to private and grant access deliberately.
RDS and Lambda
RDS is a managed relational database — PostgreSQL, MySQL and others. AWS handles backups, patching, replication and failover, and you get a connection string.
The reason to use it over running a database on EC2 is that database operations done properly is a specialist job. Tested backups, point-in-time recovery and failover are exactly the things people intend to configure and never do.
Note it is not in the free tier forever, and it is one of the more expensive services to leave running.
Lambda runs a function in response to an event without you managing a server at all. You are billed per invocation and per millisecond of execution, and it scales automatically from zero.
exports.handler = async (event) => {
return { statusCode: 200, body: JSON.stringify({ ok: true }) };
};Excellent for scheduled jobs, image processing on upload, and lightweight APIs. Less suitable for long-running work or anything needing a persistent connection — see serverless explained.
IAM and VPC — the two people skip
IAM controls who can do what. It is the most important service on this list and the least fun to learn, which is why it is usually configured badly.
Policies are JSON documents granting specific actions on specific resources. The principle to follow is least privilege: grant exactly what is needed. The tempting shortcut — granting full administrative access because a permission error is blocking you — is how a compromised credential becomes a complete breach.
Use roles rather than keys where possible. An EC2 instance with an attached role receives temporary rotating credentials automatically, so there is no long-lived secret to leak.
VPC is your private network — subnets, routing and firewalls. The important idea is public and private subnets: your web server sits in a public subnet reachable from the internet, and your database sits in a private one reachable only from inside the network.
A database with a public address and a weak password is found by scanners quickly. Putting it in a private subnet removes that entire risk.
A realistic learning path
Do not attempt breadth. Deploy one thing properly:
- Set the billing alarm and create an IAM user.
- Put a static site on S3 and serve it through CloudFront, so you meet buckets, permissions and the CDN.
- Launch an EC2 instance, connect over SSH, and run a small application — this teaches security groups and Linux administration.
- Add an RDS database in a private subnet and connect the application to it.
- Write one Lambda triggered on a schedule.
Delete everything afterwards, and check the billing page a day later to confirm nothing is still charging. Orphaned volumes and elastic IPs are the usual culprits.
That sequence takes a weekend and covers more than most certification study, because you will hit real permission and networking errors and have to resolve them. For interviews, being able to say "I deployed X with a database in a private subnet and here is why" is worth considerably more than a list of service names.