What Is AWS? A Practical Introduction

Amazon Web Services is the largest cloud provider on the planet, and the chances are high that whatever software you build in the next decade will touch it somewhere. This post is a calm, practical introduction to AWS — not the marketing version, but the mental model an engineer actually uses to find their way around.

The market share story (briefly)

AWS launched in 2006 with S3 (object storage) and EC2 (virtual machines), at a time when most companies still bought servers, racked them, and waited eight weeks for them to arrive. The pitch was simple: rent compute by the hour, pay for what you use, scale up or down whenever you like.

It worked. Today AWS holds roughly a third of the global cloud market — more than Azure, more than Google Cloud. Its scale shows up in two practical ways:

• The service catalogue is enormous. Last count, over 200 distinct services. Most projects use a dozen at most.
• There is a lot of documentation, tutorials, and StackOverflow answers. Whatever problem you have, someone has hit it before.

The downside of scale is that AWS can feel overwhelming. The trick is to ignore the 190 services you do not need and focus on the dozen that do real work.

The four-bucket mental model

Almost every AWS service falls into one of four broad buckets. If you remember this, the console map becomes much less scary.

Compute. Things that run code. EC2 (raw virtual machines), Lambda (serverless functions), ECS and EKS (containers), Fargate (containers without managing servers), Lightsail (simple VMs for beginners).

Storage. Things that hold bytes. S3 (object storage, the workhorse), EBS (block storage attached to EC2), EFS (network file system), Glacier (cold archive).

Database. Managed databases. RDS (relational — Postgres, MySQL, etc.), DynamoDB (NoSQL key-value), Aurora (AWS’s own MySQL/Postgres-compatible engine), ElastiCache (managed Redis and Memcached), OpenSearch (search/logs).

Networking. How everything connects. VPC (virtual private network), Route 53 (DNS), CloudFront (CDN), API Gateway, Load Balancers (ALB, NLB), Direct Connect (private link to your data centre).

There are other categories — security, analytics, machine learning, IoT — but compute/storage/database/networking covers the daily reality of most applications.

Quick definition. A service in AWS is a discrete product (S3, EC2, Lambda) with its own API, console page, and pricing model. Services compose: a typical web app uses Route 53 for DNS, CloudFront for the CDN, S3 for assets, ALB for load balancing, ECS for the API, and RDS for the database.

Regions and availability zones

Two terms shape every AWS architectural decision.

Region. A geographic area — us-east-1 (Northern Virginia), eu-west-1 (Ireland), ap-south-1 (Mumbai), and so on. There are over 30 regions today. Each region is fully independent: data does not flow between regions unless you explicitly arrange it.

Availability Zone (AZ). A logically separate data centre within a region — usually three per region, named things like us-east-1a, us-east-1b, us-east-1c. AZs are close enough for low-latency communication but isolated enough that a fire in one will not take down the others.

The everyday rule: deploy across multiple AZs in one region for high availability. Deploy in multiple regions only when you need geographic redundancy or to serve users far from the original region.

Region choice matters in mundane ways too:

• Latency. Pick a region close to your users.
• Cost. Prices vary by region. us-east-1 is generally the cheapest.
• Service availability. Newer services launch in some regions first.
• Compliance. Data residency laws may require specific regions.

For learning and side projects, us-east-1 (Virginia) is the default — cheapest, biggest, every service available, most tutorials assume it.

The free tier

AWS offers a generous free tier that lets you build small things at near-zero cost. It comes in three flavours:

Always free. Forever, with no expiry. Includes 1 million Lambda requests per month, 25 GB of DynamoDB storage, 10 GB of CloudWatch metrics, and several others.

12 months free. Available for the first year after you create your account. Includes 750 hours of t2.micro or t3.micro EC2 per month (enough to run one small server 24/7), 5 GB of S3 storage, 750 hours of RDS, 100 GB of CloudFront data transfer per month.

Trial offers. Short-term credits for specific services — SageMaker, Lightsail, RDS Aurora.

The free tier is genuinely useful for learning and small projects. The catch is that it is per-account, the limits are easy to exceed by accident, and a few common services (NAT Gateway, anything sending lots of data out of AWS, large RDS instances) are not on it. Always set a billing alarm the day you create your account.

# In the AWS Console:
# 1. Go to Billing → Billing preferences
# 2. Enable "Receive Free Tier Usage Alerts"
# 3. Go to CloudWatch → Alarms and create a billing alarm
#    e.g. notify me if estimated charges exceed $5

That five-minute setup has saved many beginners from a surprise hundred-dollar bill.

IAM first, always

If you remember one piece of advice from this entire post, make it this: never use your root account for daily work, and always use IAM.

When you create an AWS account, you get a root user — full power, can do anything, can shut down anything. The root user should be locked away. Enable MFA on it, write the password in a password manager, and never sign in as root again unless absolutely necessary.

For day-to-day work, create an IAM user for yourself with only the permissions you need. For applications, create IAM roles that EC2 instances, Lambda functions, or containers assume — never bake long-lived access keys into code.

The vocabulary:

• User. A human (or sometimes a CI system) with credentials.
• Group. A collection of users with shared permissions.
• Role. An identity that AWS services or other accounts can temporarily assume. Used everywhere in production.
• Policy. A JSON document granting specific permissions (e.g. “read this S3 bucket”).

A simple, well-scoped policy for reading one bucket:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::my-bucket",
        "arn:aws:s3:::my-bucket/*"
      ]
    }
  ]
}

The principle of least privilege — grant the smallest set of permissions that gets the job done — is not pedantic; it is the difference between “we had a security incident” and “we had a near-miss.”

Talking to AWS

There are four main ways to interact with AWS:

The Console. A web UI at console.aws.amazon.com. Friendly for exploration, error-prone for repeatable work.

The AWS CLI. A terminal tool that wraps the same APIs. Install it and configure credentials once:

# macOS (Homebrew)
brew install awscli

# Configure with an IAM user's access key
aws configure

# Test
aws sts get-caller-identity
# {
#   "UserId": "AIDA...",
#   "Account": "123456789012",
#   "Arn": "arn:aws:iam::123456789012:user/yourname"
# }

SDKs. Libraries for every major language (boto3 for Python, aws-sdk for JavaScript, etc.) that call the same APIs from inside your code.

Infrastructure as code. Tools like Terraform, AWS CloudFormation, and AWS CDK describe infrastructure in version-controlled files and apply changes idempotently. Once a project grows past a handful of resources, IaC is essential.

For learning, use the console and the CLI side by side. The console teaches you what exists; the CLI teaches you how to script it.

Key services to start with

If you are new to AWS, focus on these eight. Together they cover an enormous range of real applications:

1. S3 — object storage, the absolute basics of cloud
2. EC2 — virtual machines, still the workhorse of compute
3. RDS — managed Postgres or MySQL, instead of running a database yourself
4. Lambda — serverless functions, great for event-driven work and cheap APIs
5. CloudWatch — logs, metrics, and alarms
6. IAM — users, roles, and policies (already covered above)
7. Route 53 — DNS, including domain registration
8. CloudFront — CDN for static assets and global distribution

Master these and you will be productive on most projects. The other 190 services can wait until you have a concrete reason to learn them.

What AWS is not

A few clarifications worth getting right early.

AWS is not free. The free tier is excellent for learning, but real production workloads cost real money. Bills can also surprise you — data transfer out of AWS, NAT Gateways, and large EBS snapshots are the classic culprits.

AWS is not simpler than running your own servers. It is more powerful, more elastic, and more standardised, but every service has its own knobs and its own failure modes. The complexity has moved, not disappeared.

AWS is not the only cloud. Azure and Google Cloud are excellent. For specific workloads — say, BigQuery for analytics or Cloud Run for stateless containers — they may be a better fit.

AWS is not a substitute for understanding fundamentals. Networking, Linux, databases, and security are still the foundation. AWS makes them easier to consume but does not let you skip learning them.

Recap

You now know:

• AWS dominates the cloud market and has an enormous service catalogue — focus on the dozen services that do real work
• The four buckets are compute, storage, database, networking
• Regions are geographic; availability zones are isolated data centres inside a region — span AZs for HA
• The free tier is generous but easy to overrun — set a billing alarm first
• An IAM-first mindset, with the root account locked away, is non-negotiable
• Start with S3, EC2, RDS, Lambda, CloudWatch, IAM, Route 53, and CloudFront

Next steps

The next post is your first concrete service: S3, the simplest and most useful place to start. You will create a bucket, upload an object, understand the public-vs-private model, and use the AWS CLI to do real work.

→ Next: AWS S3 Basics: Buckets, Objects, and Permissions

Questions or feedback? Email codeloomdevv@gmail.com.