What is AWS?

Amazon Web Services (AWS) is Amazon’s cloud platform: a giant collection of on-demand computing services you rent over the internet instead of buying and running your own servers. It launched in 2006 and today offers more than 200 services covering everything from virtual machines and databases to machine learning and satellite ground stations. For most engineers, AWS is the default place to host an application because it is mature, well-documented, and has the largest community. This page explains what AWS actually gives you, when teams choose it over the alternatives, and the single biggest trap to avoid.

What AWS actually is

At its core, AWS lets you provision infrastructure with an API call instead of a purchase order. You pay per second, per request, or per gigabyte, and you can turn things off when you no longer need them. A cloud service here means a managed building block you consume on demand, such as compute (servers), storage (disks and object stores), and networking (virtual networks).

The 200+ services sound overwhelming, but the vast majority of real projects use only a handful. It helps to group them into families:

Family	What it covers	Common services
Compute	Running your code	EC2 (virtual servers), Lambda (functions), ECS/EKS (containers)
Storage	Keeping data	S3 (object storage), EBS (disks), EFS (shared file system)
Database	Structured data	RDS (managed SQL), DynamoDB (NoSQL), Aurora
Networking	Connecting things	VPC (your private network), Route 53 (DNS), CloudFront (CDN)
Security & identity	Who can do what	IAM (Identity and Access Management), KMS (key management)
Observability	Knowing what happened	CloudWatch (metrics/logs), CloudTrail (audit log)

EC2 stands for Elastic Compute Cloud and S3 stands for Simple Storage Service. You do not need to learn all of these at once. Most beginners start with EC2, S3, IAM, and VPC, then add services as needs arise.

Tip: Treat the service list like a toolbox, not a syllabus. Learn a service the first time a real problem needs it, not before.

When to choose AWS vs Azure vs GCP

All three major clouds can host almost any workload. The differences are about ecosystem fit and maturity, not raw capability.

Provider	Strongest fit	Pick it when
AWS	Broadest service catalogue, largest community	You want the most options, the most tutorials, and the biggest hiring pool
Microsoft Azure	Enterprises already on Microsoft (Windows, Active Directory, Office 365)	Your company runs Microsoft tooling and has an enterprise agreement
Google Cloud (GCP)	Data, analytics, and Kubernetes	Your work is data/ML heavy or you love Kubernetes (Google created it)

When to use AWS: choose it when you value maturity and ecosystem. There is an AWS answer to almost every problem, a Stack Overflow thread for almost every error, and a managed service so you rarely have to build infrastructure from scratch. It is also the safest default for hiring, because more engineers know AWS than any other cloud.

When NOT to use AWS: if your organisation has a deep Microsoft licensing agreement, Azure may be cheaper and integrate better. If your project is primarily large-scale analytics or you are committed to Kubernetes-first workflows, GCP can feel more natural. And if you only need to host a simple static site or small app, a smaller platform may be simpler and cheaper than learning AWS at all.

The biggest risk is cost, not capability

AWS can do almost anything, so the danger is rarely “AWS can’t”. The real danger is the bill. Because you pay for resources by the hour or second, anything you leave running keeps charging you, even while you sleep. A forgotten test server or an unattached storage volume quietly adds up.

A few examples of accidental cost:

An EC2 instance left running 24/7 instead of being stopped after a demo.
An Elastic IP (a permanent public IP address) that is allocated but not attached to a running server. AWS charges for idle Elastic IPs.
A NAT Gateway (Network Address Translation gateway, which lets private servers reach the internet) left up in a dev account.

You can see what is currently running with a quick CLI check.

aws ec2 describe-instances \
  --filters "Name=instance-state-name,Values=running" \
  --query "Reservations[].Instances[].{Id:InstanceId,Type:InstanceType,Launched:LaunchTime}" \
  --output table

Output:

-------------------------------------------------------------
|                     DescribeInstances                     |
+----------------------+--------------+----------------------+
|         Id           |    Type      |       Launched       |
+----------------------+--------------+----------------------+
|  i-0a1b2c3d4e5f      |  t3.micro    |  2026-06-10T08:14:00Z|
+----------------------+--------------+----------------------+

If that instance is a leftover, stop it (you keep the disk but stop paying for compute) or terminate it (delete it entirely).

aws ec2 stop-instances --instance-ids i-0a1b2c3d4e5f

Set up a billing guardrail

The best protection is a billing alarm that emails you when spending crosses a threshold. Do this on day one.

AWS Management Console:

Sign in and open the Billing and Cost Management console.
In the left menu choose Budgets, then Create budget.
Pick Cost budget, set a monthly amount (for example, 10 USD).
Add an alert threshold at 80% of the budget.
Enter your email address and choose Create budget.

AWS CLI (creates the budget plus a notification at 80%):

aws budgets create-budget \
  --account-id 123456789012 \
  --budget '{"BudgetName":"monthly-cost-cap","BudgetLimit":{"Amount":"10","Unit":"USD"},"TimeUnit":"MONTHLY","BudgetType":"COST"}' \
  --notifications-with-subscribers '[{"Notification":{"NotificationType":"ACTUAL","ComparisonOperator":"GREATER_THAN","Threshold":80,"ThresholdType":"PERCENTAGE"},"Subscribers":[{"SubscriptionType":"EMAIL","Address":"[email protected]"}]}]'

Output:

(no output on success; the budget appears under Billing > Budgets)

Warning: A budget alert tells you about spend, it does not stop it. AWS keeps charging until you actually delete or stop the resources. Always tear down anything you spun up for an experiment.

A cost note worth remembering: an idle Elastic IP costs roughly 0.005 USD per hour (about 3.60 USD a month) for doing nothing. Small numbers, but they multiply across forgotten resources.

Best Practices

Start with the Free Tier and a billing budget before launching anything serious.
Learn services on demand; do not try to memorise the whole catalogue.
Tag every resource (for example Project=demo, Owner=you) so you can find and delete leftovers.
Stop or terminate experiment resources the moment you finish with them.
Use a region close to your users, and stay aware of which services are global vs regional.
Never use your root account for daily work; create an IAM user or role instead.
Review the Bills page monthly so a surprise charge never compounds.