IT Knowledge DB

AWS Core Concepts

5 min read

AWS Core Concepts

Before touching any specific service, there’s a small set of ideas every AWS user needs. Regions, Availability Zones, the shared-responsibility model, and the split between global and regional services. Getting these right removes half the confusion with everything else.

Regions — geographic locations

A Region is a cluster of data centers in a specific part of the world. Examples: us-east-1 (N. Virginia), eu-central-1 (Frankfurt), ap-southeast-1 (Singapore). There are 30+ regions globally.

Key facts:

  • Services are region-scoped by default. An EC2 instance in eu-central-1 can’t be moved to us-east-1 — you’d have to launch a new instance and migrate data.
  • Pricing varies per region. us-east-1 is typically the cheapest; newer/remote regions cost more.
  • Feature availability varies. Not all services launch in all regions simultaneously. New features usually land in us-east-1 first.
  • Compliance / data residency. You pick the region where your data lives — important for GDPR, HIPAA, and sovereign-cloud requirements.

Why many regions exist: latency (closer is faster), disaster isolation (an earthquake affects one region, not all of them), and regulation.

Availability Zones — isolation within a region

An Availability Zone (AZ) is a logically separate data center within a region. Each region has 3-6 AZs. Examples: us-east-1a, us-east-1b, us-east-1c.

Key facts:

  • AZs are physically separated (different buildings, independent power, cooling, networking) — so a local outage affects one AZ, not all of them.
  • AZs within a region are connected by high-speed, low-latency links (single-digit milliseconds).
  • For a network engineer: think of AZs as physically separated rooms in the same metro area — high availability via redundancy, not geo-distribution.

Design rule: run production workloads across 2+ AZs. A single-AZ architecture is not highly available.

Edge locations — the CDN layer

Separate from regions and AZs, Edge Locations are smaller points of presence worldwide (hundreds of them), used for content delivery (CloudFront), DNS (Route 53), and certain low-latency services (WAF, Shield). Edge locations serve content close to users; origins remain in a region.

Global vs regional services

Most AWS services are regional — you interact with them per region, data stays in that region. A few are global — they don’t belong to any region.

Global services:

  • IAM (users, roles, policies) — one identity pool across all regions
  • Route 53 (DNS) — DNS is inherently global
  • CloudFront (CDN)
  • Organizations (multi-account management)
  • Billing — one bill for your account regardless of region

Regional services (everything else):

  • EC2, VPC, S3, RDS, Lambda, DynamoDB, and ~200 more
  • Notable caveat: S3 bucket names are globally unique even though buckets live in one region

This distinction matters in CloudFormation/Terraform: global resources are declared once; regional resources have to be declared per region you deploy to.

The Shared Responsibility Model

AWS manages some security; you manage the rest. The dividing line varies by service.

┌──────────────────────────────────────────────────────────┐
│  CUSTOMER — "security IN the cloud"                       │
│                                                           │
│    • OS patches, hardening                                │
│    • Application code, libraries                          │
│    • Data (encryption, backups)                           │
│    • Identity & access (IAM users, roles, policies)       │
│    • Firewall (Security Groups, NACLs)                    │
│    • Network segmentation (VPC design)                    │
├──────────────────────────────────────────────────────────┤
│  AWS — "security OF the cloud"                            │
│                                                           │
│    • Physical data centers, hardware                      │
│    • Hypervisors, host OS                                 │
│    • Networking fabric                                    │
│    • Facility security                                    │
└──────────────────────────────────────────────────────────┘

The dividing line shifts with the service abstraction level:

Service typeAWS handlesYou handle
IaaS (EC2)Hardware, hypervisorOS, apps, data, config
PaaS (RDS, ECS Fargate)Hardware, hypervisor, OS, DB engineApp, data, access
SaaS (S3, DynamoDB)Everything except…Data & access control

Corollary: the “security OF the cloud” is AWS’s problem. The “security IN the cloud” is where customer mistakes live — misconfigured IAM, public S3 buckets, open security groups. Most cloud breaches are this kind.

Account structure

  • AWS Account = a container for resources + billing. Root user email is the primary credential.
  • Root user — has unrestricted access; do not use it for daily work. Enable MFA, lock away, create IAM users/roles instead.
  • AWS Organizations — group multiple accounts under one master. Common pattern: one account per environment (prod/dev/sandbox), with Organizations providing central billing + SCPs (Service Control Policies).

Pricing model — at a glance

Three dimensions you’ll see everywhere:

  1. On-demand — pay per use (hour, second, GB, request). Most flexible, most expensive.
  2. Reserved / Savings Plans — commit to usage over 1-3 years → significant discount (30-70%).
  3. Spot — bid on unused capacity → 70-90% discount, but AWS can reclaim with short notice.

Most services have a free tier for the first 12 months and perpetually free limits for some services (Lambda, DynamoDB).

Costs that surprise beginners:

  • Data transfer out (egress to the internet) is often the biggest surprise bill
  • NAT Gateway is charged per hour and per GB processed
  • EBS volumes keep billing even if the EC2 instance is stopped
  • Cross-AZ traffic is not free (but cheaper than cross-region)

How you interact with AWS

Three interfaces, equivalent in capability:

  1. AWS Management Console — web UI. Good for learning, exploration, one-offs.
  2. AWS CLI — aws ec2 describe-instances — scriptable, consistent across services.
  3. SDK / API — boto3 for Python, aws-sdk for JS, etc. — programmatic.

Under the hood, all three call the same REST APIs, authenticated with signed requests using your access keys or temporary credentials from IAM roles.

Mental map for a network engineer

As a network engineer learning AWS, the most useful initial framing:

  • VPC is your customer premise — a private L3 network you own
  • Subnet is a broadcast domain, except there is no broadcast or multicast in AWS
  • Route table is the routing policy for a subnet (like policy-based routing by interface)
  • Internet Gateway is your internet uplink
  • Security Groups are stateful firewall rules, per instance (like a host firewall that follows the instance)
  • NACLs are stateless ACLs, per subnet (closer to traditional router ACLs)
  • Transit Gateway is your MPLS core at hyperscale

See AWS VPC Fundamentals for the detailed version.

See also

Graph View

Backlinks