beginnerintermediateadvanced

AWS · Section 1

AWS Fundamentals

Level: beginner
Read: 22 min
Concepts: 5

AWS is a collection of managed infrastructure and platform services, not a product list to memorize. This section is the vocabulary — account, Region, AZ — and the one security model, shared responsibility, that every later section assumes you already have.

This section

AWS Networking FundamentalsAmazon Web Services

What is true here

A service exists to take an operational problem off your plate — ask what it promises, not just what it is called.
AWS secures the infrastructure **under** a service; configuration, identity and data are always yours.
Most services are Regional. A handful — IAM, Route 53, CloudFront — are global instead.
Nearly every bill is built from the same handful of dimensions: compute, storage, requests, transfer, capacity.

What you will be able to do

Explain the shared responsibility model and place a specific setting on the correct side of it
Tell a Regional service from a global one, and predict what a missing --region flag will do
Read a new service's pricing page by mapping its charges onto the five recurring dimensions
Find and, if needed, request an increase to a service quota before it blocks production traffic

How you reach anything on AWS

You

Console, CLI, or an SDK

One API

every door leads here

AWS's responsibility

infrastructure the service runs on

Your responsibility

configuration, identity, data

AWS Fundamentals

What AWS is, the vocabulary it is described in, and the one model that governs security everywhere.

AWS as managed infrastructure and platform services

standardbeginner

Each AWS service takes over one piece of operational work — racking a server, patching a database, replicating storage — so you design against a promise ("durable," "scales automatically") instead of building it yourself.

Think of it as

Renting an apartment instead of owning a house. The landlord (AWS) fixes the plumbing and the roof; you still choose the furniture, the locks on your own door, and who gets a key.

text

Unmanaged: you run it        Managed: AWS runs it, you configure it
EC2 instance you patch   →   RDS database AWS patches
Self-hosted queue        →   SQS, always available
Servers behind your LB   →   Lambda, no servers at all

Remember: Ask what promise a service makes ("11 nines of durability," "scales to zero") before asking what it is called — the promise is what you are actually buying.

Account, Region, AZ, edge location, and the other core vocabulary

corebeginner

An AWS account is your billing and resource boundary. You work in one Region at a time, a Region is built from several isolated Availability Zones, and every action — Console, CLI, or SDK — is really one API call underneath.

Think of it as

A postal system: the account is your address, a Region is the country, an Availability Zone is one sorting depot in it (there are several, so one burning down does not stop the mail), and an edge location is a small local drop box near the reader instead of the depot.

text

Console   → click, sees the same API
AWS CLI   → aws <service> <action> --region <region>
SDK       → boto3.client("ec2", region_name="us-east-1")

What we're doing: Show that the Region flag matters for a Regional service and is silently ignored for a global one.

terminaltext

aws iam list-users --region eu-west-1
# returns the same users as --region us-east-1 — IAM has no Region

aws ec2 describe-instances --region eu-west-1
# returns ONLY instances created in eu-west-1 — EC2 is Regional

1: IAM is one of a small set of global services — the flag is accepted but has no effect.
4: EC2 is Regional — instances created in one Region are invisible from any other.

Why this works: Most AWS services are Regional: resources you create in one Region do not exist in another, and you must repeat the setup (or replicate deliberately) to appear elsewhere. A handful of services — IAM, Route 53, CloudFront — are global, with one namespace shared across every Region.

Looking for a resource in the wrong Region

Wrong

text

# created the VPC in us-east-1 (the Console's last-used Region)
aws ec2 describe-vpcs --region eu-west-1
# returns nothing — not an error, just an empty, correct answer

Better

text

aws ec2 describe-vpcs --region us-east-1
# or: check which Region the Console top-right selector was on when you created it

What you see: describe-vpcs returns an empty list with no error. The resource exists — just not in the Region you asked about.

Why: A Regional API call only ever sees resources created in that Region. There is no cross-Region search built into a single call, so an empty result reads exactly like "nothing was created" even when something was — just elsewhere.

What contains what

Organization

A group of accounts under one management account.

Account

Your billing and resource boundary.

Region

A geographic area — most services are Regional.

Availability Zone

One or more physically isolated data centers.

Resource

The actual thing — an instance, a bucket, a table.

The building blocks, smallest to largest scope

The building blocks, smallest to largest scope
Term	Scope	What it actually is
Resource	One object	A specific VPC, bucket, or instance — has its own ARN
Availability Zone (AZ)	One data center cluster	Isolated power/network from other AZs in the Region
Region	A geographic area	A group of AZs, e.g. us-east-1 — most services live here
Edge location	Near the end user	CloudFront/Route 53 point of presence, not a full Region
Account	Billing + resource boundary	Everything you create belongs to exactly one account
Organization	A group of accounts	Consolidated billing and account-wide guardrails

Together

text

# One account, working in one Region, using a global service
aws configure --profile prod          # sets the default Region for this profile
aws iam list-users                    # IAM is global — the Region flag is ignored
aws ec2 describe-instances --region us-east-1   # EC2 is Regional — this flag matters

Remember: Most services are Regional and invisible outside the Region they were created in; a small named set (IAM, Route 53, CloudFront) is global instead.

The shared responsibility model

corebeginner

AWS is responsible for security OF the cloud — data centers, hardware, network, host software. You are responsible for security IN the cloud — how you configure each service, who has access, and whether your data is encrypted.

Think of it as

AWS builds and guards the apartment block: the foundations, the walls, the fire suppression. You are responsible for locking your own door, deciding who gets a key, and not leaving valuables on the balcony in plain sight.

text

AWS's side                    Your side
─────────────────             ─────────────────
Physical data centers         IAM users, roles, policies
Host OS and virtualization    Guest OS patches (on EC2)
Network infrastructure        Security groups, NACLs
Managed-service durability    Data you choose to store there

What we're doing: See the split apply differently to two services in the same account.

responsibility.txttext

EC2 instance
  AWS: the physical host, hypervisor, network hardware
  You: guest OS patches, security group rules, what runs on it

S3 bucket
  AWS: durability of stored objects, physical storage infrastructure
  You: bucket policy, Block Public Access setting, encryption choice

2: On EC2, AWS stops at the hypervisor — everything above it, including the OS, is yours.
6: On S3, AWS manages far more internally, but access control is still entirely yours to set.

Why this works: The line between "AWS handles this" and "you handle this" is not fixed — it moves with how managed the service is. A more managed service (S3, Lambda, RDS) shifts more to AWS, but configuration, access control and data choices never move off your side, for any service.

Assuming "managed" means "secured for me"

Wrong

text

# create a bucket, upload customer data, move on
aws s3 mb s3://customer-exports
aws s3 cp report.csv s3://customer-exports/
# Block Public Access left at account defaults, bucket policy never reviewed

Better

text

aws s3 mb s3://customer-exports
aws s3api put-public-access-block \
  --bucket customer-exports \
  --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true
aws s3 cp report.csv s3://customer-exports/

What you see: The bucket and its contents are reachable by anyone with the URL, and nothing in the AWS console or bill flags it as wrong — every setting is valid, just permissive.

Why: "Managed" describes how much of the underlying infrastructure AWS runs, not who is responsible for access control. S3 durability is AWS's job; who can read or write a specific bucket is yours, on every bucket, every time.

Where the line sits, and how it moves

AWS: security OF the cloud

+Physical facilities, power, cooling
+The hypervisor and host infrastructure
+Global network backbone
+Managed-service internals (e.g. RDS engine patching)

You: security IN the cloud

−IAM: who can do what
−Data classification and encryption choices
−Network configuration — security groups, NACLs
−Application-level security and dependency patching

Remember: AWS secures the infrastructure UNDER every service. Configuration, identity, and data ON that service are always yours — "managed" never means "secured for me."

See also: managed services · core concepts

How AWS pricing dimensions generally work

standardbeginner

AWS bills are built from a handful of repeating dimensions — compute time, storage, requests, data leaving AWS, and whether you paid for capacity up front or per use. Nearly every service is some combination of these.

Think of it as

A utility bill, not a subscription. You are charged for what you actually used against a few meters (compute-seconds, gigabytes stored, requests made), not a flat monthly fee — except where you deliberately choose provisioned capacity instead.

text

Pay-as-you-go   → billed for exactly what ran, no commitment
Provisioned     → pay ahead for capacity, cheaper per unit if fully used
Free tier       → a capped monthly allowance on many services, first 12 months or always-free

The pricing dimensions, and where each shows up

The pricing dimensions, and where each shows up
Dimension	Billed by	Example
Compute time	Instance-hours or invocation duration	EC2 per second while running, Lambda per millisecond
Storage	GB stored per month	S3 storage class, EBS volume size
Requests	Per API call or invocation	S3 GET/PUT requests, Lambda invocations
Data transfer	GB moved, mostly outbound	Data leaving a Region to the internet
Provisioned capacity	Reserved ahead of use, cheaper per unit	RDS instance class, DynamoDB provisioned throughput
Managed-service tier	Feature level, not just usage	Support plans, Aurora vs standard RDS

Together

text

# A small file-hosting workload touches four dimensions at once
S3 storage:     50 GB stored              → billed per GB-month
S3 requests:    200,000 GET requests      → billed per 1,000 requests
Data transfer:  10 GB served to the internet → billed per GB out
Lambda compute: 1M invocations, 200ms each   → billed per ms + per invocation

Remember: Data transfer OUT to the internet is billed on most services; data transfer IN is usually free — avoiding egress is usually cheaper, not just faster.

Reading AWS documentation, quotas, and pricing pages

standardbeginner

AWS has hundreds of services and no engineer memorizes them all — the actual skill is going straight to a service's documentation, its quota page, and its pricing page, and reading exactly the part that answers the question in front of you.

Think of it as

A reference manual, not a textbook. You do not read AWS docs cover to cover before starting; you look up the one page — a quota table, a pricing dimension, a diagram — that answers the question you currently have.

text

Docs page      → what a service does and how its API is shaped
Quota page     → per-account, per-Region ceilings (often raisable via a request)
Pricing page   → which dimensions this specific service bills on
Console limits → what you'll actually hit first, day to day

Remember: A quota is not a hard ceiling on what AWS can do — most are a default that can be raised by request before you hit it in production, not after.

See also: pricing dimensions · core concepts