Instead of owning and managing physical hardware, you can access these resources whenever you need them and pay only for what you use. The hardware still exists — it just lives in someone else's data center, abstracted behind APIs.

Before cloud computing, organizations relied on on-premise infrastructure — buying, racking, powering, and operating their own servers in their own buildings.

As applications grew and internet usage exploded, this model became inefficient. The cloud emerged as a way to share large pools of hardware across many tenants, billed by the hour (and later, the millisecond).

Five characteristics — codified by NIST — define a true cloud:

Think of cloud computing the way you think of electricity. You don't build a power plant in your basement — you plug in.

Electricity Grid	Cloud Computing
You don't build your own power plant	You don't own racks of servers
You consume power on demand	You consume compute & storage on demand
You pay a utility bill based on kWh used	You pay a cloud bill based on usage (CPU-hours, GB, requests)
The grid handles generation, transmission, redundancy	The provider handles hardware, failover, capacity
Outages are rare and absorbed by the grid	Failures are isolated to zones; services remain available

Every industry runs on cloud today. A non-exhaustive list:

Cloud computing is implemented through providers — and the largest by market share is AWS (Amazon Web Services). Two foundational services map directly to the diagram above:

AWS abstracts the underlying hardware so you can focus on building applications instead of operating infrastructure.

Model	Owned By	Used By	Typical Fit
Public Cloud	Provider (AWS, Azure, GCP)	Many tenants share	Default for most workloads
Private Cloud	Single organization	One tenant only	Regulated / strict data residency
Hybrid Cloud	Mix of both	Per workload	Lift-and-shift, gradual migration
Multi-Cloud	Multiple providers	Per workload	Avoid lock-in — but more complex

Deep dive → Cloud Models (Deployment & Service)

Myth	Reality
"Cloud means data floats somewhere ethereal."	Data lives in real, physical data centers in specific countries. You can usually pick the region.
"Cloud is always cheaper."	It depends on usage and architecture. Idle reserved capacity or chatty workloads can cost more than on-prem.
"Cloud removes all responsibility."	Wrong — see the Shared Responsibility Model. You still own apps, data, IAM, and configuration.
"Cloud is automatically secure."	The provider secures the infrastructure; you secure what you put in it (mis-configured S3 buckets are the classic failure).
"Cloud is just someone else's computer."	Reductive — you also get global networking, managed services, autoscaling, and a programmable API surface that's not feasible on-prem.

Every AWS service sits inside one of these models. Knowing which model you're working in tells you immediately what you're responsible for — and what you can safely ignore.

Before cloud computing, organizations managed everything:

Cloud providers introduced service models to reduce this burden gradually — letting teams choose exactly how much infrastructure complexity they want to own.

Think of the three models as different housing arrangements:

Model	Housing Analogy	What You Handle
IaaS	🏚️ Empty apartment — four walls, utilities connected	Furniture, appliances, decorating, cleaning — everything inside
PaaS	🛋️ Furnished apartment — furniture and appliances included	Just bring your belongings; don't worry about pipes or wiring
SaaS	🏨 Hotel room — fully serviced, front desk on call	Unpack your suitcase; use the room; someone else cleans it

AWS spans all three models:

Model	AWS Service	What you manage
IaaS	Amazon EC2	OS, AMI, patches, runtime, app, security groups
IaaS	Amazon S3	Bucket policies, data, lifecycle rules
PaaS	AWS Elastic Beanstalk	App code and config; AWS manages OS, runtime, LB
PaaS	AWS Lambda	Function code only; AWS manages everything else
PaaS	Amazon RDS	Schema, queries, data; AWS manages DB engine & OS
SaaS	Amazon WorkMail / Chime	User accounts & configuration only

When to use IaaS: you need full control (custom OS hardening, legacy apps, specific kernel tuning), or you're migrating on-prem workloads with minimal changes.

Deep dive → Amazon EC2 (the canonical IaaS service)

When to use PaaS: you want to ship fast and don't need to tune the OS or runtime. Typical for new web apps, APIs, microservices, and event-driven functions.

When to use SaaS: you need a capability (email, CRM, monitoring) and building it in-house isn't core business. Use the service, not the stack.

Dimension	IaaS	PaaS	SaaS
Control level	High	Medium	Low
Your responsibility	OS, runtime, app, data	App & data only	Configuration & usage
Time to first deploy	Hours–days (infra setup)	Minutes–hours	Minutes (sign up)
Flexibility	Maximum — any OS, any config	Constrained by platform	Vendor's feature set only
Security ownership	You own most of the stack	Shared — infra secured by provider	Provider secures infra; you own data classification
AWS examples	EC2, S3, VPC	Lambda, Beanstalk, RDS	WorkMail, Chime, Amazon Connect

Myth	Reality
"PaaS removes all responsibility."	You still own your application code and data. If your code has a SQL injection, PaaS won't save you.
"IaaS is better because you have more control."	More control = more work. IaaS is right when you need that control — not as a default.
"SaaS is only for non-technical users."	Teams use SaaS tools (GitHub, Datadog, Snowflake) for critical engineering workflows daily.
"These models are mutually exclusive."	Most architectures mix them. A SaaS app might use IaaS for compute, PaaS for its DB, and third-party SaaS for logging.

Without virtualization, AWS could not run millions of isolated customer workloads on shared hardware. Every EC2 instance you launch is a virtual machine. Understanding how virtual machines work is understanding the foundation of cloud compute.

Before virtualization, applications ran directly on dedicated physical servers — a model known as bare-metal computing.

IBM pioneered virtualization in the 1960s on mainframes. It became mainstream in the 2000s when VMware brought it to commodity x86 hardware — and it became the bedrock of modern cloud infrastructure.

Think of a physical server as an apartment building:

Real World	Virtualization
🏢 The building itself	Physical server (CPU, RAM, disk)
🏠 Each individual apartment	Virtual machine (isolated OS + apps)
👷 Building manager	Hypervisor (allocates space, enforces rules)
👥 Tenants sharing the building	Multiple VMs sharing hardware
🔐 Locked apartment doors	VM isolation — one VM can't see another's memory
🔧 Utilities (water, power, internet)	Shared hardware resources (CPU cycles, RAM, network)

Each tenant has their own space and doesn't interfere with neighbours — even though they share the same building's infrastructure.

There are two classes of hypervisor, differing in where they sit relative to the host OS:

Aspect	Type 1 (Bare-metal)	Type 2 (Hosted)
Sits on	Hardware directly	Host operating system
Performance	High — minimal overhead	Lower — extra OS layer
Security isolation	Strong	Weaker (host OS is attack surface)
Primary use	Production clouds, data centers	Developer laptops, testing
Cloud relevance	This is what AWS uses	Not used in cloud providers

When you launch an EC2 instance, AWS:

• Selects a physical host with spare capacity in the chosen AZ
• Nitro hypervisor allocates the requested vCPUs, RAM, and EBS/NVMe storage
• The instance boots your selected AMI (Amazon Machine Image — OS snapshot)
• Your VM is fully isolated from every other customer on that same physical host

Myth	Reality
"VMs are fake computers."	VMs behave like real machines. They have full OS control, networking, storage, and can run any software a physical machine can.
"Each VM gets its own dedicated hardware."	Resources are shared and scheduled by the hypervisor. CPU time is multiplexed; RAM is allocated but pooled across the host.
"Virtualization only exists in the cloud."	Virtualization existed in data centers and developer machines for decades before cloud. Cloud added APIs, billing, and scale on top.
"Containers are the same as VMs."	Containers share the host OS kernel; VMs include a full guest OS. VMs are stronger isolation; containers are lighter-weight.
"The hypervisor adds no overhead."	Modern hypervisors (especially AWS Nitro) are near-zero overhead — but there's always a small cost for resource scheduling and isolation enforcement.

Before picking a single service in AWS you answer one question: which region? That choice determines latency for your users, data sovereignty compliance, and what disaster recovery options you have. This page explains the geography under every AWS workload.

Cloud providers built globally distributed infrastructure to solve these problems at scale — letting any customer get multinational reach without owning a single building.

Think of AWS infrastructure as a global network of cities:

Real World	AWS Infrastructure	Example
🌍 Country / Continent	Global AWS infrastructure	All of AWS worldwide
🏙️ City	Region	Singapore (ap-southeast-1)
🏢 Building district in the city	Availability Zone	ap-southeast-1a, ap-southeast-1b
📬 Local post office / delivery hub	Edge Location	CloudFront PoP in Mumbai
🔐 Fire in one building doesn't spread to others	AZ failure isolation	AZ-a down; AZ-b & AZ-c keep running

Every service you use in AWS has a geographic scope. Knowing the scope tells you what happens during a failure:

Service	Scope	What this means
Amazon EC2	AZ-level	An instance lives in one AZ. Deploy in multiple AZs for HA.
Amazon RDS Multi-AZ	Region (spans AZs)	Primary in one AZ, standby in another. Automatic failover <60s.
Amazon S3	Region (stored across ≥3 AZs)	Eleven 9s durability — survives any single AZ failure.
Elastic Load Balancer	Region (nodes in each AZ)	Distributes traffic across AZs automatically.
Amazon CloudFront	Global (Edge Locations)	Caches at 600+ PoPs — closest possible to the end user.
Amazon Route 53	Global	DNS with health checks — routes around failures automatically.
IAM	Global	Not region-specific — one IAM policy applies everywhere.

Myth	Reality
"A Region is a single data center."	A region contains at least 3 physically separate Availability Zones, each of which can be multiple data centers.
"One AZ is enough for high availability."	Single-AZ is a Single Point of Failure. AWS's SLAs for multi-AZ services assume you're using multiple AZs.
"AZs are just different rooms in one building."	AZs are kilometres apart, on separate power grids with separate networking. A natural disaster or power outage affecting one AZ will not affect another.
"Multi-region is always required."	Most applications only need multi-AZ. Multi-region is for disaster recovery and global latency — it adds real operational complexity and cost.
"Edge Locations are the same as AZs."	Edge Locations only run CloudFront, Route 53, and Shield. You cannot deploy EC2 or databases there. They are delivery nodes, not compute regions.

It's the most important security concept to internalise before you use a single AWS service. Misunderstanding it is the source of the majority of real-world cloud security incidents — not because AWS failed, but because the customer didn't know what they needed to secure.

Responsibility is not eliminated by moving to cloud — it is shared and redistributed depending on which services you use.

Think of cloud infrastructure as a secure apartment building:

Building (AWS)	Apartment (Your workload)
🏢 Guards at the front entrance	🔑 You lock your apartment door
🔐 Secured lifts and common areas	🪟 You close your windows
💡 Electricity and utilities managed	👤 You control who has your key
🔧 Building structure maintained	🧹 You keep your own space tidy
📹 CCTV on the street outside	🚨 You configure your own alarm inside

The majority of cloud security incidents fall on the customer side of the boundary. Common root causes:

Service	AWS Secures	You Secure
Amazon EC2	Host OS, hypervisor, hardware, data center	Guest OS patches, Security Groups, IAM instance profile, app code
Amazon S3	Storage infrastructure, 11-9s durability, hardware redundancy	Bucket policies, ACLs, Block Public Access, KMS encryption, versioning
Amazon RDS	DB engine installation, OS patching, hardware, Multi-AZ failover	DB users & passwords, security group rules, parameter groups, data encryption
AWS Lambda	Runtime, underlying infra, function isolation, scaling	Function code, execution role (IAM), environment variable secrets
Amazon VPC	Physical network, transit infrastructure	Subnets, route tables, Security Groups, NACLs, internet gateway configs
IAM	IAM service availability	Every policy, role, user, group, permission boundary — entirely yours

As you move from IaaS → PaaS → SaaS, your security surface shrinks — but it never disappears:

Recap → Cloud Service Models (IaaS, PaaS, SaaS)

Myth	Reality
"AWS handles all security."	AWS secures the infrastructure. Your applications, IAM policies, and data configurations are entirely your responsibility.
"If data is in the cloud, it's automatically safe."	Data safety depends on your encryption, access controls, and logging config. Misconfigured S3 buckets with sensitive data have caused massive real-world breaches.
"Using managed services removes responsibility."	PaaS and SaaS reduce your attack surface — they don't eliminate it. You still own your data, IAM roles, and application logic.
"AWS compliance certifications cover my workload."	AWS's SOC 2, ISO 27001, etc. cover their infrastructure. For your workload to be compliant, you must implement the required controls on your side of the boundary.
"The boundary is always the same."	The boundary shifts with the service model. On EC2 (IaaS) you own the OS. On RDS (PaaS) you don't. The model must be evaluated per service.

Any engineer can launch an EC2 instance. Far fewer design a system that handles 10× the expected traffic, survives an AZ failure, stays within budget, and keeps operations teams from being paged at 3 am. That's what cloud design principles enable.

In 2015, AWS published the Well-Architected Framework — a structured set of guidance for evaluating and improving cloud architectures across five dimensions. It's now the industry-standard vocabulary for cloud design.

No pillar dominates the others. A system that is perfectly reliable but astronomically expensive is not well-architected. The framework forces you to evaluate trade-offs explicitly rather than optimising one dimension in ignorance of the rest.

Think of cloud architecture like planning a modern city:

City Planning	Cloud Architecture	Well-Architected Pillar
🚦 Traffic management & road redundancy	Multi-AZ load balancing, circuit breakers	Reliability
⚡ Power grid that scales with population	Auto Scaling, serverless compute	Performance Efficiency
🔐 Locks, CCTV, access zones in buildings	IAM least privilege, encryption, VPC isolation	Security
💡 Utilities metered — pay for what you use	Right-sizing, spot instances, savings plans	Cost Optimization
🛠️ City maintenance crews & alert systems	CloudWatch, runbooks, automated remediation	Operational Excellence

AWS provides first-party tooling to operationalise these principles:

• Deploy critical services across at least 2 Availability Zones
• Use Auto Scaling groups for all stateless compute tiers
• Enable Multi-AZ for all production databases (RDS, ElastiCache)
• Implement automated backups and test restores quarterly
• Apply least-privilege IAM with SCPs at the AWS Organizations level
• Encrypt data at rest (KMS) and in transit (TLS 1.2+) everywhere
• Use managed services (RDS, Lambda, SQS) over self-managed equivalents where possible
• Tag every resource: Owner, Environment, CostCenter, Application
• Set billing alarms and AWS Budgets for every account
• Run infrastructure from code (CloudFormation, CDK, Terraform)
• Enable CloudTrail, AWS Config, and GuardDuty in every region and account
• Conduct a formal Well-Architected Review before every major launch

Myth	Reality
"Cloud automatically makes systems scalable."	Cloud gives you scalable primitives. A monolith deployed on EC2 with no Auto Scaling is not scalable just because it's in AWS.
"High performance always means high cost."	Not with the right design. Caching, CDN, right-sizing, and serverless often deliver better performance and lower cost than brute-force compute.
"Best practices are fixed rules to follow blindly."	The framework explicitly says: every principle involves trade-offs. A startup's MVP has different reliability requirements than a banking core system.
"More services = better architecture."	Complexity is a cost. Every additional service adds operational burden and potential failure points. The simplest architecture that meets requirements is the best architecture.
"The Well-Architected Framework only applies to large systems."	Even a personal project benefits from the principles. Cost optimization and security are relevant at any scale.