AWS Fundamentals

AWS has 200+ services. Most applications use a small subset; the rest are noise unless you have a specific need. This page covers the core services and the mental model for understanding the catalog.

The core dozen

The services most workloads touch:

Service	What it is
EC2	Virtual machines
VPC	Private networks
IAM	Identity and access
S3	Object storage
RDS	Managed relational databases
DynamoDB	Managed key-value/document store
Lambda	Serverless functions
API Gateway	HTTP/REST/WebSocket entry point
CloudWatch	Metrics, logs, alarms
Route 53	DNS
CloudFront	CDN
SQS / SNS	Queues and topics

Knowing these well covers most use cases. The other 188 services are specializations — you'll learn them when you need them.

IAM is the foundation

Every AWS interaction is gated by IAM (Identity and Access Management). Users, roles, policies, permissions.

The model:

Users represent people; have credentials.
Roles are assumed by services or users for specific work.
Policies describe permissions (what action on what resource).
Trust policies describe who can assume a role.

Best practice: workloads use roles, not user credentials. EC2 instances have instance profiles; Lambda functions have execution roles. Code calling AWS doesn't need keys — it gets temporary credentials from the role.

VPC: the network

A VPC is a private network in AWS. By default each region has one; you can have many.

Inside:

Subnets (public, private, isolated) — IP ranges in availability zones
Security groups — instance-level firewall rules
NACLs — subnet-level firewall rules
Internet Gateway — public internet access for public subnets
NAT Gateway — outbound internet for private subnets

Most application architecture decisions land in VPC: which subnets, what security group rules, how do services talk to each other.

EC2 vs. Lambda vs. Fargate

The compute decision:

EC2: virtual machines you manage. Most flexible; most operational work.
Fargate (ECS/EKS): container compute without managing EC2. You define container; AWS runs it.
Lambda: function as a service. Truly serverless; AWS manages everything below the function.

For typical applications, the trend is away from EC2 toward Fargate or Lambda. EC2 still wins for: long-running stateful workloads, GPU/special-hardware, tight control over the runtime, predictable steady-state load.

S3 patterns

S3 is the universal AWS storage. Cheap, durable, scales to petabytes. Common patterns:

Static asset hosting: with CloudFront in front
Backups: lifecycle to Glacier for cost
Data lakes: parquet files, queried by Athena or Redshift Spectrum
Application data: user uploads, generated documents
Build artifacts: signed JARs, container images (via ECR which uses S3)

Storage classes are a real choice: Standard for hot data, Standard-IA for warm, Glacier tiers for cold. Lifecycle rules automate the transition.

See CloudStorageOptions.

RDS vs. DynamoDB vs. Aurora

The database decision:

RDS: managed PostgreSQL, MySQL, etc. Familiar relational; full SQL.
Aurora: AWS's clone of MySQL/PostgreSQL with cloud-native storage. Similar API, different economics, better at scale.
DynamoDB: NoSQL key-value/document. Auto-scaling; pay per request; very different access patterns.

For a typical web app, RDS PostgreSQL is the right default. DynamoDB wins for high-scale, simple-access-pattern workloads. Aurora wins for relational workloads that have outgrown standard RDS.

See CloudDatabases.

Cost: where the bill comes from

Most AWS bills are dominated by:

Compute (EC2 hours, Lambda invocations × duration)
Data transfer (egress to internet, cross-AZ traffic)
Storage (S3, EBS, RDS)
Specific premium services (NAT Gateway, ALB, KMS)

Surprises are usually data transfer (cross-region or out-to-internet) or NAT Gateway (per-GB charges add up).

Common failure patterns

Storing credentials in code or config files. Use IAM roles.
Open security groups (0.0.0.0/0:22). SSH open to internet; bots find it within hours.
Single-AZ deployments for production. AZ failure = downtime.
No cost monitoring. Surprises at end of month.
Lift-and-shift without refactoring. "Cloud" without "cloud-native" — still expensive on-prem patterns.
Treating AWS as a single service. Each service has its own quirks; learn the ones you use deeply.